zum Blättern · Enter öffnet · Esc schließt

Kontakt aufnehmen.

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

Übersichtsseite des Olist-Dashboards mit fünf Kennzahlen, Umsatzverlauf, Kategorien und Bundesstaaten
Eine Seite, neun Visuals: Kennzahlen oben, Verlauf, Kategorien und Bundesstaaten darunter.

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:

Dashboard gefiltert auf den Bundesstaat São Paulo: 5,20 Mio. Umsatz, 42.000 Bestellungen
São Paulo allein trägt 5,20 Mio. von 13,59 Mio. — 41.746 Bestellungen. Die Kennzahlen oben folgen dem Klick.

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:

Dashboard nach Klick auf die Kategorie bed_bath_table: Umsatz 1,04 Mio., neu skalierter Verlauf
Ein Klick auf eine Kategorie — alle Kennzahlen und der Verlauf rechnen sich neu.

Und wer einen einzelnen Monat genau wissen will, bekommt ihn auf Zuruf:

Tooltip im Umsatzverlauf zeigt den Monatswert Juli 2017, die übrigen Visuals sind abgeblendet
Juli 2017: 498.031,48. Die übrigen Visuals blenden ab und zeigen den Anteil dieses Monats daran.

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:

Von neun CSV-Dateien zum fertigen Bericht — jeder Schritt wiederholbar 1 Rohdaten 9 CSV-Dateien, 42,6 MB ~100.000 Bestellungen 04.09.2016 – 17.10.2018 Skript lädt sie bei Bedarf 2 Aufbereitung Python + pandas Typen, Dubletten, Schlüssel 9 Dateien → 8 Tabellen Sternschema statt Rohform 3 Prüfung Primärschlüssel eindeutig 0 verwaiste Fremdschlüssel Kalender lückenlos Bricht ab statt still zu laden 4 Modell & Bericht TMDL: 8 Tabellen, 10 Bez. 14 Kennzahlen in DAX PBIR: eine Seite, 9 Visuals Power BI öffnet den Ordner Alles davon liegt im Git — außer den Rohdaten Skripte · Modelldefinition · Berichtsdefinition · Dokumentation · Entscheidungsjournal Die Rohdaten bleiben draußen: die Lizenz des Datensatzes erlaubt keine Weiterveröffentlichung. Wer das Repository klont und ein Skript startet, bekommt dasselbe Modell — nicht ein ähnliches.
Der Ablauf. Schritt 3 ist der unbequeme: Er lässt den Lauf scheitern, wenn die Daten nicht zusammenpassen — statt einen Bericht zu bauen, der plausibel aussieht und falsch ist.

Heraus kommt ein Sternschema aus acht Tabellen — vier Dimensionen, vier Faktentabellen, zehn Beziehungen:

Acht Tabellen, zehn Beziehungen — so filtert das Modell fact_order_items 112.650 Zeilen · Umsatz je Position fact_orders 99.441 Zeilen · Lieferung, Pünktlichkeit fact_payments 103.886 Zeilen · Zahlungen, Raten fact_reviews 99.224 Zeilen · Bewertungen 1–5 dim_products 32.951 Zeilen · Kategorie, Maße dim_sellers 3.095 Zeilen · Ort, Bundesstaat 1 : n 1 : n Gemeinsame Dimensionen dim_customers 99.441 Zeilen · Bundesstaat, Stadt dim_date 774 Tage · Monat, Quartal, Jahr Kunde und Kalender filtern jede der vier Faktentabellen — Produkt und Verkäufer nur die Bestellpositionen. Alle zehn Beziehungen laufen 1 : n und in eine Richtung. Keine beidseitigen Filter, keine Mehrdeutigkeit.
Das Modell in lesbarer Form. Die Entscheidung, den Kalender als eigene Tabelle zu führen statt Datumsspalten in den Fakten zu benutzen, ist der Grund, warum «Umsatz im Juli 2017» und «Bewertungen im Juli 2017» überhaupt nebeneinander stehen können.

So sieht dieselbe Struktur in Power BI selbst aus — erzeugt aus Textdateien, nicht im Editor gezogen:

Modellansicht in Power BI: vier Dimensions- und vier Faktentabellen, mit Beziehungen verbunden
Die Modellansicht in Power BI Desktop. Was hier als Diagramm erscheint, steht im Repository als Textdatei.

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.

DAX-Abfrageansicht mit Modellübersicht: acht Tabellen, 14 Kennzahlen, zehn Beziehungen
Acht Tabellen, 14 Kennzahlen, zehn Beziehungen — alles aus versionierten Textdateien erzeugt.

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.

Zwei Wege zum selben Bericht Der übliche Weg: eine .pbix-Datei Binärformat — im Kern ein gepacktes Archiv Änderungen entstehen durch Klicken im Editor Git meldet nur: «Datei hat sich geändert» Zwei Stände vergleichen: nicht möglich Wer was warum gebaut hat, steht nirgends Erzeugen lässt sich das nur von Hand. Dieser Weg: ein .pbip-Ordner Ordner aus lesbaren Textdateien TMDL: Tabellen, Beziehungen, DAX-Kennzahlen PBIR: Seiten, Visuals, Filter des Berichts Jede Änderung steht Zeile für Zeile im Diff Beschreibungen dokumentieren das Modell mit Erzeugen lässt sich das von einem Skript — oder einem Sprachmodell. Beide Wege führen zum selben Bericht. Nur einer davon lässt sich vergleichen, wiederholen und zu zweit bearbeiten.
Der Unterschied ist nicht das Dateiformat, sondern was danach möglich wird: Review, Diff, Generierung.

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.

Datenansicht der Kalendertabelle mit Beschreibungstext, der aus der TMDL-Definition stammt
Die Beschreibung rechts steht so in der Textdatei — sie wandert automatisch ins Modell.
Datenansicht der Bestellpositionen mit 112.650 Zeilen und der Beschreibung aus der TMDL-Datei
112.650 Bestellpositionen. Der Beschreibungstext hält die Granularität direkt im Modell fest — dort, wo sie jemand liest.

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.

Warum ein Dashboard in Stunden entsteht und nicht in Wochen 1 Beschreiben Welche Tabellen, welche Kennzahlen, welche Seite — in Worten, nicht in Klicks 2 Erzeugen (KI-gestützt) TMDL, PBIR und DAX als Text Die Definition ist Sprache — also schreibbar wie Code 3 Maschinell prüfen Integritätstests der Daten TMDL-Parser, Bericht öffnet Kein «sieht gut aus» 4 Ansehen, korrigieren Power BI Desktop öffnen Zahlen gegen die Rohdaten Abweichung → Schritt 2 Ein Durchlauf dauert Minuten — nicht einen Nachmittag Nacharbeit im Editor. Der Klickweg kennt diese Schleife nicht: dort ist jede Korrektur wieder Handarbeit, und niemand sieht, was sich geändert hat. Entscheidend ist Schritt 3. Nicht das Vertrauen in den Generator trägt das Ergebnis, sondern die Prüfung dahinter. Modell und Bericht dieses Falls entstanden an einem Arbeitstag. Was danach kam, war Feinschliff — nicht der Aufbau.
Die Schleife. Sie funktioniert nur, weil jeder Schritt ein maschinell prüfbares Ergebnis hat: ein Test schlägt fehl, ein Parser meckert, oder der Bericht öffnet sich nicht.

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.

← Alle Projekte