Chatter as Signal

As I promised, I am going to continue to over-play the afternoon my team spent with Steven Spear.

In his forthcoming book “Chasing the Rabbit” (to be published in the fall), he profiles what is different about those companies which seem to easily be increasing their lead against competitors when there is no apparent external advantage.

One of the core concepts he discussed was the nature of complexity in organizations, processes and products. It is the way this complexity is managed and handled that distinguishes the leaders from the pack of competitors that are fighting and jostling for second place.

In a complex system, there are invariably things people miss. Something is not defined, is ambiguous, or just plain wrong. These little things cause imperfection in the way people do things. They encounter these unexpected issues, and have to resolve them to get the job done.

This is “chatter” in Spear’s words. The sound made when imperfect parts try to mesh together.

Most organizations accept that they cannot possibly think of everything, that some degree of chatter is going to occur, and that people on the spot are paid to deal with it. That is, after all, their job. And the ones that are good at dealing with it are usually the ones who are spotlighted as the star performers.

The underlying assumptions here are:

  • Our processes and systems are complex.
  • We can’t possibly think of and plan for anything that might go wrong.
  • It is not realistic to expect perfection.
  • “Chatter is noise” and an inevitable part of the way things are in our business.

On the other hand, the organizations that are pulling further and further ahead take a different view.
Their underlying assumptions start out the same, then take a significant turn.

  • Our processes and systems are complex.
  • We can’t possibly think of and plan for anything that might go wrong.
  • But we believe perfection is possible.
  • Chatter is signal” and it tells us where we need to address something we missed.

We have all heard about Toyota’s jidoka and andon processes, so let me bring out another example, again, that was used by Spear.

The U.S. Navy has been operating nuclear reactors with a 100% (reactor) safety record for nearly (over?) 50 years. And they operate a lot of nuclear reactors. When they started, they were in totally new and unfamiliar territory – they were doing things that had never been done before. In fact, no one was even sure if it was possible.

They asked the question: How should this nuclear reactor be operated? They answered it with a set of incredibly specific procedures which everyone was expected to follow – exactly, without deviation in any way. These procedures represent the body of experience and knowledge of the U.S. Navy for operating nuclear reactors.

Here is the key point: ANYONE who departs from the procedure, in any way, no matter how trivial or minor, must report “an incident” which rockets up the chain of command. The reasons for the departure are understood. If there was something outside the scope of the procedure, the new procedure covers it. If something was unclear, it is clarified.

This may not be the Toyota Production System at work, but it is a version of something that makes it work: Jidoka.

If the process is not working, can not work, or conditions are not exactly as specified for the process to succeed, then STOP the process, understand the condition, correct it, restore the system to safe, quality operation, and address the reason it was necessary to do this.

Chatter is signal.

So – at a Toyota assembly line in Japan some years ago, I observed a Team Member drop a bolt. He pulled the andon cord and signaled a problem.

More about Overburden (Muri) in Health Care

The last post got way too long, and I wanted to get it out there. But of course, there are afterthoughts.

At a level higher than simple process chaos, overburden hits the entire organization when perceived demand is significantly greater than perceived capacity.

As I noted in the earlier post, segregating what should be routine from the true exceptions goes a long way, especially when there is work to continuously improve execution of routine things. This results in less capacity being used to process routine, and therefore, more capacity available to handle the true emergent stuff.

The next phase is to repeat the process, step by step, on the exceptions. Identify what makes them exceptions. Is there another process that can be isolated and segregated? Can you move something from “exception” to “routine” in some way?

Then look at what is left.

About 20 years ago, Philip Agre wrote a seminal PhD Dissertation at M.I.T. called “The Dynamic Structures of Everyday Life.” If you can find it, read it. This work was a major contributor to turning the science of symbolic artificial intelligence on its head. One of his conclusions was that almost everything we do is routine, and we do non-routine things in routine ways.

This thinking applies to complex, one-of-a-kind process situations. What “experience” brings to the table is knowing what things, that we know how to do routinely must be done; in what order; to gain control of the uncontrolled; and get the desired outcome.

