ERP RFP Process — A Practical Run-Through

The RFP (Request for Proposal) is the structured mechanism for collecting comparable information from short-listed ERP vendors. A well-run RFP produces decision-ready scoring within 8-14 weeks; a poorly-run RFP becomes a 6-month bureaucratic exercise that produces 600-page responses no one can read. The difference between the two is structure, weighting and discipline — not effort. This guide walks through every phase of running an ERP RFP for a mid-market company in Germany, Switzerland or Austria, with concrete timing, scoring weights and the traps that recurringly catch first-time ERP buyers.

Preparation — before the RFP starts

The RFP cannot succeed without three pre-conditions. (1) Requirements catalogue (Requirements Document): a structured 60-150 page document covering business context, processes, functional requirements, non-functional requirements and constraints. The RFP is the questionnaire form of this catalogue — not its substitute. Writing the RFP without a catalogue results in vendors responding to thin questions with thin answers. (2) Pre-qualification: filter the long-list of 8-15 candidate vendors down to 4-6 by industry fit, size fit and geographic coverage. Common DACH pre-qualification criteria: native German-language support, established partner network in your region, references in your industry sub-segment, GoBD attestation, financial stability. (3) Internal team alignment: the evaluation team needs clear authority, available time and trained scoring methodology. Without those, the scoring will diverge and the decision will be re-argued for months.

RFP document structure

A workable RFP has five sections. (1) Company and project overview — who we are, what we want to do, project timeline, budget envelope. 3-5 pages. Sets the stage so vendors propose realistic scopes. (2) Functional requirements — structured questionnaire derived from the Requirements Document, organised by ERP module (financials, sales, purchasing, inventory, production, project management, HR, CRM, etc.), with MUST / SHOULD / COULD prioritisation per item. 15-40 pages. (3) Non-functional requirements — scalability, availability, security, integrations, language and regulatory needs (GoBD, GDPR, NIS-2, industry-specific). 5-10 pages. (4) Commercial questions — licence model, implementation cost breakdown, ongoing support cost, 5-year TCO calculation worksheet with assumptions explicit, infrastructure cost separately. 3-5 pages. (5) Compliance and references — ISO 27001, SOC 2, GoBD attestation, industry-specific certifications, comparable customer reference list with industry, size and implementation duration. 2-3 pages. Total RFP document: 30-65 pages. Anything over 100 pages signals scope problems.

Scoring and weighting

Use a weighted scoring model with explicit weights per category. Typical mid-market weights: Functional fit 35-45%, Technology fit and architecture 15-20%, Vendor and partner stability 10-15%, TCO 15-25%, Implementation approach 10-15%. Score each requirement on a 0-5 scale (0 = not supported, 1 = via heavy customisation, 2 = via third-party add-on, 3 = via standard configuration with effort, 4 = standard configuration, 5 = fully native out-of-the-box), multiply by weight, sum to total score per vendor. Critical: do not score commercial terms before functional evaluation — otherwise discount pressure drives the decision before the system fits the business. Separate evaluation streams (functional team scores functional fit, technical team scores technology, commercial team scores TCO) reduce cross-contamination. Calibrate scoring across evaluators by reviewing the first 10 items together before diverging into parallel scoring.

Reading the responses critically

Vendor responses range from genuinely useful to systematically evasive. Patterns to watch and how to handle them. 'Yes' without explanation: probably means the function is technically possible but not natively present. Send a follow-up question asking for specifics — how, in which module, requiring what licence tier. 'Out-of-the-box' with no caveats: ask for a screenshot, a customer reference confirming live use, or a demo of the function in the upcoming presentation. 'Custom development' for routine needs: the vendor is admitting a gap. Score accordingly and look for competing vendors that cover it natively. Heavy custom requirements compound over the project lifecycle. Long marketing prose without specifics: usually indicates the actual implementation team has not seen the question. Press for technical detail in clarifications. References to roadmap features: never count roadmap items as available capability. If a function is critical, it must be in production today, validated by a comparable customer reference. Inconsistencies between functional and technical answers: common when different vendor teams answered different sections. Surface inconsistencies in the clarification round.

Practical run-through — week by week

Weeks 1-3: draft RFP document, internal review by project sponsor and key users, approval. Week 4: vendor briefing (optional 1-hour introductory calls per vendor to align expectations on scope, timeline and response format). Weeks 5-8: vendors respond. Allow a minimum of four working weeks for quality responses; less than three weeks systematically produces thin answers. Weeks 9-10: clarification round — written questions and answers, distributed equally to all vendors. Week 11: vendor presentations to the project team. Two-hour slots, structured agenda (30 min company overview, 60 min functional demo of scripted scenarios, 30 min Q&A). Weeks 12-13: internal scoring calibration, total-score calculation, short-list decision (typically to 2-3 finalists). Week 14: decision communicated to vendors, next phase (live demos with deep scripted scenarios, POC or pilot) scheduled. Variations: longer for complex international tenders; shorter for tightly-scoped SMB projects with fewer modules. Compressing below 8 weeks systematically reduces response quality.

Common pitfalls

• Homeing with vendor names instead of requirements. The brand-led approach skips the analysis that would have revealed misfit early
• Excessive RFP weight on functional checklists — modern ERP from major vendors covers 90% of functional checklist items; the differentiation is in fit, partner quality 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
• Reference visits scripted by the vendor — always ask for at least one reference outside the vendor's recommended list
• Ignoring the implementation partner — the partner matters more than the product. Same product with different partners delivers wildly different outcomes
• 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

Related Topics

• ERP selection
• Requirements document
• SLA