Alan Barnard (at the 2006 TOC-ICO conference) asked the question whether the simple Throughput per Constraint Unit rule is valid with 2 (or more) overloaded resources. Alan used Eli Goldratt’s P-Q thought experiment for his discussion. His question is important because it is common to see businesses reduce ‘excess’ capacities to balance (or almost balance) capacities. The practice often results in two) or more concurrent constraints or ‘almost’ constraints. Since 2006 I have observed several factories that wonder why their output collapses below the theoretical capacity of their (almost) balanced lines.
I plan to show that that the Throughput per Constraint Unit rule continues to be valid using the same P-Q thought experiment. I also want to discuss this result in relation to the real World – how should companies manage resource capacities.
I would like readers to follow Eli Goldratt’s recommendation that they solve the problems – before I provide the solution and before my discussion of results. The learning experience will be greater and readers should be better able to discuss and critique my conclusions. If you are familiar with the thought experiment you can jump to the second part of this article.
The key part of the article comes at the end when the solution used in the P-Q thought experiment is discussed in relation to REALITY. The thought experiment should not lead managers to an easy solution. The tool is useful but requires thought and care.
Interactive Constraints (like machines B and D in our example)
As we have just seen interactive constraints in my little PQ factory cut the maximum possible profit from 300€ per week to just 120€ per week (that is a 60% drop!). This is what interactive constraints can do to your business – they interfere with your capability to get the most from your most constraining resource.
Cost and efficiency pressures cause many business attempts to “balance” capacities – make all resources have about the same capability. This effectively introduces a second and potentially even more constraints into a production system. For most businesses, a collapse of capacity, is the surprising result – they cannot achieve even the original constraint’s capacity. Sales and profits are damaged. Not only do sales and profit suffer because current demand is not met; customers, because of poor delivery performance, leave for the competition, a much longer term loss and probably a much greater damage.
To maximise profits and profitability most resources must have sufficient protective (or buffer) capacity so that capacity constraints cannot interact to damage the most constraining resource’s capability. Just one bottleneck is already one too many! Because, no matter what the supply chain does – when a demand spike occurs the company must either lose the added sales represented by the spike, or the company must promise delivery it cannot physically do. If a company promises what it cannot do, then the longer-term damage of lost clients will, sooner or later, happen.
To balance capacities is a ‘policy’ (or simply the way a company works). This ‘policy’ is a kind of (fake) constraint because the policy limits how much money the business can make. In such policy constraint cases; it is NOT this (fake) constraint the business must decide how to exploit (the 2nd step of the 5 focusing steps). The first step must be: change the faulty policy, including the faulty assumption that caused the business to balance capacities in the first place. Change the hidden assumption that resources are independent (operate in isolation) and therefore do not impact other (production) resources. A further assumption, not evident in the P-Q experiment is that resources are not subject to variability. Variability enhances negative effects caused by interactive constraints – if one breaks down the other constraints can easily be starved of work.
Observe this from the point of view of Lean and ask yourself this question: Does it make sense to reduce capacity/capability to balance capacity? Damaging your customers (because you cannot reliably supply) is a huge waste. Think about Lean as focused on maximising Throughput (and profit) and not focused first on minimising cost (waste). Consider lost Throughput as part of the waste you want to eliminate. The obstacle is managers do not view lost Throughput as waste. It is impossible for managers to put a “single definitive” number on Throughput waste – it’s an uncertain number dependent not only on what the company does, but also on client demand. On the other hand, cost ‘saved’ by firing a resource is a number you can easily determine – cost per person is in the ‘system’. (Never forget the impact firing a resource has elsewhere in your factory (because it can create interactive constraints). Also, remember how employees may react to the firing of their colleagues and friends to ‘balance’ capacities. How well will the remaining employees be motivated to help improve the business in the future?)
Observe this also from the point of view of Agile. We know that demand is uncertain, and often very uncertain at the article level. Ask yourself the question: Does it make sense to operate so close to capacity that any small spike in demand must be left to the competition to fulfil? Alternatively, does it make sense that we make promises to customers we cannot keep? To be agile means to be able to capture all demand our uncertain World sends our way. To do that we must be able to respond and capacity or capability is part of the answer.
Here is a second question: Does it make sense to keep a certain amount of protective capacity (“free” capacity) to be able to respond quickly? Protective capacity makes a company more agile, protects current Throughput and gives the business a better chance to gain new (more) Throughput.
You want your business to be Lean, but never anorexic. Lean means enough reserves to respond quickly and correctly to the changes our environment throws at it? Lean means having the stamina to win against your competitors. Anorexia will not do it.
This was some thoughts about interactive constraints and protective capacity. You may want to check out Eli Schragenheim’s blog for more about the importance of capacity buffers.
