How do you choose the right ERP?

The short answer

Choose the system that runs your core processes in its standard, that your own people can change after go-live, and that you can leave with your data intact — from a partner who will still be around in five years. Judge it on the total cost over five years, not on the price per user. And judge it by what happens after the honeymoon, because that is where you will spend nine of the ten years.

Everything else — feature lists, brand names, the polish of the demo — is noise, and it is loud noise, because it is what vendors are set up to compete on. The two things ERP users complain about most, years after the decision, are running costs and interfaces: the largest German-language survey of ERP installations, covering more than 1,500 systems, finds exactly those two at the top of the list. Neither shows up in a demo. Both are decided at selection.

This guide is the process we would want a friend to follow: start from your processes, judge on seven criteria, run a selection in eight steps and about three months, run demos that tell the truth, know the red flags and the classic mistakes, check the Swiss specifics — and finish with a one-page checklist you can put in front of any vendor.

Start with your processes, not with vendors

The most common way to start an ERP selection is to google “best ERP for SMEs,” book three demos, and let the vendors explain what you need. It is also the most reliable way to buy the wrong system, because every demo is a story about the vendor’s strengths, and after three of them you will have three sets of criteria — none of them yours.

Start on your side of the table instead. Take the flows that actually run your company — for most SMEs there are about ten: quote to order, order to delivery, delivery to invoice, invoice to payment, purchasing, stock, projects or production, month-end close, payroll, and reporting — and for each one write down three things. How it works today, in two paragraphs. Where it hurts, concretely: the double entry, the spreadsheet, the question that takes a week. And what must, should, and would be nice to work in the new system.

That document is your requirements specification, and it should be twenty pages, not two hundred. Long requirement catalogues have a way of turning into feature checklists that every vendor ticks and nobody reads. Short ones get answered honestly, and they let you script the demos later. Write it with the people who do the work, not only with the people who manage it: the person who enters orders knows where the system needs to be fast in a way the CFO does not.

Two more things belong in it. The list of tools you will keep — the web shop, the CRM, the payroll provider, the bank — because every one of them is an interface to be built. And a list of what you will deliberately not customise: the special cases you have decided to give up in exchange for standard software. That list is the single most effective cost-control device in the whole project, and almost nobody writes it down.

If you are still unsure whether you need an ERP at all, or whether it is too early, start with When do you need an ERP? This article assumes you have decided that you do.

The seven criteria that actually matter

Every system on your longlist has more features than you will ever use. That is why feature count is the worst criterion there is: it cannot separate the candidates, and it distracts from the things that can. These seven do.

1. Process fit — in the standard

Does the system run your core flows out of the box, the way you work, with at most configuration? Not “can it be made to” — anything can be made to. The question is how much of your business lives in the standard and how much would have to be built. A system built for your kind of company — trading, services, manufacturing, projects — will get you further in its standard than a generalist that needs to be taught what a bill of materials is.

2. Adaptability after go-live

Your business will change more in the next ten years than it did in the last ten. The decisive question is how the system changes with it: can your own people add a field, a step, a view, a report — or does every change go back to the partner as a change request at a day rate? This one criterion decides most of the running cost, and it is the one vendors are least eager to demonstrate. Make them.

3. Total cost over five years

Licences, implementation, interfaces, training, your own people’s hours, support, upgrades, and the change requests of criterion two — added up over five years, per candidate. It is the only cost figure that can be compared between vendors, because the per-user price is the one line they can all make look similar. We took the whole bill apart in How much does an ERP cost?

4. Integration

The second-biggest complaint of ERP users, years after they chose. Which of the tools you keep does the system connect to with a standard, maintained connector? Is there an open, documented API for the rest — and who pays when the other side updates? Fewer, standard integrations beat many bespoke ones, and a system that replaces three of your tools outright is worth more than one that connects to all of them.

5. Usability for the people who use it daily

An ERP is used eight hours a day by people who did not choose it. If it is slow, cluttered, or built for the accountant instead of the person taking the order, they will route around it — and the shadow spreadsheets you are trying to retire will be back within a year. Let those people drive in the demo, and count the clicks for the things they do a hundred times a week.

6. Data ownership and exit

Whose data is it, where does it live, and how do you get it out? A serious vendor answers in one sentence: it is yours, it is stored here, and here is the export — complete, in a documented format, at this price. The absence of that sentence is the migration prison in advance. In Switzerland, add: is it stored in Switzerland or the EU, and what does the contract say about the new data protection act?

7. The partner

For most SMEs the implementation partner matters more than the software brand. They will configure the system, migrate your data, train your people, and take your calls for years. Ask who exactly will be on your project, what their day rate is, how many customers of your size and industry they have — and whether you would be their largest customer or their smallest. Both are risks.

The selection process, step by step

Eight steps, two to four months if somebody owns them. The single most important decision in the whole process is made before it starts: naming one person with the time and the authority to run it. Selections without an owner do not fail; they just never end.

A pilot — a few weeks of real work in a test environment with the winning candidate — is worth adding between step seven and the contract if the system will run production or stock. It costs a few thousand francs and has saved companies from six-figure mistakes.

How to run a demo that tells the truth

A standard vendor demo is a rehearsed story with perfect data, told by the best presenter they have. It tells you that the presenter is good. To learn something about the system, you have to take the wheel.

Red flags

None of these is disqualifying on its own. Two of them together are.

The mistakes everyone makes

The selection mistakes are as recognisable as the ten signs that you need an ERP. Most companies make at least three of them, and they are all avoidable once named.

What a Swiss company should check

International systems are built for their home market first and localised later — sometimes thoroughly, sometimes with a plug-in from a partner who has since moved on. For a Swiss SME, these are the points where “localised” has to be verified, not believed.

How AI changes the criteria

Every vendor on your longlist now has an AI slide. The same user survey that puts running costs and interfaces at the top of the complaints finds AI on 57 percent of companies’ agendas — and in broad use at under two percent. So ask the only question that separates a slide from a product: show me what it does, in the standard, on my data, today.

The deeper change is to criterion two. In a classic ERP, adaptability is a service you buy from a partner, and the seven criteria are a way of estimating how much of it you will need. In an AI-native ERP, adaptability is a property of the product: the people who use the system reshape it in plain language — the field, the step, the view, the report — and the migration is done with the system rather than around it. When that is true, the partner criterion shrinks, the five-year cost changes shape, and the feature list matters even less than it did, because the system grows the feature you need when you need it.

It also inverts the demo. Instead of asking whether the system can be made to fit your business, you ask how fast it fits itself — and you watch it happen with the same request you would have written on a change-request form.

The one-page checklist

Twelve questions, one per finalist, answered in writing. A yes is a yes with evidence — a demo you drove, a clause in the contract, a reference who confirmed it.

Frequently asked questions