Im Lager wird nachgewogen. Im Versand werden Verpackungsdaten korrigiert. Auf Marktplätzen fehlen Variantenattribute. Mitarbeiter gleichen Bestände manuell ab oder prüfen Informationen, bevor ein Auftrag weiterbearbeitet werden kann.
Solche Probleme werden im Alltag oft einzeln betrachtet. Dabei haben sie häufig eine gemeinsame Ursache: Die vorhandenen Produktdaten sind für den jeweiligen Prozess nicht vollständig, eindeutig oder fachlich korrekt.
Ein ERP-System kann technisch sauber eingerichtet sein, Schnittstellen können stabil laufen und Prozesse können weitgehend automatisiert sein. Wenn die Datenbasis nicht stimmt, entstehen trotzdem Rückfragen, Korrekturen und manuelle Umwege.
Produktdatenqualität ist deshalb keine reine Aufgabe der Artikelpflege. Sie ist eine Voraussetzung dafür, dass ERP, Lager, Versand, Marktplätze und Automatisierungen zuverlässig funktionieren.
Produktdaten steuern nicht nur Inhalte im Onlineshop, sondern auch operative Prozesse in ERP, Lager, Versand, Einkauf und Vertrieb.
Gute Produktdaten müssen nicht nur vollständig sein. Sie müssen korrekt, eindeutig, konsistent, aktuell und für den jeweiligen Prozess nutzbar sein.
Zentrale Datenhaltung ist nicht automatisch gleichbedeutend mit guter Datenqualität. Auch ein zentral gepflegter Wert kann falsch oder für einen nachgelagerten Prozess ungeeignet sein.
Automatisierung beseitigt schlechte Daten nicht. Sie kann vielmehr dazu führen, dass fehlerhafte Informationen schneller und konsequenter durch die gesamte Systemlandschaft weitergegeben werden.
Entscheidend ist deshalb, welche Daten ein Prozess benötigt, welches System sie führt und wer fachlich für ihre Qualität verantwortlich ist.
Bei Produktdaten denken viele Unternehmen zunächst an Titel, Beschreibungen, Bilder, Kategorien oder technische Merkmale im Onlineshop. Für operative Prozesse sind jedoch zahlreiche weitere Informationen relevant.
Dazu gehören beispielsweise Artikelnummern, GTINs, Maße, Gewichte, Verpackungseinheiten, Varianten, Lieferanteninformationen und Versanddaten. Hinzu kommen dynamische Informationen wie Bestand, Verfügbarkeit oder Beschaffungsstatus.
Diese Daten werden nicht nur angezeigt. Systeme verwenden sie, um Prozesse auszuführen und Entscheidungen zu treffen.
Genau deshalb werden Datenprobleme häufig erst sichtbar, wenn Abläufe stärker digitalisiert, integriert oder automatisiert werden. Ein Mitarbeiter kann fehlende oder unklare Informationen häufig durch Erfahrung kompensieren. Eine Schnittstelle, ein Workflow oder ein WMS kann das ohne definierte Regeln nicht.
Was im manuellen Prozess noch irgendwie funktioniert, wird in einer automatisierten Prozesskette schnell zur fehlenden Entscheidungsgrundlage.
Nicht jede Information hat dieselbe Funktion. Entscheidend ist deshalb nicht, möglichst viele Datenfelder zu pflegen, sondern die Informationen zu identifizieren, die für die eigenen Prozesse tatsächlich benötigt werden.
| Datenbereich | Beispiele | Typische abhängige Prozesse |
|---|---|---|
| Identifikation | Artikelnummer, SKU, GTIN | ERP, Lager, Marktplätze, Schnittstellen |
| Physische Eigenschaften | Länge, Breite, Höhe, Gewicht | Lagerplanung, Versand, Verpackung |
| Verpackungsdaten | Stück pro Karton, Verpackungsmaße, Verpackungsgewicht | Einkauf, Wareneingang, Versand |
| Varianten | Größe, Farbe, Ausführung | Shop, Marktplätze, Lager, Picking |
| Produktattribute | Material, Leistung, technische Merkmale | Shop, Filter, Marktplätze, Produktfeeds |
| Lieferantendaten | Lieferant, Lieferantenartikelnummer, Einkaufseinheit | Einkauf, Beschaffung, Disposition |
| Versandinformationen | Versandklasse, Sperrgut, relevante Verpackungsdaten | Versandregeln, Carrier, Kalkulation |
| Dynamische Daten | Bestand, Verfügbarkeit, Beschaffungsstatus | Shop, Marktplätze, Disposition, Kundenservice |
Dabei ist eine fachliche Unterscheidung wichtig: Ein Lagerbestand ist kein klassisches Stammdatum, weil er sich laufend verändert. Für die Qualität der E-Commerce-Prozesse ist seine Verlässlichkeit trotzdem entscheidend.
Ein Datenfeld ist außerdem nicht automatisch gut, nur weil es ausgefüllt ist. Wenn beispielsweise bei einigen Artikeln das Produktgewicht und bei anderen das Gewicht inklusive Verpackung hinterlegt wurde, ist das Feld formal vollständig, aber fachlich nicht konsistent nutzbar.
Ein ausgefülltes Datenfeld ist noch kein gutes Datenfeld.
Wenn für jeden Artikel ein Gewicht hinterlegt ist, klingt das zunächst nach hoher Datenqualität. Wurde das Gewicht jedoch teilweise geschätzt, teilweise mit Verpackung erfasst und teilweise ohne Verpackung, sind die Daten zwar formal vollständig, fachlich aber kaum zuverlässig nutzbar.
Produktdatenqualität lässt sich deshalb aus mehreren Perspektiven betrachten.
- Vollständigkeit bedeutet, dass für den jeweiligen Prozess notwendige Informationen vorhanden sind.
- Korrektheit bedeutet, dass der gespeicherte Wert dem tatsächlichen Sachverhalt entspricht.
- Konsistenz bedeutet, dass dieselbe Information nicht in verschiedenen Systemen widersprüchlich geführt wird.
- Eindeutigkeit bedeutet, dass Artikel und Varianten zweifelsfrei identifiziert werden können.
- Aktualität bedeutet, dass Änderungen dort berücksichtigt werden, wo sie prozessual relevant sind.
- Verwendbarkeit bedeutet schließlich, dass ein Wert nicht nur existiert, sondern auch in der Form vorliegt, die das nachgelagerte System benötigt.
Gerade der letzte Punkt wird häufig unterschätzt. Eine Information kann fachlich richtig und trotzdem technisch unbrauchbar sein, wenn Einheiten, Formate oder Zuordnungen nicht zur Schnittstelle oder zum Zielsystem passen.
Schlechte Produktdaten fallen selten bei der Artikelanlage auf. Sie werden meist erst sichtbar, wenn ein nachgelagerter Prozess die Information tatsächlich benötigt.
Fehlen beispielsweise Maße oder Gewichte, muss der Versandartikel möglicherweise nachmessen oder nachwiegen. Sind Verpackungseinheiten nicht sauber definiert, können Einkauf, Wareneingang und Lager mit unterschiedlichen Mengeneinheiten arbeiten. Eine unklare Variantenstruktur kann dazu führen, dass Shop, ERP und Marktplatz denselben Artikel unterschiedlich abbilden. Fehlende Produktattribute wiederum werden häufig erst dann zum Problem, wenn ein neuer Marktplatz oder Produktfeed genau diese Information voraussetzt.
Das Ergebnis sind nicht nur fehlerhafte Datenfelder. Es entstehen zusätzliche Arbeitsschritte.
Mitarbeiter prüfen Informationen manuell, korrigieren Datensätze, stimmen sich zwischen Abteilungen ab oder umgehen automatisierte Prozesse, weil sie den Daten nicht vertrauen. Mit zunehmendem Auftragsvolumen wächst dieser Aufwand mit.
| Datenproblem | Mögliche Folge im Prozess | Typischer manueller Workaround |
|---|---|---|
| Maße oder Gewichte fehlen | Versand- oder Verpackungsentscheidung ist nicht zuverlässig möglich | Mitarbeiter misst oder wiegt nach |
| Verpackungseinheiten sind unklar | Einkauf, Wareneingang und Lager arbeiten mit unterschiedlichen Mengen | Mengen werden manuell geprüft oder korrigiert |
| Varianten sind uneindeutig | Falsche Zuordnungen zwischen ERP, Shop und Marktplätzen | Artikel oder Varianten werden nachgepflegt |
| GTINs oder Artikelnummern sind fehlerhaft | Produkte lassen sich nicht eindeutig identifizieren oder zuordnen | Identifikatoren werden manuell geprüft |
| Produktattribute fehlen | Filter, Feeds oder Marktplatzdaten bleiben unvollständig | Daten werden kanalweise ergänzt |
| Lieferantendaten sind uneinheitlich | Beschaffung und Disposition benötigen zusätzliche Abstimmungen | Einkauf recherchiert oder fragt nach |
| Bestände sind nicht zuverlässig | Shop oder Marktplatz zeigt eine falsche Verfügbarkeit | Mitarbeiter kontrolliert den tatsächlichen Bestand |
Besonders kritisch wird es, wenn sich Mitarbeiter an solche Korrekturen gewöhnen. Dann scheint der Prozess nach außen zu funktionieren, obwohl er nur deshalb stabil bleibt, weil fehlende Informationen ständig manuell ergänzt oder geprüft werden.
Technisch betrachtet läuft das System. Organisatorisch entsteht jedoch zusätzlicher Aufwand.
Ein guter Indikator für schlechte Datenqualität ist deshalb die Frage: An welchen Stellen müssen Mitarbeiter regelmäßig Informationen prüfen, ergänzen oder korrigieren, bevor ein Prozess weiterlaufen kann?
Eine zentrale Datenquelle kann Doppelpflege und widersprüchliche Datenstände reduzieren. Sie löst aber nicht automatisch das Problem der Datenqualität.
Ein Unternehmen kann Produktinformationen konsequent in einem einzigen ERP pflegen und trotzdem schlechte Daten haben.
Wenn dort falsche Maße, unklare Verpackungseinheiten oder uneindeutige Varianten gepflegt werden, verteilt das zentrale System diese Fehler lediglich besonders zuverlässig an alle angeschlossenen Systeme.
Ein falsches Versandgewicht kann beispielsweise im ERP korrekt als führender Wert hinterlegt sein und anschließend sauber an Shop, Marktplatz und Versandsoftware übertragen werden. Die Systemlandschaft ist technisch konsistent. Die Information ist trotzdem falsch.
Damit wird deutlich: Die Frage nach dem führenden System und die Frage nach der fachlichen Qualität eines Wertes sind zwei unterschiedliche Themen.
Zentrale Datenhaltung beantwortet vor allem: Wo wird eine Information gepflegt?
Produktdatenqualität beantwortet zusätzlich: Ist diese Information für die nachgelagerten Prozesse überhaupt korrekt und verwendbar?
Gerade diese Trennung ist wichtig, wenn Unternehmen ihre Systemlandschaft stärker integrieren oder automatisieren wollen.
Wo entstehen Ihre Datenprobleme?
Fehlerhafte Produktdaten zeigen sich oft erst im Lager, Versand oder auf Marktplätzen. Die eigentliche Ursache liegt jedoch häufig früher im Prozess oder in der Systemlandschaft.
Varianten gehören zu den Bereichen, in denen eine unsaubere Produktstruktur schnell mehrere Systeme betrifft.
Ein Produkt kann im Shop als eine gemeinsame Produktseite erscheinen. Für ERP, Lager, Marktplatz und Bestandsführung müssen die einzelnen verkaufbaren Varianten jedoch eindeutig unterscheidbar sein.
Dafür braucht es eine klare Logik: Welche Information beschreibt die Produktfamilie? Welche Information identifiziert die einzelne Variante? Welche Attribute unterscheiden die Varianten? Welche Artikelnummer und gegebenenfalls welche GTIN gehört zu welcher verkaufbaren Einheit?
Wenn diese Struktur im Ursprungssystem nicht sauber definiert ist, kann eine Schnittstelle das Problem nicht lösen. Sie kann lediglich versuchen, unterschiedliche Datenmodelle aufeinander abzubilden.
Marktplätze machen solche Schwächen häufig besonders schnell sichtbar. Dort gelten definierte Anforderungen an Identifikatoren, Attribute, Varianten oder andere Produktinformationen.
Der Marktplatz verursacht das Datenproblem dabei nicht zwangsläufig. Er zeigt häufig nur, dass die bisherige Datenstruktur innerhalb der eigenen Systemlandschaft funktioniert hat, für weitere Kanäle aber nicht eindeutig genug ist.
Deshalb sind Schnittstellenprojekte häufig gleichzeitig Datenprojekte.
In manuellen Abläufen gleichen Mitarbeiter viele Unklarheiten aus. Sie erkennen falsche Bezeichnungen, wissen aus Erfahrung, welcher Karton verwendet werden muss oder fragen nach, wenn Informationen fehlen.
Automatisierungen besitzen dieses Kontextwissen nicht automatisch. Ein Workflow arbeitet mit definierten Bedingungen. Eine Schnittstelle überträgt festgelegte Felder. Ein automatisierter Lagerprozess benötigt eindeutige Datenpunkte.
Wenn die Datenbasis schlecht ist, führt mehr Automatisierung deshalb nicht zwangsläufig zu weniger Aufwand. Im ungünstigsten Fall werden Fehler nur schneller und konsequenter durch die Systemlandschaft weitergegeben.
Vor einer Automatisierung sollte deshalb nicht nur gefragt werden, welcher manuelle Schritt ersetzt werden kann.
Ebenso wichtig ist: Auf welcher Datenbasis trifft der zukünftige Prozess seine Entscheidung?
Sind die dafür notwendigen Informationen nicht zuverlässig vorhanden, sollte zunächst die Daten- oder Prozessstruktur geklärt werden.
Die Forderung nach einer Single Source of Truth wird häufig mit einem einzigen zentralen System gleichgesetzt.
In komplexeren E-Commerce-Systemlandschaften ist diese Vorstellung jedoch oft zu einfach.
Das ERP kann beispielsweise führend für bestimmte operative Artikelstammdaten sein. Ein PIM kann umfangreiche Produktinformationen und kanalspezifische Inhalte verwalten. Ein WMS verarbeitet operative Lagerdaten. Andere Systeme können wiederum für weitere Datenbereiche verantwortlich sein.
Entscheidend ist deshalb nicht zwingend, dass jede Information in derselben Datenbank liegt.
Entscheidend ist, dass für relevante Daten klar definiert ist: Wo entsteht die Information? Welches System ist führend? Wer darf sie verändern? Welche Systeme erhalten sie? In welcher Richtung wird synchronisiert? Und was passiert bei einem Konflikt?
Eine belastbare Datenarchitektur entsteht damit nicht allein durch Zentralisierung, sondern durch klar definierte Datenhoheit und Datenflüsse.
Viele Datenprobleme entstehen organisatorisch, lange bevor sie technisch sichtbar werden.
Der Einkauf erhält Informationen vom Lieferanten. Das E-Commerce-Team ergänzt Attribute und Produktinformationen. Das Lager stellt fest, dass Maße nicht stimmen. Die IT betreut Schnittstellen. Wenn niemand für die Datenstruktur als Ganzes verantwortlich ist, werden Fehler oft nur dort korrigiert, wo sie gerade auffallen.
Dadurch entsteht eine fragmentierte Verantwortung.
| Frage | Was geklärt sein sollte |
|---|---|
| Wer legt neue Artikel an? | Definierte Rolle und Anlageprozess |
| Wer prüft Lieferantendaten? | Verantwortlicher Fachbereich |
| Wer definiert Pflichtfelder? | Prozessverantwortliche und Fachbereiche |
| Wer korrigiert falsche Werte? | Klar benannter Verantwortlicher |
| Wer überwacht Schnittstellenfehler? | Technische Verantwortung |
| Wer prüft fachliche Datenfehler? | Zuständiger Fachbereich |
Produktdatenpflege wird damit von einer Nebenaufgabe zu einem Bestandteil definierter Geschäftsprozesse.
Das ist besonders wichtig, weil technische und fachliche Verantwortung nicht dasselbe sind. Die IT kann erkennen, dass eine Schnittstelle einen Wert nicht übertragen konnte. Ob der zugrunde liegende Wert fachlich korrekt ist, muss häufig ein anderer Bereich entscheiden.
Eine vollständige Bereinigung sämtlicher vorhandener Produktdaten ist für viele Unternehmen weder realistisch noch notwendig.
Sinnvoller ist ein prozessorientiertes Vorgehen.
Zunächst sollte dokumentiert werden, welche Systeme und Prozesse auf welche Produktinformationen zugreifen. Anschließend lässt sich bestimmen, welche Daten für diese Prozesse tatsächlich kritisch sind.
Ein sinnvoller Ablauf besteht aus sechs Schritten:
- Datenflüsse und beteiligte Systeme dokumentieren.
- Prozesskritische Produktinformationen identifizieren.
- Für relevante Daten ein führendes System bestimmen.
- Fachliche Definitionen und zulässige Werte festlegen.
- Verantwortlichkeiten für Anlage, Änderung und Prüfung zuweisen.
- Wiederkehrende Fehler nicht nur korrigieren, sondern ihre Ursache untersuchen.
Gerade der letzte Schritt ist entscheidend.
Wenn Mitarbeiter im Versand immer wieder Gewichtsdaten korrigieren müssen, besteht die nachhaltige Lösung nicht darin, diese Korrektur effizienter zu machen. Es muss geklärt werden, warum die Information vorher fehlt, falsch entsteht oder nicht zuverlässig weitergegeben wird.
Die Ursache kann in der Artikelanlage liegen, bei einem Lieferanten, in einer fehlenden Validierung, in unklaren Zuständigkeiten oder in der Zuordnung zwischen mehreren Systemen.
Erst wenn diese Ursache verstanden ist, lässt sich der Prozess nachhaltig verbessern.
Systemwechsel und ERP-Einführungen machen historisch gewachsene Datenprobleme häufig sichtbar. Eine Migration sollte deshalb nicht als rein technischer Export und Import betrachtet werden. Mehr dazu…
Dubletten, uneinheitliche Schreibweisen, veraltete Lieferantenbezüge oder unklare Variantenstrukturen haben im bisherigen System möglicherweise lange funktioniert, weil Mitarbeiter die Besonderheiten kannten.
Bei einer Migration müssen diese Strukturen plötzlich eindeutig abgebildet werden.
Genau deshalb sollte eine ERP-Migration nicht nur als technischer Export und Import verstanden werden. Vor der Übernahme sollte geklärt werden, welche Daten weiterhin benötigt werden, welche Informationen bereinigt werden müssen und welche Altlasten nicht in das neue System übernommen werden sollten.
Ein neues ERP schafft keine besseren Daten, wenn die alte Datenlogik unverändert mitgenommen wird.
ERP, Prozesse und Daten gemeinsam betrachten
Wenn Produktdaten mehrfach gepflegt werden, Schnittstellen regelmäßig manuell korrigiert werden müssen oder unklar ist, welches System welche Daten führen soll, lohnt sich eine strukturelle Analyse.
Schlechte Produktdaten zeigen sich häufig nicht dort, wo sie entstehen.
Ein fehlendes Gewicht fällt im Versand auf. Eine fehlerhafte Variantenstruktur wird beim Marktplatz problematisch. Eine unklare Verpackungseinheit führt im Einkauf oder Lager zu Rückfragen. Unzuverlässige Bestände erreichen schließlich den Kunden im Shop.
Der eigentliche Aufwand entsteht dabei oft durch die vielen kleinen manuellen Korrekturen dazwischen.
Deshalb reicht es nicht, Produktdaten lediglich zentral zu speichern. Unternehmen müssen klären, welche Informationen ihre Prozesse benötigen, wie diese Informationen fachlich definiert sind, wo sie entstehen und wer für ihre Qualität verantwortlich ist.
Erst auf dieser Grundlage können ERP, WMS, Shop, Marktplätze, Schnittstellen und Automatisierungen zuverlässig zusammenspielen.
Produktdatenqualität ist damit keine Detailarbeit am Artikelstamm. Sie ist eine Voraussetzung für stabile, integrierte und skalierbare E-Commerce-Prozesse.
Wenn in ERP, Shop, Lager und Marktplätzen unterschiedliche Datenstände entstehen oder Mitarbeiter regelmäßig Informationen manuell prüfen und korrigieren müssen, lohnt sich der Blick auf die gesamte Prozesskette.
eloquium betrachtet dabei nicht nur einzelne Systeme, sondern analysiert Prozesse, Datenflüsse, Schnittstellen und Verantwortlichkeiten im Zusammenhang. Das umfasst unter anderem ERP-Einführungen und Migrationen sowie die strukturelle Optimierung bestehender E-Commerce-Systemlandschaften.
Ziel ist nicht, Produktdaten dauerhaft für Unternehmen zu pflegen, sondern Strukturen zu schaffen, in denen Daten verlässlich entstehen und von den angeschlossenen Systemen sinnvoll genutzt werden können.
Bestände sind im engeren Sinn keine klassischen Stammdaten, weil sie sich laufend durch Warenbewegungen verändern. Für E-Commerce-Prozesse sind korrekte und aktuelle Bestandsdaten trotzdem ein zentraler Bestandteil der Datenqualität.
Nein. Je nach Systemlandschaft können unterschiedliche Systeme für unterschiedliche Datenbereiche führend sein. Wichtig ist, dass eindeutig definiert wird, welches System für welche Information verantwortlich ist und wie Änderungen zwischen den Systemen synchronisiert werden.
Diese Gedanken haben wir zuerst auf LinkedIn geteilt – folgen Sie uns dort für weitere Einblicke.