Escalation Practices in Automotive Development

Abstract

In automotive business many risk-involved situations occur and when detected, an escalation process takes place. Although defined and controlled by process guidelines and being supported by experts, escalation brings increased emotional pressure and stress for parties involved. Do escalation processes in automotive industry maintain all implied challenges? The purpose of the article is to present current status of escalation processes and gaps between theory and practice cases. Results of the analysis are recommendations of good engineering practice derived also from actual experiences and learned lessons. The method involves analysis of practical cases from automotive development process, lessons learned, anonymous survey of automotive engineers and classification of experiences. Results of the survey have shown that the controlled escalation process for know-how related escalations is needed in order to establish the environment where the team is able to provide new, sometimes unconventional ideas for the problem to be solved. Presented recommendations and measures enable organization and managers to put the expertise and experiences of employees into action for problem solving during escalation. In this article some practices are presented that, although simple and some yet seen, with proper adjustment stemming from real life processes give a fruitful settlement of escalations in automotive development business.

Headnote

Abstract:

Research Question (RQ): In automotive business many risk-involved situations occur and when detected, an escalation process takes place. Although defined and controlled by process guidelines and being supported by experts, escalation brings increased emotional pressure and stress for parties involved. Do escalation processes in automotive industry maintain all implied challenges?

Purpose: The purpose of the article is to present current status of escalation processes and gaps between theory and practice cases. Results of the analysis are recommendations of good engineering practice derived also from actual experiences and learned lessons.

Method: The method involves analysis of practical cases from automotive development process, lessons learned, anonymous survey of automotive engineers and classification of experiences.

Results: Results of the survey have shown that the controlled escalation process for know-how related escalations is needed in order to establish the environment where the team is able to provide new, sometimes unconventional ideas for the problem to be solved.

Organization: Presented recommendations and measures enable organization and managers to put the expertise and experiences of employees into action for problem solving during escalation.

Originality: In this article some practices are presented that, although simple and some yet seen, with proper adjustment stemming from real life processes give a fruitful settlement of escalations in automotive development business.

Keywords: escalation process, stress, lessons learned, supplier chain, automotive development.

Povzetek:

Eskalacijske prakse v razvoju v avtomobilski industriji

Raziskovalno vprasanje (RV): V avtomobilski industriji nastopa veliko situacij s povecanimi tveganji in ko jih detektiramo, nastopijo eskalacijski postopki. Ceprav so eskalacijski postopki definirani s procesnimi navodili, izvedeni skladno z njimi in ceprav so pri resevanju problema udelezeni strokovnjaki, pri vsaki eskalaciji nastopa povecan emocionalni pritisk in stres za vse udelezence. Ali definirani eskalacijski procesi odgovorijo na vse tehnicne in organizacijske izzive?

Namen: Namen tega clanka je prikaz trenutnega stanja procesa eskalacije in odstopanj med teoreticnim pristopom in prakso. Rezultati analize so tudi priporocila dobre inzenirske prakse, ki so oblikovana tudi na osnovi dejanskih izkusenj iz vsakdanje prakse.

Metoda: Metoda je vsebovala analizo prakticnih primerov iz razvojnega procesa avtomobilske industrije, na osnovi napak pridobljenih znanj, anonimne ankete avtomobilskih inzeniijev in klasifikacijo pridobljenih izkusenj.

Rezultati: Rezultati ankete so pokazali, da je v primeru eskalacij zaradi pomanjkanja knowhowa, potrebno izvajati eskalacijski proces na nadzorovan nacin zato, da zagotovimo procesno okolje, v katerem je tim sposoben priskrbeti nove, vcasih tudi nekonvencionalne ideje za razresevanje problema.

Organizacija: Prikazana priporocila in ukrepi omogocijo organizaciji in menedzerjem da v eskalacijsko razresevanje problema vkljucijo znanje in izkusnje svojih zaposlenih.

Originalnost: V tem prispevku so prikazani prakticni napotki, ki so sami po sebi enostavni in nekateri ze poznani, a s primernim prilagajanjem na osnovi ugotovljenih spoznanj, omogocajo uspesno izvajanje eskalacij v avtomobilski industriji.

Kljucne besede: eskalacijski proces, stres, pridobljene izkusnje, dobaviteljska veriga, avtomobilski razvojni proces.

1 Introduction

1.1 Competitive business environment

Traditionally engineering was always highly creative activity that tried to give answers and solutions to various technical and construction problems. From early days of engineering those answers are always expected to be final, correct, long-term reliable and in terms of the targeted products, successful both from technical and economy aspects.

At the beginning of automotive era the development time and resources were more flexible, especially for first-of-kind products. Lead times have been longer and more capacity to finish the job was available. Engineers were more versatile in terms of their knowledge about products and technologies. They have got experienced in more comfortable way because processes were slower hence there was time to re-think critical steps and process decisions.

Today however the development activities in automotive industry are executed as projects, that are organized within design & development network, formed by one or more companies acting in supply chain, fig. 1. Due to the project nature of development activities today we are faced both with technical know-how challenges as well as capacity- and resources related challenges.

1.2 Risk of product over- and under-engineering

In past 30 years information technologies intensified development & production processes and the market has become highly competitive environment where the probability of ill-posed project in the company's project portfolio increased. Each project with negative technical and economical results can represent a factor of non-survival for development- /production company. In such cases negative financial impact can end-up in excessive non-planned costs. A failure mode that is not assumed during product development phase but can happen during product lifetime represents a constant risk for a financial collapse of the company, fig.2.

Those threats can yield a working environment where the engineers are put under extreme pressure and stress. The consequence can be:

* On one hand that engineers are forced to design a product to the limit of its performance capability hence product tends to fail at higher failure rates.

* On other hand that, instead of taking advantage from the fine-tuned balance between performance capabilities and operating boundary conditions, engineers don't dare to design the product to its limits. Products are thus becoming over-engineered hence in time due to non-optimized product costs the company can become non-profitable.

Both risks can produce states where engineering organization is faced with the crisis at product development or production processes being resolved through escalation process.

2 Theoretical framework

2.1 Definition and classification of escalations

When open issue at the project is detected then countermeasures are planned and introduced. If counter measure is not successful then additional management tool is used - the escalation process. During escalation an additional pressure is applied from the (internal- or external) customer towards the (internal- or external) supplier to resolve the issue as soon as possible.

We can distinguish among several types of escalations, fig.3, but for automotive the two most important would have been:

A. Escalation based on deviation from planned activities during development - name it "resource escalation", fig.4.

B. Escalation based on unplanned events during product design and especially during production process - name it "know-how escalation", fig.4.

The first type - resource escalation - arises typically when there is lack of resources on the project - either we are talking about:

* Human resources needed to do additional tasks or

* financial budget to cover extra expenses on the project or

* too short time available to accomplish planned tasks or non-planned extra tasks.

The second type - know-how escalation - takes place when a non-planned event occurs, e.g.:

* After production ramp-up of new product a series failure occurs at the beginning of product operation, or

* during the DVP&R (Design Verification Plan and Report) testing and verification phase results are negative, meaning the product does not fulfil customer specifications.

At know-how escalation the fundamental root-cause is lack of information or/and lack of know-how. Both are also basic conditions to be fulfilled for the solution to be found.

2.2 Escalation as problem solving in production process

As already mentioned the majority of escalations in production process deal with problem of resources - therefore it is more of resource-type and less of know-how-type.

In general the target of escalation is the introduction of the problem solving process at the supplier, fig.5, using tools like DMAIC, PDCA, 8D-report.

Problem solving should consist of the following structure and control questions:

* Step 1: Problem description - What are the problem and the root cause?

* Step 2: Risks on similar products and processes - Do we have same problem and systematic fundamental root cause also on other products or processes?

* Step 3: Containment actions (<24h) - How to contain? What kind of containment can we do in 24 hours and what in longer lead-time?