In our heads, this is much messier than we want to believe it is. Fundamentally what we do is to try something we believe will have a certain effect, then see what effect it actually has. If the effect is the one we predicted, then we are one step closer to control and the stage is set for the next action; if not then we learn what did not work, gain a bit more understanding and try something else.

This is also how we build that thing called “experience” step by step, stretching our understanding, moving what we do not know into what we do. We do this as individuals, but it is only a truly exceptional organization that can do it as an institution. Learning is a process of prediction, testing and comparison.

The objective in these situations is to move an unknown, uncontrolled situation gradually toward familiar ground and make it into something routine.

Steven Spear quoted a health care worker that summed it up pretty well: “Air goes in and out, blood goes round and round. If either of those is not happening, we have a problem.” And in the most extreme medical emergency, the first steps are always to stabilize vital signs so that the patient will live long enough for the caregivers to understand the problem and develop countermeasures.

This is still, however, a customized sequence of tasks that should, themselves, be routine. Only the macro level varies. The more that can be done to stabilize the delivery of treatment to the patient, the less harried people will feel. They should not worry about the small things so they can pay attention to the big things.

The weak points in a complex system are the interconnections. People are not sure who should do, or has done, what. There are repeated transfers from one caregiver to another, often with far less than complete information – leaving it to the next caregiver to assess the situation all over again. Every time this happens presents an opportunity to overlook or misinterpret something that is already known.

By working very hard on execution of the things that should be routine, that much more mental capacity is made available to care for the patients. This means attacking ambiguity where ever it is found.

Mura, Muri (and Muda) in Health Care

Corrie van den Hoek, a regular reader and correspondent from The Netherlands, is working on applying kaizen in the health care industry. She left a comment on ‘The White Board’ asking my thoughts on the concepts of mura and muri in the health care field.

I think it is first important to define the terms because (1) Not everyone has heard them and (2) The translations from Japanese can differ a bit.

Mura is usually translated as “inconsistency.”

Muri is usually translated as “overburden.”

Mura and Muri are the brothers of the better-known Muda, which, of course, translates as “waste” or “unnecessary work.”

I am aware that it is possible to split hairs on the translations, but I think these suffice for the sake of discussion.

Like any industry, Health Care has a product to deliver (treatment of patients) and the administrative processes that support the care givers, patients, and keep it running as a business. There is huge room for improvement in both of these areas, and of course problems in one have impact on the other.

I started to get to these issues in this post, but did not go into any depth. The cool thing is that the article I was writing about in a general sense is actually written from a health care context. So I highly recommend reading it as some additional background.

Muri – Overburden – “Asking the unreasonable or impossible.”

In the article, Tucker and Edmondson refer to an “error” as doing something inappropriate or unnecessary, and a “problem” as something which interferes with accomplishing a task in the specified way.

Problems as Overburden

They cite a typical example of a problem. A Team Member’s task is to change linens. This task is routine. She goes to the storage area for linens on her floor, and finds none. She goes to another floor, and perhaps another, and ultimately finds the linens she needs, then returns to the task she was trying to accomplish in the first place. (She at least did not have to hire a taxi to deliver fresh linens from the service, as other caregivers reported they had done.)

At the end of the shift, however, I would wager this Team Member wasn’t able to get everything done. Or she had to hurry to do things. Perhaps the work left undone is now passed to someone else and will disrupt their work. All of this is an example of overburden – asking (or implicitly expecting) Team Members to do more than they should, or more than they can. At the very least, the floor she took the linens from now has fewer than they probably need, and another safari will be launched from that floor tomorrow.

In this case, the Team Member is implicitly expected to “do what must be done” in order to deliver care. There are no avenues to address, or even call out, the existence of these problems. Calling them out carries at least an implied professional or psychological risk of being branded a complainer, or “not a team player.”

Indeed, working around these kinds of issues is a major source of satisfaction and pride in the work culture. I quote from a quote in the article:

Working around problems is just part of my job. By being able to get IV bags or whatever else I need, it enables me to do my job and to have a positive impact on a person’s life – like being able to get them clean linen. And I am the kind of person who does not just get one set of linen, I will bring back several for the other nurses.

