Streamlining the replenishment process through extended information sharing and collaboration: defining the underlying e-commerce infrastructure

Katerina Pramatari, Georgios I. Doukidis, Panagiotis Miliotis Athens University of Economics & Business Department of Management Science and Technology [Link]@[Link], gjd@[Link], miliotis@[Link] [Link] Abstract
In this paper we address the issue of daily, store-level collaboration and information exchange between retailer and supplier, supporting the replenishment process for the full product range at store level. In the following section we define the requirements for supporting information sharing and collaboration in this context with the objective to streamline the store replenishment process. We then discuss a specific technical approach to meeting these requirements, utilizing the Internet and based on the concept of electronic marketplaces. We further discuss the implications and learnings acquired from implementing and applying the suggested approach in practice, with one big retailer and several suppliers. We conclude this discussion with some closing remarks and suggestions for further development and research in this area. manager to the retailers distribution centre (for centralized deliveries) or may be prepared and agreed in collaboration with the supplier salesman for direct-storedeliveries. The order-decision-making process involves two main decisions: a. which products to order, and b. what quantities to order The objective is to always have the products that consumers demand on the supermarkets shelves, i.e. not to have any stock-outs, and maintain optimum levels of stock in the store, given a pre-defined mix of products to be offered by the store (store-assortment), a fixed ordering schedule and store capacity. The two objectives are performance tradeoffs, as increasing the stock minimizes the possibility for stock-outs and vice versa [3]. What increases or decreases the effectiveness of this decision-making process is the information that the user has available in doing the right judge. We claim that, if all this information was available to the order decision maker the time he or she makes the decision on what products and quantities to order, then this would greatly increase the effectiveness of the ordering process, leading to reduced out-of-stocks and optimized stock levels, but also the efficiency of the process, as the person wouldnt spend time searching right and left for the necessary information. We further claim that the effectiveness of the process could further be improved if the supplier gets involved in this process, as the supplier has a much better knowledge of his products, the appeal they have to consumers, the product marketing activities etc. We use the term Order-Decision-Support-System (ODSS) to refer to a system supporting the order-decisionmaking process, providing the user with all the information and processing logic that are necessary to effectively support the ordering and subsequently the replenishment process. We also use the term Process of Collaborative Store Ordering (PCSO) to further describe the situation where the retailer (store-manager) and supplier (salesman) collaborate in the ordering process, sharing the same product and store information [14].

1. The Store Replenishment Process

On-shelf availability is a critical issue for both manufacturers and retailers today. Having a fully stocked retail shelf improves consumer value, builds consumer loyalty to the brand and shopper loyalty to the store, increases sales and most importantly boosts category profitability. The analysis by Gruen et al. [7] shows that 70-75 percent of out-of-stocks are a direct result of retail store replenishment practices (either underestimating demand or having ordering processes/cycles that are too lengthy) and shelf-restocking practices (product is at the store but not on the shelf). The main objective of the store replenishment process is to ensure that the right products and quantities are replenished back to the store either from the retailers distribution centre (centralized deliveries) or directly by the supplier (direct-store-deliveries). The replenishment process is mainly kicked-off by a command, which is the order, specifying which products and what quantities to be replenished. The order may be placed by a store

In this paper, we address the issue of daily, store-level collaboration and information exchange between retailer and supplier, supporting the replenishment process for the full product range at store level. We suggest an integrated approach to store level replenishment, covering both the cases where collaboration exists and the cases where the store replenishment is the sole responsibility of the retailer. In the following section we define the requirements for supporting information sharing and collaboration in this context with the objective to streamline the store replenishment process. We then discuss a specific technical approach to meeting these requirements, utilizing the Internet and based on the concept of electronic marketplaces. We further discuss the implications and learnings acquired from implementing and applying the suggested approach in practice, with one big retailer and several suppliers. We conclude this discussion with some closing remarks and suggestions for further development and research in this area.

2. Defining the Critical Requirements for Efficient Store-Replenishment and Collaboration

In the following paragraphs we describe the requirements for efficient-store replenishment, information sharing and collaboration, as shortly described above by the terms O-DSS and PCSO. We focus on the requirements that are critical in this context and which represent technological challenges to a bigger or lesser extent, looking at them from four different perspectives: information update, user interface, process requirements and system characteristics.

2.1. Information Update Requirements

