Available online at www.sciencedirect.

com

ScienceDirect
Procedia CIRP 63 (2017) 342 – 347

The 50th CIRP Conference on Manufacturing Systems

Enabling agility in product development through an adaptive engineering

change management
Günther Schuha, Thomas Gartzena, Samuel Soucy-Bouchardb, Felix Bassea,*
a
Laboratory for Machine Tools and Production Engineering (WZL) of RWTH Aachen University, Steinbachstraße 19, 52074 Aachen, Germany
b
Université de Sherbrooke, 2500 Boulevard de l’Université, Sherbrooke, QC J1K 2R1, Canada
* Corresponding author. Tel.: +49-241-8028674; fax: +49-241-8022293. E-mail address: F.Basse@wzl.rwth-aachen.de

Abstract

Agile development processes have recently regularly been named as key to the development of novel physical products. Coming from the software
industry, these processes pursue the target of limiting both time-to-market and resources associated with the realisation of innovative products.
In the case of physical products, agile development in the form of highly iterative prototyping is furthermore employed for assuring a stable ramp-
up phase. The goal of this paper is the creation of an adaptive engineering change management (ECM) for rapid engineering changes which are
identified as central enablers for the agile product development of physical products.
Due to a lack of in-depth studies in this field, an agile development project in a manufacturing company has been investigated. The findings of
the case study are based on action research. Challenges and requirements faced by the case company have been identified in workshops and
interviews. A broad study of closely related literature improved the understanding and helped in the generation of a framework for an adaptive
ECM.
The investigations led to an approach that employs a step-wise product development process with different stages of maturity. Hereby, the shift
of requirements in the course of the agile development project as observed in the case study is taken into account. The ECM is continuously
adapted along the different stages of maturity of the agile product development to cope with this shift of requirements. It is illustrated that the
adaptive ECM is reflected in three layers: responsive means of communication, a responsive design of engineering change processes and roles,
and consistent data structures. Examples for the specific design of these layers are presented.
The result of the work is thus a framework for an adaptive ECM that meets the specific requirements of agile product development for physical
products.

©©2017
2017TheTheAuthors. Published
Authors. by Elsevier
Published B.V. This
by Elsevier B.V.is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).
Peer-review under responsibility of the scientific committee of The 50th CIRP Conference on Manufacturing Systems.
Peer-review under responsibility of the scientific committee of The 50th CIRP Conference on Manufacturing Systems
Keywords: Agile development and ramp-up; Product development processes; Engineering change management

1. Introduction phased processes in the software industry. Agile development

The regular introduction of innovative products is a major
success factor for manufacturing companies in a market
characterised by shortening product life cycles and increasing
customer requirements [1,2]. This makes the ability of
manufacturing companies to develop products efficiently even
more central than before [3,4]. Performance measures of this
ability are above all a short time-to-market and a limited
amount of resources needed for the innovation process.
Since the Agile Manifesto was presented in 2001, agile
development processes, such as Scrum, have prevailed over
is a learning-oriented approach [5]. It is characterised by an
early and iterative realisation of fully-tested software
increments. This is carried out by small development teams that
are given a high degree of creative freedom [6]. Development
teams learn from testing and from customer feedback and
incorporate the knowledge obtained into the next iteration
cycles. The flexibility introduced through the agile processes
allows for an efficient reduction of market uncertainty (will the
product meet the customer’s needs?) and technical uncertainty
(will the product be able to meets its functional and design
specifications?) [7,8]. It has been reported that companies

2212-8271 © 2017 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).
Peer-review under responsibility of the scientific committee of The 50th CIRP Conference on Manufacturing Systems
doi:10.1016/j.procir.2017.03.106
 Günther Schuh et al. / Procedia CIRP 63 (2017) 342 – 347
