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

net/publication/379732247

From Engineering Change to Enterprise Change Management: An empirical

study on CM2 processes in the automotive industry

Article in Procedia CIRP · June 2024

DOI: 10.1016/j.procir.2024.01.090

CITATIONS READS

0 103

3 authors, including:

Tim Gruchmann
Fachhochschule Westküste
50 PUBLICATIONS 766 CITATIONS

SEE PROFILE

All content following this page was uploaded by Tim Gruchmann on 07 May 2024.

The user has requested enhancement of the downloaded file.

 Available online at www.sciencedirect.com

ScienceDirect
Procedia CIRP 122 (2024) 629–634

31st CIRP Conference on Life Cycle Engineering (LCE 2024)

From Engineering Change to Enterprise Change Management: An empirical

study on CM2 processes in the automotive industry
Raphaela Gangl a, Thomas Gollmann b, Tim Gruchmann c
a Westcoast University of Applied Sciences, Heide, Germany
b LMtec Benelux B.V., Amsterdam, Netherlands
c Westcoast University of Applied Sciences, Heide, Germany

* E-mail address: gruchmann@fh-westkueste.de

Abstract
Companies need to respond to changing market requirements with product and process improvements. In order to better meet the needs of
consumers, technical changes must be made within the product lifecycle of products. This can, for example, change the product’s shape, fit
or function. Engineering Change Management (ECM) processes are an elementary part of Product Lifecycle Management (PLM) and support
handling these changes. ECM ensures that changes are assessed, communicated, coordinated, and implemented in time. The present research is
based on a case study in an automotive company analysing the way of working within current ECM implementations against the CM2 framework
proposed by Wu et al. [1]. Based on the comparison of qualitative interviews and company documents, the analysis shows deviations in the
ECM process, especially regarding the implementation of changes in the plants. We suggest expanding the ECM process framework towards
an Enterprise Change Management, including master data change in the IT systems and involving all relevant departments to implement the
change successfully in the plant(s). Thus, we propose expanding the existing CM2 framework to inform ECM middle-range theory. In addition,
recommendations for a successful ECM implementation are deduced from the comparison.
© 2024 The Authors. Published by Elsevier B.V.
This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0)
Peer-review under responsibility of the scientific committee of the 31st CIRP Conference on Life Cycle Engineering (LCE 2024)
Keywords: Engineering Change Management; CM2 standard; Automotive industry; Product Lifecycle Management; Manufacturing Management.

1. Introduction The Engineering Change Management (ECM) process, as a

To remain competitive, companies must respond to chang-
ing market requirements [2]. To better meet the needs of con-
sumers, it is necessary to carry out technical changes [3]. Tech-
nical or Engineering Changes significantly impact the product’s
lifecycle and can be triggered at any stage of the product lifecy-
cle. A technical change includes modifying the product’s form,
fit, or function [4]. According to Jarratt [4], an engineering
change is defined as “changes to parts, drawings or software
that have already been released during the product design pro-
cess, regardless of the scale of the change”. Technical product
changes arise due to several reasons. They either come from in-
ternal requests (more cost-effective and accelerated production
processes) or are initiated externally, for example, by customer
requests for shortened lead times, reduced costs over the entire
product life cycle, or the assurance of product liability and qual-
ity [4]. In addition, technical changes can also be caused by raw
material shortages.
subset of the Product Lifecycle Management process, supports
handling technical changes [5]. ECM refers to the organisa-
tion and control of product changes within the product lifecycle
and ensures that changes are communicated, coordinated, and
implemented in time [4]. To implement changes successfully,
different IT systems ensure consistent data regarding product
changes and make historical changes traceable [7]. In this vein,
the Configuration Management 2 (CM2) model, which can be
used as a conceptual guide for building a standardised ECM
framework, expands the scope of general Change Management
(CM) to include “any information that may have an impact on
safety, health, quality, scheduling, cost, profit, the environment,
corporate reputation or brand perception,” such that it can be
used across organisations [8]. The CM2 model ensures that the
correct information is delivered to the right people in the right
place and time to make the right decisions. In addition, Wu et
al. [1] already proposed a standardised CM2 process that can
guide practical implementations. Within this research, the CM2

2212-8271 © 2024 The Authors. Published by Elsevier B.V.