The order-decision making process is based on many different pieces of information which either indicate future consumer demand (e.g. past product sales, promotion activities in the store, advertising, product promotional features, shelf space etc.) or affect the product replenishment cycle (e.g. ordering schedule, lead time, stock in the store, product availability at the supplier, etc.). Part or all of this information may be processed by the O-DSS to provide the user with a suggestive order quantity. Nevertheless, the final human judgment and intuition are necessary for the right order to be prepared in a complex environment where consumer demand may be affected by so many different factors that are difficult if not infeasible to be captured and processed in digital format (e.g. the weather).

The required information supporting the ordering process comes from many different sources, regardless of the way the O-DSS is used, i.e. by the store manager alone for the ordering to the retailers distribution centre (central warehouse) or in collaboration with the supplier, following the PCSO model. A main source is the store information system and the retailers central information system but also the suppliers information systems, the product brand managers, the retailer product buyers etc. The point-of-sales (POS) data and stock information should be real time or near real-time (e.g. at most one day old) for the O-DSS to be usable. This need is more critical for daily-fresh food categories, e.g. fruits and vegetables, where the merchandise not sold in a day should be destroyed and the demand may vary greatly from day to day, depending on the weather, the season, the quality of the merchandise etc. Apart from the timely update of information, the most critical requirement for the O-DSS is the quality of data. The biggest issues faced there refer to the accuracy of stock data and the existence of non-active product codes. The existence of non-active product codes results in much bigger product assortments than the actual product assortments in the stores. This becomes a problem in grocery retail, due to the very big number of new product codes introduced and becoming obsolete each month. In order to allow the update of information from the various data sources the system needs to be electronically linked to the various data sources. In addition, because of the frequent updates of information and the big amounts of data, automatic backend integration with the various systems is necessary in order to ensure the prompt information update. The same fact imposes fast data-loading processes, whereas the data to be loaded come in pre-defined ASCII or XML files, as there is no any standard, e.g. EDI, to describe the type of information exchanged. Apart from back-office data-loading processes, the system should be supported with user interface for actors with different roles (e.g. retailer central buyer, supplier product manager), who provide the required input on their side.

2.2. User-Interface and Process Requirements

On the front-end, the main users of the system are: the suppliers salesmen, who in the collaborative model review the information and prepare and send suggestive orders to the stores, and the store managers, who access all the information relevant to the ordering process, review the order proposals prepared either by the system or by the supplier salesmen and confirm/ prepare the final order.

An important parameter that greatly affects the design of the systems interface is the big number of products each user has to deal with. A typical store has more than 10.000 products in the assortment, and more than half or even all of them may be supplied via the central warehouse. An order proposal prepared by the system may contain from 500 to 2.000 products that need to be processed fast so that the final order is prepared and sent. Thus, the fast system response while dealing with large numbers of products is the most critical user-interface requirement. Another user interface requirement has to do with the system friendliness and usability, especially given the low computer-literate level characterizing the store personnel people and to a less extent the supplier salesmen. In the Web context, the term usability covers aspects that influence a sites ease of use [18], navigability [8], consistency of functionality across pages etc. The usability attribute is highly valued by users, as it ensures that they can actually use the product [11]. This also requires that the front-end is customized to the needs of each user role, so that each user sees only the functions that are relevant to him/her. What is even more critical is that each user sees only the data that is relevant to him/her. For example, the store manager should see only the information relevant to the specific store for all the products, whereas the supplier salesman should see only the information relevant to the suppliers products in the stores of his/her responsibility. This information should be presented in user-friendly format, so that the user does not get overloaded with all the different numbers. This further means that only the top numbers are presented to the user and special visual signs (flags) are used to indicate certain data conditions, e.g. the fact that a product participates in a promotional activity. Another set of information system requirements accrues from the characteristics of the replenishment process. As has been described in previous paragraphs, different process scenarios are used for the product replenishment process, depending on whether the products are delivered directly to the store by the supplier or via the retailers central warehouse. However, the people in the store participating in the ordering process are the same, no matter how many different process scenarios are used. An important requirement associated with this fact is that the people in the store should use only ONE system to deal with the ordering process and not many different systems, one for each different replenishment practice, different supplier, different product category etc. This further implies that a retailer who wishes to streamline the internal store ordering to the central warehouse and at the same time collaborate

