The Essence of the Theory of Constraints

Over the past couple of months, I have endeavored to capture the core theory underlying the Theory of Constraints (TOC). My goal is to clarify the foundation of TOC and build a better understanding of the dynamics when applied. And perhaps, armed with a deeper understanding, find ways to improve TOC.

I started with a prototype of the theory and asked for feedback from TOC interest groups on LinkedIn and Facebook. The community did not disappoint and provided lots of feedback, suggestions, and debate. And thankfully, all with clearly helpful intentions.

There is clearly a lot more to TOC than the theory. Digging into the work of Dr. Goldratt and the community you find layers upon layers of insight.

However, I believe the essence of the general theory can be boiled down to “a system’s constraint is anything that limits the system from achieving higher performance versus its goal.”

To make this general theory useful, we must first determine a system’s goal and a measurable unit of that goal, so that we can find the relevant constraint and evaluate whether changes improve performance.

Dr. Goldratt chose to focus most of his attention on the business domain. He determined the goal of business to be making money now and in the future. And defined a measurable unit of this goal to be throughput. As a result, many TOC applications focus on improving throughput.

The Core Theory of Constraints Applied to Throughput Goals

To simplify the presentation of the theory as it relates to increasing throughput, I split it into three parts:

Context:
1. Single goal serial dependent flow systems where the goal is increasing throughput.
2. Can be extended to multi-goal serial flow systems (complex systems) if the system’s multiple goals can be integrated into a single higher-order goal or by separating a complex system into multiple single-goal systems operating independently.
3. Does not apply to inherently complex network systems with multiple goals or highly variable chaotic systems.
Theory:
1. The Throughput of a System cannot be greater than the throughput of the Constraint.
2. Given the Constraint, the Throughput of a System is maximized by
  1. Utilizing the Constraint’s full capacity without interruption to increase quantity, and
  2. Protecting and improving value realized per Goal unit.
3. Increasing Throughput beyond the Constraint’s capacity requires increasing the Constraint’s capacity.
Definitions and Conventions:
1. System (with a capital S) is the total system that encompasses all the elements (e.g., activities, events, steps, and sub-systems) required to realize the global goal. The System may also be referred to as a global system or the whole system.
2. Goal (with a capital G) refers to the global goal for the System. Other goals (with a small g) shall refer to local goals or sub-system goals.
3. Throughput (with a capital T) refers to the amount of value created by the System per unit of time. Value is determined by the number of Goal units x value per Goal unit.
4. The Constraint (with a capital C) is the element of the System with the lowest throughput capacity that limits Throughput at that moment in time. The Constraint may also be referred to as the Limiting Factor. Other types of constraints shall be referred to as constraints (with a small c) or limitations.

This core theory, when coupled with the principles of TOC, gives us the power to craft high throughput systems that are reliable and relatively easy to control.

Principles of TOC

One thing that was clear from the community’s discussion of theory was the importance of the principles of TOC. These fundamental principles provide essential guidance in generating insights from the theory. Four of these principles were specified in The Choice, a book published by Dr. Goldratt. These four principles are often referred to as the pillars of TOC. I have chosen to add a fifth principle to the pillars because it is as essential as the others in helping us interpret the dynamics we see in systems.

Key principles:

Inherent Simplicity – Everything in the universe is based on simple principles
No logical conflicts or contradictions in reality – If there is an apparent conflict, there is a flawed assumption
People are good – The presumption that people have good intents
Never say I know – There is always an opportunity for significant improvement
Statistical fluctuations will occur – Variability can be reduced but not eliminated

The Special Role of Inherent Simplicity

Inherent Simplicity is one of TOC’s most important ideas, and perhaps the reason Dr. Goldratt suggested that TOC could be explained in one word: Focus.

When we look around our world, Inherent Simplicity seems absent. Our universe is filled with complex and chaotic systems producing unpredictable and non-linear outcomes. Our organizations also seem to operate in complex and, at times, chaotic ways. So, where do we find this supposed Inherent Simplicity?

Inherent Simplicity is found in the essence of how things work. It is the idea that a few simple concepts explain how systems create systematic divergence from total randomness. Incredible insights into how our universe works flow from simple concepts like entropy, F=ma, the derivative in calculus, and the Pareto Principle.

