Alamo Learning Systems - Using Cause Analysis on the Job


			Using Cause Analysis on the Job

			By: Craig LaFargue Cause Analysis (CA) is one of the more powerful tools in the AdvantEdge and APS arsenal. As with other tools, it is only as good as the user's ability to apply it to good advantage. In identifying root cause, CA is enhanced by the user's familiarity with the process. Unfortunately, the process can seem intimidating at first, and simply too complex for everyday use. Some people who attend the training become discouraged and finally consign the material to a corner where it gathers "binder dust". The end result is that the training opportunity is wasted. I believe there are identifiable reasons for "Cause Analysis paralysis" and that it can be remedied if the user has sufficient information. First-time users may sometimes feel that CA is too complex and that it supplants their intuitive problem-solving skills and the experience gained, sometimes over many years, on the job. In actuality, CA is a tool to supercharge the search for facts that the user may already know. CA does not diminish one's skills and experience; it enhances them. New users have also complained that CA is too rigid, that it can only be used in the full classic version, and then only for complex problems. This is akin to believing that it must be applied, without variation, to all problems, regardless of the level of complexity. This impasse is resolved when the user differentiates between simple and complex problems and learns how to use CA in accordance with need. It bears repeating that CA is actually a very simple process and, if positioned and taught correctly, the simplicity is obvious. So, how does one use CA on the job in a way that actually helps to solve problems more quickly without getting in the way and creating more problems? For the past eight years I have been teaching the manufacturing and field engineers at KLA-Tencor how to use the CA tool to determine root cause of failure. As a result of this experience, and with feedback from them on what works and what doesn't work on problem solving in the field, I have developed a process that makes use of one's experience with the problem object in such a way that clues are illuminated rather than obfuscated. The following steps outline that process. *Step One: Develop a problem statement.* The problem statement is the starting point. Many times, the cause of unresolved problems is an unclear problem statement. This step will ensure that you and others are in agreement about the problem to be solved, and that it is one that requires root cause analysis for resolution. *Step Two: Take 3 guesses.* This step assumes that you have some knowledge of the equipment or process. Perhaps the problem you identified is due to a recurrent cause that has not been fixed. There is nothing wrong with using your experience to solve a problem in a way that, based on your past experience, points to a known fix. Use your experience, and use it early. Fifty percent of the time, you will be able to fix the problem just using Steps One and Two. The risk of relying only on your experience is that similar symptoms may mask different underlying causes, and you can get trapped into trying every fix you know of (and then some), and before you know it, you're lost. So use your experience, but if you cannot solve the problem after three attempts using your past experience, use a more analytical approach, i.e., Cause Analysis. *Step Three: Identify relevant changes* Those changes that occurred prior to observation of the problem and, based on these changes, develop a likely cause statement and verify it. We know that problems are caused by changes. They don't just happen; some preceding event occurs that, perhaps in combination with other factors, produces the problem. Investigate the environment around the problem and ask those who are familiar with the equipment/situation if anything changed prior to observation of the problem (ex: power failure, new software upgrade). This technique could very well surface the change that caused the problem. If you identify such a change, develop a likely cause and it cannot be verified (or if you are not able to identify any changes), proceed to Step Four. *Step Four: Use the horizontal process.* The key to using the horizontal process, (i.e., observed fact, comparative fact, difference change, likely cause) is knowing where to begin. The key strategy is to always listen and look for comparatives. No comparatives, no cause analysis. Here are some hints: If the problem has just occurred and has never happened before, enter the time the problem was first observed and compare it to the previous time period to identify some clues. For example, if we have a printer in our office for two years, and today it suddenly begins having paper jams, which has never happened before, look at what has changed in the past day or two. If the problem occurs in some physical or geographical locations, enter that point and compare the location where the problem occurs with locations in which the problem does not occur. For example, if I have a pager that does not work in the Alamo office in San Ramon but works when I visit the office in Houston, I would begin the search for clues by identifying the differences between the two locations. If the problem occurs on a non-random basis, especially if in a cyclical pattern, enter at the pattern question, compare the instances when the problem occurs with the instances when the problem does not occur. For example, every Monday, the mail is late, yet during the rest of the week the mail is on time. In this case I will generate clues by identifying how Monday differs from the other days of the week. *Step Five: Use the full process.* If you still cannot solve the problem at this stage it's time to use the full process. Fortunately, you would not be starting from scratch because you would have available the data gathered in Steps 1-4 and the rest of the process would be considerably less intimidating. At this stage, it is more than likely that the full process will clearly point out which specific data you need to proceed, and it is this data that will help you solve the problem. In this article, I've tried to present a process for using CA on the job. The process is very user friendly once you learn the basic flow from observed to comparative to difference to change. It is quite flexible and easily tailored to the demands of the problem. In summary, simple problems are solved at the beginning of the process, and complex problems are solved by the full process. Craig LaFargue is an Associate of Alamo's with the Anitoch Consulting Group. In addition to our programs, Craig specializes in performance for funcational work groups and teams. He can be reached at clf2@aol.com.