We have started the Analyse Phase in the previous chapter and we saw the high-level roadmap.
Analyse phase starts with the single question of ‘why our process capability is low?’. Ask this question in a brainstorming session and list down all the causes.
I assigned the team to work on listing down all the suspected causes that come to their mind through brainstorming sessions. Generating such a ‘Mutually Exclusive and Collectively Exhaustive’ list of suspected causes is the first milestone of this phase.
It was a Monday morning. Ben called me.
“Kannan, we accomplished your task. Both the teams are ready with 40 suspected causes each. You may confirm your visit plan this week”, he said.
“Hey Ben, that is great. Hope you are happy the way your team is shouldering you in turning around your business?” I replied.
“Yes, Kannan, very much. In fact, they have taken charge for this initiative” his voice carried all his enthusiasm. He continued after a pause, “See, our ‘internal rejections’ (project) team is feeling not fully confident about the completeness of their brainstorming. We have got more than 40 suspected causes, as you recommended. But, they feel like…. something is still missing”.
I requested him to send the list of causes they derived and told him that we would discuss in detail during the review.
Utilising principles of FMEA in Analyse Phase
I landed in Chennai on Thursday early morning. This time Anand had come to accompany me to Pondicherry. We discussed the status, especially the ‘internal rejections of pizza base’. We managed to change the sequence of review for the day, to accommodate the ‘internal rejections’ team first.
They were ready and waiting for us when we reached the factory. I asked for feedback from the team. My favourite Ganesh Ji from Procurement, Chefs Shekhar and Balaji and Pawan from Engineering are part of the team. Ben joined after a few minutes. He already informed me about his appointment with the bankers that morning.
“Ganesh Ji, Anand told me about your team’s commendable work in identifying the suspected causes. But he also did mention that your team is not happy about the outcome. Can you please explain to me in detail?” I asked.
“Yes, Kannan. We had conducted a few rounds of brainstorming and came out with around 40 suspected causes. But we feel these points are not comprehensive. Mmm… in your words, we do not feel they are collectively exhaustive. At the same time, we could not move further”, said Ganesh and waited for my response.
“That is amazing Ganesh Ji. You and your team would have done it well. It takes much confidence to say ‘we are stuck’. I am happy about it” I said.
“Generally, brainstorming is a good exercise to start. But there are certain circumstances which push us beyond brainstorming”, I said. “We can try using tool FMA – a derivative of FMEA – Failure Mode and Effect Analysis from the Auto Industry”.
What is FMEA?
Ben has also joined the discussion.
“Ok, let me take a quick theory session for 30 minutes because this is an essential tool.
FMEA was developed by Americal Army to improve the quality of supplies before the 1960s. By early 1960s, NASA started utilising the power of FMEA in improving the quality, reliability and safety of their spaceships and rockets and also insisted that its suppliers have to use the method to identify potential risk to the quality of components.
Then American civil aviation has adopted the methodology, which was followed by the automobile industry.
Predict Potential Failures
FMEA is a structured methodology to identify potential failures in the system. We call this as risk identification, prioritisation and mitigation tool. The method utilises the expertise of people working in a process and streamlines their thinking towards finding out the risks in it.
Find out the failures before they occur
Let us understand some basic definitions.
We earlier saw. Failure is an instance of not meeting expectations. For example, ‘the pen is not writing’ is a failure. The expectation from the pen is to write; hence, when the pen is not writing it becomes a failure.
The ways and means of a failure to occur. There could be different ways in which the pen may fail. They are
- Not at all writing
- Not writing continuously (intermittent)
- Ink pours out of the pen.
- Writing not legible / visible (very light)
We drill down each failure mode for potential causes. What can cause this failure?
Then we proceed on to prioritise the risks by scoring the scenario based on the following” I said while displaying the picture on the screen.
Risk Prioritisation Number (RPN)
“We then rate all the potential causes based on the RPN, which is the product of Severity Score (S), Occurrence Score (O) and Detection Score (D). Higher the RPN higher will be the risk associated with that cause.”
When to use FMEA over brainstorming?
“There are certain circumstances when FMEA will be more effective than brainstorming”, I said and showed the next picture.
How to conduct an FMEA?
Process Flow Chart
“The first step of FMEA is to construct an expert team who has deep and thorough knowledge about the process in question. Then we draw a detailed process flow chart. Each step in the process would have an objective to accomplish.
For example, in the case of the baking process, all the pizza bases are passing thought the baking oven. What is the purpose of the baking oven?” I asked.
“To bake the pizzas”, “baking”, answers poured in.
Ganesh, who was silent so far, said, “to provide consistent heat at the set temperature”.
“Precise!” I said animating applause.
“Ganesh Ji, can you please explain?”
“Sir, We do not expect the baking oven to bake the pizzas. The oven does not know what is baking. We set the temperature, and we set the time. It provides the temperature across the champer consistently”.
“No one can explain this better than this, Ganesh Ji!” I said.
“So, when do you call the baking failed?” I threw the question open to everyone.
“Improperly baked pizzas,” said Chef Balaji. I looked at him with my palm on the forehead, as if I am looking at someone from a distance. Because that was the first time, I hear Balaji speaking.
“Ok, let us understand in detail – what is improper baking?” I asked. I took the pen and asked Balaji to write the points on the board.
He wrote their answers –
“These are the failure modes,” I told.
“We will assess the severity of these failure modes, ” I continued. “What will happen if the base is ‘Unbaked’?
“We can’t use it further.”
“Is it going to affect customers?”
“Well, not exactly. We will check the base before we proceed to the next step. So, it will not go to the customer. But it would definitely cause delay” said Balaji.
“Will the material be lost?”
“Sometimes. Otherwise, we would reheat the base to get the right baking. So, it is the loss of time and electricity” answered Balaji.
“Similarly, what about overbaked ones?”
“It is highly risky. Most of the times, we could not identify the overbaking. There is a high possibility that it would reach the customer, and then they would complain about the charred smell. Or they would feel hard base” he said.
“There is a loss of material and time.”
We rated the failure modes for their Severity based on the above discussions.
“Good job, Balaji! Good job, guys! This is how we assign scores for each of the failure modes based on their severity”.
I enquired Balaji whether he is ok to continue writing. He replied affirmatively.
“We will move on to the third step of FMEA – Finding out the potential causes for failure modes and assessing their occurrence. This is similar to our earlier brainstorming technique of finding all suspected causes” I said.
“Sir, I have a point to share” Ganesh came back into action.
“When we did our brainstorming for suspected causes, I felt like we were shooting in the dark. But I felt a grip on the situation as you explain FMEA. Here as we go step by step covering the entire process in sequence. I feel FMEA is significantly different from brainstorming. This is my opinion; I am not sure I am right”.
Ben and Anand acknowledged the point, and I bowed marking my surrender to his opinion.
“Okay, let us go ahead and work out a sample of cause analysis,” I said and asked them “How could the base come out of oven unbaked?”
Balaji wrote their responses on the board. Then I asked them to rate each of the causes for their frequency of occurrence.
I appreciated everyone for the achieved milestone.
The next step is to score each of the causes for the length of time between the occurrence of the cause till its detection. The lengthier the duration higher will be the detection score. We can also consider this score as ‘Control Score’ because we assess our process against whether it has sufficient controls to check or detect the occurrence of potential causes.
If a potential failure can be detected immediately upon its occurrence, then the occurrence score will be the least. If the potential failure could not be detected within the system and only a customer can detect and complain, then the score will be maximum.
What is FMA?
Ben was curious. His tilted head with shrunken eyes and broad forehead showed that he was unable to resist asking a question. So, I invited him, “Ben, do you have a question?”.
He opened up immediately, “Kannan! I do not get this right. Why are we going to rate all these ‘potential causes’ in the analyse phase using FMEA? or we are going to do it for root causes? Because you said, the objective is to prioritise root cause”.
“You are right, Ben. You are clear and correct with the objectives of the analyse phase. We chose the FMEA as a remedy the too generalistic approach of brainstorming. In this phase, we don’t need to work down to the detection scores and RPN. Even we do not need to provide severity scores for this purpose.
All we need is the comprehensive list of failure modes and then the list of all potential causes. FMEA provides the sequence and opens our thinking with the modes of failures. Rest of FMEA will be utilised in the Improve Phase.
So, I recommend calling this as FMA. I covered all the aspect of FMEA here to provide a holistic view of the tool. Here, we restrict ourselves with Failure Modes and Cause Analysis. I projected the image on the screen as I was talking to them.
Ben felt relieved.
I requested the team to complete the analysis of Failure Modes and Potential causes for the remaining process steps before the end of the day.
“Though I know it will be a daunting task, I request you to try to complete the exercise by today. Then we will start the root cause analysis tomorrow” I said.
After assessing the situation, Ben announced, “Don’t worry guys, You can do it. A grand dinner from Home-Party Pizza will be arranged tonight if you guys need to extend!”
Laughter covered the hall and we broke out for lunch.
We have covered brainstorming for suspected causes and FMA for potential causes to generate a mutually exclusive and collectively exhaustive list of causes. In the next chapter, we will discuss Validating Brainstorming for Completeness using Fish-bone Analysis. Then we will move on the Root Cause Analysis.