Power BI validieren: GxP-Berichte und Datenmodelle

Einordnung und Geltungsbereich

Der Beitrag behandelt konfigurierte Berichte und semantische Modelle. Ein unverbindliches Management-Dashboard kann einen anderen Nachweisbedarf besitzen als ein Bericht, auf dessen Basis qualitätsrelevante Maßnahmen beschlossen werden.

Quellen: [1] [2]

Der richtige Einzelwert kann im falschen Filterkontext stehen

Prüfen Sie Beziehungen und Filter mit gezielten Gegenbeispielen. Nicht zugeordnete Datensätze können verschwinden, Mehrfachbeziehungen Werte vervielfachen. Tests sollten deshalb einen kontrollierten Quelldatenbestand mit bekannten erwarteten Ergebnissen verwenden und mehrere relevante Ansichten vergleichen.

Aktualität und Zugriff sind eigene Kontrollen. Zeigen Sie den für die Aussage maßgeblichen Datenstand, nicht nur das aktuelle Kalenderdatum. Microsoft weist außerdem darauf hin, dass Row-Level Security für bestimmte Workspace-Rollen nicht wie für Viewer greift. Rollenprüfungen müssen daher die spätere reale Berechtigung abbilden.

Quellen: [1] [2] [3]

Berichtszweck und Entscheidung zuerst festlegen

Ein Dashboard zur allgemeinen Orientierung hat einen anderen Einfluss als ein Bericht, auf dessen Basis Chargen priorisiert oder Qualitätsmaßnahmen ausgelöst werden. Beschreiben Sie die konkrete Entscheidung, ihre Eingangsquellen und mögliche Folgen falscher oder veralteter Daten. Daraus folgt, welche Nachweise für Modell, Aktualisierung und Darstellung benötigt werden.

Erfassen Sie Datenquelle, Transformation, semantisches Modell, Kennzahlen, Filter, Bericht und Zugriffsweg. Ein korrekt dargestelltes Diagramm kann auf unvollständigen Daten beruhen. Eine richtige Datenquelle kann durch einen falschen Join oder Filter verzerrt werden. Die Bewertung muss deshalb die gesamte benötigte Aussagekette betrachten.

Grenzen Sie Import, andere verwendete Verbindungsmodi und Aktualisierungswege anhand Ihrer tatsächlichen Lösung ab. Dieser Artikel setzt keinen einheitlichen Refreshmechanismus voraus. Dokumentieren Sie Gateway und technische Identität, falls diese zum Einsatz gehören. Der sichtbare Bericht allein beschreibt diese Abhängigkeiten nicht.

Quellen: [1] [2] [3]

Kennzahlen mit einem bekannten Referenzbestand prüfen

Definieren Sie jede kritische Kennzahl fachlich: Zähler, Nenner, Zeitraum, Statusauswahl und Umgang mit fehlenden Daten. „Offene Abweichungen“ kann nur aktuell offene Fälle meinen oder auch wiedereröffnete Vorgänge einschließen. Ohne diese Definition lässt sich ein Zahlenwert nicht als richtig beurteilen.

Bereiten Sie einen kleinen bekannten Referenzbestand vor. Verwenden Sie Fälle innerhalb und außerhalb des Zeitraums, unterschiedliche Status und fehlende Zuordnungen. Berechnen Sie erwartete Werte unabhängig vom Bericht. Die Testauswahl sollte kritische Transformationen und Filterwirkungen abdecken, nicht nur eine plausible Gesamtzahl erzeugen.

Quellen: [1] [2] [3]

Beispiel: richtige Daten, falscher Nenner

Das Szenario ist konstruiert. Zehn Fälle gehören zum betrachteten Zeitraum, davon zwei offene. Die eigene Kennzahl soll 2 geteilt durch 10, also 20 Prozent zeigen. Ein Filter auf „offen“ beeinflusst versehentlich auch den Nenner. Der Bericht zeigt 100 Prozent. Alle sichtbaren Einzelzeilen sind richtig; die Kennzahl ist trotzdem fachlich falsch.

Dokumentieren Sie Referenzfälle und unabhängige Rechnung. Prüfen Sie die Kennzahl ohne Filter, mit Standortfilter und mit einer Auswahl, die keine passenden Fälle enthält. Legen Sie fest, wie ein leerer Nenner dargestellt wird. Eine scheinbar elegante Null kann eine nicht berechenbare Aussage verdecken. Das erwartete Verhalten folgt der fachlichen Definition.

