Survey of E-Business Standardization Initiatives and Requirements Analysis and IDEF Models for Generic Supply Chain Simulation

Transcription

1 Survey of E-Business Standardization Initiatives and Requirements Analysis and IDEF Models for Generic Supply Chain Simulation Adityavijay Rathore, Jayendran Venkateswaran, Dr. Young-Jun Son Department of Systems and Industrial Engineering The University of Arizona, Tucson, AZ Abstract This study is divided into two stages. First, the state-of-the-art e-business initiatives are investigated in terms of their conceptual approach for enabling B2B transactions, enabling models and technologies, and supporting organizations. Second, a requirements analysis for a generic supply chain simulation model is performed. Six focus areas have been identified for a generic supply chain simulation model: 1) a general structure for a supply chain in terms of stages and members at every stage; 2) roles and responsibilities for each member; 3) control strategies (push, pull, or push-pull); 4) interactions between members for each control strategy; 5) information models for the interactions and 6) messaging standards. Each of the six focus areas has been discussed in detail and suggestions are made thereof. Furthermore, functional interactions and their choreography for three control strategies are specified using IDEFØ and IDEF3, respectively. Rapid construction of a high fidelity simulation model from a library of supply chain building blocks is also discussed. 1. Overview Supply chain analysis has become a critical issue for maintaining an edge in today s cutthroat competitive market scenario. It is important for a company to have a clear idea of how its supply chain works and more importantly, how it should work to increase its competitiveness. Important factors that have been found to affect the functioning of a supply chain include: 1) well-defined roles and responsibilities; 2) standardized business choreographies; 3) smooth flow of information and materials through the supply chain and 4) clear and concise exchange of information. Problems arising due to a lack of consideration of these factors have been the basis for various research initiatives. The standardization of various business choreographies, information exchanged and mode of communication have been observed to improve the functioning of the supply chain drastically. Various industry consortiums have been constituted to standardize the interactions between supply chain members. These standardization initiatives provide guidelines for the interactions between supply chain members. Simulation has been found to be a powerful tool for supply chain analysis. For simulation to be applied effectively, it is necessary to accurately model the supply chain in terms of the structure, the member roles, the business processes that occur and the information that is exchanged as part of the business processes. The following sections will deal with the various standardization initiatives and how the concepts can be used for the development of a supply chain simulation model.

2 2. Proposed Framework for Supply Chain Collaboration in an E-Business scenario A generic framework for supply chain collaboration in an e-business scenario has been proposed in this work and is shown in Figure 1. When a Company A requires a product or a service X, it first submits its request to a repository to help search for potential partners. The requirement definition that is entered into the repository should adhere to a common terminology. The search mechanism then provides Company A with potential matches. Based on these search results, Company A further interacts with the identified companies. If both companies can come to a mutual agreement with regards to product specifications, delivery schedules, financial considerations and technological compatibility, a formal collaboration agreement is developed to define the rules of engagement in terms of business process definition, messaging protocol definition, and the information to be exchanged as part of the business process. The agreement may also cover aspects such as legal agreements, information-sharing agreements, etc. The business processes and the information to be exchanged can be developed using the following two approaches: In the first approach, companies directly adopt a standard e-business scenario and the corresponding information models developed by a standard organization. In this case, a complete set of e-business scenarios needs to be available. RosettaNet and NEMI belong to this category (see Sections 3.1 and 3.3). In the second approach, companies customize a specific e-business scenario conforming to the guidelines developed by a standard organization. This approach is more generic and flexible, and therefore, can be applied to different contexts by different companies. ebxml belongs to this category (see Section 3.2). In addition to the business processes and corresponding information exchange, the actual transactions have to cater to a specific messaging protocol. An agreement regarding the communication (messaging) protocols has to be reached between the two parties. Once the abovementioned agreements are determined, the entire process can be performed smoothly. In summary, a framework for supply chain collaboration in an e-business scenario should provide the guidelines for the following aspects: Repository or search mechanism Collaboration agreement Dictionary of common terminology Business process models/modeling Business process information models/modeling Messaging protocol definition

3 Company A Company Bi Company Bn Requirement Definition Requirement Definition Requirement Definition Common Terminology D E S I G N Repository Or Yellow Pages Requirementbased Matching S T A G E No If A & Bi agree to collaborate Yes Formalize Collaboration Agreement O P E R A T I O N Business Process Models Business Process Information Models Company A Messaging Protocol Definition B2B Transaction Business Process Modeling Company B Business Process Information Modeling Figure 1: Proposed framework for e-business process In the following section, various e-business standardization initiatives will be investigated and compared in terms of the criteria and aspects identified in Figure 1.

