Single Source of Truth für Produktdaten: Warum so viele Unternehmen daran scheitern

Fragen Sie zehn Produktmanager in einem mittelständischen Unternehmen, wo die „echte“ Produktbeschreibung liegt, bekommen Sie zehn verschiedene Antworten. Einer zeigt auf das ERP. Ein anderer öffnet eine Excel-Tabelle. Der dritte verweist auf einen SharePoint-Ordner, den seit zwei Jahren niemand mehr gepflegt hat. Und die Marketingabteilung hat ihre eigene Datei, die „eigentlich aktuell“ sein soll.

Genau das ist das Problem. Nicht fehlendes Bewusstsein, nicht fehlende Systeme. Sondern das strukturelle Auseinanderdriften von Daten, das über Jahre passiert, weil niemand explizit entschieden hat, welche Quelle gilt. Die Folge: fehlerhafte Produktseiten, erhöhte Retourenquoten, verzögerte Markteinführungen und ein Support-Team, das täglich Brandwände zwischen widersprüchlichen Datensätzen baut.

Eine Single Source of Truth für Produktdaten ist kein technisches Konzept. Es ist eine organisatorische Entscheidung, die mit Technik umgesetzt wird. Und genau deshalb scheitern so viele Unternehmen dabei.

Was „Single Source of Truth“ für Produktdaten bedeutet

Der Begriff klingt nach einem einfachen Prinzip: Alle Produktdaten stammen aus einer einzigen, maßgeblichen Quelle. Jedes System, jeder Kanal, jeder Prozess greift auf dieselbe Datenbasis zurück. Änderungen passieren an einem Ort und propagieren sich von dort aus.

In der Praxis ist das komplexer. Eine SSOT bedeutet nicht, dass alle Produktstammdaten in einem einzigen System gespeichert sind. Das wäre weder realistisch noch sinnvoll. ERP-Systeme verwalten Lagerbestände und Preise. CRM-Systeme führen Kundeninformationen. Ein Product Information Management-System verwaltet Marketingdaten, Beschreibungen und kanalspezifische Attribute.

Das Konzept der Single Source of Truth meint vielmehr: Für jeden Datentyp gibt es eine definierte, autoritative Quelle. Alle anderen Systeme beziehen diese Daten von dort, anstatt eigene Kopien zu pflegen.

Was nach einer Selbstverständlichkeit klingt, ist in der Unternehmenswirklichkeit der Ausnahmefall. Die folgende Übersicht zeigt, welches System für welchen Datenbereich typischerweise die autoritative Quelle sein sollte:

Datenbereich	Autoritative Quelle	Nur Empfänger
Marketingtexte, Beschreibungen	PIM	Shop, Marktplätze, Katalog
Technische Attribute, Spezifikationen	PIM oder ERP (je nach Prozess)	Shop, Datenblätter, B2B-Portal
Preise, Konditionen	ERP	Shop, PIM, Marktplatz
Lagerbestände, Verfügbarkeit	ERP / WaWi	Shop, Marktplätze, PIM
Produktbilder, Medien-Assets	DAM	PIM, Shop, Marktplätze
Kundendaten, Kontakte	CRM	Shop, Marketingtools

Diese Rollenverteilung klingt einfach. Ohne explizite Entscheidung und dokumentierte Governance ist sie in keinem Unternehmen gelebte Realität.

Warum Datenduplikation der Normalzustand ist

Datenduplikation entsteht nicht durch schlechtes Management. Sie entsteht durch vernünftige Entscheidungen, die unter Zeitdruck getroffen werden.

Das Marketingteam braucht kurzfristig eine überarbeitete Produktbeschreibung für eine Kampagne. Der Weg über IT und ERP dauert drei Wochen. Also pflegt man die Änderung direkt im Shop-Backend ein. Das funktioniert. Der Prozess wird wiederholt. Nach sechs Monaten hat der Shop Beschreibungen, die nirgendwo sonst stehen.

