ERP projects rarely go wrong because of one dramatic error. More often they drift off course through a run of decisions that each looked sensible at the time: a sign-off that never quite happened, a change agreed in a corridor, a default setting that nobody questioned. Those decisions add up. By the time the team notices, the new system is carrying habits the business never meant to keep.
This article looks at ERP implementation mistakes from the angle of the decisions made during a project: who makes them, what the supplier is allowed to decide, how changes are approved and how known problems are handled at go-live. It sets aside the general list of reasons projects fail, because the detail sits inside the day-to-day choices.
The advice is general. Your project will depend on your processes, your people and the product you choose, so treat each section as a set of questions to put to your team and your supplier, not as rules to copy.
The decisions behind ERP implementation mistakes
Not every project decision carries the same weight. A choice about the layout of a screen can be changed in an afternoon. A choice about how the business identifies its products may shape reports, integrations and stock history for years. Mistakes start when the second kind is handled as if it were the first.
Sorting decisions by how hard they are to undo
Before detailed design begins, list the decisions the project will need and mark each one as easy or hard to reverse. Give the difficult ones more time, more senior attention and a written note of the reasons. That list then becomes the agenda for steering meetings, so the hard choices are not left until the final weeks.
Bringing the people who do the work into the room
Decisions taken only by directors often reflect how the business is meant to run rather than how it runs. Ask the people who handle orders, stock and invoices to review each process decision before it is final. Corrections are far easier to make in a workshop than after the system has gone live.
Decision rights that stop decisions stalling
A common pattern is a steering group that discusses every issue at length and agrees very little. Decisions drift, the supplier waits for answers and the team quietly makes its own choices. Clear decision rights reduce that drift.
One named owner for each area
Give each functional area, such as sales, purchasing, stock or finance, one person who makes the final call on questions in that area. That person can consult others, but the answer should not depend on who happens to be in the meeting. Show the owner beside every open question.
A decision log that everyone can see
Keep a simple log with the question, the options considered, the decision, the date and the owner. When a decision is revisited, add a note rather than overwriting the original entry. A visible log stops old arguments resurfacing and gives new team members the reasons behind the design.
Escalating before the deadline, not after it
Agree a rule for when an open question goes to the steering group. Useful triggers are a decision that blocks the next piece of work, or one that has been open for longer than the team agreed. The rule works best when it is known in advance, so nobody has to justify raising a problem.
Letting the supplier's defaults make business decisions
Suppliers and implementation partners are good at configuring a product. They should not decide how your business sells, buys or accounts for its work. Default settings look neutral, but they carry assumptions about how a business operates, and those assumptions go unchallenged when nobody asks about them.
Set-up choices only the business can make
Some choices depend entirely on your own rules. Examples include approval limits for purchasing, the tax codes you use, who can post to which accounts, how documents are numbered and which unit of measure each product is sold in. Ask for each one to be listed, with a named person who signs it off.
Example data is not a decision
Demonstration data is built to show a product at its best, with clean records, a single warehouse and tidy pricing. If the team treats that picture as the blueprint, the first live month will bring surprises. Replace the examples with your own records as early as you can, even if you start with a small sample.
Asking why a default is set the way it is
When a default seems unfamiliar, ask the supplier why it is set that way and what would change if you set it differently. A good partner can answer in plain terms. If the answer is vague, that is worth knowing before the design is signed off.
Treating one-way decisions as if they were two-way
Some decisions become very hard to reverse once data sits in the system. These are the ones to slow down for, because changing your mind later can mean rewriting history.
Item codes, units and the chart of accounts
The way products are coded and grouped, and the structure of the chart of accounts, flows into every report and every integration. Changing them after a year of transactions means recoding history, re-testing reports and explaining the new numbers to everyone who relied on the old ones.
Costing and valuation choices
The method used to value stock or cost a job affects reported margins from the first transaction. Changing it part way through a financial year makes comparisons misleading. Agree the method with your accountant before go-live, record the reasons for it and apply it consistently.
Reversing a decision after data has been loaded
When a hard decision does need to change, the honest question is how much history will move with it. Sometimes the answer is a small adjustment. Sometimes it means repeating part of the data migration. Write that estimate down before the decision is confirmed, so the people approving it can see the trade-off.
Approving change requests one at a time
Change requests arrive steadily during an ERP project, and each one usually has a sensible reason behind it. The mistake is approving them individually, so nobody sees what the set of changes does to the design, the timeline and the testing.
Each change looks small on its own
A new approval step, an extra field or a different report layout can each seem minor. Together they change how the process runs, how long each step takes and how many people need training. Treat every change as a decision with a visible effect, not as a quick favour.
A change log that shows the combined effect
Record each request with its reason, the people affected, the work it adds and its effect on the go-live plan. Review the log at a fixed point each week. That view makes it easier to say yes to a change, to ask for a smaller version or to say not yet.
Deciding which changes can wait
Many changes can wait until after go-live, and the business is often better placed to judge them once the team knows the system. Keep a separate list of post go-live improvements and agree when it will be reviewed. Changes needed for legal, tax or payroll reasons are different and should go ahead when required.
Going live with known problems and no agreed rule
Every go-live carries known problems, and a handful of minor issues on a live system is normal. The mistake is letting the date decide what happens to them, rather than an agreed rule that everyone understands before the final week.
Who can accept a known problem
Name the people who may accept a known problem on the business's behalf. Usually that means the process owner for the affected area and the project sponsor, acting together. The person who built the fix should not be the only one who decides it is good enough.
Writing down the workaround and the fix date
Each accepted problem needs three things on record: what staff should do in the meantime, who is fixing it and by when. A list with those three columns is far more useful than a general note that issues are being handled. It also tells the support team what to say when someone asks.
When the answer should be to stop
Some problems justify delaying go-live. Examples include a fault in how money or stock is recorded, a broken link to a system that must keep running, or a reporting error that would affect a statutory return. Agree those stop conditions in advance, so the decision rests on facts rather than on pressure to keep the date.
Old workarounds: the implementation mistake nobody notices
Many businesses rely on workarounds: a spreadsheet that corrects a figure, a manual step that fixes a recurring error, an email that approves a price. When a new system arrives, those workarounds can survive simply because nobody decided their fate.
Workarounds that quietly survive
A workaround copied into the new process by default can become a permanent part of the design, and it is easy to forget why it exists. Ask people to list the workarounds they rely on today, including the ones they no longer think of as workarounds.
Keep, change or retire
For each workaround, decide whether it will be kept, changed or retired. Record each decision in a short list, such as:
- Kept: the reason, and who reviews it
- Changed: the new step and the person who owns it
- Retired: the date and how staff will be told
FAQ
What are common ERP implementation mistakes?
Common mistakes include decisions with no named owner, supplier default settings accepted as business rules and change requests approved one at a time. Known problems are often accepted at go-live with no agreed rule, and old workarounds carry into the new system by default. Each one can be spotted early and recorded, which makes it easier to avoid.
How can a business make decisions faster during an ERP project?
Name one owner for each functional area and keep a decision log with dates and reasons. Set a clear trigger for escalating open questions, so they reach the steering group before they block the work. Involve the people who run the processes, so decisions reflect how the work is actually done.
Which ERP decisions are hardest to reverse?
Item coding, the structure of the chart of accounts, the method used to value stock and the way jobs or projects are costed are among the hardest to change. Each one shapes historical records and every report built on them. Those decisions deserve more time, senior attention and a written record of the reasons.
Should a business go live with known problems?
Sometimes, but only under an agreed rule. Each accepted problem needs a named owner, a documented workaround and a fix date. Faults that affect money, stock records or statutory reporting are a reason to delay go-live rather than accept the risk.
How do you stop change requests from derailing an ERP project?
Log every request with its reason, the people it affects and its effect on the plan. Review the log at a fixed point each week so the combined impact stays visible. Many changes can wait until after go-live, and a separate post go-live list makes sure they are not lost.
Do we need an outside partner to avoid ERP implementation mistakes?
Not always, but an outside view can help. A partner can challenge default settings, test the decision list and spot gaps between your processes and the system. Whoever you work with, the business should keep ownership of its own decisions.
Final thought
ERP implementation mistakes are seldom about a single choice. They come from decisions left open, handled by the wrong person or made without a view of what came before. Naming those decisions early, sorting them by how hard they are to reverse and recording who owns each one reduces much of the risk.
Projects that stay on course tend to share a few habits: a visible decision log, a clear rule for escalation and a willingness to ask why a default is set the way it is. None of these needs special software. They need discipline and the confidence to say that a question is not settled yet.
Mirex Agency can help if you want an outside view on the decisions in front of you. We build ERP solutions for UK small and mid-sized businesses, and we are glad to talk through your decision list and open questions. You can reach us at hello@mirexagency.com.
