Proof: Vom Stakeholder-Interview zu freigegebenen KPI-Karten

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.

Im verlinkten Arbeitsplan hältst du fest, wer die einzelnen Aufgaben übernimmt, bis wann sie erledigt werden und welche Entscheidungen noch offen sind.

• 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