Gartner has been publishing the same statistic for twenty years: 50 to 70 percent of ERP implementations « fail » in some way. They are over budget, late, missing scope, or never adopted. The numbers haven’t moved despite better products, better methodologies and more experienced consultants.
That is because the industry keeps treating symptoms instead of causes. Late project ? Add more developers. Missing scope ? File a change request. Poor adoption ? Run more training sessions. None of these fix anything because the real problem is rarely where it looks.
This article is about the root cause framework we use at Asio Services to clean up broken ERP projects. It’s the framework we wish more partners used, because most ERP failures are not failures of Business Central. They are failures of analysis.
The symptom vs root cause distinction
A symptom is what hurts. A root cause is why it hurts. In ERP, the gap between the two is often three layers deep, and the layers look very different from each other.
Classic example: « Our purchase order approval workflow is too slow. » That’s the symptom. The root cause is rarely in the workflow itself. Layer one: the approver is overloaded with notifications and ignores them. Layer two: the approval matrix has 7 tiers instead of 3 because nobody trusts the system. Layer three: the company has never written down what they actually want to control versus what they pretend to control. The real fix is at layer three. Everyone tries to fix at layer one.
The five most common root causes we find
After rescuing dozens of broken BC projects, we see the same five root causes again and again.
Root cause one: process undefined. The most common pattern. The company never wrote down its own processes. They asked the partner to « automate what we do today », but « what we do today » is different in each person’s head. The result: a system that fits nobody.
Root cause two: data treated as an afterthought. Master data quality was assumed, not verified. Duplicates, missing fields, obsolete codes were migrated as-is. Now every report is unreliable and every analytic decision is contaminated.
Root cause three: customization instead of standardization. The partner customized BC to match every existing process, no matter how outdated. Five years of BC updates later, the system is unmaintainable and locked on an old release.
Root cause four: partner pleasing client. The partner never said no to a single request. Every « nice to have » became a development. The system is bloated, slow, and expensive to evolve.
Root cause five: change management skipped. The technical project was perfect on paper but nobody on the business side was prepared. Adoption never happened. The system runs but the business runs in Excel beside it.
The 5 Whys, the ERP version
The classic Toyota « 5 Whys » framework works on ERP problems if you have the discipline to keep asking. Here is a real example from a client we helped.
Problem: monthly close takes 15 days instead of the expected 5.
Why 1: because the consolidation report has to be rebuilt manually every month. Why 2: because intercompany eliminations are entered in Excel after the BC close. Why 3: because the BC intercompany module was not configured for the new entities added in 2023. Why 4: because the partner was never asked to update the configuration after the acquisition. Why 5: because the company had no internal owner for the BC roadmap after go-live.
The symptom was a 15-day close. The fix the partner had been proposing was « better reports ». The real root cause was governance: there was nobody on the client side who owned the BC roadmap. That’s the fix.
Why most partners refuse to do root cause analysis
If root cause analysis is so powerful, why don’t more partners use it ? Three reasons.
First, it’s slower. Asking five whys takes hours. Treating symptoms takes minutes. Partners on tight margins favor the fast solution.
Second, it shifts blame. Root cause often points back to a decision the partner made (or didn’t push back on). Partners avoid analysis that risks accountability.
Third, it requires senior consultants. You can’t do real RCA with a junior. Most partners staff junior on day-to-day work and reserve seniors for sales. RCA breaks that economic model.
The partners who do RCA properly charge more, deliver less volume, and have happier clients. The choice is yours.
How to spot a partner who does root cause work
Three signals tell you a partner is serious about root cause analysis.
First signal: they ask « why » a lot during your first meeting. Not in a Socratic-annoying way, but with curiosity. They want to understand the chain behind your request before they propose a fix.
Second signal: they have a paid discovery phase. RCA cannot fit in a free sales meeting. A partner who charges for discovery is a partner who plans to do the analysis right.
Third signal: they have war stories about clients they refused to help. Partners who do RCA sometimes conclude « Business Central is not the right answer for you ». If a partner has never said no to a prospect, they have never done real diagnosis.
The Asio Services way: clean ERP, no quick fixes
We built Asio Services around root cause analysis. That is why we start every engagement with a paid discovery, why we have senior consultants on every project, and why we sometimes recommend clients not to start at all.
We call this approach « ERP propre » (clean ERP) : no patchwork, no sparadrap, no symptomatic fixes that come back as bigger problems next quarter. It costs more in time upfront. It saves an order of magnitude in costs and pain downstream.
If your Business Central is showing symptoms (slow close, unreliable reports, low adoption, recurring tickets), the answer is not always more development. It might be a root cause analysis.
→ Book a free discovery call with Asio Services. We will help you separate symptoms from causes and tell you, in plain language, whether the fix is in Business Central or somewhere else.
