Power BI Fundamentals

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 1 von 14. Die meisten Unternehmen ertrinken in Daten, aber hungern nach echten Insights. Du hast Datenbanken, Spreadsheets und Cloud-Storage voller Zahlen, aber wenn das Management fragt, wie ein Produkt im letzten Quartal performt hat, bricht Panik aus. Die Lösung, um diese Lücke zwischen verstreuten Zahlen und zusammenhängenden Informationen zu schließen, ist das Power BI Ecosystem. Power BI ist nicht einfach nur ein einzelnes Stück Software. Es ist eine Sammlung von Services, Apps und Connectors, die dafür designt wurden, zusammenzuarbeiten. Seine Hauptaufgabe ist es, unzusammenhängende Datenquellen zu nehmen und sie in interaktive, visuell immersive Reports zu verwandeln. Eine häufige Falle für neue User ist es, die verschiedenen Teile dieses Ecosystems zu verwechseln, speziell die Desktop-App und den Web-Service. Das sind völlig unterschiedliche Tools, die für verschiedene Phasen des Reporting-Lifecycles gebaut wurden. Um sie auseinanderzuhalten, merk dir einfach: Das eine ist die Fabrik, und das andere ist der Showroom. Die Fabrik ist Power BI Desktop. Das ist eine kostenlose Applikation, die du auf einer lokalen Windows-Maschine installierst. Power BI Desktop ist dein primäres Authoring- und Creation-Tool. Hier passiert das Heavy Lifting. Hier verbindest du dich mit deinen Rohdaten, bereinigst sie und designst das eigentliche visuelle Layout deines Reports. Stell dir einen Sales Manager vor, der eine riesige, flache Excel-Datei voller roher Transaktions-Records bekommt. Auf eine Million Textzeilen zu starren, hilft ihm nicht dabei, eine Entscheidung zu treffen. Er öffnet Power BI Desktop auf seinem Laptop und verbindet sich direkt mit dieser Excel-Datei. Er nutzt die Desktop-App, um einen Report zu bauen, und fügt eine Map hinzu, um Sales nach Region zu zeigen, und ein Bar Chart für den monatlichen Revenue. Diese ganze Creation passiert lokal auf seiner eigenen Hardware. Sobald dieser Report fertig ist, muss der Manager ihn dem Rest des Teams zeigen. Eine riesige Datei per E-Mail herumzuschicken ist ineffizient und führt zu Version-Control-Alpträumen. Hier wird es interessant. Anstatt die Datei zu verschicken, publisht der Manager sie in den Power BI Service. Der Power BI Service ist der Showroom. Es ist eine cloudbasierte Software-as-a-Service-Plattform, auf die über einen Web-Browser zugegriffen wird. Wenn der Manager in der Desktop-App auf Publish klickt, wird der Report in die Cloud hochgeladen. Jetzt kann sich der Rest des Sales-Teams in den Web-Service einloggen. Sie können sich die Dashboards ansehen, die Charts filtern und mit den Daten interagieren. Sie müssen Power BI Desktop nicht installieren, und sie müssen nicht wissen, wie der Report gebaut wurde. Sie konsumieren einfach die Insights. Es gibt auch noch ein drittes Teil, das das Bild komplett macht, und das sind die Power BI Mobile Apps. Diese erlauben es Usern auf Phones und Tablets, sicher auf genau dieselben Reports zuzugreifen, die im Cloud-Service gehostet werden, während sie nicht an ihrem Schreibtisch sind. Der typische Workflow bewegt sich in eine Richtung. Du verbindest dich mit Daten und baust einen Report in Power BI Desktop. Du publisht diesen Report in den Power BI Service. Dann schauen du und dein Team sich diese Reports im Service oder auf Mobile an und interagieren mit ihnen. Die Desktop-Applikation ist für den Creator, und der Web-Service ist für den Consumer. Du baust lokal, aber du verteilst global. Wenn du die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Das war's für diese Folge. Danke fürs Zuhören, und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 2 von 14. Du loggst dich an deinem ersten Tag bei einer neuen Business-Intelligence-Plattform ein, und es fühlt sich an, als würdest du ins Cockpit eines Flugzeugs steigen. Es gibt Dutzende von Menüs, Listen und Items mit ähnlichen Namen, aber du musst nur die Key Metrics deines Teams finden, ohne etwas kaputt zu machen. Die Lösung ist, die Architektur des Power BI Service zu verstehen. Der Power BI Service ist das Webportal, das du unter app.powerbi.com erreichst. Wenn du dich einloggst, landest du auf dem Home Screen. Diese Seite dient als personalisierter Einstiegspunkt und zeigt deine am häufigsten verwendeten und zuletzt aufgerufenen Items an. Aber um wirklich durch das System zu navigieren, nutzt du das Pane auf der linken Seite des Screens. Das wichtigste Konzept in dieser Navigation Pane ist der Workspace. Ein Workspace ist ein Container. Er enthält deinen Content. Du hast einen persönlichen Container namens My Workspace, der streng genommen nur für deine eigenen privaten Drafts und Experimente gedacht ist. Nutze ihn nicht für Company Metrics. Für die Collaboration verlässt du dich auf Shared Workspaces. Stell dir einen Shared Workspace wie einen sicheren Projektordner vor, in dem ein bestimmtes Team seine gebündelten Data Assets speichert. Innerhalb eines Workspaces findest du verschiedene Arten von Items, und zu wissen, wie sie zusammenhängen, ist der Schlüssel, um die Plattform zu verstehen. Die Grundlage von allem ist das Semantic Model. Du schaust dir kein Semantic Model an, um Charts oder Graphen zu sehen. Es ist die zugrundeliegende Datenstruktur, die die Tabellen, die Relationships und die Calculations enthält. Es ist die Engine. Jede Zahl, die du auf einem Screen siehst, wird aus einem Semantic Model gequeryt. Auf dieser Engine sitzt der Visual Layer, der normalerweise die Form eines Reports annimmt. Hier ist die wichtigste Erkenntnis: Leute verwenden die Wörter Report und Dashboard ständig so, als würden sie genau dasselbe bedeuten. In Power BI sind das völlig unterschiedliche Objekte mit unterschiedlichem Verhalten. Ein Report ist ein mehrseitiges, hochgradig interaktives Dokument. Er ist an genau ein Semantic Model gebunden. Wenn du einen Report öffnest, kannst du auf Charts klicken, um andere Charts zu cross-filtern, Dropdown-Menüs verwenden, um die Daten zu slicen, und zwischen verschiedenen Tabs am unteren Rand des Screens navigieren. Reports sind für Deep Exploration und detaillierte Analysen gebaut. Ein Dashboard ist immer eine einzelne Seite. Es ist ein Custom Canvas, auf dem du einzelne visuelle Elemente, sogenannte Tiles, aus verschiedenen Reports anpinnst. Weil du Tiles von überall anpinnen kannst, kann ein einziges Dashboard Daten aus mehreren verschiedenen Semantic Models in einer High-Level-Overview kombinieren. Du kannst Daten auf einem Dashboard nicht direkt filtern oder slicen. Wenn du auf ein Tile klickst, fungiert es als Shortcut und bringt dich sofort in den zugrundeliegenden Report, aus dem dieses spezifische Chart stammt. Dashboards sind für schnelles Monitoring auf einen Blick gedacht. Reports sind dafür da, um in die Details einzutauchen. Wenn ein Team mit dem Bauen seiner Semantic Models, Reports und Dashboards in einem Workspace fertig ist, lädt es normalerweise nicht die ganze Firma in diesen Workspace ein, um sich dort umzusehen. Stattdessen verpacken sie die fertigen Items in eine App. Im Power BI Service ist eine App eine kompilierte, Read-Only-Sammlung von Workspace-Content. Wenn ein neuer Mitarbeiter die Key Performance Indicators seiner Abteilung finden muss, klickt er normalerweise einfach auf das Apps-Icon in der linken Navigation Pane. Apps bieten eine saubere, Custom-Menüstruktur, ohne die rohen Workspace-Files versehentlichen Edits auszusetzen. Das Ecosystem zu verstehen, bedeutet, diese Hierarchie zu verstehen. Wenn du wissen willst, wie eine bestimmte Metric auf deinen Screen gelangt ist, folge der Chain rückwärts. Die App verteilt das Dashboard, das Dashboard zieht Visuals aus dem Report, der Report visualisiert das Semantic Model, und das Semantic Model lebt in einem Shared Workspace. Das war's für diese Folge. Danke fürs Zuhören, und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 3 von 14. Der größte Fehler, den neue Power BI-Nutzer machen, ist, einen geschäftskritischen Report in ihrem persönlichen Account zu bauen, in den Urlaub zu fahren und ihr gesamtes Team komplett von den Daten auszuschließen. Die Lösung dafür ist zu verstehen, wie man Workspaces und Collaboration richtig strukturiert. In Power BI hast du zwei verschiedene Arten von Umgebungen für deinen Content. Erstens gibt es den My Workspace. Das ist deine persönliche Sandbox. Jeder Power BI-Nutzer bekommt automatisch einen. Er ist komplett privat. Du nutzt ihn, um dich mit Sample Data zu verbinden, eine neue Formel zu testen oder ein Layout zu entwerfen, bevor es jemand anderes sieht. Nutze den My Workspace nicht für offizielles Company Reporting. Wenn du hier das Main Sales Dashboard baust und dann die Company verlässt, wird dein Team Probleme haben, auf diesen Content zuzugreifen oder ihn zu updaten. Die Lösung ist der Standard-Workspace. Das ist eine Shared Environment, in der Teams an Semantic Models, Reports und Dashboards zusammenarbeiten. Ein Workspace fungiert als sicherer Container für ein bestimmtes Projekt oder eine Abteilung. Wenn du einen Workspace erstellst, legst du genau fest, wer in diesen Container darf und welche Aktionen sie ausführen können. Stell dir ein Finance-Team vor, das einen Q3 Financial Report baut. Du brauchst mehrere Leute, die zu den Daten beitragen, aber du brauchst strikte Kontrolle darüber, wer die finalen Zahlen ändern darf. Das setzt du mit vier verschiedenen Workspace-Rollen durch. Die erste ist die Admin-Rolle. Der Workspace-Admin hat die totale Kontrolle über die Umgebung. Er kann den gesamten Workspace löschen und entscheidet, wer Access bekommt. Der System-Admin oder der Leiter des Finance-Data-Teams übernimmt diese Rolle. Als Nächstes kommt die Member-Rolle. Members managen den Content und den Flow des Workspaces. Sie können Kollegen mit niedrigeren Permissions hinzufügen, Semantic Models updaten und die Workspace-Items sharen. Ein Senior Financial Analyst, der den Q3-Reporting-Prozess managt, braucht diese Rolle. Sie erlaubt es ihm, das Projekt am Laufen zu halten und den Team-Access zu managen, ohne den Admin für jede kleine Änderung nerven zu müssen. Dann hast du den Contributor. Das ist die primäre Rolle für Content Creators. Contributors können Reports und Dashboards innerhalb des Workspaces erstellen, editieren und löschen. Sie können keine Permissions managen und keine neuen User hinzufügen. Die Analysten, die die eigentlichen Charts und Tabellen für den Q3-Report bauen, bekommen Contributor-Access. Sie bauen den Content, aber sie kontrollieren nicht die Security Boundaries. Zu guter Letzt gibt es die Viewer-Rolle. Viewers können sich Reports ansehen, Charts cross-highlighten und die Daten filtern, aber sie können den zugrunde liegenden Content oder die Struktur nicht ändern. Du weist diese Rolle den Finance Directors zu, die den Q3-Report reviewen und mit den Daten interagieren müssen, bevor er für die restliche Company freigegeben wird. Hier ist der entscheidende Punkt: Permissions in einem Workspace gelten für den gesamten Container. Du kannst jemandem nicht Contributor-Access für einen Workspace geben, ihn aber gleichzeitig davon ausschließen, einen bestimmten Report darin zu sehen. Der Workspace ist eine einzige Security Boundary. Wenn jemand Access zum Workspace hat, kann er den gesamten Content darin sehen, nur eingeschränkt durch die spezifische Rolle, die du ihm zugewiesen hast. Die Workspace-Struktur zwingt dich dazu, Reporting als einen resilienten Team-Prozess zu behandeln. Indem du persönliche Drafts isoliert im My Workspace behältst und Team-Projekte in Shared Workspaces mit expliziten Rollen verschiebst, bleibt deine Datenarchitektur stabil und zugänglich, unabhängig davon, wer im Büro ist. Das war's für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 4 von 14. Das Geheimnis eines blitzschnellen und hochpräzisen Reports hat tatsächlich nichts mit den Charts auf dem Bildschirm zu tun. Wenn Zahlen abteilungsübergreifend nicht übereinstimmen, liegt das Problem selten am visuellen Interface. Es ist die Datenarchitektur, die darunter liegt. Heute schauen wir uns das Semantic Model an. Ein Semantic Model, das Power BI früher als Dataset bezeichnete, ist das unsichtbare Gehirn deiner Reports. Es ist ein häufiger Fehler, Power BI lediglich als ein Tool zu betrachten, das eine flache Database Table oder ein Excel Sheet einliest und einen Graphen darüber zeichnet. Das ist nicht der Fall. Ein Semantic Model ist ein robustes, relationales Netzwerk. Es speichert die Tabellen, aber es kapselt auch die Beziehungen zwischen diesen Tabellen, die Formatting Metadata und die vordefinierte Business Logic. Es sitzt genau zwischen deinen rohen, verstreuten Datenquellen und deinen visuellen Reports und fungiert als organisierter Middle Layer. Du kannst Daten aus einer Cloud Database, einem lokalen File und einer Web API reinholen und sie alle zu einer zusammenhängenden Struktur zusammenfügen. Das ist der Teil, auf den es ankommt. Du brauchst absolut nicht für jeden einzelnen Report ein neues Modell. Ein gut designtes Semantic Model trennt die Kern-Datenlogik von der visuellen Präsentation. Nimm ein Szenario, in dem deine Company ein Single Customer Truth Model benötigt. Das Marketing-Team möchte die Campaign Performance tracken, während das Sales-Team seine tägliche Pipeline monitoren muss. In einem schlecht designten System extrahieren beide Teams ihre eigenen Daten, schreiben ihre eigenen Business Rules und erschaffen unweigerlich konkurrierende Versionen der Realität. In einer ausgereiften Architektur verbinden beide Teams ihre individuellen Reports mit exakt demselben Semantic Model. Du baust die komplexe Logik genau einmal. Dieses Single Customer Truth Model kann problemlos zehn völlig unterschiedliche Reports im gesamten Unternehmen befeuern. Wenn sich die Definition eines aktiven Kunden nächstes Jahr ändert, updatest du das zentrale Modell. Alle zehn Reports erben die neue Regel automatisch. Wie dieses Modell deine Daten tatsächlich verarbeitet, hängt komplett vom Storage Mode ab, den du bei der Erstellung auswählst. Die beiden primären Paradigmen sind Import und DirectQuery. Der Import Mode zieht die Daten aus deiner Originalquelle, komprimiert sie und lädt sie direkt in die Power BI In-Memory Engine. Das ist die Default-Wahl für die meisten Projekte. Weil die Daten vollständig im Memory liegen, passieren komplexe Berechnungen und interaktives Filtering fast augenblicklich. Deine Reports fühlen sich für den End User extrem schnell an. Die Einschränkung ist, dass du einen Snapshot der Daten cachst. Du musst regelmäßige Refreshes schedulen, um Updates reinzupullen, und es gibt physische Grenzen dafür, wie viele Daten du in den Memory pushen kannst. DirectQuery wählt den entgegengesetzten Ansatz. Es werden niemals Rohdaten importiert. Das Semantic Model speichert nur die strukturellen Metadata, wie Tabellennamen, Spaltentypen und Beziehungen. Wenn ein User in seinem Report auf einen Filter klickt, übersetzt das Modell diesen Klick in eine Live Query und schickt sie direkt an die zugrundeliegende Datenbank zurück. Du verlässt dich auf DirectQuery, wenn dein Dataset einfach zu massiv für den Import ist, oder wenn das Business Near-Real-Time Visibility in das Source System verlangt. Der offensichtliche Trade-off ist die Performance. Ein Report, der im DirectQuery Mode läuft, ist immer nur so schnell wie die Datenbank, die die Fragen beantwortet, und jede Interaktion legt einen Compute Load direkt auf deine Source Systems. Die Visuals in deinem Workspace sind nur leichtgewichtige Fenster, die in die Daten blicken. Das Semantic Model hält die eigentliche Wahrheit, und wenn man das Modell richtig hinbekommt, bauen sich die Reports praktisch von selbst. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 5 von 14. Dein Dashboard mag zwar schön aussehen, ist aber völlig nutzlos, wenn die Zahlen eine Woche alt sind. Die wahre Herausforderung besteht darin, aktuelle Daten in die Cloud zu bekommen, wenn deine eigentliche Datenbank hinter einer strengen Corporate Firewall weggesperrt ist. Genau dieses Problem lösen Data Connectors und das On-Premises Data Gateway. Power BI ist ein leeres Gefäß, bis du es mit Informationen fütterst. Um diese Informationen reinzuziehen, nutzt du Data Connectors. Microsoft liefert hunderte davon out of the box für fast jedes System, das dir einfällt. Stell dir einen Connector wie einen vorgefertigten, spezialisierten Übersetzer vor. Egal, ob deine Daten in einer Oracle-Datenbank, einem Snowflake-Warehouse oder einem Cloud-Service wie Salesforce liegen – der Connector übernimmt das Heavy Lifting. Er managt die spezifischen API Calls, die Authentifizierungsmethoden und die nativen Query-Strukturen, die nötig sind, um mit diesem Zielsystem zu sprechen. Du gibst einfach nur die Credentials an und wählst die Tabellen aus, die du brauchst. Der Connector übersetzt deinen Request in genau die Sprache, die das Source-System versteht. Das heißt, du musst nie wieder Custom Extraction Scripts schreiben. Wenn deine Data Source schon in der Cloud ist, läuft dieser Prozess nahtlos ab. Power BI greift übers Internet darauf zu, authentifiziert sich und zieht die Daten. Aber die Realität sieht für viele Organisationen viel komplizierter aus. Was passiert, wenn deine Daten auf einem physischen Server im Keller deines Büros liegen? Du kannst das cloudbasierte Power BI nicht einfach bitten, in dein privates lokales Netzwerk reinzugreifen. Dafür müsste dein IT-Team Inbound Firewall Ports öffnen und deine interne Datenbank dem öffentlichen Internet aussetzen. Hier ist die entscheidende Erkenntnis: Du musst dein internes Netzwerk nicht der Außenwelt aussetzen, damit Power BI deine Daten lesen kann. Stattdessen nutzt du ein On-Premises Data Gateway. Das Gateway ist ein kleines Stück Software, das du auf einer Maschine in deinem lokalen Netzwerk installierst. Es sitzt hinter deiner Firewall, nah an deinen internen Data Sources. Es fungiert als sichere Outbound-Brücke. Anstatt dass Power BI sich in dein Netzwerk drängt, läuft die Kommunikation komplett umgekehrt ab. Das Gateway checkt ständig eine sichere Cloud Queue über eine standardmäßige Outbound-Internetverbindung. Es fragt die Cloud einfach, ob es irgendwelche pending Data Requests gibt. Weil die Connection von innerhalb deines Netzwerks nach außen initiiert wird, lassen Standard-Firewalls den Traffic ohne spezielle Konfiguration durch. Schauen wir uns ein praktisches Szenario an. Du hast einen Montagmorgen-Sales-Report, der sich um sechs Uhr morgens automatisch refreshen muss. Die rohen Sales-Daten liegen auf diesem durch eine Firewall geschützten Server im Keller. Um sechs Uhr registriert der Power BI Cloud Service einen Scheduled Refresh Request. Momente später pollt dein lokales Gateway die Cloud Queue und schnappt sich diesen Request. Das Gateway lädt die Query-Anweisungen herunter, verbindet sich mit deinen internen Network Credentials direkt mit deiner lokalen Datenbank und führt die Query lokal aus. Sobald der Server im Keller den Request fertig verarbeitet hat, übergibt er die Rohdaten zurück an die Gateway-Software. Das Gateway komprimiert und verschlüsselt diese Daten und pusht sie dann raus an den Power BI Cloud Service. Die Cloud empfängt das verschlüsselte Paket, entschlüsselt es und updatet dein Sales Dashboard. Durch diese Outbound Polling-Methode gibt dir das Gateway die volle analytische Power der Cloud, ohne dass du deine eigentliche Datenbank aus dem Keller holen musst. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 6 von 14. Wenn ein Stakeholder länger als fünf Sekunden braucht, um zu verstehen, was dein Dashboard ihm sagt, hast du seine Aufmerksamkeit verloren. Zehn zusammenhanglose Pie Charts auf einen einzigen Screen zu packen, ist keine Analyse, das ist einfach nur Visual Noise. Eine geführte Data Story zu erstellen, erfordert bewusstes Design, und das bringt uns zur Kunst des Report Canvas. Ein Power BI Report ist ein mehrperspektivischer View auf dein zugrundeliegendes Semantic Model. Der Report Canvas ist der leere Workspace, in dem du diesen View baust. Er ist nicht auf einen einzigen Screen beschränkt. Du kannst einem Report mehrere Pages hinzufügen, ähnlich wie bei einer Präsentation. So kannst du komplexe Business-Fragen in eine logische Sequenz runterbrechen und verschiedene Pages unterschiedlichen Aspekten der Daten widmen. Du füllst den Canvas mit Visuals. Das sind deine Charts, Graphen, Tabellen und Maps. Das richtige Visual auszuwählen, ist nur der erste Schritt. Das Layout bestimmt, wie dein User die Informationen liest. Ein gut designter Canvas führt das Auge ganz natürlich von Top-Level-Metriken runter zu granularen Details. Um komplexe Layouts zu managen, nutzt du Grouping. Grouping erlaubt es dir, mehrere Visuals, Shapes und Textboxen miteinander zu verbinden. Wenn du Items gruppierst, skalieren und bewegen sie sich als eine einzige Einheit. Das hält dein Layout präzise und verhindert, dass sich sorgfältig ausgerichtete Charts verschieben, wenn du die Page anpasst. Um einen professionellen Look über all diese Pages hinweg beizubehalten, nutzt du Themes. Ein Theme ist ein Set aus vordefinierten Farben, Fonts und Formatierungsregeln. Du wendest ein Theme auf den Report an, und jedes Visual updatet sich sofort, um dazu zu passen. Das erzwingt Konsistenz und erspart dir, Farbcodes manuell in dutzende separate Charts einzutippen. Hier ist die wichtigste Erkenntnis: Die wahre Power des Canvas ist nicht, wie die Visuals aussehen, sondern wie sie sich verhalten. In vielen Reporting-Tools sind Charts isolierte Bilder. In Power BI sind Visuals auf derselben Page standardmäßig tief miteinander verbunden. Sie cross-filtern sich ganz natürlich gegenseitig, basierend auf den Relationships in deinem Semantic Model. Denk mal an einen regionalen Performance Report. Du platzierst links ein Bar Chart, das die Sales nach Produktkategorie zeigt, und rechts eine geografische Map mit den Store Locations. Wenn ein User auf den Balken für die Kategorie Elektronik klickt, reagiert die gesamte Page. Die Map highlightet sofort die spezifischen Regionen, die Elektronik verkauft haben, und fadet den Rest der Map aus. Der User hat nach nichts gesucht, und du hast keine Routing Logic geschrieben, um diese Interaktion auszulösen. Der Canvas weiß, dass diese Visuals dieselben zugrundeliegenden Daten teilen. Wenn man also eines berührt, verschiebt sich automatisch der Kontext der anderen. Dieses Verhalten verwandelt eine statische Page in ein interaktives Exploration Tool. Die Kunst des Report Canvas ist es, zu lernen, aus dem Weg zu gehen. Indem du cleane Layouts, konsistente Themes und natives Cross-Filtering kombinierst, erlaubst du dem User, seine eigenen Fragen zu stellen, indem er einfach auf die Daten vor ihm klickt. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 7 von 14. Die besten Reports präsentieren nicht einfach nur Zahlen; sie lassen den End-User eine Unterhaltung mit den Daten führen. Wenn du ein statisches Dashboard baust, das jeden Stakeholder zwingt, sich exakt dieselben aggregierten Summen anzusehen, werden deine User diese Zahlen irgendwann einfach in ein Spreadsheet exportieren, um das zu finden, was sie wirklich interessiert. Das verhinderst du, indem du Daten interaktiv machst. Es gibt zwei Hauptwege, deinen Usern in Power BI die Kontrolle über die Daten zu übergeben. Die Begriffe werden oft synonym verwendet, weil beide Methoden ein ähnliches Endergebnis erzielen, aber die User Experience ist grundlegend verschieden. Wir sprechen von Slicern und der Filters Pane. Ein Slicer ist eine Art Visual, das du direkt auf deinen Report Canvas ziehst. Er sitzt direkt dort neben deinen Balken- und Liniendiagrammen. Weil es ein On-Page Visual ist, ist es extrem präsent. Du benutzt einen Slicer, wenn du den User explizit dazu einladen willst, die Ansicht zu ändern. Nehmen wir zum Beispiel einen nationalen Sales Report. Ein Regional Manager öffnet ihn, will aber eigentlich nur sein eigenes Gebiet sehen. Wenn du einen Slicer zum Canvas hinzufügst und ihn als einfaches Dropdown konfigurierst, kann der Manager seine spezifische Region auswählen. In dem Moment, in dem er diese Auswahl trifft, wird jedes andere Visual auf der Seite sofort aktualisiert, um nur noch diese Region anzuzeigen. Slicer geben dem User die Möglichkeit, einen Drilldown auf genau das zu machen, was in diesem Moment für ihn wichtig ist. Du kannst sie als Listen, Dropdowns oder sogar Date Range Slider formatieren, aber ihr Hauptzweck ist immer die unmittelbare, sichtbare Interaktion. Der zweite Teil davon ist die Filters Pane. Im Gegensatz zu einem Slicer wird ein Filter nicht direkt auf dem Canvas selbst platziert. Er befindet sich in einem dedizierten Side-Panel, das am Rand des Report-Fensters angedockt ist. In der Filters Pane steuerst du den zugrundeliegenden Scope deiner Daten. Sie funktioniert auf mehreren Ebenen. Du kannst ein Datenfeld in die Pane ziehen, um nur ein bestimmtes Chart, eine ganze Seite oder einheitlich jede einzelne Seite in deinem Report zu filtern. Hier ist die wichtigste Erkenntnis. Der größte Unterschied zwischen einem Slicer und einem Filter liegt in der Sichtbarkeit und Kontrolle. Slicer sind für den User immer sichtbar. Filter müssen das nicht sein. Als Report Creator kannst du einen Filter sperren, sodass der User ihn nicht ändern kann, oder du kannst ihn komplett verstecken. Wenn du eine Version deines Reports bauen willst, die immer nur Daten aus dem aktuellen Geschäftsjahr zeigt, würdest du einen versteckten Page-Level Filter für das Jahr anwenden. Der End-User sieht niemals einen Button oder ein Dropdown. Er interagiert einfach mit einem Report, der sicher auf den richtigen Zeitraum eingegrenzt ist. Du wirst oft beide Tools auf exakt derselben Seite benutzen. Du legst die Baseline-Regeln deiner Daten mit der Filters Pane fest und ziehst damit quasi eine Box um das, was der User sehen darf. Dann platzierst du ein paar strategische Slicer auf dem Canvas, damit der User innerhalb dieser Box frei erkunden kann. Dieser Ansatz hält deinen Canvas clean. Wenn du versuchen würdest, jede mögliche Variable in einen Slicer zu verwandeln, würde dein Report unlesbar werden. Die Filters Pane räumt die sekundären Settings aus dem Weg, während sie die wichtigsten Auswahlmöglichkeiten im Vordergrund behält. Gib deinen Usern On-Canvas Slicer für die Fragen, die sie jeden Tag stellen müssen, und nutze die Side-Pane Filter, um die Regeln durchzusetzen, die sie niemals brechen dürfen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 8 von 14. Die größte Herausforderung beim Report Design ist das Spannungsfeld zwischen Übersichtlichkeit und Detailtiefe. Du willst eine Main Page, die clean aussieht und sofort die High-Level-Story erzählt, aber deine Power User verlangen jeden einzelnen granularen Datenpunkt. Wenn du alles auf eine Seite packst, wird es unlesbar. Die Lösung dafür ist, Komplexität nur eine Interaktion entfernt zu verstecken, indem du kontextbezogene Deep Dives nutzt. Schauen wir uns zuerst Custom Report Page Tooltips an. Standardmäßig zeigt Power BI, wenn ein User über einen Datenpunkt in einem Visual hovert, eine einfache Textbox mit dem genauen Wert dieses Punktes. Das gibt dir zwar eine Zahl, aber keinen Kontext. Ein Report Page Tooltip lässt dich diese Default-Box durch einen komplett angepassten Canvas ersetzen. Du baust eine winzige, versteckte Report Page und konfigurierst sie so, dass sie erscheint, wenn ein User über ein Visual hovert. Statt einer nackten Zahl kannst du direkt im Hover-Fenster eine kleine Trendlinie oder ein Gauge Chart anzeigen. Nimm zum Beispiel ein Map Visual, das die Total Sales nach Stadt zeigt. Wenn ein User mit dem Cursor über die Data Bubble für Seattle hovert, poppt ein Custom Tooltip auf. In diesem Pop-up ist ein Miniatur-Bar-Chart, das die Seattle-Sales der letzten zwölf Monate aufschlüsselt. Der User erfasst diesen zusätzlichen Information Layer sofort und verlässt dabei nie die Main Map Page. Manchmal reicht ein kurzes Hovern nicht aus. Wenn ein User ein komplettes Audit für einen bestimmten Datenpunkt durchführen muss, nutzt du eine Drillthrough Page. Drillthrough ist für Deep Investigations gemacht. Du erstellst eine komplett separate, detaillierte Report Page und weist ihr ein bestimmtes Field zu, wie eine geografische Location oder eine Product Category. Dadurch weiß Power BI, dass diese Seite ein Ziel für Drillthrough Actions ist. Gehen wir zurück zu derselben Map. Der User hovert über Seattle, sieht den monatlichen Trend, entscheidet aber, dass die Zahlen einen genaueren Blick erfordern. Er macht einen Rechtsklick auf die Seattle-Bubble und wählt Drillthrough. Power BI holt ihn von der Map weg und bringt ihn auf deine Detail Page. Entscheidend ist, dass die Selection weitergegeben wird. Die neue Page wird automatisch gefiltert, um nur Daten für Seattle anzuzeigen. Jetzt sieht er eine umfassende Tabelle mit Raw Invoice Transactions. Die Grenzen zwischen diesen beiden Features verschwimmen leicht. Tooltips sind Custom Hover-Boxen, die Mini-Visuals zeigen, ohne die aktuelle Page zu verlassen. Sie sind für einen schnellen Blick gedacht. Drillthrough bringt den User auf eine komplett neue Detail Page, die exakt auf seine Selection gefiltert ist. Das erfordert einen expliziten Klick und ist für Heavy Analysis gedacht. Hier ist der Key Insight: Du musst keine überladenen Transaction Tables neben deine High-Level Executive Summaries quetschen. Nutze Tooltips, um die unmittelbare Follow-up-Frage zu beantworten, und verlasse dich auf Drillthrough Pages, um die Heavy Audits zu übernehmen. Dein Main Dashboard bleibt schnell und aufgeräumt, während deine User trotzdem genau auf die Daten zugreifen können, die sie brauchen. Wenn du die Show unterstützen willst, kannst du auf Patreon nach DevStoriesEU suchen – das hilft uns wirklich sehr. Danke fürs Dabeisein. Ich hoffe, du konntest etwas Neues mitnehmen.

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 9 von 14. Mit einfachem Drag-and-Drop von Feldern auf ein Canvas kommst du nur bedingt weiter. Irgendwann muss dein Report komplexe Fragen beantworten, die nicht explizit in deiner Datenbank stehen. Hier kommen Data Analysis Expressions, oder DAX, ins Spiel. Es ist verlockend, DAX einfach für erweiterte Excel-Formeln zu halten. Sie sehen ähnlich aus und viele Funktionsnamen sind identisch. Aber Excel arbeitet auf einem Grid aus statischen, einzelnen Zellen. DAX hingegen operiert komplett auf ganzen Spalten und Tabellen. Du lässt DAX niemals auf Zeile 3, Spalte C zeigen. Du lässt es auf die Sales Amount Column zeigen und lässt die Engine den Rest erledigen. Um DAX zu entmystifizieren, musst du nur zwei grundlegende strukturelle Konzepte beherrschen. Das sind Calculated Columns und Measures. Eine Calculated Column wird Row-by-Row ausgewertet. Wenn du eine Column brauchst, die den Unit Price mit der Quantity Sold für jede einzelne Transaktion multipliziert, nutzt du eine Calculated Column. Die Engine berechnet das Ergebnis einmalig, wenn die Daten geladen oder gerefresht werden, und speichert es im Memory. Es wird zu einem physischen Bestandteil deines Datasets und eignet sich daher super zum Kategorisieren von Daten oder zum Erstellen von Achsen in einem Chart. Hier ist die wichtigste Erkenntnis: Calculated Columns sind statisch. Sie ändern sich nicht, wenn der User mit deinem Dashboard interagiert. Measures hingegen sind komplett dynamisch. Ein Measure berechnet nicht Row-by-Row und speichert keine vorberechneten Werte im Memory. Stattdessen berechnet es on-the-fly ein Aggregate, gesteuert durch den sogenannten Filter Context. Filter Context bedeutet einfach die Kombination von Filtern, die in jedem beliebigen Moment in deinem Report aktiv sind. Das ist der Teil, auf den es ankommt. Wenn ein User ein bestimmtes Jahr auf einer Timeline anklickt oder eine bestimmte Region aus einem Drop-down-Menü auswählt, ändert er den Filter Context. Das DAX-Measure lauscht auf diese Klicks, schränkt die zugrunde liegenden Tabellen im Memory passend zur Auswahl ein und berechnet das Endergebnis sofort neu. Stell dir ein Szenario vor, in dem du ein einziges DAX-Measure für das Year-over-Year Growth schreibst. Weil es ein Measure ist, ist es nicht an eine spezifische View gebunden. Wenn dein User sich eine High-Level Summary Card ansieht, berechnet exakt dasselbe Measure das globale Wachstum für das gesamte Unternehmen. Klickt er auf einer Map auf die Region Europa, wird das Measure sofort neu berechnet und zeigt nur das europäische Wachstum an. Wenn er es weiter nach einer bestimmten Product Line im November slicet, gibt dasselbe Measure das Wachstum nur für dieses Produkt in diesem Monat aus. Du schreibst die zugrunde liegende Mathematik ein einziges Mal, und der Filter Context übernimmt die harte Arbeit, sie auf das anzuwenden, was der User sehen möchte. Calculated Columns bilden die Struktur, nach der du slicest. Measures führen die Mathematik dynamisch basierend auf diesen Slices aus. Diese Unterscheidung zu begreifen, verhindert massive Performance-Bottlenecks, wie zum Beispiel den Versuch, eine speicherintensive Row Calculation dazu zu zwingen, den Job eines dynamischen Aggregates zu übernehmen. Die wahre Power von DAX liegt nicht im Auswendiglernen hunderter verschiedener Funktionen, sondern in dem Verständnis, dass jede Berechnung innerhalb einer unsichtbaren, sich ständig verschiebenden Grenze stattfindet, die vom User gesetzt wird. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 10 von 14. Executives haben keine Zeit, sich durch fünf verschiedene, mehrseitige Dokumente zu klicken, nur um herauszufinden, ob das Business gut läuft. Sie wollen das Wichtigste auf einem Screen, und zwar sofort. Das Feature, das speziell gebaut wurde, um dieses Problem zu lösen, ist das Power BI Dashboard. Leute verwenden die Wörter Report und Dashboard oft synonym. Im Power BI Ecosystem musst du sie aber als völlig unterschiedliche Konzepte betrachten. Ein Report ist ein mehrseitiges, interaktives Tool für analytische Deep Dives und ist fast immer an ein einziges zugrundeliegendes Dataset gebunden. Ein Dashboard ist strikt ein Single-Page Canvas. Es ist eine Executive Summary. Außerdem baust du Dashboards nicht in Power BI Desktop. Sie sind ein Artefakt, das exklusiv für den Power BI Service ist. Du baust zuerst deine Reports, veröffentlichst sie und erstellst das Dashboard dann komplett im Browser. Stell dir einen CEO vor, der jeden Morgen drei bestimmte Metriken auf seinem Smartphone checken möchte. Er muss den täglichen Umsatz, die Server Uptime und den aktuellen Customer Satisfaction Score sehen. Diese Metriken stammen natürlich aus völlig voneinander getrennten Bereichen des Business. Die Umsatz-Metrik lebt in einem komplexen Financial Report. Die Server Uptime wird in einem dedizierten IT-Infrastruktur-Report getrackt. Der Satisfaction Score liegt auf Seite drei eines Marketing-Reports. Du kannst diese drei unterschiedlichen Datasets nicht einfach so in einem Standard-Report mergen. Stattdessen erstellst du ein Dashboard über einen Mechanismus namens Pinning. Du navigierst im Browser zum veröffentlichten Financial Report, wählst das Total Revenue Card Visual aus und pinnst es an ein neues Dashboard. Dann öffnest du den IT-Report, schnappst dir das Server Uptime Gauge und pinnst das an dasselbe Dashboard. Zum Schluss machst du genau das Gleiche für den Satisfaction Score im Marketing-Report. Sobald sie an den Dashboard Canvas gepinnt wurden, werden diese einzelnen Visuals als Tiles bezeichnet. Dein Single-Page Dashboard ist jetzt eine kuratierte Sammlung von Tiles, die Live-Daten aus mehreren verschiedenen Reports ziehen, was bedeutet, dass es mehrere unterschiedliche zugrundeliegende Datasets überbrückt. Diese Cross-Report Aggregation ist genau der Grund, warum Dashboards existieren. Sie durchbrechen die Grenzen einzelner Datasets, um eine Unified View zu erstellen. Wenn ein Executive dieses Dashboard öffnet, bekommt er ein sofortiges Status-Update auf einen Blick. Er interagiert hier nicht mit den Daten, so wie er es in einem Report tun würde. Stattdessen fungieren die Tiles als Entry Points. Wenn das Daily Revenue Tile einen plötzlichen Drop zeigt, klickt der Executive einfach auf genau dieses Tile. Diese Aktion holt den User sofort aus dem Dashboard heraus und bringt ihn direkt in den zugrundeliegenden Financial Report, aus dem dieses Visual stammt. Hier ist die Key Insight. Das Dashboard ist kein Ersatz für deinen detaillierten Reporting Layer. Es ist ein Curation Layer, der oben drauf sitzt. Ein gut designtes Dashboard versucht nicht, jede mögliche analytische Frage zu beantworten; es leitet den User einfach zu genau dem zugrundeliegenden Report, der die Antworten enthält, die er genau jetzt braucht. Danke fürs Einschalten. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 11 von 14. Wenn du einen Workspace mit 500 Leuten teilst, die sich nur Daten ansehen müssen, machst du einen Fehler. Du zeigst ihnen das Chaos in der Küche, obwohl sie eigentlich nur zum Essen gekommen sind. Der richtige Weg, fertige Inhalte auszuliefern, ist, die Experience zu verpacken, und das bedeutet die Nutzung einer Power BI App. Eine Power BI App ist kein eigenständiges Softwareprogramm, das du aus einem Phone Store herunterlädst. In diesem Kontext ist eine App eine gebündelte Sammlung von Dashboards und Reports, die als ein einziges, einheitliches Package präsentiert wird. Sie ist die offizielle Distribution Method für deinen fertigen Power BI Content. Lass uns gleich das größte Missverständnis klären, nämlich den Unterschied zwischen einem Workspace und einer App. Ein Workspace ist deine Küche. Dort verbinden sich die Report Creator mit Daten, bauen Models und testen verschiedene Chart-Layouts. Es ist ein kollaborativer Bereich für Builder, der mit Draft-Reports und rohen Datasets überladen sein kann. Die App ist das Esszimmer. Sie ist sauber, organisiert und strikt für die Consumption gedacht. Wenn du eine App publishst, nimmst du die fertigen Teller aus der Küche und präsentierst sie deinen Gästen. Stell dir vor, du releast die offiziellen Company Metrics für 2026 an 500 Mitarbeiter in verschiedenen Abteilungen. Du willst nicht, dass sie in einem Workspace herumsuchen müssen, um herauszufinden, welcher Report die finale Version ist. Du willst ihnen auch nicht fünf verschiedene Weblinks schicken. Stattdessen erstellst du eine App. Wenn du eine App baust, wählst du genau aus, welche Dashboards und Reports aus deinem Workspace inkludiert werden sollen. Die Drafts lässt du zurück. Dann designst du ein Custom-Navigationsmenü. Hier wird es interessant. Statt einer flachen Liste von Files kannst du zusammengehörige Reports unter ausklappbaren Headern gruppieren. Du kannst die Pages so anordnen, dass die Story logisch von High-Level-Summaries bis hin zu granularen Details fließt. Du kannst sogar eine bestimmte Theme-Farbe anwenden und dein Company-Logo hinzufügen. Für den End-User ist die Experience nahtlos. Er installiert die App einmalig aus seinem Organizational Directory. Wenn er die App öffnet, bekommt er ein gebrandetes, Read-only-Interface. Es gibt keine Edit-Buttons, die ihn ablenken. Er kann nicht versehentlich ein Visual löschen oder das Dataset verändern. Er nutzt einfach das Side-Menu, um sich durch die Reports zu klicken. Wenn er die Power BI Mobile Application öffnet, funktionieren die App und ihre Custom-Navigationsstruktur dort ebenfalls perfekt. Hier ist der wichtigste Punkt für die Maintenance dieses Contents. Weil der Workspace und die App getrennt sind, kannst du Reports updaten, ohne die User Experience kaputt zu machen. Wenn eine Metric angepasst werden muss, machst du diese Änderung in der Workspace-Küche. Deine 500 User sehen deine kaputten Visuals oder halbfertigen Charts nicht, während du arbeitest. Ihre App bleibt exakt gleich, bis du komplett fertig bist. Sobald du fertig bist, klickst du bei der App auf Update, und die neue Version geht für alle gleichzeitig live. Wenn du einem großen Publikum ein zusammenhängendes, leicht zu navigierendes Set an Reports ausliefern musst, baue den Workspace für deine Authors, aber verpacke die App für deine Consumer. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 12 von 14. Der schnellste Weg, um zu garantieren, dass niemand dein Dashboard ansieht, ist, die Leute dazu zu zwingen, einen neuen Browser-Tab zu öffnen, ein Bookmark zu suchen und sich in einem separaten Portal einzuloggen. Context Switching killt die Adoption. Wenn du willst, dass die Leute Daten nutzen, musst du sie genau dort bereitstellen, wo sie ohnehin schon kommunizieren. Das ist der Kerngedanke hinter Meeting Users Where They Work. Für die meisten Organisationen ist dieser Ort Microsoft Teams. Power BI integriert sich tief in Teams, um die Reibung durch Context Switching zu beseitigen. Anstatt einen Link zu einem Dashboard in einem Chat zu schicken, holst du das Dashboard direkt in den Workspace. Stell dir ein Lager-Team vor, das jeden Morgen die Bestände checken muss. Du kannst einen Live-Inventar-Report direkt als Tab in ihrem dedizierten Teams-Channel anpinnen. Sie klicken auf den Tab, und die Daten sind einfach da, direkt neben ihren morgendlichen Nachrichten. Es gibt ein häufiges Missverständnis darüber, wie das Ganze aussieht. Einen Report in Teams zu pushen, bedeutet nicht, einfach nur einen statischen Screenshot oder ein unverbundenes PDF zu schicken. Es bettet den kompletten, interaktiven Live-Power-BI-Report sicher in den Teams-Client ein. User können die Daten direkt im Channel slicen, filtern und einen Drill-down durchführen. Die Security-Permissions bleiben dabei strikt durchgesetzt. Wenn ein User nicht die Permission hat, die Daten im Power BI Service zu sehen, kann er sie auch in Teams nicht sehen. Du kannst außerdem einen Conversation-Thread starten, der direkt an ein bestimmtes Report-Visual angehängt ist, sodass die Diskussion und die Daten im exakt selben Kontext bleiben. Das deckt die tägliche Kommunikation ab. Schauen wir uns nun Executive-Meetings an. Präsentationen sind typischerweise der Ort, an dem Daten sterben. Jemand macht einen Screenshot von einem Chart, fügt ihn in eine Slide ein, und fünf Minuten später updatet sich die zugrundeliegende Datenbank. Die Slide ist sofort veraltet. Power BI löst das, indem es dir erlaubt, Live-Report-Pages direkt in PowerPoint-Slides einzubetten. Wenn du die Präsentation öffnest, zieht sich das Chart die neuesten Zahlen. Hier ist die wichtigste Erkenntnis: Weil der eingebettete Report komplett interaktiv ist, verändert er, wie Meetings ablaufen. Wenn ein Stakeholder eine spezifische Frage zu einem Spike in den Sales stellt, musst du sie nicht aufschreiben und versprechen, später ein Follow-up zu machen. Du kannst diesen Datenpunkt direkt auf der Präsentations-Slide anklicken, die Visuals cross-filtern und die Frage live beantworten. Zu guter Letzt haben wir Excel. Du wirst Business-User nie davon abhalten können, Daten in einem Spreadsheet haben zu wollen. Anstatt dieses Verhalten zu bekämpfen und zuzusehen, wie Leute statische, unkontrollierte CSV-Files exportieren, kannst du Power BI nahtlos in Excel integrieren. User können PivotTables, Charts und Standard-Excel-Formeln direkt mit einem veröffentlichten Power BI Dataset verbinden. Die Daten bleiben zentral gemanagt, gesichert und akkurat auf dem Server. Währenddessen können die User diese Single Source of Truth über das Grid-Interface analysieren, das sie bereits kennen. Du baust keine datengetriebene Kultur auf, indem du alle zwingst, eine neue Standalone-Application zu lernen. Du erreichst das, indem du vertrauenswürdige Live-Daten direkt in die Communication-Tools integrierst, die sie ohnehin jeden einzelnen Morgen öffnen. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Folge 13 von 14. Wahrscheinlich verbringst du zu viel Zeit damit, Dashboards zu refreshen, nur um zu checken, ob alles reibungslos läuft. Deinen Usern geht es genauso: Sie loggen sich jeden Morgen ein, nur um zu bestätigen, dass die Zahlen normal sind. Verlass dich nicht länger auf Menschen, um Routineprobleme zu checken. Lass dir von den Daten sagen, wenn etwas schiefgeht. Das ist die Kernidee hinter proaktiver BI, die man erreicht, indem man Power BI Data Alerts mit Power Automate kombiniert. Traditionell ist Business Intelligence reaktiv. Du baust einen Report, veröffentlichst ihn und wartest darauf, dass ihn jemand öffnet. Proaktive BI dreht dieses Modell um. Das System überwacht sich selbst und pusht Informationen nur dann zu dir, wenn deine Aufmerksamkeit wirklich gefragt ist. Sobald eine bestimmte Metrik einen vordefinierten Threshold überschreitet, wird das System sofort aktiv. Bevor wir das aufsetzen, müssen wir ein häufiges Missverständnis ausräumen. Du kannst diese automatisierten Alerts nicht einfach an irgendein Visual tief in einer komplexen Report-Seite hängen. Data Alerts in Power BI sind strikt an bestimmte Visual-Typen auf einem Dashboard gebunden. Du kannst sie nur für Single-Value Tiles konfigurieren, genauer gesagt für Gauges, KPIs und Cards. Wenn du eine kritische Metrik in einem detaillierten Report überwachen willst, musst du dieses spezifische Visual zuerst an ein Dashboard pinnen, um das Alerting-Feature freizuschalten. Lass uns ein konkretes Szenario durchgehen. Angenommen, du trackst die täglichen Sales für einen großen Einzelhandelsstandort. Die Baseline-Erwartung liegt bei zehntausend Dollar am Tag. Wenn die Sales unter diesen Wert fallen, ist es zu spät, darauf zu warten, dass ein Manager am Freitag das Dashboard checkt. Du brauchst eine sofortige Reaktion. Zuerst konfigurierst du einen Data Alert auf der Dashboard Card, die die täglichen Sales anzeigt. Du definierst eine Rule, die Power BI sagt, dass ein Alert getriggert werden soll, wenn der Wert unter zehntausend fällt. Pass an dieser Stelle gut auf. Power BI überwacht die Source-Datenbank nicht in Echtzeit. Stattdessen evaluiert das System jedes Mal, wenn das zugrundeliegende Power BI Dataset refresht wird, die neue Zahl auf dieser Card. Wenn die Condition erfüllt ist, feuert der Alert. Standardmäßig generiert ein getriggerter Alert einfach eine Notification im Power BI Service oder schickt eine einfache E-Mail an die Person, die die Rule erstellt hat. Um das im ganzen Unternehmen wirklich nützlich zu machen, integrierst du es mit Power Automate. Power Automate sitzt leise im Hintergrund und lauscht auf diesen spezifischen Power BI Data Alert. Wenn der Alert feuert, übergibt Power BI einen Data Payload an Power Automate. Dieser Payload enthält den Alert-Titel, den von dir gesetzten Threshold und den tatsächlichen Wert, der die Rule gebrochen hat. Du nutzt diese dynamischen Werte, um einen Downstream-Workflow zu bauen. Du kannst den Flow so konfigurieren, dass in dem Moment, in dem die Sales-Metrik fällt, zwei Dinge automatisch passieren. Erstens extrahiert der Flow den tatsächlichen Sales-Wert und pusht eine sofortige Notification direkt auf das Handy des Store Managers. Zweitens verschickt er eine automatisierte E-Mail an das regionale Team mit den genauen Zahlen und einem direkten Link zurück zum Dashboard für weitere Analysen. Niemand musste Power BI manuell öffnen, um das Problem zu entdecken. Indem du Dashboard Alerts mit Downstream-Automatisierung integrierst, entfernst du den menschlichen Flaschenhals aus der Incident Response. Der wahre Wert eines Monitoring-Systems misst sich nicht daran, wie viele Leute jeden Tag darauf starren, sondern daran, wie schnell es eine Aktion erzwingt, sobald eine kritische Grenze durchbrochen wird. Das war's für diese Folge. Danke fürs Zuhören, und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Power BI Fundamentals, Episode 14 von 14. Du starrst auf ein leeres Canvas und brauchst bis zum Ende des Tages einen umfassenden Sales Report. Anstatt stundenlang Felder per Drag & Drop zu verschieben, stellst du einfach eine Frage in Plain Text, und das Layout baut sich von selbst auf. Die Zukunft der Business Intelligence ist conversational, angetrieben von Copilot in Power BI. Es gibt die ständige Befürchtung, dass Artificial Intelligence hier ist, um den Data Analyst zu ersetzen. Das ist nicht der Fall. Copilot ist ein mächtiger Assistent, der speziell dafür entwickelt wurde, deinen ersten Draft zu beschleunigen. Er übernimmt das mühsame initiale Setup, sodass du dich darauf konzentrieren kannst, die eigentlichen Insights zu verfeinern. Er schließt die Lücke zwischen Raw Data und einem fertigen Report mithilfe von Natural Language, was die initiale Erstellungsphase viel schneller macht. Wenn du den Report Builder öffnest, kannst du direkt mit der Copilot Pane interagieren. Du tippst einen Prompt ein, zum Beispiel die Bitte, eine Summary der Sales Performance zu erstellen. Copilot analysiert sofort dein zugrundeliegendes Semantic Model. Er ermittelt basierend auf deinem Request, welche Metrics wichtig sind, wählt die passenden Visual Types aus und generiert automatisch eine komplette Report-Seite. Du musst keine Bar Charts manuell platzieren oder Achsen konfigurieren, um loszulegen. Du gibst deinen Intent an, und das System übersetzt diesen Intent in ein konkretes Layout. Das verändert grundlegend, wie du an die Report-Erstellung herangehst – weg von manueller Konstruktion, hin zu High-Level Direction. Hier ist das Key Insight: Copilot baut nicht nur Charts, er schreibt die Story deiner Daten. Neben den Visuals generiert er eine Narrative Text Box, die die Key Drivers und Trends in Plain English zusammenfasst. Das ist kein statischer Text. Weil er direkt an das Semantic Model angebunden ist, ist das Narrative komplett dynamisch. Wenn sich die zugrundeliegenden Daten über Nacht ändern, oder wenn ein User auf eine bestimmte Region in einem Map Visual klickt, schreibt sich der Text sofort neu, um diesen neuen Kontext widerzuspiegeln. Die Summary bleibt immer mit der aktuellen View der Daten synchronisiert, ohne dass manuelle Updates nötig sind. Dieses Conversational Interface senkt die Einstiegshürde für das Generieren von Insights drastisch. Du brauchst kein tiefes technisches Wissen über das Tool, um Value aus den Daten zu ziehen. Trotzdem behältst du die absolute Kontrolle. Sobald die AI dieses initiale Layout und Narrative generiert hat, greifst du wieder ein. Du kannst Visuals in der Größe anpassen, das Formatting tweaken oder das Narrative modifizieren, damit es genau deinen Spezifikationen entspricht. Es ist ein kollaborativer Workflow. Copilot baut das massive Fundament, und du kümmerst dich um den letzten Schliff, um sicherzustellen, dass das finale Produkt euren Unternehmensstandards entspricht. Die wahre Power von Natural Language in der Business Intelligence liegt nicht nur darin, ein paar Mausklicks zu sparen. Es geht darum, die Friction zwischen einer Business-Frage und der Antwort auf dem Screen komplett zu beseitigen. Da das die letzte Episode unserer Fundamentals-Serie ist, empfehle ich dir sehr, die offizielle Microsoft-Dokumentation zu erkunden und diese Features hands-on mit deinen eigenen Semantic Models auszuprobieren. Wenn du Ideen hast, was wir als Nächstes behandeln sollen, besuche devstories dot eu, um Themen für zukünftige Serien vorzuschlagen. Das war's für diese Folge. Danke fürs Zuhören und keep building!