Datenqualitäts­management: Fehlerklassen, Zuständige, Behebung an der Quelle

Weil ein Score sagt, wie gut die Daten sind, und nicht, wer etwas tun muss. Ein Data & AI Berater hat für ein Team die Daten im Power-BI-Modell gemessen. Wie das geht, beschreibt Datenqualität in Power BI prüfen. Das Ergebnis im Beispiel: 40 Regeln, 86 von 100 Punkten, 14 Punkte bis zum Ziel.

Das Team stellt den Score in seiner Runde vor. Beim nächsten Lauf steht er wieder bei 86. Niemand hat etwas falsch gemacht. Es hat sich nur niemand gemeint gefühlt. Eine Regel wie „Jeder Auftrag nennt einen Kunden“ zeigt 200 Verstöße. Wer die 200 Aufträge nachträgt, steht im Ergebnis nicht.

Daraus wird der nächste Auftrag. Der Berater soll aus dem Score eine Arbeitsliste machen. Jede Zeile dieser Liste braucht drei Angaben: was zu tun ist, wo es getan wird und von wem. Erst dann führt eine Messung zu einer Korrektur.

Der Berater ändert dafür nichts an der Messung. Regeln, Abfragen und Score bleiben, wie sie sind. Er ergänzt den Katalog um eine Angabe je Regel: die Fehlerklasse. Alles Weitere folgt aus ihr.

Fünf Schritte, die sich wiederholen: Regeln festlegen, messen, zuordnen, beheben, wieder messen. Der Berater richtet sie als Kreislauf ein. Jeder Schritt hat ein Ergebnis, das der nächste braucht.

Die Schritte haben ein Vorbild. ISO 8000-61 beschreibt Datenqualitätsmanagement als Prozesse. Im Kern stehen Planung, Lenkung, Sicherung und Verbesserung der Datenqualität. Die Norm beschreibt, was zu tun ist. Womit ein Team es tut, lässt sie offen.

Auch DAMA-DMBOK, das Rahmenwerk für Datenmanagement, führt Datenqualität als eigenes Wissensgebiet (Kapitel 13). Für die Arbeit im Alltag heißt das: Datenqualität ist eine Daueraufgabe und kein Projekt.

In der Praxis fehlt selten die Messung. Es fehlt der dritte Schritt, die Zuordnung. Ohne sie geht ein Verstoß an niemanden. Die Tabelle zeigt die fünf Schritte und was nach jedem vorliegt.

Der Fachbereich, in dem die Daten entstehen. Die IT kann ein Feld liefern. Einen fehlenden Kunden kann sie nicht nachtragen. Der Berater klärt deshalb zuerst, wer welche Rolle hat. Fünf Rollen genügen für den Anfang.

Der Data Owner verantwortet die Daten eines Bereichs. Er bestätigt die Zielwerte und entscheidet über Ausnahmen. Der Data Steward pflegt die Daten im Alltag und behebt die Verstöße. Wer Schnittstelle oder Export betreibt, sorgt dafür, dass Felder und Lieferungen ankommen. Die Verantwortlichen des Quellsystems richten Pflichtfelder und Eingabeprüfungen ein. Das BI-Team pflegt den Regelkatalog und startet den Lauf.

Wichtig ist die Trennung. Wer misst, entscheidet nicht über den Zielwert. Wer den Zielwert bestätigt, pflegt nicht jeden Satz selbst. So bewertet niemand seine eigene Arbeit. An welchen Stellen ein Mensch entscheidet und was ein Agent vorbereiten darf, zeigt Human in the Loop.

In kleinen Teams trägt eine Person mehrere Rollen. Das genügt, solange je Fehlerklasse ein Name feststeht. Eine Abteilung als Zuständiger reicht nicht. Eine Liste, die an alle geht, bearbeitet niemand.

Eine Fehlerklasse bündelt die Regeln, deren Verstöße dieselbe Art Behebung an der Quelle brauchen. Jede Regel gehört zu genau einer Klasse. Die Klasse nennt drei Dinge: was fehlt, wie es behoben wird und wer zuständig ist.

Der Berater geht den Katalog Regel für Regel durch. Zu jeder stellt er dieselbe Frage: Was müsste an der Quelle geschehen, damit dieser Verstoß verschwindet? Regeln mit derselben Antwort kommen in dieselbe Klasse. Im Beispiel werden aus 40 Regeln sieben Klassen. Die Tabelle unter der Kurzantwort zeigt sie.

Eine Dimension reicht dafür nicht. Zwei Regeln der Dimension Vollständigkeit können verschiedene Arbeit bedeuten. Ist ein Feld leer, weil es niemand gepflegt hat, trägt die Datenpflege es nach. Ist es im Quellsystem gefüllt und fehlt im Export, nimmt der Betreiber es auf. Für den Leser des Scores ist beides Vollständigkeit. Für die Behebung sind es zwei Aufgaben für zwei Personen.

Die Klasse ist eine Annahme über die Ursache. Stimmt sie nicht, wandert die Regel in eine andere Klasse. Das geschieht im Katalog und nicht im Code. So bleibt die Zuordnung für den Fachbereich lesbar.

Die Klasse, die den Gesamtscore die meisten Punkte kostet. Jede gewertete Regel kostet Punkte, sobald sie ihr Ziel verfehlt. Wie viele, hängt an ihrem Abstand zum Ziel und an ihrem Gewicht. Wie der Score einer Regel entsteht, zeigt Datenqualität in Power BI prüfen.

Der Berater summiert diese Punkte je Fehlerklasse. Alle Klassen zusammen ergeben genau den Abstand zum Ziel, im Beispiel 14 Punkte. So sieht das Team, welche Klasse wie viel davon trägt.

Die Zahl der Verstöße allein führt in die Irre. Eine Klasse mit wenigen Verstößen kann viele Punkte kosten, wenn sie eine schwere Regel trifft. Eine Klasse mit vielen Verstößen kostet wenig, wenn ihre Regeln knapp unter dem Ziel liegen. Deshalb stehen beide Werte nebeneinander. Die Werte der Tabelle sind Beispielwerte.

Das Beispiel am Ende des Abschnitts zeigt die Abfrage dazu. Sie liest das Ergebnis eines Laufs, eine Zeile je Regel.

Eine Liste der betroffenen Sätze, je Fehlerklasse. Jede Zeile nennt drei Dinge: welches Objekt, welches Feld, welcher Wert. Mit der Zahl 200 kann niemand arbeiten. Mit 200 Auftragsnummern schon.

Die Liste entsteht im selben Lauf wie der Score. Zu jeder Regel gibt es eine zweite Abfrage, die die verletzten Sätze zurückgibt. Was ein Lauf schreibt, beschreibt Datenqualität in Power BI prüfen. Je Regel ist die Liste begrenzt. Ist sie kürzer als die Zahl der Verstöße, steht das im Ergebnis.

Die Liste ist die einzige Datei mit einzelnen Sätzen. Sie enthält Schlüssel und Werte aus dem Quellsystem. Deshalb geht sie nur an den Zuständigen und liegt nicht im Repository. Score, Zählungen und Fehlerklassen darf jeder sehen.

Der Berater schickt keine Liste ohne Begleitsatz. Der Satz steht in der Fehlerklasse: was zu tun ist und woran man erkennt, dass es erledigt ist. Die Zeilen der Tabelle sind Beispielwerte mit erfundenen Schlüsseln.

Weil eine Korrektur im Bericht den Fehler nur für diesen Bericht versteckt. Das Quellsystem, der nächste Export und jeder andere Bericht zeigen ihn weiter. Ein KI-Agent, der auf dem Modell antwortet, liest ihn ebenfalls.

Zwei Muster kennt fast jedes Team. Ein Filter blendet Aufträge ohne Kunden aus. Ein Schritt beim Laden ersetzt leere Felder durch „Unbekannt“. Der Bericht sieht danach sauber aus, und an den Daten hat sich nichts geändert. Der Katalog zählt solche Platzhalter deshalb als leer.

