Die meisten Produkt- und Datateams stoßen irgendwann auf dieselbe Mauer. Das ERP hält alle „echten" Daten: SKUs, Preise, Lagerbestände, Lieferantencodes. Aber wenn jemand aus dem Marketing nach angereicherten Produktbeschreibungen fragt oder ein Channel-Manager lokalisierte Attribute für einen neuen Markt benötigt, kann das ERP diese entweder nicht liefern oder liefert sie schlecht.
Diese Lücke ist kein Bug. Sie ist von Design. ERP-Systeme wurden für operative Effizienz gebaut, nicht für Produktinformationsverwaltung. Dieser Artikel zeigt auf, welche Produktdaten ins ERP gehören, welche nicht und was stattdessen zu nutzen ist.
Welche Produktdaten werden im ERP verwaltet?
In einem ERP-System bezieht sich Produktdaten auf die strukturierten, transaktionalen Attribute, die mit einem Produktmasterdatensatz verknüpft sind. Das ist der Produktmaster: SKU, Maßeinheit, Preisgestaltung, Lagerbestände, Lieferantenreferenzen, Stücklisten, Kostencodes und Lebenszyklusstatus. In SAP ist dies der Materialstamm. In Microsoft Dynamics 365 oder Oracle NetSuite ist das Äquivalent der Artikelmaster oder der Produktkatalog-Datensatz.
Der Produktmaster im ERP ist die Single Source of Truth für den Betrieb. Beschaffung, Produktion, Finanzen und Logistik hängen alle davon ab.
Die ERP-Produktdatenverwaltung ist von Haus aus streng kontrolliert. ERP-Systeme erzwingen Validierungsregeln, Genehmigungsworkflows und Kontrollen auf Feldebene, da Fehler im Produktmaster direkte finanzielle Konsequenzen haben. Eine falsche Maßeinheit in einer Bestellung erzeugt echte Probleme. Ein fehlende Bild in einer Produktliste ist störend, aber es stoppt keinen Produktionslauf.
Diese Unterscheidung ist wichtig, wenn Sie entscheiden, was wo leben sollte.
Produktdaten, die nicht ins ERP gehören und wo sie stattdessen lagern
Ein großer Teil der Produktinformationen hat mit dem Betrieb nichts zu tun. ERP-Datenmodelle sind um Transaktionen herum aufgebaut. Jedes Feld in einem Produktmasterdatensatz existiert, weil eine Bestellung, ein Produktionsauftrag oder eine Lagerbewegung es lesen muss. Marketing-Kopien, CAD-Dateien und übersetzte Channel-Inhalte dienen keiner Transaktion. Sie im ERP zu speichern, beschwert ein für Geschwindigkeit und operative Konsistenz gebautes System und schafft Datenschutz-Probleme, wenn Marketing-, Engineering- und Produktteams die gleichen Datensätze nutzen.
Die Produktinformationen, die außerhalb des ERP fallen, und die Systeme, die sie besser handhaben:
- Marketing-Beschreibungen, digitale Assets, lokalisierte Inhalte und channel-spezifische Produktattribute gehören in ein PIM-System (Product Information Management). PIM kümmert sich um Produktdaten-Anreicherung, Multi-Channel-Verteilung und Produkttaxonomie. Es nimmt den Kern-Produktdatensatz aus dem ERP als Ausgangspunkt und baut die kommerzielle Schicht darauf auf.
- Engineering-Daten wie CAD-Modelle, technische Spezifikationen, Design-Revisionen und Material-Daten auf Komponentenebene gehören zu PLM (Product Lifecycle Management). PLM verwaltet die vorgelagerten Produktinformationen, bevor sie als herstellbares Element ins ERP gelangen.
- Versionskontrollierte technische Dokumente wie Zeichnungen, Release-Pakete und Spezifikationen sind die Domäne von PDM (Product Data Management), das oft in PLM eingebettet ist oder daneben läuft.
ERP ist der operative Kern. PLM und PDM verwalten die Engineering-Schicht. PIM verwaltet die kommerzielle Schicht. Probleme entstehen, wenn Unternehmen versuchen, diese Schichten in ein System zu kollabieren, meist das ERP, weil es bereits vorhanden ist.
Das problematische Muster ist konsistent. Ein Hersteller lagert alles im ERP, weil es das System ist, zu dem jeder Zugriff hat. Im Laufe der Zeit wird der Produktmaster unübersichtlich, die Produktdatenqualität sinkt, weil niemand klare Verantwortung trägt, und das Digital-Sales-Team erstellt eine Parallel-Tabellenkalkulation, weil das ERP nicht ausgeben kann, was sie brauchen. Die Lösung ist immer die gleiche: Trennen Sie Produktinformationen nach Zweck, weisen Sie klare Dateneigentümer zu und integrieren Sie die Systeme, statt sie zu fusionieren.
Wo die ERP-Produktdatenverwaltung zusammenbricht
ERP funktioniert gut innerhalb seines operativen Umfangs. Die Probleme beginnen, wenn Produktdaten mehr leisten müssen.
Datenverwaltung im großen Maßstab über Märkte hinweg. Wenn ein Unternehmen in mehreren Regionen tätig ist, erfordert die Aufrechterhaltung konsistenter ERP-Produktdaten oft mehrere ERP-Instanzen: eine pro Land oder Geschäftsbereich, jede verwaltet Produktmasterdatensätze unabhängig. Das Ergebnis ist eine fragmentierte Datenlandschaft ohne einheitliche Sicht über das gesamte Unternehmen. Das ERP wird nicht mehr zu einer Single Source of Truth für Produktinformationen und wird zu einer von mehreren konkurrierenden.
Produktdatenqualität auf Master-Record-Ebene. Datengenauigkeit, Benutzererfahrung und Analytics-Fähigkeiten sind die Top-drei-Bereiche, in denen ERP-Systeme für Nutzer hinter den Erwartungen zurückbleiben. Produktdatenqualitätsprobleme — doppelte Datensätze, inkonsistente Namenskonventionen, fehlende Produktattribute — sind häufig und teuer, wenn man sie später beheben muss.
Time-to-Market-Druck über Channels hinweg. Wenn ein Produkt gleichzeitig in einem Webshop, auf einem Marktplatz und in einem gedruckten Katalog live gehen muss, hat das ERP keinen nativen Mechanismus, um das zu verwalten. Jeder Channel benötigt unterschiedlich formatierte Produktinformationen. Ohne ein System, das dafür ausgelegt ist, fällt die Arbeit auf manuelle Exporte, Tabellenkalkulationen und Copy-Paste. Das verlangsamt Launches und vervielfacht Fehler.
Unsere Kunden sind genau mit diesem Problem zu uns gekommen. Ein mittelständiger Elektronikhersteller hatte Produktmasterdatensätze über zwei ERP-Instanzen verteilt, nachdem eine Akquisition durchgeführt wurde, ohne eine zuverlässige Möglichkeit, zu sagen, welches System die autoritative Quelle für einen gegebenen SKU hielt. Die Beschaffung bestellte gegen einen Preis, und die Finanzierung berichtete gegen einen anderen. Die Lösung erforderte eine Produktdaten-Governance-Schicht außerhalb des ERP, weil das ERP selbst keinen Mechanismus hatte, um Konflikte zwischen seinen eigenen Instanzen aufzulösen.
Nur ERP, ERP und PIM oder ERP und MDM: Was passt zu Ihrer Situation
Der richtige Ansatz hängt von der Komplexität des Produktkatalogs, der Anzahl der Channels und davon ab, wie viel Ihres Umsatzes von umfangreicher Produktinformation abhängt.
Für Unternehmen mit einfachen Katalogen und begrenzter Channel-Präsenz ist die ERP-Produktdatenverwaltung oft ausreichend. Eine saubere Datenverwaltung, konsistente Namenskonventionen und ein gut gepflegter Produktmaster bewältigen eine Menge.
Für Unternehmen mit großen oder komplexen Produktkatalogen, mehreren Sales-Channels oder globalen Operationen macht ein dediziertes PIM-System typischerweise mehr Sinn neben dem ERP. Das PIM kümmert sich um Produktdaten-Anreicherung, Channel-spezifische Formatierung und Content-Verteilung. Das ERP bleibt die Single Source of Truth für operative Produktdaten. Die zwei Systeme synchronisieren sich bei den gemeinsamen Attributen: SKU, Preisgestaltung und Lagerbestandssignale.
Der Unterschied wird konkret mit etwas wie „Materialzusammensetzung". Dieses Attribut muss möglicherweise als kurzer Beschaffungscode im ERP, als vollständige technische Beschreibung in einem Produktdatenblatt und als übersetzte Marketing-Kopie in einem französischsprachigen Katalog erscheinen. Ein ERP speichert einen Wert im Produktmaster. Ein PIM speichert alle drei, verwaltet die Beziehungen zwischen ihnen und leitet jeden zu seinem richtigen Ziel. SAP, Oracle NetSuite und Microsoft Dynamics 365 haben alle versucht, dies mit integrierten Content-Modulen zu tun, aber diese Ergänzungen sitzen auf einem operativen Datenmodell auf. Teams halten am Ende typischerweise trotzdem parallele Produktdatensätze.
Für große Unternehmen, die mit mehreren ERP-Instanzen, Produktdaten-Konflikten nach einer Fusion oder komplexen regulatorischen Umgebungen umgehen, ist MDM (Master Data Management) eine dritte Option. Wo PIM Produktinhalte anreichert und verteilt, regelt MDM den Produktmasterdatensatz selbst: erzwingt konsistente Definitionen, löst Konflikte zwischen ERP-Instanzen auf und dient als autoritative Quelle, die alle nachgelagerten Systeme speist, einschließlich des ERP. Die zwei sind nicht austauschbar. MDM regelt Datenkonsistenz auf Master-Ebene. PIM regelt Content-Qualität auf Channel-Ebene.
Reparieren Sie zuerst das richtige Problem
Bevor Sie ein Tool wählen, beurteilen Sie, wo das echte Problem sitzt.
Wenn Ihre Probleme in der Channel-Bereitschaft liegen: unvollständige Produktlisten, langsamer Time-to-Market und Lokalisierungsengpässe, das ist der Ort, wo die strukturellen Grenzen des ERP Sie kosten, und eine PIM-ERP-Integration ist es wert, bewertet zu werden. Wenn die Probleme in den operativen Datensätzen selbst liegen — Duplikate, falsche Maßeinheiten, konfligierende Produktmasterdaten über Systeme hinweg — repariert das keine zusätzliche Werkzeugverwaltung. Die Governance der ERP-Produktdaten muss zuerst kommen.
Die richtige Diagnose zu stellen ist wichtiger als das Tool zu wählen. Probleme mit der ERP-Produktdatenverwaltung werden oft missdeutet. Teams fügen Systeme hinzu, wenn sie Prozesse reparieren sollten, oder reparieren Prozesse, wenn die Produktdaten-Architektur die echte Constraint ist.
Der Produktmaster in Ihrem ERP trägt Last. Was daneben sitzt, muss ihn so behandeln.
*AtroPIM und AtroCore unterstützen flexible PIM- und Datenverwaltungsarchitekturen, die mit bestehenden ERP-Systemen integriert werden.