ERP selection for Swiss mid-market: how to run it without wasting a year

Most ERP selections in the Swiss mid-market take nine to fifteen months and produce a decision that could have been made in eight weeks. The extra time is not spent learning about the products. It is spent building internal agreement, badly, through the medium of a requirements spreadsheet.

For a company of 80 to 400 people, that lost year is not abstract. It is the attention of the three or four people who run operations, spent on scoring sheets instead of on the business, while the old system keeps ageing. There is a faster method, and it produces a more defensible decision.

Why the requirements-matrix approach fails

The standard method asks every department to list its requirements, weights them, scores each vendor, and picks the highest total. It fails for three structural reasons.

In the selections we have reviewed, every shortlisted product met the large majority of a typical mid-market requirement list, so the scores cluster and the ranking is decided by noise. Departments inflate importance weightings strategically once they realise the weights drive the outcome. And the requirements that actually differentiate, the twenty things that are genuinely hard in your business, are buried among three hundred that any product handles.

The matrix produces a number. It does not produce confidence.

The differentiating-requirements method

Replace the matrix with a much shorter, much harder question: what are the ten things about our operation that break standard ERP?

Ten, not three hundred. They are usually some combination of: multi-entity and multi-currency consolidation with Swiss and EU entities, variant configuration in manufacturing, project-based revenue recognition, Swiss payroll and social insurance integration, QR-bill and ISO 20022 payment handling, industry-specific traceability, and whatever your business does that competitors do not.

Then run those ten against each shortlisted product as scripted scenarios, with your own data, in a sandbox. Not a demo. A demo shows you the happy path the vendor rehearsed.

The Swiss requirements worth a scripted scenario

Some requirements apply to every Swiss company, and they are cheap to test and expensive to discover late. Each has a public standard behind it, so the test can be specific.

Two of these move every year. SIX has required structured addresses in the QR-bill since November 2025, and it publishes a new release of the Swiss Payment Standards every February, which banks support from November. Ask each vendor who maintains the Swiss localisation, and how quickly last year's changes reached customers. For payroll, Swissdec keeps a public list of certified payroll software; a product, or the partner add-on that supplies its Swiss payroll, should be on it.

What is the difference between SAP, Microsoft, Odoo and Abacus for a Swiss company?

SAP S/4HANA suits complex, multi-entity manufacturing with an appetite for standard processes. Microsoft Dynamics 365 suits companies already on Microsoft with mid-complexity operations and a phased rollout. Odoo trades depth for cost and speed. Abacus is strongest on Swiss finance, payroll and compliance out of the box. Your ten differentiating requirements decide between them, not a general ranking.

Honestly summarised, and generalising more than any individual case deserves:

Abacus deserves a specific note for Swiss buyers: Swiss payroll, social insurance and tax handling that works natively removes an entire integration workstream that the international platforms treat as a localisation project.

If you are replacing an existing system, the vendor's own lifecycle dates belong in the decision. SAP has stated that mainstream maintenance for SAP Business Suite 7 ends at the end of 2027, with optional extended maintenance to 2030 at a premium, and Microsoft's extended support for Dynamics NAV 2018 ends in January 2028. A deadline is a reason to start the selection, not a reason to shorten it.

How long should ERP selection take?

Eight weeks for a company of 50 to 500 people. Two weeks to write the ten differentiating requirements, one to longlist, three for scripted scenarios with your own data, one for reference calls, and one to decide and write down why. Longer selections rarely learn more about the products. They spend the extra months building agreement.

Weeks one and two create the agreement everything else depends on, so the people who will live with the system write the ten, not a project assistant. In week three, public information is enough to cut the field to four. During weeks four to six, your people run the scenarios and score only the ten. In week seven, ask each vendor for a reference of similar shape and for one that went badly; the second call teaches more.

Week eight produces the artefact that matters most: a written decision, including what would have changed the answer. In month fourteen, when somebody asks why you did not pick the other one, the written rationale is what prevents the decision being reopened.

What does an ERP selection cost?

Mostly internal time. Expect five to eight people from finance, operations, sales and IT to spend part of eight weeks on it, with the heaviest load during the scripted scenarios at about two days per vendor. In our experience vendors run scenarios at their own cost for a credible prospect. Outside help, if any, should be a small fraction of the implementation budget.

The larger cost is the one a bad selection causes later, in a programme that fights the product for years. That is why the method spends its effort on the ten hard requirements rather than on the three hundred easy ones. What outside support typically costs in Switzerland is set out in what a Swiss company should pay for consulting, and how to put the expected benefit next to it is in how to measure ROI on a digital transformation.

