Final Assignment – “Design Thinking for Innovation”

Matteo Cuda

2019, Oct 22

1. Challenge

In the Common Solutions Group of Applied Materials’ New Product Transition department,  troubleshooting and root cause analysis is where the rubber meets the road during the module  test and engineering validation phases of new mainframe and robot introduction.  The key here  is to quickly identify why a particular function or subsystem is not meeting expected  performance so that the system may be recovered.  A secondary goal – possibly more  important, in the grander scheme of things – is to treat each failure point as a seed for making  changes to prevent similar occurrences on future platforms.  Current methodologies and best  practices include fishbone analysis and a proprietary “8D” analysis.  Each of these methods can  be too slow to fit with the accelerated pace of product testing and aggressive shipment  schedules, and neither truly does a great job of finding and addressing the systemic root causes,  at best sharing a “lessons learned” slide with key stakeholders.

2. Selection

In my experience, mind-mapping has always been seen as a tool for organizing information and  tasks in a hierarchal, “tree” fashion.  This is undeniably very useful, but I had not attempted the  unique version of “mind mapping” as presented in this course.  That is, as a tool for finding the  “hidden” theme behind the more superficial symptoms.  I decided to use this method as part of  and an extension to our current root cause analysis culture, as I believed this would help avoid  time lost to chasing red herrings and would improve our post-mortem/lessons learned quality as  well.

3. Application

The particular problem selected was a random, chronic freezing of a front end wafer loading and  unloading fab interface for 200mm wafers into a dielectric application tool.  Specifically, the  front end robot would randomly freeze in between wafer transfer between loadports, forcing  the reliability cycling portion of the test to come to a halt, requiring the technician to manually  recover the system.  As a modification, I presented observed data (“gallery”) to a smaller group  of manufacturing engineers and technicians (stakeholders), and the process was conducted in a  more ad-hoc way, right in the test bay.

4. Insight

The method yielded several possible paths for us to follow, from errors in the code or failures of  the robot’s vacuum chuck to sags in the power supplies.  However, in fact, the key theme arose

from observation of an outlier!  Specifically, this was noticing a redundant feedback message –  an acknowledgement of the completion of the event onto which the system froze - seen upon  recovery of the system from the fault.  This lead us to ask the “so what?” questions which  brought us to realize that the message “pipeline” was being interrupted, and the robot could  not start it’s next task until receiving a message noting completion of the preceding task.   Ultimately, this turned out to be due to a random time syncing error between the serial  messaging processor on the indexer pod and the robot controller.  Incidentally, this was fixed  with a simple 10 millisecond delay - added to the control scripts – to “pause” the robot to wait  for the confirmation messages before proceeding.  This added 10-ms cycle time was  inconsequential to the productivity (throughput) of the overall system.

5. Approach

The biggest benefit from this exercise was seeing the bigger picture in that we need to be  reviewing the time synching of our related controls devices, especially for serial-controlled  (albeit legacy) systems.  Questions arise, however, such as “how will we know when to do this?”,  “what is the threshold?”, and “how would we have known to even look for this in the first  place?”.  Thus, the “takeaway” for the next application of this mode of mind-mapping shall be to  conduct a second round, after the acute root cause is found and addressed.  This second round  shall attempt to identify the design question for our business process as a whole, specifically  how to prevent a recurrence of the systemic gap that lead to the more specific failure mode.


Final Assignment – “ Design Thinking for Innovation ” Matteo Cuda 2019 , Oct 22 1 . Challenge In the Common Solutions Group of Applied Materials ’ New Product Transition department , troubleshooting and root cause analysis is where the rubber meets the road during the module test and engineering validation phases of new mainframe and robot introduction . The key here is to quickly identify why a particular function or subsystem is not meeting expected performance so that the system may be recovered . A secondary goal – possibly more important , in the grander scheme of things – is to treat each failure point as a seed for making changes to prevent similar occurrences on future platforms . Current methodologies and best practices include fishbone analysis and a proprietary “ 8D ” analysis . Each of these methods can be too slow to fit with the accelerated pace of product testing and aggressive shipment schedules , and neither truly does a great job of finding and addressing the systemic root causes , at best sharing a “ lessons learned ” slide with key stakeholders . 2 . Selection In my experience , mind - mapping has always been seen as a tool for organizing information and tasks in a hierarchal , “ tree ” fashion . This is undeniably very useful , but I had not attempted the unique version of “ mind mapping ” as presented in this course . That is , as a tool for finding the “ hidden ” theme behind the more superficial symptoms . I decided to use this method as part of and an extension to our current root cause analysis culture , as I believed this would help avoid time lost to chasing red herrings and would improve our post - mortem / lessons learned quality as well . 3 . Application The particular problem selected was a random , chronic freezing of a front end wafer loading and unloading fab interface for 200 mm wafers into a dielectric application tool . Specifically , the front end robot would randomly freeze in between wafer transfer between loadports , forcing the reliability cycling portion of the test to come to a halt , requiring the technician to manually recover the system . As a modification , I presented observed data ( “ gallery ” ) to a smaller group of manufacturing engineers and technicians ( stakeholders ) , and the process was conducted in a more ad - hoc way , right in the test bay . 4 . Insight The method yielded several possible paths for us to follow , from errors in the code or failures of the robot ’s vacuum chuck to sags in the power supplies . However , in fact , the key theme arose from observation of an outlier ! Specifically , this was noticing a redundant feedback message – an acknowledgement of the completion of the event onto which the system froze - seen upon recovery of the system from the fault . This lead us to ask the “ so what ? ” questions which brought us to realize that the message “ pipeline ” was being interrupted , and the robot could not start it ’s next task until receiving a message noting completion of the preceding task . Ultimately , this turned out to be due to a random time syncing error between the serial messaging processor on the indexer pod and the robot controller . Incidentally , this was fixed with a simple 10 millisecond delay - added to the control scripts – to “ pause ” the robot to wait for the confirmation messages before proceeding . This added 10 - ms cycle time was inconsequential to the productivity ( throughput ) of the overall system . 5 . Approach The biggest benefit from this exercise was seeing the bigger picture in that we need to be reviewing the time synching of our related controls devices , especially for serial - controlled ( albeit legacy ) systems . Questions arise , however , such as “ how will we know when to do this ? ” , “ what is the threshold ? ” , and “ how would we have known to even look for this in the first place ? ” . Thus , the “ takeaway ” for the next application of this mode of mind - mapping shall be to conduct a second round , after the acute root cause is found and addressed . This second round shall attempt to identify the design question for our business process as a whole , specifically how to prevent a recurrence of the systemic gap that lead to the more specific failure mode .