ISSN: 1204-5357

All submissions of the EM system will be redirected to Online Manuscript Submission System. Authors are requested to submit articles directly to Online Manuscript Submission System of respective journal.

The Caring Extranet: Implementing Extranet Business Communities

By Nahum Goldmann
ARRAY Development
[email protected]

Nahum Goldmann has been employed as an executive, scientist and lecturer in leading industrial high-tech firms and academia. He has published several critically acclaimed books that deal with knowledge transfer issues. Currently he leads the development of Extranet based solutions for use in online procurement and electronic banking and commerce.

Visit for more related articles at Journal of Internet Banking and Commerce


With the emergence of Internet commerce (iCommerce) and online transactional delivery of administrative services (iCompliance), world-leading corporations and public sector agencies must swiftly transfer their business to the fast-paced Internet. Their senior executives need to have a clear understanding as to how the new ways of service delivery affect corporate strategies in the global environment. Experience shows that the implementation of expensive push-button applications does not ensure business success on the Internet. For a corporation that must swiftly restructure for survival, a sudden change from a hierarchical bureaucratic model to the entrepreneurial iCommerce venture is likely to be painful. To rapidly restructure itself, an organization needs to establish a special framework, a multiphase program for managing the transition process. This article describes how to define such a framework. It introduces a new fundamental concept of the Extranet Business Community and describes what it consists of, what makes it different from conventional ways of running a business, and how much it might cost.

Shifted paradigms and confused executives

World-leading corporations and public sector agencies usually maintain their competitive edge by successfully deploying unique and rich sets of competencies and processes. With the emergence of Internet commerce (iCommerce) and online transactional delivery of administrative services (iCompliance), they must swiftly transfer their legacy competencies to the fast-paced Internet. Undoubtedly, it is a non-trivial task of monumental proportions — the emerging consensus being that procrastination hurts their very chances for survival.

However, success stories with perceptible return on investment are few and the effort and cost frustrate many executives involved. Management guru Michael Hammer warns that a corporate Web site is useless if an organization does not have a coherent business strategy. "The point is not the Internet, the point is what you do with it." Another common error is to focus on automating back office functions without addressing their integration with the customer-driven front office. That leads to unproductive functional silos within the organization. Until the organization is focused on the single, common goal of serving the customer, the Internet is just a useless distraction.

In the new Net-based knowledge economy, it is strong executive commitment and a proactive knowledge management strategy that could provide a corporation (or a country) with the sense of direction required for worldwide competitive leadership and rapid market growth. A private company that is not tuned to "the Net" (that is, the emerging worldwide information infrastructure) will not sustain its existing competitive advantage. Similarly, a public agency that fails to reengineer itself as a highly proactive advanced knowledge factory has minimal chances of survival in a Net-driven paradigm.

For large corporations, the principal difficulty in charting a new strategic course is that their old management gurus are seldom up to the task of navigating the unfamiliar waters of the new paradigm. Senior partners of leading management consulting firms are often as confused as their clients when it comes to knowing how to succeed in deploying Internet solutions.

In an effort to close the generation gap, corporate executives sometimes turn to young "techies" who are familiar with the "mysterious ways of the Internet" or to the CIO office, as the Internet is supposed to be all about technology. Wasting precious years and resources, they could only discover that HTML-skilled "techies" do not have a clear understanding as to what makes a successful business in any paradigm, old or new. Or they might find that the CIO's are usually more comfortable focusing on technology rather than dealing with clients.

More importantly, they might learn that implementation of any expensive push-button application software does not ensure business success on the Internet.

In fact, little is written on how senior executives can radically change their organizational culture, professional behavior and proven work methods, progressing into an Internet-driven competitive leadership. More than ever, such executives need to have a clear understanding of how the new ways of service delivery affect corporate strategies in the global environment. Ironically, proven ways of running lengthy brainstorming sessions and producing voluminous business plans are in an inherent conflict with the creation of highly personal and paperless Internet business offerings.

For any corporation that must swiftly restructure for survival, a sudden change from a hierarchical bureaucratic model to an entrepreneurial iCommerce venture (see Fig. 1) is likely to be painful. To leverage the opportunities created by Internet and rapidly restructure itself, such an organization-in-transition likely needs to establish a strategic change management framework, a multiphase program for managing the transition process. This article describes how to define such a framework.

Before further exploration about what corporate executives can do to ensure rapid implementation of successful iCommerce solutions, let us describe what they consist of, what makes them different from conventional ways of running a business, and how much they might cost.

Extranet as a Business Opportunity

To many executives, the very existence of their corporate Web site, however primitive or flashy, manifests their movement to the new Internet age. In contrast, corporate clients would rather use this new access channel to ensure that their business transactions are highly efficient and economical. Hence, they have little tolerance for visiting more than once yet another "dead" Web site.

To a corporation with a mission to lead, setting up a Web site or intranet is just the beginning of a long and difficult business journey. To survive and prosper in the new Internet-induced paradigm, an evolving service organization — whether private, public or nonprofit, international or local in scope — must reinvent itself as a vibrant and caring Extranet Business Community (EBC). Extranet (or Extended intranet) was brought into existence as a secure tool for worldwide accessibility of the corporate information network.

In contrast to Extranet, EBC is not a technology but a private business network of several cooperating organizations located outside the corporate firewall. EBC management would typically provide IDs and passwords to certain categories of users and thereafter control their entitlements on an individual or "group-belonging" basis.

In operating terms, EBC can be defined as an aggressively evolving Business Club unified by common interests. Such a club enables the cooperating partners (clients and suppliers) to form a tight business relationship and a strong communication bond (see Fig. 2). As well, being a new type of intermediary, it brings an enticing promise of ultimate user involvement in the service delivery and growth. However, by operating in the "non-physical" business environment, it also imposes unfamiliar constraints on structuring the partnerships and creates a radically different set of operational dependencies

An Extranet Business Community utilizes ubiquitous Internet networking for transactional delivery of administrative services; procurement of goods, services and information; as well as online publishing and consultations. Because it can cost-effectively leverage Internet infrastructure, Extranet is inherently more economical to deploy than a proprietary network. In addition to its data and transactional parts, EBC should provide interactive modules that permit users to exchange information with other stakeholders, not just with computers.

The Extranet of Toshiba America's electronic- imaging division, launched in 1997-98, has been used by 325 U.S. fax machine and copier dealers, 23 Latin American distributors and Toshiba’s own staff. "It's changing our whole business model," says Lisa Richard, the unit's VP of strategic business planning. "Information that used to take time to provide, like a dealer's entire sales history for the past two years, has become so instantaneous that it has set a whole different expectation level. Once you set that standard, you better keep it up because users just get hungrier and hungrier." (The Public Purchaser, March/April 1998, p. 7)

Since the Internet does not recognize geographic borders, an EBC often has to operate as an internationally competitive "non-parochial" enterprise whose reach extends around the globe. In reality it means that if there are compelling economies of scale, it is conceivable that a Mexican food franchiser would outsource its plastic cutlery purchasing to a Taiwanese company, or a European municipality would entrust its land registry to a computer located in Singapore. Even online meetings of a neighborhood community association in rural Iowa could be efficiently moderated by an expert located in South Africa.

On a more fundamental level, the EBC is also likely to redefine the business evolution of a conventional corporation into a "knowledge factory" (Fig. 3). For such an organization, knowledge engineering has to be the core competence, the principal strength that keeps it in business. Knowledge engineering is understood here as the business of gathering data, creating information (new knowledge), and disseminating (selling) it to the client. On the Internet, this is typically done with the use of various business and technology enablers (see Fig. 4)

Proprietary networks are usually defined by their developers. In contrast, EBC members can jointly define how their service should evolve. Extranet normally includes some technical means of tracking the usage of its various elements. Statistical tracking helps EBC management to evolve the effective and popular components and to drop unsuccessful prototypes. The introduction of the feedback system is essential for the ongoing evolution and prosperity of the service, as no Internet service could be created "once and for all".

In this article, we concentrate on the two largest business segments where EBC introduction would be the most effective, namely iCommerce and iCompliance. Unlike the more frequently used term "ecommerce" which mainly covers proprietary solutions, iCommerce deploys the Internet as the principal vehicle for banking and commercial transactions. This usually involves the ongoing processing of numerous relatively small transactions, such as administrative data or low dollar value procurement forms.

According to countless industry surveys, in large and mid sized corporations, these small transactions engage as much as 90% of all overhead resources and cover about a third of all of the corporate purchasing costs. However, only a modest fraction of business-to-business iCommerce involves direct payments. The majority of EBC transactions are likely to take place between established partners, where payments can be easily settled monthly, without much need for ongoing banking involvement. Hence, an often-used argument that iCommerce is unlikely to evolve without the implementation of sophisticated payment protocols is not entirely correct.

iCompliance can be defined as the transactional delivery of administrative services that mainly takes place in the governmental sector (including federal, military, state, municipal, health and educational institutions), the non-governmental sector (for instance, associations) and at large corporations, especially multinationals. Whereas iCompliance usually means the rigidity of rules that govern transactions, iCommerce solutions afford more flexibility.

Although iCompliance rules might be unbending, burdensome and time-consuming to follow, normally they cannot be easily changed without radical changes in the underlining laws, regulations and policies. Hence, iCompliance implementation necessitates the use of sophisticated and complex transactional expert systems, input forms, databases, workflow engines and history databases for transaction audit. Expert system controls are required to enforce the "compliance" of transactions to the demands of convoluted bureaucratic processes. Even though iCompliance technical solutions can usually be deployed as iCommerce applications, the opposite is not necessarily true.

The overall financial value of the iCompliance sector is surprisingly high. According to a leading industry magazine (The Public Purchaser, March/April 1998, p. 7), the combined United States Federal and State annual procurement budgets are in the order of US$500 billion. This amount can be expected to increase sharply with phasing in the Government Paperwork Elimination Act, which sets October 2003 as the deadline for U.S. Federal agencies to conduct all their business electronically (Federal Computer Week, February 2, 1999). Overall, the global market for iCompliance can be estimated in trillions of dollars.

EBC — Is it really about technology?

Some corporate executives are under the impression that telecomputing technologies are the essence of the new information infrastructure. They truly believe that the latest technological gadgetry would realize the elusive goal of obtaining new knowledge without any intellectual effort by the user. Consequently, they make substantial investments in the equipment and software without achieving much tangible return in improved business. Not surprisingly, most of iCommerce initiatives are today financially unsuccessful.

In reality, however, no more than 15-20% of the total information infrastructure costs over the life of a typical iCommerce program would be spent on technology. With its currently typical six to 18-months lifecycles, the computerized gear is often obsolete before it is received and installed. In fact, at any given moment of time, the EBC should aim to invest as little in technology as it reasonably can get away with. According to Randy Daker, CEO of an energy services company in Tucson, AZ, the biggest lesson he learned is that "Instead of starting with technology and trying to make a business out of it, you need to start with a [business] offer and a market that is receptive to the offer … and than work backward to figure out what technology you need to accomplish it." (Eve of an Extranet Explosion, PC Week, Dec. 21/28, 1998, p. 98).

As shown below, cost reduction can be ensured through the careful prototyping of EBC service features. Another effective (albeit non-trivial) tactic is to reduce the overall cost by identifying emerging industry-share leaders, rather than investing in technologies that are already past their prime. This can be achieved by conducting a vendor-neutral selection process — a strategy that is rational, if the overall management cost of the service cycle can be kept low.

For EBC management, it is always the best choice to stay as much technology-neutral as possible, consciously treating EBC technology enablers as commodities. If an iCommerce service becomes very successful, a low-cost commodity solution usually provides a path for its rapid scaling up in partnerships with industry leaders. Of course, no technical solution is truly technology-neutral and could be built as infinitely scaleable; thus this approach involves a certain degree of risk. On the other hand, as fast growing transactional Extranets developed by such leading corporations as, Yahoo, Dell, Microsoft and Compaq clearly illustrate, all Internet-based solutions have to be constantly rebuilt and no amount of roundtable planning can change this fact.

The only pitfall worse than improperly setting up the required information infrastructure is to overbuild one. Any attempt to impose a heavy-duty solution that would "once and for all" resolve all corporate service support needs is futile. Slowly and painfully, with many unnecessary expenses, an organization would learn that the "riskless mother-of-all-Internetservers" is simply unachievable.

In a year or two, running industrial grade Extranet technologies is likely to become a commodity service, outsourced to specialized Internet hosting farms that can keep pace with the constant changes. To minimize the substantial initial investment and the high risk of technology selection, the EBC might outsource delivery of overhead functions that are not their core competencies to specialized services providers. By constantly upgrading their services, such outsourcing farms would keep their applications up-to-date and transactional costs low. No EBC, however rich, can be expected to be for long on the top of all numerous technologies that are required to support its operations. At best, a dollar invested in the "generic" development of mainstream technology solutions will not provide a fair ROI, and at worst is just wasted.

Far too often, an iCommerce development project starts by selecting and integrating "this" or "that" magic server that, according to its vendor, implements "the Extranet solution". In reality, off-the-shelf Internet applications are at present too immature to support a fully functional and commercially viable EBC. In contrast, having a winning business concept is the most important element in creating an Extranet Business Community.

According to Doug Engelbart (a computer visionary who three decades ago created the first computer mouse, word processing, video conferencing, and hyperlinking), there is still a long way to go before the end of the computer revolution. "Companies tell me: 'We have a Web site and an Intranet. We're already there.' I tell them: 'You're just using a wheelbarrow. You haven't really started cultivating the wealth of what you can do.'" (San Jose Mercury News, 10 Dec 98).

Clearly, EBC itself is not a universal remedy for every situation and should not be used without first deriving an underlining business case. This is not to say that endless procrastination is a viable alternative to a proactive business course. However, Web services developed without clear understanding of required substantial commitments inevitably fail.

A successful EBC has to be proactive, result-oriented, and transactional in nature. Its principal goal is to add value and to do so in a cost-effective manner, usually by reintermediating conventional business practices. Reintermediation can be accomplished by leveraging Internet's economies of scale in place of labor-intensive paper-based processes. If costeffectiveness of Internet solutions could not be easily achieved, a viable alternative is to keep the conventional business "as is" rather than to move it online.

Relationship management and community building

Every EBC should be organized as a Business Club where membership has its privileges and duties. Hence, its core competence should be an ongoing community building. By perceptibly caring about its members' needs, an EBC can achieve its main goal of satisfying the unique requirements of every club member using relationship management as its principal service delivery tool.

As much as possible, the EBC should also strive to facilitate members' own related activities that strengthen the sense of the common goal. As well, to keep the members on its site for as long as possible (which is usually good for business), it is essential to partner with other service organizations. An EBC can and should be used as an ever-evolving and inexpensive infrastructure that supports interoperability among these partners.

The strategic partners should be selected to complement the club's own activities, particularly by delivering the non-core functions to the EBC members. Unless its offerings are constantly expanded, a specialized EBC is quite vulnerable to aggressive competition from the far-away clubs that could provide better services at lower prices.

For EBC members, initially the attraction of belonging to a particular Internet club is in achieving substantial economies of scale when buying goods and services. However, an astute vendor should be quite wary of EBC services being positioned as a low-cost commodity, as the Internet can be easily shopped for a better deal elsewhere. Hence, proactive involvement of clients, supplier, partners, personnel and stakeholders and building brand loyalty is literally a matter of an EBC's life and death. Only by managing individual relations through database marketing, dealing with unavoidable exceptions, providing opportunities to learn and mutual sharing of information, can EBC management sustain the club as a vibrant place to belong and to conduct essential business activities.

Relationship management is much easier to say than do. It requires tactfulness, individualized approaches and proactive sales acumen — qualities that are in short supply at the average IT shop (usually the initial runners of corporate Internet or intranet services). Good relationship management is not that easy to describe in quantitative technical terms and it requires constant gauging of client's reaction and immediate readjustment of services offered. Hence, it is typically neglected or even discounted by the "techies" who are accustomed to pushing onesize- fits-all centrally controlled solutions. According to the Canadian marketing executive Ronald F. Hughes, "It is absurd when the Web designer is responsible for implementing a new sales, distribution, support and fulfillment business model".

It is of course much easier to implement a powerful database technology than a winning sales strategy that could leverage Internet's strengths and vitality. According to the standard IT logic, the larger the database engine, the more substantive the iCommerce implementation project. Consequently, in implementing their Web sites many corporations often disregard low-cost tools essential to build individual relations. Instead, they rush to implement large "commerce servers" or other expensive technological gadgetry whose ROI is at best unproven. Worse, they sometimes try to connect the impatient Internet user to a mainframe legacy system that does not even well serve their internal sales force.

Consider that according to the September 1998 survey conducted by Jupiter Communications LLC of New York, 42% of the 125 top-ranked Web sites do not list their email address, have not responded to consumer inquiries in relation to their content, or took more than 5 days to respond. Only 54% of leading retail stores responded in less than a day. Not surprisingly, customers refuse to bond with non-responsive services. As the first transaction involves a substantial overhead in registering and informing the prospective client, it is difficult to see how an iCommerce venture can become profitable without building client loyalty, one customer at the time.

Unlike a conventional trading organization, every EBC is as much an electronic publishing venture engaged in effective and visible information dissemination, as it is a transactional enterprise. Indeed, ongoing information delivery is but a different form of providing Club services to its members. Without constant renewal of essential information, an EBC would lack the sense of vibrancy and leadership that might attract its members to visit again and to use its core services. As with any other publishing venture, such continuing information renewal is only possible with the use of an Editorial Calendar that helps in structuring online publishing.

Another essential community building element that makes EBC different from the conventional trading organizations, is the presence of loosely moderated discussions on various subjects of interest to its members. To EBC suppliers, such discussions might provide all-important early warnings of service deficiencies or to contribute a new perspective on the future evolvement of their offerings.

In the fast-paced Internet environment, ongoing user feedback can become an invaluable corporate asset. The often-cited risks that a subversive participant might try to implant malicious messages in the common discussion areas are valid but could be addressed with the use of editorial tools and procedures. Having clients' criticism on "foreign" territories that EBC cannot control should sound even less attractive to its management and suppliers.

