Decision before the dashboard

Begriffe vor dem Lesen

KPI / Kennzahl — Messgröße für eine fachliche Entscheidung; nicht nur eine Formel in einem Report.
Kennzahlenverantwortliche Person — Fachliche Rolle, die Bedeutung, Umfang und erlaubte Nutzung einer Kennzahl verantwortet.
fachliche Ebene / Koernung — Die Einheit, ueber die gerechnet wird, zum Beispiel Auftrag, Position, Kunde, Tag oder Monat.
Kennzahlenmodell — Schicht, in der freigegebene Kennzahlenlogik wiederverwendbar bereitgestellt wird.
Nachweis — Nachweis, dass Definition, verantwortliche Person, Quelle, Formel und Nutzung abgestimmt sind.

„Wir brauchen eine Umsatz-KPI“ klingt nach einer klaren Anforderung. Im Workshop folgen jedoch fünf Fragen: Gebucht oder fakturiert? Brutto oder netto? Auftragseingang oder Leistung? Welche Währung? Welcher Abschlussstand? Wer jetzt direkt ein Chart baut, versteckt ungeklärte Entscheidungen in SQL und Filtern.

Der bessere Start ist ein Entscheidungssatz und ein Mini-Contract. Beide sind klein genug für einen Workshop, aber präzise genug, um Scheineinigkeit sichtbar zu machen.

← Vorheriger Teil · Nächster Teil →

Einfach gesagt

Entscheidung: Schneidet die Anforderung als Verb + Objekt + Grenze und ergänzt Auslöser, Owner und Handlung.

Ergebnis: Das Team weiß, welche Definition benötigt wird und wann zwei ähnlich benannte Anforderungen tatsächlich zwei Kennzahlen sind.

Vom Wunsch zum Entscheidungssatz

Die Formel Verb + Objekt + Grenze zwingt zur fachlichen Präzision:

Verb: Was soll entschieden, priorisiert, freigegeben oder gestoppt werden?
Objekt: Worauf richtet sich die Handlung—Region, Produkt, Kunde, Auftrag?
Grenze: Für welchen Zeitraum, Status, Schwellenwert und Geltungsbereich gilt sie?

Aus „Churn anzeigen“ wird:

Priorisiere Kundenbindungsmaßnahmen für Vertragskohorten, wenn die monatliche Kündigungsquote im rollierenden 90-Tage-Fenster über vier Prozent liegt.

Jetzt lassen sich Definition, Datenbedarf, Aktualität und Consumer bestimmen. Ohne diesen Satz bleibt jede Formel plausibel und keine überprüfbar.

Der Mini-Contract

Ein Mini-Contract ist kein 20-seitiges Konzept. Eine Seite oder ein strukturiertes Intake reicht, wenn folgende Felder verbindlich sind:

Feld	Leitfrage
Name und Zweck	Welche Entscheidung unterstützt die Kennzahl?
Fachliche Definition	Welches Ereignis zählt, welches nicht?
Formel und Grain	Wie wird aggregiert, auf welcher Ebene?
Zeit und Status	Eventzeit, Buchungszeit oder Berichtsstand?
Owner (A)	Wer darf Definition und Grenzen freigeben?
Consumer-Tier	Operativ, analytisch, Executive oder extern?
Schwelle	Welche Abweichung löst welche Handlung aus?
Ausnahmen	Welche Sonderfälle sind bekannt und akzeptiert?
Review	Wann und durch wen wird neu bewertet?

KPI definieren vertieft den Contract. Das KPI Requirements Intake Tool hilft, Anforderungen vor dem Umsetzungs-Backlog zu qualifizieren.

Durchgearbeitetes Beispiel: Sales und Finance

Sales verlangt „Monatsumsatz“ für die Steuerung der Pipeline. Finance verlangt „Monatsumsatz“ für den Abschluss. Ein gemeinsamer Name täuscht Konsens vor.

Sales-Entscheidung: Wenn der Wert bestätigter Neuaufträge im Monat unter 90 Prozent des Ziels fällt, priorisiert die Vertriebsleitung Maßnahmen je Region.

