52 Int. J. Electronic Customer Relationship Management, Vol. 3, No. 1, 2009

Copyright © 2009 Inderscience Enterprises Ltd.

Developing a collaborative supply chain reference model for a regional manufacturing industry in China

Shui-Hua Han* School of Management, Xiamen University, Xiamen, Fujian, P.R. China E-mail: hansh@xmu.edu.cn *Corresponding author

Chao-Hsien Chu College of Information Sciences and Technology, The Pennsylvania State University, University Park, PA 16802, USA E-mail: chu@ist.psu.edu Abstract: Under today’s competitive environments and globalisation trend, supply chain management has emerged as one of the best practices for corporations to gain competitive advantages. The supply chain (SC) operations reference (SCOR) model, developed by the SC Council, provides a common framework and standard terminology for evaluating, positioning and implementing SC practice. However, the model does not get to the specifics of how to manage collaboration in SC and what makes it work. It also lacks the best practice example for specific industries. In this paper, we extend the SCOR model by integrating collaborative product commerce and project management to propose a comprehensive collaborative supply chain operations reference model (CSCOR). The CSCOR consists of four hierarchical levels: business, cooperative, process and operational models. We apply the CSCOR model to a regional electricity industry in China and assess its relative effectiveness.

Keywords: supply chain; SC; supply chain management; SCM; coordination; cooperation; collaboration; collaborative product commerce; CPC; supply chain operations reference model; SCOR; China.

Reference to this paper should be made as follows: Han, S-H. and Chu, C-H. (2009) ‘Developing a collaborative supply chain reference model for a regional manufacturing industry in China’, Int. J. Electronic Customer Relationship Management, Vol. 3, No. 1, pp.52–70.

Biographical notes: Shui-Hua Han is currently a Professor at the Department of Information System at Xiamen University. He received his PhD at the HuaZhong University of Science and Technology in 2001. His current research areas cover customer relationship management, logistics simulation and radio-frequency identification security.

Chao-Hsien Chu is a Professor of Information Sciences and Technology (IST) and the Founding Director of the Center for Information Assurance at Penn State. He received his PhD in Business Administration from the Pennsylvania State University in 1984. He has published more than 100 refereed articles in top-ranking journals on enterprise integration, security and privacy issues, and enterprise resource planning.

Developing a collaborative supply chain reference model 53

1 Introduction

In recent years, increasing competition and globalisation trend and the advances of information and communication technology has attracted more and more companies to adopt supply chain management (SCM) as a best practice to achieve manufacturing excellence. SCM seeks to deliver customers quality of products and services with economic value through synchronised management of physical goods and associated information from sourcing to consumption (Schwarz, 2004). SCM involves extensive coordination among multiple functions and independent organisations engaged in the delivery of a product or a service to end customers (Lee and Whang, 2000).

Traditional transaction-based intra-organisation relationships focus on developing a partnership in which information, processes, decisions and resources are shared among organisations. However, mere coordination among trading partners today is no longer enough to maintain a competitive advantage. Collaboration becomes a recent trend in SCM that focus on joint planning, coordination and process integration between suppliers, customers and other partners in a supply chain (SC) (Mclaren et al., 2002). Several underlying trends formed the key drivers for SC collaboration (McLaren et al., 2002; Anderson and Lee, 1999; Nambisan, 2000). The first is the demand uncertainty on the SC, known as bullwhip effect. In the traditional supplier-buyer relationship, companies communicate demand information exclusively in the form of orders. This information tends to be distorted and can misguide upstream partners in their inventory and product decisions resulted in excess inventory and inefficiencies in SC. Another issue occurs in the absence of reliable demand information; thus, vendors must guess customer needs and push product that created much waste if the product was pulled or demand driven. Even when partners agreed to share information, demand forecasts and orders are often distorted unless jointly developed by the partners. Meanwhile, effective SC integration and collaboration among partners can eliminate excess inventory, reduce lead times, increase sales and improve customer services.

Organisations are aware of the advantages of SC collaboration (Lin and Lin, 2004; Zimmer, 2002; Akkermans et al., 2004; Dudek and Stdtler, 2005; Wang and Benaroch, 2004). However, it requires a comprehensive framework as a reference model when developing a collaborative SC that consists of a manufacturer, contract partners and suppliers. A great deal of discussion on collaboration in the SC mainly focused on the implementation of functions and key techniques, and how they lead to competitive advantage (McLaren et al., 2002; Holweg et al., 2005; Dreyer and Busi, 2002; O’Brien, 2001); relatively less on the functional models, coordination and collaborative management in SC (Mentzer, 2001). The Supply Chain Council (2007) proposed a SC operations reference (SCOR) model to assist firms in developing their SC framework and processes. Although SCOR concept do provide considerable reference value for firms, to date, SCOR model does not get to the specifics of how to manage collaboration in SC and what makes it work, as well as it lacks a best practice example, especially for regional manufacturing industry.

