You are on page 1of 20

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

net/publication/265390710

An advanced CMII-based engineering change management framework: The


integration of PLM and ERP perspectives

Article  in  International Journal of Production Research · October 2014


DOI: 10.1080/00207543.2014.911987

CITATIONS READS

34 4,169

5 authors, including:

Min-Chun Yu Hao-Yun Kao


National Kaohsiung University of Science and Technology Kaohsiung Medical University
26 PUBLICATIONS   779 CITATIONS    31 PUBLICATIONS   1,653 CITATIONS   

SEE PROFILE SEE PROFILE

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

Entrepreneurship Education View project

All content following this page was uploaded by Min-Chun Yu on 29 April 2016.

The user has requested enhancement of the downloaded file.


This article was downloaded by: [Northeastern University]
On: 18 December 2014, At: 00:26
Publisher: Taylor & Francis
Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,
37-41 Mortimer Street, London W1T 3JH, UK

International Journal of Production Research


Publication details, including instructions for authors and subscription information:
http://www.tandfonline.com/loi/tprs20

An advanced CMII-based engineering change


management framework: the integration of PLM and
ERP perspectives
a b b c a
Wen-Hsiung Wu , Lung-Ching Fang , Wei-Yang Wang , Min-Chun Yu & Hao-Yun Kao
a
Department of Healthcare Administration and Medical Informatics, Kaohsiung Medical
University, Kaohsiung, Taiwan, ROC
b
Department of Information Management, National Kaohsiung University of Applied
Sciences, Kaohsiung, Taiwan, ROC
c
Department of Business Administration, National Kaohsiung University of Applied Sciences,
Kaohsiung, Taiwan, ROC
Click for updates Published online: 29 Apr 2014.

To cite this article: Wen-Hsiung Wu, Lung-Ching Fang, Wei-Yang Wang, Min-Chun Yu & Hao-Yun Kao (2014) An advanced CMII-
based engineering change management framework: the integration of PLM and ERP perspectives, International Journal of
Production Research, 52:20, 6092-6109, DOI: 10.1080/00207543.2014.911987

To link to this article: http://dx.doi.org/10.1080/00207543.2014.911987

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) contained
in the publications on our platform. However, Taylor & Francis, our agents, and our licensors make no
representations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of the
Content. Any opinions and views expressed in this publication are the opinions and views of the authors, and
are not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon and
should be independently verified with primary sources of information. Taylor and Francis shall not be liable for
any losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoever
or howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use of
the Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematic
reproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in any
form to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://
www.tandfonline.com/page/terms-and-conditions
International Journal of Production Research, 2014
Vol. 52, No. 20, 6092–6109, http://dx.doi.org/10.1080/00207543.2014.911987

An advanced CMII-based engineering change management framework: the integration of


PLM and ERP perspectives
Wen-Hsiung Wua, Lung-Ching Fangb, Wei-Yang Wangb, Min-Chun Yuc and Hao-Yun Kaoa*
a
Department of Healthcare Administration and Medical Informatics, Kaohsiung Medical University, Kaohsiung, Taiwan, ROC;
b
Department of Information Management, National Kaohsiung University of Applied Sciences, Kaohsiung, Taiwan, ROC;
c
Department of Business Administration, National Kaohsiung University of Applied Sciences, Kaohsiung, Taiwan, ROC
(Received 16 April 2013; accepted 17 February 2014)

Previous studies of engineering change management (ECM) presented valuable results from the design domain of the
product lifecycle management (PLM) perspective. However, few of these studies proposed a framework under the
Downloaded by [Northeastern University] at 00:26 18 December 2014

configuration management II (CMII) standards and its industrial implementation based on the design and manufacturing
domains of PLM and enterprise resources planning. This study proposes an advanced CMII-based ECM framework. This
framework has been successfully implemented in a large Taiwanese motorcycle manufacturer resulting in significant
performance improvement. Major contributions of this study include: (1) presenting an advanced CMII-based ECM
framework, (2) depicting information exchange and integration between the design and manufacturing activities based on
five major ECM phases and their associated processes and (3) providing a basis for best practice from the motorcycle
industry for reference in other manufacturing industries.
Keywords: engineering change management; advanced configuration management II standard; product lifecycle
management; enterprise resource planning

1. Introduction
To meet customer demands and create new market opportunities, enterprise management needs to establish coherent and
controlled processes for new product development for the creation of new, high-quality products with minimal costs and
lead times. New product development is an iterative process entailing inevitable product requirement changes based on
shifts in customer requirements or manufacturing processes (Cooper and Kleinschmidt 1995; Lilien et al. 2002; Petersen,
Handfield, and Ragatz 2005; Smith and Eppinger 1997). Change processes are a critical part of manufacturing and must
be carefully controlled. Hence, engineering change management (ECM) has become a crucial issue in new product
development, allowing enterprises to realise cost benefits by understanding customer needs and controlling design data
(Gagne and Fortin 2007; Jarratt, Eckert, and Caldwell 2011; Wright 1997).
Many ECM studies have provided valuable results from the design domain of the product lifecycle management
(PLM) perspective. For example, Shiau and Li (2007) presented a conceptual design configuration framework and a
closed loop engineering change control workflow for product data management in the PLM conceptual design phase.
Tavčar and Duhovnik (2005) proposed a five-step general ECM process including change request, change preparation,
change approval, documentation update and production implementation. Nadia, Gregory, and Vince (2006) developed a
computerised model for new product development and simulated change request management to compare performance
for changes occurring individually or in batches. Cheng, Chen, and Chang (2012) proposed a novel engineering chain
collaboration model and a corresponding ECM system to resolve problems leading to high failure rates and design
cycles for integrated circuits (ICs). Based on Configuration Management II (CMII) standards, Wu et al. (2012) proposed
a novel ECM framework with the addition of Full-track or Fast-track processes to solve fundamental product functional-
ity or quality problems within the manufacturing industry.
An important trend has emerged in recent years based on integrating different functional domains’ perspective, such as
design and manufacturing (Schuh et al. 2008). For example, the integration of PLM and enterprise resources planning (ERP)
has significantly improved productivity and effectiveness in product design and manufacturing (Cheung, Maropoulos, and
Matthews 2010; CIM Data Report 2005). Moreover, Merminod and Rowe (2012) stressed that the PLM and ERP
architectures are complementary. Grieves (2006) overcomes interoperability and data exchange issues for these two

*Corresponding author. Email: haoyun@kmu.edu.tw

© 2014 Taylor & Francis


International Journal of Production Research 6093

architectures, integrating them with a single mechanism with a shared database to ensure better consistency and singularity.
The Institute of Configuration Management (ICM) proposed a standardised ECM framework and developed the CMII model
(Guess 2002; ICM 2004). Gagne and Fortin (2007) evaluated the implementation of this model within a virtual product
development laboratory to integrate different functional domains such as design and manufacturing. In light of this direction,
the key building blocks of the ICM’s proposed approach are shown to reside in the domain of configuration
management (ICM 2012). Hence, the CMII model can be used as a conceptual guideline to construct a standardised ECM
framework.
The above discussions suggest an emerging trend in the integration of the design and manufacturing domains, using
the CMII model as a conceptual guideline. However, few studies have proposed a framework under the CMII standards
or its industrial implementation based on the design and manufacturing domains of PLM and ERP. Hence this study
proposes the development of an advanced CMII-based ECM framework from the design and manufacturing domains
based on the integration of PLM and ERP. This framework consists of four major steps and eight work items taken from
the conceptual CMII standard, and requires the addition of key activities to achieve process excellence. To evaluate the
feasibility of this advanced ECM framework, this study presents a case study implementation at a major Taiwanese
motorcycle manufacturer and provides a reference model for other industries.
The following section presents the related findings and Section 3 describes the proposed advanced CMII-based
Downloaded by [Northeastern University] at 00:26 18 December 2014

ECM framework. Section 4 applies the framework to a Taiwanese motorcycle manufacturer, with a before and after per-
formance comparison. Conclusions are offered in the final section.

2. Related work
2.1 Integration of the design and manufacturing domains from the PLM and ERP perspectives
PLM is focused on design and development functions; whereas, ERP focuses on production and manufacturing func-
tions. The two mechanisms are complementary and need to be integrated (Merminod and Rowe 2012). PLM and ERP
differ in terms of process scope, with ERP systems focusing on the integration of back office activity (Gattiker and
Goodhue 2005; Kallinikos 2004; Lee and Lee 2000; Reddi and Moon 2011a) while PLM primarily focuses on the inte-
gration of new product development process (Balaji, Ranganathan, and Coleman 2011; Schuh et al. 2008), both types of
mechanisms aim at integrating multiple departments, involving processes that have strong cross functional interdepen-
dencies.
Regarding the information integration and exchange between two above mechanisms, ownership of the product
structure and bill of material (BOM) shift from manufacturing to engineering. However, BOM information must still be
supported and accessible within ERP applications, thus increasing the importance of integrating PLM and ERP to ensure
consistency of BOM, product change and other related information used throughout an enterprise (CIM Data Report
2005; Lee, Leem, and Hwang 2011). Any product information should be created through the PLM mechanism before
being referenced in the ERP mechanism. PLM and ERP architectures are based on a single system with a shared data-
base and therefore provide better consistency and singularity (Grieves 2006). Moreover, to improving the quality of data
exchanged between design and manufacturing, enterprises need to provide an interactive and effective bridge between
the two mechanisms that support process planning activities for complex products (Huet et al. 2009; Khedher, Henry,
and Bouras 2012).
The integration of PLM and ERP can deliver significant benefits for companies of all sizes. ERP and PLM solutions
address different business needs and processes (CIM Data Report 2005). These benefits accrue to several areas includ-
ing: (1) ensuring consistent use of product/plant-related information by personnel throughout the enterprise, (2) reducing
the time needed to bring new and better products to market at a lower cost and (3) ensuring the use of common prod-
uct-related terminology and processes throughout the business. However, integrating PLM and ERP mechanisms can
force a company to address these differences to create a solution that all groups will adopt and use. More importantly,
integration between PLM and ERP is as much about integrating key processes (e.g. change management) as it is about
transferring data from one application to another. A company’s business practices will then determine how to best
implement PLM and ERP.

2.2 ECM
The importance of ECM in new product development is increasing because of the cost benefits realised by matching
customers’ needs and having a process in place which ensures that each stakeholder has input in changes (Huang and
Mak 1999; Huang, Yee, and Mak 2003). However, most relevant studies present results from the design perspective for
6094 W.-H. Wu et al.

ECM. For example, Diprima (1982) and Jarratt, Eckert, and Caldwell (2011) stressed an ECM process in which the
implementation part of an engineering change (EC) emphasises ‘Concurrent Engineering’. Reddi and Moon (2011b)
conducted simulations to identify critical components for the entire process and used system dynamics models to exam-
ine the complex interrelationships among various members in a collaborative supply chain to achieve effective and effi-
cient ECM processes. Regarding the industrial applications of ECM processes, Cheng, Chen, and Chang (2012)
proposed a novel engineering chain collaboration model (engineering chain management system – ECMS) to reduce the
high failure rate and design cycle duration for ICs.
From the standpoint of the framework and its stages, Shiau and Li (2007) created a conceptual design configuration
framework and a closed loop engineering change control workflow that can be applied to product data management in
the conceptual design phase. The former provides guidelines for identifying configuration items in the conceptual design
phase. The latter controls changes to the configuration items and their related documentation, maintaining consistency to
enable continuous improvements to product design. Huang, Yee, and Mak (2003) proposed three primary stages in a
typical ECM lifecycle: (1) an EC is identified and formally requested, but not yet approved; (2) the change is evaluated,
classified and prioritised and (3) the EC is approved and released for implementation. Tavčar and Duhovnik (2005) pro-
posed a general EC process consisting of five steps including change request, change preparation, change approval,
change of documentation and implementation in production. Wu et al. (2012) presented a novel ECM framework based
Downloaded by [Northeastern University] at 00:26 18 December 2014

on CMII standards and industrial applications. This framework considers the addition of Full-track or Fast-track pro-
cesses to solve fundamental product functionality or quality problems within the manufacturing industry.

2.3 Advanced CMII standard


The CMII model, proposed by the ICM, provides standardised guidelines for managing products, facilities and pro-
cesses. The original CMII model contains dual cycles (i.e. requirements and physical items) from the design domain. In
this model, all activities are driven by requirements, that is, requirements determine the physical items. Three entities –
the creator (i.e. product designer), the user (i.e. customer) and the change review board (CRB) – join in all activities in
the ECM process. Moreover, these two cycles contain eight work items and four major steps. The eight work items
include Schedule and Baseline, Work Authorisations, Perform Work, Verify Conformance, Change Requests, Change
Notices, Upgrade Documents and Data and Validate and Release. The four major steps consist of Plan, Do, Study and
Act (Guess 2002; ICM 2004).
ICM has recently proposed an advanced CMII standard for use in integrating process optimization between the
design and manufacturing domains (ICM 2012). This advanced methodology provides a path to integrate process excel-
lence dependent on the availability of appropriate business process infrastructure. The key building blocks of the meth-
odology are shown to reside in the domain of CM. The advanced CMII methodology allows the production process to
effectively accommodate change while keeping requirements clear, concise and valid. Consistent conformance and con-
tinuous improvement are by-products of the methodology, providing a lean process which minimises risk (ICM 2012).
Regarding the advantages of ECM standards, Paviot, Cheutet, and Lamouri (2011) stressed that the use of open stan-
dards helps overcome issues related to the semantic aspects of interoperability. The CMII-based standards were found to
foster a highly collaborative product development and manufacturing process environment in which both engineering
and manufacturing information structures are kept synchronised in real time (Gagne and Fortin 2007).

2.4 Summary
The above studies of integration of PLM and ERP domains indicate the emerging trend of integrating the design and
manufacturing domains. Moreover, most ECM studies have presented valuable results from the design domain of the
PLM perspective. From the related work of standards, we have found that previous CMII standards focused on the
design domain, and then evolved to integrate the manufacturing domain to achieve process excellence and ECM effec-
tiveness. However, few studies focused on the ECM issue in terms of the integration between design and manufacturing
domains and provided an industrial case as a reference model. Hence, this study proposes the development of an
advanced CMII-based ECM framework from the design and manufacturing domains based on the integration of PLM
and ERP. Additional descriptions of the framework and a case study are provided in the next section.

3. Framework of advanced CMII-based ECM with integration of PLM and ERP


This study proposes a framework for an advanced CMII-based ECM which integrates PLM and ERP. As illustrated in
Figure 1, in the framework, the PLM side is based on the design domain. The focus is on engineering, the goal is
International Journal of Production Research 6095

Customers

PLM ERP
Design Domain Manufacturing Domain
Focus: Engineering Focus: Manufacturing
Goal: Product management
Driver: Projects
Structure: E-BOM
ECM Goal: Resource planning
Driver: Orders
Structure: M-BOM
Delivers: New products Delivers: Ongoing manufacturing

Suppliers
Downloaded by [Northeastern University] at 00:26 18 December 2014

Engineering Change Management (ECM)

Phases Design Activities Manufacturing Activities


Identify the Issue Problem Report Customer Requirement
Conduct the Analysis Engineering Change Request Business Analysis
Planning the Change Engineering Change Notice Supplier Process
Release the Change Validation/Audit/Release Release Product Change
Change Product Configuration Engineering Change History Product Traceability

Figure 1. Overview of the advanced CMII-based ECM framework.

product management, the process is driven by projects, the structure is based on the engineering bill of material
(E-BOM) and the process is designed to deliver new products. The ERP side is based on the manufacturing domain and
focuses on manufacturing. The goal is resource planning, the process is driven by orders, the structure is based on
manufacturing bill of material (M-BOM) and the process is designed to deliver ongoing manufacturing.
Regarding the interaction of the PLM and ERP sides, the process is initiated by customer requirements. Relevant
issues are recorded on the ERP side and then transferred to the PLM side, which can provide information related to the
product or part design process. For example, information related to the product structure and attributes on the PLM side
can be transmitted to the ERP side. The ERP side can then transfer the manufacturing information (i.e. M-BOM) to the
PLM side after processing to maintain information consistency. The suppliers can collaborate on new product develop-
ment on the PLM side, with the suppliers’ workflow management taking place on the ERP side.
Given the focus on the integration of PLM and ERP, five major design activities are applied on the PLM side –
problem report, engineering change request (ECR), engineering change notice (ECN), validation/audit/release and engi-
neering change history. In addition, five manufacturing activities are proposed on the ERP side – customer requirement,
business analysis, outsourcing to suppliers’ process, release product change and product traceability. All design and
manufacturing activities are based on five ECM phases: identify the issue, conduct the analysis, plan the change, release
the change and change product configuration. The five ECM phases are described in detail as follows.
(1) Identify the issue – This phase checks for customer requirements and determines whether there is a problem
with the product. Customer feedback on product quality issues take place on the ERP side, and the staff report
problems or suggest improvement to product design (i.e. function enhancement). These reports or suggestions
are typically captured in a problem report on the PLM side. The issue is analysed, discussed and validated
before moving to the next step. Relevant information, e.g. identification of the affected product and/or sug-
gested solutions, is captured using a problem report on the PLM side. Once submitted, the problem report is
automatically sent to a designated reviewer for validation, followed by approval or rejection.
6096 W.-H. Wu et al.

(2) Conduct the analysis – This phase conducts a change investigation and business analysis based on the cus-
tomers’ requirements. Approval of a problem report on the PLM side prompts the change team to proceed
with an in-depth change investigation, which is captured in an ECR. The product experts (i.e. quality control
staff) produce a business analysis on the ERP side capturing the scope of the change, feasibility, downstream
product impact, solution proposals, costs and business justification.
(3) Plan the change – This phase plans the detailed implementation of the change through collaboration with the
relevant suppliers. When a change is accepted for implementation, an ECN records the implementation plan
on the PLM side. This plan entails multiple tasks (e.g. devising a manufacturing schedule) associated with the
product data to be changed, including outsourcing to suppliers on the ERP side. A schedule is proposed and
recommendations are made for the disposition of existing product inventory. Implementation is triggered by
the workflow when the plan is approved.
(4) Release the change – This phase validates, audits and releases the product change. Upon approval of the
implementation plan, all work tasks are delivered to the designated users (i.e. product designer). When a work
task is completed, a designated reviewer (i.e. BOM manager) is notified to review and approve the actual vs.
planned change on the PLM side. When all work tasks are approved, a final validation and audit notice is sent
to a designated reviewer, typically the engineering manager, who will perform a final validation and analysis
Downloaded by [Northeastern University] at 00:26 18 December 2014

of the entire ECN based on actual vs. planned changes, the effective date of the change, disposition of obso-
lete parts and new and updated product configurations on the PLM side. Upon approval, the product change
will be released on the ERP side.
(5) Change product configuration – This phase is to access the engineering change history of new product
version and trace it. The PLM side recodes the engineering change history and product traceability for every
version control and processing cost of the engineering change product recall on the ERP side. If already-sold
products have any issues, engineering changes are incorporated into production, and the new and modified
parts are inspected to ensure compliance with design requirements. Based on the engineering change history
on the PLM side and product traceability on the ERP side, we can quickly identify distributed products for
recall.
Based on the five ECM phases with design and manufacturing activities above, Figure 2 provides a detailed depic-
tion of the advanced CMII-based ECM framework with integration of PLM and ERP.

3.1 Identify the issue


(1) Customer requirements on the ERP side
Customer requirements are initiated from customer feedback for quality assurance, field and distributor support and cus-
tomer expectations. This feedback from claim service reports is then used to identify product problems and for enhance-
ment by the quality assurance administrator-I (QA-I). Upon completion, the information (i.e. customer feedback) on the
ERP side will be transferred to the PLM side.
(2) Problem report on the PLM side
A problem report (PR) is generally collected by an enterprise’s buyers and channel agents from feedback on customer
requirements from the ERP side, including customer suggestions for new functionality or design defects. Once a PR is
created it is sent to the change administration-I (CA-I) (i.e. the business or quality administrator), who either approves
or rejects it. If the problem is confirmed to result from a manufacturing or design defect, the problem report will be
approved and an ECR will be created.

3.2 Conduct the analysis


(1) Change Request on the PLM side
A change request (CR) can be created in response to one or more PRs according to customer requirements from the
ERP side or without reference to a PR, depending on internal decisions within the organisation (e.g. a technical
enhancement or a designer’s decision). A PR identifies the change necessary to correct the problem or provide an
enhancement such that appropriate personnel can decide whether to proceed with or cancel the proposed change. After
the CA-I accepts the problem report (using the assigned task), the CA-I creates a change request. The creator is also
responsible for technical review. Next, the creator and CA-I provide an impact analysis and report.
Based on this impact analysis and enterprise-specific criteria, the CRB will also decide whether the change will be
Full-tracked or Fast-tracked. Thus, the CRB members need to discuss the approval of CR and, if approved, which track
International Journal of Production Research 6097

Problem Report Customer


Anyone QA-I Claim service report
(Schedule & Baseline) Requirement
Identify Problem
Identify Issue
Create PR Customer Feedback
Plan
CA-I QA-I
(Work Authorization) Identify Need
Review PR