Je weiter vorn die Behebung liegt, desto länger hält sie. Im Quellsystem gilt sie für alle, die die Daten nutzen. In der Schnittstelle gilt sie für alle Empfänger der Lieferung. Beim Laden gilt sie für ein Modell, im Bericht für eine Seite.

Nicht jeder Verstoß ist ein Fehler. Manches ist eine bekannte Ausnahme, etwa ein Altbestand ohne Pflichtfeld. Dann entscheidet der Data Owner, dass sie bleiben darf. Die Ausnahme steht im Katalog und nicht in einem Filter.

Erst wenn der Fachbereich die Zielwerte bestätigt hat. Bis dahin ist jeder Zielwert ein Vorschlag des Beraters. Der Score vergleicht dann zwei Läufe miteinander. Ob die Daten gut genug sind, sagt er noch nicht.

Deshalb steht neben dem Score, auf wie vielen Regeln er ruht und wie viele davon ein bestätigtes Ziel haben. Wer einen Zielwert bestätigt und wie das Gespräch dazu läuft, beschreibt Datenvalidierung.

Manche Regeln können noch nicht laufen. Sie brauchen Daten, die das Modell nicht lädt, zum Beispiel das Datum einer Lieferung. Der Berater streicht sie nicht. Sie bleiben als „nicht prüfbar“ im Katalog sichtbar. So sieht jeder, was der Score nicht abdeckt.

Andere Regeln werden berichtet und nicht gewertet. Sie zeigen einen Hinweis und kosten keine Punkte. Die Tabelle zeigt die vier Fälle.

Am nächsten Lauf. Derselbe Katalog läuft nach der nächsten Lieferung noch einmal. Hat die Datenpflege die Sätze korrigiert, sinken die Verstöße der Klasse und mit ihnen die verlorenen Punkte.

Im Beispiel arbeitet die Datenpflege zuerst die Klasse „Wert fehlt“ ab. Beim nächsten Lauf kostet sie noch 2,0 statt 5,2 Punkte. Der Gesamtscore steigt von 86 auf 89,2. Die übrigen Klassen stehen unverändert da. Auch diese Werte sind Beispielwerte.

Jeder Lauf schreibt eine Zeile in den Verlauf. So sieht das Team über Wochen, welche Klasse kleiner wird und welche wieder wächst. Wie aus einzelnen Läufen ein Verlauf wird, zeigt Data Observability.

Wächst eine Klasse nach der Behebung wieder, liegt die Ursache nicht in einzelnen Sätzen. Dann fehlt ein Pflichtfeld oder eine Prüfung bei der Eingabe. Das ist eine Aufgabe für die Verantwortlichen des Quellsystems und keine für die Datenpflege.

Datenqualitätsmanagement ordnet die Arbeit, es erledigt sie nicht. Sieben Grenzen sollte ein Team kennen, bevor es sich auf den Kreislauf verlässt.

• Ohne Zuständigen bleibt die Liste liegen. Eine Fehlerklasse ohne Namen ist nur eine weitere Auswertung.
• Die Fehlerklasse ist eine Annahme. Die wahre Ursache zeigt erst der Blick in das Quellsystem. Stimmt die Annahme nicht, wandert die Regel in eine andere Klasse.
• Der Score ist kein Urteil, solange Zielwerte Vorschläge sind. Bis zur Bestätigung taugt er nur zum Vergleich zweier Läufe.
• Der Lauf sieht nur geladene Daten. Regeln auf Daten, die das Modell nicht lädt, bleiben „nicht prüfbar“.
• Die Liste enthält einzelne Sätze. Sie gehört nicht in das Repository und nicht in einen Verteiler.
• Eine Regel findet nur, wonach sie fragt. Ein Wert kann jede Regel erfüllen und trotzdem falsch sein.
• ISO 8000-61 beschreibt Prozesse, kein Werkzeug. Die Angaben in diesem Kapitel folgen der Beschreibung im Katalog der ISO, nicht dem Normtext.