This study proposes to integrate the concepts of SC, collaborative product commerce (CPC), project management and SCOR model to establish a collaborative SC operations reference model (CSCOR). The CSCOR consists of four hierarchical levels: business, cooperation, process and operation models. These models represent different views and hierarchy of collaborative SC. We apply this model and implement a decision support

54 S-H. Han and C-H. Chu

system for the regional manufacturing industry to assess the capability of the CSCOR in establishing the best practice example.

2 Literature review

2.1 SC collaboration

A great deal of recent SC research focused on collaboration. Nambisan (2000) proposed a framework to analyse the emerging paradigm of SC collaboration and classified SCM integration into three dimensions: information, coordination and organisational linkage. Kumar (200l) argued that collaborative SC needs go beyond mere exchange and integration of information and involved tactical joint decision making among the partners. McLaren et al. (2002) analysed the various methods for synchronising SC information and process between organisations, such as using fax, e-mail, EDI or XML, web-based order entry system and shared collaboration SCM system. They also discussed the expect costs and benefits of each such system. Holweg et al. (2005) identified four different SC configurations from the view of inventory control and planning collaboration and discussed their dynamic behaviour and key characteristics.

All these researches mainly focused on the implementation of functions and key techniques, the relationship, behavioural aspects between the participants and how do they led to competitive advantage, but relatively less on the functional models, coordination and collaborative management in SC (Mentzer, 2001).

There also have been many SC collaboration initiatives the last few years, such as vendor managed inventory, efficient consumer response, collaborative forecasting planning and replenishment, and continuous replenishment (Cachon and Lariviere, 2001; Sanat et al., 2006; Smaros, 2007). But these practices only focused on front part but not the whole product lifecycle activities, such as planning and inventory control.

2.2 The major obstacles to SC collaboration

While individual successful implementations of SC collaboration have already been reported, there has not yet been the widespread adoption that was originally hoped for. According to one estimate, only 10% of manufacturers and distributors are using collaborative SC planning systems. The reality is that while many suppliers work with key customers to build forecasts, few perform this exercise online (Brandt, 2004). The reasons are:

First, many companies are reluctant to share data. Each partner is wary of the possibility of the other partners abusing information and reaping all the benefits from information sharing. For example, SC partners seldom share information that relates to sensitive cost data, e.g., production yield data or purchase price of parts. Thus, trust and cooperation become critical ingredients in a SC partnership (Lee and Whang, 2000). Even when willing, few firms are able to commit the managerial and technological resources necessary to make this kind of collaborative planning work. Implementation of a cross-organisational information system is costly, time-consuming and risky. Partners may not agree on the specification of technical system such as EDI or on how to split the cost of investing in the system.

Developing a collaborative supply chain reference model 55

Second, confidentiality of information shared is another concern associated with sharing information. A company has no control over what happens to its data once it is released. Ensuring the privacy and confidentiality of data once it has been disclosed is a popular issue in data sharing network. To reach this goal, the confidentiality requirements would have to be attached to the disclosed data while it travels through the network.

Third, another obstacle is rooted in limitations in conventional process modelling methodologies that are excessively generic for specific processes and lacks common terminology and performance metrics as these processes are designed by and for IT specialists, not by and for business process managers. This prevented the manufacturers and service providers from improving their performance.

Finally, the lack of a common means to describe SC processes for difficult and expensive software selection. Often companies were forced to alter their SC processes to suit the software. To resolve these problems, a SC collaboration framework using a reference model is needed.

2.3 The SCOR reference model

The SCOR model provides a common framework and standard terminology for evaluating, positioning and implementing SC efforts. SCOR integrates the well-known concepts of business process reengineering, benchmarking and process measurement into a cross-functional framework. More concretely, the structural framework of the SCOR model is composed of the following elements (Choi et al., 2005; Kaipia and Hartiala, 2006):

• standard descriptions of the individual elements that make up the SC processes

• standard definitions of key performance measures

• descriptions of best practices associated with each of the process elements

• identification of software functionality that enables best practices.

The Council has focused on three process levels and does not attempt to prescribe how an organisation should conduct its business. It is important to note that the model describes processes but not functions. In addition, SCOR model does not get to the specifics of how to manage collaboration in the SC and what makes it work, as well as it lacks the best practices examples for specific industries, especially for regional manufacturing industry. To our knowledge, very few studies have attempted this issue. Thus, development and assessment of collaborative SC operations require further discussion.

3 The collaborative SC operations reference model

SC collaboration has gone through stages of evolution. The early attempts at joint performance reviews among suppliers and customers were transformed into deeper forms of information exchange around sales and production. Today, collaboration occurs around the concept of business exchanges with SC members. Collaboration as a close relationship in an overall organisational system leads to synchronised business processes (Bowersox et al., 1999). This means that integration (internal and external) and processes on the operational, tactical and strategic contexts are involved. The operational context

