Managt Ihr ERP Ihre Produktdaten, oder bewahrt es sie nur auf?

Die wichtigsten Erkenntnisse

• ERPs wie SAP, Oracle und Microsoft Dynamics sind für Transaktionen ausgelegt, nicht für die Verwaltung von Produktinhalten.
• Ein ERP kurzfristig für diese Lücke anzupassen, funktioniert zwar kurzfristig, führt aber langfristig zu steigenden Kosten, Skalierungsproblemen und IT-Engpässen.
• Ein dediziertes PIM ist kein weiteres System, das gepflegt werden muss, sondern die Schicht, die den gesamten Daten-Stack vereinfacht.
• ERP und PIM ergänzen sich: Das eine verwaltet die Zahlen, das andere die Inhalte.
• Moderne PIMs lassen sich über APIs sauber in bestehende ERP-Systeme integrieren, sodass der Umstieg weniger aufwendig ist als die meisten Teams erwarten.

Die meisten Unternehmen, die SAP, Oracle ERP Cloud, Microsoft Dynamics 365 oder NetSuite einsetzen, stellen nicht in Frage, ob ihr ERP Produktdaten verwalten kann. Das System enthält bereits SKUs, Preise und Lagerbestände; daher liegt die Annahme nahe, dass auch alle weiteren Produktinformationen dort gespeichert werden sollten.

Diese Annahme lohnt sich zu hinterfragen. Nicht weil ERPs schlechte Werkzeuge wären, sondern weil Produktdatenmanagement grundlegend andere Anforderungen stellt, als ein ERP erfüllen soll. Die Lücke bleibt oft unsichtbar, bis ein Unternehmen zu wachsen beginnt, einen neuen Vertriebskanal hinzufügt oder einen neuen Markt erschließen will. Zu diesem Zeitpunkt sind die Workarounds meist schon fest etabliert.

Wofür ERPs tatsächlich gebaut sind

Um der Technologie gegenüber fair zu sein: Enterprise-Resource-Planning-Systeme sind bemerkenswerte Infrastruktur. SAP S/4HANA, Oracle, Dynamics 365 und NetSuite haben jahrzehntelang wirklich schwierige Probleme gelöst, darunter konzerninterne Finanzen, Beschaffungsprozesse, Supply-Chain-Koordination, Lagerverwaltung und Compliance-Reporting. Sie sind um das Konzept einer Transaktion herum aufgebaut: Etwas ist passiert, muss korrekt erfasst werden und die richtigen Konten und Lagerbestände beeinflussen.

Dieses Transaktionsmodell macht ERPs für den operativen Betrieb so verlässlich. Eine Bestellung geht ein, der Lagerbestand wird aktualisiert, das Hauptbuch spiegelt die Änderung wider. Das ist präzise, nachvollziehbar und konsistent. Genau das braucht man für den operativen Betrieb eines Unternehmens.

Die Schwierigkeiten beginnen, wenn dasselbe System eine ganz andere Art von Daten verwalten soll.

Wo Produktdaten nicht hineinpassen

Produktdaten, also die Art, die tatsächlich beim Kunden ankommt, sind grundlegend anders geartet. Sie umfassen strukturierte Attribute wie Abmessungen, Materialien und technische Spezifikationen, aber auch unstrukturierte Inhalte: ausführliche Beschreibungen, Marketingtexte, Bilder, Videos, PDFs und Rich-Media-Assets. Diese Inhalte müssen für verschiedene Kanäle (ein E-Commerce-Listing liest sich anders als ein Printkatalog), verschiedene Regionen (übersetzt, lokalisiert, teils rechtlich angepasst) und verschiedene Zielgruppen aufbereitet werden.

ERP-Datenmodelle sind auf feste Schemata und Transaktionsdatensätze ausgelegt. Produktinhalte sind flexibel, kontextabhängig und verändern sich laufend. Die beiden Konzepte wurden nie dafür entwickelt, reibungslos im selben System zu koexistieren.

In der Praxis haben die meisten ERPs Schwierigkeiten mit dem, was Produktdaten täglich erfordern:

