The Data Brothers

In dieser Episode sprechen wir über die Fabcon Vienna. Welche Features haben uns überrascht, welche Ankündigungen fanden wir besonders spannend und welche kleinen, fast versteckten Dinge haben das Potenzial, den Alltag von Entwickler:innen und Datenprofis massiv zu verändern? Was haben wir mitgenommen? • Copilot überall: Kaum eine Session ohne KI. Egal ob Entwicklung, Datenmodellierung oder Administration. Copilot ist inzwischen tief in Fabric integriert und verändert die Art, wie wir mit der Plattform arbeiten. • User Defined Functions: Ein Feature, das in den großen Ankündigungen fast unterging, aber enormes Potenzial bietet. Für uns ein „Hidden Gem“. • REST-API mit Third-Party-Integration: Spannend zu sehen, wie offen Fabric inzwischen geworden ist, von der API bis hin zur Zusammenarbeit mit externen Tools. • Projektfile-Struktur in Power BI: Endlich mehr Ordnung im Entwicklungsprozess, die neue Struktur bringt Klarheit, Nachvollziehbarkeit und erleichtert Teamarbeit enorm. • Visual Studio Code Add-in: Für viele ein Gamechanger, um Power BI und Fabric-Entwicklung nahtlos in den gewohnten Entwicklungs-Workflow zu integrieren. • Featurefeuerwerk am ersten Tag: So viele Neuheiten in so kurzer Zeit, man merkte, wie schnell Microsoft das Tempo hochschraubt. Wie sehen es Andreas und Marcus? Für Andreas war der KI-Schwerpunkt der große Aha-Moment: „Es ist kein Add-on mehr, Copilot ist fester Bestandteil, das verändert die Arbeitsweise fundamental.“ Marcus dagegen schwärmt von den kleinen Dingen: „User Defined Functions klingen unscheinbar, aber wenn man tiefer einsteigt, merkt man: Damit lassen sich Prozesse viel schlanker bauen.“ Diskussionsfragen an euch • Welche Ankündigung der Fabcon Vienna war euer Highlight? • Wo seht ihr den größten Nutzen von Copilot im Alltag? • Nutzt ihr schon die neue Projektfile-Struktur in Power BI und wie verändert sie eure Arbeitsweise? • Habt ihr das Visual Studio Code Add-in getestet und wie integriert ihr es in eure Prozesse? • Glaubt ihr, dass die „Hidden Features“ am Ende wichtiger werden als die großen Ankündigungen? Wir sind gespannt auf eure Eindrücke, teilt sie mit uns und lasst uns wissen, was für euch das Highlight der Fabcon war!

Wir nehmen euch in dieser Episode mit zu genau dieser Frage: Wie nutzt ihr Fabric effizient und spart CUs dabei? Kein Dogma, sondern praktische Leitplanken: Woran erkennt man, dass es Zeit ist, genauer hinzusehen, und welche Ansätze helfen? Zum Beispiel, wenn • Funktionen im Hintergrund mehr CUs ziehen, als ihr dachtet, • eine einzelne Abfrage oder ein Feature überproportional Kapazität frisst, • neue Workloads plötzlich dieselbe Fabric-Instanz teilen müssen, • ihr merkt, dass ihr CUs nicht gezielt „deckeln“ könnt, sondern über Architektur und Nutzung steuert, • ihr euer Guthaben für Leistung immer häufiger nachkaufen müsst. Eine bewusste Nutzung von Fabric ist kein Selbstzweck. Sie wird dann wichtig, wenn ihr CUs nicht nur im Tagesgeschäft „verheizt“, sondern gezielt einsetzt, für die Workloads, die Mehrwert bringen, für geteilte Instanzen, die sinnvoll organisiert sind, und für Features, die ihr wirklich braucht. Wie sehen es Andreas und Marcus? Für Marcus ist das Thema fällig, wenn verschiedene Teams auf derselben Instanz arbeiten und der Verbrauch unkontrolliert steigt. Sein Punkt: Nutzung transparent machen, Verbräuche zuordnen, Governance klären, erst dann habt ihr die Basis, um effizient mit CUs umzugehen. „Ohne Transparenz bleibt jede Optimierung Zufall.“ Andreas spürt den Moment, wenn Features wie Streaming, ML-Experimente oder Dataflows plötzlich die Kapazität dominieren. Für ihn heißt Einsparen: Workloads konsolidieren, Standardpfade nutzen, Instanzen teilen und nur dort eigene Ressourcen aufbauen, wo sie wirklich gebraucht werden. „Fabric belohnt Klarheit: Wer weiß, was läuft, spart.“ Oder sagen Beide eher: Fachlichkeit und Technik müssen auch hier zusammenspielen, nur so gelingt es, CUs als gemeinsame Ressource fair und effizient einzusetzen. Unsere drei Learnings 1. Verbrauch sichtbar machen. Erst verstehen, welche Komponenten wie viele CUs benötigen, dann optimieren. 2. Instanzen teilen & Regeln setzen. Ein Fabric-Service, viele Workloads, klare Governance verhindert Überlast, Wildwuchs und verteilt die Kosten fair. 3. Bewusste Nutzung statt Vollgas. Nicht jedes Feature sofort aktivieren, überdenkt, ob sie echten Mehrwert liefert. Diskussionsfragen an euch • Wann habt ihr gemerkt, unser CU-Guthaben schmilzt zu schnell und was war der Auslöser? • Welche Strategien nutzt ihr, um Verbrauch transparent zu machen? • Teilt ihr Fabric-Instanzen zwischen Teams und wie regelt ihr dabei Verantwortung? • Welche Features sind für euch „Must-have“, welche eher Luxus? • Wie sorgt ihr dafür, dass der Betrieb stabil bleibt, auch wenn die Kapazität knapp wird? Teilt eure Erfahrungen, von ersten Monitoring-Ansätzen bis hin zu Regeln für die gemeinsame Nutzung von Fabric und bringt eure Tipps ein, wie man Leistung bewusst steuert, statt CUs zu verschwenden. Wir sind gespannt und freuen uns auf eure Beiträge!

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!