For management, the question is a simple one: Is this task one which you would deliberately design into this person’s work process? If not, then question why it must be done at all. But you can’t just question it. That implies the person doing it is doing something wrong. She isn’t. She is doing exactly what must be done to do the job she was given. Question why it must be done so you can remove the necessity to do it.

The Muri of Unnecessary Life-and-Death Decisions

Overburden is also the case where a Team Member is asked to make multiple perfect decisions in high-stress situations. I am not talking about deliberate decisions about, for example, what type of care to deliver. Rather I am talking about the simple decisions that are repeatedly forced on Team Members during the routine delivery of care. Many of these seemingly simple decisions are overburden because the Team Member should not be asked to make them at all. Making them adds to the work stress because, in medical care delivery, the consequences of an error can be catastrophic in terms of “negative patient outcome.”

A case that comes up time and time again in examples I hear – both from literature and in my own conversation with people inside the system is a classic one: A Team Member selects the wrong small vial of colorless liquid from a shelf or tray and injects it into a patient. Sometimes this is harmless. Other times it is fatal. These mistakes, however, only get the attention of the system when there is harm to the patient. And the attention of the system is nearly always focused on finding out who did it and assigning blame.

Steven Spear recounts a typical case in Fixing Health Care From The Inside.

He cites an investigation into a case where a woman recovering from routine surgery suddenly developed seizures. Her blood sugar level crashed, she lapsed into coma and died. Here is a key point from the investigation:

a nurse had responded to an alarm indicating that an arterial line had been blocked by a blood clot, and he had meant to flush the line with an anticoagulant, heparin. There was, however, no evidence that any heparin had been administered. What investigators did find was a used vial of insulin on the medication cart outside Mrs. Grant’s room, even though she had no condition for which insulin would be needed.

Instead of asking “Why did the care giver administer insulin instead of heparin?” how about asking “Why was insulin even in the room in the first place? This is simple 5S – eliminating the things that are not needed. Actually no. This is somewhat advanced 5S, because it is eliminating the things that are not needed NOW. Perhaps it is appropriate to have insulin in the room for some patients. But it apparently was not appropriate for this patient. And even if there are non-routine conditions which could require insulin, then the insulin should be stored in a place that forces a conscious and deliberate decision to retrieve it.

Key Point: Separate the routine from the non-routine. Separate normal from abnormal.

Another example was cited directly to me by a friend who works in Health Care. In another big-name big-city hospital a woman was in routine surgery. A staffer in the operating room chose between two clear vials of clear liquid, picked up the wrong one, and administered a cleaning substance to the patient, killing her.

Of course this scenario begs exactly the same questions as the one above it. If it doesn’t go into the patient, why is it in the room at the same time the patient is? And if must be in the room, why is it accessible in a routine way to a routine process?

Spear points out that for every death or serious injury there are many instances of these errors that do not result in serious problems, and many times that number of instances where the error is almost made, but it caught and corrected in time.

This is, in my opinion, a form of “overburden” because people are being asked to make decisions that have life-and-death consequences, and those decisions are entirely unnecessary if someone would only ask “Why did this person have to choose?” instead of “Who made the wrong choice” or (a little bit better) “Why was the wrong choice made?”

Whenever we inject ambiguity into the situation (or even allow ambiguity to persist) we are expecting someone – who may not expect it – to see it and resolve it.


Most times the proposed solution is around better labeling and identification. But I would like to suggest that “mistake proofing” is actually a process of:

  1. Systemically eliminating sources of errors by eliminating choices;
  2. If that can’t be done then putting up barriers that stop the process if an error is about to occur;
  3. and if that can’t be done by doing something that breaks unconscious routine in a way that forces the person to notice the impending error.

Better labeling falls into the third category here. Ask tougher questions, and support your people better.

What about Mura, or inconsistency?

Traditionally this is about a widely varying workload. In industry, the countermeasures are to establish a takt time, apply production leveling, set cycle times to the takt, and in general, work hard to keep the workload as even as possible. There are a lot of good benefits to this and the performance of the companies that do it very well suggests that doing it is worth the perceived costs and trouble.

