Neueste Podcast 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!
-
#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!
-
#090 Wie schaffen wir es, unseren Verpflichtungen gerecht zu werden?
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.
-
#089 Wer weiß was?
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.
-
#088 Wie sehen wir die Souveränität von Datenplattformen?
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!
-
#087 Was waren unsere FabCon Highlights?
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!
