National Institute of Standards and Technology
MET Build 220 Rm-A127 MSID MD 20899-001 USA
Modern manufacturing enterprises must collaborate with a large number of suppliers to design and produce their products. Management of these supply chains is crucial. This paper proposes a system framework for supply chain management, which will form the foundation for the construction of an integration testbed. This testbed will focus on production & operations management within the supply chain. It will contain a simulation-based decision support system, process modeling library, simulation engines, and a WEB-based data-handling system. The library includes material-flow models, information models, business process models, and decision support models. Each model is described using an object-oriented modeling paradigm. This paper describes a system concept, a system architecture, and generic business process models.
Keywords: Business modeling, Manufacturing management, Decision making, Simulation
Modern manufacturing enterprises are required to continually review their strategies for competing in the ever-changing, ever-expanding global economy. They must constantly restructure and simplify their business and fabrication processes and procedures. This restructuring frequently involves fundamental decisions regarding those activities which really do need to take place internally, and which can be better done by, and more importantly, in full collaboration with, business partners. In making these decisions, each enterprise must develop a flexible management system to survive in today's competitive market.
More and more, management is deciding in favor of outsourcing both design and fabrication. In some cases, they do not have the capabilities; in others, it is simply a matter of cost. Regardless of the reason, the management of multiple suppliers is becoming critical to an enterprise's success. There are two important keys to achieving that success: a thorough understanding of the business processes and quality practices at these suppliers, and the synchronization material flow and information flow across the chain.
It is also necessary to implement a distributed operations management system to deal effectively with both capacity and inventory problems among multiple supplier enterprises. A system concept and an implementation methodology must be well defined to take into account practical business operations and production decisions at different supplier sites. The use of such an operations management system can dramatically reduce the cost and increase the performance of the supply chain.
This paper proposes an information system framework to support such multiple supply chain management operations. The proposed system uses business process re-engineering techniques and information modeling technologies. The system will be used to construct an integrated testbed for production & operations management in a supply chain environment. This paper describes a system concept, a system architecture, and a potential implementation methodology. The architecture contains a number of models linked together to form an integrated system. To implement that system, a distributed simulation strategy is proposed.
2. SUPPLY CHAIN MANAGEMENT and BUSINESS PROCESS RE-ENGINEERING
2. SUPPLY CHAIN MANAGEMENT and BUSINESS PROCESS RE-ENGINEERING
According to Davis , a well-managed Supply Chain is one way to implement Quick Response Manufacturing (QRM). QRM is a system concept that is similar to a famous Just-In-Time (JIT) concept . While implementation of JIT is based mainly on improvements in manual operations, QRM is based on well-designed information systems that can support rapid information processing . QRM, if implemented properly, can provide the shortest lead-time for each major business process in supply chain. Those processes are, in macro scale, design, process planning, material preparation, procurement, production, and delivery.
Implementation of QRM requires not only faster execution of these individual processes, but also concurrent execution of all of them. In the supply chain environment, this concurrent execution of business processes should be done across the entire chain. Figure 1shows this for a subset of the processes. If successful, only then can we hope to realize the reduction in total lead-time and cost predicted in .
Success will depend on the ability of the suppliers to be integrated with each other, and with the prime contractor - the top tier in the chain. The emphasis on system integration must span all of the business processes listed above. To date, most supply chain integration research has focused on design, material preparation, procurement and delivery. Design integration is being achieved through the use of emerging product data standards and concurrent engineering tools. Logistics, using Business Process Re-engineering tools, is aimed at the other three. While quantitative data is not widely available, manufacturers expect to achieve both cost and time reductions by using these tools and techniques.
The synchronization of operations involved in
Fig. 1 Manufacturing business processes and concurrent operations
process planning and production across multiple firms is much more difficult than it is within a single firm. The principal reason for this is the information sharing required to perform these operations. Some examples include: design and assembly requirements must be shared with all suppliers so that process plans can be developed for individual components; the Master Production Schedule must be shared with all suppliers so they can complete the fabrication, testing and delivery of all components; suppliers must share information with the prime contractor related to the fabrication of components so that schedules can be monitored and modified if necessary; and, the prime contractor must share final product production and delivery information so that retailers make their distribution schedules.
Timely information sharing among all of the members of the supply chain can reduce waste and efficiency at both member sites and across the entire chain. Three issues must be resolved before this timely information sharing can be accomplished. First, formal models must be developed which specify the content of the shared information. Second, frequency patterns must be established which indicate how often different types of information are exchanged. Third, exchange mechanisms must be developed to insure accurate and timely information transfer. Developing and testing these models and exchange mechanisms will
be difficult because of the very nature of a supply
chain. It is an entity that is comprised of several,
perhaps loosely connected, companies. Each of these companies has it own unique manufacturing capabilities, processes, resources, and information capabilities, processes, resources.
For this reason, the National Institute of Standards and Technology (NIST) is building a virtual supply chain testbed. The initial focus will be production and operations management (POM) within the supply chain. In particular, we will concentrate on material and information flows required to support production and operations management decisions. A wide variety of models will be developed and analyzed in the testbed. They include business process models, formal information models, and simulation models. Business process models cover cross-functional policies and procedures that impact the material and information flows. Formal information models describe the entities that provide complete and detailed definitions for each of these flows. They also identify all of the relationships that exist among these entities.
Fig. 2 System Architecture
The basic building blocks for the virtual supply chain will be a collection of simulation models.
There will be models to simulate the execution of POM business processes their related flows. There will also be two types of models at both the prime and the suppliers: manufacturing process models and shop models. Manufacturing process models must represent the capabilities of the processes at each supplier accurately. They will be used to determine if a particular supplier can meet the quality and cost constraints. Shop models will be used to determine if potential suppliers can meet the schedule constraints.
A number of different commercial products will be used to build these various models. Integrating them together will require a common understanding of the inputs, outputs, and manufacturing objects. This requires a systems architecture with well defined functional modules and interfaces between them.
3. VIRTUAL SUPPLY CHAIN SYSTEM: ARCHITECTURE
As discussed above, we propose a Virtual Supply Chain Management Testbed. It will be a simulation-based testbed that will focus on the material and information flows associated with production and operations management decisions within the chain. The major difficulty is that the flows required to make these decisions and, subsequently, monitor their implementation change according to the suppliers' business situations. Furthermore, since suppliers can be distributed across the globe, communicating information and transporting material can be costly and time consuming. Therefore, the proposed architecture must support communication protocols to allow worldwide information transfer. The main modules in this architecture are (see Fig. 2):
3.1 Supply chain integration reference model
The supply chain integration reference model has four major components: business process models, material flow/logistics models, information models, and decision process models.
3.1.1 Business process models
Business process models are needed to understand how operations are carried out both at individual suppliers and in the supply chain itself. They are basically functional models that describe what activities are performed, and relationships that exist among those activities (see Fig. 3). While there may be differences in how suppliers execute activities, we believe that a common set of operational activities does exist. (This common set of activities forms the basis for a coherent production and operations management plan for the supply chain). Each of these operational activities contains a sequence of primitive activities. A primitive activity consumes both time and information /material resources. Examples include generate, dispose, assemble, branch, merge, split, join, transform, copy, assign, seize resource, and, release resource. Both network flow and activity cycle diagrams are used to represent each business process flow. Each individual process can have its own internal decomposition into sub-processes. The top-level processes are the six given in section 2
3.1.2 Material flow/Logistics model
Material flow models represent physical material flows of parts/products from suppliers to customers. Usually, these models take a hierarchical network form with multiple levels. A typical three-level model might contain factory, line, and cell levels. The factory level captures material-flows among suppliers' factories. The second level model presents the line flows within a factory, which is composed of processes and transporters. The third level models physical movement within each manufacturing cell. Mathematically, the model at each level is a general queuing network model.
Logistics models deal primarily with material flows at the factory level. It is at this level where the transfer of materials is accomplished using some sort of transportation such as trucks, rail, boat, or plane. The logistics model includes order planning, warehouse location planning, transportation planning, and inventory planning, among others. The fundamental modeling approaches are "push", "pull", and "hybrid-push/pull" (see Fig. 4).
Fig. 3 Business Process & Information-flow Model
Fig. 4 Hybrid PUSH/PULL logistics model
The push system is a schedule-driven system. The typical example is MRP (I/II) system. In such push systems, Master Production Schedule (MPS) is generated from demand predictions. Based on the MPS, the required volume of parts is calculated using a part explosion technique typically found in a Bill of Materials package. All input materials are processed at each process and "pushed" to down stream according as its material-flow. This scenario can be extended easily to a supply chain environment in which the prime contractor pushes orders down to the suppliers and they send finished goods back.
Meanwhile, the "pull" system is a WIP-driven system. A typical pull system is a Kanban system. Each station has a collection of input and output buffers. A station will pull inventory from up-stream stations whenever its input buffer becomes too low. A station will receive a request for new production orders when the WIP level in its output buffer is too low. This scenario can also be extended to a supply chain environment. In this case, the prime contractor will pull inventory from suppliers whenever it is needed. Suppliers will re-stock inventory whenever it becomes too low.
We believe that many supply chains have aspects of both push and pull systems. Therefore, we propose a "hybrid push-pull" model to represent manufacturing logistics operations in our virtual supply chain . In this model, some suppliers work on production orders from a scheduler at the prime contractor's factory. Others will send inventory to the prime upon request and will restock that inventory whenever needed. It is a difficult problem to choose between these two for individual suppliers in the chain. But, the choice impacts not only material flow, but also the information flow (and the communications infrastructure needed to support that flow) between the prime contractor and suppliers.
3.1.3 Information model
An integrated supply chain is only possible if there is a common understanding of these information flows. To achieve this common understanding, we will develop a collection of formal information models using OMT  methodologies. These models will describe the entities that provide complete and detailed definitions for each of the flows. They also identify all of the relationships that exist among these entities. Using these models, and an understanding of how and when information is transmitted between business processes, we can determine timing requirements. These requirements help resolve questions regarding storage options. Some of this information can be stored and transmitted as a file. Some information can be stored in a relational or object database with specific pieces transmitted in response to specific queries. Some information must be stored and transmitted using messages in "real-time". Once we have made these determinations, we can specify file formats, database structures, and message protocols.
3.1.4 Decision process model
Decision process models specify various production and operations management decisions that are made throughout the entire chain. Examples include:
It is possible to develop formal mathematical programming problems to represent most of these decisions. Typically, the objective functions in these formulations take into account several performance measures such as, cost estimation, lead-time, highest utilization of resources, throughput performance, and due date. This results in a multi-objective optimization problem with multiple variables. Generally, this will be an NP-complete problem, for which optimal solutions will be hard to find. Nevertheless, there are a number of commercial software packages on the market, which provide solutions to these problems. We plan to incorporate them into the testbed as needed.
3.2 Simulation Kernel
The simulation kernel for the Virtual Supply Chain (VSC) contains three levels, Factory, Line, and Cell (Fig. 5). Each of these levels will contains a number of distributed, integrated simulation models capturing various aspects of the production and operations management activities within the chain.
Fig. 5 VSC Hierarchical Simulation Reference Model
Factory level simulations will capture the highest level interactions between the factories that make up the chain. Production-order management, activity cost estimation, and capacity management are typical performance objectives for these models. Business behavior, business rules, and information transaction flows are the main interfaces between the various factory models. Line simulations capture day-to-day interactions between the prime contractor and its suppliers. The primary purpose of these simulations is to ensure that the daily schedule and quotas are met. Production requests and job/material status messages are the principal interfaces between the models. Cell simulations make up the lowest level. These are usually control logic simulations. The input is the physical transaction control rules of a particular machine or resource, such as NC or robot control programs. The output is, for example, machine performance or part quality.
4. SHARING MANUFACTURING
INFORMATION ACROSS THE CHAIN
One of the keys to the successful implementation of the virtual supply chain testbed is the timely and accurate exchange of information across the software applications in the testbed. There are several barriers that must be overcome. The most serious is that the companies participating in a particular supply chain are independent and frequently compete against one another. They may not want to share information with their competitors, so security control will be a significant issue in such an environment. The second problem is that each company has a different set of software applications and business practices. These differences will make it difficult to implement a set of common databases. The information produced by the software in one company cannot be processed directly by the software in another company.
This will lead to problems in both semantic interoperability and syntactic interoperability. The former means that two applications cannot process each other's data because they do not understand the internal organization of each other's data. The latter is that two applications cannot make use of each other's functionality because they cannot invoke each other's resources. Furthermore, each company's software applications may be complex and require extensive training to be used correctly. The solution to these problems lies in the careful development of business, logistics, and information models. These models will provide the necessary common definitions and semantics that can eliminate those problems.
4.1 Information exchange
Even if applications have a common understanding of the information they share, they must still exchange that information. The technology used to exchange that information must be cost-effective, reliable, and hardware independent. In the testbed, we will use four methods for exchanging large amounts of information:
Smaller amounts of information which have "real-time" exchange requirements will be done using message protocols which will be developed on a case by case basis.
4.2 Supply Chain Data Management
Conceptually, information management within the testbed will be carried out using three data driver sub-systems (see Fig. 2): a Production Data Driver, a Demand Data Driver, and a WEB System Driver. The Production Data Driver receives factory operational data from suppliers and translates it to meet the format specifications of the target software applications. The Demand Data Driver receives demands data from retailers and reforms it to simulation parameters. The WEB System Driver provides the data access methods and utilities needed by the other drivers. Each of these subsystems will be implemented using various combinations of the methods described above.
A large percentage of the cost of complex commercial products comes from the "external" purchases of components that go into those products. These purchases are made from a large number of suppliers. Some suppliers may be multi-million dollar companies in other countries. Others may be small shops across town. This implies that supply chains play a vital role in the production of complex products made in the world today. We believe that one key to the successful management of these supply chains is integration.
In this paper, we focused on an aspect of supply chain integration that has been largely ignored to date - production and operations management (POM). POM includes all functions related to the planning, scheduling and actual production of parts in the chain. We have described plans to build a virtual, distributed, supply chain integration testbed. That testbed will contain a wide range of operations management application software and simulation tools. It will provide 1) impetus for developing the models and interface specifications needed to integrate software at these nodes, 2) a place to house software which will be developed to implement these models & specifications, 3) an environment for testing and demonstrating the adherence to those specifications, and, finally, 4) a virtual supply chain for testing various operations management strategies across a wide range of commercial products.
In conclusion, we believe that a key issue in the success of supply chains is the synchronization of operations among multiple suppliers by using information technologies. The proposed framework will lead to integrated operations management, and customer satisfaction.
 T. Davis, Effective Supply Chain Management, Sloan Management Review, vol. 34, No. 4, Summer, 1993
 Y. Monden, Toyota Production System, 1985
 MITI, State-of-the-art of distribution information system, (in Japanese) 1994
 S. Umeda, "Manufacturing-oriented simulation for production management", Int. J. of. Tech. Mgmt. vol. 7, No.4/5, 278-289,1992
 S. Umeda, An object-oriented system model for manufacturing enterprise information system, 395-400, Proc. of APMS, IFIP WG5.7, 1996
 G. Booch, Object-Oriented Analysis and Design 2nd Edition, San Jose, Benjamin /Cummings Pub. Inc., 1994
 T. Berners-Lee, R. Cailliau, A. Luotonen, H. Frystyk Nielsen, and A. Secret, The World-Wide Web. Communications. ACM 37,8 , 1994
 ISO/IS 10303-21, "Industrial automation systems and integration - Product Data Representation and Exchange - Part 21: Clear text encoding of exchange structure," ISO, 1 rue de Varambe, Case Postale 56, CH-1211 Geneva, Switzerland, 1994.
 OMG, The common object request broker: Architecture and Specification ver. 2.0, 1995
S.Banerjee, EDI: characteristics of users and no-users', Info. & Management., 26, 65-74, 1994