ERP-Datenzuverlässigkeits-Scoring

Das echte Ausmaß des Problems

Das ERP-System ist das Herzstück operativer Entscheidungen — Einkauf, Produktion, Buchhaltung, Vertrieb laufen durch dieselbe Datenbasis. Was in diesem System steht, wird als wahr behandelt. Es wird selten hinterfragt.

Das ist das Problem: Niemand hat die Fehlerquote tatsächlich gemessen.

Eine aktuelle Befragung von 163 Unternehmen durch FIS und IT-Onlinemagazin (2024) zeigt: 63 Prozent der befragten Unternehmen bewerten ihre eigene Stammdatenqualität als verbesserungswürdig oder schlecht. Nur 26 Prozent berichten von geringen oder keinen Qualitätsproblemen. Eine ältere Umfrage unter SAP-Anwendenden (WINSHUTTLE/SAP Community, 2021/22, n=112) ergibt noch schärfere Zahlen: Nur 2 Prozent bewerten ihre Stammdatenqualität als “gut” — und 78 Prozent der SAP-Nutzenden fehlt grundlegendes Datenverständnis, um Fehler überhaupt zu erkennen.

Der Finanzschaden ist schwer isolierbar, weil er sich auf viele Prozesse verteilt. Gartner schätzt den durchschnittlichen jährlichen Kostenschaden schlechter Datenqualität auf rund 12,9 Millionen US-Dollar pro Organisation (Gartner, 2021). Für den deutschen Mittelstand ist diese Zahl zu groß — sie trifft auf Konzerne mit tausenden Datenquellen. Aber auch ein Betrieb mit 200 Mitarbeitenden spürt die Auswirkungen:

• Falsche Bestellungen durch fehlende oder veraltete Einkaufspreise im Artikelstamm
• Doppelte Lieferantenzahlungen durch Dubletten mit unterschiedlichen Bankverbindungen
• Fehlgeschlagene Automatisierung: Workflows, die auf eine gültige Kostenstelle angewiesen sind, brechen still ab — ohne Fehlermeldung, ohne Alarm
• Verzögerte ERP-Migrationen: Das Bereinigen schlechter Daten im Nachgang eines Go-lives kostet typischerweise drei- bis viermal so viel wie eine Vorbereinigung

Besonders tückisch ist, was laut einer Fallstudie aus dem Oracle-ERP-Umfeld dokumentiert ist: Automatisierte Prozesse wie Rechnungsfreigabe und Bestellauslösung laufen fehlerfrei durch — aber mit falschen Daten. Das System funktioniert. Das Ergebnis ist trotzdem falsch.

Was ERP-Datenqualität eigentlich kostet — und warum niemand die Zahl kennt

Die Kosten schlechter ERP-Daten tauchen in keiner Buchhaltungszeile auf. Es gibt keine Position “Verluste durch Stammdatenfehler”. Das macht das Problem so hartnäckig.

Schau dir an, was je Stammdaten-Kategorie schiefgeht — und was das konkret bedeutet:

Artikelstamm-Fehler (Maßeinheit fehlt, Gewicht falsch, Bestellmenge leer): Folge: Automatische Nachbestellung löst mit falscher Menge aus, oder gar nicht. Lager läuft leer oder über. In produzierenden Unternehmen bedeutet das: Fertigungsstopps, Eilbestellungen mit 20–40 Prozent Aufpreis, manuelle Korrekturen durch den Einkauf — Kosten, die als “Sonderaufwand” gebucht werden, nicht als Datenqualitätsproblem.

Lieferantenstamm-Fehler (Dubletten, falsche Bankverbindung, fehlende USt-IdNr.): Folge: Zahlungen an falsche Konten, doppelte Buchungen, nachträgliche manuelle Korrekturbuchungen, DSGVO-Risiko bei fehlenden AVV-Verknüpfungen. Buchhalterische Bereinigungen nach einer ERP-Migration kosten erfahrungsgemäß 800–2.500 Euro je fehlerhaftem Datensatz, wenn externe Berater einbezogen werden müssen.