with the suppliers should use the same underlying system to support both processes. This system should implement the specific process that is relevant to the grocery retail sector and guide the users through it. For example, the replenishment process for direct-store-delivery goods requires that a supplier salesman prepares a suggestive order which is sent to the store manager. The store manager then reviews the suggestive order and confirms the final order. The system functionalities should fit this process scenario and not allow, for example, the supplier salesman to send the final order before it is previously confirmed by the store manager. Because the product replenishment process is one of the more critical, if not the most critical process, for a supermarket, this further implies that the system should be up-and-running whenever the users want to prepare and send orders and in no-way is the user prevented from sending an order. In the opposite case this would result in very important out-of-stock situations with big revenue losses and other negative consequences. In addition, in many cases the stores have specific deadlines to meet for sending the order, e.g. the orders should be sent to the central warehouse or the supplier by 2pm in order to allow for next-day delivery. This makes the requirement for system availability even stricter, especially if a centralized architecture is used, meaning that: the system should be up-and-running all the time a store is open, i.e. from 9am to 9pm, Monday to Saturday, no system down-time is acceptable even in cases of failures, the down-time should not be more than one hour all the data-loading processes should take place in times that the users interaction with the system is not affected, e.g. during the night

2.3. System Requirements

Apart from a strong and reliable system infrastructure, especially if a centralized architecture is to be used, the following comments can be made regarding the system requirements associated with the specific application area, as coming out from the information system characteristics described above: The database management system supporting the application should be robust, able to deal with large volumes of data in very short times, and support both quick-response to user queries and fast data-loading processes. The hardware and communications infrastructure should be robust with no-single point of failure. If a

centralized architecture is used, this further means that redundant elements (e.g. double network cards) and cluster technologies should be used to allow for fail-over and undisturbed application running even in case of full server failures. The system should be linked to the Internet, to enable efficient data links in an interorganizational environment. Automatic data-transformation and loading processes should be in place to enable the back-end integration with the rest of the required systems (e.g. the retailers and the suppliers central systems) [19]. Various levels of security should be applied [1]: o Secure information transmission between the system and the various data sources o Authentication of the data sources o System access to authorized users only o Authenticated user access to the application In the following sections we describe a centralized system meeting the aforementioned requirements from the various perspectives (information update, user interface, process, system). This system follows the electronic marketplace concept, linking many retailers with many suppliers in the context of the store replenishment process.

3. An Internet-based Platform Supporting Store Replenishment and Collaboration

The term enterprise computing architecture is used to describe the set of computing platforms and the data networking facilities to support an organizations information needs [10]. Once rather stable in nature, architectures are now subject to frequent revision as organizations seek to attain the best technological fit. This is no longer a simple task, given the increasing set of technological options [10]. For the implementation of an O-DSS in a grocery retail chain, two alternative architectures should be considered: the centralized and the de-centralized model. a. In the centralized model, the O-DSS operates on a central hosting environment, which is linked to the aforementioned sources of information. The users have access to the O-DSS through a web-interface over the Internet or other network, e.g. VPN. The update of information and the processing of the order proposals takes place centrally for all the stores, but each store sees only the information that is relevant to it. b. In the de-centralized model, the O-DSS operates on the hardware of each store. Each store system is

linked with the relevant sources of information and the user has access to the O-DSS and the order proposal locally. Schuff and St. Louis [15] have analyzed the general benefits of centralization vs. decentralization of application software. In our context, while in the centralized model the users may experience slight delays in the system response, as the O-DSS is accessed via a network connection and not locally, this model is much more efficient in managing all the data integration links and the quality of the data. This task becomes very difficult to manage in the de-centralized model, as the data quality and the data integration links need to be maintained for each store separately. Furthermore, when it comes to collaboration between the stores and the suppliers, the centralized model becomes a prerequisite. The sharing of the daily store-level POS data and other information and the joint participation in the PCSO process becomes possible by linking the store, the retailer central offices and the supplier via a common Internetbased communication and collaboration platform, following the centralized model. Such a platform, if operated by a third party, falls under the broader definition of an electronic marketplace. The vocabulary, which is used to describe this new area of business, is under establishment. Within the e-hub name game [12] the name Internet-driven electronic marketplace (IEMP) or just electronic marketplace (EM) barely prevails against other terms and concepts like B2B marketplaces, e-hubs, e-markets, exchanges, auctions, portals that seem to overlap and mean different things to different people. Skjtt-Larsen et al. [16] use the term Internet-based electronic marketplace (IEMP) and define it as a place on the Internet where many business buyers and suppliers meet, trade, and collaborate. Obviously, an Internet-based collaboration platform enabling efficient store level ordering and collaboration, as described in the previous sections, falls under this definition. If such a platform would be operated by a retailer, then the term private-exchange would be more suitable. In the following paragraphs we describe in more detail the characteristics and design of this Internet-based collaboration platform.

