Migration von Produktdaten aus einer Altsystem-Datenbank in ein modernes PIM: eine Checkliste

Die meisten „PIM-Einführungsprojekte“ scheitern nicht am PIM selbst. Sie scheitern an den Daten, an den über Jahre hinweg gesammelten Produktinformationen, die in einer alten Datenbank schlummern, die sich seit dem Weggang des Entwicklers niemand mehr genauer ansehen wollte.

Dies ist eine praktische Checkliste für die Datenebene einer PIM-Migration. Nicht die Anbieterauswahl, nicht der Rollout-Plan, nicht das Change Management. Sondern nur der Teil, bei dem Sie komplexe Produktdaten aus einem System, das vor zwölf Jahren für ein anderes Geschäft konzipiert wurde, in ein PIM übertragen müssen, das seine eigenen Vorstellungen davon hat, wie Produktdaten gestaltet sein sollten.

Bevor Sie das neue PIM in Betrieb nehmen

Erfassen Sie den Bestand des Altsystems, einschließlich der Elemente, die niemand dokumentiert hat. Jede seit Langem betriebene Datenbank verfügt über ein „offizielles“ Schema und ein paralleles, informelles Schema. Letzteres findet sich in Spaltenkommentaren, Namenskonventionen und in den Köpfen von drei Personen. Finden Sie beide. Die Migration scheitert am informellen Schema, nicht am dokumentierten.

Legen Sie fest, welche Quelle maßgeblich ist. Für jedes Attribut gilt: Wo befindet sich der aktuelle Stand der Dinge? Im Katalogsystem, in der Tabellenkalkulation, im ERP-System oder im Lager? Eine Datenmigration ohne Klärung dieser Frage verlagert den Widerspruch lediglich in das neue PIM.

Dokumentieren Sie die impliziten Regeln. „Produkte, die mit K- beginnen, sind immer Fahrzeuge, mit Ausnahme derjenigen aus dem Jahr 2014.“ Dieser Satz wird irgendwo in den Daten vorkommen. Notieren Sie ihn vor der Migration, nicht danach.

Die Datenschicht

Führen Sie die Schemaabbildung schrittweise durch. Die verlockende Vorgehensweise ist eine einzige große Zuordnungstabelle: alte Spalte → neues Feld. Die richtige Vorgehensweise erfolgt jedoch attributweise, mit eindeutiger Semantik: Was bedeutete das Attribut in der Quelle, was bedeutet es im Ziel, und wie ist vorzugehen, wenn diese Bedeutungen voneinander abweichen?

Gehen Sie explizit mit inkonsistenten historischen Daten um. Produktnamen ändern ihre Schreibweise, Maßeinheiten unterliegen neuen Konventionen, und Attribute werden im Laufe der Jahre stillschweigend umfunktioniert. Entscheiden Sie für jeden Einzelfall: Bereinigung während der Migration, Bereinigung danach oder unveränderte Übernahme. Wechseln Sie nicht zwischen diesen drei Vorgehensweisen pro Attribut hin und her. Legen Sie eine Regel fest.

Modellieren Sie die Beziehungen, nicht nur die Felder. Dies gilt insbesondere für Bereiche, in denen die Daten von Grund auf relational sind: Autoteile in Bezug auf die Fahrzeugkompatibilität, Zubehör in Bezug auf Basisprodukte, Varianten in Bezug auf Stammdaten. Die Schema-Zuordnung ist einfach; bei der Semantik der Beziehungen hat sich das Altsystem jedoch still und leise von der Realität entfernt.

Beseitigen Sie Mehrdeutigkeiten bei überladenen Attributen. Eine einzelne Spalte in der alten Datenbank hat je nach Produktkategorie oft drei verschiedene Bedeutungen. Diese in korrekte, eindeutige PIM-Attribute aufzuteilen, ist zwar keine glanzvolle Aufgabe, aber unerlässlich. Andernfalls übernimmt das neue PIM dieselbe Überladung, und die Migration war reine Show.

Die Mechanismen der Migration

Verwenden Sie strukturierte Exporte und keine direkten Datenbank-zu-Datenbank-Verbindungen. Exportieren Sie die Altdaten in ein strukturiertes Zwischenformat (CSV, JSON, ein XML-Profil oder was auch immer das Ziel-PIM problemlos verarbeiten kann). Das Zwischenformat bietet Ihnen zwei Vorteile: eine überprüfbare Aufzeichnung dessen, was tatsächlich migriert wurde, und einen sicheren Ort, an dem Sie Transformationen vornehmen können, ohne entweder die Quelle oder das Ziel zu berühren.

Automatisieren Sie die Importe, aber versehen Sie sie mit Versionsangaben. Jeder erfolgreiche Import sollte anhand desselben Exports reproduzierbar sein. Wenn drei Wochen nach der Umstellung in der Produktion ein Fehler auftritt, möchten Sie in der Lage sein, genau den Migrationsschritt erneut auszuführen, mit dem die betroffenen Produkte geladen wurden.

Achten Sie auf Idempotenz. Ein erneuter Durchlauf der Migration darf keine Duplikate erzeugen, Daten überschreiben und damit verlieren oder nur teilweise angewendet werden. Idempotenz ermöglicht es Ihnen, während der Einführung mehrere Durchläufe durchzuführen. Ohne sie ist jeder Durchlauf der Migration ein Einwegvorgang, und die Nutzer werden aufhören, sie auszuführen.

Stimmen Sie die Daten ab, statt sie nur zu zählen. Eine erfolgreiche Zeilenzählung ist noch keine erfolgreiche Migration. Stimmen Sie die Feldwerte für eine aussagekräftige Stichprobe ab, einschließlich der Produkte, von denen Sie wissen, dass sie Unregelmäßigkeiten aufweisen. Die als problematisch bekannten Produkte dienen als Indikator für den Rest.

Nach der Umstellung

Prüfen Sie die Anwendbarkeit anhand der operativen Anwendungsfälle, nicht nur anhand der Daten. Öffnen Sie das neue PIM und gehen Sie die Arbeitsabläufe durch, die das Team tatsächlich nutzen wird: Suchen Sie nach diesem Attribut, filtern Sie nach jener Kategorie, exportieren Sie in das Format, das das Katalogteam benötigt. Daten, die zwar im Speicher korrekt sind, aber für den Arbeitsablauf ungeeignet sind, bedeuten dennoch eine fehlgeschlagene Migration.

Verhindern Sie, dass das alte System weiterhin maßgeblich bleibt. Solange die Altsystem-Datenbank noch in irgendeinem Betriebsablauf eingebunden ist, beginnt die Abweichung in dem Moment, in dem die Umstellung abgeschlossen ist. Nehmen Sie zunächst die Schreibpfade außer Betrieb, auch wenn die Lesepfade noch ein Quartal lang bestehen bleiben.

Passen Sie die Prozessänderungen zeitgleich an. Produktdatenmigrationen scheitern in der Endphase, wenn das Team weiterhin nach den alten Methoden arbeitet, während es bereits mit dem neuen System arbeitet. Schulungen zu Arbeitsabläufen, die Zuweisung von Verantwortlichkeiten für Attribute und Aktualisierungsprozesse sollten bereits bei der Migration erfolgen, nicht erst danach.

---

Wenn Sie vor einer PIM-Migration stehen und die Datenschicht der Teil ist, der Ihnen Angst macht, dann ist das genau der Teil, den wir normalerweise von Anfang bis Ende übernehmen würden. Der PIM-Anbieter verkauft Ihnen die Plattform; die Migration ist ein technisches Problem für sich.