This means four things in simple language:

We should expect things to be simple, not complicated
A few factors matter a lot, and the rest are trivial
When things appear to be overly complex, complicated, or unpredictable, we should ask why?
We can use the few factors that matter to restore simplicity

What Simple Looks Like

A simple throughput system is focused on a single goal. It consists of only the serially dependent elements necessary to complete the goal. It uses a basic pull system to regulate flow. Small amounts of work in process are used as buffers to absorb statistical fluctuations in production and demand.

A simple system like this is highly efficient, reliable, highly predictable, and easy to control when the Constraint is used as a single control point to coordinate work across the system.

Divergence from Simplicity

Many common management practices can turn a simple system into a complex or chaotic system quite quickly. Examples include:

Introducing additional goals that create competition for resources can lead to unpredictable oscillations between goals
Attempts to optimize the utilization of each element will lead to overproduction that creates queues, unnecessary delays, flow congestion, and dissipation of energy on non-value-adding tasks
Attempts to balance capacity across the system will lead to chaotic performance due to statistical fluctuations in production rates that are greater than capacity differences between elements
Excessive reductions in work in process or poorly managed buffers can lead to shortages and volatile throughput
Lack of attention to process variability management can lead to chaotic performance
Lack of systematic prioritization can lead to flow disruptions or trapped WIP

This is just a partial list of things that can make simple systems complex or chaotic. Fortunately, due to the principle of Inherent Simplicity, we can restore order by focusing on just a few key factors.

Restoring Simplicity: The Factors that Matter

We can use four factors to restore simplicity quickly: The Goal, the Constraint, Global Coordination, and WIP Management.

The Goal

The goal is the most important factor in any system. The goal defines effectiveness for the system. If we get the goal wrong, then every improvement will just lead us to produce more of the wrong thing.

Simple systems are focused on achieving singular goals repeatedly. A poorly formed, ambiguous, or conflicting goal is one of the leading causes of unnecessary complexity.

Establishing a single goal will help restore simplicity.

TOC has some powerful tools for transforming apparently conflicting goals into a singular higher-order goal that restores simplicity. Throughput Accounting, Thinking Process/Evaporating Clouds, and simple color-coordinated prioritization are all designed to deal with different versions of this problem.

Once the goal has been established, we need an effective way to measure the realization of these goals. Throughput is a common measure used when the goal is producing more of something such as making more money or completing more projects. However, we should always remember that throughput is a measure of a particular type of goal. Other types of goals need measures appropriate to the goal. For example, if our goal is to be more responsive, then response time might be a better goal than throughput.

Once the goal and measure have been defined, we have a basis for identifying the relevant Constraint.

The Constraint

The Constraint is the element of the system that most limits our ability to realize the global goal. While the Constraint is not the only source of leverage for improving the system’s throughput, it is the most powerful lever.

Every increase in throughput at the Constraint translates directly into increases in system throughput on a one-to-one basis. Increasing throughput provides enormous leverage on Investment and Overhead Expenses and yields disproportionate increases in profitability.

Beyond its power to improve throughput, the Constraint, when coupled with the right protective buffer design, provides a single control point over the system’s flow that can be used for system-wide flow coordination and WIP management.

One common problem with the Constraint is that it can move around as the state of the system changes. This can lead to a situation where the system appears to have multiple constraints. However, we are not seeing multiple constraints simultaneously. We are observing the system as it changes states, and a change in state can change the location of the Constraint.

When external factors, such as seasonality, cause the state change, we can use buffers to protect the Constraint from overages and shortages. However, when these state changes are the result of internal practices like balancing capacity or unmanaged variability, we should address the root causes of state instability, and not just wrap them in buffers.

Global Coordination and WIP Management

The third step of TOC’s Five Focusing Steps or Process of On-Going Improvement (POOGI) is to “Subordinate everything else to the Constraint.” The simple version of this idea is that all the decisions about non-constraints should be focused on supporting the Constraint’s needs.

The Constraint is important because it limits the quantity of throughput that can be achieved, and we need to protect the Constraint from shortages. We do this with time-based WIP buffers designed to accommodate expected production and demand variation.

