What happens in each one
01 Discovery
Inventory every process, tool and spreadsheet the business actually runs on, as opposed to the ones on the org
chart. The output that matters is not a list of software. It is a map of who re-keys what, how many times, and
what breaks when that person is away.
The test of a good discovery is that it surprises the owner. If it only confirms what leadership already
believed, it was a survey of opinions rather than a look at the work.
Deliverable: a current-state map, including the spreadsheets nobody wanted to admit to.
02 Selection
Shortlist, then scripted demos on your own data. A scripted demo means you hand the vendor three transactions
from your business and ask them to run them end to end in front of you. Generic demos are theatre, and every
system looks excellent in one.
Then a fit-gap on the processes that matter, and here is the part that gets skipped: price the gaps, not the
licence. A gap is any process the system cannot do the way you need it done. Each one becomes configuration,
customisation, an add-on, or a change to how you work. All four have a cost, and only one of them appears on
the quote.
Deliverable: signed scope and budget, with gaps priced.
03 Process design
Future-state processes, chart of accounts, item master, units of measure, roles and approvals. This is the
cheapest stage to get right and the most expensive to revisit. A chart of accounts that cannot answer the
question you will be asked next year is a problem you will live with for a decade.
It is also where a business decides what it wants to stop doing. An implementation that preserves every
existing exception produces a system as complicated as the mess it replaced.
Deliverable: the blueprint, agreed by the people who run the processes.
04 Data migration
Cleanse, map, load: customers, vendors, items, bills of materials, open orders, open balances. This is usually
the largest single block of work in an erpification, and it is systematically underestimated because it looks
technical. It is not. Deciding which of four spellings of a customer name is correct is a business decision, and
it has to be made several thousand times.
There is a full data migration checklist covering what to
load, in what order, and how to prove it reconciled.
Deliverable: trial loads that reconcile to the old system, signed off by the function owner.
05 Testing and training
End-to-end scripts, quote to cash and purchase to pay, run by the people who will actually do the job. Not by
the project team, and not by the vendor. The purpose is partly to find defects and mostly to find the places
where the design assumed something untrue about the work.
Super users emerge here. They are the people who will answer their colleagues' questions for the next two
years, which is worth more than any training deck.
Deliverable: a go or no-go decision that someone is willing to sign.
06 Cutover and hypercare
Transaction freeze, final load, go-live, then weeks of close support while habits move across. Hypercare is not
a contingency. It is the stage where the organisation stops using the old way, and it needs to be staffed
deliberately, because the default is that everyone quietly keeps their spreadsheet as a safety net.
Deliverable: the first month-end closed inside the system.
Where the effort actually goes
Precise timelines depend on scope, so treat the shape rather than the numbers. In most mid-sized
implementations the effort distribution looks roughly like this, and it is not what people expect when they
start.
| Stage | Rough share of effort | Who does most of it |
|---|
| Discovery | Small | You, with an outside pair of eyes |
| Selection | Small | You |
| Process design | Moderate | Your process owners, with the implementer |
| Data migration | Largest | Your people, whatever the plan says |
| Testing and training | Moderate to large | Your people |
| Cutover and hypercare | Moderate | Everyone |
Notice how much of it is yours. The single most common planning error is budgeting for the implementer's hours
and not for your own team's, which is how implementations end up competing with a busy season and losing.
The three decisions that determine the outcome
Most of what happens in an implementation is reversible. Three things are not, or are painful enough that they
may as well not be.
- The chart of accounts. It decides which questions you will be able to answer without a
spreadsheet for the next decade. Design it around the decisions you make, not the ones your last accountant made.
- The item and customer master. One definition, one naming standard, one owner. Everything
downstream, from costing to reporting to inventory accuracy, inherits whatever you settle on here.
- Who owns the data. Not who maintains the server. Who is accountable for the list being
right. An unowned master list decays to the state it was in before you started, usually within a year.
How to tell a stage was skipped
You can usually diagnose an implementation in trouble by the symptom, because each skipped stage fails in a
characteristic way.
| Symptom | Stage that was skipped |
|---|
| A stream of change orders for things “nobody mentioned” | Discovery |
| A core process that the system cannot do, found after signature | Selection |
| The new system needs the same manual workarounds as the old one | Process design |
| People keep a private spreadsheet “just to be sure” | Data migration |
| Go-live week is spent discovering how the business really works | Testing |
| Six months on, half the team is back on the old method | Hypercare |
§
What finished means
Go-live is the midpoint. An erpification is finished when the first month-end has been closed inside the new
system and nobody has reopened the old spreadsheets. Until both of those are true, you are running two systems,
which is more expensive than either one.
Before stage oneIf you are not certain the business needs this at all, start with the
readiness check. It is twenty scored statements, and it tells you when the honest
answer is no.