ERP Vendor Selection

Why ERP vendor selection goes wrong

ERP selection rarely fails because a business picked an objectively bad product. It fails because the evaluation measured the wrong things. The common patterns are familiar:

• Demo-led decisions. Vendors show their strongest features in a scripted tour. Without your own scenarios, every system looks capable.
• No agreed criteria. Finance, operations and sales each judge vendors by different standards, so the final choice comes down to who argued hardest.
• License price mistaken for cost. The subscription is often the smallest part of what an ERP costs to own. Implementation effort, customization, integrations and support decide the real number.
• Partner ignored. Two companies on the same platform can have very different outcomes depending on who implements it.
• Vague contracts. A statement of work full of assumptions turns into change requests the moment the project starts.

A good selection process prevents each of these by setting criteria early, testing vendors against your real processes, and putting what you learn into the contract. If you have not yet documented what you need, start with ERP requirements gathering, because a selection is only as good as the requirements behind it.

How I build the longlist and shortlist

The longlist starts from your business, not from a market report. I look at your industry, transaction volumes, number of entities and currencies, tax and compliance needs, integration landscape, hosting preferences and the skills of your internal team. Platforms that clearly cannot meet a must-have requirement are dropped early, with the reason written down.

For most growing businesses, the longlist includes a mix of suites such as Zoho, Odoo, ERPNext and Microsoft Dynamics 365, plus SAP Business One, NetSuite or industry-specific products where they make sense. Each has a sensible home, and the right one depends on how you work.

To move from longlist to shortlist I use a short screening questionnaire built from your BRD, focused on knock-out requirements and fit for your industry. Vendors and implementation partners answer in writing. I review the responses, follow up on vague answers and recommend a shortlist of usually a few options, each with a short note on its strengths and risks. That way your team only invests demo time in options that have a real chance of fitting, and anyone who asks later why a platform was excluded can see the reason.

Scripted demos and reference checks

A scripted demo puts the vendor to work on your processes. I write a set of end-to-end scenarios drawn from your requirements, for example a quote that becomes a sales order with a partial delivery and a credit note, or a purchase that is received in two batches with landed costs. Vendors receive the scripts and a sample of your data in advance, and they must walk through each scenario live.

During each session I chair the agenda and keep time, so every vendor covers the same ground. Your process owners score each scenario on a simple scale and note whether it was handled with standard features, configuration or custom development. I capture follow-up questions and make sure they are answered in writing.

Reference checks follow the demos. I ask each shortlisted vendor and partner for customers with a similar size and industry, then run structured calls covering:

• How closely the delivered project matched the original scope and plan.
• How change requests and disputes were handled.
• Quality of support after go-live.
• What they would insist on if they started again.

Reference findings often reveal more than the demo itself, especially about the implementation partner.

Weighted scoring and total cost of ownership drivers

Before the first demo, your leadership team agrees the weights: how much functional fit matters compared with usability, technical fit, partner strength, vendor viability and cost. Fixing the weights in advance keeps the scoring honest and stops the criteria shifting to favor a preferred option.

The scoring sheet then pulls together demo scores, written responses, reference findings and technical review. Each score links back to evidence, so the final ranking can be explained line by line.

Cost is assessed as total cost of ownership over several years, not as a first-year quote. I compare the options on the drivers that actually move the number:

For more on what moves ERP budgets, see my guide to ERP implementation cost.

Negotiating scope and why independence matters

The selection is not finished when you choose a vendor. It is finished when the contract reflects what you evaluated. I review the proposal and statement of work line by line and check that the agreed scope covers the scenarios from the demos, that assumptions are realistic, and that exclusions are visible. Then I help you negotiate:

• Clear deliverables and acceptance criteria for each phase.
• Named roles and the level of seniority on the partner team.
• A change control process with rates and approval steps.
• Data migration, integration and training scope stated explicitly.
• Post go-live support terms and handover obligations.

If you plan to run a formal tender, my ERP RFP consulting covers the RFP document and proposal evaluation in more depth.

Independence is the reason this works. I do not resell any ERP, I hold no partnership that rewards me for a recommendation, and I am not paid by vendors. My only client in the selection is you. That lets me push vendors on gaps, challenge optimistic estimates and recommend the option that fits, even if it is the less fashionable choice. Once the decision is made, I can stay on as your ERP implementation consultant to make sure what was sold is what gets delivered.