Viele PIM-Initiativen beginnen mit Vendor-Demos. Man vergleicht Feature-Listen, wählt ein System aus, der Rollout-Plan steht. Erst danach beginnt die Auseinandersetzung mit den eigenen Produktdaten. Spätestens nach wenigen Wochen zeigt sich, dass die Produkt- und Prozessrealität nicht ins gewählte System passt. Es folgt Custom-Logik, verschobene Deadlines und ein halbes Jahr später ein PIM, das sich nicht wie vorgesehen nutzen lässt. Nicht, weil die Anwender:innen es nicht könnten, sondern weil Datenmodell, Workflows und Zuständigkeiten vorher nicht klar genug waren.

Ob ein Projekt nach dem Go-live trägt, entscheidet sich schon vor der Implementierung in einer Phase, die wir »Discovery« oder Vorprojekt nennen. Zu oft wird sie schlicht übersprungen.

Ein PIM ist ein Verwaltungssystem für Produktdaten. Es strukturiert, versioniert, verteilt und reichert sie mit Attributen und Assets an. Was es nicht tut: ein Datenmodell erfinden, das im Unternehmen nicht existiert. Es klärt keine Verantwortlichkeiten, definiert keine Pflegeprozesse, ersetzt keine fehlende Architektur-Entscheidung.

Wer das übersieht, kauft Software für ein Problem, das vorher organisatorisch zu lösen wäre. Ein PIM ersetzt keine Data Governance und kein Master Data Management. Fehlen diese im Unternehmen, kann ein PIM ihre Einführung unterstützen – aber nur, wenn vorher feststeht, wer welche Felder pflegt und welcher Datensatz im Zweifel gilt. Ohne diese Klärung tauchen die Probleme spätestens beim Datenimport auf.

Aus unseren Projekten lassen sich drei Themenfelder isolieren, in denen die größten Risiken liegen. Sind sie nicht durchdacht, wird die Einführung kostspielig und langwierig, ganz unabhängig davon, welches System gewählt wird.

Das Produktdatenmodell

Die wichtigste Frage beim Produktdatenmodell ist, welche Art von Attributen es gibt und wie sie voneinander abhängen, denn daraus ergeben sich die Varianten. Die reine Produktmenge ist dagegen das einfachere Kriterium: Manche Systeme verarbeiten Millionen Produkte, andere stoßen früher an ihr Limit. Dazu kommt die Datenqualität, denn Produktdaten landen in Feldern, die nicht dafür gedacht sind, oder dasselbe Attribut meint an zwei Produkttypen Verschiedenes, ein Feld »Breite« etwa. Solche Fälle wirken direkt aufs Modell zurück.

Bei den Varianten lohnt die genaue Frage: Existieren sie innerhalb eines Produkttyps, oder lassen sie sich aus den vorhandenen Daten überhaupt sinnvoll erzeugen? Über welche Achsen werden sie gebildet und welche Attribute lassen sich für welchen Produkttyp auf welcher Ebene pflegen?

Die Antworten finden sich selten in einem System. Produktmanagement weiß, wie das Sortiment gedacht ist, Category Management, wie es im Shop strukturiert sein soll, ERP-Verantwortliche kennen die Stammdatenlogik. Was fehlt, ist eine systemunabhängige Beschreibung, die diese Sichten zusammenführt.

Ein praxisnaher Einstieg ist die Modellierung an echten Produkten: Zwei Dutzend repräsentative Artikel reichen, inklusive der Frage, an welchen sich überhaupt Varianten bilden lassen. Dabei tauchen die Konflikte auf, die später jedes System ans Limit bringen: überlappende Attributdefinitionen, Sonderfälle ohne Zuordnung, Sortimentsbereiche mit gegensätzlicher Logik. Sie gehören in die Konzeption, nicht in die Konfiguration eines bereits gekauften Tools. Bei einem B2B-Händler etwa war eine automatisierte Migration der Bestandsdaten unmöglich, weil das alte Modell die Produktwelt nie sauber abgebildet hatte. Der Aufwand entstand nicht im PIM, sondern davor, im Aufräumen einer Logik, die seit Jahren niemand hinterfragt hatte.

Die Prozesse