Ergänzen Sie einen Drilldown oder eine geeignete Vergleichsansicht, wenn sie zum vorgesehenen Review gehört. Die Summe der Details sollte zur dargestellten Kennzahl passen. Ein visueller Formatierungsfehler kann ebenso relevant sein, wenn Prozentzeichen, Einheiten oder Rundung eine Entscheidung verändern. Die Prüfung sollte diese Elemente ausdrücklich einschließen.

Quellen: [1] [2] [3]

Datenaktualität als Teil der fachlichen Aussage

Legen Sie fest, welcher Datenstand für die Entscheidung benötigt wird. Ein erfolgreicher Berichtsladevorgang beweist keine aktuelle Quelle. Ebenso kann ein erfolgreicher Refresh alte Quelldaten übernehmen. Unterscheiden Sie Quellenzeitpunkt, Übernahmezeitpunkt und Berichtsanzeige. Welche Angaben sichtbar sein müssen, folgt aus Ihrer Verwendung.

Testen Sie einen kontrollierten Aktualisierungsfehler. Der Nutzer sollte nicht unbemerkt einen alten Stand als aktuellen verwenden. Geeignete Kontrollen können eine erkennbare Datenstandangabe, überwachte Fehler oder eine begrenzte Nutzung sein. Der Artikel schreibt keine universelle Aktualisierungsfrequenz vor. Die Frist muss zum Prozessrisiko und zur tatsächlichen Datenentstehung passen.

Prüfen Sie auch Teilaktualisierung und fehlende Datensätze, soweit dies in Ihrer Architektur möglich ist. Ein Dashboard kann plausible Werte zeigen, obwohl eine Quelle ausgefallen ist. Eine geeignete Vollständigkeitskontrolle sollte die benötigten Datenbereiche berücksichtigen. Eine reine Prüfung des letzten technischen Erfolgszeitpunkts reicht dafür nicht immer.

Quellen: [1] [2] [3]

Row-Level Security mit tatsächlichen Rollen testen

RLS begrenzt Daten auf Zeilenebene im dafür vorgesehenen Kontext. Microsoft beschreibt, dass RLS im Workspace für Viewer gilt und nicht für Admin, Member oder Contributor in gleicher Weise greift. Verwenden Sie deshalb reale Zugriffsrollen im Test. Ein bestandener „View as“-Test allein beschreibt nicht jede tatsächliche Zugangsart.

Prüfen Sie positive und negative Datenbereiche. Ein Benutzer für Standort A soll die benötigten Daten sehen, aber keine unzulässigen Daten von B. Berücksichtigen Sie mehrere Rollenzuweisungen, Freigaben und Exporte, soweit sie Teil der Nutzung sind. Die konkrete Kombination und Plattformkonfiguration bestimmen die Aussage.

Unterscheiden Sie Informationsschutz von fachlicher Freigabe. RLS ist keine elektronische Signatur und keine Bestätigung einer Qualitätsentscheidung. Ein berechtigter Betrachter kann einen fehlerhaften Bericht sehen. Die Eignung der Kennzahl und die Angemessenheit des Datenzugriffs brauchen deshalb jeweils eigene Nachweise.

Quellen: [1] [2] [3]

Modelländerungen und Übergabe kontrollieren

Eine neue Spalte kann Beziehungen, Filter oder bestehende Kennzahlen beeinflussen. Bewerten Sie Änderungen an Datenquelle, Transformation, Modell und Bericht gemeinsam. Der aktuelle Stand sollte zu den geprüften Referenzfällen nachvollziehbar sein. Eine unveränderte Diagrammoberfläche bedeutet nicht automatisch eine unveränderte Berechnungslogik.

Übergeben Sie Kennzahlendefinition, Datenquellen, Aktualisierungsregeln, Rollen und bekannte Grenzen. Ein interner Reviewer sollte einen auffälligen Wert zu den zugehörigen Daten zurückverfolgen können. Eine schön gestaltete Visualisierung ohne erklärbaren Nenner oder Datenstand schafft im Audit zusätzliche Rückfragen.

Erhalten Sie benötigte Nachweise unabhängig von bloßen Bildschirmzuständen. Je nach Verwendung können Konfigurationsstand, Referenzdaten und Testausgaben erforderlich sein. Die genaue Aufbewahrung folgt Ihrem Prozess. Ein regelmäßig überschriebenes Dashboard ist nicht automatisch die vollständige historische Aufzeichnung einer früheren Entscheidung.