3.1. Platform Architecture

The Internet-based collaboration platform runs on a central hosting environment. The platform is accessed over the public Internet from two different perspectives: a. Over secure FTP or HTTP connections for information exchange from and to the retailers and suppliers information systems.

b. Over authenticated Web access by the application users, using web browser software. Figure 1 gives a schematic representation of the platform architecture. The application design follows the three-tier model [4], where the distinct application layers run on separate hardware modules. The database layer implements all the logic that has to do with the update, processing and storage of data and runs on the database server. Scheduled database batch processes deal with the loading of the necessary data files and the corresponding database update. Other batch processes perform other database
Retailers Central Retailers Central IS Product assortment POS sales Promotions etc. Orders Dispatch Advices FTP/HTTP Connection over Public Internet

tasks, such as the creation of the order proposals for the stores, after the loading of the daily POS data and other information has been completed. The files that need to be sent back to the retailers or the suppliers information systems, such as the order files, are also exported from the database through data export processes, running either upon user request or batch, on a frequent basis. The technology of Microsoft SQL Server 2000 has been used to implement both the database and the data-loading and data-manipulation processes through Data Transformation Services (DTS).

Direct Suppliers IS Product Catalogue Orders Dispatch Advices

Product Catalogue

Centralized Suppliers IS

Collaboration Platform

Authenticated Web Access over Public Internet

Retailer Central Buyers Supermarket Stores

Supplier Salesmen

Figure 1. Platform Architecture The application middle-tier is the interface between the front-end and the database layer. This layer translates the user requests, as coming from the web-front to database requests, incorporating the application and process logic. This layer runs on the web server and has been implemented using the ADO .NET technology. The web-front is the interface to the user and is accessed via web-browser software over an Internet connection. This runs on the web server and all the logic behind the web forms executes on the server and not on the client, i.e. no client code is incorporated in the webforms. Long session-states are also required to give the users enough time to process all the data locally before they interact with the server. For example, when updating an order over the web, a users interactions with the web server may be scarce (e.g. one every twenty minutes) as the user has to process 100 products or more locally before sending a request to the web server to update the order. The ASP .NET technology and Microsofts Internet Information Services Manager have been used to implement this layer of the application.

The central hosting environment that has been used for hosting the platform contained redundant elements (e.g. active-passive database cluster, two web servers in load-balancing, two domain-controllers etc.) so that maximum levels of system availability were ensured. This is schematically presented in Figure 2.
Common Storage

Database Server 1 Primary

Database Cluster

Database Server 2 Secondary

Primary Domain Controller

Web Server-1

Web Cluster

Web Server-2

Secondary Domain Controller

Firewall

Internet

Figure 2. Hardware infrastructure hosting the Platform

3.2. Information Exchange Links

Until recently, electronic links between suppliers and retailers in the grocery retail sector have been limited to the exchange of purchase orders, invoices and shipping notifications, and this just to a limited extent [20]. Lee et al. [10] distinguish between basic and collaborative business-to-business (B2B) electronic communications. In the context of this research we obviously talk about collaborative B2B communication extending beyond the exchange of product catalogues, orders and dispatch advices between retailers and suppliers. The information links required to support efficient store ordering and supply-chain collaboration practices involve, apart from these, the exchange of several other types of information, as described in previous sections. The most common technology for exchanging structured messages, such as orders and dispatch advices,

