Semantic layer vs 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 Zählebene / 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.

Ein Team definiert „aktive Kunden“ in einem Dashboard-Tooltip: „Kunden mit Aktivität in den letzten 30 Tagen.“ Im nächsten Report werden Service-Tickets als Aktivität ergänzt, im Export jedoch nicht. Drei Monate später stimmen alle Tooltips, aber keine zwei Zahlen überein.

Der Tooltip ist nützliche Nutzende-Hilfe. Er ist kein belastbarer Ort für zentrale Bedeutung oder Berechnung. Der Semantic Layer beziehungsweise Metrics Store trägt den wiederverwendbaren Vertrag; das Dashboard gestaltet eine Sicht für einen bestimmten Nutzungskontext.

Einfach gesagt

Entscheidung: Haltet fachliche Bedeutung und kanonische Berechnung in einer gemeinsamen semantischen Schicht. Dashboards wählen, filtern, erklären und visualisieren diese Kennzahlen für Nutzende-Tiers.

Ergebnis: Eine freigegebene Änderung kann kontrolliert auf mehrere Sichten wirken, ohne Definitionen manuell zu kopieren.

Zwei Schichten, zwei Jobs

Semantic Layer / Metrics Store	Dashboard / Nutzende-Sicht
kanonische Definition und Formel	Auswahl relevanter Kennzahlen
Bezugs- und Detailebene, Dimensionen und Join-Regeln	Layout, Visualisierung und Navigation
Zeitlogik und erlaubte Filter	kontextbezogene Default-Filter
Owner, Version und Status	Zielgruppe und Nutzungssituation
Lineage und technische Umsetzung	Erklärung, Annotation und Warnhinweis
wiederverwendbar über Tools	optimiert für einen Nutzende-Tier

„Dashboard“ meint hier jede Ausgabesicht: BI-Bericht, eingebettete Analyse, Scorecard oder die Nutzende-UI eines Data Products. Keine davon sollte heimlich zur alleinigen Definitionsinstanz werden. Ein Data Product ist nicht das Dashboard.

Ein Tooltip kann eine Definition verständlich zusammenfassen. Problematisch wird er, wenn er die einzige Quelle ist. Dann:

bleibt die Berechnung im Berichtscode verborgen;
sind Änderungen nicht über Nutzer hinweg nachvollziehbar;
können Exporte und APIs eine andere Logik liefern;
besitzt die Definition keinen unabhängigen Freigabestatus;
wird ein Layout-Release unbemerkt zum KPI-Change.

Die richtige Kette lautet: Contract wird fachlich freigegeben, semantisch implementiert und getestet; der Tooltip verweist in verständlicher Sprache auf diese Definition. Er dokumentiert die Sicht, nicht eine lokale Variante.

Nutzende-Tiers statt Einheitsdashboard

Gemeinsame Bedeutung verlangt nicht dieselbe Darstellung. Trennt mindestens:

Operativ: hohe Aktualität, klare Schwellen, konkrete Aktion, begrenzte Exploration.
Analytisch: mehr Dimensionen, Zeitvergleiche und Drill-down für Ursachenanalyse.
Executive: wenige entscheidungsrelevante Signale, stabile Perioden und kommentierte Abweichungen.
Extern/reguliert: formale Definition, fixierter Stichtag, nachweisbare Freigabe und eingeschränkte Änderungen.

Alle Tiers dürfen dieselbe kanonische Kennzahl verwenden. Unterschiede in erlaubten Dimensionen, Aktualität oder Rundung gehören explizit in Nutzende-Vertrag und Sicht—nicht als stille Neuberechnung.

Durchgearbeitetes Beispiel: Retourenquote

Der Kennzahlvertrag definiert:

Retourenquote = vollständig retournierte Bestellpositionen / ausgelieferte Bestellpositionen, bezogen auf Liefermonat, mit 45 Tagen Reifezeit.

Der Semantic Layer implementiert Zähler, Nenner, Liefermonat, Reifezeit und zulässige Dimensionen. Danach entstehen drei Sichten:

Operations sieht täglich vorläufige Werte, klar als „unreif“ markiert, und untersucht Produkte über Schwelle.
Management sieht monatlich gereifte Werte gegen Ziel.
Externe Partner sehen quartalsweise aggregierte, freigegebene Werte ohne Kundendimension.

Würde Operations die Reifezeit lokal entfernen, entstünde keine harmlose Sicht, sondern eine andere Kennzahl. Entweder bleibt der Wert als vorläufiger Status derselben Vertragslogik erkennbar oder ein eigener Contract wird nötig.

Architekturentscheidung ohne Toolreligion

Ein Semantic Layer kann in einem dedizierten Metrics Store, einem BI-Modell oder einer kontrollierten Transformationsschicht liegen. Entscheidend sind Fähigkeiten, nicht Produktnamen:

eine Definition ist wiederverwendbar;
Version und verantwortliche Person sind sichtbar;
Dimensionen und fachliche Zählebene sind kontrolliert;
Tests und Lineage sind anschließbar;
Nutzer können den Status erkennen;
Änderungen haben einen nachvollziehbaren Weg.

Die Catalog–Metadata–Dashboard–Semantic Map hilft, Systemrollen zu trennen. Der Katalog beschreibt und macht auffindbar; die semantische Schicht berechnet; das Dashboard konsumiert.

Checkliste für saubere Schichtentrennung

Kanonische Definition liegt außerhalb eines einzelnen Dashboards
Formel, fachliche Zählebene und Zeitlogik sind zentral implementiert
Zulässige Dimensionen und Filter sind dokumentiert
verantwortliche Person, Status und Version sind sichtbar
Dashboard referenziert statt kopiert
Tooltips erklären die kanonische Bedeutung
Nutzer-Tier und Nutzungskontext sind benannt
Vorläufige und freigegebene Werte sind unterscheidbar
Abweichende Logik erzeugt Review oder eigenen Vereinbarung
Lineage und Tests decken die semantische Definition ab
Änderungen werden über betroffene Sichten geprüft

Umsetzung im Alltag

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.

Inventarisiert zehn kritische Dashboard-KPIs und markiert lokale Formeln, Tooltips und Abweichungen.
Wählt zwei Kennzahlen und bestimmt kanonische Definition, Bezugs- und Detailebene, Dimensionen und Owner.
Implementiert die Definition semantisch und verbindet je eine operative und analytische Sicht ohne Formelkopie.
Testet Gleichheit, Filterverhalten und Statusanzeige. Entfernt lokale Varianten erst nach fachlicher Abnahme.

Woran der nächste Ausbau anknüpft

Erweitert den Umfang erst, wenn Definition, technische Umsetzung und fachliche Abnahme für den ersten Fall zusammenpassen. Der nächste Fall sollte eine neue Fehlerart oder einen neuen Nutzungskontext prüfen, nicht nur mehr vom Gleichen hinzufügen.