using Scrum have seen a notable increase of success in their
product development through a limited time-to-market and
resources employed for the development process [9].
In hardware industry, traditional deterministic-normative
development processes are still widely used [10]. However,
these processes are frequently regarded as “heavyweight”: too
slow, too bureaucratic and too rigid [9,11,12,13]. In approaches
adapting the concept of agility to physical product development
the deliverable of an iteration loop has been interpreted as a
prototype [10, 14]. This establishes the notion of a highly
iterative prototyping process: an iterative learning and
information gathering process leading to a rapid reduction of
uncertainty.
In physical product development, the reduction of technical
uncertainty is of particularly high significance due to the series
ramp-up which follows the development phase [15]. Today,
after the product development, numerous defects on the
product side still occur resulting into an unstable series ramp-
up phase. The elimination of defects during the ramp-up phase
is time-consuming and costly as it has large technical
implications on the product and processes [16]. Consequently,
a systematic decrease of technical uncertainty to a sufficient
amount at an early stage before production ramp-up is
desirable. The highly iterative prototyping approach proves
suitable in this context as the continuous testing for problems
concerning the product (and process) steadily optimises the
product.
The shift from deterministic-normative development
processes to agile processes in the form of highly iterative
prototyping supports a notion that has emerged in the academic
community: change replaces ab-initio design as the
predominant paradigm [16,17]. Product changes resulting from
external sources (customer requirements) or internal sources
(product defects) should no longer be seen as ”necessary evil”
that must be avoided. Instead changes should be regarded as
opportunities to systematically improve the system design
before the ramp-up phase is reached. By means of engineering
change requests (ECR) a continuous learning process from an
early point on can be initiated. Through a fast feedback of
information (from external and internal sources) to the design
department, series product maturity for a stable ramp-up can be
rapidly achieved. Concerning internally triggered changes, an
enhanced capability of reactively dealing with a faulty product
on the shop floor is required. A close co-operation of
development and production departments in an interdependent
engineering environment is indispensable for this.
Consequently, agile processes supported through efficient an
ECM have the potential to lead to a reduced time-to-market and
to a more stable and thus shortened ramp-up phase.
After having introduced the importance of an efficient ECM
for agile product development in chapter 1, chapter 2 illustrates
difficulties connected to the implementation of engineering
changes. In the following chapter, the methodology pursued in
the research study is pointed out before chapter 4 gives insights
about the findings and suggests a framework for an adaptive
ECM. Chapter 5 gives detailed examples of the design of the
framework. Lastly, the findings of the paper are concluded in
chapter 6.
343
2. Problematisation
Analogous to the findings of a previous paper stating that
knowledge management has a significant positive effect on the
ramp-up phase itself [18], the present paper claims that the
access to implicit knowledge and experience from the shop
floor staff is also an accelerator of the product optimisation
during the highly iterative prototyping phase. In this context,
not only a fast data transfer from engineering to manufacturing,
but also a timely information feedback to the design department
via ECRs from the shop floor staff is a key capability.
Problems within the interaction process of design and
production departments have recently been investigated by
Fraunhofer IAO. Here, it is illustrated that companies which
are required to react flexibly to changes already today, assess
the coordination effort between the development and
production departments as high [19]. It seems that strategies
and approaches in use do not provide a comprehensive,
effective and sustainable solution for an efficient change
management. This is in conflict with the interdependent
engineering environment requested earlier limiting
organisational learning and thus the efficiency of actors and the
responsiveness of the organisation [20].
The presentation of the problem situation leads to the
following research question: how must the engineering change
management in an agile development project be designed to
allow for an efficient interaction between development and
production department for a rapid product optimisation?
3. Methodology
As a research approach the paper follows a qualitative
research process as an interplay between theory and empiricism
[21]. The examination of current literature through a broad
study of papers has formed the basis of the paper. The
knowledge acquired through the literature study has been
compared with observations based on an in-depth case study in
a manufacturing company.
The case study was launched in May 2016 and is ongoing.
The case company is a start-up in the field of electromobility.
It develops fully electric vehicles and employs an agile
development process in the form of highly iterative prototyping
to prepare for series ramp-up. The engineering change process
currently employed is supposed to be improved for this.
Methods of the case study have included process
observations as well as semi-structured interviews and
workshops with stakeholders involved, namely members of
both design and production teams. The research work follows
an action research approach as it aims at solving the particular
problem of inefficient engineering changes and develops a
framework for improvement [22]. For this, an analysis of the
current challenges in the co-operation of design and production
within the company’s prototyping phase is conducted. The
development of a suitable framework as intended in this paper
is supposed to underlie an improvement of the company’s
ability to carry out efficient engineering changes. The
implementation of first elements of the framework within the
company is taken as a basis for a proof of concept.
344 Günther Schuh et al. / Procedia CIRP 63 (2017) 342 – 347
4. Findings and Discussion
The aim of this paper is the development of a framework for
an efficient ECM (chapter 4.3) which has been identified as the
central enabler of an agile development of physical products.
This framework must take into account both the challenges in
the field of ECM (chapter 4.1) and the requirements of the
dynamic prototyping processes as investigated in the case study
(chapter 4.2).
4.1. Categorisation of challenges
Together with an in-depth literature study, the investigations
in the case company have led to a better understanding of the
challenges mentioned briefly in chapter 2. The observations
resulted in a categorisation that complements existing
segmentation approaches in the field of ECM found in
literature [16,17,23]. This research work proposes that the
challenges can be divided into three categories: means of
communication, processes and roles and data structure. The
problems found within these categories are considered as the
main obstacles for a fast and high-quality information transfer
between the design and production departments impeding
organisational learning from existing knowledge for the
structural increase of the product maturity.
x Means of communication
Today’s conventional information feedback from the shop
floor to the design department is characterised by contents that
are frequently incomplete, misleading and incomprehensible.
This is due to communication barriers between the problem
identifying shop floor staff and the problem solvers in the
design department [24]. Barriers have been identified as
especially pronounced during the dynamic phase of the highly
iterative prototyping. Reasons for this are among others:
Poor accessibility of content-related data. Basic metadata
for contextualising a product failure identified on the shop floor
are e.g. part no. and name. During the prototyping phase, these
data are often not accessible to production staff as standard
documentation such as paper-based drawings, work-plans or
bills of material (BOM) are either missing or incomplete due to
the avoidance of the effort associated with their creation.
Absence of standards and little systemic support.
Conventional documentation tools used on the shop floor today
are mostly still of analogue, manual nature. High
administrative effort and poor operability concerning
conventional documentation tools are the consequence: In the
case company, when a product specific problem arises it is
usually noted down on the drawing (if available). This way of
transferring information is highly unstructured and handwriting
has frequently been unreadable making avoidable loops
between the staff in the course of the observation in the case
study necessary. Furthermore, a lot of effort is currently
connected to the translation of information from the shop floor
into digital formats as there is little systemic support when
transferring hand-written notes into IT-Systems. An often used
alternative to this in series production are more systematic pre-
structured forms. However, their acceptance within the staff
has been identified as low during the prototyping because of
the extremely high time pressure of this phase and the often
elevated administrative effort connected to their completion.
For both alternatives banal problems such as the disappearance
of paper-based drawings and forms are frequently observed.
Unfamiliar scope of duties of shop floor staff. The work
content of production staff is developing more and more from
routine tasks to regulative and steering tasks. This implies
higher requirements concerning capabilities in the field of
problem solving, communication and self organisation [19].
Moreover, during the highly iterative prototyping problems
identification cannot be automated like in series production.
This is especially the case for assembly tasks. Consequently,
the entire system is more dependent on the human-being and
its expert knowledge. In practice, workers have partly been
overstrained with this increase of responsibility.
x Processes and roles
Organisational speed is decisive for the efficient handling of
unforeseen events [25]. However, organisational structures and
workflows are often not adapted to the requirements of the
specific phase. This interacts with a lack of transparency as
presented in the following section.
Missing or too rigid and inefficient processes. Process
design is one major challenge for early phases when
departments collaborate for the first time. This is also the case
for dynamic prototyping: Either clear workflows to
communicate problems are absent or they are too formal and
bureaucratic [15]. The former case is true for the observation
within the case company where there is a lack of guidelines for
efficient process flows. A lack of transparency about statuses
further compounds the situation.
Numerous organisational interfaces, unclear roles and
responsibilities. In the case company, it has been observed that
on the one hand organisational structures are too hierarchic for
fast decision making and on the other hand, process owners are
often not clearly defined. This is in line with observations in
literature [19]. In combination with unrefined processes this
leads to an ad-hoc way of problem solving and
misunderstandings. Moreover, decisions are often delayed.
x Data structure
Initiating change creates data, which are the source of the
following processes. Both an efficient downstream data flow
and the fast feedback of these data back to the engineering
department are significant aspects for shortening the product
development time and for planning capacities [25]. A major
source of long delays and resulting cost increases is an
insufficient data management. Engineering mostly looks at
computer-aided design (CAD) and structure information etc.
while manufacturing uses separate expert systems for
operations, e.g. for manufacturing planning. This leads to
disconnected teams, complicating data exchange, as described
below:
 Günther Schuh et al. / Procedia CIRP 63 (2017) 342 – 347