Wir reden über diesen Moment, in dem du ein altes Power-BI-Modell öffnest, eine kleine Änderung machen willst und plötzlich starrt dich eine Zahl an, die nie so hätte existieren dürfen. Jahre lang hat’s niemand gemerkt, weil die Berichte „funktionierten“. In der Zwischenzeit hat sich der Business Case leise verschoben. Also was tun mit Fehlern aus altem Code, weiterflicken oder neu denken? Und die eigentliche Gretchenfrage, sind eure Business Cases wirklich beschrieben oder ist der Code längst zur heimlichen Spezifikation geworden? In dieser Episode nehmen wir euch mit in den Maschinenraum. Wir sprechen von Bugs, die nicht laut krachen, sondern nur ein bisschen schieben, bis sie ganze Entscheidungen in die falsche Richtung lenken. Wir müssen uns dann fragen: Was ist hier eigentlich die Wahrheit, die Fachregel von heute oder die Logik von damals? Woher kommt der Fehler? Wen trifft er wirklich? Und was passiert mit den Berichten, die jeden Morgen pünktlich in Postfächern landen? Manchmal reicht ein sauberer, kleiner Fix. Manchmal merkt man, der Code erzählt eine Geschichte, die niemand mehr unterschreiben würde. Dann hilft nur aufräumen und anpassen, so dass das Modell wieder zu dem passt, was das Business heute ist. Wir sprechen darüber, wie man währenddessen den Laden am Laufen hält, wie man Änderungen sichtbar macht, ohne Panik zu verbreiten, und warum ein paar gut erzählte Business-Regeln mehr bewirken als der schönste DAX-Zauber. Wie sehen es Andreas und Marcus? Marcus schaut zuerst auf die Governance-Seite. Für ihn ist klar, dass man Altfehler nicht einfach technisch beheben darf, ohne vorher die fachliche Grundlage zu prüfen. Sein Ansatz, erst definieren, wie es „heute“ richtig sein müsste und das sauber dokumentieren. Dann kann der Code angepasst werden. „Ein Bug ist oft nur das Symptom dafür, dass niemand mehr weiß, wie die Logik eigentlich gemeint war.“ Andreas kommt von der technischen Seite. Er sieht alte Fehler als Chance, die Architektur zu verbessern. Für ihn ist jeder Fund ein „Eintrittsticket“ in den Code, um aufzuräumen, zu modularisieren und Abhängigkeiten zu reduzieren. Sein Credo: „Wenn ich schon am offenen Herzen operiere, dann auch gleich den Bypass legen, der uns künftige Probleme erspart.“ Beide wollen, dass am Ende Fachlichkeit und Technik wieder übereinstimmen und dass der Code nicht länger als heimliche Dokumentation herhalten muss. Unsere drei Learnings 1. Transparenz vor Technik: Erst Klarheit über die fachlichen Regeln schaffen, dann bauen. Sonst bleibt jeder Fix ein Ratespiel. 2. Altfehler sind Organisationsfehler: Ohne Zuständigkeiten, Tests und klare Definitionen bleiben Bugs unsichtbar, oft über Jahre. 3. Struktur schlägt Aktionismus: Kleine, getestete Schritte mit klaren Guardrails verhindern das Fass-ohne-Boden-Gefühl. Diskussionsfragen an euch • Wo seid ihr zuletzt auf einen Altfehler gestoßen und warum konnte er so lange unentdeckt bleiben? • Fix oder Redesign? Nach welchen Kriterien trefft ihr die Entscheidung in der Praxis? • Ist bei euch der Business Case sauber beschrieben oder beschreibt der Code (noch) die Realität? • Wie stellt ihr sicher, dass bestehende Berichte während der Korrektur weiter funktionieren? • Welche Methoden/Tools helfen euch, Abhängigkeiten sichtbar zu machen und strukturiert aufzuräumen? Wir freuen uns auf eure Erfahrungen, Tipps und Perspektiven rund um Modellpflege, Weiterentwicklung und nachhaltige BI-Lösungen!

Jede Modellüberarbeitung beginnt mit einer ehrlichen Bestandsaufnahme. Wir beleuchten, woran man erkennt, ob punktuelle Anpassungen ausreichen oder ob ein Neuanfang nötig ist. Was ist eigentlich noch wartbar? Was hängt alles dran, auch an den bestehenden Berichten? Und wie vermeiden wir es, in endlosen Detailanpassungen zu versinken? Stakeholder statt Einzelkämpfer, wer gehört an den Tisch? Ein Power BI Modell ist nie nur ein technisches Artefakt, es ist Teil eines größeren Ökosystems. Wir sprechen darüber, wie viele (und welche) Stakeholder eingebunden werden müssen, damit Änderungen auch strategisch sinnvoll sind. Wer entscheidet, was bleiben muss und wer versteht, welche Anpassungen welche Auswirkungen haben? Kein Fass ohne Boden, wie wir gezielt vorgehen Oft beginnt es mit einem kleinen Wunsch und endet im kompletten Umbau. Wir diskutieren, wie man die Kontrolle behält, realistische Ziele setzt und vermeidet, in technischem Perfektionismus zu versinken. Auch wichtig: Wie dokumentieren wir sinnvoll, was wir tun und für wen? Komplexität verstehen und trotzdem vereinfachen In vielen Modellen geht es längst nicht mehr nur um einfache Kennzahlen. Unterschiedliche Logiken, heterogene Datenquellen und sich verändernde Anforderungen machen das Ganze schnell unübersichtlich. Wir zeigen, wie man auch in komplexen Situationen handlungsfähig bleibt und warum technisches Know-how allein oft nicht reicht. Tools können dabei unterstützen: Der Measure Killer zum Beispiel hilft, Abhängigkeiten aufzudecken und sichtbar zu machen und so besser zu verstehen, was man überhaupt umbaut. Bestandsschutz trifft Innovation, was muss bleiben? Berichte, Dashboards, vertraute Strukturen in vielen Organisationen darf Bestehendes nicht verändert werden. Doch wie passt das zur Weiterentwicklung? Wir sprechen über Strategien, wie man bestehende Auswertungen erhält, ohne Innovation zu blockieren. Unsere drei Learnings: 1. Technik ist nicht alles: Gute Entscheidungen beginnen mit einem klaren Zielbild, nicht mit Tools. 2. Einbindung ist der Schlüssel: Wer nicht von Anfang an die richtigen Personen einbindet, scheitert am Ende an Akzeptanz. 3. Komplexität braucht Struktur: Gute Modelle wachsen mit, aber nur, wenn man regelmäßig ausmistet. Diskussionsfragen an euch: • Wann habt ihr zuletzt ein Power BI Modell überarbeitet und warum? • Wie entscheidet ihr, ob ihr neu startet oder weiterentwickelt? • Welche Tools oder Methoden helfen euch, den Überblick zu behalten? • Wie stellt ihr sicher, dass bestehende Berichte weiterhin funktionieren? • Welche Rolle spielt euer Team und wie holt ihr alle ins Boot? Wir freuen uns auf eure Erfahrungen, Tipps und Perspektiven rund um Modellpflege, Weiterentwicklung und nachhaltige BI-Lösungen!

Zehn Jahre Power BI bedeuten auch zehn Jahre BI-Erfahrungen, Community-Wachstum und technologische Reife. Von den ersten Self-Service-Berichten bis zum unternehmensweiten Datenportal mit integriertem Copilot: Power BI hat sich massiv weiterentwickelt und mit ihm unser Verständnis von Datenarchitektur, Verantwortung und Plattformstrategie. Und wie unterscheidet sich das heutige Arbeiten mit Daten von der klassischen OLAP-Welt? Wir sprechen über technologische Entwicklungen, den Community-Spirit und darüber, warum Self Service heute anders gedacht werden muss. Von der ersten Henry-Eule zum Tabular-Supermodell Wer erinnert sich noch an die frühen Zeiten mit Henry der Eule? Damals war BI vor allem bunt, schnell und oft ein wenig chaotisch. Heute denken wir in semantischen Modellen, Git-Integration, Datenklassifikation und Mandantenfähigkeit. Unsere langjährige Erfahrung hat uns gelehrt: Ohne robuste Governance wird jedes noch so schöne Modell irgendwann zur Blackbox. Self Service schafft Freiheit, benötigt aber Standards Power BI ist heute so zugänglich wie nie: Kein Server, keine Installation, einfach loslegen. Das ist einerseits ein Riesenvorteil. Andererseits entstehen neue Herausforderungen: Wer ist wofür verantwortlich? Wie sorgen wir für Datenqualität und Wiederverwendbarkeit? Und was passiert, wenn Self Service aus dem Ruder läuft? Community als Rückgrat der Entwicklung Was uns von Anfang an geholfen hat, war die Power BI Community. Foren, User Groups, Blogs, Meetups, der Austausch ist enorm. Viele Lösungen stammen nicht aus der Dokumentation, sondern aus der Praxis anderer. Diese Kultur des Teilens ist ein echtes Alleinstellungsmerkmal und einer der Gründe, warum Power BI sich so schnell weiterentwickeln konnte. Unsere Erfahrungen nach 10 Jahren Power BI: • Ohne Community wären wir an vielen Stellen nicht weitergekommen. • Die Einfachheit des Einstiegs darf nicht über die Komplexität der Verantwortung hinwegtäuschen. • Das Tabular-Modell erfordert ein neues Denken, weit über klassische OLAP-Konzepte hinaus. Diskussion mit euch: • Welche Rolle spielt Power BI heute in eurer Plattformstrategie, eher integrierter Kern oder austauschbares Frontend? • Wo zieht ihr die Grenze zwischen Cloud-Komfort und technischer Unabhängigkeit? • Welche Power BI-Erlebnisse sind euch besonders im Kopf geblieben? • Wie hat sich eure Arbeit mit Datenmodellen über die Jahre verändert? • Was war euer größter Aha-Moment oder euer größter Frust? • Wie nutzt ihr heute die Power BI Community, aktiv oder eher lesend? 10 Jahre Power BI und kein bisschen leise. Wir freuen uns auf eure Erfahrungen!

Standortbestimmung, nicht nur, wo wir sind, sondern wo wir hinwollen Was machen wir gut und was davon macht uns wirklich stark? Wir beleuchten, wie man sich selbst besser einschätzt, wo blinde Flecken lauern und warum ehrlicher Austausch mit Kollegen und Kunden oft der beste Spiegel ist. Standortbestimmung ist kein Selbstzweck, sondern ein wichtiger Schritt für gezielte Weiterentwicklung. Wo laufen wir im Alltag auf Autopilot und wo fängt echtes Lernen an? In dieser Folge sprechen wir darüber, wie man seine eigenen Stärken erkennt und gleichzeitig offen für Entwicklung bleibt. Technische Exzellenz beginnt im Anspruch an uns selbst. Exzellenz wird oft mit Zertifikaten oder Tools verwechselt. Aber technische Exzellenz zeigt sich nicht im Technik-Stack, sondern in der Qualität von Lösungen, im Verständnis für Prozesse und im Umgang mit Komplexität. Wir fragen uns: Wie erkennt man Exzellenz, bei sich selbst und im Team? Und wie entwickeln wir sie weiter? Bin ich Anwender, Entwickler, Übersetzer oder Impulsgeber? Wo geht die Reise hin, persönlich wie organisatorisch? Strategische Ausrichtung ist kein Thema nur für Führungskräfte. Auch auf individueller Ebene stellt sich die Frage: Welche Technologien, welche Methoden und welche Rollen passen zu mir. Wir neigen dazu, uns am lautesten, sichtbarsten oder bequemsten zu orientieren. Aber, wer wirklich weiterkommen will, braucht Vorbilder, die inspirieren. Selbsteinschätzung trifft Realität, warum Standortbestimmung kein Einmal-Workshop ist Ein realistisches Bild von sich selbst zu haben, ist schwer und selten endgültig. Standortbestimmung ist ein Prozess, keine Momentaufnahme. Wir zeigen, warum Offenheit und Neugier entscheidender sind als perfekte Pläne. Feuer weitergeben, statt sich verbrennen zu lassen Wer brennt, kann andere entfachen oder sich im Alleingang erschöpfen. Wir diskutieren, wie gute Kollegen andere motivieren können, ohne sich selbst zu verlieren. Und warum echter Austausch mehr bringt als jede Einzelperformance: Wenn man voneinander lernt, wächst das ganze Team. Unsere drei Learnings sind auch wieder dabei, hört mal rein. Diskussionsfragen an euch: • Wie bestimmt ihr euren Standort, individuell oder im Teamkontext? • Welche Rolle spielen Kollegen, Vorbilder oder Mentoren in eurer Entwicklung? • Was bedeutet für euch „Feuer weitergeben“ und wie gelingt es, ohne auszubrennen? • Wie verhindert ihr, dass sich starke Teammitglieder an schwächeren ausrichten? • Wie bringt ihr eure eigenen Ziele mit denen eures Teams oder Unternehmens in Einklang? Wir freuen uns wie immer auf eure Gedanken, Erfahrungen und Impulse aus der Praxis!

