RFI, RFP oder RFQ: So wählen Sie einen Dienstleister für Ihren Onlineshop

RFI, RFP oder RFQ sollten Sie nicht nach der Höhe des Budgets auswählen, sondern danach, was Sie über Ihren künftigen Onlineshop noch nicht wissen. Sind die Möglichkeiten am Markt unklar, benötigen Sie Informationen. Steht das Ergebnis fest, ist der Weg dorthin aber noch offen, benötigen Sie Lösungsvorschläge. Sind Leistungsumfang und Bedingungen bereits abgestimmt, können Sie vergleichbare Preise anfragen.

Ein Fehler entsteht, wenn ein Unternehmen mehrere Teams bittet, „einen Shop mit ERP-Anbindung zu kalkulieren“, und anschließend die Gesamtsummen vergleicht. Ein Team berücksichtigt nur die Übertragung von Bestellungen, ein anderes zusätzlich Lagerbestände, Retouren und die Wiederherstellung nach Ausfällen. Der Preisunterschied spiegelt dann unterschiedliche Annahmen zum Umfang wider, nicht die unterschiedliche Effizienz der Entwickler. Die richtige Anfrage muss diese Annahmen vor dem Vertragsabschluss sichtbar machen.

1. Beginnen Sie mit den offenen Fragen, nicht mit dem Namen des Dokuments

Halten Sie gemeinsam mit den Verantwortlichen für Vertrieb, Marketing und das Warenwirtschaftssystem fest, was der Shop verändern soll: Händlern individuelle Preise anbieten, die manuelle Übertragung von Bestellungen überflüssig machen oder mehrere Lager unterstützen. Trennen Sie bekannte Fakten, Wünsche und unbeantwortete Fragen voneinander.

Für die Anzeige des Lagerbestands müssen Sie beispielsweise klären, welches System die Reservierungen verwaltet, wie aktuell die Daten sein müssen und was Käufer bei einem Ausfall sehen. Solange das unbekannt ist, vermittelt eine feste Kostenkalkulation eine falsche Genauigkeit. Zunächst ist eine Analyse erforderlich.

2. Worin sich RFI, RFP und RFQ unterscheiden

RFI steht für Request for Information – eine Informationsanfrage; RFP für Request for Proposal – eine Anfrage nach Lösungsvorschlägen; RFQ für Request for Quotation – eine Preisanfrage. In den Leitlinien von New Zealand Government Procurement hängt diese Unterscheidung mit dem Beschaffungsziel zusammen: den Markt erkunden, einen Weg zum gewünschten Ergebnis erhalten oder eine bereits festgelegte Leistung kalkulieren lassen. Die folgenden Empfehlungen sind eine praktische Anpassung für privatwirtschaftliche Unternehmen in der Ukraine und kein verbindliches ausländisches Verfahren.

Diese drei Verfahren müssen nicht zwingend nacheinander durchgeführt werden. Wenn Markt und Aufgabe klar sind, können Sie direkt mit einem RFP beginnen. Sind alle wesentlichen Bedingungen bereits festgelegt, ist ein RFQ möglich. Selbst ein hohes Budget macht eine Anfrage nach Lösungsvorschlägen nicht automatisch notwendig, und ein kleines beseitigt keine technischen Unklarheiten.

3. RFI: Gewinnen Sie das Wissen, das Ihnen als Auftraggeber fehlt

Ein kurzer RFI ist sinnvoll, wenn Sie nicht wissen, ob eine Standardlösung ausreicht oder eine individuelle Entwicklung erforderlich ist. Beschreiben Sie das Vertriebsmodell, die Käuferrollen, die bestehenden Systeme, den Zustand des Produktkatalogs und die Rahmenbedingungen für den Start. Bitten Sie um eine Erläuterung möglicher Ansätze, ihrer jeweiligen Kompromisse, der benötigten Zugänge und der Aspekte, die sich ohne Analyse nicht kalkulieren lassen. Ein grober Budgetrahmen kann besprochen werden, ersetzt aber keine spätere Kostenkalkulation.

