Daten­mo­del­lie­rung & KPIs

Meist liegt es nicht an den Daten, wenn Vertrieb und Controlling für denselben Monat unterschiedliche Umsätze nennen. „Umsatz“ wurde an mehreren Stellen verschieden berechnet: in Tabellen, in einzelnen Berichten oder in Abfragen, die irgendwann jemand geschrieben hat.

Wir bauen Datenmodelle, in denen jede Kennzahl genau einmal definiert ist. Das Sternschema gibt den Daten ihre Struktur, ein semantisches Modell enthält die Berechnungen, und ein KPI-Katalog hält fest, was jede Kennzahl bedeutet und wer dafür zuständig ist. Dashboards, Excel-Auswertungen und KI-Assistenten greifen auf dieselben Definitionen zu. Wie Daten im Data Warehouse geladen, historisiert und in Schichten organisiert werden, ist ein eigenes Thema. Hier geht es um das Modell darüber, das Fachbereiche und Werkzeuge direkt nutzen.

Fakten und Dimensionen

Im Sternschema speichern Faktentabellen Ereignisse mit Zahlenwerten, etwa Verkäufe mit Menge und Betrag. Um sie liegen Dimensionstabellen, die beschreiben, wonach gefiltert und gruppiert wird: Produkt, Kunde, Region, Datum. Das passt zur Arbeitsweise von BI-Werkzeugen, denn jede Visualisierung gruppiert über Dimensionen und fasst Werte aus Fakten zusammen. Microsoft empfiehlt das Sternschema für Power-BI-Modelle ausdrücklich, auch wegen Performance und Verständlichkeit.

In der Praxis hängt viel an der Granularität. Jede Faktentabelle hat eine feste Detailstufe, zum Beispiel eine Zeile je Bestellposition. Werden Plan- und Istwerte auf unterschiedlicher Stufe in dieselbe Auswertung gemischt, stimmen die Summen nicht mehr. Mit einer gemeinsamen Datumsdimension laufen Vorjahresvergleiche und Monatsabschlüsse überall gleich, und Bestell-, Liefer- und Rechnungsdatum nutzen sie in unterschiedlichen Rollen. Beziehungen laufen über Schlüssel, die in der Dimension genau einmal vorkommen. Wechselt eine Person im Vertrieb die Region, müssen ihre bisherigen Umsätze der alten Region zugeordnet bleiben, was in der Regel im Data Warehouse gelöst wird.

Der häufigste Fehler beim Entwurf ist, die Tabellen des ERP eins zu eins zu übernehmen. Ein Modell, das nach dem Quellsystem aufgebaut ist statt nach den Fragen der Fachbereiche, bleibt schwer verständlich.

Wo der Semantic Layer liegt

Der Semantic Layer enthält die Berechnungsregeln der Kennzahlen, damit sie nicht in jedem Bericht neu gebaut werden. Ändert sich eine Definition, wird sie an einer Stelle angepasst. Wer ausschließlich mit Power BI arbeitet, definiert Kennzahlen als Measures in DAX im Semantikmodell, und Berichte, Excel und Copilot nutzen dasselbe Modell.

Im BI-Tool ist die Schicht schnell eingerichtet, gilt aber nur dort. Sobald mehrere Werkzeuge, Anwendungen oder Assistenten dieselben Zahlen brauchen, liegt sie besser in der Datenplattform oder in einer eigenen Schicht, die Metriken, Dimensionen und Zugriffsregeln als Code beschreibt. Mehrere Hersteller bieten dafür inzwischen eigene Objekte an. Das ist eine Architekturentscheidung, und wir treffen sie anhand der vorhandenen Systeme.

Der KPI-Katalog

Ein KPI-Katalog beschreibt jede Kennzahl so, dass Fachbereich und Technik dasselbe meinen. Zu einem Eintrag gehören der Name und die Entscheidung, die die Kennzahl unterstützt, eine fachliche Definition („Umsatz ist der fakturierte Nettobetrag ohne Stornos“), die Berechnung mit Formel, Filtern, Zeitbezug und Quelle, die Person oder Rolle, die Änderungen freigibt, und die Version, also seit wann die Definition gilt und was sich geändert hat.

Kennzahlen stehen selten allein. Umsatz, Deckungsbeitrag und Ergebnis bauen aufeinander auf und bilden ein Kennzahlensystem. Wir bilden diese Zusammenhänge im Modell ab, damit sich Abweichungen auf eine Ursache zurückführen lassen. Für jede Kennzahl steht fest, wer sie fachlich verantwortet. Neue Kennzahlen entstehen dann nicht im einzelnen Bericht, sondern gehen über einen kurzen, festen Weg in den Katalog.

Wir starten dabei mit den Kennzahlen, auf die sich Entscheidungen stützen, und lassen den Katalog danach wachsen. Wer zuerst alles erfassen will, kommt selten zum Modell.

Kennzahlen wie Code behandeln

Definitionen, die nur in der Oberfläche eines Werkzeugs oder in den Köpfen einzelner Leute existieren, lassen sich nicht prüfen. Bei Metrics as Code liegen sie als Dateien in einer Versionsverwaltung wie Git. Änderungen werden geprüft, sind nachvollziehbar und lassen sich zurücknehmen. Die meisten eigenständigen Semantic-Layer-Werkzeuge arbeiten ohnehin so, und bei Power BI lassen sich Semantikmodelle als Power BI Project mit TMDL-Dateien speichern und versionieren. Automatische Tests ergänzen das, etwa der Abgleich, dass die Summe nach Region der Gesamtsumme entspricht.

Damit Definitionen nicht an einen Anbieter gebunden bleiben, arbeiten mehrere Hersteller an einem offenen Austauschformat. Die Open Semantic Interchange (OSI) wird inzwischen unter dem Namen Apache Ossie bei der Apache Software Foundation weiterentwickelt. Modelle mit Tabellen, Beziehungen, Dimensionen und Metriken werden darin in YAML beschrieben. Werkzeuge wie dbt unterstützen das Format, und auch Microsoft beteiligt sich. Der Standard ist noch jung und bildet nicht jeden Aspekt eines Modells ab. Er ersetzt saubere Definitionen nicht, kann aber später einen Wechsel erleichtern.

Was ein KI-Assistent vom Modell erwartet

Assistenten, die Fragen zu Unternehmensdaten beantworten, lesen das semantische Modell: welche Kennzahlen es gibt, wie sie heißen und wie Tabellen verbunden sind. Je genauer das beschrieben ist, desto seltener raten sie. Dazu gehören verständliche Namen, Beschreibungen, Synonyme (etwa „Erlös“ für „Umsatz“), einheitliche Formate und ausgeblendete Hilfsfelder. Mehrere Hersteller dokumentieren das ausdrücklich als Voraussetzung für gute Antworten.

Ohne ein solches Modell müsste ein Assistent Berechnungen aus Rohtabellen selbst ableiten und käme je nach Frage zu verschiedenen Ergebnissen. Wie Chat-Funktionen im Einzelnen funktionieren und getestet werden, behandeln wir unter Conversational Analytics.