Contents
Short answer
A three-hundred-line comparison grid separates no one. The proposed approach starts from problems, distinguishes blocking from structuring and comfort needs, demands a demonstration on your own data, questions the share of custom work, has data entry tested on the shop floor, computes the full five-year cost and checks the exit before the entry. Five blocking needs, a demo on your data, a full five-year cost and a reversibility clause are usually enough.
Choosing an ERP commits a company for ten years or more. Yet the most common method remains the three-hundred-line comparison grid, filled in by the vendors themselves, where everyone ticks “yes” everywhere. Such a grid separates no one. Here is an approach that produces a defensible decision.
1. Start from problems, not features
Before opening a single brochure, list the ten situations that cost you the most today: the order delivered late because material was missing, the project closed at a loss discovered three months too late, the day wasted rebuilding a batch file. Put a number on them, even roughly. That list becomes your real specification, and it fits on one page.
2. Separate the core business from the nice-to-have
Every ERP can print an invoice. Few can handle a variant bill of materials, finite-capacity scheduling or piece-by-piece traceability. Sort your needs into three categories:
- Blocking: without it, the product is eliminated. Rarely more than five points.
- Structuring: it shapes the organisation, but a workaround exists.
- Nice-to-have: pleasant, never decisive. Do not let it weigh on the final score.
3. Demand a demo on your own data
This is the most discriminating point of the whole exercise. Send each candidate three of your real items, with their bill of materials, their routing and a typical order. Ask that the demo run on those. A vendor who knows your trade will accept; the others will offer their demo set, always flawless, always beside the point.
Then watch how many clicks it takes to release a work order and to find the real cost of a finished project. These are the two gestures your teams will repeat thousands of times.
4. Question the custom development
Every custom development is paid for twice: at the order, then at every version upgrade. Ask what share of your needs is covered by configuration and what share requires code. Beyond fifteen percent of custom work, the product is probably not made for your trade.
5. Assess use on the shop floor
An ERP is filled in on the ground. If declaring an operation calls for six screens and a keyboard, it will be done at the end of the day, from memory, or not at all. The data will then be wrong, and every analysis built on it too. Have the data entry tested by an operator, not by the IT director.
6. Compute the full cost over five years
Add up subscription or licences, implementation, training, custom development, version upgrades and — the line regularly left out — your own teams' time during the project. It is that total, not the advertised monthly price, that allows an honest comparison.
7. Check the exit before the entrance
Ask the question plainly: if we leave in three years, in what format and within what time do we get our data back, and at what cost? A clear answer written into the contract says a lot about the confidence the vendor places in its own product.
In short
Five blocking needs, a demo on your data, a five-year full cost and a reversibility clause: these four elements are usually enough to separate candidates that three hundred criteria left tied.
