ERP Implementation Guide: How to Plan, Run and Finish an ERP Project

Most ERP implementation guides describe a tidy sequence of phases. Real projects are messier. Requirements change, data turns out worse than anyone admitted, key users get pulled back into their day jobs, and a go-live date set in a board meeting starts driving decisions it shouldn't.

This guide covers what actually determines whether an ERP implementation works, in the order you will meet those decisions. It is written for owners, finance leads and operations managers who are about to sponsor or run a project — not for consultants.

What "done" should mean

Before planning anything, agree what success looks like. "The system is live" is not a success criterion. Better examples:

• Orders are entered once and flow through to delivery and invoice without re-keying.
• The warehouse picks from the system, not from printed spreadsheets.
• Finance closes the month in five working days using system data.
• Stock accuracy at location level is above an agreed threshold after three months.

Write three to six of these down. They will settle arguments about scope later, because every proposed feature can be tested against them.

The phases, and what each one is really for

1. Discovery

Discovery is where you learn how the business actually runs — which is rarely how the process documents say it runs. Good discovery includes walking the floor, sitting with customer service, watching a month-end close and collecting every spreadsheet people rely on.

The outputs are a process map, a systems inventory, a data quality assessment and a prioritised requirements list. Each requirement should be tagged as configure (standard functionality), extend (custom work), integrate (another system does it) or defer.

2. Solution design

Design turns requirements into decisions. The important ones are expensive to reverse once transactions exist:

These decisions deserve workshops with the people who will live with them, a written rationale, and sign-off before build starts.

3. Build and configure

Build should be iterative. Every two weeks, the team should demonstrate working functionality on your own data. Demonstrations surface misunderstandings while they're cheap to fix — a wrongly interpreted pricing rule found in week six costs hours; found in user acceptance testing it costs weeks.

Custom development deserves scepticism. Every customisation is code you'll maintain through every upgrade. Push configuration as far as it will go first.

4. Data migration

Data migration is the most underestimated workstream in nearly every project. Treat it as its own project with an owner, from week one:

1. Profile source data — duplicates, gaps, inconsistent units.
2. Cleanse at source where possible, with business owners deciding ambiguous cases.
3. Map every field and document transformation rules.
4. Script loads so they can be repeated identically.
5. Rehearse at least two full mock migrations.
6. Reconcile counts, stock quantities and values, open orders and the trial balance after each run.

We cover this in depth in the ERP data migration guide.

5. Testing

Unit and integration tests catch technical problems. User acceptance testing catches business problems — but only if users write the scenarios. They know the edge cases: the customer who always orders in odd quantities, the supplier who ships partial deliveries, the product returned under warranty after a price change.

Test integrations with failure in mind: what happens when the web shop sends a duplicate order, when a token expires, when a carrier API is down?

6. Training

Train by role, on the transactions each person performs, in an environment loaded with their own data. Time training close to go-live — two to three weeks before is usually right — and leave behind short, task-based guides.

7. Cutover and go-live

Cutover follows a runbook written and rehearsed in advance: transaction freeze times, final extracts, loads, reconciliations, smoke tests and a formal go/no-go decision against agreed criteria. If the numbers don't reconcile, you don't go live. That rule protects everyone.

8. Hypercare

The first month after go-live is when trust is won or lost. Plan for daily check-ins, fast resolution of blocking issues, and close support through the first period close. Don't let the implementation team disappear on go-live day.

Roles you can't skip

• Executive sponsor — owns the business case and breaks ties.
• Project owner — makes day-to-day decisions with authority.
• Key users per department — define requirements, test and train colleagues.
• Data owners — decide how to clean and map their data.
• Partner project manager and consultants — design, build and guide.

The most common staffing failure is assuming key users can do project work on top of their full-time jobs. Back-fill them or plan for slippage.

Phasing: why less is more at first

A first phase that covers the core transactional flow — sales, purchasing, inventory and accounting — and goes live cleanly beats a big-bang launch of eight modules that nobody fully understands. Manufacturing detail, advanced planning, field service and HR can follow once the foundation is stable.

Phasing also spreads change management. People absorb a new way of working better in two or three waves than in one.

Budget realism

Licences are rarely the biggest cost. Implementation services, data migration, integrations, training and internal staff time usually dominate. Build in contingency — 15–20% is common — and track change requests visibly. We break the cost drivers down in how much ERP implementation costs.

Signs your project is going off track

• Design documents aren't signed off, but build has started.
• Demonstrations are on demo data rather than yours.
• Data migration hasn't had a full rehearsal by the midpoint.
• Key users are missing workshops.
• The go-live date hasn't moved despite scope growing.

Any one of these is recoverable. Several together usually mean the plan needs resetting. See common ERP implementation mistakes for more.

Final thought

ERP implementations succeed when they're treated as business change projects supported by software, not software projects that happen to affect the business. Get scope, data and people right, and the technology usually follows.