One of the things frequently cited by Health Care is how their workload is wildly variant and unpredictable. These perceptions are certainly not unique to Health Care, but it is probably worthwhile exploring the situation from their context. I certainly don’t expect the Health Care community to make the leap from consumer goods or dump trucks to patient workloads and processing insurance claims.

Based on my limited dealing with Health Care, I am going to do a little conjecture, then attempt to go from there. If I am totally off base with my assumptions, feel free to correct me in a comment, and I’ll re-think.

As I see it, two big drivers for high day-to-day variation of demand on the system are:

  • Patients can show up at any time. This is especially true in Emergency Services, where, by definition, demand is unprogrammed.
  • Each individual case is potentially unique, or at the least, any one of them could go from routine to non-routine at any time.

Does that about capture it?

Shifting The Thinking A Bit

Not everything I propose here will work every time – there are true exceptions out there. But, in general, at least one of these concepts have usually helped people find some foundation of stability they can leverage.

Rather than looking at a varying aggregate workload, start breaking things down into individual streams, and finding components of stability within the variation.

Workload Variation

This graph represents a wildly varying workload. Most reasonable people are going to look at this and conclude they pretty much have to either be ready for anything, in any form, at any time.

But even in the face of wide demand swings, it is a rare operation the experiences -zero- or close to zero demand. There is some element which is reliable. Perhaps that element is small, but, at some level, it is usually there.

At first you probably won’t be able to control the wide swings, but what you can do is apply the principle of isolating instability.

Elements of Variation

This is exactly the same graph as the first one. The difference is the shading. The consistent part of the workload is shaded in green, the unstable or varying workload is shaded in red.

If you look for sources of stability, vs. causes or sources of instability, most operations can usually find something to leverage. This works particularly well in administrative processes, but I’ll work on applying it to the care-delivery flow in a bit.

An Administrative Flow

(Thanks to the GHC team for making me think about this in their context)

Imagine, if you will, a routine administrative process that is carried out many times a day. Many, if not most, of these processes involve something along the lines of:

  • Getting some initial piece of information that triggers the process itself.
  • Confirming known information, frequently doing routine research to gather more information.
  • Summarizing that information in some formal manner – a report, a request, a transaction.

In my little example a process just like this one was experiencing wildly varying workloads from day to day. Some days they could process 15 or more, other days they would get bogged down with one. Some days they would receive a lot, other days they would receive a few. The Arrivals followed all of the queuing models – work arrived in batches, in distribution biased to the right, with a long left tail. The team was working Saturdays and long hours just to keep up, and was often getting further and further behind.

To level the workload we had to do two things. First, we needed to understand the actual demand over some reasonable period of time. We took a week since that time interval matched the kinds of deadlines they were usually under. Your mileage may vary. Based on that, we looked at how many per day they needed to get through, every day, to keep up with the demand they were experiencing. From that we established a nominal takt time of an hour.

For the cases that arrived reasonably complete, and were reasonably routine, one person could easily complete the work in an hour. The first countermeasure, therefore, was to put an upstream filter into place. The idea was that one person would be dedicated to routine transactions. The supervisor would do a quick review for completeness, and if the “routine” criteria were met, they would be placed in the appropriate work queue.

This process had a built-in check. The assumption being tested was that a complete case should take an hour to process, never longer. If a case took longer than an hour to process, it should not have been placed in the “routine work queue.” Thus, at the 60 minute mark, if the processor was not done, he kicked that one out of the work queue, back to the supervisor and started the next one.

This process immediately stabilized and accelerated the throughput on the vast majority of cases which were, in fact, routine. Everything went faster because they were no longer stopping the entire train to deal with an exception. The routine stuff went through routinely. They isolated variable processing from routine processing.

Of course they didn’t ignore the abnormal cases. There were two types of exceptions to handle.

  • The case that should have been routine, but was not because it was lacking something required to process it.
  • The case was truly an exception – something difficult or complicated, which even with complete information, requires more work than normal to be processed.