Kostenstellen- und Buchungskreis-Fehler (inaktive Kostenstellen, falsche Hierarchien): Folge: Automatische Rechnungsfreigabe-Workflows scheitern still, Berichte auf Kostenstellenebene stimmen nicht, Controlling entscheidet auf Basis falscher Zahlen. Die Fehlentscheidung selbst — z.B. ein Budget, das auf einer falschen Kostenstellenauswertung basiert — ist nie dem Stammdatenfehler zuzuordnen.

Genau hier liegt die Tücke: Weil der Schaden diffus ist, wird er systemisch unterschätzt. Eine einzelne Fehlerquote von 8 Prozent bei den Artikelstammsätzen klingt handhabbar. Wenn du aber weißt, dass deine automatisierte Bestellfreigabe auf diese Stammdaten angewiesen ist, weißt du auch: 8 Prozent deiner automatisierten Bestellungen sind potentiell fehlerhaft — und keiner sieht es.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Erfahrungswerte aus ERP-Einführungsprojekten im deutschen Mittelstand (50–500 Mitarbeitende). Keine repräsentative Studie — konsistente Beobachtungen aus mehreren Implementierungen.

Einschätzung auf einen Blick

Zeitersparnis — niedrig (2/5) ERP-Datenzuverlässigkeits-Scoring ist kein Werkzeug, das täglich Arbeit spart. Es ist ein Audit-Instrument, das punktuell eingesetzt wird — vor einer ERP-Migration, vor einem Automatisierungsprojekt, nach einem Datenbereinigungszyklus. In diesen Momenten spart es erheblich Zeit gegenüber manueller Prüfung. Im Alltagsbetrieb ist der direkte Zeiteffekt aber gering, verglichen mit Use Cases wie automatisierter Berichterstellung oder Kundenkorrespondenz.

Kosteneinsparung — mittel (3/5) Der Einspareffekt ist real, aber zeitversetzt und schwer isolierbar. Wer vor einer ERP-Migration weiß, dass 12 Prozent der Artikelstammsätze unvollständig sind, kann das bereinigen — und vermeidet damit im besten Fall einen mehrmonatigen Projektverzug und externe Beratungskosten von 50.000–150.000 Euro. Wer es nicht weiß, zahlt den Preis mit Verzug und Nachbereinigung. Der Zusammenhang ist logisch nachvollziehbar, aber kaum sauber messbar, weil der Alternativfall nicht eintritt.

Schnelle Umsetzung — niedrig (2/5) Für einen ersten Scoring-Report auf einer ERP-Datenbankschicht sind realistisch 4–8 Wochen anzusetzen. Du brauchst Lesezugang zur ERP-Datenbank, eine IT-Fachkraft mit SQL-Kenntnissen, ein klares Bild davon, welche Tabellen und Felder für welche Prozesse kritisch sind — und einen Data Owner, der die Ergebnisse interpretiert. Das ist deutlich aufwändiger als ein SaaS-Tool in drei Tagen zu konfigurieren.

ROI-Sicherheit — sehr niedrig (1/5) Das ist der ehrlichste Score. Datenqualität ist eine Voraussetzung für andere Wertschöpfung — nicht selbst ein Umsatzhebel. Der ROI tritt ein, wenn eine darauf aufbauende Automatisierung besser läuft, eine ERP-Migration reibungsloser verläuft, ein Controlling-Bericht endlich stimmt. Aber all das lässt sich nicht direkt der Datenzuverlässigkeitsprüfung zurechnen. Wer diesen Use Case einführt, muss bereit sein, einen Wert zu akzeptieren, der sich nicht in einer Zahl ausdrücken lässt.

Skalierbarkeit — hoch (4/5) Sobald die Scoring-Pipeline einmal läuft und an die ERP-Datenbank angebunden ist, skaliert sie ohne proportionalen Mehraufwand: mehr Tabellen, mehr Felder, mehr Buchungskreise, mehr Standorte. Eine einmal definierte Qualitätsregel lässt sich auf jeden neuen Datensatz anwenden. Für Unternehmen mit mehreren Mandanten oder einem Konzernverbund ist das besonders wertvoll.

Richtwerte — stark abhängig von ERP-System, Datenbankzugang und interner Expertise.

Was das Scoring-System konkret macht

Machine Learning kann hier in zwei verschiedenen Modi eingesetzt werden — und es ist wichtig, den Unterschied zu verstehen:

Modus 1: Regelbasiertes Profiling mit automatischer Anomalie-Erkennung Das System durchsucht jede Spalte jeder definierten ERP-Tabelle auf bekannte Fehlertypen: leere Pflichtfelder, Wertebereichsverletzungen (z.B. negative Lagermengen), Formatfehler (Steuernummer hat nicht das erwartete Format), statistische Ausreißer in Bewegungsdaten (ein Lieferant hat im Vergleich zur Peer-Gruppe ungewöhnlich hohe Stornoquoten). Das ist kein KI im engeren Sinne — es ist systematisiertes Regelwerk, das Teile manueller Prüfprozesse automatisiert.

Modus 2: ML-gestützte Mustererkennung Darüber hinaus können ML-Algorithmen Muster erkennen, die keine explizite Regel voraussetzen: zwei Lieferanten-Datensätze, die sich in Name und Adresse leicht unterscheiden, aber dieselbe Steuernummer und IBAN haben — Dubletten, die kein Regelwerk als Dublette definiert hätte. Oder: ein Artikel-Datensatz, dessen Bestellwert-Geschichte stark von vergleichbaren Artikeln in derselben Warengruppe abweicht — ein Signal, dass der Preisansatz möglicherweise falsch ist.

Was der Output ist: Das System liefert keine Korrekturen — es liefert eine priorisierte Liste von Verdachtsfällen. Typisch: eine strukturierte Übersicht je Tabellentyp (Artikelstamm, Lieferantenstamm, Kostenstellen, Buchungskreise) mit Fehlerquote je Feld, Anzahl betroffener Datensätze und Prozesskritikalität. Wer die Felder mit der höchsten Fehlerquote in den prozesskritischsten Tabellen kennt, hat einen fundierten Bereinigungsplan — statt blind ins ERP-Projekt zu gehen.

Was es nicht macht: Das System entscheidet nicht, was der richtige Wert wäre. Es erkennt keine inhaltliche Fachlichkeit — ob ein Einkaufspreis von 3,50 Euro für einen bestimmten Artikel “richtig” ist, kann nur ein Fachmensch beurteilen. Scoring liefert Hinweise, Menschen treffen Entscheidungen.

Konkrete Werkzeuge — was wann passt

Die Tool-Landschaft für ERP-Datenzuverlässigkeits-Scoring lässt sich grob in drei Kategorien unterteilen:

Kostenlos / Open Source — für technisch versierte Teams:

Great Expectations (GX Core) ist das meistgenutzte Open-Source-Framework für Datenqualitätsprüfungen. Du definierst Qualitätserwartungen als Code (“der Wert in Spalte umsatzsteuer_id darf nicht leer sein, wenn land = ‘DE’”), GX Core prüft sie gegen die ERP-Datenbank und erstellt einen HTML-Report mit Bestandsaufnahme. Kostenlos, Apache-2.0-Lizenz, läuft on-premises. Voraussetzung: Python-Kenntnisse und direkter Datenbankzugang zur ERP-Schicht. Für ein erstes Scoring-Projekt in einem Unternehmen mit IT-Fachkraft realistischer Einstieg.

Plattformlösungen für datenzentrierte Teams:

Dataiku eignet sich, wenn du neben dem Datenqualitäts-Scoring auch ML-Modelle für die Anomalie-Erkennung in Bewegungsdaten bauen willst — z.B. um Buchungsmuster zu identifizieren, die statistisch auffällig von der historischen Norm abweichen. Dataiku bietet eine visuelle Umgebung für solche Pipelines ohne reinen Code-Aufwand. Community Edition kostenlos, Enterprise ab ca. 26.000 USD/Jahr.

Databricks ist die richtige Wahl, wenn ERP-Daten bereits in einer modernen Datenlake-Architektur (z.B. Azure Data Lake, AWS S3) liegen und du das Scoring als dauerhaften Batch-Job in einer Spark-Umgebung betreiben willst. Für Unternehmen mit vorhandener Cloud-Infrastruktur und Data-Engineering-Kompetenz. Kosten: nutzungsabhängig, typisch 1.000–3.000 Euro/Monat für mittelständische Workloads.

