Brownfield ist der Normalfall: Warum PIM-Projekte am Umzug scheitern – und nicht am Ziel

Auf der grünen Wiese lässt sich hervorragend planen. Nur steht dort nie ein Unternehmen.

Jede PIM-Demo, die Sie je gesehen haben, war ein Greenfield-Projekt: ein sauberer Katalog, ein konsistenter Attributsatz, ein Kategoriebaum, der aussieht, als hätte ihn jemand entworfen. Ihr Sortiment sieht anders aus. Es hat vierzehn Jahre Historie, drei Excel-Generationen, ein ERP, das versehentlich zum Stammdatensystem geworden ist, und einen Lieferantenfeed, den seit 2019 niemand mehr anfasst – weil niemand weiß, was passiert, wenn man es tut.

Das ist kein Sonderfall. Das ist der Normalfall.

Die entscheidende Frage in einem PIM-Projekt ist nicht, welches System das beste ist. Sie ist, was mit den Daten passiert, die Sie schon haben.

PIM-Projekte scheitern selten an der Software

Wenn ein PIM-Projekt kippt, dann fast nie im Feature-Vergleich. Es kippt in der Migration.

Die Zahlen dazu sind unangenehm eindeutig: Laut Gartner scheitern 83 Prozent aller Datenmigrationsprojekte oder überschreiten Budget und Zeitplan. Nicht 83 Prozent der Softwareauswahlen – der Migrationen.

Der Grund dafür steht in keinem Projektplan. Er heißt Migrationsschuld: die Summe aller Altlasten, die Sie mitnehmen müssten, damit das neue System an Tag eins funktioniert. Migrationsschuld taucht in keinem Budget als Position auf, weil sie sich vor dem Projekt nicht seriös schätzen lässt. Sichtbar wird sie erst, wenn jemand versucht, das alte Datenmodell auf das neue abzubilden – und feststellt, dass die alten Daten nie dafür gedacht waren, verstanden zu werden. Sie waren dafür gedacht, gespeichert zu werden.

Die drei Altlasten, die jedes Brownfield-Projekt teuer machen

Erstens: Attributchaos. Dieselbe Information liegt in sechs Feldern mit fünf Namen. „Farbe“, „Colour“, „col_1“, „Grundfarbe“, plus ein Freitextfeld, in dem jemand 2021 angefangen hat, Farbfamilien zu pflegen. Die Werte sind genauso heterogen: „S“, „s“, „Small“, „36/38“. Technisch ist das trivial zu migrieren. Semantisch ist es die eigentliche Arbeit.

Zweitens: der Kategoriebaum. Er ist nicht entworfen, er ist gewachsen. In ihm stecken Marketinglogik, Logistiklogik, eine alte Steuerlogik und mindestens ein Knoten, den es nur gibt, weil ein Großkunde 2018 eine Sonderauswertung wollte. Niemand im Unternehmen kann für jeden Knoten sagen, was er bedeutet. Ein neues System zwingt Sie, genau das zu beantworten.

Drittens: die Datenlücken. Die sind das Perfide, denn sie sind im Altsystem unsichtbar. Das alte PIM hat sie nicht angezeigt, weil es sie nicht verlangt hat. Sobald Sie das Sortiment gegen ein sauberes Zielmodell mit Pflichtattributen mappen, wird sichtbar, dass 40 Prozent Ihrer Artikel keine belastbaren technischen Daten haben. Diese Lücke war immer da. Sie hat nur nie jemand gemessen. Gartner beziffert die Kosten schlechter Datenqualität auf durchschnittlich 12,9 Millionen US-Dollar pro Jahr und Unternehmen – der größte Teil davon fällt an, lange bevor jemand über ein Migrationsprojekt nachdenkt.

Der Big Bang ist das Risiko, nicht das Ziel

Der klassische Zuschnitt eines PIM-Projekts ist ein Stichtag. Alles muss zu einem Datum X richtig sein: alle Attribute gemappt, alle Kategorien übersetzt, alle Lücken geschlossen, alle Kanäle umgestellt.

Stellen Sie sich einen Händler mit 38.000 Artikeln vor, Go-Live geplant für September. Im Juli stellt sich heraus, dass die Kategorien für zwei Marktplätze anders geschnitten werden müssen als geplant. Die Optionen sind jetzt: Termin reißen, Umfang kürzen – oder mit halbfertigen Daten in das Weihnachtsgeschäft gehen. Alle drei Optionen sind schlecht, und alle drei entstehen aus derselben Entscheidung: alles auf einen Stichtag zu legen.

