Monday, June 11, 2018
Five Guidelines on Effective 5 Why Analysis
Asking why 5 times: “the 5 Whys”, is a simple but powerful tool to use with any problem solving activity. It’s a technique to help you get past the symptoms of a problem, and to find its root causes. Simply ask the question “why” up to five times.
Sakichi Toyoda, one of the fathers of the Japanese industrial revolution, developed the technique in the 1930s. He was an industrialist, inventor and founder of Toyota Industries. His method became popular in the 1970s, and Toyota still uses it to solve problems today.
Taiichi Ohno gave this example about a machine that stopped working (Ohno 1988, p. 17):
1. Why did the machine stop?
There was an overload and the fuse blew.
2. Why was there an overload?
The bearing was not sufficiently lubricated.
3. Why was it not lubricated?
The lubrication pump vs not pumping sufficiently.
4. Why was it not pumping sufficiently?
The shaft of the pump was worn and rattling.
5. Why was the shaft worn out?
There was no strainer attached and metal scarps got in.
Without repeatedly asking why, we would likely replace the fuse or pump and the failure would recur. Keep asking why until the root cause is reached and eliminated.
Here are some guidelines to doing a 5 Why analysis correctly:
Five is not a set in stone number. It’s not the guaranteed magic number. It does usually force you to push deeper than most feel comfortable, in most cases. Think about it like this. It might be something that takes asking why seven or eight times or maybe three is adequate. The key point is to not just accept the first answer to the question: Why did XX happen, because it’s probably a symptom of a deeper cause, so you have to keep asking why until you get out of the symptom level and into the root cause level.
Take time to do it right. Don’t think you need to gather everyone to have one meeting and finish it by the end of the meeting. All possibilities in the brainstorming activity should be investigated and validated as true or not. This quite possibly will require team members to seek out more information and report back. There’s nothing wrong with this. I’d advise to not let this turn into an excessive break in the problem solving process, especially in more urgent matters.
Brainstorm with a group. Unless you’re a one person business, take advantage of the different points of views of the team. Always include the person that is the closest to the problem, this is usually an employee from the floor. I don’t know how many times I’ve seen a group of managers or engineers argue about a theoretical cause while ignoring the fact that the person that was physically present during the problem probably knows exactly what happened.
Don’t punish employees for telling the truth. Many times they will have information, but with-hold it in fear of getting in trouble for not doing or saying something earlier. This is why Lean can only truly exist if a “blame free environment” is created.
Look at things from different perspectives. Examine every detail. Don’t assume that something is happening correctly, verify that it is. Think about the cause of the problem form outside of the proverbial box. After all, the solution is unknown at this point, so the cause could be absolutely anywhere, even in the most likely of places.
Bonus Tip:
Get out of the office. The Japanese term Genchi Genbutsu means to go to the place where the work is done. Ask questions. Observe the work for a while. Look at data that is relevant to tracking down clues. You may have to ask for some additional data to temporarily be collected if needed.
5-Why analysis is more than just an iterative process or a simple question asking activity. The purpose behind a 5-why analysis is to get the right people in the room discussing all of the possible root causes of a given defect in a process.
Many times teams will stop once a reason for a defect has been identified. These conclusions often do not get to the root cause. A disciplined 5-why approach will push teams to think outside the box and reach a root cause where the team can actually make a postive difference in the problem, instead of treating symptoms.
Posted by
Tim McMahon
at
6:00 AM
Labels:
Problem Solving,
Quality
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment