Governance Proof

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

Sizing: KMU — drei bis fünf KPI-Karten mit Ownern, bevor mehr Visuals gebaut werden. Mid-Market — Interview-Pack plus Mart-Design-Handoff. Enterprise — Portfolio von Proofs mit wiederverwendbaren Card-Templates.

Proof-Governance beginnt nicht mit einem weiteren Pipeline-Dashboard. Sie beginnt mit der Entscheidung, welche Frage „offene Pipeline“ steuert — und welche Karte Grain, Population und Owner bindet, bevor Engineering eine Struktur gießt.

Typische Fragen sind:

• Wer entscheidet was mit „offener Pipeline“ — Eingriff, Forecast-Genauigkeit oder konservative Monatsplanung?; Welcher fachliche Ebene gilt — Opportunity oder Position?; Welche Stage-Filter, Stichtage und Close-Date-Lücken unterscheiden die drei Zahlen?; Welche Definition behält den Namen, welche bekommt einen eigenen?; Welche Artefakte entstehen — Discovery, KPI-Karten, Auswertungstabelle Design Brief?; Wann ist der Proof fertig — nicht wenn das hübscheste Visual steht?

Wenn drei Dashboards denselben Namen tragen und das Monatsmeeting zehn Minuten über die „richtige“ Zahl spricht, sind die Berechnungen oft alle korrekt. Das Problem ist nicht das BI-Tool. Es ist der fehlende Vertrag zwischen Interview, Grain und benannter Karte.

Guter Proof macht den Streit ausführbar — Frage, Grain und Karte am selben Label, nicht am neuesten Report.

Anschluss an Vom Stakeholder-Interview zum Tabellenmodell, Welche Artefakte entstehen? und Salesforce → Mart.

Weiter: Proof: Von der SaaS-Quelle zum freigegebenen Pilotprojekt-Mart.

Die Serie Governance Proof gibt dir den Einstieg und den roten Faden für die folgenden Teile. Die folgenden Teile zeigen denselben Ansatz für eine SaaS-Quelle und für BI-Report-Chaos — als Operating-Beweise, nicht als drei zusätzliche Methodik-Folien.

Ausgangslage

Ein mittelständisches B2B-Vertriebsteam nutzt Salesforce und ein BI-Tool. Vertriebsleitung, Sales Operations und Controlling haben unabhängig Pipeline-Dashboards gebaut. Alle sagen „offene Pipeline“, mit unterschiedlichen Stage-Filtern, Stichtagen und Close-Date-Regeln. Jedes Monatsmeeting verliert zehn Minuten an „welche Zahl stimmt“. Teams bauen dann ein viertes Dashboard oder heften einen Katalog-Badge an — und der Streit bleibt.

Was diese Serie klärt

• Orientierung: Interview, fachliche Ebene-Satz, benannte KPI-Karten, Auswertungstabelle Design Brief (diese Seite)
• Vertiefung: Von der SaaS-Quelle zum freigegebenen Pilotprojekt-Auswertungstabelle
• Abschluss: Vom BI-Report-Chaos zu vertrauenswürdigen Kennzahlen

Begriffe und Kürzel vor dem Lesen

• Proof — anonymisierter Lehrdurchlauf mit Artefakten, die ihr nachbauen könnt — keine Kundenfallstudie.
• Discovery-Pack — Interview trennt Evidenz, Interpretation und Entscheidung; Aussagen werden nicht still zum Modell.
• fachliche Ebene-Satz — eine Zeile wofür (hier: Opportunity, nicht Position), bevor Kennzahlen-Namen fallen.
• KPI-Karte — versionierte Definition mit Formel, fachliche Ebene, Zeitlogik, Filtern, Owner und vorgesehener Entscheidung.
• Auswertungstabelle Design Brief — Business Event, fachliche Ebene, Fact-/Dim-Kandidaten und Snapshot-Bedarf — freigegeben vor Tabellenbau.
• Namensspaltung — eine Definition behält „offene Pipeline“; die anderen heißen Pipeline at Risk und Committed Forecast.

Lesepfad

1. Proof: Vom Stakeholder-Interview zu freigegebenen KPI-Karten
2. Proof: Von der SaaS-Quelle zum freigegebenen Pilotprojekt-Mart
3. Proof: Vom BI-Report-Chaos zu vertrauenswürdigen Kennzahlen

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Dashboard-, CRM- und Rollennamen durch eure Catalog-, BI- und Prozessquellen.

Produkte und Entscheidungen

Proof braucht nicht „ein bereinigtes Dashboard“, sondern geschnittene Produkte.

Discovery-Pack

Dieses Produkt beschreibt:

• wer entscheidet was; drei konkurrierende Sichten; Evidenz versus Interpretation versus Entscheidung; offene Fragen.

Entscheidungen:

• Welche Handlung hängt an welcher Zahl?; Welche Aussage ist Beobachtung, welche schon Modellwunsch?; Wer dokumentiert das Pack — nicht wer das hübscheste Chart hat?

Grain-Satz

Eine Zeile pro Opportunity, nicht pro Position, weil Produktdetails keine der drei Fragen brauchen.

Entscheidungen:

• Welcher fachliche Ebene löst schon einen Teil des Konflikts?; Welche bestehende Sicht aggregiert ungewollt auf Position?; Wann entsteht ein zweiter Fact statt einer Spalten-Erweiterung?

KPI-Karten-Satz

Drei benannte Karten statt einer mehrdeutigen Kennzahl.

Es benötigt:

• Formel; fachliche Ebene-Referenz; Zeitlogik; Filter; verantwortliche Person; Entscheidungsnutzung; Version.

Entscheidungen:

• Welche Definition behält „offene Pipeline“?; Wer ist KPI-verantwortliche Person — hier Sales Operations?; Welche zwei Sichten bekommen eigene Namen statt Kompromissformel?

Mart Design Brief

Grain, Fact-/Dim-Kandidaten, Snapshot-Bedarf.

Entscheidungen:

• Welche Dimensionen braucht der Pipeline-Auswertungstabelle (Account, verantwortliche Person, Stage, Datum)?; Braucht Stage-Bewegung einen Snapshot-Fact?; Wer gibt den Brief frei, bevor Tabellen gebaut werden?

Wo Governance hängt

Zwischen Monatsmeeting und ungetrennter Frage

Zehn Minuten „welche Zahl stimmt“ sind drei ungeklärte Entscheidungen unter einem Namen.

Zwischen Interview-Aussage und Modellspalte

Aussagen direkt als Fact zu gießen kodiert den Streit in die Struktur.

Zwischen Kennzahl-Streit und fehlendem Grain

Ohne Zeilenvertrag landet die Debatte wieder bei „wessen Zahl“, nicht bei „welche Frage“.

Zwischen einem Namen und drei Populationen

Stage-Filter, Stichtag und Close-Date-Lücke sind verschiedene Produkte. Kompromissformel heilt das nicht.

Zwischen KPI-Karte und nächstem Visual

Die Karte regiert Bedeutung. Das Dashboard ist dünner Consumer.

Zwischen Brief und physischem Mart

Ohne freigegebenen Brief baut Engineering konkurrierende Bedeutungen in Tabellen.

Rollen-Mapping

Sales Operations / KPI-Owner

Trifft die Namens- und Definitionsentscheidung. Sales Ops ersetzt nicht die Vertriebsleitung für den Eingriff und nicht Controlling für die konservative Planung.

Vertriebsleitung

Consumer der Eingriffssicht. Darf eine eigene Karte fordern, nicht denselben Namen umdefinieren.

Controlling / Business Analyst

Consumer der Planungszahl. Bekommt Committed Forecast oder einen klaren zweiten Namen.

Analytics Engineer / Custodian

Setzt Brief und Karten um. Implementierungsmacht ist keine KPI-Verantwortung.

Discovery Facilitator / Steward

Führt Interview-Pack und Artefakt-Versionierung. Stewardship braucht Kapazität, nicht die Restzeit zwischen Meeting und Sprint.

Audit / Assurance Consumer

Empfängt Karten und Brief, wo die Zahl später extern wirkt.

Mini-Fall

Symptom: Drei Salesforce-Pipeline-Dashboards, ein Name, unterschiedliche Stage-Filter und Stichtage. Monatsmeeting startet mit zehn Minuten Wahrheitsstreit.

Typischer Fehlstart: Das hübscheste Dashboard wählen oder einen Katalog-Badge an „open pipeline“ heften und weiter Visuals bauen.

Vereinbarung: Discovery nach Stakeholder-Interview → Tabellenmodell; fachliche Ebene eine Zeile pro Opportunity; drei Karten via KPI Requirements Anfrageweg und KPI Definition; Brief via Auswertungstabelle Design Brief Generator vor Tabellenbau.

Aus dem Durchlauf entstanden governance-discovery.md, kpi-cards.csv und mart-design-brief.md — dieselben Dateinamen wie in Welche Artefakte entstehen?.

Hinweis: Diese Story ist ein anonymisiertes, zusammengefasstes Beispiel zur Veranschaulichung der Methodik. Sie ersetzt keine Rechts-, Datenschutz- oder Vendor-Beratung und ist keine Fallstudie eines konkreten Kunden.

Kritische Übergaben

Anti-Patterns

• Viertes Dashboard bauen, bevor Fragen getrennt sind
• Interview-Aussagen still als Modell übernehmen
• Eine Kompromissformel unter einem Namen erzwingen
• KPI-Karten ohne fachliche Ebene-Satz schreiben
• Auswertungstabelle bauen, bevor der Brief freigegeben ist
• Katalog-Badge als Proof behandeln
• Dashboard und KPI-Karte gleichsetzen

Erster Umsetzungsschnitt

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.

• Arbeitsplan — Governance Operations
• Lernpfad — Governance Operations

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.

Schritt 1: Rahmen und Entscheidung klären

Einen wiederkehrenden Namensstreit wählen (Pipeline, Forecast, Bestand). Stakeholder und Entscheidungen listen. Discovery-Pack skizzieren. KPI-Owner benennen.

Schritt 2: Control und Nachweis umsetzen

Grain-Satz schließen. Drei bis fünf Karten versionieren — KMU bleibt in diesem Rahmen. Abweichende Sichten umbenennen, nicht mitteln.

Schritt 3: Testen und Ausnahmen sichtbar machen

Mart Design Brief aus Grain und Karten ableiten. Negativtest: neues Visual ohne Karten-Referenz darf nicht als Proof gelten. Fachliche Abnahme im nächsten Monatsmeeting.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Bestandene Muster in Teil 2 (SaaS-Quelle) oder Teil 3 (BI-Chaos) übertragen.

Exit-Kriterien

• Jede Pilotprojekt-Zahl hat eine benannte Karte mit fachlicher Ebene, Grundgesamtheit, Owner und Entscheidungsnutzung.
• Ein Name bezeichnet eine Definition; die anderen sind umbenannt.
• Discovery-Pack, kpi-cards.csv und Brief existieren vor dem nächsten Auswertungstabelle-Bau.
• Das Monatsmeeting startet bei der Handlung, nicht bei der Wahrheitsdebatte.
• Analytics bleibt technischer Betreiber; Sales Ops bleibt für die Leitdefinition accountable.

Weiterlesen

• Vom Stakeholder-Interview zum Tabellenmodell
• Welche Artefakte entstehen?
• Salesforce → Auswertungstabelle: Körnung, Fakten und KPI-Karten
• KPI Requirements Anfrageweg
• KPI Definition
• Auswertungstabelle Design Brief Generator
• Governance Advisor

Ein Analytics-Team mit drei möglichen ersten Quellen — Salesforce, ein Ticketing-System und ein ERP-Exportordner — musste entscheiden, wo die erste Ingestion beginnt. Diese anonymisierte Story zeigt den Weg von dieser Priorisierungsfrage über eine dokumentierte Load/Skip-Entscheidung bis zu einem freigegebenen Pilotprojekt-Mart, ohne Kundennamen oder reale Zahlen.

Ausgangslage

Das Team hatte begrenzte Kapazität für genau eine vollständige erste Quelle in diesem Quartal. Alle drei Kandidaten hatten Fürsprecher: Salesforce war am sichtbarsten für die Geschäftsführung, das Ticketing-System hatte die „sauberste“ API, und der ERP-Export war bereits als Datei verfügbar. Bequemlichkeit allein sollte aber nicht die Entscheidung treiben.

Zusätzlich bestand Unsicherheit über den Umfang: Eine frühere, informelle Diskussion hatte vorgeschlagen, „einfach alle Salesforce-Objekte“ zu laden, um spätere Nacharbeit zu vermeiden — ohne zu klären, welche Objekte tatsächlich einen Analytics-Zweck hatten.

Schritte

1. Portfolio-Entscheidung statt Bauchgefühl. Mit der Methodik aus Welche Quelle zuerst laden? wurden alle drei Kandidaten nach Decision Value und Source Readiness getrennt bewertet. Salesforce gewann nicht wegen der Sichtbarkeit, sondern weil eine benannte Entscheidung — Pipeline-Steuerung nach Stage und Owner — bereits klar formuliert war und Verantwortung, Zugriff und Grain-Wissen vorhanden waren.

2. Skip-Muster generisch vorab prüfen. Bevor objektspezifisch entschieden wurde, nutzte das Team SaaS-Exporte: Tabellen, die man nicht laden sollte, um die generischen Kategorien zu kennen: UI-Caches, doppelte Snapshots, umfangreiche Audit-Logs und unbeschränkter Freitext sollten unabhängig vom Hersteller kritisch geprüft werden.

3. Salesforce-Objekte klassifizieren. Mit Welche Salesforce-Tabellen für Analytics laden wurden Opportunity, Account und User als Must-have eingestuft, Contact als Conditional mit Feld-Allowlist, und Task/Event sowie Notizen und Anhänge bewusst zurückgestellt, weil kein benannter Aktivitäts-Use-Case existierte.

4. Source Scope dokumentieren. Der Source Scope Builder hielt für jedes Objekt Zweck, Beitrag zum Grain, Zeitbedarf, PII-Risiko und Entscheidung fest — inklusive der explizit ausgeschlossenen Objekte und ihres Review Triggers.

5. PII vor dem Load klassifizieren. Für Contact- und User-Felder lieferte der PII Recommend Generator eine erste Risikoeinschätzung. Freitextfelder aus Task und Event blieben außerhalb des Scopes, bis ein Owner einen konkreten Zweck benennt.

6. Vom Scope zum Mart. Mit dem freigegebenen Scope folgte das Team Salesforce → Mart: Grain, Fakten und KPI-Karten: Opportunity-Grain wurde als primärer Grain gewählt, Fact- und Dimension-Kandidaten benannt und die Standard-Pipeline-KPIs als Karten erfasst.

7. Mart Design Brief freigeben. Der Mart Design Brief Generator verband Source Scope und KPI-Karten zu einem Brief mit Grain, Historienverhalten und Scope-Out, bevor die erste physische Tabelle gebaut wurde.

Artefakte

• source-scope.csv — Salesforce-Objekte mit Decision (Include/Defer/Exclude), Begründung und Review Trigger.
• kpi-cards.csv — Pipeline Value, Win Rate und Average Deal Size als versionierte KPI-Karten auf Opportunity-Körnung.
• mart-design-brief.md — fachliche Ebene, Fact-/Dimension-Kandidaten und Umfang-Out für das Pilotprojekt-Auswertungstabelle, freigegeben vor dem Tabellenbau.

Die vollständige Liste der Standard-Dateinamen steht in Welche Artefakte entstehen?.

Lernerfolg

Der wichtigste Effekt der Portfolio-Entscheidung war, dass Salesforce nicht „weil es sichtbar ist“, sondern mit einer dokumentierten Begründung gewann — inklusive der zwei zurückgestellten Kandidaten mit klaren Prerequisites für eine spätere Bewertung. Das machte die Entscheidung für alle drei Fürsprecher nachvollziehbar, auch für die, deren Quelle nicht zuerst startete.

Der zweite Lernpunkt betraf den Scope selbst: Ohne die Objekt-für-Objekt-Klassifikation wäre wahrscheinlich der ursprüngliche Vorschlag „alle Objekte laden“ umgesetzt worden. Der freigegebene Scope reduzierte die tatsächlich geladenen Objekte deutlich, ohne dass das Pilotprojekt-Mart dadurch etwas verlor — der Grain brauchte diese Objekte schlicht nicht.

Hinweis: Diese Story ist ein anonymisiertes, zusammengefasstes Beispiel zur Veranschaulichung der Methodik. Sie ersetzt keine Rechts-, Datenschutz- oder Vendor-Beratung und ist keine Fallstudie eines konkreten Kunden.

Tools und nächste Schritte

• Source Umfang Builder — Objekte, Felder und Beziehungen als source-scope.csv dokumentieren.
• personenbezogene Daten Recommend Generator — Feldrisiko vor dem Load klassifizieren.
• KPI Definition — Standard-KPIs als kpi-cards.csv versionieren.
• Auswertungstabelle Design Brief Generator — fachliche Ebene, Fakten und Umfang-Out als mart-design-brief.md freigeben.
• Unsicher, welche Quelle zuerst dran ist? Der Governance Advisor führt durch die Priorisierung — für Projektstart Goal Projekt-Delivery und Lernpfad Governance Project Anfrageweg.
• Pilotprojekt-Muster generalisiert: Pilotprojekt Delivery Pattern.

Verwandte Playbooks

• Welche Quelle zuerst laden? — die Portfolio-Methodik hinter Schritt 1.
• SaaS-Exporte: Tabellen, die man nicht laden sollte — die generischen Skip-Muster hinter Schritt 2.
• Welche Salesforce-Tabellen für Analytics laden — die vollständige Objektklassifikation hinter Schritt 3.
• Salesforce → Auswertungstabelle: Körnung, Fakten und KPI-Karten — der Guide hinter Schritt 6 und 7.
• Unbekannte Quelle — wer hilft, personenbezogene Daten, Qualität — Erstkontakt-Protokoll, bevor der Proof startet.

Teil 3 dieser Serie zeigt, wie ein bestehendes Report-Chaos in vertrauenswürdige, zertifizierte Kennzahlen überführt wird.

Ein Reporting-Team entdeckte im Rahmen einer Qualitätsprüfung, dass der Begriff „Nettoumsatz“ in mindestens sieben verschiedenen Reports, Semantic Models und einer Excel-Arbeitsmappe vorkam — mit unterschiedlichen Werten. Diese anonymisierte Story zeigt den Weg von diesem Fund über ein strukturiertes Report-Inventar bis zu einer zertifizierten, wiederverwendbaren Kennzahl.

Ausgangslage

Die Organisation nutzte Power BI für Executive-Reporting, Qlik für operative Vertriebsanalysen und eine gepflegte Excel-Arbeitsmappe im Controlling. Alle drei Umgebungen enthielten eine Kennzahl namens „Nettoumsatz“. Bei einem Zahlenabgleich vor einem Quartalsabschluss fielen Abweichungen auf, die zunächst niemand erklären konnte — die Formeln sahen in jedem Tool unterschiedlich aus, weil jede BI-Engine Filterkontext anders ausdrückt.

Der reflexartige erste Vorschlag lautete, „einfach eine Formel zu kopieren“. Das Team entschied sich stattdessen für eine systematische Aufarbeitung.

Schritte

1. Report-Inventar statt Formelvergleich per Zuruf. Mit der Methodik aus Vom Report Inventory zur vertrauenswürdigen Kennzahl wurden alle sieben Implementierungen erfasst: Plattform, Ausdruck, Basisgranularität, Filter, Zeitverhalten, Owner und Nutzung. Bereits diese Erfassung zeigte, dass zwei der sieben Varianten exakte Kopien waren, drei syntaktisch unterschiedlich, aber semantisch gleich, und zwei tatsächlich unterschiedliche fachliche Definitionen (brutto versus netto nach Stornos).

2. Cluster bilden und vergleichen. Die Kandidaten wurden nach Geschäftsfrage, Population, Grain, Aggregation, Zeitlogik und Owner-Bereitschaft verglichen, statt nach vermeintlicher Ähnlichkeit der Formel. Die am häufigsten genutzte Variante erwies sich dabei nicht automatisch als die fachlich korrekte.

3. Platzierung entscheiden. Mit Semantic Layer vs Measure im Report wurde geklärt, welcher Teil der Logik ins Warehouse gehört (Stornobehandlung, Währungsstandardisierung), welcher in die semantische Schicht (freigegebene Aggregation, Zeitverhalten) und welcher als report-lokale Variante bestehen bleiben darf (Anteil an der aktuell ausgewählten Gesamtsumme in einem Vertriebsdashboard).

4. Owner-Entscheidung einholen. Ein benannter Metric Owner aus Finance genehmigte eine einzige kanonische Definition für „Nettoumsatz“ und ordnete den zwei abweichenden Definitionen neue, eindeutige Namen zu, statt sie unter demselben Label weiterlaufen zu lassen.