Change Request Business Analysis


QA-I
CA-I Creator Investigate
(Perform Do (Verify
Technical Change Need
Work) Create CR Conformance)
Review
Clarify
Conduct the Analysis

CRB
Review
Impact Manufacturing
Analysis Technical
Study Cost Estimation

CRB Re-Work
Downloaded by [Northeastern University] at 00:26 18 December 2014

Review Analysis
Decision Making (CRB) Approve

Fast Track Full Track

Change
Notice CA-II Plan Major Plan Minor
Suppliers Process
QA-II
Change Change
Create Create (CN)
CN CN
Act
Change
Create Create Implementation
Implementation Implementation
Plan the Change

Plan Plan

CIB
CIB Review
QA-I:Quality assurance Administrator I
Implementation
QA-II:Quality assurance AdministratorII
Review Change
QC:Quality ControlAdministrator
Implementation
Plan
Re-Work

Approve Release
(Upgrade Change
Creator
Documents&
Edit Produ Data)
Datact

Release Product Change


User QC
PR:Problem Report
CR:Change Request Physical
Validation
Implementation
Release the Change

CN:Change Notice
Re-Work
CA-I:Change Administration I
CA-II:Change Administration II
CA-III:Change Administration III (Validation
CA-III &Release)
CRB: Change Review Board CN Audit Review /Audit
Approve
CIB:Change Implementation Board Change

Released

Product Change History


Review /Audit Product Traceability
Approve
Change Product

Change Manufacture Management


Configuration

Engineering
Change History
Product Traceability
Review /Audit Service Parts Management
Change Approve

Figure 2. Detailed view of the advanced CMII-based ECM framework.


6098 W.-H. Wu et al.

to adopt. Full-track is for large changes that generate time delays and high costs, while Fast-track is suited to small
changes that can be implemented at low cost. As the CRs are reviewed and confirmed, change notices (CNs) are created
by the change administration-II (CA-II) (i.e. the design administrator).
(2) Business analysis on the ERP side
Given one or more approved problem reports from the PLM side, the QA-I needs to investigate the required change. If
the need for the change is not clear, the process returns to the previous task for clarification. If the need is clear, a man-
ufacturing technical review is conducted to determine the scope, feasibility and cost of the change. When the CRB on
the PLM side has completed and approved the previous tasks, it proceeds to the next phase.

3.3 Plan the change


(1) Change notice on the PLM side
The CA-II in the CN is responsible for creating ECNs and implementing plans. The plans mainly consist of a part
drawing renewal plan, part change plan, production change plan or prototype testing plan, depending on whether the
change request is determined to be Full-track or Fast-track.
 If the CR is being Fast-tracked, the change is restricted to the forward path of the change. That is, the appropri-
Downloaded by [Northeastern University] at 00:26 18 December 2014

ate CA-II is assigned to create the CN and execute necessary actions from the implementation plan, such as the
part drawing renewal plan, part change plan and production change plan.
 Full-tracked CRs require thorough prototype testing of the impact of the change. The appropriate CA-II is then
assigned to create the CN and document the necessary actions of the implementation plan, such as the part
drawing renewal plan, part change plan and production change plan. Based on the implementation plan above,
the change implementation board (CIB) is assigned to review and approve this plan prior to implementing any
CN.
(2) Outsourcing to suppliers’ process on the ERP side
When the changes captured in the CN from the PLM side are approved, QA-II on the ERP side needs to assess the
scope of the change. Minor changes should be quickly implemented, requiring little review prior to the release of the
changed product data. Major changes can require the creation of a project with an implementation team and detailed
plans measuring progress against significant milestones. More complicated changes require the coordination of tasks
between internal manufacturing and technology staff, and their counterparts in the firm’s suppliers. When QA-II
determines the change scope, change implementation tasks can be initiated. When this implementation is complete,
the reviewer (i.e. CIB) checks whether the review/audit task is completed. When all review/audit tasks for a CN are
approved, it is forwarded to the workflow by a change administrator (i.e. CA-II) to release the change and go to
the next phase. If the changes raise any questions, the change will be sent back to the change implementation stage and
reworked.

3.4 Release the change


(1) Change notice on PLM side
Regardless of which route the CR takes in the planning change phase, when the CN and implementation plan are
approved, the product structure, product model and/or documentation are upgraded. Then, the following tasks must be
processed:
 The creator edits the product data as directed by the change notice tasks.
 Users must check and approve the creator’s work before the EC is completed.
 When all tasks associated with the CN have been completed, the CA-III (i.e. quality administrator) audits the
result to ensure that it is clear, concise and valid before releasing it to the ERP side.
(2) Release Product Change on the ERP side
Based on the released change from the PLM side, the quality control (QC) administrator determines the physical imple-
mentation, such as manufacturing a small volume of the revised part. The QC then reviews/audits the gap between
actual vs. planned change. If the QC did not reject the review, it goes back to physical implementation for rework.

3.5 Change product configuration


(1) Product change history on the PLM side
International Journal of Production Research 6099

When the ECN is released, the revised part or product goes to mass production on the ERP side. All engineering
change histories including change information, documentation and workflow process are recorded. The change informa-
tion consists of product issue, PR, the CRB report and the CIB report. The documentation mainly includes impact anal-
ysis documentation related to relevant techniques, costs and stock analysis). The workflow process includes engineering
change workflow roles, actors, signatories, sign off times and comments. Staff members (i.e. product managers) on the
ERP side can check this engineering change history on the PLM side for future reference regarding the product or part’s
design, manufacture or use.
(2) Product traceability on the ERP side
When the physical implementation in the last phase is approved, the next step is the approval of the review/audit task
based on sampling approach for mass production. For manufacturing management, staff members need to review prod-
uct traceability including items such as assembly serial number, manufacturing date and the new product version. For
service part management, staff members need to review product traceability items including manufacturing date, old and
new product versions and stock locations. This data for both kinds of product traceability categories on the PLM side
will serve as a reference for future inquiries on the ERP side.
Downloaded by [Northeastern University] at 00:26 18 December 2014

4. Case study implementation


4.1 Overview
Company M, a large Taiwanese motorcycle manufacturer, was chosen for the study case. This company has been in
operation for over 40 years, and has annual revenues in excess of NT$20 billion. Company M produces various products
and parts, such as two-wheel motorcycles, all-terrain vehicles, power equipment and engines based on different product
development strategies for own branding and manufacturing (OBM), own designing and manufacturing (ODM) or origi-
nal equipment manufacturing (OEM). The company has a global sales network including channels in Asia, Oceania,
North America, Europe and Africa.

4.2 ECM problems and implementation


