Power-BI-Berichte richtig dokumentieren

Wer Power-BI-Berichte dokumentieren will, muss mehr festhalten als die enthaltenen Visuals. Eine gute Dokumentation beschreibt warum der Report existiert, für wen er gebaut ist, welche Kennzahlen er verwendet und von welchen Modellen und Aktualisierungen er abhängt.

Damit wird der Report auch für Personen verständlich, die ihn nicht entwickelt haben. Gleichzeitig kann das BI-Team Änderungen besser einschätzen und wiederverwendete Measures konsistent halten.

Beginne mit einem kurzen Berichtssteckbrief und verweise von dort auf die verwendeten KPI- und Modelldefinitionen. Das verhindert, dass dieselbe Berechnungslogik in jeder Berichtsdokumentation separat gepflegt wird.

Was gehört in eine Power-BI-Berichtsdokumentation?

Die Dokumentation sollte drei Ebenen verbinden:

1. Fachlicher Kontext: Zweck, Zielgruppe, Entscheidungen und Verantwortliche
2. Berichtsstruktur: Seiten, Visuals, Filter, Navigation und Nutzungshinweise
3. Technische Herkunft: Measures, Datenmodelle, Refresh, Quellen und Abhängigkeiten

Wenn eine Ebene fehlt, entstehen typische Rückfragen. Ein rein fachliches Datenblatt hilft nicht bei einem fehlerhaften Refresh. Eine Liste technischer Measures erklärt nicht, welche Entscheidung der Bericht unterstützt.

Die zwölf zentralen Dokumentationsfelder

Ergänze Report-URL, Workspace und Status gleich im Steckbrief. Name und Screenshot allein reichen nicht aus, um Entwicklung, Test und Produktion zuverlässig auseinanderzuhalten.

Berichtszweck und Zielgruppe formulieren

„Sales Dashboard“ ist kein Zweck. Beschreibe, welche Entscheidungen mit dem Report getroffen werden. Zum Beispiel:

Der Bericht unterstützt Vertriebsleitung und Regionalverantwortliche bei der wöchentlichen Bewertung von Pipeline, Auftragseingang und Zielerreichung.

Die Zielgruppe beeinflusst Detailgrad, Aktualität und Berechtigungen. Ein operatives Dashboard für Account Executives braucht andere Filter und Refresh-Zeiten als ein monatlicher Bericht für die Geschäftsführung.

Dokumentiere auch, wofür der Bericht nicht geeignet ist. So wird verhindert, dass aggregierte Managementzahlen für operative Einzelfallentscheidungen verwendet werden.

Fachlichen und technischen Owner trennen

Der fachliche Owner entscheidet über KPI-Auswahl, Abgrenzungen und Prioritäten. Der technische Owner verantwortet Modell, Refresh und Fehlerbehebung.

Beide Rollen können in kleinen Teams bei derselben Person liegen. Die Trennung der Verantwortung bleibt trotzdem nützlich: Eine technische Änderung darf nicht stillschweigend eine fachliche Definition verändern.

Seiten, Visuals und Navigation beschreiben

Eine kompakte Seitenübersicht reicht häufig aus:

Dokumentiere besondere Navigation, Drillthroughs, Tooltips oder Bookmarks nur dann ausführlich, wenn sie für die Interpretation wichtig sind. Ziel ist Orientierung, keine pixelgenaue Bedienungsanleitung.

Measures und KPI-Definitionen verbinden

DAX-Measures enthalten Berechnungslogik, aber nicht immer eine verständliche Business-Definition. Für jedes entscheidungsrelevante Measure sollten dokumentiert sein:

• fachlicher Standardname,
• Aussage und Abgrenzung,
• Formel oder DAX-Ausdruck,
• Einheit und Zeitraum,
• Owner und Status,
• verwendete Tabellen und Felder,
• Abhängigkeiten zu weiteren Measures.

Technische Hilfs-Measures können im Modell dokumentiert bleiben. Sie müssen nicht alle als Business-KPI erscheinen. Diese Trennung verhindert, dass ein Kennzahlenkatalog mit Zwischenrechnungen überladen wird.

