Part Change Management: A Case Study on Automotive Engineering and Production; Domestic and International Perspectives

Changes to parts in the automotive industry come from two sources [1]: (1) creating innovative features that are implemented in existing vehicles and (2) managing existing features, where innovation is defined as “the multi-stage process whereby organizations transform ideas into new/improved products, service or processes, to advance, compete and differentiate themselves successfully in their marketplace” [2]. This definition is based on an analysis of word clustering among 60 definitions from 1934 to 2010 [2]. Managing these changes is increasingly important, not only as the rate of innovation increases [1] but also as companies continue to seek to improve quality and sustainability while meeting new regulations, often resulting in changes to existing parts [3]. A consumer survey conducted in 2008 showed that 86% of respondents list quality as the most important factor in buying a new vehicle [4]. The results of this survey show the importance of quality to the customer, explaining why many companies list quality concerns as a main source for part engineering changes [3,5,6]. Furthermore, the implementation of some engineering changes can lead to cost reductions for the company, which can have a significant impact on the company’s financial standing [7].

To understand what is meant by P-EC (part engineering change), it is necessary to understand what is meant by parts in the context of this paper, the kind of changes part engineering change entails, and the sources of these changes. For the purpose of this paper, parts refer to any item that is identified on the Bill of Materials at the original equipment manufacturer (OEM). Additionally, different definitions of the term part engineering change management (P-ECM) exist due to the breadth of work that has been performed on this topic. Here, change is defined as “engineering change orders (ECOs)—changes to parts, drawings or software that have already been released” [8]. This definition is used in several other research efforts [5,9].

The reasons for engineering part changes can come from a variety of sources [3,10]. At the company that was the focus of this paper, data analysis shows the common sources include quality improvements, cost savings, safety concerns, legal considerations, and ergonomic changes benefitting the employee assembling the vehicle. Examples of each of the aforementioned engineering part change sources can be seen in Table 1. The exact frequency is withheld here for proprietary reasons.

Examination of engineering change data at the automotive OEM showed that in a 20-month period in the middle of a product’s lifecycle, 1211 changes of all kinds were made. Quality and/or product improvement is the most frequent reason for a part engineering change and accounted for over half of the changes. Many changes are also due to cost savings. According to one interviewee, removing a painted component and replacing it with a black component can reduce vehicle costs by almost €1/vehicle. In an industry where some automobile manufacturers produce over 10 million vehicles annually, these savings make a significant difference to the company. These types of changes accounted for approximately a quarter of total changes. Another driver of change is safety concerns. A component will generally be changed as soon as possible if there is a safety concern [5]. For example, battery connections that can become corroded due to water and/or salt must be redesigned as these corrosions could lead to the loss of electrical power to safety-critical components such as the brakes. These types of changes are rare, but it was not possible to filter the available data for these types of changes. Less common are legal considerations and ergonomic changes. Legal changes can include changes to laws in countries around the world. For example, some Gulf States require a sticker on the vehicle that describes the fuel economy of the vehicle. While this is not strictly a part change because neither the windshield that bears the sticker nor the fuel system itself is affected, it is a change that needs to be made to the final vehicle before it is shipped. These types of changes are rare and account for less than 5% of the changes. To make the assembly of the vehicle more employee-friendly, ergonomic changes can also be made. One example of this is a preassembly of a wiring harness inside the vehicle. By preassembling this harness, only one connection has to be made once the harness has been installed in the vehicle. As these connections are frequently made in tight spaces, reducing the number of occurrences to one helps the associates. These types of changes are rare, but it was not possible to filter the available data for these types of changes

Other industries are also affected by similar sources, albeit not limited to those listed in Table 1. In the defense industry, the most common sources as determined by an industry roundtable discussion are a change in requirements or regulations, quality/cost/durability, sustainability, product integration, and project management [3]. Ergonomic changes have been studied to increase employee output, especially in the furniture industry where carpal tunnel syndrome and tendinitis are more prevalent than in other industries [11]. Furthermore, it has been shown that legal considerations can account for roughly 20% of engineering changes in the civil engineering design community [7,12]. Regardless of industry, the reasoning behind making an engineering change is frequently the same. All changes require some combination of efforts such as time, cost, and risk. By making a change, the company hopes that the positive aspects of the change, such as improved cost or quality outweigh these negative aspects.