This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0)
Peer-review under responsibility of the scientific committee of the 31st CIRP Conference on Life Cycle Engineering (LCE 2024)
10.1016/j.procir.2024.01.090
630 Raphaela Gangl et al. / Procedia CIRP 122 (2024) 629–634
model, according to Wu et al. [1], is used as a reference for
comparison.
Building on the practical importance of the CM2 standard,
the present study conducted a single case study on how the CM2
standard is implemented in practice and whether the standard
covers all relevant practices. The selected case company op-
erates in the automotive industry and has an established ECM
process according to the CM2 standard. Based on qualitative
data through expert interviews and collected company docu-
ments, the ECM process and the related IT landscape are ex-
plored and compared against CM2. The findings of the anal-
ysis confirm that the implemented process broadly covers the
CM2 processes. However, there are major gaps regarding the
change implementation. We accordingly propose an extended
CM2 model covering the insufficiently illuminated processes
of change implementation, contributing to extend ECM middle-
range theory. The remainder is structured as follows: Section 2
describes the practical background, particularly the ECM pro-
cess according to CM2. Section 3 gives an overview of the em-
pirical investigation. The results of the interviews are presented
in Section 4 and Section 5. Section 6 discusses and concludes
the study.
2. Practical background
The Institute of Configuration Management emphasised the
necessity of a standardised ECM framework and devised the
Configuration Management II (CM2) model to achieve stan-
dardisation and efficiency in ECM practices [9]. The CM2 stan-
dard process consists of three main components: the Problem
Report, the Change Request, and the Change Notice [1] (see
Fig. 1, left-upper area). First, a Problem Report (PR) must be
submitted. The PR describes the problem and requirements and
proposes a change. Once the PR has been created, it is sent to
the Change Administration-I (CA-I, Business or Quality Ad-
ministrator). The PR is checked and then either approved or
rejected. The PRs are collected in a Change Request (CR).
The CR can be created based on the PR according to the
customer’s requirements or internal decisions (e.g., technology
improvement or a designer’s decision). The CR is created by the
CA-I, who is also responsible for the technical review, includ-
ing an impact analysis and the associated report. The Change
Review Board (CRB) then decides whether the change should
be completed or accelerated. A distinction is made between
Full-Track and Fast-Track procedures. The Full-Track proce-
dure is suitable for significant changes that cause time losses
and high costs. In contrast, the Fast-Track procedure suits minor
changes that can be implemented cheaply. During the review
and confirmation of CRs, Change Notices (CN) are created by
the Change Administration-II (CA-II, Design Administrator).
The CA-II creates CNs and implementation plans. The plans
are a renewal of parts drawings, a parts change plan, a produc-
tion change plan, or a prototype testing plan; this depends on
whether the CR is classified as Full-Track or Fast-Track. Fast-
track engineering changes bypass the CRB and Change Imple-
mentation Board (CIB) and are sent directly to CA-II for im-
plementation [1]. The Full-Track includes testing the impact of
the change. Then, the CA-II is tasked with preparing the CN to
document the necessary measures of the implementation plan.
Before implementing a CN, the CIB must review and approve.
The product structure, model, and documentation are up-
dated after the CN and implementation plan are approved. Sub-
sequently, the creator edits the product data according to the
tasks in the CN. Afterwards, users check and approve the cre-
ator’s work before completing the technical change. Once all
tasks are completed, Change Administrator-III (CA-III, Qual-
ity Administrator) checks the result. It must be clear, concise,
and valid before it is released. Depending on the determination
by the CA-III, the CN is approved or rejected. If the CN is ap-
proved, it is released, and the PR and CR are resolved [1].
3. Research design
3.1. Data collection
The case company is a globally operating automotive tier-
1 supplier undergoing digitalisation projects since 2017 and is,
therefore, very well suited for the research purpose. The com-
pany develops and produces tailor-made products for the dif-
ferent OEMs (Original Equipment Manufacturers). In doing so,
the company is constantly confronted with change requests. The
focus of this research is on the end-to-end ECM process, in-
cluding different departments and IT systems involved in the
process. We focused on the departments: Sales (Change Man-
agement), Technics (Engineering Bill of Materials (EBOM) and
Manufacturing Bill of Materials (MBOM) Management) and
Operations (Bill of Processes (BOP) Management and Change
Coordination). Five interviews were conducted as expert inter-
views and recorded (see Tab. 1).
Table 1. Interviewees.
Interview Role Duration
Interview 1 (I1) Change Management 00:54:10
Interview 2 (I2) EBOM Management 01:06:05
Interview 3 (I3) MBOM Management 01:09:36
Interview 4 (I4) BOP Management 00:54:36
Interview 5 (I5) Change Coordination 01:20:21
Total duration 05:24:48
3.2. Data analysis
After the interviews were conducted, they were en-
tirely transcribed with the help of the transcription software
‘f4transkript’. Next, coding was carried out in a deductive man-
ner in Excel [10]. The interview analysis aimed to understand
individual process steps better, so the coding was limited to the
main dimensions: Supplier, Input, Process, Output, Customer,
and Software. To validate the findings, triangulations with ex-
isting company documents were performed. Accordingly, dif-
ferent sources were analysed and compared to assess how con-
sistent the statements in the individual interviews were [10].
 Raphaela Gangl et al. / Procedia CIRP 122 (2024) 629–634
