Selecting the right ERP is the most consequential single decision in a typical 5-10 year IT roadmap. The cost of a bad selection — millions in implementation effort, productivity loss, broken commitments and eventually another migration — dwarfs the cost of investing 6-9 months in a disciplined selection. This guide outlines a methodology proven across dozens of mid-market ERP projects in Germany, Switzerland and Austria. It covers concrete deliverables per phase, realistic time and effort estimates, scoring approaches, the typical traps that catch first-time ERP buyers, and practical recommendations for each decision point. The methodology is product-agnostic — it applies equally to organisations evaluating SAP S/4HANA, Microsoft Dynamics, Oracle Cloud ERP, NetSuite, abas, proALPHA, Sage, weclapp, Xentral, Odoo or any other ERP product.
The seven phases of ERP selection
A disciplined ERP selection runs through seven phases, each producing concrete deliverables that feed the subsequent phase. Skipping or rushing any one of them is the most consistent predictor of selection regrets within 18 months of go-live.
Pain-point analysis — document current operational frictions, broken processes and data-quality issues across all major departments. Interview 15-30 key operational staff. Output: a 5-10 page issue catalogue with prioritisation by impact and urgency. Time: 3-6 weeks.
Requirements catalogue (Requirements Document) — structured list of functional and non-functional requirements, covering core ERP modules, industry-specific needs, integration points, regulatory constraints. Output: 60-200 page document, version-controlled, signed off by the steering committee. Time: 4-8 weeks.
Vendor pre-qualification — long-list of 8-15 vendors filtered by industry fit, size fit and geographic presence. Output: long-list summary with rationale for each entry. Time: 2-4 weeks.
RFP (Request for Proposal) — structured questionnaire derived from the Requirements Document, distributed to the long-list, with weighted scoring of responses. Vendor presentations. Output: short-list of 3 vendors with detailed scoring. Time: 8-14 weeks.
Live demos and POC — scripted scenarios based on your business, executed by the vendors with their actual system. Optional proof-of-concept on critical functions. Output: hands-on evaluation by key users with structured scoring. Time: 4-8 weeks.
Reference visits — in-person or virtual visits to comparable customers using the short-listed systems. Output: independent perspective on real-world strengths and weaknesses. Time: 3-5 weeks.
Contract negotiation — commercial terms, licence model, implementation scope, SLA, exit clauses, indemnification, IP rights. Output: signed agreement with the chosen vendor. Time: 4-10 weeks.
Timeline and effort
A disciplined ERP selection runs 6-9 months from kick-off to signed contract. Compressing this to 4 months is occasionally necessary (regulatory deadlines, M&A timing) but reliably produces buyer regrets within 18 months of go-live. Extending beyond 12 months typically reflects analysis paralysis — the decision drifts as priorities shift, vendor offers expire, and the project loses momentum.
Internal effort: 100-300 person-days from the project team and key users, typically 5-10 people part-time. The project lead alone commits 40-60% of their time across the selection. Key users contribute 5-15 person-days each for requirements elicitation, demo evaluation and reference checks. The executive sponsor commits 10-20 person-days for steering committee meetings, vendor executive meetings and final decision sessions.
External consulting effort (when using a selection consultancy — common for first-time ERP buyers and mid-market projects above 500,000 EUR budget): 60-180 person-days at daily rates of 1,500-2,200 EUR for senior selection consultants. Total external cost for selection alone: 90,000-400,000 EUR for a typical mid-market project. This is 5-10% of total ERP project cost — small relative to the cost of choosing wrong, which can run to 20-50% of the total project as remediation and missed business opportunity.
Building the requirements catalogue
The Requirements Document (requirements catalogue) is the foundation of everything else. Its quality directly determines the quality of vendor evaluation. The structure most teams converge on includes six sections.
(1) Company context — business model, organisational structure, key operational metrics, sites, languages, regulatory environment. 5-10 pages. Provides the framing every vendor needs.
(2) Process overview — end-to-end operational processes (order-to-cash, procure-to-pay, plan-to-produce, record-to-report, hire-to-retire) at a level any vendor can understand. BPMN diagrams or narrative process flows. 10-25 pages.
(3) Functional requirements — the largest section, broken into ERP-module sub-sections (financials, controlling, sales, purchasing, inventory, warehouse, production, project management, HR, CRM, BI). Each requirement marked MUST / SHOULD / COULD with rationale. 30-80 pages.
(5) Integration landscape — existing systems the new ERP must connect to (CRM, e-commerce, MES, WMS, BI, payroll, e-invoicing) with data flows, frequencies, APIs. 5-15 pages.
(6) Constraints and preferences — cloud versus on-premises, technology preferences, timeline constraints, budget envelope, geographic considerations. 2-5 pages.
Total: 60-150 pages for typical mid-market. Less than 60 pages indicates inadequate detail; more than 200 pages indicates analysis paralysis or scope creep. The discipline of MUST / SHOULD / COULD prioritisation is the most important single technique — the 80/20 rule applies, where 20% of requirements drive 80% of vendor differentiation.
Vendor pre-qualification
Pre-qualification filters the universe of ERP vendors down to a workable long-list. Without filtering, the RFP process drowns in irrelevant responses; over-filtering risks missing good options. The right criteria for DACH mid-market typically include:
Industry fit — vendor has demonstrable references in your sub-industry (machinery, food, pharma, wholesale, etc.). Industry analyst reports (Trovarit, IDC MarketScape, Gartner Magic Quadrant) provide structured input
Company-size fit — vendor's customer base matches your scale. Enterprise vendors selling to 30-employee companies typically over-engineer the project; SMB-focused vendors stretched into 500-employee operations typically underdeliver
Geographic coverage — partner network in your region with implementation capacity. Critical for DACH operations: native German-language support, local regulatory know-how (GoBD, ZUGFeRD, XRechnung, DATEV)
Financial stability — the vendor must be around in 5-10 years. Recent acquisitions, ownership changes and financial-distress signals warrant deeper review
Compliance posture — ISO 27001, SOC 2, GoBD attestation, industry-specific certifications where relevant
Technology roadmap — modern cloud architecture, AI integration plans, public API breadth
Pre-qualification narrows 30-80 candidate vendors to 8-15 long-listed, then to 4-6 RFP recipients. Each filtering step should be documented with rationale — this becomes the audit trail when stakeholders later ask 'why was X not considered?'
Live demos and reference checks
The single most predictive activity in ERP selection is the hands-on demo with scripted scenarios from your business. PowerPoint demos reveal almost nothing; functional checklists in RFPs reveal little; vendor-controlled standard demos reveal what the vendor wants to show. Scripted live demos against your own scenarios reveal whether the system actually fits your operations.
Build 5-10 scenarios that exercise the highest-priority requirements. Examples: receive a complex customer order with variant configuration, run MRP and verify the resulting production orders match expectations, post a partial delivery, issue an invoice with non-standard discount approval, perform month-end close on a multi-entity book, run a tax-compliant report for your auditor. Send the scripts to vendors 2-3 weeks before the demo. Require them to demonstrate on their actual system, not on a custom-built demo environment.
Reference visits are the next most valuable activity. Ask the short-listed vendors for 3-5 references from comparable customers (similar industry, size, scope) and arrange 60-90 minute reference calls or in-person visits. Critical: ask for at least one reference outside the vendor's recommended list — vendors only refer their happiest customers, so the unfiltered perspective is essential. Useful reference questions: how long did implementation take versus plan, how is the vendor support quality, what would you do differently, what surprised you negatively after go-live, would you choose the same vendor again.
Typical mistakes — what to avoid
Homeing with vendor names instead of requirements. The brand-led approach skips the analysis that would have revealed misfit early. Even if you have a strong preference for a specific vendor, run the disciplined process — you will either confirm the preference with evidence or discover a better fit you would have otherwise missed
Excessive RFP weight on functional checklists — modern ERP from major vendors covers 90% of functional checklist items. The differentiation is in fit (do the workflows match your operation), partner quality, ecosystem breadth and roadmap — not in checkbox depth
No actual hands-on testing — selecting from PowerPoint presentations alone catches only the most obvious misfits. Always require live demos with your scripted scenarios. Without hands-on testing, mid-implementation discoveries become very expensive change requests
Reference visits scripted by the vendor — always ask for at least one reference outside the vendor's recommended list. Use professional networks, industry associations and the Trovarit database to find unfiltered references in DACH
Ignoring the implementation partner — the partner matters more than the product. Same product with different partners delivers wildly different outcomes. Evaluate partner CVs, success stories, and (most importantly) ask to meet the actual team that will deliver your project, not just the sales team
Inadequate contract review — the default vendor contract heavily favours the vendor. Push back on indemnification, IP, audit rights, exit clauses, price escalators, sub-processor lists for GDPR. Specialist ERP-contract lawyers (or ERP-experienced corporate lawyers) pay for themselves multiple times over
No internal sponsorship — selections led by IT alone without active business sponsorship reliably produce technology-first decisions that the business rejects during implementation. The executive sponsor must be a business leader, with IT in a supporting role
Selection in regulated industries
Selection in regulated industries (pharma, medical devices, automotive Tier-1, food, financial services) adds compliance layers on top of the standard methodology. Validation-readiness (GAMP-5 for pharma, IATF 16949 for automotive supply, IFS Food and BRC for food, ISO 13485 for medical devices) becomes a binary qualifier rather than a scoring dimension — vendors without demonstrable regulatory fit drop from consideration. Audit-trail depth, electronic-signature compliance, and the vendor's assurance-evidence portfolio (SOC 2 Type II, ISO 27001, vendor-supplied validation documentation) shift weight materially. For DACH mid-market manufacturers facing NIS-2 obligations from 2025 onwards, cybersecurity-control evidence and incident-reporting integration capabilities should be evaluated explicitly during selection rather than added retroactively after go-live. The selection methodology described in this guide adapts cleanly to these regulated-industry needs; the additional weighting shifts naturally during the requirements-catalogue phase as the regulatory constraints get explicit treatment.
Practical recommendations
Five practical recommendations distilled from many mid-market ERP selections.
(1) Build the requirements catalogue with the business operators who actually run the processes, not just IT or finance. The clearer the operational view, the better the selection. Reserve IT for editorial and architectural input, not authorship. Business-led requirements result in business-led implementations, which result in successful go-lives.
(2) Pre-qualify based on industry depth, partner network in DACH and company-size fit — not on global market-share rankings. Top-5 global vendors are not automatically the right answer for your specific situation. Mid-market specialists often deliver materially better outcomes in their sweet-spot industries than enterprise leaders.
(3) Run live demos against your own scripted scenarios. A 30-minute scenario you control reveals more than two hours of vendor presentation. Pay particular attention to non-happy-path scenarios: order changes, returns, credit notes, period-close exceptions — these are where the differences between systems become visible.
(4) Speak to at least two references per short-listed vendor and at least one outside the vendor's suggested list. The independent voice is the most valuable single source of information in the entire selection process. Industry associations (VDMA for machinery, BVL for logistics, BAH for pharmaceutical wholesale) often help connect with unfiltered references.
(5) Take the time. Compressed selection processes (under 4 months) consistently produce regrets within 18 months of go-live. The implementation phase costs 5-10x the selection phase — saving weeks in selection to lose months in implementation is the worst possible trade. Budget 6-9 months for the selection and protect the schedule.
How long does a professional ERP selection process take?
Realistic ranges are three to six months for mid-sized companies and six to twelve months for complex, international group projects with multiple sites and legal entities. Cutting the process below three months almost always comes at the expense of quality, particularly for the requirements document, structured demos and contract negotiation. The pure selection is frequently confused with the subsequent implementation, which can take another six to eighteen months depending on complexity. Anyone planning the timeframe too tightly risks one of the most common causes of later budget overruns.
What is the difference between the requirements document and the functional specification in ERP selection?
The requirements document (Lastenheft) describes, from the customer's perspective, what the future system is supposed to deliver, and is produced before vendor selection as the basis for comparable quotes. The functional specification (Pflichtenheft) is then created by the chosen vendor and defines how it will concretely implement the requirements. Put simply: the requirements document states the what, the functional specification the how. A carefully drafted requirements document is considered one of the most important success factors across industries, because experience shows that unclear requirements lead to misunderstandings, customising and later cost increases.
When is external selection advisory support worthwhile?
External support is worthwhile above all for a first ERP implementation, for international multi-country projects and in highly regulated industries where internal methodological expertise or capacity is lacking. It typically pays for itself through better contract terms, lower customising ratios and faster time-to-value. The independence of the advisors is important: support tied to vendor commissions can create conflicts of interest. Since licence fees usually account for only about 15 to 35 percent of total project costs, with the larger block going to implementation, customising, training and data migration, well-founded preparation has an effect across the entire project lifetime.
Should we commit to one vendor or run an open tender?
An open tender almost always yields better terms and more transparency, even if a favourite already exists internally. Experience shows that competitive pressure pushes prices down and leads to sharper service descriptions and more binding statements on functional coverage. A direct award only makes sense when a group-wide standard is strictly mandated or the relevant market is extremely small. Even with a clear favourite, it is advisable to keep at least one serious competitor in the process to protect your negotiating position.
How many vendors should be on the longlist and shortlist?
A sensible longlist contains eight to twelve vendors, the shortlist three to a maximum of five. Fewer candidates weaken competition and increase price and vendor lock-in risks, while more make demos and evaluation uneconomical. It is important that the remaining candidates are genuine alternatives and not merely token participants who distort the picture. Since the German-speaking market comprises well over two hundred relevant ERP vendors, systematic filtering by company size, industry, deployment model and country coverage is the decisive step from longlist to a viable shortlist.
Cloud or on-premise — how do you decide this in ERP selection?
The decision should follow from the business model and not the other way round: what matters are the company's dynamics, the speed of site and service integration, regulatory requirements and the available IT and process competencies. Cloud ERP relieves you of technical operations and offers automatic updates and faster implementation, while on-premise enables deeper customisation and full data sovereignty. According to current surveys, the cloud share in the DACH market stands at a good forty percent of systems in operation, with a clearly rising trend, which is why hybrid models and hosted solutions with servers located in Germany are also gaining importance. Rather than committing early, the deployment model should enter the evaluation matrix as a weighted criterion.
What are the most common mistakes in ERP selection?
Cross-industry surveys show that, depending on the source, roughly half to two thirds of ERP projects miss their goals or significantly exceed budget and schedule, with the causes rarely being technical. Typical mistakes are a rushed decision under time pressure, selecting purely on feature lists and sales arguments instead of your own functional requirements, and underestimating the implementation partner and the internal effort. Frequently there is also no clear mandate from management, no early change management and no clean data basis as the foundation for comparable licensing models. A structured selection process with a requirements document, weighted decision matrix and scripted demos demonstrably reduces exactly these risks.
