A Web-based system for proactive management of supply exceptions

Journal of Manufacturing Systems 29 (2010) 91–101

Contents lists available at ScienceDirect

Journal of Manufacturing Systems journal homepage: www.elsevier.com/locate/jmansys

Technical paper

A Web-based system for proactive management of supply exceptions Henry Huaqing Xu ∗ UQ Business School, The University of Queensland, St Lucia, Brisbane, Queensland, 4072, Australia

article

info

Article history: Received 24 March 2010 Received in revised form 29 September 2010 Accepted 7 November 2010 Available online 27 November 2010

abstract To avoid or mitigate the ripple effect of a supply exception (defined here as a partial and/or late delivery) in the supply chain, it is imperative to identify the exceptional event early and handle it effectively and efficiently between the affected parties. This paper proposes a Web-based system which enables the early identification of supply exceptions and provides structured business processes for handling them. Particularly, through the dynamic mapping of a specific customer order with finished goods inventory and the progress of internal work orders against a pre-defined milestone model for each product, the status of the customer’s order is determined. In case of an exception (i.e. a customer order cannot be fulfilled as promised in the order schedule), a standard process is triggered to handle it collaboratively by business partners through fast, effective negotiations. To achieve these objectives, a top-down system design approach was employed, which covers conceptualization of the key co-ordination processes, methodology development, design of system architecture and the integrative processes and subsequent system implementation. To demonstrate the effectiveness of the Web-based system, an example is used to compare the current process with the one proposed. The system was evaluated in the context of the IST project Co-OPERATE. Finally, the presented work is concluded and future research directions are indicated. © 2010 The Society of Manufacturing Engineers. Published by Elsevier Ltd. All rights reserved.

1. Introduction With the increase in complexity and uncertainty in global supply networks, effective supply chain management (SCM) has become more challenging [1]. Under these circumstances, a key to maintaining consistent on-time order fulfillment is how to handle supply exceptions, or supply risks as the managerial counterpart [2] due to an unexpected event (e.g. a strike) on the supplier’s side [3]. Here, a supply exception refers to a partial and/or delayed delivery to the customer as a consequence of an unexpected event (e.g. a material shortage, a machine breakdown or a quality problem) which has occurred on the supplier’s side. A significant amount of research has been conducted in investigating exception handling in manufacturing systems both at the system and cell levels (e.g. [4–8]). The research scope in this area, however, does not go beyond the boundary of an individual company. Meanwhile, there have been an increasing number of publications on supply chain disruption management in the last two decades (e.g. [9–20]). Generally, this stream of research has provided useful information on how mitigation strategies can be used to manage supply chain risks. For example, Sheffi and Rice [20] argue that flexibility (i.e. the ability to sense and respond to threats quickly) may be a competitive advantage.

∗

Tel.: +61 0 7 3346 8135; fax: +61 0 7 3365 6988. E-mail address: [email protected].

In terms of commercial solutions, existing software systems, e.g. enterprise resources planning (ERP), advanced planning and scheduling (APS), SCM and business-to-business systems such as electronic data interchange (EDI), are designed to improve efficiency, rather than reliability or robustness of the supply chain [21]. Some vendors (e.g. SAP, Oracle, i2) offer partial solutions to this problem under the title of supply chain event management (SCEM), which monitors events (e.g. order status) in supply chains, alerts the responsible person of an exceptional event and lets him or her resolve the issue [21,22]. On the academic side, seminal research work on SCEM has been limited and mainly focused on conceptualization in SCEM (e.g. [23]) or modeling of events in the supply chain (e.g. [24]). This article addresses some of the gaps in current research focusing on conceptualization and existing SCEM solutions, which do not provide an integrative process and decision support for managing supply exceptions [22]. This paper proposes a Webbased system which not only enables early identification of supply exceptions, but also provides standard business processes to handle them effectively and efficiently. Specifically, two fundamental issues are addressed in relation to proactive SCM. (1) How to determine if a problem on the supplier’s side (e.g. machine breakdown) is disruptive or not by using an early warning system through intra- and inter-firm information sharing [3,25]. (2) How to mitigate the negative impact of a supply exception by decreasing the time for responding to it through enhanced supplychain visibility [1,25].

0278-6125/$ – see front matter © 2010 The Society of Manufacturing Engineers. Published by Elsevier Ltd. All rights reserved. doi:10.1016/j.jmsy.2010.11.003

92

H.H. Xu / Journal of Manufacturing Systems 29 (2010) 91–101

Nomenclature For ease of reference, the nomenclature used in this paper is presented. APO APS ASP EDI EHC EIC ERP eXH IDEF0 IIS JIT PAC RDBMS SCEM SCHEME SCM SME VOP WIP

Advanced planner and optimizer Advanced planning and scheduling Active server page Electronic data interchange Exception handling capability Exception identification capability Enterprise resources planning Exception handling Integration definition for function modeling Internet information server Just-in-time Production adaptation capability Relational data base management system Supply chain event management Supply chain execution management by exceptions Supply chain management Small and medium-sized enterprise Visibility of order progress Work-in-process

