The Correct Sequence for Implementing Lean Systems

Looking through some of my notes from seminars, salons and study sessions I participated in during November and December, I came across an interesting string of characters: JID > JIT > TWI > SW > TQC? This was code to myself whose meaning luckily I had not forgotten. The question came up during a discussion on how to design lean operating systems and how to implement lean system.

Much of the discussion and teaching, questions and discussion was around the importance of team identity, properly selected, trained and motivated team leaders and the problem solving dialogue that goes on between members and leaders of teams. Anyone with passing familiarity of the lean lingo will recognize that JIT is Just In Time, TWI is Training Within Industry, and TQC is Total Quality Control. JID was shorthand for jidoka and SW is Standard Work (capitalization is not necessary).

The students in one of my seminars observed that I was placing a lot of importance on the people aspects of lean, and yet in describing the history of the development of the Toyota Production System TWI comes roughly as the third major system implemented after jidoka and just in time. Was this the correct sequence for implementing lean systems or should we start with TWI before attempting to flow and pull, establish standard work or to have andon response systems?

But even this question needs to be placed in larger context before it can be answered properly. Teachers of lean who come from a heavy machining background tend to emphasize process stabilization before flow. While those from discrete parts assembly will emphasize using flow to expose problems and instabilities. Those who are experts in lean accounting will see doom in not starting off first, or at least very early, with getting the right accounting and measuring system in place. Those with backgrounds in organizational development or psychology will see the benefit in making sure all people systems are in place before making major changes to process systems. Lean strategy experts who gravitate to the boardroom may insist that hoshin kanri must come before any serious shop floor implementation. None of these approaches is wrong, though each may be more or less appropriate depending on the situation. Always insisting on a single approach despite the particulars of the situation is what leads to mistakes.

Let’s take the classic Toyota Production System house. At the foundation of the classical TPS house is standardized work, kaizen and heijunka. Heijunka is the base, but almost nobody starts here. The corner stone of standardized work, or at least documenting standards, is well respected. Kaizen in its fullest meaning as practical problem solving is lost on many, with the kaizen event being the main format. A smoothed and sequenced production volume (heijunka) is often cited as a prerequisite for stable just in time production. Heijunka relies on small lot sizes, which relies on SMED which relies on 5S which relies on leader standard work and zone control which lead us to people on teams. So when we explore the various systems we can quickly recognize the linkages and even what we might call correct sequencing.

Yet there are as many versions of the house of lean as there are companies attempting to implement lean. There is nothing wrong per se with customizing and modifying the TPS lean model, provided convenient cherry picking of the tools and systems is avoided. I can still recall frustrating discussion from a few years ago in which I failed to persuade the client that “the 10” chosen and non-negotiable lean tools agreed after so much discussion by their steering committee and the Lean Promotion Office, were a path to failure. Establishing a closed list of lean tools and a rigid sequence for implementation is like building a temple with only limited understanding of geometry, masonry and architecture. Even if the masonry doesn’t come tumbling down, you might end up with just half of a building, not unlike the ruins of the sanctuary of Apollo pictured above. A more pragmatic and open-ended approach is best, realizing that there is no king’s road to success in lean implementation, though there are many ditches.

What is the correct sequence for implementing lean systems? We need to ask three questions; What is the greatest area of need for the business? What is the greatest gap in lean success factors? What is the likely set of lean systems or tools that will be most immediately useful for this organization? The ability to answer all three questions requires a solid knowledge of business fundamentals, expertise in evaluating organizations from the people side, and more than a passing knowledge of the lean tools and systems.

All lean systems rely on people to succeed, and people rely on each other. Nearly all lean systems rely on team leaders and small teams working toward a common purpose. I can’t see getting there without tapping into all of the aforementioned systems and more. The best and most concise answer to the question may be, “Do first things first, then next things next.”

What’s the correct sequence for implementing lean systems, in your experience?

2 Comments

  1. Bruce Baker

    December 27, 2009 - 6:48 am

    Good question. There isn’t one best order. History (experience) doesn’t always tell you exactly what to do, but it will more frequently tell you exactly what NOT to do. One thing that I have learned is that pull is important. In all three of the organizations that I have done this in there was a general belief that pull was really advanced and would have to be done “after a high level of stability is achieved by implementing all the foundational tools.” This is wrong in most cases. In my experience you should look for those sections of your EXTENDED stream where you can flow (in smaller batches if not one piece) and where you need to pull. Make getting those things done your purpose.
    What I mean by that is — you may not be able to flow until you get some SMED done on mach A, you might have difficulty pulling in a section of you stream until you level (heijunka) demand some. Then those are the things that you should get started on. I did a post on my blog a couple weeks ago about the ‘why’. It wasn’t about the problem solving why (unknown whys). It was about the known whys. These are the purposes behind what you are doing. If you understand why you need to take action then you will know (I may be violating fundamental tenets of epistemology but work with me) what to do. Usually, from a system design standpoint I have come to value synchronization with demand as philosophically predominant. The only way I know how to do that is with some combination of flow or pull. I have found that that there are usually many things to make those thing feasible, could be: SMED, batch size reduction, right-sizing of equipment, moving machines together, poka yoke, SW, and that is not the whole list. Usually do a pretty detailed EXTENDED stream map helps to organize thoughts quite a bit. I am probably biased towards flow because I cut my teeth in discrete manufacturing.
    All that being said (which is a bout systems), I think it is best to start on some of the organizational / people stuff. In my experience the best way to get all that system stuff implemented is to get people involved. People will need to understand the PURPOSE (the why) behind what they are doing so training and maybe even some education will be in order. People will need some mechanism, kaizen blitzes, structure changes that allow rapid day to day improvements, etc. Once again the purpose predominates the what. Sometimes teams are a good mechanism to get people involved and let them do a lot of the change.
    Finally, getting people to understand that coming up with a hypothesis and giving it a try QUICKLY instead of making everything a 4 – 6 month, 12 defined and rigid step six sigma project with 5 ppt presentations to senior leadership. This last part is probably in my belief structure because lean has followed six sigma in all three organizations in which I’ve done this.
    So to sum up. I think the right order is to go way up the ladder of abstraction to find synchronization and then use that purpose to decide the order while helping people understand then support them in getting things done.
    I’m sure that isn’t what you want Jon. But I have learned through experience that there is no order of implementation on the tactical level and that purpose (the why) must predominate over the tool (the what) and that you need people who all share a common professional philosophy to get it done.
    Starting SW, TWI, and 5S (5S with real purpose not just aesthetics) as many people do never hurt anybody though. Maybe just makes the whole thing go slower.
    Bruce Baker
    http://leanisgood.wordpress.com/

  2. Jon

    December 27, 2009 - 5:13 pm

    Thanks Bruce for the very thoughtful response.
    The “why” certainly belongs before the “what” and “how”.
    We need to help corporations cure their fear of heights so they can climb higher on their ladders of abstraction.
    “The only thing I know for sure is that I do not know for sure.”