Metrik-Drift über BI-Tools — warum Semantic Governance

Das Unternehmensproblem und der umsetzbare Auftrag

Dieselbe Kennzahl wird in mehreren Werkzeugen gepflegt; Änderungen und Abgleiche müssen mehrfach bezahlt werden.

Freigegebene Definition und versionierte Referenzberechnung werden gemeinsam betrieben. Consumer erhalten Änderungshinweis, Vergleich und einen kontrollierten Umstellungsweg.

Wirtschaftliche Wirkung prüfen

Messe lokale Formelkopien, Pflegeaufwand pro Änderung und Stunden für Cross-Tool-Abgleiche. Vergleiche diese Entlastung mit Integrations-, Betriebs- und Migrationsaufwand. Kapazitätsgewinn, tatsächlich vermeidbare Ausgaben und Qualitätswirkung werden getrennt ausgewiesen.

Veränderung im Alltag verankern

Der Fachbereich besitzt die Semantik. Builder übernehmen die Referenz statt eigener Dauerformeln; der Sponsor priorisiert die Ablösung tatsächlich verwendeter Kopien.

Für die Nutzenentscheidung dient Nutzen im ersten Review prüfen; für Mandat, Kapazität und tatsächliche Übernahme Change und Adoption. Wähle den kleinsten Umfang, der das Problem nachweisbar verbessert.

Eine Kennzahl über verschiedene Produkte abnehmen

Wähle eine strittige Kennzahl und einen kleinen freigegebenen Prüfbestand. Notiere Zählebene, Periode, Stornoverhalten, Währung, Regelversion und erwarteten Wert. Die führende Berechnung kann im vorhandenen SQL-Modell, dbt oder KNIME liegen; entscheidend ist die gemeinsam abgenommene Definition.

Power BI und Qlik müssen bei gleicher Definition und gleichem Filter den vereinbarten Wert zeigen. Eine Denodo-View ist nur ein möglicher Bereitstellungsweg und benötigt dieselbe Prüfung. Eine abweichende Zahl wird nicht per Dashboardkorrektur versteckt: Quelle, Transformation und Filter werden gegeneinander abgeglichen. Der Kennzahlenverantwortliche entscheidet die Korrektur; betroffene Nutzer erhalten Version, Wirksamkeitsdatum und Ansprechpartner. Miss anschließend die eingesparte Abstimmungszeit bei vergleichbarem Berichtsumfang.

Nächster Arbeitsschritt: Entscheidung im bestehenden Fachkapitel konkretisieren.

Einstieg

Fachlichen Metric Owner und verbindliche Definitionsversion festlegen. Vergleich braucht verantwortete Bedeutung und einen identifizierbaren Stand. Gleichen Datenstand und angewendete Filter mit ablegen. Ohne gemeinsame Vergleichsbasis ist ein Delta nicht eindeutig interpretierbar. Technisch gültige Zahlen können verschiedene Fragen beantworten. Abstimmung braucht prüfbare Unterschiede und deren Einordnung.

Kennzahlen-Governance beginnt nicht mit dem Kauf eines semantischen Werkzeugs. Sie beginnt mit einer gemeinsam verstandenen Definition: Welche Datensätze gehören zur Kennzahl, was bedeutet eine Zeile, welche Formel gilt und welches Datum ordnet den Wert einer Periode zu?

Ohne diese Festlegungen kann „Umsatz“ gleichzeitig gebuchten Auftragseingang, gestellte Rechnungen oder erhaltene Zahlungen meinen. Tableau zeigt dann beispielsweise 12,4 Millionen Euro, Power BI 11,1 Millionen und die Vorstandstabelle 13,0 Millionen. Jedes Ergebnis kann technisch korrekt berechnet sein und trotzdem eine andere fachliche Frage beantworten.

Diese Serie zeigt, wie eine Kennzahl eindeutig definiert, versioniert, in BI-Werkzeugen veröffentlicht und bei Änderungen kontrolliert wird. Außerdem erklärt sie, wer die fachliche Bedeutung verantwortet, wer sie technisch umsetzt und wie Abweichungen zwischen Werkzeugen aufgeklärt werden.