Filter, Zeitlogik und Berechtigungen

Filter verändern die Aussage eines Reports. Halte mindestens fest:

• globale und seitenspezifische Standardfilter,
• verwendete Datumslogik,
• ausgeschlossene Test- oder interne Datensätze,
• Währungs- und Regionseinstellungen,
• Row-Level-Security oder andere Sichtbeschränkungen.

Ein häufiger Fehler ist eine KPI-Definition, die fachlich korrekt wirkt, während der Bericht zusätzliche versteckte Filter verwendet. Definition und tatsächlicher Reportkontext müssen zusammenpassen.

Filter sind keine Berechtigungskontrolle. Ein Slicer beschreibt die aktuelle Auswahl; Row-Level Security beschreibt, welche Daten eine Rolle sehen darf. Dokumentiere beides getrennt und teste mit der vorgesehenen Nutzerrolle. Microsoft erläutert die Abgrenzung in der Dokumentation zu Row-Level Security.

Refresh und Aktualität

Dokumentiere nicht nur „täglich“, sondern:

• geplante Aktualisierungszeit,
• relevante Zeitzone,
• erwartete Quellverfügbarkeit,
• verantwortliches Team,
• Verhalten bei einem Fehler,
• sichtbare Kennzeichnung der Datenaktualität.

Unterscheide den Datenstand der Quelle, den letzten erfolgreichen Modell-Refresh und die Aktualisierung der Visuals. Bei Import-Modellen wird ein gespeicherter Datenbestand geladen; DirectQuery greift bei der Auswertung auf die Quelle zu. Ein neu geladenes Visual garantiert deshalb nicht automatisch aktuelle Quelldaten. Die technischen Varianten beschreibt Microsoft unter Datenaktualisierung in Power BI.

Ein verständlicher Hinweis lautet beispielsweise: „ERP-Daten bis gestern 23:59 Uhr; Modell zuletzt heute um 06:12 Uhr aktualisiert, Europe/Berlin.“ Das ist aussagekräftiger als „zuletzt heute aktualisiert“.

Quellmodelle und Abhängigkeiten

Dokumentiere das semantische Modell, auf das der Bericht zugreift, einschließlich Workspace und Owner. Wenn dieses Modell weitere semantische Modelle oder Datenquellen einbindet, erfasse sie als vorgelagerte Abhängigkeiten. So bleiben Bericht und Modellkette unterscheidbar.

Für eine Auswirkungsanalyse sind mehrere Arten von Beziehung wichtig:

• Report verwendet Measure.
• Measure hängt von weiterem Measure ab.
• Measure verwendet Tabelle oder Feld.
• Modell bezieht Daten aus einer Quelle.
• Report ersetzt oder ergänzt einen anderen Report.

Diese Beziehungen sollten strukturiert statt ausschließlich als Text gepflegt werden. Wie das Modell dahinter dokumentiert wird, zeigt der Leitfaden Datenmodelle dokumentieren.

Änderungshistorie sinnvoll führen

Nicht jede Farbänderung braucht einen Governance-Eintrag. Dokumentiere Änderungen, die Bedeutung, Nutzung oder Ergebnis beeinflussen:

• neue oder entfernte KPI,
• geänderte Berechnungslogik,
• neue Standardfilter,
• Anpassung von Zeit- oder Währungslogik,
• Wechsel des Quellmodells,
• Änderung von Owner oder Status,
• Ablösung durch einen anderen Report.

Zu jedem Eintrag gehören Datum, Verantwortlicher, Grund und betroffene Elemente.

Durchgängiges Beispiel: Vertriebssteuerungsbericht

Dieses fiktive Beispiel zeigt den Dokumentationsumfang, keine vorhandene Kundenimplementierung.

Name: Sales Performance & Pipeline

Zweck: Wöchentliche Steuerung von Auftragseingang, Umsatz, Pipeline und Forecast auf Unternehmens- und Regionsebene

Zielgruppe: CRO, Vertriebsleitung, Regional Leads

Fachlicher Owner: VP Sales Operations

Technischer Owner: BI Sales Team

