Die meisten PIM-Projekte scheitern nicht, weil die Software falsch war. Sie scheitern wegen Entscheidungen, die Wochen oder Monate vor dem Go-live getroffen wurden: übersprungene Datenmodellierung, unterschätzte Migrationsbemühungen, Integrationen, die auf „Phase 2" verschoben werden. Die Probleme sind vorhersehbar. Das gilt auch für die Lösungen.
Kauf vor der Reife
Der häufigste Fehler bei einer PIM-Implementierung passiert, bevor sie beginnt: Eine Plattform wird ausgewählt, während der interne Prozess noch undefiniert ist.
Teams vereinbaren Herstellerpräsentationen, vergleichen Preismodelle und verhandeln über Verträge, während ihre Produkttaxonomie inkonsistent ist, ihre Datenquellen unklar sind und niemand festgelegt hat, wer für Produktdaten verantwortlich ist. Das PIM wird gekauft. Dann wartet es, während die interne Abstimmung aufgeholt wird.
Ein PIM löst kein Prozess-Problem. Es schafft Infrastruktur, um einen Prozess darauf auszuführen. Wenn der Prozess nicht definiert ist, schichten Sie nur eine teure Ebene auf das gleiche Chaos.
Vor der Erstellung einer Shortlist sollten mindestens zwei Dinge geklärt sein: Sie kennen die Systeme, die derzeit Produktdaten enthalten und die das PIM speisen werden, und Sie haben einen klaren internen Verantwortlichen für Produktdatenqualität. Ohne diese Basis ist die Herstellerauswahl verfrüht. Der Channel-Umfang und die Produktfamilienstruktur können später verfeinert werden, aber die Dateneigentümerschaft und die Quellzuordnung müssen vor jeder Plattformdiskussion etabliert sein.
PIM-Implementierung beginnt mit Datenvorbereitung
Die Datenmigration ist durchweg die am meisten unterschätzte Phase jeder PIM-Implementierung. Beginnen Sie mit dem PIM-Implementierungsplan. Teams rechnen mit zwei Wochen. Es dauert sechs.
Die Diskrepanz kommt fast immer aus der gleichen Quelle: Produktdaten sind über mehrere Systeme verteilt, ohne eine zentrale Quelle der Wahrheit. Die Attributbenennung unterscheidet sich zwischen ERP und Legacy-Tabellenkalkulationen. Doppelte Datensätze, deren Existenz niemand realisiert hat, tauchen bei der Überprüfung auf. Fehlende Werte kommen nur ans Licht, wenn jemand versucht, sie auf ein Zielfeld abzubilden. Jedes dieser Probleme ist für sich genommen handhabbar. In Kombination verwandelt sich ein zweiwöchiger Schätzwert in eine sechswöchige Realität.
Lieferantendaten sind ein eigenes Problem. Hersteller, die Produktspezifikationen von Dutzenden von Lieferanten beziehen, stellen normalerweise fest, dass jeder Lieferant Daten in einem anderen Format mit unterschiedlichen Feldnamen, verschiedenen Einheiten und unterschiedlichen Vollständigkeitsstufen liefert. Die Normalisierung dieser Daten vor dem Import ist keine kleine Aufgabe.
Bei Projekten, die wir für Hersteller von Industrieausrüstung durchgeführt haben, zeigte die Datenüberprüfung regelmäßig, dass 30 bis 40% der Produktattribute über die Quellsysteme hinweg unvollständig oder inkonsistent waren. Diese Erkenntnis überraschte den Kunden jedes Mal, auch wenn der Katalog relativ klein war.
Überprüfen Sie, was vorhanden ist, deduplizieren Sie, bereinigen Sie, ordnen Sie Quellenfelder Zielattributen zu und einigen Sie sich darauf, was „ausreichend zur Migration" bedeutet, bevor Sie beginnen. Dieser letzte Punkt ist wichtig. Ohne eine klare Definition der akzeptablen Datenqualität zum Migrationszeitpunkt wird die Migration nie offiziell abgeschlossen.
Inriver zitiert McKinsey-Forschung, die die Kosten schlechter Datenqualität auf bis zu 30% der verschwendeten Unternehmenszeit beziffert. Die Kosten entstehen nicht nur durch die Migrationsbemühungen selbst. Es sind alle Wochen danach, in denen Teams um schlechte Daten herumarbeiten, anstatt sie zu verwalten.
Datenmodellierung bei PIM-Implementierung überspringen
Vorbereitung ist das Bereinigen und Migrieren von dem, was Sie haben. Modellierung ist die Entscheidung, wie die Datenstruktur aussehen soll. Das ist unterschiedliche Arbeit, und das Überspringen der Modellierung ist der Fehler, der die meiste Nacharbeit verursacht.
Teams importieren Produktdaten in das PIM, ohne zuvor Produktfamilien, Attributgruppen, Maßeinheiten oder die Beziehungen zwischen Produkten zu definieren. Das PIM wird bevölkert. Dann wird sechs Monate später klar, dass die Struktur nicht damit übereinstimmt, wie die Produkte tatsächlich präsentiert werden müssen, und große Teile müssen neu aufgebaut werden.
Die Modellierungsphase dauert, wenn sie richtig durchgeführt wird, typischerweise zwei bis vier Wochen. Die meisten Teams sehen das als Verzögerung. Das ist die Arbeit, die zum richtigen Zeitpunkt erledigt wird.
Produktbeziehungen sind die häufigste Sache, die übersehen wird. Ein Industriesensor, der mit kompatiblen Befestigungsbügeln, Kalibrierungszubehör und Ersatzteilen verbunden ist, hat eine implizite Struktur, die explizit modelliert werden muss. Überspringen Sie das anfangs und Sie flicken es später unbeholfen. Die Variantenlogatik ist eng verwandt: Wenn das Modell nicht klar trennt, welche Attribute eine Variante definieren und welche über eine Produktfamilie hinweg gemeinsam sind, wird der Katalog mit dem Wachstum schwer zu verwalten. Channel-spezifische Attribute sollten auch in der Modellierungsphase angesprochen werden und nicht nach dem Anreichern begonnen hat. Was der Webshop braucht, was in einen gedruckten Katalog geht und was Einzelhandelspartner erfordern, unterscheiden sich oft erheblich. Diese Unterscheidung nachträglich zu implementieren ist immer schmerzhafter als sie von Anfang an einzubauen.
Das konfigurierbare Datenmodell von AtroPIM ermöglicht es Teams, Produktfamilien, Attributgruppen und Beziehungen ohne Beteiligung von Entwicklern zu definieren und zu ändern, was die Iteration während der Modellierungsphase schneller macht. Die Flexibilität hilft nur, wenn die Modellierungsarbeit bewusst durchgeführt wird. Ein konfigurierbares System mit einem schlecht durchdachten Modell gibt Ihnen einfach mehr Strick.
Falsche Teamstruktur
PIM-Implementierungen, die aus dem Ruder laufen, haben normalerweise eines gemeinsam: Niemand besitzt die Daten.
Der Projekteigentümer ist verantwortlich für Umfang, Zeitplan und Entscheidungen bei Prioritätskonflikten. Das ist normalerweise ein Produktmanager oder Betriebsleiter, kein IT-Manager. Der technische Architekt kümmert sich um Integrationen, Importlogik und Infrastruktur. Beide Rollen werden normalerweise ohne große Debatten besetzt.
Der Datenmanager ist derjenige, der übersprungen wird. Diese Person besitzt die Datenqualität vor, während und nach der Migration: Sie führen die Überprüfung durch, koordinieren die Bereinigung, definieren Attributstandards und werden zur internen Autorität für das, was in das PIM geht. Ohne einen benannten Datenmanager werden diese Aufgaben informell über jeden verteilt, der Zeit hat. Sie werden nicht konsistent erledigt, und die Probleme tauchen spät auf.
In kleineren Unternehmen könnte eine Person zwei dieser Rollen tragen. Das funktioniert. Die Konfiguration, die nicht funktioniert: IT besitzt das Projekt, weil sie die Software bereitstellt, aber niemand ist zuständig für die Datenqualität. Die Datenvorbereitung wird zu jedem Problem, was bedeutet, dass sie zu niemandem Problem wird. Wir haben Implementierungen in genau dieser Konfiguration monatelang stagnieren sehen, mit sauberen Daten, die halbvorbereitet über drei verschiedene Tabellenkalkulationen verteilt sind, weil keine einzelne Person die Autorität hatte, sie zu konsolidieren und abzuschließen.
Eine PIM-Implementierung ohne einen benannten Datenmanager ist ein Datenqualitätsproblem, das zum ungünstigsten Moment auftaucht: mitten in der Migration oder zwei Wochen vor dem Go-live.
Warum PIM-Implementierungs-Integration verschoben wird
ERP-Integrationen und E-Commerce-Integrationen werden bei PIM-Implementierungen überraschend oft als „Phase 2" geplant. Die Begründung klingt auf dem Papier logisch: Bringen Sie das PIM zum Laufen, dann verbinden Sie die Systeme. In der Praxis kommt Phase 2 selten sauber an.
Das PIM geht mit manueller Dateneingabe als Übergangsprozess live. Der Übergangsprozess wird permanent, weil es immer etwas Dringlicheres gibt als das Integrationsprojekt. Sechs Monate später verwaltet das Team zwei parallele Datenerfassungs-Workflows und das PIM ist nicht die zentrale Datenquelle, die es sein sollte.
Der Integrations-Umfang muss von Anfang an definiert werden, nicht verschoben. Nicht jede Integration muss am ersten Tag live sein. Aber die Integrationsarchitektur sollte von Anfang an entworfen werden, Datenflüsse zwischen Systemen kartographiert und der Build als Teil der Implementierung ressourciert werden, auch wenn der Rollout gestaffelt ist.
AtroPIM enthält native Connectoren für gängige ERP- und E-Commerce-Plattformen, was den Integrations-Build-Aufwand erheblich reduziert. Die Existenz des Connectors ist irrelevant, wenn die Integration nicht vor dem Go-live geplant und ressourciert wird.
Go-live ohne Pilot
Ein großer Bang-Go-live, bei dem das PIM alle vorherigen Systeme über alle Kanäle an einem einzelnen Datum ersetzt, ist der höchste Risiko-Rollout-Ansatz. Das ist aber auch der häufigste, weil er sauberer und schneller wirkt.
Fehler in dieser Größenordnung sind schwer einzudämmen. Wenn das Datenmodell Lücken hat, sind alle Kanäle und alle nachgelagerten Systeme gleichzeitig betroffen. Wenn die Benutzerunterstützung langsam ist, verlangsamt sich der gesamte Betrieb damit. Und UAT, das mit Testdaten durchgeführt wird, erfasst fast nie, was echte Benutzer treffen, wenn sie mit Live-Produktdaten im vollständigen Katalog-Maßstab arbeiten.
Ein gestaffelter Rollout reduziert dieses Risiko. Wählen Sie eine Produktkategorie oder einen Kanal aus und durchlaufen Sie zunächst einen vollständigen Zyklus durch das PIM. Verwenden Sie es als echte Test. Beheben Sie, was bricht. Dann erweitern Sie.
Die Hersteller, die die reibungslosesten PIM-Implementierungen durchgeführt haben, die wir gesehen haben, starteten mit 10 bis 15% ihres Katalogs. Sie behandelten die erste Phase als echte Validierung und bauten Vertrauen auf, bevor sie skaliert wurden.
Der gestaffelte Ansatz schafft auch interne Verfechter. Ein Team, das das PIM erfolgreich für eine Produktlinie vor dem vollständigen Rollout verwendet hat, wird zur Gruppe, die alle anderen trainiert. Diese Verschiebung der internen Eigentümerschaft führt normalerweise zu schnellerer Annahme als jede formale Change-Management-Programm.
Keine Erfolgskennzahlen vor dem Start
PIM-Implementierungsprojekte gehen oft live, ohne definierte KPIs. Das macht es unmöglich, die ROI danach zu demonstrieren, und macht laufende Prioritätierung willkürlich.
Die Metriken, die verfolgt werden sollten, hängen vom Grund für die PIM-Implementierung ab. Häufige: Daten-Vollständigkeitsquote nach Produktfamilie, Zeit-zu-Markt für neue Produkte, Anzahl der Datenfehler, die die nachgelagerten Kanäle erreichen, und Reduzierung der manuellen Export-Arbeit pro Woche. Für Hersteller ist ein nützliches Substitut, wie lange es dauert, Produktdaten eines neuen Lieferanten von Rohdateien bis zum veröffentlichten Katalog onzuboarden. Unser PIM-Implementierungs-Leitfaden behandelt, wie diese Metriken im breiteren Projektplan strukturiert werden.
Definieren Sie diese KPIs vor dem Go-live, nicht danach. Ohne Basis können Sie keine Verbesserung zeigen. Und ohne messbare Verbesserung wird die nächste Budgetanfrage für zusätzliche Module oder Personal ein viel schwierigeres Gespräch.
Keine Governance nach Go-Live
Das PIM wird ohne definierte Datenqualitäts-Eigentümerschaft nach dem Start veraltet. Dieser Schritt wird fast immer übersprungen.
Go-live ist nicht das Ende des PIM-Implementierungsprojekts. Jemand muss die laufenden Fragen besitzen: Wer genehmigt neue Attributtypen, wer löst Konflikte auf, wenn zwei Teams widersprüchliche Werte eingeben, wie ist der Überprüfungs-Rhythmus für Daten-Vollständigkeit und wie werden neue Produktfamilien modelliert, wenn der Katalog wächst. Da regulatorische Anforderungen wie der EU Digital Product Passport expandieren, muss der Governance-Rahmen auch Daten auf Produktebene berücksichtigen, die beim Launch nicht erforderlich waren.
Ein praktisches Minimum: Bestimmen Sie eine Person als laufenden Daten-Verwalter, definieren Sie eine monatliche Überprüfung der Daten-Vollständigkeit nach Kategorie, und dokumentieren Sie den Prozess zum Hinzufügen neuer Attribute. Das reicht aus, um die meiste Entropie zu verhindern, die die PIM-Datenqualität über die Zeit verschlechtert.
McKinsey-Forschung zur digitalen Transformation beziffert die Fehlerquote von Software-Implementierungen auf 70%, mit schlechter Benutzerunterstützung als Hauptursache. Ein PIM, das das Team verwirrend oder losgelöst von täglichen Arbeitsabläufen findet, wird minimal verwendet, unabhängig von seinen technischen Fähigkeiten. Annahme-Planung ist kein separater Workstream. Sie gehört von Anfang an in das Implementierungsprojekt.
Was Erfolg bestimmt
PIM-Implementierungen, die über die Zeit standhalten, teilen ein Muster: Teams investierten mehr in Vorbereitung als geplant und hielten den Launch-Umfang kleiner als Stakeholder wollten. Diese Kombination ist unbequem, intern zu verteidigen, wenn es Druck gibt, schnell Ergebnisse zu zeigen. Sie funktioniert konsequent.
Die Softwareauswahl ist weniger wichtig als das. Ein gut implementiertes PIM auf einer flexiblen, konfigurierbaren Plattform wird ein schlecht implementiertes auf einem technisch überlegenen System übertreffen. AtroPIM ist genau für diese iterative Herangehensweise gebaut: Kernfunktionalität zuerst, mit Modulen, die es ausbauen, wenn Bedarf wächst, und vollständige Kontrolle über das Datenmodell durchweg.