Ein Außendienstmitarbeiter braucht ein Datenblatt für ein Kundengespräch. Er findet eine PDF aus 2021, ergänzt die neuen Specs manuell und speichert sie auf seinem Laptop. Beim nächsten Gespräch schickt er diese Datei. Sein Kollege findet die Datei im gemeinsamen Laufwerk und hält sie für die aktuelle Version.

Ein Marktplatz-Manager pflegt Produktdaten direkt in den jeweiligen Portalen, weil die Anforderungen von Amazon, Zalando und dem eigenen Shop zu unterschiedlich sind, um sie aus einer Quelle zu bedienen. Nach einem Jahr gibt es drei verschiedene Datenstände für dasselbe Produkt.

Jede dieser Entscheidungen war rational. Im Rückblick hat jede von ihnen zur Fragmentierung der Produktstammdaten beigetragen.

Was schlechte Datenqualität Ihr Unternehmen wirklich kostet

Datenduplikation ist kein abstraktes Problem. Sie hat konkrete Auswirkungen auf den Geschäftsbetrieb, die sich in Euro und Prozent messen lassen.

Laut dem Gartner-Report „How to Stop Data Quality Undermining Your Business“ (2021) kosten schlechte Daten Unternehmen durchschnittlich 12,9 Millionen Dollar pro Jahr. Dieser Wert gilt für größere Unternehmen, ist aber in seiner Struktur auf den Mittelstand übertragbar. Für Hersteller mit mehreren Hundert bis einigen Tausend Produkten bedeutet das typischerweise:

• Erhöhte Retourenquoten: 20 bis 40 Prozent aller Retouren im E-Commerce gehen auf fehlerhafte oder unvollständige Produktdaten zurück (Händlerbund-Studie 2022). Bei einem Onlineshop mit 2 Millionen Euro Umsatz und 15 Prozent Retourenquote kann eine Verbesserung der Datenkonsistenz um 20 Prozent die Retourenkosten um rund 60.000 Euro jährlich senken.
• Verzögerte Markteinführungen: In Unternehmen ohne klare Datenstrategie dauert die Vorbereitung für einen neuen Artikel im Schnitt 3 bis 5 Arbeitstage, weil Produktdaten manuell zusammengesucht, bereinigt und harmonisiert werden müssen. Mit einer funktionierenden SSOT sinkt dieser Aufwand auf unter einen halben Tag.
• Compliance-Risiken: Wenn dasselbe Produkt auf verschiedenen Kanälen mit unterschiedlichen technischen Daten erscheint, entstehen Support-Anfragen, Rückgaben und bei regulierten Produkten (Medizintechnik, Chemie, Elektronik) rechtliche Konsequenzen. Die EU-Produktsicherheitsverordnung GPSR verschärft diesen Druck ab 2025 erheblich.

Warum SSOT-Projekte scheitern: 5 Ursachen

1. Historisch gewachsene Silos ohne klare Eigentümerschaft

In den meisten Unternehmen gibt es keine bewusste Entscheidung darüber, welches System für welche Daten zuständig ist. Das ERP kam für Buchhaltung und Logistik. Der Shop wurde implementiert, um online zu verkaufen. Das PIM wurde eingeführt, weil jemand erkannt hat, dass Produktbeschreibungen besser organisiert werden müssen.

Niemand hat dabei definiert, welche Daten in welchem System „leben“ und welche Systeme nur Empfänger sind. Das Ergebnis: Jedes System wird von verschiedenen Teams als primäre Quelle behandelt, jedes Team pflegt seine eigene Wahrheit.

2. Fehlende Dateneigentümerschaft

Solange niemand verantwortlich ist, ist jeder ein bisschen verantwortlich. Das bedeutet in der Praxis: niemand.

Produktdaten berühren mindestens vier Abteilungen: Einkauf oder Produktmanagement (technische Spezifikationen), Marketing (Beschreibungen und Assets), IT (Systemintegration) und Vertrieb (kanalspezifische Anforderungen). Ohne klare Entscheidung, wer für welchen Datenbereich die finale Hoheit hat, entstehen Parallelstrukturen. Ein Data Owner pro Datenfeld, mit Eskalationsweg und Freigabeprozess, ist keine Bürokratie. Es ist die Grundvoraussetzung für funktionierende Datenkonsistenz.

