The Dilemma Of Recurring Problems

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.

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”!

More