Power BI Reporting für ein Großbauprojekt mit über 1 Mrd. CHF Volumen

Großbauprojekte erzeugen enorme Datenmengen: Projektfortschritt, Budget, Timelines, Verzögerungen, Risiken, Sitzungen, Maßnahmen und Statusinformationen liegen selten in einem einzigen System, sondern verteilt über Plattformen, Dateien und Fachanwendungen.

Auch hier kamen die relevanten Daten aus sehr unterschiedlichen Systemtypen — SQL-Server-Datenbanken, manuell gepflegten Excel-Dateien, Cloud-Systemen und Fachanwendungen, die über REST-Schnittstellen angebunden werden mussten. Manche lieferten strukturierte Daten, andere nur teilweise standardisierte Exporte. Für einzelne Teams war das handhabbar; auf Management-Ebene entstand daraus ein Problem: Informationen mussten aus vielen Quellen zusammengetragen, verglichen und interpretiert werden — ein konsistentes, aktuelles Gesamtbild war kaum möglich.

Technisch hieß das: Einzelne Power-BI-Berichte direkt an die Quellen zu hängen, reicht bei dieser Datenmenge, Systemvielfalt und Nutzerzahl nicht. Zuerst braucht es eine belastbare Datenplattform mit klaren Datenflüssen, definierten Datenmodellen, Rollenmanagement und Governance — erst darauf ein Reporting, das performant, nachvollziehbar und langfristig wartbar ist.

smiit baute eine zentrale Datenarchitektur, in der die Daten aus den Quellsystemen zunächst in Azure Databricks zusammengeführt werden — bewusst ein vorgelagerter Data-Warehouse-Ansatz statt komplexer Transformationslogik direkt in Power BI. So bleibt Power BI die analytische Oberfläche für Management und Projektsteuerung, während Integration, Harmonisierung und Qualitätslogik in einer skalierbaren Plattform stattfinden: stabilere, schnellere und langfristig besser wartbare Berichte.

Die Daten durchlaufen eine mehrstufige Bronze-/Silver-/Gold-Architektur. Im Bronze Layer werden Rohdaten möglichst unverändert aufgenommen — das schafft Nachvollziehbarkeit bis zur Quelle. Im Silver Layer werden sie bereinigt und fachlich harmonisiert: einheitliche Projekt- und Programmstrukturen, konsistente Datumslogiken, bereinigte Statuswerte sowie zusammengeführte Risiko- und Terminstrukturen.

Im Gold Layer entstehen kuratierte, auf die Analyse optimierte Datenmodelle: Management-Kennzahlen, Projektstatus, Budgetentwicklung, Terminabweichungen und Risikokategorien sind so vorbereitet, dass Power BI sie performant und verständlich auswerten kann. Daten werden damit nicht mehr punktuell visualisiert, sondern systematisch in eine belastbare Reporting-Grundlage überführt, die mit neuen Anforderungen wächst.

Ein Kernstück der Umsetzung war die Integration sehr unterschiedlicher Quellen. Strukturierte Daten aus SQL Servern wurden direkt angebunden; ergänzend verarbeitete smiit Excel-Dateien, die in Projektorganizationen weiterhin eine wichtige Rolle spielen — etwa für Statuslisten und manuelle Ergänzungen. Cloud-Systeme und Fachanwendungen kamen über REST-APIs hinzu; wo Daten nicht in der benötigten Form vorlagen, erschloss und strukturierte smiit die Schnittstellen.

Diese Arbeit ist entscheidend, weil Power BI nur so gut ist wie die Datenbasis darunter: Ein Dashboard auf uneinheitlichen, manuell kopierten Daten erzeugt im Management schnell Misstrauen. Die vorgelagerte Plattform macht Datenflüsse transparenter und fachliche Definitionen konsistenter — weniger manuelle Zusammenführung, weniger Interpretationsspielraum, eine verlässlichere Grundlage für Projektentscheidungen.

Auf den kuratierten Gold-Datenmodellen entstanden mehrere Power-BI-Berichte — vor allem für die Management-Ebene, aber auch für Programm- und Projektverantwortliche. Sie decken Projektfortschritt, Budget, Terminpläne, Verzögerungen, Sitzungen, Maßnahmen und Risiken ab und setzen diese in Beziehung: So wird etwa sichtbar, welche Terminverzögerungen mit kritischen Risiken zusammenhängen oder welche Budgetentwicklung auf welche Projektbereiche zurückgeht.

Die Reporting-Struktur ist hierarchisch — von der Management-Perspektive über Programm- und Projektebenen bis zu Detailanalysen einzelner Themenbereiche —, sodass dieselbe Landschaft strategische Steuerungsrunden und operative Detailfragen bedient. Ein Fokus lag auf Performance: Datenmodellierung, Measures, Filterlogik und Berichtsnavigation wurden so gestaltet, dass die Berichte bei großen Datenmengen, mehreren Hierarchieebenen und vielen Nutzern schnell reagieren und verständlich bleiben.

Da unterschiedliche Nutzergruppen die Berichte verwenden, war Governance zentral — nicht jeder benötigt dieselbe Sicht auf Daten und Detailinformationen. Eine rollenbasierte Struktur organisiert Zugriffe entlang der Verantwortlichkeiten: klare Workspace-Strukturen, abgestimmte Berechtigungen, kontrollierte Veröffentlichung und je nach Kontext Row-Level Security, App-Verteilung oder getrennte Entwicklungs-, Test- und Produktivbereiche.

So wird Reporting nicht zu einer unkontrollierten Sammlung einzelner Dateien, sondern zu einer verwalteten BI-Landschaft, in der klar ist, welche Berichte produktiv sind, welche Datenmodelle genutzt werden und welche Nutzergruppen Zugriff haben. Bei dieser Größenordnung ist das entscheidend: Management-Reporting muss nicht nur korrekt aussehen, sondern organisatorisch belastbar sein.

Der zentrale Zielkonflikt lag zwischen schnell sichtbaren Ergebnissen und sauberer Datenarchitektur: Ein rein reportgetriebener Ansatz führt schnell zu schwer wartbaren Power-BI-Dateien, doppelter Logik und inkonsistenten Kennzahlen. smiit löste das iterativ — zuerst MVP-Berichte, um Anforderungen sichtbar und mit Stakeholdern diskutierbar zu machen, parallel dazu die Databricks-Architektur professionalisiert. So arbeiteten Management und Fachbereiche früh mit konkreten Visualisierungen, während die technische Grundlage Schritt für Schritt stabiler wurde — schnelle fachliche Fortschritte ohne langfristige technische Sackgasse.

Der iterative MVP-Ansatz hat die Zusammenarbeit beschleunigt — aber er hatte einen Preis, den wir unterschätzt haben. Sobald die ersten ansprechenden Dashboards standen, stritten Stakeholder nicht über die Visualisierung, sondern über die Zahlen selbst: Was genau zählt als „Verzögerung“, ab wann ist ein Arbeitspaket „in Verzug“, wie ist ein „Status“ über verschiedene Quellsysteme hinweg definiert? Dieselbe Kennzahl bedeutete für verschiedene Teams und Systeme Unterschiedliches.

Damit war die vermeintliche Diskussion über die Korrektheit des Reports in Wahrheit eine Diskussion über fehlende gemeinsame Definitionen — ein Daten- und Semantikproblem, kein Tool-Problem. Wir haben daraus gelernt, die fachlichen Definitionen früher festzuzurren: ein abgestimmtes Kennzahlen-Glossar als verbindliche Logik im Gold Layer, bevor und während die Dashboards entstehen. Erst diese eine Quelle der Wahrheit beendete die wiederkehrenden Definitionsdebatten in den Status-Runden.

Über mehr als zwei Jahre entstand eine Power-BI-Reporting-Landschaft, die Daten aus SQL-Datenbanken, Excel-Dateien, Cloud-Systemen und manuellen Statusformaten zentral verarbeitet und für Management-, Programm- und Projektebene bereitstellt — statt sie einzeln zusammenzuführen. Das Ergebnis ist ein aktuelleres, einheitlicheres und besser nachvollziehbares Lagebild über das Gesamtprojekt.

Für ein Bauprojekt mit über 1 Milliarde CHF Volumen ist dieser Überblick ein erheblicher Mehrwert: Fortschritt, Budget, Termine, Verzögerungen, Sitzungen und Risiken lassen sich auf mehreren Hierarchieebenen analysieren, kritische Entwicklungen werden früher sichtbar und Statusbesprechungen datenbasierter. Technisch verbindet die Architektur Datenintegration, Data-Warehouse-Logik, Power BI Reporting, Governance und Betrieb — geschäftlich entsteht Transparenz für die Steuerung komplexer Infrastrukturprojekte.