Most day-to-day root cause analysis (RCA) follows one or a combination of several steps.
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 analysis (RCA) follows 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.
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.
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β!