Datenqualität im ERP: Was schlechte Stammdaten ein Unternehmen wirklich kosten

Ein Großhändler mit rund 180 Mitarbeitenden geht mit seinem neuen ERP-System an den Start. Die Einführung hat achtzehn Monate gedauert, das Budget ist weitgehend eingehalten. Am Go-Live-Tag läuft das System technisch sauber. Drei Wochen später bemerkt der Einkauf, dass über 12.000 Artikelstammdaten keine gültige Warengruppe haben. Der Vertrieb stellt fest, dass mehrere hundert Kundendatensätze doppelt angelegt sind – teilweise mit abweichenden Konditionen. Die Lagerverwaltung kämpft mit Bestandsdifferenzen, weil Einheiten in der Migration nicht konsistent konvertiert wurden.

Was folgt, sind Monate aufwendiger Nachbereinigung im laufenden Betrieb – mit allen Konsequenzen: fehlerhafte Auswertungen, manuelle Korrekturen, gebundene Kapazitäten, und ein wachsendes Misstrauen der Belegschaft gegenüber dem neuen System. Der Satz, der in solchen Projekten am häufigsten fällt: „Das alte System war besser.“ Gemeint ist meistens: „Im alten System haben wir die Fehler gekannt und gelernt, damit umzugehen.“

Datenqualität im ERP bedeutet:

Datenqualität im ERP ist nicht:

Das klingt drastisch. Es ist aber in der Mehrzahl der Projekte, die ich begleitet habe, die Ausgangslage. Nicht weil die Unternehmen nachlässig wären – sondern weil Daten in gewachsenen Systemlandschaften ein Eigenleben entwickeln. Felder werden anders belegt als ursprünglich vorgesehen. Klassifizierungen werden über Jahre uneinheitlich gepflegt. Workarounds führen zu Datensätzen, die technisch valide sind, aber inhaltlich falsch.

Wenn dann die Frage gestellt wird: „Wie gut sind Ihre Stammdaten?“, lautet die ehrlichste Antwort meistens: „Wir wissen es nicht genau.“

In einem Projekt im Fachhandel haben wir im Rahmen einer strukturierten Datenanalyse festgestellt, dass von rund 40.000 Artikelstammdaten knapp 38 Prozent mindestens ein kritisches Qualitätsproblem aufwiesen – fehlende Pflichtfelder, Dubletten oder inkonsistente Einheiten. Niemand im Unternehmen hatte diesen Wert vorher auf dem Radar. Das Erstaunen war groß. Die Konsequenz war ein eigenes Bereinigungsprojekt, das ohne diese Analyse erst nach dem Go-Live sichtbar geworden wäre – mit entsprechend höheren Kosten und Risiken.

Datenmigration ist kein Datenexport mit anschließendem Import. Sie ist ein Transformationsprozess, der fachliche Entscheidungen erfordert: Welche Daten werden migriert, welche nicht? Wie werden unterschiedliche Nummernkreise zusammengeführt? Was passiert mit Datensätzen, die im Altsystem noch aktiv sind, aber im neuen System kein Äquivalent haben?

Diese Fragen haben keine technischen Antworten. Sie haben fachliche Antworten, die von den Abteilungen getroffen werden müssen, die mit den Daten arbeiten. Wer die Datenmigration allein an IT oder Systemhaus delegiert, bekommt technisch korrekt migrierte Daten – und inhaltlich falsche.

Ein konkretes Muster aus der Praxis: Kundenstammdaten werden migriert, aber niemand hat vorab definiert, welches Datenfeld aus dem Altsystem das Pflichtfeld „Kundengruppe“ im neuen System befüllen soll. Das Systemhaus belegt es mit einem Default-Wert. Nach dem Go-Live stellt der Vertrieb fest, dass Konditionssteuerung und Rabattstaffelungen nicht mehr korrekt funktionieren – weil sie an der Kundengruppe hängen. Die Ursache liegt vier Ebenen tiefer in einer Migrationsentscheidung, die niemand bewusst getroffen hat.

Selbst wenn eine Bereinigung vor der Migration durchgeführt wird, stellt sich sechs Monate nach Go-Live oft heraus, dass die Qualität wieder sinkt. Neue Datensätze werden uneinheitlich angelegt. Pflichtfelder werden umgangen. Die Bereinigung war ein Ereignis – keine strukturelle Veränderung.

Was fehlt, ist Datengouvernanz: klare Verantwortlichkeiten dafür, wer Stammdaten anlegt, ändert und freigibt. Einheitliche Standards, die nicht im Kopf einzelner Mitarbeitender gespeichert sind, sondern dokumentiert und für neue Kollegen zugänglich sind. Und ein Prozess, der regelmäßige Qualitätsprüfungen als Routineaufgabe verankert – nicht als Sondermaßnahme vor der nächsten Systemänderung.

Gute Datengouvernanz ist keine aufwendige Bürokratie. Sie ist die Summe von wenigen, konsequent angewendeten Regeln. Wer Stammdaten anlegen darf, welche Felder wie belegt werden müssen, welche Systeme als führendes System gelten. Das lässt sich auf zwei bis drei Seiten dokumentieren – wenn der Wille vorhanden ist, es zu tun.

Schlechte Datenqualität verursacht Kosten. Aber da sie diffus über das gesamte Tagesgeschäft verteilt sind, werden sie selten als Datenproblem erkannt und benannt. Der Einkäufer, der zwanzig Minuten sucht, bis er den richtigen Artikelstamm gefunden hat. Der Buchhalter, der Monatsabschlüsse manuell korrigiert, weil Kostenstellenzuordnungen fehlerhaft sind. Das Lager, das regelmäßig Inventurdifferenzen ausgleicht, weil Einheiten nicht konsistent gepflegt wurden.

