Sieben alte PIM-Systeme, ein moderner Produktkatalog.

Die Ausgangssituation

In gewachsenen Industrie- und Handelsunternehmen existiert häufig nicht das eine führende PIM-System. Unterschiedliche Geschäftsbereiche, Produktgenerationen, Regionen oder Akquisitionen haben eigene Datenquellen hervorgebracht. Manche Systeme werden aktiv gepflegt, andere nur noch für einzelne Sortimente benötigt. Hinzu kommen Excel-Dateien, Lieferantenfeeds und technische Datenbanken.

Das Ergebnis ist keine einheitliche Produktwahrheit, sondern eine verteilte Produktrealität:

• Dasselbe Produkt besitzt in mehreren Systemen unterschiedliche Kennungen.
• Attribute werden unterschiedlich benannt oder strukturiert.
• Ein Wert ist in einer Quelle aktueller, in einer anderen vollständiger.
• Varianten und Zubehörbeziehungen werden nicht einheitlich modelliert.
• Pflichtinformationen für Commerce oder Händler fehlen.
• Manche Produkte existieren mehrfach, ohne zuverlässig als Dublette erkannt zu werden.
• Verschiedene Empfänger benötigen unterschiedliche Ausschnitte und Formate.

Ein moderner Commerce-Katalog lässt sich aus dieser Situation nicht durch einen einmaligen Export erzeugen. Er benötigt eine dauerhaft betriebene Datenschicht.

Warum ein Datenimport nicht ausreicht

Die technische Übertragung ist nur der erste Schritt. Selbst wenn alle Systeme Dateien oder APIs bereitstellen, bleiben die fachlich schwierigen Fragen bestehen:

• Welche Datensätze beschreiben dasselbe Produkt?
• Welche Quelle ist für welchen Wert maßgeblich?
• Was passiert, wenn die formal aktuellere Quelle unvollständig ist?
• Dürfen technische Daten aus einer Quelle mit Marketingtexten aus einer anderen kombiniert werden?
• Wie werden Konflikte sichtbar?
• Wie bleibt nachvollziehbar, woher ein Wert stammt?
• Welche Qualitätsregeln müssen erfüllt sein, bevor ein Produkt veröffentlicht wird?
• Welche Informationen darf ein bestimmter Händler oder Vertriebskanal erhalten?

Wer diese Fragen nicht im System beantwortet, verschiebt die manuelle Arbeit lediglich vom PIM in den Commerce-Prozess.

Die zentrale Product-Data-Schicht

Ein sinnvoller Ansatz besteht darin, zwischen den bestehenden Quellen und den späteren Verbrauchern eine kontrollierte Product-Data-Schicht aufzubauen.

Die vorhandenen PIM-Systeme können zunächst weiterarbeiten. Die neue Schicht übernimmt ihre Daten regelmäßig oder ereignisbasiert, normalisiert sie und erzeugt daraus eine konsistente Sicht für die nachgelagerten Anwendungen.

Das reduziert das Risiko einer sofortigen Komplettmigration. Gleichzeitig entsteht eine moderne Grundlage, auf die neue Commerce- und Händlerprozesse aufbauen können.

Ein gemeinsames Datenmodell

Bevor Datensätze zusammengeführt werden können, braucht es ein gemeinsames fachliches Modell. Dieses Modell darf sich nicht einfach an der Struktur eines einzelnen Quellsystems orientieren. Es muss die Produktrealität des Unternehmens und die Anforderungen der Verbraucher abbilden.

Dazu gehören beispielsweise:

• Produkt und Produktfamilie
• Variante und Ausprägung
• technische Attribute
• Texte und Medien
• Kategorien und Taxonomien
• Zubehör und Beziehungen
• Gültigkeiten und Märkte
• Vertriebsfreigaben
• Übersetzungen
• Quellen und Aktualitätsinformationen

Das gemeinsame Modell ist nicht nur ein technisches Schema. Es definiert, wie das Unternehmen seine Produktinformationen systemübergreifend versteht.

Produktidentität vor Datenzusammenführung

Ein Golden Record setzt voraus, dass das System erkennt, welche Quellobjekte tatsächlich dasselbe Produkt beschreiben. Eine gemeinsame Artikelnummer wäre hilfreich, ist aber in gewachsenen Landschaften nicht immer vorhanden oder zuverlässig.

Die Identifikation kann deshalb mehrere Signale kombinieren:

• Hersteller- oder Artikelnummern
• interne Schlüssel
• Variantenbeziehungen
• technische Merkmale
• Produktfamilien
• EAN oder andere externe Kennungen
• definierte Mapping-Tabellen
• in geeigneten Fällen semantische Ähnlichkeit

Unsichere Zuordnungen sollten nicht stillschweigend zusammengeführt werden. Das System benötigt Grenzwerte, Prüfzustände und bei Bedarf eine manuelle Freigabe.

Welche Quelle hat recht?

Eine globale Regel wie „das neueste System gewinnt“ ist fast immer zu grob. Führende Quellen unterscheiden sich häufig nach Attribut, Produktgruppe oder Geschäftsbereich.

Beispiele:

• Technische Leistungswerte kommen aus einem Engineering-System.
• Marketingtexte werden in einem zentralen PIM gepflegt.
• Vertriebsfreigaben stammen aus dem ERP.
• Bilder liegen in einem DAM.
• Ein regionales System ist nur für bestimmte Märkte führend.
• Eine ältere Quelle bleibt für ein ausgelaufenes Sortiment weiterhin maßgeblich.

Die Prioritätslogik muss deshalb fachlich modelliert werden. Für jeden Wert sollte nachvollziehbar bleiben:

• aus welcher Quelle er stammt,
• wann er zuletzt aktualisiert wurde,
• welche Regel zu seiner Auswahl geführt hat,
• ob er automatisch oder manuell freigegeben wurde.

Golden Record statt blindem Überschreiben

Der Golden Record ist nicht einfach der zuletzt importierte Datensatz. Er ist das Ergebnis eines kontrollierten Entscheidungsprozesses.

Ein belastbarer Golden Record berücksichtigt:

• Identität des Produkts
• Herkunft jedes Attributs
• Priorität der Quellen
• Aktualität
• Vollständigkeit
• fachliche Plausibilität
• Freigabestatus
• Markt- und Kanalregeln

Wichtig ist außerdem, den Golden Record nicht als undurchsichtige Endstufe zu behandeln. Bei einem fehlerhaften Wert muss erkennbar sein, welche Quelle und welche Regel verantwortlich waren.

Validierung als laufender Prozess

Datenqualität entsteht nicht einmalig vor dem Launch. Quellsysteme verändern sich, neue Produkte kommen hinzu und bislang gültige Mappings werden unvollständig.

Deshalb benötigt die Product-Data-Schicht laufende Prüfungen:

• Pflichtfelder je Produktgruppe
• Wertebereiche und Datentypen
• Einheiten und Umrechnungen
• Beziehungen zwischen Varianten
• Vollständigkeit von Medien
• zulässige Kategorien
• unerwartete Mengenabweichungen
• ausgebliebene Datenlieferungen
• widersprüchliche Freigaben
• fehlerhafte oder neue Attribute

Die Ergebnisse müssen sichtbar und bearbeitbar sein. Eine Datenpipeline, die technisch erfolgreich durchläuft, kann fachlich trotzdem fehlerhafte Produkte erzeugen.

Unterschiedliche Ausleitungen

Ein gemeinsamer Produktbestand bedeutet nicht, dass jeder Verbraucher dieselben Daten im selben Format erhält.

Typische Ausleitungen sind:

• vollständiger Produktkatalog für Händler
• Commerce-Feed für den eigenen Shop
• inkrementeller Änderungsfeed
• REST- oder GraphQL-API
• Suchindex für schnelle Filterung und Volltextsuche
• marktspezifische Kataloge
• geschäftsbereichsspezifische Sichten
• Export für Marktplätze oder Partner

Die Product-Data-Schicht trennt damit die Komplexität der Quellen von den Anforderungen der Verbraucher.

Abschluss

Ähnliche Situationen entstehen überall dort, wo Produktinformationen über Jahre in mehreren Systemen gewachsen sind. Entscheidend ist nicht nur die technische Anbindung, sondern ein nachvollziehbares Regelwerk für Identität, Qualität, Herkunft und Bereitstellung.