KPI & Metric Governance

Vertrauenswürdige Daten führen nicht automatisch zu vertrauenswürdigen Kennzahlen

KPI & Metric Governance steuert, dass dieselbe Kennzahl — z. B. Nettoumsatz — überall dieselbe Bedeutung, Berechnung und Verantwortung hat.

Warehouse und DQ-Tests sind grün. Trotzdem zeigt das Power-BI-Board 12,4 Mio. und die Qlik-Sales-App 11,9 Mio. unter demselben Label — unterschiedliche Storno- und Retourenregeln.

Der Grund liegt häufig nicht in den Rohdaten, sondern in der Metrikschicht:

• dieselbe KPI wird in mehreren Tools unterschiedlich berechnet
• Filter und Selektionslogik verändern das Ergebnis
• Business-Regeln werden direkt im Report statt im Datenmodell umgesetzt
• Excel-Dateien enthalten eigene Formeln und manuelle Korrekturen
• Qlik-, Power-BI- oder Tableau-Anwendungen definieren eigene Dimensionen
• Aggregationen reagieren unterschiedlich auf Granularität und Kontext
• fachliche Änderungen werden nicht versioniert oder freigegeben
• ein KPI-Name bleibt gleich, obwohl sich die Berechnung verändert
• verschiedene Teams verwenden unterschiedliche Zeit-, Kunden- oder Produktdefinitionen
• Kennzahlen besitzen keinen eindeutigen verantwortliche Person

KPI & Metric Governance verbindet fachliche Bedeutung, technische Berechnung, Verantwortung, Lineage, Freigabe und Nutzung zu einem kontrollierten Lifecycle.

Eine KPI ist erst dann vertrauenswürdig, wenn Definition, Berechnung, Filter, Granularität, Herkunft und Verantwortlichkeit nachvollziehbar und über alle Nutzungskanäle hinweg konsistent sind.

Phase A — definieren und verantworten

Name, Zweck, Formel, Grain und Owner — bevor ein zweites Tool Nettoumsatz rechnet.

Phase B — berechnen und konsumieren

Im Semantic Layer publizieren, in BI/Excel konsumieren, bei Formelwechsel recertifizieren.

Eine Kennzahl besteht aus mehr als einer Formel

Eine belastbare KPI-Definition umfasst mindestens:

Ohne diese Informationen kann dieselbe Formel in verschiedenen Kontexten unterschiedliche Ergebnisse erzeugen.

Das typische Problem zwischen dbt und Reporting

dbt ist stark in der Transformation, Dokumentation und Versionierung von Datenmodellen.

Viele dbt-Projekte modellieren bewusst:

• Facts für messbare Ereignisse
• Dimensions für fachliche Merkmale
• standardisierte Transformationen
• vorberechnete Felder
• Tests und Dokumentation

Das ist eine gute Grundlage — aber noch keine Garantie für einheitliche Kennzahlen.

In Reportlösungen entstehen häufig zusätzliche Berechnungsebenen:

• Qlik verwendet dynamische Expressions und kontextabhängige Aggregationen
• Power BI nutzt DAX Measures
• Tableau verwendet Calculated Fields und Level-of-Detail-Ausdrücke
• Excel enthält Zellformeln, Pivot-Berechnungen, Power Query oder Power Pivot
• Self-Service-Nutzer erstellen eigene Dimensionen, Gruppen und Filter
• semantische Modelle definieren weitere Logik außerhalb von dbt

Dadurch kann eine Kennzahl trotz identischer Facts und Dimensions auseinanderlaufen.

Beispiel:

dbt Modell:
revenue = quantity * unit_price

Qlik:
Sum({<Status={'Closed'}>} revenue)

Power BI:
CALCULATE(
    SUM(FactSales[Revenue]),
    DimStatus[Status] = "Closed"
)

Excel:
=SUMIFS(Revenue, Status, "Closed")

Die Formeln wirken gleich — können aber unterschiedliche Ergebnisse liefern, wenn:

• Status unterschiedlich interpretiert wird
• Nullwerte anders behandelt werden
• Beziehungen im semantischen Modell abweichen
• Filterkontext unterschiedlich wirkt
• Zeitdimensionen nicht identisch sind
• Duplikate oder Many-to-Many-Beziehungen existieren
• Nutzer eigene Gruppen oder Ausnahmen hinzufügen
• Excel-Daten nicht denselben Aktualitätsstand besitzen

Das Kernproblem lautet:

Trusted Facts + Trusted Dimensions
        ≠
automatisch Trusted Metrics

Vertrauenswürdige Kennzahlen benötigen eine kontrollierte Metrikschicht.

Dynamische Formeln sind nicht das Problem

Dynamische Berechnungen sind in Reporting-Tools oft notwendig.

Sie ermöglichen:

• kontextabhängige Aggregationen
• flexible Zeitvergleiche
• Set Analysis
• Szenarien und What-if-Analysen
• Nutzerselektionen
• dynamische Gruppierungen
• rollenspezifische Sichtweisen
• interaktive Self-Service-Analysen

Das Problem entsteht erst, wenn die Logik:

• nur lokal im Report existiert
• nicht dokumentiert ist
• keinen verantwortliche Person besitzt
• nicht getestet wird
• nicht versioniert ist
• von anderen Tools abweicht
• fachlich nie freigegeben wurde
• durch Kopieren unkontrolliert vervielfältigt wird

KPI Governance sollte dynamische Logik deshalb nicht verbieten, sondern kontrolliert klassifizieren.

Drei Ebenen der Metriklogik

Ein praktisches Modell unterscheidet drei Ebenen.

Die entscheidende Frage ist:

Welche Logik gehört in die zentrale, freigegebene Metrikdefinition — und welche darf bewusst lokal und explorativ bleiben?

Das KPI & Metric Operating Model

Ein belastbarer Lifecycle kann in sechs Schritten aufgebaut werden.

1. KPI fachlich definieren

Vor der technischen Umsetzung müssen folgende Fragen beantwortet sein:

• Welche Business-Frage beantwortet die KPI?
• Welche Entscheidung soll sie unterstützen?
• Welche Ereignisse werden gezählt?
• Welche Ereignisse werden ausgeschlossen?
• Welche Zeitlogik gilt?
• Welche Granularität ist zulässig?
• Welche Dimensionen dürfen verwendet werden?
• Welche Zielwerte und Schwellenwerte gelten?
• Welche Ausnahmen existieren?
• Welche andere Kennzahl darf nicht mit ihr verwechselt werden?

Eine Definition wie „aktive Kunden“ reicht nicht.

Besser:

Active Customer

Ein Kunde gilt als aktiv, wenn innerhalb der letzten
90 Kalendertage mindestens ein abgeschlossener Kauf
mit positivem Nettoumsatz vorliegt.

Ausgeschlossen:
- Testkunden
- vollständig stornierte Bestellungen
- interne Mitarbeiterkonten

Zeitbezug:
Rolling 90 Days auf Basis des Buchungsdatums

2. Verantwortung und Entscheidungsrechte

Kennzahlen benötigen fachliche Verantwortung.

Wichtig ist eine eindeutige Entscheidungshoheit.

Nicht jedes Team darf dieselbe KPI unabhängig neu definieren.

3. Berechnung, Filter und Granularität standardisieren

Eine technische Definition sollte explizit festhalten:

• Formel
• Quellen
• Join-Logik
• Aggregationsart
• Zeitdimension
• Granularität
• Standardfilter
• Ausschlüsse
• Nullbehandlung
• Währungslogik
• Rundung
• Dimensionsabhängigkeiten
• Slowly-Changing-Dimension-Verhalten
• Late-arriving Facts
• historische Neuberechnung

Beispiel:

metric: net_revenue
version: 3.2
owner: finance
expression: gross_revenue - discounts - returns
time_dimension: booking_date
default_grain: day
currency: group_currency
filters:
  order_status:
    - booked
    - completed
exclude:
  - test_customer
  - internal_account
certification: certified

4. Freigegebene Metriken veröffentlichen

Freigegebene Kennzahlen sollten dort verfügbar sein, wo Nutzer arbeiten.

Mögliche Zielsysteme:

• Kennzahlenmodell
• Metrics Layer
• dbt Kennzahlenmodell
• Qlik Apps und Master Measures
• Power BI semantisches Modells
• Tableau Published Data Sources
• Excel über kontrollierte Datenverbindungen
• Datenkatalog und Business Glossary
• API-basierte Datenprodukte

Das Ziel ist nicht, alle Nutzer in ein Tool zu zwingen.

Das Ziel ist:

Qlik, Excel, Power BI und Tableau dürfen unterschiedliche Oberflächen bieten — aber die freigegebene KPI sollte dieselbe Bedeutung behalten.

Excel ist Teil der Governance-Landschaft

Excel wird in vielen Unternehmen weiterhin intensiv genutzt.

Typische Gründe sind:

