In the Kaizen process, we ask everybody to identify problems (or opportunities) and then to write down an idea that could potentially solve the problem (or at least solve it to some extent).
What’s written down on the card (or submitted into KaiNexus software) is the starting point for discussion within a team and/or with a supervisor.
When coaching an organization on Kaizen recently, I got a really good question from a physician who had taken the excellent week-long Lean healthcare training at the University of Michigan. She said that, in the Lean training, they said you should never “jump to a solution” in the course of problem solving. She raises a good point.
Many of the problems identified and brought forward through this Kaizen process don’t require any root cause analysis. That might sound shocking. Isn’t Lean all about “the 5 whys” and root cause analysis? Sure, where it’s needed. Root cause analysis happens a lot in Lean.
Some relatively problems, “Our IV trays are disorganized” have a somewhat obvious solution, “Organize the trays and remove unneeded items.”
We can just fix the trays and then recognize those who did so, share the idea with others, and then check back to see if the idea really worked and if it was sustained.
Some problems are more complex, such as “Patients are waiting too long in the waiting room.” We couldn’t really jump to a simple solution there. We’d want to do root cause analysis and maybe manage this through an “A3 problem solving process” or something more rigorous like a “Rapid Improvement Event” or a longer-project.
Or, we can break a bigger problem down into smaller pieces, taking care to not sub-optimize anything.
As Kaizen leaders, we learn how to triage things that are submitted through the Kaizen process. It this idea an easy “just fix it”? If so, we can have a bias for action and test ideas experimentally, in the PDSA approach. If it’s a more complicated problem or something with a non-obvious solution, we can start an A3 or get a Rapid Improvement Event sponsored.
This can all work together. We can’t oversimplify everything, nor should we overcomplicate everything.
A similar contrarian thought is that not every improvement needs to be a formal “Rapid Improvement Event.”
Thanks for reading! I’d love to hear your thoughts. Please scroll down to post a comment (or click through to the blog if you’re reading via email or RSS).