The Truth About Kanban | Bill Waddell

Bill Waddell, intellectual sparring partner for almost 20 years now, has put out this video revealing “The Truth About Kanban”:

Michel Baudin‘s comments:

This video is just Bill’s talking head against the background of a brick fireplace with a few books on top, notably “Toyota Kata.” It contains no moving pictures of Kanbans in action and all you learn from viewing is in Bill’s words, and I have a few quibbles with these words.

I usually get impatient with this kind of video, because voice is a slow medium, and you would get the same information five times faster reading the transcript. But I have never met Bill in the flesh, and I was curious to hear his voice. It’s a good radio voice, albeit curmudgeonly, reminiscent of a younger Tommy Lee Jones.

Now, about the content, Bill makes three main points:

  1. What you use for a pull signal doesn’t matter.
  2. You can use Kanbans with long lead time items.
  3. The Kanban system is a mechanism to drive improvement.

I agree with Point 3, but find Points 1 and 2 problematic.

In Point 1,  Bill asserts that it makes no difference whether, “the information is on a card, embedded in a container, on a computer screen, in lights, or people just talking to each other.” It is like saying that using coins, bills, checks, or credit cards makes no difference because it’s all money. In practice, I don’t think many of us would gladly revert to carrying around purses of coins.

In my experience of the Kanban system, the choice of pull signal can make the difference between implementation success and failure. Even at Toyota, it doesn’t have to be a card, which in 1950s information technology; they have been using eKanbans for 20 years. The different types of pull signals support different replenishment protocols that must be sophisticated enough to do the job, yet easy enough for the humans involved to understand, and a simplification of their work. This is explained in Chapter 10 to 13 of Lean Logistics.

The term “demand pull” may be misleading, because, in the Kanban system, the trigger is not that a unit has been sold, but consumed. Toyota’s Kanban system does not trigger the production of a car whenever one has been sold, and dealers hold new cars that have yet to be sold. It comes into play after dealer orders have been processed into a master production schedule and items in that schedule sequenced through heijunka, with the goal of smoothing the consumption rates of components and subassemblies.  The Kanban system then kicks in to regulate the replenishment of components in response to the remaining fluctuations.

Bill’s Point 2 about long lead time items is puzzling. He asserts that using Kanbans for them is better than using forecasts but, using Kanbans to replenish an item is implicitly making the naive forecast that demand in the immediate future will equal consumption in the recent past. Naive forecasting is difficult to improve on a time scale of hours for products made at takt times in a few minutes, but the quantity you consumed in the past 30 minutes doesn’t tell you much about what you will need 4 months from now, which is a common lead time for auto parts procured from overseas.

An approach for dealing with such long lead time items is to have a logistics company operate a consolidation center near the plant and have the plant use Kanbans to order these parts from the consolidation center as a local supplier. It doesn’t solve the problem of managing the supply of long lead time items for the whole supply chain, but it gets it off the list of issues the manufacturing plant deals with.

Even with local suppliers, the Kanban system is not used instead of forecasting but as a complement to it. Rolling forecasts are issued to suppliers for information — sometimes as part of agreements that provide compensation for repeated errors — and these forecasts are for information only, with actual orders coming in the form of Kanbans. (See Chapter 17 of Lean Logistics.)

#kanban, #leanlogistics, #logistics, #leadtime, #demandpull

