Professional change management implemented at automotive supplier

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 respond to customer requests in ever shorter timeframes. Changes by customers, suppliers or even the realisation of own improvement ideas are part of daily business. It is therefore important to have an efficient process that supports these necessities. 

Our customer is successful in the market and naturally has processes and procedures in place to implement changes. However, in the search for greater efficiency and effectiveness, the desire to scrutinise the processing of changes grew. The objective was to become even more profitable by optimising the change process. The initiative also aimed to increase process robustness and ensure delivery capability.

Together we have chosen the classic approach:

• An analysis has revealed the challenges but also initial ideas
• The process was modelled together with the customer team
• One current focus is on implementation at all of the Group's locations and subsidiaries

In contrast to 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.

When setting up the project, it was important to us from the outset that all areas involved in product development were also part of this initiative. Our team was correspondingly large. It was also important for us to involve all affected production sites in the analysis phase. We organised a cross-divisional workshop at each of the sites to record the process. We also conducted interviews with department representatives to find out what needed to be changed - and just as importantly, what needed to be retained. Due to the issue of IT system implementation, we also took a close look at the tools used during the analysis.

We have focussed on the three levels of process, roles and tool. These elements have accompanied us throughout the entire project and now help to structure the results of the analysis.

The analysis showed that the customer naturally had existing solutions for all three elements. The task was therefore to identify the need for action in order to take performance to the next level. In terms of tools, it quickly became clear that SAP was perceived as a hindrance to the workflow in many areas. Individual areas or plants had created workarounds that affected data integrity.

A look at the process has shown that a large number of changes are processed in parallel. A comparison with the available resources did not always take place and change requests were only partially prioritised. It was also noticeable that a not insignificant number of changes were processed and only after some progress and effort was it realised that the changes did not make sense. For example, a possible material change was worked out intensively before it was realised that new machines and infrastructure would be needed for the material in production. In this 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. There was obviously potential in terms of evaluation, transparency and prioritisation.

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

In summary, it can be summarised in one picture: Our customer 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 or could process as input, and there were also surprises from time to time with the results. The project is therefore comparable to the general overhaul of this "modification machine".

The cross-functional project group set about making improvements with the results of an analysis supported by all those involved.

As 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 constitutes a change and when structured change management makes sense. Essentially, it is important to find the right balance between effort, speed and benefit. In terms of content, the main consideration was whether the process should only cover technical changes or all changes to the project and 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 retention. 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 approved project/product status is changed. In future, this should cover all changes to the product and process that have an impact on the "magic triangle" of costs, quality and time.

The question of the timing of application was also assessed differently. The consensus that change management should take place until the end of production (EOP) was quickly reached. However, 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 at which an initial, binding offer was sent to the customer. The trade-off to be made concerned the speed with which changes are processed, particularly in the quotation phase, in order to win the order, versus the added value of a structured approach and data management. The agreement to develop a process framework that enables process derivatives of varying complexity depending on the phase and the added value of a consistent change history then led to the decision to pursue a standardised process and documentation basis from the first quotation to the end of the product.

The process framework itself takes up many of the client's successful and existing elements. The biggest change is to carry out a cross-functional rough assessment before the actual start of the development of the change project. In this assessment, each department is asked to estimate the effort involved and can also state its "no go" from the department's perspective. Based on this assessment, a transparent decision can then be made as to which changes are to be made and when. Early transparency also makes it possible to bundle changes in order to reduce the effort required for verification and validation, for example. Improvements in the process details and the sharpening of milestones round off the process revision. For approvals, the aim was to leave the decisions to the responsible teams as far as possible. The aim is to strengthen personal responsibility. The conclusion of a change project has also been honed in such a way that the success of the project, the fulfilment of the objectives and also the experiences gained can be discussed pragmatically in order to learn for future projects.

As already mentioned, the biggest change, which also requires further development of the mindset of employees, is certainly working with estimates in the earliest possible phases. This is also a focal point of implementation. We explain the opportunities to employees and encourage them to work with estimates. We make management aware that employees will only appreciate mistakes if the error culture allows them to make mistakes. Working with assumptions plays a key role in this.