Engineering changes and their management (process and tools) in the industry have been reviewed from several different angles, such as time management and financial management [12–17], as well as P-ECM tool use. The process can be highly complex depending on the type of product and industry involved. To help with this complexity, companies have developed numerous in-house tools that track financial and temporal information [3,16,18,19]. Furthermore, these can be broken down into research regarding strategies, change propagation, process responsibilities, change drivers, other tools and findings as well as process descriptions.

In the reviewed literature, no examples of a case study using insights from departments ranging from engineering to purchasing to sales regarding the engineering change management system and the employees’ perception of the system have been found. The research for this paper set out to gather the opinions of employees who interact with the process and software for their insight into the process. Overall, the role of user acceptance in the success of software and the financial implications of engineering changes and its management in general led to the following research questions:

1. How do employees engage with the engineering change management process and tool?

2. If so, how do these issues align with differences between departments?

To understand the need for ECs and ECM processes, a review of the related literature was conducted. This included definitions of ECs, an explanation of change propagation and the potential impacts of the phenomenon, and trends in ECM research. Additionally, suggestions for improvements in ECM methods were explored. Lastly, a comparison of the different process models used in ECM studies was conducted.

The definition of engineering change differs slightly depending on the perspective of the research being conducted. Raffaeli et al. defined ECs as a series of changes that impact the components of a product after production has begun for that product [20]. Another study defined EC as an “alteration made to parts, from embodiment design stage through production stage, in its form or fit or function, drawings or software that has already been released” [10,21]. Knackstedt and Summers gave a similar definition in their study of part change management, which said that ECs were changes to parts, drawings, or software that had already been released [22,23]. Additional context for that definition was given, which stated that ECs are typically made for reasons of either quality and product improvement or to increase cost savings. The literature review conducted by Wright defined EC as a modification to a component of a product after the product is in production [24]. A commonly used explanation of ECs defined the concept as the changes or modifications in the forms, fits, materials, dimensions, or functions of a component after the product design is released [19,25,26]. Huang et al. further elaborated on the EC phenomenon, explaining that ECs typically induce a series of downstream changes that flow across companies and require multi-disciplinary teams to address the effects [25].

Engineering changes can be broken down into two categories: initiated changes and emergent changes [27–29]. Initiated changes stem from a response to altered customer requirements or from internal innovations in design. Some of the driving factors of initiated changes from the outset of a product design include customer requirements, from general capability statistics to specific equipment; certification requirements, including government codes and environmental standards; innovations, in materials or in processes; and problems identified from past designs. Other factors that can introduce initiated changes even later into the product design process involve new customer requirements, such as changing operation environments or marketplaces; recent innovations, which are more common for products with a long design period; and retrofits, common for products with a long life cycle [27]. Emergent changes are caused in response to problems occurring during the design process, or from weaknesses identified in the product. The aforementioned problems could occur during the initial part design, as some changes cannot be predicted by computer-aided design (CAD) systems, or during testing, prototyping, and manufacturing phases. Additionally, problems occurring during the use of the product could cause emergent changes as issues are addressed [27].

Traditionally, engineering changes have been considered a hindrance in the design and manufacturing process. In the literature review conducted by Wright, opinions on different aspects of the manufacturing process are presented [24]. The manufacturing perspective thinks of ECs as an evil that has the potential to disrupt production operations. Production control views ECs as a source of confusion that has the potential to upset a precarious balance of manufacturing resources, while inventory control sees ECs in terms of the cost of the scrap and rework that would potentially be produced. This sentiment is echoed by Huang et al. in their study of the ECM methods employed in Hong Kong manufacturers, as the companies involved found the management of ECs to be costly and time-consuming [25]. ECs were also found to have a noticeable negative effect on the delivery time of products, as well as less prominent but still adverse effects on product quality, day-to-day jobs, and workmanship. The article written by Jarratt et al. similarly found that ECs were considered to be a major source of problems in the part development process [29].

Despite these negative perceptions, ECs are increasingly seen as a way to keep up with the market and implement continuous improvement. Raffaeli et al. stated that ECs represent a key aspect of innovation, especially with regards to product families of standard parts or solutions, as ECs allow for more variants to be created in order to satisfy niche market demands [30]. Huang and Mak found support for that statement, in that companies gain significant market competitiveness if ECs are handled properly [19]. Similarly, Wright’s review of ECM literature showed that the incremental improvements made to products using ECs lead to vast leaps in innovation, as well as the fact that EC is a key process that allows companies to stay competitive in the market and effective in their product design [24]. Kidd and Thompson echoed this sentiment and summed up the new viewpoint toward ECs, saying that ECM has a vital role in all successful industrial organizations [31].

The new view on ECs is timely, as, across manufacturing industries, there has been a widespread shift in the approach to manufacturing, from mass production to mass customization [32]. This new approach has been embraced by manufacturers because of the need to make continuous improvements in order to create competitive products [31]. Mass customization is seen as the best way to satisfy individual needs through products while still turning a profit [33]. However, this approach introduces new issues to the traditional consideration of EC and change propagation. The greater connectivity that is created between systems using a mass customization, modular system architecture, or product family approach leads to a greater probability that changes will spread to other systems [27]. Eckert et al. also found that complex products with parts or systems that are tightly linked are more susceptible to change propagation [27]. Building on this, Raffaeli et al. found a need to extend EC methods in a way that allows for the evaluation of the impact that a change to a single product has on the overall product family [30].

Engineering change as it relates to manufacturing has been studied through mapping to general process models [34]. For instance, one model views three basic steps of a manufacturing change management process: before approval, during approval, and after approval [35]. This work was limited to looking at general phases and did not deeply study the roles of individuals, the timing, or the criticality of the proposed changes. An expansion of this included a cyclic model that required the manufacturing engineer to submit a proposal to the engineering team (the owner of the product, often the development team, but not always) that requires approval before implementation. A challenge identified with this approach is that the production is ongoing and that the change is either implemented immediately pending retraction or manufacturing waits for approval. This resulted in iterative revisions to proposals approved [36]. Another model focuses on identifying the need, selecting the solution, approving the change intent, approving and releasing updated documents, and communicating modifications. Between selecting the solution and approving the change, this process argues for a pause in production (a decrease in work), but additional steps are required between approving the change and releasing approved and updated documents when compared to the traditional process [37].

The sources for change in manufacturing can be from the production line, from quality control offices, supplier changes, design changes, or logistics modifications [10,34]. An example of design changes may take the form of introduction of new options or packages in a vehicle model. Option change management intersects both manufacturing and design [32]. While there are some differences between design engineering changes and manufacturing engineering changes, the processes for implementing these are similar. The main distinction tends to be with respect to the authority to implement the change and the timeliness associated with manufacturing changes during production.

The trickle-down nature of change is commonly referred to as change propagation; however, the definition of this term varies between researchers. Shankar et al. considered change propagation as the effects of changes that spread to other design sections [21]. Another study by Shankar et al. defined change propagation as the phenomenon by which one change sparks a series of other changes, which is typically studied by considering the linking parameters as the root cause of the spread [10]. Rouibah and Caskey found that stronger couplings between components increase the possibility that changes in one component will cause a change in another part [26]. An oft-cited explanation of change propagation defines it as the process by which a change to one part of an existing design or system configuration results in additional changes to the system, when those changes would not otherwise have been required [27–29]. Further breakdown of the phenomenon includes the types of behavior exhibited by components in response to a change, as well as the characterization of propagation types. When a change is introduced to a system or environment, components can act as constants, absorbers, multipliers, resistors, or reflectors. Propagation itself can be characterized as change ripples or change blossoms, if the changes finish on time differentiated by the size of the initial change effort, or as change avalanches, if the changes do not finish on time [27–29].

A study by Shankar et al. looked extensively into the reasons for change propagation [10]. In the study, 77% of all changes were internal changes, with the remaining 23% considered external changes. Internal changes were found to be caused by document error corrections, cost reduction exercises, manufacturing issues, design corrections, and inventory issues. External changes largely stemmed from changes to customer requirements. Further study broke down changes into propagated and initiated changes. The propagated changes were discovered to come from inventory issues, design error rectification, and manufacturing difficulties [10].

Further studies have explored methods of measuring and capturing trends in change propagation. Raffaeli et al. considered a method to measure the extent of change propagation and the linkages between changes and found that most of the existing work looks at linkages in the physical domain or in the functional domain [30]. However, few studies look at the connections between the physical and functional domains. With regards to capturing trends, Eckert et al. used a design structure matrix to show the connection network between trends and to look at the relationship between affecting and affected parameters [27]. Giffin et al. studied a data set of over 41,500 change requests and used graph theory to find change networks [28]. From this analysis, they found that the large change networks tend to coalesce based on nucleation in different parts of the system. Additionally, Giffin et al. constructed 1-, 2-, and 3-change motifs, which were used to categorize and characterize the trends in the change requests data. This data can then be used to determine a way to manage the extent of the engineering change propagation.