• hohe Verbreitung
• flexible Ad-hoc-Analyse
• schnelle Szenarien
• individuelle Berechnungen
• vertraute Arbeitsweise
• einfache Weitergabe
• Nähe zu Finance und Controlling

Excel aus Governance auszuschließen ist deshalb unrealistisch.

Stattdessen sollten klare Regeln gelten:

• zertifizierte Datenquellen verwenden
• freigegebene KPI-Definitionen referenzieren
• manuelle Überschreibungen sichtbar machen
• lokale Formeln von offiziellen Kennzahlen unterscheiden
• Version und Aktualitätsstand anzeigen
• kritische Dateien kontrolliert speichern
• fachliche Freigabe für wiederkehrende Management-Reports
• bekannte Excel-KPIs in das Metrik-Inventar aufnehmen

Ein sinnvoller Status kann sein:

Qlik und dynamischer Filterkontext

Qlik bietet mit Set Analysis und assoziativem Datenmodell hohe Flexibilität.

Gerade diese Stärke kann jedoch zu Abweichungen führen.

Beispiel:

Sum(Sales)

gegen:

Sum({<OrderStatus={'Closed'}>} Sales)

gegen:

Sum(
    Aggr(
        Sum({<OrderStatus={'Closed'}>} Sales),
        CustomerID
    )
)

Alle drei Ausdrücke können fachlich sinnvoll sein — aber sie messen nicht automatisch dasselbe.

Governance sollte daher festlegen:

• Welche Master Measures sind zertifiziert?
• Welche Set-Analysis-Filter gehören zur offiziellen Definition?
• Welche Dimensionen sind freigegeben?
• Welche Alternate States beeinflussen die Kennzahl?
• Welche lokalen Expressions sind explorativ?
• Wie werden Änderungen an Master Measures geprüft?
• Wie wird die Formel in Lineage und Katalog sichtbar?

Eigene Dimensionen verändern die Aussage

Nutzer definieren häufig eigene Dimensionen:

• Kundengruppen
• Produktcluster
• Regionen
• Altersklassen
• Vertriebssegmente
• Zeitperioden
• manuelle Ausnahmen

Diese Flexibilität ist wertvoll, kann aber Kennzahlen verändern.

Beispiel:

Zentrale Dimension:
Region basiert auf Vertragsstandort

Lokale Report-Dimension:
Region basiert auf Postleitzahl des Rechnungsempfängers

Beide Reports zeigen „Umsatz nach Region“, messen aber unterschiedliche Konzepte.

Deshalb benötigen auch Dimensionen Governance:

• Definition
• Herkunft
• Gültigkeit
• Hierarchie
• Granularität
• Änderungsverlauf
• verantwortliche Person
• Freigabestatus

Metrik-Lineage

Eine Kennzahl sollte bis zu ihren Quellen nachvollziehbar sein.

Beispiel:

Lineage sollte nicht am Tabellenmodell enden.

Sie sollte möglichst auch erfassen:

• verwendete Formel
• Filter
• Dimensionen
• semantische Modelle
• Report-Objekte
• Excel-Verbindungen
• Downstream-Management-Reports

KPI-Konflikte erkennen

Typische Konfliktmuster sind:

• gleicher Name, unterschiedliche Formel
• gleiche Formel, andere Zeitlogik
• gleiche KPI, andere Standardfilter
• gleiche Kennzahl, andere Granularität
• lokale Excel-Korrekturen
• Qlik Set Analysis weicht von DAX oder SQL ab
• Dimensionen verwenden unterschiedliche Hierarchien
• historische Versionen werden parallel genutzt
• alte Reports behalten veraltete Definitionen

Ein Governance-Prozess sollte Konflikte sichtbar machen.

Beispiel:

Testing von Kennzahlen

KPI-Tests sollten über technische Datentests hinausgehen.

Geeignete Kontrollen sind:

• Formeltest
• Abgleich zwischen Quelle und Metrik
• Vergleich über Reporting-Tools
• Filter- und Kontexttest
• Zeitlogiktest
• Granularitätstest
• Regressionstest bei Änderungen
• bekannte Beispieldatensätze
• Grenzfalltests
• Abweichungstest gegenüber freigegebener Referenz

Beispiel:

Reference Scenario:
Customer A
2 booked orders
1 cancelled order
10 EUR discount

Expected Nettoumsatz:
190 EUR

Die Referenz sollte in dbt, Semantic Layer und BI-Tool dasselbe Ergebnis erzeugen.

