DESIGN THINKING IN AUTOMOTIVE SOFTWARE DOMAIN

CHALLENGE:

Working for an automotive software supplier, customer complaints from the field are a norm.

However short turnaround times are expected so as to firstly contain the problem (temporary solution) and  secondly unearth the root cause and provide a permanent solution. During the manufacture of ‘Car A’ a  fault was reported sporadically in the engine ECU (Electronic Control Unit) which reduced the throughput  of that particular line in the production plant. The experts from both parties (OEM and Supplier) were  shooting in the dark to arrive at a quick and dirty solution. Somehow by merely studying the symptoms  alone they were able to arrive at containment actions which reduced the occurrence of the problem by 10%,  but it did not solve the problem 100%! This provided a perfect platform to apply design thinking as a problem  solving tool to resolve this issue.

SELECTION:

The need of the hour was to identify the fundamental problem from the different symptoms that

were observed. Mind mapping would aid in this front so as to recognize patterns and form a base to  structure the potential root causes in such a way, as to attack them sequentially or in parallel with clarity of  the fundamental problem in mind.

APPLICATION:

A two-fold approach was needed.

1. Document the list of symptoms observed in the production plant so as to identify the fundamental

problem.

2. With the fundamental problem in the center, the various potential root causes were mapped as

child nodes arising from this central node. These child nodes were also clustered based on the  different entities like hardware, software, calibration, etc.

Step1: A special technique called ‘Is / Is-not’ was used. Simple questions such as the following were asked  and the answers were documented in a tabular format.

a) What is the problem?

What is not the problem?

b) Where did the problem occur? (Geographic location)

Where did the problem not occur?

c) When did the problem occur?

When did the problem not occur?

d) Who reported the problem? (Production plant)

Who did not report the problem?

e) How frequently did the problem occur?

Based on the answers to these questions the fundamental problem was identified. Though this data  collection was a time consuming affair, yet this ensured that we stayed in the problem space instead of  jumping directly into the solution space. Accrued to that it also ensured that innovative questions could be  asked while trying to unearth the root cause of the problem.

Step2: A mind map was created with the fundamental problem as the central node and the potential root  causes from the various areas (hardware, software, calibration, etc.) as child nodes branching from the  central node. Links were also created between nodes to show the interaction between them. This helped  in breaking down a complex problem into smaller logical chunks and later in eliminating them one by one  when a particular root cause was understood to not lead to the problem.

INSIGHT:

The biggest realization for the entire team was that with this approach the bigger picture was always

clear and visible, irrespective of the phase of problem solving. Though the time taken to demystify the  problem was more, yet the confidence level of the team increased with each and every step. The morale  was severely boosted. Most importantly the customer was happy with the progress. This was primarily  because the thought process and approach was transparent compared to merely preparing Powerpoint  slides explaining the problem and further actions planned.

APPROACH:

After a few months the root cause was identified and the solution was pretty straight forward. It felt

as if the solution took care of itself as the issue was fixed in just a few days once the root cause was  identified. When 80% of the time was invested in the problem space, then the solution phase was a stroll  in the park (the golden 80-20 rule). The first few weeks wasted in directly trying out different solutions based  on umpteen assumptions is one thing that could certainly be avoided next time. In an attempt to quickly  resolve the issue, acting on the symptoms would only camouflage the complex fundamental problem. In  retrospect any sporadic problem could directly be assumed as a complex one and the principles of design  thinking could be applied.