Enterprise Data Governance Plattformen:

Collibra und Ataccama sind die Marktführer für unternehmensweites Datenzuverlässigkeits-Scoring mit automatischem Profiling, Lineage-Tracking und Governance-Workflows. Ataccama liegt bei ca. 90.000 USD/Jahr, Collibra ab ca. 170.000 USD/Jahr. Diese Plattformen sind für die meisten mittelständischen Unternehmen wirtschaftlich nicht sinnvoll — sie sind auf Konzerne ausgelegt, die Datenqualität über zehn oder mehr Systeme hinweg gleichzeitig steuern wollen. Für ein mittelständisches ERP-Scoring-Projekt sind sie überdimensioniert.

Einstiegs-Empfehlung für den deutschen Mittelstand: Starte mit Great Expectations und einem klar definierten Scope — zwei bis drei Stammdaten-Tabellen, die für den kritischsten Prozess relevant sind (z.B. Lieferantenstamm für die automatische Zahlungsfreigabe). Das liefert in 4–6 Wochen erste belastbare Zahlen, ohne Enterprise-Lizenzkosten.

Datenschutz und Datenhaltung

ERP-Daten enthalten fast immer personenbezogene Informationen: Mitarbeiterstammdaten in der HR-Anbindung, Kundenkontakte im Debitorenstamm, Lieferantenansprechpartner. Sobald ein externes System oder ein Cloud-Dienst diese Daten verarbeitet, gilt die DSGVO — einschließlich AVV nach Art. 28 DSGVO.

Die gute Nachricht: Für das Datenzuverlässigkeits-Scoring gilt in vielen Fällen eine einfachere Regel als bei inhaltlicher KI-Analyse. Scoring-Systeme, die auf der Datenbankschicht agieren und nur Metadaten erzeugen (Null-Quote, Dublettenanzahl, Formatfehler-Anzahl), müssen keine personenbezogenen Daten in Klartext an externe Systeme übertragen. Wenn das Scoring vollständig on-premises läuft — also auf eigenen Servern, mit Datenbankverbindung ins ERP — gibt es keine Drittübertragung.

Für cloudbasierte Tools oder KI-Plattformen gilt: Vor dem ersten Lauf klären, welche Daten die Plattform tatsächlich sieht. Ein Scoring-Run, der nur aggregierte Statistiken (Prozentzahlen, Feldnamen, keine Datensatz-Inhalte) in die Cloud überträgt, ist datenschutzrechtlich anders einzustufen als ein System, das Rohdaten hochlädt.

Praktischer Ratschlag: Führe ein erstes Profiling mit Great Expectations on-premises durch. Die HTML-Reports enthalten keine Rohdaten — nur Statistiken und Regelprüfungen. Das ist ein sicherer Einstieg, ohne den Datenschutzbeauftragten in lange Prüfprozesse einzubeziehen. Wenn du auf Cloud-Plattformen umsteigst, ist ein AVV mit dem Anbieter und eine Prüfung mit dem Datenschutzbeauftragten vor Produktivbetrieb Pflicht.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

• IT-Fachkraft: 40–80 Stunden für Setup, Datenbankanbindung, erste Regelsets (intern oder externer Berater)
• Externe Beratung für Scoring-Konzept und Priorisierung: 3.000–8.000 Euro
• Tool-Lizenz: 0 Euro (Great Expectations), 1.000–3.000 Euro/Monat (Databricks), oder ab 90.000 USD/Jahr (Enterprise-Plattformen)

Laufende Kosten

• Betrieb der Scoring-Pipeline: minimal, wenn automatisiert — ca. 2–4 Stunden/Monat IT-Betreuung
• Bereinigungsarbeit der identifizierten Fehler: 10–30 Stunden/Monat je nach Fehlermenge, typisch in den ersten 3–6 Monaten intensiver

