How to prepare your business for ERP implementation

ERP implementations rarely fail because the software was wrong. They fail because the organisation was not ready to be described by software — and the implementation became an attempt to define the business and install a system at the same time.

The preparation that determines success happens before any vendor demo. Here is what it consists of.

1. Write down how the work actually happens

Not how it is supposed to happen. How it happens. Who approves a purchase over a certain value. What someone does when stock arrives without paperwork. Which figure people trust when two reports disagree.

These informal rules are the real operating model, and they are usually undocumented because they live in the heads of a handful of long-serving staff. An ERP will encode whatever it is told. If it is told the official process rather than the real one, staff will work around it within a month, and you will have paid for a system that everybody bypasses.

2. Find out what state your data is in

Every migration surfaces the same discoveries, and it is far cheaper to make them now than during go-live.

• Customers who exist three times under slightly different names
• Stock items with no unit of measure, or two different units meaning the same thing
• Opening balances nobody can substantiate
• Suppliers still active who last traded four years ago
• A chart of accounts that grew by accretion and no longer maps to how the business is managed

Clean this before migration, not during. Data cleansing under go-live pressure is where scope and timelines die.

3. Decide who owns each decision

An implementation generates hundreds of small decisions: how departments are structured, what a branch means for reporting, whether a particular cost is inventory or expense. If ownership is unclear, each one becomes a meeting, and the project stalls on consensus rather than complexity.

The single best predictor of a smooth implementation is a named decision-maker who is available, informed, and empowered to say no.

4. Be honest about what you are changing

There are two kinds of ERP project. One replaces the tools and keeps the process. The other changes the process and uses new tools to do it. Both are legitimate. Problems begin when an organisation says it wants the first and behaves as though it bought the second — or sells the second internally as though it were the first.

Decide which one you are doing, say it out loud, and let that decision drive scope, budget, and how much change staff are asked to absorb.

5. Plan for the period after go-live

Go-live is the beginning of the difficult part, not the end. The weeks that follow are when real transactions meet real configuration and every assumption gets tested. Budget attention, not just money, for that period.

• Someone available daily to answer process questions, not only technical ones
• A defined route for reporting a problem, and a defined person who triages it
• Agreement on which reports must be correct on day one and which can wait
• A parallel-run period for the highest-risk area — usually financial close

The honest summary

Readiness is mostly organisational, not technical. If processes are understood, data is clean, decisions have owners, and the scope of change is named honestly, most competent systems will succeed. If those things are missing, no system will rescue the project — it will only make the gaps visible faster and more expensively.