56 S-H. Han and C-H. Chu

includes traditional processes related to procurement, production, distribution, transport and order. The planning and control context incorporates information technology and planning systems. The behaviour context relates to how a firm manages internal and external relationships among SC entities.

Figure 1 Framework of the CSCOR model

Level Title Schematic Summary

Collaborative business model

The model covers the

five SC core processes.

Collaborative cooperation

model

The model focuses on cooperation model and

collaborative interaction patterns.

Collaborative process model

The model describes the process items

and their inputs and outputs.

Collaborative operation

model

The model utilises tools

such as scenario,

interaction and work

flow analyses.

Collaboration means an organisational entity where the partners are integrated and acts as one extended enterprise with a mutual set of visions, goals and plans. Here, we extend the SCOR model by integrating CPC and project management to propose a comprehensive CSCOR. The CSCOR consists of four hierarchical levels (see Figure 1): business, cooperation, process and operations levels. As shown, the collaborative SC encompasses a high-end strategic business model for planning purposes, middle-end procedural model for collaborations and interactions, and low-end detailed model for operational analysis and control.

1 Collaborative SC business model (Level 1): The business model encompasses the core processes in a collaborative SC, which contains five core procedures: plan (P) covers processes that balance aggregate demand and supply to develop a course of action which best meets sourcing, production and delivery requirements; source (S) includes processes that procure goods and services to meet planned or actual demand; make (M) encompasses processes that transform product to a finished state

Developing a collaborative supply chain reference model 57

to meet planned or actual demand; delivery (D) covers activities from providing finished goods and services to meet planned or actual demand, typically including order management, transportation management and distribution management; return (R) encompasses processes associated with returning or receiving returned products.

2 Collaborative SC cooperation model (Level 2): The cooperation model describes interactions and collaboration patterns between suppliers and customers. The model helps to capture the numerous interactions in the collaborative SC when planning multiple interactive relationships of the five core processes between customers and suppliers. Also, each core process has multiple and concurrent tasks. Two collaborative patterns exist: management mechanisms and collaboration mechanisms (Table 1). The top level management mechanism is based on collaboration patterns consist of plan (P) management, source (S) management, make (M) management, delivery (D) management and return (R) management. Each core process has particular managerial activities. The bottom-level collaboration mechanism is based on communication between suppliers and customers and is deconstructed into a buyer’s internal project review, buyer-seller joint review and seller’s internal project review, such as buyer’s demand planning. Buyers and sellers can select suitable communication pathways based on core processes.

Table 1 Summary of the collaboration patterns

Patterns Plan (P) Source (S) Make (M) Delivery (D) Return (R)

Management mechanism

Plan management

Source management

Make management

Delivery Management

Return Management

Buyer’s internal project review/buyer-seller joint review/seller’s internal project review

Buyer’s P Buyer’s S Buyer’s M Buyer’s D Buyer’s R Buyer-seller

joint plan Buyer-seller joint source

Buyer-seller joint M

Buyer-seller joint D

Buyer-seller joint R

Collaboration mechanism

Seller’s P Seller’s S Seller’s M Seller’s D Seller’s R

3 Collaborative SC process model (Level 3): The process model describes the process items and process input/output (I/O) data. Based on the collaboration patterns described in Level 2, this model corresponds to each process to illustrate the standard process and I/O data for each collaboration pattern. Due to the CSCOR processes, this study only uses the collaborative process controlled by the manufacturer in ‘M1: buyer’s scheduling management’ as an example for further discussion (Figure 4).

4 Collaborative SC operation model (Level 4): The operation model utilises scenario analysis, interaction analysis and information flow analysis to document the SC operations. Scenario analysis encompasses the commercial activities of the customer, manufacturer with its suppliers in the SC process; interaction analysis is applied to analyse the interactive activities among the customer, manufacturer and its suppliers during the SC process and information flow analysis evaluates information exchange and interaction among the customer, manufacturer and its suppliers via online platforms. We here utilises the three analytical approaches described previously to develop the operational procedure ‘M1.2: searches for possible supplier source’ as an example for discussion (Figure 5).

58 S-H. Han and C-H. Chu

4 Adoption of the CSCOR to a regional electricity manufacturing industry

A regional manufacturing chain is a mixture of product and business types in a particular region, which often contains a core manufacturer, suppliers, contractor and distributors/retailers. The core manufacturer is the head of the regional manufacturing chain. In order to supply customers with creative and quality products, simplified processes and lower cost, the head needs to closely communicate and coordinate the SC according to product specifications. In this study, we apply CSCOR model to a regional electricity manufacturing SC in China.

4.1 Key processes in SC collaboration

The core manufacturer, Xiamen Overseas Chinese Electronic Company (XOCECO for short) founded in Dec. 1985 is a special colour TV manufacturer and has been long committed to independent innovation, R&D and making of such high end products as LCD TV, PDP TV and HDTV. Now XOCECO has a sales and service network spreading over the five continents and 119 countries and regions across the world and the company is doing its most to build a panel colour TV manufacturing base which is the largest in the world with an annual output of 8–10 million panel colour TV sets.

Figure 2 The CSCOR process in a regional electricity manufacturing industry

In order to meet end customer requirements promptly and face market demand variability with faster changes in production/resource planning, the core manufacturer has established a CPC virtual manufacturing team for collaboration with customers, contract firms and suppliers. Figure 2 depicts the key processes of the manufacturing SC. When receiving an order from customers, the core manufacturer first analysed the customer requirements and then developed a plan to ensure its control over the production schedule, quality and costs. The company may choose to outsource some particular components so that it can master the core product components. In addition, the company may purchase other standard components from suppliers. The collaborative scheduling includes main production scheduling, manufacturer production schedule, customer shop scheduling and outsource delivery scheduling.

Developing a collaborative supply chain reference model 59

4.2 The development of the CSCOR platform

The CSCOR decision support system can be developed following two major approaches: using the private network or using a certified public third party service provider. Table 2 summarises the pros and cons of each approach.

The private network approach tends to result in a more consistent collaborative SC platform, as the core manufacturer knows very well about its requirements and has control over its suppliers and contactors. However, this may cause such problems as asymmetric distribution of information, inventory and bargaining power and over control on SC. Meanwhile, since the network is own and controlled by the core enterprise, other SC partner can only do transaction with this core enterprise. If a partner corporation needs to exchange information with others, several interface protocols are needed in order to communicate with different enterprises.

The service provider approach provides equal opportunity for participators in the collaborative commerce, thus, it tends to reduce concerns on the uneven progress in SC. Core enterprise and its partners are equal during business operations, so the partners do not concern about the uneven progress in SC. Both can gain benefits from focusing on their own core operations without caring much about non-core information system operations. While several core enterprises can share a common platform, only one-interface protocol is needed in order to communicate with all other enterprises.

So we choose to use a certified public third party service provider platform because the certified third party IT infrastructure in China is still in developing. Table 2 Comparison on collaborative SC developing mode

Mode Pros Cons

Individual private network

Maintain a consistent collaborative SC platform

• Asymmetric distribution of information

• Asymmetric distribution of inventory

• Asymmetric distribution of bargaining power between partners

• No optimisation in the entire supply network

Third party service provider

• Reduce concerns the uneven progress in SC

• Reduce concerns the non-core information system operations

• More effective coordination

• May have integration problems and privacy focus

4.3 Apply the CSCOR to the regional manufacturing industry

Application of the proposed CSCOR to the regional manufacturing industry is described in details below, following the hierarchical framework.

60 S-H. Han and C-H. Chu

4.3.1 Collaborative SC business model (Level 1)

We depict the collaborative business model for the regional manufacturer in Figure 3. The core manufacturer and its suppliers first collaboratively conduct the forecast. They then decide the requirement plan and make collaborative schedule according to the bills of materials. During the manufacturing stage, SC partners negotiate to amend schedule online according to the forecast, order, outsource and delivery. As shown, the business model covers four of the five core SC processes: forecast (plan), schedule (make), order (source), outsource (source) and deliver.

Figure 3 Collaborative SC business model (Level 1)

4.3.2 Collaborative SC cooperative model (Level 2)

The cooperative model elucidates the patterns of collaboration between the core manufacturer and its suppliers during the collaborative manufacturing. From requirement forecast to schedule release, the process covers making requirement plan, uploading component requirement plan, searching contract firms, looking for source, negotiating schedule and amending and releasing schedule. If negotiation of the collaborative schedule fails, this process needs to look for new supplier and renegotiates collaborative schedule again. If it is still unsuccessful, then the whole process will be cancelled and a new schedule needs to be created. For example, in outsourcing manufacturing, if contract firm cannot carry out contract order, manufacturer will have to search for new source and amend the released schedule.

Two collaborative patterns exist in the above collaborative process: management mechanisms and collaboration mechanisms (see Table 1). The top-level mechanism focuses on the management plan and control over the five SC core processes. Each core process has particular activities that management should concentrate. For example, the plan management includes the following activities:

1 identify, prioritise and aggregate SC requirements

2 identify, assess and aggregate SC resources

3 balance SC resources with requirements

4 establish and communicate SC plans (please refer to SCOR for details).

Developing a collaborative supply chain reference model 61

The bottom-level collaboration mechanism concentrates on the communication between suppliers and manufacturers and is decomposed into buyer’s internal project review (such as buyer’s demand planning), buyer-seller joint review and seller’s internal project review. Buyers and sellers can select suitable communication path based on the core processes.

4.3.3 Collaborative SC process model (Level 3)

In this level, the collaboration pattern of SC (from Level 2) was decomposed into detailed processes. The process model describes the process items and their inputs and outputs. For example, Figure 4 illustrates the manufacturer’s ‘M1: buyer’s scheduling management’, the core manufacturer control over collaborative manufacturing process.

1 the core manufacturer first upload product scheduling (M1.1).

2 the core manufacturer searches for possible supplier source (M1.2), amend schedule and items of schedule, which include scheduling date, purchasing amount, expected amount and received amount, here, expected amount and purchasing amount are referred by next order, received amount is decided by delivery order.

3 then schedule is activated (M1.3), it can be reached by suppliers and contractors.

4 the core manufacturer will negotiate detail items of collaborative schedule with suppliers and contractors, and the amend detail item of schedule (M1.4).

5 finally the collaborative scheduling is confirmed, the suppliers and contractors can search the confirmed scheduling (M1.5).

6 if negotiation failed, schedule turns to be deactivated and the company needs to search new source again (M1.2).

Figure 4 Example of collaborative SC process model (Level 3)

M1-1 Upload scheduling Create scheduling

M1-2 Search source

M1-3Activate scheduling

M1-5Search scheduling

M1-4Amend scheduling order

62 S-H. Han and C-H. Chu

4.3.4 Collaborative SC operational model (Level 4)

This model focuses on operational-level collaborative analysis utilising three analytical tools – scenario analysis, interaction analysis and workflow analysis.

A. Scenario analysis

The scenario analysis of M1-2 focuses on three aspects. First, the manufacturer communicates and coordinates with the customer to complete the product plan under customer needs. Next, the manufacturer collaborates with the partners of SC to create/modify product scheduling. Finally, the manufacturer contracts with contactors to make plan of OEM products, additionally it purchases other standard components from suppliers.

Figure 5 An example of scenario analysis (see online version for colours)

The scenario analysis is clarified in detail as follows (Figure 5)

1 Customer sends a product-planning request.

2 The customer and manufacturer collaborate during product planning.

3 The manufacturer completes the product plan and delivers it to the customer for confirmation.

4 The core company creates collaborative scheduling; the partner members search scheduling, the collaborative scheduling is decided by group negotiation. Negotiation can be done immediately by message/mobile message B2B platform to help each other communication.

�

Customer

Contractor

Supplier

Product Plan

Scheduling

�

�

� �

�

�

�

�

� ��

Manufacturer

Developing a collaborative supply chain reference model 63

5 Through the make plan of collaborative manufacturing, it contracted several contractors to produce the OEM components.

6 Then contractors deliver the OEM components to company after the manufacturing was completed.

7 The core manufacturer purchases other standard components from suppliers.

8 The supplier delivers these parts to the manufacturer.

9 The manufacturer delivers product to the customer after the assembling was completed.

B. Interaction analysis

The interaction analysis of M1-2 focuses on activities in which the exception occurs, for example, supplier can’t response for order, schedule turns to be deactivated and the manufacturer has to search the new source again (e.g., contractor or parts supplier). Its process is shown in Figure 6.

1 the core manufacturer receives a message on accident interruption of delivery

2 the core manufacturer searches pending schedule and find a pending schedule

3 the core manufacturer looks for supplier resource

4 the core manufacturer negotiates collaborative scheduling with new suppliers

5 after then, the core manufacturer locks the schedule

6 before amend collaborative scheduling, it needs to analyse information about planned, purchased and received, so that new scheduling is confirmed by coordinating with SC partners.

Figure 6 Collaborative SC operational model (Level 4) interaction analysis (see online version for colours)

64 S-H. Han and C-H. Chu

4.4 System implementation in the regional manufacturing industry

The system was implemented using J2EE. Struts and Hibernate frame are adopted for the system implementation. Struts is chosen as main development frame, hibernate is chosen as data persistent layer, solving date exchanges between SC system and legacy system, then improving the system reusability and scalability, and lowering down the cost of maintenance. Hence, this system attains the benefits inter-organisation collaboration via heterogeneous systems. Figure 7 shows the five major service modules in the system: requirement forecast, collaborative schedule, outsourcing management, order management and delivery management.

Figure 7 Regional collaborative manufacturing system (see online version for colours)

Table 3 Effectiveness of CSCOR implement

Item Before After

Order Telephone/fax Systematic focus Forecast Artificial Artificial/systematic Shut trouble Severe Seldom PO process 3–5 days Less than 24 hours PO confirm 3–5 days Less than 24 hours PO cycle One week Shorten more than 30% Delivery Telephone/fax Systematic monitoring Turnover days 30 days Shorten more than 30%

Developing a collaborative supply chain reference model 65