While supporting the Constraint is critical, we should always be mindful that the overarching objective is to improve the system’s performance. To that end, the rate-limiting function of a throughput Constraint does not mean that the Constraint creates all the value. Value comes from the global coordination of all the system elements to deliver the solution that does the job the customer needs at the right price, quickly, on time, and with as little waste as possible. A 10% increase in value per unit has the same effect on throughput as a 10% increase in throughput quantity.

To maximize the value created by the system, we coordinate production rates and regulate WIP across the system using signaling mechanisms connected to dynamic buffers that protect the Constraint and the system. This prevents all system elements from over or under-producing.

This global coordination mechanism changes the focus of each element in the system from maximizing local utilization to successful buffer management.

While other methodologies such as Lean also utilize global coordination and WIP management, TOC is unique in two ways. First, TOC uses the Constraint as the control point for this global coordination and WIP management. Having a single control point should make global coordination and WIP management easier to manage. You make a change at the Constraint and it flows throughout the system.

Second, while other methodologies try to eliminate variability, TOC assumes some level of variability is inevitable and some types of variability cannot be eliminated. Instead of trying to eliminate all variability, TOC tackles the problem of statistical fluctuations with dynamic time-based buffers. This approach makes the system more resilient to upside statistical fluctuations such as sudden increases in demand for a particular product or group of products.

Challenging Assumptions

In Dr. Goldratt’s “Standing on the Shoulders of Giants” Process, he observed the importance of understanding the giant’s solution, identifying the conceptual differences, and identifying the wrong assumptions.

This process is logical, but it is difficult to challenge assumptions made by others, particularly when the assumption has never been made explicit. When you make assumptions about what you think other people are assuming it will inevitably lead to problems.

So instead of challenging Dr. Goldratt’s assumptions, I focus on challenging the following assumptions that I have made about TOC at some point in time:

The theory of constraints is for throughput
Constraints should be eliminated
The Constraint can be in the market
There can be multiple Constraints
We should not spend time on small things because they are trivial
A constraint limits performance

1. The Theory of constraints is for throughput

As Dr. Goldratt wrote, “a system’s constraint is anything that limits the system from achieving higher performance versus its goal.” Throughput may have made TOC famous, but TOC is not limited to throughput. There are other types of goals that may be able to benefit from TOC in the same way that TOC thinking has been extended to Critical Chain Project Management where I believe the goal is on-time delivery.

What other types of goals should we investigate? My short list of other interesting goals includes process control, responsiveness, and breakthrough innovation.

2. Constraints should be eliminated

Among casual readers of The Goal, I believe many people walked away with the idea that bottlenecks are bad, and that we should get rid of them.

I think TOC still struggles with this misperception. Building a compelling case for the Constraint as a source of competitive advantage along with supporting case studies from large companies would be good for TOC.

3. The Constraint can be in the market

I find this assumption to be particularly troublesome. How can the Constraint of a business be outside the business?

In practice, this leads to an oscillation between the Constraint being inside the company and the Constraint being outside the company. If we follow POOGI, we must choose a Constraint and then subordinate everything to the Constraint. If the Constraint is bouncing between the two locations, how do we use the subordinate step?

An alternative framing of this problem is that the Constraint never leaves the business and that the problem is a demand shortage at the Constraint. This would suggest that sales & marketing are under-producing. Perhaps, we should keep the Constraint in the business and task sales & marketing with generating enough business to keep the demand side buffer full.

4. There can be multiple Constraints

If often seems like there are multiple constraints in a system. Can this be true or is there another explanation?

A common problem with the Constraint is that it can move around as the state of the system changes. This can lead to a situation where the system appears to have multiple constraints. However, we are not seeing multiple constraints simultaneously. We are observing the system as it changes states, and a change in state can change the location of the Constraint.

I now believe the following to be true.

At any given time, a system has one Constraint based on the state of the system.
If the state of the system changes, the location of the Constraint may move.
If we view the system over time, we may observe more than one Constraint due the changing state of the system, but only one Constraint is active at any given time.
The system may also appear to have more than one Constraint if there are large buffers between chained sub-systems. Draining the buffer will force the system to reveal the true Constraint or the oscillation between Constraints if statistical fluctuations cause large changes in the state of the system.

