DQ-Befunde wirklich beheben
Wie aus einem Data-Quality-Befund ein Remediation-Loop mit Ursache, Quellkorrektur, Ausnahme und Wirksamkeitsprüfung wird.
Diese Story schließt die kurze Serie Operatives DQ-Monitoring ab. Danach führen die Plattformteile weiter zu Fabric, dbt, Databricks, Cross-Platform-Regeln und Cockpit.
Begriffe vor dem Lesen
- Root Cause — Ursache des Fehlers, nicht nur seine sichtbare Auswirkung.
- Quellkorrektur — Behebung im führenden System, wenn der Fehler dort entsteht.
- Exception — befristete Ausnahme mit verantwortliche Person, Grund, Ablaufdatum und Risikoakzeptanz.
- Wirksamkeitsprüfung — Nachweis, dass der Fehler nach der Maßnahme nicht nur verschoben wurde.
- Nutzer Impact — betroffene Reports, KPIs, KI-Kontexte, Prozesse oder Kundenentscheidungen.
Ausgangslage
Ein Qualitätsbefund wird gesehen, ein Ticket wird erstellt, der Report bleibt aber online. Einige Werte werden in der Transformation repariert, andere bleiben in der Quelle falsch. Nach zwei Wochen fragt niemand mehr, ob die Ursache beseitigt wurde. Das Dashboard sieht besser aus, aber der nächste Consumer oder AI-Agent kann denselben Fehler wieder aufnehmen.
Das Problem ist nicht fehlende Aktivität. Das Problem ist ein offener Remediation-Loop.
Der Loop
Ein geschlossener Loop enthält fünf Schritte: Befund klassifizieren, Ursache lokalisieren, Entscheidung treffen, Behebung oder Ausnahme umsetzen, Wirksamkeit prüfen.
Die Entscheidung ist fachlich. Technik kann zeigen, wo der Fehler sichtbar wird. Der Owner muss akzeptieren, ob eine Quellkorrektur nötig ist, ob eine nachgelagerte Bereinigung erlaubt ist oder ob eine befristete Ausnahme getragen werden kann.
AI-Fitness prüfen
Nach jeder Behebung muss geprüft werden, ob der betroffene Datensatz in BI, Retrieval, Training, Features oder Agentenpfaden genutzt wird. Wenn ja, braucht der Consumer einen Hinweis: Was wurde korrigiert? Seit welcher Version? Welche alten Ergebnisse bleiben betroffen? Muss ein Index, Feature Store oder Report neu aufgebaut werden?
Ohne diesen Schritt wird Data Quality lokal besser, aber AI-Kontext bleibt alt.
Mini-Check
- Ist die Ursache benannt oder nur der Fehler gezählt?
- Wird an der Quelle korrigiert, wenn die Quelle falsch ist?
- Ist eine ETL-Korrektur sichtbar und begründet?
- Gibt es Ablaufdatum und verantwortliche Person für Ausnahmen?
- Wurden BI-, KI-Suche-, Training- und Agenten-Nutzer informiert oder neu aufgebaut?
Operational DQ monitoring
Part 3 of 3
View series