Was schlechte Daten Ihr Unternehmen wirklich kosten — und warum frühes Erkennen günstiger ist

Ein nichttechnischer Leitfaden zu den Geschäftskosten schlechter Datenqualität — wohin das Geld wirklich fließt, warum ein Fehler mit jeder überlebten Stufe rund zehnmal teurer wird, und wie Sie Ihre eigene Zahl ermitteln, statt die eines Analystenhauses zu übernehmen.

2026-09-02 · 10 min read

Schlechte Daten kosten an vier Stellen Geld: die Stunden, die Ihr Team mit der Korrektur verbringt, die Entscheidungen, die deswegen falsch getroffen werden, das Vertrauen, das sie in Berichten zerstören, die niemand mehr glaubt, und die Kundinnen und Aufsichtsbehörden, die sie vor Ihnen sehen. Entscheidend ist nicht die Summe, sondern die Form. Ein Fehler, der dort abgefangen wird, wo er entsteht, kostet ein paar Minuten. Derselbe Fehler, in einer Vorstandsvorlage entdeckt, kostet eine Sitzung, eine Richtigstellung und einen Teil Ihrer Glaubwürdigkeit. Ihn früh abzufangen ist keine technische Vorliebe, sondern die gesamte Ökonomie des Problems.

Die Zahl, die Sie wahrscheinlich schon gesehen haben

Gartner schätzt die durchschnittlichen Kosten schlechter Datenqualität auf rund 12,9 Millionen US-Dollar pro Organisation und Jahr. Sie finden diese Zahl im Foliensatz jedes Anbieters für Datenqualität — inzwischen auch in diesem hier.

Behandeln Sie sie als Gesprächseinstieg, nicht als Beleg. Sie ist ein Durchschnitt über völlig unterschiedliche Organisationen, sie ist mehrere Jahre alt, und noch nie hat ein CFO ein Budget freigegeben, weil ein Analystenhaus einen Mittelwert veröffentlicht hat. Die Zahl, die Ihre Finanzleitung tatsächlich bewegt, ist die, die Sie aus Ihren eigenen letzten sechs Monaten berechnen — und die lässt sich meist leichter ermitteln, als man denkt.

Der nützlichere Teil der Forschung ist ohnehin nicht die Summe. Es ist der immer wiederkehrende Befund, dass die Kosten eines Fehlers damit wachsen, wie lange er überlebt.

Die 1-10-100-Regel

Die verbreitete Faustregel aus dem Qualitätsmanagement lautet, dass die Kosten mit jeder Stufe um etwa eine Größenordnung steigen:

1 US-Dollar für die Prävention — den Datensatz dort validieren, wo er erzeugt oder geladen wird.
10 US-Dollar für die Korrektur — ihn später in den eigenen Systemen finden und beheben.
100 US-Dollar für das Versagen — nichts tun und die Kosten der falschen Entscheidung, der falschen Rechnung, der falschen aufsichtsrechtlichen Meldung tragen.

Auf die genauen Faktoren kommt es nicht an, und präzise sollten sie nie sein. Auf die Form kommt es an, und die deckt sich mit nahezu jeder Erfahrung: Einen doppelten Kundendatensatz bei der Erfassung zu korrigieren, ist eine Trivialität; sechs Monate doppelt zugeordneten Umsatzes über drei nachgelagerte Systeme hinweg zu entwirren, ist ein Projekt.

Deshalb lohnt es sich, „früh abfangen" auszusprechen. Es klingt wie eine Plattitüde. Tatsächlich ist es eine Aussage über einen hundertfachen Kostenunterschied.

Wohin das Geld tatsächlich fließt

Vier Töpfe, grob nach ihrer Sichtbarkeit geordnet:

Kosten	Wie es aussieht	Warum es sich versteckt
Nacharbeit	Analystinnen gleichen zwei Zahlen ab, die übereinstimmen sollten; Engineers lassen Pipelines erneut laufen; jedes Quartal eine „Datenqualitätswoche"	Steckt in den Gehältern, wird nie ausgewiesen
Falsche Entscheidungen	Ware gegen eine kaputte Prognose bestellt; eine Kampagne auf eine falsch segmentierte Liste ausgerichtet; eine Einstellung auf Basis einer aufgeblähten Pipeline	Wird schlechtem Urteil zugeschrieben, nicht schlechten Eingangsdaten
Verlorenes Vertrauen	Teams bauen private Tabellen, weil sie dem Dashboard nicht glauben	Sieht aus wie Kultur, kostet wie doppelte Infrastruktur
Externes Versagen	Falsche Rechnungen, falsche aufsichtsrechtliche Meldungen, eine Kundin, der etwas Unwahres über ihr eigenes Konto gesagt wird	Wird erst gezählt, wenn daraus ein Vorfall wird

