The Theory of Constraints

In the Eighties and Nineties, Eliyahu Goldratt got quite a bit of attention by arguing that a good way to think of the process of change is by means of an approach that he termed the Theory of Constraints (TOC). The term “Theory of Constraints” was advocated by Goldratt in two books, The Goal in 1984 and Theory of Constraints in 1990, which are still popular, so we decided to provide everyone with a high level overview and a quick evaluation.

In essence, the TOC holds that any given process is limited in what it can achieve by one or at least a very small number of constraints. For the moment, think of a constraint as a bottleneck. You examine a manufacturing environment and see that everything being processed eventually ends up in front of a punching machine and that that punching machine limits the total number of units that can be processes in a given period of time.

Like Lean’s concern with waste, TOC is a technique that is focused on improving the internal flow within a given process, and, as such, is just one of the techniques that a process redesign team might use during the Analysis Phase of a BPTA redesign effort.

Imagine a process like the one shown in Figure 1. If you keep track of where units are waiting to be processed, it’s obvious that activity B is the constraint on this particular process. If you could increase the number of units going through activity B, you might be able increase the overall output of the process.

Figure 1. A simple process with a constraint or bottleneck

Once you identify the constraint on a process, TOC recommends you take steps to assure that the specific activity is working as well as it can. If the activity is going slow because of bad policies (unnecessary double checking, for example), because of awkward internal flow, or lack of enough equipment or properly trained people, then these can be adjusted. If the constrained activity is as efficient as possible, then TOC recommends ways to adjust the flow between activities (with buffers) to make the entire system as stable as possible. In other words, there’s no need to pile up excess inventory if activity B and only process 2 per hour: We might as well slow activity A down a bit, perhaps reducing our workforce.

TOC started out in manufacturing and is still primarily used there, but as some have extended it to other domains, it has added the idea that a constraint can be internal (within the major process) or external (as when customers don’t buy enough product).

TOC offers some interesting measurement ideas, but comparing three measures: unit throughput rate, cost of inventory, and operational expenses (which are all the costs the process spends to turn inventory into output units).

TOC gets very technical when it begins to consider plant types – in effect offering a classification of manufacturing processes and buffering solutions appropriate for each type of problem. For example, one plant type is termed the I-plant. In this case material flows straight through a sequence of activities. The constraint is the slowest activity.

In A-plants, on the other hand, sub-assemblies converge for a final assembly and the constraint usually involves how one coordinates the converging lines so everything arrives at the right time.

For those with a background in BPM, focusing on a single problem, like a constraint, may seem a narrow approach. Why not focus on the consistency of the outputs of the process, as Six Sigma does, or on wasted steps or activities throughout the process, as Lean does, or on decision process, as the business rule people do. More to the point, why not have a tool kit with all these techniques and use the appropriate one at the appropriate time. In other words, although TOC has gotten a lot of attention from some quarters, most BPM practitioners will probably think of it as a good tool rather than a major management theory.

On the other hand, if one is engaged in maximizing the efficiency of a process flow, and must choose between linear programming, PERT or TOC, then TOC has a lot to offer. It’s a straightforward approach and provides lots of suggestions for identifying problems and improving them.

Similarly, if you are trying to improve a process and don’t have a lot of time or have a limited budget, then its useful to have a tool in your tool kit that will help you focus on THE problem that will likely give you the biggest improvement for the effort. If you try TOC, however, and identify the constraint and can’t identify any way to improve the flow through the constraint, however, you will find yourself wishing you had a second tool – like, say, Lean, or Human Performance Improvement Theory with its ideas on how to analyze and improve the motivation of human performers.


[1] Earlier, Wolfgang Mewes in Germany had published a book Energo-Kybernetic System in 1971 which spoke of a theory of bottlenecks. In a similar way Goldratt’s ideas draw from earlier operations management ideas, including PERT and critical path analysis, Just In Time theory, linear logistics models, simulation modeling, and Pareto’s 80/20 analysis. It isn’t so much unique as its well named and supported by two well written books. (See Goldratt’s video Standing on the Shoulders of Giants ( )

[2] TOC shouldn’t be confused with work in the AI or business rules community – or in new product development — on the “propagation of constraints.” In the business rules community, one often starts by specifying the constraints on an outcome or a product: the object has to be less than 3 foot tall and cost less than $500, and then apply rules to help design a product that will comply with those constraints.

Eliyahu M. Goldratt. The Goal. 408 pg. (1984). A “novel” that presents TOC in the context of an actual problem to be solved.

Eliyahu M. Goldratt. Theory of Constraints. 100 pg. (1990). A straight forward introduction to the theory and its techniques. An organization devoted to teaching about and offering certification for practitioners of the Theory of Constraints.

PDF Version

Paul Harmon

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of BPTrends Associates, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in Las Vegas. Paul can be reached at

Speak Your Mind