With our intuitions we are often wrong. Here is a small case from the bottleneck theory, where I myself felt this way again. The background is that during the development of our Online Kanban Simulation we have intensively explored the bottleneck theory [1], which is also used in Kanban [2]. Keyword: “Manage the Flow, not the People”. One of its most important statements is “The throughput of the entire system is determined only by its bottleneck”. Sandbox. Funnel. That somehow sounds very logical. I was even more surprised when, during the initial analysis of our test data, we had a case where this principle failed at first sight. But let’s look at it in detail.
Die Ausgangssituation
The throughput of the entire system is “8 completed jobs per minute”. Station 3 is apparently the bottleneck in the system, because it still has 4 things waiting to be processed by it. When we look at the data for Station 3, we notice that this station is processing 9 jobs per minute. So more than the throughput of 8 of the whole system. Is Kanban broken?!? So let’s take a closer look again and get the data for the throughput of each individual workstation in addition.
Detailed analysis
| Workstation | 1 | 2 | 3 | 4 | Total |
| Throughput | 15 per minute | 15 per minute | 9 per minute | 8 per minute | 8 per minute |
Oops. Station 4 has a lower throughput of 8 jobs per minute than station 3 with 9 jobs per minute. Furthermore, the throughput of Station 4 even corresponds exactly to the throughput of the entire system. Fortunately: Bottleneck theory rescued after all. But what is the reason why work is stacking before station 3 and not before station 4, the actual bottleneck?
A brief consideration about how to determine the amount of waiting work at a workstation may help here. From a station’s point of view, this is the difference between the work that arrives at the station and the work that it processes itself. And if you consider all stations in front of that station as one system, then the well-known principle applies again: “The stations in front of it deliver exactly as much work to it as the bottleneck of this (sub)system can complete”. For our example this looks like this:
| Workstation | 1 | 2 | 3 | 4 | Total |
| Throughput | 15 per minute | 15 per minute | 9 per minute | 8per minute | 8 per minute |
| Growth of queue | Backlog | 15 minus 15 0 per minute | 15 minus 9 6 per minute | 9 minus 8 1 per minute |
Even though station 4 is the bottleneck of the whole system, most of the work is stacked up in front of station 3. If someone would offer support to this station or make optimizations here (so that the station manages e.g. 10 instead of 9 tasks per minute), this would have no effect on the throughput of the entire system for the moment. There would still be 8 things “tumbling out” at the end.
Some of the implications
Of course I am aware that these are all very theoretical considerations. But all right, you have read up to this point, after all. For practical purposes, in future I’ll take a second look at it when I think I’ve identified the supposed “bottleneck”. And of course: “Manage the flow, not the people”. I remember some practical examples where there was an intensive focus on specific teams or departments of an organization. Because that is where most of the work was “stacked up”. In retrospect, I am no longer sure whether this was really always the spot with the lowest throughput.
tl;dr
The bottleneck of a system is not necessarily where most of the work stacks up. It is only the workstation that has the highest difference between its own throughput and the throughput of all stations in front of it. There may still be stations in the system with lower throughput, to which this criterion does not apply. If you really want to find the bottleneck, you have to look more closely.
Sources
[1] https://en.wikipedia.org/wiki/Theory_of_constraints
[2] https://en.wikipedia.org/wiki/Kanban_(development)
Inspiriert? 
