Nightmare scenario: The phone rings and you learn with dread that the problem you thought you had gotten rid of a month ago is\u00a0back and bigger than ever.<\/b> 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.<\/p>\n
This happens all too often and takes precious time away from what we get rewarded for – getting product out the door.\u00a0 Worse, it moves us into what we get penalized for – fixing, again, <\/em>what we were told was fixed for good.<\/p>\n 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.<\/p>\n Most day-to-day root cause analyses (RCA) follow one or a combination of the several steps noted below:<\/p>\n So what happens in this process when they don’t get it right?\u00a0 It typically starts with the problem statement.\u00a0 In many cases Operators tend to jump to cause and record the problem in such vague terms that only they know what they mean.\u00a0 When you try to give them some structure, i.e., use the Five Why process, it goes something like this:<\/p>\n Question: “Why is production on line three slow?” … Question: “Why don’t the new tubes fit?” … Question: “Why is the hole too small?” … Question: “What happened since yesterday?” … 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.\u00a0 Then they make the changes, document what they did – hopefully – and move on.<\/p>\n So what went wrong?<\/em>\u00a0 First, five is not a magical number in the Five Why Process. Sometimes it requires additional questions to get to a valid possible cause.\u00a0 Ending up with “I don’t know” does not provide valid data to define a cause. It just indicates that more information is needed. \u00a0It is important when using 5 Whys to isolate and focus on confirming – not just brainstorming – answers that come from the previous question.\u00a0 Brainstorming, rather than focused, pinpointed questioning implies all answers are valid, which encourages Operators to apply many “fixes” to address all the answers.\u00a0 This just masks the real root cause and clutters up the data for future analysis should the problem return.<\/p>\n And here’s another thing that can go wrong.\u00a0 It is just as important to not<\/em> 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.<\/p>\n 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<\/em> like this:<\/p>\n Question: “Why is production on line three slow?” … Question: “Why don’t the new tubes fit?” … Question: “Why is the hole to small?” … Question: “What happened since yesterday?” … Question: “What is specified for the hole?” … Question: “What is specified in the tooling set up?” … Question:\u00a0 “Did we check what was set up for the tooling?” … Question: “Let’s check”. … By asking focused questions to isolate data that is specific to the problem, you CAN reduce your wicked<\/em> problems to a critical few and avoid that nightmare scenario … “IT’S BACK!” …<\/p>\n","protected":false},"excerpt":{"rendered":" Nightmare scenario: The phone rings and you learn with dread that the problem you thought you had gotten rid of a month ago is\u00a0back 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 […]<\/p>\n","protected":false},"author":5,"featured_media":821,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"ppma_author":[112],"class_list":["post-24721","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-other"],"acf":[],"yoast_head":"\n\n
\nAnswer: “The new tubes don’t fit”<\/p>\n
\nAnswer: “The hole is too small to allow easy insertion” <\/p>\n
\nAnswer: “I don’t know, it was fine for us yesterday”<\/p>\n
\nAnswer: “I don’t know”<\/p>\nWhen Confirmation Should Replace Brainstorming<\/h2>\n
Keep Going: Find the Cause of the Cause<\/h2>\n
\nAnswer: “The new tubes don’t fit”<\/p>\n
\nAnswer: “The hole is too small to allow easy insertion”<\/p>\n
\nAnswer: “I don’t know, it was fine for us yesterday”<\/p>\n
\nAnswer: “I don’t know.”<\/p>\n
\nAnswer: “It is specified in the tooling setup”<\/p>\n
\nAnswer: “Whatever is in the tooling setup SOP”<\/p>\n
\nAnswer: “No we assumed it was good to go”<\/p>\n
\nAnswer:\u00a0 “Looks like there is an error in the data entry for set up during programming.”<\/p>\n