This paper contributes to the development of an integrative solution and a set of innovative and practical approaches for proactive management of supply exceptions. Based on these, a Web-based system is implemented under the name of supply chain execution management by exceptions (SCHEME). The work starts from identification of business requirements, which underlie the key co-ordination processes. Then, a methodology for proactive management of supply exceptions is presented. This is followed by design and implementation of a pilot system, an application example and system evaluation. Finally, conclusions are drawn and future work is indicated. 2. Key co-ordination processes This paper represents a continuity of the author’s early work in handling supply chain exceptions in the short term, which includes rush orders on the demand side and delivery problems on the supply side [26]. In comparison with [26] which was mainly focused on the conceptualization of the seven co-ordination processes and design of the rush order handling process, this paper concentrates on the whole process of early identification and effective handling of supply exceptions, and covers all the major aspects of system development and implementation as indicated above. Prior to the development of a SCM system, it is essential to identify business requirements, which must be met by the system under consideration. The analysis of business requirements was based on an extensive literature review and the results of over 30 face-to-face interviews with managers and operational staff of six companies in the automotive and semiconductor industries covering first, second and third-tier suppliers and small and medium-sized enterprises (SMEs), which were conducted for the Co-OPERATE project [27]. Generally, major operational issues in a complex supply network (e.g. in the automotive industry) include distorted demand or the bullwhip effect, missed deliveries and poor responsiveness [27], which negatively impact the overall objectives of the supply network in terms of cost reduction and service improvement. Therefore, there are three major business requirements for a SCM system: (1) reducing the bullwhip effect,

(2) enhancing supply chain reliability, and (3) improving supply chain responsiveness [21,27]. The above business requirements were first translated into seven interrelated business processes, which have the potential to improve network co-operation. The contents and positioning of these co-ordination processes are described in my article Ref. [26], and are mainly focused on the co-ordination of operational planning and control activities, especially at the interfaces between the customer and the supplier across the entire supply chain. Therefore, the proposed co-ordination processes have a distinctive business focus in comparison with the eight business processes identified by Croxton et al. [28], which cover both internal and external supply chain processes at both the strategic and operational levels. Particularly, this work is related to two co-ordination processes: visibility of order progress (VOP) and exception handling (eXH), which can be briefly described as follows:

• Visibility of order progress: closes information flow loops by feeding back order status information and providing early warning of delivery problems to the downstream companies. • Exception handling: mainly focuses on dealing with short-term demand changes and short to medium-term delivery problems through fast, effective negotiation processes. Generally, VOP provides the customer with up-to-date order status information through order tracking and early warnings of anticipated delivery problems, i.e. partial and/or delayed deliveries while eXH complements VOP and reconciles the customer’s demand and the supplier’s delivery capability by considering the constraints on both sides. The overall methodology on how these two co-ordination processes work together is presented in the following section. 3. Methodology development During the last three decades, much of the academic research on supply chain control has been concentrated on how to respond to internal and/or external uncertainties through effective use of buffers (i.e. buffer stock, time buffer and/or reserved capacity [29]) and manufacturing flexibility at the system level [30–32]. Though this stream of research has been focused on reactive control of internal supply chains, it has provided some useful insight on how a dynamic balance between the negative effect of uncertainties and measures to absorb them can be achieved and maintained. The principles of using both buffers and manufacturing flexibility to cope with demand and supply uncertainties have been extensively discussed in the literature (e.g. [30,31]). Here, manufacturing flexibility is meant at the manufacturing system level, which can be classified into four major types: product, mix, volume and delivery [33]. However, with a wide application of justin-time (JIT) practices, buffers in the form of inventories and time slack in the schedule have been reduced to the minimum level, which makes the supply chain more vulnerable to disruptions [34]. Therefore, when a work order is delayed, the first measure to absorb its negative effect is the flexibility in the manufacturing system [30]. If the total negative impact of the delay increases and goes beyond what the flexibility can cope with, companies tend to use buffers to maintain a balance [31]. Here, the totality of manufacturing flexibility and buffers is referred to as production adaptation capability (PAC) of a company [29]. Fig. 1 illustrates how a dynamic balance between the impact of exceptions and PAC can be maintained. The balance between the impact of exceptions and PAC exhibits a dynamic nature as it is influenced by two major factors: (1) when an exception is identified, and (2) how effectively and efficiently it is handled by the affected parities including internal functions and external business partners. These two factors are referred to

H.H. Xu / Journal of Manufacturing Systems 29 (2010) 91–101

93

Fig. 1. Dynamic interactions between EIC, EHC and PAC. Source: (adapted from [26]).

as exception identification capability (EIC) and exception handling capability (EHC) respectively as shown in Fig. 1. As indicated by the left control valve, both EIC and EHC have the ability to reduce the overall impact of an exception. On the right side, expeditors influence the decisions on buffers in terms of their sizes and allocations. Actually, EIC and EHC have a mutually supportive relationship. EIC helps to reduce the impact of an exception and thus the demand for EHC. Meanwhile, EHC assists in further identification of the priority (or the emergency level) of the exception after its impact on the downstream supply chain has been assessed by the customer during the exception handling process. Note that though both EIC and EHC have the potential to mitigate the negative effect of exceptions, EIC has a higher priority because it is logically the first step towards proactive management of supply exceptions. Particularly, if an exception is identified early enough, a delay in the progress of a work order may be accommodated by the flexibility of the manufacturing system. These principles for exception handling accord with what has been suggested by Christopher and Lee for breaking the risk spiral in the supply chain in terms of an alert system for out of control conditions and tools for making corrective actions [35]. Proactive supply chain control requires that a supply exception must be contained at the lowest level, i.e. within the supplier company. If this is impossible, it is important to minimize the negative ripple effect of the exception on the supply network through collaborative exception handling between the affected business parties [36]. To achieve this, there is a need to identify exceptions as early as possible, which is a major task of the VOP process. Meanwhile, it is also of vital importance to effectively and efficiently resolve the problems, which is the focus of the eXH process.

Fig. 2. The top-down system design approach.

as outlined in Section 2. In this section, three basic system architectures are discussed, and the fully decentralized system architecture is chosen based on the evaluation of the three alternatives. The top-level design defines the overall scope and objectives of the system, its relationship with other systems (e.g. ERP) and how it works. These are detailed by the high-level design of the overall co-ordination process, which includes vision, objectives, performance indicators and process outline. Finally, the high-level design is further detailed through functional modeling and scenario analysis, and the designed system is subsequently implemented and evaluated. 4.2. System architecture

