Governance Proof

Begriffe 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 Zählebene-Satz — eine Zeile wofür (hier: Opportunity, nicht Position), bevor Kennzahlen-Namen fallen.
• KPI-Karte — versionierte Definition mit Formel, fachliche Zählebene, Zeitlogik, Filtern, Owner und vorgesehener Entscheidung.
• Auswertungstabelle Design Brief — Business Event, fachliche Zählebene, 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.

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?

Bezugs- und Detailebene-Satz

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

Entscheidungen:

• Welcher fachliche Zählebene 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 Zählebene-Referenz; Zeitlogik; Filter; verantwortliche Person; Entscheidungsnutzung; Version.

Entscheidungen:

• Welche Definition behält „offene Pipeline“?; Wer ist für die Kennzahl verantwortliche Person — hier Sales Operations?; Welche zwei Sichten bekommen eigene Namen statt Kompromissformel?

Mart Design Brief

Bezugs- und Detailebene, 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 Bezugs- und Detailebene

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

Alltagssituation: Drei Salesforce-Pipeline-Dashboards tragen denselben Namen. Sie nutzen aber unterschiedliche Stage-Filter und unterschiedliche Stichtage. Das Monatsmeeting startet deshalb nicht mit Entscheidungen, sondern mit der Frage, welche Zahl gilt.

Was schiefläuft: Die Visualisierung ist nicht das Problem. Es fehlt die KPI-Karte, die sagt, wofür die Zahl genutzt wird, welche Verkaufschance zählt, welcher Stichtag gilt und wer die Definition ändern darf.

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 Zählebene-Satz schreiben
• Auswertungstabelle bauen, bevor der Brief freigegeben ist
• Katalog-Badge als Proof behandeln
• Dashboard und KPI-Karte gleichsetzen

Erster Umsetzungsschnitt

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung 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 verantwortliche Personen, 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 echten 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

Bezugs- und Detailebene-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 Bezugs- und Detailebene 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 Entscheidungsnutzen und Quellenreife getrennt bewertet. Salesforce gewann nicht wegen der Sichtbarkeit, sondern weil eine benannte Entscheidung — Pipeline-Steuerung nach Phase und verantwortlicher Person — bereits klar formuliert war und Verantwortung, Zugriff sowie die benötigte Detailebene bekannt 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. Quellenumfang dokumentieren. Der Source Scope Builder hielt für jedes Objekt Zweck, Beitrag zur benötigten Detailebene, zeitliche Anforderungen, Risiko personenbezogener Daten und Entscheidung fest — einschließlich der ausdrücklich ausgeschlossenen Objekte und des Anlasses für eine erneute Prüfung.

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 Umfang zur Auswertungstabelle. Mit dem freigegebenen Umfang folgte das Team Salesforce → Mart: Bezugs- und Detailebene, Fakten und KPI-Karten: Eine Zeile je Verkaufschance wurde als primäre Detailebene gewählt, Fakten und beschreibende Dimensionen wurden benannt und die zentralen Vertriebskennzahlen als Karten erfasst.

7. Mart Design Brief freigeben. Der Mart Design Brief Generator verband Source Scope und KPI-Karten zu einem Brief mit Bezugs- und Detailebene, 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 Zählebene, 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 Bezugs- und Detailebene 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 Zählebene, 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, Bezugs- und Detailebene, 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, Bezugs- und Detailebene 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, Bezugs- und Detailebene 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.