Choose ERP by documenting the processes that actually differentiate your business, then scoring candidates on fit, integration cost and five-year total cost rather than on feature counts. Most selection failures are caused by requirements that were never captured and by business cases that excluded implementation, integration and exit costs.
Start with processes, not with vendors
The single most useful preparatory exercise is to list your core processes and classify each as differentiating or commodity. A differentiating process is one where the way you do it creates margin that a competitor would struggle to copy. A commodity process is one where every competitor does it the same way and the only question is cost.
This classification determines the correct answer for each process. Commodity processes should be adopted as standard from a package, because the vendor will maintain them against regulatory and best-practice change far more cheaply than you can. Differentiating processes should not be forced into configuration screens, because that puts your advantage inside someone else's product.
Most organisations discover that their ERP requirement is genuinely mixed, which is why hybrid outcomes, a package for the commodity core with custom services around the differentiating edges, are so common.
Requirements and fit-gap analysis
Convert the process inventory into prioritised requirements with a clear must-have, should-have and nice-to-have grading. Must-haves should be few and genuinely non-negotiable, because every must-have becomes a reason to reject the best overall candidate.
Then run structured demonstrations against scripted scenarios drawn from your own data, not vendor demo scripts. Watch for the demonstration that avoids a requirement rather than showing it, and ask directly how the requirement is satisfied and what configuration or development it needs.
Document the fit-gap output: for each requirement, standard fit, configuration required, extension required, or not supported. Extension counts are the best predictor of implementation cost and of future upgrade pain.
- Grade requirements as must-have, should-have and nice-to-have.
- Script demonstrations from your own processes and sample data.
- Record fit, configuration, extension or not supported for every requirement.
- Treat a high extension count as a cost and upgrade-risk warning.
The total cost model
Purchase price is the smallest part of ERP cost. The five-year model should include licence or subscription, implementation services, integration development, data migration and cleansing, testing, training, change management, ongoing support, upgrade projects and the cost of exit.
Two lines deserve particular attention. Change management is frequently omitted and is the most common cause of adoption failure. Exit cost is almost always omitted and includes data extraction, integration replacement and retraining at the end of the contract.
Subscription pricing also needs to be modelled against growth. Per-user tiers, module add-ons and consumption metering mean the annual figure is a starting point rather than a fixed cost.
| Cost line | Usually included | Frequently omitted |
|---|---|---|
| Licence or subscription | Yes | Growth in users and modules |
| Implementation services | Yes | Change orders after scope drift |
| Integration development | Partly | Ongoing maintenance of integrations |
| Data migration | Partly | Cleansing and reconciliation effort |
| Testing and validation | Partly | Regulatory validation if applicable |
| Training and change management | Rarely | Almost always omitted |
| Support and upgrades | Yes | Internal effort per upgrade |
| Exit and data extraction | No | Always omitted |
Implementation and governance
Selection and implementation are the same project viewed from two ends. The strongest predictor of success is not the product but the client-side capability: a named business owner with decision authority, a small steering group that can actually decide, and a product owner who can arbitrate between conflicting departmental requirements.
Plan a phased rollout by process or by legal entity rather than a single big-bang cutover. Phasing reduces risk, surfaces data quality problems early and produces visible progress that sustains executive sponsorship.
Define acceptance criteria in business terms, such as a closed accounting period or a shipped order through the new system, rather than in technical terms. Acceptance tied to business outcomes prevents a technically complete implementation that nobody can use.
- Name a business owner with real decision authority.
- Keep the steering group small enough to actually decide.
- Roll out by process or entity rather than a single cutover.
- Define acceptance in business outcomes, not technical milestones.
Frequently asked questions
Should we buy a package or build custom ERP?
Buy for commodity processes where the vendor's investment in regulatory and best-practice maintenance exceeds what you would spend, and build or extend for processes that genuinely differentiate your business. Most organisations need a hybrid.
How long does an ERP selection take?
A disciplined selection, from process inventory through contract, typically takes three to six months. Compressing it below that usually means requirements were not captured, which shifts the cost into implementation change orders.
What is the biggest cause of ERP implementation failure?
Weak client-side ownership combined with under-investment in change management. Technical problems are usually recoverable; an organisation that has not been prepared to adopt the system is not.
References
Engineer your next strategic platform
Estimate your project investment and delivery timeline instantly, or schedule an architectural discovery call with our engineering leadership.