Change Management

Metriken verändern sich.

Änderungen können ausgelöst werden durch:

• neue Geschäftsmodelle
• regulatorische Anforderungen
• veränderte Produktstruktur
• neue Währungslogik
• neue Zeitdefinitionen
• Fusionen oder Organisationsänderungen
• korrigierte fachliche Regeln

Jede Änderung sollte dokumentieren:

• Änderungsgrund
• betroffene Version
• neue Definition
• Gültigkeitsdatum
• Auswirkung auf historische Werte
• betroffene Reports
• Migration
• Freigabe
• Kommunikationsplan

Ein KPI-Name sollte nicht stillschweigend eine neue Bedeutung erhalten.

Versionierung

Beispiel:

Historische Reports benötigen eine klare Regel:

• alte Werte unverändert lassen
• vollständig neu berechnen
• parallele Versionen anzeigen
• Umstellung ab Stichtag

KPI & Metric Governance messen

Nützliche Kennzahlen sind:

• Anteil freigegebener KPIs mit verantwortliche Person
• Anteil KPIs mit dokumentierter Formel
• Anteil KPIs mit definierter Granularität
• Anteil KPIs mit verfügbarer Lineage
• Anteil zertifizierter Metriken je Reporting-Tool
• Anzahl widersprüchlicher Definitionen
• Anzahl lokaler, nicht registrierter KPI-Formeln
• Anzahl veralteter KPI-Versionen in Reports
• Zeit bis zur Freigabe einer KPI-Änderung
• Anzahl Änderungsanträge
• Anzahl KPI-bezogener Data-Quality-Incidents
• Nutzung zertifizierter gegenüber lokaler Kennzahlen
• Anzahl Excel-Reports mit manueller Überschreibung
• Anteil Reports auf kontrollierten semantisches Modells
• Anzahl KPI-Abweichungen zwischen Tools
• Wiederverwendungsrate zentraler Metriken

Ein einfaches Reifegradmodell

Typische Anti-Patterns

• dieselbe KPI wird in jedem Tool neu gebaut
• dbt-Facts und Dimensions gelten automatisch als vollständige KPI-Governance
• dynamische Reportformeln sind nicht dokumentiert
• Excel wird ignoriert, obwohl Management-Entscheidungen darauf basieren
• lokale Dimensionen verändern unbemerkt die Aussage
• unterschiedliche Zeitlogiken verwenden denselben KPI-Namen
• Kennzahlen besitzen keinen fachlichen verantwortliche Person
• Berechnungen werden kopiert statt wiederverwendet
• Änderungen erfolgen ohne Versionierung
• alte Reports bleiben mit veralteten Formeln aktiv
• Kennzahlenmodell und BI-Logik widersprechen sich
• Tests prüfen Daten, aber nicht das KPI-Ergebnis
• Filter und Granularität sind nicht Bestandteil der Definition
• Nutzer sehen keinen Zertifizierungsstatus
• Erfolg wird an der Anzahl dokumentierter KPIs statt an reduzierten Konflikten gemessen

Eine zentrale Faktentabelle verhindert keine widersprüchlichen Kennzahlen.

Erst die kontrollierte Verbindung von Datenmodell, Metrikdefinition, Semantic Layer und Reporting-Nutzung schafft Vertrauen.

Verbindung zu den anderen Governance-Säulen

Praktisches Zielbild

Das Ergebnis

Wirksame KPI & Metric Governance schafft:

• Einheitliche Bedeutung — Teams sprechen über dieselbe fachliche Kennzahl
• Konsistente Berechnung — zentrale Logik reduziert Tool-Abweichungen
• Transparenz — Formel, Filter, Granularität, Version und Herkunft sind sichtbar
• Vertrauen — Management und Fachbereiche können Zahlen nachvollziehen
• Flexibilität — Reporting-Tools bleiben nutzbar, ohne neue Wahrheiten zu erzeugen
• Effizienz — freigegebene Metriken werden wiederverwendet
• Kontrolle — Änderungen werden versioniert, getestet und freigegeben
• Business Value — Entscheidungen basieren auf abgestimmten und belastbaren Kennzahlen

Die entscheidende Frage lautet nicht:

„Haben wir eine zentrale Faktentabelle?“

Sondern:

„Erzeugen alle relevanten Tools aus denselben fachlichen Regeln dieselbe vertrauenswürdige Kennzahl?“

Verwandte Übersicht: Die 8 Säulen der Data Governance.

Vorherige Säule: Data Quality Governance.