Choosing an ERP system is not mainly a software comparison. It is a decision about how finance, purchasing, inventory, operations, people and reporting will work together for years. The safest selection process begins with the organisation’s needs and makes every shortlisted vendor prove the fit against the same real scenarios.
The decision in one sentence: Choose the ERP that best supports your essential processes, controls and future direction at an acceptable lifetime cost and risk—not the product with the longest feature list.
Agree on what must change
Start with outcomes. “Replace the old ERP” is a project description, not a business case. A useful objective sounds more like reducing manual reconciliation, shortening the month-end close, improving stock visibility or supporting a new operating model.
Map the most important current processes with the people who perform them. Note repeated data entry, workarounds, delays, weak controls and reports that arrive too late to support a decision. This gives the selection team something concrete to improve.
Build a team that can make the decision
ERP affects more than IT. The team needs people who understand finance, operations, data, security and the daily work, together with an executive sponsor who can resolve priorities.
Keep the decision structure clear. A large group can contribute requirements, but a named group must own the scoring, recommendation and final approval. Also identify who will own the product after implementation; selection should not end at contract signature.
- Executive sponsor with authority to resolve priorities
- Business process owners
- Finance and procurement
- Technology, integration and data specialists
- Security, privacy and compliance
- Representative end users
- A named owner for the future ERP service
Separate essential requirements from preferences
A requirement should describe the business need and how it will be tested. Avoid writing hundreds of vague items such as “must be user-friendly.” State the scenario, data, role, control and expected result.
Make vendors demonstrate your work
A polished standard demonstration shows what the seller wants to show. Give each serious vendor the same short script based on your real processes and realistic sample data.
Ask them to show exceptions, not only the happy path: a rejected invoice, a changed order, a failed interface, a permission change, a corrected transaction and the audit trail. Record what works as standard configuration, what needs an extension and what depends on another product or partner.
Give every shortlisted vendor the same processes, roles, data and expected results.
Ask the vendor to follow your sequence instead of a prepared sales tour.
Record standard fit, configuration, custom work, gaps and unanswered questions.
Confirm identity, permissions, APIs, logging, recovery and data handling.
Speak with customers of a similar size, industry and implementation model.
Count the full lifetime cost
Subscription or licence pricing is only one line. Include implementation, internal staff time, data cleansing and migration, integrations, extensions, testing, training, change support, environments, security, upgrades and ongoing administration.
The lowest initial price may not be the lowest total cost. A heavily customised product can be expensive to change; a simple subscription can rise sharply when more users, storage, countries or premium capabilities are added. Write down the assumptions behind every estimate so proposals can be compared fairly.
Check risk before the contract
Security promises should become specific evidence and contract terms. Use the organisation’s security framework to assess identity, least privilege, logging, vulnerability handling, data protection, recovery and supplier dependencies. CISA’s Secure by Design guidance is a useful reference when asking what security the supplier provides by default.
Who cleans, maps, approves and reconciles the data before go-live?
What happens when another system or API is unavailable?
Can the need be met through configuration, or will custom code create upgrade work?
Which named people will deliver the project, and who is accountable when delivery changes?
How will data be exported in a usable format if the organisation leaves?
Make the decision traceable
Use a weighted scorecard, but do not let a spreadsheet hide weak evidence. Record the requirement, its weight, the demonstrated result, the remaining risk and the source of the score. A final recommendation should explain why the preferred option supports the business outcomes better than the alternatives.
Before signing, connect important requirements to implementation scope, acceptance criteria, service commitments, data terms and pricing assumptions. If a capability mattered during selection, it should not disappear into a sales presentation.
Key takeaways
- Define outcomes before comparing products
- Use real processes and exception cases in demonstrations
- Score evidence rather than promises
- Compare lifetime cost, not only licence price
- Treat security, data migration, integration and exit as selection questions
- Keep the decision and its assumptions visible after implementation begins