Ausgangslage

FP&A veröffentlicht „Revenue“ im Warehouse. Tableau zeigt 12,4 Mio., Power BI 11,1 Mio., das Board-Report 13,0 Mio. Population, Booking- vs. Invoice-Datum und eine lokale Measure unterscheiden sich. Der Katalog nennt Owner = FP&A. Niemand hat eine Version, niemand kann die letzte zertifizierte Formel nennen. Teams kaufen dann einen Semantic Layer oder taggen certified=true — und der nächste Board-Pack trägt weiter drei Zahlen.

Was diese Serie klärt

• Orientierung: Metrik-Drift, kanonische Definition, semantisches Modell/Metrics-Publish, Abgleich, Änderungsprüfungen (diese Seite)
• Vertiefung: Metrikdefinition, Version, zertifizierter Publish
• Vertiefung: Kennzahlenmodell-Verantwortung RACI über Tools
• Vertiefung: Änderungsprüfungen und Nutzer-Benachrichtigung
• Abschluss: Cross-Tool-Abgleich-Evidenz

Die Beispiele sind Anwendungsbeispiele (keine Kundendaten). Ersetzt Kennzahlen-, Report- und Toolnamen durch eure Semantic-, BI-, Catalog- und Prozessquellen.

Begriffe vor dem Lesen

• Kennzahlenabweichung — dieselbe bezeichnete Kennzahl liefert in verschiedenen Werkzeugen unterschiedliche Ergebnisse.
• Kanonische Definition — verbindliche Beschreibung von Grundgesamtheit, Zählebene, Formel, Zeitlogik und Ausschlüssen.
• Semantic Layer — eine gemeinsame semantische Schicht, die fachliche Begriffe und Berechnungen für mehrere Berichte bereitstellt.
• Metrics Store — zentraler, wiederverwendbarer Veröffentlichungsort für freigegebene Kennzahlenlogik.
• Abgleich — Nachweisbarer Vergleich mehrerer Implementierungen gegen dieselbe genehmigte Definition.
• Änderungsprüfung — Prüfung vor einer Änderung an Formel, Umfang, Quelle oder Veröffentlichungsort.

Produkte und Entscheidungen

Semantic Governance braucht nicht „eine BI-Plattform“, sondern geschnittene Produkte. Kein Vendor gewinnt die Serie; der Vertrag ist tool-neutral.

Kanonische Metrikdefinition

Dieses Produkt beschreibt:

• Kennzahl-ID; Anzeigename; Grundgesamtheit; Zählebene; Formel; Zeitlogik (Buchung, Rechnung, Cash); Ausschlüsse; verantwortliche Person; Version; Review-Datum.

Entscheidungen:

• Welche Grundgesamtheit ist materiell genug für den Vertrag — und welche Shadow-Kennzahl im Spreadsheet gehört trotzdem ins Register?; Wer darf „Revenue“ umlabeln, wenn die Methode bricht?; Welche Zeitlogik gilt verbindlich, wenn Booking und Invoice kollidieren?

Semantic-Layer- / Metrics-Store-Publish

Der Store ist System of Record für die Berechnung. Dashboards konsumieren.

Entscheidungen:

• Wo wird veröffentlicht — Layer, zentraler Metrics Store oder freigegebenes Warehouse-Maß?; Welche tool-lokale Kopie zählt als Abweichung?; Wer nimmt ein neues BI-Tool als denselben Nutzer oder als neue Drift-Quelle an?

Verantwortung-RACI

Fachsemantik und Implementierung sind getrennt.

Entscheidungen:

• Wer ist Kennzahlenverantwortliche Person — Head of Finanzplanung, Sales Ops, Product — nicht der Visual-Author?; Wer ist Steward für Pflege und Drift-Triage?; Wer ist technischer Betreiber für Deploy, ohne Bedeutung zu verantwortet?

Cross-Tool-Reconciliation

Zwei Tools, eine Metrik, ein nachweisbares Delta.

Entscheidungen:

• Welche Tool-Paare müssen vor dem Vorstandsbericht abgeglichen sein?; Welche Ursache gilt — Definition, Timing oder Filter?; Wer schließt das Delta, und welches Datum trägt der Nachweis?

Änderungsprüfungen und Hinweis an betroffene Nutzer

Eine Formeländerung ist ein Release.

Entscheidungen:

• Welche Änderung erzwingt ein Prüfpunkt statt „weiterhin gültig“?; Wer benachrichtigt Nutzer, bevor Tableau und Power BI neu rechnen?; Welche Override darf befristet bleiben, und was passiert am Expiry?

Wo Governance hängt

Zwischen Anzeigename und Definition

„Revenue“ im Dashboard-Titel sagt nichts über Population und Zeitlogik. Ohne Vertrag ist der Name eine Einladung zur Drift.

Zwischen Semantic-Publish und Dashboard-Measure

Ein Visual darf deklarierte Filter und lokale Darstellungsberechnungen anwenden. Es darf die gemeinsame Basiskennzahl nicht still umdefinieren. Lokale Varianten, Geltungsbereich und gegebenenfalls Migration oder Ausnahmenablauf bleiben dokumentiert.

Zwischen Metric Owner und BI-Author

Wer die Kachel editieren kann, entscheidet damit nicht Booking vs. Invoice. Semantik bleibt beim fachlichen Owner.

Zwischen Version und stillem Edit

Ein Hotfix, der Formel, Population oder Filterbedeutung ändert, braucht eine bewertete semantische Version und Kommunikation. Eine reine Performanceänderung kann den fachlichen Vertrag unverändert lassen; die Codeversion bleibt trotzdem nachvollziehbar.

Zwischen zwei Tools und fehlender Reconciliation

Tableau und Power BI können beide „zertifiziert“ aussehen und trotzdem 1,3 Mio. auseinanderliegen. Ohne Delta-Akte ist Zertifizierung Theater.

Zwischen Katalog-Link und Publish-Vertrag

Der Katalog macht Owner und Version auffindbar. Controls und Freigabe leben im Semantic-/Metrics-Vertrag — nicht in der Kachel.

Rollen-Mapping

Data Owner (Metric)

Head of FP&A, Sales Operations Lead oder benannter Domain Owner ist accountable für Population, Formel, Zeitlogik und Freigabe der Version. Der Owner entscheidet nicht das Visual-Layout.

Data Steward

Analytics Engineering, Metrics Ops oder BI Governance führt Definitionen, Drift-Tickets, Reconciliation-Cadence und Hinweis an betroffene Nutzere.

Data Product Owner

Priorisiert Metrikfamilie, Veröffentlichungspfad und Änderungsprüfungen. Nutzen und Lieferbarkeit — nicht die Buchungslogik.

Data Architect

Schützt die Zählebene der Kennzahl: Ein Beleg, ein Auftrag und ein Kunde sind nicht dieselbe Zähleinheit. Außerdem hält der Architect fest, aus welchen Quellen die Kennzahl entsteht und welche Änderungen gefährlich sind, wenn der Name gleich bleibt, die Formel aber wechselt.

Data Custodian

Warehouse- und BI-Admins veröffentlichen die Kennzahl, rollen Änderungen aus, setzen Zugriff und pausieren Jobs bei Drift. Wer eine Formel technisch ändern kann, entscheidet damit nicht automatisch, ob diese Bedeutung fachlich gilt.

Data Consumer

Berichtsersteller, Vorstandsreporting, Finance-Controller und Operations nutzen die Zahl für Entscheidungen. Lokale Abweichungen laufen über denselben Intake.

Mini-Fall