EBC enablers

An effective Extranet Business Community has to include the following seven principal elements:

1. The EBC's terms of success

2. EBC executives

3. EBC professional staff

4. Internet-compatible business enablers

5. Fast download time

6. 7x24x365 support services

7. Off-the-shelf technology enablers

8. Proprietary technology enablers

Let us analyze each of these elements in sequence.

The EBC's terms of success should be clearly spelled out in its mission statement. Due to the transitory nature of this fledging industry, many iCommerce enterprises are organized with the implicit or explicit goal of rapidly capturing the market share, rather than the reasonable expectation of ROI from the enterprise operations. To keep such an enterprise from being little more than a glorified pyramidal scheme, its executives should be careful in managing the terms of success in the environment of overheated growth.

Virtually all large or mediaum size corporation in the developed countries now have Web sites and intranets. However, most have not coupled their backroom legacy systems with the Net operations. To the old-school executives who have never used the Internet, every initial step in transferring the legacy service to paperless environment looks like a large success story (and it is often oversold to them like the one by the developers). Subsequently, it might lead a service's executives to unjustifiable complacency. In the long run, however, the service might rapidly fail, as it is unlikely that its clients and internal users would accept electronic solutions that are not in line with the top Internet interface and operational standards that they are accustomed to.

Responsible EBC executives and management should be firmly committed to both the Club's strategic business success and to the quick start of its client services. EBC introduction is often impossible without the radical change in corporate directions and the old ways of doing business. Strong executive commitment should make possible the re-engineering of organization's operations and taking justifiable business risks along the way.

The EBC executive should be capable of controlling the technology implementation team. Otherwise, the implementation project is likely to expand towards heavy-duty technologies that cannot be justified by iCommerce's needs alone.

Knowledgeable, well-prepared and service-oriented professional staff is the EBC's main operational asset. To assure that people are an integral part of the service, all staff members should have clear understanding of their functions in achieving organizational priorities. The staff should also be empowered to fulfill their professional tasks even as the competitive environment changes.

EBC business enablers help to manage relationships by establishing a strong, lasting and caring bond with every client, reseller ("the channel"), staff member and supplier. For iCommerce, business enablers should be defined somewhat differently than for a conventional enterprise (see Table 1 for the list of EBC business enablers).

EBC staff that routinely manages client entitlements should be careful not to use its business solutions as the tools to control the clients themselves. Instead, they should strive to help their users to conduct their business activities. Any administrative attempt to prevent clients from selecting what they perceive as the most promising way of conducting transactions will likely fail, as creative Internet users would find their ways around any unreasonable restriction or refuse to use the service.

Fast download time. Zona Research study entitled, "The Need for Speed" released in July 1999, summarizes critical web user preferences and tabulates the economic impact of "bailout rates." The study’s results show that fully one third of online shoppers waiting for web pages to download will "bailout" after only 8 (eight!) seconds. Potential lost revenue due to bailout amount to over $73 million per month, whereas an additional $58 million each month in online sales has been lost due to web page loading failures. Increased web traffic and the desire to place more visually appealing content on merchant web pages are slowing load times. Until the underlying bandwidth problem has been solved across the network, the EBC management should standardize on qualitative download time targets (e.g., 15-sec HTML page download through a 14.4kb modem) and insist that these targets are never compromised by bloated graphic design and other non-performing features.

7x24x365 support services are essential, as the EBC typically operates at the convenience of its members, that is, around the clock. A list of support service enablers is presented in Table 2.

Off-the-shelf transaction-support technology enablers facilitate fast introduction of Extranet service and ensure its versatility. By using such customizable enablers, the Extranet can support rapid implementation of iCommerce and iCompliance. As well, these open-standard "generic" tools help to leverage the value of the channel. A separate column in Table 3 marks the enablers that are good candidates for the off-the-shelf selection.

However, it is a common misconception that off-the-shelf technology enablers are the essence of the Extranet and that an iCommerce implementation could be limited to their purchasing and integration. Rather than decrease with the automation, the average cost per transaction sometimes increases compared to labor-intensive legacy operations. This is because the cost of routine data processing is but a negligible part of the overall cost of the transaction. Not surprisingly, the iCommerce development project that is limited to the integration of technologies usually finishes in failure.

The importance of relationship management tools cannot be overestimated as, typically, as much as 94% of business costs are in resolving errors and handling exceptions. It takes a computer to royally mess up an already badly structured sales cycle! Without the implementation of low cost interactive relationship management, it is impossible to realize overly optimistic cost reductions per transaction envisioned in so many iCommerce financial projections.

