Das Problem: Viele Wahrheiten, kein Vertrauen
In vielen Unternehmen existieren Dutzende Reports — aber niemand vertraut den Zahlen. Jede Abteilung hat eigene Excel-Dateien, eigene Definitionen und eigene Versionen der Wahrheit. Das Ergebnis: Meetings werden damit verbracht, über Zahlen zu diskutieren statt über Entscheidungen.
Eine Single Source of Truth (SSOT) bedeutet: Ein Datenmodell, eine Definition, ein Report — für alle.
Architektur einer Enterprise-BI-Lösung
Schicht 1: Data Warehouse
Power BI ist ein Präsentations-Tool, kein Data Warehouse. Die SSOT entsteht nicht in Power BI selbst, sondern in der darunterliegenden Datenschicht:
- Azure Synapse / SQL Server für strukturierte Daten
- Delta Lake / Databricks für hybride Workloads
- Star Schema als bewährtes Datenmodell für analytische Abfragen
Schicht 2: Semantisches Modell
Das Power BI Dataset (semantisches Modell) definiert die Geschäftslogik:
- Measures: Zentral definierte Kennzahlen (Umsatz, Marge, Conversion)
- Beziehungen: Korrekte Verknüpfungen zwischen Tabellen
- Hierarchien: Zeit, Geographie, Produktkategorien
- Row-Level Security (RLS): Wer sieht welche Daten
Schicht 3: Reports und Dashboards
Die Visualisierungsschicht nutzt das zentrale semantische Modell. Keine lokalen Datenquellen, keine importierten Excel-Dateien, keine eigenständigen Berechnungen.
Governance: Die unterschätzte Dimension
Zertifizierte Datasets
Power BI unterscheidet zwischen „promoted” und „certified” Datasets:
- Promoted: Vom Ersteller als nützlich markiert
- Certified: Von der BI-Governance als offiziell bestätigt
Nur zertifizierte Datasets sollten für unternehmensweite Reports verwendet werden.
Workspace-Strategie
- Entwicklung: Workspace für Prototypen und Tests
- Produktion: Separater Workspace mit kontrolliertem Deployment
- Self-Service: Workspace für Fachabteilungen mit klaren Regeln
Namenskonventionen
Klingt trivial, ist entscheidend: Wenn jeder Report „Umsatz Q2” heißt, findet niemand den richtigen. Definieren Sie Konventionen:
[Bereich]_[Thema]_[Version] — z.B. Vertrieb_Pipeline_v3.1
Typische Fehler und wie man sie vermeidet
1. Direkte Datenbankverbindung statt Data Warehouse
Wenn Power BI direkt auf operative Datenbanken zugreift, entstehen Performance-Probleme und inkonsistente Daten. Immer über ein Data Warehouse gehen.
2. Import Mode für alles
Import Mode lädt Daten in Power BI. Bei großen Datenmengen (>10 GB) wird das Management aufwändig. DirectQuery oder Composite Mode für große Tabellen in Betracht ziehen.
3. Zu viele Measures in einem Dataset
Ein Dataset mit 500 Measures ist unwartbar. Gruppieren Sie Datasets nach Geschäftsbereichen und verwenden Sie Shared Datasets für bereichsübergreifende Kennzahlen.
4. Keine automatische Aktualisierung
Reports, die manuell aktualisiert werden, sind keine SSOT. Richten Sie automatische Aktualisierungszyklen ein — mindestens täglich für operative Reports.
Implementierungsfahrplan
Phase 1 (4-6 Wochen): Data Warehouse aufbauen, Star Schema für 2-3 Kernbereiche, automatische Datenladung
Phase 2 (2-4 Wochen): Semantisches Modell erstellen, zentrale Measures definieren, RLS konfigurieren
Phase 3 (2-3 Wochen): Reports und Dashboards für Pilotgruppe, Feedback sammeln, iterieren
Phase 4 (laufend): Ausrollen, Schulung, Governance etablieren, Self-Service ermöglichen
Fazit
Power BI kann eine echte Single Source of Truth liefern — aber nur mit der richtigen Architektur und Governance. Das Tool allein reicht nicht. Investieren Sie in das Datenmodell und die Prozesse dahinter, dann investiert sich die Visualisierung fast von selbst.