5. Implementierung kontrolliert generieren. Für die genehmigte Definition wurden mit Wann BI-Formel-Generatoren der Governance helfen Implementierungen für Power BI und Qlik erzeugt — auf Basis eines vollständigen Metrikvertrags, nicht einer vagen Anforderung. Referenzergebnisse und Toleranzen wurden vorab festgelegt.

6. Parallel abgleichen und migrieren. Beide generierten Implementierungen wurden gegen dieselben Testszenarien reconciled, bevor produktive Reports migriert wurden. Die Excel-Arbeitsmappe blieb als Analyseoberfläche bestehen, bezieht die Kernzahl aber seither aus dem freigegebenen Semantic Model statt aus einer eigenen Formel.

7. Verbleibende Lücken prüfen. Mit The Missing Pieces of Trusted Metrics prüfte das Team abschließend, ob Definition, Verantwortung, Qualität und Zertifizierung tatsächlich für vertrauenswürdige Nutzung ausreichten, oder ob eine der sieben Varianten weiterhin unentdeckt im Umlauf war.

Artefakte

• Trusted Metric Candidate Record — eine Zeile pro Metrikfamilie mit gefundenen Implementierungen, Vergleichsergebnis und Entscheidung der verantwortlichen Person (zertifizieren, konsolidieren, deprecaten).
• Metric Einstiegsangebot Decision — dokumentiert, welche Logik im Warehouse, in der semantischen Schicht und report-lokal lebt.
• kpi-cards.csv — die genehmigte „Nettoumsatz“-Definition sowie die beiden neu benannten Varianten, versioniert als KPI-Karten.
• Formula Generation Request and Validation Record — Input-Vertrag, generierte Formeln, Abgleich-Ergebnis und Freigabe für Power BI und Qlik.

Die gemeinsamen Dateinamen für KPI-Karten und weitere Standard-Artefakte stehen in Welche Artefakte entstehen?.

Lernerfolg

Der zentrale Lernpunkt war, dass technische Gültigkeit keine semantische Äquivalenz beweist: Zwei Formeln können in einer Stichprobe denselben Wert liefern und trotzdem unterschiedliche Bedeutungen haben, sobald sich Filterkontext oder Zeitraum ändern. Erst der strukturierte Vergleich auf Ebene von Population, Grain und Zeitlogik machte sichtbar, dass zwei der sieben Varianten tatsächlich unterschiedliche Geschäftsfragen beantworteten.

Der zweite Lernpunkt betraf die Rolle der Formelgeneratoren: Sie beschleunigten die Implementierung für zwei Plattformen erheblich, ersetzten aber an keiner Stelle die Owner-Entscheidung über Bedeutung, Grain oder Zertifizierung.

Hinweis: Diese Story ist ein anonymisiertes, zusammengefasstes Beispiel zur Veranschaulichung der Methodik. Sie ersetzt keine Rechts-, Datenschutz- oder Vendor-Beratung und ist keine Fallstudie eines konkreten Kunden.

Tools und nächste Schritte

• Report Inventory — Formeln, Grains und Widersprüche über Plattformen hinweg erfassen.
• KPI Definition — die genehmigte Definition als kpi-cards.csv versionieren.
• Power BI DAX Kennzahl Generator und Qlik Set Analysis Generator — kontrollierte Implementierungen aus dem genehmigten Vertrag erzeugen.
• Unsicher, ob ein Report-Inventar oder direkt eine Platzierungsentscheidung der richtige nächste Schritt ist? Der Governance Advisor hilft bei der Einordnung.

Verwandte Playbooks

• Vom Report Inventory zur vertrauenswürdigen Kennzahl — die Methodik hinter Schritt 1 und 2.
• Kennzahlenmodell vs Kennzahl im Report — die Platzierungsentscheidung hinter Schritt 3.
• Wann BI-Formel-Generatoren der Governance helfen — die Grenze zwischen genehmigter Bedeutung und generierter Syntax hinter Schritt 5.
• The Missing Pieces of Trusted Metrics — die abschließende Prüfung hinter Schritt 7.

Diese Story schließt die dreiteilige Proof-Serie ab: von Stakeholder-Interviews über eine SaaS-Quelle bis zu vertrauenswürdigen Kennzahlen — jeweils mit denselben Standard-Artefakten.