* Step 4: Root cause for non-detection - Why compromised products were delivered?

* Step 5: Root cause for occurrence - Why compromised products were produced?

* Step 6: Corrective action plan (<10days) - What is corrective action?

* Step 7: Effectiveness - Is corrective measure effective?

* Step 8: Lessons learned (<60 days) - What did we learn? How we will transfer learned lessons to other products and processes?

The escalation process is defined by guidelines and norms (Swift 2015) (Vorest AG, 2014) (ISO/TS 16949:2002(E), pp.28 - 30) mainly for the production processes. There are several levels of production process escalations in case of flaws detected:

* Level E0, Standard process - special 100% inspection of deliveries for 1-month.

* Level E1, Intensified process - corrective measures must be fulfilled to downgrade the level from E1 to E0.

* Level E2, Warning - corrective measures and additional customer conditions must be fulfilled to downgrade the level E2 to E1.

* Level E3, New Business Hold (NBH) - supplier is temporarily blocked for new business and exit criteria must be fulfilled to be removed from NBH.

* Level E4, Disqualification - exclusion of supplier from supplier base.

Typically as a consequence of escalation process the supplier management is involved in order to assure more resources, shorten lead-time and discuss with the customer exit conditions on proper managing levels.

3 Method

In order to check various aspects of escalations an anonymous survey was executed at automotive Tier-1 supplier from Slovenia where 189 potential respondents were asked to answer the survey. The survey consisted of 20 questions with predefined answers (from 6 to 9 answers per question possible) in order to get normalized response database for later analysis.

The method of this analysis was implemented using following survey inquiries:

* To understand the age, educational background, level of experiences of respondents several questions were raised, like:

* How old are you? How many years you are working at the company?

* What is your position in company's organization?

* To understand the working pressure and the handling of daily stress of respondents several questions were raised like:

* How often do you experience escalations at development projects?

* How do you feel and how are you acting when escalation happens? Is your thinking ability and creativity influenced by the escalation pressure? Does stress represent positive or negative stimulation for you?

* What do you do first when customer escalates the issue (claim, concern)? Who do you ask for help and support when escalation happens? Whom would you rather have as a teammate: young good educated colleague (potentially less experience) or matured professional with long-term experiences (potentially less theoretical background)? What is more important during escalation: good relationship with the customer or good theoretical background?

4 Results and Discussion

4.1 Survey results

The survey lasted 5 working days and out of 189 addressed respondents 72 of them (38%) have given feedbacks. Some of results are presented in fig 6 and fig.7.

4.2 Escalation as problem solving in development process

4.2.1 Development process deliverables and escalation type

Compared to production processes also during design and industrialization development phases many risk-involved situations can produce an escalation. Similar to escalations in production also this escalation process must have root-cause analysis and corrective actions.

So far in the presented text the automotive escalation process is declared and defined in detailed way. But looking at second glance we can see that definition is aimed mainly to the production processes. Why mainly for the production processes?

The answer lies within the fact that the production process differs from the development process in terms of deliverables and their quantities. For example:

* When dealing with production process then objects of the statistical analyses are produced parts (goods). In automotive production there is almost always considerably large product series available where, when faced with issues, the principles of statistical analysis can be applied. Based on that analysis one can find and deal with root causes, introduce corrective measures and track the effects of corrective measure implementation.

* But when dealing with design process then we are talking about one-of-kind deliverable, represented as a set of technical data, drawings and technical documents, that define information base for the related tools and production technologies yet to be developed. When faced with an issue of design deliverables one cannot get solution using statistical approach, based on which corrective actions would be introduced. There are no quantity of deliverables in design process where statistics would enable steering toward solution.

For later example the know-how is essential. Therefore it can be concluded that in development the know-how escalation takes place more often than resource escalation.

This has been proven with the results of the survey with answers to the question "What is by your opinion the most often root cause for escalations during product's development phases?". Answers on fig. 8 show that the cause with highest vote of 24% was "hidden errors at the product due to improper design (concept, maturity)". The second most probable cause (22%) was "improper quality of developed products due to lack of proper formal agreements with the customer... " which also reflects lack of information and know-how.

