B2B-RFP-Checkliste für Softwareentwicklung-Lieferanten

Ein RFP für Softwareprojekte sollte Problem, funktionale und nicht funktionale Anforderungen, Sicherheits- und Datenbedarfe, kommerzielle Konditionen und das Bewertungsverfahren benennen, bevor Softwareentwicklung-Lieferanten antworten. Gewichten Sie die Kriterien und bewerten Sie danach, statt hinterher zu streiten, prüfen Sie Referenzen statt den Fallstudien zu glauben und fahren Sie vor jeder Budgetbindung einen kurzen bezahlten Piloten.

Was muss ein RFP für die Softwareentwicklung enthalten?

Das Dokument dient dazu, Antworten vergleichbar zu machen. Ein Lieferant kann nur auf das antworten, was geschrieben steht; ein RFP, das eine Vision beschreibt und einen Preis erfragt, lädt Angebote ein, die alle hervorragend klingen und die sich gegeneinander nicht bewerten lassen. Der funktionale Inhalt, die Rahmenbedingungen und die Bewertungsregel müssen feststehen, bevor die erste Antwort eintrifft, sonst wird die Bewertung zu einer Verhandlung über Kriterien.

Es gibt außerdem einen Reihenfolgenpunkt, der Monate spart: Im RFP entdeckt man nicht, was man braucht. Anforderungen entstehen aus interner Arbeit — die Prozessverantwortlichen beschreiben, wie das Geschäft tatsächlich läuft, die Finanzen sagen, was abgestimmt sein muss, die Menschen, die das System täglich benutzen, benennen den heutigen Schmerzpunkt. Diese Arbeit ist langsam und politisch, und sie geschieht, bevor ein Lieferant überhaupt involviert ist. Teams, die sie dem ersten Lieferanten überlassen, bekommen Anforderungen in der Produktsprache dieses Lieferanten geschrieben — und dadurch sieht jedes andere Angebot wie eine schlechte Passung aus, nicht weil es eine ist, sondern weil der Maßstab um einen der Bieter herum geschrieben wurde.

Eine Unterscheidung lohnt sich zudem zwischen drei Dokumenten, die oft verwechselt werden. Ein RFI fragt den Markt, was es gibt; es ist kurz, es kommt vor den Anforderungen und verpflichtet niemanden. Ein RFP bittet um ein Angebot entlang definierter Anforderungen und eines genannten Bewertungsverfahrens. Ein RFQ fragt einen Preis für einen definierten Umfang. Ein RFQ, bevor es den Umfang gibt, ist der häufigste Weg, drei Zahlen zu vergleichen, die drei verschiedene Dinge bedeuten.

Fünf Dinge, die ein vollständiges RFP kann und ein unvollständiges nicht:

• Definiert das Problem, nicht die Lösung. „Die Zeit für den monatlichen Konsolidierungsbericht von mehreren Tagen auf eine festgelegte Stundenzahl senken“ ist eine Problemdefinition; „Bauen Sie uns ein Data Warehouse“ ist ein Lösungsgeraten, das das Problem womöglich nicht löst.


• Trennt Anforderungen von Vorlieben. Muss-Funktionen, die über ein Bestehen entscheiden, Soll-Funktionen, die über die Rangfolge entscheiden, und Kann-Funktionen, über die nichts entschieden wird. Ernsthaft antworten Lieferanten nur, wenn diese Unterscheidung sichtbar ist.


• Benennt die Rahmenbedingungen. Bestehende Systeme, die angebunden werden müssen, Daten, die migrieren müssen, Prüf- und Aufbewahrungspflichten, das Go-live-Fenster, wer freigibt.


• Nennt das Bewertungsverfahren vorab. Gewichtete Kriterien, wer bewertet, welche Nachweise verlangt werden und wann nicht berücksichtigte Lieferanten eine Zusammenfassung ihrer Punkte erhalten.


• Legt die Termine des Verfahrens fest. Frist für Fragen, Klärungsfenster, Einreichfrist, Bewertungszeitraum, Entscheidungsdatum. Ein Verfahren ohne Termine zieht Lieferanten an, die ohnehin ausgelastet sind.

Aufbau eines RFP

Funktionale und nicht funktionale Anforderungen an die Softwareentwicklung

