Power BI Governance im Self Service

Power BI wird selten zu früh ein Erfolg. Meist passiert es so: Erst bauen ein paar Leute ein paar Reports. Dann merken plötzlich alle, dass es nützlich ist. Und dann — zack — ist es überall. Das Problem ist nicht zu viele Dashboards. Das Problem ist: zu viele Dashboards ohne Spielregeln.

Dann kommt der Klassiker: Board-Meeting in fünf Minuten, zwei Reports zeigen dieselbe Kennzahl - aber unterschiedlich. Und irgendwer sagt den Satz, der Power BI mehr schadet als jede schlechte Visualisierung:

“Wir wissen nicht, welcher Report stimmt.”

Governance ist die Antwort darauf. Aber bitte nicht indem jetzt erstmal alles gesperrt. Gute Governance Umsetzungen sind eher wie Leitplanken auf einer kurvigen Bergstraße: Sie sind nicht da, um dich langsam zu machen, sondern damit du schneller fahren kannst — ohne abzustürzen. Die Leitidee: Guardrails statt Gatekeeping. Self Service bleibt Self Service. Nur eben auf einem Untergrund, der nicht bei jedem Schritt knirscht.

Power BI Governance bedeutet klare Spielregeln für alle

Wenn du bei Governance nur an das Admin-Portal und Tenant Settings denkst, verpasst du den Kern. Microsoft sagt es sogar ziemlich deutlich: Tenant Settings helfen beim Establishing von Governance Policies, sind aber keine Sicherheitsmaßnahme. Beispiel: Das Deaktivieren von “Export data” schränkt nicht automatisch die Berechtigungen auf dem Semantikmodell ein — wer Leserechte hat, kann das Modell weiterhin abfragen und Ergebnisse ggf. auch anders persistieren.

Viele Teams versuchen, ein Problem mit dem falschen Werkzeug zu lösen. Governance, Security und Compliance hängen zusammen - aber sie sind nicht dasselbe. Wenn du das sauber auseinanderziehst, bekommst du Kontrolle und Self Service:

• Governance = Rahmen + Verantwortlichkeiten + Wiederholbarkeit

• Security = Berechtigungen + Datenzugriffskontrolle (RLS/OLS/CLS)

• Compliance/Schutz = Klassifizierung, DLP, Audit, Nachvollziehbarkeit

Wenn du diese drei sauber trennst, wird Governance plötzlich nicht Bürokratie, sondern Betriebssystem.

Power BI Governance: Zonen-Modell

Du brauchst nicht “entweder total frei oder total streng”. Du brauchst Zonen — also unterschiedliche Grade an Freiheit, abhängig davon, wo etwas lebt und was damit passiert.

Eine einfache Version, die in der Praxis erstaunlich gut funktioniert:

Zone	Zweck	Typische Inhalte	Leitplanke
Sandbox	Ausprobieren, Lernen, Skizzen	persönliche/kleine Team-Reports	kurzlebig, klar als nicht offiziell markiert
Team / Domain	Zusammenarbeit, echte Deliverables	Team-Reports, wiederverwendbare Modelle	Ownership, Namensregeln, minimale Reviews
Managed / Certified	Quelle der Wahrheit	zentrale Semantikmodelle, Kerndashboards	Zertifizierung, Release-Prozess, Monitoring

Das ist der Deal: In der Sandbox maximaler Spielraum, dafür weniger Versprechen. Im Managed-Bereich weniger Wildwuchs, dafür ein offizielles Siegel: Darauf könnt ihr bauen. Und genau hier kommt die Hauptarbeit von Governance her, die nicht aus 47 Regeln besteht, sondern einer klaren Erwartungshaltung entspricht, was offiziell ist und was nicht.

Die 6 Stellen, an denen Power BI ohne Governance teuer wird

1) Vertrauen: Welche Zahl stimmt?

Wenn niemand weiß, welche Kennzahl die richtige ist, generieren Teams ihre eigenen Wahrheiten. Das ist nicht böswillig, das ist Überlebensstrategie. Im Ergebnis führt dies zur Doppelarbeit und Diskussionen statt Entscheidungen.

