ERP Implementation Mistakes: When to Fix and When to Stop
A few weeks after a new ERP system goes live, the complaints start. Invoices from one branch carry the wrong prices, the stock report no longer matches the shelves, and finance says the month-end close is slower than before. The chief executive now faces a hard question: is the system the problem, so we stop and find a replacement, or is the implementation the problem, so we fix it and carry on?
Getting this wrong is expensive either way. Abandoning a rescuable project writes off everything spent, and the next system usually hits the same problems because their causes were never addressed. Pushing on with a system that does not fit the business means spending more on something that will not work. Below we sort the common mistakes into vendor-side and client-side, give an example and a fix for each, then offer a framework for the fix or stop decision and a five-step recovery method.
The examples are hypothetical, drawn from recurring patterns in implementation projects, not from specific clients.
Mistakes on the Vendor Side
The vendor knows the system and owns the implementation method, so it carries much of the responsibility. These are its most frequent early mistakes.
1. Shallow requirements analysis
Some vendors start configuring after one questionnaire or meeting with management, never sitting with the people who do the daily work. The system ends up reflecting how management thinks the business runs, not how it really runs.
Example: a distributor with 12 warehouses uses a different price list per region. The system got one price list because nobody asked the regional reps, so invoice discrepancies appeared in week one.
The fix: separate sessions with each department to document the real workflow and its exceptions, then rebuilt price lists linked to regions and customers. This is a configuration error, not a software flaw, and usually takes a few weeks to correct.
2. Migrating data without cleaning it
Moving old data across as it stands brings its problems along: duplicate items, customers without VAT numbers, long-dormant accounts. The new system exposes these more clearly than the old one, so it looks as if it caused them.
Example: a 3,000-account chart of accounts was migrated in full, and about a third turned out to be duplicates or dormant. Reporting became slow and confusing, and accountants were unsure where to post.
The fix: review master data, merge duplicates, deactivate unused records, and name an owner for each data type to approve new additions.
3. Classroom training that ignores daily work
A tour of the screens teaches an employee how to open a screen, not how to complete a full transaction. The first time they must match an invoice to a purchase order and a receipt, nobody is there to ask.
Example: an accountant learned to create supplier invoices but never practised matching them to orders and receipts. Unmatched invoices piled up and payments slipped.
The fix: retrain on real scenarios per role using company data, with a short guide per process and a key user in each department for daily questions.
4. Excessive customization
Accepting every change request without assessing its impact pulls the system away from its standard version. Each later update becomes a project of its own, and breakages become more likely.
Example: dozens of code changes were added in six months, many just to mimic the old screens. An important update then took months to apply because of conflicts.
The fix: review each customization. Could configuration do it? Does it serve a real goal or just a habit? Whatever stays is documented and tested with every update.
5. No clear project manager on the vendor side
A technical team without a lead means conflicting priorities and support requests that get lost between people.
Example: the client sends requests to three people, and each assumes another is handling them. Issues pile up and trust erodes.
The fix: one named project manager with real authority, a single shared issue log, and a fixed weekly meeting to review progress.
Mistakes on the Client Side
The client is a full partner, and its mistakes do as much damage as the vendor's. Some of them no vendor can fix.
1. Not freeing up an internal team
When staff get the project on top of their normal jobs, it always comes last. Decisions slip, testing is postponed, and the vendor waits.
Example: the finance manager responsible for approving the new chart of accounts was busy with the quarter-end close and preparing the VAT return. Approval slipped by six weeks, and the whole project slipped with it.
The fix: name an internal team with clear authority, release key users for at least half their time until the system is stable after go-live, and schedule critical phases away from closing periods and tax filing deadlines.
2. Constantly changing requirements
Adding requests at every meeting without assessing their effect on time and budget is scope creep, one of the most common causes of delay.
Example: after the purchasing setup was finished, the client asked for a supplier rating system with fifteen criteria. The request was reasonable, but its timing pushed go-live back by two months.
The fix: a formal change request log that estimates the time and cost impact of each request before it is approved, plus a phase two list for anything not essential to go-live.
3. Resistance from middle management
Senior management approves the project, but some department heads quietly work against it, seeing the new transparency as a threat to their authority or a spotlight on weaknesses in their area.
Example: a warehouse manager kept a paper ledger "just in case" and entered movements late. The gap between system and reality grew daily, until people said the system's figures could not be trusted.
The fix: involve department heads in the design early, tie their objectives to indicators the system measures, and have senior management state clearly that the system is the only official source of figures.
4. Unrealistic expectations
Some clients expect full capacity within weeks. In practice the first months are for learning and tuning, and some indicators dip before they improve.
Example: management expected reporting time to fall sharply at go-live. After a month they questioned the system's value, though training was unfinished and no full month-end close had happened yet.
The fix: a roadmap with milestone indicators at 30, 90 and 180 days, agreed before go-live. For what to expect in the first stage, see our guide to the first 90 days after an ERP go-live.
5. Skipping proper testing
Rushing go-live without thorough testing means errors surface in front of customers and suppliers, not in a test environment.
Example: e-invoicing went live without anyone testing credit notes for returns. On the first return, nobody knew how to issue a credit note linked to the original invoice, and the customer's refund was delayed by several days.
The fix: a user acceptance testing phase of at least two weeks, with documented scenarios that cover complete end-to-end processes and the exceptions for every module.
Summary: Each Mistake and Who Owns the Fix
| Mistake | Primary owner | Nature | Typical time to fix |
|---|---|---|---|
| Shallow requirements analysis | Vendor | Configuration | Weeks |
| Uncleaned data | Vendor and client | Data | Weeks |
| Classroom training | Vendor | Skills | Days to weeks |
| Excessive customization | Vendor and client | Technical | Weeks to months |
| No internal team | Client | Management | Starts as soon as decided |
| Scope creep | Client | Management | Starts as soon as decided |
| Middle management resistance | Client | Cultural | Months |
| Skipped testing | Both | Methodology | Weeks |
Almost every item here concerns configuration, data, skills or management, all fixable without changing the system. The problem that genuinely calls for stopping is of a different kind, covered next.
Fix or Stop? A Decision Framework
Not every mistake justifies stopping, and not every project deserves to continue. What matters is the kind of problem, whether it can be fixed, and how deeply it touches the core of the business.
| Criterion | Points toward fixing and continuing | Points toward stopping and reassessing |
|---|---|---|
| Nature of the problem | Configuration, data or training | The system does not support the way the business works |
| Scope of impact | One module or department | Every department and core process |
| Cost of fixing | A limited share of the project budget | Close to the cost of starting again |
| Time to fix | A few weeks to two months | More than six months |
| Vendor's response | Acknowledges the issue and offers a clear plan | Denies, stalls, or has stopped responding |
| Regulatory compliance | Achievable through configuration | Not achievable, such as integration with e-invoicing |
Example of a fundamental flaw
A contracting company chose a retail system because it was cheapest. It has no concept of projects, progress billing, site labor costs or retention, and every attempt to bend it needs heavy custom development. The problem is the selection, not the implementation, so the right call is to stop and choose again, keeping the cleaned data and documented processes already produced.
Example of a fixable mistake
A distributor's inventory reports do not match reality. Investigation shows opening balances were migrated without a stock count, and some warehouses record inter-branch transfers late. The system is sound. A full count, corrected balances and storekeeper training on transfers can settle the figures within two months.
Five questions to ask before deciding
- Can the system handle our core process through configuration, even if it does it differently from what we are used to?
- Have we tried the same process with clean data and a trained user before passing judgment?
- Is the problem confined to one module, or does it affect all of them?
- Does the system meet regulatory requirements such as e-invoicing, VAT and payroll?
- Would any replacement system face the same problem because the cause sits inside our own organization?
If the answer to the last question is yes, stopping will solve nothing.
A Five-Step Recovery Method
- Joint diagnosis: vendor and client list every problem, its source and real impact. Document first, because rushed fixes treat symptoms.
- Priority ranking: critical issues stop daily work or compliance, such as being unable to issue a valid e-invoice. Medium issues slow work down. Low issues are improvements. Start on the critical ones immediately.
- A plan with dates: every problem gets an owner and a deadline, with a mandatory weekly review attended by the executive sponsor.
- Test before rolling out: each fix is tried in the test environment, then in a single branch or department, and only then rolled out across the company.
- Record the lessons: log each mistake and its resolution so it is not repeated when a branch or module is added.
A Hypothetical 60-Day Recovery Plan
Suppose a mid-sized distribution company went live two months ago and now faces three problems: inaccurate stock balances, a backlog of unmatched supplier invoices, and a late monthly close. A recovery plan might look like this:
| Period | Work | Owner | Milestone |
|---|---|---|---|
| Week 1 | Joint diagnosis and a single issue log ranked by priority | Project managers on both sides | Log approved by the executive sponsor |
| Weeks 2 and 3 | Full warehouse stock count and correction of balances | Warehouses with finance | Count reconciled with the system |
| Weeks 3 and 4 | Corrective training on supplier invoice matching and inter-branch transfers | Vendor | Unmatched invoices falling each week |
| Weeks 5 and 6 | Review of settings and permissions, and an end to entries outside the system | Both | No transactions recorded outside the system |
| Weeks 7 and 8 | A complete month-end close on the system using a checklist | Finance | Close finished by the target date |
The plan starts with diagnosis rather than solutions, gives every stage a measurable milestone, and is followed weekly by the executive sponsor.
If You Decide to Stop: Protect What You Have Built
Stopping does not mean everything spent is lost. Make sure you:
- Keep the cleaned data: master data that has been cleaned is a valuable asset that will move to whatever system comes next.
- Keep the process documentation: process maps and test scenarios can save weeks on the next project.
- Review the contract: termination terms, ownership of configurations and customizations, and handover of data in a usable format.
- Understand why the selection went wrong: if you do not know why you chose a system that did not fit, you may make the same choice again.
Do Early Mistakes Mean the System Is Useless?
No. Early problems are expected in any ERP implementation. What separates successful projects from struggling ones is how quickly mistakes are found and how they are handled. The causes are usually understandable:
- The transition gap: moving from manual work or an old system to an integrated one takes time to adjust to.
- Real requirements emerging: some needs only show up once the system is in daily use. The new system reveals what the old processes used to hide.
- The learning curve: user errors in the first weeks are normal and fall with practice.
Judge the system after the pilot period, the tuning phase and the first full close, not at the first error. To measure progress objectively, see our article on ERP implementation KPIs.
How to Assess the Vendor During a Crisis
How a vendor handles problems tells you more than any sales presentation. Watch three things:
- Speed of response: does diagnosis start within days, or do weeks pass before anyone replies?
- Transparency: does the vendor own its share of the mistakes and explain the causes in plain language, or does it always blame the users?
- Quality of solutions: does it provide a written plan with dates and named owners, or general promises?
Be fair with yourself too. If decisions stall on your side, data arrives late and requirements change weekly, much of the solution is in your hands.
How to Avoid These Mistakes From the Start
Most of what this article describes can be prevented with good planning before implementation begins: an engaged executive sponsor, written objectives with numbers attached, a dedicated internal team, data cleaning before migration, and testing with real scenarios. We cover these factors in detail in our article on ERP implementation success factors, and the human side in our guide to change management and user adoption.
At Tranquil, implementation includes certified training, on-site or remote, organized in tracks by role, with 30 days of support after training, plus customization of screens, reports and approval workflows where there is a genuine need.
Frequently Asked Questions
Is it normal for mistakes to appear early in an ERP implementation?
Yes. This happens in every technology transformation project. What matters is how quickly problems are spotted and how methodically they are handled, not whether they appear at all.
When is stopping the project necessary?
When the chosen system is fundamentally unsuited to the way the business works, when the cost and time to fix it approach the cost of starting over with an alternative, or when the system cannot meet a regulatory requirement such as e-invoicing.
Does the client share responsibility?
Certainly. Delayed decisions, data that never arrives, constantly changing requirements and a team that was never freed up are all on the client side, and the vendor cannot fix them alone.
How long does it take to rescue a struggling project?
Configuration, data and training mistakes are usually fixed within a few weeks to two months if they are diagnosed early. Internal resistance and excessive customization take longer.
What should I do if my current project is struggling?
Start with a written diagnosis of the problems, ranked by priority, before making any decision. You can also contact the Tranquil team to discuss where your project stands.