So far…
We are on our way to finding the reasons for poor customer turnover to Ben’s Pizza outlets in our story.
In the earlier two chapters, we saw the application of FMEA and Fish-bone Analysis.
We have discussed Fishbone Analysis to generate the list of potential causes and verify their completeness. Thus, we call it ‘an exhaustive list of potential causes’ in the Analyse Phase.
Now
We assembled after the evening coffee break. Meanwhile, I spoke to Anand and requested the second team working on FMEA to join the remaining part of the day.
We had a full house gathering and we could sense that with the noise reaching outside.
When I entered the hall, they talked to each other about FMEA, their findings, the fishbone etc. I felt good at their involvement in the project.
The Heart of an Improvement Initiative
They started settling down quickly after seeing me taking the centre table. I stood behind the table, facing them, and slightly leaned at the table, keeping my both hands to support.
I pretended as if I was clearing my throat, as I heard people murmuring. Then I started.
“Friends, I am really happy to see your focus and determination of going through the grills of DMAIC and in solving your problems,” and looked at Ben, who was sitting extreme right of the last row. He nodded in acceptance and with an expectation of what is coming next.
I continued, “If we consider the Analyse Phase is the heart of Six Sigma problem-solving, then we have to consider Root Cause Analysis the heart of Analyse Phase. This step is very crucial in our problem-solving journey.
Because, if we are not comprehensive in this stage, then the failure of our project is certain.
That is the reason, we dedicate more time in this phase than any other phases of DMAIC,” I spoke. Everyone listened silently and acknowledged the importance of Analyse phase.
I wanted to break the monologue. Hence, pulled them with a question, “Do you remember the roadmap of Analyse Phase?”
“Yes, Sir” they chorused.
The Objective
“The objective of analyse phase is to find out the prioritised and validated root causes of the problem,” Mr Ganesh perfected the answer.
I saluted Ganesh and continued, “Yes, the objective is to find out the root causes. What are the steps have followed so far in our journey to find the roots?”
“We have collected all potential causes through FMEA method and the other team members have worked with Brainstorming technique. We have collected all potential causes for our problem in hand. Then, we applied Fish-bone technique to see whether we have sufficiently covered all the 6Ms” narrated Pawan.
In every company and in every project, we come across such people, who are very much into the system; they grasped the essence of the method and clear with why we do and what do we do.
I bowed to say I am impressed and showed a thumbs-up to Pawan. I looked at Ben and he was also happy. When he realised why I continued to stare at him, he applauded to praise to Pawan.
Three Scenarios of Root Cause Analysis
I continued, “Now, let us move on to the Root Cause Analysis. I would like to answer Ben’s question – which he asked just before we break for coffee”.
Ben was deeply thinking about something. “Ben, can you please repeat your question?”
“Well…, which question?” he asked.
“The question you were asking about the use of Fishbone diagram for root cause analysis”, I replied.
He realised that he was off the track and took few seconds to recollect himself and the question.
Then he asked, “Just wanted to know. Are we going to use Fishbone diagram for our root cause analysis? Or we are going to use the table as your showed in your case study?”
“My straight answer to this question is we are not going to use Fishbone diagram for the root cause analysis. However, people use it to find out the root causes. Before I say why I am not recommending this tool, we will discuss its actual application at its origin. And before that, we need to understand various scenarios that warrants problem solving”. I opened my laptop as I was speaking and displayed a slide.
When do we deploy problem solving?
I continued, “We often start analysing a problem during these two situations – one, when there is a failure incident. For example, there is an accident that caused an injury to a staff, something that went terribly wrong with a customer, and such incidents. When the severity of the incident is high then we choose finding the cause of the problem. In the above example, the risks are injury and loss of a customer.
In other case when an incident – that happened a few days back, manifests into another problem, then we would analyse that incident. For example, a customer comes to the outlet and tells that the pizzas they received last week were not cooked completely. Here, it is a failure incident and has a significant impact to the customer experience. Hence, we must try to solve this problem”.
I looked at their faces, they were seriously listening. I looked at my indicators. Usually, trainers would choose few people among the participants as indicators. Their faces would show the interest level of participants.
The third scenario is when you experience recurring problems or frequenting category of problems.
1. We take actions against the problems we observed and for some time we think that the problems were solved. But after a while, the same problems occur.
2. We also see accumulated cases, like customer complaints, internal failures, etc., and choose a category of problems to solve.
3. In some other cases we observe a worrying trend of data, indicating a future failure. We would want to take actions proactively to avoid such problems.
Root Cause Analysis for a recent failure incident
We hear a lot of examples for this category of RCA to emphasise the power of RCA. This is something like,
A manager walks into the shopfloor and finds the floor dirty. It was not acceptable to the standards of the company.
Manager (to the operator nearby): Why the floor is dirty?
Operator: There is a continuous oil leak from the machine. To avoid spread of oil on the floor and to prevent accidents, I applied some saw dust and sand. That’s why it looks dirty.
Manager: Why oil is leaking from the machine?
Operator: Oil is leaking from the joint.
Manager: Why the oil is leaking from the joint?
Operator: Because the oil seal does not fit appropriately.
Manager: Why oil seal does not fit appropriately?
Operator: Because the oil seal is not intended for use in that joint.
Manager: Why a wrong size of oil seal is used here?
Operator: Because the stock of the exact size oil seal was not available in the Engineering Stores.
Here, cleaning the floor repeatedly is called containment action of managing the problem. It will not solve the problem permanently. Instead, if the manager ensures stock availability of such spare parts, it can prevent recurrence of oil leak here and in similar other machines.
Are you with me?” I asked them.
“Yes” was their unanimous answer.
Finding Root Causes for a past incident
“Kannan, this scenario explains the power of why-why analysis, as you mentioned. It also proves that one problem might have only one root cause. Am I right?” curious Anand asked.
“Wait Anand, wait! This case explains the power of root cause analysis. It helps us identify the root cause of a failure that is currently happening.
However, let us think of the second scenario. Here, the problem had happened in past. The past can be yesterday, last week, last month or last year. How can anyone find the exact root cause that had occurred and resulted in the failure? If a customer complains to you saying that she did not like the pizza which she ate last month. She says the pizza was not cooked fully.
Anand, how can you manage this case?” I asked.
Anand started hesitantly, “We need to talk to the concerned person who had delivered the pizza and track backward to the kitchen and chef. Then we might study why that pizza got delivered uncooked”.
“Anand, do you think the real-life situations would be straight forward as you said?”, interrupted Ben.
Anand kept thinking.
“In fact, the real-world scenario would be much more complex”, I said. “The waiter who served the pizza or the chef who cooked the pizza – which the customer ate might not know that the pizza is uncooked. They would not be able to recollect any further details about the pizza in question”.
“Yes, Kannan. I agree with you”, said Ben. “We need to take a different approach here. Even if we try to probe further, we cannot be sure of the validity of the reasons they share”, he said.
“Correct”, I said, and Anand started to understand.
How-How Analysis
“Instead of asking ‘why did you deliver the uncooked pizza?’, we need to ask, ‘how an uncooked pizza can get delivered to a customer? This question calls for brainstorming. People must spell out all the possible causes that can lead to this failure”, I continued.
In this situation, in the Japanese shop floor, the Leader of a small group would identify a sufficiently large board or a wall space to conduct Fishbone analysis.
“I prefer calling this technique as How-how analysis. Because in real sense this is what we are asking during the brainstorming sessions; and not why-why”.
“Then the people belonging to the concerned process will gather at a regular interval in front of the fishbone and brainstorm ‘how a machine failure would lead to the problem?’, ‘how a method failure would lead to the problem?’ and cover all the six causes. They will continue to brainstorm and fill the bones. Therefore, fishbone analysis is called as structured brainstorming technique.
“Hey, Kannan, then this is a new tool! Shall we call this kind of analysis, where we synthesise scenarios as ‘How-How’ analysis?”, Ben was curious, and his high energy indicated he wants to venture into something new.
“Of course, Ben, we can. But such developments take time. Asking ‘why’ talks about the past and ‘how’ talks about the possibility. However, we will keep the nomenclature discussion after today’s session”, I kind of winked at him and continued.
Next
We will discuss Breaking the bones in Fishbone – Removing the non-evidenced causes and responding to the trends of failure by building robust processes and preventing recurrence of the problem in the coming chapters.