Robots Fail Too By Ferra Weyhuni Within the recent month, therehave been two sudden robot failures on two differ- ent tools duringa build cycle. Lisa, the manufacturing engineer, has notified Nick,supplier quality engineer, about the failures, assuming that thetwo robots have some bad parts. She has requested that the tworobots be sent back to the supplier for rework, even though no rootcause has been identified. But, it seems that such a move hascaused some to question where the blame should be placed. The focusof this case is related to project quality management. OUR BUSINESSThe IEM Company is a high-tech company producing customized Ion andElectron Microscopes. The applications of their products can beused in a variety of fields, from academia to high-tech industries.Their customers are given the options of customizing the product tomeet specific process needs. The company’s financial profile showsthat their sales revenue last year exceeds $400 million. Thecompany is currently upgrading their tools for the improvement inthe imaging and wafer transfer system. This is required to helpexpand the market size and to meet customers’ satisfaction. Thisupgrading project was executed and is now in now in its operationalstage. WE HAVE A PROBLEM AND IT IS NOT OUR FAULT Nick: How do youknow it was the supplier’s fault? Is there a chance that we damagedthem during handling or installation? Lisa: According to the Rejectreport, the technician said that the two robots were working finefor two weeks after installation. But then there were a few errorlines such that the wafer transfer was stopped. Nick: We don’treally know if it’s the supplier’s fault or not. If it is theirfault, those robots wouldn’t have worked for two weeks, would they?Lisa: True. However, anything is possible. I think we should sendthese machines back for them to check it out. Nick: We can’t justsend them back without a well-documented “potential causes” report.Lisa: We don’t have time to do any tests or troubleshooting. Theyhave the experts in their company who can test the robots to findout what’s wrong with the machines. I suggest we send them back andsave ourselves some time. Nick agreed with Lisa’s suggestion. Thetwo robots were sent back to the sup- plier for investigation. Oneweek later, similar problems occurred on several other machines.The problem became so big that the issue was elevated to Donnie, amanufacturing engineering manager. Donnie asked Lisa to form a teamto identify the root cause of the problem. Lisa agreed to puttogether the team to brainstorm the root cause and the next courseof action. She promised to follow the following steps: goaldefinition, root cause analysis, countermeasures identification,and standardization. Lisa called a meeting with Nick and the othertwo manufacturing technicians, Joseph and Ryan. The team wasworking to get a list of possible causes for the problem. As anormal procedure in the team’s analysis, the first thing to do wasto create a fishbone diagram. Joseph: As a starting point, can wecapture what actually happened before the error message showed upon the screen? Ryan: I don’t really know what happened. I was juststarting to teach the robot, following our procedure, but then theerror message showed up. Joseph: That doesn’t make any sense. Ifnothing changed on the system itself, we shouldn’t have gotten theerror. There’s got to be something changed on the system. Lisa:Let’s create a fishbone diagram for potential root causes of thisproblem. The team brainstormed using the affinity diagram method.The purpose of this exercise was to ensure everyone’s input wascaptured during the process. They determined the amount of time tobe spent on brainstorming, and then went through each idea thateach member came up with. When going through each idea, they alsodecided whether those ideas were candidates for root causes. If anyof the ideas didn’t make sense, they put them aside and noted themas “possible but not likely” causes. Some of the ideas are shown inTable 8.1. Once the ideas of potential root causes were laid out,they started their fishbone diagram by grouping the potentialcauses into larger categories such as Software, Mechanical, etc.The fishbone diagram would be used as a tool to communicate withupper management as well as field personnel showing all possibleitems that needed to be checked if and when the errors occurredagain. Figure 8.1 is an example of a fishbone diagram. Lisa: Here’sthe fishbone diagram you requested. We came up with a few thingsthat need to be checked using our tools on the manufacturing floor.Donnie: How much time do you need? Do you have a test plan for eachitem? Lisa: I have not created the test plan yet but it should bestraightforward. Donnie: I think you should create a test plan toshow us all what you’re going to do and what the results would be.The customer does not know that we have this issue on themanufacturing floor and they don’t know how severe it is. We shouldget to the root cause before it gets out of hand. Lisa: Iunderstand. However, I don’t have the bandwidth to do all of thiscorrectly. Donnie: This is of the highest priority now. Lisa: Okay.I will work on it. Lisa created a spreadsheet that could be used bytechnicians to test the tool for all possible causes (see Figure8.2). This spreadsheet shows all activities to be per- formed toensure there are no assumptions made by technicians. The resultsare recorded and anything worth noting during the test must bewritten down.
+ Abstract ?
+ Context and Background Information ?
+ Identification of the Main Issues/ Problems?
+ Analysis of the Issues?