In the first few weeks, the team had a lot of cases get kicked out of the “routine” work queue. Then the numbers started to drop. This is because, each time, the team learned a little more about what causes line stops, and did a little better job:

  • Defining what they needed from their upstream processes, and making sure they got it.
  • Screening the incoming work to make sure it was set to process routinely and quickly.

What about the true exceptions? These, of course, remained. But they no longer clogged up the pipeline and stopped processing of the routine. The true exceptions were managed from a priority queue with a visual control. The other team members would pick the next one on the queue, and work it. The group’s supervisor could re-shuffle the work queue at any point, so the most important was always the next one to be picked. However, as a rule, he would not interrupt a Team Member from one case to work another.

Over a fairly short period of time, the group’s throughput went up dramatically, they were no longer working weekends and overtime, and there was far less rework involved because they were catching the reasons for rework up front.

Now, apply this same thinking to any transaction that occurs in your Health Care arena. Processing insurance claims (or other financial transaction), for example, seems like something fairly similar to this.

But here is the point: Isolate the routine from the true exceptions. Establish a routine process to do routine things in routine ways. Process the exceptions separately.

What about delivery of care?

This gets a little trickier, but I think the same basic processes apply. If you think about it, most Emergency Rooms already do this with triage. But where they fall short is in establishing routines to do routine things, and having checks in place to make sure those things are happening as specified.

Thus, even with the best of intentions, the exceptions become the norm because they are allowed to become the norm.

Let’s look at routine, scheduled, surgery. There are fixed sequences of steps to prepare the patient, prepare the facility, and prepare the team. But I would contend that, even though “everybody knows what to do” there isn’t an expectation that everybody does it a particular way. The “Who does What, When” is not part of the expected routine. Thus, people don’t expect routine things to actually BE routine, so the non-routine things that mess up the process are taken as a matter of course.

Instead, assume that a routine, smooth, consistent process is possible. Then look for what keeps it from being ideal, and embrace those little things as kaizen opportunities… then address them!

This post is MUCH longer than I set out to make it. But I think the original question gets to the very core of the work most Health Care organizations need to tackle. I am going to stop writing, and throw it out there. I apologize if it is a little unpolished.

Hopefully it will generate a little discussion.

Jim Collins: “Good to Great” Website

Jim Collins book “Good to Great” has been a best selling business book for several years. But I am not so sure everyone knows about Jim Collins web site. It as on-line mini-lectures, and much more material that reinforces the concepts outlined in the book.

As for how the concepts in the book relate to “lean thinking” – I believe they are 100% congruent. Examining Toyota in the context of the model outlined in the book shows everything Collins calls out as the crucial factors that separate sustainable improvement from the flash-in-the-pan unsustainable variety.

The only difference I can see between Toyota and the companies that were profiled is that Toyota has had these ingredients pretty much from the beginning, and Collins’ research was looking at companies that acquired them well into their existence.

How The Sensei Sees

Steven Spear told an interesting story in our session with him.

A Toyota sensei, very senior, was looking at a process unlike anything in his previous experience base. The researchers watching expected him to do “analysis by analogy” – to take what he observed, find a matching analogy in his deep experience, and then draw conclusions about the current situation.

This model, by the way, is a commonly accepted one for how “experts” work with new situations.

But that isn’t what happened. The insights were very fundamental, and quite specific to the process he was seeing for the first time.

The way he worked was revealed in the way he described the issues.

“Ideally,” he would say, “it should be ___________ . But the problem is __________ .”

In describing the “problem” he would describe the departure from the ideal situation. In so doing he was seeing problems, not as “seeing waste” but as seeing “departure from the ideal.”

This was, at least for me, a fairly significant ah-ha. I realized two things immediately.

  1. If I may be so bold, I got some insight into what I did in the same situation. At the risk of over-stating myself, I have found I am fairly good at getting to the core issues when looking at a process. Becoming a little more concious about it will, first, let me be better at it and, more importantly it will allow me to be much better at teaching others to do it.
  2. Tying back to #1, we teach this wrong. We teach people to look for “waste.” We teach them to look for ways to “make the process better.” We are always measuring “what could be” from a baseline of “what is.” This is totally backwards.

What we should be doing is measuring “what is” from a baseline of “what is perfect?”

