Data Quality Dashboard in Power BI: die Fehlerliste als eigener Bericht

Weil eine Datei mit Tausenden Zeilen niemand abarbeitet. Ein Data & AI Berater hat für ein Team die Daten im Power-BI-Modell geprüft. Der Lauf hat einen Score geliefert und eine Fehlerliste geschrieben. Im Beispiel sind es 2.578 Fehler in sieben Fehlerklassen.

Die Liste geht als Datei an die Datenpflege. Zwei Wochen später ist sie so lang wie vorher. Die Datenpflege wollte anfangen und wusste nicht, wo. Welche Zeilen gehören in ihren Bereich? Welche sind dringend? Die Datei sagt es nicht.

Der nächste Auftrag lautet deshalb: Die Liste soll sich filtern lassen, und zwar von denen, die korrigieren. Der Berater baut dafür keinen neuen Lauf. Er baut einen zweiten Bericht, der die Dateien des Laufs liest. Das Team nennt ihn Datenqualitäts-Dashboard.

Zwei Kapitel gehen diesem voraus. Datenqualität in Power BI prüfen zeigt, wie aus Regeln Abfragen werden. Datenqualitätsmanagement zeigt, wer welchen Fehler behebt. Dieses Kapitel zeigt die Stelle, an der die Datenpflege ihre Arbeit findet.

Mit drei Fragen: Was ist los, wer behebt es und wie, und wie dringend ist es? Jede Zeile der Liste ist ein Fehler an einem Satz. Sie trägt acht Angaben. Vier kommen aus dem Regelkatalog, vier aus den Daten.

Aus dem Katalog kommt, was vorher festgelegt wurde: die Tabelle, die Spalte, die Regel und die Fehlerart. Aus den Daten kommt, was im Satz steht: der Wert, die Original-ID, ein lesbarer Kontext und der Status des Objekts.

Die Original-ID ist die Kennung, unter der das Quellsystem den Satz führt. Neben ihr steht der Name ihrer ID-Spalte. Das ist wichtig, weil die Kennung je Fehler etwas anderes ist: einmal eine Kundennummer, einmal eine Auftragsnummer. Der Kontext nennt Name und Ort, damit ein Mensch den Satz wiedererkennt.

Im Beispiel liest sich die Zeile so: Beim Kunden K-4417 ist die Branche nicht gepflegt. Die Datenpflege trägt sie im Quellsystem nach. Der Kunde ist noch in Anlage. Der Fall ist deshalb weniger dringend als bei einem aktiven Kunden. Alle Angaben der Tabelle sind erfunden.

Fehlt nicht ein Wert, sondern ein ganzer Satz, nennt die Zeile die Tabelle, in der er fehlt. Ein Beispiel ist ein Auftrag mit einer Kundennummer, die der Kundenstamm nicht kennt.

Drei Zahlen, vier Diagramme, eine Suche und eine Tabelle. Mehr braucht die erste Fassung nicht. Der Berater legt eine einzige Seite an und nennt sie „Datenfehler“.

Die vier Diagramme sind Balkendiagramme, je eines für eine der vier Fragen. Ein Klick auf einen Balken filtert die Seite. Mit gedrückter Strg-Taste kommt ein weiterer Filter dazu. Ein zweiter Klick hebt ihn auf. Wer die Seite bedient, braucht dafür keine Einweisung in Power BI.

So arbeitet die Datenpflege damit. Sie wählt die Fehlerart, dann Tabelle und Spalte, dann den Status „aktiv“. Übrig bleibt die Liste der Sätze, die im Quellsystem zu korrigieren sind. Kennt jemand die Kennung schon, findet die Suche den Satz direkt.

Die Bildfolge unter der Tabelle zeigt die Seite in drei Zuständen: ohne Filter, nach den vier Klicks und nach einer Suche. Es sind Entwürfe mit Beispielwerten, keine Bildschirmfotos aus Power BI. Die Zahlen passen zu den Tabellen dieses Kapitels.

Ein Score steht nicht auf der Seite. Er sagt, wie gut die Daten sind, und nicht, was jemand tun muss. Wer hier arbeitet, braucht Zeilen. Score und Verlauf stehen weiter in den Dateien des Laufs. Wer sie zeigen will, legt dafür eine zweite Seite an. Wie sie aussehen kann, zeigt der Entwurf in Data Observability.

Die drei Zahlen sind Kennzahlen auf der Fehlerliste. Das Beispiel am Ende des Abschnitts zeigt sie als DAX-Abfrage. Die Werte der Tabelle sind Beispielwerte.

Wenn das Objekt in einem Zustand ist, in dem das Feld gefüllt sein muss. Ein Kunde in Anlage hat noch keine Branche. Das ist kein Fehler, der heute jemanden aufhält. Bei einem aktiven Kunden ist es einer.

Der Berater trägt deshalb im Katalog zu jeder Tabelle ein, welche Spalte den Status eines Satzes liefert. Der Lauf schreibt den Status in jede Zeile der Fehlerliste. Das vierte Diagramm zeigt ihn. Die dritte Zahl zählt nur die Fehler an aktiven Objekten.