Engineering change management is defined as an activity in which the design change life cycle is monitored [31]. Rouibah and Caskey and Bouikni et al. go further in their definitions, stating that ECM is the process of making ECs in a planned, systematic manner that typically consists of engineering change requests and engineering change orders [26,38]. Many studies discussing ECs and ECM describe the steps for a successful ECM system. Kidd and Thompson mentioned a multi-stage cycle of change proposal, work order, and specific instructions, change implementation, and release approval for the ECM systems they reviewed [31]. Another procedure, consisting of identification, evaluation, implementation, and audits of ECs, was discussed in the study of ECM in UK manufacturing industries conducted by Huang and Mak [19]. Rouibah and Caskey posed an ECM system with four key steps: tracking change impact on product structure elements, identifying the people to be informed of the change, determining a sequence for informing the previously identified people, and executing approval and release of workflow with the participation of all involved parties [26]. A fourth set of steps was posited by Phelan et al. which consisted of the EC request, development of possible solutions, evaluation of change impacts, EC approval, implementation, and then review of the EC [32].

Although ECM systems are specialized to work with individual companies, there are some general trends. When first introduced, most ECM systems were paper-based and used the highly inefficient strategy of sequential review [19,25,29,31]. ECM systems then moved to a more computer-aided approach, in which the systems provided electronic documents that functioned in the same manner as traditional paper documents [19,25,26]. Once product data management (PDM) systems became available, many companies began integrating the ECM and PDM systems [26,31]. Huang and Mak determined from their research into the practice of ECM that most ECM systems are formally defined, with clear procedures, with most decisions and meetings involving both the design office and the industrial and production department [19]. Also identified were the barriers to using ECM efficiently: poor communication and late problem discovery, which leads to panicking and easy acceptance of quick fixes.

Across the literature reviewed, a common theme was the need for improvement to the ECM system and process. Thus, many of the reviewed articles discussed systems or tools. Shankar et al. proposed a seven-step verification validation and testing (VV&T) planning and computational tool, designed to guide a change engineer through the process and reduce human error by carrying over information between computational steps [21]. Rouibah and Caskey suggested a five-step parameter-based model for ECM, distinct from existing process- or document-dependent models, that would support communication in distributed engineering environments across company borders [26].