4.2.2 Experiences as performing factor in escalation process

The escalation process in development phase relies on definitions valid for escalations in production and that do not comply perfectly with the nature of development process. Although such escalation process is defined by process guidelines and being supported by technical experts, it still brings increased emotional pressure and stress for the parties involved.

There are several methods and theories (Swift, 2015, p.1; Vorest AG, 2014, p.1; DMAICTools, 2016, p.1) on how to handle critical situation in the development teams. There are many customer guidelines for suppliers (Schaeffler, 2015, pp.1-3; VOSS Automotive Group, 2014, pp.12-14; Faurecia, 2013, pp.25-30) that describe requirements of escalation and step-out of escalation. But a methodology about how to maintain the resulting pressure during escalation and how to use energy and ideas in best way to find solution is rare. Majority of recommendations are considering organizational aspects of the situation during escalation but few of them could offer reliable path toward the resolution using the technical expertise and experiences of involved personnel.

We know however that during every team set-up four significant phases happen: forming, storming, norming and performing phase, fig.9. Let us check how escalation process can be casted into those phases in order to recognize significance of experiences and know-how to maintaining escalations. For involved project team-members the escalation represents even more workload pressure and stress compared to the ordinary problem solving. What happens?

The first reaction on customer escalation message is team forming phase. If organization has escalation process defined and people are skilled they try to follow those process guidelines where team is defined and conceptual roadmap toward solution is explained.

Beside regular problem-solving which typically consist of solving of technical problems, the team must also assure information flow toward customers and toward management stakeholders. This communication tends to become difficult therefore the level of stress at team-members is even increased, their working time dedicated to problem solving is reduced and due to this we might end-up with higher costs and longer lead-times.

Escalation is not normal mode of operations hence the involved people are mentally and emotionally challenged. An instant seek of way out is induced by higher level of adrenaline and people react instinctively saving them against disaster. It is a storming phase.

It is evident that for successful development process results it is necessary to save developers from high level of negative stress and keep them in good mental condition. In order to do this, a controlled escalation process should be introduced also for know-how related escalations.

It is very important that in the team there are (senior) colleagues with lots of expert experiences. They can suggest proper steps while searching the solution, they are helpful with their broad professional network when seeking the expert information and in psychological aspect they can act as pillars of stability within the team. This has been proven with the survey answers to the question "Whom would you rather have as a teammate: young fresh-educated colleague (potentially less experience) or matured professional with long-term experiences" where the highest score (50%) gets the answer "both colleagues, older as lead" and second highest scored answer (24%) was "both colleagues, younger as lead", fig. 7.

A controlled escalation process for know-how related escalations represent the environment where the team can provide new, maybe unconventional ideas for the problem to be solved. In this way the chances for fast and successful resolution of the problem are higher and the crisis can be brought in a controlled way to successful end. All these influences happen normally within norming and performing phases.

4.2.3 Stress factor during escalation process

As mentioned the breakthrough should be done within the norming phase of the team lifetime. In order to do that it is important for the team to understand what is happening on rational and on emotional level of cooperation. Generally during escalation certain psychological pressure exists which can be intensive - the team-members need to perform in an excellent way under very challenging conditions - to list just few of them:

* Short or zero timing for execution of needed activities.

* Need to control several activities running in parallel.

* Regular / daily cross-examinations from customer side.

* Customer demand to present solution in person at the customer location.

* Customer demand to provide interim solution with high level of confidence.

* Customer demand to provide final solution with ultimate level of confidence.

* Lack of proper information and know-how.

* Lack of internal and external resources (availability of production, materials & stock).

* Lack of budget.

* Lack of stakeholder's (management) support, etc.

All these conditions represent at the same time the levers used by the customer (and sometimes suppliers) to push the team to provide the solution in zero time.

Team members with organizational- and especially with customer relationship experiences are extremely important here. They are able to steer the discussion with the customer in a way to calm down the situation hence enabling the rest of the team to start thinking without burden of stress in order to provide new ideas for interim- and final solution of the problem.

4.2.4 Development escalation process and measures

In order that problem is maintained in fast and efficient way the escalation must be handled as process where necessary steps and actions take place. The following principles and measures are recommended when organizing escalation in development as a controlled process:

* Principle 1: after information that something went wrong the immediate reaction is necessary! For the one who got the information no delay is allowed and no weekend off-line mode is acceptable, no excuse for passive approach should be accepted. He/she must immediately raise the voice and escalate the issue within own organizational structure.

* Principle 2: Top management must be informed about the escalation accordingly and must provide full support for organization of escalation process with corrective actions.

* Principle 3: All relevant experts from different fields should be summoned and delegated/ nominated by stakeholders (management) to the Task force team (TF).

* Principle 4: The leader of the Task force team is nominated. He must be awarded will full authority and power for decision making within the scope of escalation.

* Principle 5: Team Room (War Room, Large Room, Obeya - Toyota Production System) should be organized as physical location where Task force team meets or is located. For the team to work and exchange information with working environment and customer the Team Room should have all necessary infrastructure, e.g. mail access, phone line, telecon equipment, overhead projector, computer, whiteboards, pinboards, flipcharts, digital photo camera, scanner, printer, enough electrical power plugs, extension cables, cabinet/rack for keeping of samples and prototypes, accessories for marking of samples (pens, markers, etc.), brainstorming accessories (pens, markers, pins, Post-it, glue, tapes, cardboards, paper sheets, etc.), furniture (desk, chairs), Cafeteria/ refreshment corner.

* Principle 6: Immediate systematic work of the TF team must be organized and scheduled.

Activities that should be systematically executed when escalation happens are:

* Each information contents must be declared with additional data like source of information, time of collection. Information should be presented at one spot (e.g. whiteboard, pin-board, common folder on file server, common database, etc.) where they can be further classified / clustered. For clustering of information different approach should be used, e.g. clustering according to expert areas or clustering according to geographical locations of sources.

* When Task Force team members are nominated they must be at the same time released from other tasks - what should be assured by their line-managers.

* Kick-off meeting must be organized, Task force team and all stakeholders have to attend.

* Regular meetings must be scheduled (daily) - it is very important that the team meets at regularly scheduled routines in order to keep strong focus to tasks and to react on changed circumstances instantly.

* Team meeting must be clearly structured - it must have fixed agenda with clear reporter names, meeting coordinating person and List of open points (LOP).

* Information and communication channels with the customer as well as with important suppliers must be established. Customer relationships can be established both on formal level and also on informal, personal level. At later, the relationships are more informal and it is likely that also unofficial information that is important for problem solving (e.g. details about particular claim or failure mode) can be acquired from customer.

* The suppliers and customers can be involved in technical discussions. With this we are acting as partner dealing with customer in transparent way which is beneficial for increase of trust at the customer side. During this activity it is important that every team member understands the level of transparency that is appropriate to particular external party at given moment. It must not be the case that two or more team-members are communicating about the same issue with one external party unless otherwise agreed upon.

* Before communication to the customer / supplier (by emails, with official statements) it is essential to align in the team about standpoint and wording of the message.

* Supporting environment must be established (extended team), e.g. simulation engineering support, laboratory support, purchasing and sales support, production technology support, maintenance support, prototyping support, engineering design support, etc. Some of the experts from this extended supporting environment can be also members of the TF team.

* The rest of organization should be informed that the regular daily tasks of the TF team-members will be delayed or even cancelled, therefore the escalation might have a negative impact also on their projects.

* Every small step toward successful resolution of the problem must be a reason for celebration. With this approach we keep high level of team-members' motivation. Every team-member must get full support and trust from other team-members. It is essential that the team takes special care for integrity of its team-members, in order that if things go completely wrong the team disintegration does not occur (e.g. mutual accusations between team-members). The later situation can occur due to high negative stress levels, where the cause is fundamental one: the fear against loss of personal careers.

