Onlineshop und ERP verbinden: Datenflüsse planen

1. Die führenden Systeme festlegen

Ordnen Sie jedem Datenbereich einen Verantwortlichen zu: Artikelstamm, verkaufbarer Bestand, Preise, Aufträge, Versand und Erstattungen müssen nicht im selben System entstehen. Schreiben Sie auf, wer Daten ändern darf und welche Systeme sie nur übernehmen.

Vermeiden Sie die pauschale Aussage „alles wird synchronisiert“. Zwei Systeme, die denselben Preis unabhängig überschreiben, können trotz funktionierender Verbindung widersprüchliche Ergebnisse erzeugen.

Erstellen Sie eine Verantwortungsmatrix je Datenobjekt und nötigenfalls je Feld. Ein ERP kann etwa eine Artikelnummer führen, während redaktionelle Produkttexte aus einem anderen System kommen. Halten Sie auch Ausnahmen fest: Wer darf im Störungsfall einen Bestand korrigieren, und wie verhindert die nächste Übertragung, dass diese Korrektur unbemerkt überschrieben wird?

Besprechen Sie Konflikte vor der Umsetzung. Werden Preise oder Adressen nach einer Änderung im Shop erneut an das ERP übertragen? Gibt es einen Zeitpunkt, ab dem ein Auftrag nur noch im ERP geändert werden darf? Solche Regeln sind fachliche Entscheidungen. Sie lassen sich nicht zuverlässig allein aus verfügbaren API-Feldern ableiten.

2. Datenflüsse statt Feldlisten beschreiben

Beginnen Sie mit dem Weg einer Bestellung: Eingang im Shop, Übernahme ins ERP, Reservierung, Versandauftrag, Tracking und Abschluss. Ergänzen Sie Stornierungen und Retouren als eigene Abläufe.

Definieren Sie pro Übergabe Auslöser, benötigte Daten, erwartete Rückmeldung und fachlich akzeptable Verzögerung. Eine nächtliche Übertragung kann für einen bestimmten Bericht ausreichen, während der verkaufbare Bestand eine andere Aktualität benötigt.

Beschreiben Sie für jedes Objekt, ob neue Einträge, Änderungen und Löschungen übertragen werden sollen. Legen Sie fest, wie sich Varianten, zusammengesetzte Artikel und mehrere Lagerorte zuordnen lassen. Dokumentieren Sie außerdem, welche Daten vorliegen müssen, bevor der nächste Schritt starten darf. Ein Auftrag ohne gültige Artikelzuordnung sollte nicht stillschweigend unvollständig weiterlaufen.

Unterscheiden Sie Meldungen von Zuständen. „Bestand geändert“ ist ein Ereignis; der aktuelle verkaufbare Bestand ist ein Zustand, der bei Bedarf erneut abgefragt und abgeglichen werden können sollte. Für das Briefing genügt zunächst diese fachliche Unterscheidung. Die technische Umsetzung und erforderliche Aktualität müssen die Beteiligten danach für ihre konkreten Systeme bestätigen.

• Artikel und Varianten eindeutig über stabile Kennungen zuordnen.
• Reservierte, verfügbare und physische Bestände auseinanderhalten.
• Statuswerte und deren Bedeutung zwischen den Systemen abstimmen.

3. Konnektor, Middleware oder eigene Entwicklung vergleichen

Ein vorhandener Konnektor kann den Einstieg vereinfachen, wenn die benötigten Versionen und Abläufe unterstützt werden. Prüfen Sie den konkreten Umfang: Ein Export von Aufträgen bedeutet noch keine vollständige Abbildung von Retouren oder Teillieferungen.

Eine Middleware kann mehrere Verbindungen und Umwandlungsregeln bündeln. Individuelle Entwicklung kann bei besonderen Anforderungen sinnvoll sein. Vergleichen Sie Einrichtung, laufenden Betrieb, Änderbarkeit und Verantwortlichkeiten anhand derselben Anwendungsfälle, statt allein die Zahl verfügbarer Schnittstellen zu bewerten.

Verlangen Sie für jede angebotene Verbindung eine Abdeckungsliste Ihrer Anwendungsfälle. Markieren Sie Standardfunktion, Konfiguration, zusätzliche Entwicklung und nicht unterstützte Fälle getrennt. Lassen Sie sich auch erklären, wer Anpassungen bezahlt und betreut, wenn eine Seite der Verbindung ihre Schnittstelle oder ihr Datenmodell verändert.

