After coming across a confusing listserv discussion about value-stream mapping and some other concepts of lean, we asked LEI Senior Advisor John Shook, co-author with Mike Rother of the Learning to See workbook on value-stream mapping, to respond in order to clarify what mapping is — and is not. Here is his response. -LEI
This discussion thread was forwarded to me by a participant who requested that I join in to try to answer some of the questions being debated. I hesitate, honestly, to jump in here for fear of adding yet additional layers to the confusion. But, after reading the discussion, I feel compelled to dispel a few misconceptions and in the process perhaps answer a couple of the questions that have come up. But it’s hard to know where to begin. I think I’ll limit myself to discussing takt time, value-stream mapping (VSM), and “lean flow”, and I’ll discuss a little of the origin of some of these topics in the process of attempting to clarify how they fit into the issues being discussed.
First, VSM does not equal “flow analysis” or the process of designing and creating optimum product flows. VSM is a simple tool to help operation managers and engineers (and others) understand how their flows currently operate and to help guide them through the process of analysis to improve those existing flows and design better ones in the future. VSM as described in Learning To See (LTS) is not nor was it ever presented as representing the entire kit of tools to design optimum flow of product. VSM as described in LTS introduces none of the algorithms, calculations that are available to design optimum flow of product. If it did, perhaps it would be titled, “Optimum Flow Design.” Instead, it was given the curious title of Learning To See for a reason.
Learning To See does contain one small chapter on “Characteristics of a Lean Value Stream.” In this chapter, the most elementary, but essential, aspects of a “lean value stream” are introduced. However, the intent of the book was only to introduce the reader/user to a new way of thinking and looking at their operations. Thus, the description of takt time and the other concepts is necessarily kept very simple. As such, we believed the basic principles, concepts and tools described could be applied in a very wide variety of environments. However, the application of the concept/tool must, of course, vary according to the situation.
It is been misunderstood in some circles that VSM, or takt time, or “lean flow,” is only useful in highly repetitive, high volume, low variety manufacturing. This is a highly unfortunate and total misunderstanding. To explain, let’s review some history for a bit.
VSM is just a tool. As described in LTS, it is a tool to help people look at value streams rather than at discrete operations. For the most part, it seems that the book LTS and the tool VSM have helped many people and many companies.
The issue of designing or creating lean product flow, however, is a much, much broader issue. VSM relates to that broader issue in that it is a tool to assist in that design. But, VSM as described in LTS is only a beginning step in that regard. By “lean product flow,” I am referring to the material and information flows of the Toyota Production System (TPS). Among the key elements of TPS flow (the just-in-time pillar of TPS) is the concept you have been discussing: takt time. Takt time as a concept and tool predates theory of constraints (TOC) by decades.
Takt time, in great contrast to the way some have misunderstood it, is NOT primarily for use on highly repetitive assembly lines! And its primary purpose is certainly not for staffing determination!! Takt time was developed as a manufacturing flow tool in the 1930s. It was thoroughly developed by Toyota internally as a manufacturing management tool in the 1950s. By the late 1960s it was in widespread use throughout the Toyota supply base and was well known throughout Japanese industry by the mid-1970s. In the U.S., Takt time was a well-known concept by the mid-19802, well before the term “lean” was even introduced.
The purpose of takt time is, first and foremost, to serve as a management tool to indicate at a glance whether production is ahead or behind. It serves as an alignment tool, aligning proceeding with following processes, aligning resource requirements with demand, aligning corporate functions with real-time production needs.
Rather than being limited to “repetitive production situations,” takt time is actually most useful in helping establish flow under those very conditions when flow is especially difficult to establish or see. In fact, its first use (in 1930s Germany) was in the aerospace industry, where product flow was extremely slow and repetitive activities difficult to discern. Toyota adopted and further developed takt time in the 1950s to help them cope with their situation at that time, which was vastly different from their Detroit-based competitors, who were blessed with seemingly endless demand. Toyota at that time was producing volumes that were a tiny fraction of that of the Big Three (in 1950, Toyota as a company was producing in one month no more than each of the Big Three produced of one model on one assembly line in one day! And Toyota was producing numerous different models within that tiny volume).
From this you can probably see that another common comment – that takt time has no application in “low-volume job shops” – is also a misconception. Most of Toyota’s early suppliers were “job shops” and many of them still are. A purpose of takt time – the “alignment” issue mentioned above – is to bring them into the flow. Takt time is useful in situations where the product mix is complex, the flows are complex, the demand changing, and in various processing environments – Toyota’s Taiichi Ohno proved out almost all of the concepts in his machining shop before expanding to other areas. (This history of TPS and takt time is fairly well documented, in books available from LEI or Productivity Press, if you are interested in knowing more. Taiichi Ohno’s own Toyota Production System is a great place to start and Takahiro Fujimoto’s Evolution of a Manufacturing System at Toyota is an incredible – and often overlooked – book.)
Takt time as introduced in LTS uses the simple ACME Stamping example that has one simple takt time for two variations of the product. However, most cases in real life involve products with varying levels of demand, and thus various takt times. Thus, one mixed model assembly line may have a takt time of 58 seconds, but that overall takt time – or “compound takt” – may consist of many different individual product takt times. And those times each are determined and used to achieve alignment with their various upstream value streams. The math used to determine the mixed-model takt time (the heijunka mixed flow) has characteristics that are analogous in function and complexity to the TOC flow and routing calculations. (And it can be used, as Toyota uses it, for extremely complex BOM situations). LTS does not go into the calculations simply because explaining the techniques of routing determination was never intended to be the purpose of LTS. (To repeat, if that was the purpose, why would the book have such a curious title?) (Monden’s book, the Toyota Production System, is a good place to go to learn more about flow applications that are more complex than those presented in LTS.)
Some points of clarification regarding three final topics of your discussion come to mind. First, takt time is typically determined over a longer time period than was mentioned in the discussion (a shift, a day, and a week). Toyota typically reviews takt time on a monthly basis, with a “tweaking review” conducted every ten days. Some plants, however, may change their overall takt time very infrequently, though different models in the mix may see takt times changing frequently.
Secondly, there is a fundamental difference between TOC “bottlenecks” and TPS “pacemakers,” though they are frequently misunderstood to be roughly analogous. What is analogous is that TPS, like TOC, strives to identify and “break” bottlenecks. But, TPS does not allow a bottleneck to set the pace of the value stream. After all, the bottleneck may exist for any number of problematic reasons – excessive downtime, poor quality, long changeover times, etc. Why would I choose to let an operation with such problems determine the way I flow my entire value stream? Of course, I have to deal with the problem operation (the bottleneck), and there are numerous techniques to do so, but I will not let it dictate the pace (takt) of my entire product flow!
Finally, it is true that VSM as introduced in LTS ignores layout. Trust me, LEI and the LTS authors are aware there is such a thing as layout and that layout is indeed important. But, VSM intentionally delays layout considerations until after first making other observations and determinations. The reason is that many manufacturing managers and engineers tend to immediately jump to moving things around, which costs time, money, and other resources and frequently results in mistakes. Often, there is a flow solution within the existing layout. Look for that first. Think about rates of operation, what flows where currently, what should flow where ideally. Try first to exercise creativity without spending any money, which forces us to focus on the system, the methods we are using. Then do your layout analysis (which is certainly important, but simply wasn’t the focus of VSM as introduced in LTS).
Oh yes, someone had a question about a bottleneck operation in a flow-line cell. TPS would never combine — as one poster did “for simplicity” – run time with setup time. The point, from the TPS point of view, is to reduce the setup time to enable more frequent changeovers in order to reduce lot size. So, simply put, the TPS way would be to start with the theoretical capacity, the demand (over some period), determine the number of changeovers that are possible within lean.org Lean Enterprise Institute, One Cambridge Center, Cambridge, MA 02142 USA (617) 871-2900 those parameters, and then possibly determine run patterns or otherwise develop alignment with upstream and downstream processes (and yes, there is “math” for all that).
VSM and the various lean value-stream tools indeed exist within the tradition of industrial engineering as a discipline, as was mentioned in your discussion. They are mostly evolutions of tools that existed previously, but also involve major innovations over those previously-existing tools. Previous “process mapping” tools focused (as the name implies) on the “processes” whereas VSM focuses on the interdependence of the twin flows of material and information. Other mapping tools in common use among industrial engineers ignored information flow – without which an integrated material & information flow system obviously can be neither visioned nor attained. This emphasis on understanding production as an integrated material & information flow system is a major innovation of the Toyota Production System and a valuestream (or “process”) Map that ignores information flow is like a piece of sheet music that just lists notes randomly – you know what notes to play but not when to play them!
But, this is all less important than the main point of VSM, which relates to the reason we recommend VSM be done by hand. The point is not that the “absolute optimum product flow” is best calculated by hand. Of course not! But, do the central problems of American manufacturing revolve around the fact that we have inadequate queuing algorithms? Is what we need now yet another, bigger and better, software package? The value in creating the drawings by hand is that it forces the drawer to go look, observe, and to try to really see what is going on at the value stream – not just individual process – level.
Many mathematicians have shown me algorithms that they claim can attain “better material velocity through the system” than “Toyota’s pull system.” My reply is to them is always the same: “Perhaps, but you have completely missed the point.” The point rather revolves around observation and learning. Certainly, that may not sound as sexy as a new software package that will “spit out the ‘right’ answer.” But, there is no “right answer.” There is the answer we, as manufacturing practitioners and leaders, determine through leading our people through the process of truly learning how our value streams are truly operating. We have no shortage of ability to develop theoretical ideals. Our shortage is in our collective ability to implement, to innovate, and react to contingencies when things go wrong.
Learning to See was an attempt to address that need. Of course, LTS isn’t the complete answer to such a big problem. But, perhaps it was a start. To repeat, again, that’s where the title comes from. You draw a map, and, yes, you draw it from personal observation. That’s what’s important, not the map itself. What’s important is to try to really see what’s going on. In the case presented in Learning To See, the focus is on seeing at the plant door-to-door level. Then you can use the map to set a vision and manage to a plan.
I’ll post this and get out of the way, and hope I didn’t add to the confusion!