4.5 Performance assessment

To assess the effectiveness of CSCOR, we applied the model to a regional manufacturing industry in China. A software prototype was developed and tested. We have seen some encouraging results from pilot testing the prototype. Table 3 shows efficiency after CSCOR application. As shown, communication efficiency between enterprise and supplier has been enhanced more than 20%, probability of cut off due to shut, cost of purchase and time to delivery have also been greatly reduced.

5 Results and discussion

Creating, managing and maintaining real collaboration pose many challenges for SC in the following aspects:

• information sharing and heterogeneous data integration

• creating shared processes among the SC parties

• secure SC collaboration (SSCC) and trust management.

These issues are important in guiding us to an appropriate model of SC that we intend to design. It is our belief that next generation of SCs are collaborative SCs and all of these issues need to be handled properly in order to materialise a collaborative and trust worthy SC.

5.1 Information sharing and heterogeneous system integration

As collaborative SC system is built in the third-party platform, it faces the problems of information sharing and exchanging between different legacy systems. These problems are from following:

1 From view of data users, they don’t know where and what kind of method data is stored, so they want a common and consistent data service.

2 From view of data providers, they do not want to setup client software, do not allow the third party to modify their own information system. The third party can only integrate the information system with the platform by available API functions.

3 From view of data sharing, data providers do not allow users to access their data unlimitedly; also they do not like to leak their private information by the other party. Meanwhile, the integration with the third-party platform should not exist security risk.

4 From view of system flexibility, information sharing and exchanging should adapt loose-coupling SC environment, system maintenance and upgrade should not have effect on the third-party platform.

To solve these problems, instead of popular XML integration method, we use ORM technology with Hibernate to create persist layer which integrates several databases as a virtual database that unifies to see the diagram, then open to provide the indiscrimination data service. Based on data volume and relational level, different integration methods are used for different enterprise. In order to integrate with core enterprise application, data

66 S-H. Han and C-H. Chu

layer is used for data interaction between heterogeneous database to integrate with other enterprises, Hibernate technology and JDBC is used for reading information from heterogeneous database.

For core company, we realise data input and output between different databases in data layer. If SC system is tired-coupling with legacy system, then huge amount of data will be shared. We use data output method to realise data integration. First, SCM database is divided into two parts, A and B. Part A is shared data in SCM system as well as the backup data from legacy system, part B is used to store private data. Please note: it is not map of legacy system; we will timely input data from legacy system to part A of SCM system.

If item of table in legacy system is different from that of SC system, first we will create a similar structure of table with legacy system, then select item of table by Hibernate data persistent layer technology, to make them consistent.

For the suppliers or external consultants, we use ORM technology of Hibernate to integrate with the legacy system. It creates virtual object on persistent layer, which can be a related data table map of legacy system, the system will access data from legacy system by JDBC.

Take product data table for example. Product information table CpInfo exists in legacy system, we use hibernate.cfg.xml file to claim remote database address, access mode and used tables.

<property name="connection.driver_class"> com.jnetdirect.jsql.JSQLDriver </property> <property name="connection.url"> jdbc:JSQLConnect://172.18.1.169/erp </property> … <mapping resource="com/xoceco/service/scm/po/CpInfo.hbm.xml" />

Then we will create a product information virtual object CpInfo.java and map file CpInfo.hbm.xml on persistent layer of third-party platform. Here, data item in virtual object may be different from the legacy’s system, such as product information table CpInfo has purchase price item, while virtual object CpInfo.java doesn’t need to include this item.

Hibernate will automatically relate product information of virtual object with legacy system to promise operation on virtual object will automatically map into legacy system.

<class name="com.xoceco.service.scm.po.CpInfo" table="cp_info" mutable="true" polymorphism="implicit" dynamic-update="false" dynamic-insert="false" select-before-update="false" optimistic-lock="version"> <id column="cpcode" name="cpcode" type="java.lang.String"> </id> <property column="cpname" length="40" name="cpname" not-null="true" type="java.lang.String" unique="false" optimistic-lock="true" lazy="false" generated="never" />

Developing a collaborative supply chain reference model 67

5.2 Collaboration mechanism among enterprises

While SCM focuses on controlling the activities among the SC partners, SC integration focuses on improving the information flow between links in the chain and SC optimisation or SC coordination focuses on making decision that reduce the information asymmetry and excess inventory in the SC. However, if only dominant partner drivers SC optimisation decision, this can create an asymmetrical distribution of information, inventory and ultimately bargaining power between the partners (McLaren et al., 2002). Thus, in order to optimise the entire supply network and not create just local optima in one or two partners, the organisation must jointly make supply and demands decision that create sustainable value for all involved.