Was du dagegenrechnen kannst Die Kosten schlechter ERP-Daten entstehen nicht als Linieneintrag — sie verstecken sich in Projektüberschreitungen, Sonderbestellungen, manuellen Korrekturbuchungen und fehlgeschlagener Automatisierung. Eine konservative Rechnung für ein mittelständisches Unternehmen mit einem laufenden ERP-Migrationsprojekt: Wenn Datenmigration das häufigste Einzelproblem bei ERP-Einführungen ist (Trovarit, 2020/2021) und externe Berater bei einem Unternehmen mit 200 Mitarbeitenden zwischen 80.000 und 200.000 Euro für ein ERP-Projekt in Rechnung stellen, dann ist jede Verschiebung des Go-live-Termins um einen Monat typischerweise mit 10.000–25.000 Euro Mehrkosten verbunden. Ein Scoring-Projekt, das diesen Verzug verhindert, amortisiert sich in Stunden.

Die ehrliche Einschränkung: Wenn dein Unternehmen kein ERP-Migrationsprojekt plant und keine konkreten Automatisierungsvorhaben auf den Tisch liegen, ist der ROI schwer zu greifen. Scoring allein, ohne einen Anlass, der Datenbereinigung wirtschaftlich erzwingt, führt oft zu einem Bericht, der niemanden zum Handeln bringt.

Typische Einstiegsfehler

1. Den gesamten ERP-Datenbestand auf einmal bewerten wollen. Ein SAP-System hat Hunderte von Tabellen, viele davon mit Millionen Einträgen. Wer “das ERP” als Ganzes bewerten will, verliert sich in der Komplexität. Die Scoring-Qualität ist am höchsten, wenn du mit zwei bis drei Tabellen startest, die für einen konkreten Prozess kritisch sind — und diesen Prozess bis ins letzte Feld verstehst, bevor du Regeln formulierst.

2. Scoring ohne einen Data Owner einführen. Das Scoring-System liefert eine Liste von Verdachtsfällen — aber wer entscheidet, welcher Artikel-Stammsatz den richtigen Einkaufspreis hat? Wer klärt, ob “Müller Stahl GmbH” und “Mueller Stahl GmbH” tatsächlich dasselbe Unternehmen sind? Ohne eine fachlich zuständige Person, die diese Entscheidungen trifft, erzeugt das System Berichte, die niemand abarbeitet. Alert-Fatigue ist das Resultat: zu viele Hinweise, keine Kapazität, kein Prozess — und nach drei Monaten schaut niemand mehr in den Report.

3. Scoring als einmaligen Scan verstehen. Datenqualität verfällt. Neue Lieferanten werden unvollständig angelegt. Kostenstellen werden inaktiv, ohne aus dem System genommen zu werden. Artikel-Stammsätze werden nie aktualisiert. Ein Scoring-Run, der einmal vor der ERP-Migration durchgeführt wird und dann nie wieder, ist wertvoll — aber nicht dauerhaft ausreichend. Wer Datenqualität langfristig sichern will, braucht eine monatliche oder wöchentliche Scoring-Pipeline, die Abweichungen sofort sichtbar macht.

4. Die Ergebnisse nur an die IT berichten — nicht an den Fachbereich. Das ist der gefährlichste Fehler. Wenn der Scoring-Report beim IT-Verantwortlichen ankommt, wird er zur IT-Aufgabe. Datenfehler entstehen aber meist in Fachprozessen — Einkauf legt Lieferanten an, Buchhaltung pflegt Kostenstellen, Produktmanagement betreut den Artikelstamm. Die Berichte müssen zu den Menschen, die die Fehler verursachen und bereinigen können — mit konkreten Handlungsanweisungen, nicht mit Datenbankjargon.

Was mit der Einführung wirklich passiert — und was nicht

Das erste Scoring-Ergebnis ist meistens ein Schock.

Nicht weil die Zahl so hoch ist — sondern weil sie existiert. Vorher gab es eine vage Ahnung, dass “manche Stammdaten nicht stimmen”. Jetzt gibt es eine Zahl: 17 Prozent der Lieferantendatensätze haben keine gültige USt-IdNr., 9 Prozent der Artikelstammsätze haben keine Maßeinheit, 4 Prozent der Kostenstellen sind inaktiv aber noch buchbar. Das ist konkret. Das ist neu. Und das löst unterschiedliche Reaktionen aus.

Die Abwehrreaktion: “Das sind doch nur technische Einträge, die nicht genutzt werden.” Dieser Reflex ist fast immer falsch. Tote Datensätze im System werden regelmäßig von Batch-Jobs und Automatisierungen aufgerufen — und erzeugen dort stille Fehler, die niemand sieht, weil kein Alarm ertönt.