3. Excel als Brücken-Werkzeug, das zum Fundament wird

Excel-Tabellen sind flexibel, jeder kann sie bearbeiten, und sie funktionieren ohne IT-Aufwand. Das macht sie zur perfekten Notlösung für Datentransfers und Ad-hoc-Anpassungen. Das Problem: Notlösungen werden zu dauerhaften Lösungen.

Besonders hartnäckig wird Excel bei Lieferantendaten. Ein Lieferant schickt ein Datenblatt im XLS-Format. Jemand bereinigt es manuell und importiert es in den Shop. Die Originaldatei landet im Laufwerk. Beim nächsten Update des Lieferanten beginnt das Spiel von vorn, aber niemand erinnert sich mehr, welche Felder beim letzten Mal angepasst wurden. In einem Produktportfolio mit 500 Lieferanten und 8.000 Artikeln ist das kein Randproblem, das ist der Alltag.

4. Zugriffskontrollen, die das Gegenteil von dem bewirken, was sie sollen

Das ist die Ursache, die die wenigsten so benennen: In vielen Unternehmen sind Datenänderungen im ERP an IT-Tickets gebunden. Für jede Anpassung muss ein Antrag gestellt, genehmigt und eingeplant werden.

Der gut gemeinte Versuch, Datenqualität durch Zugriffskontrollen zu schützen, zwingt operative Teams dazu, Daten anderswo zu pflegen, wo sie schneller sind. Das Resultat ist exakt die Fragmentierung, die man verhindern wollte. Zugriffskontrollen ohne Self-Service-Prozesse für Fachabteilungen erzeugen Schatten-IT. Das ist keine Spekulation, das ist in fast jedem mittelständischen Projekt das erste, was wir vorfinden.

5. Governance auf dem Papier statt in der Praxis

Selbst Unternehmen, die ein PIM einführen, scheitern oft nicht am System, sondern an der Governance-Frage dahinter: Welche Attribute müssen in welcher Qualität vorliegen, bevor ein Produkt freigegeben wird? Was passiert, wenn ein Lieferant fehlerhafte Stammdaten liefert? Wer prüft Vollständigkeit?

Ohne gelebte Governance-Prozesse wird auch Pimcore zu einem weiteren Datensilo mit besserem Interface. Die Technologie ist nie das Bottleneck. Es ist immer die Frage, wer das Recht hat, „Nein, diese Daten sind nicht gut genug“ zu sagen.

„Ein PIM ohne klare Verantwortung ist eine Datenbank mit Admin-Oberfläche. Der Unterschied zwischen Werkzeug und Wert entsteht erst, wenn jemand die Macht hat, Produktdaten abzulehnen, die nicht den definierten Standards entsprechen.“

Philipp Foreman

Geschäftsführer, onacy GmbH

Wie eine SSOT für Produktdaten in der Praxis aufgebaut wird

Der Aufbau einer Single Source of Truth für Produktdaten folgt keinem Schema, das sich auf jedes Unternehmen identisch anwenden lässt. Die Ausgangssituation ist immer unterschiedlich: Manche Unternehmen haben bereits ein PIM, das niemand nutzt. Andere verwalten 20.000 Artikel ausschließlich in Excel. Wieder andere haben drei parallele Systeme, die alle als „führend“ gelten.

Was sich über Projekte hinweg bewährt hat, ist dieser Ansatz:

1. Bestandsaufnahme aller Datenquellen: Bevor ein System eingeführt oder umstrukturiert wird, muss klar sein, wo Produktstammdaten aktuell tatsächlich leben. Das schließt offizielle Systeme ebenso ein wie inoffizielle: Shared-Drive-Ordner, persönliche Laufwerke, E-Mail-Anhänge, Tabellen in Projektmanagement-Tools. Diese Bestandsaufnahme ist ernüchternd, aber notwendig. In einem Projekt mit einem Kunden aus dem Bereich technischer Industriebedarf (ca. 200 Mitarbeiter, 4.500 Artikel) fanden wir 14 verschiedene Quellen für denselben Produktdatentyp. Erst mit diesem Bild ließ sich priorisieren.
2. Datenfelder klassifizieren und Eigentümer zuweisen: Für jeden Datentyp muss entschieden werden, welches System die autoritative Quelle ist, welche Teams dort schreiben dürfen und welche Systeme Daten nur beziehen. Eine einfache Matrix hilft: Datenfeld als Zeile, Systeme als Spalte, mit den Kategorien „Quelle“, „Empfänger“ und „Nicht relevant“. Diese Matrix ist kein IT-Dokument, sie ist ein Organisationsdokument und muss von Fachbereichsverantwortlichen unterzeichnet werden.
3. Prozesse vor Systemen definieren: Welcher Prozess stellt sicher, dass Produktdaten vor der Markteinführung vollständig und korrekt sind? Wer gibt frei? Was passiert bei Lieferantendaten mit Qualitätsproblemen? Diese Fragen müssen dokumentiert und gelebt werden, bevor Systemänderungen sinnvoll sind. Ein neues System löst kein Prozessproblem, es verstärkt es nur schneller.
4. Konsolidierung in ein zentrales System: Mit klaren Eigentümern und Prozessen kann die technische Konsolidierung beginnen. Ein Pimcore-basiertes PIM ist die natürliche Heimat für Marketingdaten, Beschreibungen, Attribute und kanalspezifische Ausspielungen. Das DAM für Medien-Assets lässt sich direkt integrieren, sodass Bild, Text und Attribut in einem Workflow freigegeben werden.
5. Integrationen automatisieren, manuelle Transfers abschaffen: Jeder manuelle Datentransfer zwischen Systemen ist ein potenzieller Divergenzpunkt. Automatisierte Integrationen via API oder Middleware sorgen dafür, dass Shop, Marktplätze und Kataloge stets aktuelle Daten aus der autoritativen Quelle beziehen. Als Faustregel gilt: Wenn ein Mensch Daten kopiert und in ein anderes System einfügt, ist das ein Integrationsproblem, kein Arbeitsproblem.

SSOT-Einführung: Diese Fallen kosten Projekte den Erfolg

Einige Muster wiederholen sich bei Projekten, die scheitern oder ins Stocken geraten:

• Der Big-Bang-Ansatz: Alle 10.000 Produktdaten auf einmal bereinigen, alle Systeme gleichzeitig umstellen, alle Abteilungen gleichzeitig schulen. Das scheitert fast immer. Der Aufwand wird um den Faktor drei unterschätzt, Prioritäten ändern sich, das Projekt zieht sich über zwei Jahre und verliert die interne Unterstützung. Besser: Mit dem wichtigsten Produktbereich beginnen, Erfolg demonstrieren, dann skalieren. Ein Pilot mit 200 Artikeln und zwei Kanälen zeigt in drei Monaten, ob das Modell funktioniert.
• Perfektion als Feind des Fortschritts: Manche Unternehmen warten, bis die Governance vollständig definiert ist, das Attributmodell final abgestimmt ist und alle Stakeholder Einigkeit erzielt haben. Das dauert Jahre. Eine pragmatische 80-Prozent-Lösung, die tatsächlich umgesetzt wird, ist mehr wert als eine theoretisch perfekte Lösung, die nie fertig wird. Governance entwickelt sich im Betrieb, nicht in Workshops.
• Technologie als Lösung verkaufen: „Wir kaufen Pimcore, dann ist das Problem gelöst.“ Das ist falsch. Ein PIM-System macht Datenkonsistenz möglich, es erzeugt sie nicht. Wer ein System einführt, ohne die organisatorischen Fragen zu klären, schafft ein weiteres Datensilo mit besserem Interface und höheren Lizenzkosten.
• Stakeholder-Management als Nachgedanke: Das Marketing versteht nicht, warum es für jede Produktbeschreibung jetzt durch ein zentrales System gehen soll, das langsamer ist als das Shop-Backend. Der Vertrieb sieht nicht, warum seine kanalspezifischen Anpassungen jetzt nicht mehr direkt möglich sein sollen. Wenn diese Widerstände nicht adressiert werden, werden die Prozesse umgangen, und das neue System wird zu einem weiteren ungenutzten Werkzeug im Tech-Stack.

