ERP implementation: seven decisions that decide the outcome
ERP projects rarely fail because of the software. They fail because seven decisions were made badly — or worse, never made at all.
Across enough implementations one pattern repeats: whether an ERP project succeeds is settled in the first few weeks, across seven decisions most organisations don't realise they're making.
None of them belong to the software vendor. All of them are yours.
1. Who owns the project — the business or IT?
It has to be the business. IT is the delivery partner, not the owner.
When IT owns it, the project becomes a technical one: measured in modules enabled and integrations shipped. When the business owns it, it's measured by "did month-end close get shorter" — which is what the organisation actually needs.
Warning sign: the person deciding how a process should be standardised has no authority to change that process.
2. Change the process to fit the system, or the system to fit the process?
This is the most expensive decision, and most organisations dodge it by answering "both".
The workable rule: processes that create competitive advantage get kept and customised; processes that differ out of habit adopt the system's way.
Your distinctive way of selling may be a genuine advantage. Your receipt numbering scheme almost certainly isn't. Every customisation is a debt repaid at every future upgrade — spend the customisation budget where it buys advantage.
3. Phase one scope — how much is enough?
Both directions are costly.
Too broad: eighteen months, exhausted participants, key people leaving mid-flight, and nothing visible to the organisation in the meantime.
Too narrow: the new system runs alongside the old one, data splits in two, and you've acquired a second source of truth — the exact thing the project existed to remove.
A good test: phase one must be enough to close one complete cycle. Order to cash, or purchase to pay. A closed cycle produces reconcilable data; half a cycle doesn't.
4. Who are the primary users — and were they asked?
The people who will enter data daily must be in the design phase, not first appear at training.
The reason is pragmatic: they know the exceptions no process document records. Which customer always pays late but still gets shipped. Which item sells by carton but arrives by pallet. Those details decide whether the system is usable, and they live only in people's heads.
5. Legacy data — how much comes across?
The default should be: less than you think.
Migrating ten years of history feels safe, but it drags ten years of dirty data into the new system — and you've just skipped the one cleanup opportunity the project affords.
A practical proposal: opening balances + open records (unpaid receivables, undelivered orders, live contracts) + cleaned master data. Keep history in the old system read-only, or export it to an archive for lookup.
6. Who decides when two departments disagree?
This sounds like internal politics. It is the most important technical question on the list.
At some point accounting wants revenue recognised at moment A, sales wants moment B, and both have a case. Without someone who can settle it within a week, the project stalls — or worse, each department is configured its own way and you now hold two definitions of revenue inside one system.
Name the decider before the dispute, not after.
7. How is success measured?
"Go-live" is not a metric. It's a milestone, and the easiest one.
Pick three or four business metrics, measure them before you start, measure again after three months live:
- Days to close the month
- On-time delivery rate
- Days sales outstanding
- Times the same data is re-keyed
Measuring beforehand is the step usually skipped, and it's the step that makes every later number mean something. Without a baseline, every improvement is a feeling.
Three signs a project is slipping
Catching it early is far cheaper than rescuing it late:
The customisation list grows after every meeting. Usually means decision #2 was never settled, and each department is negotiating separately.
Primary users are absent from review sessions. They will be present at go-live, which is the most expensive moment to discover a design error.
Nobody can answer "what percentage are we at". Which means scope was never defined concretely enough to measure.
In closing
Modern ERP software is good enough. The difference between a project that lands and one that never ends is almost always the seven decisions above — and whether they were made explicitly, early, by the right person.
A decision not made is still a decision. You just don't get to choose its outcome.