Zum Hauptinhalt springen

Leistung

Power BI und Data Analytics

Power BI wird oft wie Excel mit saubereren Diagrammen benutzt. Ich baue Dashboards andersherum: erst das Datenmodell, dann die Measures, dann die Visuals. Das Ergebnis aktualisiert sich selbst und bricht nicht bei der nächsten neuen Datenquelle.

Bildschirm mit Analyse-Dashboard und Diagrammen auf einem Laptop
Foto: Luke Chesser / Unsplash

Das Problem

Was ich häufig vorfinde: ein Power-BI-Bericht mit einer einzigen riesigen, flachen Tabelle, DAX-Measures, die eigentlich berechnete Spalten sind, und ein Refresh, den seit dem Weggang der ursprünglichen Ersteller niemand mehr anfassen will. Jede neue Kennzahl bedeutet eine neue Spalte in der Rohtabelle statt einer neuen Measure im Modell.

Datenquellen sind oft ein Sammelsurium: ein SQL-Export hier, eine manuell gepflegte Excel-Liste dort, ein SharePoint-Ordner mit monatlichen CSV-Dateien. Ohne sauberes Star-Schema wächst mit jeder neuen Quelle die Fehleranfälligkeit, und niemand kann mehr erklären, warum zwei Kennzahlen auf zwei Berichtsseiten leicht unterschiedliche Zahlen zeigen.

Microsoft Fabric und die Azure-Anbindung machen es nicht automatisch besser. Ohne durchdachtes Datenmodell verlagert sich das Excel-Chaos nur in eine teurere Cloud-Umgebung.

Die Lösung

Ich baue das Datenmodell zuerst: Star-Schema mit klar getrennten Fakten- und Dimensionstabellen, Beziehungen statt verschachtelter SVERWEIS-Logik, Measures statt berechneter Spalten. Das ist der Unterschied zwischen einem Dashboard, das in einem Jahr noch verständlich ist, und einem, das schon nach drei Monaten niemand mehr erweitern will.

Power Query übernimmt die Anbindung an die Quellen (SQL Server, Azure, SharePoint, Excel-Exporte), inklusive Query Folding, wo die Quelle es hergibt, und Microsoft-Fabric-/Lakehouse-Komponenten, wenn Datenmenge oder Governance-Anforderungen das rechtfertigen. DAX-Measures sind dokumentiert und nach Themenbereich organisiert, nicht als unsortierte Liste.

Lieferumfang: ein dokumentiertes Datenmodell, wiederverwendbare Measures, ein Aktualisierungsplan (geplanter Refresh im Power BI Service oder über ein On-Premises-Gateway), und ein README, das erklärt, welche Kennzahl wo herkommt und warum.

Typische Anwendungsfälle

  • Ablösung einer manuell gepflegten Reporting-Excel-Datei durch ein Power-BI-Dashboard mit automatischem Refresh
  • Star-Schema-Aufbau für ein bestehendes, gewachsenes Power-BI-Modell mit widersprüchlichen Kennzahlen
  • Anbindung von SQL Server, Azure-Datenquellen oder Microsoft Fabric/Lakehouse an ein Power-BI-Modell
  • DAX-Audit: bestehende Measures prüfen, Performance-Probleme und falsche Kontextübergänge beheben
  • Executive-Dashboards mit klarer KPI-Definition und Drill-Down statt einer Diagramm-Sammlung ohne roten Faden
  • Migration von Excel-Pivot-Reporting auf Power BI, inklusive kurzer Schulung fürs Team

Konkreter Nutzen

  • Ein Datenmodell, keine Kopien: Kennzahlen stimmen über alle Berichtsseiten hinweg überein
  • Automatischer Refresh statt manueller Excel-Pflege, geplant im Power BI Service oder Gateway
  • DAX-Measures sind dokumentiert und für einen zweiten Analysten in ein bis zwei Tagen nachvollziehbar
  • Skalierbar Richtung Microsoft Fabric, wenn Datenmenge oder Governance es später verlangen
  • Weniger falsche Kennzahlen, weil die Logik einmal im Modell steckt statt mehrfach in Excel-Formeln
Nahaufnahme einer Hand, die mit einem Stift Daten auf einem Tablet mit Diagrammen prüft
Foto: Jakub Żerdzicki / Unsplash

So läuft die Zusammenarbeit

  1. Audit des bestehenden Berichts oder der Anforderung (1-2 Tage)

    Welche Kennzahlen gibt es, woher kommen die Daten, wo widersprechen sich Zahlen? Output ist ein priorisierter Plan für Datenmodell und Measures.

  2. Datenmodell und Power-Query-Anbindung aufbauen

    Star-Schema, Beziehungen, Query-Folding-taugliche Power-Query-Schritte. Bei Bedarf Anbindung an Microsoft Fabric/Lakehouse oder Azure-Quellen.

  3. DAX-Measures und Visuals

    Measures nach Themenbereich dokumentiert, Berichtsseiten mit klarer Navigation, Drill-Down wo sinnvoll, keine Diagramm-Sammlung ohne Zusammenhang.

  4. Übergabe mit Refresh-Plan und Walkthrough

    README mit Kennzahlen-Herkunft, geplanter Aktualisierung, Wartungshinweisen. 60-90 Minuten Live-Walkthrough mit Aufzeichnung.

Häufige Fragen

Power BI vs. Excel: wann lohnt sich der Umstieg?

Sobald mehrere Personen denselben Report unterschiedlich interpretieren, sobald der Report monatlich von Hand aktualisiert wird, oder sobald mehrere Datenquellen zusammenlaufen. Für einen einmaligen Auswertungsbedarf reicht oft weiter Excel plus Power Query, ohne Power BI obendrauf.

Was kostet ein typisches Power-BI-Projekt?

Abgerechnet wird zu 100 Euro pro Stunde, der Gesamtaufwand hängt stark von der Anzahl der Datenquellen und Kennzahlen ab. Ein reiner DAX-/Modell-Audit einer bestehenden Datei ist deutlich günstiger als ein Dashboard-Neubau. Nach dem Discovery-Workshop gibt es einen belastbaren Rahmen.

Brauchen wir Power BI Pro oder reicht die kostenlose Version?

Power BI Desktop zum Bauen ist kostenlos. Pro brauchen Sie, sobald Sie Berichte im Power BI Service mit anderen teilen wollen. Für einen einzelnen Nutzer ohne Sharing reicht oft die kostenlose Variante.

Wie hängt das mit Microsoft Fabric zusammen?

Fabric lohnt sich, wenn die Datenmenge oder die Governance-Anforderungen über ein klassisches Power-BI-Modell hinauswachsen, etwa bei einem Lakehouse mit mehreren nachgelagerten Verbrauchern. Für die meisten Mittelstands-Dashboards reicht Power BI mit sauberem Power-Query-Unterbau, Fabric ist kein Automatismus.

Können wir das Modell später selbst erweitern?

Ja, wenn Measures dokumentiert und nach Themenbereich sortiert sind. Eine Person mit DAX-Grundkenntnissen erweitert in ein bis zwei Tagen. Tiefere Fragen (Kontextübergänge, Performance bei großen Modellen) sind ein guter Retainer-Fall.

/ Nächster Schritt

Power-BI-Modell auditieren oder neu aufbauen lassen?

Beschreiben Sie kurz, welche Kennzahlen heute noch manuell zusammengetragen werden und woher die Daten kommen. Sie bekommen eine ehrliche Einschätzung, wo das Datenmodell ansetzen sollte.