ERP selection: the process from business question to decision
ERP selection is the process in which you choose which ERP system and which implementation partner fit your organisation. Below you read in seven steps how that process runs, from recording your business question to a decision you can still explain later. You also read what to test system and partner on, what plays per sector and when a selection process is needed.
What to test a system on
What to test a partner on
When you do not need a process
Two decisions, not one
An ERP selection holds two decisions: which software you will run, and who will help you put it in. They fail in different ways, which is why you should assess them separately.
As background to those two decisions: Gartner research predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business goals (Gartner, 2024).
The system
Sets what is possible. When it does not fit, you notice it in the number of exceptions you have to have built.
Read about choosing a systemThe partner
Sets what you actually get. When they do not fit, you notice it in the pace at which problems get resolved.
Read about choosing a partnerAssess the two separately, each on its own criteria.
An ERP selection is therefore not a comparison of feature lists. So look beyond what a system can do on paper. The difference lies in your exceptions, and you do not see that in a feature list.
What are the seven steps of an ERP selection?
The order runs from business question to decision. The weight sits deliberately before the demonstrations: complete steps one and two before you look at candidates, otherwise you spend the rest of the process justifying a choice that was already made.
Record the business question and core processes
Start with the processes that earn the money, not with a feature list. Record where you want to go as an organisation, which steps pinch today and which exceptions genuinely occur. Also decide which of those disappear once the process changes. Make that distinction before you draw up requirements.
Result: a description of your core processes, the bottlenecks in them and the goals the new situation has to meet.
Involved: management, process owners and the person responsible for finance.
Separate requirements from wishes
A requirement is something the business cannot run without. Everything else is a wish. Separate requirements from wishes and compare candidates on criteria set in advance. Trace every requirement back to a business goal: according to Gartner, strong alignment between ERP initiatives and the organisation’s strategic goals is a clear predictor of successful ERP initiatives (Gartner, 2024). Record requirements and priorities in one overview, for example with a business requirements scan.
Result: a list of requirements and wishes in order of importance, linked to the processes from step 1.
Involved: key users per process, the person responsible for finance, and IT.
Build the long list on sector, size and architecture
Select candidates on demonstrable fit for your sector and your size, not on how well known they are. Also look at the architecture: cloud, self-hosted or a combination, and how a system fits your existing integrations. Include systems you do not know, alongside the names already on the table. Which types exist, you read at comparing ERP systems; what plays per sector, at ERP for manufacturing, ERP for wholesale and ERP for professional services.
Result: a long list built on facts, where you know for each candidate why it is on it.
Involved: the project team, with IT for the questions on architecture and integrations.
From long list to shortlist with an RFI or RFP
Send the candidates an RFI or RFP in which you describe your core processes and ask concrete process questions. Do not ask whether a system supports returns, but how it processes a return with a partial credit note. Ask every candidate the same concrete questions and put the answers side by side. Also speak to references you choose yourself, preferably in your own sector, and not only to the references the vendor puts forward.
Result: a shortlist backed by the answers to your own process questions and by reference calls.
Involved: the project team drafts the questions, key users assess the answers.
Demonstrations on your own scenarios
Do not let vendors give their standard demonstration. Hand them your own orders, your own exceptions and your own month-end close, and watch where the standard stops and custom work begins. Take notes per process rather than per system, and compare afterwards per process rather than on a general impression. Also ask what the system does not do well and where its limits are.
Result: per process, a comparison of what each candidate does as standard and where adaptation is needed.
Involved: the person responsible for finance and the operational users, not only IT.
Assess the partner separately and compare the cost breakdown
System and partner are two separate decisions. So assess the partner apart from the package. Test consultant availability, sector experience and how they handle setbacks, and ask about a project that ran into trouble. Ask for the breakdown of every quote: licences, implementation, data migration, training, change management and an item for contingencies. How you test a candidate before signing, you read at choosing an ERP implementation partner.
Result: per candidate, an assessment of the partner and a cost breakdown you can set beside those of the other candidates.
Involved: the project team, the person responsible for finance and the intended system owner after go-live.
Record the decision with its trade-offs and the steering committee
Trace the final choice back to the goals from step 1, not to the feature list. Record why the choice fell as it did, which risks were known and which assumptions still need testing. Use that document later to explain why certain concessions were made. Involve the steering committee that approved the business case and put the decision to it for approval.
Result: a recorded decision on system and partner, with the trade-offs, the known risks and the open assumptions.
Involved: the steering committee, management and the project team.
ERP selection per sector
Record for your sector which requirements weigh heavily for your processes. Per sector you read what plays, which systems run there and what you select on.
Manufacturing: in manufacturing, test whether a system fits your production model: to stock, to order or to project.
ERP selection for manufacturersWholesale: in wholesale, test whether the system records stock per location and pricing agreements per customer correctly at the same time.
ERP selection for wholesalersProfessional services: in services and maintenance, test how the system records the planning of people, the time spent and the invoicing of that time.
ERP selection for service providers
What do you test a system and a partner on?
Each topic carries two different questions. If you can answer only one of them, you are not yet in a position to decide on that topic.
Two questions per topic
| Topic | About the system | About the partner |
|---|---|---|
| Process fit | Does the system cover your core process as standard, without custom work? | Does the partner know this process from their own projects in your sector? |
| Exceptions | How does the system handle your unusual orders and customers? | Does the partner advise dropping exceptions, or building them? |
| Data | Which data are you bringing across, and what structure does the system demand? | Who owns data quality, you or the partner? |
| Integrations | Are the connections to your existing systems available as standard? | Who maintains those connections after go-live, and under what agreement? |
| Life after go-live | What can you configure yourself, and where do you stay dependent? | Do the same people stay involved, or does the team change after handover? |
| Cost balance | Which items sit inside the licence, and which arrive on top of it? | How does the hourly rate relate to the guidance you will actually need? |
When do you need a selection process?
Not every ERP question calls for a selection. Establish that up front.
A selection process fits
- Your processes have changed and the system no longer follows them
- You can no longer see what custom work costs you each year
- The vendor is ending support, or forcing a migration
- You are growing into a scale or a country the system was not built for
Something else fits better
The system fits, the configuration does not
Complaints are about screens, permissions and reports, not about what the system can do. Then first test whether a configuration project solves it, before you choose a new system.
The bottleneck sits in the process
If the same exception returns every week because nobody is allowed to refuse it, new software moves that problem to a new screen.
A choice has been made that nobody has tested
A second opinion on that choice is then more useful than a full process. Test the assumptions, not the candidates.
Going deeper per topic
Both decisions have a page of their own, because there is more to say about each than fits here.
Frequently asked questions
- What does ERP selection involve?
ERP selection is the process of establishing which ERP system and which implementation partner fit your processes, your risks and your ambitions.
It ends in a reasoned decision rather than a preference. The reasoning is the real deliverable: it is what explains, later, why certain concessions were made.
- What is an ERP system?
An ERP system is standard software that supports an organisation’s core processes as one connected whole, such as purchasing, stock, production, sales and finance.
Test with every candidate how that connection works for your own processes.
- How do you choose the right ERP implementation partner?
Judge the partner separately from the system, on sector experience, consultant availability, and how they handled setbacks on earlier projects.
Ask about a project that ran into trouble and what they changed as a result. A partner who can only name successes has either done little or learned little.
- What does an ERP project cost?
That depends on your size, your number of users and how much falls outside the standard. Look beyond the licence to the cost of implementation and the custom work around it.
So do not ask for a figure but for the breakdown: what the price includes, what is charged per user, and what counts as extra work. A quote without that breakdown cannot be compared with another one.
- Can you run an ERP selection yourself?
Yes, provided you free up someone who knows the processes, has the time, and has no stake in the outcome. Test that last condition critically above all.
The question is not whether you can, but who organises the challenge. External guidance makes sense as soon as those three conditions do not coincide.
- What is the difference between an RFI and an RFP?
An RFI (request for information) is exploratory: you ask vendors for general information about their package, their services and how they support your core processes. With an RFP (request for proposal) you describe your requirements and scenarios and ask for a concrete proposal, with approach, planning and cost breakdown.
You use an RFI to get from long list to shortlist, and an RFP to compare the shortlisted candidates on a concrete proposal. In both cases, ask process questions rather than questions that can be answered with yes or no.
Further reading on ERP selection
This page describes the process. The articles below each take one part of it and go deeper.
Have your selection tested
ERP Company earns nothing from your choice: no licence, no implementation hours, no commission from a vendor. We guide the process from the client side and review choices that have already been made.
Where we help
- Testing your requirements before you go to market
- Guidance on choosing a system and a partner
- A second opinion on a choice already made
On 15 October 2026 our network counted 270+ specialists. ERP Company has no ties with software vendors.