After more than 20 ERP implementations across manufacturing, logistics, trading and real estate businesses, I’ve seen most of the ways these projects go wrong. The software is rarely the problem. The problem is almost always something that happened before the implementation began.
Here is what I’ve observed, and what makes the difference between an implementation that transforms a business and one that leaves it worse off than before.
The promise versus the reality
The ERP sales pitch is compelling: one system for all your data, real-time dashboards, automated workflows, accurate financials, instant reports. Every implementation partner has a demo showing it working beautifully.
The reality for many businesses, particularly SMEs, is that two years after go-live, the ERP is half-configured, the finance team is still maintaining parallel spreadsheets, the dashboards nobody uses are frozen on last quarter’s data, and the founder has largely stopped looking at it.
This is not rare. Studies consistently put ERP implementation failure or underperformance rates above 50%. For SMEs in India, the proportion is likely higher.
Why this happens: the five patterns I’ve seen repeatedly
1. No one mapped the business before configuring the software
An ERP is a system designed to model your business. If you don’t have a precise understanding of your business processes (how an order moves from inquiry to invoice, how inventory is tracked, how you handle returns, how inter-branch transfers work) you cannot configure an ERP to mirror them.
What typically happens instead: the implementation partner uses the default configuration, makes adjustments for the most visible processes, and the less obvious ones (the edge cases that account for 40% of the actual workload) are handled manually or ignored entirely.
Six months later, the business has an ERP that works for 60% of its transactions and a team that has learned to route the rest around it.
The fix: Before any software is opened, map every significant workflow end-to-end. Know your exceptions. Know your edge cases. Understand how your GST obligations interact with your transaction flows. The mapping exercise takes time. It is also the single most valuable thing you can do.
2. The wrong ERP was chosen for the business
There is no universally best ERP. There is only the right ERP for a specific business at a specific stage of its development.
Zoho is excellent for multi-location businesses with field operations, strong compliance requirements and a need for fast deployment. It is not ideal for a manufacturer with complex bill-of-materials management and multi-level production planning.
Odoo handles manufacturing and inventory complexity well and is highly customisable. It requires more implementation effort and ongoing technical maintenance.
SAP Business One is the right choice when you have complex group financials, sophisticated reporting requirements and the budget to match.
Choosing the wrong platform (often because it was the cheapest, or because the implementation partner preferred it, or because a competitor uses it) means you’re fighting the software from day one.
3. The implementation was treated as an IT project, not a business project
Most ERP failures I’ve seen have one root cause: the business owner handed the project to an IT person or an accountant and assumed it would get done.
An ERP implementation is a business transformation project. The decisions made during configuration (how your chart of accounts is structured, how cost centres are defined, which approval workflows are automated, what the reporting hierarchy looks like) are business decisions. They cannot be made by someone who doesn’t understand the business’s strategy, its growth plans and what management actually needs to see.
When the business owner is not involved in the key configuration decisions, the system gets built around what the accountant finds convenient, not what the business needs to scale.
4. Data migration was underestimated
Moving your historical data from your old system into the new ERP is typically the most time-consuming and error-prone part of the project. Most businesses underestimate it significantly.
The issues are predictable: opening balances don’t reconcile, historical inventory levels are wrong, supplier and customer master data is inconsistent, old transactions have classification errors that carry forward into the new system.
When these are not cleaned up before migration, the new system inherits the problems of the old one. The team loses confidence in the data quickly. A team that doesn’t trust its own system will find workarounds.
5. Training was delivered once and never reinforced
ERP training is typically delivered during the go-live period, when the team is already under pressure to learn a new system while keeping the business running. Most of it is forgotten within three months.
The businesses that successfully embed an ERP invest in reinforcement: short sessions focused on specific workflows, access to documentation, a point person who can answer questions, and a culture where using the system correctly is treated as the default, not the workaround.
What a successful implementation looks like
Across the implementations I’ve been involved in, the ones that genuinely transformed the business had a few things in common:
The business owner was actively involved in the configuration decisions. Not the day-to-day work, but the key structural choices about how the system modelled the business.
The processes were mapped before the software was configured. The implementation captured how the business actually worked, not how the implementation partner assumed it worked.
The data was cleaned before migration. Reconciliation happened before go-live, not after.
The reporting was designed around what management needed to make decisions. Not a standard report package: the specific numbers, by location, by product category, by customer, that the management team needed to run the business.
There was a plan for the post-go-live period. Someone was responsible for resolving issues, training new staff and ensuring the system continued to be used correctly.
The specific value of having a CA involved in ERP implementation
One pattern I’ve noticed: businesses that involve their CA in ERP selection and configuration make better decisions about the financial dimensions of the system: chart of accounts structure, GST mapping, cost centre design, reporting hierarchies.
The financial architecture of an ERP is the foundation everything else sits on. If it’s designed poorly, the reports are wrong, the reconciliations are harder and the system’s ability to support business decisions is limited. Getting this right from the start pays for itself many times over.
If you’re evaluating an ERP, in the middle of a troubled implementation, or running a system that isn’t delivering what was promised, a conversation about your specific situation is usually enough to identify what’s gone wrong and what can be done about it.