4. The SCHEME system 4.1. System design approach Information system development usually employs a systems approach, which involves four major steps: (1) identify system requirements, (2) select the solution that best meets the requirements, (3) design the selected system solution, and (4) implement and evaluate the designed system [37]. In alignment with this, a top-down approach was adopted to design the SCHEME system as illustrated in Fig. 2. At the top level, the co-ordination processes are conceptualized based on analysis of the business requirements

The first logical step in developing the pilot system is to configure how co-ordination can be technically organized in a supply network, which is the design of system architecture. Currently, there are three types of system architectures for network co-ordination in commercial software packages and research projects: (1) a centralized co-ordination system with local data access (e.g. SAP’s R/3), (2) a hybrid co-ordination system with some distributed local functionality and a central co-ordination module (e.g. SAP’s advanced planner and optimizer (APO), European project X-CITTIC [38]), and (3) a fully decentralized co-ordination system without a central co-ordination module

94

H.H. Xu / Journal of Manufacturing Systems 29 (2010) 91–101

Fig. 3. The decentralized model for network co-ordination.

• Reduce the frequency of material shortages and their associated costs by resolving delivery problems as early as possible [26]. Performance indicators

• Percentage of early warnings sent to customers on delivery problems.

• Average length of advance time of early warnings on delivery problems.

• Percentage of delivery problems which are successfully resolved [26]. Fig. 4. Basic diagram of the overall process for SCHEME.