Der erste Topf ist der, den alle spüren und niemand misst. Wenn Ihre Analystinnen und Analysten einen Tag pro Woche damit verbringen, Zahlen abzugleichen, gehen rund 20 % Ihrer Analysekapazität dafür drauf, zu beweisen, dass die Daten von gestern stimmten — Kosten, die auf keiner Position je auftauchen und die Sie heute Nachmittag beziffern könnten.

Der vierte Topf ist der, der in einer Vorstandssitzung landet. Er ist zugleich der, den frühe Erkennung fast vollständig beseitigt, denn externes Versagen entsteht selten aus exotischen Problemen. Es entsteht aus gewöhnlichen Problemen, auf die niemand geachtet hat.

Warum Fehler teurer werden, je weiter sie reisen

Ein Fehler in einer Quelltabelle ist eine Tatsache über eine Tabelle. Hat er erst Ihre Transformationsschicht durchlaufen, ist er eine Tatsache über jedes Modell, das auf dieser Tabelle aufbaut. Erreicht er ein Dashboard, ist er eine Tatsache über jede Entscheidung, die jemand beim Blick darauf getroffen hat.

Drei Dinge kumulieren:

Der Schadensradius wächst. Eine fehlerhafte Spalte speist fünf Modelle, die zwanzig Dashboards speisen. Die Spalte zu reparieren ist einfach; alle zwanzig Konsumenten zu finden, sie zu informieren und zu korrigieren, was sie bereits getan haben, ist es nicht.

Die Spuren verschwinden. Ein Duplikat, das am Tag seines Entstehens gefunden wird, lässt sich auf den Ladevorgang zurückführen, der es verursacht hat. Dasselbe Duplikat, in einem Quartalsreview entdeckt, muss aus Logs rekonstruiert werden, die womöglich rotiert wurden — von jemandem, der damals nicht dabei war.

Vertrauen erholt sich nicht im selben Tempo, in dem es verloren geht. Ein zurückgezogener Bericht bringt Ihnen monatelang Leute ein, die Ihre Zahlen still in ihren eigenen Tabellen nachrechnen. Diese Kosten sind real, dauerhaft und in jedem Budget, das Sie je schreiben werden, unsichtbar.

Berechnen Sie Ihre eigene Zahl

Sie brauchen weder ein Reifegradmodell noch eine Beratung. Nehmen Sie Ihre letzten sechs Monate und beantworten Sie fünf Fragen:

Wie viele Datenvorfälle hatten Sie? Zählen Sie alles, wofür jemand eine Zahl korrigieren, neu berechnen oder sich dafür entschuldigen musste.
Wie lange dauerte es jeweils bis zur Erkennung? Nicht bis zur Behebung — bis zum *Bemerken*. Das ist meist die erschütternde Zahl.
Wie lange dauerte die Behebung jeweils, über alle Beteiligten hinweg, nicht nur beim Engineer, der den Fix geschrieben hat.
Wie viele wurden von einem Konsumenten gefunden statt von Ihnen? Wenn eine Stakeholderin Ihren Fehler findet, ist das eine andere, deutlich teurere Kategorie, als wenn Sie ihn selbst finden.
Was hat der schlimmste Fall tatsächlich gekostet — an getroffenen Entscheidungen, erstatteten Beträgen oder korrigierten Meldungen?

Multiplizieren Sie die Stunden mit einem Vollkostensatz, addieren Sie den schlimmsten Fall, und Sie haben eine belastbare Zahl, die vollständig aus Ihrer eigenen Historie stammt. In den meisten Teams landet die Antwort an einem Punkt, der das Gespräch über Werkzeuge sehr kurz macht.

Die mit Abstand nützlichste Kennzahl dieser Liste ist die Zeit bis zur Erkennung. Sie ist die, über die Sie die meiste Kontrolle haben, sie entscheidet, in welchem der 1-10-100-Töpfe ein Fehler landet, und sie ist die, die ein Monitoring-Werkzeug unmittelbar verbessert.

Was „früh abfangen" in der Praxis heißt