5. We should not spend time on small things because they are trivial

I really like this assumption, but it should be changed to don’t spend time on trivial things. The difference is that trivial things are always trivial things and very small things in very large quantities can easily become very material. When small things add up to millions or billions of dollars, it’s usually worth putting some effort into finding and eliminating the root cause of the problem.

The other part of this is psychological. TOC fails to give everyone something constructive to do, and that is a problem. People without something to do will find something to do.

One of the most important parts of Lean is kaizen. We mostly think of kaizen as a continuous improvement process. TOC generally dismisses this as not making a difference. However, when kaizen is done well it also leads to huge increases in employee engagement. It makes people feel like they matter.

I think it would be good for TOC to build a constructive framework for widespread employee contribution and engagement. Three areas that might be productive include tackling big dollar problems that stem from small things, reducing unhelpful internal variability, and improving responsiveness.

6. A constraint limits performance

This assumption is built into Dr. Goldratt’s definition of Constraint and stems from his original focus on bottlenecks, which are conditions that impede progress.

Dr. Goldratt generalized from the word bottleneck to word constraint, but he defined it to mean something very similar thing. The small generalization greatly expanded the possibilities for TOC. And when Dr. Goldratt expanded the theory beyond throughput he built Critical Chain Project Management.

Can further generalization lead to more insight?

We know the word constraint is used in many other domains such as physical mechanics, linguistics, biology, neuroscience, and art. In those domains, it is used in various ways to describe a limitation of possibilities. These limitations, like a bottleneck, can limit good possibilities from happening, but others, like focus and guidelines, can also accelerate progress when used correctly.

We also know that Constraints play amazing roles in structuring complex systems such as languages, DNA, and life.

My question is what would we find if took the next step and built a fully generalized theory of constraints on possibility space?

Potential Improvements for TOC

TOC applications are potent combinations of theory and principle applied to specific problems in specific contexts such as production, project management, distribution, and sales. Some of TOC’s core tools, such as the Thinking Processes, have also proven immensely valuable in areas beyond business settings like Education.

If we embrace the fourth principle of TOC, we know there is still much to be done to improve and expand TOC. A few examples of potential improvements include:

TOC for Enhanced Control – Dr. Goldratt designated throughput as the most important goal, and at times described attempts to improve things that did not enhance throughput as trivial or ego-driven endeavors. However, throughput is not the only way to improve value. Consistency, reliability, and control are highly valued by customers, shareholders, employees, and regulators. Many of these stakeholders would gladly swap some level of throughput for greater control. The individual TOC applications are primarily designed for increasing throughput, with enhanced control as a secondary benefit. It would be interesting to flip this paradigm and use TOC to make distributed control the primary focus, with throughput a secondary objective. In this context, local constraints become much more relevant as they would become the control points for managing sub-system performance more effectively.
Managing Constraint Transitions – I believe that exploring the enhanced control TOC provides in more depth has some very interesting potential in helping companies understand the relationship between the current Constraint and the element(s) that could become the next Constraint. A clearer mapping of these potential constraints and the lead time required to improve them might be a simpler and more flexible approach than full Strategy & Tactic trees.
TOC for Shared Services – Many large multi-business unit organizations have adopted a shared services approach for G&A functions like finance, HR, Legal, and IT. The idea is primarily driven by a belief in economies of scale without considering the complexity costs incurred. TOC may provide some insights into the best way to structure these organizations so that resource conflicts and time lost to resolving resource conflicts can be reduced.

Hopefully, this attempt to define the essence of the Theory of Constraints is helpful and leads to many more productive discussions. The inherent potential of TOC is only limited by our imaginations. There is much more ahead.

************

Thank you for your help

I would just like to add a world of thanks to the following people for their active participation in the discussion so many months ago:

Jan van Egmond
Richard Zultner
Jose Carlos Camarena
Suneel Potdar
Peter Reynolds
Madan Gopal Agarwal
Rina Ushakova
Charlie Pritchard
Thomas Knorr
Aniruddha Joshi
Kelvyn Youngman

And a special recognition for Justin Roff-Marsh one of the best intellectual sparring partners I’ve had the privilege of working with.

And for those whom I’ve missed, my apologies and my thanks.