RFP erstellen: Die vollständige Anleitung für die Softwareauswahl im Mittelstand 2026
Wer Software auswählt, ohne ein klares RFP zu haben, entscheidet am Ende nach Demo-Eindruck und Sympathie. Nicht nach dem, was das Unternehmen wirklich braucht. Ein gutes RFP ist kein Bürokratie-Dokument. Es ist das einzige Werkzeug, das Anbieter vergleichbar macht. Dieser Guide zeigt Ihnen, wie Sie ein belastbares RFP in 6 Schritten aufsetzen, versenden und auswerten.
Was Sie aus diesem Guide mitnehmen
- Ein RFP ist kein Lastenheft, aber eng verwandt. Das Lastenheft beschreibt, was das System können muss. Das RFP ist das Dokument, mit dem Anbieter eingeladen werden, genau darauf zu antworten, inklusive Preis, Referenzen und Implementierungsplanung.
- Ein RFP ohne Priorisierung ist wertlos. Wer alle Anforderungen gleichwertig auflistet, bekommt gleichwertig unbrauchbare Angebote zurück. Muss / Soll / Kür ist keine Bürokratie, sondern die Grundlage jeder Entscheidung.
- Das größte Einzelproblem in jedem RFP: Anforderungen, die eine Lösung beschreiben statt ein Bedürfnis. "Das System muss einen Excel-Export haben" versus "Sachbearbeiter müssen Daten in gängige Tabellenformate exportieren können." Der Unterschied klingt klein und verändert die Anbieter-Landschaft grundlegend.
- RFPs, die manuell per E-Mail versendet werden, erzeugen E-Mail-Chaos. Antworten kommen in unterschiedlichen Formaten, zu unterschiedlichen Zeiten und in unterschiedlicher Vollständigkeit. Strukturiertes Feedback-Management ist der entscheidende Unterschied zwischen einer auswertbaren und einer nicht auswertbaren Ausschreibung.
- Das Ziel eines RFP-Prozesses ist eine Nutzwertanalyse, keine Bauchentscheidung. Wer das RFP von Anfang an so aufsetzt, dass die Antworten direkt in eine gewichtete Bewertungsmatrix fließen, spart am Ende Wochen.
RFP, Lastenheft, RFI: Was ist was und was brauchen Sie wirklich?
Im deutschen Mittelstand werden drei Begriffe oft synonym verwendet, obwohl sie unterschiedliche Phasen beschreiben. Das sorgt für Verwirrung, besonders dann, wenn Anbieter von "RFP" sprechen und der Auftraggeber "Lastenheft" schickt.
Request for Information
Erste Marktanfrage, bevor eine Shortlist besteht. Fragt Anbieter, ob sie grundsätzlich passen, ohne dass bereits ein ausformuliertes Anforderungsset vorliegt.
Wann einsetzen: Bei völlig unbekannter Softwarekategorie.
Mittelstand-Praxis: Oft übersprungen, weil die Matching Engine oder ein erster Marktüberblick diese Funktion übernimmt.
Internes Anforderungsdokument
Das interne Dokument, das beschreibt, was das System leisten soll. Vollständig aus der Kundenperspektive formuliert, ohne Einschränkung auf einen Anbieter.
Rolle: In Deutschland der etablierte Standard, aus dem Pflichtenheft und Implementierungskonzept abgeleitet werden.
Request for Proposal
Die Ausschreibung an Anbieter, die auf dem Lastenheft basiert und sie auffordert, konkret Stellung zu nehmen, zu beschreiben wie sie die Anforderungen erfüllen, was es kostet und wie die Implementierung aussieht.
Enthält: Lastenheft + Projektrahmen + Angebotsanforderung.
Was der Mittelstand wirklich braucht
Ein kombiniertes Dokument, das Anforderungen (Lastenheft-Teil), Projektkontext, Rahmenbedingungen und Anweisungen zur Angebotsstruktur zusammenführt.
Kein 80-seitiges Vergaberecht-Dokument. Ein belastbares, prüfbares Anforderungsset mit klaren Spielregeln für alle Beteiligten.
| Dokument | Wann einsetzen | Was es enthält | An wen |
|---|---|---|---|
| RFI | Vor der Shortlist | Grobe Informationsanfrage | Viele potenzielle Anbieter |
| Lastenheft | Als internes Arbeits-Dokument | Vollständige Anforderungen | Interne Stakeholder, dann Basis für RFP |
| RFP | An die Shortlist | Lastenheft + Projektrahmen + Angebotsanforderung | 3 bis 8 vorselektierte Anbieter |
Was in ein professionelles RFP gehört: Die 6 Pflicht-Bestandteile
Aus der Begleitung von über 200.000 Softwareprojekten wissen wir, welche Kapitel ein RFP braucht, damit Anbieter vergleichbare und auswertbare Antworten liefern. Was fehlt, führt zu Rückfragen, Nachbesserungen und Entscheidungsverzug.
Unternehmens- und Projektkontext
Der Anbieter muss verstehen, mit wem er es zu tun hat. Nicht als Selbstdarstellung, sondern als Einordnungshilfe: Unternehmensgröße, Branche, aktuelle Systemlandschaft (Kernaussagen aus der IT-Bestandsaufnahme), Anzahl der Nutzer, Standorte und der Ausgangspunkt des Projekts. Ein Anbieter, der ohne diesen Kontext antwortet, antwortet ins Blaue.
Projektumfang und Abgrenzung
Was gehört zum Projekt, was explizit nicht. Welche Module oder Prozesse werden in der ersten Phase eingeführt? Was ist Scope für spätere Phasen? Was läuft in der Eigenregie des Unternehmens? Klare Abgrenzung verhindert, dass Angebote völlig unterschiedliche Scope-Annahmen zugrunde legen.
Anforderungskatalog (Muss / Soll / Kür)
Das Herzstück. Strukturiert nach Muss-Anforderungen (K.O.-Kriterien), Soll-Anforderungen (gewichtete Bewertungskriterien) und Kür-Anforderungen (differenzierende Extras). Jede Anforderung mit einem prüfbaren Kriterium: nicht "Das System muss benutzerfreundlich sein", sondern "Ein ungeschulter Sachbearbeiter kann einen Standardbericht in unter 3 Minuten erstellen und als PDF exportieren." Dieses Prüfkriterium macht die spätere Demo auswertbar.
Rahmenbedingungen
Technische und organisatorische Vorgaben, die für alle Anbieter gleich gelten: Hosting-Präferenz (Cloud / On-Premise / Hybrid), DSGVO und Datenschutzanforderungen, Integrations-Anforderungen zu bestehenden Systemen (aus der IT-Bestandsaufnahme), Verfügbarkeitsanforderungen und Wartungsfenster sowie interne IT-Ressourcen für die Implementierung.
Angaben zu Kosten und Implementierung
Anbieter müssen vergleichbar antworten. Das heißt: einheitliches Format für Lizenzkosten (pro User, pro Modul, pro Standort), Implementierungskosten, Schulungskosten und laufende Kosten nach Go-Live. Wer kein strukturiertes Kostenformat vorgibt, bekommt Angebote zurück, die sich nicht addieren und nicht vergleichen lassen. Zusätzlich: Implementierungsmethodik, Zeitplan-Vorschlag und mindestens drei vergleichbare Referenzkunden.
Prozessrahmen für die Ausschreibung
Spielregeln der Ausschreibung: Frist für die Antwort, Kontaktperson für Rückfragen (ausschließlich schriftlich, damit alle Anbieter dieselben Informationen erhalten), geplanter Demo-Termin, Entscheidungszeitraum. Wer diesen Rahmen nicht definiert, bekommt Rückfragen auf verschiedenen Kanälen und verliert die Kontrolle über den Prozess.
RFP erstellen in 6 Schritten: Von der Anforderung bis zum Scoring
Anforderungen strukturiert erfassen
Bevor eine Zeile RFP geschrieben wird, müssen alle relevanten Anforderungen gesammelt sein. Nicht nur von der IT, nicht nur von der Fachabteilung, die das Projekt initiiert hat, sondern von allen Bereichen, die mit dem System arbeiten werden. In der Praxis sind das typischerweise 3 bis 6 Abteilungen.
Shortlist definieren und RFP-Empfänger festlegen
Das RFP geht nicht an alle, die sich je gemeldet haben. Die richtige Empfängeranzahl liegt bei 3 bis 8 Anbietern. Weniger als 3 sind kein Vergleich, mehr als 8 erzeugen einen Auswertungsaufwand, der intern nicht zu leisten ist.
RFP-Dokument aufsetzen
Die sechs Bestandteile (Kontext, Scope, Anforderungskatalog, Rahmenbedingungen, Kosten-/Implementierungsformat, Prozessrahmen) zu einem Dokument zusammenführen. Die Sprache ist präzise, nicht werblich, und konsequent aus Auftraggeber-Perspektive geschrieben.
RFP versenden und Rückfragen koordinieren
Alle Anbieter erhalten das RFP gleichzeitig und zur gleichen Zeit. Rückfragen laufen ausschließlich über einen definierten Kanal (schriftlich), und die Antworten gehen an alle Anbieter, damit kein Anbieter einen Informationsvorsprung erhält.
Antworten strukturiert erfassen und auswerten
Anbieter-Antworten kommen in unterschiedlicher Qualität und Vollständigkeit. Wer die Auswertung manuell in Excel macht, verbringt Tage damit, Angebote vergleichbar zu machen. Das Ergebnis ist trotzdem eine Excel-Tabelle, die der letzte war, der sie bearbeitet hat.
Nutzwertanalyse durchführen und Entscheidung dokumentieren
Auf Basis der ausgefüllten Anforderungsmatrix und der Anbieter-Antworten entsteht die Nutzwertanalyse: jede Anforderung bewertet (0 bis 3 Punkte), gewichtet nach Muss/Soll/Kür, Gesamtpunktzahl je Anbieter. Das Ergebnis ist eine nachvollziehbare, dokumentierte Entscheidungsgrundlage.
Die 6 Schritte im Detail
Die häufigsten Fehler in diesem Schritt: Anforderungen werden aus dem alten Lastenheft kopiert (inklusive aller alten Kompromisse), alles wird als Muss klassifiziert, und die Anforderungen beschreiben eine Lösung statt ein Bedürfnis. Das Selection Portal erzwingt bei jeder Anforderung ein prüfbares Kriterium und macht die Muss/Soll/Kür-Verteilung sichtbar, damit ein Ungleichgewicht sofort auffällt.
Ergebnis: Ein vollständiger Anforderungskatalog mit Quelle (Abteilung und Person), Priorität und Prüfkriterium.
Die Shortlist entsteht aus einem Matching-Prozess: Welche Anbieter erfüllen die Muss-Anforderungen prinzipiell? Welche haben nachweisbare Referenzen in der Branche und Unternehmensgröße? Die Matching Engine auf find-your-software.de liefert aus einer URL heraus in sechs Minuten eine anbieterneutrale Shortlist auf Basis von über 16.000 Systemen und 200.000 realen Projekten als Ausgangspunkt.
Ein gut strukturiertes RFP für einen mittelständischen ERP-Prozess hat typischerweise 15 bis 30 Seiten. Was zählt, ist nicht die Länge, sondern die Prüfbarkeit jeder einzelnen Anforderung. Im Selection Portal gibt es branchenspezifische RFP-Vorlagen, die direkt mit dem Anforderungsmanagement verbunden sind. Anforderungen aus dem kollaborativen Erfassungsprozess fließen automatisch in die RFP-Struktur ein, ohne manuelle Übertragung.
Was in der Praxis passiert, wenn der Versand manuell per E-Mail läuft: Anbieter erhalten unterschiedliche Dokumentversionen, Rückfragen kommen per Telefon und E-Mail durcheinander, und der Überblick geht in der ersten Woche verloren. Im Selection Portal werden alle Anbieter der Shortlist mit einem Klick eingeladen, das RFP wird direkt aus dem Portal versendet, und Rückfragen laufen strukturiert über das Portal, protokolliert und für alle Beteiligten sichtbar.
Anbieter antworten im Selection Portal strukturiert auf jede Anforderung direkt im Portal. Keine Formatkonversion, keine manuelle Übertragung. Die Antworten fließen automatisch in die Nutzwertanalyse ein. Jede Antwort ist zeitgestempelt und dem Anbieter zugeordnet. Das Team bewertet gemeinsam, jeder Stakeholder mit seinem eigenen Login.
Der Audit-Trail im Selection Portal protokolliert jede Änderung, jeden Kommentar und jede Bewertung mit Datum und Urheber. Das ist nicht nur gute Praxis, sondern bei Projekten mit GmbH-Fremdgeschäftsführung oder öffentlicher Beteiligung häufig rechtlich relevant.
Das Selection Portal: RFP-Prozess von Anfang bis Ende auf einer Plattform
Wer einen RFP-Prozess das erste Mal strukturiert durchführen will, steht vor einem Tooling-Problem: Anforderungen in Excel, RFP-Dokument in Word, Versand per E-Mail, Antworten in verschiedenen Ordnern, Scoring wieder in Excel, Entscheidungsprotokoll irgendwo im SharePoint. Jeder Medienbruch kostet Zeit und erhöht die Fehlerquote.
Kollaborativ & strukturiert
Muss/Soll/Kür-Struktur, kollaborative Erfassung durch bis zu 200 Stakeholder und erzwungene Prüfkriterien für jede Anforderung. Branchenspezifische Vorlagen als Ausgangspunkt, ergänzt durch KI-gestützte Vorschläge des eingebetteten Agenten Amatus.
Einheitlich & protokolliert
Alle Anbieter der Shortlist mit einem Klick einladen. Alle erhalten die identische Version, Rückfragen laufen strukturiert über das Portal, Antwortfristen werden automatisch überwacht.
Strukturiert & direkt
Anbieter antworten strukturiert auf jede Anforderung direkt im Portal. Keine Formatkonversion, keine manuelle Übertragung. Die Antworten fließen automatisch in die Bewertungsmatrix.
Revisionssicher & gemeinsam
Scoring direkt im Portal, gemeinsam mit dem Team. Jede Bewertung ist nachvollziehbar, jede Änderung im Audit-Trail dokumentiert, revisionssicher.
Das Selection Portal ist kostenlos nutzbar für einen ersten Überblick.
Selection Portal ansehen → Direkt mit Anforderungsmanagement startenDie 5 Fehler, die jede Softwareauswahl teurer machen als nötig
RFP ohne Prüfkriterien
Anforderungen wie "benutzerfreundliche Oberfläche", "schnelle Verarbeitung" oder "flexibel konfigurierbar" können von jedem Anbieter bejaht werden. In der Demo kann niemand widerlegen, dass das System langsam oder unflexibel ist, weil kein Prüfkriterium definiert wurde. Das Selection Portal erzwingt bei jeder Anforderung ein konkretes Prüfkriterium. Eine Demo wird damit zu einem strukturierten Test statt zu einem Verkaufsgespräch.
Alles ist ein Muss
Wenn 90 % aller Anforderungen als Muss klassifiziert sind, verliert die Priorisierung ihre Funktion. Alle Anbieter sehen gut aus, wenn sie 80 % der Muss-Anforderungen erfüllen, weil niemand weiß, welche 20 % kritisch sind. Erzwungene Priorisierung mit sichtbarer Verteilung verhindert diesen Fehler schon bei der Erfassung.
E-Mail-basierter RFP-Versand
Wer das RFP per E-Mail versendet, verliert die Kontrolle über Versionsstand, Rückfragen-Protokoll und Antwort-Eingang. Anbieter erhalten unterschiedliche Versionen, telefonische Rückfragen gehen verloren, und die Auswertung beginnt mit einem Chaos aus verschiedenen Excel-Dateien und PDF-Anhängen. Strukturierter Versand über das Portal verhindert genau das.
Nur interne Perspektive, kein Marktabgleich
Ein RFP, das ohne Marktkenntnis erstellt wird, verlangt häufig Dinge, die kein Standardsystem bietet, und vergisst Dinge, die jedes Standardsystem bietet. Wer die Anforderungsliste mit einer KI-gestützten Marktanalyse (z. B. über die Matching Engine) abgleicht, erkennt früh, ob seine Anforderungen realistisch, typisch oder außergewöhnlich sind.
Keine Entscheidungsdokumentation
Die Auswahl ist getroffen, der Vertrag unterschrieben, und drei Jahre später fragt der neue IT-Leiter, warum damals Anbieter X gewählt wurde. Niemand weiß es mehr. Fehlende Entscheidungsdokumentation ist nicht nur ein organisatorisches Problem: Bei größeren Projekten, die unter Gesellschafter-Scrutiny oder Compliance-Anforderungen stehen, kann sie haftungsrelevant werden. Der Audit-Trail im Selection Portal hält jeden Schritt automatisch fest.
Wie ein unstrukturierter RFP-Prozess 4 Monate und 180.000 Euro kostet
Ausgangslage
Ein Maschinenbauer mit 260 Mitarbeitern und 4 Fertigungsstandorten initiierte eine ERP-Auswahl ohne formalen RFP-Prozess. Der IT-Leiter versendete ein 12-seitiges Word-Dokument mit 180 Anforderungen per E-Mail an 11 Anbieter. Prioritäten waren nicht gesetzt, alle Anforderungen gleichwertig aufgelistet.
Was passierte
9 Anbieter antworteten, in 9 verschiedenen Formaten. Die Auswertung dauerte 6 Wochen und zwei Vollzeit-Personalressourcen. 3 der 9 Angebote waren unvollständig, weil Rückfragen per Telefon beantwortet und nicht protokolliert wurden. Zwei Anbieter erhielten andere Antworten als die anderen, weil ein Vertriebsmitarbeiter telefonisch "ausführlicher erklärt" hatte.
Am Ende zog das Unternehmen 4 Monate nach Versand des ursprünglichen Dokuments die Entscheidungsgrundlage in Frage und startete den Prozess teilweise neu, weil ein Vorstandsmitglied nach dem ersten Demo-Zyklus andere Prioritäten definierte. Keine dieser Änderungen war dokumentiert.
Tatsächliche Kosten des RFP-Prozesses allein (ohne Implementierung)
- Interne Personalkosten: 180.000 Euro
- Externe Beratungsunterstützung für die Neustrukturierung: 45.000 Euro
- Projektverzögerung: 4 Monate
Was eine strukturierte Alternative gebracht hätte
Anforderungserfassung kollaborativ im Selection Portal mit Muss/Soll/Kür-Verteilung, Shortlist von 5 Anbietern statt 11, strukturierter Versand mit einheitlichem Antwortformat, automatisches Feedback-Management. Geschätzter Zeitbedarf: 3 Wochen RFP-Erstellung, 2 Wochen Antwortfrist, 1 Woche Auswertung. Personalaufwand: 40 % weniger.
Lehre: Ein professionell aufgesetzter RFP-Prozess ist keine Zeitinvestition, er verhindert Zeitverlust im Auswahlprozess und teure Entscheidungskorrekturen nach Vertragsschluss.RFP-Checkliste: Das müssen Sie vor dem Versand geprüft haben
- Unternehmenskontext vollständig (Größe, Branche, Standorte, aktuelle Systemlandschaft)
- Projektumfang und Abgrenzung klar definiert
- Alle Anforderungen nach Muss / Soll / Kür priorisiert
- Keine Anforderung ohne konkretes Prüfkriterium
- Keine Anforderung, die eine Lösung statt ein Bedürfnis beschreibt
- Technische Rahmenbedingungen vollständig (Hosting, Schnittstellen, DSGVO)
- Einheitliches Kosten- und Implementierungsformat vorgegeben
- Referenzanforderungen formuliert (Branche, Unternehmensgröße, Projekttyp)
- Shortlist auf 3 bis 8 Anbieter begrenzt
- Alle Anbieter erhalten gleichzeitig und gleichlautend dieselbe Version
- Rückfragen-Kanal definiert (schriftlich, ein Ansprechpartner)
- Rückfragen-Antworten gehen an alle Anbieter
- Antwortfrist klar kommuniziert (typisch: 2 bis 3 Wochen)
- Folgeprozess kommuniziert (wann Demo, wann Entscheidung)
- Einheitliches Antwortformat vorgegeben (nicht PDF-Freitext)
- Bewertungsmatrix vorbereitet (Nutzwertanalyse mit Gewichtung)
- Stakeholder für das Scoring definiert und eingeladen
- Dokumentationsformat für die Entscheidung festgelegt (Audit-Trail)
Häufige Fragen zum RFP erstellen
RFP strukturiert aufsetzen und direkt im Selection Portal starten
Vermeiden Sie E-Mail-Chaos, Excel-Wirrwarr und undokumentierte Entscheidungen. Das Selection Portal führt Sie durch den gesamten RFP-Prozess: von der kollaborativen Anforderungserfassung über den strukturierten Versand bis zur revisionssicheren Nutzwertanalyse.