Lean implementation

In an invitation to the Lean Enterprise Academy ‘s Lean Summit 2014, David Brunt included the following summary of Lean since 1990:

“Early implementations focused on empowered teams and continuous improvement (kaizen) or attempts to replicate a pre-defined box of tools such as 5S, SMED, SPC and kanban. For others lean became synonymous with kaizen events – that were actually kaikaku – radically reconfiguring individual operations. For some, this led to them developing their version of Toyota’s famed Production System (TPS) including their own schematic ‘house’ or ‘temple’ of lean along with departments of continuous improvement specialists.”

It is a pretty accurate account of what happened — the only major omission being the omnipresent VSMs — and it goes a long way towards explaining why the vast majority of these efforts failed. They were limited at best to superficial details of TPS, included elements that were not part of TPS, and misjudged implementation priorities. Let’s us go through the list:

1. “Empowered teams.”  As a manager you have a team to work with. What decisions should you allow this team to make on its own? This is best subjected to the sleep-at-night test. Knowing that you are responsible for the outcome, what can you delegate to the team and still sleep at night? It obviously depends on the team. If it is a team of production operators with 10 years of TPS practice behind it, the answer will not be the same as if they are beginners. Implementations that start with empowering teams put the cart before the horse.
2. “Continuous improvement (kaizen).” Lean, or TPS, are often described as approaches to continuous improvement (CI), when CI is in fact only one component of the system. You cannot convert a plant from mass production to Lean manufacturing by continuous improvement, because it is not about tweaking details. For example, if you have implemented cells in machining or assembly, you can make them perform better with CI, but you have to have cells first, and that is beyond the scope of CI.
3. “Replicate a pre-defined box of tools.” It can work, if your situation is sufficiently similar to the one you are copying, you really know what the tools are, and you master them.
   • SMED and Kanban are tools of TPS but often misunderstood. For example, you often see SMED used to try to increase equipment utilization instead of flexibility, and Kanban is often confused with the two-bin system or even reorder-point.
   • SPC is not part of TPS. This is so shocking to American and European professionals trained by the Quality establishment that they just inserted it back in, regardless of what Toyota actually did. The latest examples of SPC control charts at Toyota are from the 1950s.
   • 5S is part of TPS, but is mistakenly assumed easy to implement because its technical content is trivial. In fact, the absence of technical content is what makes it difficult to implement and certainly unfit for an initial project.
4. “Kaizen events” are an American invention and not part of TPS. As Brunt points out, the name is misleading, because what they do is not Kaizen. The popularity of this method over the past 25 years and the confusion created by the name have in effect prevented Lean implementation from including the real Kaizen.
5. “Departments of continuous improvement specialists.” The creation of these departments has often made Lean implementation into a function alongside Production Control, Maintenance, or Quality Assurance, with the result of making it a professional specialty instead of part of everybody’s job. It works to make a good show for outside visitors, but not for much else. This department cannot be large enough to have the capacity to do all that needs to be done. Even if it did, it does not have the authority to make the changes take root in daily operations.

These efforts failed because the approach was simplistic. Both the technical and managerial content of TPS are deeper and take a while to learn. A successful implementation, particularly is a different industry, is not based on copying tools but on understanding underlying principles and deploying them as appropriate to the new context.