4. Interview findings
4.1. Change Management (CM)
The CM has cross-departmental responsibility over the en-
tire ECM process, from the created ECR within the PLM sys-
tem to the closed Manufacturing Change Order (MCO) within
the ERP system (I2, para. 187) and is the support of the
Main Project Manager (HPL). The CM documents the deci-
sions made by the HPL in the system, approves the Engineering
Change Requests (ECR), and prepares the Engineering Change
Order (ECO). Anyone from the project can create an ECR (I1,
para. 87). The created ECRs are sent to the CM (I1, para. 93).
They are checked for correctness and completeness before the
CM meetings (I1, para. 97, para. 101, 141, I1, para. 47). The
ECR is created and managed within Teamcenter (TC, PLM sys-
tem). After reviewing all relevant documents, a checked and
complete ECR, a completed PFD (Product Flow Diagram =
formula with all relevant information for BOM and BOP), and
a change presentation are available. With this information, the
ECR can be started and evaluated by the other departments (I4,
para. 167), like logistics, purchasing, and production, which as-
sess or estimate the costs and efforts. After the evaluation, the
budget, the delivery date, the status of the plant, and the imple-
mentation date are known. When the HPL decides that the ECR
is reasonable, the CM can set it on status order (I1, para. 189)
and send an offer to the customer. The customer finally decides
whether to pursue the change (I2, para. 191). If the change is
accepted, the ECO can be created (I3, para. 57). Here, an MCO
is generated in SAP for the first time. Parallel, all needed de-
partments (EBOM, MBOM and BOP) execute their tasks (I1,
para. 197). The assignment of tasks is done automatically via a
workflow in TC started by the CM.
When the CM has checked and tracked all relevant informa-
tion and the ECO has been approved, the ECO is automatically
transferred again from TC to SAP, and the MCO is updated (sta-
tus 25). With the MCO, the implementation date is also trans-
ferred to SAP, which is responsible for the validity of the master
data (MBOM and BOP). Only the CM can change the imple-
mentation date in SAP (I1, para. 225, 239). After updating the
MCO, the CM hands over to the Change Coordination (CC) in
the plant(s). For a change implemented in different plants, dif-
ferent CCs are responsible. The MCO is closed (status 50) after
feedback from the CC (I1, para. 255); the status is set manually
by the CM.
4.2. EBOM Management
The goal of EBOM Management is to implement the EBOM
and the CAD data set in the ECM (I2, para. 49). The EBOM
Management can start the ECM process by creating an ECR
if the change directly influences the geometry of the product
(I2, para. 145, 151, 171, I2, para. 175, 181), and informs the
CM that a new change has been created (I2, para. 187). The
constructor designs with the CATIA and NX systems and then
saves the data in TC (I2, para. 103)—the correct CAD data set
has been stored in EBOM.
631
The EBOM Management is also responsible for releasing
the EBOM (I2, para. 217, 219). It starts the release and sends it
to the respective architect. The architect checks the information,
and either approves or rejects the release (I2, para. 195). The
approval runs through a four-eye workflow (I2, para. 197). In
the case of a geometric product change, the released EBOM is
sent to the supplier or tool manufacturer so that they can change
the tools (I2, para. 211). EBOM Management then requires the
released EBOM (I2, para. 207). After the EBOM Management
has placed the released EBOM in the ECM process, the MBOM
Management can begin its task (I2, para. 215).
4.3. MBOM Management
The MBOM Management is mainly responsible for creat-
ing and maintaining the Material Master (MM) and MBOMs
over the entire product life cycle (I3, para. 9, 13). The MBOM
Management is part of the ECM process and the CM meetings.
During the ECR phase, the MBOM Management fills the prob-
lem items into the ECR (I3, para. 151, 153, 155). The problem
items are the current data objects, which will be adapted dur-
ing the change. After the ECR is set on order and the ECO
is created, the MBOM Management gets the automatically as-
signed task within the ECO (I3, para. 51, 53, 57). It starts to
create the solution items, which are the new revised objects.
The needed information is contained in the ECR and ECO. If
not, the MBOM Management has to coordinate with the depart-
ments and contact them to get the information (I3, para. 55).
After completing the tasks, the MBOM Management informs
the CM and the BOP Management (I3, para. 155).
4.4. BOP Management
The main tasks of the BOP Management are creating and
changing the BOP, including the related tools and resources in
TC and creating or changing workcenters in SAP. In the ECR,
the BOP Management fills the problem and impacted items,
equivalent to the MBOM Management (I4, para. 145, 147). Af-
ter ECR approval, the ECO is created (I4, para. 167), and the
automatic tasks are assigned to the BOP Management. After
approving the task by the MBOM, a new revision of BOP can
be created. If needed, the BOP Management also creates the
MM for tooling (i.e., machines) and the needed workcenters.
All BOP managers are working in PLM and SAP. The BOPs
cannot be changed after release without a new ECR; no changes
are directly allowed in the ERP system to assure traceability.
When a BOP is changed, this directly impacts the product (I4,
para. 261), and a new ECR/ECO process is started.
4.5. Change Coordination (CC)
Although the CM and the CC are located in different depart-
ments, i.e., sales and operations, they work closely together in
the ECM team. The CC coordinates the implementation of the
change in the plant; each plant has its own CC (I5, para. 152,
172). Changes can affect different plants in parallel, so the CM
must have an extended workbench for all locations. During the
632 Raphaela Gangl et al. / Procedia CIRP 122 (2024) 629–634
ECR phase, the CC supports the evaluation of the ECRs. It is
done with the person responsible for the implementation, so the
plant is better informed in a very early stage of the change (I5,
para. 111, 117).
Mainly, the CC is responsible for planning and implement-
ing the change in the plant and participating in the CM meet-
ings. The CC receives the inputs from the CM meetings and
can pass them on to the different departments in the plant, e.g.,
production scheduling, quality or purchasing. The CC has to co-
ordinate the implementation to deliver on time, without rejects
and additional work (I5, para. 180). When all tasks in the plant
are executed and documented in the MCO, he handovers back to
the CM. The CM is responsible for closing the MCO. By clos-
ing it, the change is implemented in the plants. The plants which
are affected can have different dates for closing the change.
5. Applicability of the CM2 standard
The expert interviews have shown that the case company’s
ECM process is oriented towards the CM2 standard regarding
procedures and role allocation. There are some deviations from
the standard. For instance, the ECM process does not start with
a problem report; it starts with an ECR (I5, para. 15, I3, para.
51) or a different usage of the roles and responsibilities. The re-
search shows that the case company defines ECM more broadly.
The business process includes not only the change of master
data (MM, BOM, BOP) but also the implementation within the
plant operations (e.g., production and logistics) and the associ-
ated processes after the adaptation of the master data.
5.1. Need for an extended scope
The CM2 standard defines all needed steps to execute and
assess changes in the master data. It starts with the definition of
the change (CR), leads over impact analysis of the change for
different departments to the definition of the implementation
plan of the change to the execution of the change in the mas-
ter data (”Edit Product Data”, ”Validation”, ”CN Audit” and
”Released”). In our research, we saw that the extension of this
model needs to be done after the implementation plan was cre-
ated or released. Although the data has not yet changed, the first
tasks must be executed to smoothen the implementation. When
the data is sent from PLM to the ERP system for the first time,
the plants can prepare the change, although there are still tasks
to execute.
It has been found that the standard CM2 process focuses
on the change of master data; Fig. 1 left part, shows that the
standard process ends with the release of the changed master
data. This represents a change management focus which does
not consider the effects of changes in the operational areas but
refers to master data creation. Of course, impact analyses are
made on different areas (see ”Impact Analysis”), decisions are
made based on these (see ”Review Analysis Decision Making”)
and the implementation plan is defined (see ”Create Implemen-
tation Plan” and ”Review Implementation Plan”), but this is
done before the data is changed. There is no feedback loop to
the operational areas or plants and no follow-up on implement-
ing the terminated master data in the operational areas. As the
change in master data primarily impacts operations, production,
and logistics, the ECM process needs to integrate manufactur-
ing management processes in the ECM business environment.
Therefore, the MCO extends the standard CM2 process,
implementing the change in the production plants. When the
changed data is available and released from PLM to SAP, for
the CM2, the change is closed. Here, we suggest a further ex-
tension of the standards process: Implementing the change in
the plant will be tracked via plant-specific tasks and roles. Like
in the standard CM2 process, the focus lies not on the data but
on the operative execution (e.g., creating a production order or
sampling). The change is closed when all tasks are executed,
which means when the product, based on the changed master
data, is produced, checked, packed, and sent to the customer.
5.2. Reflection on the Manufacturing Change Order (MCO)
The MCO is the extension of the ECR/ECO process from
TC to SAP and has three main statuses: 20 (executing), 25 (final
executing), and 50 (completed). The MCO is triggered twice by
the ECO; status 50 is set manually by the CM.
• Status 20: Coming from the CM2 model, the first infor-
mation from TC to SAP is sent after creating or reviewing
the implementation plan. This is related to the creation
of the ECO at the case company. Initially, the informa-
tion about the description, change ID and implementation
date is sent to SAP and creates the MCO in Status 20, as
well as the Change Master, which is related to the MCO.
Within status 20, only plant-independent roles have tasks
to do—those are not related to the plant but need to be
executed prior the plant can start.
• Status 25: Related to CM2, after releasing the changed
master data, the MCO gets updated with the solution
items. For CM2, the change is closed, and the imple-
mentation of the change starts. With status 25, the plant-
dependent tasks are created for all relevant plants and
roles.
• Status 50: The final status of a change in the company is
the MCO Status 50. All tasks are completed, e.g., pro-
duction order is created, production is started, and sam-
pling is done (See Fig. 1, Extension of the CM2 process
towards including the MCO Process).
In practice, simultaneous work in the engineering data man-
agement and the preparation of the implementation in the plant
are executed (cf. Status 20). After reviewing the implementa-
tion plan, the ECO is sent to SAP (MCO Status 20). In par-
allel, the ECO is enriched in PLM with the new master data
(MM, BOM, BOP) and maintained in SAP (plant-independent
tasks). After the ECO is released, an update is sent to SAP again
(MCO Status 25). In TC, the change is now finished; in the ERP
system, implementing the change in the plant can start (plant-
dependent tasks). The CC starts the implementation, and the
departments can execute the tasks (I5, para. 184).
 Raphaela Gangl et al. / Procedia CIRP 122 (2024) 629–634
5.3. IT systems
Many software programs support the ECM process in the
case company. These include mainly TC (PLM) and SAP
(ERP). Different systems integrated with Teamcenter were not
in focus (I2, para. 91; I3, para. 37, 39; I4, para. 81-85, 210). The
PLM system TC is used to determine the master data (I3, para.
43). It is relatively rare that the BOP is created in the PLM sys-
tem because it is the mapping of the production process from
the system side; it is more often that it is directly created in
the ERP system. The ERP and PLM systems are integrated and
complement each other (I3, para. 241; I5, para.81).
6. Discussion and conclusion
The results of the qualitative content analysis show that the
case company has implemented an ECM process similar to
CM2 and extended it to implement the change in the manu-
facturing area (MCO). Only a few studies investigated the im-
plementation of the CM2 standard based on PLM and ERP in-
tegration [1]. Recognising the complementary nature, the inte-
gration between PLM and ERP is essential. The first research
regarding integrating the PLM and ERP systems came from Wu
et al. [11]. The process as it is lived in the case company in-
cludes the design and manufacturing areas, which mainly link
the PLM and ERP systems. The different data objects (MBOM,
BOP and MM) are captured on the PLM-side and fed into the
ERP system (I5, para. 81). In practice, the processes within the
ECM can no longer be considered independently. If no master
data is maintained, no changes can be made. This also means
that the process extension is not exclusively sequential possible:
the integration of PLM and ERP is decisive; this is also shown
through the two different statuses of the MCO (20 and 25). The
business process is not limited to a particular IT system. Only
when a complete integration and a smooth transition between
PLM and ERP is possible, frictional losses (money, resources,
time) within the process can be avoided.
The CM2 model described by Wu et al. [11] focuses on the
engineering change, which means analysing and implementing
an engineering data change. It ends with the released data. The
case company started with the CM2 model but enriched it with
the operational implementation of the change. The question is:
Is this still an engineering change, or do we define an extended
Enterprise Change Management model (see Fig. 1)? Due to the
strong interlinking of the single departments and activities, it
is impossible to speak of a delimination here. Product changes
require strong integration and do not end at system boundaries;
for this reason, the entire business process is not bound to a sys-
tem. It starts with an engineering change but is then transferred
to a manufacturing change that has to implement the effects of
the engineering changes. The overall construct combines en-
gineering and manufacturing change management and can be
titled enterprise change, as it also defines, accompanies and fi-
nalises the operational impact of the data requirements.
The study proves that the ECM is a critical process within
the Product Lifecycle Management (PLM) process and has a
633
significant impact on different lifecycle phases. It showed that
the ECM relates to the management and implementation of
changes to a product and is critical to ensuring an organisa-
tion’s agility and responsiveness to changing market conditions,
customer requirements and quality standards. Integrating ECM
with PLM ensures consistent and traceable documentation, in-
creases transparency, and facilitates department collaboration.
Implementing changes within a product’s lifecycle leads to in-
creased flexibility, quality, efficiency and cost control of the
entire product lifecycle; since new products are also managed
within the company via the ECM process, the PLM process is
primarily defined by the ECM process.
This study features some limitations and provides an outlook
for further research. The research results are based on inter-
views with a single company in the automotive industry. Since
only five process executors were interviewed, the research only
provides a limited picture of the implementation of ECM in cor-
porate practice. Due to the given scope, process stability and
achievements could not be considered. The following recom-
mendations for future research can be derived: Conducting ex-
pert interviews with the IT architects (PLM and ERP) to iden-
tify the system derivations from the standard and illuminating
how many personal interactions are needed to execute a suc-
cessful ECM; due to the increasing automatisation, the effort
of personal meetings will be reduced in future. In this vein, the
question ”How many personal interactions within the ECM is
needed?” can be generally raised. Currently, the case company
has a high degree of automation in the MCO. With the auto-
mated tasks and the predecessor/successor task arrangement, it
is contested to reduce personal interaction and speed up the pro-
cess execution.
References
[1] Wu, W.-H., Fang, L.-C., Wang, W.-Y., Yu, M.-C., Kao, H.-Y., 2014. An
advanced CMII-based engineering change management framework: The
integration of PLM and ERP perspectives. International Journal of Produc-
tion Research 52.20, 6092–6109.
[2] Schuh, G., Gartzen, T., Soucy-Bouchard, S., Basse, F., 2017. Enabling
agility in product development through an adaptive engineering change
management. Procedia CIRP 63, 342–347.
[3] Maceika, A., Tolocka, E., 2021. The motivation for engineering change in
the industrial company. Business: Theory and Practice 22.1, 98–108.
[4] Jarratt, T. A.W., Eckert, C.M., Caldwell, N.H.M., Clarkson, P.J., 2011. En-
gineering change: An overview and perspective on the literature. Research
in Engineering Design 22.2, 103–124.
[5] Arica, E., Bakaas, O., Sriram, P.K., 2020. A Taxonomy for Engineer-
ing Change Management in Complex ETO Firms. in 2020 IEEE Interna-
tional Conference on Industrial Engineering and Engineering Management
(IEEM), 285–289.
[6] Lashin, G., 2021. Technisches Änderungsmanagement. In: B. Bender, K.
Gericke (Eds.). Pahl/Beitz Konstruktionslehre, Springer Berlin Heidelberg,
pp. 919–942.
[7] Gollmann, T., Gangl, R., Gruchmann, T., 2023. Engineering Change Man-
agement – An Empirical Study on IT, Processual, and Organisational
Requirements. In: U. Buscher, J.S. Neufeld, R. Lasch, J. Schönberger,
J. (Eds.). Logistics Management. LM 2023. Lecture Notes in Logistics,
Springer Cham, pp. 99–112.
[8] Institute for Process Excellence: Das Fundament für Operational Excel-
lence - Die Reise zur Umgestaltung von veralteten Geschäftsprozessen und
Softwaresystemen beginnt hier, CM2-01, 2021.
 634 Raphaela Gangl et al. / Procedia CIRP 122 (2024) 629–634

[9] Institute of Configuration Management, 2002. CMII for Business Process [11] Wu, W.-H., Fang, L.-C., Lin, T.-H., Yeh, S.-C., Ho, C.-F., 2011. A novel
Infrastructure. Holly Publishing Company, 2002. CMII-based engineering change management framework: an example in
[10] Mayring, P., 2022. Qualitative Inhaltsanalyse: Grundlagen und Techniken. Taiwan’s motorcycle industry. IEEE Transactions on Engineering Manage-
Belitz Weinheim Basel. ment 59.3, 494–505.

Fig. 1. Extension of the CM2 process towards including the MCO Process.

View publication stats