4 3. Investigation of E-business Standardization Initiatives In this section, we introduce major state-of-the-art e-business initiatives, including 1) RosettaNet, 2) ebxml, 3) NEMI 4) BPMI, and 5) BizTalk, in terms of supporting organizations and key concepts. We further compare and contrast these initiatives with the proposed generic framework in Figure 1 in terms of key aspects defined in Section RosettaNet RosettaNet is a consortium of companies in a high technology industry working towards standardizing business processes among the supply chain members: Supporting Organizations: Companies from the electronic components, information technology, semi-conductor manufacturing, solution provider, and telecommunications industries as a consortium of more than 500 companies. Key Terms: PIP (Partner Interface Processes), RNIF (RosettaNet Implementation Framework), TPA (Trading Partner Agreement), Business and Technical Dictionaries. Reference: RosettaNet divides the entire e-business supply chain domain for which PIPs (Partner Interface Processes) are specified into several clusters. Each cluster is further divided into two or more segments. Each segment comprises several PIPs. Each PIP contains one or more activities, and each activity in turn specifies actions. An example to illustrate this relationship is shown below: CLUSTER 3: Order Management => Segment A: Quote and Order Entry => PIP 3A4: Manage Purchase Order => Activity: Create Purchase Order => Action: Purchase Order Request PIPs include specification of partner business roles (e.g., buyer, seller), business activities involved between the partners, and the type, contents, and sequence of the business documents exchanged by the partners while performing these activities. They also specify the time, security, authentication, and performance constraints of these interactions. The structure and contents of the business documents are specified using XML Schema and associated Message Guidelines. The interactions between the partners are conducted based on network and messaging protocols specified by the RosettaNet Implementation Framework (RNIF). The overview of the RosettaNet compared with the proposed generic framework (see Figure 1) is shown in Figure 2. Although an open repository is not supported, an account maintenance facility is offered through Cluster 1 -> Segment 1A (Partner Review). Further, the Business and Technical Dictionaries define the common terminology for the interactions. As mentioned before, RosettaNet employs Partner Interface Processes (PIPs) as business process models. These PIPs use XML DTDs to specify the information that is exchanged as part of the business process. RosettaNet Implementation Framework (RNIF) specifies the communication protocols for the

5 business transactions. More technical details regarding RosettaNet are discussed in Section 4.1. Company A Company B i Company B n Requirement Definition Requirement Definition Requirement Definition Business and Technical Dictionaries Segment 1A Partner Review Requirementbased Matching Legends: Supported by initiative No If A & Bi agree to collaborate Yes Not supported Trading Partner Agreement Partner Interface Process PIP specific Process Flow Diagram PIP specific XML Schema RosettaNet Implementation Framework Business Process Modeling Business Process Information Modeling Company A B2B Transaction Company B 3.2 ebxml Figure 2: RosettaNet compared with the proposed framework in Figure 1 ebxml is another e-business initiative, and its characteristics are discussed below: Supporting Organizations: The e-business Board for European Standardization ( RosettaNet, OASIS ( Open

6 Applications Group ( and e-centre UK ( Key Terms: ebmss (Messaging Service Specification), BPSS (Business Process Specification Schema), CPP/CPA (Collaboration Protocol Profile/Agreements), Registries & Repositories, Core Components. Reference: Companies wishing to collaborate under the ebxml based e-business framework develop a CPP (Collaboration Protocol Profile) and submit it to the registry. Based on this profile, suitable partners are found. A company may have more than one CPP depending on the role that it plays, i.e. buyer or seller. Once a suitable partner is obtained, a CPA (Collaboration Protocol Agreements) is prepared for further interactions. ebxml employs a business process modeling methodology, referred to as BPSS (Business Process Specification Schema), which provides guidelines for companies to develop their specific business processes. In this aspect, ebxml is more generic than RosettaNet (see PIPs in Section 4.1). It is noted that two different approaches for business process specification have been discussed in Section 2. The BPSS also crossreferences with business processes defined by other standardization initiatives e.g. RosettaNet. ebxml employs a concept of Core Components that are the common elements in a business process. Finally, the communication protocols are managed by the ebmss (Messaging Service Specification). The overview of the ebxml compared with the proposed framework (see Figure 1) is shown in Figure 3. Among five initiatives considered in this report, it has been observed that the ebxml approach is closest to the proposed generic framework in Figure 1.

7 Company A Company Bi Company Bn Requirement Definition Requirement Definition Common Terminology Requirement Definition Collaboration Protocol Profiles Registries and Repositories Requirementbased Matching Legends: No Supported by initiative Not supported If A & Bi agree to collaborate Yes Collaboration Protocol Agreement Cross-referencing with other models like RosettaNet PIPs PIP specific XML Schema Business Process Specification Schema Core Components ebmss Company A B2B Transaction Company B Figure 3: ebxml compared with the proposed framework in Figure NEMI (National Electronics Manufacturing Initiative) NEMI is an initiative of the electronics manufacturing industry towards deployment of new technology, development of standards and efficient business practices. With regards to standards development, NEMI collaborates with RosettaNet and the Association Connecting Electronics Industries (

8 Supporting Organizations: NEMI is supported by more than 60 electronics manufacturers, suppliers, associations, government agencies and universities. Key Terms: PDX standards (Product Data exchange), CAMX standards (Computer Aided Manufacturing using XML). Reference: Two major specifications in this initiative are CAMX (Computer Aided Manufacturing using XML) and PDX (Product Data exchange). CAMX is used for information exchange between electronic assembly equipment and higher level software applications. CAMX comprises of the IPC-2540 that defines shop floor data in the form of XML messages and IPC-2501 that defines how they are to be exchanged in a CAMX environment. PDX is used for exchanging data amongst original equipment manufacturers (OEMs) and electronic manufacturing service (EMS) providers and suppliers. PDX is being integrated into RosettaNet Clusters 2 and 7 that relate to the distribution and update of the production information and the exchange of technical data for manufacturing. The approach that NEMI uses is similar to that of RosettaNet, and therefore, Figure 2 can be applied to NEMI too. However, the scope of NEMI (PDX) is limited to the product information and manufacturing exchange information, which correspond to Clusters 2 and 7 of RosettaNet. 3.4 BPMI (Business Process Management Initiative) The Initiative's mission is to promote and develop the use of Business Process Management (BPM) through the establishment of standards for process design, deployment, execution, maintenance, and optimization: Supporting Organizations: BPMI is a non-profit organization supported by Computer Services Corporation ( IBM ( Infosys Technologies ( PeopleSoft ( SAP ( and other companies. Key Term: BPML (Business Process Modeling Language), BPQL (Business Process Query Language), BPMN (Business Process Modeling Notation). Reference: BPMI defines an e-business process between two organizations as made of three parts: a common public interface and two private implementations. The public interface is common to the partners and is supported by initiatives such as ebxml, RosettaNet and BizTalk. The private implementations are partner specific and can be described in BPML (Business Process Modeling Language). The BPQL (Business Process Query Language) is used to query and control the state of process executions. BPQL relies on UDDI (Universal Description, Discovery and Integration protocol) to provide a standard way of registering, advertising and discovering the public interfaces of e-business processes. While the front end is taken care of by ebxml, RosettaNet and BizTalk, enabling technologies that are applied on the backend include XML Schema, SOAP (Simple Object Access Protocol) and J2EE (Java 2 Platform, Enterprise Edition).

9 The overview of the BPMI compared with the proposed framework (see Figure 1) is shown in Figure 4. As shown in Figure 4, the major focus of BPMI is BPML, while they collaborate with other initiatives for the remaining aspects. Company A Company B i Company B n Requirement Definition Requirement Definition Requirement Definition Common Terminology Repository Or Yellow Pages Requirementbased Matching Legends: No If A & B i agree to collaborate Supported by initiative Not supported Yes Formalize Collaboration Agreement Business Process Models Business Process Information Models Messaging Protocol Definition Business Process Modeling Language Business Process Information Modeling Company A B2B Transaction Company B Figure 4: BPMI compared with the proposed framework in Figure 1

10 3.5 BizTalk BizTalk is a business integration and automation package. It is divided into the following components: BizTalk Server, BizTalk Accelerator, BizTalk Adapters and BizTalk Framework: Supporting Organization: Microsoft ( Key Term: BizTalk Server, BizTalk Accelerator, BizTalk Adapters and BizTalk Framework. Reference: The BizTalk server facilitates the application integration process. It acts as a translator for business documents in one format to another format. The BizTalk Accelerator caters to specific industries and relevant business scenarios. The BizTalk Adapter caters to widely used applications like SAP, SQL Server or Web Services. The BizTalk framework is a set of guidelines that enables reliable messaging between organizations and between applications. BizTalk differs from the other initiatives in its approach, where it supports widely used specific applications such as SAP, SQL Server or Web Services. Compared with other initiatives where a neutral protocol or language is used to specify business interactions, BizTalk Server acts as a medium for communication that provides a translation service for companies running heterogeneous applications. The overview of BizTalk compared with the proposed framework (see Figure 1) is shown in Figure 5.

11 Company A Company Bi Company Bn Documents supported by BizTalk modules Documents supported by BizTalk modules Documents supported by BizTalk modules BizTalk Server Repository Or Yellow Pages Requirementbased Matching Legends: No Supported by initiative Not supported If A & Bi agree Yes to collaborate Yes Formalize Collaboration Agreement BizTalk Accelerator Business Process Models Business Process Information Models BizTalk Framework Business Process Modeling Business Process Information Modeling Company A B2B Transaction Company B Figure 5: BizTalk compared with the proposed framework in Figure 1 4. Details about E-business Standardization Initiatives 4.1 RosettaNet While Section 3.1 has provided an overview of RosettaNet, this section provides more details about it. Partner Interface Processes: They are standardized business processes that pertain to the interactions between members of a high technology supply chain. They are XML-based dialogs between partners. They are classified into eight clusters, each cluster defining a set of core processes. The clusters are shown below:

12 o Cluster 0: RosettaNet Support o Cluster 1: Partner Product and Service Review o Cluster 2: Product Information o Cluster 3: Order Management o Cluster 4: Inventory Management o Cluster 5: Marketing Information Management o Cluster 6: Service and Support o Cluster 7: Manufacturing RosettaNet Dictionaries: The terms used in the PIPs are standardized using the Business and Technical Dictionaries so as to prevent any ambiguity about the grammar usage in PIPs. o RosettaNet Business Dictionary: It is used to define business properties, business data entities and fundamental business data entities under the guidelines of their usage in PIPs. o RosettaNet Technical Dictionary: It provides common properties for defining products for PIPs. RosettaNet Implementation Framework: The PIPs are implemented using the RNIF. These specifications are responsible for the transportation, routing and packaging of the messages. They define the overall business message format for exchange of business documents along with elements to support authentication, authorization, encryption and non-repudiation, details about transfer protocols like HTTP and reliable messaging specifications. PIPs differ in their content but to be part of an interaction, the messages have to cater to a prescribed format which is described using the RNIF. It specifies a consistent mechanism for digital encryption of all RosettaNet messages. It also provides for the acknowledgement of the receipt of messages and error messages. Trading Partner Agreement: This deals with the legal aspects of collaboration, about information sharing and other modules. The TPA documentation is divided into several modules to facilitate review. The TPA includes legal provisions and service-related modules: o General Legal Provisions o Non-Disclosure Agreement o Portal Services o XML Services o EDI Service 4.2 ebxml While Section 3.2 has provided an overview of ebxml, this section provides more details about it: ebmss: The Messaging Service Specifications are similar to the RNIF in functionality. It prescribes an envelope for every message so that the communication is consistent and secure. It takes care of the transport, routing and packaging of messages. BPSS: The Business Process Specification Schema presents a metamodel of the business processes between any two companies. It is designed for a binary

13 collaboration. It has been modeled using the UN/CEFACT Modeling Methodology (UMM). The UMM describes the business semantics and using them, companies can model their scenarios based on their own requirements out of a business process. The BPSS is a subset of the UMM metamodel. In the domain of ebxml, the UMM metamodel contains more than the necessary information, hence the subset BPSS contains only the information required to configure ebxml compliant software. CPP/CPA: The Collaboration Protocol Profile describes the capabilities and protocols of message exchange between two companies engaged in a business process. The way in which a party can collaborate is described by the CPP. A company may have more than one CPP depending on the different job roles that it requires to perform. It includes the organizational details along with the communication and security protocols supported by the company. The message exchange agreement can be described by the Collaboration Protocol Agreement. It is functionally similar to the TPA in RosettaNet. Registries & Repositories: A company wishing to do a business using ebxml enters relevant information about the company and information about its communication architecture and protocols in the Registry. It is through this Registry that the process of discovery of partners takes place. A Registry stores a company s business profile which describes the company s ebxml capabilities and the scenarios supported by the company based on the CPP. On the basis of this information with the Registry, prospective business partners meet each other. Core Components: When you look at any business document with a view to answering questions like who, what, where, when and why, there is an underlying common base. What can be a product or a service exchanged between organizations and individuals. This common link is utilized in the Core Component architecture by using structured information and the use of layers. The structure uses a series of layers, designed to take into account the common links amongst business processes. Core components are structurally context free and are used in a particular context to convey the message. 4.3 NEMI The main aspects of NEMI are: CAMX Standards: Computer aided manufacturing using XML define a common system of exchanging information among a system of electronic assembly equipment and higher-level applications. They consist of the IPC-2540 and IPC-2501 which respectively define the exchange of information in terms of XML messages and a guideline to exchange these messages. PDX Standards: The Product Data Exchange standards are used to exchange technical data in a common language. NEMI works in conjunction with RosettaNet and IPC (Association Connecting Electronics Industries) for enabling compatibility between the different standards. The IPC standards considered here are o IPC Product Information: The standard is designed to transfer technical information including bill of materials (BOM), approved manufacturer list (AML), as-built product configuration, and change information regarding the engineering, manufacturing or product aspects.

14 o IPC As-built product configuration and manufacturing process information: The information represented in this standard includes: as-built product characteristics related to form, fit and function; serialization; batch/lot information; manufacturing site; manufacturing date; part number; component and sub-assembly data. o IPC-2577-As-built quality assessment and manufacturing process yield information: The information represented by this standard may be used to improve manufacturing processes and design criteria to incorporate design for excellence principles. o IPC Information for distributed manufacturing: The information includes the Bill of Materials, Approved Manufacturers List, and Approved Suppliers List. It supports changes in engineering orders and also possesses a description of the component listed on the Bill of Materials. 4.4 BPMI An e-business process can be defined as made of three parts: a common public interface and two private implementations. The main aspects of the Business Process Management Initiative discussed in the previous sections are: BPML: The public interface is common to the partners and is supported by initiatives such as ebxml, RosettaNet and BizTalk. The private implementations are partner specific and can be described in Business Process Modeling Language. BPQL: The BPQL (Business Process Query Language) is used to query and control the state of process executions. BPQL relies on UDDI to provide a standard way of registering, advertising and discovering the public interfaces of e-business processes. 4.5 BizTalk The main aspects of BizTalk are: BizTalk Server: The BizTalk server is based on the BizTalk framework. It facilitates the process of integration of applications. In a B2B transaction, there are instances where the business document received from one organization may follow X protocol and the organization where the business document is headed may be using Y protocols. It is in such scenarios that the BizTalk server plays the role of an application integrator. BizTalk Accelerators: Accelerators are used to speed up the process of application integration. They cater to specific industries and hence speed up the process of integration in their field. They support a broad spectrum of business scenarios and industries. BizTalk Adapters: The adapters facilitate the integration of enterprise applications like SAP, IBM MQ series, SQL Server and Web Services. This results in speeding up of the integration process because of wide spread use of these applications. BizTalk Framework: It is a set of guidelines that enables reliable message exchange between organizations and applications. It comprises rules for creating message schemas for document exchange. The framework is based on SOAP. It acts on the XML tags (Biztags) present in the BizTalk document.

15 4.6 Summary of Comparison In the previous sections, five state-of-the-art e-business initiatives have been compared with respect to the generic Framework proposed in Figure 1. Table 1 shows a summary of these comparisons against several criteria.

16 Table 1: Summary of comparison of five e-business initiatives against the proposed framework in Figure 1 Criteria RosettaNet ebxml NEMI BPMI BizTalk EC, SM, IT, TC OASIS, Open Electronic mfrs, SAP, PeopleSoft, industries in a Applications Group, Government CSC, IBM, Infosys Microsoft consortium of 500 RosettaNet, BES, e- agencies, and others companies centre UK Universities Organizational Support Common Terminology Repository/Search mechanism Collaboration Agreement Business Process Model Information model Scope of information model Business Process Modeling Information modeling Messaging Specifications Scope of Application Business & Technical Dictionaries Cluster 1 Segment 1A Partner Review Trading Partner Agreement PIP specific Process Flow Diagram PIP specific XML Schema Business and Production RNIF Caters to the High Technology Supply Chain Collaboration Protocol Profiles Registries & Repositories Collaboration Protocol Agreement Cross Referencing with RosettaNet and other initiatives Business and Production Core Components and BPSS ebmss Generic Supply Chain model PDX standards that are being integrated with RosettaNet and IPC for implementation Production Based on RosettaNet & IPC Electronic Manufacturing Industry UDDI based BPQL Based on other e- business initiatives BPML SOAP, based on other e-business initiatives Business process modeling BizTalk supported applications BizTalk Accelerators and Adapters BizTag documents Business and Production BizTalk Framework Enterprise applications running on BizTalkcompatible modules

17 5. Standardization Initiatives and Supply Chain Collaboration Standardization initiatives focus on six major aspects for inter-company collaboration as mentioned previously: Repository or search mechanism Collaboration agreement Dictionary of common terminology Business process models/modeling Business process information models/modeling Messaging protocol definition Based on our analysis of the standardization initiatives, five major focus areas have been identified for the development of a supply chain simulation model and they are: A generic structure for a supply chain in terms of stages and members at every stage. Roles and responsibilities for each member. Interactions between members. The information models of the proposed set of interactions. The messaging standards. 6. Requirement Analysis for Supply Chain Simulation Model Supply chains normally function under two different environments. They can be either a part of the same company with a centralized controller i.e. business headquarters and a set of standard operating procedures, or they can be different companies collaborating in a mutually beneficial pattern. The supply chains of the second type are more prominent. Because of the rapidly changing customer demands and the responsiveness in terms of product variety and availability, it becomes necessary for companies to collaborate and share responsibilities. In a supply chain, there exist three levels of decision hierarchy: 1) competitive strategy; 2) tactical plans and 3) operational routines. The scope of our analysis is the consideration of operational routines. Our research approaches supply chain interactions as a set of buyer-seller interactions that take place between members of consecutive stages of a supply chain. This buyer-seller relationship has been addressed in terms of business processes conducted, information exchanged and the precedence relation of different business processes. 6.1 Stages of a Supply Chain A supply chain can be divided into the following five stages (Chopra and Meindl, 2001) as illustrated in Figure 6: Supplier Manufacturer Distributor Retailer Customer

18 Supplier Manufacturer Distributor Retailer Customer Figure 6: Different stages of a supply chain Even though each stage of the supply chain may consist of more than one member, the functional profile of each of the members in any particular stage may be common, e.g. there may be more than one raw material supplier or there could be a supplier for subcomponents that may be used in the manufacture of the final product, but in the perspective of the supply chain, both the raw material supplier and the sub-component supplier belong to the same stage. In the five stages of the supply chain discussed above, the transporter member is a common element between all the stages. Figure 6 shows the flow of a product from the supplier till the customer. During the passage through the supply chain, the value of the raw material increases at each stage. The six types of supply chain members are defined as the following: Customer: The customer defines the final destination of the product. The supply chain s activities exist to satisfy the demands of the customer. Retailer: The retailer is the final functional downstream member in the supply chain. Based on the customers demands and feedback the retailer places orders with the distributor/manufacturer. Distributor: The distributor manages the inventory of finished products. The distributor can be a part of the manufacturer or a separate entity. If it is a part of the manufacturer, then it functions as a warehouse for storage of finished products. If it is a separate entity, it correlates the customer demands through the retailer channel with the production orders for the manufacturer. Manufacturer: The manufacturer is the final stage of the manufacturing process of the product. It can also be equivalent to the assembler. Supplier: The supplier provides the manufacturer with raw materials and subcomponents that are used directly in the manufacture of the product. Transporter: The transporter takes care of the transport of the raw materials and products between members of the various stages of the supply chain. 6.2 Interactions between Members from Generic Buyer-Seller Perspective Interactions in a supply chain can be generically described by a buyer-seller relationship between consecutive stages of the supply chain. The buyer-seller relations possible in a supply chain are shown in Table 2. Table 2: Buyer-Seller relationships in a supply chain Buyer Seller Manufacturer Supplier (raw material, sub-components) Distributor Manufacturer Retailer Distributor Customer Retailer

19 A pattern is observed in the interaction of the members with the transporter which includes the placement of a transport order to transport raw materials, sub-components or finished goods from a seller to a buyer in the supply chain. The common interactions that are possible between members of any two stages of a supply chain are divided into the following three areas: Product information exchange which depends on the stages of the supply chain. Interactions for order management including order shipment. Interactions for management of inventory. A comprehensive set of interactions that are possible within the scope of our supply chain analysis have been classified into 7 business processes. These business processes comprise of a set of messages. The interactions presented in this work have been compiled after an exhaustive review of present e-business initiatives like RosettaNet, NEMI and available supply chain literature. The business processes from a generic buyer and seller perspective are enumerated below (the left column denotes the message and the right column denotes the response to the message. The messages (and business processes) and their information models for each pair (see Table 2) of supply chain members will be discussed individually in Sections 6.6 and 6.7. Product Manufacturing Information Exchange Process Request Product Design Information Provide Design Information Request Bill of Material Provide Bill of Material Provide Work in Process Status Acknowledge Work in Process Status Pre-Order Interaction Process Request for Quote Request for Quote Adjustments Order Placement Process Place Order Request Order Change/Clarification Request Status of Order Order Delivery Process Issue Transport Order Request Status of Shipment Confirm Shipment of Order Issue Transport Order Change Order Payment Process Notify Invoice Inventory Management Process Provide Inventory Report Provide Quote Respond to Quote Adjustments Confirm Receipt of Order Provide Order Change/Clarification Provide Status of Order Confirm Transport Order Provide Status of Shipment Confirm Shipment Receipt Confirm Transport Order Change Issue Payment Acknowledge Inventory Report

20 Forecast Development Create Forecast Resolve Changes to Forecast Propose Changes to Forecast Confirm Forecast 6.3 IDEFØ Representation of Supply Chain Activity An IDEFØ functional model is used to describe the components of a supply chain and the flow of information and objects among the components. IDEFØ is a systematic methodology for static functional specification of the system. The functional specification or model is a structured representation of the functions within the system, along with the flow of information and objects which relate the functions. In an IDEFØ diagram the rectangular boxes represents the functions and the arrows represent the information and object flow. Arrows entering on the left side of the box are the inputs to the function; arrows entering the top of the box are the control on the function; arrows entering the bottom of the box are the mechanisms that perform the function; and the arrows leaving the box on the right side are the outputs of the function. A function can be further decomposed into multiple sub-functions and is shown by a rectangular box with a shadow. In Figure 7 the input to the system are the raw materials and the output is the final products supplied to the customer. The suppliers, manufacturers, distributors, retailers and transporters act as the mechanisms to the supply chain function A0. The scheduling policy, production policy, resource capacity, inventory status and the demand act as the controls to the supply chain functions. Figure 7: IDEFØ model showing supply chain activity

21 A supply chain system as shown in Figure 7 can be decomposed into five functions: 1) Supply 2) Manufacture 3) Distribute 4) Retail and 5) Transport. The supply chain activities have been described as a set of buyer-seller relationships in Table 2. This buyer-seller relationship has been addressed in the decomposition shown in Figure 8. A further decomposition of the buyer activity has been shown in Figure 9. An IDEFØ model representing the buyer-seller relationship for the case of the manufacturer (buyer) and supplier (seller) along with the transporter is shown in Figure 8. A1 represents the Supply function, A2 represents the Transport function and A3 represents the Manufacture function. It is noted that the functions A1 and A3 can be modified to represent the buyerseller relationships in the supply chain as shown Table 2. The set of interactions specific to the interacting members will be discussed in Section 6.6 Supply (A1): It acts as the source for the A3. The inputs to A1 include the Raw Materials and the Orders from A3. The functioning of the A1 is controlled by the Scheduling Policy, Production Policy, Inventory Status. Resource Capacity, Product Design Information, Bill of Materials, Request for Quote and Shipment Status. A1 request Product Design Information and the Bill of Materials from A3. Once it receives this information, it works on the Order. It can receive Receive Status of Order from A3 and responds with the Order Status. It also provides A3 with Work in Process Status. On completion of the order it issues a Transport Order to A2 so that the Products can be transported to the Manufacturer. Once a confirmation of the receipt of shipment is received from A3, It sends an Order Invoice to A3. A3 responds with the Order Payment. It also receives a Shipment Invoice from A2 and responds with Shipment Payment. Transport (A2): It serves as a logistical function between A1 and A3. It receives a Transport Order from A1 and sends back a confirmation. It receives Products from A1 and transports them to A2. On receiving a Request for Shipment Status from either A1 or A3, it provides the Shipment Status. Once it has delivered a shipment to A3, it sends out a Shipment Invoice to A1 and receives Payment for the same. Manufacture (A3): The Scheduling Policy, Production Policy and the Inventory Status act as controls to A3. It receives Demand as an input and sends out a Request for Quote to A1. A1 queries it for Product Design Information and the Bill of Materials and it provides the same. Based on the Quote received from A1, it makes a decision about Ordering. Once it has placed an Order, it sends out a Request for Status of Order to A1 and schedules product deliveries based on the Order Status it receives. It is informed of Order Shipment by A1. It requests A2 for Shipment Status and receives Shipment Status from A2. On receipt of the delivery of the order, it sends out a Confirmation of Shipment Receipt to A1. Then it receives an Order Invoice from A1 and based on it, makes a Payment.