Finance-Entscheidung: Wenn gebuchter Nettoumsatz nach Storno und Währungsumrechnung vom Forecast abweicht, entscheidet Finance über Abschlusskorrektur und Kommunikation.

Contract-Aspekt	Sales	Finance
Ereignis	Auftrag bestätigt	Erlös gebucht
Zeit	Bestätigungsdatum	Buchungsperiode
Wert	Vertragswert	Nettobetrag nach Storno
Grain	Auftrag/Region	Buchungszeile/Gesellschaft
Zweck	Pipeline steuern	Abschluss freigeben

Das sind zwei Kennzahlen. Ein Dashboard-Filter kann den Bedeutungsunterschied nicht heilen. Sinnvolle Namen wären „Bestätigter Neuauftragswert“ und „Gebuchter Nettoumsatz“. Eine fachliche Beziehung kann dokumentiert werden, aber die Verträge bleiben getrennt.

Verantwortlichkeit: A ist nicht der Report-Owner

Der accountable Owner entscheidet über fachliche Bedeutung und zulässige Nutzung. BI Engineering ist häufig responsible für Implementierung, Stewards unterstützen Dokumentation und Consumer validieren Nutzbarkeit. Der Dashboard-Owner darf Layout und Sicht verantworten, wird dadurch aber nicht automatisch KPI-Owner.

Bei strittigen Definitionen entscheidet A nicht nach persönlicher Vorliebe. A prüft Zweck, regulatorische Vorgaben, Anschlussfähigkeit und Auswirkungen. Gibt es zwei legitime Zwecke, sind zwei Kennzahlen oft sauberer als ein politischer Formelkompromiss.

Umfang: Wie groß darf der Contract-Start sein?

Klassifiziert Anforderungen für den Einstieg:

S: eine Entscheidung, eine Domäne, bestehende Quelle — Mini-Vereinbarung im Workshop.
M: mehrere Nutzer oder Quellen — Vereinbarung plus fachlicher Review und Prototyp.
L: externe Berichte, Vergütung oder mehrere Domänen — formale Freigabe, Lineage, Kontrollen und Change Prüfpunkt.

Das Umfang bestimmt die Governance-Tiefe, nicht die Bedeutung. Auch S braucht einen Owner und klare Grenzen.

Checkliste vor dem ersten Chart

Entscheidung enthält ein aktives Verb
Entscheidungsobjekt ist eindeutig
Zeit-, Status- und Geltungsgrenze sind genannt
Auslöser und Folgehandlung sind verbunden
Fachlicher verantwortliche Person (A) hat zugestimmt
Ereignis und Ausschlüsse sind definiert
fachliche Ebene, Aggregation und Zeitlogik stehen
Nutzer-Tier und Aktualitätsbedarf sind klar
Gleichnamige Kennzahlen wurden auf unterschiedliche Zwecke geprüft
Reviewdatum und Änderungsweg sind eingetragen

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.

Woche 1: Nehmt zehn KPI-Anforderungen aus dem Backlog. Formuliert jede als Verb + Objekt + Grenze. Anforderungen ohne Handlung gehen zurück ins Intake.

Woche 2: Erstellt drei Mini-Contracts und benennt A. Trennt gleichnamige Anforderungen mit unterschiedlichen Zwecken.

Woche 3: Validiert Definition und Beispieldaten gemeinsam mit Owner, Engineering und zwei echten Consumern.

Woche 4: Gebt nur akzeptierte Contracts in semantische Umsetzung und Dashboard-Design. Dokumentiert offene Entscheidungen sichtbar.

Kurzer 90-Tage-Ausblick

Nach 90 Tagen sollte das BI-Backlog keine kritische KPI ohne Entscheidungssatz aufnehmen. Baut einfache Review-SLAs nach S/M/L auf und verbindet freigegebene Contracts mit dem Semantic Metrics Store sowie dem Trusted-Metrics-Pfad.

Nächster Schritt

← Vorheriger Teil · Nächster Teil → Semantic Layer vs Dashboard

Entscheidung vor dem Dashboard