CASE DESCRIPTION

Analysis and Design Issues

Due to the complexity of the issues, the new system had to address and efficiently solve, much attention was paid to the system's early SDLC (System Development Life Cycle) phases, that is analysis and design. Analysis was divided into a requirements determination and a requirements specification sub-phases. During the former, statements of system services and constraints were gathered from all parties involved, namely, all managers of the company's divisions (and subdivisions), representatives of the company's retailers and suppliers (having diverse IT background or previous experience in using an enterprise system), all staff of the IS Division, and foreseen system's users across the company's divisions. Collection of statements was performed through a mix of (both structured and unstructured) interviews and questionnaires, as well as through a careful study of the company's related documents and forms to clearly identify data and work flows. Statements were also classified as concerning an individual user or the whole user community.

Generally speaking, the statements gathered contained the business rules that should be "obeyed" at all times, computations that the system has to carry out, the desired users' views and restrictions on the system's behaviour or development. Having collected the above, a rapid prototype was constructed (in HTML format); this significantly helped the development team to clarify some difficult (vague, contradictory, or overlapping) requirements and avoid misunderstandings early in the development of the project. It should be noted here that most parts of the rapid prototype were reused later, in the implementation phase, since the system was highly web-based.

Rational's Rose CASE tool was extensively used during the requirements specification sub-phase, thus requirements were modelled in UML (Unified Modeling Language). Class diagrams and use case diagrams received much concern in this phase. Moreover, (semi-formal) specifications were drawn concerning the system's performance, usability, maintainability and security. Having concluded, the analysis phase, particular emphasis had been given to the following major issues:

• The system foreseen should efficiently support communication with companies that have their own legacy, EDI-based, enterprise systems. Moreover, all types of interaction with such systems should not affect the traditional working methods of the related companies;

• It should easily support communication with companies (being their retailers or suppliers) that have not an IT background or previous experience in using an enterprise system. For this category of companies, a PC and a connection to the Internet should be sufficient to make business. In addition, such transactions should be based on the use of interactive selection of a set of options and on the completion of user-friendly electronic forms;

• It should provide the appropriate schemas and modules to support business-to-business interaction. Moreover, these should be able to get seamlessly integrated with the existing ERP system to efficiently initiate a series of related actions; and

• It should be based on an open architecture that can be easily extended to address alternative data formats and structures. To this direction, open and widely adopted standards should be preferred.

The design phase consisted of an architectural design and a detailed design sub-phases. During the former, the development team performed a description of the system in terms of its modules, while decisions about the strategies to be followed regarding client, server and middleware issues were taken. It was decided that the proposed framework should rely on two servers using the Microsoft's Windows 2000 Advanced Server operating system. One of them should stand for the system's front-end (Web server) running Microsoft's Commerce Server 2000 and BizTalk Server 2000 applications, while the other for the system's back-end (database) running SQL Server 2000 (the three-tier architecture of the proposed system is illustrated in Exhibit 4). In the sequel, detailed algorithms and data structures for each of the system's modules were developed (detailed design sub-phase). Certainly, some of these algorithms and structures had to be tailored or adapted to all constraints imposed by the previously decided implementation platform. In any case, database design for this platform was not a cumbersome task; logical mappings could be easily created from the previously specified data combination rules. Moreover, user interface design basically concerned the fine-tuning of some parts of the previously developed rapid prototype.

Exhibit 4: The Architecture of the Proposed System

Implementation Issues

