Startseite » Data

Schlagwort: Data

#100 Was steht noch auf unserer Bucket List?

Von Translytical bis Self Service, von Modellüberarbeitung bis Fehlerkultur. In unseren letzten Folgen drehte sich alles um praktische BI-Herausforderungen und echte Projekterfahrungen. Wir haben diskutiert, wann Power BI allein nicht mehr reicht, wie man Fabric effizient nutzt und welche Learnings zehn Jahre Power BI gebracht haben. Ein Highlight, die FabCon Vienna, mit spannenden Impulsen zur Zukunft moderner Datenplattformen und natürlich auch die Frage: Wo stehen wir beruflich und wohin wollen wir uns entwickeln? Mit diesen Erkenntnissen starten wir in eine neue Folge, mit dem Ziel, Verantwortung, Technik und Fokus in Einklang zu bringen. 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: Zwischen UDFs, dbt und OnPrem, was steht auf unserer Bucket List? Nach Jahren technischer Entwicklung und zahllosen BI-Projekten wird deutlich, Verantwortung hört nicht bei Modellen und Pipelines auf. Ob User Defined Functions, dbt-Modelle oder OnPrem-Systeme, überall geht es darum, Komplexität zu beherrschen, ohne den Überblick zu verlieren. Und auch wenn oft von Cloud-first die Rede ist, OnPremise ist nicht tot, es ist immer noch intensiv, wichtig und Teil vieler produktiver Architekturen. Die Cloud geht ihren Weg mit neuen Ideen und mutigen Schritten nach vorn, aber nicht als Ersatz, sondern als Ergänzung. Auf Konferenzen wie den SQL days spüren wir, wie sich die BI-Welt verändert: Neue Tools, neue Rollen, neue Erwartungen. Doch mit jeder Innovation wächst auch der Druck, Schritt zu halten – und gleichzeitig das Bestehende zu pflegen. Deshalb geht es in dieser Folge um Prioritäten, Fokus und das bewusste Setzen von Grenzen – beruflich wie privat. Und natürlich werfen wir einen Blick auf unsere Bucket List, die großen Ziele und die kleinen Momente. Beruflich geht es um spannende Projekte, neue Technologien, vielleicht einen eigenen Vortrag auf der nächsten SQL days oder den Plan, ein komplexes Datenmodell endlich sauber in dbt zu überführen. Privat geht’s um Erlebnisse, die Kraft geben: mal wieder ein Fußballspiel live im Stadion erleben, mehr Zeit mit der Familie verbringen oder ein Wochenende komplett offline bleiben, bevor das nächste große Projekt ansteht. Denn manchmal braucht es genau diesen Perspektivwechsel, raus aus der Datenwelt, rein ins Leben, um mit neuer Energie und klarem Fokus zurückzukehren. Und wie sehen es Andreas und Marcus? Was steht auf ihren Bucket Lists? Welche Projekte wollen sie noch angehen und wo ist auch mal Zeit, innezuhalten? Wie gelingt der Spagat zwischen beruflichem Anspruch, technischer Neugier und persönlicher Balance? Wie immer bekommt ihr drei, oder vier, praktische Takeaways, ehrlich und authentisch. Reinhören lohnt sich für alle, die BI machen und dabei Mensch bleiben wollen.
#099 Was waren unsere Highlights der Fabcon Vienna?

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!
#098 Wie nutzt ihr Fabric effizient und spart CUs dabei?

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!
#097 Wann sollte man von Power BI Only auf eine Datenplattform wechseln?

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!
#096 Wie gehen wir mit Fehlern um, die schon immer da waren?

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!
#095 Wie überarbeiten wir ein Power BI Modell?

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!
#094 Welche Learnings ziehen wir aus 10 Jahren Power BI?

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!
#093 Wie bestimmen wir unseren beruflichen Standort?

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!
#092 Sollte jeder Self Service machen?

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!
#091 Was kann Translytical?

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!