Self Service für alle? Chancen, Risiken und der richtige Einstieg Self Service klingt nach Freiheit, Effizienz und direktem Zugriff auf Daten, doch ist es für jeden geeignet? In dieser Episode diskutieren wir, wie niedrig die Einstiegshürden wirklich sein sollten, ob eine Schulung verpflichtend sein muss und wie man mit der unausweichlichen Schatten-IT umgehen kann. Außerdem: Ist „Dashboard in a Day“ ein guter Start? Kann jeder Self Service und sollte es jeder dürfen? Self Service eröffnet Fachanwenderinnen ganz neue Möglichkeiten. Daten analysieren, Dashboards bauen, Erkenntnisse gewinnen und das ohne langes Warten auf die IT. Aber nicht jeder hat die nötige Erfahrung oder das Verständnis für Datenqualität, Modellierung und Governance. Die Technik ist einfach, aber die Verantwortung bleibt komplex. Brauchen wir eine Art „Führerschein“ für Self Service? Die Frage ist provokant, aber legitim. Sollte man einfach loslegen dürfen oder braucht es eine Basisqualifikation? Ein Datenführerschein klingt bürokratisch, könnte aber helfen, Risiken wie Fehlinterpretationen oder Datenchaos zu vermeiden. Denn Self Service ohne Schulung ist wie Autofahren ohne Fahrschule. Man kommt voran, aber das Risiko steigt. Schatten-IT – unvermeidbar oder steuerbar? Die Realität ist klar. Wenn zentrale Lösungen zu träge sind, holen sich Fachbereiche ihre Tools selbst, ob erlaubt oder nicht. Schatten-IT ist oft kein böser Wille, sondern Ausdruck von Pragmatismus. Der bessere Weg: Hürden senken, sinnvolle Governance etablieren und den Dialog mit den Fachbereichen suchen, denn die Leute werden es sich sowieso holen. Wie fängt man an und wie hoch ist die Lernkurve? Ein gutes Onboarding ist entscheidend. „Dashboard in a Day“ ist dafür ein beliebter Einstieg. Kompakt, praxisnah, und es vermittelt zentrale Konzepte. Aber es bleibt dabei nicht. Wer tiefer einsteigen will, muss sich mit Datenmodellen, DAX, Sicherheit und Performance beschäftigen. Die Lernkurve ist da, aber mit den richtigen Formaten gut zu meistern. Self Service ist kein Selbstläufer So groß die Potenziale sind, Self Service ist keine Plug-&-Play-Lösung. Es braucht klare Rahmenbedingungen, Schulungsangebote, Unterstützer und Governance. Die Tools sind da, die Begeisterung auch, jetzt kommt es auf Strukturen an, die beides zusammenbringen. Unsere drei Learnings sind auch wieder dabei, hört mal rein. Diskussionsfragen an euch: • Welche Einstiegspunkte funktionieren in euren Organisationen? (z. B. „Dashboard in a Day“) • Wo zieht ihr die Grenze zwischen Empowerment und Kontrolle? • Wer sollte Self Service machen dürfen? Jede*r, oder nur mit Schulung? • Wie geht ihr mit Schatten-IT um? Verbieten, dulden oder integrieren? Wir freuen uns auf eure Meinungen und Erfahrungen!

Was kann Translytical Data Flow eigentlich genau leisten? In dieser Folge tauchen wir in das Konzept ein, das die klassische Trennung zwischen Analyse und operativen Prozessen auflösen kann? Wir beleuchten, wie dieser Ansatz in der Praxis funktioniert, welche technischen Voraussetzungen nötig sind und wo die größten Chancen und Herausforderungen liegen. Besonders überzeugend war ein Tutorial, das wir ausprobiert haben: Es macht die Funktionsweise direkt greifbar, weil man sofort selbst mit echten Daten arbeiten kann. Diese unmittelbare Umsetzbarkeit hilft Teams, schneller zu verstehen, wie sie Translytical Data Flow sinnvoll in ihre Systeme integrieren können. Doch es gibt auch Grenzen: Eine Logikfunktion fehlt aktuell, was komplexe Entscheidungsregeln erschwert. Hier bleibt es spannend, ob und wie das Feature weiterentwickelt wird und die Community Wünsche und Input liefert. Der Gedanke, dass Datenprozesse nicht mehr „nachgelagert“ sind, sondern Teil der eigentlichen Anwendung werden machen es interessant, oder? Und ganz klar: Planungsapplikationen in Power BI kann Translytical Data Flow (noch) nicht ersetzen. Es fehlen zentrale Funktionen wie: • Splashing (Werteverteilung auf einzelne Ebenen) • Verteilen von Planwerten auf Benutzer oder Organisationseinheiten • Master-Data-Pflege, also das strukturierte Management von Stammdaten Drei Erkenntnisse und Tipps aus der Folge: 1. Gute Tutorials mit Live-Interaktion fördern schnelles Verständnis. 2. User Data Functions und Filterobjekte eröffnen neue Anwendungsfelder. 3. Low Code / No Code senkt die Einstiegshürden aber komplexe Logiken brauchen noch Ergänzung. Diskussionsfragen an euch: • Welche Use Cases für Translytical Data Flow seht ihr in eurem Unternehmen? • Nutzt ihr bereits User Data Functions oder ähnliche Ansätze in eurer Datenanalyse? • Low Code / No Code-Ansatz, der schnelle Entwicklung erlaubt, auch für Fachanwender? • Welche Anforderungen habt ihr an Logikfunktionen in Echtzeitanwendungen? Wir freuen uns auf eure Ideen, Erfahrungen und Fragen!

