Unidirektionale oder bidirektionale Integration: Wie Sie die Synchronisationsrichtung ohne Datenkonflikte festlegen

Die Entscheidung zwischen einer unidirektionalen und einer bidirektionalen Integration besteht nicht nur darin, einen Pfeil zwischen zwei Anwendungen zu zeichnen. Sie betrifft die Datenhoheit, operative Verantwortlichkeiten und die Risikotoleranz. Eine scheinbar einfache Verbindung zwischen einem CRM, einem ERP, einem Onlineshop oder einer Kundenservice-Plattform kann Dubletten, Überschreibungen und Statusfehler verursachen, wenn beide Systeme dieselben Informationen ohne explizite Regeln ändern.

Die Grundregel ist einfach: Synchronisieren Sie nur dann in beide Richtungen, wenn ein realer Prozess erfordert, dass beide Systeme denselben Datenbereich bearbeiten. Dass zwei Anwendungen Informationen austauschen können, bedeutet nicht, dass sie es tun sollten. Weniger Datenflüsse und weniger bearbeitbare Felder senken in der Regel Wartungsaufwand, Störungen und nachträgliche manuelle Entscheidungen.

Was sich zwischen einer unidirektionalen und einer bidirektionalen Integration unterscheidet

Bei einer unidirektionalen Integration veröffentlicht oder sendet ein System Informationen, während das andere sie empfängt, repliziert oder abfragt. Beispielsweise kann ein ERP Katalog, Verfügbarkeit und Preise an einen Onlineshop senden. Der Onlineshop empfängt diese Werte, korrigiert sie jedoch nicht und sendet sie nicht an das ERP zurück.

Bei einer bidirektionalen Integration kann jedes System Änderungen erzeugen, die im anderen System ankommen. Ein typischer Fall ist die Bestellung: Der Onlineshop erstellt sie, das ERP aktualisiert ihre Kommissionierung oder Rechnungsstellung, und der Onlineshop muss diesen Status anzeigen, um den Kunden zu informieren. Die Bidirektionalität kann für dieses Objekt sinnvoll sein, verpflichtet aber nicht dazu, alle seine Felder in beide Richtungen zu synchronisieren.

Eine globale Einordnung wie „die Integration ist bidirektional“ sollte vermieden werden. Die hilfreiche Entscheidung wird pro Entität, Feld und Vorgang getroffen:

• Entität: Kunde, Bestellung, Produkt, Rechnung, Ticket oder Bestand.
• Vorgang: erstellen, aktualisieren, stornieren, archivieren oder abfragen.
• Feld: E-Mail-Adresse, Lieferadresse, Status, Preis, Steueridentifikationsnummer oder Einwilligung.

So kann eine Integration für Preise unidirektional, für Bestellstatus bidirektional und für Rechnungen nur lesend sein. Dieser Detailgrad verhindert, dass eine zulässige Änderung in einem Kanal Informationen überschreibt, die einem anderen Kanal gehören.

Beginnen Sie mit der Datenhoheit, nicht mit der verfügbaren API

Bevor Webhooks, geplante Aufgaben oder API-Funktionen bewertet werden, sollte das Team eine Übersicht der Datenhoheit erstellen. Beantworten Sie für jede relevante Information, wer sie erstellt, wer sie ändern darf, wo sie validiert wird und welche Anwendung sie anzeigen soll.

1. Bestimmen Sie das führende System. Es ist die maßgebliche Quelle bei Abweichungen. Es muss nicht das System sein, in dem die Daten am häufigsten angezeigt werden.
2. Trennen Sie Stammdaten und operative Daten. Ein ERP kann führend für Artikelnummern, Steuern und Verfügbarkeit sein, während der Onlineshop führend für den Einkaufskanal, den Warenkorb und die im Checkout bestätigte Adresse ist.
3. Definieren Sie die Notwendigkeit einer Rückübertragung. Fragen Sie, welche Entscheidung oder Aufgabe blockiert wäre, wenn die Änderung nicht zum Ursprungssystem zurückkehrt.
4. Dokumentieren Sie Ausnahmen. Innerhalb derselben Entität können Felder unterschiedliche Verantwortliche haben. Ein Vertriebsteam aktualisiert möglicherweise die Telefonnummer im CRM, während die gültige Lieferadresse aus der Bestellung stammt.

Ein Warnsignal liegt vor, wenn die Antwort auf „Wer bestimmt über dieses Feld?“ lautet: „Es kommt darauf an.“ Das verhindert die Integration nicht, erfordert aber, dieses „Es kommt darauf an“ in eine überprüfbare Regel zu überführen: nach Status, Kanal, Datum, Kundentyp oder Benutzerberechtigung.