Fragen Sie nach Grenzen, nicht nach der Anzahl der Funktionen

Fragen Sie statt „Binden Sie ERP-Systeme an?“ lieber: „Welche Daten und Dokumentationen benötigen Sie, um den Austausch von Preisen, Lagerbeständen und Bestellungen zu kalkulieren?“ Statt „Ist das System skalierbar?“ fragen Sie: „Welche Lastparameter müssen vor der Wahl der Architektur gemessen werden?“ Eine hilfreiche Antwort benennt Bedingungen und offene Fragen, statt einfach alle Wünsche zu bestätigen.

Das Ergebnis eines RFI sind ein präzisiertes Briefing, Alternativen und eine Liste erforderlicher Prüfungen. Stellen Sie klar, dass es sich um eine Erkundung handelt, nicht um die Auswahl eines Gewinners. Eine detaillierte Konzeption oder ein Prototyp erfordern einen gesondert vereinbarten Leistungsumfang und sollten nicht kostenlos im Rahmen der Antwort erbracht werden.

4. RFP: Machen Sie unterschiedliche Lösungen vergleichbar

Geben Sie im RFP einen gemeinsamen Kontext vor, lassen Sie aber Raum für begründete Alternativen. Erforderlich sind Ziele, der Umfang der ersten Ausbaustufe, die wichtigsten Szenarien, eine Systemübersicht, Anforderungen an die Datenmigration und Abnahmekriterien. Kennzeichnen Sie verbindliche Anforderungen getrennt von Wünschen. Steht die Technologie noch nicht fest, bitten Sie um eine Begründung der Auswahl; steht sie fest, nennen Sie die tatsächliche Rahmenbedingung und nicht nur den Namen der Plattform.

Ein einheitliches Antwortformat für alle Teams

Erstellen Sie eine Matrix mit folgenden Angaben: Anforderungskennung, Art der Umsetzung, im Preis enthaltene Leistungen, Abhängigkeiten vom Auftraggeber, Ausschlüsse und Erfüllungsnachweis. Bei einer Funktion muss die Antwort zwischen einer bereits vorhandenen Funktion, Konfiguration, individueller Entwicklung und einem externen Dienst unterscheiden. Die Formulierung „wird unterstützt“ verbirgt ohne diese Präzisierungen spätere Kosten.

Bitten Sie darum, den Preis nach Analyse, Design, Entwicklung, Integrationen, Migration, Tests, Inbetriebnahme und Support aufzuschlüsseln. Trennen Sie den Basisumfang von optionalen Leistungen. Vereinbaren Sie für laufende Kosten einen einheitlichen Vergleichszeitraum, eine gemeinsame Währung sowie einheitliche Annahmen zu Steuern und zum Nutzungsumfang der Dienste.

Legen Sie die Bewertungskriterien fest, bevor die Antworten eingehen: Abdeckung kritischer Szenarien, Qualität der Nachweise, Beherrschbarkeit der Integrationen, Team, Support und Gesamtkosten. Wählen Sie die Gewichtung entsprechend Ihren eigenen Risiken, nicht nach einer universellen Formel. Geben Sie Fragen der Teilnehmer und allgemeine Präzisierungen der Anforderungen in gleicher Fassung an alle weiter, ohne vertrauliche Geschäftsinformationen anderer offenzulegen.

Prüfen Sie gesondert, wer die Arbeiten tatsächlich ausführen wird, wie Änderungen abgestimmt werden und wer für Drittanbieter verantwortlich ist. Informationen über das Unternehmen GL.ua (Глянець) liefern ebenso wie die Unternehmensseite eines anderen Kandidaten einen Kontext, ersetzen aber nicht die Prüfung des konkreten Teams und seines Angebots.

5. RFQ: Fragen Sie Preise nur für klar abgegrenzte Leistungen an

Für einen RFQ benötigen Sie ein einheitliches Ergebnis, eine Spezifikation, Testdaten und Abnahmeregeln. Wenn jedes Team die Rabattlogik oder den Umfang der Migration selbst festlegt, werden die Preise nicht vergleichbar sein.

