Die wichtigsten Erkenntnisse
- Eine Produktdatenbank ist mehr als nur Speicher. Sie definiert, was nachgelagerte Systeme mit Ihren Produktdaten tun können – von der ERP-Integration bis zur Kanalverteilung.
- Hersteller und Distributoren sehen sich mit wachsender Komplexität konfrontiert: tiefe technische Attribute, Lieferantendaten in inkonsistenten Formaten und Produktdaten, die ohne aktive Governance jährlich um 20–25 % verfallen.
- Die häufigste Ursache für Produktdatenprobleme ist nicht schlechte Tooling. Es ist Produktdaten, die über mehrere Systeme verteilt sind, ohne einen einzelnen autoritativen Datensatz.
- Ein PIM-System bringt Workflows, Validierung, Vollständigkeitsverfolgung und Multi-Channel-Verteilung zur Produktdatenbank-Ebene hinzu und wandelt ein Speicherproblem in einen verwalteten Prozess um.
- Datengovernance-Entscheidungen gehen der Tooling voraus. Einigung auf Attributstruktur, Naming-Konventionen und Verantwortlichkeit ist das, was jede Produktdatenbank in großem Maßstab funktionieren lässt.
Eine Produktdatenbank ist der Ort, an dem strukturierte Produktinformationen gespeichert werden: SKUs, Attribute, Spezifikationen, Medienreferenzen, Klassifizierungen und die Beziehungen zwischen ihnen. Sie ist das Fundament Ihres Produktkatalogs, und alles, was danach kommt, hängt davon ab – von Ihrem ERP bis zu Ihrem Webshop bis zum PDF, das Sie einem Kunden auf einer Messe in die Hand geben.
Die meisten Hersteller und Distributoren haben bereits eine. Das Problem besteht normalerweise nicht darin, dass es nicht existiert. Das Problem besteht darin, dass es an drei oder vier Orten gleichzeitig existiert, von verschiedenen Teams gepflegt, in Formaten, die nicht miteinander übereinstimmen.
Was eine Produktdatenbank tatsächlich enthält
Auf der einfachsten Ebene speichert eine Produktdatenbank Datensätze, die physische oder digitale Produkte beschreiben. Jeder Datensatz identifiziert ein Produkt und enthält die Daten, die es beschreiben: Abmessungen, Gewicht, Material, Zertifizierungen, Verpackungseinheiten, Herkunftsland, EAN-Codes, technische Parameter und so weiter.
Für einen Hersteller von Industriekomponenten könnte ein Produktdatensatz 50 oder mehr Attribute umfassen. Eine Hydraulikpassstück benötigt beispielsweise Druckbewertungen, Temperaturbereiche, Gewindtypen, Verbindungsstandards, kompatible Materialien und geltende Normen neben grundlegenden Identifikationsdaten wie SKU und GTIN. Diese Attribute variieren je nach Produktkategorie, daher bricht eine starre flache Tabellenstruktur schnell zusammen. Ein Hersteller, der eine neue Produktlinie hinzufügt, benötigt unterschiedliche Attribute, und die Produktdatenbank muss diese unterstützen, ohne dass ein Schema-Überhaul erforderlich ist.
Deshalb verwenden spezialisierte Produktdatenbanken flexible Attributmodelle anstelle von festen Spalten. Das Entity-Attribute-Value-(EAV-)Modell ist der häufigste Ansatz: Anstatt jedes Attribut als separate Spalte zu speichern, speichert die Datenbank Attribut-Wert-Paare, die mit jedem Produktdatensatz verknüpft sind. Neue Attribute können hinzugefügt werden, ohne die Tabellenstruktur zu berühren – wichtig, wenn Ihr Katalog wächst.
Neben Attributen speichert eine Produktdatenbank normalerweise:
- Produktklassifizierungsdaten (Ihre eigene Produkttaxonomie, sowie externe Standards wie ETIM oder UNSPSC, wenn relevant)
- Medienreferenzen oder eingebettete digitale Assets wie Bilder, Zeichnungen, Sicherheitsdatenblätter
- Produktbeziehungen: Zubehör, Ersatzteile, kompatible Artikel, Varianten
- Lokalisierte Inhalte für verschiedene Märkte und Sprachen
- Kanalbezogene Daten, einschließlich Beschreibungen und Spezifikationen, formatiert für verschiedene Verkaufsplattformen
Datenenreicherung erfolgt auch auf dieser Ebene. Ein aus einem ERP importierter Produktdatensatz kommt mit Identifikatoren und grundlegenden Spezifikationen. Beschreibungen, Marketing-Texte, SEO-Inhalte und zusätzliche technische Details werden in der Produktdatenbank hinzugefügt, bevor etwas an einen Kanal veröffentlicht wird. Ein Distributor, der über ein B2B-Portal, einen Webshop, einen EDI-Feed an Einzelhandelsketten und einen gedruckten Produktkatalog verkauft, benötigt verschiedene Formate derselben Daten. Die Produktdatenbank ist der Ort, an dem all das aus einem einzelnen, autoritativen Datensatz stammen sollte.
Warum Hersteller und Distributoren es schwerer haben
Unternehmen mit Konsumgütern verwalten typischerweise Dutzende oder Hunderte von Produktlinien. Hersteller von Industrieausrüstung, Baumaterialien, Elektrokomponenten oder Sicherheitsprodukten verwalten oft Zehntausende von SKUs mit wirklich komplexen technischen Attributen.
Ein Distributor fügt eine weitere Schicht hinzu. Sie verwalten ihre eigenen Produktdatensätze und die von Dutzenden oder Hunderten von Herstellern erhaltenen Daten, von denen jede in einem anderen Format, mit unterschiedlichen Vollständigkeitsgraden und nach verschiedenen Zeitplänen versandt wird.
In Projekten, die wir für Industriedistributoren implementiert haben, wird das Problem der eingehenden Lieferantendaten fast immer unterschätzt. Hersteller schicken Excel-Dateien, PDFs und proprietäre Exporte, die sich nicht sauber auf einen gemeinsamen Standard abbilden. Die Normalisierung dieser Daten manuell, bevor sie in die Produktdatenbank gehen, ist der Punkt, an dem ein großer Teil der Zeit des Produktteams tatsächlich verbraucht wird.
Forschung von Akeneo ergab, dass 70 % der B2B-Unternehmen zwei Wochen oder länger benötigen, um Produktinformationen von Lieferanten zusammenzutragen und zu katalogisieren, wobei 10 % länger als 30 Tage benötigen. Diese Verzögerung wirkt sich direkt auf die Markteinführungszeit aus, und für einen Distributor, der versucht, eine neue Produktlinie vor einem Konkurrenten aufzulisten, sind zwei Wochen eine lange Zeit.
Der manuelle Aufwand nimmt mit der Zeit zu. Studien deuten darauf hin, dass Produktdaten im E-Commerce jährlich um ungefähr 20 bis 25 % verfallen, da Lieferanten Spezifikationen aktualisieren, Produkte eingestellt werden und neue Varianten eingeführt werden. Ohne systematische Prozesse, um diesen Verfall zu erkennen und zu korrigieren, driftet die Produktdatenbank langsam von der Realität ab.
Die echten Kosten einer schlecht strukturierten Produktdatenbank
Zerstreute oder inkonsistente Produktdaten haben echte finanzielle Kosten. Nach Gartner-Forschung, zitiert von integrate.io, kostet schlechte Datenqualität Organisationen durchschnittlich 12,9 Millionen Dollar pro Jahr in allen Branchen. Für Unternehmen in Fertigung und Verteilung ist Produktstammdaten ein großer Bestandteil dieser Zahl, da falsche Spezifikationen zu falschen Bestellungen, fehlgeschlagenen Installationen und Rückgaben führen.
Nach Forschung von Eklipse Creative haben 40 % der Online-Käufer Produkte aufgrund von falschen oder unvollständigen Produktinformationen zurückgegeben, und 2024 gaben US-Verbraucher Waren im Wert von 890 Milliarden Dollar zurück, wobei 31 % dieser Rückgaben auf falsch beschriebene Artikel zurückzuführen waren.
Bei B2B-Transaktionen sind die Konsequenzen schlimmer. Ein Käufer, der 500 Einheiten des falschen Teils basierend auf einer falschen Spezifikation in Ihrer Produktdatenbank bestellt, sendet die Bestellung nicht einfach zurück. Er vertraut Ihrem Katalog nicht mehr. Wenn der Fehler ihn Produktionsausfallzeiten gekostet hat, könnte er ganz aufhören, bei Ihnen zu kaufen.
Die strukturelle Grundursache ist normalerweise die gleiche: Produktdaten, die über mehrere Systeme verteilt sind, ohne eine einzelne autoritative Quelle. Das ERP hält einige Attribute. Die Tabellenkalkulation des Produktmanagers hält andere. Die Website hat Beschreibungen, die vor zwei Jahren zuletzt aktualisiert wurden. Marketing hat seine eigene Version. Niemand besitzt vollständig den kanonischen Datensatz, und jedes System weicht allmählich ab.
Wie die Datenbankstruktur beeinflusst, was Sie damit tun können
Eine flache Tabellenkalkulation oder eine einfache Datenbanktabelle kann grundlegende Produktinformationen speichern, kann aber Attributvariationen über Produktkategorien hinweg nicht sauber handhaben. Sie enden mit Hunderten von Spalten, von denen die meisten für ein bestimmtes Produkt leer sind. Diese spärliche Struktur ist langsam zu abfragen, schwer zu warten und zerbrechlich, wenn Sie Kategorien hinzufügen müssen.
Eine gut strukturierte Produktdatenbank, die auf einem flexiblen Datenmodell aufgebaut ist, verwaltet Attributsätze nach Kategorie: Elektrokomponenten erhalten elektrotechnische Attribute, mechanische Teile erhalten mechanische, und keine erbt irrelevante Felder von der anderen. Das Variantenmanagement funktioniert genauso: Ein Produkt mit zehn Größenvarianten und drei Farboptionen ist ein Basisdatensatz mit strukturierter Variantenlogik, nicht dreißig separate Einträge, die einzeln aktualisiert werden müssen.
Lokalisierung wird als zusätzliche Attributwerte auf dem gleichen Produktdatensatz gespeichert, nicht als duplizierte Datensätze pro Sprache. Beziehungszuordnung verknüpft Ersatzteile mit dem Hauptprodukt, zu dem sie gehören, und Zubehör mit den Basisprodukten, mit denen sie kompatibel sind. Diese Beziehungen ermöglichen genaue Cross-Selling-, technische Dokumentations- und gefilterte Suche in großen Katalogen.
Am wichtigsten ist dieser Struktur an dem Punkt der Integration. Wenn Ihre Produktdatenbank sich mit einem ERP, einem Webshop, einem Marktplatz oder einem Kundenportal verbindet, bestimmt die Qualität des Datenmodells, wie sauber und zuverlässig diese Verbindung ist. Schlecht strukturierte Daten schaffen an jedem Integrationspunkt Reibung: fehlende Felder, inkonsistente Einheiten, als freier Text statt als kontrollierte Attribute gespeicherte Werte.
Wann eine grundlegende Produktdatenbank unzureichend wird
Eine Tabellenkalkulation oder eine grundlegende Datenbanktabelle funktioniert, bis sie es nicht mehr tut. Der Fehlermodus ist graduell, dann plötzlich.
Häufige Anzeichen dafür, dass das aktuelle Setup zusammenbricht:
- Neue Produkteinführungen erfordern manuelle Dateneingabe in mehreren Systemen, bevor etwas live geht
- Verschiedene Abteilungen haben unterschiedliche Versionen der Spezifikationen des gleichen Produkts
- Das Hinzufügen eines neuen Verkaufskanals bedeutet, einen benutzerdefinierten Export von Grund auf zu erstellen
- Die Übersetzung des Katalogs für einen neuen Markt ist eine manuelle Kopier-Einfügen-Übung
- Produktmanager verbringen einen bedeutenden Teil ihrer Zeit damit, Datenfehler zu korrigieren, anstatt Daten anzureichern
In Projekten, die wir für Baumaterialhersteller implementiert haben, kommt dieser Moment typischerweise, wenn ein zweiter Verteilungskanal hinzugefügt wird. Der erste Kanal war mit Exporten und manuellen Anpassungen handhabbar. Der zweite verdoppelt die Wartungsarbeit. Beim dritten führt das Team permanente Abstimmungen zwischen Systemen durch und die Produktdatenbank hat sich praktisch in separate parallele Versionen aufgeteilt. Neue Produkteinführungen verlangsamen sich, da niemand zustimmen kann, welche Version einer Spezifikation aktuell ist. Unternehmen beginnen zu diesem Punkt, spezialisierte Produktinformationsmanagementsysteme zu evaluieren, üblicherweise nach einem öffentlichen Datenfehler, der einen Kunden erreichte.
Was ein PIM-System zu einer Produktdatenbank hinzufügt
Ein PIM-System ist im Kern eine Produktdatenbank mit einer Schicht von Betriebswerkzeugen, die darum herum aufgebaut ist. Die Datenbank speichert die Daten. Das PIM fügt Workflow hinzu, um zu kontrollieren, wer was und wann aktualisieren kann, Governance, um Validierungsregeln und Vollständigkeitsstandards durchzusetzen, und Verteilung, um die richtige Untergruppe von Attributen an jeden Kanal im richtigen Format zu schieben. Produktdatenmanagement wird zu einem strukturierten Prozess anstatt zu einem Koordinationsproblem über Teams und Tabellenkalkulationen hinweg.
Ein PIM gibt Produktmanagern eine strukturierte Schnittstelle zur Dateneingabe und -anreicherung mit Validierungsregeln, die Fehler erkennen, bevor sie sich nachgelagert ausbreiten. Es bietet Versionierung, damit Sie nachverfolgen können, was sich wann geändert hat. Es verwaltet Vollständigkeitsverfolgung, damit Sie wissen, welche Produktdatensätze veröffentlichungsbereit sind und welche noch erforderliche Felder vermissen.
AtroPIM ist ein Open-Source-PIM, das auf der AtroCore-Datenplattform aufgebaut ist, was bedeutet, dass es über das hinausgeht, was ein klassisches PIM tut. Es unterstützt konfigurierbare Datenmodelle, sodass die Attributstruktur an einen bestimmten Katalog angepasst werden kann, ohne benutzerdefinierte Entwicklung. Es hat native Unterstützung für komplexe Produktbeziehungen, Klassifizierungshierarchien und Lokalisierung. Es verbindet sich über REST API mit ERPs und E-Commerce-Plattformen, mit nach OpenAPI-Standards pro Instanz generierter Dokumentation. Und es enthält ein eingebautes DAM, daher werden Medien-Assets neben den Produktdaten verwaltet, zu denen sie gehören, anstatt in einem separaten System.
Für Hersteller mit komplexen, hochgradig technischen Katalogen ist die Möglichkeit, das Datenmodell ohne Code zu konfigurieren, wichtig. Produktkategorien in Industrieausrüstung oder Elektrokomponenten folgen keinen generischen Templates. Das System muss dem Produkt folgen, nicht andersherum.
On-Premise- und SaaS-Deployment-Optionen bedeuten, dass die Wahl der Infrastruktur beim Unternehmen bleibt, was für Hersteller mit strikten Datengovernance-Anforderungen oder existierender IT-Infrastruktur, die sie nutzen möchten, wichtig ist.
Das Fundament richtig legen
Die Produktdatenbank ist kein Projekt, das Sie beenden. Sie spiegelt den aktuellen Zustand Ihres Produktkatalogs, Ihrer Kanäle, Ihrer Lieferantenbeziehungen und Ihrer internen Prozesse wider. Produkte durchlaufen einen Lebenszyklus: Sie werden eingeführt, aktualisiert, lokalisiert, eingestellt. Die Datenbank muss diesem Lebenszyklus zuverlässig folgen, oder sie sammelt die Art von veralteten, widersprüchlichen Daten an, die das Vertrauen über jeden errosden, der sie berührt.
Die Struktur frühzeitig falsch zu bekommen, ist teuer. Die Migration von Daten aus einem schlecht strukturierten System ist störend. Das Bereinigen von fünf Jahren inkonsistenter Attributbenennung und duplizierten SKU-Datensätzen braucht Zeit, die Produktteams selten zur Verfügung haben.
Der praktische Startpunkt ist zu entscheiden, wie die einzelne Wahrheitsquelle aussieht, bevor Sie sie erstellen oder zu ihr migrieren. Das bedeutet, sich auf die existierenden Attribute zu einigen, wie sie heißen, welche Werte gültig sind und wer für ihre Verwaltung verantwortlich ist. Die Tooling ist wichtig, aber Entscheidungen über Datengovernance gehen zuerst.
Eine genaue, vollständige und konsistent strukturierte Produktdatenbank entfernt Reibung an jedem Punkt, an dem Produktinformationen sich bewegen müssen, und in Fertigung und Verteilung stellt sich heraus, dass dies fast jede Betriebsübergabe im Geschäft ist.