Datenanalyse & Dashboards generieren

Datenanalyse & Dashboards generieren

0:00 Zwischen einer Datenbank und einer Folie, die jemand im Meeting versteht, liegen normalerweise mehrere Werkzeuge und mehrere Menschen. Jemand schreibt die Abfrage, jemand baut die Tabelle, jemand macht daraus eine Präsentation — und bei jeder Übergabe geht Zeit und ein wenig Genauigkeit verloren. In diesem letzten Kapitel gehen wir diesen Weg einmal komplett, und zwar aus einem einzigen Werkzeug heraus: von der unbekannten Datenbank über die Auswertung in Notebook oder Excel bis zum fertigen Deck.

0:27 Ein schöner Abschluss, denn hier laufen viele Fäden der vergangenen Kapitel zusammen.

Datenanalyse & Dashboards generieren

0:32 Drei Stationen, und sie folgen dem natürlichen Weg einer Auswertung. Zuerst die Exploration: Was steckt überhaupt in diesen Daten? Dann das Festhalten der Erkenntnisse in einer Form, die andere ausführen oder öffnen können — Notebook oder Excel, je nach Publikum. Und zum Schluss die Kommunikation: aus den Ergebnissen wird eine Präsentation.

0:53 Der rote Faden ist diesmal wörtlich zu nehmen: von den Rohdaten bis zum vorzeigbaren Ergebnis, ohne Werkzeugwechsel.

Datenbankexploration

1:01 Am Anfang steht fast immer dieselbe Situation: Sie bekommen Zugang zu einer Datenbank, die jemand anders gebaut hat, und niemand kann Ihnen genau sagen, was darin steht. Genau hier fangen wir an. Stellen Sie sich vor, Sie kommen in ein fremdes Archiv: Hunderte Ordner, keine Beschriftung, und irgendwo darin steht die Antwort auf Ihre Frage.

1:21 Was Sie zuerst brauchen, ist kein Detail, sondern ein Überblick. Genau das leistet die Exploration. Über einen Daten-MCP — Sie erinnern sich an das MCP-Kapitel, hier etwa DuckDB oder MotherDuck — scannt Claude Code zunächst das Schema und erkundet dann per SQL, wie die Daten verteilt sind. Das Beispiel im Kurs sind Taxi-Daten: Welche Routen kommen häufig vor, wo häufen sich die Fahrten?

1:44 Aus solchen Fragen entsteht in wenigen Minuten ein Bild, für das man früher einen halben Tag gebraucht hätte. Der zweite Punkt ist der, auf den es ankommt: Muster werden sichtbar statt vermutet. Wir alle haben Annahmen darüber, wie unsere Daten aussehen, und erstaunlich viele davon stimmen nicht — sie stammen aus einer Zeit, als das System kleiner war, oder von einem Kollegen, der es auch nur gehört hat.

2:08 Ein schneller Blick auf die tatsächliche Verteilung räumt damit auf. Der dritte Punkt ist die praktische Erleichterung: SQL direkt aus dem Terminal, ohne ein weiteres Werkzeug zu öffnen. Und der vierte beschreibt die richtige Reihenfolge — erst schauen, dann Hypothesen bilden. Nicht umgekehrt. Vier Schritte, die vom Groben ins Feine gehen. Die Anbindung kennen Sie schon aus dem MCP-Kapitel, das ist ein Einzeiler.

2:33 Dann kommt der Schemascan — der Grundriss des Archivs, bevor Sie den ersten Ordner öffnen. Erst danach folgen die aggregierenden Abfragen, und im vierten Schritt halten Sie fest, was aufgefallen ist. Dieses Festhalten ist wichtiger, als es aussieht: Aus Auffälligkeiten werden Hypothesen, und Hypothesen sind das, was Sie später gezielt prüfen.

2:53 Die Fußzeile wiederholt eine Regel aus dem MCP-Kapitel, und sie verdient die Wiederholung: erst nur lesen. Verändernde Schritte gehören bewusst getrennt. Diese Abfrage ist bewusst so simpel, wie sie aussieht — und genau das ist die Lehre. Sie stellt eine einzige Frage: Welche Zonen kommen am häufigsten vor? Kein Join, keine Unterabfrage, nur zählen, gruppieren, sortieren und die ersten zehn anzeigen.