Should we customise or stay close to standard?

Stay close to standard unless the process is genuinely a source of competitive advantage. The test is commercial, not technical: if a customer would not notice or pay for the difference, the customisation is a maintenance liability you will carry through every upgrade for a decade.

Upgrade exposure has grown with cloud delivery. Business Central online, for example, receives two major updates a year, in April and October, and every extension has to keep working through each of them. The exceptions are real, though. If your variant configuration logic is why customers choose you, standardising it away to simplify an upgrade path is a strategy error dressed up as an IT decision. For an industrial company, that logic and the machine data around it are also what Industrie 4.0 work builds on.

A worked example: a 120-person pump manufacturer

Take a hypothetical 120-person maker of industrial pumps with a sales subsidiary in Germany, replacing a system whose support ends in 2028. The details are illustrative.

Its ten differentiators fit on one page: variant configuration for pumps built to order; serial-number traceability from casting to customer; consolidation of the Swiss parent and the German subsidiary in two currencies; service contracts billed annually; spare parts priced from the installed base; Swiss payroll including withholding tax for cross-border commuters; QR-bills and ISO 20022 payment files; German and French documents; project costing for large custom orders; and a month-end closed in five working days.

Three of the four longlisted products handle seven of the ten without difficulty, so those seven decide nothing. The selection turns on variant configuration, withholding tax and serial traceability. Two days of scenarios per vendor show one product configuring the pump variants in the standard, one needing development, and one routing payroll through a certified Swiss add-on. The decision record names those three points and states what would have reversed the outcome.

That is the whole selection. Everything else was noise the matrix would have counted.

What changes between 50 and 400 people

The method stays the same; the shortlist and the team change. A 50-person company with one legal entity often compares three products built for smaller businesses, and the selection team is the managing director, the finance lead and whoever runs operations. Swiss payroll and finance usually decide it, which favours the Swiss-first products.

At 400 people, with an EU subsidiary and a production site, the ten requirements shift towards consolidation, intercompany flows and variant configuration, and the international platforms come into play. The team grows to six or eight people, and the risk shifts from picking the wrong product to picking the wrong implementation partner, because at that size partner quality varies more than the products do.

The cost line nobody budgets

Data migration. It is consistently the most underestimated phase, and the reason is structural: you cannot scope it accurately until you have looked at the source data, and nobody looks at the source data during selection.

Profile your master data during week four, not during month nine. Count the duplicate customers, the products with no unit of measure, the open items nobody can explain. That number changes your timeline more than the platform choice does, as set out in ERP data migration and in the pattern we documented in why ERP programmes stall.

Do we need a consultant to run an ERP selection?

Not necessarily. A company of 50 to 150 people can run this method itself if one person owns it and has the time. Outside help earns its fee when nobody internal can be spared, when the decision is politically loaded, or when independence from vendors and implementation partners matters. Whoever helps should not earn commission from the product you choose.

Ask any adviser how they are paid, which products they have implemented, and whether they would tell you to wait. A company that is not sure it needs an ERP at all should read when a small company actually needs an ERP first. How to judge advisers more generally is covered in how to choose a management consulting firm in Zurich.

After selection

Selection is the easy half. The programme that follows is where the value is won or lost, and the binding constraint is decision latency rather than technology. Our ERP consulting practice instruments that from week one, and our partnership models describe how fees can be linked to agreed outcomes rather than hours.

Whatever you select has to satisfy Swiss retention and audit obligations; confirm that in the scripted scenarios rather than in the vendor's compliance brochure.

Sources

• SIX — QR-bill, structured addresses since November 2025
• SIX — ISO 20022 and the Swiss Payment Standards, message types and annual release cycle
• Swissdec — Lohnstandard-CH (ELM), electronic payroll reporting
• Swissdec — Certified ERP and payroll software, register of certified products
• Federal Tax Administration (ESTV) — MWST-Kontrolle, the VAT audit trail
• Fedlex — Swiss Code of Obligations, SR 220, Art. 958f: ten-year retention
• SAP — SAP S/4HANA maintenance until 2040, and the choice for SAP Business Suite 7, maintenance dates
• Microsoft — Dynamics NAV 2018 lifecycle, support end dates
• Microsoft — Business Central update cycles, two major updates a year

Related reading

• Why ERP programmes stall in Swiss mid-market companies
• ERP data migration: the part that overruns, and why
• How to measure ROI on a digital transformation before you fund it
• How to choose a management consulting firm in Zurich
• ERP consulting