What The Goal Got Right About Bottlenecks, and Why It Still Applies Beyond the Factory Floor
September 02, 2026
A Software Development Perspective on Finding the Real Constraint Before Automating Anything
Walk into most operations, a factory floor, a logistics hub, a professional services firm, a clinic, and ask where the biggest efficiency problem is, and you will usually get a confident answer pointing at whichever team looks the busiest, or the messiest, or the one people complain about most in weekly meetings. It is rarely the right answer.
Operations management has understood this for decades. A system’s total output is never determined by how hard every station or team works. It is determined by whichever single point in the chain has the least capacity relative to demand. Fix that point, and throughput moves. Fix anything else, and you have often just moved work, or inventory, or backlog, around without changing what actually comes out the other end.
This idea sits at the center of how we approach custom software and automation work, across manufacturing and beyond. Bottlenecks are simply the thing we like to eliminate, wherever they show up. If you are looking for efficiency built from the ground up, and not just a quick fix, before we ever propose a system, an integration, or a piece of automation, we start with a more fundamental question. What is actually limiting your throughput right now, and is technology the right lever to address it.
The Trap of Fixing What Is Visible
Most operations carry a running list of frustrations, a review queue that never clears, an approval process that takes too long, a system that does not talk to the rest of the business. It is tempting to automate whichever one is loudest. But a process that looks inefficient and a process that is actually constraining your output are not always the same thing.
As an example, picture four stages of a typical workflow. This pattern shows up whether the units are physical products, insurance claims, client orders, or service tickets.
Â
| Stage | Capacity | Utilization |
| Stage 1, intake or production | 10,000 per day | 80 percent |
| Stage 2, packaging or processing | 12,000 per day | 70 percent |
| Stage 3, review or quality control | 7,000 per day | 100 percent |
| Stage 4, delivery or dispatch | 15,000 per day | 60 percent |
Here, Stage 3 is running at full capacity while everything else has room to spare. That makes it the actual constraint on the whole operation, even if Stage 1 looks busier day to day, or Stage 4 raises more complaints about last minute rushes. Automating Stage 2 or Stage 4 in this scenario, however well intentioned, would do almost nothing for overall output. The math simply does not move.
This is the core discipline behind Eliyahu Goldratt’s Theory of Constraints, first laid out in his business novel The Goal, though the logic applies just as well outside a factory. Do not optimize local efficiency, optimize system throughput. An hour saved at a non constraint is, in practical terms, invisible to your bottom line. An hour saved at the true constraint shows up in every unit of work that moves through afterward.
Finding the Real Constraint Before Proposing a Fix
Most organizations do not actually know where their constraint sits. They have a guess, usually shaped by whichever team is currently escalating the loudest. We approach this differently, using three sources of evidence rather than one, regardless of industry.
What leadership believes matters first. A useful diagnostic question we like to ask executives is this, if demand increased 30 percent tomorrow, where would the operation break first. The answer, and more importantly the reasoning behind it, usually reveals a lot before any data has even been pulled.
What the front line actually experiences matters just as much. Rather than asking people what software they use, we ask what happens when everything goes wrong. That is where the real friction shows up, duplicate data entry, spreadsheets bridging two systems that were never meant to talk to each other, approvals stuck in someone’s inbox, work re keyed by hand between platforms.
What the data shows is often the most revealing source of all. Most organizations are sitting on more insight than they realize. If your end to end process touches multiple systems, whether that is an ERP, a CRM, a case management tool, or scheduling software, those systems are already logging timestamps for every step. Reconstructing that timeline for a batch of orders, claims, or projects often produces a number leaders do not expect. It is common to find that of a multi day turnaround, only a small fraction is actual processing time, and the rest is waiting between handoffs. That gap is where the constraint usually hides, and it rarely maps neatly onto a single team’s org chart.
Where Automation Actually Fits
This is the part that gets skipped when automation is sold as a starting point rather than an outcome. Once a constraint is identified, Goldratt’s own sequence still holds up well as a guide, before writing a single line of code.
Exploit the constraint first. Can the constraint produce more with what it already has. A common discovery is that a team spending a third of its time manually copying data between two systems is not understaffed, it is spending a large share of its capacity on work that is not its actual job. Removing that manual step can lift constraint throughput meaningfully without adding a single tool or hire.
Subordinate everything else to the constraint. Sometimes a bottleneck team or resource is running well below its theoretical capacity, not because it is slow, but because upstream steps deliver work late, priorities shift without warning, or approvals sit idle. In that case, automating the constraint itself is the wrong move, the fix belongs upstream, in whatever is starving it of work.
Elevate the constraint only when needed. New automation, system integration, or added capacity make sense once exploitation and subordination have been exhausted, not before.
Applied well, this changes what a business case for automation looks like. Instead of stating that a change will save someone time on data entry, the case becomes that it removes the single largest drag on the constraint’s capacity, with a throughput number that moves as a result. That is a very different conversation, and a far more defensible investment.
A Practical Way to Start
For organizations weighing where to focus improvement or automation spend, in manufacturing, logistics, healthcare, professional services, or anywhere else with a multi step process, a structured approach tends to work better than jumping straight to a tool or vendor.
• Discover, map the end to end flow, gather leadership and front line input, and pull system data to build an honest picture of where work actually queues and waits
• Quantify, calculate constraint capacity, lost throughput, and the cost of the gap in terms leadership can act on
• Design, determine, for the identified constraint specifically, whether the fix is elimination, simplification, automation, or system integration
• Pilot, implement one focused initiative directly tied to the constraint, and measure the before and after in throughput or turnaround time terms
In Summary
The organizations that get the most value from automation are rarely the ones that automate the most. They are the ones that automate the right thing, the one point in the system where an hour gained actually compounds across everything downstream. Goldratt made that case for factories forty years ago. It holds just as well everywhere else today.
If you are trying to determine where your organization’s real constraint sits, or whether automation is the right lever to address it, we offer structured discovery engagements to map your workflow, quantify the gap, and design a solution around it. Contact us at contact@bottlenecktechnologies.com to schedule a consultation.
Back
Latest posts
