Eine Kennzahl, eine Definition, in jedem Bericht. Wir definieren Kennzahlen zentral in der Plattform, Ihre Fachbereiche werten sie in Power BI selbst aus.
Power BI ist in den meisten Unternehmen längst im Einsatz. Trotzdem beginnt manche Managementrunde mit der Frage, welche der vorliegenden Zahlen gilt. Die Ursache liegt meist darin, an welcher Stelle die Kennzahlen definiert sind.
Wenn jeder Bericht seine eigene Kennzahlenrechnung mitbringt, existiert dieselbe Logik an vielen Stellen. Ändert sich eine fachliche Regel, laufen diese Stellen auseinander, und es ist nicht mehr eindeutig, welche Berechnung gilt. Mehr Self-Service verstärkt das Problem dann nur.
Deshalb definieren wir jede Kennzahl genau einmal und möglichst weit vorn in der Plattform: in der Gold-Schicht (der auswertbaren Schicht, mehr zum Plattformaufbau). Das semantische Modell in Power BI bleibt schlank, und Berichte übernehmen die Kennzahlen von dort.
„Wie hoch war die Liefertreue im letzten Quartal?“
Dieselbe Frage, dieselbe Datenbasis, zwei Wege zur Antwort
Solange die Definition im Bericht steckt, bleibt das unsichtbar. Liegt sie im Modell, wird sie einmal ausgehandelt, ist dokumentiert und gilt für die unternehmensweite Frage. Eigene Kennzahlen einer Abteilung bleiben davon unberührt, sie stehen dann neben der gemeinsamen Definition statt an ihrer Stelle.
Der ausführliche Hintergrund zu diesem Abschnitt: wie zentrale Logik in der Plattform aussieht, was im semantischen Modell bleiben darf und woran Sie merken, dass die Grenze verrutscht ist.
Sechs Bereiche, vom Datenmodell bis zum Betriebsmodell. Berichte zu bauen ist dabei der kleinere Teil der Arbeit.
Die Geschäftslogik liegt möglichst weit vorn in der Plattform, in der Gold-Schicht. Darauf setzen schlanke semantische Modelle in Power BI auf, eines je Themenbereich wie Vertrieb oder Einkauf, mit Beziehungen, Zeitintelligenz und verständlichen Feldnamen. In DAX bleiben Aggregation und Darstellung.
Wir moderieren die Abstimmung, wenn Fachbereiche dieselbe Kennzahl unterschiedlich rechnen, und halten das Ergebnis fest: Definition, Berechnungsgrundlage, Verantwortlicher. Gelten mehrere Sichten bewusst nebeneinander, bekommen sie eigene Namen.
Wer welche Zeilen sieht, gehört ins Modell und nicht in getrennte Berichtskopien je Werk oder Region. Wir setzen Row-Level Security auf, prüfen sie gegen die realen Rollen und dokumentieren, welche Regel woher kommt.
Freigegebene und selbst gebaute Inhalte sichtbar getrennt, ein leichter Freigabeprozess, Namenskonventionen und ein Review neuer Berichte. So viel Struktur, dass alle mit denselben Kennzahlen arbeiten, und so wenig, dass niemand sie umgehen muss.
Langsame Berichte liegen meist am Modell. Wir prüfen Granularität, Beziehungen und die Wahl zwischen Import und DirectQuery, bevor über größere Kapazitäten gesprochen wird.
Die ersten Berichte entstehen gemeinsam mit den Personen, die sie später pflegen. Danach begleiten wir nur noch im Review. Einige Key User je Fachbereich, die das Modell gut kennen, bringen mehr als eine breit gestreute Schulung.
Das Modell legt fest, was das Plattformteam zentral definiert, was die Fachbereiche selbst bauen und welche Leitplanken dazwischen gelten. Ist diese Grenze unklar, wird das Plattformteam zum Engpass, oder es entstehen Kennzahlen ohne geklärte fachliche Verantwortung.
Wir beginnen bei den Entscheidungen, die Berichte stützen sollen: Welche Frage soll ein Bericht beantworten, und trägt er sie heute? Dazu sichten wir, welche Berichte existieren, welche tatsächlich genutzt werden und wo sich Kennzahlen widersprechen. Am Ende wissen Sie, welche Berichte fehlen oder verbessert werden sollten und was ein Neubau realistisch bringt.
Aus vielen Modellen werden wenige, klar verantwortete semantische Modelle mit abgestimmten KPI-Definitionen und einem Berechtigungskonzept. Was in der Datenplattform besser aufgehoben ist, wandert dorthin.
Freigabeprozess, Namenskonventionen und Review-Rhythmus werden festgelegt und mit den Fachbereichen eingeübt. Danach begleiten wir auf Abruf, neue Berichte bauen die Fachbereiche selbst.
Wir kommen von der Plattform her. Was das für Sie bedeutet:
Widersprüchliche Zahlen und langsame Berichte haben ihre Ursache meist eine Schicht tiefer, in der Datenmodellierung und in der Governance. Weil wir die Plattform darunter selbst bauen, beheben wir die Ursache, statt sie in DAX zu umgehen.
Projekte mit vielen Abteilungen, unterschiedlichen Lesarten derselben Kennzahl und Berechtigungen bis auf Zeilenebene sind bei uns der Normalfall. Wir wissen daher, wie Analytics und Self-Service BI aufgebaut sein müssen, damit sie auch in dieser Größe tragen.
Unser Ziel ist, dass Ihre Fachbereiche ihre Berichte selbst pflegen und wir nur noch bei Modelländerungen gefragt werden.
In der globalen Finance-Plattform eines Konzerns sank der administrative Aufwand um rund 70 %, Berichte laufen schneller und stabiler (Referenz 05).
Dass Fachbereiche eigene Auswertungen bauen, ohne dafür jedes Mal ein Ticket zu schreiben, und ohne dabei eigene Kennzahlenlogik zu erfinden. Möglich wird das durch freigegebene semantische Modelle, in denen Beziehungen, Filterlogik und KPI-Definitionen bereits stecken. Der Fachbereich wählt aus und kombiniert, er definiert nicht neu.
Weil sie sich dort vervielfältigt. Wird dieselbe Kennzahl in drei Berichten je einmal gerechnet, gibt es drei Stellen, an denen sie auseinanderlaufen kann, und keine, die als verbindlich gilt. Typische Folge sind Diskussionen über die Zahl statt über die Entscheidung, die sie stützen soll. Geschäftslogik gehört deshalb an genau eine Stelle, möglichst weit vorn in die Plattform. Berichte und Excel-Auswertungen übernehmen sie von dort. Ausführlich mit Beispielen steht das in „Business-Logik in Microsoft Fabric richtig denken“.
Meist an drei Stellen. Erstens Bestandsaufnahme: welche Berichte existieren, welche werden tatsächlich genutzt, und wo widersprechen sich Kennzahlen. Zweitens Konsolidierung: aus vielen Modellen werden wenige, klar verantwortete semantische Modelle. Drittens Leitplanken: Namenskonventionen, Freigabeprozess und Berechtigungskonzept, damit die Konsolidierung nicht in einem Jahr wieder rückgängig gemacht ist.
Vor allem dadurch, dass das freigegebene Modell der einfachste Weg ist. Steht es mit sauberen Feldnamen und fertigen Kennzahlen bereit, ist es weniger Arbeit, es zu nutzen, als eine eigene Datenquelle anzuschließen. Dazu kommen eine sichtbare Kennzeichnung freigegebener Inhalte, ein schlanker Freigabeprozess und regelmäßige Reviews neuer Berichte.
Power BI arbeitet mit beiden zusammen. Mit Microsoft Fabric ist die Kopplung am engsten: Über Direct Lake liest Power BI die Delta-Tabellen in OneLake direkt, ohne Import und ohne DirectQuery. Auf Azure Databricks gibt es drei Wege zur Gold-Schicht: Import in das Modell, DirectQuery gegen ein SQL Warehouse und Direct Lake, wenn der Unity Catalog per Mirroring in OneLake eingebunden wird. Die Wahl der Plattform hängt deshalb weniger an Power BI als an den übrigen Anforderungen. Azure Databricks bietet mehr Kontrolle über Rechenressourcen, ausgereiftere Muster für Streaming und mit MLflow eine vollständige Modellverwaltung. Microsoft Fabric dagegen läuft als SaaS mit weniger eigenem Betrieb, die gebuchte Kapazität macht die Kosten planbar.
Indem sie am eigenen Fall lernen. Wir bauen die ersten Berichte gemeinsam mit den Personen, die sie später pflegen, halten die Konventionen schriftlich fest und begleiten die nächsten Berichte nur noch im Review. Danach sind einige Key User je Fachbereich, die das Modell gut kennen, die ersten Ansprechpartner für ihre Kollegen.
Wir gehen jeden Bericht danach durch, welche Frage er beantwortet und welche Entscheidung er stützt, und wie er technisch aufgebaut ist. Daraus entsteht eine Empfehlung je Bericht: unverändert übernehmen, mit einem verwandten Bericht zusammenführen, auf das freigegebene Modell umbauen oder neu schneiden, wenn sich die Entscheidung, die er stützen soll, damit besser unterstützen lässt. Häufig fällt dabei auch auf, welche Auswertung bislang fehlt, weil sie mit den bisherigen Mitteln zu aufwendig war. Bestehende Berichte laufen so lange weiter, bis der Nachfolger fachlich abgenommen ist.
Kennzahlenlogik, Datenmodell und Plattformwahl, ausführlich erklärt in unserem Blog.
„Sanalytics hat uns bei der Modernisierung unserer Datenplattform und unseres Reportings begleitet. Zudem unterstützten sie uns bei der Evaluierung von KI-Lösungen sowie bei der Entwicklung von Prototypen. Dank ihrer Unterstützung gelang der reibungslose Übergang zu einer skalierbaren Datenplattform für Group Finance mit höherer Datenqualität, besserer Performance und verbesserter Wartbarkeit.“
David Sanadze
Gründer & Solutions Architect – Data & AI
Wenn im Management über die Kennzahl statt über die Entscheidung diskutiert wird, fehlt meist eine gemeinsame Definition.
In 30 Minuten klären wir:
