Datenqualität verbessern: Regeln, Messgrößen und ein wirksamer Prozess
Wenn Sie Ihre Datenqualität verbessern wollen, beginnen Sie mit einem wichtigen Geschäftsprozess und wenigen überprüfbaren Regeln. Messen Sie den Ausgangszustand mit einem festen Nenner, beheben Sie die Fehlerursache an der Quelle und legen Sie fest, wer auf eine verletzte Regel reagiert. Erst dieser Zusammenhang macht aus einer guten Kennzahl verlässliche Daten.
Wofür wollen Sie Datenqualität verbessern?
„Unsere Daten sind schlecht“ ist noch kein bearbeitbarer Auftrag. Eine falsche Lieferadresse, ein fehlender Auftrag und ein verspäteter Umsatzbericht haben unterschiedliche Ursachen und Folgen. Beschreiben Sie deshalb zuerst, welche Entscheidung oder welcher Ablauf zuverlässig funktionieren soll. Anschließend bestimmen Sie die dafür notwendigen Daten: etwa Auftragsnummer, Kundenzuordnung, Betrag und Lieferstatus.
Für eine monatliche Trendanalyse kann ein Datenstand vom Vortag ausreichen. Eine Disposition benötigt möglicherweise einen deutlich frischeren Stand. Derselbe Datensatz kann damit für den einen Zweck brauchbar und für den anderen unzureichend sein. Dieser Zweckbezug ist zentral im Government Data Quality Framework. Eine universelle Qualitätsquote über sämtliche Unternehmensdaten liefert dagegen wenig Orientierung.
Priorisieren Sie Fehler anhand ihrer konkreten Wirkung. Verhindert ein fehlender Schlüssel die Rechnungsstellung? Wird ein Kunde doppelt kontaktiert? Müssen Mitarbeitende jeden Morgen Zahlen abgleichen? Beginnen Sie dort, wo ein Fehler eine klare Folge hat und ein Fachbereich das Sollverhalten erklären kann. Ein erreichbarer erster Auftrag ist beispielsweise: „Alle gestern bestätigten Bestellungen müssen bis 8 Uhr vollständig im Versandbestand stehen.“
Auch gut geprüfte Daten können unzulässig zugänglich sein oder für eine andere Fragestellung ungeeignet bleiben. Zugriffsschutz, Nutzungsrechte und fachliche Relevanz gehören deshalb zum Gesamtbild. Eine Qualitätsprüfung allein bestätigt weder Datenschutzkonformität noch die Richtigkeit jeder späteren Analyse.
Sechs Dimensionen in konkrete Qualitätsregeln übersetzen
Das offizielle Framework unterscheidet Vollständigkeit, Einzigartigkeit, Konsistenz, Aktualität, Gültigkeit und Genauigkeit. Besonders wichtig ist die letzte Trennung: Eine gültig formatierte Postleitzahl muss noch nicht zur tatsächlichen Lieferadresse passen. Formale Gültigkeit prüft Regeln; Genauigkeit prüft die Übereinstimmung mit der Wirklichkeit.
Die folgende Tabelle ist ein hypothetischer Prüfvertrag für Bestell- und Rechnungsdaten. Die Regeln sind eigene Beispiele, keine allgemeingültigen Grenzwerte. Jede Quote besteht aus einem definierten Zähler und Nenner. Der Prüfprozess macht nachvollziehbar, wie die Zahl entsteht.
| Dimension und Regel | Messgröße: Zähler / Nenner | Prüfprozess |
|---|---|---|
| Vollständigkeit: Kunden-ID vorhanden | Gestern eingegangene Bestellzeilen mit nicht leerer Kunden-ID / alle gestern eingegangenen Bestellzeilen | Nach dem Import NULL, leere Zeichenfolgen und reine Leerzeichen prüfen. Fehlende Zeilen zusätzlich gegen das Quellsystem abgleichen. |
| Einzigartigkeit: eine Zeile je Bestell-ID | Anzahl verschiedener nicht leerer Bestell-IDs / Anzahl der Zeilen mit nicht leerer Bestell-ID im Tagesimport | Nach ID gruppieren, Mehrfachvorkommen ausgeben. Fehlende IDs separat als Vollständigkeitsfehler behandeln. Die Quote misst Schlüssel je Zeile, nicht den Anteil ausschließlich einmal vorkommender IDs. |
| Gültigkeit: Status aus vereinbarter Liste | Zeilen mit Status aus der versionierten erlaubten Werteliste / alle Zeilen des Tagesimports | Liste mit dem Fachbereich bestätigen; unbekannte und fehlende Werte als Fehler ausgeben. Neue Statuswerte zuerst fachlich freigeben. |
| Konsistenz: Rechnung und Positionen stimmen überein | Rechnungen mit vollständigen Positionen und höchstens 0,01 Euro Abweichung / alle gestern importierten Euro-Rechnungen | Positionen einschließlich vereinbarter Steuer- und Rabattlogik berechnen; mit dem Gesamtbetrag desselben Datenstands vergleichen. Fehlende Positionen nicht aus dem Nenner entfernen. |
| Aktualität: fällige Lieferungen rechtzeitig da | Bis 8 Uhr vollständig eingegangene fällige Datenpakete / alle laut Lieferplan bis 8 Uhr fälligen Pakete | Lieferplan mit Ankunftsprotokoll abgleichen. Ein komplett ausgebliebenes Paket muss erkennbar sein; Zeitstempel vorhandener Zeilen genügen nicht. |
| Genauigkeit: Lieferadresse tatsächlich bestätigt | Mit der bestätigten Originalbestellung übereinstimmende Adressen / alle vorab ausgewählten Adressen der Prüfungsstichprobe | Stichprobe vor der Prüfung auswählen und gegen den bestätigten Beleg kontrollieren. Unklare Fälle gesondert ausweisen und nicht als Treffer zählen. |
Zum Prüfvertrag gehören außerdem Zeitfenster, Verantwortliche, Ausnahmen und Reaktion. Eine leere Kunden-ID kann einen Versandlauf blockieren; ein optionales Marketingfeld darf vielleicht nur eine Warnung auslösen. Legen Sie diese Unterschiede mit dem betroffenen Fachbereich fest. Für notwendige Schlüssel ist eine einzelne Ausnahme unter Umständen wichtiger als der Durchschnitt über viele unkritische Felder.
Ein Nenner von null ergibt keine bestandene Prüfung. Sind wirklich keine Bestellungen angefallen, lautet der Status „nicht anwendbar“. Fehlt dagegen der erwartete Import, lautet er „Prüfung nicht möglich“ oder „Lieferung fehlt“. Diese Zustände dürfen in einem Dashboard nicht als grün erscheinen.
Warum 96 Prozent Vollständigkeit fehlende Daten verdecken können
Nehmen wir hypothetisch an, ein Import enthält 1.000 Bestellzeilen. Bei 960 Zeilen ist die Kunden-ID gefüllt. Die Feldvollständigkeit beträgt damit 960 / 1.000 = 96 Prozent. Das sagt etwas über die angekommenen Zeilen aus.
Das Quellsystem hat jedoch 1.020 Bestellungen für denselben Zeitraum bestätigt. 20 davon sind im Import überhaupt nicht enthalten. Keine Prüfung eines Feldes in den 1.000 vorhandenen Zeilen kann diese Bestellungen entdecken. Dafür benötigen Sie einen separaten Abgleich erwarteter und tatsächlich vorhandener Bestell-IDs. Die Lieferabdeckung beträgt im Beispiel 1.000 / 1.020, also gerundet 98,0 Prozent.
Auch diese beiden Quoten sollten Sie nicht einfach mitteln. Eine fehlende Bestellung ist ein anderer Fehler als ein fehlendes Feld. Bewahren Sie daher für jeden Messwert seine Grundgesamtheit, Definition und Fehlerliste auf. Prüfen Sie außerdem beide Systeme zum selben fachlichen Stichtag: Ein während des Abgleichs neu angelegter Auftrag ist nicht automatisch ein Importfehler.
Dieser Nennerfehler taucht ebenso bei Kundenstammdaten, Sensormessungen oder Tagesabschlüssen auf. Wer nur vorhandene Daten prüft, kann eine sauber wirkende Teilmenge mit einem vollständigen Datenbestand verwechseln.
In sechs Schritten vom Datenfehler zur stabilen Regel
Ein einmal bereinigter Bestand verliert seinen Wert, wenn dieselbe Ursache am nächsten Tag wieder Fehler erzeugt. Der folgende Ablauf ist ein praktischer Vorschlag für ein einzelnes Datenprodukt. Er verbindet Messung und Ursachenbehebung, wie sie auch die offizielle Anleitung zum Data Quality Action Plan behandelt.
1. Bestand und Datenweg untersuchen
Ermitteln Sie zunächst fehlende Werte, Wertverteilungen, Mehrfachschlüssel und Lieferzeiten. Betrachten Sie typische Tage und bekannte Störungen. Verfolgen Sie einen fehlerhaften Datensatz vom Report zurück über Transformation und Schnittstelle bis zur Erfassung. So erkennen Sie, ob das Problem schon in der Quelle besteht oder erst beim Transport entsteht.
2. Das Soll als gemeinsamen Prüfvertrag festhalten
Dokumentieren Sie je Regel Datenobjekt, Feld, fachlichen Zweck, Prüflogik, Zeitraum, Schwelle und Ausnahme. Vereinbaren Sie bei systemübergreifenden Daten ein führendes System je Merkmal: Die Versandadresse kann beispielsweise aus einem bestätigten Auftrag stammen, die Rechnungsanschrift aus der freigegebenen Kundenakte. Eine gemeinsame Plattform erspart diese fachliche Entscheidung nicht.
3. Die Ursache an der passenden Stelle beheben
Im Beispiel könnte die Kunden-ID leer werden, weil ein Import alte und neue Feldnamen unterschiedlich behandelt. Dann ist die robuste Korrektur eine angepasste Zuordnung samt Regressionstest. Ist bereits die Erfassung unvollständig, helfen passende Pflichtfelder und verständliche Eingabehinweise. Schulen Sie das Team an der konkreten Entscheidung: Wann darf ein Datensatz gespeichert werden und woher kommt der richtige Wert?
Eine Bereinigung bleibt manchmal nötig, etwa für einen vorhandenen Altbestand. Bewahren Sie dabei Originalwerte und Korrekturgrund auf. Ähnliche Namen sind nicht automatisch dieselbe Person; eine vermeintlich eindeutige Dublette muss fachlich bestätigt werden, bevor zwei Kundenakten zusammengeführt werden.
4. Für Fehler einen verbindlichen Ausgang wählen
Eine Warnung lässt Daten weiterlaufen und informiert die Zuständigen. Quarantäne hält betroffene Datensätze getrennt, während freigegebene Daten weiterverarbeitet werden können. Ein Stopp verhindert die betroffene Verarbeitung, wenn das Ergebnis fachlich unbrauchbar wäre. Entscheiden Sie diese Reaktionen vor dem ersten Alarm. Prüfen Sie insbesondere, ob ein stilles Entfernen ungültiger Zeilen den Bestand unbemerkt verkleinert.
5. Entscheidung und Bearbeitung zuordnen
Eine fachlich verantwortliche Person, häufig Data Owner genannt, entscheidet über Zweck, Priorität und akzeptierbare Grenzen. Ein Data Steward oder eine vergleichbare operative Rolle untersucht Fehler und stimmt Korrekturen ab. Das technische Team betreibt die Prüfungen und Schnittstellen. In kleinen Teams können Personen mehrere Rollen übernehmen; die Zuständigkeit pro Vorfall muss trotzdem eindeutig sein.
Ein hilfreicher Alarm nennt betroffene Regel, Zeitraum, Umfang, Beispieldatensätze und zuständige Person. Er sagt auch, welches Datenprodukt eingeschränkt ist. „Quote unter Schwelle“ ohne betroffene Bestellungen und Bearbeitungsweg führt häufig nur zu weiteren Rückfragen.
6. Erneut prüfen und die Regel weiterentwickeln
Spielen Sie korrigierte Daten nachvollziehbar erneut ein und vergleichen Sie das Ergebnis mit dem ursprünglichen Vorfall. Prüfen Sie, ob der Fehler beim nächsten regulären Lauf ausbleibt. Neue Fachstatus, geänderte Schnittstellen oder andere Zeitzonen können eine Regel später ungültig machen; versionieren Sie daher Definitionen und Tests.
Halten Sie bekannte Grenzen beim Datenprodukt sichtbar. Ein Umsatzbericht mit fehlendem Standort darf nicht denselben Freigabestatus haben wie ein vollständiger Bericht. Die offizielle Framework-Anleitung behandelt Metadaten und die Kommunikation von Qualität ausdrücklich. Eine Fehlermeldung ist nur dann nützlich, wenn die Menschen, die Daten verwenden, ihre Bedeutung kennen.
Welche Werkzeuge und Rahmen benötigen Sie?
Beginnen Sie bei der fehlenden Funktion. Für wenige klare Regeln können versionierte SQL-Abfragen, Datenbankbedingungen und Validierung bei der Eingabe ausreichen. Brauchen Sie regelmäßige Ausführung, Fehlerhistorie, Zuständigkeiten und Benachrichtigung, wird ein betreuter Prüfprozess wichtiger als eine weitere Bereinigungsoberfläche. Wenn sich die Richtigkeit eines Merkmals nicht aus dem Bestand ableiten lässt, benötigen Sie einen unabhängigen Referenzabgleich. Dieser kann mit einer verlässlichen Quelle automatisiert erfolgen oder als gezielte Stichprobe organisiert werden.
In Snowflake Data Quality Monitoring liefern Data Metric Functions zunächst Messwerte. Eine Erwartungsbedingung legt fest, ob diese Werte den definierten Regeln genügen. Die dokumentierte Funktion benötigt die Enterprise Edition und verursacht unter anderem Verbrauch für die Ausführung. Ein Nullwertzähler allein entscheidet also noch nicht, welche fachliche Abweichung akzeptabel ist.
Databricks Lakeflow Expectations bieten unterschiedliche Fehlerreaktionen: warnen und Zeilen behalten, ungültige Zeilen entfernen oder den betroffenen Flow scheitern lassen. Das Scheitern eines Flows stoppt nicht zwangsläufig alle parallelen Flows; bei dieser Fail-Reaktion werden laut Dokumentation keine Erwartungsmetriken aufgezeichnet. Ihr Betriebsprozess muss deshalb auch den Fehlerlauf und das erneute Verarbeiten nachvollziehbar machen.
Rahmen helfen bei der organisatorischen Einordnung. ISO 8000-61:2016 beschreibt ein Prozessreferenzmodell für Datenqualitätsmanagement. Es unterstützt die Einordnung der organisatorischen Prozesse; Ihre täglichen Feldprüfungen benötigen zusätzlich konkrete fachliche Regeln. Für den Start ist ein sauber gepflegter Regelvertrag oft hilfreicher als die Übernahme eines großen Reifegradmodells ohne verantwortliche Bearbeitung.
Nutzen messen und KI-Unterstützung realistisch einsetzen
Bewerten Sie den Nutzen an Ihrem gewählten Prozess. Erfassen Sie beispielsweise, wie viele Versandfälle korrigiert werden müssen, wie viel aktive Zeit der Abgleich beansprucht und wie häufig Datenprodukte verspätet freigegeben werden. Vergleichen Sie ähnliche Zeiträume und berücksichtigen Sie veränderte Fallzahlen. Weniger Fehler bei halb so vielen Aufträgen belegen noch keine Verbesserung der Fehlerquote.
Eine Wirtschaftlichkeitsrechnung benötigt getrennte Positionen: Aufbau und Betrieb der Prüfungen, Bearbeitung verbliebener Fehler und tatsächlich vermiedener Aufwand. Rechnen Sie denselben vermiedenen Fehler nicht einmal als ersparte Arbeitszeit und ein zweites Mal mit einem Pauschalbetrag ein, der diese Arbeitszeit bereits enthält. Ob Qualität Arbeit spart oder zunächst sichtbar macht, die vorher unbemerkt blieb, lässt sich nur am eigenen Prozess beurteilen.
KI kann bei einem solchen Vorgehen Vorschläge liefern: mögliche Regeln aus einer Feldbeschreibung ableiten, auffällige Muster zusammenfassen oder Prüfcode entwerfen. Lassen Sie jeden Vorschlag gegen echte Fachdefinitionen und bekannte Fehlerfälle prüfen. Ein Modell darf einen ungewöhnlichen, aber richtigen Namen nicht allein wegen seiner Seltenheit verändern. Eine automatische „Korrektur“ ohne Referenz kann den Bestand gleichförmiger machen und dabei seine Genauigkeit verschlechtern.
Formulieren Sie einen kleinen, vollständigen Startauftrag
Wählen Sie ein Datenprodukt, benennen Sie eine fachlich verantwortliche Person und vereinbaren Sie drei bis sechs Regeln einschließlich Nenner und Fehlerreaktion. Prüfen Sie einen repräsentativen Ausgangsbestand. Bearbeiten Sie danach eine Ursache vollständig bis zum nächsten regulären Lauf. So wird sichtbar, welche Daten-, Schnittstellen- und Betriebsentscheidungen tatsächlich nötig sind.
Wenn Sie diese Regeln anschließend mit Integration, Governance und einer gemeinsam nutzbaren Plattform verbinden möchten, beschreibt die eBiz-Seite zur Data-to-AI Foundation den organisatorischen und technischen Rahmen. Der Ausgangspunkt bleibt Ihr konkreter Datenprozess und dessen überprüfbarer Qualitätsbedarf.