Semantic-Layer-Verantwortung RACI über Tools
RACI für Semantic Layer und Metrics Store über mehrere BI-Tools: Data Owner, Steward, Custodian, Data Product Owner.
Begriffe vor dem Lesen
- Metric Drift — Auseinanderlaufen derselben Kennzahl ueber Tools, Reports oder lokale Formeln hinweg.
- Kanonische Definition — Verbindliche Beschreibung von Grundgesamtheit, fachliche Ebene, Formel, Zeitlogik und Ausschluessen.
- Metrics Store — Wiederverwendbarer Ablage- oder Publish-Ort für freigegebene Kennzahlenlogik.
- Abgleich — Nachweisbarer Vergleich mehrerer Implementierungen gegen dieselbe genehmigte Definition.
- Change Prüfpunkt — Pruefpunkt vor Aenderungen an Formel, Umfang, Quelle oder Publish-Ort.
Wenn Power BI, Tableau, Qlik und ein Metrics Store dieselbe Kennzahl anbieten, braucht es ein RACI — sonst entscheidet der Lauteste im Chat. Kein Tool ist der Owner; der Business-Owner ist es.
Dieser Teil legt fest, wer Semantik freigibt, wer Anträge triagiert und wer nur deployed — über alle Consumer-Tools hinweg.
Vorher: Metrikdefinition und Versionierung. Weiter: Change Gates. Nachbarn: BI-Governance-Entscheidungen, Consumer Shared Model.
Entscheidung
Für die Semantic-/Metrics-Fläche gilt:
- R — Steward pflegt Anträge, Mapping und Triage;
- A — Data Owner (Business) genehmigt Semantik und Publish;
- C — Data Product Owner, Privacy, Finance (je Metrikfamilie);
- I — Dashboard-Autoren und Consumer bei Versionwechseln;
- Custodian führt technische Umsetzung aus (R für Deploy, nicht A für Semantik).
Technical Owner ist kein Ersatz für A.
Workflow
1. Metrikfamilien schneiden
Der Data Owner schneidet Familien wie Revenue, Funnel oder Supply so, dass genau eine Person A trägt. Artefakt ist eine einseitige Familienkarte mit Owner, Steward und Consulted — nicht eine globale KPI-Kommission ohne Entscheidungsdruck. Der Steward hält die Karte aktuell, wenn Metriken wandern. Wird der Schnitt übersprungen, konkurrieren Tool-Teams um dieselbe Zahl, und Versionierung aus Teil 2 hat keinen Freigeber.
2. Tool-Rollen klären
Jedes BI-Tool bekommt benannte Custodians für Anbindung, Workspace und Deploy. Sie setzen die freigegebene Definition um; sie entscheiden sie nicht. Der Steward verteilt Deploy-Aufträge pro Tool und verhindert lokale „Verbesserungen“ der Formel. Fehlt diese Trennung, entsteht je Tool ein stilles A, und Cross-Tool-Reconciliation vergleicht verschiedene Wahrheiten.
3. Shared Model respektieren
Capability Tiers und Consumer-Rechte aus dem Shared Model legen fest, wer Measures lokal erweitern darf und was als Abweichung gilt. Der Data Product Owner benennt erlaubte Overrides; der Owner bleibt A für die Kernsemantik. Der Steward dokumentiert jede lokale Erweiterung mit Ablauf. Wird das ignoriert, werden Dashboard-Maßnahmen zur zweiten Definition, und zertifiziert driftet ohne Versionsbump.
4. Eskalation
Konflikte zwischen Tools laufen Steward → Owner, nicht Chat → Lautester. Artefakt ist ein Eskalationspaket mit beiden Definitionen, Consumer-Impact und Timeout. Läuft die Frist ab, gilt der dokumentierte Default des Owners — nicht der letzte Kommentar. Ohne Timeout und Default bleibt Drift der Dauerzustand, und Change-Gates haben keine Autorität.
5. RACI sichtbar machen
RACI steht kurz im Metrik-Contract und ist aus dem Catalog verlinkt — erreichbare Personen, keine 40-Zeilen-Matrix-Folie. Der Steward prüft Quartalsweise, dass Owner und Custodians noch antworten. Fehlt Sichtbarkeit oder Erreichbarkeit, ist das Catalog-Feld „owner“ Labeling, und niemand kann Publish oder Ausnahme zeichnen.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Data Owner | Steward | A-Freigabe Semantik |
| Steward | Custodian (je Tool) | Deploy-Auftrag |
| Data Product Owner | Steward | Consumer-Impact |
| BI Author | Steward | Änderungs-/Override-Antrag |
| Steward | Owner | Eskalationspaket |
Anti-Patterns
- „Das BI-Team owned alle KPIs“
- RACI nur auf dem Papier, Chat entscheidet live
- Jedes Tool mit eigenem A für dieselbe Metrik
- technischer Betreiber als heimlicher A
- Catalog-Rolle „owner“ ohne erreichbare Person
- Kein Tool ist A für Semantik — Haltung: Komponieren, nicht mergen
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.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- RACI für eine Metrikfamilie auf eine Seite bringen.
- Tool-Custodians benennen (ohne ihnen A zu geben).
- Einen Konfliktfall mit Timeout durchspielen.
- Catalog-Links auf Owner/Steward aktualisieren.
Semantic layer and metrics store governance
Part 3 of 5
View series