7 ERP implementation mistakes that cost UK businesses the most

We have seen ERP projects succeed in six weeks and fail over eighteen months. The difference is almost never the software. It is a handful of avoidable mistakes, most of which are made early. Here are the seven we see most often in UK businesses, and how to avoid each one.

1. Starting without a reason

"We need an ERP" is not a reason. "Our stock is wrong 20% of the time and it is costing us orders" is. Without a clear problem to solve, scope grows, priorities blur and nobody can say whether the project worked.

Avoid it: write down the three things that must be different after go-live. Use them to make every scope decision. Our article on signs you have outgrown spreadsheets can help you name the problems.

2. Skipping or rushing discovery

Discovery is where the implementer learns how your business actually works. Skip it and the real requirements appear halfway through the build, when changes are expensive. Our implementation steps guide explains what proper discovery looks like.

Avoid it: insist on workshops with each department and a written specification you sign off before the quote is fixed.

3. No project lead with authority

Someone on your side has to make decisions, chase colleagues for data and testing, and protect the go-live date. If that person does not exist, or has no time, the project stalls at every step.

Avoid it: name the lead before the project starts and clear part of their diary. It should be someone who understands the business, not necessarily the most technical person.

4. Migrating bad data

Years of duplicated customers, inconsistent product codes and obsolete records, loaded into a new system because "we might need them". The result is a new system nobody trusts, on day one.

Avoid it: clean master data before migration, migrate open items and opening balances, and leave most history in the old system read-only. Our data migration guide walks through it.

5. Over-customising to match the old way

Every workflow the old system forced on you, rebuilt in the new one at a cost, even though the new system has a better standard way to do it. This is how projects double in price and lose the benefit of moving.

Avoid it: for each customisation, ask whether the outcome could be achieved with a standard feature and a small change in habit. Customise where it creates real advantage, not where it preserves comfort.

6. Testing with tidy examples

Testing a perfect order from a perfect customer proves nothing. The system will meet the awkward cases on day two: the partial delivery, the credit note, the customer with two addresses, the supplier bill that does not match the order.

Avoid it: give each department a list of their ten most awkward real scenarios and test every one before go-live.

7. Going live without training and support

One "super user" trained, everyone else shown the system on the morning of go-live, and the implementer gone by lunchtime. Staff revert to spreadsheets within a week.

Avoid it: train each type of user on their own tasks, with written guides, before go-live. Agree a hypercare period with fast response for the first weeks. Go live at a period boundary, not in your busiest week.

The pattern

Notice that six of the seven happen before or around the build, not during it. The technical work is the part implementers control; the mistakes are the parts clients control. A good implementer will push you on all seven. If yours does not, that is a warning in itself.

If you want a project run the way this article describes, start with our free discovery call. Read about our ERP service or request a quote.

Frequently asked questions