XML (eXtensible Markup Language), developed by the World Wide Web Consortium (W3C, see http://www.w3c.org), can efficiently aid companies embarking on e-business, in that it provides the appropriate data format for the related applications (Glushko et al., 1999). More specifically, XML may convey both the contents and structure of a business document, and it has rapidly imposed itself as a popular format for representing business transactions on the Web. At the same time, it is fully flexible, in that it allows a company to set up the document structure that best fulfills its business needs. The structure of an XML document can be formally described in a Document Type Definition (DTD) or an XML schema, whereas appropriate software tools can validate an XML document against a DTD or a schema definition. In addition, the IS Division's manager was aware that a series of industrial standards and tools have been already developed around the XML syntax.

Having seriously considered the above, it was decided that the development of the open e-business information management system for the company's needs had to be highly based on the combination of EDI and XML technologies (Webber, 1998). Following such an approach, the overall framework could efficiently support interaction and cooperation between various types of companies (partners), while the required functionality is delivered over the Internet. Data combination and interoperability issues had to be properly solved at this point. The system implemented can efficiently support communication with companies that have their own legacy, EDI-based, enterprise systems (Karacapilidis, 2001). Moreover, all types of interaction with such systems do not affect the traditional working methods of the companies involved.

Another system's feature is that it can easily support communication with partners that do not have an IT background or previous experience in using an enterprise system. In addition, the company's approach was based on the use of interactive selection of a set of options and on the completion of user-friendly electronic forms. It also provided the appropriate XML schemas and modules to support business-to-business interaction. These can be exploited and seamlessly integrated with the enterprise system of a company to initiate a series of related actions (companies can easily integrate the proposed framework with their own applications). Moreover, the overall framework was based on an "open" architecture that can be easily extended to address alternative data formats and structures. This is due to the advantages of XML, in that it can be adapted according to the needs of various systems and users.

Messages sent and received by the system are in XML format. In cases that a supplier's enterprise system is based on EDI, the appropriate conversion is taking place (all messages submitted and received by such companies adhere to their legacy EDI format). The overall system provides any-to-any format transformation and multiple communication protocols (hypertext transfer protocol, simple mail transfer protocol, flat-file transfer, etc.). In other words, it overcomes the limitations of classical EDI and provides an enterprise with alternative ways of performing electronic transactions.

The system developed consists of three main modules (see Exhibit 5), which deal with the internal workflow management, the demand-side transactions (hold between the company and its customers) and the supply-side transactions (hold between the company and its suppliers). A brief presentation of their specifications together with some technical details of the underlying technology is given below.

Exhibit 5: The Proposed Supply Chain Management System

The Internal Workflow Management Module mainly deals with the processes, and the related documents accompanying them, that are triggered by the reception of an order from a customer. It is based on clearly specified business models of the company this case reports on; however, it has been kept open and extendable to address the requirements of any other enterprise. Information related to an incoming order is embedded in the company's existing ERP system, which in the sequel issues the necessary production orders. Similarly, ERP provides the module with the input needed to monitor the route of an order throughout the company's production units. The module relies on Microsoft's BizTalk Server 2000, which has been successfully tested in various enterprise settings, and provides all tools and methodologies needed for the transformation and routing of business documents, as well as monitoring of the related processes. Exchange of documents is done in W3C-standard XML, while all document transformation can be done in W3C-standard XSLT (Extensible Stylesheet Language Transformations).

Among the tools provided are:

1. BizTalk Messaging Manager, which automates the process of setting up trading profiles and agreements to exchange business documents with applications and trading partners over the Internet. This management technology is based on a graphical user interface;

2. BizTalk Orchestration Designer, which provides a visual environment to design and build dynamic distributed business processes;

3. BizTalk Editor, which easily creates and edits XML document schemas; and

4. BizTalk Mapper, which easily transforms one schema into another generating W3C-standard XSLT files for transforming documents.

The Demand-Side Transactions Module is a Web-based application, through which customers can put an order by filling in some specially designed forms. Moreover, the module allows customers to monitor the status of an order, view the pricing lists and offers of the company, and consider his/her personal account files. Much attention has been paid to keep the related user interface as friendly as possible. The tool is also based on XML technologies and relies on Microsoft's Commerce Server 2000 and SQL Server 2000. The tool is fully customizable to the needs of any user involved, providing easy user profiling and management, transaction processing, product and service management, and targeted marketing and merchandising.

Commerce Server 2000 offers an easy way to build tailored and effective e-commerce solutions. By providing the application framework, together with sophisticated feedback mechanisms and analytical capabilities, it allows for quick development of sites that optimize the customer experience and help establishing closer relationships among the trading partners. Its basic tools comprise:

1. Business Desk, which provides the means for a centralized, web-based management of users, products and services, and marketing campaigns;

2. Profile System, which handles issues such as authentication to use a site and advanced targeting and personalization of users;

3. Business Processing Pipeline System, which helps in tailoring orders and merchandising processes to fit the users requirements, while being able to easily modify them upon business changes;

4. Product Catalog System, which is able to manage millions of products, offer custom catalogues, etc.; and

5. a set of development and administrative tools and pre-built business components.

Finally, SQL Server 2000 is an ideal platform for launching the above set of applications. Its basic features include reliability, robustness, industry-leading performance, scalability, and appropriate management tools. In addition, it provides rich support for XML, easy Web access to database information, and powerful analysis tools, coupled with high availability and tight security.

The Supply-Side Transactions Module manages the electronic interchange of business documents with the suppliers, thus fully covering the supply chain of the company. In its current version, the tool is not based on the Web; instead, it offers data mediation services among the information systems (i.e., ERPs) of two enterprises. A drawback arising here is that the supplier companies should have a satisfactory level of information technology infrastructure. However, future versions are planned to be fully Web-based, in line with the demand side transactions module described above. As illustrated in Exhibit 5, integration of the three modules described above takes place through the Microsoft's Biztalk Server 2000.

Whenever customers want to interact with the enterprise, they have to fill in the appropriate Web forms and submit a message to the system. Messages sent through the Web interfaces may also be converted to any known format required. Additionally, the system is able to handle documents of any type, thus providing flexibility for future extensions. As made clear from the above, the proposed framework by no means affects the existing trading partners. There will be no change in the working methods they use, nor will they need any extra software or hardware resources. On the other side, customers will only need Internet access and a Web browser to interact with the company. The Web forms designed provide them with a user-friendly interface, thus such companies will not need much effort and investments to get fully acquainted with the proposed way of doing business.

Supply Chain Management Issues

Having previously discussed the technical aspects of the framework adopted by the company, this section comments on some supply chain management issues that have impacted the system's analysis, design and implementation. These concern the improvement of the buyer-supplier relationship, the reduction of production costs through a more efficient and up-to-date production planning, and the more efficient inventory management.

Value chain analysis describes the activities within and around an organization, and relates them to an analysis of the competitive strength of the organization or its ability to provide "value-for-money" products or services (Porter, 1985; Shepherd, 1998). The system envisioned by the company had to facilitate the early supplier involvement, which is an accepted practice in many contemporary firms. Usually (but not always), early supplier involvement results in the selection of a simple source of supply, between carefully pre-qualified potential suppliers. While purchasing and supply management have the ultimate responsibility for selecting the "right" source, the selection process can be handled in many ways (Dobler & Burt, 1996). Using the system developed, the company could easily conduct the analysis and make the appropriate selection (Supply Side Transactions Module). After developing a comprehensive list of potential suppliers, the company's next step is to evaluate each perspective supplier individually. Through an elimination process, a list of potential suppliers is developed, which the buying company may be willing to do business with. The supplier list should be complete enough to include every type of criteria desired, such as quality, price and service. The overall system's approach takes into consideration that the evaluation required to determine supplier capability varies with the nature, criticality, complexity and money value of the purchase to be made. All of the above led to an operating situation in which the buyer-supplier relationship was closer and more cooperative than before. Literally speaking, it led to an informal partnership operation aiming at establishing a "win-win" deal.

Another big issue was the reduction of production costs. The company's objectives, concerning production planning and control functions, have always been to coordinate the use of the firm's resources and synchronize the work of all individuals concerned with production, in order to meet required completion dates, at the lowest total cost, consistent with the desired quality. From the early development phases of this project, two important production planning concepts were considered: the former concerned the multi-level nature of the operation of the production planning system, while the latter its dynamic nature (Dobler & Burt, 1996; Thomas & Griffin, 1996). The aggregate planning and the master scheduling activities were certainly top management and staff responsibilities. Activities associated with the material requirements planning and capacity requirements planning activities were primarily falling under the responsibility of production planning and control personnel. Finally, the control of production operations themselves was a joint responsibility of production planning and control personnel and supervisory operating personnel (all in the Production Division). Much attention was paid to avoid reengineering the above issues; the system developed gives restricted access to the appropriate users, maintains the traditional decision making processes, while, at the same time, provides accurate and up-to-date information to all associated parties. All company's managers had agreed that efficient coordination of information and workflows, through the foreseen system, should result in a significant reduction of production costs.

Another supply chain management issue was inventory management. As known, the basic objective of an inventory management system is to determine the most appropriate inventory levels. During the development of the system, the company considered the following inventory categories: production inventories (raw materials, parts, and components), MRO inventories (maintenance, repair and operating supplies), in-process inventories (semi-finished products) and finished goods inventories. Their concern focused on the planning and control of production and MRO inventories at various time periods (weekly, monthly and, in some cases, quarterly or even yearly decisions). Complementary to the above aspects, and in order to make more elaborated decisions about inventory management, the overall approach had to consider the behavior of the inventory-related costs (Kobert, 1992). More specifically, two basic categories of costs were associated with inventories: inventory carrying costs (opportunity cost associated with inventory investment, insurance costs, property taxes, storage costs, obsolescence and deterioration) and inventory acquisition costs, which were not related to inventory size per se, but rather, to the number of orders placed or deliveries received during a given period of time. The system developed keeps full track of the above. Identification of correspondences and development of logical mappings (e.g., SQL views) from the associated diverse sources were the major tasks in this issue.