Geben Sie die Version der Spezifikation an. Bitten Sie um Angaben zur Gültigkeitsdauer des Preises, zu Ausschlüssen, Zahlungsbedingungen, Abhängigkeiten von Zugängen und zum Verfahren bei Änderungen des Leistungsumfangs. Klären Sie, ob Fehlerbehebung, Bereitstellung, Dokumentation und Übergabe des Ergebnisses enthalten sind.

Wenn die Teilnehmer statt eines Preises Rückfragen liefern, präzisieren Sie den Leistungsumfang oder lagern Sie die ungeklärte Komponente in eine gesonderte Analyse aus. Ein RFQ kann sich auf einen definierten Teil der Arbeiten beziehen, nicht nur auf den gesamten Shop.

6. Prüfen Sie eine risikoreiche Integration vor dem Hauptvertrag

Die Präsentation eines fertigen Shops zeigt die Benutzeroberfläche, belegt aber nicht die Zuverlässigkeit des Datenaustauschs mit Ihrem Warenwirtschaftssystem. Vereinbaren Sie für das risikoreichste Szenario eine klar begrenzte technische Prüfung: einen Prototyp, einen Test des Datenaustauschs oder eine Analyse der tatsächlichen Dokumentation. Das ist eine eigenständige Leistung mit einem definierten Ergebnis, Zugängen und Abschlusskriterien, keine Aufforderung, kostenlos einen Teil des Produkts zu entwickeln.

1. Wählen Sie einen kritischen Datenfluss: Artikel und Preis aus dem Warenwirtschaftssystem, Bestellung aus dem Shop, Zahlungsbestätigung und Statusänderung. Benennen Sie für jeden Datentyp die verantwortliche Stelle.
2. Stellen Sie eine Testumgebung, die Dokumentation der API – der Schnittstelle für den Datenaustausch zwischen Systemen – und anonymisierte Beispiele bereit. Prüfen Sie Berechtigungen und Begrenzungen der Anfragehäufigkeit.
3. Halten Sie das erwartete Ergebnis für den Normalfall, einen Fehler, eine Verzögerung und eine wiederholte Nachricht fest. Legen Sie fest, wie sich die Datensätze auf beiden Seiten abgleichen lassen.
4. Simulieren Sie einen Verbindungsabbruch und eine erneute Übertragung. Prüfen Sie, ob doppelte Bestellungen oder Reservierungen entstanden sind und wie die zuständige Person vom Fehler erfahren hat.
5. Lassen Sie sich ein Prüfprotokoll, eine Liste der Einschränkungen und eine Schlussfolgerung vorlegen: bestätigt, Änderung des Ansatzes erforderlich oder Daten unzureichend. Aktualisieren Sie die Schätzung und die Abnahmekriterien.

Der Schutz davor, dass ein Vorgang mehrfach ausgeführt wird, heißt Idempotenz. So beschreibt beispielsweise die Stripe-Dokumentation zu wiederholten API-Anfragen den Einsatz eines Schlüssels, mit dem sich ein Vorgang sicher wiederholen lässt. Das ist ein Beispiel für einen Mechanismus und kein Beleg dafür, dass Ihr ERP denselben Schutz bietet: Das Verhalten der konkreten Integration muss gesondert geprüft werden.

Auch Sicherheit erfordert Nachweise

Der Software Acquisition Guide der CISA behandelt die Bewertung der Praktiken eines Anbieters über den gesamten Softwarelebenszyklus hinweg. Für einen Shop betreffen die praktischen Fragen Zugänge, Abhängigkeiten, Updates und den Umgang mit Schwachstellen. Das ist ein hilfreicher Rahmen für das Gespräch, keine Verpflichtung, US-amerikanische Behördenverfahren einzuhalten.

