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 . 


EMAIL: 
ID_NUM: 
NAME_STUDENT: Matteo Cuda
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: 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 .
### Output: 