Your ERP project will fail on the process, not the software

I have been on both sides of an ERP implementation. First as the accountant who had to live with the result — reconciling what the system produced against what the business actually did. Later as the person writing the code. The view from each side explains the other.

Here is the pattern I keep seeing: the software works. The process around it does not.

The translation problem

An ERP implementation has two groups of people in the room. One group knows how the business really runs — which approvals are theatre, which reconciliation exists because of one incident in 2019, why the site engineer always submits late. The other group knows what the system can do.

Neither group speaks the other’s language, so a document is produced to bridge them. Requirements are written down, signed off, and handed across. And in that handover the important things get lost, because the important things were never written down. They were never written down because to the finance team they are too obvious to mention, and the consultant did not know to ask.

Six months later there is a system nobody trusts, and a parallel spreadsheet doing the real work.

What “process first” actually means

Everyone says process before configuration. Almost nobody does it, because doing it properly is uncomfortable and slow, and configuration feels like progress.

Doing it properly looks like this:

Sit with the people doing the work. Not their managers — the person who actually enters the invoice. Ask them to do it while you watch. You will find three steps that nobody documented and one workaround that the entire month-end depends on.

Write the as-is process without judgement. The goal is not to find fault. It is to produce a description the team recognises as true. If they read it and say “well, that’s not quite how it works”, you are not finished.

Then design the to-be process on paper. On paper, in plain language, before anyone opens the system. This is where you delete steps rather than automate them. Automating a step that should not exist is the most expensive mistake in this business — you pay for it once to build, and forever to maintain.

Get it agreed by finance and operations together. Not sequentially. In the same room. Most process disputes are really disputes about who absorbs an inconvenience, and those only resolve face to face.

Only then does it become configuration.

Why the accountant should be in the build

The conventional structure puts a functional consultant between the finance team and the developer. It is a reasonable structure, and it adds a layer of translation loss at exactly the point where precision matters most.

The questions that decide whether an implementation works are not technical questions:

• Should this be a separate cost centre or a project dimension?
• What actually happens when a contractor invoices for work that fails inspection?
• Does retention get held per invoice or per contract, and who releases it?
• When the budget is exceeded, does the system block the transaction or flag it?

A developer without accounting background will build exactly what the specification says. An accountant without development background will not know which options were even available. The answers get better when one person holds both — or when the two people involved have spent enough time together to stop needing the document.

The uncomfortable conclusion

If your ERP project is struggling, the instinct is to look at the software. Change the module. Add a customisation. Escalate to the vendor.

Look at the process first. In my experience the software is doing precisely what someone told it to do, and the problem is that nobody checked whether that was what the business needed.

That is not a satisfying answer, because it means the fix is slow, human, and involves sitting in rooms with people. But it is the one that works.