In diesen Folgen haben wir nicht nur über die Integration sauberer Daten und die Bedeutung des Datenmodells gesprochen, sondern auch über den Aufbau einer BI-Community. Wir haben unsere Lieblingsfunktionen in Power BI beleuchtet, die Rolle von KI in der Datenanalyse diskutiert und Anforderungen im Zeitalter der künstlichen Intelligenz reflektiert. Dabei standen ebenso Fragen zur Datenqualität, zum Umgang mit Direct Query und zur Bewältigung von Veränderungen im Fokus, inklusive unserer Erwartungen an das kommende Jahr. Ist jetzt noch Zeit für ein neues Thema? Nach zehn intensiven Folgen zu Power BI, Datenkultur und technologischen Entwicklungen könnte man meinen, wir hätten alles besprochen. Doch es gibt eine Frage, die über Technik hinausgeht und unser tägliches Arbeiten direkt betrifft: Wie schaffen wir es, unseren Verpflichtungen gerecht zu werden? Business Intelligence lebt von Verantwortung. Von sauberen Daten, zuverlässigen Modellen und fundierten Entscheidungen. Doch hinter jeder BI-Lösung stehen Menschen und mit ihnen eine Vielzahl von Verpflichtungen, Erwartungen und Herausforderungen. Wir wollen heute einen Schritt zurücktreten und uns fragen: Wie schaffen wir es, all dem gerecht zu werden? Und wie gelingt uns das auf eine Weise, die nachhaltig ist, für Projekte, aber auch für uns persönlich? Verpflichtungen in BI-Projekten sind vielfältig: Fachbereiche erwarten schnell nutzbare Dashboards, die IT fordert Standards und Governance, das Management will strategische Auswertungen und das möglichst gestern. Dazu kommen Schulungen, Nutzerfeedback, Bugs, Deadlines. Alles wichtig. Alles dringend. Doch was passiert, wenn alles gleich wichtig erscheint? Wenn Berufliches ins Private übergreift, weil „es ja nur noch schnell gemacht werden muss“? Wenn der Kalender voll ist, aber dennoch jede neue Anfrage ein "Ja" bekommt? Darum sprechen wir auch über: • Grenzen ziehen: Wie gelingt es, Berufliches und Privates zu trennen, in Zeiten von Homeoffice, mobilen Geräten und ständiger Erreichbarkeit? • Nein sagen: Warum es manchmal das mutigste (und klügste) ist, auch mal bewusst Aufgaben abzulehnen, um Qualität zu sichern, statt auf allen Baustellen gleichzeitig zu sein. • Prioritäten setzen: Welche Verpflichtungen sind wirklich wichtig? Und wer definiert das eigentlich? • Selbstverantwortung und Fürsorge: Wie achten wir auf uns selbst, damit wir langfristig leistungsfähig und motiviert bleiben? • Teamstrukturen und Rollenklärung: Wer übernimmt was und wie verhindern wir, dass alle alles machen (und niemand mehr durchblickt)? Verpflichtungen sind nicht nur eine Frage der Organisation, sondern auch der Haltung. Verantwortung heißt nicht, alles zu machen, sondern die richtigen Dinge gut zu machen. Für das Team, die Organisation und sich selbst. Und wie sehen es Andreas und Marcus? Auch in dieser Folge teilen wir offen unsere eigenen Erfahrungen: Wann haben wir uns zu viel vorgenommen? Wie schaffen wir es, Prioritäten zu setzen und wo fällt uns das noch schwer? Welche Tools und Strategien helfen uns? Wie immer bekommt ihr drei praktische Takeaways, ehrlich und authentisch. Reinhören lohnt sich für alle, die BI machen und dabei Mensch bleiben wollen.

Je digitaler unsere Arbeitswelt wird, desto wichtiger ist die zentrale Frage: Wer weiß was? Oft liegt entscheidendes Know-how bei Einzelnen ungeteilt, unausgesprochen, unbewusst. Dabei entsteht echte Souveränität nicht allein durch Technik, sondern durch das Teilen von Wissen. In einer Welt, in der Dienste, Daten und Prozesse ständig wachsen, muss Wissen bewusst gemacht und zugänglich sein. Nur wer sich regelmäßig mit Kolleginnen und Kollegen austauscht, kann informierte Entscheidungen treffen über Systeme, Verantwortlichkeiten und Risiken. Denn Wissen wirkt nur dann, wenn es weitergegeben, hinterfragt und gemeinsam weiterentwickelt wird. Wissenssouveränität entsteht im Team Andreas und Marcus bringen zwei Perspektiven in den Austausch ein: Andreas stellt die Frage nach Verantwortung: Für ihn ist es zentral, dass alle Beteiligten verstehen, wer auf welche Informationen Zugriff hat und wie Wissen klassifiziert wird bevor Projekte starten. Marcus bringt die technische Seite ein für ihn zählt, dass Wissen dokumentiert, zugänglich und portabel ist, sodass Teams bei Bedarf unabhängig agieren können. Was uns beide verbindet: Wir setzen auf transparente Kommunikation, klare Rollen und den Willen, gegenseitig voneinander zu lernen, statt sich auf Einzellösungen oder Spezialwissen zu verlassen. Drei Impulse für mehr Wissenshoheit im Team 1. Wissen sichtbar machen Wer weiß was – und wo fehlt etwas? Erst Transparenz schafft Handlungsfähigkeit. 2. Austausch fördern Regelmäßige Gespräche im Team helfen, Wissen zu verbreitern, auch über Fachgrenzen hinweg. 3. Verantwortung teilen Wenn alle wissen, worauf es ankommt, kann Verantwortung auch gemeinsam getragen werden. Jetzt seid ihr gefragt • Wie gelingt es euch im Alltag, Wissen zu teilen und weiterzugeben? • Welche Formate oder Tools nutzt ihr, um Wissen zugänglich zu machen? • Wo seht ihr Potenziale und vielleicht auch Blockaden im Austausch? Teilt eure Erfahrungen, denn Wissenshoheit entsteht, wenn wir reden, zuhören und voneinander lernen.

Souveränität statt Abhängigkeit: Warum wir jetzt über selbstbestimmte Plattformen sprechen müssen Die digitalen Möglichkeiten wachsen rasant. Von Managed Services bis "Everything-as-a-Service" liefern Hyperscaler unzählige Funktionen, die Entwicklungsteams und BI-Teams begeistern – gleichzeitig aber neue Abhängigkeiten schaffen. Wer heute eine moderne Plattform aufbaut, braucht mehr als nur technische Power: Gefragt ist ein klares Modell, das Portabilität, Flexibilität und Unabhängigkeit im Blick behält. Denn das "Schiff" der Plattform wird größer, komplexer – und wer nicht aufpasst, landet schneller als gedacht im Strudel der Anbieterabhängigkeit. Die Herausforderung: Innovation nutzen, ohne sich komplett von einem Hersteller oder System abhängig zu machen. Unternehmen und Teams müssen bewusst entscheiden, wo sie auf Services setzen – und wo sie lieber offen bleiben wollen. Nur so bleibt das Wechseln des Hafens – oder gar der ganzen Reederei – auch in Zukunft möglich. Wie sehen es Andreas und Marcus? Andreas und Marcus bringen verschiedene Perspektiven aus ihren BI- und Data-Engineering-Erfahrungen mit: Andreas betont die Balance zwischen Komfort und Kontrolle: Er liebt bewährte Tools, achtet aber auf mögliche Stolperfallen bei Web-Only-Angeboten und Funktionsunterschieden. Marcus setzt auf technische Portabilität: Mit Containern, offenen Formaten wie Parquet und einer Infrastruktur, die bei Bedarf den Anbieter wechseln kann. Ihr gemeinsames Ziel: ein flexibles, manövrierfähiges Plattform-Schiff, das Innovationen aufgreift, ohne die Kontrolle zu verlieren. Daraus haben sie drei praktische Tipps für den Nachhauseweg abgeleitet, oder? Warum Portabilität heute wichtiger denn je ist. Weshalb offene Formate und modulare Architekturen echte Lebensretter sein können. Und warum "alles online, alles überall" nicht immer der beste Weg sein muss. Lasst uns eure Erfahrungen wissen und steigt mit uns in die Diskussion ein!