„Wir haben drei Jahre gebraucht zu verstehen, dass unser PIM kein SSOT-Problem löst, solange Marketing weiter eigene Exporte pflegt. Die Einführung von Pimcore war nicht unser Problem. Das Problem war, dass niemand die Autorität hatte, dem Marketingteam zu sagen: Diese Exporte werden ab sofort nicht mehr gepflegt.“

CT

CDO, mittelständischer Markenhersteller

Name auf Wunsch anonymisiert · Branche: Konsumgüter, ca. 350 Mitarbeiter

Was erfolgreiche Projekte gemeinsam haben

Unternehmen, die eine funktionierende Single Source of Truth für Produktdaten aufgebaut haben, teilen einige Gemeinsamkeiten. Sie sind keine Gemeinsamkeiten in der Technologieauswahl, auch nicht in der Unternehmensgröße. Sie sind Gemeinsamkeiten in der Führungsstruktur.

Erstens: Es gibt einen Executive Sponsor, der das Projekt nach oben hin absichert und Abteilungsgrenzen überbrücken kann. Nicht ein IT-Projektleiter, der intern kämpfen muss. Sondern jemand auf Geschäftsführungs- oder Bereichsleitungsebene, der bei Konflikten zwischen Abteilungen eine Entscheidung treffen kann und diese auch trifft.

Zweitens: Das Projekt beginnt mit einem konkreten Datenproblem, das alle beteiligten Stakeholder spüren. Nicht mit einer abstrakten Vision von „besserer Datenqualität“. Zum Beispiel: Die Retourenquote für Produktkategorie X ist 32 Prozent, weil Maßangaben in Shop und Katalog seit 18 Monaten voneinander abweichen. Das ist ein Problem, das Marketing, Vertrieb und Logistik gleichzeitig schmerzt. Von dort aus lässt sich ein Konsens für Veränderung aufbauen.

Drittens: Erfolg wird messbar definiert, bevor das Projekt beginnt. Welche Fehlerrate ist in 12 Monaten das Ziel? Welche Time-to-Market für neue Artikel? Welche Attributvollständigkeit vor Kanalfreigabe? Ohne messbare Ziele wird aus einem Datenprojekt ein Dauerprojekt ohne Abschluss.

Und schließlich: Die Unternehmen, die es schaffen, verstehen, dass eine SSOT keine einmalige Migration ist. Es ist eine dauerhafte Änderung in der Art, wie das Unternehmen mit Produktdaten umgeht. Systeme lassen sich in einem Jahr implementieren. Die Kultur des „eine Quelle, eine Wahrheit“ aufzubauen dauert länger.

Häufige Fragen zur Single Source of Truth für Produktdaten

Fazit

Eine Single Source of Truth für Produktdaten ist erreichbar. Aber nicht durch die Einführung eines Systems allein. Es braucht klare Entscheidungen über Dateneigentümerschaft, Prozesse, die Governance operationalisieren, und eine technische Infrastruktur, die diese Prozesse unterstützt.

Das Scheitern vieler Unternehmen liegt nicht an mangelndem Willen und auch nicht an fehlenden Budgets. Es liegt an der Unterschätzung der organisatorischen Dimension. Wer versteht, dass SSOT eine Führungsaufgabe ist und keine IT-Aufgabe, hat die wichtigste Grundlage gelegt.

Der erste Schritt ist nicht die Systemauswahl. Der erste Schritt ist die Frage: Wer darf in unserem Unternehmen entscheiden, welche Produktdaten die Wahrheit sind?