In a hotel restaurant there is a table with a juice dispenser. Next to the juice dispenser is a stack of trays with glasses. Sometimes the glasses run out, and a queue of customers build up. What is the best way to prevent glass outages?
I had a solution, but I wasn't happy with it. It involved using a photocell to detect when the glasses were in danger of running out. One complication was that the serving personnel could not easily see if the glasses were running out. The table with the juice dispenser is in an alcove. The, usually very busy, serving personnel move along paths that make it difficult to see the trays. If there is a queue of people waiting for juice, they obscure the trays, and any simple kanban mechanisms. Of course, if the arrival rate of thirsty restaurant guests is great enough, a queue may form even if there is plenty of juice and glasses.
I quickly got several suggestions on how to implement various kanban mechanisms to replenish the glasses. All of the suggestions were good, but only a few will work in the environment at the restaurant. (Or so I believe. I've been there only once, and it was awhile ago.) This was what I had expected, but one member of the group told me that my problem was a distribution problem, not a process scheduling problem, and therefore it would be more appropriate to ask the question in another group.
This sparked some heated debate. For once, I didn't wade into the thick of it. There were some big guns on both sides of the debate. One thing that became clear to me, is that there was a difference of opinion about some of the fundamentals, like what a pull system is, when to apply kanban or DBR mechanisms, and stuff like that.
I like diagrams. Mailing lists are not diagram friendly, so I thought I'd blog about my point of view. It allows me to describe the system under discussion with a diagram like this:
(Click the image to get a full size view.)
As you can see, the system has two legs, a glass leg, and a juice leg. (Some of it is conjecture. For example, I do not know if the restaurant dilutes concentrated juice, but it seems a reasonable supposition.)
The basic conflict, as I understand it, is described in the following evaporating cloud:
(Click the image to get a full size view.)
I asked about the reason for kanban not being applicable, and got the answer that the system is not a pull system because the operator of the system - the restaurant management - is not able to control the arrival rate of the work - the customers who want a drink of juice.
This seemed strange to me on two counts:
- Pull systems control the flow of resources in a production process by replacing only what has been consumed. This has nothing to do with controlling the arrival rate of customers. (Controlling the arrival rate of work orders is important, but it is not something that defines a pull system.)
- There was an assumption that the system was not a pull system, but suitable for a TOC distribution system approach. TOC distribution systems are pull systems.
For definitions of the term pull system, see
For explanations of the TOC distribution system approach, see
- Viable Vision, Ch 7. Distribution: From Push to Pull, Gerald I. Kendall;
- Managing Distribution According to TOC Principles, Amir Schragenheim.
Maybe there is some other reason to consider this a distribution problem? Well, distribution problems are primarily about sizing, composing, and placing buffers. The TOC distribution system is based on two ideas:
- Pool the inventory where there is the greatest predictability
- Use a pull system to replenish exactly what has been consumed at short intervals
On the other hand, proving that this is not primarily a distribution problem, does not prove that it is a problem that can be solved with kanban (or DBR). What does kanban provide? A visual aid that tells when to replenish a buffer in a pull system. Sounds rather abstract. How about translating it into something specific:
A visual aid that tells when to place a new tray of glasses next to the juice machine.
Much better. This is exactly what a kanban solution is. It also satisfies step 2 in the TOC distribution mechanism. Could it be that kanban systems can extend throughout the entire supply chain? Yes they can.
The kanban idea originated by studying how wares are replenished on the shelves of supermarkets. This is a classic kanban application, but it also ties into distribution problems. Supermarkets don't make anything, they are retail outlets, so they are fed by distributors.
A kanban system is just a signaling mechanism for replenishing resources used by a process stage in a pull system. Whether that pull system is a manufacturing system, or a distribution system does not really matter. That is not to say a manufacturing system and a distribution system are necessarily alike in all other ways. They are not.
Thus, the Kanban Juice War was caused by misunderstandings:
- It was not understood that the juice dispenser system under discussion is a pull system
- It was not understood that the TOC distribution system is a pull system
- It was not understood that it is irrelevant whether the system under discussion is a production system or a distribution system, because kanban is applicable to all pull systems
Focusing on buffering won't work, because the problem is the faulty triggering mechanism. Choosing between kanban and distribution solutions is also wrong, because kanban solutions may be a part of distribution solutions that are based on pull systems.
When someone misunderstands, the responsibility may lie with the sender of the message, as well as with the receiver. As I am the original sender, I may be guilty of garbling the problem description. Hard for me to say. The message seemed clear to me, but that proves nothing. If you understand the problem description it does not prove anything either. I have restated the problem, and I am using illustrations. This may make a lot of difference. On the other hand, if you don't get the the problem explanation in this post, then I have probably goofed in my original posting to the mailing list too.
The whole thing may seem like a storm in a glass of juice, but I find the Juice War interesting. If we "experts" can't agree on how to define a very simple problem like this, how are we going to sell TOC and Lean solutions to the people who need them so desperately? Why do TOC experts themselves use the Evaporating Cloud technique to resolve conflicts so rarely? Is it because the technique does not work? Or, is it because it does work very well? (I suspect the latter, probably because I find clouds very useful.)