icrosoft Fabric ermöglicht jetzt KI-Features bereits in kleineren Kapazitäten – aber wie sinnvoll sind diese Features im echten Arbeitsalltag? Wir hinterfragen kritisch, ob die Umbenennung der „KI Skills“ in „Agents“ einen echten Mehrwert bietet und warum das Timing kurz vor dem 1. April möglicherweise etwas unglücklich war. Weitere Themen sind der Copilot, der eigenständig innerhalb des Teams mit relevanten Daten antwortet, sowie der Überspannungsschutz, der unbemerkt im Hintergrund agiert. Wir diskutieren, wie Autoscaling für Spark effizient Ressourcen bereitstellt und Kosten optimiert. Besonderes Augenmerk legen wir auf die Sicherheitsaspekte von OneLake Security: Welche Schutzmechanismen bietet Microsoft Fabric, um sensible Unternehmensdaten sicher zu speichern? Kann Fabric durch fein abgestufte Berechtigungen überzeugen und welche Herausforderungen lassen sich dadurch effektiv meistern? Zudem werfen wir einen Blick auf praktische Neuerungen wie den COPY Job, der nun die passenden Features in Fabric-Pipelines bringt, die Einsatzmöglichkeiten von User Defined Functions und die Integration mit Git. Wir sprechen außerdem darüber, ob die Vielzahl der Konferenzen wirklich dabei hilft, Neuerungen gezielt zu vermitteln oder ob weniger manchmal mehr ist. Nicht zuletzt diskutieren wir den immer relevanten Konflikt: Setzen wir lieber auf individuelle Freiheit in der Datenanalyse oder bevorzugen wir standardisierten Business Content „von der Stange“? Ganz nebenbei erinnern wir uns daran, dass schon die Italiener vor Jahrhunderten die Buchhaltung erfunden haben. Wie immer gibt es drei praktische Tipps für den Nachhauseweg oder machen wir es diesmal anders? Wir freuen uns auf eure Meinung zu diesen Themen: Welche Highlights von der FabCon waren für euch besonders relevant? Wie bewertet ihr die Nützlichkeit der KI-Features in kleinen Kapazitäten? Sind die neuen „Agents“ wirklich eine Verbesserung? Wie setzt ihr Copilot, Autoscaling oder Git Integration praktisch ein? Wie zufrieden seid ihr mit der OneLake-Security? Bevorzugt ihr eher freie, flexible Lösungen oder Business Content von der Stange? War der Release-Termin kurz vor dem 1. April clever gewählt? Lasst uns eure Erfahrungen wissen und steigt mit uns in die Diskussion ein!

In dieser Podcast-Episode diskutieren wir intensiv über Microsoft Fabric und die zentrale Frage: Ist Fabric tatsächlich das „Waschen ohne nass zu werden“ der BI-Welt? Früher hatten wir unsere eigenen Server, on Premises, individuell konfiguriert und sogar mit Namen versehen. Doch davon müssen wir uns langsam verabschieden. Die Zukunft gehört Plattformen, bei denen jeder Wunsch erfüllt wird – sei es Notebooks für Analysten, SQL-Datenbanken für Entwickler oder umfassendes Dateimanagement über integrierte Warehouse-Lösungen. Wir sprechen darüber, ob das ständig wachsende Angebot neuer Features tatsächlich hilft oder ob wir uns nicht doch lieber eine einfache, verlässliche Oberfläche wünschen, die „einfach funktioniert“. Denn nicht immer braucht man gleich eine Power BI Premium Lizenz – oder gar die leistungsstarke F64-Kapazität die auch gleich die KI-Features mitbringt. Dabei werfen wir auch einen Blick auf das Lakehouse-Konzept, das mit seinen Spark-Notebooks neue analytische Möglichkeiten bietet. Doch wann ist der richtige Moment, von traditionellen Lösungen auf ein Lakehouse zu wechseln? Vielleicht lautet die Antwort: „Dann gehe ich doch erstmal Richtung Lakehouse!“ Wir gehen auf die Vor- und Nachteile ein, wenn alles „in der Box“ verfügbar ist. Welche Erfahrungen machen Unternehmen und Analysten, wenn sie traditionelle Infrastrukturen verlassen und zu Fabric wechseln? Können Anforderungen wirklich flexibler und effizienter erfüllt werden oder führt die Fülle an Möglichkeiten eher zu Überforderung? Wie sehen Andreas und Marcus das Thema? Haben wir es hier mit einer echten Revolution im Datenmanagement zu tun oder ist es nur eine vorübergehende Entwicklung? Und wie immer gibt es die drei Dinge für den Nachhauseweg! Möchtet ihr mit uns ins Gespräch kommen? Hier sind ein paar Fragen zur Diskussion • Kennt ihr noch eure Server „on Prem“ und gebt ihr ihnen immer noch Namen? • Wie seht ihr den Wandel von klassischen Server on Prem hin zu Cloud-Lösungen wie Fabric? • Glaubt ihr, dass Microsoft Fabric tatsächlich alle Bedürfnisse von Analysten und Entwicklern erfüllt? • Welche Erfahrungen habt ihr mit dem „Alles in der Box“-Ansatz gemacht, wo jedes Tool für Analysten und Entwickler direkt verfügbar ist? • Wann entscheidet ihr euch für eine Power BI Pro Lizenz oder sogar für eine F64-Kapazität – braucht man das immer? • Seid ihr schon auf dem Weg Richtung Lakehouse und wie sind eure Erfahrungen mit Spark-Notebooks? Wir freuen uns auf eure Meinungen und eine spannende Diskussion!

In dieser Podcast-Episode fokussieren wir uns auf das Thema automatisiertes Testing in Power BI-Projekten. Wir diskutieren, warum automatisierte Tests entscheidend sind, um eine hohe Datenqualität und Performance sicherzustellen, und wie sie professionell implementiert werden können. Besonderes Augenmerk liegt auf der Nutzung von Unit Tests und klar definierten Testfällen, um Kundenanforderungen zuverlässig abzubilden und Projektanforderungen effektiv zu dokumentieren. Wir sprechen auch darüber, warum es essenziell ist, dass Testverfahren gut dokumentiert sind und wie professionelle Entwicklungsprozesse dadurch unterstützt werden. Zudem gehen wir auf die Implementierung eines Regelwerks in dbt ein, das durch standardisierte Prozesse eine konsistente Datenverarbeitung sicherstellt. Welche Erfahrungen haben wir und andere Tester in diesem Bereich gemacht? Wie unterscheiden sich verschiedene Ansätze hinsichtlich Granularität, Performance und Qualität der Ergebnisse? Wie sehen Andreas und Marcus das Thema automatisiertes Testing? Welche Methoden haben sich bewährt und welche Auswirkungen hat eine professionelle Teststrategie auf BI-Projekte? Und wie immer gibt es die drei Dinge für den Nachhauseweg! Möchtet ihr mit uns ins Gespräch kommen? Hier sind ein paar Fragen zur Diskussion: • Welche Methoden nutzt ihr für automatisiertes Testing in euren BI-Projekten? • Wie integriert ihr Unit Tests in eure Power BI-Modelle? • Wie dokumentiert ihr Testfälle und sorgt dafür, dass die Anforderungen der Kunden erfüllt werden? • Welche Erfahrungen habt ihr mit der Implementierung eines Regelwerks in dbt gemacht? Wir freuen uns auf eure Meinungen und eine spannende Diskussion!

Power BI ermöglicht schnelle Analysen und flexible Berichte – doch wo liegt die Grenze zwischen Self-Service und professioneller BI-Entwicklung? Marcus und Ulrik diskutieren, ob getrennte Entwicklungs-, Test- und Produktivumgebungen in Power BI wirklich notwendig sind oder ob sie den Prozess unnötig verkomplizieren. Die zentrale Frage: Wie lassen sich schnelle Anpassungen ohne Risiko umsetzen? Während im klassischen Software-Development klare Strukturen existieren, setzen viele Unternehmen in Power BI immer noch auf spontane Änderungen direkt in der Produktionsumgebung. Doch was passiert, wenn kleine Anpassungen unerwartet große Auswirkungen haben? Wir beleuchten Best Practices zur Versionierung, die Herausforderungen beim Deployment und mögliche Automatisierungen, um den Entwicklungsprozess effizienter zu gestalten. Außerdem klären wir, ob Power BI sich noch im reinen Self-Service bewegt oder bereits professionelle Entwicklungsstandards benötigt. Wie sehen es Marcus und Ulrik? Sind sie sich einig oder haben sie unterschiedliche Perspektiven? Welche Erfahrungen haben sie in Projekten gemacht? Gibt es eine goldene Mitte zwischen Kontrolle und Flexibilität? Hört rein, um die Antwort zu finden! Natürlich gibt es auch wieder drei spannende Takeaways für euch!

BI-Projekte sind oft mit Herausforderungen wie schlechter Datenqualität, unrealistischen Erwartungen und fehlenden Standards verbunden. In dieser Episode sprechen wir mit unserem Gast Sarah über genau diese Stolpersteine und beleuchten, wie Unternehmen sie erfolgreich überwinden können. Dabei gibt sie spannende Einblicke in ihre Arbeit im digitalen Marketing und der Datenanalyse und zeigt auf, warum insbesondere in der Anfangsphase von BI-Projekten ein klares Erwartungsmanagement und definierte Standards in der Datenverarbeitung entscheidend sind. Sie bringt spannende Einblicke aus dem digitalen Marketing mit und spricht über die Rolle von Automation Tools in der Datenanalyse. Wir sprechen über die Schwierigkeiten, die entstehen, wenn Unternehmen sich auf Standardlösungen verlassen und erst später merken, dass diese nicht alle wichtigen Fragen beantworten können. Diese versprechen umfassende Reportingmöglichkeiten, stoßen jedoch schnell an ihre Grenzen, wenn es um individuelle Fragestellungen geht. Genau hier kommt Power BI ins Spiel: Welche Vorteile bietet das Tool gegenüber Standardlösungen? Was muss man beachten? Welche Vorteile bietet das Tool gegenüber Standardlösungen im Marketing? Wir diskutieren, welche Best Practices es für die Modellierung und Visualisierung gibt, um aussagekräftige Analysen zu erstellen. Dabei geht es auch darum, welche Funktionen von Power BI Unternehmen helfen können, Daten sinnvoll zu aggregieren und Entscheidungen datengetrieben zu treffen. Oft fehlt eine enge Zusammenarbeit über Fachteams hinaus, was dazu führt, dass wertvolle Daten nicht effizient genutzt werden. Wie können Unternehmen sicherstellen, dass alle Beteiligten an einem Strang ziehen? Welche Rolle spielen Controlling und Datenschutz in diesem Prozess? Welche Erfahrungen haben Sarah, Andreas und Marcus mit der Wahl des richtigen BI-Modells gemacht. Wie hat sich sich deren Anwendung in der Praxis bewährt? Haben sich unterschiedliche Herangehensweisen als besonders effektiv erwiesen? Sind alle drei einer Meinung, oder gibt es hier unterschiedliche Sichtweisen? Zum Abschluss gibt heute Sarah drei wertvolle Tipps für den erfolgreichen Umgang mit BI-Projekten: 1. Einfach mal anfangen und nicht zu lange zögern. 2. Projekte in kleine Schritte aufteilen, um den Veränderungsschmerz zu reduzieren. 3. Sich von Anfang an bewusst machen, warum man etwas tut, und die dahinterstehenden Prozesse verstehen. Möchtet Ihr mit uns ins Gespräch kommen? Hier sind einige Fragen zur Diskussion: • Wie geht ihr mit der Erwartungshaltung eurer Kunden in BI-Projekten um? • Welche Erfahrungen habt ihr mit der Zusammenarbeit zwischen Marketing, Sales und Controlling gemacht? • Wie handhabt ihr die Problematik rund um Datenqualität und Automatisierungsfehler? Wir freuen uns auf eure Meinungen und eine spannende Diskussion!

