Dass eine Datei in ein System übertragen wurde, bedeutet noch nicht, dass die Katalogintegration erfolgreich abgeschlossen ist. Entscheidend ist, ob dasselbe Produkt in unterschiedlichen Systemen dieselbe Bedeutung hat. Eine gute Integration steuert Datenquelle, Transformation, Freigabe und Nutzung im Zielsystem gemeinsam.
Zuerst die Aufgaben der Systeme abgrenzen
Ein ERP kann Bestände und Geschäftsvorgänge verwalten, ein Produktinformationsmanagementsystem die Produktinhalte und eine E-Commerce-Plattform das Kundenerlebnis. Die Architektur ist jedoch in jedem Unternehmen anders. Statt anzunehmen, dass 'alle Daten dem ERP gehören', sollte das führende Quellsystem für jedes Feld bestimmt werden. Technische Abmessungen, Verkaufspreise, Bestandsmengen und freigegebene Beschreibungen müssen nicht am selben Ort entstehen.
Sobald die führende Quelle feststeht, sind auch Konfliktregeln zu definieren. Wird eine lokale Korrektur eines Nutzers im Vertriebskanal bei der nächsten Übertragung überschrieben? Welche Zielsysteme werden aktualisiert, wenn sich der Quelldatensatz ändert? Ohne Antworten kann die Integration zu einem Übertragungszyklus werden, der durch manuelle Eingriffe immer wieder rückgängig gemacht wird.
Feldzuordnung ist mehr als der Abgleich von Spaltennamen
Das Feld 'Nummer' kann in einem System die Herstellerteilenummer und in einem anderen den internen Artikelcode enthalten. Ähnliche Namen garantieren keine ähnliche Bedeutung. Das Feldverzeichnis sollte Definition, Datentyp, Einheit, Pflichtstatus, erlaubte Werte und den Umgang mit leeren Werten enthalten. Bei der Produktidentität ist auch die Beziehung zwischen Marke und Nummer zu berücksichtigen. Dieselbe Zeichenfolge kann bei verschiedenen Marken vorkommen.
Einheitenumrechnungen, Dezimaltrennzeichen, Sprache und Zeichenkodierung müssen ausdrücklich behandelt werden. Stückzahl und Satzangaben dürfen nicht verwechselt werden. Der ursprüngliche Quellwert sollte erhalten und der umgewandelte Wert separat gespeichert werden. Ist eine Transformationsregel fehlerhaft, lässt sich der Grund für eine Änderung untersuchen, ohne die Quelldatei erneut suchen zu müssen.
Produkt-, Anwendungs- und Geschäftsdaten als getrennte Datenströme betrachten
Technische Produktmerkmale und Fahrzeuganwendungsbeziehungen erfordern unterschiedliche Validierungsregeln. Auch der Standardansatz der Auto Care Association trennt Produktinformationen von Anwendungsdaten. [1] Preise und Bestände ändern sich in vielen Unternehmen wiederum in einem anderen Rhythmus als diese beiden Inhaltsgruppen. Alle Felder im selben Intervall zu übertragen, kann unnötige Last oder Verzögerungen verursachen.
Auch die Zielkanäle haben unterschiedliche Anforderungen. Ein B2B-Portal benötigt möglicherweise detaillierte technische Filter, während ein anderer Vertriebskanal bestimmte Beschreibungslängen vorgibt. Der gemeinsame Stammdatensatz sollte erhalten bleiben. Kanalspezifische Regeln gehören in die Verteilungsschicht. Die Beschränkung eines Kanals darf den Informationsumfang der Quelldaten nicht dauerhaft reduzieren.
Fehlerbehandlung in das Design integrieren
Eine robuste Übertragung muss empfangene, validierte, abgelehnte und im Zielsystem veröffentlichte Datensätze getrennt zählen können. Eine technische Empfangsbestätigung beweist nicht immer, dass die Daten für Kunden sichtbar sind. Deshalb sollten Veröffentlichungsstatus und Datensatzanzahl im Zielsystem abgeglichen werden. Bei einem teilweisen Fehler sollten nur betroffene Datensätze erneut verarbeitet werden können. Eine erneute Übertragung darf keine Produktduplikate erzeugen.
Besonders wichtig ist das Verhalten beim Löschen und Deaktivieren. Fehlt ein Datensatz in der Quelldatei, bedeutet das nicht zwingend, dass das Produkt entfernt wurde. Die Datei kann ausschließlich geänderte Datensätze enthalten. Der Unterschied zwischen vollständiger und inkrementeller Übertragung, die Versionsnummer und der Verarbeitungszeitpunkt müssen protokolliert werden. Um eine fehlerhafte Veröffentlichung rückgängig machen zu können, sollte der vorherige freigegebene Zustand erhalten bleiben.
Den Piloten mit echten Ausnahmefällen testen
Für einen Piloten nur saubere Datensätze auszuwählen, ist irreführend. Einbezogen werden sollten Nummern mit führenden Nullen, mehrere Anwendungsbeziehungen, fehlende Pflichtfelder, geänderte Abmessungen und deaktivierte Produkte. Definieren Sie die Abnahmekriterien vorab: Erhalt der Identitäten, korrekte Transformationen, Trennung fehlerhafter Datensätze und Prüfung des Ergebnisses im Zielsystem.
Mit dem Produktivstart endet die Verantwortung nicht. Zeitpunkt der letzten erfolgreichen Übertragung, Veröffentlichungsverzögerung, Alter der Fehlerwarteschlange und Unterschiede zwischen Quelle und Ziel sollten regelmäßig überwacht werden. Das Technikteam prüft die Verbindung, der Fachbereich Bedeutung und Nutzung der Daten. Datenverantwortung und nachhaltiges Qualitätsmanagement sind auch zentrale Themen im GS1-Datenqualitätsrahmen. [2]
Aus einer Verbindung einen steuerbaren Prozess machen
Listen Sie Quellen, Zielsysteme und priorisierte Datenfelder auf, bevor Sie Ihren Integrationsbedarf mit Apis Business Solutions besprechen. Ein klares Feldverzeichnis, Abnahmekriterien und Verantwortlichkeiten für Fehler konkretisieren den Projektumfang und machen den operativen Alltag besser planbar.
Quellen
- [1] Auto Care Association - Data Standards — Die unterschiedlichen Umfänge von Produkt- und Anwendungsdaten. https://www.autocare.org/data-standards
- [2] GS1 - What is the GS1 Data Quality Framework? — Ansatz für Qualitätsmanagement, Selbstbewertung und Validierung. https://support.gs1.org/support/solutions/articles/43000734211-what-is-the-gs1-data-quality-framework-