How to run an ERP selection process without getting it wrong

Why ERP selections fail before they start

Most ERP selection processes are already compromised before the first vendor demonstration is booked. The organisation has not defined what problem it is actually trying to solve. The internal team has been handed a shortlist assembled from sales enquiries rather than requirements. The decision-making authority is unclear. And the person leading the process has never done it before.

The result is a selection process that is driven by vendor momentum rather than organisational need - ending in a commitment to a platform that is either too large and expensive for the business or too limited for the growth the business expects.

The cost of a wrong ERP decision is significant. Not just the implementation cost - which for a mid-market business typically runs from £200k to £2m depending on complexity - but the 18-24 months of organisational disruption, the opportunity cost of the leadership attention consumed, and the operational risk of a go-live that does not go well.

A well-run selection process takes longer at the front end and saves significant money and pain at every subsequent stage.

What to do before you speak to a single vendor

The work that happens before vendor engagement determines the quality of the selection. Skipping it is the single biggest mistake organisations make.

Define the problem, not the solution

The instinct when an ERP decision is approaching is to start looking at systems. The right starting point is defining what problem the current system is causing and what a future system needs to enable - in operational terms, not technology terms.

Common triggering problems: the current system cannot produce accurate margin by product line; reconciliation between production and finance takes three days each month; stock visibility across sites is manual and unreliable; the system cannot scale to the volume the business expects in three years. These are operational problems. The ERP is one possible solution to some of them - but not always the right one, and rarely sufficient on its own.

Establish current-state evidence

Before specifying requirements for a new system, you need an honest picture of what the current system is actually doing well, what it is failing at, and - critically - whether those failures are system failures or process failures. A system that is being blamed for producing bad data is often a symptom of a process that was never designed to produce good data. A new system will produce bad data too, just more expensively.

This diagnostic step is often skipped because it feels like delay. It is the most commercially valuable part of the entire selection process.

Define decision authority

Before any vendor speaks to anyone in your organisation, establish: who has the authority to make the final selection decision, who has the authority to commit the budget, and what the board sign-off process looks like. ERP selections that drift often do so because the decision authority was never clearly established and vendors - who are expert at navigating organisational politics - exploit the ambiguity.

Set a budget range and stick to it

Vendors will sell you the system your budget can afford. If they do not know your budget, they will size for the largest commitment they can plausibly justify. Setting a clear budget range - licence, implementation, data migration, training, first year support - before vendor engagement keeps the process anchored to commercial reality.

How to write requirements that vendors cannot game

Generic requirements produce generic responses. A requirements document that lists "stock management", "purchase order processing", and "financial reporting" will get a confident "yes" from every vendor on the market - because every ERP system handles those things at some level.

Requirements that are useful in a selection process are specific, operational, and testable:

• Specific: "The system must produce a margin report by SKU by week, drawing from production cost data captured at job completion, without manual intervention." Not: "The system must support management reporting."
• Operational: Written in terms of what your team needs to do, not what the system should technically support. "Our warehouse team needs to confirm goods receipt on a mobile device on the shop floor" is a better requirement than "mobile device support".
• Testable: Every requirement should be capable of being demonstrated in a vendor session. If you cannot define what a passing demonstration looks like, the requirement is not specific enough.

Separate your requirements into three tiers: must-have (non-negotiable), should-have (important but not disqualifying), and nice-to-have (genuinely optional). Vendors should know which is which - a system that meets all your must-haves and half your should-haves is a better choice than one that scores impressively on nice-to-haves but struggles on your core operational requirements.

Building a longlist and shortlist

The longlist should be assembled on the basis of your requirements and your operational context - sector, scale, complexity, integration landscape - not on the basis of which vendors found you first or which analyst report your IT director read last.

Common ERP platforms for mid-market businesses

The landscape varies significantly by sector. For manufacturing:

• SAP Business One - strong for product-based businesses up to around £100m turnover; broad functionality but implementation quality varies significantly by partner
• Epicor Kinetic - manufacturing-specific with strong shop-floor data capture; better for discrete and make-to-order environments
• Infor CloudSuite Industrial - suited to more complex manufacturing environments; higher implementation cost and longer timelines
• Sage 200 - appropriate for simpler manufacturing businesses; lower cost but more limited in production management depth
• Microsoft Dynamics 365 Business Central - broad functionality with a large partner ecosystem; fit varies significantly by implementation partner

For distribution and professional services, the right longlist looks different. The principle is the same: fit against your specific operational requirements, not brand recognition.

