Toyota Kata : Managing People for Improvement, Adaptiveness and Superior Results Page 10
The traditional approach for regulating production, which is still in wide use, is that each process in a value stream gets a schedule. These schedules are based on predictions of what the downstream processes will need in the future. Since humans, even with the help of computer software, cannot accurately predict the future, this approach is called a “push system.” That is, each process produces what we believe the next process will need and pushes that material on toward the next process.
The alternative approach for regulating production—Toyota’s “pull,” or kanban, system—is by now also well known, and its basic mechanics are summarized in Figure 5-12.
The customer process, here assembly, receives some form of production instruction. Perhaps this is a leveled production instruction as described on the previous pages under heijunka.
The material handler serving this assembly process regularly goes to the upstream store and withdraws the parts that the assembly process needs in order to fulfill the production instruction.
The supplying process then produces to replenish what was withdrawn from its store.
The difference with the pull approach is that production at the supplying process is regulated by the customer process’s withdrawals from the supplying process’s store, rather than by a schedule. In this manner the supplying process only produces what the customer process has actually used, and the two processes become linked in a customer/supplier relationship.
Figure 5-12. Basic kanban, or pull-system, mechanics
These mechanics of the kanban system are what we benchmarked at Toyota, and those mechanics are what we have been trying to implement in our factories for many years. However, as with leveling, our success with pull systems has not been so good. In many cases what begins as an effort to introduce a pull system devolves into just better-organized inventory, and the supplying process continues to produce to some kind of a schedule.
Let us use the depiction in Figure 5-13 of a material flow between two production departments to take a deeper look at Toyota’s kanban system. Each circle in the diagram represents one machine, and there are multiples of the same machine in each department. Each line in the diagram represents a path that parts may take, and any part number can be run on any machine. As is suggested by all the lines, currently the supplying department runs parts on whatever machine is available at the time. Also shown is the supervisor of the supplying department.
Figure 5-13. Material flow between two production departments
Now assume that we would like to insert a supermarket (kanban system) between these two departments, as shown. Perhaps we are doing this because the departments are located far apart, or maybe the machines in the supplying department have vastly different changeover times than those in the customer department.
To set up this pull system, we will need some information, which includes, among other things, part numbers, quantity, and the following two locations, or “addresses”:
Where, in the supermarket, the parts associated with a kanban card will be kept
On what machine the parts associated with a kanban card should be produced
The act of specifying the second address—of defining what parts should be run on what machine—helps us to see what kanban is really about at Toyota. How do you think the supervisor will respond if we ask him to define what parts run on what machine?
The supervisor is likely to object to someone taking away his flexibility to run the parts on whatever machine is available. Perhaps he will say something like, “If we are going to define what parts will run on what machine, and thereby reduce my ability to run items on any machine, then we better start improving the reliability of these machines.” And so kanban has already started working for us. It has shown us an obstacle, and now we need to roll up our sleeves and look into that problem.
I have heard many managers and engineers say, “We tried the kanban system, but it doesn’t work here.” To this, a Toyota person might well say, “Ah, kanban is actually already working. It has revealed an obstacle to your progress, which you now need to work on and then try again.” We gave up at the place where Toyota rolls up its sleeves and gets going.
Figure 5-14. Two different approaches
It is the same point again. Whether all those crossing lines—the flexibility to run parts on any available machine—look good or bad to you depends on your purpose (Figure 5-14):
If your purpose is “make production,” then the flexible system looks good because despite the existence of problems you can work around them and still make the numbers.
If your purpose is “survive by continuously improving,” then the flexible system looks bad. In fact, operating this way is not permitted at Toyota.5 Working around problems by making the same part here and there increases the number of variables and makes understanding the cause of problems considerably more difficult. Flexible systems that autonomously bypass problems are by their nature nonimproving. You may make production today, but will you still beat the competition tomorrow?
The Intention Behind Kanban
The overt, visible purpose of kanban is to provide a way of regulating production between processes that results in producing only what is needed when it is needed. The invisible purpose of kanban is to support process improvement; to provide a target condition by defining a desired systematic relationship between processes, which exposes needs for improvement. In a push system, processes are disconnected from one another and routings are too flexible. There is no target condition to strive for.
. . . according to Ohno, the kanban controlled inventories . . . served as a mechanism to make any problems in the production system highly conspicuous . . .
—Michael Cusumano, The Japanese Automobile Industry
The difference between the visible and invisible purposes of kanban is very much the difference between the implementation and problem solving orientations I described in Chapter 1. We have been trying to implement the visible purpose of kanban without the invisible problem-solving effort, but one does not work without the other. No matter how carefully you calculate and plan the details of a pull system, when you start up that system it will not work as intended. This is completely normal, and we are setting ourselves an impossible target if we think we can achieve otherwise. What we are actually doing with all our careful preparation for a pull system—as with so many Toyota techniques—is defining a target condition to strive for.
My colleague Joachim Klesius and I once visited a large, 6,000-person factory that had decided to get into lean manufacturing. When we asked the plant’s management what their first step would be, the answer was, “We will be introducing the pull system across the entire factory.” This not only reveals our flawed thinking about pull systems, it also simply cannot work:
Anytime you start up a pull system, it will crash and burn within a short time. There will be glowing and charred pieces, so to speak. But it is precisely these charred and glowing pieces that tell you what you need to work on, step by step, in order to make the pull system function as intended. Your second attempt to make that pull system work may then last a bit longer than the first, but it too will soon fail. And again you will learn what you need to work on. This cycle will actually repeat, albeit with longer intervals between the problems, until someday you have a 1×1 flow and no longer need the pull system. Keep in mind, by the way, that the kanban system does not cause problems, it only reveals them.
Pull systems are rarely the first step in adopting lean manufacturing. Many production processes are currently unstable, and the amount of inventory you would need in order to have a functioning pull system between unstable processes would be unacceptably high. That much inventory would be detrimental anyway, since you would be covering up instability rather than first setting other process target conditions that help you understand and eliminate that instability.
If kanban is a tool for process improvement, then it makes sense to introduce pull systems on a small scale first and expand
step by step as we learn more about and improve the relevant processes. If we try to introduce kanban quickly across an entire factory, an unmanageable number of problems will surface. Toyota’s organization could not handle that either.
All this means that just introducing a kanban system by itself will improve very little; the system only mirrors and sheds light on the current situation. It does not, for example, by itself reduce inventory. It just organizes and utilizes inventory.
This in turn means it is impossible to implement a pull system. We should think of and use the pull system as a tool to establish target conditions in our effort to keep improving toward the ideal state condition. Each state we achieve is simply the prelude to another.
This last point was made clear by remarks from two Toyota people. The first was: “The purpose of kanban is to eliminate the kanban.” While I was still pondering that one, I heard another Toyota person say: “We don’t know how you make progress without kanban.”
Ah-ha! Kanban is a tool to help us shrink the supermarket (inventory) over time and move progressively closer to 1×1 flow. That is why when a kanban loop at Toyota has been running trouble-free for some time, a manager might remove a kanban card from the loop. In this manner inventory is reduced, in a controlled fashion, and problems can begin surfacing again. Kanban is used to define successive target conditions, on the way to a 1×1 flow (Figure 5-15).
Figure 5-15. Kanban allows us to define challenging target conditions on the way to a 1×1 flow
Now Toyota’s Tools Make More Sense
Toyota’s tools and techniques become more understandable, and effective, when we view them in the context of striving to achieve a target condition by working step by step through obstacles. These tools and techniques are subordinate to the routine of Toyota’s improvement kata, not independent of that routine, and our failure to see this perhaps explains some of the limited success we have had in trying to copy them.
Simply introducing kanban cards or andon boards doesn’t mean you’ve implemented the Toyota Production System, for they remain nothing more then mere tools.
—Teruyuki Minoura, President and CEO 1998–2002,
Toyota Motor Manufacturing North America
If your primary objective is to “make products,” then many of Toyota’s techniques—which by their nature limit your ability to work around problems—actually make little sense. To “make products” you want to be able to jump quickly to another machine if one breaks down (kanban makes this more difficult), to change to a different production schedule when there is a parts shortage (heijunka makes this more difficult), and so on.
Toyota uses many of its tools, such as takt time, 1×1 flow, heijunka (leveling), and kanban, as target conditions in order to better see problems and obstacles. There is possibly an even more deep-seated and subtle reason for our missing this intention and for our limited success, so far, in utilizing those tools.
Take the example of takt time, where we monitor process output per shift or day, and thereby fail to recognize how much a process’s individual output cycles fluctuate. Perhaps we tend not to think about the individual process cycles because we have learned to manage by outcomes (rather than improving in small steps every day), tend to work with implementation lists (rather than target conditions), and feel we do not have the time to observe such detail. However, with many processes it only takes 20 minutes or so with a stopwatch to see if the process is fluctuating in or out of control. Despite such ease of analysis, I find very few companies where this is done. Why?
As discussed in Chapter 1, there is a human tendency to desire and even artificially create a sense of certainty. It is conceivable that the point here is not that we do not see the problems in our processes, but rather that we do not want to see them because that would undermine the sense of certainty we have about how our factory is working. It would mean that some of our assumptions, some things we have worked for and are attached to, may not be true.
In hindsight it seems somewhat foolish to have thought that simply implementing a kanban system or leveling scheme, for example, would result in significant and continuous improvement. The production processes themselves are still performing with essentially the same attributes as before. (There may be small, onetime improvements due to better organizing or paying closer attention.) We can now see that it is not actually the leveling pattern or kanban routine by itself that generates the improvement, but the step by step pursuit of conditions required to make those techniques work as intended. It is the striving for target conditions via the routine of the improvement kata that characterizes what we have been calling “lean manufacturing.”
An interesting side note is that since Toyota is pursuing the one contiguous flow ideal, then any solution, tool, or practice that does not yet equal that ideal can be thought of as a temporary countermeasure. For example, I am sometimes asked for a formula to calculate how many kanban cards one needs in a pull system loop. Viewed in the light of moving toward the ideal state, having exactly the right number of kanban is not important at the start. You just need enough inventory, or kanban, to hold the system together while striving to continually improve processes and reduce the necessary number of kanban over time. To want to know the precisely correct number of kanban at the start suggests that we are thinking in static rather than continuous improvement terms.
Mobilizing Our Improvement Capability
Putting our capability for improvement, resourcefulness, and creativity to use takes managing ourselves in a way that marshals that capability. If people act before having a target condition, they will tend to produce a variety of ideas and opinions about where to go and what to do. At each juncture they often end up shifting direction or simply selecting the path of least resistance.
Success depends on your challenge.
—Shinichi Sasaki, former TME President and CEO
In contrast, a target condition—that is, a target pattern—creates a challenge that depersonalizes a situation (not your idea versus my idea about what we could do) and brings people’s efforts into alignment. The diagram in Figure 5-16 based on an insightful sketch by my colleague Bernd Mittelhuber, depicts this well.
Of course, it is not enough to simply set a challenging target condition and hope people will find a way to achieve it. Toyota’s improvement kata requires more than just that, and in the next chapter we will look at Toyota’s routine for how to move toward a target condition.
Figure 5-16. What a difference a target condition makes
Target Condition ≠ Target
It is important to recognize the difference between a target and a target condition. A target is an outcome, and a target condition is a description of a process operating in a way—in a pattern—required to achieve the desired outcome (Figure 5-17). It may take some practice before this distinction becomes instinctively clear to you.
Unfortunately, when they are speaking English, Toyota people from Japan still often use the word target when they mean a target condition. This has led to misinterpretations by westerners who are accustomed to managing by setting quantitative outcome targets and focusing less on process details. When a Toyota person asks, “What is the target?” we naturally assume they are referring to a quantitative outcome metric. In actuality, a target condition as defined here is a good description of what Toyota people often mean when they say target.
Figure 5-17. Difference between a target condition and a target
The danger in not being clear about this distinction is that there are many different ways to achieve target outcome numbers, many of which have little to do with actually improving how processes are operating. Having numerical outcome targets is important, but even more important are the means by which we achieve those targets.6 This is where the improvement kata, including target conditions, comes into play.
For example, a quantitative cost reduction target by itself is not descriptive enough to be actionable by people in the organization. The overall goal may be
to improve cost competitiveness, but having that alone will tend to make people simply cut inventory and people.
Inventory-reduction targets are also very common, and when utilized without associated process target conditions, cause a lot of problems. For instance, I have a nice award on my office wall that was given to me for increasing inventory. The plant manager at this particular factory had decreed a target of no more than one day of finished goods inventory, and people complied with this by reducing inventory. The result was a tremendous increase in expensive expedited shipping, because one day of inventory was too low for the current lot-size performance of the assembly processes. What I did was point out that the process, not the inventory, should be the focus of our attention.
I once ran into this while touring a Detroit factory with a group that included a mostly Japanese speaking former Toyota executive. At one point on the tour the Toyota person pointed and said, “More inventory here.” We chuckled and said, “Oh, your English is a little difficult to understand, but we know Toyota’s system and of course you mean less inventory here.” To which the former executive exclaimed, “No, no, no! More inventory here! This process is not yet capable of supporting such a low inventory level.”
It is easy to say “reduce inventory” and much harder to understand the appropriate and reasonably challenging next target condition for the processes causing that inventory. The inventory around and in a process is an outcome, and there are reasons it is there. We need to dig into the related processes themselves, set the next process target condition, and then tackle the obstacles that arise on the way to achieving that target condition. Then we will learn what it is that requires us to have so much inventory,