Take order management for example, from order created to order release, there is a continuing negotiation process between supplier and core enterprise by message, telephone and fax. However, these tools cannot guarantee seamless order processing as the partner in SC may ignore changes of order. In order to avoid such situation, the system provides two kinds of extra collaborative mechanism:

1 one is open cooperative platform such as message, electronic bulletin

2 the other is an embedding cooperative tool such as e-mail, notice and interactive log.

Electronic bulletin posts general information (such as dynamic price, user information, market analysis) and requirement information (such as product resource and new product supply). Message service is a light interactive tool in which enterprise can send message to specific partner. The system can also fresh message listing every five seconds, despite that message has been sent to partner real-time.

Meanwhile, system log records change of order according to date and operator. SC enterprise can check order-changing log, which records detail interaction interface. Interaction interface shows who and when has done operations on the item. Here, the user can upload file related to item, also download file to check detail snapshot. File upload and download enable interaction information goes beyond structure data; it also record all stage’s detail version. Detail snapshot helps enterprise to fast check-modified data, then make efficiency improved.

Notice includes notice of shipping and notice of delivery. Notice of shipping traverse orders by date of delivery in accordance with the organisational code, supplier code and material code, then statistics the total quantity of shipping. Notice of delivery statistics the delivery orders from the selected date till today, and then calculate the quantity arrival. Notice enables the core company to have an overall grasp of delivery orders.

5.3 SSCC and trust management

One of the major sources of inefficiency in SCM is information asymmetry; i.e., information that is available to one or more organisations in the chain (e.g., manufacturer, retailer) is not available to others. There are several causes of information asymmetry, among them; fear that a powerful buyer or supplier will take all advantages of the private information and the information will leak to a competitor and fear of potential espionage of combined data sets, etc. Therefore, if it is possible to enjoy the benefits of information-sharing without disclosing private information is a major bottleneck for SC collaboration. Inspired by the work of Atallah et al. (2006), we propose to use a SSCC

68 S-H. Han and C-H. Chu

protocol that can enable SC partners to cooperatively achieve desired system-wide goals without revealing the private information of any of the parties, even though the jointly computed decisions requiring the information of all the parties.

Trust management is another difficult problem to solve. Trust means having confidence on your partner, will do what he says and that he will not exploit your vulnerabilities. Trust is critical, without it, you waste much time in negotiations and trying to get a bargaining advantage and forget sharing any information that you do not have to. Trust is also the key focuses for data safekeeping. If data is collected in computer centre of third-party, such a collaborative SC system will only be used among limited partners who trust with each other because efficient trust mechanism is still unavailable in China, also there exist information security, bribe and tax dodging in business. Such a problem can only solved by government policy and social trust system first, the second is name of certified public third party, the third is technical security guarantee, More viable method is that the data scatters to store in internal environment of application enterprise, the certified public third party try to manage and provide the technique support service through the network, though this is just a kind of the safety of mental state.

Figure 8 The five-layer authorisation management system (see online version for colours)

Information security is another problem, which is an extension of the trust problem. In fact, all data stored in the computer centre of the third party is safer than in application enterprises; however, organisations need to be security conscious to safeguard the confidentiality of customer interactions. The security mechanisms implemented in the CSCOR platform should have a high-level of security to ensure the privacy and authenticity of the information being exchanged. Public key infrastructure (PKI), secure socket layer (SSL) and the secure electronic transaction (SET) protocol all needs to be evaluated properly to offer easy and secured solutions. There have been plenty of instances where hackers have been able to download malicious code and hack sensitive data despite the efforts of leading-enterprise firewalls. Checkpoint and RSA security’s SecurID token-based authentication system and firewalls are electronic moats that have built around the enterprise castle. Yet these moats will only provide a false sense of

Developing a collaborative supply chain reference model 69

security if they are not properly configured or maintained or if they are one-way systems that do not include controls for outbound traffic.

To solve the security problem, the CSCOR platform not only heavily invest in such hardware security devices as firewall and intrude detection system, but also use IPsec-standard virtual private network (VPN) that can interoperate with the major corporate VPN gateways, content filtering software, anti-virus software and digital certificates from VeriSign or any other agencies. A five-layer authorisation management system in CSCOR platform is built as shown in Figure 8. Enterprise user should first have a login license system and then each user can login using a secret key to access the system.

6 Conclusions

Establishing an operations reference model and providing an example of the best practices for industry is a common goal for academics and practitioners. This study integrates the concepts of SC, collaborative product design, CPC, project management and the popular SCOR model in SC to propose the CSCOR reference model.

The main contribution of this paper is that we extend the popular SCOR model to CSCOR, a universally applicable collaborative SC reference model, to help manage the complicated intra- and inter-collaborations between suppliers, manufacturer and customers. This study also applies the CSCOR and develops a prototype to test in an electronics industry, which serves as an example of the best practices for a collaborative SC involving customers, a manufacturer, contract firms and suppliers. A decision support system such as this would help to simplify the decision-making process, enhance collaborative effectiveness, improve operational efficiency, reduce cost and improve customer satisfaction. Given that the proposed CSCOR is only being evaluated by its application to the electricity industry, further studies should apply this model to other industries.

Acknowledgements

This work is supported by Program for New Century Excellent Talents in Fujian Province University.

References Akkermans, H, Bogerd, P. and Doremalen, J. (2004) ‘Travail, transparency and trust: a case study

of computer-supported collaborative supply chain planning in high-tech electronics’, Euro. J. Op. Res., Vol. 153, pp.445–456.

Anderson, D.L. and Lee, H.L. (1999) ‘Synchronized supply chains: the new frontier’, in Anderson, D. (Ed.): Achieving Supply Chain Excellence through Technology, Montgomery Research, USA.

Atallah, M., Blanton, M., Deshpande, V. et al. (2006) ‘Secure collaborative planning, forecasting and replenishment (SCPFR)’, Multi-Echelon/Public Applications of Supply Chain Management Conference.

70 S-H. Han and C-H. Chu

Bowersox, D.J., Closs, D.J. and Stank, T.P. (1999) 21st Century Logistics: Making Supply Chain Integration a Reality, Council of Logistics Management.

Brandt, J. (2004) ‘Demand planning, optimizing operations across the supply chain’, White paper on Microsoft Dynamics.

Cachon, G. and Lariviere, M. (2001) ‘Contracting to assure supply: how to share demand forecasts in a supply chain’, Management Science, Vol. 47, No. 5, pp.629–646.

Choi, Y., Kim, K. and Kim, C. (2005) ‘A design chain collaboration framework using reference models’, Int. J. Adv Manuf. Tech., Vol. 26, pp.183–190.

Dreyer, H.C. and Busi, M. (2002) ‘Supply chain collaboration: what does it mean for logistics?’, Proceeding of 14th Annual NOFOMA Conference.

Dudek, G. and Stdtler, H. (2005) ‘Negotiation-based collaborative planning between supply chains partners’, Euro. J. Op. Res., Vol. 163, pp.668–687.

Lee, H.L. and Whang, S. (2000) ‘Information sharing in a supply chain’, International Journal of Technology Management, Vol. 20, No. 3, pp.373–387.

Holweg, M., Disney, S., Holmström, J. and Smaro, J. (2005) ‘Supply chain collaboration: making sense of the strategy continuum’, Euro. Manage. J., Vol. 23, No. 2, pp.170–181.

Kaipia, R. and Hartiala, H. (2006) ‘Information-sharing in supply chains – five proposals on how to proceed’, Int. J. Logistics Management, Vol. 17, pp.377–393.

Kumar, K. (2001) ‘Technologies for supporting the supply chain management’, Communication of ACM, Vol. 44, No. 6, pp.58–61.

Lin, J. and Lin, T. (2004) ‘Object oriented conceptual modelling for commitment based collaboration management in virtual enterprises’, Information and Software Technology, Vol. 46, pp.209–217.

McLaren, T., Head, M. and Yuan, Y. (2002) ‘Supply chain collaboration alternatives: understanding the expected costs and benefits’, Internet Research: Electronic Networking Applications and Policy, Vol. 12, pp.348–364.

Mentzer, J.T. (2001) Managing Supply Chain Collaboration, Supply Chain Management, Sage Publications, Inc., USA.

Nambisan, S. (2000) ‘EC and supply chain management: towards cross-industry supply chain’, Electronic Markets, Vol. 10, No. 3, pp.197–202.

O’Brien, W. (2001) ‘Enabling technologies for project supply chain collaboration’, Invited white paper for the NSF/ICIS Infrastructure and Information Technology Workshop, June 25–27, Arlington, VA.

Sanat, K.B., Keshav, P.D. and Bhadra, M.T. (2006) ‘Agent oriented peer-to-peer supply chain for collaborative planning, forecasting and replenishment’, Proceedings of the 7th Informatics Workshop for Research Students.

Schwarz, L.B. (2004) The State of Practice in Supply Chain Management: A Research Perspective. Applications of Supply Chain Management and E-Commerce Research in Industry, Kluwer Academic Publishers, The Netherlands.

Smaros, J. (2007) ‘Forecasting collaboration in the European grocery sector: observations from a case study’, J. Operations Management, Vol. 25, pp.702–716.

Supply Chain Council (2007) Supply-Chain Operations Reference Model (SCOR) Version 9.0, Supply-Chain Council, USA.

Wang, C.X. and Benaroch, M. (2004) ‘Supply chain coordination in buyer centric’, B2B Electronic Markets, Vol. 92, pp.113–124.

Zimmer, K. (2002) ‘Supply chain coordination with uncertain, just in time delivery’, Economics, Vol. 77, pp.1–15.