Shortlisting criteria

Reduce the longlist to three or four vendors based on: coverage of must-have requirements, relevant sector experience with implementations at your scale, implementation partner quality in your geography, and total cost of ownership within your budget. You are not looking for the best ERP. You are looking for the best ERP for your specific situation.

Running demos that reveal the truth

Standard vendor demonstrations are scripted to showcase strengths and avoid weaknesses. A selection process that relies on standard demos will produce a selection decision based on the vendor's best case rather than the operational reality.

Script your own scenarios

Give vendors a set of specific scenarios drawn directly from your operational requirements and ask them to demonstrate each one live - not in a pre-prepared sandbox, but in a working system. "Show me how a production order is created when a customer order is received, how the material requirement is calculated, and how the resulting purchase orders are generated and approved" is a testable scenario. "Show me your production planning module" is not.

Bring operational staff to demos

The people who will use the system every day will spot problems in a demonstration that the project team misses. A warehouse manager watching a goods receipt demonstration will notice immediately if the workflow does not match how the operation actually works. Their instinctive reactions to a demonstration are more reliable than a scoring matrix completed by a project manager.

Ask about failure modes

Ask vendors explicitly: what happens when X goes wrong? What does the system do when a goods receipt does not match the purchase order? What happens when a production job cannot be completed as scheduled? Vendors are trained to talk about what the system does well. The failure mode conversation reveals whether the system has been designed for operational reality or for sales demonstrations.

Using reference sites properly

Every vendor will offer reference sites. Every reference site they offer will be a positive one. The reference site conversation is still valuable - but only if you ask the right questions.

• Ask for references at businesses that are similar to yours in size, sector, and operational complexity - not the vendor's largest or most prestigious client
• Ask specifically about what went wrong during implementation and how it was resolved
• Ask about the quality of the implementation partner, not just the software
• Ask what they would do differently if they were starting again
• Ask whether the system is doing what they expected it to do 12 months after go-live

If a vendor cannot provide a reference at a business similar to yours, that is relevant information about their experience at your scale.

Total cost of ownership - what vendors don't tell you

The licence or subscription cost is the smallest part of an ERP investment. The items that are most often underestimated:

• Implementation cost - typically 1.5x to 3x the annual licence cost for a mid-market implementation; varies significantly by complexity and partner quality
• Data migration - often treated as a line item rather than a project; data quality problems in the existing system become data migration problems in the new one, and fixing them takes time and money
• Integration - connecting the ERP to other systems (CRM, WMS, e-commerce, payroll) is almost always more complex than estimated; ask vendors specifically how their system integrates with your existing landscape
• Change management and training - the most consistently underbudgeted element; a system that the team cannot or will not use is not an asset
• Internal resource cost - the management and staff time consumed by an ERP implementation is rarely captured in project budgets; for a mid-market business it can represent the equivalent of 2-4 FTE for 12-18 months
• Post go-live support - the first 6-12 months after go-live typically require more support than the steady-state annual support cost; build this into the business case

Making the decision and presenting it at board level

The selection decision should be presented to the board as a comparison of options rather than a single recommendation. A board that receives only one option to approve cannot meaningfully challenge the recommendation - which means the challenge happens after commitment rather than before it.

A board-ready ERP selection summary includes:

• The problem the selection is designed to solve, in operational and commercial terms
• The shortlisted options with their total cost of ownership over three years
• Coverage of must-have requirements for each option
• Key risks of each option - implementation risk, integration risk, vendor risk, internal capacity risk
• The recommended option with the specific reasons it was selected over the alternatives
• The implementation plan at headline level, including go-live date and key dependencies

The board should be able to ask any reasonable challenge question - "why not option B?", "what happens if the implementation runs over?", "what is the contingency if this vendor is acquired?" - and receive a prepared answer. If the project team cannot answer those questions, the selection process is not complete.

When to use independent support

Independent ERP selection support is most valuable when:

• The organisation has not run an ERP selection before and does not have the institutional knowledge to do it well
• The project team is under time pressure that risks compressing the front-end work that protects the decision
• Vendor relationships already exist that could compromise the independence of the evaluation
• The board requires independent assurance before committing to a significant investment
• A previous ERP implementation did not go well and the organisation needs external credibility for the new process

The key test: does the independent adviser have any commercial relationship with the vendors being evaluated? If they earn implementation revenue from the platforms they are recommending, they have a structural conflict of interest. Independent selection support should be fee-only, with no vendor relationships that could influence the outcome.