Your ERP is live. Congratulations! Now the real work begins.
Two years. That's how long many mid-size companies spend selecting, configuring, testing, and rolling out their new ERP system. Two years of steering committee meetings, data migrations, consultants in the building, and change management workshops. And then, finally go-live.
The celebrations are real. The relief is real. But so is what happens in the months that follow: the quiet realization that not everything is quite as solved as everyone assumed it would be.
"We spent € 2.4 million and two years on this system. Why is Karen still running the weekly inventory report in Excel?"
This is one of the most common, and least discussed, problems in enterprise software. Call it the Go-Live Illusion: the belief that once the system is in, the problems are out. In reality, implementation is just the beginning of a different kind of work.
55% of ERP projects exceed budget or timeline
3 in 5 companies still rely on Excel post-go-live
18 mo. average time before shadow systems reappear
Excel doesn’t die. It relocates
Here's a pattern that plays out across industries: the ERP goes live, and within a few months, spreadsheets quietly reappear. Not in the obvious places, the system handles basic orders, invoices, and inventory fine. But in the in-between places: the workarounds, the custom calculations, the edge cases nobody configured for.
Planners build pivot tables because the demand forecasting module doesn't match how their product lines actually work. Finance teams maintain a master Excel workbook because the consolidation reports take too long to run or does not include the right dimensions. Operations managers track exceptions manually because the alerting logic in the system is too blunt.
This isn't user failure. It's a signal. When Excel keeps showing up after a major ERP rollout, it points to one of two root causes and usually both.
Problem one: the system doesn't support your business well enough
Standard ERP modules are designed for standard businesses. But most companies that go through a multi-year ERP implementation have something non-standard about them: a unique pricing model, a complex production structure, regulatory requirements specific to their market, or customer relationships that don't fit the system's data model cleanly.
During implementation, these gaps are often addressed with compromise: the business adjusts its process to fit the system, the consultant finds a creative workaround in the system, or the requirement is deferred to "phase two" which, more often than not, never arrives. The result is a system that covers 80% of the business well and 20% awkwardly. That 20% is where Excel lives because users look for alternatives if the system is not efficient. That 20% creates 80% of the frustration or inefficiencies.
This is where custom software enters the conversation. Not as a replacement for the ERP, but as a bridge: purpose-built tools that extend the system into the areas where generic functionality falls short. A custom calculation engine that plugs into the ERP's data. A specific workflow application for a process the standard module can't accommodate. A reporting layer that pulls from the ERP but presents information in the way the business actually thinks.
Problem two: requirements evolve rapidly
ERP systems are configured for a point in time. They're built around the business processes that existed during the design phase, often 18 -24 months before go-live. By the time the system is live, the business has already moved on. Changing or new processes, new market segments, evolving customer requirements, a recently acquired subsidiary with its own process logic. Adapting ERP systems is expensive, takes a lot of time and is mostly not anticipated in the budget, certainly not shortly after the ‘Go live’.
The questions worth asking now
If your ERP has been live for six months or more, the most valuable thing you can do is audit where the workarounds are. Not to blame people for using them, but to understand what they reveal about gaps in usage or gaps in the system itself.
Where is Excel still being used, and why? Which reports are still being built manually? Which processes have more steps than they should? Which teams have quietly rebuilt something that the system was supposed to handle?
The answers will tell you whether the issue is training and adoption - in which case the path forward is structured enablement and process redesign - or whether the system genuinely lacks the efficient implementation of business logic your organization needs, in which case targeted custom development is likely the more honest solution.
Either way, the conversation is overdue. The ERP isn't finished when it goes live. It's finished when the business actually runs efficiently on it and that milestone is further along than most project plans acknowledge.