Company M annually deals with about 24 new product development projects of varying scales per year, ranging from
the development of new two-wheel motorcycles to the design of new engines. The company also handles hundreds or
thousands of engineering changes annually, ranging in scope from changes to body colour to engine materials. To com-
plete high CMII standards across different product development strategies, different global markets and buyers, and dif-
ferent scales of new product development projects, Company M decided to adopt the CMII-based ECM framework
starting in 2004, with the first phase completed in 2007. With the completion of phase one, the framework had been
adopted as a crucial foundation for CMII standards and had been successfully implemented in the Company. However,
this phase only focuses on the design domain and needs to further consider integration with the manufacturing domain
through CMII-based ECM. Hence, beginning in 2008, the top management decided to pursue the second phase to inte-
grate the design and manufacturing domains from the PLM and ERP sides. The CMII-based ECM framework is imple-
mented in Company M with PTC Winchill software and ERP software developed by IS department based on enterprise
application integration (EAI) technique for decreasing the cost of design and manufacturing (i.e. EC frequency and
product traceability time), resolving the interoperability between heterogeneous platforms and ensuring the timeliness,
consistency and accuracy of product data exchange.
From a practical perspective, Company M is a successful real-world case of advanced CMII-based ECM framework
deployment. The results and overall implementation experiences are valuable and can provide guidance for best practice
for other industries. From an academic perspective, this case fits Yin’s (2003) three rationales of case research: First, this
is a critical case for testing and supplementing well-formulated ECM related research; second, it is unique given the rar-
ity of successful implementation in industrial settings; and third, this is a revelatory case in that it provides an opportu-
nity to observe and analyse phenomena (e.g. the integration of design and manufacturing domains) which were
previously inaccessible to scientific investigation.

4.3 Practical implementation of five major phases in Company M


(1) Identify the issue
Figure 3 shows Company M’s operational process for identifying the issue from customer feedback and customer
requirements on the ERP side to create an engineering change problem report on the PLM side. The process is
described in detail below.
6100 W.-H. Wu et al.

Customers

Problem Report
Analyze customer Customer Requirement
Analyze Problem Report-
Requirement -
Change Administrator I
Quality assurance
Administrator I Clarify
Reject

Not Clarify

Confirm Create Confirmed


Problem Problem Notify Identify Describe
Report Report Accepted Issue Issue

Reject
Downloaded by [Northeastern University] at 00:26 18 December 2014

Notify
Reject
Conduct CIB Rejected

Develop
ECR

Figure 3. Operational process of identifying the issue in Company M.

On the ERP side, customer feedback on issues including product quality, function enhancement and price are coded
as product issues, which are then described, analysed and identified as customer needs. If the customer issue has been
clarified and confirmed by the QA-I, the customer needs are then accepted and transferred to the PLM side to create a
problem report. If the issue is not adequately clear, it will be rejected. Otherwise, the customer issues are identified,
accepted and transferred to the PLM side to create a problem report which is then analysed by the appropriate depart-
ments and approved by the creator (i.e. QA-I). Once the creator has finished reporting the problem, the engineering
change is delivered to the CA-I for review. The CA-I must then analyse the problem report to confirm that the problem
report is valid in CIB. Any resolved problem report sends a notification to the creator of the problem report with the
appropriate justification in CIB. The CA-I can choose to confirm the PRs and send it on for ECR creation, reject the
problem report as unsuitable or send it to the problem report author for more clarification.
For example, customer feedback from South-east Asia mentioned insufficient rigidity and fractures in the main struc-
ture pipe in a certain type of motorcycle. However, these problems are seldom reported from regions. The QA-I asked
the local agency to collect and analyse information about motorcycle use, and found that road conditions in Southeast
Asia are poor and users regularly overload the motorcycles more than 10 times the safe loading limit. When this prob-
lem was confirmed and this issue was accepted, the issue was transferred to the PLM side to create a product problem
report. Finally, the insufficient rigidity and broken structure pipe were discussed and analysed in the CIB. Once the
importance of the issue is confirmed, a product ECR will be proposed.
(2) Conduct the analysis
Figure 4 presents Company M’s operational process of conducting the analysis based on information from the previous
phase. The steps in the change process include creating and analysing the ECR on the PLM side, and business analysis
on the ERP side. Detailed descriptions of this phase and an example are as follows.
On the PLM side, ECR may be created from existing problem reports or may be created independently. For a busi-
ness decision to be made, ECR must be analysed in terms of describing a product defect or proposing a detailed
enhancement. The captured information includes the affected parts and documents, the approach, the risks and benefits
and costs involved, the business decisions made during the process (e.g. whether to make the change), and potential
impact of Full-Track or Fast-Track routing. However, the ECR needs to attach any and all problem reports that the ECR
is needed to resolve. The ECR’s creator has the option of providing additional information to validate the ECR and/or
conduct an impact analysis with the corresponding proposals. However, the requestor can store the additional
International Journal of Production Research 6101

Problem Report

Engineering Change Request Business Analysis


Analyze ECR -Quality assurance
- Change Administrator I Administrator I

Create ECR New Parts


Required ?

Reject Analyze ECR Identify and Collect


Affected Data

Investigate
Validate Problem
Downloaded by [Northeastern University] at 00:26 18 December 2014

Impact
Analysis

Assess Manufacturing Analysis


Impact Stock Analysis
Cost Analysis
Track
?
Fast Track Full Track

Create ECN

Figure 4. Operational process of conducting the analysis in Company M.

information with the ECR. The ECR’s creator may also collaborate with technical reviewers (i.e. CRB) to validate and
assess potential impacts.
Based on the analysis of ECR from the PLM side, the staff (i.e. QA-I) can conduct business analysis to evaluate new
part requirements on the ERP side. New change requests capture information from the problem reports, and identify and
collect the change data. All departments must be aware of the current state of the engineering change and cooperate to
ensure its smooth execution. Once a change request is generated and submitted, it is analysed by the QA-I. Establishment
of the change request is followed by repeated confirmation, problem discussions, technical manufacturing reviews, impact
analysis, problem investigation and feasibility reviews. The QA-I must then evaluate the ECR and collect the data for the
change request, and either make a business decision to proceed (i.e. stock/cost analysis) with the change or reject the
change request. The QA-I could also return the change request to the author for further clarification.
For example, when an ECR is created regarding the insufficient rigidity of the main structure pipe, the staff needs to
conduct a business analysis covering insufficient rigidity, customer importance and contribution, new part creation costs,
and ECR goals for the customer requirements (i.e. requirements for added rigidity in the main structure pipe and goal
costs) on the ERP side. Moreover, the staff processes the expectation analysis of impact for actual rigidity, expected
rigidity and goal setting for the main structure pipe, inventory cost and cost of engineering change on the ERP and
PLM sides. Finally, the firm will choose to Fast-Track or Full-Track the change, and create an ECN for the next phase
based on the impact analysis above.
(3) Plan the change
Figure 5 shows the operational process of Company M for planning the change. This phase consists of creating and
analysing the ECN on the PLM side, and outsourcing to suppliers on the ERP side. Detailed descriptions of this phase
and an example are given below.
After the product issue decided to make the EC, the CA-II creates the ECNs on the PLM side. When the ECN has
been created and approved it is analysed and delegated. The operational process includes assigning people (i.e. the
product managers) to conduct each required data modification. It may be necessary for CA-II to delegate planning
6102 W.-H. Wu et al.

Create ECN

Engineering Change Notice


Suppliers Process
Analysis ECN -Change Administrator II
-Quality assuranceAdministrator II

Analysis
ECN

Planning Review & Audit


Delegation Implementation Suppliers
Plan
Fast Track Full Track

Create Create
Implementation Implementation
Plan Plan

Review
Downloaded by [Northeastern University] at 00:26 18 December 2014

