Download: Software Ausschreibung Vorlage (RFP-Template)
RFP-Template (Word) – Software Ausschreibung Vorlage
Textstruktur mit Kapitel-Template für Scope, Use Cases, Anforderungen, NFRs, Integrationen, Fragenkatalog, Scoring und TCO.
Format: .docx
Hinweis: Wenn Sie den Download gaten möchten (E-Mail), ersetzen Sie den direkten Link durch ein Formular/CRM-Flow.
Warum eine Ausschreibung hilft (und wann nicht)
Warum ein RFP (Ausschreibung) im Mittelstand sinnvoll sein kann
- Vergleichbarkeit: Anbieter beantworten die gleichen Use Cases und Kriterien
- Risikoreduktion: kritische Punkte (Integration, Rechte, Datenmodell) werden früh sichtbar
- Zeitersparnis: weniger 'Showcases', mehr strukturierte Antworten
- Bessere Angebote: klare Abnahmekriterien und Scope reduzieren Change-Request-Spiralen
Wann ein RFP übertrieben ist
- Wenn Scope sehr klein ist (z. B. 1–2 Workflows) und Sie schnell iterieren möchten
- Wenn Sie ohnehin nur 1 realistische Option haben (z. B. Konzernstandard)
- Wenn Sie nicht bereit sind, Antworten sauber zu bewerten (dann wird es Theater)
Aufbau einer guten Software-Ausschreibung (RFP) – Kapitel für Kapitel
Die Vorlage folgt einer Logik: erst Kontext und Scope, dann Use Cases und Risiken, dann Bewertung und Vertrags-/TCO-Themen. So bleibt das RFP für Anbieter klar – und für Sie vergleichbar.
1) Kontext & Zielbild
- Problem-Statement (1 Seite): Symptome, Impact, Zielgrößen
- Zielbild als Capabilities (nicht Feature-Liste)
- MVP-Scope + Roadmap v2/v3
2) Systemklasse & Abgrenzung
- Welche Systemklasse suchen Sie? (ERP, PIM, CRM, MDM, iPaaS …)
- Was ist bewusst out of scope? (z. B. BI, DWH, DMS)
- Integrationslandkarte (Ist/Soll)
3) Use Cases (Kernteil)
- 10–25 priorisierte Use Cases (Impact × Häufigkeit × Risiko)
- Akzeptanzkriterien (testbar) + Beispiel-Datensätze
- No-Go Use Cases (muss gehen, sonst raus)
4) Datenanforderungen & Ownership
- Datenobjekte und Felder (Minimum Dataset für MVP)
- Datenhoheit pro Feld (führende Quelle / write-back Regeln)
- Validierungen: Pflichtfelder, Wertebereiche, Dublettenlogik
5) Nicht-funktionale Anforderungen (NFRs)
- Rollen/Rechte, Audit, DSGVO/PII, Logging
- Performance/Volumen, Verfügbarkeit, Backup/Restore
- Betrieb: Monitoring, Reprocessing, Support-Prozesse
6) Bewertungslogik & Scoring
- Kriterienkatalog + Gewichtung (nicht nur ungewichtete Summen)
- Muss/Kann: Mindestkriterien vs. Differenzierungsmerkmale
- Trade-offs dokumentieren (wichtig für Governance)
7) PoC/Demo-Design
- Standardisierte Demo-Skripte je Anbieter (gleiche Zeitbox)
- Mini-PoC: kritische Risiken prüfen (Integration, Rechte, Datenmodell)
- Definition of Done + Abnahmekriterien
8) Angebote, TCO & Vertrag
- TCO (3–5 Jahre): Lizenz + Implementierung + Betrieb + Integrationen + Wachstum
- Meilensteine, Abnahme, Change Requests, Exit/Portabilität
- SLA/SLO Anforderungen je kritischem Prozess
Praxis-Tipp: Der Kern ist immer Kapitel 3 (Use Cases). Wenn Sie dort sauber sind, werden Demos, PoCs und Angebote deutlich besser.
Systemklassen: Ausschreibung richtig einordnen (ERP, PIM, CRM, MDM, iPaaS)
Ein RFP ist am besten, wenn es klar ist, welche Systemklasse gesucht wird. Sonst vergleichen Anbieter unterschiedliche Problemtypen.
ERP (Kernprozesse & Transaktionen)
Wenn End-to-End Prozesse (Finance, Beschaffung, Auftragsabwicklung, Produktion) im Zentrum stehen.
PIM (Produktcontent & Kanäle)
Wenn Produktdaten für Shop/Marktplätze/Kataloge sauber gepflegt und ausgespielt werden müssen.
MDM (Golden Record & Governance)
Wenn Dubletten, Governance, Audit und Domänen-Konsistenz (Kunde/Lieferant) kritisch sind.
CRM (Revenue-Prozess)
Wenn Sales/Marketing/Service datengetrieben konsistent werden soll (Lead→Deal→Kunde).
iPaaS (Integration + Betrieb)
Wenn Integrationen der Hebel sind: Monitoring/Reprocessing/Runbooks reduzieren Run-Kosten.
Typische Fehler in Ausschreibungen (und wie Sie diese vermeiden)
Fehler 1: Feature-Listen statt Use Cases
Fix: Use Cases mit Akzeptanzkriterien erzwingen Vergleichbarkeit. Features sind abgeleitet, nicht entscheidend.
Fehler 2: Keine Gewichtung der Kriterien
Fix: Gewichtung macht Trade-offs sichtbar. Ohne Gewichtung gewinnt der beste Sales-Pitch.
Fehler 3: TCO nur als Lizenzvergleich
Fix: Betrieb, Admin, Integrationen und Weiterentwicklung dominieren 3–5 Jahre. TCO muss Run enthalten.
Fehler 4: Kein PoC für kritische Risiken
Fix: Mini-PoC fokussiert wenige, aber riskante Fragen: Datenmodell, Rechte, Integration, Performance.
Weiterlesen — 3 Artikel
Vorbereitung
Anforderungsanalyse
Solide Use Cases und Akzeptanzkriterien sind das Fundament jedes guten RFP.
Zum Artikel →Auswahl
Software Demo bewerten
Wie Sie Demo-Skripte ableiten und Anbieter strukturiert bewerten.
Zum Artikel →Kosten
TCO-Analyse
Warum TCO und Betriebskosten ins Angebot gehören – nicht als Fußnote.
Zum Artikel →RFP-Bewertungsraster (Vorlage zur Anpassung)
Eine objektive Anbieter-Bewertung braucht ein Raster mit klaren Gewichtungen — sonst entscheidet die Story-Telling-Qualität des Anbieters statt der Fit-for-Use.
| Kriterium | Gewicht | Skala 1–5 / Erläuterung |
|---|---|---|
| Funktionale Abdeckung (Must-Haves) | 25 % | % der Must-Haves nativ erfüllt — nicht mit Custom |
| Funktionale Abdeckung (Should/Could) | 10 % | % der Should-Haves nativ + Roadmap-Items |
| Integrations-Fähigkeit (APIs, Std.) | 15 % | Anzahl produktiver Connectors für eure Systeme |
| TCO über 5 Jahre | 15 % | Lizenz + Implementierung + Betrieb (€) |
| Implementierungs-Partner DACH | 10 % | Anzahl zertifizierter Partner + Referenzen |
| Vendor-Risiko (Stabilität, M&A) | 10 % | Umsatz/Wachstum/Eigentümerstruktur |
| User Experience (Demo-Score) | 10 % | Bewertung der Power-User im Demo-Workshop |
| Compliance / DSGVO / Datenhoheit | 5 % | Hosting-Region, ISO-27001, AVV vorhanden |
| Summe | 100 % | Score 1–5 pro Kriterium × Gewicht = Gesamtscore |
5 typische Anbieter-Tricks — und wie Sie sie aushebeln
Anbieter sind Profis im Win/Loss. Wer eine Ausschreibung schreibt, kämpft gegen 30+ Jahre Sales-Erfahrung. Diese 5 Muster tauchen am häufigsten auf.
01 ── Wir können das auch, das ist Customizing.
Gegenstrategie: Liste der Must-Haves explizit als nativ markieren. Wer 'Customizing' antwortet bekommt 0 Punkte.
02 ── Pro-Lizenz versteckt die Premium-Features.
Gegenstrategie: TCO immer mit dem konkret benötigten Lizenz-Tier rechnen — bei dem die geforderten Features enthalten sind, nicht 'Basic'.
03 ── User-Lizenz vs. Named-User vs. Concurrent.
Gegenstrategie: Klären: wie viele tatsächliche User × wie viel gleichzeitig × in welchem Modell. Manchmal verdoppelt sich der Preis.
04 ── Konnektoren als ‚optional' deklarieren.
Gegenstrategie: Pflicht-Konnektoren (ERP, SSO, BI) im Lastenheft explizit als Pflicht-Lieferumfang fordern.
05 ── ‚Roadmap-Feature in Q3' als Verkaufsargument.
Gegenstrategie: Roadmap-Features mit 0 % gewichten. Nur produktiv-verfügbare Features zählen.