ERP implementation
An ERP implementation is the project in which a chosen system is configured, connected, filled with your data and put into use. The technology is rarely where it goes wrong.
Which phases it has
Who decides what
Where it becomes irreversible
What is an ERP implementation?
An ERP implementation is the project in which a chosen system is configured around your processes, connected to your other software, filled with your data and put into use by your people. It starts after the choice and it does not end at go-live.
The line with selection is sharp: selection decides what you buy, implementation decides what you do with it. The second question takes more time, more money and more attention from your own people than the first.
That it rarely goes wrong on technology shows up in the figures. In the 2026 ERP Report by Panorama Consulting, almost a quarter of organisations reported going over schedule, and the most common cause was organisational: decision-making, resistance to change and process redesign.
An implementation is not an IT project with a business edge to it.
It is a series of business decisions that happen to get recorded in software. Which process changes, which exception is dropped, who gets to see the new figures: none of those are technical questions, and none of them belong to your vendor.
Which phases does an ERP implementation have?
Five phases, in this order. The names differ per vendor, the substance does not. Each phase carries where it goes wrong in practice, which is more useful than a list of activities.
Per phase, and where it goes wrong
| Phase | What happens | Where it goes wrong |
|---|---|---|
| Preparation | Scope, schedule and staffing are settled. The steering group meets for the first time. | Staffing is named as roles, not people. Who will actually do it only emerges once the project runs. |
| Design | Your processes are laid alongside the system standard. This is where you decide what you adapt and what you have built. | Every exception gets adopted instead of questioned. Custom work grows before a line of code is written. |
| Build and configuration | The system is configured, integrations are built and data is prepared for migration. | Data quality turns out worse than assumed. Cleaning it is your work, not the partner’s, and it rarely reaches the schedule early enough. |
| Testing | Key users run their own work through the new system, month-end close included. | Testing follows what was built rather than how your people work. Exceptions then surface after go-live. |
| Go-live and aftercare | The old system goes off, the new one on. Then comes the period where real use produces the remaining issues. | Aftercare has no owner. The partner scales down exactly when your people start asking questions. |
In practice the phases overlap, certainly in a rollout per site or per division. The order of the decisions still holds: design before build, and testing before go-live.
Who decides what?
The split of responsibility rarely gets written down, and that is exactly where the conflicts start. Five roles, each with the decision that belongs to it and the trap that comes with it.
Roles and decisions
| Role | Decides on | The trap |
|---|---|---|
| Executive sponsor | The goal, the budget, and whether the project continues when it hits trouble. | Only turning up at the steering group. Scope then gets set in the project team, out of sight of whoever pays for it. |
| Your own project lead | Progress, escalation and the daily trade-off between time, scope and quality. | Someone doing it alongside a full job. The role needs attention on the days it pinches, not on the days it suits. |
| Process owner | Which process changes and which exception is dropped. | Left unnamed, so nobody is allowed to say no to an exception. Every deviation then becomes custom work. |
| Key user | Whether what was built works the way the work is actually done. | Brought in only at testing. By then the design is fixed and every objection is a change request. |
| Implementation partner | How the system is configured within what you decide. | Handed decisions that are yours. Let that happen and every doubt is resolved as extra work. |
Which decisions become irreversible, and when?
Four moments where something is fixed that you can only undo at a cost. Each carries the question to ask out loud at that point.
At the scope, before the start
What is in this project and what is not, and which site or division follows later. This drives the schedule more than the technology does.
What happens to this project when the next division joins a year from now?
At every departure from the standard
Every time you have an exception built instead of retiring it, you buy that exception again at every major update.
What does it cost us to change this process to fit the system rather than the other way round?
At the data migration
Which history moves across and in what shape. Dirty data stays dirty after migration, and cleaning it afterwards costs more than cleaning it first.
Who owns this data, and who says whether it is good enough?
At the decision to go live
Going live with known open issues can be sensible, but only if it is settled who resolves them and by when. Otherwise they disappear into the daily grind.
Which open issues do we accept, and on what date are they gone?
Where do implementations get stuck?
Five patterns that keep returning, whatever the sector or the system. None of them is technical, and all five are visible early.
Staffing is named as roles, not people
A plan full of roles reads well and says nothing. Only once there are names, with days per week beside them, do you know whether the project is staffed.
Ask for names before the signature, not after.
Exceptions get adopted instead of questioned
Every department has a reason why it has to be different for them. Leave those reasons untested and you rebuild the old process in new software.
An exception nobody can explain is a habit.
Data quality reaches the schedule too late
Cleaning data is your work and it takes longer than anyone assumes. It usually appears on the schedule once the build is already running.
Start cleaning before you know which system it will be.
Testing follows the build, not the work
A test that follows the specification confirms the specification. Only your own orders and your own month-end close show what is missing.
Test on your hardest week, not on a clean example.
Bad news surfaces too late
Whoever reports progress is usually also the party causing the delay. That is not bad faith, it is a conflict of roles.
Have progress judged by someone who is not building.
Going deeper per topic
Two decisions come before the implementation and shape how it runs. Each has a page of its own.
The implementation partner
Which kinds of firms exist, where their interest sits, what stays yours, and how to test a candidate before you sign.
Read about choosing a partnerThe system itself
Which types of ERP system exist, what you meet per sector, and where they genuinely differ from one another.
Read about choosing a systemFrequently asked questions
- What is an ERP implementation?
An ERP implementation is the project in which a chosen system is configured around your processes, connected to your other software, filled with your data and put into use by your people.
It starts after the choice and it does not end at go-live. The period afterwards produces the open issues that real use makes visible.
- How long does an ERP implementation take?
That depends on your size, the number of sites and how much falls outside the standard. In the 2026 ERP Report by Panorama Consulting the median project timeline was nine months.
That median comes from an international survey of relatively large organisations, so it is an order of magnitude rather than a norm. The spread around it is wide.
- What is the difference between ERP selection and ERP implementation?
Selection decides what you buy. Implementation decides what you do with it: which process changes, which exception is dropped and who decides what.
The second question takes more time and more attention from your own people than the first, while most of the preparation tends to go into the first.
- Who is responsible for an ERP implementation?
The client stays responsible for the goal, the budget and the decisions about processes. The partner is responsible for configuration within those decisions.
That line rarely appears in the quote, and that is exactly where the conflicts start. Say it out loud before you sign.
- Why do ERP implementations get stuck?
Rarely on technology. The recurring causes are staffing that only exists on paper, exceptions nobody questions, data quality that reaches the schedule too late, and progress judged by the party doing the building.
All four are visible early, provided somebody asks. That is precisely the reason to separate judgement from execution.
Further reading
This page covers the phases, the roles and the decision points. The articles below go deeper into carrying it out.
- Eight steps from kickoff to go-live
- Outsource it or do it in house?
- Preparing your data for migration
- Bringing your people along before go-live
- Ready to go live, or not yet
- Keeping control without partner ties
This page was last reviewed on 3 September 2026.
Have an implementation watched over
We sit on your side of the table: we do no building and hold no vendor ties. That lets us judge progress without a stake in the outcome.
Where we help
- Saying the split of responsibility out loud before you sign
- Reviewing design choices that create custom work
- Judging progress separately from the party building it