How to implement an ERP successfully (and why projects fail)
The previous three lessons covered what an ERP is, when you need one, and how to choose between it and the alternatives. Suppose you've chosen your system. Now begins the stage where the investment is won or lost: implementation. The uncomfortable truth is that many ERP projects disappoint — not because the software is bad, but because of how it's rolled out. The software may be excellent and the result still poor, because what matters is how it's brought into the work. Let's understand why, and how to avoid it.
Why do projects stumble?
The reasons are recurring and well known, and most have nothing to do with the software itself:
| Reason | What happens |
|---|---|
| Unclean data | You move old mess into a new system, so the mess remains |
| No project owner | Everyone is responsible and no one is, so decisions stall |
| Switching everything at once | The team drowns, and any error halts all the work |
| Insufficient training | Staff quietly revert to their old way |
| Over-customisation | Complexity, cost, and hard upgrades later |
Five principles for a successful rollout
1. Clean your data before migrating
The new system reflects what you feed it. Move in duplicate customer lists and items with inconsistent names, and you get a newer mess. Set aside time to clean the data before the migration, not after. And cleaning is a business decision, not a technical chore: who approves the correct item name? Which record survives a duplicate? Settle these rules first.
2. Assign an internal project owner
One person from inside your business owns the decisions and tracks execution — not the vendor alone. The vendor knows their software, but they don't know your business the way you do. Give that owner enough time away from their daily tasks, because the project needs continuous follow-up, not a passing signature. A missing internal owner is among the most common causes of failure.
3. Roll out in phases, not all at once
Start with one module or department, stabilise it, then move to the next. A phased rollout contains errors and gives the team time to adapt. And once the first phase is stable, it becomes a reference the team learns from before the next one. A single big-bang switchover multiplies the risk needlessly.
4. Train before go-live, not after
A system doesn't run itself — it runs on the people who use it. Training the team before go-live turns resistance into acceptance. And don't settle for a single session; short, repeated training lasts longer than one intensive day. A staff member who doesn't understand the system will work around it.
5. Keep your processes standard where you can
Every extra customisation is a cost now and a burden at every future upgrade. Modify the system only where customisation makes a real difference, and adopt its ready-made way for the rest. The rule: change how you work to fit the system where it doesn't hurt you, and customise the system where there's no substitute for what sets you apart.
A concrete example
Two companies bought the same system. The first switched on every module in a single day without adequate training; the team was overwhelmed and stalled within a month, demanding a return to the old way. The second started with finance and inventory only, trained its team for two weeks, stabilised the two modules, then added sales after a month and HR after three. The system was identical — the whole difference was in the implementation. The lesson: phasing isn't slower; it's faster to a stable result — the haste that sent the first company back cost it the time twice.
Early signs the rollout is stumbling
A stall rarely happens suddenly; it is preceded by signs, and catching them early makes the fix cheap:
- Staff keep their old spreadsheets alongside the system.
- Simple questions go unanswered because no one owns the decision.
- Customisation requests pile up before the basics are stable.
- Data gets entered twice by hand because no one trusts the system's numbers.
Each of these is far cheaper to address early than to leave until the team rejects the whole system.
A checklist before go-live
- You cleaned the data, removed duplicates, and standardised naming.
- You assigned a clear internal project owner.
- You split the rollout into phases ordered by priority.
- You trained everyone who will use the system before go-live.
- You documented a fallback plan in case the first phase stumbles.