The idea of a process framework recognises 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 fulfil 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 fulfils all requirements. The overall result is comparable to a small product development process that covers all aspects of cross-functional collaboration. Depending on the specific requirements, customised processes can be derived from the framework. If there are recognisable patterns, these process derivations can be made permanently available, so-called "pre-tailored" process derivatives. In this case, there are fixed derivatives for relocations between two locations or colour changes, for example. A very short process for editorial drawing changes was also firmly derived. And, of course, the entire process framework also offers the option in each application of adding or removing activities as required as part of project management.

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 customer's descriptive logic so that the result fits into the overall picture. As recognised in the analysis, there was no consistent role model. In the discussion, the value of clear divisional representatives in the core project team quickly crystallised. This is the only way to ensure that the project manager with overall responsibility has sufficient resources to manage the entire project. This approach was therefore favoured across the board. For new product projects, this merely means strengthening the existing role model. In series production, however, it requires the installation of divisional representatives. The end result is the realisation that each area must also build up 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, however, this additional effort is offset by clear advantages. In future, a conscious decision can be made on which topics to work on and, if necessary, more capacity can be invested if it makes sense.

For the IT implementation, we mainly focussed on converting the workflow from SAP to JIRA and Confluence. Due to parallel IT projects to replace the existing PLM and ERP systems, it was ensured in these cases that the requirements from the change process were clearly defined. The introduction of the systems will enable further synergies.

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 designed 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 they can describe their requirements for the desired change. The aim was not to impose a complex process on the user, but to provide a simple introduction to the change process. True to the motto "keep it simple and smart".

Together with the project team, it was decided to define a handful of pieces of information for a change request. These are essentially clear information about what the changes describe. Furthermore, which components, drawings and references are affected. A brief description of the objective or expected result of the change described, what influence this change has on a possible urgency and what the possible triggers for this change could 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-orientated tool design also plays a role here, and here we have used familiar tool masks as a guide.

In the second step, the requirement created by the user is evaluated by a change administrator. This evaluation is important in order to rule out in advance that this change already exists or whether there is a possibility, with regard to the process described, to be able to run through the changes more quickly in a tailoring process. The change administrator also has the option of deferring the changes due to a 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 on a Confluence page. This is primarily for clarity and provides a quick overview of the change, where you stand 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 fulfilled this task or is an evaluation or feedback still missing. From a toolset design perspective, we have created attributes for each piece of driving information in the project change management process in JIRA, which can 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 tick boxes. Process tasks that require a clear evaluation or decision are process drivers that are necessary to be able to switch from one process gate to the next. Process tasks, which consist of individual subtasks, have been divided into so-called tasks and subtasks in the toolset. These were then mapped together again on the Confluence page to provide a simple view of the status of the process.

The entire run of the process comprises approx. 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 not sufficiently described, the toolset also provides the option of jumping back to the beginning of the phases. An evaluation can be configured in JIRA Confluence at any time during the change, 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:

Simple 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 history of the change, through a configured Confluence page per change
• Toolset and process are clearly described in Doing and Design
• Easy to learn, as JIRA Confluence is already used in the company

However, even the best process in the world will only be successful if it is implemented well. As consultants specialising in 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 employees and management with the new process. We rely on a combination of explaining and presenting as well as experiencing and developing together. Playful elements such as a role quiz encourage training participants to directly apply what they have heard 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 supporting the divisions on the path to implementation. One offer is implementation workshops to deepen understanding. This involves scrutinising whether all relevant standards, methods and templates are already in place and, if necessary, discussing the procedure for closing any gaps. We often also have a "best practice" that we can make available for the transition period. It is also important to define the specific roles in the department, including who will fulfil these roles. In this specific case, the discussion in the divisions about how estimates will be derived in future and the definition of a common understanding was very important in order to give employees orientation and security. Existing committees are being adapted and stakeholders trained. This ensures that a noticeable change is and remains perceptible in the organisation.

As with any good consultant, our aim is to anchor the content in a sustainable way and ensure that the organisation adopts and internalises the content. We therefore make sure to involve the client's employees intensively right from the development stage. During implementation, it is important to us that these colleagues also present the results and discuss them with us. In this way, the organisation recognises that the solution comes from within. We initially support the employees in the implementation process in a needs-orientated manner and then gradually withdraw.

All in all, we worked with the customer to take their change management process to the next level in order to be prepared for future challenges. In doing so, we contributed our entire expertise and implementation skills. It also paid off that our consultants, with their OEM and supplier background, knew the levers and were able to contribute this expertise.