Frühe Erkennung ist keine Kultur der Wachsamkeit. Sie ist eine kleine Zahl konkreter, unspektakulärer Gewohnheiten:

Prüfen Sie Daten dort, wo sie eintreten, nicht dort, wo sie konsumiert werden. Die Validierung gehört an die Grenze — an den Punkt, an dem Daten aus einem Quellsystem eintreffen oder aus einem Ladevorgang landen —, denn dort ist der Schadensradius noch eine Tabelle breit.

Schreiben Sie auf, was „richtig" bedeutet, bevor Sie es brauchen. Die meisten Datenvorfälle sind nicht exotisch. Es sind ein Pflichtfeld, das NULL wurde, ein Schlüssel, der sich verdoppelt hat, eine Statusspalte, die einen Wert bekommen hat, den niemand erwartet hat, oder eine Tabelle, die schlicht nicht aktualisiert wurde. Diese Erwartungen lassen sich im Voraus in einfachen Worten formulieren, von der Person, der die Daten gehören — und sobald sie aufgeschrieben sind, lassen sie sich automatisch prüfen, für immer und kostenlos.

Genau das ist ein Data Contract. Es ist eine Vereinbarung zwischen denjenigen, die ein Dataset erzeugen, und allen, die davon abhängen, geschrieben in einem Format, das Mensch und Maschine lesen können: Diese Spalten existieren, diese hier ist nie leer, diese ist eindeutig, diese enthält immer nur diese fünf Werte, und diese Tabelle ist nie älter als einen Tag. Catalyst nutzt dafür genau den Open Data Contract Standard, damit die Vereinbarung in einem portablen offenen Format lebt und nicht im Produkt eines einzelnen Anbieters.

Überwachen Sie die Aktualität, nicht nur die Korrektheit. Der häufigste Datenvorfall sind nicht falsche Daten. Es sind *fehlende* Daten — ein Ladevorgang, der stillschweigend nicht lief und die Zahlen von gestern völlig plausibel aussehen lässt. Eine Freshness-Prüfung ist die billigste Regel, die Sie je schreiben werden, und sie fängt einen überproportionalen Anteil realer Vorfälle ab.

Alarmieren Sie bei der Veränderung, nicht beim Zustand. Sagen Sie den Leuten Bescheid, wenn etwas zu scheitern *beginnt*. Stündlich „scheitert immer noch" zu wiederholen, ist der Weg, auf dem ein Channel stummgeschaltet wird — und ein stummgeschalteter Channel ist schlimmer als gar keiner, weil er sich wie Abdeckung anfühlt.

Leiten Sie den Alarm an die Person, die ihn beheben kann. Ein Qualitätsfehler, der in einem allgemeinen Channel landet, ist das Problem aller und damit niemandes. Er sollte die im Contract benannte verantwortliche Person erreichen.

Die interne Argumentation

Drei Rahmungen, die in der Regel besser ankommen als die Kosten schlechter Daten selbst:

Beginnen Sie mit der Zeit bis zur Erkennung, nicht mit Qualität. „Wir erfahren von Datenproblemen derzeit dann, wenn uns eine Stakeholderin schreibt — im Schnitt elf Tage später" ist ein Satz, der Budget bekommt. „Unsere Datenqualität ist schlecht" ist ein Satz, der ein Nicken bekommt.

Schneiden Sie es auf eine Entscheidung zu, nicht auf eine Plattform. Nehmen Sie die drei Datasets hinter Ihrem meistgenutzten Bericht und decken Sie zuerst diese ab. „Alles überwachen" genehmigt niemand. „Dafür sorgen, dass das Umsatz-Dashboard nie wieder falsch ist" genehmigen viele.

Berichten Sie Abdeckung, nicht Vorfälle. Sobald das Monitoring läuft, zeigt sich Fortschritt am Anteil kritischer Datasets unter Contract und am Trend, wie schnell Fehler gefunden werden. Eine fallende Vorfallszahl ist mehrdeutig — sie kann bedeuten, dass es besser geworden ist, oder dass Sie aufgehört haben hinzusehen.

Wo Sie anfangen

Listen Sie Ihre zehn meistgenutzten Datasets. Nicht alle — die, mit denen Menschen tatsächlich Entscheidungen treffen.
Fragen Sie für jedes die verantwortliche Person, was zutreffen müsste, damit es falsch wäre. Sie bekommen vier oder fünf Antworten, und es werden einfache sein.
Schreiben Sie diese als Contract nieder und machen Sie automatische Prüfungen daraus.
Lassen Sie die Prüfungen im Takt der Daten laufen, direkt nach dem Job, der sie lädt.
Schicken Sie Fehler an die verantwortliche Person — und nur beim Übergang ins Scheitern.

