This Powerpoint training file shows the 5-Why approach with an example that everyone can understand.
After receiving this training, team members will understand the differences between symptoms and root causes, and will a technique and mindset to identify root causes using 5-Why.
This first slide provides an introduction and gives credit to 5-Why founder Sakichi Toyoda. Bullet #1 is the most important: the goal here is to change with way we think about problems, taking our focus off symptoms and finding root causes.
This slide defines a symptom as a problem that comes to our attention. We can often “make symptoms go away,” but they will more than likely return in the future if we do not address the root cause.
This slide defines the root cause as the reason behind the symptom. It all begins with asking “Why?” Correcting a root cause will prevent similar symptoms from occurring in the future.
This is a thorough 5-Why example with animation. Time can be taken to get the class engaged with questions like, “What do you think happened next?” One thing not in the training – in this case the problem solving team sent the broken hose to the forklift manufacturer to find out why it failed. If the team had not taken that initiative, they would not have arrived at the root cause.
This slide shows the added effect of addressing each “Why?” When we get to the last “Why?,” we benefit from the preventive action that goes with written maintenance procedures. The result will be fewer breakdowns across all equipment, not just forklifts.
Even though the early Why’s do not uncover the root cause, we will often implement containment measures based on our findings. Example: replacing the hydraulic hose in the example above does not address the root cause, but it does get the forklift running again.
Here is the 5-Why worksheet that brings it all together.
This class exercise gets the class thinking about their problem solving approach, now that they understand the value in finding the root cause. Many teams would react simply by replacing the product. But there is likely a root cause that will surface again, with other customers!
We wrap up with a class discussion to further emphasize the importance of root cause analysis. Teams that develop the habit of “fixing” symptoms may find themselves consumed with reacting to problems instead of improving their products and processes.