Wir nehmen euch in dieser Episode mit auf genau diese Schwelle. Kein Dogma, sondern praktische Leitplanken: Woran erkennt man, dass es Zeit ist, vom Tool zur Plattform zu denken? Zum Beispiel, wenn • dieselbe Kennzahl in drei Workspaces drei Bedeutungen hat, • Refresh-Fenster den Morgen dominieren und jede Änderung Zittern auslöst, • neue Quellen (API, Stream, Files, ERP) euch zwingen, Logik mehrmals zu erfinden, • Kunstgriffe oder Workarounds in Power BI nötig sind, die eine Plattform eleganter lösen könnte, • Audits, Datenschutz oder Datenfreigaben an Grenzen stoßen, • Verantwortung und Betrieb auf wenige Personen verteilt sind und Urlaub plötzlich zur Herausforderung wird, • ihr euch nach Versionierung, automatischen Tests, Lineage-Transparenz und einem zentralen Metrik-Katalog sehnt. Eine Datenplattform ist kein Selbstzweck. Sie wird dann sinnvoll, wenn sie das liefert, was Power BI allein nur begrenzt abbildet: ein gemeinsames Regelwerk, wiederverwendbare Logik, kontrollierte Releases, offene Formate, klare Ownership und die Fähigkeit, mit dem Geschäft zu wachsen, nicht nur mitzuhalten. Wie sehen es Andreas und Marcus? Bei Marcus ist der Plattform-Schritt fällig, wenn Definitionen und Zuständigkeiten wichtiger werden als das nächste visuelle Feature. Sein Punkt: Business-Regeln, Datenverantwortung, Datenkatalog und Freigabeprozesse zuerst klarziehen, dann Technik auswählen. „Eine Plattform ist am Ende ein Versprechen: gleiche Wahrheit, egal wo du schaust.“ Andreas spürt den Moment, wenn CI/CD, offene Formate (z. B. Parquet/Delta), Orchestrierung, Dev/Test/Prod und reproducible Deployments den Unterschied machen. Für ihn ist die Plattform die Chance, Logik aus Berichten ins Fundament zu ziehen, Abhängigkeiten sichtbar zu machen und Skalierung ohne Drama zu ermöglichen. Beide wollen, dass Fachlichkeit und Technik wieder an einem Ort zusammenfinden, der Code unterstützt das Regelwerk und ersetzt es nicht. Ob ihr bei Power BI bleibt oder eine Plattform baut, entscheidet letztlich die Frage, wie ihr dauerhaft konsistente, nachvollziehbare und skalierbare Antworten liefert. Unsere drei Learnings 1. Zielbild vor Werkzeug: Erst klären, welche Regeln, Datenprodukte und Verantwortlichkeiten ihr braucht, dann die Plattform bauen. 2. Plattform = Betriebsmodell: Nicht „ein Projekt“, sondern Standards, Automatisierung und Ownership, die jeden Tag wirken und Lasten verteilen. 3. Wachstum in kleinen Schritten: Von bestehenden Berichten aus iterativ migrieren: Katalog, Lineage, Git, Tests – Stück für Stück, aber konsequent. Diskussionsfragen an euch • Wann habt ihr gemerkt: Power BI only reicht nicht mehr und was war der Auslöser? • Weiter veredeln oder Plattform-Schritt? Nach welchen Kriterien entscheidet ihr (Governance, Skalierung, Performance, Compliance, Teamgröße)? • Wie sorgt ihr dafür, dass bestehende Berichte während des Umbaus stabil bleiben? • Welche Methoden/Tools (z. B. Git-Integration, Autoscaling, Copilot, Lineage-Viewer) helfen euch, Definitionen zu harmonisieren, Transparenz zu schaffen und Releases zu automatisieren? • Setzt ihr eher auf offene, austauschbare Komponenten oder auf vorkonfigurierten Content und warum? • Wie verteilt ihr Betrieb und Verantwortung im Team und wie verhindert ihr, dass Urlaub oder Krankheit zum Risiko wird? Teilt eure Erfahrungen, von der ersten Git-Verzweigung bis hin zum zentralen Datenprodukt-Katalog und bringt eure Tipps und Perspektiven rund um Modellpflege, Weiterentwicklung und nachhaltige BI-Lösungen ein. Wir sind gespannt und freuen uns auf eure Beiträge!