Most selections are decided by the demonstration. Most regrets are caused by the contract.

How to choose an ERP system: a practical checklist

How to run a selection that produces a decision you can defend - the questions to ask, the demonstrations to insist on, and the answers that should worry you.

ERP selection processes tend to follow a predictable shape: a long requirements list, three demonstrations, a scoring matrix nobody fully believes, and a decision that is largely made on impression. It is not that the process is dishonest - it is that it measures the wrong things, because a polished demonstration is a poor predictor of how a system behaves in your business on a bad Tuesday.

This guide describes a selection process built around evidence rather than presentation. It will take slightly longer and produce a materially better decision.

In this guide

  1. Before you contact anybody
  2. Write requirements as scenarios, not features
  3. What to insist on in a demonstration
  4. Questions worth asking, and the answers to worry about
  5. References, used properly
  6. The contract is where regrets are made

Before you contact anybody

  1. 1Write down the five to ten things that are costing you money now, with numbers attached. List problems rather than features.
  2. 2Separate your processes into those that are a real competitive difference and those that are habits. Be ruthless; the second list is longer than it feels.
  3. 3Decide who owns the project internally and how much of their time is actually available. If the answer is "some", stop here and fix that first.
  4. 4Agree what you will not change. Existing accounting package, particular customer requirements, specific compliance obligations. This narrows the field usefully.
  5. 5Set the three-year budget envelope before you see any pricing, so you evaluate against your own figure rather than anchoring on theirs.

Write requirements as scenarios, not features

A feature list invites a column of ticks and tells you almost nothing. Every supplier will tick nearly everything, because most features exist somewhere in most systems in some form.

Scenarios are harder to fake. Instead of "supports batch traceability", write: "a customer reports a fault on a unit despatched in March; show me how you identify every other unit that used the same component lot and every customer who received one". Instead of "supports back orders", write: "a customer orders ten of an item and we have four; show me what happens next, including what the customer sees".

Send five or six of these in advance and require them to be demonstrated on the day, in the system, without a slide.

What to insist on in a demonstration

  • Your scenarios, run in the product. Not a video, not a mock-up, not "that is on the roadmap".
  • Your data, or at least your part numbers and a real bill of materials. Demonstration data is always tidy in a way yours is not.
  • The unhappy paths: what happens when stock is short, when a posting fails, when someone books to the wrong job, when a delivery is refused.
  • The screens that ordinary staff will use forty times a day, not the executive dashboard.
  • The mobile or shop-floor interface, on a real device, in something approximating real conditions.
  • Somebody who will actually be on your implementation, not only a pre-sales specialist.

If a supplier will not run your scenarios live, that is your answer. It is the cheapest piece of diligence available to you.

Questions worth asking, and the answers to worry about

  • "Can we get a full export of all our data, including documents, at any time?" - hesitation here should end the conversation.
  • "Do you charge per integration or per connector?" - a yes materially changes your three-year cost.
  • "Can we query our own database read-only for reporting?" - a no means every future report is chargeable.
  • "What is the contractual annual uplift?" - vagueness now becomes a surprise in year two.
  • "Who does the data migration, and what exactly is our part?" Expect the answer to involve a lot of work by you.
  • "What happens when a posting to our accounts package fails?" - "it retries and reports" is right; "it does not fail" is not an answer.
  • "Can we talk to a customer who left you?" - the response to the question is informative even if they say no.
  • "Which parts of our requirement are you weakest on?" - a supplier who claims none is either not listening or not being straight.

References, used properly

Supplier-provided references are curated, which is fair enough, but you can still get value from them by asking the right questions. Skip "are you happy with it". Ask what went wrong during implementation, how long it actually took against the original plan, what they would do differently, and what they still work around.

Ask specifically about support: how long a response takes, whether they speak to somebody who knows their business, and whether escalation works. Support quality is the thing customers complain about most and evaluate least.

The contract is where regrets are made

Selection processes concentrate on capability and then treat the contract as an administrative formality. It is the opposite: capability differences between mid-market systems are usually modest, while contractual differences are enormous.

Check the exit terms, the data export commitment, the uplift mechanism, the notice period, what happens to your data if you leave, and whether support levels are contractual or aspirational. Have somebody read it who is not emotionally invested in the project succeeding.

In short

What to take away

  • Write scenarios, not feature lists - they are much harder to answer vaguely.

  • Insist on live demonstration of your scenarios, including the unhappy paths.

  • Ask about data export, connector charges and database access before price.

  • Use references to ask what went wrong, not whether they are happy.

  • Read the contract properly; that is where the long-term cost lives.

Questions

Asked while people are working this out

  • Two to four months is typical and reasonable for a mid-sized business. Faster usually means the requirements work was skipped; much slower usually means nobody owns the decision.

  • It can help if they are independent and not taking commission from suppliers. Ask directly how they are paid. A consultant with supplier relationships is not necessarily bad, but you should know before you weigh their advice.

  • Three properly is far better than six superficially. More than four and the scenarios stop being run seriously because the time required becomes prohibitive.

  • Not always. Industry specialism matters most where compliance or trading requirements are unusual, such as food traceability or automotive EDI. Elsewhere, a general system that configures well often ages better than a narrow one.

  • Then either your requirements include habits that could change, or you need something bespoke. Both are legitimate conclusions, and a supplier willing to tell you the second one is worth listening to.

Relevant to this

Where CubeERP fits

Linked because they are relevant to the guide, not because this is where the sales pitch goes.

Next

Read these too

After reading

Bring the questions this raised

If the guide has made you think of something specific about your own business, that is exactly the conversation worth having. No obligation and no scripted demonstration.

Start a conversationCall 01234 672 617