Implementation
Plan

Execute
CIB
Plan

Release Product Data

Figure 5. Operational process of planning the change in Company M.

cactivities to another technical resource. However, CA-II remains responsible for the total plan and for setting the effec-
tive date for each new or revised part version.
When the process of planning delegation is complete and EC is benefit positive, the CRB must select either a Fast-
track or Full-track change request. For Full-track changes, the next step is to create and obtain approval of the change
notice implementation plan from the CIB. If the plan is on the fast track, then the implementation tasks are sent to the
next phase. If the CIB believes that the plan is incomplete or inaccurate, it may be sent back to the CA-II for further
planning. The change request/change notice package may also be sent back to the CA-II for further review of the
change request if details of the implementation plan increase the cost/impact of the change.
The cost-benefit decision is usually measured against a pre-determined cost threshold expressed in dollars. In Com-
pany M, Full-track and Fast-track change requests, respectively, account for approximately 15 and 85% of all change
requests. Given Full-track’s detailed review of high-impact changes and Fast-track’s high efficiency in executing low-
impact changes, the proposed CMII-based ECM framework can simultaneously increase efficiency and reduce opera-
tional costs.
Within Company M, Full-track and Fast-track processes are classified according to the following five grades (Full-
track: A–B class, Fast-track: C–E class).
 A class (Full-track)
A critical function defect has been found. Production must cease immediately until the defective parts can
be replaced. All defective parts in circulation must be retrieved.
 B class (Full-track)
A critical function defect has been found, but the defect can be remedied through modifying the part. Pro-
duction need not stop. The old parts can still be used after modification and can be exchanged for the new part
when it is available. Old parts in the sales pipeline must be retrieved while the new parts are distributed.
International Journal of Production Research 6103

 C class (Fast-track)
The problem does not affect the function, so current production need not be suspended, and existing inven-
tory can be used before the distribution of replacement parts, but production of the problem parts should cease
immediately.
 D class (Fast-track)
The EC will increase functionality and/or productivity. Existing stock will be used up, and production will
be changed to the replacement part within three months (though this can be extended in special cases).
 E class (Fast-track)
The EC will increase pattern management or part integration. Existing stock will be used up, and production
will be changed to the replacement part within six months. Where existing stock cannot be used on other mod-
els, and the change results in supply chain shortages lasting less than a month, vendors will be compensated
for insufficient stock based on the number of days of insufficient stock divided by thirty, multiplied by a pre-
scribed amount per month.
On the ERP side, the implementation plan must be approved by the CIB before implementation. The CA-III is typi-
cally the chairman of the CIB, whose responsibilities include scheduling meetings, setting agendas and conducting
Downloaded by [Northeastern University] at 00:26 18 December 2014

reviews. The CIB is comprised of a cross-functional team of participants empowered to review and audit a change
notice and determine whether an implementation plan is completed and communicated with suppliers.
For example, once the ECN for enhancing the rigidity of the main structure pipe is created and approved, Company M
needs to redesign the part, and conduct computer simulations and lab testing on the PLM side. Based on the above consid-
eration and task execution, after review CIB executes the plan on the Full-track. Moreover, the processes for research and
development analysis and planning are conducted such as supplier management, supplier engineering change review,
auditing and implementation plan, while reconfirming the manufacturing process tasks and methods on the ERP side.
(4) Release the change
Figure 6 shows the operational process of Company M for releasing the change, including execution, validation, audit,
approval recording and release of product data on the PLM side, along with physical implementation, review and audit
of the change on the ERP side by CA-III. Detailed descriptions of this phase and an example are as follows.
On the PLM side, the CA-III executes all change plan process activities and then audits all of the document changes
implemented by the ECN tasks. Each part version will also have a proper effective date. The CA-III then records his or
her decision. When the audit is successfully completed, each changed notice is validated. If validation fails, the failed
elements are sent back to the appropriate implementers for correction. When validation is complete, a series of workflow
process events route all effective dates to completion. The ECN, CRs and PRs are also audited. When the CA-III com-
pletes the audit task, the CN and all of the changed parts and documents are set as ‘Released’.
On the ERP side, physical changes are implemented by the ECN tasks. Each part version will also have a proper
effective date. Note that, in the manufacturing and/or the supplier physical implementation part change, the physically
changed part or new version part must be reviewed/audited. When the CA-III completes the physical implementation
review/audit task, the changed parts are set as ‘Approved’. However, actual manufacturing depends on stock availability
and business decisions.
For example, after the CIB reviewed the ECN to enhance the rigidity of the main structure pipe, they executed, vali-
dated and audited the engineering change plan. The CA-III acts as an auditor for all of the information to ensure that it
fits the customer requirements, that all resulting documentation is clear, concise and valid, and that all tasks (i.e. safety
testing) are properly executed. Each EC task must be conducted accurately according to the ECN plan because of the
safety issues involved in the main structure pipe. Hence, every validation and auditing task needs to be checked and
approved prior to the release of the EC.
(5) Change product configuration
Figure 7 shows the operational process of Company M for changing product configuration. This phase records the engineer-
ing change history on the PLM side and conducts product traceability such as manufacturing management, supplier manage-
ment and service part management on the ERP side. Detailed descriptions of this phase and an example are as follows.
On the PLM side, when all product changes are completed, a new version part/product will be designed and
released. This history of new product designs in production depends on manufacturing schedules (i.e. manufacture by
order), hence the change process is not finalised until new part designs are fabricated and assembled. Moreover, the
engineering change history provides the ability to address variances to product specifications. It is important that vari-
ances from design specifications are only temporary solutions and must be followed by the permanent solutions that
bring produced parts back into compliance with design specifications.
6104 W.-H. Wu et al.

Execute
CIB
Plan

Validation/Audit/Release Product Data Product Change Implementation


-Change Administrator III -Quality Control

Audit Physical
Execute Implementation
Activity

Rework

Review/Audit
Validation Physical Change
Downloaded by [Northeastern University] at 00:26 18 December 2014

Approve
Conduct
Audit

Record Correct Data


Approval

Release

Engineering Change
History

Figure 6. Operational process of releasing the change in Company M.

Engineering Change
Release

Engineering Change
History Product Traceabillity

Engineering Change Product Manufacturing Suppliers’


History Traceability Management Management

Service Par
Management

Figure 7. Operational process of changing product configuration in Company M.


International Journal of Production Research 6105

When all ECs are released, the part/product change data will be linked with the ERP side. Once the manufacturing
line and after-service maintenance mechanisms possess the change data, product traceability is performed. Moreover,
manufacturing management and service part management are linked to the production processing and supplier manage-
ment.
For example, when the EC for enhancing the rigidity of the main structure pipe is complete, the engineering change
history records related documents such as marketing surveys, product changes, testing and workflow signatures for refer-
ence to product design and tracing. To complete product traceability, once a new part or product is manufactured, the
serial number of the main chassis needs to be changed to differentiate between old and new parts. Moreover, inclusion
of the new part or product creates a new version change and requires updates to supplier management. Finally, product
traceability needs to show that the old version part can no longer be used in the new product for service part manage-
ment.

4.4 Performance evaluation