3:17 Für den ersten Blick auf unbekannte Daten ist das fast immer die richtige Form, denn sie zeigt Ihnen die Verteilung, und die Verteilung zeigt Ihnen, wo es interessant wird. Erfahrene Analystinnen beginnen praktisch immer so. Wenn hier drei Zonen achtzig Prozent aller Fahrten ausmachen, wissen Sie sofort, worüber sich das Nachdenken lohnt — und worüber nicht.

3:39 Nehmen Sie sich jetzt eine Datenbank vor, die Sie nicht gut kennen — im Zweifelsfall eine aus einem älteren Projekt. Der Hinweis gibt Ihnen die Reihenfolge vor, und sie ist mehr als ein Tipp: grobe Verteilung vor Detailanalyse. Die Versuchung ist groß, sofort die eine spannende Frage zu stellen; ohne Überblick misslesen Sie dann aber die Antwort.

3:58 Verlangen Sie beim Ergebnis auch die Erklärung — nicht nur die Zahlen, sondern was sie bedeuten. Das ist übrigens ein guter Test für den Agenten: Wer eine Verteilung erklären kann, hat die Daten tatsächlich angeschaut.

Jupyter Notebooks & Excel

4:11 Eine Erkenntnis im Terminal ist eine flüchtige Sache. Sobald die Sitzung zu Ende ist, bleibt bestenfalls die Erinnerung. Deshalb geht es jetzt darum, Analysen in eine Form zu bringen, die jemand anders öffnen, nachvollziehen und wiederholen kann. Hier stehen zwei Formate nebeneinander, und die Wahl zwischen ihnen ist im Kern eine Frage nach dem Publikum.

4:33 Ein Jupyter-Notebook ist ein Dokument, in dem Text, Code und Ergebnisse abwechselnd stehen — man kann es lesen wie einen Bericht und jederzeit neu ausführen. Excel dagegen ist das Format, das praktisch jeder öffnen kann, ohne irgendetwas zu installieren. Claude Code erzeugt beides, im Fall von Excel über Bibliotheken wie `openpyxl`, inklusive Pivot-Tabellen und Diagrammen.

4:54 Sie entscheiden also nicht zwischen gut und schlecht, sondern zwischen reproduzierbar und breit zugänglich. Die ersten beiden Punkte gehören zusammen und beschreiben die Stärke des Notebooks: Eine Analyse ist dort nicht das Ergebnis, sondern der Weg dorthin — lesbar, ausführbar, ergänzbar. Wer in drei Monaten fragt „wie kam diese Zahl zustande?", bekommt eine Antwort, die man nachrechnen kann.

5:17 Der dritte Punkt ist die andere Realität: Ihre Empfänger haben oft keine Code-Umgebung, und eine Excel-Datei erreicht sie ohne Diskussion. Und Pivot-Tabellen sind dabei mehr als Formatierung — sie fassen große Datenmengen so zusammen, dass jemand ohne Vorwissen die Struktur erkennt. Beides zusammen deckt fast jeden Empfängerkreis ab.

5:37 Interessant an diesem Ausschnitt ist nicht, was er tut — er baut eine simple Tabelle mit zwei Spalten —, sondern dass er es als Code tut. Eine Excel-Datei entsteht hier nicht durch Klicken, sondern durch ein Skript. Der Unterschied zeigt sich beim zweiten Mal: Kommen nächsten Monat neue Daten, lassen Sie das Skript einfach erneut laufen.

5:56 Kein Nachbauen, kein vergessener Zwischenschritt, keine Frage, welche Version die aktuelle ist. Das ist die Botschaft der Fußzeile, und sie gilt weit über Excel hinaus: Wenn die Analyse als ausführbarer Code vorliegt, ist sie jederzeit wiederholbar — und damit überprüfbar. Überführen Sie eine Ihrer Auswertungen jetzt in eine dieser beiden Formen.

6:16 Der Hinweis nimmt Ihnen die Entscheidung ab, und zwar nach dem Kriterium, das tatsächlich zählt: Excel für Empfänger ohne Code-Umgebung, Notebook für Analysen, die reproduzierbar sein sollen. Wichtig ist der zweite Teil des Erfolgskriteriums — das Ergebnis muss mit den Daten übereinstimmen. Prüfen Sie das stichprobenartig nach, gerade bei aggregierten Zahlen.

6:37 Eine hübsch formatierte Tabelle mit falschen Summen ist gefährlicher als gar keine, weil ihr jeder glaubt.

Automatisierte Präsentationen

