Enterprise-Entscheidung
Shopify Discovery Audit: Was vor dem ersten Build geklärt sein muss
Aktualisiert
Ein Discovery Audit übersetzt Geschäftsziele, Prozesse und Systemlandschaft in belastbare Entscheidungen vor dem Build. Das Ergebnis ist keine Präsentation mit Allgemeinplätzen, sondern ein dokumentierter Scope mit Zielarchitektur, Datenhoheit, Integrationsflüssen, Migrationsplan, Risiken, Abnahmekriterien und einer Roadmap, die ein Team seriös kalkulieren und umsetzen kann.
Das Audit eignet sich für Replatforming, komplexe Relaunches und neue B2B-, POS- oder Internationalisierungsprogramme. Es ersetzt keine Detailkonzeption jedes Screens, reduziert aber die teuren Unbekannten davor.
Wann braucht ein Shopify-Projekt eine Discovery?
Eine Discovery lohnt sich, sobald mehrere Systeme, Länder oder Teams voneinander abhängen. Wenn Datenmodell, Integrationen und Verantwortlichkeiten erst während der Entwicklung entschieden werden, wird jede technische Entscheidung vorläufig und spätere Änderung teuer.
Ein einfacher Theme-Relaunch mit sauberem Katalog braucht kein mehrwöchiges Audit. Ein Wechsel von Shopware oder Adobe Commerce mit ERP, PIM, B2B, SEO-Historie und mehreren Märkten dagegen schon, weil der sichtbare Shop nur ein Teil des Projekts ist.
Welche Belege werden zu Beginn eingesammelt?
Das Audit startet nicht mit Meinungen, sondern mit Artefakten: Systemdiagrammen, App- und Vertragsinventaren, Datenexporten, API-Dokumentation, Analytics, Search Console, Supportfällen, Prozessbeschreibungen und realen Beispieldatensätzen.
Interviews ergänzen diese Belege. Sie ersetzen sie nicht. Ein Prozess gilt erst als verstanden, wenn Verantwortliche, Auslöser, Datenobjekte, Ausnahmen und gewünschtes Ergebnis sichtbar sind.
Typische Inputs
- Shop- und Marktstruktur mit Domains, Sprachen und Währungen
- Katalogexport mit Varianten, Attributen, Medien und Metafeldern
- Systeminventar mit APIs, Jobs, Dateien und manuellen Zwischenschritten
- SEO-URLs, Rankings, Backlinks und bekannte Redirect-Ketten
- Bestell-, Retouren-, B2B- und Fulfillment-Beispielfälle
- Release-, Support- und Incident-Prozess des aktuellen Teams
Wie werden Datenhoheit und Integrationen entschieden?
Für jedes Objekt wird ein führendes System festgelegt: Produkt, Preis, Bestand, Kunde, Auftrag, Lieferung, Retoure und Finance. Danach lassen sich Richtung, Trigger, Frequenz, Fehlerweg und Wiederanlauf pro Strecke bestimmen.
Ohne diese Matrix schreiben Systeme gegeneinander. Shopify, ERP und PIM können technisch dasselbe Feld verändern, aber organisatorisch darf nur eines davon die Wahrheit besitzen. Diese Entscheidung ist wichtiger als die Wahl des Connectors.
| Objekt | Führendes System | Ziel | Audit-Frage |
|---|---|---|---|
| Produktstamm | ERP oder PIM | Shopify | Wer erzeugt Varianten und Identifikatoren? |
| Produkttexte | PIM, CMS oder Shopify | Storefront | Wer darf bestehende Texte überschreiben? |
| Preis | ERP oder Shopify | Shopify | Wie werden Märkte und B2B-Kataloge getrennt? |
| Bestand | ERP oder WMS | Shopify | Welche Reservierungen sind bereits abgezogen? |
| Auftrag | Shopify | ERP/WMS | Wie werden Duplikate und Teilausfälle verhindert? |
| Retoure | ERP, WMS oder App | Shopify/Finance | Wo entsteht der finale Status? |
Was gehört in Zielarchitektur und Scope?
Die Zielarchitektur zeigt Systeme, Verantwortungen und Datenflüsse, nicht jeden späteren Dienst. Dazu kommt ein Scope, der Funktionen nach Pflicht, später und bewusst nicht enthalten trennt.
Jeder Scope-Punkt braucht eine Abnahme. Funktioniert ist kein Kriterium. Ein importierter Kunde, ein B2B-Preis, ein Marktwechsel oder eine Retoure muss mit konkreten Daten und erwarteten Ergebnissen testbar sein.
Wie werden SEO und Cutover Teil der Architektur?
SEO-Migration ist keine Checkliste kurz vor Launch. URL-Inventar, neue Informationsarchitektur, Redirect-Regeln, Canonicals, hreflang, strukturierte Daten und Statuscodes beeinflussen Datenmodell und Content-Produktion bereits während des Builds.
Der Cutover verbindet technische und organisatorische Abhängigkeiten: Freeze, Delta-Importe, DNS, Tracking, Zahlungsprüfung, Redirects, Bestandsabgleich und Rückfallplan. Jede Aktivität braucht Zeitpunkt, Owner und eindeutiges Signal für Erfolg oder Abbruch.
Welche Ergebnisse muss ein guter Audit liefern?
Am Ende stehen ein aktuelles Systembild, die Zielarchitektur, Daten- und Integrationsmatrix, priorisierter Scope, Risikoregister, Migrations- und Cutover-Plan, Abnahmekriterien sowie ein Aufwand mit klaren Annahmen.
Offene Fragen verschwinden nicht hinter einer pauschalen Schätzung. Sie werden als Entscheidung, Spike oder Voraussetzung benannt. Dadurch kann ein internes Team, NICCOS oder ein anderer Anbieter den nächsten Schritt nachvollziehbar planen.
FAQ
Häufige Fragen zum Discovery Audit
Wie lange dauert ein Shopify Discovery Audit?
Das hängt von Systemzahl, Märkten und verfügbaren Unterlagen ab. Ein fokussierter Audit kann in wenigen Workshops entstehen; ein Enterprise-Replatforming braucht zusätzliche Daten- und Schnittstellenanalyse. Die Dauer sollte aus den offenen Fragen folgen, nicht aus einem festen Workshop-Paket.
Was ist der Unterschied zu einem technischen Audit?
Ein technisches Audit bewertet den aktuellen Code und die technische Qualität. Discovery verbindet zusätzlich Geschäftsziele, Prozesse, Daten, Organisation, Migration und Betrieb und leitet daraus eine Zielarchitektur sowie einen umsetzbaren Scope ab.
Muss die umsetzende Agentur die Discovery machen?
Nein. Die Ergebnisse sollten so dokumentiert sein, dass mehrere Teams damit arbeiten können. Gleichzeitig ist es sinnvoll, die später Verantwortlichen früh einzubeziehen, weil sie technische Annahmen und Betriebsfolgen direkt prüfen können.
Was passiert mit unbekannten Anforderungen?
Sie werden nicht versteckt kalkuliert. Jede Unbekannte bekommt einen Owner und wird als Entscheidung, technischer Spike, Datenprüfung oder Voraussetzung geführt. Erst wenn ihre Auswirkung verstanden ist, wird sie verbindlicher Scope.
Ist das Audit bereits Teil der Umsetzung?
Er kann der erste Projektabschnitt sein, sollte aber ein eigenständig nutzbares Ergebnis liefern. Das Unternehmen muss mit den Artefakten eine Umsetzung beauftragen, vergleichen oder intern weiterplanen können.
Offizielle Quellen
Primärquellen zu Plattformfunktionen und kaufmännischen Annahmen. Preise und Editionen können sich ändern.
Weiter entscheiden
Verwandte Entscheidungen
Die unbekannten Teile vor dem Build sichtbar machen
NICCOS verbindet Geschäftsprozesse, Datenmodell, Integrationen, SEO und Delivery zu einem Scope, der sich belastbar entscheiden und kalkulieren lässt.
Shopify-Beratung ansehen