Die Überforderungsreaktion: “Wenn 17 Prozent falsch sind, müssten wir alles gleichzeitig bereinigen.” Das ist nicht nötig. Die Scoring-Ergebnisse erlauben eine Priorisierung: Welche Fehler blockieren die wichtigsten Prozesse? Welche betreffen aktive Datensätze, welche sind nur historischer Ballast? Eine gute Bereinigungskampagne startet mit den 20 Prozent der Fehler, die 80 Prozent des operativen Schadens verursachen.

Die häufigste Überraschung in der Einführung: Die Fachbereiche beginnen, eigene Qualitätsfragen zu stellen. Wenn Einkauf sieht, dass 12 Prozent der Lieferanten keine gültige E-Mail-Adresse haben, fragt Einkauf: “Wie schicken wir denen dann Bestellbestätigungen?” Dieses Bewusstsein — “wir haben ein Datenproblem, das meinen Prozess betrifft” — ist der eigentliche kulturelle Gewinn eines Scoring-Projekts. Er lässt sich nicht erzwingen, entsteht aber fast immer organisch, wenn die Zahlen sichtbar sind.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

“Wir haben ein Data Governance Team — das regelt das.” Data Governance definiert, was korrekt sein sollte. Es sagt nicht, was tatsächlich korrekt ist. Eine Governance-Richtlinie, die vorschreibt, dass jeder Lieferant eine gültige USt-IdNr. haben muss, verhindert nicht, dass in der Praxis 17 Prozent dieser Felder leer bleiben — weil Governance keine Echtzeitprüfung durchführt, sondern Regeln setzt. Das Scoring misst den Abstand zwischen dem, was die Governance vorschreibt, und dem, was im System tatsächlich steht. Beides zusammen macht Qualitätssicherung vollständig.

“Datenqualität verbessern wir bei der nächsten ERP-Migration sowieso.” Das ist die teuerste Strategie. Laut Trovarit ist die Datenmigration das meistgenannte Problem bei ERP-Einführungen — nicht weil Datenbereinigung schwierig ist, sondern weil sie im Migrationsstress unter Zeitdruck stattfindet. Wer die Qualität vorher kennt, kann sie vorher bereinigen — zu einem Bruchteil der Kosten. Wer sie im Projekt entdeckt, bereinigt unter Druck, mit schlechterer Qualität, und verteuert das gesamte Projekt.

“Unsere Mitarbeitenden kennen die Daten — die wissen, was stimmt und was nicht.” Individuelle Kenntnis ist kein Qualitätsmanagement. Was einzelne Fachleute im Kopf haben, überlebt keine Fluktuation, kein Wachstum, keine Automatisierung. Wenn ein erfahrener Einkäufer weiß, dass Lieferant X eigentlich unter zwei verschiedenen Namen im System läuft, dann ist das eine manuelle Kompensation eines Systemfehlers — kein Qualitätsmerkmal. Scoring macht diese stillschweigenden Korrekturen sichtbar.

Woran du merkst, dass das zu dir passt

• Du planst in den nächsten 12 Monaten eine ERP-Migration oder ein größeres ERP-Upgrade — und willst nicht im Projekt herausfinden, wie hoch der Bereinigungsaufwand ist
• Automatisierungsprojekte (Rechnungsfreigabe, automatische Bestellung, EDI-Anbindung) laufen schlechter als im Test — und niemand weiß warum; Stammdatenqualität ist der häufigste unentdeckte Grund
• Du hast mehr als zwei Jahre Bewegungsdaten im ERP, und neue Mitarbeitende beklagen, dass Reportergebnisse nicht nachvollziehbar sind
• Es gibt keine systematische Prüfung der Stammdaten — Probleme werden gemeldet, wenn sie auffallen, nicht vorher
• Dein ERP wird von mehreren Standorten oder Buchungskreisen gleichzeitig genutzt — konsistente Stammdaten über Standortgrenzen hinweg sind besonders schwer manuell sicherzustellen

Wann es sich noch nicht lohnt — vier harte Ausschlusskriterien:

1. Kein ERP-System im Einsatz oder weniger als zwei Jahre Bewegungsdaten. Ein Scoring-System, das auf einem sehr jungen Datenbestand aufbaut, hat keine aussagekräftige Anomalie-Basis — es gibt noch kein “Normal”, von dem abzuweichen ist. In diesem Fall zuerst saubere Dateneingabe-Prozesse etablieren, dann messen.

2. Aktive ERP-Migration läuft bereits. Wenn das Migrationsprojekt gestartet ist, ist es zu spät für ein vorgelagertes Scoring-Projekt. Jetzt geht es darum, die Migration zu steuern und Fehler im laufenden Prozess zu erkennen — kein anderer Zeitplan ist realistisch. Scoring vor der Migration wäre sinnvoll gewesen; jetzt ist Schadensbegrenzung gefragt.

3. Kein Data Owner, der auf die Ergebnisse reagieren wird. Scoring ohne Bereinigung erzeugt Reports, die in Schubladen verschwinden. Wenn keine fachlich verantwortliche Person für die relevanten Stammdaten-Kategorien benannt ist — und wenn diese Person nicht die Kapazität hat, Fehler zu beheben — ist das Scoring-Ergebnis wertlos. Alert-Fatigue ist das sichere Ergebnis.

4. Keine IT-Fachkraft mit SQL-Grundkenntnissen verfügbar. Der Einstieg in ERP-Datenbankschichten ist ohne technische Unterstützung nicht machbar. Wer weder intern über die Kompetenz verfügt noch einen IT-Dienstleister einbinden kann, der ERP-Datenbankstrukturen versteht, sollte diesen Use Case erst angehen, wenn diese Ressource verfügbar ist.

Das kannst du heute noch tun

Fang mit einer Bestandsaufnahme an, ohne ein einziges Tool anzufassen. Öffne ChatGPT oder Claude und beschreibe deinen kritischsten ERP-gestützten Prozess — z.B. die automatische Lieferantenbestellung oder die Rechnungsfreigabe. Frag dann: “Welche Stammdatenfelder müssen fehlerfrei sein, damit dieser Prozess ohne manuelle Eingriffe funktioniert?”

Die Antwort ist deine Prioritätenliste für das erste Scoring.

Quellen & Methodik

• FIS / IT-Onlinemagazin (2024): Umfrage zum SAP-Stammdatenmanagement 2024 mit 163 teilnehmenden Unternehmen. Kernbefund: 63% bewerten Stammdatenqualität als verbesserungswürdig; 81% wünschen stärkere Automatisierung. Quelle: it-onlinemagazin.de/sap-stammdatenmanagement-wird-ki-zum-schluessel-der-transformation
• WINSHUTTLE / SAP Community Survey (2021/22): 112 SAP-Nutzende befragt; nur 2% bewerten Stammdatenqualität als “gut”, 78% fehlt Datenverständnis. Quelle: it-onlinemagazin.de/78-prozent-der-sap-kunden-fehlt-datenverstaendnis
• Trovarit, “ERP in der Praxis” (2020/21): Datenmigration ist das meistgenannte Einzelproblem bei ERP-Einführungen. Quelle: news.it-matchmaker.com/datenmigration-bremst-erp-projekte-aus
• Gartner (2021): Durchschnittlicher jährlicher Kostenschaden durch schlechte Datenqualität: 12,9 Millionen USD/Organisation. Zitiert in mehreren unabhängigen Quellen; Originalstudie hinter Gartner-Paywall.
• Buchungskreis-Bereinigungskosten (800–2.500 €/Datensatz): Erfahrungswerte aus ERP-Einführungsprojekten im deutschen Mittelstand (50–500 Mitarbeitende); keine repräsentative Studie.
• Great Expectations (GX Core): Offizielle Dokumentation und Lizenzangaben: greatexpectations.io/gx-core
• Ataccama / Collibra Preisangaben: G2, Capterra und Käuferdaten (Stand April 2026); Angebote auf Anfrage, Preise können abweichen.

Du willst wissen, welche eurer ERP-Tabellen du zuerst bewerten solltest und wie ein realistischer Scoring-Fahrplan für euer System aussieht? Meld dich — das klären wir gemeinsam in einem kurzen Gespräch.