Das ist für die meisten Teams eine Arbeitswoche, und es verschiebt Ihren typischen Fehler vom 100-Dollar-Topf in den 1-Dollar-Topf. Wie hoch der tatsächliche Faktor in Ihrer Organisation auch sein mag: Dort liegt die Rendite.

Häufig gestellte Fragen

Wie viel kostet schlechte Datenqualität ein Unternehmen?

Gartner schätzt durchschnittlich rund 12,9 Millionen US-Dollar pro Organisation und Jahr, aber Durchschnitte über eine ganze Volkswirtschaft sind keine Grundlage für einen Business Case. Berechnen Sie Ihre eigene Zahl aus den letzten sechs Monaten: Zählen Sie Ihre Datenvorfälle, die Stunden für Erkennung und Behebung jedes einzelnen sowie die Kosten des schlimmsten. Diese Zahl ist belastbar, wie es ein geliehener Benchmark nie ist.

Was ist die 1-10-100-Regel in der Datenqualität?

Eine Faustregel aus dem Qualitätsmanagement: Es kostet etwa 1 US-Dollar, einen Fehler zu verhindern, 10 US-Dollar, ihn zu korrigieren, sobald er in Ihren Systemen steckt, und 100 US-Dollar, mit den Folgen zu leben, wenn man auf ihn hin gehandelt hat. Die Faktoren waren nie als präzise Messwerte gedacht — der Punkt ist, dass die Kosten stark damit steigen, wie lange ein Fehler unentdeckt überlebt.

Warum ist es günstiger, Datenfehler früh abzufangen?

Weil die Kosten eines Fehlers mit seinem Schadensradius wachsen. An der Quelle abgefangen betrifft er eine Tabelle und lässt sich auf den Ladevorgang zurückführen, der ihn verursacht hat. Bleibt er unbemerkt, pflanzt er sich in jedes nachgelagerte Modell und Dashboard fort, die Spuren zur Diagnose altern weg, und Menschen treffen Entscheidungen auf seiner Basis. Frühe Erkennung ist der Unterschied zwischen einer Korrektur von fünf Minuten und einem Abgleich über mehrere Wochen.

Wie messe ich die Kosten schlechter Daten in meiner eigenen Organisation?

Erfassen Sie vier Dinge: Anzahl der Vorfälle, Zeit bis zur Erkennung, Zeit bis zur Behebung und wie viele von einem Konsumenten gemeldet statt intern gefunden wurden. Multiplizieren Sie den Aufwand mit einem Vollkostensatz je Stunde und addieren Sie die direkten Folgen des schlimmsten Vorfalls. Die Zeit bis zur Erkennung ist die handlungsrelevanteste der vier, weil sie bestimmt, wie teuer jeder andere Vorfall wird.

Brauche ich Engineers, um ein Datenqualitäts-Monitoring aufzusetzen?

Für die wichtigsten Teile nicht. Die wertvollen Regeln sind fachliche Regeln — dieses Feld ist immer gefüllt, dieser Identifikator ist eindeutig, dieser Status nimmt nur diese Werte an, diese Tabelle wird täglich aktualisiert — und wer sie kennt, ist die für die Daten verantwortliche Person, nicht eine Engineerin. Catalyst liest die Struktur Ihrer Tabelle automatisch aus und schlägt einen Startsatz an Prüfungen vor; die Aufgabe wird damit zum Prüfen und Anpassen statt zum Programmieren.

Macht unser Data Warehouse das nicht längst?

Data Warehouses erzwingen Struktur, nicht Bedeutung. Sie hindern Sie daran, Text in eine Zahlenspalte zu schreiben, akzeptieren aber bereitwillig eine Bestellung mit negativer Summe, eine vierfach duplizierte Kundin oder eine Tabelle, die seit Donnerstag nicht aktualisiert wurde. Mehrere verbreitete Data Warehouses erzwingen Eindeutigkeits-Constraints überhaupt nicht — siehe die Hinweise zu Redshift und BigQuery, wo deklarierte Primärschlüssel nie geprüft werden. In der Lücke zwischen „strukturell gültig" und „tatsächlich richtig" leben Datenvorfälle.