What is the difference? I think it is important on a couple of levels. First is simple engagement of the workforce.

Ask someone “How can we make your work better than it is?” And the question carries all kinds of baggage. It says “Obviously you don’t do it as well as you could.” Whether or not it is meant this way is irrelevant. That is how it, all too often, comes across. The common symptom of this thinking is when you hear “This is as good as we can make it.”

Ask, instead, “Where is this process imperfect?” or “What gets in your way of doing this perfectly?” and you disarm the above objection. Anyone who works in the midst of complexity encounters dozens or hundreds of things every day that must be worked around or somehow coped with. All of those things take time, effort, energy, and each decision about how to handle something unforseen brings in the possibility of getting it wrong – making a mistake.

Think about it – how many mistakes result from someone just trying to figure out what should be done to correct some kind of anomaly, and making the wrong judgment?

Over the next few posts I am going to continue to beat these concepts to death from different angles. Forgive me in advance – it is my way of exploring it in my mind, and I am using you, the reader, as a sounding board. Writing things down forces me to think about them in more detail.

Toyota falls short of GM in global sales – Yahoo News… So What?

Toyota falls short of GM in global sales – Yahoo News

This news article is interesting, because it totally misses the point.

First, in the fine print, Toyota fell short of GM, yes, by about 3,000 total cars out of about 9.3 million cars. So, in my book, that is a tie because +/- a couple of thousand out of nearly 10 million is just noise.

But what is missed is the bottom line – profit.

Take a look at the numbers that matter:

These results are not something that comes from a quarter-by-quarter strategy to “maximize shareholder value.” Rather they come from a consistent year-to-year pursuit of being an ever-better supplier to their customers.

So many companies equate top-line sales with success. Apparently the press does as well – assigning significant meaning to “total number of cars sold” without even mentioning the simple fact that one company is giving them away at a loss, and the other is actually making money.

Upgrade and New Look

As you may have noticed, there is a new look. This is the result of finally getting around to upgrading WordPress, and the unintended consequence that the new version “broke” the theme I was using. So I finally found another theme (which is easier than rolling my own or dissecting someone else’s code to figure out the problem), implemented it, and here we are.

There are still a few glitches in the categories, etc. which I am cleaning up but basically it works.

If you see anything weird, please let me know (a comment to this post is fine).

Lean in Health Care

A little over a month ago I had an opportunity to spend about 4 hours in a small-group session with Steven Spear. For those readers who don’t already know, Steve is a researcher and practitioner who has made his name in understanding the Toyota Production System as Toyota actually does it.

He first came to the attention of the “lean” community with the 1999 publication of Decoding the DNA of the Toyota Production System, a paper summarizing his PhD research and dissertation.

Since then he has become active in improving the health care system. I’ll leave a full bio to your Google skills.

While health care certainly has a lot of room for improvement, I think the rest of us have a lot to learn from experience and insights being gained in efforts to apply the TPS to health care.

I plan to put together the next few posts intertwining these topics. But first, I wanted to share some interesting performance numbers we heard from Steven Spear.

  • During a hospital stay in the U.S. health care system, the patient’s risk of being injured or killed by the efforts to deliver treatment are roughly on-par with the risks of base jumping. For those of you who don’t know, base jumping is jumping off ‘B’uildings, ‘A’erials, ‘S’pans and ‘E’arth and (hopefully) then parachuting to a (hopefully) safe landing without hitting the thing you are jumping from.
  • Hour-per-hour, you would be safer on an infantry patrol in Bagdad than staying in a hospital.

Now, before you start shaking your head and pointing out just how terrible this is, please consider:

  • As a product moves through your own system, what are the odds it makes it through absolutely unscathed and in perfect condition? Do you do any better than this?
  • If you were to study your own processes do you honestly think they are any more effective at delivering a defect-free outcome at each and every step?
  • Do you even know where, when, and why, those processes fail to deliver a defect-free outcome?

I would contend that most of us have no idea.

Why I Don’t Like Two-Bin Systems

On the surface, a “two bin system” seems a great, simple solution to a part resupply process that could otherwise get complex.

And, on the surface, I don’t argue with that.

But two-bin has some limitations. And because it is so simple to set up, those limitations are frequently not understood or taken into account.

What is “Two Bin?”

Although it may be obvious to all, I want to define “two bin” to reduce the chance that what is “obvious” is actually less so.

“Two bin” is a simple pull system. The parts are supplied by two rotating containers. When a bin is empty, it is returned to the supplying process to refill. The second bin supplies parts while the first one is being filled.

The same system can be applied to things much bigger than “bins.” I have seen carts carrying fabricated steel parts weighing many hundreds of pounds set up the same way.

When does it work?

In general, two-bin is OK when two criteria are met:

  1. The parts are relatively cheap. That is you don’t worry too much about having more than you actually need. This comes with a warning, however. It is easy to have a ton of money tied up in relatively small excesses of hundreds of parts. It does all add up.
  2. This is critical: The time to replenish and return a full bin is short compared to the time to use the parts contained in a full bin.

In this scenario, the first bin is empty, and long before the Team Member has emptied the second bin, the first one is safely returned and is behind it on the shelf.

So What’s The Problem?

There are problems at two levels. I am going to emphasize the practical one, then talk about the philosophical one.

At The Practical Level

First, let me explain how this system would work if it were being done with kanban cards as signals.

One of the rules of kanban cards is that the card is removed from the container when the first part is consumed. That is, the container is NOT empty.

In this type of system, the number of containers circulating is +1 over the number of cards circulating. If you think about it, this makes sense. Let’s say there are five cards circulating, and the container size is 10. If all of the full containers were on the rack, and one part is used from the first container, then the rules state that the card is removed and signals bringing another bin.

If production stops at that point, the worst-case scenario of kanban is realized: The card is returned with another bin of 10 parts. There are now 5 full bins on the shelf, each with a card attached, plus the one bin of 9 parts.

What this has to do with two-bin: Two bin is mathematically identical to a one-card kanban loop.

At a practical level: Do the math for kanban. If your system, with your replenishment quantity and times won’t work with one kanban card, a two-bin won’t work either.

At a Philosophical Level

The problem comes in in practice. Two-bin is easy to set up, and frequently the people doing so don’t do the math. And it usually works.

What results is a pull system that has locked down the number of circulating containers (two), and if there are perceived problems the reflex is to alter the quantity of parts in each bin.

If the system is running a little close to the edge, the materials people will up the parts quantity per-bin from, say, seven parts to ten parts.

Then the system fails.


With kanban, you signal for replenishment when the first part is removed from the bin. Having more parts in the bin means it takes longer to empty the bin. Your supplier has more time to return with a full bin.

With two-bin, you signal for replenishment when the last part is removed from the bin. Having more parts in the bin means it takes longer to empty the bin. Adding more parts to the bin delays the notification to your supplier that you have started using parts.

While it doesn’t always happen, there are cases when adding even a few parts to the bins will cause two-bin to fail because of this.

No matter what system you use, you must thoroughly understand how it works, why it works. You must think through (and try) every step of the process, not just talk about it.

You must ask questions and understand every detail:

  • If there are hundreds of bins, and they all have part-specific labels, how will they be sorted and routed to the appropriate supplying process?
  • How will the bins be used to visually manage the replenishment process?

These are questions with obvious answers in card systems (that use generic bins), but are frequently not well thought through in the rush to implement the “simpler” circulating bin systems.
Also keep in mind: If you are not constantly monitoring actual use, execution and results against your assumptions and expectations of what should be happening, you might be using pull, but you are not applying the Toyota Production System.


  • Go ahead and use two-bin if you want to. Just do the math and make sure it will work for you.
  • However, if you use cards, or other signals, anywhere consider the complexity you are introducing with more than one system. The rules are different depending on the parts. Remember, you are asking your customers to keep track of all of this.
  • Generally speaking, if your system is operating close to the edge, it is better to use more containers that are smaller. Things will circulate more quickly, and your supplying process will have a much better picture of your consumption patterns.
  • Remember – your objective is to move closer to single-piece-flow. If you move away from that (with bigger containers) you are doing the opposite of kaizen.