Hence, an essential technology enabler often neglected in Extranet implementation projects is a set of tools required for interactive relationship management. Interactive relationship management tools should be able to sustain and support a successful decision-making cycle over an extended time span, helping service suppliers to effectively manage ongoing relations with their clients, both individually and as a group.

As an example, ARRAY Development's DeLiberation™ Extranet modules (see include powerful tools for exception management, online help, dispute resolution, peer interaction, online conferencing, electronic collaboration and interactive publishing. Among its big advantages is implementation of the "no clients, no applets" software architecture, which in contrast to other approaches ensures radical cost-reduction in application installation and management.

In contrast to the off-the-shelf technology enablers, certain technological solutions are required to keep EBC's service uniquely positioned on the competitive market. These are strategically important areas where an EBC is expected to excel. Every dollar invested in the development of such proprietary technology enablers is supposed to keep the EBC competitive and hence should be treated as a strategic investment. It is up to the EBC management to decide on what limited selection of technologies constitutes its core competencies and hence should be treated as the strategic investment.

iCompliance as an off-ramp solution

Many large and medium size enterprises already use or plan to introduce Enterprise Resource Planning (ERP) systems, such as SAP, Oracle or PeopleSoft, to manage financial, human resource, manufacturing, procurement and other backroom operations. Executives in corporations that plan to introduce ERP systems often question the need for initiating separate iCompliance systems, or prefer to postpone their introduction until the time their ERP effort is fully completed.

Contemporary ERP systems are quite complex, inflexible and take very long time to install. They often do not provide a good way to reach every person in the corporation, even less to involve external clients and suppliers in rapid redefining of corporate offerings. In contrast, using the Internet or intranet infrastructure already in existence, EBC can reach every stakeholder, servicing their unique needs and soliciting their feedback on how to improve the business.

Both ERP and EBC systems most effectively work in harmony. ERP could provide the core backroom financial operations and reporting, whereas EBC can be structured as an "off-ramp solution" that ensures vital connections to clients and a stream of critical financial data to the ERP engine. The cost of such an EBC implementation would be negligible compared to the cost of customizing standard ERP solutions to support individualized relationship management, a task that it is currently ill equipped to do.

ERP implementation is an ever-evolving task. Experience shows that few, if any such systems are ever "finished". Even after an ERP module is implemented, it might take many years to obtain business value from it. For a growing corporation, it is imprudent to neglect the interactive needs of clients, partners and staff that can meanwhile be served by the use of the EBC.

Costs and payback

By implying that technology integration is the main ingredient of an iCommerce system, its developers often underestimate its substantial implementation and maintenance costs. Table 4 includes extracts from two different evolutionary scales of Web services that address such costs. According to a leading business publication (Nibbling At the $60 Billion E-Commerce Pie, VAR Business, 2 Mar 99), the development and enhancement of US-based iCommerce sites represented a more than US$60-billion business in 1998.

Many initially designed corporate Web sites have been infested with the multimedia and graphics, well suited for presentations to corporate executives instead of satisfying the business demands of service’s clients. As noted in the above-cited article, a typical Fortune 1000 company would have to spend as much as US$780,000 to $1.5 million to remodel a poorly design Web site. Perhaps more important, such a company could relinquish its business leadership, conceding the initiative to upstart competitors.

Since most of the iCommerce development costs have to be earmarked for marketing, content development and servicing, the fall in technology prices observed since 1996 would have little affect on the overall implementation costs. If any, they would be easily offset by the evolving need for technologies that are more sophisticated and the increased costs of non-technical development. As well, the cited prices do not typically include the costs of Internet security implementations, which for a large transactional iCommerce site might run in the millions.

As noted, government and large corporate iCompliance solutions often require expensive development of sophisticated and complex transactional expert systems, input forms, databases and workflow engines. Because their implementation is more rigidly defined and controlled, their per-page and overall implementation costs could be as much as several times higher compared to the iCommerce sites of comparable functionality.

The "soft" costs of maintaining individualized relationships — that is, of attracting and retaining new clients — are usually as substantial as purely technical costs, whether EBCs are used for Internet commerce or to conduct non-for-profit activities. In his 1999 review (The Cost of New Customers, WebServer OnLine Magazine, vol. 4 no. 3, Mar 99), Marty Nemzow builds a strong argument that such "non-technical" tasks are at the core of iCommerce activities. Technology development and maintenance can often be outsourced. However, to ensure financial success, the EBC management should retain strategic tasks like marketing, planning, service structuring, attracting new customers, and statistics gathering and analysis. As well, they have to proactively address considerable "avoidance costs" for crucial business well-being factors — such as managing unavoidable downtimes, disaster contingency planning, security maintenance and audit, as well as managing legal, personnel relations and taxation environments.

