Professional change management implemented at automotive supplier

Framework conditions and initial situation

The automotive industry is changing constantly and ever faster. Cost and time pressure are constant companions. Of course, this also applies to Tier 1 suppliers, who have to offer, deliver and react to customer wishes in ever shorter time. Changes by customers, suppliers or even the implementation of own improvement ideas are part of the daily business. Therefore, it is important to have an efficient process that supports these necessities.

Our client is successful in the market and naturally has processes and procedures to implement changes. However, in the search for more efficiency and effectiveness, the desire grew to put the processing of changes to the test. The objective was to become even more profitable by optimising the change process. But strengthening process robustness and ensuring delivery capability were also goals of the initiative.

Together, we took the classic approach:

• An analysis revealed the challenges but also initial ideas.
• Together with the client team, the process was modelled.
• One focus is currently on the implementation in all locations and subsidiaries of the group.

Unlike a classic process project, we were tasked from the outset with integrating the process directly into a suitable tool landscape and ensuring the connection of the PLM and ERP systems.

Approach

When setting up the project, it was important to us from the beginning that all areas involved in the product creation were also part of this initiative. Our team was accordingly large. It was also important to us to include all affected production sites in the analysis phase. We held a cross-departmental workshop at each of the locations to record the processes. At the same time, we conducted interviews with departmental representatives to find out what the departments felt needed to be changed - and at least as importantly, what needed to be maintained. Due to the question of IT system implementation, we also took a close look at which tools are used in the analysis.

In doing so, we focused on the three levels process, roles and tool. These elements have accompanied us through the entire project and now help to structure the results of the analysis.

The analysis showed that the client naturally had existing solutions for all three elements. The task was therefore to identify the need for action to bring performance to the next level. With regard to tools, it quickly became clear that SAP was perceived as a hindrance in many areas as a support for the workflow. Individual areas or plants had created workarounds for themselves that affected data integrity.

A look at the process showed that a great many changes were being processed in parallel. Alignment with available resources did not always take place and prioritisation of change requests was also only partial. It was also noticeable that a not insignificant part of changes were processed and only after some progress and effort it was realised that the changes were not useful. For example, a possible material change was worked out intensively before it was realised that new machinery and infrastructure would be needed for the material in production. In that case, the benefit of the cheaper material was cancelled out by the machine. However, the realisation only came after some effort had already been invested in the change. So obviously there was potential in terms of evaluation, transparency and prioritisation.

Roles and responsibilities were described. But there was a need for improvement in the application and implementation. There were different processes across the product life cycle phases. At the transitions, there was a transition in responsibility, data management and procedure. There were different role concepts in the phases. While a clearly defined project manager acted with an interdisciplinary core team in the product development period up to SOP, this form of guided interdisciplinary cooperation did not exist for the processing of changes in the series phase. Here, the project manager had the task of directly controlling all areas and experts, which often led to the limit of controllability.

In conclusion, it can be presented in one picture: Our client had a functioning "change machine" that processed the changes. However, the machine kept making strange noises and it was not always clear what the machine needed as input or could process, and there were also surprises in the result from time to time. The project is thus comparable to the general overhaul of this "changing machine". With the results of the analysis supported by all participants, the cross-functional project group ventured into the improvement.

Definition of change

In a first step, it was important to find a common definition for changes that should be covered by this process. It is understandable that each department has its own idea of what a change is and when structured change management makes sense. The main thing is to find a good balance between effort, speed and benefit. In terms of content, the main consideration was whether the process should only cover technical changes or holistically all changes in the project and the product. In the end, the view prevailed that all changes in the life cycle of a product should run through the same process and result in consistent data. The term "Project Change Management Process" was deliberately chosen to express this understanding. For better manageability, it was also determined that a change only exists if a defined or released project/product status is changed. Thus, in future, all changes to the product and process that have an impact on the "magic triangle" of costs, quality and time are to be covered.

The question of temporal application was also assessed differently. The consensus that change management should take place until the end of production (EOP) was quickly found. But the question of the starting point and consistency was weighed up intensively. In the end, it was agreed that future change management would start at the point where a first, binding offer goes to the customer. The trade-off to be made was the speed with which changes are processed, especially in the quotation phase, in order to win the contract, versus the added value of a structured approach and data management. The agreement to develop a process framework that allows for process derivatives of varying complexity depending on the phase and the added value of a continuous change history then led to the decision to follow a uniform process and documentation basis from the first offer to the end of the product.

Process

The process framework itself echoes many of the client's successful and existing elements. The biggest change is to carry out a cross-functional rough assessment before actually starting to work on the change project. In this assessment, each department is asked to estimate the effort and can also place its "no go" from the department's point of view. On the basis of this assessment, a transparent decision can then be made as to which changes should be tackled and when. Early transparency also makes it possible to bundle changes, for example to reduce the effort for verification and validation. Improvements in the process details and the sharpening of milestones round off the process revision. In the case of releases, an attempt was made to leave the decisions to the responsible teams as far as possible. The aim is to strengthen ownership. The conclusion of a change project was also sharpened to pragmatically reflect on the success of the project, the adherence to the goals and also on the experiences in order to learn for future projects.

The biggest change, which also requires further development of the staff's mindset, is certainly, as already mentioned, working with estimates in the earliest possible phases. This is also a focus in the implementation. We explain the opportunities to the employees and encourage them to work with estimates. We make management aware that employees will only estimate if the error culture also allows them to make mistakes. Working with premises plays an essential role in this.

The idea of a process framework takes into account the realisation that there are different requirements for a change process in the life cycle of a product. In the early phases, the aim is to quickly bring the concept to maturity. Short-cycle changes are the rule; testing, industrialisation or validation is not yet necessary. In the series production phase, every change needs to be well coordinated and planned so as not to jeopardise the existing processes and the released product. These requirements are difficult to meet with a "one size fits all" approach.

From our point of view, the solution is simple: With the process framework, we have described a consistent structure that meets all requirements. The overall result is comparable to a small product development process that covers all aspects of cross-functional cooperation. Depending on the specific requirement, adapted processes can be derived from the framework. In the case of recognisable patterns, these process derivations can be made permanently available, so-called "pre-tailored" process derivatives. In this case, there are fixed derivatives, for example, for relocations between two locations or colour changes. A very short process for editorial drawing changes has also been firmly derived. And of course, the entire process framework also offers the possibility in each application to add activities as needed within the framework of project management or to hide them in a specific case.

Every process needs clear definitions of who is responsible for which activity. That is why there is a complete RASIC matrix behind the process. In these cases, we always like to use the client's description logic so that the result fits into the overall picture. As recognised in the analysis, there was no consistent role model. The discussion quickly crystallised the value of having clear division representatives in the project core team. Only in this way does the project manager with overall responsibility have enough resources to steer the entire project. Thus, this approach was favoured throughout. For new product projects, this merely means strengthening the existing role model. In series, however, it requires the installation of divisional representatives. In the end, this means that each division must also build capacity for changes in the series in order to manage them. Together with the transparency and the clear focus on promising changes in the early phase of the change process, this additional effort has clear advantages. In the future, conscious decisions can be made on which issues to work on and more capacity can be invested when it makes sense.

IT implementation

For the IT implementation, we focused mainly on the conversion of the workflow from SAP to JIRA and Confluence. Due to parallel IT projects for the replacement of the existing PLM and ERP systems, it was ensured in these cases that the requirements from the change process were clearly stored. With the introduction of the systems, further synergies will be possible.

The basis for the IT implementation in the JIRA Confluence toolset is the process described. The start for the user in the toolset for the project change management process was deliberately tried to be simple. The JIRA Confluence tool provides support in the form of a service desk module, which provides the user with a guided screen in which he can describe his requirements for the desired change. The aim was not to impose a complex process on the user, but to enable a simple entry into the change process. True to the motto, "keep it simple and smart".