Funktionale Anforderungen beschreiben, was das System tut: welche Prozesse, für welche Rollen, mit welchen Ergebnissen. Nicht funktionale Anforderungen beschreiben, wie gut es das tut — und genau die fehlen am häufigsten; entweder werden sie später teuer erzwungen oder gar nicht.

In den meisten B2B-Projekten lohnt es sich, sie ausdrücklich zu benennen:

• Leistung. Antwortzeiten unter einer genannten Last für die Vorgänge, die zählen — Auftragserfassung, Berichtserstellung, Monatsabschluss.


• Verfügbarkeit. Welche Ausfallfreiheit das Geschäft braucht, Wartungsfenster und was passiert, wenn das System steht — ein Ziel ohne Beschreibung der akzeptablen Ausfallzeit ist keine Anforderung.


• Wiederherstellung. RTO und RPO in einfacher Sprache: wie schnell der Betrieb nach einem Vorfall weiterläuft und wie viel Arbeit verloren gehen darf. Beide Zahlen gehören in die Bewertung und nicht nur in den Vertrag.


• Prüfpfad. Wer was wann geändert hat, wie lange es aufbewahrt wird und wer es abrufen kann — besonders dort, wo Geld, Bestand oder personenbezogene Daten bewegt werden.


• Zugänglichkeit und Bedienung. Wer das System benutzt, auf welchen Geräten, in welchen Sprachen; ein System, das das Lager nicht bedienen kann, ist nicht eingeführt, egal wie gut es abschneidet.


• Integration und Daten. Welche Systeme verbunden werden, in welche Richtung die Daten fließen und wem der Stammsatz je Objekt gehört.

Fragen zu Sicherheit und Compliance

Besser stellt man Sicherheit als Fragen mit verlangten Nachweisen, statt sie als Ja-Nein-Zeile abzufragen. Die Fragen, die hineingehören:

• ISO/IEC 27001 — besitzt der Lieferant es, und was deckt der zertifizierte Geltungsbereich ab? Ein Zertifikat, das die Vertriebsorganisation und nicht die Lieferteams erfasst, sagt etwas ganz Bestimmtes aus.


• Sichere Entwicklung — wo Sicherheit in Entwurf, Code-Review und Test sitzt und ob der Umgang mit Abhängigkeiten und Schwachstellen Routine ist.


• OWASP Top 10 — ob es Teil des Reviews webnaher Bestandteile ist; eine konkrete, beantwortbare Frage.


• Zugriffskontrolle — wer auf Ihre Umgebungen und Daten gelangt, wie Zugriff gewährt und entzogen wird und welche Protokollierung es gibt.


• Datenschutzpflichten — KVKK und DSGVO, wo sie gelten; wer Verantwortlicher, wer Verarbeiter ist und was der Auftragsverarbeitungsvertrag zu Unterauftragsverarbeitern und zur Meldung von Datenpannen sagt.

Konditionen und SLAs

Verlangen Sie Preise in einer Struktur, die sich vergleichen lässt: was enthalten ist, was separat berechnet wird und wie Änderungen bepreist werden. Eine einzelne Zahl ohne dahinterstehenden Umfang lässt sich nicht mit einer anderen einzelnen Zahl vergleichen; die Seite zu Kosten- und Preismodellen erklärt die üblichen Strukturen und die Fragen, die jede davon aufwirft.

SLAs verdienen dieselbe Präzision wie Anforderungen. Ein Verfügbarkeitsprozentsatz ist nur mit Messmethode, Ausnahmen und Abhilfe sinnvoll; eine Reaktionszeit nur mit Schweregraddefinitionen und Geschäftszeiten. Lassen Sie jeden Lieferanten die Begriffe im SLA selbst definieren, statt eine Seite voller Prozentzahlen ohne Definitionen zu akzeptieren.

Bewertungsmatrix

Eine kopierbare Vorlage. Die Gewichtungen unten sind ein Beispiel — setzen Sie Ihre eigenen gemäß Ihren Prioritäten und halten Sie die Gesamtsumme bei 100. Definieren Sie, was 1, 3 und 5 bedeuten, bevor jemand bewertet, nicht erst, wenn die Streitgespräche begonnen haben.

