Stage 4 and the identification of root cause is, arguably, the most difficult and the most poorly executed.
Here Mark took us through a detailed process to move from the prioritised problem to possible direct causes.
But often, it isn’t done well and in many cases may not fix the actual problem we set out to.
Toyota, on the other hand, uses a systematic problem solving process which carefully frames the problem, finds true root cause and uses experiments to test countermeasures to ensure the problem is fixed once and for all.
We have included a number of our favorite rockpets from the Zen garden to help support the message and hope you enjoy this fresh overview.
For more infographics or slideshares please feel free to stick around on our channel and check us out.This is a fundamental building block of Toyota’s success and is practised by all employees at all levels.In a practice-based workshop, Mark Davies, Senior Manager at Toyota Lean Management Centre UK, took us through the 8 step problem solving process :- 1 – Clarify the problem2 – Breakdown the problem3 – Set a target4 – Analyse the root cause5 – Develop countermeasures6 – See countermeasures through7 – Monitor the process and results8 – Standardise successful processes Toyota understands that stages 1 – 4 are key to ensuring the right problem is tackled and in the right way.But, when I had the chance to work with a former Toyota leader, Pascal Dennis, I was fortunate to learn this more precise 8-step model. If you've been practicing Kaizen as daily continuous improvement or "rapid improvement events" or using A3 thinking...or "doing PDSAs" or small "just do it" improvements, I think the Practical Problem Solving (PPS) methodology is an important thing to know... Sometimes, slightly different terms or words get used, but the idea is the same. Steps 1 through 5 are "Plan," and steps 6, 7, and 8 are the "Do, Study, and Adjust" phases. Before jumping into root cause analysis, we have to first make sure we understand the problem.Problems can get messy and convoluted so it’s often confusing to teams as to which specific aspect of a problem to focus on.Step 1 and 2 are important to stratify data, often using Pareto to breakdown the problem.Recently I was reading It almost felt trivial that this sort of framework would be invaluable to software engineers too (in fact for everyone). And finally countermeasures, evaluations, and countermeasures. Here from the direct cause, we expose and go deep to the root cause of the problem by asking WHY five times. 4th Why – Why CPU reached 100% – Because server instance size was not enough to handle increased number jobs. 5th Why – Why server size was not enough to handle the spike in usage – Because our auto-scaling is slow.When confronted with a problem, first we want to make it crystal clear and get a grasp of the real point of cause. By asking a series of 5 whys, we can generally get to the root cause of the problem and fix it there instead of just duct-taping it and be waiting for it to rise again.This step is fixing the root cause of the problem so that this doesn’t come up again. Moved to a more sophisticated auto-scaler to manage spikes in usages and setting up alerts to monitor the performance. “Now analytics are always in sync and even if they miss getting updated, we get an alert to know it beforehand and take action.” This resonates with another Toyota principle ofmeaning building in the quality.After the countermeasure have been executed, it’s important to evaluate the effect post that. How can we standardize the countermeasures such that similar problems are not faced again?