The ERP market creates an uncomfortable problem for management teams: almost every serious vendor can demonstrate an impressive product. Dashboards look good, workflows appear smooth and most requirement lists receive a reassuring ‘yes’.
That does not mean every product is equally suitable. ERP selection fails when the organisation compares software before it has made its own requirements and decision criteria explicit.
The objective is not to identify the ‘best ERP’ in the market. It is to identify the solution, implementation partner and commercial model that best fit the organisation’s processes, scale, controls, integration needs and capacity for change.
A seven-step ERP selection framework
Start with the business case
Why is the organisation considering ERP now? Growth, lack of visibility, manual work, weak controls, fragmented systems, high inventory, project overruns and delayed reporting all lead to different priorities. Before speaking to vendors, management should define the outcomes it expects from the programme and the baseline against which value will be measured. Otherwise the selection becomes a feature comparison rather than an investment decision.
Map how the business actually works
Document the current end-to-end processes and the exceptions that matter. Identify where the business deliberately operates differently from standard industry practice and where variation simply exists because processes have evolved informally. This distinction is critical. Genuine differentiators may need to be preserved. Historical workarounds should not automatically become customisation requirements.
Convert processes into prioritised requirements
Requirements should describe what the organisation needs to accomplish, not copy the language of a preferred product. Separate mandatory requirements from desirable ones and include reporting, security, integration, audit trail, data migration, scalability and usability—not only transaction screens. For large requirement sets, group needs by business process and assign importance. A requirement that affects statutory compliance or a core operational differentiator should not carry the same weight as a convenience feature.
Build the market longlist—then screen it
Create a broad list based on industry fit, company scale, deployment model, geography, ecosystem, client references and implementation capability. Use a small set of non-negotiable criteria to remove unsuitable options before issuing a detailed RFI or RFP. This saves both the organisation and vendors from spending time on products that cannot meet the basic operating requirement.
Make the RFI/RFP comparable
A strong RFI/RFP forces vendors to respond in a common structure. Ask not only whether a function exists, but whether it is standard, configurable, customised or dependent on a third-party product. Request implementation approach, team profiles, integration assumptions, product roadmap, client references, support model and commercial details. The output should make comparison easier, not create five different sales proposals that management has to interpret from scratch.
Use scenario-based demonstrations
Generic demos are designed to show software at its best. Management learns more by giving every shortlisted vendor the same business scenarios and asking them to demonstrate how the product handles them. A useful demo set normally includes a high-volume routine transaction, a complex transaction, an exception or amendment, a cross-functional hand-off, and a management reporting requirement. Ask the vendor to show the complete journey, including what happens when something changes after approval.
Score fit, cost and implementation risk together
The lowest licence cost is not necessarily the lowest-cost decision. Total cost of ownership should include implementation, customisation, interfaces, data migration, training, infrastructure or cloud costs, support, upgrades and the internal effort required from the business team. A product that meets every requirement through heavy customisation may carry greater long-term risk than one that meets slightly fewer requirements through stable standard functionality.
What should be inside total cost of ownership?
- Licence or subscription fees and user-volume assumptions.
- Implementation and project-management charges.
- Customisation, reports and workflow development.
- Interfaces with existing applications and external systems.
- Data cleansing, migration and validation.
- Training, change management and internal project-team effort.
- Cloud, hosting, database or infrastructure cost where applicable.
- Annual support, AMC, upgrades and future expansion.
Evaluate the implementation partner as seriously as the product
ERP is a multi-year relationship. The quality of the implementation team, their understanding of the industry, ability to challenge weak requirements, availability of senior resources, project governance and response during difficult phases can determine whether a good product becomes a good implementation.
Reference conversations should therefore go beyond ‘Are you happy with the software?’ Ask about implementation delays, change requests, quality of consultants, escalation behaviour, post-go-live support and whether the client would choose the same partner again.
Red flags management should not ignore
- The vendor is defining your requirements during the sales process.
- The demonstration is polished but avoids your real scenarios and exceptions.
- Too many critical needs require customisation.
- Commercial assumptions and future user/transaction charges are unclear.
- Data migration and integration responsibilities are vague.
- The proposed implementation team is not the team that attended the sales process.
- Project governance, acceptance criteria and change-control mechanisms are weak.
“The best ERP selection process is independent of the vendors until the organisation knows what it is trying to select for.”
Make the decision defensible
A disciplined evaluation does more than produce a winner. It gives management a documented rationale for the decision, creates clarity for contract negotiation, and gives the implementation programme a much stronger starting point.
When processes, requirements, scenarios, scoring and total cost are defined before the final sales pitch, the organisation is far less likely to buy a product because it demonstrated well—and far more likely to select a system it can actually operate and scale.