A managing director put this to us a few weeks ago, having just finished his selection: "I have an ERP with the best features. But how does it fit my business, and how is it going to make me perform better?"
The question is the right one. It simply came too late: by that point the tool had been chosen and the budget set. It should have opened the project.
Functional coverage measures the wrong thing
Selection grids compare features. They produce a coverage score, and that number often decides the choice. Yet a feature that exists, a feature that is actually used and a feature that changes a result are three different things. The grid measures only the first.
That is why an ERP can post excellent coverage and leave every company indicator exactly where it was. Nothing failed. It is simply that nobody ever asked the system to produce anything beyond screens that matched the specification.
The project has an owner, the outcome does not
An ERP project is very well equipped to succeed as a project. It has a scope, a budget, a go-live date, a steering committee, a sponsor. Each of those has a named owner.
The expected outcome usually has none. Shortening the accounting close, cutting data-entry errors on orders, compressing the quote cycle: these appear in the scoping note from time to time, rarely in the project's governance. Nobody answers for them the way they answer for a budget.
The consequence follows mechanically. A project can hold its dates, stay inside its envelope, deliver its whole scope — and change nothing measurable. That is no one's fault. The structure never asked the question.
Processes get decided by default when nobody decides them
An ERP carries a way of working. If the company does not define its target processes, the vendor's standard imposes them.
That is not a flaw: adopting the standard is often the better decision, and it is what we recommend in most cases. But it has to be a decision. When it is not taken, it surfaces after go-live — a control that used to exist has gone, an approval loop has been invented by configuration, a business rule nobody ever wrote now applies to everyone.
The trade-off between standard and custom development follows the same logic, and it is settled at the same moment: we set it out in Standard or custom ERP.
No measurement before, no evidence after
Most ERP projects cannot answer the question "did this help?". Not because the result is poor, but because no starting point was ever recorded.
The measurement has to be taken beforehand, on a small number of indicators the company already recognises. An indicator invented for the project convinces nobody and does not survive go-live. An indicator the business was already following, which then moves, needs no commentary.
The questions to settle before choosing a tool
Four questions, in this order. None of them is about a feature.
- What has to be different in six months, and for whom? Phrased in terms of the business, not of modules. "Sales people produce a quote without calling production" is an objective. "Roll out the CPQ module" is not.
- How will we know? An existing indicator, recorded before the start, with its current value.
- Who in the business answers for it? Not the project manager, who answers for the project. Someone whose daily work changes if the outcome is missed.
- Which process are we willing to change, and which one is not up for negotiation? The answer drives the volume of custom development, and therefore the cost of ownership over five years.
None of these questions is an IT question. They are settled with the executive team and the business leads, and they shape everything that follows — including the choice of tool, which should follow from them rather than precede them.
What an ERP actually does
An ERP does not produce performance. It removes obstacles that were preventing it: information that had to be keyed in twice, a control that arrived too late, a delay that came from waiting rather than from processing.
That still requires having named those obstacles. This is the scoping work, and it is the part of the project that does not come with the licence.
