Enterprise-Entscheidung
Shopify Plus RFP: So werden Agenturangebote wirklich vergleichbar
Aktualisiert
Ein gutes Shopify-RFP beschreibt nicht jede spätere Lösung, sondern schafft vergleichbare Ausgangsbedingungen. Es trennt Ziele von Vorgaben, dokumentiert Systeme und Daten, nennt kritische Prozesse, definiert Abnahme und Betrieb und verlangt von jedem Anbieter dieselben Annahmen. Damit werden Unterschiede in Architektur, Team und Risiko sichtbar statt nur Unterschiede im Preis.
Diese Checkliste richtet sich an Replatformings und größere Relaunches. Für ein einzelnes Theme-Modul oder einen kleinen Optimierungssprint ist ein RFP meist unnötig schwer.
Was muss vor dem Versand des RFP feststehen?
Vor dem Dokument steht eine interne Entscheidung: Welches Geschäftsergebnis soll sich verändern? Ein RFP ohne Ziel führt zu Funktionslisten, die niemand priorisieren kann. Umsatz, Märkte, Betriebskosten, Release-Geschwindigkeit oder B2B-Fähigkeit müssen als konkrete Zielrichtung benannt sein.
Ebenso wichtig ist ein realistischer Entscheidungsrahmen. Budgetkorridor, gewünschter Launch, verfügbare interne Rollen und Systeme mit fixen Vertragsgrenzen beeinflussen die Lösung. Werden diese Punkte verschwiegen, kalkuliert jeder Anbieter ein anderes Projekt.
Welche Informationen gehören in den technischen Ausgangspunkt?
Beschreibe Plattform, Stores, Märkte, Kataloggröße, Bestellvolumen und alle angebundenen Systeme. Für ERP, PIM, WMS, CRM und Finance reicht der Produktname nicht: relevant sind Datenobjekte, Richtung, Frequenz, führendes System und bekannte Ausnahmen.
Custom-Funktionen brauchen Beispiele aus dem echten Betrieb. Die Aussage „komplexe Preislogik“ ist nicht prüfbar. Konkrete Beispiele für Firmenkunden, Preislisten, Freigaben und Retouren zeigen dagegen, was eine Architektur tatsächlich leisten muss.
| Bereich | Benötigte Information | Warum sie zählt |
|---|---|---|
| Storefront | Themes, Märkte, Sprachen, Domains | Bestimmt Architektur und Rollout |
| Katalog | Produkte, Varianten, Medien, Metafelder | Bestimmt Mapping und Import |
| Commerce | B2B, POS, Subscriptions, Bundles | Bestimmt Plattform- und App-Scope |
| Systeme | ERP, PIM, WMS, CRM, Finance | Bestimmt Integrationsarbeit |
| SEO | Indexierte URLs, Rankings, Redirect-Historie | Bestimmt Migrationsrisiko |
| Betrieb | Release, Support, Monitoring, Rollen | Bestimmt das Modell nach Launch |
Wie formulierst Du Anforderungen ohne die Lösung vorzugeben?
Formuliere zuerst das Ergebnis und den Rand. Statt Wir benötigen App X lautet die Anforderung: Das Merchandising-Team muss Regeln ohne Deployment pflegen können; Änderungen müssen versioniert und innerhalb von zehn Minuten sichtbar sein.
Technische Vorgaben gehören nur dort hinein, wo sie echte Unternehmensgrenzen sind: bestehende Verträge, Security-Anforderungen, Datenstandorte, Identity, vorhandene APIs oder ein verbindliches Betriebsmodell. Alles andere sollte der Anbieter begründen dürfen.
Jede kritische Anforderung braucht
- einen fachlichen Zweck
- einen realen Beispielprozess
- eine messbare Abnahmebedingung
- den verantwortlichen internen Owner
- eine Kennzeichnung als Pflicht, Wunsch oder offen
Welche Fragen zeigen die Qualität einer Agentur?
Frage nach Entscheidungen, nicht nur nach Referenzen. Gute Antworten benennen Annahmen, offene Punkte, Risiken und Alternativen. Eine Agentur, die vor Discovery bereits jede Lösung kennt, hat die unbekannten Teile des Projekts wahrscheinlich nicht eingepreist.
Verlange außerdem die tatsächliche Teamstruktur: Wer arbeitet in Discovery, Architektur, Entwicklung, QA und nach Launch? Titel und Verfügbarkeit sind wichtiger als eine große Liste möglicher Spezialisten, die später nicht am Projekt sitzen.
Wie sollte die Angebotsbewertung aussehen?
Bewerte Angebote gegen feste Kriterien und dokumentiere die Gewichtung vor Eingang der Antworten. Preis ist ein Kriterium, aber ohne Scope-Klarheit nicht vergleichbar. Architekturverständnis, Risikobehandlung, Team, Delivery und Betrieb müssen sichtbar danebenstehen.
Separate Annahmen von Zusagen. Ein günstiges Angebot kann auf fehlenden Daten, fertigen APIs oder internem Content-Aufwand beruhen. Diese Annahmen gehören in dieselbe Tabelle wie der Preis, sonst wird erst nach Vertragsstart sichtbar, warum Angebote auseinanderlagen.
Was gehört in die letzte Runde vor der Vergabe?
Die letzte Runde sollte kein zweiter Verkaufspitch sein. Arbeitet mit den Finalisten an einem konkreten Prozess, einem Integrationsfluss und einem kritischen Migrationsfall. So wird sichtbar, wie das Team Fragen strukturiert und Entscheidungen dokumentiert.
Vor Vergabe werden Scope, Ausschlüsse, Abnahmekriterien, Rollen, Change-Prozess und Betrieb gemeinsam gespiegelt. Ungeklärte Punkte bleiben als benannte Risiken im Vertrag oder wandern in eine bezahlte Discovery vor dem Build.
FAQ
Häufige Fragen zur Shopify-RFP
Wie lang sollte ein Shopify-RFP sein?
So lang wie nötig, aber nicht als Sammlung jeder denkbaren Funktion. Ein gutes Dokument ist oft kürzer als ein schlechtes, weil es Ziele, Systemlandschaft, kritische Prozesse, Abnahme und Bewertungslogik sauber trennt und Detaildaten in Anhänge legt.
Sollte das Budget im RFP stehen?
Ein realistischer Korridor verbessert die Vergleichbarkeit. Ohne ihn schlagen Anbieter unterschiedliche Programme vor oder investieren viel Aufwand in eine Lösung, die später außerhalb des Rahmens liegt. Der Korridor darf mit klaren Optionen und Annahmen verbunden sein.
Brauchen wir vor dem RFP eine Discovery?
Bei komplexen Integrationen, mehreren Märkten oder unklarer Custom-Logik meistens ja. Eine kurze unabhängige Discovery verhindert, dass jeder Anbieter andere Lücken errät und die Angebote deshalb nur scheinbar vergleichbar sind.
Wie viele Agenturen sollten eingeladen werden?
Genug für echte Auswahl, aber nicht so viele, dass Rückfragen und Bewertung oberflächlich werden. Eine kleine, vorqualifizierte Gruppe liefert meist bessere Gespräche als eine offene Ausschreibung ohne klare fachliche Passung.
Darf eine Agentur Alternativen zum RFP vorschlagen?
Ja, ausdrücklich. Sie sollte aber kenntlich machen, welche Anforderung anders gelöst wird, welche Annahme dahintersteht und wie sich Kosten, Risiko und Betrieb dadurch verändern. Unbegründete Abweichungen sind keine Innovation.
Offizielle Quellen
Primärquellen zu Plattformfunktionen und kaufmännischen Annahmen. Preise und Editionen können sich ändern.
Weiter entscheiden
Verwandte Entscheidungen
RFP und Scope vor der Ausschreibung schärfen
Wir prüfen Zielbild, Systeminventar, Abnahmekriterien und Bewertungsmatrix, bevor daraus ein Projektangebot wird.
Shopify-Beratung ansehen