9 comments on “The Truth About Kanban | Bill Waddell

  1. KanBan is/was a mechanism to maintain alertness to the consumption-replenishment cycle. The frequency of ‘checking what’s happening’ is a critical part of keeping the flow synchronized to takt time, which is ultimately governed by actual customer demand. Inside the Toyota Production System (a closed system) demand is a managed producing variable based on many factors. KanBan works well for component supply internally and externally. Although you will never see a kanban signal generated on the final sale of an auto. There are other considerations that dictate when and where final vehicle sales are consummated. That’s why there Toyota Sales Company is separated from the Toyota Motor Manufacturing Company.

    Early in the development of TPS the kanban solved a devilishly difficult communications issue. The written kanji and kata-kana was not fluent among many of the many participants in Toyota’s supply chain. Neither were computers in common use in Japan, for mainly the same reasons (keyboard complexity). But there was general recognition of symbols (shapes in particular) and colors as well. So in order to maintain orderliness, placement of inventories was organized by color, shape, and other visually prominent means. For instance the Blue Section might be divided into the Circle sub-section, and then further by a circle outlined but only one quarter of it color filled solid, then 1/2 solid, 3/4 solid, then the whole. Then a circle with a donut hole on the same basis. Then a square shape, a triangle, an octagon, etc. This ‘system’ was permeated with numbers (as a double check) and extended to supply partners (and third party transporters) as a means to communicate where things should be located/delivered/receipted when transferring components.

    It should not be so surprising that fixed-quantity containers (mostly in multiples of Five for easy counting), and cards (colored and with the symbols and numbers) emerged as production volumes scaled. My first exposure to this was at Nippondenso in 1983 where they were introducing a bar code onto the cards. The barcode was intended to produce a receipt (via their cash register device) which could then be delivered to their Treasurer by the driver to submit for cash transfer at their bank (cash flow).
    It is also not surprising that western observers in the 1980’s misinterpreted this as something that was a clever way to manage inventories compared to the convoluted MRP method being used in the US.

    So much for “Toyota’s genius, or American naïveté.

    Ken McGuire

    • I am puzzled by your statement that “The written kanji and kata-kana was not fluent among many of the many participants in Toyota’s supply chain.” While the Japan’s script is overly complicated, the country has had a literacy rate on a par with Western Europe and the US for at least 150 years — 40% in 1868 and 99% today — and I have a hard time believing that it was an issue in the Toyota supply chain in the 1950s.

      Toyota Sales and Toyota Motor merged back in 1982. It remains, however, that Sales is Manufacturing’s single customer, and that the products it orders to be made may or may not be already sold. Otherwise, you would not see new cars for sale at dealerships.

      I see the Kanban system as a means or regulating the production and movement of items that are subject to moderate fluctuations in consumption around a stable average. The boundary of what “moderate” means are arbitrary: ±10% qualifies, but ±50% doesn’t. In between is a gray area. And the average must periodically revised.

      If you are making gun sights on a defense contract in peace time for 1,000 units/months for the next 10 years, Kanbans are overkill. If you are making toys for the next Christmas season, the swings in demand are too extreme for Kanbans to work.

      Kanbans are part of a set of different methods, applicable even within the same plant, for different categories of items, including consignment for nuts, bolts, and washers, reorder point for pellets of resin, and body-on-sequence for model-option specific components.

      If we were to accept Bill’s Point 1, we would make no difference between Kanban and Reorder-Point. As you pointed out, however, “the frequency of ‘checking what’s happening'” is critical, and this frequency is much higher with the Kanban system than with Reorder-Point.

  2. Rob thanks for explaining the purpose and role of Kanban. Kanban is a production control tool which will prevent the overproduction. Ideally there should be zero Kanban. Coming to Bill’s point I agree with point 1. It does not matter how you pass the production instruction. Production instruction has three elements Kanban,Sequence and material. In many of the service oriented operations Kanban is used in different form . Example if you go for the restaurant some of them use tokens as Kanban. You pay the bill in advance in the counter and you get the token with sequence number. The same information is passed to the kitchen which starts the production of the food. If there is no token for production kitchen will not produce. In auto dealer we have used vehicle itself as a kanban for some of the processes. In some of the production centre parts preparation staff monitor the vehicle in assembly line through camera and start the parts preparation once the vehicle reaches certain station in the conveyor. In point 2 I agree with Bill. If you see in the calculation of the number of kanban depends on order cycle ,lead time , delivery cycle . But if we reduce the order cycle time which means increase the ordering frequency and increase the delivery cycle the number of Kanban can be reduced. Even though the lead time is longer since the order frequency is high we adjust the order quality in later orders as bill told we can forecast better for tomorrow rather 6 months later. Only challenge is the scale merit for the logistics volume for frequent delivery . Depending ups geography we can use cross dock with milk run to get scale merit. Lead time will have no impact on on hand Kanban it affects only on order which is in pipeline. So I feel both the points are valid . It is just a personal view not any critical view . Thanks Michael for sharing.

    • Who is Rob? Bill put out the video, I wrote some comments, and so did Ken McGuire, but none of us is a “Rob.” You seem to consider that any kind of pull signal can be called a Kanban. But I don’t think it is helpful in a discussion of production control tools. Flagging a taxi by waving your arm is not using a Kanban. Kanbans may be tokens, but not every token is a Kanban. In the New York subway, you used to pay for rides with metal tokens, and they were not Kanbans.

      The distinctions between types of pull signals make a difference for practical reasons. A card, for example, may be detached from a bin, placed on a board, and attached to another bin. These are meaningful actions you cannot take if the bin itself is used as a signal. And, if you use electronic messages, you can’t attach them to bins.

      If you use the Kanban system for an item with a 4-month lead time, what you receive today is in response to signals emitted 4 months ago. Why would you want today the quantity you consumed 4 months ago? If you get deliveries from a crossdock center, the crossdock is your supplier, and its lead time is not 4 months.

      • Mystery cleared: “Rob” is Rob van Skekelenborg, and his comments were on LinkedIn. See below.

  3. Comment in the TPS Principles and Practice discussion group on LinkedIn:

    I’m not in full agreement either, particularly not with Bill’s first point, although the 2nd one is a challenge and requires more than just the kanban.

    But let me focus on the first point. Regarding this, I vividly recall a visit to Toyota (our customer at the time) with some of our plants. One of our plants presented the use of SAP’s kanban system with the visual statuses that come along with it. At the end of the presentation they were told “they didn’t understand a thing about kanban”… The key reason was that it shouldn’t (only) be seen as a scheduling system but also as a means to increase autonomy on the shop floor.

    A kanban is just a part of a kanban system (kanban hoshiki), which again is part of the just-in-time pillar, which is again part of the Toyota production system. It serves several functions besides the production control function to restrain overproduction and to level the load:

    1. A simple, physical means to implement (a part of) the JIT concept on the shop floor. As an example, in 1985, Cusumano wrote that the physical exchange of kanban was central to the Toyota production system. Sugimori and Cho in 1977 also referred to this aspect to reduce the administrative cost

    2. A timely communication tool: to enable all processes to quickly gain accurate knowledge of the timing and quantity of parts required (one of the JIT requirements). Toyota sought a way to communicate (a) timely (in sync with its cycle time), (b) not too early (as this can only create confusion) and (c) sequentially (following the production sequence upstream).

    3. A visual control: to engage in standard work and subsequently to enable swift detection (by all) of abnormalities using Toyota’s principle of “management-by-sight”. It links the JIT pillar with the jidoka pillar in the TPS (for more on this I refer to http://dumontis.com/2016/04/delivering-promise-kanban/).

    4. A tool that enables self-regulation and rapid and precise acquisition of facts on the shop floor as also described by Sugimori and Shingo in their writings. It is well known that Toyota sees kaban as the autonomic nerve of their system. It promotes Toyota’s principle of “making full use of worker’s capabilities”. It provides autonomy to the shop floor in managing the flow. Toyota’s OMCD also states that by using Kanban, operators shoulder this important management function.

    5. Via the visual control function, and the continual lowering of the number of Kanban, the Kanban system promotes continual improvement. Besides this “technical” function, it also brings the improvement responsibility back to the shop floor when it is implemented as a physical card (as described before).

    For all of the above, I do think that it matters a lot on how you actually implement the kanban system on the shop floor.

    • About Kanbans being “simple.”

      One Kanban loop is a simple system; 1,000 loops in one plant, not so simple.

  4. Hi Michel, thanks for cross-posting.

    And about kanban being simple: I fully agree. You need to carefully think about where to decouple and why, considering technical constraints, lead times per kanban loop and loop boundaries versus team boundaries.

    But even single kanban loops can be pretty difficult. To testify, I just helped implementing one kanban loop (one of many) that involves a material flow from a factory (my client) to a subcontractor directly to a cross-dock platform (to be mixed with other parts, including make-to-order items) and then onward to a consigned stock under VMI at their client. And we want to visually represent all of this to ensure autonomy of the team at the factory, and to ensure they can take responsibility for the contractual agreed stock levels and service (also on MTO). I can tell you, that isn’t that simple! But it works and we use kanban cards to do so!

    Furthermore, I think far too many consider kanban as a logistical technique only. It is, but should not be implemented alone without leveling. But is is far more as I tried to explain in my earlier remark..

  5. Great points! Few simple ideas that anyone can take on board. We’ve recently started to use an internet-based kanBan for a small furniture manufacturing shop. We keep the board online – on pages of http://kanbantool.com – and the shop signals when items are needed for ordering and when products are ready for delivery. Works like a dream. And I agree, that the key part is making the process better and simpler all the time. It’s not easy, but it is what we strive for. Thank you for this to-the-point video.

Leave a Reply

Your email address will not be published. Required fields are marked *