Eine einzige Wahrheit bedeutet nicht zwingend ein einziges System
Der Begriff „Single Source of Truth“ wird oft so verstanden, dass alle Daten in einer zentralen Anwendung liegen müssen. In gewachsenen Handelslandschaften ist das selten realistisch. Ein ERP oder JTL-Wawi verwaltet andere Aspekte besonders gut als ein PIM, DAM oder Shopsystem.
Wichtiger als eine physische Zentralisierung ist eine eindeutige fachliche Verantwortung: Für jedes Datenobjekt und jedes relevante Feld muss klar sein, welches System es anlegt, verändern darf und an andere Systeme verteilt.
Datenobjekte getrennt betrachten
„Produktdaten“ ist als Begriff zu grob. Ein verkaufsfähiger Artikel besteht aus mehreren Datenbereichen mit unterschiedlichen Abläufen:
- Identifikation: Artikelnummer, GTIN, Herstellerreferenz
- kaufmännische Daten: Einkaufspreis, Verkaufspreis, Steuer, Konditionen
- logistische Daten: Gewicht, Maße, Verpackung, Lagerbestand
- beschreibende Daten: Titel, Texte, Merkmale, Übersetzungen
- digitale Medien: Bilder, Datenblätter, Videos
- kanalbezogene Daten: Kategorie, Listing-Titel, Pflichtattribute
- Transaktionen: Kunde, Auftrag, Zahlung, Versand, Retoure
Diese Bereiche können unterschiedliche führende Systeme besitzen. Entscheidend ist, dass Übergänge und Änderungsrechte dokumentiert sind.
Typische Rollen der Systeme
ERP oder JTL-Wawi
Warenwirtschaft und ERP führen häufig kaufmännische sowie operative Daten. Dazu können Artikelstämme, Preise, Bestände, Kunden und Aufträge gehören. Welche Informationen tatsächlich führend gepflegt werden, hängt vom eingesetzten System und den internen Prozessen ab.
PIM
Ein Product Information Management eignet sich für umfangreiche Produktbeschreibungen, Merkmale, Beziehungen, Übersetzungen, Qualitätsregeln und Freigaben. Das PIM ersetzt nicht automatisch die Warenwirtschaft. Es ergänzt sie um produktbezogene Inhalte und Workflows.
DAM
Ein Digital Asset Management verwaltet Medien, Varianten, Nutzungsinformationen und Zuordnungen. In kleineren Landschaften kann diese Aufgabe im PIM oder einem anderen System liegen.
Shop und Marktplätze
Vertriebskanäle sollten nur solche Daten selbst führen, die tatsächlich kanalspezifisch sind. Werden zentrale Artikelinformationen direkt im Shop korrigiert, ohne sie zurückzuführen, entstehen schnell widersprüchliche Stände.
Eine Datenmatrix schafft Klarheit
Vor einer Integration ist eine einfache Matrix oft hilfreicher als ein großes Architekturdiagramm. Für jedes Datenobjekt werden mindestens diese Fragen beantwortet:
- Wo wird der Datensatz angelegt?
- Welches System führt welches Feld?
- Wer darf Änderungen freigeben?
- In welche Systeme wird die Information verteilt?
- Wie aktuell muss sie sein?
- Was geschieht bei einem fachlichen Fehler?
- Darf ein Zielsystem Informationen zurückschreiben?
So wird beispielsweise sichtbar, dass der Grundpreis aus der Warenwirtschaft kommt, Marketingtexte im PIM entstehen und ein Marktplatz einen eigenen Listing-Titel benötigt.
Konflikte nicht dem Zufall überlassen
Wenn zwei Systeme dasselbe Feld verändern dürfen, muss eine Konfliktregel existieren. „Der letzte Schreibvorgang gewinnt“ ist bei geschäftskritischen Daten selten eine gute fachliche Entscheidung.
Mögliche Regeln sind:
- Änderungen sind nur im führenden System zulässig.
- Ein Zielsystem darf Vorschläge zurückmelden, aber nicht direkt überschreiben.
- Bestimmte Felder werden bewusst zusammengeführt.
- Konflikte werden zur manuellen Prüfung gestellt.
- Daten mit ungültigem Format werden nicht verteilt und klar protokolliert.
Aktualität passend zum Datenobjekt wählen
Nicht jede Information benötigt Echtzeit. Ein Lagerbestand kann zeitkritisch sein, ein Datenblatt möglicherweise nicht. Eine unnötig enge Echtzeitkopplung erhöht Aufwand und Fehlerfolgen.
Für jeden Datenfluss sollte deshalb geklärt werden:
- Wie schnell muss eine Änderung im Ziel sichtbar sein?
- Welches Volumen ist zu erwarten?
- Kann der Prozess bei einem Ausfall warten?
- Muss die Reihenfolge von Änderungen erhalten bleiben?
- Wie wird nach einer Störung wieder angeknüpft?
Aus diesen Antworten ergibt sich, ob ein synchroner API-Aufruf, ein Ereignis, eine Warteschlange oder ein geplanter Stapelprozess angemessen ist.
Fazit
Eine gute Systemlandschaft braucht nicht ein System für alles. Sie braucht klare Verantwortung für jedes relevante Datenobjekt. Erst wenn diese Verantwortung geklärt ist, können Connectoren, APIs und Middleware zuverlässig umgesetzt werden.
Das Ergebnis ist eine fachlich verständliche Architektur: Mitarbeitende wissen, wo sie Daten pflegen; Integrationen wissen, woher sie Daten beziehen; Fehler lassen sich einem Prozess und einer Verantwortung zuordnen.
Mehr über unsere Leistungen für Datenintegration und Schnittstellen erfahren.