Governance-Antwort: Endorsement (Promote/Certify) plus eine klare Certified-Linie für Kernmodelle und -Reports. Power BI unterscheidet Promotion (niedrigschwellige Empfehlung) und Certification (nach Standards geprüft, autoritativ).

2) Security-Illusion: Permissions ≠ Datensicherheit

Viele glauben: “Wenn ich Build oder Export abschalte, ist das sicher.” Leider: nein.

Chris Webb beschreibt “Build permission” sehr treffend als primär Discoverability-Feature: Es macht Modelle auffindbar und nutzbar für eigene Reports/Tools. Es ist nützlich zur Steuerung der Report-Proliferation — aber es ist nicht Security.

Governance-Antwort: Für echten Datenzugriff brauchst du RLS/OLS (und je nach Architektur auch OneLake-Security). RLS filtert Zeilen, OLS sperrt Tabellen/Spalten so, dass Abfragen ins Leere laufen bzw. Fehler werfen.

3) Datenabfluss: Export, Teilen, “ich schick’s kurz per Mail”

Hier wird es heikel: Daten verlassen Power BI, landen als Datei irgendwo, und plötzlich gelten ganz andere Regeln.

Governance-Antwort: Sensitivity Labels + DLP. Sensitivity Labels klassifizieren Inhalte in Power BI und sorgen dafür, dass beim Export (Excel/PDF/PowerPoint/PBIX) der Schutz mitwandert. Wichtiges Detail: Im Power BI Service ändern Labels nicht automatisch die Zugriffsrechte auf Inhalte; Schutz greift vor allem beim Verlassen des Service über unterstützte Exportpfade.

4) Modell-Sprawl: 17 Sales-Datasets, alle ähnlich, keines gleich

Wenn jeder ein eigenes Semantikmodell baut, entstehen Parallelwelten. Und irgendwann fragt jemand, warum Umsatz in Team A anders ist als in Team B.

Governance-Antwort: Semantischer Kern (ein paar zentrale Modelle, sauber dokumentiert), darauf aufbauend Self Service per Build und Wiederverwendung - aber gesteuert über Zonen und Endorsement. Genau diese Balance aus Kontrolle und Agilität ist der Kern moderner Power-BI-Governance-Ansätze.

5) Lifecycle & Qualität: “Das hab ich im Desktop geändert — warum ist Prod kaputt?”

Ohne Release-Logik wird Prod zum Experimentierfeld. Das ist kein Power-BI-Problem - das ist ein Prozessproblem, das Power BI nur sichtbar macht.

Governance-Antwort: klare Trennung von Entwicklungs- und Managed-Zone, plus minimaler Review- und Veröffentlichungsprozess (muss kein Monster sein).

6) Betrieb & Transparenz: “Wer hat was geteilt? Wer nutzt das überhaupt?”

Wenn du nicht messen kannst, steuerst du nach Bauchgefühl. Das fühlt sich schnell nach wir schränken ein, weil wir Angst haben an und das ist der schnellste Weg, Self Service zu töten.

Governance-Antwort: Auditing & Activity Log. Power BI bietet Activity Log / Audit-Tracking; viele Events tauchen typischerweise innerhalb von ungefähr 30 Minuten auf (mit möglichem Lag). Das Ziel ist nicht Überwachung — sondern Sichtbarkeit, damit du gezielt verbessern kannst, statt pauschal zu verbieten.

Umsetzung in Power BI: 5 Leitplanken für schnelleren Self Service

Jetzt zum praktischen Teil. Das sind fünf Leitplanken, die ich in fast jeder Umgebung wiedersehen will, weil sie Freiheit ermöglichen, statt sie zu fressen.

1) Workspaces als Produkt - nicht als Ablage

Wenn Workspaces irgendwie entstehen, hast du später keine Chance mehr, Ownership und Verantwortlichkeit sauber zuzuordnen. Power BI Workspaces arbeiten mit Rollen (Admin, Member, Contributor, Viewer). Das klingt banal, ist aber dein Grundgerüst für Governance.

Praxis-Setup (leichtgewichtig, aber wirksam):

