Nightmare scenario: The phone rings and you learn with dread that the problem you thought you had gotten rid of a month ago is back and bigger than ever. Your stomach sinks and your pulse quickens, as you scramble to find out exactly what is happening. AND you know it is only a matter of time before plant management will be showing up at your door to have a “serious” discussion.
This happens all too often and takes precious time away from what we get rewarded for—getting product out the door. Worse, it moves us into what we get penalized for—fixing, again, what we were told was fixed for good.
Before we get to what to do now, let’s take a quick look to see what happened when we thought we got it right and what, in fact, went wrong.
Most day-to-day root cause analyses (RCA) follow one or a combination of the several steps noted below:
· “I know the cause.” (RCA Action—Brainstorming) Fix it and, hopefully, consider what could go wrong upstream/downstream as a result of the fix (Think beyond the fix).
· “I think I know the cause.” (RCA Action—Five Whys) Verify, fix it and “think beyond the fix.”
· “I have some ideas of cause.” (RCA Action—Fishbone) Use cause(s) from a Fishbone diagram, fix it and “think beyond the fix.”
So what happens in this process when they don’t get it right? It typically starts with the problem statement. In many cases Operators tend to jump to cause and record the problem in such vague terms that only they know what they mean. When you try to give them some structure, i.e., use the Five Why process, it goes something like this:
Question: “Why is production on line three slow?”….
Answer: ”The new tubes don’t fit”
Question: “Why don’t the new tubes fit?”…
Answer: ”The hole is too small to allow easy insertion”
Question: “Why is the hole too small?”…
Answer: ”I don’t know, it was fine for us yesterday”
Question: “What happened since yesterday?…
Answer: ”I don’t know.
Typically at this point the operator talks with others around him and with the shift supervisor and they come up with some “fixes” using a verbal fishbone discussion for ideas. Then they make the changes, document what they did—hopefully—and move on.
When Confirmation Should Replace Brainstorming
So what went wrong? First, five is not a magical number in the Five Why Process. Sometimes it requires additional questions to get to a valid possible cause. Ending up with “I don’t know” does not provide valid data to define a cause. It just indicates that more information is needed. It is important when using Five Whys to isolate and focus on confirming—not just brainstorming—answers that come from the previous question. Brainstorming, rather than focused, pinpointed questioning implies all answers are valid, which encourages Operators to apply many “fixes” to address all the answers. This just masks the real root cause and clutters up the data for future analysis should the problem return.
Keep Going: Find the Cause of the Cause
And here’s another thing that can go wrong. It is just as important to not define an intermediate cause as the “root” cause without FIRST testing it, based on the facts and data, to determine if it is the true cause. The pitfall of not checking the possible cause against the facts first is that it can cause Operators to drive their troubleshooting effort towards “known cause” fixes, which in many cases are unrelated to the original problem.
In the end, you can get better results if your Operators drive deeper in their RCA questioning and look for the cause of the cause like this:
Question: “Why is production on line three slow?”….
Answer: ”The new tubes don’t fit”
Question: “Why don’t the new tubes fit?”…
Answer: ”The hole is too small to allow easy insertion”
Question: “Why is the hole to small?”…
Answer: ”I don’t know, it was fine for us yesterday”
Question: “What happened since yesterday?…
Answer: ”I don’t know.
Question: “What is specified for the hole?”…
Answer: ”It is specified in the tooling setup”
Question: “What is specified in the tooling set up”?…..
Answer: ”What is in the tooling setup SOP”
Question: “Did we check what was set up for the tooling?”….
Answer: ”No we assumed it was good to go”
Question: “Let’s check.”……
Answer: ”Looks like there is an error in the data entry for set up during programming.”
By asking focused questions to isolate data that is specific to the problem, you CAN reduce your wicked problems to a critical few and avoid that nightmare scenario…“ITS BACK”!