So it was decided with the project team to define a handful of pieces of information for requesting a change. This is essentially clear information about what the changes describe. Furthermore, which components, drawings and references are affected. A short description of what goal or expected result is expected from the described change, what influence this change has on a possible urgency and what possible triggers for this change can be. This form should make it possible to give each change a space in the first stage of the assessments and to lower the entry hurdle somewhat. Of course, a simple and user-oriented tool design also plays a role here; here, already known tool masks were used as a guide.

In the second step, the requirement created by the user is evaluated by a change administrator. This evaluation is important to rule out in advance that this change already exists, or whether there is a possibility, with regard to the described process, to be able to go through the changes more quickly in a tailoring process. The Change Administrator also has the option of moving the changes to the back of the queue due to lack of urgency or even rejecting them. After the Change Administrator has evaluated and tailored the change, the described requirements of the change are merged from the JIRA Confluence toolset onto a Confluence page. This primarily serves the purpose of clarity and thus offers a quick view of the change, where one stands and what still needs to be done.

Depending on the process described, the Confluence page describes where we are in the changes, which role in the process currently has which task and who has already completed this task or is still missing an evaluation or feedback here. From a toolset design point of view, we have created attributes for each driving information in the project change management process in JIRA, which are to be assigned an input by the user. These inputs are configured in such a way that they can be controlled via text input, selection list, drop-down menu or ticks. Process tasks that require a clear evaluation or decision are process drivers that are necessary to switch from one process gate to the next. Process tasks, which consist of individual subtasks, were divided into so-called tasks and subtasks in the toolset. These were then mapped together again on the Confluence page for overview reasons, in order to ensure a simple view of the status in the process.

The entire run of the process comprises approximately 120 tasks. Each of these tasks is assigned to a role in the process via the Change Admin or an automation logic. At the transition points from one process phase to the next, mandatory fields or mandatory attributes must be filled in, otherwise it is not possible to switch to the new process phase. If information is missing or insufficiently described, the toolset also provides the option of jumping back to the beginning of the phases. At any time within the change, an evaluation can be configured in JIRA Confluence, as each attribute created in the overall process describes an amount of progress. We would like to highlight the following highlights from the JIRA Confluence toolset:

• Easy and clear entry into the process
• There is a task or subtask for each step in the process, which is linked to a role
• Overview of the progress of the change, through a configured Confluence page per change.
• Toolset and process are clearly described in the doing and the design
• Easy to learn, as JIRA Confluence is already used in the company.

Implementation and training

Even the best process in the world will only be successful if it is implemented well. As consultants with a special focus on change management, this is very important to us. Our approach therefore goes beyond mere information and training. Of course, these elements are the first step in familiarising staff and management with the new process. We rely on a combination of explaining and presenting as well as experiencing and working through together. Playful elements such as a role-playing quiz encourage training participants to apply what they have heard directly and promote discussion and understanding. Of course, fun and enjoyment are also part of successful understanding.

In addition to information and training, we also attach great importance to accompanying the areas on the way to implementation. One offer is implementation workshops to deepen understanding. In these workshops, we ask whether all relevant standards, methods and templates are already available and, if necessary, discuss how to close the gaps. Often we also have a "best practice" for the transition period that we can make available. In addition, the concrete design of roles in the field, including the definition of who will take on this role, is important. In this specific case, the discussion in the areas on how estimates will be derived in the future and the definition of a common understanding was very important in order to give orientation and security to the staff. Existing committees are adapted and stakeholders are trained. This ensures that a noticeable change is and remains perceptible in the organisation.

As for every good consultant, it is also our goal to anchor the contents sustainably and to ensure that the organisation adopts and internalises the contents. Thus, we make sure to intensively involve the client's employees already in the development phase. During implementation, it is important to us that these colleagues also present the results and argue with us. In this way, the organisation recognises that the solution comes from within. In the beginning, we accompany the employees in the implementation process according to their needs and then gradually withdraw.

In sum, together with the client, we have taken their change management process to the next level in order to be prepared for future challenges. In doing so, we have contributed our entire technical and implementation expertise. In addition, it paid off that our consultants, with their OEM and supplier background, knew the levers and were able to contribute this expertise.