• Sandbox: Contributor-lastig, klare nicht offiziell-Markierung (Beschreibung, Naming)

• Team/Domain: Admin/Member klar benannt, Contributors für Entwickler

• Managed: sehr wenige Admins, klare Change-Regeln

Kleiner, aber wichtiger Punkt aus der offiziellen Dokumentation: Selbst Viewer können je nach Setup bestimmte Aktionen (z.B. Analyze in Excel) nur dann sinnvoll nutzen, wenn sie gezielt Build Permission auf dem Semantikmodell bekommen. Das ist Governance in Reinform: nicht du darfst nicht, sondern du darfst - aber auf dem richtigen Modell.

2) Der semantische Kern - ein paar Modelle, auf die alle bauen

Die meisten Organisationen brauchen nicht 200 zertifizierte Modelle. Sie brauchen:

• wenige, stabile Core-Modelle (Umsatz, Finance, HR - je nach Kontext)

• klar dokumentiert: Definitionen, Grain, Refresh, Owner

• wiederverwendbar über Build / Live-Verbindungen

Und dann darf Self Service passieren, aber auf einem Kern, der nicht ständig wackelt. Wenn du das richtig machst, passiert etwas Schönes: Self Service wird leichter. Weil du nicht mehr jedes Mal bei Null anfängst.

Guardrail 3: Sicherheit dort, wo sie hingehört: RLS/OLS (statt “Settings hoffen”)

Tenant Settings sind Feature-Schalter, keine Datensicherheit. Microsoft formuliert das explizit und nennt Export data als Beispiel, das Berechtigungen nicht ersetzt.

Wenn Daten wirklich geschützt sein müssen:

• RLS für Zeilenfilter (wer sieht welche Region/Kunden/etc.)

• OLS für Spalten/Tabellen (z.B. Gehälter, interne IDs)

• und bei Fabric/Direct Lake ggf. zusätzliche Security-Konzepte auf Storage-Ebene

Tabular Editor fasst die Wirkung von RLS/OLS gut zusammen, inkl. der Konsequenz: Wenn ein Benutzer ohne OLS-Rechte indirekt eine gesperrte Spalte über Measures anfasst, schlägt die Abfrage fehl. Das ist unbequem, ja. Aber es ist echte Sicherheit ohne Security-Theater.

4) Labels & Purview: Klassifizieren, dann schützen - und erst dann hart durchgreifen

Viele scheitern, weil sie mit Enforce anfangen. Und dann ist die Akzeptanz sofort tot.

Ein besserer Weg ist eine Progression:

1. Observe: Labels sichtbar machen, Reporting auf Label-Nutzung

2. Classify: Standards definieren (was heißt “Vertraulich” bei euch?)

3. Enforce: DLP/Export-Beschränkungen dort, wo es Sinn macht

In Power BI können Sensitivity Labels beim Export automatisch angewendet und mit Schutz versehen werden. Und Purview ist der Ort, an dem du diese Schutz- und Governance-Mechaniken zusammenziehst (Labels, DLP, Audit, Retention etc.).

Wenn du zusätzlich Governance/Monitoring tiefer im Power-BI-Kosmos brauchst: Tools wie Power BI Sentinel positionieren sich explizit als Ergänzung zu Purview (Purview = Breite im Data Estate, Sentinel = Tiefe in Power BI). Ob du so etwas brauchst, ist eine Reifegradfrage - nicht die Startlinie.

5) Monitoring & Audit als Feedback-Schleife, nicht als Aufsichtsorgan

Governance wird dann nervig, wenn sie nur Regeln ausspuckt, aber nicht lernt. Darum brauchst du eine Feedback-Schleife:

• Welche Reports werden genutzt?

• Welche Modelle sind die Basis für unzählige Artefakte?

• Wo entstehen Duplikate?

• Welche Exporte passieren wirklich?

• Wo schlagen Refreshes fehl?

Power BI stellt dafür Activity Log / Audit-Möglichkeiten bereit; der Activity Log ist über REST API / PowerShell auslesbar, mit bekannten Rahmenbedingungen (z.B. Abruf in Tages-Scheiben, große Datenmengen, Continuation Tokens).