McKinsey hat das für Banken untersucht und kommt zu einem Muster, das branchenunabhängig gilt: Wer bei der Modernisierung zuerst integriert und erst danach vereinfacht, halbiert typische Transformationslaufzeiten und senkt die Kosten um bis zu 70 Prozent – bei gleichem Ergebnis.

Ein Stichtag ist keine Projektmethode. Er ist eine Wette.

Der dritte Weg: ergänzen statt ablösen

Zwischen „alles bleibt wie es ist“ und „wir ersetzen das Altsystem“ liegt die Option, die in Ausschreibungen fast nie auftaucht: ainavio als Ergänzung zum bestehenden System.

Das Altsystem behält, was es gut kann. Das ERP bleibt Master für Preise, Bestände und kaufmännische Stammdaten. Das alte PIM bleibt so lange im Betrieb, wie es gebraucht wird. ainavio übernimmt daneben den Teil, an dem das Altsystem tatsächlich scheitert: Onboarding neuer Produkte, KI-gestützte Anreicherung, Kategorie- und Attribut-Mapping auf Kanäle und Marktplätze, Veröffentlichung. Angebunden über REST-API und Konnektoren, in beide Richtungen, mit einem Golden Record, in dem sich pro Attribut festlegen lässt, welche Quelle Vorrang hat.

Für manche Kunden ist das der Zielzustand: eine agentische Schicht über einer gewachsenen Landschaft, die niemand anrühren will. Für andere ist es der Migrationspfad. Sie fangen mit einem Sortimentsbereich und einem Kanal an, ziehen Bereich für Bereich nach – und stellen nach zwölf Monaten fest, dass das Altsystem wieder ein ERP ist. Ohne Cutover-Wochenende. Ohne Stichtag.

Wie der Einstieg konkret aussieht

Das ist der Punkt, an dem Brownfield-Projekte üblicherweise ins Stocken kommen: Bevor das neue System etwas leisten kann, soll der Kunde erst seine Altdaten aufräumen. Genau diese Reihenfolge drehen wir.

Wir übernehmen das initiale Onboarding gemeinsam mit Ihnen – nicht als Hausaufgabe, die Sie vorher erledigen müssen:

1. Rohdaten rein, ungeputzt. Export aus dem Altsystem als CSV, Excel, per API oder als PDF-Katalog. Kein Cleanup vorab.
2. Mapping. Der Mapping Agent bildet Quellfelder auf Zielattribute ab und normalisiert Werte – „Small“, „s“ und „S“ werden zu einem Wert, Farbvarianten zu einer Farbfamilie.
3. Kategorien anlegen. Der Classification Agent schlägt Kategorien und Produktfamilien vor und ordnet die Artikel zu. Ihr alter Baum wird nicht blind kopiert, sondern gegen einen neuen Vorschlag gehalten. Sie entscheiden pro Knoten.
4. Lücken sichtbar machen. Der Quality Agent findet fehlende Pflichtattribute, Dubletten und Inkonsistenzen. Die Lückenliste ist ab hier ein Arbeitsplan und keine Überraschung mehr.
5. Lücken schließen. Research und Enrichment Agent recherchieren fehlende Informationen aus Hersteller- und Lieferantenquellen, PDFs und Bildern – jedes Attribut mit Quelle und Confidence-Bewertung, damit nichts still erfunden wird.
6. Ausspielen. Der Publishing Agent validiert gegen die Anforderungen des jeweiligen Kanals, bevor exportiert wird.

Die Kennzahl, die dabei zählt, ist nicht das Go-Live-Datum. Es ist die Time to First Product: die Zeit, bis das erste Produkt durch das neue System tatsächlich in einem Kanal ankommt. Bei einem Big-Bang-Projekt ist diese Zahl identisch mit dem Go-Live und liegt neun Monate in der Zukunft. Bei einem ergänzenden Einstieg liegt sie in Tagen. Bei SDS Swiss Dental Solutions war das komplette PIM-Projekt inklusive Business-Central- und Shopify-Anbindung in unter sechs Wochen live.

Zurück zur Sanierung

Ein Gebäude, in dem gearbeitet wird, reißt man nicht ab, um es neu zu bauen. Man saniert bei laufendem Betrieb: Etage für Etage, mit einer Baustelle, die man abgrenzen kann, und einem Zustand, in dem man jederzeit stehen bleiben könnte, ohne dass das Haus unbewohnbar ist.

Genau diese Eigenschaft fehlt dem klassischen PIM-Projekt. Es hat keinen Zwischenzustand, in dem man stehen bleiben kann. Es hat nur ein Vorher und ein Nachher – und dazwischen ein Risiko, das niemand seriös beziffern kann.

Ein PIM-Projekt muss nicht mit einem Umzug beginnen. Es kann mit dem ersten Produkt beginnen.