Quellen: [1] [2] [3]

Arbeitsvorlage: Kennzahl, Filter und Datenstand unabhängig erklären

Beschreiben Sie eine kritische Kennzahl in einer Form, die ohne DAX- oder Modellkenntnis verständlich ist. Im Beispiel werden offene Fälle im bezeichneten Zeitraum durch alle Fälle desselben Zeitraums geteilt. Notieren Sie Statusdefinition, Zeitraum, fehlende Zuordnungen und leere Auswahl. Erst dann wird der Bericht gegen den bekannten Referenzbestand geprüft.

Prüfen Sie dieselbe Frage unter mehreren erlaubten Filtern. Eine Standortauswahl darf nur den beabsichtigten Umfang verändern. Ein Filter auf offene Fälle darf den Nenner nicht unbeabsichtigt auf dieselbe Teilmenge reduzieren. Die unabhängige Rechnung ist dafür wichtiger als die optische Plausibilität des Diagramms.

Wenn eine Abweichung gefunden wird, prüfen Sie Quelle, Transformation, Modell und Darstellung getrennt. Ein Formatfehler kann anders behandelt werden als ein verlorener Datensatz. Dokumentieren Sie den betroffenen Umfang und bestätigen Sie nach Korrektur auch die relevanten Filter- und Zugriffsfälle.

Quellen: [1] [2] [3]

Refreshkette und fachliches Datenalter getrennt überwachen

Eine Aktualisierung kann mehrere Stufen enthalten: Quelle, Export, Gateway, semantisches Modell und sichtbare Berichtsebene. Legen Sie fest, welcher Zeitpunkt welche Aussage trägt. Ein erfolgreicher Modellrefresh um 08:00 Uhr beweist nicht, dass der Quellbestand ebenfalls von 08:00 Uhr stammt. Prüfen Sie einen kontrollierten Fall, in dem die Quelle veraltet bleibt, während die nachgelagerte Aktualisierung technisch erfolgreich ist. Die Anzeige muss die für die Entscheidung benötigte Information erkennen lassen.

Microsoft beschreibt Gatewayverbindung, Zugangsdaten und Zeitplan als Teile der geplanten Aktualisierung. Geplante Refreshs können nach vier aufeinanderfolgenden Fehlern oder einer nicht behebbaren Konfigurationssituation deaktiviert werden. Prüfen Sie die tatsächliche Fehlerkette und Reaktivierung im vorgesehenen Modell. Das Verfahren darf einen deaktivierten Zeitplan nicht stillschweigend als normalen aktuellen Betrieb behandeln. Die konkrete erlaubte Datenaltergrenze folgt Ihrem Geschäftsprozess; sie wird nicht aus einem allgemeinen Herstellerzeitfenster übernommen.

Quellen: [4]

Eigenes Ausfallbeispiel: Der Bericht öffnet, die Daten fehlen

Im konstruierten Fall werden für eine Morgenentscheidung aktuelle Sperrstatus benötigt. Die letzte belegte Quelle stammt vom Vortag. Der Bericht öffnet problemlos und zeigt die alte Population. Der Test simuliert den Quellausfall kontrolliert und prüft, ob der Nutzer den eingeschränkten Stand erkennt und die festgelegte Ausweichentscheidung anwenden kann. Ein grüner Berichtsladevorgang wäre dafür kein geeigneter Erfolgstest.

Die Microsoft-Dokumentation unterscheidet auch Benachrichtigungswege. On-demand- und programmatisch ausgelöste Refreshs erzeugen nicht dieselben E-Mail-Fehlerbenachrichtigungen wie die beschriebenen geplanten Aktualisierungen. Testen Sie deshalb die tatsächliche Alarmierung Ihres Auslösewegs, einschließlich Empfänger und Vertretung. Eine Benachrichtigung an ein nicht mehr betreutes Eigentümerkonto ist keine wirksame Betriebsreaktion.

Quellen: [5]

Die nächsten Schritte

• Entscheidung, Kennzahl und Datenumfang definieren.
• Transformationen, Beziehungen und Berechnungen nachvollziehbar erfassen.
• Filter-, Fehler- und Rollenfälle gegen einen bekannten Datenbestand prüfen.
• Aktualisierung, Versionsfreigabe und Änderungen kontrollieren.