Seven ERP Implementation Mistakes That Cost Six Figures

ERP projects rarely fail loudly. They fail as a slow accumulation of small compromises until, eighteen months in, half the company is still running the spreadsheets the system was supposed to replace. After fourteen years of these implementations, the failure patterns repeat with remarkable consistency.

1. Automating a broken process

If your purchase approval takes nine days because it passes through four people who each wait for a weekly meeting, digitising it gives you a nine-day digital process. Map the process, fix the process, then automate the fixed version. The discovery phase is where ERP money is saved or lost.

2. Letting scope be defined by the loudest department

Whichever team is most vocal in requirements workshops gets the most functionality — not necessarily the team where the business value is. We now score every requested module on transaction volume, error cost and how many people it touches, then sequence by that score rather than by enthusiasm.

3. Treating data migration as a final-week task

Migration is not a task at the end of the project. It is a project running alongside your project.

Your existing data is dirtier than you think. Duplicate vendors, items with three different unit conventions, customers with no GST number. Start extraction and cleansing in week two, not week twenty. Run a full trial migration at the one-third mark so the surprises arrive while there is still time to absorb them.

4. Skipping the parallel run

Running the old and new systems side by side for one full cycle is expensive and tedious, and every client asks to skip it. The ones who do skip it discover their reconciliation gaps in the middle of a live month-end close, with no fallback. We now treat the parallel run as non-negotiable.

5. Under-investing in training

A two-hour demo before go-live is not training. Budget for role-specific sessions, written quick-reference guides for the ten tasks each role does daily, and a designated super-user inside each department. The super-user model matters more than any other single adoption factor we have measured.

6. Customising before living with the standard flow

Every customisation is a permanent tax on upgrades and maintenance. Insist that teams run the standard workflow for one full cycle before requesting changes. Roughly half of all customisation requests evaporate once people have actually used the system rather than imagined using it.

7. No named owner after go-live

ERP is not a project that ends; it is a system that lives. Without an internal owner responsible for master data quality, permissions and enhancement requests, entropy sets in within months and the workarounds begin. Name that person before you go live, not after.

The pattern underneath all seven

Every one of these mistakes is cheap to avoid in the first six weeks and expensive to fix in month nine. Front-load the unglamorous work — process mapping, data cleansing, training design, ownership — and the technology part turns out to be the straightforward half.