Before you buy an ERP, fix the process it will run

Why the project stalls in month four

The pattern is consistent enough to predict. Selection goes well. The demonstrations are impressive. The budget is approved. Then configuration begins, and the implementation team asks what looks like a simple question: what happens when a customer changes an order after the material has been issued?

Three people give three different answers, all of them correct descriptions of what actually happens today. The project pauses while the business decides. Multiply that by fifty process decisions and the timeline doubles, the cost follows, and the team concludes the software was the wrong choice.

The software was probably fine. The business was asked to codify processes it had never agreed.

Settle these before selection

Process as it actually runs. Not the diagram from a previous consultant. Walk the order from enquiry to cash and the purchase from requirement to payment, with the people who do the work. Write down where it stalls and where the exceptions live. Exceptions are where implementations get expensive.

Ownership. Every process step needs a name attached. Who approves a credit limit, who releases a dispatch, who authorises a purchase above a threshold, who can change a price. If that is unclear today, the system will simply force the question at the worst possible moment.

Master data. This is the least discussed and most damaging item. Duplicate customers, inconsistent item codes, missing supplier details and three versions of the same price list will move directly into the new system. Cleaning data is dull work that has to happen before go live, not after.

What management actually needs to see. Reporting requirements defined after implementation lead to a second project. Agree the ten or fifteen numbers leadership will run the business on, and check during selection that the system can produce them without custom development.

Choose the size of system the business can absorb

Ambition tends to drive selection upward. A platform designed for a multinational will technically run a mid sized trading business, but it will also demand a level of process discipline and internal capability the business does not have yet.

The better question is not which system is most powerful, but which system the team can be running competently within six months. A modest platform used properly beats a sophisticated one used partially.

Implementation is a business project with software in it

Treating it as an IT project is the second common mistake. The people who must change how they work are in sales, purchasing, stores, production and finance. If their managers are not visibly responsible for the outcome, adoption will be partial and the old spreadsheets will survive quietly alongside the new system.

Appoint an internal owner with enough authority to settle process disputes. Protect their time. Agree in advance how much configuration is permitted, because every customisation is a cost that returns at every future upgrade.

Plan for the dip. Productivity falls for a period after go live in almost every implementation. Teams that expect it manage through it. Teams that were promised a smooth transition lose confidence in the system precisely when they need to persist with it.

A closing thought

An ERP is an excellent way to enforce a process the business has agreed on and a very expensive way to discover it has not. Spend the first weeks on the process, the ownership and the data. The software decision becomes much easier afterwards, and much cheaper to live with.