Your plant doesn't have a data problem. It has a decision problem.
Independent, plant-grounded advisory that names the real constraint behind a stalled roadmap or an "unexplained" loss — before recommending a single system, dashboard, or study.
Most "we need more data" requests are actually unnamed decisions in disguise.
When output slips or a transformation stalls, the instinct at almost every level of a manufacturing organization is the same: ask for more data. A new report, a better dashboard, a platform that finally promises to show "the truth." It feels like the responsible move — nobody gets criticized for wanting better information. But across a wide range of engagements, the actual constraint turns out to be something else entirely: a decision nobody has clearly owned, evidence nobody has agreed to trust, or authority nobody has actually been given. The request for more data is often a proxy for a harder, more uncomfortable question that's easier to avoid by commissioning another report instead.
This isn't a failure of any one person's judgment. It's what happens when a plant has been operating long enough that formal reporting quietly drifts away from how decisions actually get made. A KPI review held every week for years can become a ritual for agreeing on a number rather than acting on one. An org chart can look perfectly rational while the real authority to stop a line, approve a deviation, or greenlight a fix sits informally with someone whose name isn't on any chart at all. Asking "who really decides this" is uncomfortable precisely because the honest answer often exposes a gap between the formal structure and how work actually happens — which is exactly why the gap tends to persist, quietly, for years.
Business Operations Advisory exists to name that gap directly, before recommending a system, a study, or a reorg. In practice, that means spending real time on the shop floor rather than only in the data warehouse; structuring an "unexplained" loss into an issue tree instead of a blame list; and building roadmaps with a named owner attached to every single line. The data requirement usually shrinks by half once the actual decision is named — because most of what gets requested was never going to answer the real question in the first place. For many organizations, this work quietly doubles as the first real step toward AI readiness — the decisions get named, the process and data gaps get exposed, and the operational foundation the next intelligence layer would need is already partly in place before anyone's asked for it.
Why this isn't generic operations consulting
Most operations engagements bring a framework and ask your team to fill in the blanks with your own data. The framework is rarely wrong in the abstract — it's just generic enough to fit any plant, which means it fits none of them precisely. For a board or CEO weighing where to place capital, that gap shows up later, as a roadmap that reads well in a steering committee deck and stalls quietly by month four. For a supply chain leader, it shows up sooner — as a recommendation that looks sound on a slide but doesn't account for the changeover reality, the maintenance backlog, or the informal workarounds that actually govern throughput day to day.
| Generic operations consulting | Business Operations Advisory | |
|---|---|---|
| Starting point | A framework applied to your data | The specific decision behind your problem, named first |
| How the numbers get read | Averages, trend lines, benchmarks | Domain-grounded — changeovers, shift patterns, and workarounds accounted for |
| Supply chain's role | A downstream consumer of the plan | A stakeholder from week one, dependencies mapped in both directions |
| At handoff | A slide of recommendations | A named owner and governance cadence, built in |
| What leadership takes to the board | A capability narrative | A defensible number tied to margin, working capital, or cost |
What this looks like at every level of your organization
The decision problem doesn't announce itself the same way twice. It shows up as a different, entirely genuine frustration depending on where you sit — and the fix has to speak to each of them, not just the one holding the budget.
"Every shift-change meeting, I'm explaining a number that changed for a different reason than it did last time — and I'm not always sure I'm giving the real answer."
What changesA structured issue tree replaces the reconstructed story. When a loss is investigated the same disciplined way every time — root cause kept separate from symptom — an explanation stops depending on memory three days later and starts depending on evidence gathered on the floor, the same shift it happened.
"I sign off on numbers I trust maybe seventy percent of the time, and I've stopped being sure which thirty percent is wrong."
What changesDirect shop-floor observation and one canonical definition for every contested metric mean a report is backed by something firmer than inherited habit. A genuine diagnostic tells you which numbers actually deserve that seventy percent confidence, and which quietly don't.
"Every roadmap looks airtight in the steering committee deck, and by month four half the initiatives on it have gone quietly dormant."
What changesA roadmap only earns that name once every line has an owner, a milestone, and a dependency map that would survive a budget cut. We pressure-test the plan before it's presented — not after it's already stalled.
"I keep approving capital requests framed around 'digital capability' that I can't actually connect to a number I'm accountable for."
What changesEvery recommendation is translated into a defensible, ranged estimate tied to margin, working capital, or cost — the language finance already tracks — rather than a capability narrative that sounds compelling and underwrites nothing.
"I don't want to learn about an operational exposure from an incident report. I want to know it's being watched before it becomes one."
What changesA lightweight, periodic governance review — the kind run before a programme needs saving, not after — paired with an honest read of how decisions actually get made, gives leadership a genuine early-warning system, not just a quarterly status deck.
"I keep building the dashboard that was asked for, and I keep watching it go quiet within a quarter."
What changesA dashboard built after the decision has been named, with an owner and a defined action already attached, gets used. One built to answer a vague request rarely does — and now that difference gets caught before the build starts, not after.
Six habits behind every engagement
Name the decision before the data
Before commissioning another data project, we name the specific decision it's meant to serve, and who's actually accountable for making it. In practice, the data requirement usually shrinks by half once that decision has a real owner — most of what a scoping document originally asked for turns out to be unnecessary once the target is precise.
Test the diagnosis, not just the symptom
A short, disciplined diagnostic — three sharp questions, not a six-week study — usually exposes whether data is really the constraint, or something else entirely: an unowned decision, an informal authority nobody's named, a definition three departments quietly disagree on.
Spend a shift where the metric is generated
A week of direct shop-floor observation surfaces workarounds, exceptions, and informal fixes that no report is built to show — because reports, by design, are built to summarize, and summarizing is exactly what hides this kind of detail.
Structure the loss instead of accepting the mystery
"We don't know why we lost the output" is rarely true. An issue tree, built deliberately and revisited after every shift, turns an unstructured question into a traceable one — and a traceable one into an opportunity register leadership can actually act on.
See the real operating model, not the org chart
A reorg that doesn't touch who actually decides what has changed the chart, not the operating model. We diagnose how decisions really get made — including the informal authority a chart never shows — and set it against a simple capability heatmap, so it's visible at a glance where the organization's real strengths and gaps sit, before recommending how decisions should be made.
Write the roadmap someone owns
A roadmap without an owner per line is a wish list wearing a roadmap's clothing. Every recommendation leaves with a named owner, a milestone, and a governance cadence built in from day one — not bolted on after the first review meeting goes badly.
The Operations Diagnostic Framework
The same five-step discipline runs through every engagement, whether the starting question is about production losses, a stalled roadmap, or a system nobody trusts anymore.
Each engagement moves left to right — but the framework is also a diagnostic loop: a "Govern" review often surfaces the next problem still framed, at first, as a data question.
Three weeks from vague pain point to actionable roadmap
You don't need a perfect scope to start. You need three weeks of disciplined framing — and a domain-grounded read of the numbers that a generalist analyst simply won't produce, because plant experience changes how you read a spreadsheet.
Week one — frame the decision
We name the decision the engagement is actually meant to serve, and the specific measures that would tell you it's been made well. This alone often reveals that the original request — another dashboard, another study — was aimed at the wrong target.
Week two — study current state and root cause
Time on the floor, across shifts, alongside the people generating the metric — not just time in the data warehouse. This is where the workarounds, exceptions, and informal authority structures that no report shows actually surface.
Week three — compare options and sequence
Findings become a small set of options, each with a rough cost and a rough payoff, sequenced into a roadmap with a named owner and milestone per line — not a slide of possibilities with no order attached.
Plant experience changes how you read a spreadsheet
Two advisors can look at the same numbers and read them completely differently — one sees figures, the other sees a changeover pattern, a shift-handover gap, or a maintenance backlog hiding behind an averaged line. That difference isn't a matter of analytical skill; it's a matter of having stood on enough plant floors, across enough countries and organizations, to recognize what a number is actually describing.
Before trusting any advisor's read of your operation, ask them how they'd interpret your numbers differently from a generic analyst. The answer tells you what they actually understand — and it's the same question this practice is built to answer well.
Ready to test the diagnosis before funding the cure?
A short, independent diagnostic is cheaper than a data platform built on the wrong assumption. Let's find out what's actually blocking the decision — at whichever level of the organization is feeling it most.