| What IS a constraint?
By definition, a constraint in the context of the Theory of Constraints (TOC) is anything that limits the performance of the system relative to its goal. A whole bunch of things can appear to be constraints - but in fact there are rarely more than a few in even the most complex environments, and part of the TOC know-how is being able to identify them.
In a for-profit manufacturing business, where the goal is to make more money now and in the future, a lack of capacity to satisfy market demand means the company has a Capacity Constraint. More capacity would translate into more money. (The TOC's Synchronous Manufacturing application typically exposes 20% to 40% of "hidden" capacity in even the busiest environments).
If the same company has idle time on its resources, then it has a Market Constraint – it could make and ship more if only there were more sales. There is a need for more sales if the company is to make more money. (The Theory of Constraints' Marketing solution and Sales solution provide a strategy to win new buisness).
If the same company cannot get its hands on all the materials it needs to meet demand, it has a Material Constraint – if it could obtain more material (at the right price) it would be able to make and sell more product and therefore make more money. We rarely encounter this constraint during Theory of Constraints implementations, but it isn't unknown - some sectors of steel- and forestry-dependent industries are no strangers to living with limited materials.
All the above (and there can be others ... floor space, for example, or cash) are considered physical constraints, and the 5 Focusing steps of the Theory of Constraints were developed with these in mind.
But underneath every physical constraint you'll find a far more insidious, damaging constraint - Policy Constraints.
In Theory of Constraints, a Policy Constraint is a rule or measurement or behaviour or policy that is inhibiting the company from improving performance.
For example, a policy of making large batches of product, usually for what seem to be perfectly good reasons – in order to achieve a lower cost per unit and higher resource efficiencies – can easily become a major policy constraint. Negative consequences can include increased WIP and finished goods inventories, increased lead times, late deliveries and worsening customer service, constant rescheduling, priorities constantly changing, lost productivity, increased overtime, and more!
One of the tenets of the Theory of Constraints is that a single Policy Constraint such as this has negative implications for every function in the company as well as for the bottom line.
Policy Constraints often set departments in conflict. For example, to keep sales (and the customer) happy the appropriate course of action might be to break into a long "run," throw away one or two or even three set-ups, and as a result be able to ship an urgent order on time; while the measurement systems for the production people might demand that they run the big batch and minimize set-ups, to keep costs down and efficiencies high. Calls for improvement in terms of shorter lead times, lower inventory and higher productivity will keep bumping up against the same obstacle – the policy of running large batches. (Anyone familiar with the Theory of Constraints "Thinking Processes" will recognize that I'm simply verbalizing the conflicts that are usually diagrammed in the conflict diagram known as the Evaporating Cloud).
Policy constraints are enormously damaging because they are often invisible – they usually pass unchallenged, being the "only" way to do something, the way things have always been done. It is almost always policy constraints that prevent a company from correctly exploiting a physical constraint or subordinating non-constraints. This is the key to understanding the leverage of the Theory of Constraints technology.
How DO you identify constraints?
Sometimes through data, although data is rarely accurate enough to provide a trustworthy answer without a significant amount of added validation.
The cause-effect understanding that develops from understanding the Theory of Constraints applications lends itself to more pragmatic techniques of identifying physical constraints - even in a cluttered and complex environment where bottlenecks seem to spring up in different locations each day.
Identifying Policy Constraints is more difficult. The TOC's Thinking Processes were developed expressly for this purpose.
What does EXPLOIT mean in practice?
The first of the 5 Focusing Steps of the Theory of Constraints is, to Identify the constraint(s).
The second is, to decide how to Exploit the constraint(s).
For example, where there is a capacity constraint around a piece of equipment, one obvious (bot often omitted) Exploit action might take the shape of staggering coffee and lunch breaks so the equipment never stops running. A company with a capacity constraint would logically want fast set-ups on this equipment (which might be a low priority elsewhere). Fast availability of mechanics in the event of a breakdown. The highest level of preventative maintenance on equipment to minimize unplanned downtime. A focus on speeding the process up. Perhaps SPC on this equipment and on anything that has problems in feeding consistent quality products to the equipment. And so on.
There are literally dozens of other Exploit actions that would be applied in this situation. This is a good scenario for a Lean-influenced "Kaizen Event," for example. This is one example of how Theory of Constraints "pulls in" Lean Manufacturing techniques in a focused manner for maximum impact.
Most managers commonly practice some degree of "Exploit" in certain circumstances; it simply makes sense. However, the Theory of Constraints approach to "Exploit" is a far more rigorous practice.
What does SUBORDINATE mean in practice?
Focusing Step 3 of the Theory of Constraints is, to Subordinate non-constraints to the decisions made in Steps 1 and 2 ... i.e. having identified the constraint(s) and decided how to Exploit them for maximum profit, then the job of the rest of the resources is to make that plan happen.
For example, a resource with capacity to spare (a non-constraint) might go through several set-up cycles producing only small batches in order to keep a capacity-constrained resource busy making the right products to plan. It might appear that the non-constraint resource is being used inefficiently ... and in conventional terms, it is. But by subordinating the performance of this non-constraint, we get more performance from the constraint, and this translates into more product shipped for the same level of operating expense, and more money on the bottom line. The non-constraint is less efficient; but the plant as a whole is more efficient at making money. This is a central tenet of the Theory of Constraints - that the optimal performance of the whole (the business) doesn't come from sub-optimizing each individual part of the business (each resource).
A policy that would prevent a manager from using a resource in this manner would be an example of a Policy Constraint – see above.
What does ELEVATE mean in practice?
In the case of a Capacity Constraint … add people, add a shift, or buy more equipment would be examples of how to elevate a constraint. In the case of a market constraint … add more sales.
Many people who's knowledge of the Theory of Constraints is limited to having read The Goal mistakenly believe that the correct thing to do once a constraint is discovered is to immediately elevate it. In fact, this usually costs money - so the second of the 5 Focusing Steps is to try to Exploit the constraint, which is usually free or calls for insignificant investments or added expenses. Although you should always be thinking ahead, it is only when a constraint is fully exploited, and the non-constraints are being superbly subordinated to make this happen, that Elevation is justified. | 