22 C1 C3 C2 C4 Scheduling Policy Resource Capacity Production Policy C5 Demand Inventory Status I1 Raw Materials Supply A1 Confirm Shipment of Order Request Product Design Information Confirm Receipt of Order Work in Process Status Status of Order Request for Bill of Materials Quote Order Invoice Request for Status of Shipment Products Shipping Payment Change Transport Order Transport Order Transport A2 Confirm Transport Order Status of Shipment Products Shipment Invoice Manufacture A3 Request for Status of Shipment Bill of Materials Product Design Information Request for Quote Request Status of Order Confirm Shipment Receipt Order Payment Change Transport Order Final Products O1 Retailer Distributor Supplier Transporter Manufacturer M4 M5 M1 M3 M2 Figure 8: IDEFØ model showing level 1 decomposition of supply chain activity

23 A decomposition of A3 is shown in Figure 9. It assumes the buyer as a part of a push supply chain. It comprises of 6 functions: 1) Develop Forecast (A31) 2) Schedule Production (A32) 3) Manage Pre-Order Interaction (A33) 4) Monitor Order Progress (A34) 5) Receive Completed Orders (A35) and 6) Manufacture Final Products (A36). Each of the functions has been discussed below: Develop Forecast (A31): It develops a forecast for the manufacturer s activities based on the Inventory Status, Demand and Resource Capacity. The Forecasting Department acts as the mechanism for this function. Schedule Production (A32): It uses the Scheduling Policy, Resource Capacity and Production Policy and the Forecast, to prepare a Production Schedule and calculate the Material Requirements. The Purchasing Department acts as the mechanism for this function. Manage Pre-Order Interaction (A33): Based on the Production Schedule and Material Requirements, this function gives out Request for Quotes. It provides prospective sellers with Product Design Information and Bill of Materials on request to prepare their Quote. Based on the Quotes received, the function decides on an Order. The Purchasing Department acts as the mechanism for this function. Monitor Order Progress (A34): This function maintains a record of the progress of the Order at the seller end. It queries the seller for Order Status. It monitors the order status by comparing with the original order. The Purchasing Department acts as the mechanism for this function. Receive Completed Orders (A35): This function is initiated by the receipt of Confirm Shipment of Order. It keeps track of the shipment by requesting Shipment Status from the transport function. It receives the shipment from the transporter and checks it against the Order. After receipt of the Order Shipment, it receives an Order Invoice from the seller and responds with the Payment. The Purchasing Department acts as the mechanism for this function. Manufacture Final Products (A36): On receipt of the Products from the seller, the Final Products are produced. The production of the Final Products is based on the Production Schedule prepared by A32 and follows the Production Policy of the manufacturer. The Production Department acts as the mechanism for this function.

