However, there was one book from that class that grabbed my attention and stuck with me: The Goal by Eliyahu Goldratt. At the time, I couldn’t imagine that, ten years later, I would realize how powerful the book really is.
If you haven’t read it, you should; it’s a classic, up there with Good to Great, The Tipping Point, Crossing the Chasm and all the rest. In it, Eliyahu reveals a set of “thinking tools” he developed, called the Theory of Constraints (TOC), and uses them to solve a range of problems at a fictional manufacturing plant. In the book, a constraint was defined as anything that prevents the system from achieving its goal.
Whack-a-Mole Isn’t Fun in Business
One of the key principles of TOC is that you need to consider entire systems, not just one aspect of them. TOC reminds us that, sometimes, improving one part of the system will make no difference to overall results, and it is even possible that an improvement to one part will make the overall result worse.
“Any improvements made anywhere besides the bottleneck are an illusion.”
For example, in healthcare, adding more beds to a hospital likely won’t improve quality of care if the real problem is a bottleneck in the emergency department. Similarly, in software (an industry that I'm very familiar with), adding more field sales execs won’t drive revenue growth if there just aren’t enough people ready to buy (aka, a market constraint). In fact, in this case, the more common result will be a bunch of really mad sales execs and a bad reputation (but that's a topic for another day).
So, How Do We Apply this Magic of TOC?
One of the core principles within TOC is that "there are NOT tens or hundreds of constraints… there are at least one but at most a few in any given system.” TOC is a management paradigm, and should be used to focus an organization's team on a common goal, hence the name of Goldratt's book.
As the Wikipedia entry on TOC explains:
"The concept of the constraint in Theory of Constraints is analogous to but differs from the constraint that shows up in mathematical optimization. In TOC, the constraint is used as a focusing mechanism for management of the system. In optimization, the constraint is written into the mathematical expressions to limit the scope of the solution."
So basically, they’re saying “don’t get confused here, guys. Yes, optimization is very similar to TOC, but you’re business users; you can’t program, so it's best to just focus on one thing at a time.”
Note: constraints should be used to represent real world limitations vs. explicitly limit scope of the problem.
Why Do We have to Choose Between TOC or Optimization?
But why can there only be TOC or optimization? Didn’t we start this discussion by saying that decision-makers need to consider the whole system, not just one aspect of it? Why would we just pick a few of the constraints to consider? Why would we only focus on throughput?
I think there are two reasons we’re unnecessarily constraining our thinking:
- When Eliyahu wrote the book, he was writing it from an operations perspective, looking at a single plant or even a single line. That’s just what he could control. He couldn’t control all the aspects of an integrated business model, nor do things like shape demand and redefine the product portfolio.
- The human mind can not handle the complexity of juggling more than a few items (4-7 typically), and there were no advanced analytics in 1984 to help Eliyahu: there was barely even spreadsheets. If you are considering all aspects of a system, then juggling multiple constraints and decision variables quickly gets out of control.
You’ve Given Me Problems, You Promised Me Answers
When The Goal was written, they still played videos on MTV and Steve Jobs had just announced the Macintosh. It made sense, then, to focus the company on a single goal and a single constraint. In fact, it still makes sense to align the company to a single goal today. In optimization, that goal is referred to as the objective function, and, for most companies, the objective function is to maximize profit.
So, if your goal is to maximize profit, how do you know which constraint to address? That’s what we at River Logic call “Opportunity Values” and it’s one of the coolest parts of the Enterprise Optimizer (EO) solution.
In my short time here, I’ve seen companies use opportunity values to prioritize capital investments, optimize a product portfolio mix, and analyze the profitability of strategic bids for new business or in negotiations with suppliers. It’s incredible to hear our clients talk about how these types of decisions result in millions - and sometimes billions - of dollars dropping straight to the bottom line.
The best part? They’re tied to the integrated business model of the company, which in-turn does two things:
- It produces a forecast that is both operationally and financially accurate. With EO, financials aren’t just tallied up at the end: they’re a first class citizen.
- It enables operations to take the output of the model at a plant, customer and supplier level, and execute to realize the benefit. That is a disconnect that has existed for years in analytics. It’s hard to drive forward when you’re looking out the back window.
Isn’t Optimization Math? Sounds Difficult
With the technology of EO, it no longer takes a PhD in Operations Research with a Masters in Computer Science to leverage optimization. In fact, the best EO modelers are typically business domain experts. It used to take months, or even years, to code a complex optimization model representative of a business. Typical models in EO are created in 8-12 weeks.
At River Logic, we're taking it another step forward, and, frankly, that’s why I’m here. How valuable would it be to empower the average business user with the ability to analyze millions of decisions, variables and constraints, and prescribe the optimal decisions, from any device, in an intuitive interface?
What do you think Eliyahu Goldratt would say?
Editor’s Note: This post was originally published March 20th, 2016 and revised September 30th, 2018.