Alltagssituation: Tableau zeigt 12,4 Mio. Umsatz, Power BI 11,1 Mio. und der Vorstandsbericht 13,0 Mio. Im Katalog steht die Finanzplanung als verantwortliche Person. Ein weiterer Bericht filtert Testkonten anders als die anderen Auswertungen. Niemand kann sagen, welche Version verbindlich ist.

Was schiefläuft: Es gibt mehrere technisch funktionierende Zahlen, aber keine verbindliche Metrik. Ohne Grundgesamtheit, Veröffentlichungsweg und Abgleich bleibt „zertifiziert“ nur ein Label.

Vereinbarung: Eine verbindliche Definition legt fest, welche Rechnungen zählen, welcher Monat gilt und welche Testkonten ausgeschlossen sind. Version v3 bekommt einen Hinweis für alle Nutzer. Tableau und Power BI laufen eine Zeit lang parallel im Abgleich. Eine manuelle Tabellenkorrektur ist entweder befristet erlaubt oder gesperrt.

Kritische Übergaben

Anti-Patterns

• Jedes BI-Tool als eigene Metrik-Wahrheit
• Katalog-Badge ohne Versions- und Publish-Vertrag
• Dienstleister-Standard als alleinige Governance
• technisch verantwortliche Person oder Visual-Author entscheidet fachliche KPI-Semantik
• Shadow-Measures in Excel ohne Ausnahmeweg und Ablauf
• Formeländerung ohne Nutzer-Hinweis
• Abgleich erst am Morgen des Board-Termins

Praktische Umsetzung

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 — Metrics Foundations 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 jüngsten Drift wählen (zwei Tools, eine Kennzahl). Population, Zählebene, Formel, Zeitlogik und lokale Measures aufnehmen. Metrikregister mit fünf Einträgen schneiden. Metric Owner benennen.

Schritt 2: Control und Nachweis umsetzen

Eine kanonische Definition versionieren und über Layer oder Store publishen. Eine lokale Override befristen oder schließen. Dual-Run für ein Tool-Paar dokumentieren.

Schritt 3: Testen und Ausnahmen sichtbar machen

Negativtest: eine stille DAX- oder LookML-Änderung ohne Gate muss den Publish stoppen oder eskalieren. Reconciliation-Akte für den Board-Pack erzeugen. Eine Spreadsheet-Measure nachträglich ins Register holen.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Nur bestandene Muster (Definition, Version, Publish, Reconciliation) auf eine zweite Metrikfamilie oder ein zweites Tool übertragen.

Exit-Kriterien

• Jede entscheidungsrelevante Kennzahl hat Grundgesamtheit, Zählebene, Formel, Zeitlogik, Owner und Version.
• Veröffentlichungspfad ist Kennzahlenmodell, Metrics Store oder freigegebenes Warehouse-Maß; tool-lokale Kopien sind Abweichung.
• Änderungsprüfungen und Nutzer-Hinweis existieren vor dem Recompute.
• Abgleich-Akte existiert vor dem Vorstandsbericht; technischer Betreiber liefert Konfigurationsnachweis.
• Kennzahlenverantwortliche Person ist fachlich; BI-Admin ist technischer Betreiber.

Weiterlesen

• BI-Governance-Entscheidungen
• KPI & Metric Governance
• Dashboard Deep Dive
• Nutzergruppen und gemeinsames Datenmodell

OTD-W40: diesen Arbeitsschritt am selben Fall prüfen

Einstiegspaket für OTD-W40: bestätigte KPI-Karte OTD-SHIP/1.0.0, Snapshots S1/S2 und minimale Consumer Map CM-OTD-01. Bevor du die Änderungsprüfung liest, müssen Anwendung, Testidentität, Scope, verantwortlicher Kontakt, Versionspin und Rückmeldung für jeden betroffenen Consumer erfasst sein. Fehlt die Map, baue sie anhand der verlinkten Karte auf; die spätere Consumer-Serie vertieft ihre Regeln. Ein Gesamtwert von 75 % und eine erlaubte Nord-Sicht von 50 % sind keine widersprüchlichen Formeln.