Die Regel selbst bleibt, wie sie ist. Sie zählt weiter jeden leeren Wert. Der Status ändert nur die Reihenfolge der Arbeit: zuerst die aktiven Objekte, dann die anderen. So verschwindet kein Fehler aus der Liste, nur weil er gerade warten kann.

Wo die Grenze liegt, entscheidet nicht der Berater. Ob ein Wert erst bei aktiven Objekten erwartet wird, legt der Data Owner fest. Bis dahin ist die Grenze ein Vorschlag, wie jeder Zielwert. Manche Sätze tragen keinen Status, im Beispiel die Aufträge. Sie stehen unter „ohne Status“. Die Werte der Tabelle sind Beispielwerte.

Weil eine Prüfung das Geprüfte nicht verändern soll. Der naheliegende Weg wäre, die Fehlerliste in den geprüften Bericht zu laden. Dann stünde alles in einem Modell. Der Berater entscheidet sich dagegen und hält vier Gründe fest.

Der erste Grund ist die Reihenfolge. Die Prüfung braucht den fertig geladenen Bericht, ihr Ergebnis entsteht erst danach. Der Bericht müsste nach jeder Prüfung ein zweites Mal laden. Ohne das zweite Laden stünden die Fehler von gestern neben den Daten von heute.

Der zweite Grund ist die Abnahme. Jede neue Regel wäre eine Änderung an dem Modell, das der Fachbereich abgenommen hat. Außerdem prüfte der Bericht sich selbst. Eine Regel über alle Kennzahlen liefe auch über die Kennzahlen der Fehlerliste.

Der dritte Grund sind die Filter. Die Original-ID ist je Fehler etwas anderes. Eine Beziehung im Modell passt nur zu einer Art von Kennung. Ein Filter auf die Region träfe deshalb nur Fehler mit einer Kundennummer. Die übrigen fielen bei jedem gesetzten Filter still heraus.

Der vierte Grund ist die Freigabe. Die Fehlerliste enthält einzelne Sätze mit Namen und Adressen. Sie ist für die Datenpflege gedacht und nicht für alle Leser des Berichts. Technisch ginge beides in ein Modell. Die Trennung ist eine Entscheidung.

Klein, und in denselben Schichten wie jedes andere Modell. Das Dashboard liest einen Ordner, in dem jeder Lauf einen Unterordner mit Zeitstempel anlegt. Der Pfad ist ein Parameter. Geladen wird immer der jüngste Lauf: Der größte Ordnername gewinnt.

Zwischen Datei und Tabelle liegt je eine Abfrage, die nicht geladen wird. Sie liest die Datei, prüft die erwarteten Spalten und setzt die Datentypen. Fehlt eine Spalte, bricht sie mit einer klaren Meldung ab. So zeigt das Dashboard nie eine halbe Liste.

Geladen werden Fakten und Dimensionen. Die Fakten sind die Fehlerliste und die Ergebnisse je Regel, je Gruppe und je Fehlerklasse. Dazu kommen Protokoll und Verlauf. Fünf Dimensionen filtern sie: Regel, Fehlerklasse, Lauf, Datum und die Tabelle des geprüften Modells. Jede Beziehung läuft von der Faktentabelle zur Dimension, in eine Richtung.

Eine Stelle kostet beim ersten Bau Zeit. Der jüngste Lauf hat je Regel und je Fehlerklasse genau eine Zeile. Power BI Desktop hält solche Spalten für eindeutig. Beim Laden legt es von selbst Beziehungen an, eins zu eins und in beide Richtungen. Der Berater schaltet die automatische Erkennung für diese Datei ab und setzt die Beziehungen selbst.

Das Dashboard hält sich an dieselben Regeln wie der geprüfte Bericht: feste Präfixe für Tabellen, Schlüssel als ganze Zahlen, ein Zahlenformat für jede Kennzahl. Wie man ein Modell gegen einen solchen Regelsatz prüft, zeigt Power BI Dokumentation und Regelprüfung.

Über den Arbeitsbereich. Der Berater veröffentlicht das Dashboard im selben Arbeitsbereich wie den geprüften Bericht. Aus einem Arbeitsbereich entsteht genau eine App. Beide Berichte werden ihr hinzugefügt, das Dashboard als eigener Eintrag „Datenqualität“ in der Navigation.

Für die Nutzer bleibt es eine Anwendung. Sie öffnen die App und wechseln mit einem Klick zwischen Bericht und Fehlerliste. Dass dahinter zwei Datenmodelle liegen, merken sie nicht.

Wer den Eintrag sieht, regeln Zielgruppen. Eine App kann bis zu 25 Zielgruppen haben, und jeder Inhalt lässt sich je Zielgruppe ein- oder ausblenden. Die Datenpflege sieht beide Berichte, die übrigen Leser nur den Bericht. Ausblenden allein schützt nicht in jedem Fall. Ist der Zugriff auf ausgeblendete Inhalte erlaubt, öffnet ein direkter Link sie trotzdem.