Zwei Disziplinen machen das funktionsfähig. Zuerst unabhängig bewerten, bevor diskutiert wird, damit die erste selbstsichere Stimme den Raum nicht bestimmt. Und je Punkt eine Begründung in einem Satz festhalten — Lieferanten, die eine Punktzusammenfassung mit Gründen erhalten, akzeptieren das Ergebnis deutlich leichter, und das eigene Team kann es sechs Monate später vertreten.

Eine dritte Disziplin betrifft, wer bewertet. Im Gremium sitzen die Menschen, die mit dem Ergebnis leben — der Prozessverantwortliche, die Person für die Daten, jemand aus Sicherheit oder Finanzen, falls es diese Funktionen gibt —, nicht nur der Einkauf. Bewertungen scheitern im Stillen, wenn das Gremium das bewertet, was es beurteilen kann (die Struktur des Angebots, den Feinschliff des Vertriebsteams), und das aufschiebt, was es nicht beurteilen kann (ob das Integrationsvorgehen wirklich zu den bestehenden Systemen passt). Eine technische Person mit dem Recht zu sagen „Das funktioniert nicht mit dem, was wir betreiben“, verhindert mehr Kosten als jeder Rabatt.

Die Gewichtungen selbst verdienen noch eine Warnung: Sie sind eine Prioritätenaussage, die für Lieferanten sichtbar wird. Wenn Sicherheit mit 5 % und der Preis mit 30 % gewichtet sind, bemerken das ernsthafte, sicherheitsorientierte Lieferanten — und das eigene Team bemerkt es, wenn der Vertrag unterschrieben wird. Eine in Eile gesetzte Gewichtung, nur um die Tabelle zu füllen, wird von allen außerhalb des Raums als Wahrheit gelesen; setzen Sie sie einmal, mit den Entscheidern im Raum, und ändern Sie sie nur mit derselben Förmlichkeit, mit der Sie sie gesetzt haben.

Referenzprüfung und Pilotprojekt

Fallstudien sind Marketing; Referenzgespräche sind Belege. Das Gespräch, das funktioniert, ist kurz und fragt, was passiert ist, nicht was geliefert wurde: Wurde das Projekt fertig, was hat sich im Umfang geändert, wer war tatsächlich im Team, was würden sie anders machen und würden sie das Projekt mit diesem Lieferanten erneut starten? Vergangenheitszeit und konkrete Antworten sind das Signal.

Verlangen Sie eine Referenz aus einem Projekt, das Ihrer Größe und Komplexität gleicht, nicht die stolzeste Arbeit des Lieferanten — eine Flaggschiff-Einführung in doppeltem Budget lehrt wenig darüber, wie sich das Team in Ihrer Größenordnung verhält. Und prüfen Sie die Referenz selbst: Ein Kontakt, den der Lieferant vorab einweiht, ist eine Empfehlung, keine Referenz; das nützliche Gespräch ist das, in dem der Kunde vor Ort erfährt, was Sie fragen.

Ein kurzer bezahlter Pilot prüft anschließend den Teil, den keine Referenz prüft: wie dieses Team mit Ihren Leuten arbeitet, wenn die Anforderungen unvollständig sind. Die Gestaltungsregeln sind dieselben, die sich für jeden Piloten lohnen — echte Arbeit, schriftliche Abnahmekriterien, eine Änderung mitten drin und eine vorher vereinbarte Entscheidungsregel. Die Seite zum IT-Outsourcing behandelt die Pilotgestaltung genauer.

Prüfbare Vertragsklauseln

• Rechteübertragung — Rechte an Code, Dokumentation und Ableitungen gehen auf Sie über, ab der Entstehung, nicht erst mit der Schlusszahlung.
• Eigentum an Daten — Ihre Daten bleiben Ihre; die Rechte des Lieferanten sind auf das beschränkt, was zur Lieferung nötig ist.
• Abnahme — was Abnahme bedeutet, wer sie erklärt und welcher Prozess greift, wenn etwas sie nicht besteht.
• Änderungssteuerung — wie Umfangsänderungen angefordert, bepreist und freigegeben werden; ohne sie wird jede Änderung zum Streit.
• Exit und Übergabe — Quellcode, Zugänge, Dokumentation und Unterstützung am Ende; wie Wissen weitergeht, wenn der Lieferant wechselt.
• Escrow — wo die Geschäftskontinuität von Komponenten abhängt, die beim Lieferanten liegen, und was passiert, wenn dieser nicht weiterarbeiten kann.
• Haftung — Obergrenzen, Ausschlüsse und was nicht versichert ist; lesen Sie sie mit derselben Aufmerksamkeit wie den Preis.
• Kündigung — Kündigungsfristen, Pflichten nach der Kündigung und das Verfahren zur Rückgabe oder Löschung der Daten.