24 C11 C12 C9 C8 C10 Inventory Status Scheduling Policy Demand Production Policy Resource Capacity C3 C4 C5 C1 Status of Order Status of Shipment Work in Process Status Confirm Receipt of Order Develop Forecast Forecast A31 C6 C2 I1 Forecasting Department Scheduling Department Request Product Design Information Request for Bill of Materials Quote Schedule Production A32 Production Schedule Material Requirements Manage Pre-Order Interaction A33 Request for Quote Product Design Information Bill of Materials Order O4 O3 O2 O8 Purchase Department Monitor Order Progress Request Status of Order O5 A34 I2 C7 I3 Order Invoice Confirm Shipment of Order Products Purchase Department Receive Completed Orders A35 Request for Status of Shipment Change Transport Order Confirm Shipment Receipt Payment O1 O1 O6 O9 Purchase Department Manufacture Final Products Final Products O7 Production Department A36 Manufacturer M1 Figure 9: IDEFØ model showing level 1 decomposition of Function A3

25 6.4 Types of Supply Chain Control Strategies Supply chains function under either pull or push type control strategy. A third type i.e. push-pull type has been recently observed to combine the benefits of the pull and push strategies. Push supply chains: Push supply chains base production and distribution decisions on long-term forecasts. The demands are forecast on the basis of the orders received from the downstream members. Inventory in a push supply chain is prone to experience the bullwhip effect (Simchi-Levi and Simchi-Levi, 2004). The bullwhip effect tends to stock up inventory as we go upstream in the supply chain. A push supply chain is schedule driven, and its response to changing conditions is slow. A detailed discussion of the process flow in a push supply chain has been done in Section 6.5 using IDEF3 representation. Pull supply chains: In pull supply chains, the production and distribution decisions are based on the actual customer orders. Pull supply chains work on a nil or very low inventory level because all production takes place on the basis of actual customer orders. An important consideration in a pull supply chain is the lead time between order placement and delivery. It is imperative for a supply chain to respond quickly so that its competitiveness is maintained. A pull supply chain can be driven by the stock keeping levels or through orders placed by downstream members. A detailed discussion of the process flow in a pull supply chain has been done in Section 6.5 using IDEF3 representation. Hybrid Push-pull supply chains: Push-pull supply chains have the advantage of both control strategies. In such supply chains, the upstream members work on a push control while downstream members work on a pull control. In a Push-pull supply chain, the product s development is curbed till the stage where it is still at the product family level of generality. Until this stage the supply chain operates on a push type control and beyond this, depending on the customer orders, the products are customized. 6.5 IDEF3 Representation of Supply Chain Control Strategies Supply chains work under three control strategies: 1) Push 2) Pull and 3) Push-pull. IDEF3 is an effective tool for describing the precedence and causality relationship between different processes in a system. A process, also known as Unit of Behavior, is shown as a rectangular box with three compartments. The process represents different types of behavior such as operations, decisions, function or events that occur in the system. The processes are linked together to form a process path. The sequencing of the processes is described using logical connectors like XOR, AND & OR. Push supply chain: An IDEF3 representation of a push supply chain is shown in Figure 10. The processes involved at the buyer end are illustrated in the figure. The process flow begins with the buyer developing a forecast. Based on the forecast, the buyer schedules its activities. At the end of the scheduling process, the buyer invites quotes for the material requirements calculated during the forecasting process. Once

