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
The ideal time is after internal clarity on requirements has been reached and before the first vendor contact. Starting too early wastes vendor meetings; starting too late gives away negotiating leeway. A clear signal to start is having documented knock-out criteria and an internal project team with a decision-making mandate. A lead time of 4-8 weeks before vendor selection is common.
Who should be involved in the ERP RFP process?
A mixed team drawn from IT, the business departments (accounting, sales, logistics depending on the module focus) and management. IT brings the technical perspective, the business departments the process expertise, and management decides on budget and strategy. Ideally there is a dedicated project lead with 30-50 % of their time available. Larger mid-sized companies frequently also bring in external selection support — see selection advisory.
How long does an ERP RFP process typically take?
The duration varies greatly with complexity: simple setups in 4-8 weeks, mid-market ERP projects in 6-12 months, corporate group migrations in 18-36 months. The functional preparation phase is frequently underestimated — it accounts for 30-40 % of total project time. Realistic timelines allow for holiday and quarter-end peaks as well as the typical delays in data migration. A buffer of 20-30 % on the initial plan is standard industry practice.
What typical mistakes occur in the ERP RFP process?
Common pitfalls: no written requirements document, too few reference checks on vendors, underestimated data migration and missing change management for end users. Another mistake is committing to a vendor without a demo on your own data. Risk is minimised through a structured approach, written documentation and at least three vendors for comparison. External support significantly reduces the risk of wrong decisions.
Which tools or templates help with the ERP RFP process?
Proven aids include a structured requirements document, a weighted evaluation matrix for vendors, a demo script using your own data and a RACI model for role clarity. Templates are available under requirements document template. A project-tracking tool (Jira, Asana, MS Project) with milestone tracking is also worthwhile. Weekly status calls with an escalation path are mandatory in every project phase.