* After successful solution of the problem the technical lessons-learned workshop must be organized in order to collect new know-how and implemented technical ideas, which should be included into FMEA master model.

* After the solution also lessons learned workshop about the organization of escalation must be organized in order to collect experiences and provide facts-feedback throughout organization and to management. The most valuable contributors must be rewarded by management. Successful resolution of crisis must be celebrated within the team.

* At the end of escalation the Task force team should be formally disengaged by stakeholder decision upon final report on executed actions and solution of escalation.

In order to maintain escalation process successfully those principles should be considered in the company quality system in escalation process guideline.

5 Conclusion

As summary we can conclude that escalation types are important for solution approach selection. To distinguish escalation types it is important to understand boundary conditions and requirement scope of particular escalation. Generally only two major types of escalation occur in automotive: resource escalations and know-how escalations.

Solving of resource type of escalations is relatively easy because it only requires management to approve additionally needed capacities and resources. However solving of know-how type of escalations is more complex because one should find and implement expert knowledge or in worst case where there is no knowledge available, one must generate new ideas and know-how. Moreover the generation of new know-how must be done in zero time frame. How?

The ordinary approach of involvement of higher management does not help a lot. Generally one must rely on usage of new ideas generation methods like brainstorming, and afterwards supported by functional checking of rapid prototyped products. For this kind of escalation activities one must have available personnel that is professionally trained for coordination of escalations and for communication with the customer. Research has showed that experienced personnel is therefore of crucial importance for efficient steering toward solution: 69% of respondents trust more to "matured professional with long-term experiences", fig.7.

To successfully maintain escalation process an important principles should be respected and must be considered in the process guidelines that are essential to management and organization of the company. Escalation process must have ultimate priority compared to other activities in the organization. All other processes must be de-prioritized or even put to the ice during escalation period. The best people must be engaged and proper team must be nominated to the task-force team. Budgeting and other resources must be assigned to escalation process and management must follow-up progress of escalation continuously until the final solution of the crisis.

The research was rather limited to the sample from local environment not including the intercompany aspects and international base of respondents. As potential further research opportunity the collection, assessment and classification of know-how resulting from organization lessons-learned sessions should be considered.

References

References

1. ISO/TS 16949:2002(E) (2002) - Quality Management System - Particular requirements for the application of ISO 9001:2000 for automotive production and relevant service part organizationsfor the Automotive Industry.

2. Paul Swift, BeyondLean.com, (2015), Lean Six Sigma Green Belt Training, Retrieved from http://www.beyondlean.com/lean-six-sigma-green-belt-training.html.

3. Six Sigma-Mehr Wissen, Vorest AG, (2013-2014), Der DMAIC-Zyklus im Überblick, Retrieved from http://www.six-sigma.me/six_sigma_dmaic_zyklus/.

4. DMAICTools.com, (2016), Define, Measure, Analyze, Improve, Control (New!), Retrieved from https://www.dmaictools.com/.

5. Schaeffler, (2015), QAA with Production Material Suppliers, Escalation process, Retrieved from http://www.schaeffler.com/remotemedien/media/_shared_media/12_suppliers/quality/qu ality_assurance_agreement_qaa_/special_agreement/S_296001-6_Escalation_Process.doc.

6. VOSS Automotive Group, (2014), Supplier quality guideline (Issue 02.06.2014 Rev00), Retrieved from http://www.voss.de/files/auto_400_downloads/Lieferantenrichtlinie_EN_Rev0 0_ 20140717.pdf

7. Faurecia, Supplier requirements manual (2013), Retrieved from http://www.faurecia.com/files/media/site_com_corporate/Suppliers/documents/FAURECIA_S UPPLIER_REQUIREMENTS_MANUAL.pdf.

8. Epinephrine, Retrieved from https://en.wikipedia.org/wiki/Epinephrine.