When trying to find the system’s constraint, why not simply asking the middle management? At least when Theory of Constraint was young, our world spinning slower and processes simpler, the foremen usually had a common sense understanding of their bottleneck. They knew what machine to look after, and what part of their process to give more attention.
If you haven’t read part 1, catch up: How to identify the constraint of a system? Part 1
Even so they may not have discovered all 9 rules about managing a bottleneck by themselves, they intuitively applied some of them.
Nowadays the picture is blurred with complexity and frequent changes. Nevertheless, asking middle management can still give precious hints about bottlenecks. Ask what the more troublesome spot of the process is and from where / whom the downstream process steps are waiting for something. Chances are that many managers will point to the same direction.
This works for project management or (software) development as well. In those cases I would also ask who the superstar (programmer) is, the one everyone wants on his/her project and in every meeting. Chances are that that person turned into a constraint without even noticing it.
Now if the tip can be useful, refrain from rushing to conclusions from these answers and check for yourself. Many managers may tell you the same just because they all heard the same complaints in a meeting. A meeting where all managers meet…
Go to the gemba, look for Work In Progress
Let’s start the shop floor investigation searching for the bottleneck like it is described in the early text books.
Go to the gemba, follow the flow (which is easier and somewhat more natural than walking upstreams, but up to you to choose the preferred way) visually assess the work in progress (WIP) and inventories in front of the machines or work cells.
Usually the highest piles of Inventories or work in progress are sitting in front of the bottleneck and the following downstream process steps are starved from material or parts.
Yet if it would be that easy it would be no fun. The above works well in simple processes which are neat and tidy. Most often the inventories are scattered wherever it is possible to store something, FIFO (First In First Out) rules are violated and downstream processes, incentivized on productivity, work on whatever they can work on for the sake of good looking KPIs. Finding the bottleneck in such a chaos needs more than a visual check.
It is also possible that excess inventory and work in progress may be temporarily stored in remote warehouses and not in full sight, thus not visible.
Another pitfall is confusing work waves, periodically releasing parts or information, and real bottlenecks. An example could be a slow process which is not a true bottleneck but needs more than the regular shifts to catch up with its workload.
Imagine a slow machine (sM) amidst a process. The process upstream (P1) works 8 hours with best possible productivity and WIP piles up in front of sM. The downstream process (P2) works at best possible productivity and has some WIP in front of it.
At the end of the shift P1 and P2 are shut down. They both fulfilled their daily scheduled work. sM goes on for a second shift, processing the WIP in front of it.
By the end of the second shift, no more WIP (or very few) in front of sM and what was waiting in front of sM is now waiting after it, in front of P2. This is the picture the next early morning:
An observer, depending when he/she looked at the process, could have come to wrong conclusions about a bottleneck. Early morning it looks like the first machine of P2 is holding back the flow. In mid afternoon it is sM that is the culprit, when in reality there is no true bottleneck. sM has enough capacity provided it can work more than one shift.
Some would mention wandering bottlenecks, jumping from one place to another. This is something I will elaborate on in a separate post. Or series…
We are not done now with our bottleneck safari. To learn more, proceed to part 3: V, A & T plants.
Chris HOHMANN 