Stammdaten aus dem ERP, Texte aus dem CMS oder von der Agentur, Bilder aus dem DAM oder vom Hersteller, technische Daten aus Lieferantenkatalogen, dazu Übersetzung, Variantenpflege und Qualitätskontrolle in wieder anderen Rollen: Ein PIM wird fast nie von einer einzigen Abteilung bedient. Vor dem Go-live muss klar sein, wer welche Daten in welcher Reihenfolge pflegt und freigibt.

Das klären wir entlang der Abteilungen, nicht entlang des Produkts. In Deep Dives mit den Teams, die wirklich mit Produktdaten arbeiten, halten wir fest, wer was anlegt, anreichert und freigibt und über welche Wege (E-Mail, Excel, Ticket) die Daten wandern. Das schärft zugleich das Datenmodell und nimmt die Beteiligten früh mit, denn ein neues System verändert ihre Arbeit. Das wiederkehrende Signal dabei ist fast immer dasselbe: Die Time-to-Market ist zu lang. Genau dort setzt die Prozessaufnahme an, nicht bei der Reibung im Detail.

Erst auf dieser Grundlage wird die Vendor-Frage konkret. Akeneo etwa glänzt mit nahtlosen Prozessen und parallelem, berechtigungsbezogenem Arbeiten mit Rollen, Workflows und Benachrichtigungen. Centric PXM denkt vom Produktlebenszyklus her und passt, wo PLM-Aspekte in die Arbeit mit Produktdaten hineinreichen.

Ohne beschriebenen Pflegeprozess entscheidet die Feature-Liste, und die Prozesse sollen sich später ans System anpassen. Das funktioniert selten.

Die Architektur

Ein PIM steht nie allein. Es ist eingebettet in eine Landschaft aus ERP, Shop oder Marketplace, DAM, Lieferantensystemen, mitunter einem Data Hub. Die Architektur-Bewertung beantwortet dafür drei Fragen: Wo muss das PIM sitzen, wer hält welche Daten, und wie fließen sie?

Wo sitzt das PIM? Seine Position in der Kette ist von Fall zu Fall verschieden. Mal steht es am Anfang und vergibt selbst die SKU, mal hängt es am ERP, mal treibt ein PLM den Produktlebenszyklus, nicht ohne Grund hat Centric mit Contentserv ein PIM gekauft, das an sein PLM anschließt. Auch zu Lieferanten gibt es keine feste Richtung: mal ist das PIM das Portal, in das sie einspielen, mal spielt es selbst an einen Marktplatz aus. Die relevante Frage ist daher nicht, ob ein PIM angebunden wird, sondern an wie viele Systeme und in welche Richtung.

Wer hält welche Daten? Vor dem Vendor-Gespräch lohnt eine Bestandsaufnahme: Welche Systeme halten heute welche Daten, wo ist das PIM führende Quelle, wo nur Konsument? Ziel ist, dass jede Information dort gepflegt wird, wo sie entsteht oder gebraucht wird, und nicht an zwei Stellen. Für mindestens eine Datenkategorie muss das PIM führen, sonst fehlt die Begründung für seinen Einsatz. Das betrifft besonders das ERP: Fehlt ein Attribut, heißt es schnell »legen wir im ERP an«, obwohl es dort nie gebraucht wird, sondern auf der Website oder im Katalog. Ins ERP gehört ein Attribut nur, wenn das System aktiv damit arbeitet, etwa für Versandkosten oder, wie bei Riese & Müller, für Preisschilder mit Barcode im Showroom. Sonst bläht es sich auf, bis es kaum noch zu warten ist.

Wie fließen die Daten? Nach innen nimmt das PIM Daten auf und führt sie zusammen, nach außen verteilt es sie, oft in unterschiedlicher Form: Dasselbe Produkt geht an B2B und B2C, die einen wollen fachliche Informationen, die anderen Marketing; ein Druckmedium hat weniger Platz als eine Produktseite. Dabei lohnt es, die Zahl der Ausgabekanäle und Sprachen niedrig zu halten. Ein eigener Kanal ist nur nötig, wenn sich die Daten für die Empfänger wirklich unterscheiden. Wer in Akeneo drei Channels mit identischen Daten anlegt, hat das Konzept missverstanden.