• Flexible, konfigurierbare Attributstrukturen, die je nach Produktkategorie variieren
• Native Verwaltung digitaler Assets wie Bilder, Dokumente und 3D-Dateien
• Mehrsprachiges Content-Management mit länderspezifischen Varianten
• Workflow-Werkzeuge, mit denen nicht-technische Teams Produktinhalte anreichern und freigeben können
• Ausgabeformatierung für verschiedene Vertriebskanäle wie Marktplätze, E-Commerce und Print
• Verwaltung von Produktvarianten mit komplexen Beziehungen und Vererbungslogik

Das bedeutet nicht, dass das ERP fehlerhaft ist. Es bedeutet, dass es für etwas eingesetzt wird, wofür es nie konzipiert wurde.

Die Falle der Individualisierung

Die typische Reaktion, wenn Teams auf diese Grenzen stoßen, ist Anpassung: ein Modul hinzufügen, einen Workaround bauen, Inhalte in eine Tabelle exportieren und dort pflegen, dann wieder importieren. Das funktioniert, bis es das irgendwann nicht mehr tut.

Das Problem bei der Anpassung eines ERPs für Produktdaten liegt nicht im ersten Entwicklungsaufwand. Es liegt in allem, was danach kommt. Individuelle Module müssen gepflegt werden. Wenn SAP oder Oracle ein größeres Update veröffentlicht, muss jemand sicherstellen, dass die angepassten Schichten nicht kaputtgehen. Wenn sie es doch tun, ist das eine dringende und teure Reparatur. Gleichzeitig sind die tabellenbasierten Prozesse, die die Lücken gefüllt haben, still und leise zur unverzichtbaren Infrastruktur geworden, die niemand anfassen will.

Jede ERP-Anpassung, die ein fehlendes Feature kompensiert, ist eine künftige Wartungslast. Die eigentlichen Kosten entstehen nicht beim Bauen, sondern beim Betrieb durch Upgrades, neue Mitarbeiter und sich ändernde Geschäftsanforderungen.

So sieht das typischerweise bei einem Unternehmen aus, das ein stark angepasstes ERP für Produktdaten betreibt:

• Das Hinzufügen eines neuen Vertriebskanals, etwa eines Marktplatzes oder eines regionalen Webshops, erfordert eine erneute Anpassung der Exportlogik und ist keine reine Konfigurationsänderung.
• Neue Produktkategorien mit anderen Attributsätzen einzuführen bedeutet entweder, sie in ein bestehendes Schema zu zwingen, oder eine weitere Runde individueller Entwicklung.
• Produktinhalte in großem Umfang zu aktualisieren, also Beschreibungen, Bilder und Ãœbersetzungen, erfordert IT-Beteiligung für alles, was über die grundlegendsten Felder hinausgeht.
• Wenn das Unternehmen etwas Neues ausprobieren möchte, etwa Bundles, konfigurierbare Produkte oder angereicherte Spezifikationen, lautet die Antwort meist: „Dafür müssen wir ein Entwicklungsprojekt aufsetzen.“

Mit der Zeit wird die IT zum Engpass, nicht weil das Team langsam wäre, sondern weil die Architektur ihre Beteiligung bei Dingen erfordert, die eigentlich Self-Service sein sollten. Marketing kann eine Produktbeschreibung nicht ohne ein Ticket aktualisieren. E-Commerce kann kein neues Attribut ohne einen Sprint hinzufügen.

Was ein dediziertes PIM tatsächlich leistet

Ein Product-Information-Management-System ist Software, die speziell für das oben beschriebene Problem entwickelt wurde. Seine Kernaufgabe besteht darin, Produktinhalte zu zentralisieren, Teams die Werkzeuge zur Anreicherung und Validierung bereitzustellen und die Daten präzise an alle Ziele auszuspielen, sei es ein Onlineshop, ein Printkatalog, ein B2B-Portal oder ein Marktplatz-Feed.

Der strukturelle Unterschied zum ERP ist erheblich. PIMs basieren auf konfigurierbaren Datenmodellen: Man definiert, welche Attribute für jede Produktkategorie existieren, ohne Datenbankschemas anzufassen oder benutzerdefinierten Code zu schreiben. Ein Produktteam kann ein neues Attributfeld hinzufügen, zum Beispiel „Nachhaltigkeitszertifizierung“ für eine neue Produktlinie, ohne einen Entwickler einzubeziehen.