Stage 1
Dimension Mockups/Prototypes
Production volume single products
Degree of agility highly iterative/agile
Machine utilisation manual prototyping
Process plans partly existing
Work instructions partly existing
Division of work partly existing
Tool use simple tooling
Conformity to standards simple valididation
Documentation hardly any documentation effort
Bill of material low level of detail
Product maturity low
Fig. 1. Shift of requirements along the different stages of maturity during development
Lack of high quality digitalised geometric data. Many
non-conformances in the case company are due to the manual
data exchange from engineering to manufacturing and vice
versa. The media disruption in form of 2D drawings that are
derived from the original 3D model results in inaccuracies (e.g.
rounding of values) and interpretation errors when drawings
are created or used for manufacturing.
Intransparent and inconsistent data management. Due
to different perspectives of the company divisions, various data
management applications, such as product lifecycle
management (PLM) and enterprise-resource planning (ERP)
systems have been established. Comparing and transferring
data from one system to another is necessary but highly time
consuming and an error-prone process. Thus, the engineering
change process leads to inconsistencies and intransparency of
data states in the data management systems. Information
deficiencies of different development teams and decisions
about the product without up-to-date data are the result [26, 27,
16]. The lack of consistent documentation is a frequently
associated problem of ECM [16].
4.2. Typology and requirements of the product development
process
A central result of the case study’s investigations is the
characterisation of the requirements of the highly iterative
prototyping process. The observations resulted in the
identification of an overall process that can be roughly divided
into three distinct stages of maturity. The intent is to start the
product development within a highly agile stage. This new
agile approach for physical product development progressively
becomes more restrictive and controlled in order to ultimately
deliver a fully documented product ready for series ramp-up
and certifications.
Stage 1. The product development is considered to start
from scratch. This stage needs to be suitable for radical
innovation, which is subject to great uncertainty. It is intended
to be the most agile of the three stages with a lot of freedom for
the designers and the production staff. This stage offers a
highly flexible work environment to allow the teams to be fast
performing their iterations. This also implies that only
rudimentary production planning is conducted for the early
mockups and prototypes. The documentation is intended to be
345
Stage 2 Stage 3
Functional products Preseries/Series
single products to small series small series to series
(highly) iterative/agile iterative/agile - rigid
semi-auto. small series production automated series production
coarse-grained detailed
coarse-grained detailed
partly defined fully defined
simple and pre-series tooling pre-series and series tooling
higher conformity to standards full standard compliance
individual authorisation objects large amount of documentation
medium level of detail fully defined
medium high
absent or minimal, according to the product maturity, which is
still low at this stage. As for the Scrum method from software,
a working product is preferred to comprehensive
documentation, that is time consuming to create and maintain,
as prototypes change quickly in their design. The output of this
maturity stage is simulations, mockups and functional
subsystem prototypes.
Stage 2. The second stage is a transitional phase between
the highly agile stage 1 and the more rigid stage 3. It is needed
to include an integration stage that is still fundamentally agile.
As soon as most of the functions are intended to be put together,
the product should enter this stage of maturity. In the first loops
of this stage, it is intended to validate the interaction of the
subsystems together and their interfaces. Progressively, it is
necessary to start using transitional manufacturing processes
and optimise the BOM. The output of the stage 2 are functional
products that are ready to go into pre-series production in
stage 3.
Stage 3. Both product and processes need to be pre-set for
high volume production. The design is made in order to meet
the certifications requirements, a detailed documentation is
required and the change management needs to be highly
controlled. In this stage intended for the preparation of
production and series ramp-up, the amount of changes
decreases. They are now however more complex and time
consuming as more implications on manufacturing and
documentation are the consequence. The output of stage 3 is a
shippable product that is realised by means of processes
intended for high volume series production and the
corresponding materials.
As described above, the typology of the development
process is changing over time with increasing product maturity.
The three stages of maturity and the associated shift of
requirements are defined accurately using eleven dimensions
found to evolve over time from stage to stage. These are
presented in figure 1.
4.3. Development of a framework for an adaptive ECM
The aim of this paper is to define a framework for the
development of an efficient ECM within an agile environment.
For this purpose, the findings previously described in the paper
346 Günther Schuh et al. / Procedia CIRP 63 (2017) 342 – 347
Stage
Stag
ge 1
ge
Dimension Mockups/Prototypes
Mo
oc
oc
ockups /P
Pr
Pr
Prototyp
pe
es
es
production volume single products
Design element/layer
Means of !
communication
Processes and
roles
Data structure
Adaptive Engineering Change Management
Fig. 2. Layout of the ECM framework composed of three design elements/layers (acc. to chap. 4.1) and taking into account the shift of requirements (see Fig. 1)
are taken into account and are used as basic elements for the
creation of the framework concept.
The challenges within the field of engineering change
(chapter 4.1) are addressed through the underlying structure of
the framework. The engineering change concept must be
suitably designed along all categories to avoid the problems
described before. Hence, the three categories are proposed as
design elements and are described hereinafter as layers:
Adequate means of communication form the front-end of the
framework, processes and roles the intermediate layer and a
suitable data structure the back-end. For a suitable design of the
means of communication content-related data must be
accessible at any time, standards for documentation must be
provided and shop floor staff must be supported in
communication processes. For processes to be efficient, they
have to be customised accordingly and a clear scope of duties
must be assigned to members of the organisation. In order to
guarantee for an error-free data management, geometric data
have to be digitalised and application systems must share
common data structures.
The shift of requirements along the three stages of maturity
(chapter 4.2) is the second determining factor of the
framework. The design of the three layers of the ECM
framework must be adaptive in order to respond to the different
changing requirements. The overall approach is outlined in
figure 2.
5. Application of the framework
This chapter suggests a specific design of the framework for
an adaptive ECM (see Fig. 3). The elements are partly already
being piloted in the company, partly they are still in a concept
phase.
For any stage of the process CAD and PLM data from the
design department are made available through the use of
mobile devices with complying access rights to the application
systems. Furthermore, based on model-based definition (MBD)
specifications are defined in the design department and added
to the CAD e.g. in form of geometric dimensions and
tolerances. Product information normally provided through 2D
drawings is digitally provided in high quality to the shop floor
through this method. For the early stage of the highly iterative
process, informal and semi-formal feedback is seen as
appropriate as it is in line with the reduced need for
documentation and the highly agile process. A designer
continually accompanies the production workers directly
integrating their feedback into his work. At later stages, more
Stage 2 Stage 3
Functional
Fun
nctional products
p od
products
ducts Preseries/Series
single products to small series small series to series
systemic support is provided for triggering an official ECR.
Here, a user-friendly app is utilised to directly integrate
remarks into the workspace of the designers inside the PLM
system, triggering an official EC process. All necessary
information can be accessed through a direct link to the PLM
system of the company. Photos and descriptions are added and
additional remarks can be captured inside the CAD-model
using the model-based method. While the workers are
supported by the designer in the early stage, the simple app
interface gives assistance in the later stages.
Along the middle layer, processes and roles have been
determined according to the specific need for information
inside the organisation. During the early stage, a product
change entails far less implications on other departments. For
manufacturing there is little relevant information at this stage
as e.g. work instructions and process plans are only
rudimentary. This also limits the number of process steps and
persons involved. Approaching the series ramp-up, more
departments need to be involved and additional quality insuring
steps are needed: Work flows for releasing an engineering
change now also have to take into consideration tool making,
standards that have to be met and the effort of documenting
changes connected to these elements.
Concerning the back-end an adequate data structure must be
designed in order to handle the increasing need for information
along the stages. As mentioned above, MBD is a central enabler
of high quality digital information that is centrally located
around the engineering bill of material (eBOM) in a product-
oriented data model. With increasing maturity of the product
and the process, transactional aspects of producing the product
in higher quantities have to be considered. Transactional
systems, such as ERP systems gain in importance. Here, an
eBOM is translated into an execution-oriented view of the
manufacturing BOM (mBOM). Moreover, process plans and
resources, work instructions and target times become relevant.
With an ERP system implemented, the overall data structure
must guarantee for a consistent data management between the
systems. Equivalence links between the objects of the eBOM,
mBOM and process plans have to be determined to ensure this.
So, coming from the product structure (eBOM), impacts from
an ECR can be identified up to the resources required and vice
versa.
6. Conclusion
The article at hand argues that agile product development in
the form of highly prototyping is promising for limiting the
 Günther Schuh et al. / Procedia CIRP 63 (2017) 342 – 347 347