Dass Daten zwischen den Systemen nicht immer unverändert fließen, zeigt Riese & Müller. Hier war die Erkenntnis, dass es zuerst eine eigene Datendrehscheibe brauchte: einen Data Hub, der Daten konsumiert, harmonisiert und verteilt. Er machte das blockierte ERP wieder funktionsfähig und war überhaupt erst der Enabler, um Daten zwischen den Systemen auszutauschen.

Wo eine Discovery solche Fälle aufdeckt, gehören Custom-Konnektoren und eine Transformationsschicht in die Architektur, die Daten vorher aufbereiten, aggregieren oder zusammenführen.

Eine konsequent durchgeführte Discovery kann zu dem Ergebnis kommen, dass die Antwort »noch nicht« lautet. Oder dass eigentlich ein ganz anderer Schritt gegangen werden muss.

»Readiness« zeigt sich an konkreten Signalen. Das Sortiment ist groß und heterogen genug, dass die Spreadsheet-Pflege spürbar an ihre Grenzen stößt. Mehrere Kanäle wollen unterschiedliche Datenausschnitte aus derselben Quelle. Es gibt eine Person oder ein Team, das die Verantwortung für Produktdaten organisatorisch übernehmen kann, nicht nur operativ pflegen. Stammdaten- und Marketinginhalte lassen sich logisch trennen, statt vermischt im selben System zu liegen. Und eine konkrete KI-Roadmap braucht strukturierte Produktinformationen als Input.

Fehlen mehrere dieser Signale, lohnt sich vor dem PIM oft ein anderer Schritt: eine Bereinigung der ERP-Stammdaten, ein Data-Hub-Konzept, eine klare Owner-Definition für Produktdaten. Das PIM kommt dann später, mit weniger Reibung und einem klareren Auftrag.

Eine saubere Discovery endet nicht mit einem Slide-Deck und einer Empfehlung. Sie liefert drei Artefakte, die für die Vendor-Auswahl und das spätere Implementierungsprojekt arbeiten.

Erstens ein dokumentiertes Produktdatenmodell, getestet an einem repräsentativen Ausschnitt des Sortiments, mit echten Attributen, Varianten und Hierarchien. Zweitens eine Prozessübersicht, die festhält, welche Rolle welche Daten in welcher Reihenfolge pflegt, inklusive der Schnittstellen zu anderen Abteilungen und externen Datenlieferanten. Drittens eine Architektur-Bewertung, die die heutige Systemlandschaft kartiert, Datenhoheiten definiert und benennt, welche Anbindungen das PIM-Projekt aufwändig machen werden.

Auf dieser Grundlage lässt sich eine Vendor-Entscheidung an konkreten Kriterien festmachen. Und die Implementierung beginnt nicht mit einer weiteren Konzeptionsphase, sondern direkt mit der Umsetzung eines durchdachten Modells.

In der Praxis dauert eine PIM-Discovery zwischen vier und acht Wochen, je nach Sortimentsbreite, Anzahl der beteiligten Quellsysteme und Teams. Wirksam wird sie nur, wenn die richtigen Personen am Tisch sitzen: operative Produktdatenpflege, Category Management, ein IT-Architekt mit Überblick über die Schnittstellen und jemand aus Vertrieb oder Marketing, der die Ausspielseite kennt. Sie alle gehören nicht nur befragt, sondern ins Projekt mitgenommen. Läuft die Discovery rein über die IT, entsteht eine technisch saubere Architektur, die an der operativen Realität vorbeigeht. Ohne IT entsteht vielleicht ein ausgefeiltes Datenmodell, das später an den Schnittstellen hängenbleibt.

Ob ein PIM-Projekt gelingt, entscheidet sich nicht erst beim Go-live. Es entscheidet sich in den Wochen, in denen geklärt wird, was das System eigentlich tun soll: für wen, mit welchen Daten, in welcher Architektur.

Diese Klärung als reine Vorstufe zu behandeln, schiebt die wichtigste Entscheidung im PIM-Projekt an den Rand. Eine stringente Discovery sorgt dafür, dass die Implementierung mit einem Werkzeug startet, das zur eigenen Realität passt. Ohne diese Vorarbeit bleibt die Hoffnung, dass beides später irgendwie zusammenfindet. Und die trägt selten bis zum Go-live.