ERP BasicsLast reviewed: 2026-07-30

ERP Selection

Also: ERP-Auswahlprozess · Systemauswahl

ERP selection is the structured process a company uses to identify the right ERP system on the market – from requirements analysis through long list, short list and demos to a weighted evaluation and final decision.

ERP selection refers to the structured decision-making process a company uses to identify and choose the ERP system that best fits its processes, industry and size from the many systems available. It does not start by looking at products, but with the company’s own requirements: only once it is clear which processes the system needs to cover and how success will be measured can the market be sensibly narrowed down. The outcome is a well-founded, transparent decision for one vendor, together with a rough budget and timeline.

The process typically follows a funnel: broad market research (long list) is filtered through defined criteria into a narrower selection (short list), which is then tested in practice through demos and, where appropriate, a proof of concept. A weighted evaluation matrix makes the candidates comparable and separates mandatory from nice-to-have criteria. The goal of ERP selection is to reduce the risk of a costly wrong decision – an ERP often accompanies a company for ten years or more and can only be replaced with great effort once it is live.

At a glance

  • Structured funnel: requirements → long list → short list → demo/PoC → decision
  • The starting point is the requirements analysis, not the product comparison
  • A requirements specification creates a binding basis for comparison
  • A weighted evaluation matrix separates must-have from nice-to-have criteria
  • The rough budget covers licence, rollout, customisation and ongoing operation (TCO)

Why a structured ERP selection is decisive

An ERP system is a long-term investment that reaches deep into a company’s daily operations. A wrong choice ties up resources for years, creates workarounds and, in the worst case, forces a second selection and implementation project. That is why ERP selection is not simply a software purchase, but an undertaking that affects processes, people and profitability alike.

The value of a structured approach lies in comparability and traceability. Anyone who documents requirements, weights criteria and evaluates candidates under the same conditions decides on the basis of facts rather than gut feeling or a sales pitch. This protects against costly surprises after the contract is signed and builds acceptance within the company, because the decision is transparently justified.

The ERP selection process step by step

The ERP selection process can be broken down into clearly separated phases that build on each other. Each phase narrows the pool of candidates while deepening the assessment – from a broad market view to a concrete test against the company’s own processes.

Requirements analysis and requirements specification

It begins with capturing the as-is processes and the target requirements. Departments define which workflows the system must cover – such as order processing, warehousing, handover to financial accounting or multichannel integration. These requirements are described from the client’s perspective in the requirements specification; the vendor later responds in a functional specification detailing how it will implement them. A cleanly prioritised requirements specification with must-have, should-have and nice-to-have requirements is the single most important foundation of the entire selection.

Market research, long list and short list

Based on the requirements, a long list of ten to fifteen fundamentally suitable systems is drawn up. Knock-out criteria such as industry focus, company size, operating model or required interfaces filter this list down to a short list of usually three to five candidates. Only these are examined in detail, in order to keep the effort manageable.

Demos, proof of concept and references

The short-listed candidates present the system using predefined, real-world test scenarios – not a standard sales demo. In a proof of concept, critical processes can be run through with real data. In addition, reference customers of a similar size and industry provide insight into the reality of implementation, support and customisation effort.

Evaluation criteria and weighting

To compare candidates fairly, you need an evaluation matrix with weighted criteria. It translates gut feeling into traceable points and makes clear where a system is strong and where it demands compromises. Typical criteria groups are functional coverage, industry suitability, integration capability via interfaces, usability, scalability, vendor stability, support and the total cost.

The weighting is decisive: criteria that are central to the business model receive more weight than nice-to-have functions. Must-have criteria act as exclusion criteria – if one is not met, the candidate drops out regardless of the overall score. This prevents a system with many small advantages from masking a missing core function. Besides the pure purchase, the total cost of ownership also belongs in the evaluation, so that ongoing operating and customisation costs are not overlooked.

Rough budget and decision

Before the final decision, a rough budget is drawn up that covers more than just the licence fee. The cost blocks include software licences or subscription fees, rollout and project support, custom development and interfaces, data migration, training and ongoing operation including maintenance and updates. Only this overall view allows a realistic comparison of the offers.

The decision is ideally made jointly by a selection committee drawn from IT, the departments and management – based on the weighted matrix, the demo results and the budget assessment. It is important to consider, alongside function and price, soft factors such as the working relationship with the vendor and the future viability of the system. The reasoned decision is documented and forms the basis for contract negotiation and the subsequent implementation.

Common mistakes and the role of neutral consulting

Many ERP projects fail not because of the software, but because of the selection. Typical mistakes are a missing or overly vague requirements analysis, focusing on price alone, relying on polished sales demos instead of your own test scenarios, and a candidate list that is too short and eliminates attractive options too early. Underestimating migration, training and change management, as well as a weighting without genuine must-have criteria, also regularly leads to wrong decisions.

Vendor-neutral consulting starts exactly here. An independent consultant knows the market, has no sales commission tied to any particular system and facilitates the process with an open outcome – from capturing requirements through creating the long list and evaluation matrix to accompanying the demos. This aligns the selection with the company’s actual needs rather than with the strongest sales arguments. Especially in mid-sized companies, where internal resources and market overview are limited, neutral consulting significantly reduces the risk of a wrong purchase while also speeding up the process.

Example

Example: a wholesaler with 40 employees looks for a new ERP

A wholesaler runs its inventory management on an outdated system and wants to grow. Instead of immediately inviting vendors, the company first captures its core processes and creates a requirements specification with prioritised requirements – including, as must-have criteria, a DATEV interface, batch management and integration of the existing online shop.

From a long list of twelve systems, applying the knock-out criteria leaves a short list of four vendors. Each presents the same three real-world test scenarios; in parallel, a committee scores the candidates in a weighted matrix. Two systems fail because they do not meet a must-have criterion. The cheapest vendor ultimately loses to the runner-up, because its lower total cost over five years and stronger industry reference are more convincing. The documented decision provides the basis for the contract and the rollout.

Frequently asked questions

Depending on company size and complexity, the selection phase alone usually takes two to six months. Smaller businesses with clear requirements are faster, while many departments, sites or interfaces extend the process. Structured preparation noticeably shortens the duration.
The requirements specification describes, from the client’s perspective, what the ERP system should deliver. The functional specification is the vendor’s response to it and defines how these requirements are concretely implemented. The requirements specification is created during the ERP selection, the functional specification usually at the start of the project.
Three to five candidates have proven effective. Fewer restricts the comparison too much, more makes demos and detailed assessment uneconomical. The reduction from the long list is done using clear knock-out and must-have criteria from the requirements specification.
Often yes – especially when internal market overview and time are lacking. Vendor-neutral consulting facilitates the process with an open outcome, brings market knowledge and reduces the risk of a costly wrong decision. It is important that the consultant works independently and without a vendor’s commission.

Questions about ERP Selection in your ERP project?

We advise vendor-neutrally – and implement it ourselves on request.

Free consultation