The right ERP is not the product with the most features. It is the system that meets your critical processes at an acceptable project risk and total cost, and that answers your integration, data management and growth needs sustainably. This article sets out the decision framework that belongs before any product comparison.
1. Define your processes before looking at ERPs
The first step is not to review products but to write down your own processes. For each main process, clarify three things: where the data is born, who enters it, and which decision is taken by looking at which output.
Demos entered without that work end in liking the screens you were shown; real fit is never measured.
Answer one more question up front: is the problem the ERP itself, or a process that was never built? If core finance, stock and order processes work and only one process is missing, building that process as a separate application and integrating it is usually a narrower risk. We cover that distinction in the packaged software versus custom development framework.
2. Prioritise the critical requirements
Weighing every requirement equally makes the outcome arbitrary. Split requirements into three classes:
- Must have: without these, operations stop or statutory compliance breaks.
- Should have: without these, significant inefficiency appears, but it can be managed temporarily.
- Nice to have: useful, but should not decide the outcome on its own.
Assign weights before seeing demos. Weights given afterwards drift toward the screens you saw.
3. Run a fit-gap analysis
Fit-gap is the real technical step of ERP selection. For each requirement, mark how the candidate system meets it:
| Mark | Meaning | Project impact |
|---|---|---|
| Standard | Met by the product's standard functionality | Lowest risk and cost |
| Configuration | Met through parameters, definitions or setup | Low risk; needs documentation |
| Development | Needs development by a method the platform supports | Creates duration, cost and upgrade impact |
| Integration | Met together with another system | Needs its own testing, reconciliation and monitoring |
| Not met | The candidate cannot meet this requirement | Grounds for elimination if the requirement is critical |
Ask for a day estimate on every item needing development or integration; that estimate belongs in a contract annex.
4. Evaluate the architecture, not only the functions
The feature list decides year one; the architecture decides the next five. What to examine:
- API and data access: which data is reachable by which method, is access included in the licence, are there volume limits?
- Extensibility: at which layer and by which method is development done? Does the vendor officially support that method?
- Upgrades: by which method are configurations preserved through version upgrades?
- Deployment model: cloud, on-premise or hybrid; how long can operations continue during a connectivity loss?
- Security and authorisation: role model, record-level rights, audit trail.
- Performance: what are response times on an installation with a transaction volume similar to yours?
5. Assess the implementation ecosystem
The ecosystem that will build and sustain the product matters as much as the product: consultant availability, the number and depth of partners, documentation quality, the support model and the developer pool.
Count your own side too: without a key user who can change a report or make a definition in-house, every small change becomes an external cost line.
6. Calculate total cost of ownership
Comparing licence prices is misleading. Compare over five years: licence or subscription, infrastructure, configuration, development, integration, data migration, training, internal staff, maintenance and support, and version upgrades. The line-by-line calculation is in how to calculate ERP cost, and the ERP investment and TCO pre-assessment tool produces a complexity picture for your own scope.
7. Run the demo on your own scenario
A vendor-prepared demo shows the flow where the product is strongest. Give them your own end-to-end scenario instead and ask to see it run live:
Enter this customer order, release it to production, consume the materials, put it through quality control, ship it, invoice it, and show me the cost of that job on screen.
Three things are worth noting during the run: how many screens the operator moves between, which step falls outside standard, and which data is keyed manually.
8. Do reference checks
Ask for installations live in production in a similar sector at a similar scale. In the reference call ask about the project rather than the product: how did scope change, how did data migration go, what happened in the first three months after go-live, and which decision would you not take again?
9. What must be settled in the contract
- The scope list, and what is explicitly out of scope
- Acceptance criteria and who performs acceptance testing
- The change request process and unit prices
- Support SLA: response time and resolution time defined separately
- Data ownership and the format in which data is handed back
- Ownership of development and configuration documentation
- Who is responsible for carrying configurations through version upgrades
- The licence increase model and the price of adding users
Which products get evaluated?
Which option is more defensible under which conditions — without declaring a winner — is compared in alternatives in the ERP ecosystem. For the technical assessment on the manufacturing side see the ERP guide for manufacturers, and for assessing the implementation team, how to choose an ERP consultancy.
If you would like to review how this framework applies to your own project, you can talk to our ERP consulting team.
Frequently asked questions
Which ERP is cheapest?
The lowest entry cost is not necessarily cheapest over five years. A product whose API access is licensed separately, whose every report change needs outside help, or whose configurations do not survive upgrades can cost more in total. Compare on TCO.
Industry-specific ERP or general ERP plus configuration?
Industry-specific products can bring that sector's common processes ready-made and shorten the project. The risk is limited flexibility when a need outside that industry appears. A general ERP plus configuration can be more flexible, at the price of duration and cost. The decision depends on what share of your processes is genuinely industry-specific.
Cloud or our own servers?
Cloud reduces hardware and backup effort; on-premise gives data residency and infrastructure control. The deciding factor is usually tolerance to outage: if shop-floor terminals or tills depend on the ERP, offline capability or a local copy is required.
How long does ERP selection take?
Process analysis, requirement prioritisation and fit-gap work, together with candidate evaluation and scenario-based demos, add up to a project of several months. Shortening it usually means deferring scope until after signature.
Is source code access a selection requirement?
No. Source access adds flexibility on some platforms, while on others development happens through the vendor-supported extensibility and API layers. The critical question is not "is there source code" but whether the change you need can be made by a supported method and preserved through upgrades.