By the time a bottleneck shows up as an operational problem, it has usually been an engineering problem for months.
The plant director sees it as a missed target. The board sees it as a margin question. The line sees it as "we're always short at eleven." All three are downstream symptoms of the same upstream fact: somewhere in the system, one constraint is governing the output of everything connected to it, and nobody has isolated which one it is.
Most organisations respond to that symptom by buying something. More capacity, more software, more headcount. Occasionally that's correct. Far more often it treats the part of the system that's easiest to see, rather than the part that's actually governing throughput, and the constraint simply reappears somewhere else three months later.
We don't start engagements by proposing a system. We start by finding the constraint. Here is the methodology, in order, and why the order matters.
1. Observe the operation
Before anything gets measured, it gets watched.
This sounds obvious and is almost never done properly. Most diagnostic work starts with a data request - send us your production reports, your downtime logs, your throughput figures - and builds a picture entirely from records that were, as we've written elsewhere, often assembled by someone estimating at the end of a shift. That's a picture of what got written down, not what happened.
We put an engineer on the floor, watching the actual process, before we touch a single spreadsheet. Watching surfaces things no report contains: the workaround everyone uses and nobody mentions, the step that takes three times longer under specific conditions, the informal coordination happening on a radio or a WhatsApp group because the formal system is too slow to be useful.
Output of this stage: a first-hand account of the process as it actually runs, independent of what anyone believes it does.
2. Map the process
Observation gets converted into a sequence: every step, every handoff, every decision point, every wait.
The critical discipline here is including the invisible steps. A process map that only shows the value-adding activity is not a process map, it's an aspiration. The real map includes the ten minutes waiting for approval, the walk to the other end of the building to get a signature, the queue behind the one machine that's shared across three lines.
This stage typically produces the first genuine surprise of the engagement, because most organisations have a mental model of their own process that is meaningfully simpler than the process itself.
Output of this stage: a complete, verified map of the process as it runs today, agreed with the people who run it.
3. Identify constraints
With the full map in hand, one question: which single point, if you improved nothing else, would raise the output of the whole system?
That is the constraint, in the strict sense. It is very often not the part of the process people assume, and it is very rarely the part that's newest or most visible. It's frequently something structural and unglamorous - a single shared resource, an approval step with one authorised signatory, a piece of equipment with a long changeover that everything else has to wait around.
The discipline that matters here is resisting the urge to fix everything you noticed in stages one and two. A process usually has several inefficiencies and only one true constraint. Improving a non-constraint feels productive and changes nothing about total system output, because the constraint downstream absorbs the gain.
Output of this stage: one clearly identified constraint, with the reasoning for why it's the constraint rather than merely an inefficiency.
4. Measure movement and data
Now, and only now, does instrumentation-grade measurement start - specifically targeted at the constraint, not scattered across the whole operation.
This is deliberate sequencing. Measuring everything before you know what matters produces enormous amounts of data and very little insight; it's expensive, slow, and it's the reason a lot of "digital transformation" initiatives generate dashboards nobody acts on. Measuring the constraint specifically - cycle time at that step, variability around it, what's actually happening in the minutes before and after - produces a small amount of data that's directly actionable.
Output of this stage: quantified behaviour of the constraint: how it performs, how consistently, and under what conditions it degrades.
5. Determine root cause
A constraint is a location. A root cause is a reason. These get confused constantly, and the confusion is expensive.
"The packing line is the bottleneck" is a location. "The packing line is the bottleneck because changeover between SKUs takes forty minutes and changeovers happen eleven times a shift" is a root cause, and it points to a specific, solvable problem. Root cause analysis at this stage means asking why repeatedly, against the actual measured data from stage four, until you reach something that can genuinely be acted on - not a category like "mechanical" or "human error" that explains nothing.
Output of this stage: a specific, evidenced explanation of why the constraint behaves the way it does.
6. Instrument the process
Only once the root cause is understood does permanent instrumentation get designed - sensors, capture points, automated logging at exactly the points that matter.
This is where the earlier discipline pays off. Because the constraint and its root cause are already known, instrumentation can be precise rather than exhaustive. You're not wiring the whole plant speculatively, hoping something useful turns up in the data later. You're placing measurement exactly where it will tell you, continuously, whether the specific problem you found is improving, recurring, or migrating somewhere else.
Output of this stage: a monitoring architecture design, built around the confirmed constraint, ready for build.
7. Integrate systems
With instrumentation designed, the question becomes what it needs to talk to. ERP, WMS, an existing SCADA layer, a group reporting platform, whatever already exists on-site.
Consistent with how we build everything - standalone-first - integration is designed as an enhancement layer, not a dependency the core system needs to function. The instrumentation and control logic has to work correctly on its own before it's connected to anything else, because a system that depends on a third-party platform to make a local decision has imported that platform's downtime as its own.
Output of this stage: a defined integration architecture that extends the core system without making it dependent on anything external.
8. Automate where appropriate
Automation comes second-to-last, deliberately, and the qualifier "where appropriate" is doing real work in that sentence.
Not every constraint should be automated. Some root causes are procedural, not technical, and the right fix is a changed sequence of human decisions, not a machine making them instead. Automating a badly-designed process just makes the bad process run faster and fail more expensively. We only automate once the earlier stages have confirmed exactly what decision is being automated, why, and what the failure mode looks like if the automation itself goes down.
Output of this stage: targeted automation of the specific decision or action identified in stages three through five - nothing broader.
9. Measure improvement
The methodology closes where it started: measurement, but now against a baseline that was established honestly in stage four, not against a vague sense that things feel better.
If the constraint has genuinely moved, the data at the same measurement point will show it, and - this is the part organisations often skip - a new constraint will now be governing the system, somewhere else. That's not a failure of the intervention. It's how constrained systems behave. The discipline is going back to step three rather than declaring the project finished.
Output of this stage: verified, quantified confirmation of improvement, and an honest answer about where the next constraint now sits.
Why the sequence is the methodology
Every stage in this list can be done out of order. Most engineering failures we're brought in to fix are the result of exactly that: automation applied before root cause was understood, systems integrated before anyone confirmed what needed measuring, instrumentation installed everywhere instead of where it mattered, software purchased before anyone watched the actual operation it was meant to serve.
The sequence isn't procedure for its own sake. It's what stops capital from being spent solving the wrong problem precisely.
Don't start with the software. Start with the constraint. Everything else in this methodology exists to make sure that when you do reach for a system, you're building the right one, for the right reason, in the right place.
You cannot reliably identify many operational constraints without sufficient visibility into what is happening across the process.
A factory gate provides a useful example: a delay at the perimeter can become a constraint affecting the wider yard and production flow — the factory gate is not a security problem, it is an operations problem.
Some bottlenecks are created not by physical capacity but by the inability of systems to exchange information at the right time — why enterprise software projects fail before development begins.
This approach reflects a broader engineering philosophy: start with the operation, identify the constraint, and only then determine what technology is appropriate — five principles that shape how we engineer.
TENNXT is a Nigerian enterprise systems integrator working across engineering, industrial automation, software and IoT for manufacturing, logistics, healthcare and government. We find the constraint before we propose the system.
hello@tennxt.com · www.tennxt.com
