Stell dir vor, du automatisierst morgen deinen Bestellprozess. Alles wird schneller, alles läuft digital. Und dreimal so schnell wie bisher landen Fehlbestellungen beim Lieferanten – weil die Adresse im System seit zwei Jahren veraltet ist. Automatisierung korrigiert Datenfehler nicht. Sie beschleunigt sie.
Was schlechte Datenqualität wirklich kostet
Gartner beziffert die durchschnittlichen jährlichen Kosten schlechter Datenqualität auf rund 12,9 Millionen US-Dollar (je Organisation). Für den Mittelstand klingt diese Zahl abstrakt. Sie wird konkreter, wenn man sie aufschlüsselt: Jede falsche Stammdaten-Adresse erzeugt eine Rücksendung. Jeder fehlerhafte Lagerbestand zieht eine Überbestellung nach sich oder eine Lieferverzögerung. Jede doppelt gepflegte Kundendatei multipliziert Fehler in Folgesysteme.
Das Tückische daran: Die meisten dieser Kosten erscheinen nicht in einer Zeile der Gewinn-und-Verlust-Rechnung. Sie stecken im Zeitaufwand erfahrener Mitarbeitender, die Ausnahmen manuell bereinigen. In Entscheidungen, die auf falschen Zahlen basieren. In Systemen, denen niemand mehr traut, und um die herum Excel-Listen entstehen, die das eigentliche Wissen des Unternehmens tragen.
Garbage in, garbage out: warum Reifegrad vor Tempo kommt
„Garbage in, garbage out" ist das älteste Prinzip der Datenverarbeitung – und das am häufigsten ignorierte. Es bedeutet: Die Qualität des Outputs ist nie besser als die Qualität des Inputs. Automatisierst du einen Prozess mit schlechten Daten, produzierst du schlechte Ergebnisse schneller. Trainierst du ein KI-Modell auf inkonsistenten Bestandsdaten, trifft es schlechtere Entscheidungen als ein erfahrener Disponierter – nur hundertmal schneller.
Deshalb ist Datenreifegrad keine technische Fußnote, sondern eine Projektvoraussetzung. Grob lassen sich fünf Reifestufen unterscheiden: von rohen, unsystematisch erfassten Daten über konsolidierte und bereinigte Bestände bis hin zu verlässlichen, analysierbaren Grundlagen. Die wenigsten Mittelständler starten auf Stufe fünf. Viele unterschätzen, auf welcher Stufe sie tatsächlich sind.
Das ist keine Kritik – es ist der Ausgangspunkt. Wer seinen Datenreifegrad kennt, bevor er ein Projekt startet, kann realistisch planen: was zuerst bereinigt werden muss, welche Automatisierung sofort möglich ist und wo noch Vorarbeit nötig ist.
Datenqualität verbessern: ein Kreislauf, kein Kraftakt
Die gute Nachricht: Datenqualität ist kein Großprojekt, das man einmal stemmt und dann abhakt. Sie ist ein Kreislauf, den man schrittweise durchläuft – erst für den wichtigsten Datenbereich, dann für den nächsten. Genau dieses iterative Vorgehen hat sich in der Praxis bewährt, weil es das Risiko klein hält und schnell erste Ergebnisse liefert, statt monatelang „aufzuräumen", bevor irgendetwas nutzbar wird. Methodisch steckt dahinter die Control-Logik aus Six Sigma / DMAIC: nicht einmal säubern, sondern sauber halten.
Die vier Schritte sind bewusst schlicht:
- Profilieren: Erst messen, wo die Fehler tatsächlich sitzen – Dubletten, Lücken, widersprüchliche Formate. Kein Bauchgefühl, sondern ein ehrlicher Ist-Stand des betroffenen Datenbereichs.
- Bereinigen: Die gefundenen Fehler korrigieren, Dubletten zusammenführen, Lücken schließen. Einmalige Aufräumarbeit – der Teil, den die meisten mit „Datenqualität" meinen.
- Regeln verankern: Der entscheidende Schritt, den viele überspringen. Pflichtfelder, Validierungen und eine klare Quelle der Wahrheit sorgen dafür, dass dieselben Fehler nicht morgen wieder entstehen. Ohne diesen Schritt bereinigst du in einem halben Jahr erneut.
- Überwachen: Ein paar einfache Kennzahlen – Dublettenquote, Anteil unvollständiger Datensätze – zeigen laufend, ob die Qualität hält. Kippt ein Wert, greifst du früh ein, statt beim nächsten großen Projekt böse überrascht zu werden.
Dann beginnt der Kreislauf von vorn – mit dem nächsten Datenbereich. So wächst die Datenqualität mit, statt in einem großen, riskanten Kraftakt vorab „fertig" sein zu müssen. Für den Mittelstand ist das der pragmatische Weg: kleine, belegbare Schritte statt Big-Bang.
Deine Daten reden schon — hörst du zu?
Der positive Gegenpol zur Warnung: Die Daten, die du heute schon hast, enthalten meistens mehr Antworten, als du ahnst. Nicht als abstraktes Big-Data-Versprechen, sondern sehr konkret.
Wie oft werden Bestellungen manuell korrigiert? Wie hoch ist die Nacharbeitsquote bei eingehenden Rechnungen? In welchem Schritt entstehen die meisten Rückfragen? Das sind keine Gefühle – das sind Messwerte, die in deinen Systemen bereits existieren. Sie zeigen, wo der Prozess klemmt, welche Datenqualität tatsächlich vorliegt und wo die größten Hebel für Verbesserungen liegen.
Wenn in einem Ticketsystem 30 Prozent der Tickets den Status „Rückfrage an Ersteller" tragen, ist das kein Zufall. Es ist ein Datenpunkt, der sagt: Hier fehlen bei der Erfassung konsistente Pflichtfelder. Oder die richtigen Personen sehen die falsche Information. Beides ist lösbar – aber nur, wenn man hinschaut.
Der ehrliche Reifegrad-Check vor dem Projekt
Vor jedem Optimierungsprojekt lohnen sich fünf ehrliche Fragen:
- Woher kommen unsere Stammdaten – und wer pflegt sie, nach welchen Regeln?
- Wie hoch ist der manuelle Korrekturanteil in den betroffenen Prozessen?
- Wie viele Systeme enthalten dieselben Daten in unterschiedlichen Versionen?
- Wer ist die verlässliche Quelle der Wahrheit für die wichtigsten Entscheidungsgrundlagen?
- Welche Entscheidungen treffen wir heute auf Basis von Bauchgefühl, weil die Datenlage unklar ist?
Je mehr dieser Fragen zu einem „weiß ich nicht genau" führen, desto wertvoller ist es, sie zu klären, bevor investiert wird. Nicht um das Projekt zu bremsen – sondern um es auf einem Fundament zu bauen, das trägt.
Wir schauen uns diesen Stand gemeinsam mit unseren Kunden an, bevor wir technische Konzepte entwickeln. Was dabei regelmäßig passiert: Oft sind die nutzbaren Daten besser als befürchtet. Und die problematischen Stellen sind kleiner und gezielter behebbar, als man dachte. Das ist der Unterschied zwischen einem Projekt, das liefert, und einem, das ein Jahr nach dem Go-live wieder mit Excel-Hilfslösungen flankiert wird.
Im nächsten Teil der Serie geht es um eine Voraussetzung, die noch seltener explizit geklärt wird als die Datenlage: Wer trägt eigentlich die Verantwortung dafür, dass dieser Prozess dauerhaft gut läuft?