Prüfen Sie die spätere Handlungsfähigkeit Ihres Teams: Können Sie fehlerhafte Zuordnungen erkennen, Regeln nachvollziehen und Daten exportieren? Wer besitzt Konfiguration und Dokumentation, wenn der Umsetzungspartner wechselt? Beziehen Sie laufende Lizenzkosten und betreute Betriebsleistungen in denselben Vergleich ein. Eine große Zahl unterstützter Systeme ersetzt keinen Nachweis für Ihren Ablauf.

4. Fehler und Wiederholungen einplanen

Was passiert, wenn ein Auftrag im ERP angekommen ist, die Bestätigung aber verloren geht? Eine erneute Übertragung darf nicht automatisch einen zweiten Auftrag anlegen. Verlangen Sie eine nachvollziehbare Zuordnung und Bearbeitung bereits bekannter Vorgänge.

Shopify weist in seiner Webhook-Dokumentation darauf hin, dass Ereignisse nicht zwingend in Reihenfolge eintreffen und Zustellungen fehlen können. Daraus folgt für die Planung: Rückstände und Abweichungen müssen erkennbar und abgleichbar bleiben. Welche Mechanismen nötig sind, hängt von den beteiligten Systemen ab.

Eine brauchbare Fehlermeldung benennt den betroffenen Vorgang, die Ursache und die nächste mögliche Aktion. Trennen Sie beispielsweise eine unbekannte Artikelnummer von einem vorübergehend nicht erreichbaren System. Erstere benötigt meist eine fachliche Korrektur, Letzteres einen geeigneten Wiederholungsweg. Unbegrenzte automatische Wiederholungen ohne Sichtbarkeit lösen nicht jedes Problem.

Planen Sie einen regelmäßigen fachlichen Abgleich ein: Welche Aufträge fehlen auf einer Seite, welche Status passen nicht zusammen und welche Bestände weichen ab? Legen Sie fest, wie weit zurück geprüft wird und wer über eine Korrektur entscheidet. Zugänge und Berechtigungen sollten dabei nur die tatsächlich benötigten Daten und Aktionen umfassen.

5. Fachliche Abnahmefälle vereinbaren

Lassen Sie eine typische Bestellung und bewusst schwierige Fälle prüfen. Dazu gehören etwa eine geänderte Lieferadresse, eine nicht verfügbare Variante, ein Teilversand und eine Retoure nach Abschluss des Auftrags.

Dokumentieren Sie je Fall das erwartete Ergebnis in Shop, ERP und gegebenenfalls Lager. Eine technisch erfolgreiche Übertragung reicht als Abnahme nicht, wenn der Bestand oder die Auftragsbearbeitung fachlich falsch ist.

Verwenden Sie einen überschaubaren Satz repräsentativer Testdaten: einfache und mehrteilige Aufträge, mehrere Varianten, unterschiedliche Lagerzustände und die von Ihnen benötigten Sonderfälle. Halten Sie Eingangsstand, ausgelöste Aktion und erwarteten Endstand je System fest. So können dieselben Fälle nach einer Änderung erneut geprüft werden.

Testen Sie auch den Neustart nach einer Unterbrechung. Wird eine bereits bestätigte Bestellung erneut angelegt? Bleiben ältere Änderungen hinter neueren zurück? Lassen sich bewusst fehlerhafte Vorgänge nach einer Korrektur gezielt nachverarbeiten? Benennen Sie für jeden Fall, welche Person die fachliche Freigabe erteilt und welche Nachweise dafür vorliegen müssen.

6. Den Betrieb mitbeauftragen

Klären Sie, wer fehlgeschlagene Vorgänge sieht, behebt und bei Bedarf erneut anstößt. Das Shopteam benötigt verständliche Meldungen und einen erreichbaren Ansprechpartner, nicht nur ein technisches Protokoll.

Vereinbaren Sie außerdem Tests vor Systemupdates, Pflege der Zugangsdaten, Dokumentation und Übergabe. Die laufende Zuständigkeit gehört ebenso in das Angebot wie die erste Einrichtung.

Vereinbaren Sie, welche Ereignisse eine Meldung auslösen und wer sie während welcher Zeiten bearbeitet. Ein Fehlerprotokoll ohne zuständige Person ist noch kein Betriebsprozess. Unterscheiden Sie technische Störungen von fachlichen Rückfragen und legen Sie fest, wer bei einem blockierten Auftrag eine Übergangslösung freigeben darf.

Planen Sie für Änderungen einen kontrollierten Ablauf: Anforderung beschreiben, betroffene Datenflüsse bewerten, repräsentative Fälle testen und erst dann freigeben. Halten Sie die Dokumentation der tatsächlichen Verbindung aktuell. Dazu gehören Feldzuordnungen, Statusregeln, Zugangszuständigkeiten und bekannte Grenzen; keine Passwörter oder Geheimnisse in allgemein zugänglichen Projektunterlagen.