Ein Sprung vom Bericht in die Fehlerliste ist der nächste Schritt. Power BI kennt dafür den berichtsübergreifenden Drillthrough: von einem Kunden im Bericht zu seinen Fehlern im Dashboard. Beide Berichte müssen dafür im selben Arbeitsbereich liegen. Das Feld muss in beiden gleich heißen und denselben Datentyp haben. Im Zielbericht wird der Drillthrough eingeschaltet.

Damit der Dienst das Dashboard aktualisieren kann, muss er den Ordner der Läufe erreichen. Liegt der Ordner auf einem Rechner im Haus, braucht die Aktualisierung ein Gateway. Die Angaben dieses Abschnitts folgen der Dokumentation von Microsoft, Stand November 2026.

In drei Schritten: den geprüften Bericht öffnen und aktualisieren, den Lauf starten, das Dashboard aktualisieren. Der Lauf dauert Sekunden. Er liest nur und ändert weder den Bericht noch die Quelldaten. Seine Abfragen gehen an den Rechner selbst und nicht ins Internet.

Der Rechner dafür braucht wenig. Lässt sich der Bericht in Power BI Desktop öffnen, reicht er aus. Dazu kommen eine Laufzeit für das Skript und der Ordner mit Katalog und Abfragen. Ein Server ist nicht nötig. Wie das Skript das geöffnete Modell erreicht, beschreibt Datenqualität in Power BI prüfen.

In vielen Häusern darf niemand selbst Software installieren. Der Berater klärt deshalb früh, wer den Lauf ausführt. Vier Wege stehen zur Wahl, die Tabelle nennt sie. Ansehen kann das Dashboard jeder, dem es freigegeben ist. Dafür braucht es keine Installation.

Zum Lauf gehört ein Rhythmus. Ein Lauf nach jeder Lieferung der Quelldaten genügt. Öfter zu prüfen bringt nichts, solange sich die Daten nicht ändern. Die Datenpflege sieht deshalb erst mit der nächsten Lieferung, ob ein korrigierter Fehler verschwunden ist.

Für die Prüfung selbst nichts. Jede Angabe im Dashboard lässt sich auf eine Regel oder auf einen Wert in den Daten zurückführen. Was ein Fehler ist, legt der Katalog fest. Gleiche Daten ergeben dasselbe Ergebnis.

Nützlich ist ein Agent an drei Stellen. Er findet Muster hinter den Fehlern, etwa dass fast alle fehlenden Werte aus einer Auftragsart stammen. Er schreibt eine kurze Zusammenfassung je Lauf. Und er schlägt neue Regeln vor.

Der Berater zieht dafür eine Grenze. Der Agent bekommt Summen und keine einzelnen Sätze mit Namen und Adressen. Seine Texte stehen als Vorschlag neben der Liste und sind so gekennzeichnet. Über eine neue Regel entscheidet ein Mensch. Wo solche Freigaben liegen, zeigt Human in the Loop.

Umgekehrt hilft das Dashboard jedem Agenten, der auf dem geprüften Modell antwortet. Die Summen je Fehlerart und Spalte sagen ihm, welche Felder gerade nicht tragen. Er kann das in seiner Antwort nennen, statt eine Lücke zu verschweigen.

Das Dashboard zeigt Fehler, es behebt keinen. Acht Grenzen sollte ein Team kennen, bevor es die Seite verteilt.

• Die Liste ist je Regel begrenzt. Der Lauf listet je Regel nur eine feste Zahl von Sätzen. Verletzt eine Regel mehr, zeigt das Dashboard einen Teil. Die volle Zahl steht im Ergebnis je Regel.
• Das Dashboard zeigt den jüngsten Lauf. Ohne neuen Lauf zeigt es alte Fehler. Der Zeitpunkt des Laufs gehört deshalb auf die Seite.
• Die Filter des geprüften Berichts wirken hier nicht. Wer nach Region oder Zeitraum filtern will, braucht dafür eine eigene Spalte in der Fehlerliste.
• Zwei Modelle sind zwei Veröffentlichungen. Beide Berichte gehören in denselben Arbeitsbereich. Der Ordner der Läufe muss für den Dienst erreichbar sein.
• Die Liste enthält einzelne Sätze. Zielgruppen in der App blenden Inhalte nur aus. Ob ein direkter Link trotzdem öffnet, hängt an einer Einstellung der App.
• Ohne Zuständigen bleibt auch ein Dashboard liegen. Filtern ersetzt keinen Namen je Fehlerklasse.
• Der Status ist eine Annahme. Ob „aktiv“ die richtige Grenze für „erwartet“ ist, entscheidet der Data Owner.
• Prüfung und Dashboard sind keine Funktion von ABIS. Die Prüfung ist ein Skript, das Dashboard ein gewöhnlicher Power-BI-Bericht.