Seiten: Executive Overview, Pipeline, Forecast, Regionen, Opportunity Details

Zentrale KPIs: Nettoumsatz, Auftragseingang, Pipeline Value, Win Rate, Forecast Accuracy

Standardfilter: Aktuelles Geschäftsjahr; interne Test-Accounts ausgeschlossen; Konzernwährung EUR

Quellmodell: Sales Analytics Model

Refresh: Werktags um 06:00 Uhr Europe/Berlin nach Abschluss der CRM-Replikation

Abhängigkeiten: CRM Opportunity, ERP Sales Order, Wechselkurstabelle und Kalenderdimension

Letzte fachliche Änderung: Win Rate nutzt seit Juli das Abschlussdatum statt des Erstellungsdatums. Die Änderung gilt ab Juli; frühere Monatsstände werden in diesem Beispiel nicht rückwirkend neu berechnet.

Abnahmefall: Zwei Nutzer sehen unterschiedliche Werte

Die Vertriebsleitung sieht 120 abgeschlossene Opportunities, eine Regionalleitung nur 30. Bevor die Formel geändert wird, prüfe die Dokumentation in dieser Reihenfolge:

1. Verwenden beide dieselbe produktive Reportversion und dasselbe Modell?
2. Sind Zeitraum, Datumsfeld und gesetzte Filter identisch?
3. Beschränkt RLS die Regionalleitung auf ihre Region?
4. Sind Datenstand und letzter erfolgreicher Refresh vergleichbar?
5. Berechnet das Visual die Quote im aktuellen Kontext oder verwendet es eine abweichende Measure-Logik?

Die Abweichung kann fachlich gewollt sein. Eine gute Berichtsdokumentation erlaubt, das nachvollziehbar zu erklären, bevor ein vermeintlicher Fehler behoben wird.

Review-Checkliste

• Zweck und Zielgruppe sind konkret beschrieben.
• Fachlicher und technischer Owner sind benannt.
• Seitenübersicht und wichtige Navigation sind aktuell.
• Entscheidungsrelevante Measures besitzen fachliche KPI-Definitionen.
• Standardfilter, Zeitlogik und Berechtigungen sind sichtbar.
• Quellmodelle, Tabellen und Measure-Abhängigkeiten sind verknüpft.
• Refresh-Zeit und Verhalten bei Fehlern sind dokumentiert.
• Fachlich relevante Änderungen sind nachvollziehbar.
• Veraltete Reports verweisen auf ihren Nachfolger.
• Dokumentation und sichtbarer Report widersprechen sich nicht.

Häufige Fehler

Nur Screenshots dokumentieren

Screenshots veralten schnell und sind nicht durchsuchbar. Strukturierte Metadaten bleiben für Suche und Beziehungen nutzbar.

Jedes DAX-Measure als KPI behandeln

Hilfs-Measures haben technische Bedeutung, sind aber nicht automatisch geschäftliche Steuerungsgrößen.

Modellmetadaten mit vollständiger Berichtsdokumentation verwechseln

Ein Modellimport liefert keine vollständige Beschreibung von Reportseiten, Bookmarks, Nutzungskontext und fachlichen Entscheidungen. Ergänze diese Informationen gezielt am Bericht, statt sie aus Measure-Namen abzuleiten.

Refresh und Datenstand verwechseln

Ein erfolgreicher Berichtslauf garantiert nicht, dass alle Quellen aktuell waren. Dokumentiere erwartete Quellverfügbarkeit und sichtbaren Datenstand.

Reportvarianten ohne Lebenszyklus behalten

Kennzeichne Entwürfe und veraltete Reports. Ein Katalog ohne Status vergrößert das Suchproblem.

Häufige Fragen

Fazit

Power-BI-Dokumentation verbindet Berichtszweck, Nutzerkontext und technische Herkunft. Beginne mit Ownern, KPIs, Filtern, Quellmodell und Refresh. Ergänze Seiten und Änderungen so detailliert, wie es für Betrieb und Entscheidungen notwendig ist.

Passende Blogartikel

• Datenmodelle richtig dokumentieren: Grain, Beziehungen und Lineage