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 . 


EMAIL: 
ID_NUM: 
NAME_STUDENT: 
PHONE_NUM: 
STREET_ADDRESS: 
URL_PERSONAL: 
USERNAME: 

### Task: You are a PII (Personal Identity Information) Detection. Given a essays written by students, you have to identify ONLY the following:
NAME_STUDENT - The full or partial name of a student that is not necessarily the author of the essay. This excludes instructors, authors, and other person names.
EMAIL - A student’s email address.
USERNAME - A student's username on any platform.
ID_NUM - A number or sequence of characters that could be used to identify a student, such as a student ID or a social security number.
PHONE_NUM - A phone number associated with a student.
URL_PERSONAL - A URL that might be used to identify a student.
STREET_ADDRESS - A full or partial street address that is associated with the student, such as their home address.
### Input: 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 .
### Output: 