Das Wichtigste in Kürze
  • Datenqualität ist kein Projekt, sondern ein Betriebszustand: automatisierte Prüfungen in der Pipeline, klare Ownership und messbare Kennzahlen statt einmaliger Bereinigung.
  • Die sechs Dimensionen (Vollständigkeit, Genauigkeit, Konsistenz, Aktualität, Eindeutigkeit, Gültigkeit) machen Qualität überhaupt erst messbar und steuerbar.
  • Data Contracts verlagern die Qualitätsprüfung an die Quelle: Das Quellsystem garantiert ein Schema, statt dass Downstream-Teams jeden Fehler nachträglich abfangen.
  • Silent Data Errors sind teurer als Ausfälle: Ein falsch trainiertes ML-Modell fällt nicht aus, es liefert Monate lang plausible, falsche Ergebnisse.

Schlechte Datenqualität fällt selten sofort auf. Sie zeigt sich in einem Dashboard, dem niemand mehr traut, in einem ML-Modell, das plausible aber falsche Vorhersagen liefert, oder in einem Reporting, das jeden Monat manuell korrigiert wird. Dieser Artikel erklärt, wie Datenqualität im Unternehmen messbar wird, welches Framework sie dauerhaft sicherstellt und welche Fehler immer wieder scheitern.

Warum Datenbereinigung das Problem nicht löst

Der häufigste Ansatz ist auch der wirkungsloseste: Ein Team bereinigt einmalig einen Datenbestand, korrigiert Dubletten, vereinheitlicht Formate und erklärt die Datenqualität für hergestellt. Wenige Wochen später ist der Zustand wieder derselbe, weil die Ursache nicht adressiert wurde. Die Fehler entstehen laufend an der Quelle, und eine einmalige Bereinigung repariert das Ergebnis, nicht den Prozess.

Datenqualität ist deshalb kein Projekt mit Enddatum, sondern ein Betriebszustand. Er entsteht durch automatisierte Prüfungen bei jedem Pipeline-Lauf, klare Verantwortlichkeiten und Kennzahlen, die sichtbar machen, wenn die Qualität abweicht. Alles andere ist Symptombehandlung.

Die sechs Dimensionen der Datenqualität

Bevor Qualität gesteuert werden kann, muss sie messbar sein. Sechs Dimensionen haben sich in der Praxis etabliert:

  • Vollständigkeit: Fehlen Werte, wo Werte erwartet werden? Ein Kundendatensatz ohne Land ist für eine DSGVO-Residenzentscheidung wertlos.
  • Genauigkeit: Bilden die Daten die Realität korrekt ab? Eine syntaktisch gültige Adresse kann trotzdem falsch sein.
  • Konsistenz: Widersprechen sich Werte über Systeme hinweg? Wenn CRM und ERP unterschiedliche Umsätze für denselben Kunden führen, ist mindestens einer falsch.
  • Aktualität: Sind die Daten frisch genug für ihren Zweck? Ein Bestandswert von gestern taugt nicht für eine Echtzeit-Verfügbarkeitsprüfung.
  • Eindeutigkeit: Existiert jede Entität genau einmal? Dubletten verfälschen jede Aggregation.
  • Gültigkeit: Entsprechen die Werte den definierten Regeln und Wertebereichen? Ein Geburtsdatum in der Zukunft ist syntaktisch eine Zahl, fachlich ein Fehler.

Jede Dimension lässt sich als automatisierter Test formulieren. Erst dadurch wird aus einem vagen Qualitätsanspruch eine überprüfbare Zusage.

Das Framework: Prüfen, messen, verantworten

Ein tragfähiges Datenqualitäts-Framework besteht aus drei Schichten, die ineinandergreifen.

Automatisierte Prüfungen in der Pipeline. Qualitätsregeln laufen bei jeder Verarbeitung, nicht in einem separaten Review. Werkzeuge wie Great Expectations, dbt-Tests oder Soda definieren Erwartungen (etwa "Spalte Kundennummer ist nie leer und immer eindeutig") und schlagen an, sobald ein Lauf sie verletzt. Der entscheidende Punkt: Die Prüfung ist Teil des Datenflusses, nicht nachgelagert.

Kennzahlen und Monitoring. Qualität wird als Kennzahl geführt, pro Datensatz und pro Dimension, mit Schwellwerten und Alarmierung. Data-Observability-Plattformen erkennen zusätzlich Anomalien automatisch: ein plötzlicher Einbruch der Zeilenzahl, eine unerwartete Verteilungsverschiebung, ein verzögertes Update. So werden Fehler bemerkt, bevor ein Konsument sie meldet.

Ownership und Service Level. Jeder Datensatz hat einen verantwortlichen Owner, idealerweise das Domänenteam, das ihn erzeugt, und ein definiertes Qualitäts-Service-Level. Ohne klare Verantwortlichkeit verpufft jede gemessene Abweichung, weil niemand zuständig ist, sie zu beheben.

Data Contracts: Qualität an die Quelle verlagern

Das strukturell wirksamste Muster der letzten Jahre sind Data Contracts. Statt dass Downstream-Teams jeden Fehler nachträglich abfangen, garantiert das Quellsystem ein vertraglich festgelegtes Schema: definierte Felder, Datentypen, Wertebereiche und eine Zusage, dass Schemaänderungen angekündigt und versioniert werden.

Der Effekt ist grundlegend. Datenqualität wird zur Bringschuld des Erzeugers statt zur Holschuld des Konsumenten. Bricht ein Quellsystem den Vertrag, schlägt die Prüfung an der Grenze an, nicht drei Pipelines weiter in einem falschen Dashboard. Data Contracts verbinden damit Datenqualität mit Governance: Sie machen Verantwortlichkeit technisch durchsetzbar.

Silent Data Errors: die teuersten Fehler

Ein Systemausfall ist unangenehm, aber sichtbar: Jemand bemerkt ihn, jemand behebt ihn. Gefährlicher sind stille Datenfehler, die keine Fehlermeldung erzeugen und trotzdem falsche Ergebnisse produzieren.

Ein Beispiel aus der Praxis: Ein Quellsystem ändert die Einheit eines Feldes von Cent auf Euro, ohne Ankündigung. Die Pipeline läuft weiter, die Werte sind plausibel, das Reporting sieht korrekt aus. Erst Wochen später fällt auf, dass eine Kennzahl systematisch um den Faktor 100 daneben liegt. Bei einem ML-Modell ist es noch subtiler: Es fällt nicht aus, es wird auf korrumpierten Daten trainiert und liefert danach dauerhaft schlechtere Vorhersagen, ohne dass ein Alarm auslöst.

Genau gegen diese Klasse von Fehlern wirken automatisierte Prüfungen und Monitoring. Sie fangen die Abweichung ab, während sie klein ist, statt sie über Monate in Entscheidungen einsickern zu lassen.

Typische Fehler, die Datenqualität untergraben

Aus der Praxis: die Muster, die immer wieder scheitern.

1. Einmalige Bereinigung statt laufender Prüfung. Der Datenbestand wird bereinigt, der Prozess bleibt unverändert, der Zustand kehrt zurück.

2. Qualität ohne Owner. Abweichungen werden gemessen, aber niemand ist zuständig. Die Kennzahl wird zur Dekoration.

3. Prüfung erst am Ende. Fehler werden im finalen Dashboard entdeckt, nicht an der Quelle. Die Fehlersuche wird zur Rückwärtsarchäologie durch mehrere Pipelines.

4. Kein Schema-Vertrag. Quellsysteme ändern Struktur oder Bedeutung ohne Ankündigung, Downstream bricht still.

5. Qualität als reines IT-Thema. Ob ein Wert fachlich korrekt ist, weiß nur die Fachabteilung. Ohne deren Einbindung prüft die IT Syntax, nicht Bedeutung.

Datenqualität im Unternehmen aufbauen

DNA Solutions unterstützt Unternehmen im DACH-Raum dabei, Datenqualität dauerhaft sicherzustellen: von den messbaren Dimensionen über automatisierte Prüfungen in der Pipeline und Data Contracts bis zu klaren Verantwortlichkeiten und Monitoring. Wenn Sie einem Dashboard nicht mehr trauen oder ein Modell auf zweifelhaften Daten läuft, beginnen wir dort, wo die Fehler tatsächlich entstehen, an der Quelle. Sprechen Sie uns an.