Warum BI-Publish Governance bricht
Workspace-Administrator ist nicht Data Owner und ein zertifizierter Report ist kein Kennzahlvertrag — Publish braucht Stage, Artefakt und ein A je Entscheidung.
BI-Publish-Governance beginnt nicht mit einem Tenant-Häkchen. Sie beginnt mit der Entscheidung, wo ein Artefakt veröffentlicht werden darf, wer promoviert und wer sieht — getrennt von der Kennzahlendefinition.
Typische Fragen sind:
- Wer darf aus einem Personal Workspace in Produktion heben?; Ist „steht im Produktions-Workspace“ eine Freigabe?; Wer besitzt Refresh und Credentials?; Wo lebt die Berechtigungsmatrix, wenn Power BI, Tableau und Qlik dieselben Regionen filtern?; Wann ist ein Zertifizierungslabel ein Vertrag — und wann nur UI?
Nicht diese Serie, wenn du noch entscheidest, ob die Formel im Semantic oder im Report lebt — BI-Governance-Entscheidungen — oder die Matrix als Steuerdaten-Produkt baust — Berechtigungsmatrizen und Section Access. Fabric als Vendor-Start bleibt Microsoft Fabric als Governance-Einstieg.
Wenn in der Praxis „steht im Prod-Workspace“ als Freigabe gilt, entscheidet der Workspace-Admin die Unternehmenszahl. Das Problem ist nicht fehlende Endorsement-Klicks. Es ist der fehlende Operating-Vertrag zwischen Stage, Artefakt-Typ und einem A je Entscheidung.
Gute Publish-Governance macht den Pfad ausführbar — Stage, Promotion, Refresh und Reduktion als Produkte, nicht als Ordnernamen.
Die Serie BI-Publish Deep Dive gibt dir den Einstieg und den roten Faden. Die folgenden Teile vertiefen Promotion-Gates, Refresh/Gateway und Berechtigung-Durchsetzung so, dass Zweck, Rollen, Entscheidungen und Nachweise im Alltag nachvollziehbar bleiben.
Ausgangslage
In der Praxis zeigt sich das so: Finance hat Nettoumsatz im Mart auf 12,4 Mio. gebunden. Ein Builder veröffentlicht denselben Power-BI-Report aus dem Personal Workspace „weil Prod voll ist“. Das Board liest die Personal-Zahl. Ein Zertifizierungslabel steht auf einem anderen Semantic. IAM-Rezert ist grün. Drei Apps reduzieren Regionen unterschiedlich. Führung fragt, welche Zahl und welche Sicht gelten.
Was diese Serie klärt
- Orientierung: Veröffentlichungspfad als Operating-Vertrag; Workspace-Administrator ≠ Data Owner; zertifizierter Report ≠ Kennzahlvertrag (diese Seite)
- Vertiefung: Workspace, Stage und Produktfreigabe-Gates
- Vertiefung: Refresh, Gateway und Credential-Verantwortung
- Vertiefung: BI erzwingt die Matrix, besitzt sie nicht
- Abschluss: Ein Matrix-Schlüssel, N Tool-Adapter
Lesepfad
- Warum BI-Publish Governance bricht
- Workspace, Stage und Promotion-Gates
- Refresh, Gateway und Credential-Verantwortung
- BI erzwingt die Berechtigungsmatrix
- RLS, OLS und Tool-Reduktion-Maps
Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Workspace-, App- und Toolnamen durch eure Catalog-, BI- und Prozessquellen.
Begriffe vor dem Lesen
- Publish — Freigabe und Bereitstellung eines BI-Produkts für Nutzung.
- Workspace / Stage — Arbeits- oder Veröffentlichungsbereich für Entwicklung, Test und produktive Nutzung.
- Refresh — Aktualisierung von Datenmodell, Kennzahlenmodell oder Reportdaten.
- Berechtigung — Berechtigung, welche Person welche Daten oder Flächen nutzen darf.
- RLS / OLS — Row-Level- und Object-Level-Security; Zugriff auf Zeilen oder Objekte im BI-Modell.
Produkte und Entscheidungen
Die Landschaft braucht nicht „einen Tenant sauber“, sondern geschnittene Publish-Produkte.
Publish-Vertrag
Dieses Produkt beschreibt:
- Artefakt-Typ (Workspace / App / semantisches Modell / Report); erlaubte Stage; wer heben darf; welcher fachliche verantwortliche Person die Freigabe trägt; Review-Datum.
Entscheidungen:
- Welche Artefakte dürfen in Produktion stehen?; Wer ist A für Heben vs. A für Bedeutung?; Wann ist ein Personal-Publish ein Incident?
Stage-Register
Dev, Test, Prod — oder Personal, Shared, zertifiziert — als Gate, nicht als Ordnerfarbe.
Entscheidungen:
- Welche Stage darf Board-Packs speisen?; Welcher Negativtest gilt vor Produktfreigabe?; Wer darf Stage-Zwecke umbenennen?
Refresh- und Reduktion-Anschluss
Refresh und wer die Zeile sieht gehören zum Publish, nicht als Nachgedanke.
Entscheidungen:
- Wer besitzt Credentials und Gateway?; Welche Matrix erzwingt die App — und wo ist sie System of Record?
Wo Governance hängt
Zwischen Workspace-Administrator und Data Owner
Admin-Rechte am Workspace sind Custodian-Arbeit. Semantik, Zweck und Freigabe bleiben beim fachlichen Owner.
Zwischen Zertifizierungslabel und Kennzahlvertrag
Endorsement macht auffindbar. Grain, Population und Evidence leben im KPI-Vertrag, nicht im Badge.
Zwischen Personal Speed und Board-Pack
„Nur schnell teilen“ wird zur Wahrheit, sobald Steuerung denselben Link öffnet.
Zwischen Tenant-Setting und Policy
Ein Tenant-Häkchen ist keine Zweckbindung, keine Retention und keine Rezert der Reduktion.
Zwischen App, Workspace, Semantic und Report
Vier Objekte, oft ein Name. Ohne Typ im Vertrag promoviert das falsche Artefakt.
Zwischen Refresh-Stille und Decision Cadence
Ein grünes Badge auf gestrigen Zahlen ist kein Operating.
Rollen-Mapping
Data Owner (Fachlichkeit)
Head of Finance oder benannter Process Owner gibt Bedeutung, Nutzung und Promotion in den Board-Kreis frei. Layout und Workspace-Rechte sind nicht dieses A.
Data Steward
Triagiert Publish-Incidents, pflegt das Stage-Register, eskaliert Personal-zu-Prod-Drift.
Data Product Owner
Priorisiert, welches Semantic oder welche App den Veröffentlichungspfad zuerst bekommt. Nutzen und Lieferbarkeit — nicht die fachliche Definition.
Data Architect
Schützt Artefakt-Typen und Lineage Mart → Semantic → App. Breaking Changes an Consumer-Schnittstellen.
Data Custodian
BI-Admin und Plattformbetrieb setzen Workspace, Gateway, Labels und fail-closed Durchsetzung um. Lizenzverwaltung ist keine Semantikhoheit.
Report- / BI-Builder
Liefern Thin-Consumers auf dem freigegebenen Pfad. Sie heben nicht still von Personal nach Prod.
Mini-Fall
Symptom: Der Nettoumsatz ist in einer freigegebenen Auswertungstabelle definiert. Der Vorstand liest aber einen Bericht aus einem persönlichen Arbeitsbereich. Ein anderes semantisches Modell trägt das Label „zertifiziert“. Drei Apps zeigen unterschiedliche Regionen.
Typischer Fehlstart: Tenant-Zertifizierung einschalten und alle Produktions-Workspaces als „governed“ labeln, ohne Stufen-Prüfpunkt, ohne Aktualisierungsverantwortung und ohne führende Berechtigungsmatrix.
Vereinbarung: Ein Veröffentlichungspfad für ein semantisches Modell und eine App; Stufen-Prüfpunkt vor Board; technischer Betreiber setzt um; Data Owner gibt frei; Reduktion kommt aus dem Berechtigungsprodukt.
Kritische Übergaben
| Von | An | Artefakt |
|---|---|---|
| Data Owner | Steward | Freigabe: dieses Artefakt darf Board speisen |
| Steward | Custodian | Publish-Vertrag (Stage, Typ, A) |
| Builder | Steward | Promotion-Antrag Personal/Dev → Prod |
| Custodian | Steward | Inventory: Artefakte ohne Vertrag in Prod |
| Steward | Data Owner | Incident: Board liest Personal oder stale Refresh |
Anti-Patterns
- Workspace-Administrator als Data Owner behandeln
- Zertifizierungslabel ohne fachliche Ebene, Owner und Nachweis
- Personal Workspace als Produktion-Quelle für Steuerung
- Tenant-Setting mit Richtlinie verwechseln
- App, Workspace, semantisches Modell und Report in einem „Ordner“ mergen
- Refresh und Reduktion erst nach dem Launch klären
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
- Ein Semantic und eine App wählen, die bereits steuern.
- Publish-Vertrag schreiben: Stage, Artefakt-Typ, A für Heben, A für Bedeutung.
- Personal- und Prod-Kopien inventarisieren; Board-Quelle benennen.
- Refresh-Owner und Reduktion-Quelle in einem Satz festhalten — Vertiefung in Teil 3–5.
Exit-Kriterien
- Vorstandsbericht speist nur aus einem benannten Stage-Artefakt.
- Workspace-Administrator ist technischer Betreiber, nicht Data Owner.
- Zertifizierungslabel verweist auf einen Kennzahlvertrag, ersetzt ihn nicht.
- Produktfreigabe Personal/Dev → Produktion braucht Antrag und Freigabe durch die verantwortliche Person.
Weiterlesen
- Nutzer-Stufen und gemeinsames Modell
- Gemeinsames Modell für alle Nutzer-Stufen
- Kennzahlenmodell vs Kennzahl im Report
- Fabric / Power BI Metric Certification
- Berechtigungsmatrizen und Section Access
- Dashboard Design Operating Checklist
- Dashboard- und Report-Design Deep Dive
BI publish deep dive
Part 1 of 5
View series