In dieser Podcast-Episode geht es um die Bedeutung von Datenmodellen in Power BI und ihre Auswirkungen auf die Performance und die Datenanalyse. Wir werfen einen genauen Blick auf die Rolle von Dimensionen und Granularität und erläutern, wie du diese effektiv einsetzt, um aussagekräftige Berichte zu erstellen und gleichzeitig die Performance deines Modells zu optimieren. Ein wichtiger Punkt ist die Trennung von Datum und Zeit. Es ist entscheidend, diese beiden Elemente klar zu differenzieren, um präzise Zeitreihenanalysen und effiziente Aggregationen zu ermöglichen. Doch bei all dem spielt auch die Datenmenge eine wichtige Rolle: Wie viele Felder und Zeilen können in Power BI verarbeitet werden, ohne dass die Performance leidet? Und wie beeinflusst die Datasetgröße die Ladegeschwindigkeit und Verarbeitung? Ein zusätzlicher Faktor: Alles, was du an Daten mitnimmst, kostet Performance. Der Italiener in mir sagt dazu: "It depends!" Es kommt darauf an, welche Daten du tatsächlich benötigst und wie gut du sie komprimierst. Gute Komprimierungsverfahren in Power BI können hierbei helfen, die Performance trotz großer Datenmengen auf einem hohen Niveau zu halten. Im Gespräch gehen wir auch auf die Bedeutung der Datenqualität und -güte ein. Denn ein solides Datenmodell ist nicht nur eine Frage der Struktur, sondern auch der Qualität der Daten, die du darin abbildest. Nur wenn deine Daten konsistent und vertrauenswürdig sind, kannst du daraus wertvolle, zuverlässige Analysen ableiten. Natürlich werfen wir auch einen Blick auf die unterschiedlichen Lizenzen in Power BI, die entscheidend dafür sind, welche Datenmengen und Verarbeitungsressourcen dir zur Verfügung stehen. Power BI Pro und Power BI Premium bieten unterschiedliche Kapazitäten, die je nach Umfang und Anforderungen deines Projekts eine Rolle spielen. Wie sehen es Andreas und Marcus? Können die eigenen Erfahrungen mit der Wahl des richtigen Modells und deren Anwendung helfen bei der Fragestellung? Haben wir unterschiedliche Herangehensweisen, die besonders gut funktionieren und was hat die Granularität und Qualität der Daten für eine Auswirkung? Macht es einen Unterschied in der Analyse wie man das Modell konzipiert? Und wie immer gibt es die drei Dinge für den Nachhauseweg! Möchtet Ihr mit uns ins Gespräch kommen sind hier ein paar Fragen zur Diskussion • Was ist eure bevorzugte Methode zur Datenmodellierung in Power BI? • Wie geht ihr mit der Trennung von Datum und Zeit um und welche Granularität verwendet ihr in euren Modellen? • Welche Erfahrungen habt ihr mit der Handhabung von großen Datenmengen und der Wahl der passenden Lizenz gemacht? Wir freuen uns auf eure Meinungen und eine spannende Diskussion!

Power BI entwickelt sich in rasantem Tempo weiter und wird zunehmend anspruchsvoller. Ständig werden neue Funktionen und Features hinzugefügt, die das Tool leistungsfähiger machen, jedoch auch neue Herausforderungen mit sich bringen: Wie lassen sich diese Neuerungen einfach und effizient nutzen? Zudem rücken immer mehr Themen in den Fokus, die über den ursprünglichen Zweck von Power BI hinausgehen. Diese Entwicklung wirft die Frage auf, ob wir es noch mit Power BI zu tun haben oder bereits in „Fabric“ unterwegs sind. Das „Schiff“ wächst und wird umfangreicher – doch wie bleibt es steuerbar? Die zusätzlichen Möglichkeiten machen Power BI zu einem vielseitigen Werkzeug, doch mit der wachsenden Komplexität steigt auch das Risiko, den Überblick zu verlieren. Es erfordert eine durchdachte Herangehensweise, um die Plattform optimal zu nutzen. Dabei ist es entscheidend, die Kernfunktionen gezielt einzusetzen und sich nicht in weniger relevanten Randthemen zu verzetteln. Nur so können Nutzer von den stetigen Innovationen profitieren, ohne von der Dynamik überfordert zu werden. Wie sehen es Andreas und Marcus? Andreas und Marcus diskutieren, ob sie derselben Meinung sind oder unterschiedliche Perspektiven vertreten. Welche Erfahrungen haben sie in ihren BI-Projekten gemacht? Wie gehen sie mit der wachsenden Komplexität und neuen Features um? Gibt es unterschiedliche Herangehensweisen, um das „Schiff“ auf Kurs zu halten und welche Lösungsansätze haben wir für euch? Natürlich gibt es auch wieder drei interessante Takeaways für euch!

n den letzten zehn Folgen haben wir zentrale BI-Themen behandelt, wie die Integration sauberer Daten, die Bedeutung des Datenmodells und den Aufbau einer BI-Community. Wir sprachen über Power BI, unsere Lieblingsfunktionen und die Nutzung von KI, sowie über Datenqualität und Anforderungen im Zeitalter der KI. Zudem teilten wir Erfahrungen mit Direct Query und diskutierten, wie wir mit Veränderungen umgehen und welche Erwartungen wir für das neue Jahr haben. Ist jetzt noch Zeit für ein neues Thema? Nach diesem umfassenden Rückblick stellt sich die Frage, ob noch Raum für ein neues Thema bleibt. Die Antwort ist ein klares Ja. Datendemokratisierung: Wie fördern Mobile Reports die Datendemokratisierung? Ein zentrales Thema, das wir nicht außer Acht lassen dürfen, ist die Datendemokratisierung. Wie können wir sicherstellen, dass alle Mitarbeiter, unabhängig von ihrer technischen Expertise, Zugang zu den richtigen Daten haben? Ziel ist es, eine Kultur zu schaffen, in der jeder – vom CEO bis zum operativen Mitarbeiter – die Möglichkeit hat, fundierte, datengetriebene Entscheidungen zu treffen. Sind unsere BI-Systeme so aufgebaut, dass sie eine breite Nutzergruppe ansprechen, vom Power-User bis hin zum weniger technisch versierten Anwender? Es ist entscheidend, eine Kultur der Datentransparenz zu etablieren. Alle Mitarbeitende erhalten Zugang zu den Informationen, die sie für ihre Arbeit benötigen, und können Entscheidungen nachvollziehbar und transparent treffen. So wird Vertrauen in die Daten aufgebaut und die Zusammenarbeit im Unternehmen gefördert. Mobile Reports spielen eine Schlüsselrolle in der Datendemokratisierung, indem sie es einer breiten Benutzergruppe ermöglichen, Daten in Echtzeit und auf mobilen Geräten zuzugreifen. Diese Berichte fördern eine breitere Nutzung von Daten, indem sie nicht nur den traditionellen Power-Usern zugänglich gemacht werden, sondern auch den weniger technisch versierten Nutzern die Möglichkeit geben, fundierte Entscheidungen zu treffen. Indem Unternehmen den Zugang zu Daten über Mobile Reports erweitern, fördern sie eine Kultur der Datentransparenz und -verfügbarkeit, die für die Datendemokratisierung unerlässlich ist. Wie sehen es Andreas und Marcus? Sind wir derselben Meinung oder haben wir unterschiedliche Ansichten? Welche Erfahrungen haben wir in unseren BI-Projekten gemacht? Gibt es unterschiedliche Herangehensweisen an das Thema? Hört mal rein, was wir zu sagen haben. Natürlich gibt es auch wieder drei interessante Takeaways für euch!