Häufig gestellte Fragen

Sollten wir zuerst ein RFI oder ein RFP senden?

Ein RFI, wenn Markt oder Problem unklar sind — dann fragen Sie, was es gibt und was es kostet. Ein RFP, wenn die Anforderungen und das Bewertungsverfahren feststehen; wer ihn früher verschickt, verlagert nur die Anforderungsarbeit in jedes Angebot des Lieferanten, in dessen Worten und mit dessen Prioritäten.

Wie viele Lieferanten sollten wir einladen?

So wenige, dass Sie jedes Angebot richtig lesen und jede Referenz anrufen können. Die meisten Bewertungen verlieren jenseits einer Handvoll an Qualität; eine Vorauswahl aus einem RFI, einem Sichtungsgespräch und einem vergleichbaren Referenzprojekt ist meist nützlicher als eine lange Liste berühmter Namen.

Wie sollten Gewichtungen festgelegt werden?

Aus Ihren Prioritäten, bevor Sie ein Angebot sehen, und vereinbart zwischen den Menschen, die mit dem Ergebnis leben. Ein häufiger Fehler sind gleichgewichtete Kriterien überall — eine Art zu sagen, dass nichts wichtiger ist als alles andere; wenn Preis oder Risiko für Sie dominieren, sollten die Gewichtungen das aussagen.

Soll der Preis bewertet werden?

Ja, aber als ein gewichtetes Kriterium mit festgelegtem Umfang, nicht als die gesamte Bewertung. Ein ohne Umfang bewerteter Preis belohnt den Lieferanten, der für sich am wenigsten Arbeit annimmt; bepreisen Sie zuerst Ihre Anforderungen und vergleichen Sie dann die Summen für dasselbe.

Wie bewerte ich Antworten zur Sicherheit?

Anhand von Nachweisen, nicht am Ton. Drei Stufen funktionieren: keine Haltung (1), beschriebene Richtlinien (3), geprüfter Geltungsbereich des Zertifikats samt Beschreibung der sicheren Entwicklung und gelieferten Nachweisen (5). Wo ein Lieferant kein Zertifikat besitzt, fragen Sie, welche gleichwertigen Kontrollen es schriftlich gibt — ein ehrliches Nein mit dokumentierten Kontrollen punktet besser als ein nicht überprüfbares Ja.

Können wir die Anforderungen nach dem RFP ändern?

Vor der Einreichung ja — mit Ankündigung an alle. Nach der Einreichung nur über eine formale Klärung, die alle Bieter erhalten; Anforderungen still für einen Lieferanten zu ändern, beendet die Vergleichbarkeit, auf der das ganze Verfahren aufbaut. Nach dem Vertrag dafür gibt es die Änderungssteuerung.

Quellen und Standards

• ISO — Herausgeber von ISO/IEC 27001 (Informationssicherheits-Managementsystem); aktuelle Ausgabe und Geltungsbereich eines Zertifikats prüfen, bevor man sich darauf stützt.
• OWASP — Herausgeber der Top-10-Liste der häufigsten Sicherheitsrisiken bei Webanwendungen, die auf dieser Seite genannt wird.
• Die Prinzipien der Bewertungsmatrix folgen veröffentlichter RFP-Vorlagenpraxis; die gezeigten Gewichtungen sind ein zum Bearbeiten gedachtes Beispiel, keine Empfehlung. Diese Seite ist Einkaufsleitfaden, keine Rechtsberatung, und für WorldwideTradeX wird keine Zertifizierung oder Prüfung behauptet.

Verwandte Seiten

Softwareentwicklung · IT-Outsourcing aus der Türkei · Kosten- und Preismodelle · IT-Audit und Beratung · Angebot anfordern