Bottleneck in the Work Flow vs. Constraint in the Work Process

5 minute read

One of the practices used in TameFlow Kanban is that of identifying the constraint in the work process, by looking for the work state that takes the largest average flow time. In the Kanban Method bottlenecks are typically identified by looking for queues and/or starvation. The work state in front of one that is being starved, could be a bottleneck. A work state where there are queues could also be a bottleneck. Naturally, when work state WIP limits are employed, queues are more difficult to see; but starvation is always evident.

Practitioners of the Kanban Method often employ the Five Focusing Steps of the Theory of Constraints, to handle such bottlenecks. Yet, such application might not be warranted, because those are bottlenecks in the work flow and not the constraint in the work process.

The difference between the two concepts might be subtle, but it is fundamental to understand in order to know how you can manage them. In this post we will look deeper at these different perspectives.

Painting Items

In January 2014, in an email exchange about this topic, Mike Burrows proposed this example for discussion (paraphrased here):

One painter can paint one item per hour. Two can paint two per hour and so on. Assuming plenty of spare rack space for drying, the 10 hours required for drying (supervised by 1 person) has no effect whatsoever on throughput; items will leave at the same rate they arrive. The longer activity is not a throughput constraint; if you want to get more throughput you add painters, not drying supervisors.

It is good to start with such a physical example, because then TOC concepts are more easily applied (TOC has more than 30 years success in manufacturing, so it is good at handling these situations).

First, to make this example realistic, you cannot assume that you have “plenty of spare rack space” — you certainly know how much space you have, and that is one potential bottleneck.

There is a clear distinction between “bottleneck” and “constraint”. A bottleneck is simply a resource that has more demand placed on it than capacity to delivery. A constraint is the bottleneck with the least capacity in the entire system, and it can be reasoned about as the “constraint” only once you decide to manage it.

Let us first reason about the “work flow” because it is what is most visible; and what the Kanban Method typically deals with. If the overall capacity of all painters that are available is less than what can go through the drying space, the reasoning is sound. You can consider “painting” as the work state that is the constraint. Apply the 5FS: elevate, by adding painters. This is exactly what is originally suggested.

At a certain point you add so many painters that the “painting” work state is no longer the “constraint.” The constraint moves to the “drying” state, the moment you have added so many painters that they produce more items than can be placed at any one time on the drying racks. The interesting additional observation, from a TOC perspective, is that by elevating the constraint (the painters), at a certain point the constraint will move: in this case from “painting” to “drying.”

Suppose we have done that. You have effectively worked with the “work flow,” and you get to the point where the constraint is the “drying” stage. Because of the nature (a chemical process) of the stage, it appears we have hit something that cannot be further optimized.

From Work Flow to Work Process

Time to switch gears. So far we have reasoned as customary in the Kanban Method. Now we take a look at what we can do with TameFlow Kanban.

So now we start to look at the “work process,” instead of the “work flow.” We do not look at the painters and the drying supervisors. Instead we look at a single work item going through the whole process. Imagine you are a patient going through a hospital visit. What do you experience from that perspective?

The painting process goes through 1 hour of painting and 10 hours of drying. The 10 hour of drying are the constraint of the process. It is the single work state that (on average) takes the longest for the whole process of painting one single item.

The only way to improve the process is to reduce those 10 hours. Maybe you could devise the usage of some kind of baking oven, where by applying temperature, the drying time would go down to 3 hours. Of course you would incur in the investment of building the oven, and the operating expense of keeping it running. Throughput accounting would tell you if it is worthwhile. If it is, then you have elevated the constraint in the work process. Drying is still the constraint in the process (3 hours drying are more than 1 hour painting).

However, it could be that the elevation is high enough, that the constraint in the work flow goes back to the painters. Back to square one. Time to hire more painters, as suggested originally.

The Kanban Method and TameFlow Kanban are Complementary

These are the two different perspectives, which necessarily need to co-exist, depending on what is truly impeding flow through the system. The Kanban Method focuses on the work flow, while TameFlow Kanban focuses on the work process. The two approaches are not competing; they are complementary.

In the real world, you would keep on switching between one and the other, depending on where the constraint is at the moment.

This is not a heuristic, but is simply TOC and its application. One of the innovations with TameFlow Kanban is to add this process thinking to what you ordinarily do with the Kanban Method. Flow time metrics are the key. Long running state flow time averages will reveal the constraint in the process.

As in the above example, you might have one constraint in the process (3 hours bake drying), yet another, different constraint in the flow (depending on the relative capacity of painting vs drying).

The Kanban Method seems to discount (or even ignore) the constraint in the process — and that is why TameFlow Kanban can add additional tools and improvement opportunities for anybody using the Kanban Method.

Updated:

Leave a Comment