For the four years preceding the implementation of an advanced CMII-based ECM framework Company M developed
an average of 24 new product development projects per year. This raised challenges integrating customer needs and
Downloaded by [Northeastern University] at 00:26 18 December 2014

product data such as PR timeliness between the design and manufacturing processes. However, since implementing the
proposed advanced framework with enterprise application integration (EAI) techniques to integrate various databases
and modules from PLM and ERP, the firm has resolved the above problems by integrating product data for the design
and manufacturing processes, thus significantly improving the ECM performance.
Performance indices can be divided into two categories based on the systems and information perspectives. Regard-
ing the systems’ perspective, those associated with the design dimension on the PLM side and those associated with
manufacturing dimension on the ERP side. Indices of the design dimension can be presented in terms of engineering
change frequency, change development cost and development time. Indices of the manufacturing dimension can be
shown by BQ costs (i.e. losses based on poor product quality), product change frequency and product change cost.
Regarding the information perspective, indices consist of product traceability time and timeliness based on frequency.
Table 1 summarises performance evaluation results before and after the implementation of the advanced CMII-based
ECM framework. Based on the systems’ perspective, all indices from the design dimension are decreased due to the
integration of PLM and ERP systems. For example, engineering change frequency was cut from 2880 to 1584 times
(a savings of 1296 times per year). Change development cost decreased from NT$88.3 million to NT$48.6 million
(an annual savings of NT$39.7 million) and the average of development time was decreased from 18 to 16 months
(a savings of two months) based on different scale of new product development projects. Moreover, all indices from the
manufacturing dimension are significantly decreased. For example, BQ cost was reduced from NT$8 million to NT$2
million (a saving of 6 million). Product change frequency was decreased from 408 times to 48 times per year (a savings
of 360 times) and product change cost was reduced from NT$ 12.5 million to NT$1.4 million, providing respective
annual savings of about NT$11.1 million. Based on the product data and information exchange between design and
manufacturing domains, product traceability time was sharply reduced from 1 week to 1 min and timeliness based on
frequency was substantially decreased from 5 days/time to 1 day/time due to the information integration automatically
between PLM and ERP systems.

5. Conclusions
Previous studies on ECM issues (e.g. Cheng, Chen, and Chang 2012; Nadia, Gregory, and Vince 2006), presented valu-
able results from the design domain of the PLM perspective. However, few studies proposed a framework under the
CMII standards for implementation in industrial contexts based on the design and manufacturing domains of the PLM
and ERP perspectives. This study proposes an advanced CMII-based ECM framework which was successfully imple-
mented in a large Taiwanese motorcycle manufacturer, resulting in significant performance improvement.
From an academic perspective, this study makes significant contributions in presenting an advanced CMII-based
ECM framework which integrates the PLM and ERP perspectives. Firstly, compared with previous ECM studies (e.g.
Cheung, Maropoulos, and Matthews 2010; Lee, Leem, and Hwang 2011; Tavčar and Duhovnik 2005), the results of this
study extend the scope from the design domain of PLM alone to integrate the manufacturing domain of ERP for ECM
research. Second, from the viewpoint of framework evaluation, past ECM studies (e.g. Shiau and Li 2007; Wu et al.
2012) only proposed a design configuration framework. Importantly, the present study not only proposes an advanced
CMII-based ECM framework that considers both the design and manufacturing domains, but also evaluates industrial
performance before and after framework implementation based on the integration of product data. Finally, from the
Downloaded by [Northeastern University] at 00:26 18 December 2014

6106

Table 1. Performance evaluation before/after implementing the advanced CMII-based ECM framework.

Change
Engineering development Development Product change Product change Product traceability
Item change frequency cost time BQ cost frequency cost time Timeliness

Before implementation 2880 timesa/year 88.3 Mb/year 18 Monthsc 8 Md/year 408 timese/year 12.5 Mf/Year 1 weekg/trace 5 daysh/time
(product data and
information non-
integration)
After implementation 1584 times/year 48.6 M/year 16 months 2 M/year 48 times/year 1.4 M/year 1 Min/trace 1 day/time
(product
data and information
integration)
Performance improvement 1296 times/year 39.7 M/year 2 months 6 M/year 360 times/year 11.1 M/year Nearly 1 week/trace 4 days/time
W.-H. Wu et al.

a
Engineering change frequency = number of new product development projects/year × number of engineering change/project.
b
Change development cost = engineering change frequency/per year × cost of every engineering change (Note: cost of every engineering change = number of participating person
for engineering change × working days × working hours/day × minutes/working hours × expenses (NT$)/minute); M: million NT$ (New Taiwan dollars).
c
The estimated value is from the internal data of Company M.
d
BQ cost = (Change development cost + product change cost) × BQ ratio (Note: BQ: loss based on poor product quality).
e
Product change frequency = number of new product development projects/year × number of product change/project.
f
Product change cost = product change frequency × cost of every engineering change.
g
The estimated value is from the internal data of Company M.
h
The estimated value is from the internal data of Company M.
International Journal of Production Research 6107

standpoint of the CMII standard, compared with past CM studies (i.e. Gagne and Fortin 2007; ICM 2004), this study
provides for information exchange and integration between the design and manufacturing activities based on five major
ECM phases and their associated processes. Hence, the results of this study can promote the adoption of the CMII stan-
dard to enhance process excellence and to develop the best guidelines for resolving ECM issues.
From a practical perspective, this study successfully applies the proposed advanced CMII-based ECM framework to
the motorcycle industry and then evaluates the before and after performance based on product data and information inte-
gration between the design and manufacturing domains. More importantly, we found that this integration with EAI tech-
nique not only decreases the cost of design and manufacturing (i.e. EC frequency and product traceability time), but
also resolves the interoperability between heterogeneous platforms and ensures the timeliness, consistency and accuracy
of product data exchange. The results and findings can provide valuable managerial insight into the design and manufac-
turing domains for the integration of PLM and ERP, thus helping to establish best practice guidelines for promoting
competitiveness in engineering design and manufacturing activities, and for guiding improved practice in manufacturing
industries with significant production volumes.
Regarding the future research, we suggest researchers can attempt to extend this advanced CMII-based ECM frame-
work to integrate with manufacturing execution systems (MES) that are used in real time to enable the control of multi-
ple elements during the production process (i.e. inputs, machines, personnel and support services) based on the design
Downloaded by [Northeastern University] at 00:26 18 December 2014

and manufacturing domains. Moreover, we suggest researchers can consider adding the supply chain management
(SCM) from the supply domain into this framework for facilitating the collaboration and integration processes with sup-
pliers. Finally, we suggest researchers can try to implement this framework in other industries for comparison analysis
and provide a best practice for generalisation.

References