Workflow-Funktionen stellen sicher, dass die Inhaltsanreicherung, also das Schreiben von Beschreibungen, das Hinzufügen von Bildern, das Einholen von Freigaben und die Verwaltung von Übersetzungen, im System selbst stattfindet. Dabei ist jederzeit sichtbar, was vollständig ist, was fehlt und was auf eine Überprüfung wartet. Das sind Aufgaben, die mangels einer geeigneten Heimat oft in E-Mail-Threads und Tabellen erledigt werden.

Auf der Ausgabeseite kann ein PIM Produktdaten je nach Ziel unterschiedlich aufbereiten und ausliefern. Dasselbe Produkt benötigt möglicherweise eine 500-Wörter-Beschreibung für eine E-Commerce-Detailseite, eine zweigliedrige Zusammenfassung für einen Marktplatz und ein Datenblatt für einen B2B-Katalog. Ein PIM verwaltet diese Varianten, ohne den Basisdatensatz zu duplizieren.

„Wir wollen kein weiteres System pflegen“

Dies ist der häufigste Einwand, und er verdient eine direkte Antwort.

Die Sorge ist nachvollziehbar: Ein neues System bedeutet neue Integrationspunkte, neue Verträge und neue potenzielle Fehlerquellen. Doch diese Sichtweise setzt voraus, dass die aktuelle Situation einfach ist. Das ist sie in der Regel nicht. Ein Unternehmen, das Produktdaten über ein angepasstes ERP, einen Satz Tabellen und manuelle Prozesse für jeden Vertriebskanal verwaltet, betreibt kein einfaches System. Es betreibt ein komplexes, das nur unsichtbar ist.

Der treffendere Vergleich lautet: ein PIM, das mit dem ERP verbunden ist, gegenüber einem ERP, das direkt mit jedem Vertriebskanal einzeln verbunden ist. Im zweiten Szenario hat jeder Kanal seine eigene Integration, seine eigenen Besonderheiten und seine eigene Datentransformationslogik. Ein neuer Kanal bedeutet ein neues Integrationsprojekt. Eine Änderung eines Produktattributs erfordert Anpassungen in der Logik jedes einzelnen Kanals. Die Komplexität ist real; sie ist nur auf viele Stellen verteilt statt an einem Ort verwaltet.

Ein PIM erhöht die Komplexität im Stack nicht, sondern konsolidiert sie. Statt eine direkte Verbindung zwischen dem ERP und jedem Vertriebskanal separat zu pflegen, gibt es eine saubere Integration, und das PIM übernimmt den Rest.

Die Aufgabenteilung wird klar: Das ERP bleibt die führende Datenquelle für SKUs, Preise und Lagerbestände. Das PIM wird zur führenden Datenquelle für alles, was ein Kunde oder Partner tatsächlich sieht. Keines der Systeme versucht, die Aufgabe des anderen zu übernehmen.

PIM-Systeme, die man kennen sollte

Der PIM-Markt hat sich erheblich weiterentwickelt. Es gibt Enterprise-Plattformen, Lösungen für den Mittelstand und Open-Source-Tools mit großem Anpassungspotenzial. Hier sind drei Optionen, die je nach Situation einer Evaluierung wert sind:

AkeneoSaaS & selbst gehostet · Starkes E-Commerce-Ökosystem

Akeneo gehört zu den am weitesten verbreiteten PIMs im mittleren und großen Einzel- und Großhandel sowie in der Fertigungsindustrie. Das System verfügt über eine umfangreiche Bibliothek an Konnektoren für E-Commerce-Plattformen und Marktplätze, und die Oberfläche ist auch für nicht-technische Teams zugänglich. Es ist ein solider Ausgangspunkt für Unternehmen, die eine bewährte, gut unterstützte Lösung mit starker Community suchen. Die Preisgestaltung skaliert mit dem Nutzungsumfang, was bei hohem Volumen relevant werden kann.

PimcoreOpen Source · PIM + DAM + CMS kombiniert