According to Nemzow, for a typical transaction-based business, each new customer costs roughly US$800. This number (which consists of $450 for advertising, $125 for account setup, $150 for account billing and MIS services and $60 for credit report clients — see some of its components in Fig. 5) apparently holds true for most Web-based catalog and phone sales. However, the above total does not take into account considerable costs incurred by the clients themselves, often higher than that incurred by the provider. The client’s own costs typically include comparative evaluation of potential providers; lost time for obtaining relevant information and filling application forms; identifying how to best fit your particular circumstances to the standardized service packages offered by providers; dealing with inevitable errors, limitations and exceptions to the application process; and discontinuing the use of the previous service provider.

Thus, in a typical "low dollar value" transactional environment, neither a commercial EBC nor a client are likely to make a profit, or even break even, on their first transaction. Hence, for both parties, maintaining client’s loyalty through long term relationship management is an absolute necessity, a prerequisite for the EBC’s survival.

According to a leading industry publication (The ROIght Stuff, CIO Web Business Magazine, Feb. 1, 1999, pp. 49-54), coming up with a method for measuring Extranet payback can be tricky, as benefits are spread across departments and companies. Perhaps more important, Extranets are supposed to mainly reengineer the processes that involve external partners. However, corporate evaluation structures usually concentrate on making internal activities more efficient and hence are inadequate for Extranet ROI evaluation.

The speed at which the Extranet benefits accrue typically depends on how quickly outsiders are willing to change the way they do business. For EBC managers, it is quite difficult to control effectively such external factors, as it requires measuring the ROI for the business processes that cut across corporate boundaries.

Nonetheless, the bottom-line results of Extranet implementation are often quite positive. Better external links typically result in increased sales, improved customer retention and attracting new customers and business partners. Establishing long-term customer relationships is critically important to the very concept of the Extranet Business Community, as it is virtually impossible to realize a profit on a first Internet transaction with a given client. In a long term, an EBC could become viable only through building the club's brand loyalty and retaining repeat customers.

Based on a comprehensive survey cited in the above article, Forrester Research Inc. of Cambridge, MA have reported in 1999 that Extranets linking companies with their suppliers typically pay for themselves in one to four years. The companies could recoup their Extranet investments even faster, if the benefits were to include less need for working capital due to reduced development cycles or shorter bill collection time. Principal benefits and paybacks for EBC implementation are listed in Table 5.

A proactive framework for managing transition: Reengineering by prototyping

Numerous industry surveys consistently show that only a small share of all large-scale IT projects undertaken by Fortune 1000 companies are delivered on time and within the budget. (Note that this low success rate is characteristic of the best North American corporations that specialize in software development and system integration.) Clearly, a dicey success outcome is inadequate for iCommerce development projects that typically operate in a fast-paced environment, where a missed deadline usually means a missed business opportunity.

Can a low success rate be substantially improved using conventional development methods? According to Jerrold M. Grochow, the CTO of the American Management Systems, the leading system integrator, all conventional IT development plans are based on a number of assumptions that either turn out to be wrong or are bound to change time and again (Feel Like All Your Project Plans Are for Naught? PC Week, November 23, 1998, p. 80). The developers usually assume that specifications are known, the staff assigned to the project has the expected skills and stays on until completion, procured technology works as advertised, the network is robust, and the project sponsors sustain their commitment. And that is not even counting obvious planning mistakes, such as forgotten or underestimated tasks.

It is counterproductive to treat plans as static, ignoring the dozens of external variables that will likely change the original conditions and hence quash the plan. Each time the plan moves to a lower level of detail, the overall estimate inevitably goes up. For a number of structural reasons, systems projects are usually late, resulting in cost overruns and "underdelivery" of features. With the thousands of projects conducted over the years, large system integrators have still not learned how to make a plan that is "right on" and, according to Mr. Grochow, they never will.

The main problem with the EBC implementation is that there are not that many proven "templates for success", hence corporate executives do not usually know what to ask for when starting an iCommerce project. Voluminous system specifications are written by technology experts who pretend that the final system is going to be a well-oiled perpetuum mobile which churns out a continuous flow of identical transactions. These fictional transactions are being eagerly awaited by numerous committed customers, all well trained and highly coherent.

