An ERP selection is not a package comparison.
It is an investigation into how a company actually earns its money, which processes are distinctive in that, and which IT landscape supports those processes best. We reverse the usual order: first understand the business, then classify the process landscape, only then invite vendors. And we never look at the ERP alone, because the ERP is usually just one of the six or seven building blocks on the table.
Standard
Any mainstream package supports this fine. Don't select on it.
Distinctive
Company-specific complexity most platforms handle with configuration. Watch effort and maintainability.
Differentiating
Unique to the business model, and exactly where standard software structurally falls short. This is where the decision falls.
Why most selections go wrong
The feature list beats the business process
A list of hundreds of features gets ticked off, the vast majority green at every vendor. The five processes the company earns its money with disappear into the noise. Exactly what a selection should decide is made invisible.
The demo is a sales show
The vendor shows its best screen, with its own data, in its own order. Everyone nods. Afterwards nobody knows whether the company's critical process is actually supported. A demo should be evidence, not a presentation.
The scope is drawn too narrow
An ERP gets chosen, and only then does it turn out that the configurator, the dealer portal, the data layer, the integrations and the shopfloor tooling also need replacing or connecting. Those decisions belong together, not loosely one after another.
The feature list
hundreds of checkmarks, all green, distinguishes nothing
The processes that decide
- Make-or-buy at order level
- Bidirectional delivery-date calculation
- Configuration with thousands of variants
- Dealer orders through the portal
- Post-calculation that matches the pre-calculation
a handful of lines, and exactly here the choice is made
The approach: four blocks, nine steps
Every step produces something the next step needs. No step is a report for the drawer.
Understand
How does this company earn its money?
We don't start with systems but with the business model. What does the company compete on: lead time, price, total solution, service level? What is the character of production: high mix low volume, or series? Where is the volume, where is the margin, where is the vulnerability? How do sales run: direct, through dealers, through a portal?
Without this answer you cannot weigh a single selection criterion properly.
The process landscape mapped, and classified
We capture all processes per domain: commerce, supply chain, production, warehouse and logistics, finance, master data and engineering, data and integration. Every process gets a label.
Two things we always name explicitly in this step. Which critical processes live only in the head of one employee? That is a system risk, not an efficiency question. And how good is the data quality? Because every AI or forecasting ambition stands or falls with it.
Structure
The full IT landscape, not just the ERP
We inventory everything that plays along: CPQ, CRM, BI, the integration layer, time registration, transport, invoice processing. And the Excel files where the real processes hide. Those workarounds aren't clutter, they are requirements that were never written down.
Then we divide the landscape into functional clusters, so you can ask each cluster a targeted question instead of one broad question to everyone.
Architecture scenarios instead of a package choice
Before a single vendor is called, we lay a few coherent landscape variants side by side. Per scenario we explain why certain domains belong together.
This makes the choice strategic instead of technical. The board gets a real decision to make, not a vendor list.
Broad standard ERP
with separate CRM and BI
ERP + separate MES
the shop floor as its own domain
Low-code platform
with only a separate finance app
Standard + low-code
commodity standard, differentiators built
From longlist to shortlist, per cluster
We select vendors on industry fit, capacity profile, relevance to your market and match with the differentiating requirements. An important detail: we also assess every vendor on its reach into adjacent clusters. An ERP vendor gets tested on CPQ and planning too, a low-code platform on everything except finance.
That shows where a landscape can consolidate and where it must split.
Test
A structured request that forces vendors to be honest
Every vendor receives the same structure: the company's situation, the scenarios being evaluated, a process list with company-specific context and priorities, a set of open questions, and the business case that must be shown in the demo.
We explicitly ask for the platform's limits: what is standard, what is configuration, what is custom, what runs through a partner, and where does the vendor itself recommend an external tool? An honest no scores better in our assessment than an unproven yes.
Demos that force the critical process
This is where our approach deviates most from the norm. The demo is not a product presentation but a case from the actual company. Per cluster we write out what must be shown, numbered and concrete, based on a scenario that genuinely goes wrong today. No room for a generic pitch.
Concretely: show one customer order from entry to delivery-date confirmation, including the make-or-buy decision and the lead-time calculation behind it. Or: show how a business analyst changes a rule after go-live, and do it live. For platforms where a working end product isn't realistic we adapt the form: a short live build session, or a tour of a real customer environment.
The effect is double. You get evidence instead of promises, and the key users see their own work in the demo. That does more for buy-in than any communication campaign.
Decide and push through
Scoring on ten dimensions, behaviour included
We score all candidates on the same ten dimensions: five functional and five non-functional. The functional dimensions are the company's own differentiating processes. The non-functional: implementation risk, total cost, presence and partner ecosystem in your market, future-proofness and openness, and the vendor signal.
That last one is among our strongest predictors. How a vendor behaves in the selection phase predicts how it behaves in the implementation. Responding slowly, offering no reference, giving no cost indication, showing up with ten consultants for an exploratory meeting, or answering fully supported to every question while there are objective gaps: those aren't details, those are signals. We record them and weigh them.
Next to the scoring we show per vendor how its stack lands on the architecture scenarios: what is native, what is an extra licence, what comes from a partner, and where a gap needs to be built. A board sees in one picture what it is actually buying.
| Dimensie | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| Functional: the differentiating processes | |||
| Make-or-buy at order level | |||
| Delivery-date calculation | |||
| Configuration and variants | |||
| Dealer portal flow | |||
| Planning and capacity | |||
| Non-functional | |||
| Implementation risk | |||
| Total cost | |||
| Ecosystem in your market | |||
| Future-proofness and openness | |||
| Vendor signal | |||
The decision is yours, and the model moves into the implementation
We advise sharply and with evidence, but the knot is cut by the organisation itself, with the board and the key users at the table.
The work doesn't stop there. The process landscape that steered the selection is exactly the material the implementation starts with: the AS-IS capture per key user, two improvement directions per process, and from that a scoped MVP with cost estimate and project plan. One model, reused, not built twice.
The principles
- You select on the distinctive process, not on the feature list.
- A demo is evidence, not a presentation.
- Look at the whole landscape. The ERP is one building block, not the whole.
- Processes that live in one person's head are a continuity risk and belong in the system.
- Honesty about gaps outweighs a fully ticked checklist.
- How a vendor sells predicts how it delivers.
- AI ambitions are as good as the data underneath. Basics first, promise second.
- The decision belongs to the client. Our job is putting the evidence on the table.
- The work from the selection is the starting stock for the implementation.
How it went in practice
We executed this approach in full at a Dutch manufacturer in the agricultural sector: high mix low volume, steel production, configurable products, two production sites, a dealer network with over five hundred active users and a large import volume. Starting point: an ageing SAP ECC landscape.
- A fully classified process landscape across seven domains, with the decisive differentiating process explicitly on the table as a selection criterion: a dynamic make-or-buy decision at order level with bidirectional delivery-date calculation. That process became the sharpest distinction between the candidates.
- Four architecture scenarios, letting the board make a strategic choice instead of a package choice.
- A longlist of thirty-two vendors across seven clusters, reduced to a shortlist per cluster.
- Demos on a real business case, with the key users in the room.
- A vendor comparison on ten dimensions, including stack mapping per scenario.
- A supported decision, and an implementation that started with the material already built during the selection.
What you keep
Not a report for the drawer, but six things that keep working:
A choice you can explain to the board, the bank and your own organisation.
Certainty that the processes you compete on are actually supported. Proven in a demo, not promised in a quote.
Sight of the whole landscape, including the connections and tools that otherwise only surface after the ERP choice.
Buy-in, because key users saw their own work in the process.
A realistic cost and risk assessment, with vendor behaviour as an explicit factor.
A flying start to the implementation, because the process model already exists.
On request. A proposal on a single A4 within a week, with fixed scope and price.
What clients say about it
Quote to follow, once approved.
Quote to follow, once approved.
We structure the process intake, scoping and model building with our own tooling. The tool is why the approach is fast, not why it works.
See Scope Compass →Frequently asked questions about ERP selection
How long does a selection take?
Count on two to four months from first conversation to signed contract, depending on your pace and the number of clusters in the request. The elapsed time is almost always set by calendars, not by the work.
Do you have a fixed shortlist of systems?
No. The shortlist follows from your processes and the architecture scenarios. A fixed list is the business model of firms with reseller deals, and that is not what we are.
What if our current ERP is actually fine?
Then that's the outcome, and it's cheaper than any alternative. Sometimes the answer is a reconfiguration, a better integration layer or a few targeted apps next to the existing system.
Do you help with contract negotiation?
Yes. Scope, change-request clauses and implementation commitments are where the money sits, and the structured request from block 3 is the negotiating basis: the vendor has declared in writing what is standard and what is not.
Does this approach work for smaller companies too?
Yes, proportionally. The blocks stay the same, the depth scales. A fifty-employee company doesn't need a longlist of thirty-two vendors, but it does need the same honest classification of what really matters.
Which process is in your way?
Describe it in a few lines. Within one working day you'll hear whether it fits in 48 hours — and if so, the clock starts.
Send in your process