Viele Schnittstellenprobleme sind keine Technikprobleme, sondern ungeklärte Zuständigkeiten für Datenfelder. Dieser Artikel zeigt, wie du führende Systeme festlegst, Synchronisationsrichtungen sauber definierst und Fehlerfälle einplanst, bevor sie im Betrieb auffallen.
Die kurze Antwort: Lege zuerst für jedes Datenfeld fest, welches System die Wahrheit hält, und verbinde erst danach. Wenn Preis, Bestand oder Produkttext an zwei Stellen gepflegt werden können, sind widersprüchliche Stände wahrscheinlich – und dann kostet es Zeit, herauszufinden, welcher Wert stimmt. Diese Zuständigkeitsfrage ist der Kern des Themas; vieles Weitere ist Umsetzung.
Wer besitzt welches Datenfeld?
Die typische Aufteilung sieht so aus: Das ERP kennt kaufmännische Wahrheiten wie Preise, Bestände, Bestellungen und Gutschriften. Ein PIM kennt beschreibende Wahrheiten wie Attribute, Texte, Medien und Kategoriezuordnungen. Der Shop ist die Verkaufsoberfläche und damit das Ziel der meisten Datenflüsse – mit einer wichtigen Ausnahme: Bestellungen entstehen im Shop und fließen zurück.
Diese Aufteilung ist ein Vorschlag, kein Gesetz. Wenn du kein PIM hast, kann der Shop selbst das führende System für Produkttexte sein – das ist völlig in Ordnung, solange es bewusst entschieden und aufgeschrieben ist. Problematisch wird es erst, wenn niemand die Frage beantworten kann.
| Datenfeld | Führendes System (Beispielannahme) | Richtung | Takt |
|---|---|---|---|
| Artikelstamm und Attribute | PIM | PIM zu Shop | Bei Änderung |
| Produkttexte und Medien | PIM | PIM zu Shop | Bei Änderung |
| Preise | ERP | ERP zu Shop | Täglich oder bei Änderung |
| Lagerbestand | ERP oder Lagersystem | ERP zu Shop | Nahe Echtzeit |
| Bestellungen | Shop | Shop zu ERP | Nahe Echtzeit |
| Retouren und Gutschriften | ERP | ERP zu Shop | Bei Statuswechsel |
| Kundenstammdaten | Bewusst festlegen | Nur eine Richtung | Je nach Entscheidung |
Richtung und Takt sind Betriebsentscheidungen
Zwei Regeln ersparen viel Ärger. Erstens: Beidseitige Synchronisation nur dort, wo sie wirklich gebraucht wird. Jede Zwei-Wege-Verbindung braucht eine Konfliktregel, und Konfliktregeln sind schwer zu testen. Zweitens: Der Takt richtet sich nach der Folge eines Fehlers, nicht nach dem technisch Möglichen. Ein Bestand, der zwei Stunden alt ist, kann zu Überverkäufen führen; ein Produkttext, der zwei Stunden alt ist, fällt in der Regel nicht ins Gewicht.
Denk außerdem an die Datenmenge. Ein vollständiger Abgleich aller Artikel ist bequem und kann bei wachsendem Sortiment zur Belastung werden. Ein Abgleich nur der Änderungen ist aufwendiger zu bauen und im Alltag deutlich ruhiger. Prüfe, ob ein Änderungsabgleich gebraucht wird. Für kleine Kataloge mit seltenen Änderungen kann ein kontrollierter Vollabgleich reichen; häufige Bestandsänderungen stellen andere Anforderungen.
Fehlerfälle sind der eigentliche Test
Eine Schnittstelle, die im Normalfall funktioniert, hat noch nichts bewiesen. Interessant wird sie, wenn ein System nicht erreichbar ist, wenn ein Datensatz unvollständig ankommt, wenn dasselbe Ereignis doppelt gesendet wird oder wenn eine Bestellung ein Produkt enthält, das es im Zielsystem nicht mehr gibt. Für jeden dieser Fälle braucht es eine Entscheidung: erneut versuchen, verwerfen, in eine Warteschlange legen oder einen Menschen informieren.
Ein ausdrücklich fiktives Szenario
Erfundenes Beispiel: Ein Shop führt seine Bestände im ERP und pflegt Produkttexte direkt im Shop. Bei einer Aktion verkaufen sich mehrere Artikel gleichzeitig; der Bestandsabgleich läuft nur nachts. Am Morgen liegen Bestellungen für Artikel vor, die längst leer sind. Der Reflex wäre, den Abgleich häufiger laufen zu lassen. Die eigentliche Frage ist aber, ob der Shop den Bestand beim Kaufabschluss gegen das führende System prüft – und was passieren soll, wenn die Prüfung negativ ausfällt.
Das Szenario zeigt das Muster: Der Fehler wirkt technisch, entsteht aber aus einer nicht getroffenen Prozessentscheidung. Deshalb beginnt jede Integration sinnvollerweise mit Prozessarbeit, nicht mit Konfiguration – der Artikel zum Dokumentieren von Prozessen vor der Automatisierung beschreibt genau diese Reihenfolge.
Bevor du verbindest: aufschreiben
Ein brauchbares Integrationsdokument passt auf wenige Seiten und enthält: die Feldtabelle mit führendem System, Richtung und Takt; die Liste der ausgetauschten Objekte inklusive Pflichtfeldern; die Fehlerregeln; die Schlüssel, über die Datensätze zugeordnet werden – etwa Artikelnummern; und die Frage, was bei einem Systemwechsel passiert. Gerade der letzte Punkt wird gern übergangen und verursacht bei einem späteren Systemwechsel oft den größten Aufwand.
Die Zuordnungsschlüssel verdienen besondere Sorgfalt. Wenn Artikelnummern in einem System mit führenden Nullen und im anderen ohne gepflegt werden, greift die Zuordnung für die betroffenen Artikel nicht – bei selten verkauften Artikeln fällt das oft lange nicht auf. Da Attribute und Texte häufig aus dem Vorsystem stammen, hängt auch die Qualität deiner Produktdatenpflege im Shop direkt an dieser Zuordnung.
Standard, Middleware oder eigener Workflow
Für die Umsetzung gibt es drei übliche Wege: eine fertige Verbindung für deine Systemkombination, eine Integrationsplattform, auf der du Abläufe zusammensetzt, oder eine individuell entwickelte Anbindung. Fertige Verbindungen sind schnell, aber nur so gut wie ihre Annahmen über deine Prozesse. Plattformen sind flexibel und brauchen jemanden, der sie betreut. Individuelle Anbindungen lassen sich genau auf den Bedarf zuschneiden und binden dauerhaft Wartungsaufwand.
Wir empfehlen, zuerst zu prüfen, ob deine Sonderfälle echte Anforderungen sind oder historisch gewachsene Gewohnheiten – häufig schrumpft die Anforderungsliste dabei. Wenn du in Richtung Plattform gehst, ist auch die Betriebsfrage relevant, die der Artikel zu n8n Cloud oder Selfhosting behandelt. Für die Umsetzung selbst ist der Aufbau von Shop-Schnittstellen vor allem eine Frage sauberer Spezifikation, nicht der eingesetzten Werkzeuge.
Grenzen und der nächste Schritt
Schnittstellen reparieren keine schlechten Daten – sie verteilen sie nur schneller. Wenn Attribute im PIM lückenhaft sind, sind sie nach der Integration im Shop lückenhaft. Ebenso wenig ersetzen sie Prozessentscheidungen: Ob eine Bestellung mit unklarem Zahlungsstatus ins ERP darf, ist eine kaufmännische Frage. Und Aufwandsschätzungen lassen sich seriös erst nennen, wenn Feldliste und Sonderfälle stehen.
Als nächsten Schritt empfehlen wir, die Feldtabelle aus diesem Artikel für deine echten Systeme auszufüllen und jede Zeile mit einem Namen zu versehen. Die Zeilen, bei denen zwei Systeme in Frage kommen oder niemand zuständig ist, sind deine offenen Entscheidungen – und in aller Regel auch die Stellen, an denen dein heutiger Betrieb hakt.
Datenflüsse einmal sauber sortieren
Wenn du deine Systemlandschaft vor einer Integration ordnen willst, ist die gemeinsame Durchsicht der Feldzuständigkeiten der schnellste Einstieg.
E-Commerce-Beratung ansehen
Wissen