If the responsible executives were reading the product specification (it is hardly a secret that they usually don't), they might have noticed that in its key business assumptions, the contemplated Internet system suspiciously resembles the old legacy system that it is supposed to replace. The logical question is: "Why bother to change a proven technology to a new and unproven one if it will do more or less the same job?" Not surprisingly, the clients that barely tolerate the proprietary system refuse to come in for a second transaction on the newly minted Internet server.

Is there a way to radically improve the development process in the new Internet paradigm? To substantially reduce implementation costs and risks and to achieve swift client acceptance, we have formulated a novel multiphase transition framework optimized to the EBC-development environment. This original change management framework is effective in guiding organizations committed to making a fundamental transition — from a well-respected but perhaps outdated service, to a lean reengineered knowledge factory.

The transition program is an active way to structure and run required iCommerce and iCompliance solutions. It should help an organization to build upon its core competence and the competitive advantage of its key personnel.

To run a transition program, a high-ranking corporate executive should designate a small transition management team and give it a clear mandate for change (that is, to define its terms of success). For example, the team's principal goal could be to prototype and pilot a new iCommerce venture. Achieving that, the team should be able to hard sell the fledging service back to the executives, principal stakeholders and, more important, the prospective clients.

We start a typical development process from the rapid prototyping of the targeted service. Even though the initial prototyping is usually not that expensive, with its initiation the Client's executives do have to accept a certain degree of commitment.

A working prototype should be structured as a set of vibrant, business-like and user-friendly interactive services. It should help the EBC staff to involve prospective clients in the service definition and its subsequent advancements, improvements and scaling up of the critical enablers. It exposes the need for support required from other parts of the organization and from external suppliers. More important, it helps to size up the potential market and various non-technical bottlenecks (such as legal, insurance, payment and security) that have to be resolved before the service could commence.

As well, a working prototype could allow EBC executives and professional staff to visualize essential relationships between the system's technical and organizational elements. By prioritizing various layers of service and support, EBC executives can hope to reduce the duplication and over-investment in non-essential areas that plague many Extranet development projects. Presenting a system's description as a vibrant online service is far superior to producing paper documents that are unlikely to be read or easily understood.

The prototyping phase is usually concluded by validating the EBC service model. For example, the initial testing of functions, approaches and client acceptance could be done by employing focus groups. Alternatively, a limited but intensive probe marketing campaign could be conducted to involve a number of lead users and early adopters in providing some limited services using the prototyped EBC. User comments and corrections should be addressed before the service progresses to the Go/No go Project Gate.

Using the same online tools that are so effective in running the Extranet Business Communities, our development framework ensures drastic improvement in project quality, cost-reduction and fast implementation cycles. If the development team cannot use the same tools as the service clients would have to use, what is the likelihood that the final service would ever succeed?

The completion of the working prototype of the EBC service is as important to the developer as it is to the client. Let's face it, no developer would commit itself to a new project with the objective to fail. Signing off the prototyping phase of the development project equals obtaining a clear commitment from the client.

The developer should try to avoid building a long-term relationship with wavering clients who would not commit modest resources (usually within 15 to 20% of the overall implementation budget) to conduct the conceptualization and prototyping phases. If the client asks upfront for numerous briefings, paper reports, and risk-free guaranties but would try to save on the prototyping phase, it is better not to over-invest in this business relationship as it is unlikely to succeed.

From a prototype to a successful service

Developing an EBC prototype is just a start in a long business journey. In the open environment imposed by the fast-paced Internet paradigm, client needs and business viability of the offered services have to be solved on an ongoing basis. By sharing information on various common initiatives, EBC staff should be able to involve clients and partners in the follow-up service definition and development cycles. The EBC infrastructure should also support proactive promotion across the potential client base of all the services and core competencies residing within the Club.

The EBC Web site should include comprehensive information on all facets of the Club's business activities. As well, the Extranet platform typically consists of a number of interactive elements that are listed in Table 3.


The author is thankful to Stefan Rollwage, Ronald F. Hughes, John Patrick, Richard Bertrand, John Sancin, Keith Spicer, David McGaw, Dr. Irwin Pressman, Marvin Schwartz, John Cockerill, Greg Wright and Sam Wex for editorial comments and fruitful contributions to the discussion on the nature of the concepts described in the article.


Table 1: EBC Business Enablers.


Table 2: 7x24x365 Support Service Enablers.


Table 3: Extranet Enablers.


Table 4: Evolutionary Scales of Web Services.


EBC Implementation: Principal Benefits

1. Shorter development cycles achieved through:

a. implementing collaborative R&D

b. instant access to project data on the road

c. reduced travel and training costs

2. Shorter cycles of:

a. information dissemination

b. orders taking

c. account handling inquiries;

3. Higher efficiencies:

a. in inventory replenishment

b. from intercorporate processing of claims and returns

4. Reduced costs for:

a. labor

b. training new employees

c. mailing of printed catalogs and manuals

d. price quote, order and invoice statement faxing

e. call avoidance

f. In the North American industry, typical cost for placing an order could drop from almost US$200 by as much as 50%