Inhaltsilos gehören zu jenen Problemen, die still und leise wachsen. Ein Team führt ein neues Tool ein. Ein anderes Team arbeitet weiter mit der alten Tabelle. Die E-Commerce-Plattform bekommt ihre eigene Produktdatenbank. Niemand plant die Fragmentierung; sie häuft sich einfach an.
Wenn das Problem sichtbar wird, ist es bereits teuer. Produktbeschreibungen widersprechen sich kanalübergreifend. Aktualisierungen in einem System brauchen Tage, um ein anderes zu erreichen. Mehrere Personen in verschiedenen Abteilungen erfassen dieselben Daten manuell. Kunden erhalten je nach Kanal unterschiedliche Informationen.
MIT-Sloan-Forschungen zeigen, dass Unternehmen aufgrund mangelhafter Datenqualität zwischen 15 % und 25 % ihres Jahresumsatzes verlieren (Quelle). Gartner beziffert die durchschnittlichen jährlichen Kosten für Unternehmen auf 12,9 Millionen US-Dollar (Quelle). Produktinformationen gehören zu den fragmentiertesten und wirkungsstärksten Datenkategorien für jedes Unternehmen, das über mehrere Kanäle verkauft.
Was sind Inhaltsilos?
Im Kontext von Produktdaten sind Inhaltsilos isolierte Repositories von Produktinformationen, die in voneinander getrennten Systemen innerhalb derselben Organisation existieren. Das Marketing verwaltet Beschreibungen in einem CMS. Der Vertrieb speichert Spezifikationen in einem CRM. Das Lager betreibt sein eigenes Bestandssystem. Die E-Commerce-Plattform pflegt ihre eigene Produktdatenbank. Jedes System enthält einen Teil des Produktdatensatzes, aber keines enthält alles, und keines ist dauerhaft mit den anderen synchronisiert.
Das Ergebnis ist, dass Produktinformationen nach Abteilung fragmentiert werden, anstatt rund um das Produkt selbst organisiert zu sein. Keine einzige Version des Datensatzes ist maßgeblich. Aktualisierungen in einem System erreichen andere nicht automatisch. Je länger diese Struktur besteht, desto größer werden die Lücken zwischen den Versionen und desto teurer wird ihre Schließung.
Dies unterscheidet sich vom SEO-Konzept der Inhaltsilos, das sich auf die Organisation von Website-Seiten in thematische Cluster für die Sichtbarkeit in Suchmaschinen bezieht. Das ist eine strukturelle Strategie. Was wir hier beschreiben, ist ein organisatorisches Datenproblem mit direkten operativen und geschäftlichen Folgen. Der Rest dieses Artikels befasst sich mit den Ursachen, den Kosten und dem, was die Behebung tatsächlich erfordert.
Wie Inhaltsilos entstehen
Die meisten Produktdatenfragmentierungen entstehen nicht durch schlechte Entscheidungen. Jede Abteilung löst ihr eigenes Problem unabhängig. Das Marketing wählt ein CMS, das redaktionelle Flexibilität bietet. Der Vertrieb hängt Spezifikationen an CRM-Datensätze, weil er dort bereits arbeitet. Das E-Commerce-Team integriert Produktdaten direkt in die Plattform, weil die Synchronisierung schnell sein muss. Jede Entscheidung ist vernünftig. Zusammen schaffen sie eine Situation, in der keine einzige Version des Produktdatensatzes maßgeblich ist.
Die Symptome werden deutlich, sobald man weiß, wonach man suchen muss, und erfahrungsgemäß folgen sie einem vorhersehbaren Muster. Eine Produktseite zeigt ein Gewicht, das PDF-Datenblatt ein anderes. Ein Kunde ruft an, nachdem er falsche Kompatibilitätsinformationen in einem Partnerportal gelesen hat. Ein Produktlaunch verzögert sich, weil die Koordination von Aktualisierungen über fünf Systeme zwei Wochen statt zwei Tage dauert. Das Marketingteam überarbeitet eine Beschreibung, die das Produktteam letzten Monat aktualisiert hatte, weil niemand es informiert hatte.
Unsere Kunden beschreiben oft dieselbe Situation, bevor sie mit uns zusammenarbeiten: ein wachsendes Produktportfolio, eine steigende Kanalanzahl und eine Datenverwaltungsbelastung, die schneller wächst als das Team.
Was zentralisierte Produktdaten wirklich bedeuten
Zentralisierte Produktdaten bedeuten ein maßgebliches Repository, aus dem alle anderen Systeme schöpfen. Nicht eine Oberfläche, die jeder nutzt. Keine Migration, die jedes Tool eliminiert. Die Website, die Marketplace-Feeds, die Vertriebstools, der Workflow für den gedruckten Katalog – all das bleibt bestehen. Was sich ändert, ist der Ursprung der Daten.
Das zentrale Repository enthält den Master-Produktdatensatz: Beschreibungen, Attribute, Spezifikationen, Bilder, Kategorisierung, Preisreferenzen, regulatorische Daten und alle anderen Felder, die das Unternehmen benötigt. Nachgelagerte Systeme beziehen diese Daten über Integrationen. Wenn sich im Master-Datensatz etwas ändert, wird die Änderung automatisch an alle verbundenen Systeme weitergegeben.
In der Praxis ist dies am wichtigsten, wenn sich etwas ändert. Ein Lieferant aktualisiert Komponentenspezifikationen. Eine regulatorische Anforderung fügt ein neues Pflichtfeld hinzu. Ein Marken-Relaunch ändert die Beschreibung einer Produktlinie. Ohne einen zentralen Datensatz muss diese Änderung in jedem System separat nachverfolgt und angewendet werden, und jemand, irgendwo, wird eine vergessen. Mit einem zentralen Datensatz erfolgt die Änderung einmal und wird automatisch weitergegeben.
Dies ist die Kernfunktion eines Product Information Management Systems. Ein PIM sitzt zwischen den Datenquellen und den Vertriebskanälen – der einzige Punkt, an dem Produktinformationen erstellt, validiert, angereichert und genehmigt werden, bevor sie irgendwohin gelangen. Dieser zentrale Kontrollpunkt ist es, der zentralisierte Produktdaten von einem Konzept in etwas Operatives verwandelt.
AtroPIM basiert auf diesem Prinzip. Die Plattform verwaltet den vollständigen Produktdatensatz an einem Ort und verbindet sich mit nachgelagerten Systemen über eine REST-API, wobei die Dokumentation pro Instanz gemäß OpenAPI-Standards generiert wird. In der Praxis bedeutet das, dass kanalspezifische Varianten, Lokalisierung und Zugriffskontrollen auf Attributebene alle innerhalb desselben Systems verwaltet werden, ohne externe Middleware für die Kerndatenflüsse.
Die operativen Kosten von Inhaltsilos
Die direkten Kosten fragmentierter Produktdaten lassen sich leichter messen, als die meisten Teams erwarten. Zeit, die mit der Suche nach der aktuellen Version einer Datei verbracht wird, mit der erneuten Eingabe von Daten, die bereits anderswo vorhanden sind, mit der Korrektur von Fehlern, die Kunden erreicht haben, weil eine Aktualisierung sich nicht weitergegeben hat – das sind messbare Stunden. In Projekten, die wir für Hersteller mit mehreren tausend SKUs über mehrere Märkte hinweg umgesetzt haben, zeigt das Pre-PIM-Audit fast immer dasselbe: Ein erheblicher Teil der Produktmanagement-Zeit geht in Koordination und Korrektur, nicht in die eigentliche Verbesserung der Daten.
Rücksendequoten sind ein zuverlässiger Indikator. Laut dem Forrester Wave-Bericht über Product Information Management (Q2 2021) haben 18 % der US-amerikanischen Käufer einen online gekauften Artikel zurückgegeben, weil die Produktbeschreibung ungenau war. Rücksendungen kosten den Einzelhandel bereits über 890 Milliarden US-Dollar jährlich, so die National Retail Federation. Ungenaue Produktinhalte tragen direkt zu dieser Zahl bei und gehören zu den behebbarsten Ursachen.
AtroPIM-Nutzer verzeichnen einen messbaren Rückgang der Rücksendungen innerhalb von Monaten nach der Zentralisierung von Produktdaten, weil die Spezifikationen, die Kunden auf der Website sehen, endlich mit dem übereinstimmen, was sie erhalten. Die Lösung ist kein besseres Texten, sondern das Schließen der Lücke zwischen der maßgeblichen Spezifikation und der veröffentlichten.
Produktlaunch-Zeitpläne sind das andere messbare Opfer. Wenn ein neues Produkt koordinierte Aktualisierungen über eine Website, drei Marketplace-Konten, einen gedruckten Katalog, einen Vertriebskonfigurator und ein Partnerportal erfordert, wird der Launch-Termin vom langsamsten System in der Kette bestimmt. Mit zentralisierten Produktdaten und automatisierter Verteilung verlagert sich der Engpass von der Koordination zur Inhaltserstellung – wo er sein sollte.
Datenqualität als strukturelles Problem
Schlechte Produktdatenqualität wird in der Regel als Inhaltsproblem behandelt. Teams stellen Texter ein, führen Audits durch, erstellen Stilrichtlinien. Das hilft, aber es bekämpft das Symptom und nicht die Ursache. Wenn dasselbe Produktattribut in vier Systemen ohne definierten Eigentümer und ohne Validierungsregel existiert, wird es abweichen. Die Menschen, die es pflegen, sind nicht nachlässig. Es gibt schlicht keinen Mechanismus, der es konsistent hält.
Zentralisierung macht Datenqualität zu einer strukturellen Eigenschaft und nicht zu einer Wartungsaufgabe. Validierungsregeln erzwingen Vollständigkeit, bevor ein Datensatz veröffentlicht werden kann. Workflow-Stufen leiten Änderungen durch die Überprüfung, bevor sie einen Kanal erreichen. Die Attributverantwortung wird zugewiesen, sodass es immer eine definierte Person gibt, die für ein bestimmtes Feld verantwortlich ist, und die Versionshistorie verfolgt, was sich geändert hat und wer es genehmigt hat. Diese Regeln auf der Datenschicht durchzusetzen, anstatt Probleme nach der Veröffentlichung zu entdecken, ist das, was zentralisierte Produktdaten von einer ordentlichen Tabelle unterscheidet.
AtroPIM unterstützt konfigurierbare Validierung auf Attributebene. Pflichtfelder, zulässige Wertebereiche, Formatregeln und bedingte Logik können alle durchgesetzt werden, bevor ein Datensatz weitergeleitet wird. Das integrierte DAM in AtroCore verwaltet Assets als Teil desselben Datensatzes und nicht als separates System, sodass der Produktdatensatz von der Spezifikation bis zum endgültig veröffentlichten Asset kohärent bleibt.
Governance ist keine Option
PIM hilft erheblich, aber das ist nicht alles. Organisationen, die ein PIM ohne Governance-Frameworks implementieren, erzielen inkonsistente Ergebnisse. Die Technologie funktioniert, aber ohne definierte Verantwortlichkeiten, Genehmigungsworkflows und Qualitätsstandards beginnt das neue System dieselben Probleme anzuhäufen, die das alte hatte. Verschiedene Personen interpretieren Attribute unterschiedlich. Felder werden inkonsistent befüllt. Die einzige Quelle der Wahrheit wird zu einer etwas übersichtlicheren Version der ursprünglichen Fragmentierung.
In Projekten, in denen die Datenmigration als Ziellinie betrachtet wurde, driftet der Katalog innerhalb von sechs Monaten erneut ab – nicht weil die Plattform versagt hat, sondern weil niemand die Attribute nach dem Go-live besaß.
Governance bedeutet, vor Beginn der Datenmigration zu entscheiden, wer jedes Attribut besitzt, welche Werte akzeptabel sind, wie der Genehmigungsprozess für verschiedene Änderungstypen aussieht und welchen Qualitätsstandard ein Datensatz erfüllen muss, bevor er verteilt werden kann. Das ist nicht kompliziert, erfordert aber funktionsübergreifende Abstimmung, die Technologie allein nicht liefern kann.
Die Organisationen, die den größten Nutzen aus zentralisierten Produktdaten ziehen, behandeln sie als fortlaufende Fähigkeit und nicht als einmaliges Implementierungsprojekt. Kataloge ändern sich. Kanäle ändern sich. Märkte ändern sich. Ein Governance-Modell, das sich anpassen kann, ist mehr wert als ein anfänglich perfektes Setup, das später brüchig wird.
Die Kanaldimension
Der Druck auf die Governance skaliert direkt mit der Kanalanzahl. Ein Unternehmen, das über eine Website und einen Marketplace verkauft, hat ein begrenztes Risiko für Inkonsistenz. Ein Hersteller, der über eine direkte Website, drei regionale Marketplaces, ein Netzwerk von Wiederverkäufern, ein B2B-Portal und einen Druckkatalog vertreibt, steht vor einem Koordinationsproblem, das manuelle Prozesse nicht zuverlässig lösen können und bei dem eine Governance-Lücke sich schnell verstärkt.
Jeder Kanal hat seine eigenen Anforderungen. Marketplaces erzwingen spezifische Attributformate und Vollständigkeitsschwellen. Druck-Workflows erfordern Assets in definierten Formaten. Wiederverkäufer-Portale benötigen kanalspezifische Preise und lokalisierte Beschreibungen. Zentralisierte Produktdaten bewältigen diese Variationen, indem der Master-Datensatz einmal gespeichert und beim Output kanalspezifische Transformationsregeln angewendet werden, anstatt separate Produktdatensätze pro Kanal zu pflegen. Neue Kanal-Launches werden dadurch erheblich weniger aufwendig. Ohne Zentralisierung bedeutet das Hinzufügen eines Marketplace oder einer regionalen Storefront eine neue Datenmigration und eine neue Quelle für Inkonsistenz. Mit einem zentralen Datensatz und einer konfigurierbaren Ausgabeschicht ist es eine Konfigurationsaufgabe und kein Projekt.
Laut Mordor Intelligence ist der globale PIM-Markt im Jahr 2026 mit 19,95 Milliarden US-Dollar bewertet und wird bis 2031 voraussichtlich 37,39 Milliarden US-Dollar erreichen, mit einer jährlichen Wachstumsrate von 13,38 %. Cloud-Deployments machen 63,5 % dieses Marktes aus und wachsen am schnellsten – was mit unserer praktischen Erfahrung übereinstimmt. Der Wechsel weg von On-Premise-Infrastruktur hat die Adoptionshürde für mittelständische Unternehmen erheblich gesenkt.
Wie man Inhaltsilos abbaut
Der häufige Fehler ist, mit der Tool-Auswahl zu beginnen. Die richtige Reihenfolge ist die entgegengesetzte: erst den aktuellen Zustand der Produktdaten verstehen, dann den Bedarf definieren, dann Plattformen evaluieren.
Mit einem Daten-Audit beginnen. Es muss nicht erschöpfend sein, um nützlich zu sein:
- Erfassen, wo Produktinformationen derzeit liegen
- Identifizieren, wer welche Art von Daten pflegt
- Dokumentieren, wo die schädlichsten Inkonsistenzen auftreten
- Kanäle und Produktkategorien priorisieren, in denen Fehler die direktesten Auswirkungen haben – sei es auf Rücksendequoten, entgangene Verkäufe oder Compliance-Risiken
Mit einer wenig sichtbaren Kategorie zu beginnen, verschwendet das Potenzial des Piloten, internen Rückhalt aufzubauen und echte Governance-Lücken aufzudecken.
Einen Pilot vor der Skalierung durchführen. Eine Produktkategorie, ein Kanal oder ein Markt. Das Ziel ist nicht, zu beweisen, dass die Technologie funktioniert, sondern:
- Das Datenmodell zu verfeinern
- Den Governance-Prozess zu testen
- Ein internes Verständnis dafür aufzubauen, was Zentralisierung tatsächlich erfordert, bevor sie auf den gesamten Katalog ausgeweitet wird
Einen Bereich wählen, in dem der Schmerz offensichtlich und messbar ist: eine Produktlinie mit hohen Rücksendequoten oder ein Kanal, in dem Update-Verzögerungen zu sichtbaren Problemen geführt haben.
Attributverantwortung vor Beginn der Migration definieren. Jedes Feld braucht eine verantwortliche Rolle, und das ist der Schritt, den die meisten Teams überspringen, weil er sich vor dem Go-live verfrüht anfühlt. In der Praxis verbringen Teams, die ihn überspringen, das erste Jahr nach dem Go-live damit, Entscheidungen neu zu verhandeln, die vor dem Import des ersten Datensatzes hätten getroffen werden sollen. Einige Grundsätze, die vor dem Launch festgelegt werden sollten: Qualitätsschwellen sollten den geschäftlichen Auswirkungen entsprechen und nicht der theoretischen Vollständigkeit. Kanal-Konnektoren sind ein Produktdatenanliegen – die Personen, die wissen, was jeder Kanal erfordert, sollten die Ausgaberegeln konfigurieren, nicht nur die Ingenieure, die die Verbindung aufbauen.
Change Management als Kernlieferung behandeln. Teams, die Produktdaten jahrelang über Tabellenkalkulationen und E-Mails verwaltet haben, haben etablierte Gewohnheiten, und diese Gewohnheiten verschwinden nicht, wenn ein neues System in Betrieb geht. Das häufigste Versagensmuster ist, Menschen darin zu schulen, wie sie die Plattform nutzen, ohne zu erklären, warum der Prozess so strukturiert ist, wie er ist. Wenn Menschen die Logik verstehen (warum Attribute Eigentümer haben, warum Änderungen durch Überprüfung gehen, warum das Datenmodell so aufgebaut ist, wie es ist), folgt die Akzeptanz viel natürlicher.
Was sich nach der Zentralisierung ändert
Die operativen Veränderungen sind greifbar. Produktlaunches, die zuvor mehrteilige Koordinationszyklen erforderten, werden auf Tage komprimiert. Attributaktualisierungen werden in Stunden statt Wochen an alle Kanäle weitergegeben. Das Onboarding neuer Kanäle wird zu einer Konfigurationsaufgabe statt zu einem Datenmigrationsprojekt.
Die weniger offensichtliche Veränderung ist das, was Teams aufhören zu tun. Die Stunden, die mit dem Abgleichen widersprüchlicher Produktdatensätze verbracht wurden, mit der Suche nach der aktuellen Version einer Datei, mit der Korrektur von Fehlern, die von Kunden statt von der internen Überprüfung entdeckt wurden – diese verschwinden. Die Zeit verlagert sich auf Inhaltsverbesserung, Marktanalyse und Kanalausbau.
In unserem jüngsten Projekt für einen mittelgroßen Hersteller schätzte das Produktteam, dass es innerhalb des ersten Quartals nach dem Go-live etwa zwei volle Arbeitstage pro Woche zurückgewann (Zeit, die zuvor in die Datenkoordination statt in die Datenverbesserung geflossen war).
Hersteller, mit denen wir zusammengearbeitet haben, beschreiben einen konsistenten Übergang: In den ersten Monaten nach der Zentralisierung von Produktdaten ist die Haupttätigkeit die Bereinigung. Fehler, die sich über Systeme hinweg angesammelt hatten, werden sichtbar und korrigiert. Nach dieser Phase verlagert sich die Arbeit auf die Anreicherung. Mit einer zuverlässigen Grundlage wird es praktikabel, die Attributvollständigkeit systematisch zu verbessern, lokalisierte Inhalte hinzuzufügen und kanalspezifische Varianten zu erstellen – Arbeit, die immer auf der Roadmap stand, aber nie ganz erreicht wurde, weil die Wartungslast keinen Raum dafür ließ. Das ist der praktische Unterschied zwischen dem Verwalten fragmentierter Daten und dem Besitzen davon.