Wann eine Richtung ausreicht und sicherer ist

Eine unidirektionale Synchronisierung ist vorzuziehen, wenn es eine eindeutige Quelle gibt, der Empfänger Daten hauptsächlich nutzen muss und eine Rückübertragung keine unverzichtbare Aktion auslöst. Sie eignet sich auch, wenn Daten sensibel, intern stark reguliert oder schwer abzugleichen sind.

Häufige Fälle sind ein Katalog vom ERP zum Onlineshop, Segmente vom CRM zu einer Kommunikationsplattform oder abgeschlossene Tickets zu einem Analysesystem. In diesen Situationen schafft die Bearbeitung im Empfängersystem ein schwer erfüllbares Versprechen: dass jede lokale Änderung erhalten bleibt und außerhalb dieses Kontexts sinnvoll ist.

Praktische Signale für einen unidirektionalen Datenfluss

• Ein System führt Validierungen, Freigaben oder Berechnungen aus, die das andere nicht nachbilden kann.
• Der Empfänger benötigt nur Sichtbarkeit, Suche, Berichte oder die Ausführung einer nachgelagerten Aufgabe.
• Änderungen im Zielsystem sind lokal, temporär oder sollen den Stammdatensatz nicht beeinflussen.
• Ein Konflikt hätte finanzielle, rechtliche, operative oder kundenbezogene Auswirkungen.
• Die Informationen ändern sich selten oder können stapelweise aktualisiert werden, ohne den Prozess zu beeinträchtigen.

Der wichtigste Vorteil ist nicht nur technischer Natur. Ein Datenfluss in nur eine Richtung ermöglicht eine klare Erklärung, warum ein Wert auf dem Bildschirm erscheint und wo er korrigiert werden muss. Erkennt ein Mitarbeiter im Onlineshop einen falschen Preis, weiß er, dass er ihn im ERP korrigieren muss, statt eine Kopie zu bearbeiten, die bei der nächsten Synchronisierung ersetzt wird.

Wann eine bidirektionale Synchronisierung gerechtfertigt ist

Bidirektionalität ist gerechtfertigt, wenn zwei Teams in unterschiedlichen Anwendungen arbeiten und beide legitime Teile desselben Prozesses abschließen müssen. Es muss ein konkreter operativer Bedarf bestehen, nicht nur der Wunsch, „alles aktuell zu halten“.

Ein häufiges Beispiel verbindet Onlineshop, ERP und Kundenservice. Der Onlineshop erstellt die Bestellung und erfasst die Lieferadresse. Das ERP bestätigt Kommissionierung, Versand oder Stornierung. Der Kundenservice kann einen Vorgang oder einen Änderungswunsch erfassen. Dennoch sollten nicht alle Beteiligten dasselbe bearbeiten:

• Der Onlineshop ist führend für Daten, die während des Kaufs erfasst und bestätigt wurden.
• Das ERP ist führend für Logistikstatus, operative Dokumente und zugesagte Verfügbarkeit.
• Die Kundenservice-Anwendung kann einen Fall anlegen und eine Maßnahme vorschlagen, sollte aber einen Logistikstatus nicht direkt verändern, ohne die im ERP festgelegte Regel zu durchlaufen.

Dieses Design ermöglicht ein abgestimmtes Erlebnis, ohne drei Systeme zu gleichwertigen Autoritäten zu machen. Bidirektionalität braucht Schreibgrenzen, nicht nur Leseberechtigungen.

Risiken beider Richtungen und Regeln zur Konfliktlösung

Die typischen Fehler einer bidirektionalen Synchronisierung sind meist keine einzelnen Verbindungsfehler. Es handelt sich um geschäftliche Unklarheiten, die als Datenfehler sichtbar werden. Zu den häufigsten gehören Aktualisierungsschleifen, Überschreibungen, Dubletten, verspätet eintreffende Änderungen und Status, die zwischen den Systemen keine Entsprechung haben.

Eine Schleife entsteht, wenn System A System B aktualisiert, B dieselbe Änderung an A zurücksendet und der Zyklus weiterläuft. Eine Überschreibung tritt auf, wenn zwei Benutzer ein Feld an unterschiedlichen Orten bearbeiten, bevor die Integration beide Versionen übertragen kann. Dubletten entstehen, wenn jede Plattform Datensätze erstellt, ohne die Kennung der anderen zu erkennen.

Um dies zu vermeiden, definieren Sie vor der Umsetzung eine Konfliktrichtlinie:

• Vorrang nach Feld: Das ERP hat bei Bestand Vorrang, der Onlineshop bei der bestätigten Lieferadresse.
• Vorrang nach Status: Solange eine Bestellung offen ist, kann sie im Onlineshop geändert werden; nach der Kommissionierung erfordern Änderungen einen kontrollierten Ablauf.
• Letzte Aktualisierung: Nutzen Sie diese Regel nur, wenn Uhrzeit, Zeitzone und Bedeutung der Änderung zuverlässig sind. Sie ist keine universelle Regel.
• Manuelle Prüfung: Leiten Sie Fälle mit hoher Auswirkung mit Verantwortlichem, Grund und verglichenen Daten an eine Warteschlange weiter.
• Explizite Ablehnung: Wenden Sie eine inkompatible Änderung nicht an; geben Sie einen umsetzbaren Fehler zurück und bewahren Sie die Nachweise auf.

Auch Status sollten modelliert werden. „Storniert“, „erstattet“, „versendet“ und „geschlossen“ bedeuten nicht zwangsläufig in jeder Anwendung dasselbe. Erstellen Sie eine Zuordnungstabelle und legen Sie fest, welche Übergänge zulässig sind. Wenn ein System einen Übergang nicht unterstützt, erzwingen Sie keine Entsprechung, die eine operative Ausnahme verdeckt.

Technisches Mindestdesign für eine betreibbare Integration

Die Architektur muss die Datenrichtlinie unterstützen, nicht ersetzen. Mindestens benötigt jeder synchronisierte Datensatz eine stabile interne Kennung und die Kennung des externen Systems. Verwenden Sie keine E-Mail-Adresse, keinen Namen und keine sichtbare Referenz als eindeutigen Schlüssel, wenn diese sich ändern oder mehrfach vorkommen können.

• Ursprungskennzeichnungen: Halten Sie fest, welches System die Änderung erzeugt hat, damit sie nicht erneut als neue Änderung verarbeitet wird.
• Versionen oder Änderungszeitpunkte: Sie helfen, verspätete Ereignisse und gleichzeitige Aktualisierungen zu erkennen.
• Idempotenz: Das erneute Verarbeiten einer Nachricht darf keine zusätzliche Bestellung, keinen zusätzlichen Kunden oder kein zusätzliches Ticket erzeugen.
• Nachvollziehbares Protokoll: Speichern Sie Kennungen, Flussrichtung, Ergebnis, Fehler und Verarbeitungszeitpunkt.
• Kontrollierte Wiederholungsversuche: Unterscheiden Sie zwischen vorübergehenden Fehlern und endgültigen Validierungsfehlern, und begrenzen Sie Wiederholungsversuche.

ursprung: onlineshop
entitaet: bestellung
externe_id: EC-10452
version: 7
vorgang: status_aktualisieren
idempotenzschluessel: onlineshop-EC-10452-7

Diese Art von Informationen ermöglicht es, zu untersuchen, warum eine Änderung nicht angekommen ist, zweimal eingetroffen ist oder verworfen wurde. Ohne Nachvollziehbarkeit vergleicht das Team am Ende Bildschirme und korrigiert Daten manuell – eine Praxis, die Abweichungen verschärft.

Testen Sie Konfliktszenarien und geben Sie den Datenfluss mit einer Checkliste frei

Validieren Sie eine Integration nicht nur mit erfolgreichen Neuerstellungen und Aktualisierungen. Die Tests sollten gleichzeitige Änderungen, unvollständige Datensätze, doppelte Ereignisse, Netzwerkfehler, unzureichende Berechtigungen und eine längere Nichtverfügbarkeit eines der Systeme umfassen.

Bestätigen Sie vor der Freigabe für die Produktion Folgendes:

• Jede wichtige Entität und jedes wichtige Feld haben ein führendes System und einen geschäftlich Verantwortlichen.
• Die Richtung jedes Datenflusses entspricht einem dokumentierten operativen Bedarf.
• Für Konflikte bestehen Regeln für Vorrang, Ablehnung und manuelle Prüfung.
• Externe Kennungen, der Ursprung der Änderung und Idempotenz sind umgesetzt.
• Inkompatible Status werden explizit behandelt, nicht implizit umgewandelt.
• Es gibt Warnmeldungen und ein Verfahren zur Prüfung von Fehlern, Wiederholungsversuchen und ausstehenden Datensätzen.
• Die Teams wissen, wo Daten korrigiert werden müssen und welche Änderungen sie nicht lokal vornehmen dürfen.

Die beste Integration ist nicht diejenige, die die meisten Daten in beide Richtungen bewegt. Sie bewahrt eine verständliche Quelle der Wahrheit, liefert Informationen dann, wenn der Prozess sie benötigt, und macht Ausnahmen sichtbar, bevor sie zu Problemen für Kunden werden.