Stage 1 Stage 2 Stage 3

Mockups/Prototypes Functional products Preseries/Series

Means of
Create new ECR Complete description
communication
1 2 3
!

#ECR @bsf 20/10/16

opening too narrow Photo documentation

Processes and
Design Production (Shopfloor)
roles

Data structure eBOM eBOM mBOM Process Plan Work instructions

Model-based definition Body Body
Body
Op 10 Process times
Front-End Front-End Assy #1

Part 1 Bumper Sub Assy #1

Op 20
63,5

Part 2 Frame-Front 02_... Resources

01_... Op 30 Tools
Part 3 03_...
12,5

Center 02_... Sub Assy #2

Op 40
Back-End 03_... 01_...

Fig. 3. Detailed design of the framework for an adaptive ECM

time-to market and resources used for development projects.
Moreover, it is suggested to lead to a stable ramp-up phase
through a rapid and continuous increase of product maturity.
An efficient ECM is presented as the key enabler for this
development method. Challenges within the field of ECM have
been identified through a case study and a broad literature
research and are divided into three categories: means of
communication, processes and roles, and data structure.
Considering these challenges and the changing typology of the
development and ramp-up phase investigated within the case
study, a framework of an adaptive ECM is presented. Based on
the challenges, a three-layer-model with a responsive design is
developed taking into account the characteristics of the
different stages defined in the case study. Examples for the
specific design of the three-layer-model are presented in detail.
Acknowledgements
The research work presented has been examined within the
publicly funded (German Research Foundation, DFG)
university graduate training programme “Interdisciplinary
Ramp-Up” (Graduiertenkolleg Anlaufmanagement).
References
[1] McDermott CM, O'Connor GC. Managing radical innovation: an overview
of emergent strategy issues. J Prod Innov Mgmt 2002;19:424-438.
[2] O'Connor GC, Rice MP. Opportunity Recognition and Breakthrough
Innovation in Large Established Firms. Calif Mgmt Rev 2001;43: 95-116.
[3] Ameri F, Dutta, D. Product lifecycle management: closing the knowledge
loops. Computer Aided Design and Applications 2005;2: 577-590.
[4] Durmusoglu SS. The role of top management team’s information
technology (IT) infrastructure view on new product development:
conceptualizing IT infrastructure capability as a mediator. Europ J Innov.
Mgmt 2009;12: 364-385.
[5] Herstatt C, Verworn B. Management der frühen Innovationsphase.
Wiesbaden: Gabler; 2007.
[6] Sutherland J. The Scrum Handbook. Cambridge: Scrum Inc.; 2013.
[7] Unger D, Eppinger S. Improving product development process design: a
method for managing information flows, risks, and iterations. J
Engineering Design 2010;22:689-699.
[8] De Meyer A, Loch C, Pich M. Managing project uncertainty: from variation
to chaos. MIT Sloan Management Review 2002;43:60-67.
[9] Cooper RG. What´s next? After Stage-Gate. Research-Technology
Management 2014;57:20-31.
[10] Schuh G, Gartzen T, Basse F, Schrey E. Enabling radical innovation
through highly iterative product expedition in ramp up and demonstration
factories. PROCEDIA CIRP 2016;41:620-625.
[11] Smith PG. Change: Embrace it, don´t deny it. Research-Technology
Management 2008;51:34-40.
[12] Becker B. Re-Thinking the stage-gate process - a reply to the critics.
Management Roundtable Inc, Waltham; 2006.
[13] Lenfle S, Loch C. Lost Roots: How Project Management Came to
Emphasize Control over Flexibility and Novelty. Calif Mgmt Rev
2010;53:32-55.
[14] Gartzen T, Reuter C, Bambring F, Basse F. Target-oriented prototyping in
highly iterative product development. PROCEDIA CIRP 2016;51:19-23.
[15] Leino SP, Jokinen L, Anttila JP, Pulkkinen A. Case Study on Engineering
Change Management and Digital Manufacturing. Springer; 2016.
[16] Jarratt TAW, Eckert CM, Laldwell NHM, Clarkson PJ. Engineering
change: an overview and perspective on the literature. Research in Eng
Design 2011;22:103-124.
[17] Hamraz B, Caldwell NHM, Clarkson PJ. A Holistic Categorization
Framework for Literature on Engineering Change Management. Systems
Engineering 2013;16:473-505.
[18] Bußwolder P, Basse F. An Empirical Study on the Effect of Knowledge
Management on Ramp up Performance in the SME Sector. In: Proceed of
the 17th Europ Conf on Knowledge Mgmt. North Ireland. 2016. p. 118-127.
[19] Spath D, Pokorni B, Ganschar O, Schlund S. Intelligenter
Störungsassistent im Serienanlauf als Industrie 4.0-Anwendungsfall HAB-
Tagungsband; 2014. p. 343-371
[20] Rivere A, Féru F, Tollenaere M. Controlling Product Related Engineering
Changes in the Aircraft Industry. Proceedings of ICED 03; 2003.
[21] Kubicek H. Heuristische Bezugsrahmen und heuristisch angelegte
Forschungsdesigns als Elemente einer Konstruktionsstrategie empirischer
Forschung. In: Köhler R, editor. Empirische und handlungstheoretische
Forschungskonzeptionen. Stuttgart: Poeschel Verlag; 1977. p. 3-36.
[22] Denscombe M. The good research guide: For small-scale social research
projects. 4th ed. Berkshire: Open University Press; 2010.
[23] Ahmad N, Wynn DC, Clarkson J. Information Models Used to Manage
Engineering Change: A Review of the Literature 2005 – 2010. Int Conf on
Eng Design, ICED11. Technical University of Denmark; 2011.
[24] Meyer G, Knüppel K, Möhwald H, Nyhuis P. Kompetenzorientiertes
Störgrößenmanagement. Productivity Mgmt 2014;1:15-18.
[25] Spath D, Ganschar O, Gerlach S, Hämmerle M, Krause T, Schlund S.
Produktionsarbeit der Zukunft – Industrie 4.0. In: Spath D, editor. Stuttgart:
Fraunhofer Verlag 2013. p. 50-56.
[26] Fricke E, Gebhard B, Negele H, Igenbergs E. Coping with changes:
causes, findings and strategies. Systems Eng 200;4:169-179.
[27] Rouibah K, Caskey KR. Change management in concurrent
engineering from a parameter perspective. Comp In Ind 2003;50:15-34