Pimcore verfolgt einen breiteren Ansatz und kombiniert PIM-Funktionalität mit Digital-Asset-Management und Content-Management in einer einzigen Plattform. Das System ist sehr flexibel und vermeidet Vendor-Lock-in, was es für Unternehmen mit spezifischen Anforderungen attraktiv macht, die Standardlösungen nicht gut abdecken. Die Implementierung und der Betrieb erfordern mehr technische Ressourcen als bei einer SaaS-Lösung. Pimcore eignet sich daher besser für Teams mit internen Entwicklungskapazitäten oder einem verlässlichen Implementierungspartner.

AtroPIMOpen Source · Hohe Anpassbarkeit · ERP-Erstintegration

AtroPIM ist ein hochflexibles PIM, das für komplexe ERP-zentrierte Umgebungen entwickelt wurde. Sein praktischer Vorteil liegt in der ERP-Integration: AtroPIM verbindet sich über API mit nahezu jedem ERP, darunter SAP, Odoo, Oracle, NetSuite und weiteren. Damit gehört es zu den realistischen Optionen für Unternehmen, die eine saubere, bidirektionale Synchronisierung ohne großes Implementierungsbudget benötigen. Das Open-Source-Fundament bedeutet zudem, dass keine Abhängigkeit von einem Anbieter bei der Preisgestaltung oder Produkt-Roadmap besteht.

Bevor Entscheidungen getroffen werden

Praktische Schritte

• Erfassen, wo Produktdaten heute tatsächlich leben. Jedes System, jede Tabelle und jeden freigegebenen Ordner im aktuellen Prozess kartieren. Das Ergebnis ist meist komplexer als erwartet und macht den Handlungsbedarf deutlich sichtbar.
• Den gesamten Datenfluss nachverfolgen. Wo entsteht ein neues Produkt, wer bearbeitet die Daten und wo landen sie am Ende? Die Ãœbergabepunkte zu identifizieren, zeigt, wo sich Fehler und Verzögerungen häufen.
• Nicht alles auf einmal migrieren. Mit einer Produktkategorie oder einem Vertriebskanal beginnen. Ein begrenzter Pilotbetrieb liefert echte Ergebnisse, ohne das Risiko einer fehlgeschlagenen Gesamtmigration.
• IT und Fachseite frühzeitig einbeziehen. Marketing, E-Commerce und Katalogteams sind oft am stärksten vom aktuellen Prozess betroffen. Ihr Input bestimmt, wie eine gute Lösung in der Praxis aussieht.
• Die ERP-Integration zuerst prüfen. Vor allem sollte geprüft werden, wie sich ein PIM mit dem spezifischen ERP verbindet. Die Qualität dieser Integration, also bidirektionale Synchronisierung, Feldmapping und Aktualisierungsfrequenz, entscheidet darüber, ob das Gesamtsetup funktioniert.

Das Ziel besteht nicht darin, das ERP zu ersetzen

Das sollte klar gesagt werden: Ein PIM steht nicht in Konkurrenz zum ERP. Das ERP erledigt weiterhin, was es gut kann. Der Unterschied besteht darin, dass Produktinhalte nun eine Heimat haben, die tatsächlich für sie gebaut wurde.

Die Unternehmen, die aus diesem Setup den größten Nutzen ziehen, sind jene, die aufgehört haben, ein einziges System für alles einzusetzen, und akzeptiert haben, dass unterschiedliche Probleme von zweckgebauten Werkzeugen am besten gelöst werden. Das ERP verwaltet die Zahlen. Das PIM verwaltet die Inhalte. Beide bleiben über eine API synchron, und jeder Vertriebskanal erhält saubere, konsistente und aktuelle Produktdaten, ohne dass jemand eine Tabelle pflegen muss, damit das funktioniert.

Das ist keine komplexere Architektur. Für die meisten Teams, die die Alternative kennen, ist es deutlich einfacher.

Die Frage lautet nicht, ob ein ERP Produktdaten speichern kann; das kann es in der Regel. Die Frage lautet, ob Speichern dasselbe ist wie gutes Verwalten. Für die meisten Unternehmen ab einer gewissen Größe wird die Antwort darauf schnell deutlich.