Balaji, S., C. Ranganathan, and T. Coleman. 2011. “IT-led Process Reengineering: How Sloan Valve Redesigned Its New Product
Development Process.” MIS Quarterly Executive 10 (2): 81–92.
Cheung, W. M., P. G. Maropoulos, and P. C. Matthews. 2010. “Linking Design and Manufacturing Domains via Web-based and
Enterprise Integration Technologies.” International Journal of Computer Applications in Technology 37 (3/4): 182–197.
CIM Data Report. 2005. PLM and ERP Integration: Business Efficiency and Value. Ann Arbor, MI: CIM Data.
Cooper, R. G., and E. J. Kleinschmidt. 1995. “Benchmarking the Firm’s Critical Success Factors in New Product Development.”
Journal of Product Innovation Management 12 (5): 374–391.
Diprima, M. 1982. “Engineering Change Control and Implementation Considerations.” Production and Inventory Management 23 (1):
81–87.
Cheng, F. T., Y. L. Chen, and J. Y.-C. Chang. 2012. “Engineering Chain: A Novel Semiconductor Engineering Collaboration Model.”
IEEE Transactions on Semiconductor Manufacturing 25 (3): 394–407.
Gagne, S., and C. Fortin. 2007. “Application of the CMII Model to an Integrated Engineering and Manufacturing Development Envi-
ronment.” International Journal on Interactive Design and Manufacturing 1: 5–13.
Gattiker, T., and D. Goodhue. 2005. “What Happens after ERP Implementation: Understanding the Impact of Inter-dependence and
Differentiation on Plant Level Outcomes.” MIS Quarterly 29 (3): 559–585.
Grieves, M. 2006. Product Lifecycle Management: Driving the Next Generation of Lean Management. New York: McGraw Hill.
Guess, V. C. 2002. CMII for Business Process Infrastructure. Lancaster: Holly Publishing Company.
Huang, G. Q., and K. L. Mak. 1999. “Current Practices of Engineering Change Management in UK Manufacturing Industries.” Inter-
national Journal of Operations & Production Management 19 (1): 21–37.
Huang, G. Q., W. Y. Yee, and K. L. Mak. 2003. “Current Practice of Engineering Change Management in Hong Kong Manufacturing
Industries.” Journal of Materials Processing Technology 139: 481–487.
Huet, G., Clement Fortin, G. Mcsorley, and B. Toche. 2009. “Information Structures and Processes to Support Data Exchange
Between Product Development and Resource Planning Systems.” International Conference on Industrial Engineering and
Systems Management, Montreal, Canada.
ICM (Institute of Configuration Management). 2004. Configuration Management Plans – From Traditional CM to CMII (Rev B).
White Paper.
ICM (Institute of Configuration Management). 2012. CMII-100F: CMII Standard for Integrated Process Excellence and Configuration
Management. Phoenix, AZ: ICM.
Jarratt, T. A. W., C. M. Eckert, and N. H. M. Caldwell. 2011. “Engineering Change: An Overview and Perspective on the Literature.”
Research in Engineering Design 22: 103–124.
Kallinikos, J. 2004. “Deconstructing Information Packages: Organizational and Behavioural Implications of ERP Systems.” Informa-
tion Technology & People 17 (1): 8–30.
6108 W.-H. Wu et al.

Khedher, A. B., S. Henry, and A. Bouras. 2012. “Quality Improvement of Product Data Exchange Between Engineering and Produc-
tion through the Integration of Dedicated Information Systems.” The 11th Biennial Conference on Engineering Systems Design
and Analysis, Nantes, France.
Lee, Z., and J. Lee. 2000. “An ERP Implementation Case Study from a Knowledge Transfer Perspective.” Journal of Information
Technology 15 (4): 281–288.
Lee, C., C. S. Leem, and I. Hwang. 2011. “PDM and ERP Integration Methodology Using Digital Manufacturing to Support Global
Manufacturing.” The International Journal of Advanced Manufacturing Technology 53: 399–409.
Lilien, G. L., P. D. Morrison, K. Searls, M. Sonnack, and E. Hippel. 2002. “Performance Assessment of the Lead User Idea-genera-
tion Process for New Product Development.” Management Science 48 (8): 1042–1059.
Merminod, V., and F. Rowe. 2012. “How Does PLM Technology Support Knowledge Transfer and Translation in New Product
Development? Transparency and Boundary Spanners in an International Context.” Information and Organization 22: 295–322.
Nadia, B., G. Gregory, and T. Vince. 2006. “Engineering Change Request Management in a New Product Development Process.”
European Journal of Innovation Management 9: 5–19.
Paviot, T., V. Cheutet, and S. Lamouri. 2011. “A PLCS Framework for PDM/ERP Interoperability.” International Journal of Product
Lifecycle Management 5 (2–4): 295–313.
Petersen, K. J., R. B. Handfield, and G. L. Ragatz. 2005. “Supplier Integration into New Product Development: Coordinating Product,
Process and Supply Chain Design.” Journal of Operations Management 23 (3–4): 371–388.
Reddi, K. R., and Y. B. Moon. 2011a. “A Framework for Engineering Change Management in Enterprise Resource Planning Using
Downloaded by [Northeastern University] at 00:26 18 December 2014

Service-oriented Architecture.” International Journal of Business Information Systems 8 (1): 46–65.


Reddi, K. R., and Y. B. Moon. 2011b. “System Dynamics Modeling of Engineering Change Management in a Collaborative Environ-
ment.” The International Journal of Advanced Manufacturing Technology 55: 1225–1239.
Schuh, G., H. Rozwfeld, D. Assmus, and E. Zancul. 2008. “Process Oriented Framework to Support PLM Implementation.” Comput-
ers in Industry 59: 210–218.
Shiau, J. Y., and X. Li. 2007. “A Closed-loop Design Change Control Workflow in Product Data Management for Conceptual Design
Phase.” International Journal of Intelligent Control and Systems 12: 24–36.
Smith, R. P., and S. D. Eppinger. 1997. “Identifying Controlling Features of Engineering Design Iteration.” Management Science 43:
276–293.
Tavčar, J., and J. Duhovnik. 2005. “Engineering Change Management in Individual and Mass Production.” Robotics and Computer-
Integrated Manufacturing 21: 205–215.
Wright, I. C. 1997. “A Review of Research into Engineering Change Management: Implications for Product Design.” Design Studies
18: 33–42.
Wu, W. H., T. H. Lin, L. C. Fang, S. C. Yeh, and C. F. Ho. 2012. “A Novel CMII-based Engineering Change Management Frame-
work: An Example in Taiwan’s Motorcycle Industry.” IEEE Transactions on Engineering Management 59 (3): 494–505.
Yin, R. K. 2003. Case Study Research, Design and Methods. 3rd ed. Newbury Park, CA: Sage.
International Journal of Production Research 6109

Appendix 1. Glossary of acronyms

BOM Bill of material


BQ Loss based on bad product quality
CA-I Change administration-I
CA-II Change administration-II
CIB Change implementation board
CMII Configuration management II
CN Change notice
CR Change request
CR Change request
CRB Change review board
E-BOM Engineering bill of material
EC Engineering change
ECM Engineering change management
ECMS Engineering chain management system
ECN Engineering change notice
Downloaded by [Northeastern University] at 00:26 18 December 2014

ECR Engineering change request


ERP Enterprise resources planning
IC Integrated circuit
ICM The institute of configuration management
M-BOM Manufacturing bill of material
OBM Own branding and manufacturing
ODM Own designing and manufacturing
OEM Original equipment manufacturing
PLM Product lifecycle management
PR Problem report
QA-I Quality assurance administrator-I
QA-II Quality assurance administrator-II
QC Quality control

View publication stats

You might also like