(e.g. i2’s Tradematrix Open Commerce Network, European project PRODNET II [39]. The decentralized system architecture has two important privileges over the other two for network co-ordination: (1) to the fullest extent possible, it maintains local decision autonomy for individual companies in the supply network, as there is no central optimization for the total network [40,41], and (2) it supports heterogeneity of their existing local planning systems (e.g. ERP systems). Thus, it was considered to be most suitable for manufacturing co-ordination in complex supply networks such as in the automotive industry. In this fully decentralized model, each company in the supply network has its own local planning systems (e.g. ERP and/or APS systems), which perform local planning for the company while connecting via a co-ordination unit module to other business partners in the network. Fig. 3 illustrates the proposed decentralized system architecture for network coordination. 4.3. High-level process design Vision

• To provide meaningful, formalized information on order status, while alerting customers in case of supply exceptions.

• To provide both customer and supplier expeditors an efficient, robust tool when dealing with delivery problems (Fig. 4) [26]. Objectives

• Improve customer service (i.e. fulfilled deliveries) by monitoring and providing order status in near real time across the network. • Reduce manual work by providing a formalized way of reporting order status.

• Percentage of fulfilled deliveries. Process outline Fig. 5 presents the schematic process view of SCHEME, which integrates the exception identification process (i.e. VOP) and the exception handling process (i.e. eXH). To detect exceptions in the order fulfillment process, the first logical step is to measure the progress of a customer’s order. Essential to this task is to track work orders and monitor inventory levels so that deviations in the production process can be detected quickly [42]. The progress of work orders is measured against the predefined milestones, which are determined according to the local production process for a specific product and the criticality of the product. However, there is no direct link between customers’ orders and finished goods inventories and work orders in local planning systems (e.g. ERP systems). In practice, it is a dynamic mapping process between them. As indicated on the delivery schedule in Fig. 5, the required quantity (1000 pieces) of the first order (with an ID of DS_01) is dynamically mapped against the available amount (350 pieces) of on-hand finished goods inventory and the lot size (700 pieces) of a work order. In this case, if the work order is delayed and cannot meet the due date of the order, the customer’s order status is set as ‘‘RED’’ as indicated in the figure. This dynamic mapping process can be automated based on certain criteria (e.g. due date, importance of customer) and business rules using the criteria (e.g. allocation of the available quantity of a product to customers according to their importance to the company). For example, in a wafer manufacturing company that produces blank silicon wafers according to exacting specifications of their customers, the macro manufacturing steps for a product are: (1) transfeed, (2) sawing, (3) lapping, (4) polishing, (5) cleaning, and (6) finished goods [27]. These macro steps can be used as the predefined milestones. The quantities are sorted from finished

H.H. Xu / Journal of Manufacturing Systems 29 (2010) 91–101

Milestone

M.S.: Milestone

Supplier

95

Customer

Fig. 5. Schematic process view of the SCHEME system.

goods to raw material arrivals, and are dynamically matched to customer orders according to their due dates. For those customer orders with the same due date, quantities are matched to these orders according to the importance of these customers to the company. To provide customers with simplified, meaningful information on order progress, the traffic light approach is employed to signal the general status of order progress. ’Green’ means that the customer’s order is progressing normally. ‘Yellow’ indicates that the order is slightly delayed or the quantity falls short, but can be recovered at the later stages of production or accommodated by buffer stock, so only the supplier needs to take action. ‘Red’ signals that the order is severely delayed, and can neither be recovered at the later stages of production nor accommodated by buffer stock, so the customer’s order cannot be fulfilled as scheduled. An order with a ‘red’ status needs to be assessed by the supplier’s expeditor based on information of current inventory and production status. The current delivery schedule for the customer may need to be revised as a result of the assessment. The review process is necessary before an external exception alert is generated and sent to the customer. The information regarding the exception must be certain and meaningful to avoid confusion. After the supplier’s external exception alert is received by the customer, it is reviewed by its expeditor to determine if it is necessary to initiate an exception handling process. If the revised delivery schedule does not meet the customer’s production schedule, the customer expeditor may request a minimum delivery from the supplier, which triggers the collaborative exception handling process. In this case, the supplier expeditor may then need to adjust the delivery solution to try to satisfy the minimum delivery request. In the event that there is insufficient outbound stock, the shop floor may be requested by the expeditor for the possibility of delivering a certain amount of finished goods by a specific date. Based on the feedback from the shop floor and the on-hand inventory, the supplier expeditor can then respond to the customer with a readjusted delivery solution. Clearly, early identification of an external exception is a key to taking proactive actions. However, such an advantage can be

reduced or offset by the delay or ineffectiveness in the exception handling process. Therefore, it is imperative to establish a fast, effective communication channel by which both the customer and the supplier can collaborate to find mutually acceptable solutions. This necessitates designing standard co-ordination processes for early identification and effective handling of exceptions. 4.4. Detailed process design The two interrelated co-ordination processes for the SCHEME system, i.e. VOP and eXH were modeled with integration definition for function modeling (IDEF0). In alignment with the top-down design approach as shown in Fig. 2, the IDEF0 modeling technique uses a hierarchical approach for functional decomposition [43,44]. While function modeling provides a detailed process view of the system through functional decomposition, scenario analysis tries to describe what the system should achieve from the user’s point of view, and thus bridges the gap between business process design and software development. Generally, scenario analysis involves mapping the current business processes and analyzing them to identify jobs or process steps that can be eliminated or combined with other work for improved efficiency [45]. Such business process re-engineering was carried out with active involvement and extensive feedback from the major industrial partners in the Co-OPERATE project. The result of scenario analysis is sequence diagrams that show interactions between systems (e.g. ERP) and company users (e.g. expeditors) in a time sequence. Fig. 6 shows the sequence diagram of the ‘late delivery handling process’, which will be illustrated through an example in Section 6. As indicated in Fig. 6, the late delivery handling process involves eight major steps which can be outlined as follows: 1. An internal exception alert is generated from the VOP process when a customer’s order is delayed and cannot be recovered at the later stages of production. 2. Supplier expeditor gets outbound stock data from the supplier’s ERP system. If the stock is insufficient to cover the quantity required, an external exception alert is sent to the customer.

96

H.H. Xu / Journal of Manufacturing Systems 29 (2010) 91–101

Fig. 6. Sequential diagram of the late delivery handling process.

3. Customer expeditor gets inbound stock data and time slack in the production schedule from the customer’s ERP system. If they can accommodate the delay in delivery, the customer accepts the revised delivery solution as proposed by the supplier. 4. Otherwise, a request for a minimum delivery is generated and sent to the supplier. 5. Supplier expeditor allocates outbound stock to the order and sends a request to the production planner if the assigned stock is insufficient to cover the minimum amount requested by the customer. 6. By aggregating the assigned stock and feedback from the production planner, supplier expeditor proposes a readjusted delivery solution and sends it to the customer. 7. Customer expeditor comments on the readjusted delivery solution. 8. Supplier expeditor makes notes to the production planner as per the comment. 4.5. Comparison of SCHEME with other solutions In comparison with currently available commercial solutions, the SCHEME system possesses some distinctive features that differentiate it from other SCM solutions. First, the system employs a fully decentralized approach to support the co-ordination processes, which is different from APS or SCM applications (e.g.

SAP’s APO and i2’s SCM solutions) that are largely centralized systems. This decentralized system architecture corresponds directly to the peer-to-peer nature of the supply network, maintains local decision autonomy and complements existing local planning systems. Second, whilst on-line order tracking systems have been commonly used in major forwarders (e.g. FedEx) and logistics service providers [46,47], the described process emphasizes a broader view of a manufacturer’s delivery capability, covering the whole manufacturing process as well as suppliers’ delivery capabilities. Meanwhile, by using the traffic light approach as described in Section 4.3, simplified, meaningful information is created to signal the current status of a customer order. Finally, compared with the currently available SCEM applications (e.g. SAP Event Management (SAP EM) [48]), which are mainly focused on monitoring events and sending alerts to the responsible people [21], the SCHEME system covers the whole process from monitoring of order progress, to identification and handling of supply exceptions. Specifically, the system provides additional functionalities in comparison to the existing SCEM applications: (1) it aggregates both the production and the supply status to generate dependable information about a customer’s order status; and (2) when an exception arises, a collaborative exception handling process can be initiated by the customer to find a mutually acceptable solution to the problem.

H.H. Xu / Journal of Manufacturing Systems 29 (2010) 91–101

97

Fig. 7. Technical architecture for the pilot system.

5. System implementation 5.1. Implementation approach

2.

address. For each company, it also includes some key information about each user, e.g. user name, password. Product data: contains key attribute information for both supplied and purchased products in a company, e.g. part ID description, price. Order data: provides some essential information on each order, e.g. order ID, order type, due date and quantity for a certain period. Stock data: supplies some aggregate information on both inbound and outbound stock in a company, e.g. on-hand stock, allocated stock, control limits. Manufacturing data: is mainly about information on the shop floor. Key information includes production order ID, current milestone, quantity produced, and due date.

The results of the detailed process design are the direct inputs for implementation of the SCHEME system. The implementation was carried out in two stages in the form of two prototypes: concept and final. The concept prototype helped to demonstrate the concepts and basic process functions and was implemented by using a rapid Web application development platform—EQOS. This platform facilitated quick and easy development and testing of the concept prototype, however its limited flexibility in accessing databases made it unsuitable for implementing the full system functionality. Consequently, after the concept prototype was implemented, the most popular tools for Web application development were reevaluated. Microsoft’s active server pages (ASP), was chosen for implementing the final prototype of the SCHEME system, which was called the pilot system afterwards. To some extent, the ASP approach combines the advantage of the rapid Web application development platform (i.e. short system implementation cycle) and that of the object-oriented approach (i.e. flexible system infrastructure). The technical structure of the pilot system is outlined as follows.

The above data can be stored in a large enterprise database (e.g. an ERP database) or more often in multiple databases for different enterprise applications (e.g. warehouse management systems, manufacturing execution systems). At SMEs, these data may be contained in files (e.g. spread sheets and text files) or in other forms of databases. When network co-ordination activities take place, some derived data will be generated such as delivery schedules, customer order status, and minimum delivery request from customers.

5.2. Technical structure

5.4. System functionality

A three-tier client/server architecture was adopted to run the pilot system as illustrated in Fig. 7. The Web browser and the Web server comprise the first tier (the presentation layer). For the pilot implementation, Microsoft’s Internet Explorer was the preferred Web browser. Microsoft’s Internet Information Server (IIS) was chosen to implement the Web server. The application server consists of the second tier (the application layer) and represents the business logic of the application. The main responsibilities of the application server include the access to the relational data base management system (RDBMS) and the execution of serverside business logic. Microsoft’s IIS and ASP engine implement this functionality and the integration between the Web server and the application server. Microsoft’s SQL server 7.0 was the chosen product for the provision of RDBMS services. Data exchanges between the RDBMS and ERP systems or local legacy systems can be achieved via XML files.

The main functionality of the pilot system is detailed on the basis of workflow models. Generally, a workflow is the movement of tasks, information, and paperwork from one recipient to another for actions according to a set of procedures [49]. Automation of workflows can increase organizational productivity, and is thus a hot topic in information system development [45]. The workflow models for the pilot system consist of multiple process steps on both the supply and the demand sides. For example, a workflow model for the late delivery handling process is captured in Fig. 6 in Section 4.4.

5.3. Database structure To manage the supply chain by exceptions, only relevant data essential for manufacturing co-ordination are extracted from local legacy systems and transferred into the pilot system database. These data can be classified into five different sources: 1. Administration data: includes some basic information about each company in the network, e.g. company ID, name and

3.

4.

5.

6. An example This section presents an example used by the industrial partners in the Co-OPERATE project for the testing and evaluation of the pilot system. It illustrates how the supplier and the customer collaboratively handle a late delivery. The purpose of this example is to reveal how the pilot system can improve the supplier’s delivery performance in comparison with the current process. 6.1. Background information The customer company (called T1 hereafter) in this case is a tier 1 supplier to major car manufacturers, producing complex assemblies (e.g. electronic engine management systems, navigation

98

H.H. Xu / Journal of Manufacturing Systems 29 (2010) 91–101

Fig. 8. Supplier expeditor review on an external exception alert.

systems). The supplier company (called T2 hereafter) provides T1 with packaged integrated circuits (ICs). Overall, T2’s manufacturing processes are typical of high complexity (hundreds of manufacturing steps with re-entrant process flows), long cycle times (6–12 weeks) and unexpected yield loss, leading to high uncertainty in order fulfillment. With OEMs pursuing JIT practices, T1 must satisfy their needs for more frequent, on-time delivery of products. Thus, it is imperative for T1 to synchronize their production processes with those of their suppliers. Due to short product life cycle, high inventory costs and capacity constraints, T2 usually holds only a limited amount of buffer stock for some critical products. In fact, the protection of buffer stock is very limited because T2’s delivery capability may be severely impaired by a disruptive event in the manufacturing process. The following example is a typical scenario that requires an expeditor’s attention in T1’s logistics department. The following occurred on a typical work day: on a given day, say, 12/9/2002, an expeditor in T1 received a message via EDI from T2 that a scheduled delivery for a certain order (order ID: 750515, Part ID: DEV1, due date: 12/9, quantity: 12 000) would not arrive as planned because a critical machine for the final test of packaged ICs broke down on 7/9, and the expected delivery would be delayed to 17/9. 6.2. The current process Currently, T2 cannot provide T1 with a regular update on the status of their orders or an early warning in case of delivery problems. Usually, on the scheduled delivery date a message on a missed delivery is transmitted via EDI to T1. In the above late delivery scenario, upon receiving the message from T2 that the scheduled delivery was postponed to 17/9, an expeditor in T1 manually checked their ERP system for the available quantity of inbound stock and the current production schedule to see if the delay would cause a material shortage. In this case, as the shop floor was scheduled to launch a manufacturing lot of 6000 pieces on 12/9, and there was currently insufficient inbound stock of part ‘DEV1’, the unexpected delay in delivery caused a severe shortage of material, which would shut down the whole production line.

Clearly, the delivery failure incurred a costly consequence at T1 due to the fact that T2 had not given T1 an early warning in respect of the delivery problem. When it came to the scheduled delivery date, it was already too late for T1 to do anything to avoid the shutdown of its production line. To address the problem proactively, the SCHEME system would be an ideal tool that could have been used to provide reasonably early (e.g. one week before the due date) warnings on foreseeable delivery problems and effective exception handling processes with decision support and standard user interfaces. 6.3. The proposed process In the proposed process, the progress of a product being manufactured is continuously monitored by T2’s work-in-process (WIP) tracking system. Customer orders are typically matched against WIP in the manufacturing process. According to the quantities of production lots on current milestones and standard lead-times for the milestones, the status of a customer order is calculated and updated on a time-driven (e.g. daily) or eventdriven (e.g. hitting a milestone) basis. By virtue of the WIP tracking system, the late delivery problem as described previously could have been detected and reported early and resolved quickly. Specifically, when the machine broke down on 7/9, management decided to have an overhaul of the facility, which entailed a 10-day downtime. The pilot system first assesses the impact of this event on the next delivery to T1 by checking available outbound stock for DEV1, which would have been found to be insufficient to cover the planned delivery quantity. Thus, the status of the order is set to ‘red’, which is reviewed by an expeditor at T2 to revise the original delivery schedule. Then, an exception alert is sent to T1 as illustrated in Fig. 8. T2’s exception alert is transmitted to T1 and reviewed by a responsible expeditor, who is informed of the reason for the missed delivery, the action taken and the revised delivery solution proposed by T2. In this case, as the total quantity of inbound stock for DEV1 (available plus expected) is insufficient to meet the production schedule, a minimum delivery is required so that production will not be disrupted. The system then

H.H. Xu / Journal of Manufacturing Systems 29 (2010) 91–101

99

Fig. 9. Customer expeditor request on minimum delivery.

automatically calculates the latest delivery date and the minimum delivery quantity as the default value subject to the expeditor’s modification according to his/her own experience and judgement as illustrated in Fig. 9. The minimum delivery request is reviewed by the expeditor in T2, who assigns a certain amount of stock to the request. As the assigned stock is insufficient to cover the requested quantity, the system automatically calculates the required due date and quantity for the shop floor as default value subject to the expeditor’s modification. Upon receiving a response from the shop floor, the expeditor proposes a readjusted delivery solution trying to satisfy T1’s minimum delivery request. In this case, as the request is met, a short message is sent back to T2 as a reminder on the remaining amount of the original delivery quantity. 7. System evaluation 7.1. Evaluation method A progressive, multi-phase evaluation strategy was used for the evaluation of the pilot system. Before the actual implementation process, the proposed co-ordination processes had been validated from a conceptual perspective through multiple communications with the industrial partners in the Co-OPERATE project. They were also verified by the evaluation of the concept prototype. As it was not feasible for the user companies to turn over their critical business processes to the developed system due to the issue of integration with their local systems, the benefit from using the system could not be quantified. To approximate the real business situation, the pilot system was run independently on a server from which company users accessed the system via Web browsers respectively. Meanwhile, the evaluation of the pilot system was based on real, historical data, such that the proposed processes could be analyzed in comparison with the existing ones. Though the cases used for the system evaluation were mainly based on typical, rather than all possible business scenarios, it clearly demonstrated the potential benefits that could be gained through implementation of the pilot system.

7.2. Evaluation of the pilot system The testing and evaluation of the pilot system involved experts from industrial partners who were highly experienced with existing methods and procedures. Company users were trained with user manuals and scenario scripts. After the user trial and verification phase, project members participated in an evaluation workshop to make sample runs of real-world business scenarios and to judge the system’s performance under these conditions. The result of the system testing and evaluation was captured through detailed questionnaires by comparing the current process with the proposed process according to a number of criteria, which were summarized in Table 1. The evaluation results indicated that the pilot system would provide near-real-time visibility of the customer’s order status, help to significantly improve supply chain delivery performance through early identification and collaborative handling of delivery problems, reduce costs related to inventories, stock-outs, transportation, and expedite deliveries. Specifically, customers can view online the up-to-date information on an order’s status and be alerted to exceptions in a controlled manner avoiding confusion and information overload. In the case of exceptions, both the supplier and the affected customer can collaboratively handle them through structured exception handling processes and standard user interfaces, which pool the necessary information together to assist fast and effective decision making. For example, if the planned delivery schedule cannot be met, opportunities exist to supply just the critical quantity required, which reduce the chances of production line shutdowns. From a technical perspective the pilot system has the following features: 1. The pilot system could be scaled to cater for the growth of the supply network, or easily re-configured to reflect changes in the network structure due to its open and flexible system architecture. In particular, the decentralized system architecture allows new members to join or existing ones to withdraw from the supply network on an as-needed basis.

100

H.H. Xu / Journal of Manufacturing Systems 29 (2010) 91–101

Table 1 Comparison of the current process with the proposed process. Criteria

The current process

The proposed process

Supply visibility

Almost no supply visibility.

Early warnings to delivery problems Ability to avoid delivery problems Ability to solve delivery problems

Almost no early warnings to customers on existing or potential delivery problems. Poor due to lack of visibility of order progress and inefficiency in communication. Limited due to: predominantly reactive to delivery problems; telephone-based communication; too much manual work.

Cost reduction

Limited due to poor supply visibility and lack of coordination, incurring costs for extra stock, expediting and expensive transportation. Poor; often large companies dominant to their own benefits.

Near-real-time visibility through Web-based communication on order status. Readily available through continuous monitoring of order progress and timely exception alerts to delivery problems. Significantly improved through fast communication of customer order status and timely exception alerts. Significantly improved due to: mainly proactive to delivery problems; Web-based communication with standard business processes and user interfaces. Highly potential due to improved supply visibility and enhanced coordination, reducing costs for extra buffer stock, expediting and expensive transportation. Significantly improved through Web-enabled supply visibility and collaborative exception handling.

Network collaboration

2. The integrated database of the pilot system ensures data consistency and minimizes data redundancies, making it a very stable and reliable system. Specifically, when changes of company information are made in the database, it is not necessary to reconcile it with user, order and product records because these records are updated synchronously. Normalisation helps to remove redundant data in the relational database [50]. 3. The pilot system features user-friendly interfaces and secure access by virtue of data ownership and user authorization at different levels (e.g. system administrators, expeditors). For example, while the system administrator can access the administration data of all the network members, the customer expeditor can only access their own company’s information such as stock data and production schedules. 4. Finally, though it may be argued that the local connection to the Internet influences the speed in navigating the system, by minimizing client–server transactions the speed of the pilot system was enhanced and was satisfactory from the users’ perspective. For example, in Fig. 8, assigning outbound stock, proposing a new delivery solution, or checking delivery schedules is executed on the client side with no client–server transactions. 7.3. Limitations This presented work has some limitations. First, it may be necessary to customize the functionalities of the co-ordination processes to meet the specific business requirements of individual network members. Second, in comparison with the Java-based system development method, the ASP approach has limitations in term of system portability. Therefore, it is suggested that the Java-based, object-oriented approach be employed if the pilot system is commercialised. Web services may be a promising technology for Web-based supply chain collaboration, however, some standardisation efforts are needed to make it widely accepted [51]. Finally, with an increased level of information sharing and collaboration, inter-firm trust needs to be enhanced before a Web-based SCM system is adopted [52]. 8. Conclusion and future work A Web-based early warning system is particularly useful for handling supply chain disruptions, as accurate timely information can easily be disseminated to the affected business partners [1]. To provide the customer with dependable information on order status, it is essential to have a broad view of a manufacturer’s delivery capability, covering the whole manufacturing process as well as suppliers’ delivery capabilities. Meanwhile, in case of an exception, it is very important for the affected business parties to collaboratively resolve the problem as soon as possible.

This paper proposes a Web-based system which addresses the above issues. Specifically, the system enables early identification of supply exceptions by using a milestone approach and dynamic matching between external customer orders and internal inventory and work orders. When a supply exception arises, the system supports the customer expeditor in assessing the impact of the unexpected event and to determine if an exception handling process needs to be initiated. Compatible with existing industrial practices which are largely manual work, this structured exception handling process pools the necessary information from other local systems to support fast, effective decision making. The knowledge base on how to avoid and manage supply chain disruptions is still in its infancy from both the practical and research perspectives [1]. The proposed system fills the gap in SCEM between the limited academic work mainly focusing on conceptualization in SCEM (e.g. [23]) and modeling of supply chain events (e.g. [24]), and currently available SCEM applications developed by major ERP/SCM system vendors (e.g. SAP, Oracle, i2), which fall short of decision support and efficient negotiation for fast problem solving [25]. The major contributions of this presented work include: (1) an integrative solution to common supply problems, which covers monitoring of customer order status, identification of supply exceptions, and handling of them in a fast and effective way; (2) a set of innovative and practical approaches for proactive supply chain control through early identification of exceptions, which include dynamic mapping between external customer orders and internal stock and work orders, the milestone approach for order progress calculation, and the traffic light approach for simplified presentation on customer order status; (3) the workflow models for early identification and collaborative handling of supply exceptions, which are compatible with the current manual practices; and (4) the approaches for system design and implementation (e.g. the decentralized system architecture, the top-down approach for system design, the integrated database). Therefore, this paper provides useful information and practical guidance for supply chain practitioners and software vendors in developing or implementing a Web-based SCM system. This paper also provides two theoretical contributions in relation to SCM. First, it extends the existing theories on responding to uncertainties in manufacturing (through appropriate use of different types of buffers [30–33,29]) from the manufacturing system level to the supply chain level. This leads to the development of a methodology for managing supply exceptions proactively, which is detailed in Section 3. Second, the paper conceptualises, develops and integrates what Christopher and Lee [35] suggested for breaking the risk spiral in the supply chain through an alert system for out of control conditions (which corresponds to the exception identification process) and tools for

H.H. Xu / Journal of Manufacturing Systems 29 (2010) 91–101

making corrective actions (which corresponds to the exception handling process). Future work can be carried out along three research lines. First, to get the system up and running in a real industrial environment with the maximum possible cost-benefits in a reasonable period, it is essential to address the issue of the integration of the supply chain system with local legacy systems. Second, the functionality of the pilot system can be enriched by some specific reports. For example, a comprehensive report on the current production status of the shop floor containing backlogs, WIP, throughput, etc. would be helpful for the production planner to make more informed decision making. Finally, the pilot system can be extended as a demonstrator to show how best practices in SCM can be achieved through enhanced information sharing and process integration with business partners, and what the expected benefits of improved co-ordination are for all the parties involved. For example, the exception handling process will get more and more responsive to delivery problems when information sharing migrates from the modest level, e.g. only the supplier has the visibility of inventories on the customer side, to the high level, e.g. the supplier has full control of inventories and online visibility of the customer’s shortterm production schedule. References [1] Blackhurst J, Craighead CW, Elkins D, Handfield RB. An empirically derived agenda of critical research issues for managing supply chain disruptions. International Journal of Production Research 2005;43(19):4067–81. [2] Juttner U. Supply chain risk management—understanding the business requirements from a practitioner perspective. The International Journal of Logistics Management 2005;16(1):120–41. [3] Craighead CW, Blackhurst J, Rungtusanatham MJ, Handfield RB. The severity of supply chain disruptions: design characteristics and mitigation capacities. Decision Sciences 2007;38(1):131–56. [4] Jain AK, Elmaraghy HA. Production scheduling/rescheduling in flexible manufacturing. International Journal of Production Research 1997;37:281–309. [5] Adacher L, Agnetis A, Meloni C. Autonomous agents architectures and algorithms in flexible manufacturing systems. IIE Transactions 2000;32: 941–51. [6] Li H, Li Z, Li LX, Hu B. A production rescheduling expert simulation system. European Journal of Operational Research 2000;124:283–93. [7] Bruccoleri M, Amico M, Perrone G. Distributed intelligent control of exceptions in reconfigurable manufacturing systems. International Journal of Production Research 2003;41:1393–412. [8] Bruccoleri M, Renna P, Perrone G. Reconfiguration: a key to handle exceptions and performance deteriorations in manufacturing operations. International Journal of Production Research 2005;43:4125–45. [9] Snyder LV, Scaparra PM, Daskin MS, Church RL. Planning for disruptions in supply chain networks. INFORMS 2005;1–23. [10] Qi L, Shen ZJM, Snyder LV. A continuous-review inventory model with disruptions at both supplier and retailer. Production and Operations Management 2009;18(5):516–32. [11] Kleindorfer PR, Saad GH. Managing disruption risks in supply chains. Production and Operations Management 2005;14(1):53–68. [12] Fine CH, Freund RM. Optimal investment in product-flexible manufacturing capacity. Management Science 1990;36(4):449–67. [13] Jordan WC, Graves SC. Principles on the benefits of manufacturing process flexibility. Management Science 1995;41(4):577–94. [14] Van Mieghem JA. Investment strategies for flexible resources. Management Science 1998;44(8):1071–8. [15] Bish EK, Wang Q. Optimal investment strategies for flexible resources, considering pricing and correlated demands. Operations Research 2004;52(6): 954–64. [16] Tomlin B, Wang Y. On the value of mix flexibility and dual sourcing in unreliable newsvendor networks. Manufacturing & Service Operations Management 2005;7(1):37–57. [17] Chod J, Rudi N. Resource flexibility and responsive pricing. Operations Research 2005;53(3):532–48. [18] Goyal M, Netessine S. Strategic technology choice and capacity investment under demand uncertainty. Management Science 2007;53(2):192–207. [19] Lus B, Muriel A. Measuring the impact of increased product substitution on pricing and capacity decisions under linear demand models. Production and Operations Management 2009;18(1):95–113. [20] Sheffi Y, Rice JB. A supply chain view of the resilient enterprise. MIT Sloan Management Review 2005;47(1):41–8.

101

[21] Gaonkar RS, Viswanadham N. Analytical framework for the management of risks in supply chains. IEEE Transactions on Automation Science and Engineering 2007;4(2):265–73. [22] Bodendorf F, Zimmermann R. Proactive supply-chain event management with agent technology. International Journal of Electronic Commerce 2005;9(4): 57–89. [23] Otto A. Supply chain event management: three perspectives. The International Journal of Logistics Management 2003;14(2):1–13. [24] Liu R, Kumar A, Aalst W. A formal modeling approach for supply chain event management. Decision Support Systems 2007;43(3):761–78. [25] Huang HY, Chou YC, Chang S. A dynamic system model for proactive control of dynamic events in full-load states of manufacturing chains. International Journal of Production Research 2009;47(9):2485–506. [26] Xu HQ, Besant CB, Ristic M. System for enhancing supply chain agility through exception handling. International Journal of Production Research 2003;41(6): 1099–114. [27] Co-OPERATE Deliverable D3. Solution Scope. 2000. [28] Croxton KL, Garcia-Dastugue SJ, Lambert DM, Rogers DS. The supply chain management processes. The International Journal of Logistics Management 2001;12(2):13–36. [29] Matson JB, McFarlane DC. Assessing the responsiveness of existing production operations. International Journal of Operations & Production Management 1999;19(8):765–84. [30] Newman WR, Hanna M, Maffei MJ. Dealing with the uncertainties of manufacturing: flexibility, buffers and integration. International Journal of Operations & Production Management 1993;13(1):9–34. [31] Ho CJ, Law WK, Rampal R. Uncertainty-dampening methods for reducing MRP system nervousness. International Journal of Production Research 1995;33(2): 483–96. [32] Hung YF, Chang CB. Determining safety stocks for production planning in uncertain manufacturing. International Journal of Production Economics 1999;58(2):199–208. [33] Slack N. The flexibility of manufacturing systems. International Journal of Operations & Production Management 1987;7(4):35–45. [34] Coleman BJ, Jennings KM. The, UPS. Strike: lessons for just-in-times. Production and Inventory Management Journal 1998;(fourth quarter): 63–67. [35] Christopher M, Lee H. Mitigating supply chain risk through improved confidence. International Journal of Physical Distribution & Logistics Management 2004;34(5):388–96. [36] Haugen R, McCarthy WE. REA, a semantic model for internet supply chain collaboration. In: The ACM conference on object-oriented programming, systems, languages, and applications. 2000. [37] O’Brien JA, Marakas GM. Management information systems. New York: McGraw-Hill; 2009. [38] Rupp TM, Ristic M. Fine planning for supply chains in semiconductor manufacture. Journal of Materials Processing Technology 2000;107(1–3): 390–7. [39] Camarinha-matos LM, Afsarmanesh H, Garita C, Lima C. Towards an architecture for virtual enterprises. Journal of Intelligent Manufacturing 1998; 9(2):189–99. [40] Anussornnitisarn P, Nof SY, Etzion O. Decentralized control of cooperative and autonomous agents for solving the distributed resource allocation problem. International Journal of Production Economics 2005;98(2):114–28. [41] Hulsmann M, Grapp J, Li Y. Strategic adaptivity in global supply chains— competitive advantage by autonomous co-operation. International Journal of Production Economics 2008;114(1):14–26. [42] Karkkainen M, Holmstrom J, Framling K, Artto K. Intelligent products: a step towards a more effective project delivery chain. Computers in Industry 2003; 50(2):141–51. [43] Rensberg AV, Zwemstra N. Implementing IDEF techniques as simulation modelling specifications. Computers & Industrial Engineering 1995;29(1–4): 467–71. [44] Presley A, Sarkis J, Barnett W, Liles D. Engineering the virtual enterprise: an architecture-driven modeling approach. The International Journal of Flexible Manufacturing Systems 2001;13:145–62. [45] Wisner JD, Stanley LL. Process management—creating value along the supply chain, text and cases. Ohio: Thomson; 2008. [46] Janah M, Wilder C. FedEx special delivery. Information Week 1997;(654): 42–60. [47] Karkkainen M, Ala-Risku T, Framling K. Efficient tracking for short-term multicompany networks. International Journal of Physical Distribution & Logistics Management 2004;34(7):545–64. [48] SAP. Supply chain event management (SAP EM); 2009. http://help.sap. com/saphelp_scm50/helpdata/en/69/b4393c95b04325e10000000a11405a/ frameset.htm. [49] Allen R. Workflow handbook. In: Layna Fischer (Ed.), Published in association with the workflow management coalition; 2005. Available at: http://www. wfmc.org. [50] Whitehorn M, Marklyn B. Inside relational databases. London: Springer; 2001. [51] Muehlen M, Nickerson JV, Swenson KD. Developing Web services choreography standards—the case of REST vs. SOAP. Decision Support Systems 2005;40: 9–29. [52] Pant S, Sethi R, Bhandari M. Making sense of the e-supply chain landscape: an implementation framework. International Journal of Information Management 2003;23:201–21.