Projekte
Power BI: Dashboard in Stunden per KI und Code, nicht per Klickerei.
Demo30. Juli 2026
- Bereich
- E-Commerce
- Umsetzung
- 2 Tage
- Kompetenz
- Business Intelligence
- Stack
- Power BI · Python · pandas · Git
Ergebnis
- Modell und Bericht liegen als lesbare Textdateien im Git — jede Änderung ist im Diff sichtbar
- Sternschema aus acht Tabellen, maschinell geprüft: keine verwaisten Schlüssel, kein Loch im Kalender
- Fünf Kennzahlen auf einen Blick statt neun CSV-Dateien: 13,59 Mio. Umsatz, 4,09 Bewertung, 93,2 % pünktlich
- Aufbau an einem Arbeitstag — KI-gestützt erzeugt, maschinell geprüft, nicht zusammengeklickt
Dieser Fall ist bewusst kein Kundenprojekt, sondern eine Demonstration: ein öffentlicher Datensatz, ein Dashboard, ein offenes Repository, in das jeder hineinschauen kann. Interessant daran ist weniger das Ergebnis als der Weg dorthin — denn Modell und Bericht wurden nicht im Editor zusammengeklickt, sondern als Textdateien erzeugt und maschinell geprüft.
Genau das ist der Punkt, auf den es mir ankommt: Weil ein Power-BI-Modell inzwischen als Text beschrieben werden kann, lässt es sich auch von einem Sprachmodell schreiben — und, was wichtiger ist, anschließend von einer Maschine gegenprüfen. Aufbau von Modell und Bericht: ein Arbeitstag. Nicht, weil irgendwo geschludert wurde, sondern weil die Arbeit an dieser Stelle aus Beschreiben, Erzeugen und Prüfen besteht statt aus Klickwegen.
Datengrundlage: «Brazilian E-Commerce Public Dataset by Olist» (Kaggle), lizenziert unter CC BY-NC-SA 4.0 — Nutzung ausschließlich nicht-kommerziell. Die Rohdaten liegen nicht im Repository; ein Skript lädt sie bei Bedarf. Alle Beträge sind brasilianische Real (R$).
Die Ausgangslage
Der Datensatz besteht aus neun CSV-Dateien, zusammen 42,6 MB: Bestellungen, Positionen, Zahlungen, Bewertungen, Kunden, Verkäufer, Produkte, Geodaten und eine Übersetzungstabelle für Kategorienamen. Knapp 100.000 Bestellungen zwischen dem 4. September 2016 und dem 17. Oktober 2018.
Die Daten sind vollständig. Antworten enthalten sie trotzdem nicht. Wer wissen will, wie sich der Umsatz entwickelt hat, muss Positionen und Bestellungen verbinden, Zeiträume gruppieren und Preise mit Frachtkosten sauber trennen. Wer dieselbe Frage nach Bundesstaat gestellt bekommt, fängt von vorn an. Nach der dritten Pivot-Tabelle weiß niemand mehr, welche Zahl aus welchem Stand kam.
Das ist der Normalfall in Betrieben, nur mit anderen Dateinamen: Die Zahlen liegen vor, aber jede Frage kostet einen halben Tag Handarbeit — und das Ergebnis ist am nächsten Monat wieder von Hand zu wiederholen.
Was daraus wurde
Oben fünf Kennzahlen: 13.591.643,70 R$ Umsatz, 98.666 Bestellungen mit Positionen, 96.096 eindeutige Kunden, eine Durchschnittsbewertung von 4,09 von 5 und 93,2 % pünktliche Lieferungen (96.478 von 99.441 Bestellungen wurden zugestellt). Darunter der Monatsverlauf, die Kategorien nach Umsatz und die Bundesstaaten.
Der Unterschied zum Bericht in Tabellenform ist nicht die Optik, sondern dass man Rückfragen stellen kann, ohne jemanden zu fragen. Ein Klick auf einen Bundesstaat rechnet die gesamte Seite neu:
Dasselbe gilt für Kategorien. bed_bath_table ist die stärkste Warengruppe und
kommt auf 1,04 Mio. — der Verlauf darunter skaliert sich neu, sodass man die
Saisonalität dieser einen Gruppe sieht statt der des Gesamtgeschäfts:
Und wer einen einzelnen Monat genau wissen will, bekommt ihn auf Zuruf:
Eine Einschränkung gehört dazu: Es gibt keinen Live-Link zum Anklicken. Dafür bräuchte es eine Power-BI-Pro-Lizenz — und ein eingebetteter Power-BI-Bericht setzt Cookies, was dem Versprechen dieser Website widerspricht. Was Sie hier sehen, sind deshalb Bildschirmfotos aus Power BI Desktop; die Dateien dahinter liegen offen im Repository.
Das Modell darunter
Zwischen den neun CSV-Dateien und dem Bericht liegt eine Aufbereitung, die wiederholbar ist — kein einmaliges Aufräumen von Hand:
Heraus kommt ein Sternschema aus acht Tabellen — vier Dimensionen, vier Faktentabellen, zehn Beziehungen:
So sieht dieselbe Struktur in Power BI selbst aus — erzeugt aus Textdateien, nicht im Editor gezogen:
Zur Aufbereitung gehören Prüfungen, die vor dem Bericht laufen: Sind alle Primärschlüssel der Dimensionen eindeutig? Zeigt jeder Fremdschlüssel aus den Faktentabellen auf eine Zeile, die es gibt? Deckt der Kalender jeden Tag im Zeitraum ab? Das Ergebnis für diesen Datensatz: keine verwaisten Schlüssel, keine Lücke im Kalender. Das klingt nach Formalität, ist aber die Grenze zwischen «die Zahl ist richtig» und «die Zahl sieht richtig aus» — verwaiste Schlüssel verschwinden in Power BI stillschweigend in einer Sammelzeile.
Warum Textdateien statt Klickarbeit
Power BI speichert normalerweise alles in einer .pbix-Datei: Modell, Bericht
und oft auch die Daten in einem Binärformat. Seit dem Projektformat PBIP
geht es anders — dann liegt dasselbe als Ordner mit Textdateien vor:
TMDL beschreibt das Modell, PBIR den Bericht.
Ein Nebeneffekt, der mir wichtiger geworden ist als erwartet: Die Beschreibungstexte zu Tabellen und Spalten stehen in derselben Datei wie die Definition. Dokumentation und Modell sind damit eine Quelle, nicht zwei, die auseinanderlaufen.
In Stunden statt in Wochen — und warum das prüfbar bleibt
Der eigentliche Grund für diesen Demo-Fall steht in der Überschrift. Ein Dashboard dieser Art galt lange als Wochenarbeit. Es ist keine mehr — vorausgesetzt, man arbeitet in einem Format, das eine Maschine schreiben und eine andere prüfen kann.
Dieses Projekt ist KI-gestützt entstanden, und ich halte das für einen Vorteil, nicht für einen Vorbehalt. Der Grund ist der Aufbau selbst: Ein Sprachmodell schreibt hier keine Zahlen, sondern Definitionen — Tabellen, Beziehungen, Kennzahlen, Berichtsseiten. Ob diese Definitionen stimmen, entscheidet danach keine Meinung, sondern die Prüfkette: die Integritätstests der Pipeline, der TMDL-Parser von Power BI und die Frage, ob sich der Bericht überhaupt öffnet. Was da nicht durchkommt, kommt nicht ins Repository.
Genau umgekehrt ist es beim Klickweg: Dort erzeugt jede Änderung ein Binärartefakt, das niemand vergleichen kann — und je schneller man arbeitet, desto weniger ist nachvollziehbar. Die Verbindung aus Modell als Code und KI-gestützter Erzeugung dreht dieses Verhältnis um: Tempo und Nachvollziehbarkeit steigen gemeinsam.
Für einen Betrieb heißt das schlicht: Eine Auswertung, für die früher ein Projekt mit Wochenplanung nötig war, ist heute eine Sache von Tagen — und man kann hinterher zeigen, woher jede Zahl kommt.
Was dabei schiefging
Zwei Fehler haben mich mehr Zeit gekostet als der gesamte Modellaufbau. Beide sind lehrreich, weil sie zeigen, wo maschinelle Prüfung greift und wo nicht.
Der TMDL-Parser verweigert //-Kommentare. In den Modelldateien hatte ich
Kommentare im üblichen Stil hinterlassen. Power BI öffnete das Projekt daraufhin
nicht mehr, mit der Meldung InvalidLineType / Unexpected line type: Other.
Erlaubt sind ausschließlich Beschreibungen mit ///, die zu einem Objekt
gehören. Unangenehm daran: Ein externer Linter, der die Struktur prüfte, ließ
die //-Zeilen durchgehen — er gab also falsche Sicherheit. Ein Prüfschritt,
der nicht dasselbe prüft wie die Zielanwendung, ist keiner.
Das Berichtsschema PBIR verlangt themeCollection. Ohne dieses Feld
öffnet sich das Modell einwandfrei, der Bericht aber scheitert mit «Failed to
load the report» — ohne brauchbare Angabe in den Logs. Die Lösung bestand aus
drei Teilen: ein Basis-Theme benennen, es in den resourcePackages eintragen und
die Theme-Datei tatsächlich ablegen. Beides steht samt Fundstelle im
Entscheidungsjournal des Repositories, und die Commit-Historie zeigt den Weg
dorthin — was wiederum nur geht, weil alles Text ist.
Was das mit Ihrem Betrieb zu tun hat
Der Datensatz hier ist brasilianischer E-Commerce, weil er öffentlich ist. Das Muster darunter ist branchenunabhängig: Zahlen liegen in mehreren Dateien oder Systemen, jede Frage kostet Handarbeit, und niemand kann später sagen, wie eine Zahl zustande kam.
Die Antwort ist dieselbe wie in diesem Fall: ein wiederholbarer Weg von den Rohdaten zur Ansicht, mit Prüfungen dazwischen — und in einem Format, das man vergleichen und weitergeben kann. Ob dahinter Power BI steht oder eine selbst gebaute Seite, ist zweitrangig; wie ein solches Cockpit ohne Power BI aussieht, zeigt der Fall SEO-Dashboard: fünf Datenquellen, eine Ansicht. Der Gedanke dahinter steckt im Paket Owner’s Cockpit; warum das mehr bringt als der Monatsbericht vom Steuerberater, steht in Liquidität im Blick statt Monatsende-Überraschung.
Der Code dieses Falls liegt offen: das Repository auf GitHub (MIT-Lizenz) und die daraus gebaute Dokumentation — inklusive Entscheidungsjournal.
Wenn Sie so eine Ansicht für Ihre eigenen Zahlen brauchen: Offen für eine Festanstellung in Data Analytics und Automatisierung? Kontakt aufnehmen.