Why ERP implementations fail to deliver the visibility they promise.
Mid-market businesses keep buying ERP visibility and keep failing to receive it. The ERP is rarely the problem. The operating model around it is — and the part of the project that would have fixed that was usually descoped before the implementation began.
- By Malik Asad Ali
- January 2026
- 13 min read
In this article
A mid-market business signs off on an ERP implementation expecting to come out the other side with weekly visibility across operations, margin, cash and pipeline. Eighteen months and several million dollars later, the system is live, the data is technically correct, and the leadership team is still running the operational review off a spreadsheet a senior analyst rebuilds each Monday morning.
This is not an unusual outcome. It is a structural one. The ERP delivered exactly what it was specified to deliver. The visibility the leadership team wanted was never something the ERP, on its own, could install. And the part of the project that would have built it was usually the first thing cut when the implementation timeline slipped.
The problem is not the ERP. The problem is operating-model debt that no system, on its own, can pay down.
01
The visibility a leadership team actually wants
When mid-market leadership teams describe “the visibility we need from the ERP,” they tend to mean four things stacked on top of each other.
They want to see, on a weekly cadence, where margin is actually sitting across the live portfolio of work. Not at month-end, two weeks after the data was relevant. Weekly. Live.
They want exception management. They don’t want a 40-page dashboard. They want a short list of things that have moved outside expected boundaries this week — projects, contracts, clients, subbies — and an evidence trail showing why.
They want decisions to land in one operational forum, not be re-litigated in three. The leadership team should be looking at the same numbers as the operations team, sourced from the same place, with the same definitions of what each metric means.
They want, above all, to trust the reporting. To stop running the silent second mental check during every meeting — “is this current?” “did this come out of the system or did someone adjust it?”
Notice what this list is not. It is not “more data.” It is not “a better dashboard tool.” It is operating-model architecture: cadence, exception thresholds, single source of truth, definitional clarity. The ERP is a necessary input to delivering it, but it is far from sufficient.
02
Why the ERP project doesn't deliver it
ERP implementations in the mid-market follow a recognisable pattern. The selection phase is intense and well-managed. The implementation phase delivers the system on time and roughly on budget. The reporting phase — which is where the visibility was supposed to land — gets descoped, deferred or quietly handed back to the business to build itself.
This is not because the implementation partners are bad. It’s because the visibility the leadership team wants is operating-model work, not system work, and the implementation contract was scoped around the system. The reporting layer that would have delivered the visibility — the metric definitions, the cadence design, the exception management framework, the single source of truth conventions — was either out of scope, undersold, or sacrificed to the timeline.
The result is predictable. The system goes live. The data is in it. The dashboards exist. But the leadership team can’t get the operational view they need, because the operating model that would have produced that view was never built. So a senior analyst rebuilds the Monday operational pack from extracts, and the business pays for the ERP and the operating model separately — once in cash, once in senior time.
The ERP is a necessary input to delivering visibility, but it is far from sufficient. The reporting layer that would have closed the gap is usually descoped before the project starts.
03
The four operating-model gaps no system can close
In every ERP-visibility-gap engagement we’ve run, the same four operating-model failures sit underneath the symptom. The system can support the fixes, but cannot, by itself, make them.
1. No single source of truth on the metric
The leadership team thinks “margin” means one thing. The operations team thinks it means a slightly different thing. The finance team has a third definition. The ERP can store any of the three, but it cannot decide which one the business is going to use. Until the operating model fixes the definition, the reporting will always feel slightly off, and the trust will never fully arrive.
2. No cadence design
The system can produce reports daily, weekly, monthly, on demand. The question is what gets produced when, who reviews it, and how decisions cascade from it. Without a cadence design, the reporting either drowns the leadership team (everything, all the time) or starves them (a 40-page month-end pack with nothing useful in between). The right cadence is an operating-model decision, not a system one.
3. No exception management
The system can flag every variance from plan. Most flag too many. The operating-model question is which variances genuinely warrant leadership attention this week, what threshold each is held to, who owns the response, and how it gets escalated if it doesn’t resolve. Without this framework, the leadership team learns to ignore the system’s flags, and the next time something actually matters, they ignore that one too.
4. No reporting-trust architecture
The leadership team trusts a number when they can trace it back to operational reality without re-checking. That requires definitional clarity, a single source, a known refresh cadence, and visible data lineage. The ERP can provide the plumbing. The trust is built by the operating model — and trust, once broken, takes longer to restore than the original implementation took to deliver.
04
One commercial fit-out, one rebuild
A useful example. We worked with a commercial fit-out business in NSW running fifteen to twenty active projects at any given time. The business had implemented separate systems for estimating, project management and finance — each well-chosen, each fit-for-purpose, none of them speaking to each other.
Margin reconciliation was happening at month-end, two to three weeks after the data was actually relevant. By the time the leadership team saw a project’s margin position, the project had usually moved on, and the conversation in the weekly project review was being held on numbers everyone in the room knew were two weeks stale.
Worse than the lag was the trust gap. The leadership team had stopped fully trusting the project margin reports they were seeing. Not because the data was wrong — the data was actually fine — but because the reconciliation step in the middle was opaque, and the leadership team had no way to verify whether what they were looking at was a clean ERP output or a number a senior PM had adjusted offline.
The work was structural, not technological. We:
01
Rebuilt the project controls layer around real-time margin visibility — defining what “margin” meant project by project, with consistent treatment across the portfolio.
02
Redesigned the weekly project review cadence around live job data — same numbers in the room as the operations team was using on site, sourced from the same place, refreshed on a defined rhythm everyone could see.
03
Integrated the estimating, project management and finance layers so margin moved through the systems without manual reconciliation in the middle.
04
Built a project margin dashboard sourced directly from live operational data, with project-level drill-down available the same week the data was captured.
The leadership team gained portfolio-level margin visibility for the first time. The weekly project review, which had been a debate about which numbers were current, became a conversation about which projects actually needed attention.
We’ve seen the same pattern in a different sector. A multi-site allied health provider in Victoria was assembling monthly reporting from four operational systems by hand — one senior person spending five days each month producing a pack that was already partly out of date by the time it landed in the leadership meeting. The rebuild followed the same logic: define the metrics, design the cadence, source from operational systems, eliminate the manual reconciliation. The five days of monthly assembly disappeared. Reporting became something the leadership team could trust without re-checking.
The mechanism in both cases was identical. Different sector, different systems, same operating-model failure underneath.
05
What to do before the next system selection
If your business is approaching an ERP selection — first time, replacement, consolidation — the most valuable work to do before the system decision is to fix the operating-model gaps the new system will otherwise inherit.
The principle
An ERP cannot deliver visibility the operating model has not yet defined. Build the operating model first. Let the system support what’s already working.
01
Define what each leadership-relevant metric means, with one definition per metric, signed off by the leadership team and the finance team together. If you cannot define it before the system is selected, no system will define it for you.
02
Design the cadence — what gets reviewed when, by whom, with what decisions cascading from each forum. The system supports the cadence; the cadence is not a system feature.
03
Decide the exception thresholds. Which variances genuinely warrant leadership attention this week, at what level. Build the discipline of acting on flags before the system starts producing them.
04
Establish the single source of truth for each metric. Where the number originates, how it refreshes, who is responsible for its accuracy, what its data lineage is. This is operating-model architecture, not a system selection criterion — but it changes how you scope the implementation.
Done before the selection, this work makes the system implementation faster, cleaner and more likely to deliver the visibility the business actually wanted. Done after the selection, it usually gets descoped under timeline pressure, and the business pays for both halves separately for the next three years.
06
The shift that matters
The deepest mistake mid-market leadership teams make with ERP projects is treating visibility as a system deliverable. It isn’t. Visibility is what you get when the operating model is designed to produce it and the system is set up to support what’s been designed. Put the design first, and the implementation works. Put the implementation first, and the design rarely catches up.
The businesses we’ve seen come out the other side of this work share one quiet characteristic. The leadership team and the operations team look at the same numbers, sourced from the same place, refreshed on the same rhythm, with the same definitions. The Monday operational pack writes itself. Decisions land in one forum and stay landed.
That, more than the ERP itself, is what mid-market leadership teams were trying to buy in the first place. The system is one input. The operating model around it is the rest.
MA
Malik Asad Ali
Founder, Infinikey Consulting
Malik works with mid-market businesses across construction, field service and care to redesign the operating model when growth has outpaced the structure behind it. He writes from inside the engagements.
More from Insights
Continue reading.
Operating Model
The hidden cost of process fragility in mid-market businesses.
Construction
Why variations and claims get lost in mid-market construction.
02
Start Here
Begin with a Transformation Diagnostic.
A short, structured engagement that shows where control is breaking down across workflows, systems, reporting and accountability. And what to fix first.
- 2–4 Weeks
- Senior-Led
- Fixed Scope
- A clear view of the biggest operational bottlenecks across your workflows, systems, and reporting layer.
- A 90-day plan that prioritises the changes most likely to unlock control and margin.
- Conducted personally by senior consultants, not handed to a team of analysts.