From my previous post, you now have an idea on my position with Lean and Six Sigma. They fit together well so long as the Six Sigma problem solving rigor is subjugated to the Lean Methodology and Principles. One place that I’ve seen the two methodologies butt head’s is between Yokoten and Best Practice.
Six Sigma follows the DMAIC (Define, Measure, Analyze, Improve, Control) cycle for problem solving. During the Analyze phase, teams often look out to the industry to see who is “Best in Class” or has the “Best Practice” for the process the team is improving. This best practice is then adopted as the “To Be” state. The improvement phase then focuses on closing the gap between the As Is and To Be. This approach might work well if you work at the company where the best in class solution is implemented. If not, the approach usually fails.
It looks at the end result and it ignores the 5 Why’s that led to the solution. This approach ignores the question: what problem were they trying to fix? Many companies know they have a broken process. So instead of figuring out why, they spend time and money on consultants to bring them the best in class solution. Unfortunately, this solution was designed to fix problems that they might not have.
“But the best practice was implemented perfectly”, they say.
“The process is world class, so it’s not the process, it must be the incompetent people!”
And so the long line of throwing good people at a bad process begins. Insanity prevails.
Yokoten offers a bit of sanity to the mix. Yokoten means, horizontal dissemination of information. It’s about knowledge sharing, not just solution sharing. Yokoten in a culture is about spreading wisdom to other areas of a business that might do similar processes and letting them know what problems you had and what you did about it. It can manifest itself as a Lessons Learned activity which then updates the standard work for the next go around or highlights improvements for other teams not to that point yet.
This is not to say that yokoten zealots ignore best practices. On the contrary, they use them to speed the problem solving process. I experienced a good example of yokoten recently while working with a couple Toyota plants. Toyota brings me in occasionally to work on certain problems. I always enjoy going back to the mother ship for a little re-indoctrination. I did some work at the Indiana plant which they were pleased with. Then a few months later I got a call from the Lexus plant in Canada. They wanted to bring me in for a few days to discuss an issue they had.
When I arrived they said that the solution we came up with for the Indiana plant was highlighted as a “best practice” within the network of Toyota plants. So that was the reason for bringing me in. However, their first question was: ‘what were the problems they were trying to solve?’ They listed these on a board. They then pulled out their notes and said: ‘here are our problems and what we’re trying to solve.’ They then listed them next to the other list. We matched up the common problems and then highlighted the gaps. We then went on to come up with a solution that addressed all their issues.
They did two things here. First, they specifically understood their problem. They didn’t jump straight to the best practice solution. They took the time to understand all the variables impacting them. Second, they didn’t adopt the best in class, best practice blindly. They understand that the best practice is the best practice given a set of circumstances and doesn’t mean in every circumstance. As a result, they ended up with a best practice for them.
When you approach problem solving, you should absolutely consider best practices and leverage them. Look at what others have done but also look at why they did it. What problem were they trying to solve? Make sure you understand the problem you’re trying to solve and don’t short cut the process. Utilize best practices as a starting point, not a goal! If you’re always trying to implement the best in class process, you never will be.