Kidd and Thompson discuss the in-house custom-designed software system used at British Aerospace (Military Aircraft Division) (BAe(MAD) and its three key advantages [31]. The BAe(MAD) system allows customers as well as the design and manufacturing departments to initiate design changes, notifies all affected departments or individuals of the change proposals, and requires those affected to give advice on the design change. The system also locks CAD files and only releases drawings when changes affect them, thus preventing documentation errors [31].

The study conducted by Huang and Mak on the ECM methods used in manufacturing industries in the UK found both tools and systems in use [19]. Commonly used systems include computer-aided design (CAD) and manufacturing (CAM) as well as material requirements planning (MRP) software. Many companies were also found to use design tools such as quality function deployment (QFD), failure modes and effects analysis (FMEA), design for manufacturing and assembly (DFM/DFA) principles, and value analysis in order to control ECs.

Bouikni et al. proposed a product feature evolution validation (PFEV) model that would support formal modification processes used for ECM after the initial product release [38]. The model would create a dynamic workflow that would offer the flexibility to efficiently handle the informal pre-release EC process, in addition to the formal post-release process. This would be done by incorporating the concepts of shared product features between disciplines, introducing an estimator of change, and generation of discipline- and task-specific information sets.

Other proposed models include the meta-product model that addresses both functional and modular part structures and product architectures [30]. Eckert et al. suggested modeling ECs using a problem-solution-evaluation loop, representing both a forward partial redesign process and a backward debugging process [27]. Shankar et al. created a model that would translate change interactions to a domain mapping matrix [10]. Similarly, Jarrett et al. proposed a change prediction method that would combine design structure matrices with risk management techniques [29].

Given the research questions proposed in the previous section, a case study was used to answer these questions. This section will give details on case studies, and data collection.

A case study is an objective, in-depth look into the uncontrolled environment offered by companies in industry or universities in an academic setting [39,40]. It can be used for different reasons; providing a description, generating a theory, or testing a theory is among the most common [41].

A case study can focus on just one company or examine multiple companies to compare and contrast a situation. Within one case study, it is also possible to study processes specific to one company or processes that have become common throughout the entire industry [42]. Case Studies can use multiple research methods, such as interviews, surveys, and experiential analysis to add credibility to the research while helping to ensure the results are valid and accepted [39,40,43]. The case study described here used interviewing and a survey to generate data. An interview and survey approach to understanding the change management process for line-sustaining engineering was selected to provide a broader comparative understanding of organizational elements within the company. The views and perceptions of participants within the process are critical for understanding the rationale associated with any process deviations. This approach has been used for understanding other aspects of engineering design, such as the research culture [44,45], change management in automation and manufacturing [34,46], and capstone design effectiveness [47,48]. Alternative approaches in case study research in engineering design are more generally focused on document analysis, focusing on the objectivity of analyzing existing information rather than seeking to extract potential explanations or perceptions. Document analysis in the case study has been used to understand information loss [49], design tool use [50,51], or problem-solution detailing [52–54].

For this case study, an automotive OEM was identified that presented a potential to study both the difference between engineering and manufacturing groups in the organization as well as studying the general cultural differences between the groups. The manufacturing facility is located in the Southeast US, while the engineering and management offices are located in Europe. The development headquarters and engineering teams are responsible for design and development of three brands. The manufacturing facility is responsible for the assembly of four vehicle models for one of these brands. The development headquarters employs nearly 20,000 employees across all major functions, while the production plan employs approximately 9000 employees across manufacturing and production activities. Both organizations employ a company-specific permanent engineering change management system, while the production plant also employs internal systems for temporary engineering change management.

Further, this case study was developed to be conducted while the first author was employed at the organization during a graduate internship that spanned roughly nine months. Further, the first author is fluent in both languages that are commonly used within the organization. This allowed the research team to not only literally translate interview and survey information collected, but to also add contextual understanding as appropriate. Finally, the research team had extensive contacts within this organization that spanned multiple decades. This was crucial in that trust had been established through multiple mechanisms that helped encourage multiple interviewees and survey respondents to participate without hesitation or reservation.

While specific details of the engineering change examples are not provided here for proprietary concerns, an illustrative example is presented. The seatbelt receiver in the passenger front seat might be found to rub on the center console, creating minor scratches that could be viewed negatively by the end-user. Therefore, a solution is needed to quickly respond to this quality defect. Locally, the manufacturer could decide to use a soft, felt pad on a sticker to attach to the seatbelt receiver. This could be immediately implemented to address the problem (temporary change), but it would still need to be submitted as an engineering change notification to the engineering group. This change would follow the defined engineering change management process as it is a product deviation. Any changes to the steps for assembly or the tools used are not considered changes to the product and are therefore not submitted as part of the change management process unless the assembly steps or fixtures are explicitly defined as required by the engineering department.

The research procedure for this case study consisted of interviews and surveys. The interview process will be outlined in the ensuing subsections and is followed by the results. The interviews were used primarily to narrow down employee responses to a list of issues and topics that could be used for conducting a survey. A sample of interview questions can be seen in Table 2.

The questions in Table 2 were selected because they point toward the targeted nature of questions that were asked during the interview. It was important to find out whether or not the official P-EC process is actually used or if there are deviations. This allows for a starting point in investigating problems. Question 2 was included for a similar reason- if users think about how much time they spend with the problems created by the process and software system, they may be more inclined to actively participate in the interview. The last question is an example of a question that was added to later revisions of the interview list based on previous interviews during which it was mentioned that there is a problem with the P-EC notification system. The final set of interview questions consisted of 26 questions.

To identify the P-EC process and obtain details about the software system in use, a focal point was to ask individuals with varying degrees of system interaction and responsibilities in the process. Furthermore, weaknesses in the process and systems were discovered through this approach. A tracking system used by the company was searched to identify interview candidates. This system tracks participants, roles, and timing for all engineering changes for specific models over a period of time that can be set by the user. Other companies track similar information [55].

The search was narrowed to a period of January 1, 2014, to December 31, 2015, and models that are produced at one particular manufacturing plant in the United States. The time was narrowed to this period because it gave a large enough sample size to be able to segment participants into user frequency groups (UFG), while minimizing the number of people who have moved on to other functions or other employment opportunities. Additionally, interview representation from all major departments at the OEM was sought. These departments are development, purchasing, production, and a group called “other,” describing those employees who do not fall into the other three departments.

The users, defined as those employees who have access to the system and are requested to give feedback, were then divided into user frequency groups, each user being a high-, medium-, or low-volume user. For example, a user who has given feedback 40 times over the course of a year would be in user frequency group “High.” An overview of this categorization can be seen in Table 3.

The interviews were conducted in the native language of the interviewee. Each interview lasted between 30 and 60 min and was audio recorded after consent was obtained. The interviews were conducted in neutral locations, such as conference rooms or empty breakrooms. The interviewees were generally pleased that this study was being undertaken with comments such as “It’s about time someone looks at this system [translated]” and “throughput times that are pretty much completely pointless… with all the shadow lists that are being created off-line [translated]”. Further, the “low frequency” users were generally surprised to be included in the interview process.

Results regarding the employees and the software system were gathered. All interviewees stated that their work requires face-to-face meeting time as well as phone conversations to complement the information that is in the P-ECM software system. None of the 15 who were interviewed had familiarity with other engineering change processes, as they had not worked at any other companies.

One difference among the interviewed associates is how much time it takes for them to work on a request, including data entry as well as meetings. This ranged between a few minutes and several hours, regardless of the department.

Additional differences came in the form of the final question, when associates were asked to give feedback on any other struggles they have with the process or the system. The process efficiency (“The ineffable throughput times that are pretty much completely pointless… with all the shadow lists that are being created off-line, it’s really not efficient” [translated]) and the quality of information (“The quality of the information we receive isn’t always good” [translated]), as well as the timing that is automatically generated for change requests, were the most frequently mentioned criticisms. Furthermore, the purchasing department had specific criticisms of the system and the workflow. Another interviewee was not pleased with getting requests that have no impact on him, saying, “If somebody would just use their brain for once and think, ‘yeah that part number is affected but there is no change’ that would really help out” [translated].

To obtain additional data, a survey was used to receive more feedback. The following subsections detail the steps in creating the survey, finding survey participants, and distributing the survey.

Based on the information gathered in the interviews, a survey consisting of 29 questions was created that was submitted to additional persons identified by the company tracking system. The survey was used to triangulate information obtained in the interviews. Prior to giving out the survey, it was tested on three individuals who had also completed interviews to ensure the questions reflected the current issues of the process and system and could be answered without needing clarification [56]. While the participants in the survey remained anonymous, the first section of the survey consisted of questions that made it possible to group the participant into different groups. For example, the participant was asked whether or not he still uses the engineering change system and how many years he has used the system.

The next section of the survey gave the participant the chance to indicate to which extent they agree with a statement that was made on the survey by marking it on the line. An example of this can be seen in Table 4.

Lastly, the users had three free response questions asking them if there are other issues with the system, other ways to improve the system, and how much time they could save with an improved system.

The participants for the survey were found using the same approach as finding the participants for the interviews. It was based on the data management system that the OEM uses and was then filtered for those participants with the highest use of the engineering change management system. Fifty participants were sent the survey. The list was continually expanded, following the same selection protocol, until 46 individuals completed the survey.

Upon receiving the participant’s written consent, the survey was distributed in person, making it possible to personally thank the participant for his time. The survey distribution was completed for three weeks to account for the availability of all participants. The participants were asked to complete the survey in one week. The surveys were then collected as the participants finished them, also for three weeks.

In total, 46 surveys were handed out and completed. The answers to two of the introductory questions (department and the number of uses per week) can be seen in Table 5.

In addition to the data shown in Table 5, the participants reported an average of 6 years of use in the software system that guides the P-EC process. Furthermore, participants required on average approximately one hour to complete their task regarding an engineering change request. This number includes meeting times, working in the system, and ensuring that all information is correct. However, the range of values given for this question is between 5 min and 7 h. Employees working in development took longer than their counterparts in other departments did.

To analyze the data, a measurement of the mark that was made on the survey for each question was taken. The further to the right the mark is, the more strongly a participant agreed with the statement (see Table 4). The data were recorded in a spreadsheet and were grouped by department, use, and experience level of the participant. Initially, every question was grouped by department, and the average was taken. Additionally, a total average for every question was taken. The total average is first used as a baseline for which topics the participants felt most strongly about based on either high or low values on the scale from 0 to 8.0. The raw data can be seen graphically in Fig. 1.

A review of Fig. 1 reveals that all questions have a standard deviation between 1.7 and 2.2 with the exception of the last question, which has a standard deviation of 1.3. The next step in the analysis is to look at differences between the departments, company experience, and uses per week. This is the topic of the next section.

Analysis of differences is completed on several different groups: departments, number of uses per week, and number of years of experience. To examine whether or not statistical differences between responses exist, a Mann–Whitney U-test was used. This test is explained in further detail in the next subsection.

A Mann–Whitney U-test is used because of its ability to handle non-normal, discrete, or continuous data [57]. To use this type of test, the data must exhibit characteristics and/or be exposed to the assumptions displayed in Table 6.

The nomenclature for these equations can be seen in Table 7.

Two sets of data are compared using Eqs. (1) and (2). The comparison follows on the basis of the number of samples in each data set as well as the data rank. For each comparison that is conducted, a value for U₁ and a value for U₂ are generated. The lower of the two U values is then compared to a table of values for this test, which gives a critical value based on the number of samples in each data set and the significance level, α. For the comparisons in this thesis, α = 0.05 was used because it is frequently used in studies where a particular result is expected [59].

The null hypothesis is the following: H₀ = there is no significant difference between the data sets. This hypothesis is rejected if the calculated value for either U₁ or U₂ is lower than the critical value obtained from the table (i.e., U₁ < U_α=0.05 or U₂ < U_α=0.05) [57]. The test was run using IBM SPSS Statistics 23.

Using the Mann–Whitney U-test, all of the statements presented can be analyzed for the significance of the differences in the data. The focus of the data analysis is on differences between the development department and the production department for the following reason: the development department most frequently generates an engineering change and therefore may exhibit bias toward any issues with the perceived quality of engineering changes, whereas the production department is generally the end-user/customer of the engineering change, and must implement changes. Conducting the test on these two departments reveals the following information, summarized in Table 8. It is important to note that the significant results are influenced by the number of participants in each group. Since not all participants answered all questions, a different sample size occurred for some questions. The change in sample size leads to a change in the U_critical.

Statements 15, 18, 23, and 24 indicate significant differences between the development and the production department. To understand what can explain these differences, the statements are reproduced in Table 9.

It should be noted that the reason for the different results regarding these four statements is not clear, but the following statements are theories based on the author’s experience in the company.

• Statement 15 shows a difference because the production department may rely very heavily on the information that is in the engineering change and may be particularly weary of giving feedback since the members of the production department must ultimately implement changes.

• The difference in statement 18 may stem from the fact that a creator of an engineering change needs the feedback of multiple production department employees while not needing as many feedbacks from his own department because he is solely responsible for a part.

• The difference in answers to statement 23 may be explained by the fact that the development department, as the creator of the engineering change, does not want to fill out more information, while it would help the production department receive more information to provide informed feedback.

Statement 24 may also be attributed to these differences, though it should be noted that all departments felt strongly about this statement.

The distinction of how many times the software is used per week is another comparison that can be made. For this comparison, those who give feedback on 10 or more changes per week are compared to those who give zero to two feedbacks per week. The results of this comparison can be seen in Table 10.

Table 10 summarizes that none of the differences between those participants who use the system zero to two times and more than 10 times are significant. While it may seem initially that the averages of those two groups, as seen in Table 10, are very far apart on some questions, the small sample size of this comparison resulted in comparison to very low U_crit values, which resulted in accepting the null hypothesis for every question and therefore accepting that there is no significant difference between the two data samples.

Finally, the differences in terms of experience levels were analyzed. In this case, those participants who had used the system for at least 10 years were compared with those who were novices, having less than 2.5 years of experience. The results from this comparison can be seen in Table 11.

A review of Table 11 shows that Statements 8, 9, 13, and 18 indicate significant differences in responses based on experience level. To understand what can explain these differences, the questions are reproduced in Table 12.

The statements in Table 12 indicate that, when employees start using the engineering change software system, they feel that the transparency of the process and the usability of the software needs to be improved. It is therefore likely that the employee perception of usability and transparency increases the more they use it. Additionally, there is an expectedly large difference for statement 13 because new users, who are unfamiliar with the process and software, will most likely not help others in a similar position. The response to Statement 18 can be explained in a similar fashion. If the user is a novice user, it is more likely that others in the department will receive a feedback request on the same topic, to ensure that a more knowledgeable employee also knows of a potential change.

The data presented here indicate very few shared differences between the different groups that were compared. The only statement that created statistically significant differences for various groups was Statement 18, which appeared in the department comparison and the years of experience comparison.

During a literature review on the management of engineering changes throughout different industries, no research was found that focuses on the employees’ perception of the engineering change process and software tool. It has been shown that employee involvement in the creation of new software processes can be beneficial in increasing user acceptance [14]. Research was conducted at an automotive OEM to assess the extent to which the employees use the part engineering change software and their attitude toward the software. To this end, a total of 58 employees of this company were either interviewed or surveyed to answer the two research questions presented in Sec. 1.2:

1. Do the employees have any issues with the engineering change management process or tool?

   Based on the information provided in Sec. 3 of this paper, the employees do have issues with the engineering change management process or tool. Examples include lacking quality in the engineering change feedback requests and lack of notifications when information is altered in the request. However, it must also be noted that overall, the question “does this software make your work harder?” was generally answered on the “disagree” end of the spectrum.

2. If so, can these issues be broken down into differences between departments?

   These issues and many other statements can be broken down into statistically significant differences between departments and years of experience. Grouping by the number of uses per week did not reveal any statistically significant differences. A shared difference between departments and years of experience exists regarding other employees receiving feedback requests on the same topic. This may be an opportunity to cut costs for the OEM.

While this is a case study that explores a single organization and its implemented engineering change management process for supporting line-sustaining engineering, the findings can be generalized and applied beyond this specific organization. First, automotive OEMs might have different approaches to product development, but they are constantly sharing best practices through exchange programs and research literature. These organizations are generally multinational with engineering in one country and products distributed internationally. Thus, the design-manufacturing division is often reinforced by multiple national cultures. The findings within this case study can have potential generalization to other automotive organizations of similar structure and configuration.

In addition to direct transferability to other automotive or other complex systems design and manufacturing organizations, there is the potential to generalize the findings that the process that is implemented to support a specific activity and a defined key performance indicator can be modified and corrupted without malicious intent through the introduction of shadow systems. This is something that should be incorporated into company process development as a consideration. While it is commonly suggested that key performance indicators are often used incorrectly, this case study presents evidence of this. At the same time, it presents an approach to help uncover these deficiencies through systematic analysis through interactions with employees.

Ultimately, the goal of this research is not to present a universal truth, but to add to the understanding of how engineering change management operates in industrial practice. This can help inform the future development of processes and supporting tools.

A limitation of this case study is that the data in the form of interviews and survey results were only analyzed on one product line at one automotive OEM. The perceived issues are only valid for the associates of the product line that were interviewed and could be different when interviewing associates who work on the engineering change request for a different product line within the same company.

Building off this research and its limitations, many other avenues can be pursued. Similar analysis involving more product lines at this OEM and/or other OEMs throughout the world. The differences between companies could give insights into best practices regarding software use and process flow. These best practices could then lead to cost savings across the industry. Furthermore, an increase in the number of survey participants would help strengthen the case made in this paper as well. Another opportunity to further research engineering change management deals with a detailed analysis of the impact of past engineering changes. Many engineering changes are presented as cost savings; investigating whether or not these cost savings were realized or not can be beneficial to an organization in handling engineering changes. This leads to the following research question: “What percentage of all part engineering changes have a positive long-term value?”

This work can be used as a framework for other industry case studies on manufacturing change management. For instance, this structured interview and survey approach has already been used in a study on “de-automating” aircraft assembly workstations [46]. Having a defined structure for how to conduct this research is critically important for supporting future studies.

There are no conflicts of interest. All procedures performed for studies involving human participants were in accordance with the ethical standards stated in the 1964 Declaration of Helsinki and its later amendments or comparable ethical standards. Informed consent was obtained from all participants. Documentation is provided upon request. Informed consent is not applicable. This article does not include any research in which animal participants were involved.

The data sets generated and supporting the findings of this article are obtainable from the corresponding author upon reasonable request.