Selection
Buying an ERP? Score the shortlist, do not rank the demos.
Demo quality is a sales skill, not a product property. A practical scoring method for comparing ERP options on the things that decide whether the project succeeds.
Most ERP selections are decided in a room by whoever presented best. The software is rarely the problem; the way it was chosen is.
A demo tells you how well a vendor can demo. It does not tell you whether the system fits your work, whether the data will survive migration, or whether the team delivering it has done this before. Those are the things that decide whether you are still live in eighteen months.
Start from decisions, not features
Feature checklists are comfortable because they look objective. They are usually a list of everything any vendor might do, scored by people who have not run the process.
Instead, list the decisions the system has to support. For a distributor, that might be:
- Can we promise a delivery date and keep it?
- Which customer or product is actually profitable?
- What do we buy this week, and in what quantity?
- Where is this order, and what is blocking it?
A system that answers these four questions well is more valuable than one that wins a 300-row checklist. Score the decisions, and let the feature list be evidence rather than the agenda.
Score what is hard to change later
Some things are cheap to adjust after go-live: screen layouts, reports, notification rules. Others are expensive: the accounting model, unit-of-measure handling, tax logic, multi-company structure, and the core item master.
Weight your criteria accordingly. A useful split:
| Category | Weight | Why |
|---|---|---|
| Fit to core operations | 30% | This is what people use every day |
| Data model and migration | 20% | Most failures start here |
| Implementation partner | 20% | The same software succeeds and fails depending on who delivers it |
| Cost over three years | 15% | Licence plus implementation plus change requests |
| Ecosystem and hiring | 10% | Can you find people who know it? |
| Exit and data portability | 5% | What happens if this ends badly |
Adjust the weights, but decide them before the demos. Otherwise the weighting quietly follows whoever presented last.
Ask the same questions of every vendor
Script the evaluation. Every vendor gets the same scenarios, the same data, and the same time. For example:
- Show us a quote with a non-standard discount and a partial delivery.
- Show us what happens when a purchased item arrives short.
- Show us the report a sales manager would actually use on Monday morning.
- Show us how a mistake is corrected, and who can see the audit trail.
Watching a vendor handle a correction is more informative than watching them create a record. Anyone can show the happy path.
Separate the software from the partner
Two proposals can name the same product and be completely different projects. Ask:
- Who specifically will be on the team, and for how many days?
- What has this team delivered that resembles our scope?
- How do you handle scope change, and at what rate?
- What does your handover look like, and what do we own at the end?
- What is your escalation path when something is late?
A strong partner will have uncomfortable answers ready. A weak one will redirect to the product.
Price the whole three years
Licence cost is the visible number and rarely the decisive one. Build a three-year total:
- Licences and hosting.
- Implementation and configuration.
- Data migration, including cleanup you have not done yet.
- Integrations (payments, banks, e-commerce, payroll).
- Internal staff time for testing and training.
- Change requests after go-live.
- Exit costs: export, rebuild, or both.
A cheaper licence with a heavier integration burden is not cheaper. Put the numbers side by side, and state your assumptions so they can be challenged.
Make the no-change option compete
Every evaluation should include the status quo, costed honestly: the spreadsheets, the manual reconciliation, the stock write-offs, the reporting delays, and the key-person risk.
Sometimes the answer is that the current system is fine and the process is the problem. A selection process that cannot produce that answer is not a selection process; it is a procurement ritual.
Write the decision down
The final artefact should be one page:
- The decision.
- The two or three assumptions that matter most.
- The conditions under which the answer would change.
- Who owns the next step.
If the recommendation cannot survive being written down, it was probably a preference dressed as analysis.
This is the method bworkx uses in its fixed-scope assessment. It is deliberately boring: same questions, same weights, same evidence standard for every option.