6:43 Bleibt der letzte Schritt, und es ist der, den man am liebsten jemand anderem gäbe: aus dem Ergebnis etwas machen, das man zeigen kann. Auch dieser Schritt lässt sich automatisieren — dieses Deck hier ist der Beweis. Aus den aggregierten Ergebnissen erzeugt Claude Code ein fertiges Deck mit Visualisierungen — und zwar im Code generiert, etwa über eine Bibliothek wie `pptxgenjs`.

7:06 Für dieses Vorgehen gibt es ein Beispiel, das Sie gerade vor sich haben: Diese Präsentation stammt aus dem Foliogen-Repo, wo genau das passiert. Markdown geht hinein, ein geprüftes Deck kommt heraus. Der entscheidende Unterschied zum Klicken in PowerPoint ist derselbe wie eben beim Excel-Beispiel: Was aus Code entsteht, lässt sich reproduzieren.

7:26 Ändern sich die Zahlen, baut man das Deck neu, statt zwölf Folien von Hand nachzuziehen. Der erste Punkt benennt die Lücke, die hier geschlossen wird: Der Weg von der Analyse zur Kommunikation war bisher der einzige Schritt, der zwingend Handarbeit blieb — und oft der zeitraubendste. Der dritte Punkt ist der qualitative: Ein Deck aus Code ist reproduzierbar, nicht handgeklickt. Das klingt nach einem Detail für Ordnungsliebende, hat aber praktische Folgen.

7:52 Sie können den Datenstand nachvollziehen, das Deck versionieren und beim nächsten Quartal denselben Weg gehen. Und der vierte Punkt zieht die Bilanz dieses Kapitels: ein durchgängiger Weg von den Rohdaten bis zum Pitch, ohne Bruch dazwischen. Vier Schritte, und der zweite ist der, der über die Qualität entscheidet: aus den Daten die Kernaussagen ableiten.

8:12 Das ist Denkarbeit, keine Technik — welche drei Dinge soll das Publikum mitnehmen? Wer diesen Schritt überspringt, bekommt ein Deck voller korrekter Diagramme ohne Botschaft. Schritt drei ist dann die Generierung im Code, und Schritt vier ist der, den man gern vergisst: das Ergebnis prüfen, visuell und auf Überläufe. Auch ein generiertes Deck kann hässlich sein. Die Fußzeile schließt den Kreis zu diesem Kurs — genau dieser Workflow steckt hinter den Folien, die Sie gerade sehen.

8:41 Zum Abschluss bauen Sie den ganzen Weg einmal zu Ende. Der Hinweis ist die wichtigste Anweisung dieser Übung: Legen Sie erst die drei wichtigsten Aussagen fest, dann lassen Sie die Folien bauen. Nicht umgekehrt. Wer den Agenten bittet, „ein Deck aus diesen Daten" zu machen, bekommt eine Sammlung von Diagrammen; wer drei Aussagen vorgibt, bekommt eine Präsentation.

9:02 Das ist derselbe Gedanke, der sich durch den ganzen Kurs zieht — die Qualität des Ergebnisses hängt an der Klarheit der Vorgabe. Halten Sie das Deck bewusst kurz, wenige Folien reichen. Damit schließt sich der Bogen dieses Kapitels — und des ganzen Kurses. Sie haben gesehen, wie unbekannte Daten über einen Daten-MCP zugänglich werden und wie ein erster Blick auf Schema und Verteilung schnell Orientierung schafft.

9:26 Sie können Erkenntnisse in Notebooks oder Excel gießen, je nachdem, wer sie öffnen soll — das eine reproduzierbar, das andere überall lesbar. Und Sie wissen, dass auch der letzte Schritt, die Präsentation, aus Code entstehen kann. Aus einer Datenbank, die niemand erklären konnte, wird so innerhalb eines Vormittags ein Ergebnis, das man zeigen kann.

Von Rohdaten zum Pitch

9:47 Explorieren, auswerten, präsentieren — aus einem Werkzeug heraus. Das ist der Schlusspunkt dieses Kapitels und ein passender für den gesamten Kurs, denn er zeigt, worum es die ganze Zeit ging: nicht darum, schneller zu tippen, sondern darum, die Brüche zwischen den Arbeitsschritten zu schließen. Ein Gedanke zum Mitnehmen: Der Agent nimmt Ihnen die Wege ab, nicht die Fragen.

10:09 Welche Frage die Daten beantworten sollen und welche drei Aussagen zählen — das bleibt Ihre Arbeit, und sie ist die wertvollere geworden. Fragen und das Material zum Nachlesen finden Sie unter www.HCO.de.