Archive: Episoden
-
#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!
-
#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.