Vereinbaren Sie statt „Die Website muss sicher sein“, wer Rollenberechtigungen, den Schutz des administrativen Zugangs und die Wiederherstellung aus einer Sicherungskopie prüft. OWASP ASVS kann als Grundlage für konkrete Prüfanforderungen dienen. Benennen Sie die Version, die anwendbaren Anforderungen und die Nachweise; ein bloßer Verweis auf den Standard belegt noch keine Konformität.

7. Kalkulieren Sie Termine, Kosten und den Preis offener Fragen

Der Zeitplan hängt nicht nur von den Entwicklern ab. Einfluss haben auch die Einsatzbereitschaft des Produktkatalogs, die Designfreigabe, der ERP-Zugang, die Mitwirkung des Zahlungsdienstleisters, die Datenbereinigung und die Verfügbarkeit der Mitarbeiter des Auftraggebers. Fordern Sie einen Plan mit Abhängigkeiten und Verantwortlichen: Was kann parallel erfolgen, was blockiert die nächste Phase und wann wird die Schätzung erneut geprüft? Ein pauschaler Termin ohne diese Bedingungen hilft wenig dabei, den Start zu steuern.

Vergleichen Sie nicht nur die Erstellung, sondern auch die Kosten über die gesamte Nutzungsdauer des Shops. Weisen Sie in der Kalkulation Geschäftsanalyse, Konzeption, Design, Entwicklung, Datenaustausch, Migration, Prüfungen und Schulung gesondert aus. Zu den laufenden Kosten gehören Infrastruktur, kostenpflichtige Dienste, Monitoring, Updates und Support. Klären Sie, welche Zahlungen von Bestellungen, Nutzern oder Datenmengen abhängen und wer die Verträge mit diesen Diensten abschließt.

Bitten Sie bei noch ungeklärten Arbeiten nicht um einen versteckten Aufschlag, sondern um eine Erklärung: Was genau ist unbekannt, wie lässt es sich klären und wann wird die Schätzung angepasst? Ein Festpreis beseitigt keine unklaren Anforderungen, und eine Abrechnung nach Stunden hebt die Budgetkontrolle nicht auf. Beide Modelle benötigen klare Grenzen, Berichte und ein Verfahren zur Freigabe von Änderungen. Prüfen Sie kaufmännische und rechtliche Bedingungen mit den zuständigen Fachleuten; dieser Artikel ist keine Rechtsberatung.

8. Entscheiden Sie nach geprüften Ergebnissen, nicht nach Versprechen

Kehren Sie vor der endgültigen Entscheidung zur Anforderungsmatrix zurück. Ein unvertretbares Risiko bei einer kritischen Integration sollte nicht durch ein ansprechenderes Design oder einen niedrigeren Preis aufgewogen werden. Zugleich beweist ein Prototyp nicht, dass der gesamte Shop für Spitzenlasten bereit ist: Er klärt lediglich eine bestimmte offene Frage. Die übrigen Szenarien benötigen eigene Prüfungen während der Entwicklung und Inbetriebnahme.

Halten Sie vereinbarte Präzisierungen im Leistungsumfang fest, statt sie nur in der Korrespondenz zu belassen. Definieren Sie Abnahmekriterien, Verantwortliche für Daten und Zugänge sowie Regeln für Support und die Übergabe von Code, Dokumentation und Konfigurationen. Geben Sie den Teilnehmern für die Kalkulation keine Passwörter für Produktivsysteme oder vollständige Kundendatenbanken. Verwenden Sie für die erste Prüfung eingeschränkte Zugänge und anonymisierte Daten.

Ein gutes Auswahlergebnis ist nicht der längste RFP, sondern ein Angebot, aus dem der umsetzbare Leistungsumfang, bestätigte Fähigkeiten und verbleibende Risiken hervorgehen. Wenn Sie einen neuen Shop oder eine Migration vorbereiten, besprechen Sie die Entwicklung Ihres Onlineshops mit GL.ua: Übermitteln Sie Ihre Geschäftsszenarien, eine Systemübersicht und offene Fragen, damit das Gespräch mit der tatsächlichen Aufgabe beginnt und nicht mit unvergleichbaren Preisen.