26 the buyer agrees on the quote, it places an order with the seller. Upon fulfillment of the order by the seller, payment is done to complete the process. Figure 10: IDEF3 model illustrating Push control o Develop Forecast (1.1): The level 1 decomposition of process 1.1 is shown in Figure 11. The process flow starts with the buyer receiving sales data from downstream members. Based on the Sales Data and an Inventory Status Check the buyer Creates a Forecast. The forecast is reviewed and finalized. Figure 11: IDEF3 model illustrating forecast development o Schedule Member Activity (2.1): The level 1 decomposition of process 2.1 is shown in Figure 12. Based on the forecast, the Material Requirements Planning is done and the sub-components and raw material requirements are calculated. Sourcing decisions in terms of a Make or Buy Decision is made. Figure 12: IDEF3 model showing the scheduling of member activity o Pre-Order Interaction (3.1): The level 1 decomposition of process 3.1 is shown in Figure 13. Depending on make or buy, a search is made for suppliers for the raw materials or the sub-components. Once a supplier is found, a Request for Quote is sent to the seller. Based on the quote received, the buyer Requests Quote Adjustments. If the seller Rejects the Quote Adjustments alternative suppliers are searched.

27 Figure 13: IDEF3 model showing the pre-order interaction o Order Placement (4.1): The level 1 decomposition of process 4.1 is shown in Figure 14. Once a quote is accepted the buyer Places an Order and the buyer receives an Order Confirmation from the seller. In case the buyer wants to change the order, it Requests Order Change, the seller confirms the change. If the buyer Queries the Order Status, the seller provides the Order Status. Figure 14: IDEF3 model showing the order placement o Order Delivery (5.1): The level 1 decomposition of process 5.1 is shown in Figure 15. The seller sends an Order Shipment Notification to the buyer. Once the buyer Receives the Order Shipment, it sends an Acknowledgement of Shipment Receipt to the seller. Figure 15: IDEF3 model showing the order delivery

28 o Order Payment (6.1): The level 1 decomposition of process 6.1 is shown in Figure 16. Once the seller receives an Acknowledgement of Shipment Receipt the buyer Receives an Order Invoice. Based on it, the buyer Issues Payment to the seller. Figure 16: IDEF3 model showing the order payment Pull Supply Chain: An IDEF3 representation of a pull supply chain is shown in Figure 17. The processes involved at the buyer end are illustrated in the figure. The process flow begins with the buyer receiving an order from a downstream member. Based on the order and an inventory status check, the buyer schedules its activities. At the end of the scheduling process, the buyer invites quotes for the material requirements calculated during the forecasting process. Once the buyer agrees on the quote, it places an order with the seller. Upon fulfillment of the order by the seller, payment is done to complete the process. Figure 17: IDEF3 model illustrating the Pull control o Schedule Member Activity (2.2): The level 1 decomposition of process 2.2 is shown in Figure 18. Based on the forecast, the Material Requirements Planning is done and the sub-components and raw material requirements are calculated. Sourcing decisions in terms of a Make or Buy Decision is made.