Das Ziel ist nicht, alles zu kontrollieren. Das Ziel ist, gezielt zu steuern:

• Diese zwei Modelle sind faktisch Kern - dann sollten sie auch behandelt werden wie Kern.

• Diese 40 Reports werden nie geöffnet - dann müssen sie nicht governed werden, sondern entsorgt.

Power BI Governance: Operating Model

Du brauchst keine 12-köpfige “BI-Polizei”. Du brauchst klare Rollen, klein gehalten:

• Fabric/Power BI Admin: Plattform-Schalter, Kapazitäten, Tenant Settings, Audit aktivieren

• Domain Owner / Data Owner: fachliche Definitionen (was ist Umsatz?), Prioritäten

• Semantic Model Owner: technische Verantwortung (Modell, Measures, Security, Release)

• Workspace Owner: Ordnung im Workspace, Zugriff, Lifecycle

• Makers: erstellen Reports bevorzugt auf zertifizierten Modellen, sonst in Sandbox/Team-Zone

Der Trick ist: Admins sind Enablement, nicht Entscheidungsinstanz für jedes Detail. Power BI wächst schnell und Governance muss Schritt halten, sonst holt dich der Wildwuchs ein.

Der 30 Tage Startplan: klein anfangen, aber richtig

Wenn du jetzt denkst klingt gut, aber wo starte ich, hier ein pragmatischer 30-Tage-Plan, der nicht alles umkrempelt:

Woche 1 – Zonen & Basics

• Zonen-Modell definieren (Sandbox/Team/Managed)

• Naming-Konvention light (kein Roman)

• Workspace-Ownership festlegen

Woche 2 – Semantischer Kern

• 1–3 Kandidaten für Core Model identifizieren

• Rollen & Build sauber setzen (wer darf konsumieren, wer darf bauen?)

• Security-Prüfung: RLS/OLS dort, wo es nötig ist

Woche 3 – Vertrauen sichtbar machen

• Promotion für gute Inhalte, Certification-Prozess für Kernmodelle aufsetzen

• Modell-Beschreibungen verpflichtend (kurz, aber informativ)

Woche 4 – Schutz & Feedback

• Sensitivity Labels aktiv nutzen (zuerst beobachten, dann schärfen)

• Activity Log / Audit Daten ziehen und ein simples Governance-Dashboard bauen

Wenn du nach 30 Tagen nur das hast, bist du schon weiter als die meisten und vor allem: Du hast einen Happy Path, dem Leute freiwillig folgen, weil er ihnen Arbeit spart.

---

Fazit: Power BI Governance als Beschleuniger mit Leitplanken

Power BI Governance hat ein Imageproblem, weil viele sie als Regelwerk erleben. In Wirklichkeit ist gute Governance ein Produktivitäts-Upgrade:

• Sie macht klar, was vertrauenswürdig ist (Endorsement/Certified).

• Sie trennt Feature-Schalter von echter Sicherheit (Tenant Settings vs. RLS/OLS).

• Sie schützt Daten dann, wenn sie Power BI verlassen – etwa per Export oder Weitergabe.

• Und sie gibt Self Service eine Bühne, auf der man nicht ständig über Kabel stolpert.

Oder kurz: So viel Governance wie nötig, so viel Freiheit wie möglich - nicht als Motto, sondern als Designprinzip.

---

Der nächste sinnvolle Schritt

Power BI entfaltet seinen Nutzen erst dann vollständig, wenn Dashboards sauber aufgebaut, Datenmodelle durchdacht und Kennzahlen klar definiert sind.Genau diese Grundlagen entscheiden darüber, ob Berichte genutzt oder ignoriert werden.

Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich mit:

• Power BI Training – für einen sauberen, praxisnahen Einstieg

• Power BI Coaching – für konkrete Herausforderungen in Modellen, DAX oder Performance

• Data Strategy Check – um eure Analytics-Organisation ganzheitlich einzuordnen

So wird aus einem funktionierenden Bericht eine belastbare Analytics-Lösung.