between larger companies has been the electronic data interchange (EDI), meaning that structured data, by agreed message standards, is transferred from one computer to another, by electronic means [13]. However, there is clearly the need for less expensive methods of data sharing to reach the critical mass required to make electronic communications meaningful to both retailers and suppliers [2]. The advent of the Internet opens up new perspectives for business-tobusiness electronic communications. The suggestive Internet-based collaboration platform follows exactly this trend, utilizing Internet as a means to facilitate extensive information exchange between the business partners and the collaboration platform. Wherever EDI standards exist to describe standard business documents, such as orders and dispatch advices, the EDI file format can be used. In all other cases, the data are exchanged via simple ASCII files with predefined format or even better XML files. The important fact here is that the intermediate collaboration platform acts as a translation hub, translating the data files from any format received (e.g. from a retailer) to the format required for data-loading to the platform or to be sent back to another partner (e.g. to a supplier). In this way, each company has to implement and maintain only one integration link, between the internal information system and the collaboration platform, through which it is able to communicate with all its partners in a many-to-many environment. All the data files (EDI, ASCII, XML) are transferred between the retailers/ suppliers information system and the platform through the Internet. While FTP may be used to support the file transfer, it is suggested that the Web Services technology ([5], [19]) is used instead, where the client-side and server-side applications are developed and customized to the needs of the specific case, ensuring reliable and secure data transfer.

4. Learnings and Implications from the Practical Application

In this section we refer to some learnings and implications derived from applying the aforementioned collaboration platform in practice. This started in the form of a pilot between Hellas Spar Veropoulos, the 3rd largest grocery retail chain in Greece, and three suppliers, the Greek company Elgeka S.A., Procter & Gamble Hellas and Unilever Hellas. The pilot implementation was facilitated by a service provider, operating the collaboration platform. The pilot, which went live on October 1st, 2001, produced very positive business results regarding the reduction of out-of-stocks

[14]. A year after the first application, Veropoulos rolledout the system to all the 130 stores of the retail chain. Despite the very positive business results, there have been several issues associated with the selected technological approach and the extent to which the aforementioned requirements were met. As coming out from the users feedback after the initial implementation, while they could see the value behind the O-DSS and PCSO and the support it provided both to the ordering process but also to other store processes, they considered that there was still room for improvement. Most of the problems the users encountered at this stage centered around the slow system response, owed to both slow Internet connections and poor system usability. The system underwent several changes and improvements before one could say that the new ordering process was not only more effective but also more efficient than the old process and the system could be rolled-out to all the stores. However, once all the stores were using the platform, the users started experiencing significant delays, while the data-loading processes occupied the rest of the time the users were not online. In order to cope with this scalability issue of the application and the large volumes of data, the systems database had to be redesigned for the centralized application model to be usable. Additional improvements in the user interface further improved the systems response time. Providing the users with the possibility to check and validate the orders offline and get connected only to get and send the right information is another step that can be taken towards this direction. Apart from the systems response and usability, an important element, if not the most important, has to do with the quality and timeliness of the information presented to the users through the Internet-based collaboration platform. Both the concept of the O-DSS and PCSO rely on reliable and prompt information update, as the outcome of the ordering process clearly depends on the decision that people take, either collaboratively or on their own, based on the information they see in the system. During the initial stages, several problems were encountered that had a negative impact on the quality of the information presented to the users and, as a result, on the results of the store ordering process. Many of the issues affecting the quality of the information in the system related to back-end integration and communication problems between the retailers and suppliers information systems and the collaboration platform. Furthermore, the alignment of data between the retailers data files and the data files received by suppliers was also an issue. The solutions towards overcoming these issues were sought in the following directions:

The development of robust mechanisms ensuring the reliable transmission of information between the retailers and suppliers information systems and the collaboration platform, which also gave notification in case of failure (e.g. by sending an e-mail or mobile SMS message in the opposite case). The development of robust data-loading procedures performing several checks in order to ensure that the information is updated correctly, even in cases of failures.

5. Conclusions
In this paper we have suggested a technological framework for the implementation of O-DSS and PCSO, based on the Internet and the concept of electronic marketplaces, supporting store-level ordering and collaboration practices. We have discussed the requirements that such a system should meet and we have defined a centralized system and application architecture for its implementation. From the short discussion on the practical implications above, we could conclude that the best architectural approach would be a variation of the centralized model, enabled e.g. by the use of web-services technology, which would allow that part of the processing (e.g. what requires extensive user interaction, such as the order validation) takes place locally, i.e. on the client-side, while the gathering of the information, the management of the order proposal criteria etc. continuous to take place centrally, i.e. on the server-side. This variation overcomes many of the aforementioned issues, but the respective technology needs to be implemented and tested before reliable conclusions can be drawn. Other questions that arise in this context relate to who should be the operator of the collaboration platform. Should this be the retailer or an independent intermediary? What is the impact in each case and what are the factors that should guide this decision? Is this a service that should be offered by a marketplace? Sparks and Wagner [17] report that suppliers are wary of further involvement in e-marketplaces. Disillusioned by pricing and other concessions, they are still waiting to see the promised volume and liquidity levels. On the other hand, they see the emergence of private exchanges, namely invitation only networks that connect a single company to its customers, suppliers or both. A few retailers e.g. Wal-Mart, have had the will and the finance to create priority supply chain information systems and the power to force suppliers to adopt them [17]. Sainsbury is also working on software solutions to build collaborative applications into its private exchange [6].