Diese Kosten summieren sich. Studien zur Datenqualität in Unternehmensanwendungen – unter anderem vom TDWI und der MIT Sloan School of Management – beziffern die Kosten schlechter Datenqualität auf fünfzehn bis zwanzig Prozent der betroffenen Prozesskosten. Für einen mittelständischen Händler mit zwanzig Mitarbeitenden im kaufmännischen Bereich bedeutet das schnell sechs- bis siebenstellige Beträge pro Jahr – die niemand sieht, weil sie nirgendwo als „Datenproblem“ auftauchen.

Am Ende einer strukturierten Datenanalyse sollte ein Unternehmen Folgendes in der Hand haben:

Ein quantitatives Bild der Ist-Qualität – mit klaren Kennzahlen: Welcher Anteil der Datensätze hat kritische Qualitätsprobleme? Welche Felder sind am häufigsten betroffen? Wo liegen die Hauptrisiken für die Migration?

Eine priorisierte Bereinigungsliste – mit Unterscheidung nach Schweregrad und Aufwand. Nicht jedes Datenproblem muss vor der Migration gelöst werden. Aber die kritischen müssen identifiziert sein, bevor das neue System befüllt wird.

Ein Regelwerk für die Migration – welche Daten werden wie migriert, welche nicht, welche Transformationslogiken gelten? Schriftlich, abgestimmt mit den Fachbereichen, vor dem Start der Migrationsarbeiten.

Governance-Empfehlungen – wer ist für welche Stammdaten verantwortlich, welche Standards gelten, wie wird Qualität nach dem Go-Live gesichert?

In vielen ERP-Projekten wird über Datenmigration gesprochen, als wäre sie ein Transport. Daten werden vom alten ins neue System gebracht. Was dabei übersehen wird: Eine ERP-Einführung ist die beste Gelegenheit, den eigenen Datenbestand grundlegend zu überdenken.

Welche Datensätze brauchen wir wirklich? Welche Klassifizierungen haben wir geerbt, obwohl sie schon lange keinen operativen Mehrwert mehr haben? Welche Standards wollen wir künftig gelten lassen?

Wer diese Fragen vor der Migration beantwortet, startet mit einem sauberen Datenbestand in das neue System. Wer sie nicht stellt, migriert das Chaos des Altsystems in das neue – strukturiert und dokumentiert, aber inhaltlich unverändert.

Die technische Prozesslogik, auf der diese Daten dann operieren, ist dabei ebenso entscheidend: Eine solide ERP-Prozessanalyse mit ERPulse360 und eine belastbare Datenbasis gehören zusammen – das eine ohne das andere erzeugt halbe Lösungen.

Und die Mitarbeitenden, die täglich mit diesen Daten arbeiten, müssen verstehen, warum neue Standards gelten und wie sie diese einhalten. Das ist weniger eine Schulungsfrage als eine Frage der Veränderungsbereitschaft – und der Anknüpfungspunkt für strukturiertes Change Management mit ChangeReady360.

Schlechte Stammdaten entstehen nicht aus technischem Versagen. Sie entstehen aus ungeklärten Verantwortlichkeiten, fehlenden Standards und dem natürlichen Wachstum jeder Datenbasis über Zeit. Die Konsequenzen sind real und messbar – auch wenn sie selten unter diesem Namen auftauchen.

Eine ERP-Einführung ist der Moment, an dem Datenqualität sichtbar wird. Die Frage ist nur, ob man sich diesen Moment aussucht – als vorgelagerte, kontrollierte Analyse – oder ob er sich seinen Weg bahnt: durch Fehler im laufenden Betrieb, durch Nachbereinigung unter Zeitdruck und durch ein wachsendes Misstrauen in das neue System.

In einem kostenlosen 30-minütigen Erstgespräch besprechen wir gemeinsam, wo die größten Datenqualitätsrisiken in Ihrem ERP-Vorhaben liegen – und welche Schritte vor der Migration den größten Hebel haben.

Spätestens sechs Monate vor dem geplanten Go-Live – idealerweise früher, weil die Bereinigung Zeit braucht und parallel zu anderen Projektphasen laufen muss. Wer die Analyse erst startet, wenn die Konfiguration abgeschlossen ist, hat kaum noch Spielraum für grundlegende Korrekturen.

Aus der Praxis sind es fast immer dieselben drei Bereiche: Artikelstammdaten (fehlende Klassifizierungen, Einheiteninkonsistenzen, veraltete Datensätze), Kundenstammdaten (Dubletten, fehlende Pflichtfelder für Konditionssteuerung) und Lieferantenstammdaten (uneinheitliche Strukturen, fehlende Bankverbindungen oder Steuerangaben). In Handels- und Großhandelsunternehmen kommt häufig noch die Lagerstruktur hinzu.

Nachträgliche Bereinigung im laufenden Betrieb ist drei- bis fünfmal aufwendiger als eine vorgelagerte Analyse, weil Änderungen an produktiven Daten wesentlich mehr Abstimmung, Tests und Freigaben erfordern. Hinzu kommen die Kosten des laufenden Betriebs mit schlechten Daten: fehlerhafte Auswertungen, manuelle Korrekturen, gebundene Kapazitäten. Erfahrungswerte aus der Praxis zeigen, dass Unternehmen, die Datenqualität erst nach dem Go-Live systematisch angehen, dafür im Schnitt zwölf bis achtzehn Monate benötigen.

Quellen: TDWI Research, Data Quality and the Bottom Line (2022); MIT Sloan Management Review, Seizing Value from Data Quality Investments (2021); Panorama Consulting ERP Report 2023; eigene Projekterfahrung aus ERP-Begleitungen im Handel und Großhandel