Eine Kennzahl, eine Definition, in jedem Bericht. Wir bauen die semantischen Modelle, auf denen Ihre Fachbereiche selbst auswerten können, ohne dass die Zahlen auseinanderlaufen.
Erstgespräch vereinbarenPower BI ist in den meisten Unternehmen längst im Einsatz. Trotzdem beginnt manche Runde im Management mit der Frage, welche der vorliegenden Zahlen denn nun stimmt. Der Grund liegt fast nie im Werkzeug, sondern darin, wo die Geschäftslogik lebt.
Wenn jeder Bericht seine eigene Kennzahlenrechnung mitbringt, existiert dieselbe Logik an vielen Stellen. Sie läuft auseinander, sobald sich eine fachliche Regel ändert, und niemand kann sagen, welche Fassung gilt. Aus Self-Service wird dann kein Tempogewinn, sondern eine wachsende Zahl an Wahrheiten.
Wir setzen deshalb eine Schicht davor: In der Gold-Schicht der Plattform (der auswertbaren Schicht, mehr zum Plattformaufbau) und im semantischen Modell wird jede Kennzahl genau einmal definiert. Berichte greifen darauf zu, statt sie neu zu rechnen. Erst damit wird Self-Service verlässlich, statt die Zahl der Wahrheiten weiter zu erhöhen.
„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.
Ein semantisches Modell je fachlichem Bereich statt eines Modells je Bericht. Beziehungen, Filterrichtungen, Zeitintelligenz und Feldnamen so gebaut, dass sie für Fachanwender verständlich sind. Was im Modell nicht sinnvoll ist, gehört in die Gold-Schicht, nicht in DAX.
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 unterschiedliche Namen statt derselben Bezeichnung.
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. Genug Struktur, dass nichts auseinanderläuft, wenig genug, dass es niemand umgeht.
Langsame Berichte sind meist ein Modellierungsproblem, kein Kapazitätsproblem. 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. Ein Ansprechpartner je Fachbereich, der das Modell wirklich kennt, trägt mehr als eine breit gestreute Schulung.
Drei Ebenen, jede mit einer eigenen Verantwortung. Solange die Grenze unklar ist, entstehen entweder Engpässe im Plattformteam oder Zahlen, die niemand verantwortet.
Wir gehen von der Entscheidung aus, nicht vom Bericht: 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 steht, wo Potenzial liegen bleibt 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 Gold-Schicht besser aufgehoben ist, wandert dorthin.
Freigabeprozess, Namenskonventionen und Review-Rhythmus werden festgelegt und mit den Fachbereichen eingeübt. Danach begleiten wir auf Abruf, statt in jedem Berichtswunsch zu stecken.
Wir kommen von der Plattform her, nicht vom Dashboard. 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.
Mehrere Abteilungen, unterschiedliche Lesarten derselben Kennzahl, Berechtigungen bis auf Zeilenebene: Das ist unser Normalfall, kein Sonderfall.
Unser Ziel ist, dass Ihre Fachbereiche ihre Berichte selbst pflegen und wir nur noch bei Modelländerungen gefragt werden. Erfolgreiche Beratung macht sich mit der Zeit überflüssig.
Daran lassen wir uns messen: rund 70 % weniger manueller Aufwand in der Berichtserstellung, und Entscheidungen, die nicht mehr an Abstimmungsrunden über widersprüchliche Zahlen hängen.
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. Ohne diese Basis ist Self-Service nur ein anderes Wort für Wildwuchs.
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 genau einmal in die Plattform und in das semantische Modell, nicht in Berichte oder in lokale Excel-Zwischenschritte. Ausführlich mit Beispielen steht das in Warum Business-Logik nicht ins BI-Tool gehört.
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.
Nicht durch Verbote, sondern indem der bequemste Weg auch der richtige ist. Wenn ein freigegebenes Modell mit sauberen Feldnamen und fertigen Kennzahlen bereitsteht, ist es weniger Arbeit, es zu nutzen, als eine eigene Datenquelle anzuschließen. Dazu kommen ein sichtbarer Unterschied zwischen freigegebenen und selbst gebauten Inhalten, ein leichter Freigabeprozess und regelmäßige Reviews neuer Berichte.
Power BI arbeitet mit beiden zusammen, die Frage ist eher, wo die Daten liegen und wie das Modell darauf zugreift. In Microsoft Fabric ist die Kopplung enger: Power BI kann über Direct Lake direkt auf die Delta-Tabellen in OneLake zugreifen, ohne Import und ohne den Umweg über DirectQuery. Auf Azure Databricks führen drei Wege zur Gold-Schicht: Import in das Modell, DirectQuery gegen den SQL Warehouse, und seit Mitte 2025 Direct Lake, indem der Unity Catalog nach OneLake gespiegelt wird und Power BI ohne Kopie auf dieselben Delta-Tabellen liest. Der Umweg lohnt sich, wenn Engineering-Tiefe zählt. Microsoft Fabric beherrscht Spark, Structured Streaming und Experiment-Tracking ebenfalls, Azure Databricks ist in diesen Punkten aber weiter: mehr Kontrolle über Runtime und Rechenressourcen, ausgereiftere Streaming-Muster für den Produktivbetrieb, und mit MLflow eine vollständige Modellverwaltung samt Registry und Serving, wo Fabric derzeit vor allem Experimente nachverfolgt. Die Plattformwahl ist damit eine echte Architekturentscheidung. Sie ersetzt aber nicht die Disziplin, die über die Qualität der Berichte entscheidet: Die Kennzahlenlogik gehört in die Gold-Schicht und in das semantische Modell, nicht in den einzelnen Bericht.
Durch Arbeiten am eigenen Fall statt an Schulungsbeispielen. 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. Ein Ansprechpartner je Fachbereich, der das Modell wirklich kennt, trägt weiter als eine breit gestreute Schulung.
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.
„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, liegt das selten am Berichtswerkzeug.
In 30 Minuten klären wir: