See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4291924

Developing a collaborative supply chain reference model: A case study in

China

Conference Paper · September 2007

DOI: 10.1109/SOLI.2007.4383879 · Source: IEEE Xplore

CITATION READS

1 451

3 authors, including:

Shuihua Han Chao Chu

Xiamen University Pennsylvania State University
43 PUBLICATIONS   452 CITATIONS    146 PUBLICATIONS   3,573 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Building a Saas Platform for small-medium Manufacturing Enterprises in China View project

Operation and optimization for sustainable Supply chain management View project

All content following this page was uploaded by Shuihua Han on 29 April 2015.

The user has requested enhancement of the downloaded file.

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

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.

Copyright © 2009 Inderscience Enterprises Ltd.

 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

The model
Collaborative
covers the
business
five SC core
model
processes.

The model
focuses on
Collaborative cooperation
cooperation model and
model collaborative
interaction
patterns.

The model
describes the
Collaborative
process items
process
and their
model
inputs and
outputs.

The model
utilises tools
Collaborative such as
operation scenario,
model 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 Plan Source Make Delivery Return
mechanism management management management Management Management
Buyer’s internal project review/buyer-seller joint review/seller’s internal project
review
Collaboration Buyer’s P Buyer’s S Buyer’s M Buyer’s D Buyer’s R
mechanism Buyer-seller Buyer-seller Buyer-seller Buyer-seller Buyer-seller
joint plan joint source joint M joint D joint R
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 Maintain a consistent collaborative
network SC platform
Third party • Reduce concerns the uneven
service provider progress in SC
• Reduce concerns the non-core
information system operations
• More effective coordination
• Asymmetric distribution of
information
• Asymmetric distribution of
inventory
• Asymmetric distribution of
bargaining power between partners
• No optimisation in the entire
supply network
• 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 M1-3
Upload scheduling Activate scheduling
Create scheduling M1-5
Search scheduling
M1-2 M1-4
Search source Amend 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)

Supplier Scheduling
Customer

Product
Plan
Manufacturer Contractor

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.
 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.

View publication stats