Other issues refer to the organizational changes triggered in both the retailer and supplier organizations through these new practices, their extent and pace of change. Apparently, these are some of the questions that arise when considering the use of the suggested ecommerce infrastructure for enabling information sharing and collaboration to streamline the replenishment process. Many other questions are still to be identified and answered through both research and practical application. Before we can consider, though, any organizational aspects associated with the use of electronic marketplaces and B2B collaboration, the technology needs the right testing and fine-tuning so that it comes up to the users expectations. What is necessary is to define a specific business objective and process context, so that the requirements are clearly identified. The work presented in this paper is an attempt towards this direction.

[11] J. Nielsen User Interface Directions for the Web Communications of the ACM, Vol. 42, No. 1, 1999, pp. 65-72. [12] J. Obrecht Playing e-hub Name Game, [Link], Vol. 3, July 2000, pp. 9. [13] M. Perfett, What is EDI? NCC Blackwell Limited, Oxford, UK, 1992. [14] K. Pramatari, D. Papakiriakopoulos, A. Poulymenakou, and G.I. Doukidis, New forms of CPFR, The ECR Journal, Vol. 2, No. 2, 2002, pp. 38-43. [15] D. Schuff, and R. St. Louis, Centralization vs. Decentralization of Application Software, Communications of the ACM, Vol. 44, No. 6, 2001, pp. 88-94. [16] T. Skjott-Larsen, H. Kotzab, M. Grieger, Electronic marketplaces and supply chain relationships, Industrial Marketing Management, Vol. 3, No. 2, 2003, pp. 199-210. [17] L. Sparks and B.A. Wagner, Retail exchanges: a research agenda, Supply Chain Management: An International Journal, Vol. 8, No. 3, 2003, pp. 201-208. [18] J.M. Spool, J. Pool, T. Scanlon, C. Snyder, T. DeAngelo, and W. Schroeder, Web Site Usability: A Designers Guide, 1st edition . Morgan Kaufmann Publishers, 1998. [19] M. Stal, Developing and integrating enterprise components and services. Web services. Beyond componentbased computing, Communications of the ACM, Vol. 45, No. 10, 2002, pp. 71-76. [20] G. Stefansson, Business-to-business data sharing: A source for integration of supply chains, International Journal of Production Economics, Vol. 75, 2002, pp. 135146.

6. References
[1] E. Bertino, E. Pagani, G.P. Rossi, and P. Samarati Protecting information on the Web, Communications of the ACM, Vol. 43, No. 11, 2000, pp. 189-199. [2] P. Bradley, Its time to get plugged in Logistics, September 2000, pp. 62-69. [3] T.H. Clark and H.G. Lee Performance interdependence and coordination in business-to-business electronic commerce and supply chain management, Information Technology and Management, Vol. 1, 1/2, 2000, pp. 85-105. [4] J. Edwards and D. DeVoe, 3-Tier Client/Server At Work, John Wiley & Sons Inc., 1997. [5] C. Ferris and J. Farrell What Are Web Services?, Communications of the ACM, Vol. 46, No. 6, 2003, pp. 31. [6] (The) Grocer B2B exchanges must make strides in supply chain services, The Grocer, 18/5/2002. [7] T.W. Gruen, D.S. Corsten, and S. Bharadwaj, Retail Outof-Stocks: A Worldwide examination of Extent Causes and Consumer Responses, The Food Institute Forum (CIES, FMI, GMA), 2002. [8] T. Horgan, Finding the Way, Web Master Magazine, May/June, 1996. [10] S.C. Lee, B.Y. Pak, and H.G. Lee, Business value of B2B electronic commerce: the critical role of inter-firm collaboration, Electronic Commerce Research and Applications, 2003. Article in Press. Available at: [Link] [10] G.S. Nezlek, H.K. Jain, and D.L. Nazareth, An Integrated Approach to Enterprise Computing Architectures, Communications of the ACM, Vol. 42, No. 11, 1999, pp. 82-90.