I’ve recently seen a couple of well respected folks saying something along the following lines on Twitter “If you’re working on something that’s not the bottleneck, you’re working on the wrong thing.” That gets my hackles up, because while it contains a grain of truth, it’s an over simplification.

Let’s look at a really basic system for manufacturing widgets:

Simple Widget Factory

Simple Widget Factory Valuestream Map

For the purposes of the discussion let’s assume that orders have been subordinated to the bottleneck, so the whole system has a throughput equal to that of the bottleneck component. In this case that’s the “join” step, which runs at 100 units per day.

Typically we focus on improving throughout in our systems, but other improvements can indeed be valuable.

The cost of manufacturing each widget is £100. £75 of that it’s the cost of “Gilding” the widget at an external subcontractor once it’s assembled. One day one of the team observe that maybe gilding the widgets is overkill, and they could be painted instead. After investigations, the subcontractor agrees, and begins painting widgets for a cost of £25 each.  Throughput is unaffected, but the cost per item has halved. That’s got to be a good thing! Remember that “the goal” is to make money. This factory is now making £50 extra profit per widget, which is an extra £5,000 per day in pure profit.  Possibly the higher margin allows us to invest in later expanding the bottleneck.

Later, the team observe that they’re now paying a specialist subcontractor to do a simple paint job. Also, the time taken to send widgets out and back is adding significantly to the lead time of the system. The company agrees to recruit some painters and bring the work in house. The duration of the paint step falls to 1 day, and the cost remains at £25 per widget.  Throughput is unaffected, as is operating cost, but lead time it’s reduced by 40%. Again, that’s got to be a good thing! Orders are shipping 2 days earlier, and we’ve reduced inventory by 40%.

These improvements illustrate that working outwith the bottleneck can be very beneficial.  Increasing throughput through exploiting and subordinating to the bottleneck, and eventually elevating it is extremely powerful, but don’t discount the value of other improvements.

In software development terms:

  • is your release process expensive to operate, even if it doesn’t constrain throughput?
  • is your test phase slow, therefore increasing inventory, and lead time?
Latest posts by Stuart Leitch (see all)

CC BY-NC-SA 4.0 Improvements Outwith the Bottleneck by Stuart Leitch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

%d bloggers like this: