malvasia bianca

I’ve been kind of obsessed with the theory of constraints recently, which has gotten me wondering about bottlenecks. One of their points is that, in general, a system has a single bottleneck; you should do everything you can to make that bottleneck as productive as possible.

For a simple bottleneck example, say you have a linear, five-step production process. So there are steps A through E, with A’s output being B’s input, and E’s output being the final product. Assume they can produce at the following rate (assuming the previous step has completed): A can produce 10 per day, B can produce 5 per day, C can produce 10 per day, D can produce 3 per day, and E can produce 10 per day.

If you look at where work is piling up, both steps B and D might look like bottlenecks: A can produce tons of stuff, so step A might get annoyed that B can’t consume its output fast enough. Looked at from the whole system point of view, though, only step D is a bottleneck: no matter how fast the other steps get, the whole system can’t produce more than 3 per day.

This example is very simple, but actually a lot of its similarity is irrelevant for this analysis: even if the paths branch and join in interesting ways, ultimately the rate of production of the whole system is limited by its least productive step. (For more complex graphs, though, the actions you take get more interesting – for example, typically there’s some day-to-day variation in the productivity of any given step, and you have to pay more attention to that on the steps feeding the bottleneck than elsewhere. But that is a discussion for another day.)

This, however, doesn’t mean that you can’t get a lot of good from improving the non-bottleneck steps. The first level of analysis is simply to look to make sure that the non-bottlenecks aren’t stealing resources from the bottlenecks. But, aside from that, the above discussion is about throughput; in many situations, latency can be just as important, or even more important.

So, in the above example, consider step C. It can produce at a rate of 10 per day. Maybe that means that it can carry out its step for 10 items in parallel every day; maybe that means that it can carry out its step for 1 item every .1 days. (Or maybe it can carry out its step for 100 items every 10 days.) From a throughput point of view, these are all the same; from a latency point of view, though, doing it for 1 item every .1 days is the best: compared to the 10 items in parallel version, that reduces the time from when raw materials enter the door to when a finished product leaves the door by .9 days. Which is great.

In fact, from the point of view of the whole solution, even a version of C where it could carry out its step for 1 item every .2 days would be better than a version that could carry out its step for 10 items every day. The latency of that step would go from 1 day to .2 days, which is good. The throughput of that step would go from 10 per day to 5 per day; that looks bad, except the throughput of the whole system is 3 per day, so that reduction in throughput is irrelevant.

Which doesn’t mean that you should go around reducing throughput willy-nilly: you’d better make quite sure you know you’re not the bottleneck before doing that! Fortunately, one lesson of lean and agile is that, if you work at it, you can increase latency without decreasing throughput. (Single Minute Exchange of Dies, as opposed to taking two hours to change dies.) Look for waste, find ways to reduce or eliminate it, and you’ll be happy.

It’s not at all clear to me how to apply this at work: I don’t know where the bottleneck is, and our process isn’t even well-enough defined for me to be confident that there isn’t something big that this analysis is missing. One tool to give clarity on this matter is a value stream map; I’d like to try producing one of those some time over the next week or two. If done right, that will help identify potential bottlenecks, and will probably help with ideas for reducing latency. The other tool is waste reduction; the value stream map will help there, too, and I should go through the traditional lean categories of waste to see what examples I can come up in my organization.