Mein erstes Fallstudien-Dashboard: drei Dinge, die ich unterschätzt habe

Die erste Fallstudie steht: ein Executive Financial Dashboard für einen Zulieferer für Präzisionskomponenten. Vier Pflichtanforderungen, drei Kür, strikte Design-Vorgaben, und der Satz, der den Ton gesetzt hat: Der Verwaltungsrat schaut zehn Sekunden auf den Bildschirm und muss danach wissen, ob das Unternehmen auf Kurs ist.

Was in der Fallstudie steht, ist das Ergebnis. Hier steht, wie ich dorthin gekommen bin – und an welchen drei Stellen es nicht glattlief.

Wie ich gearbeitet habe

Ich habe den Bericht mit Gemini als Assistent erarbeitet. Der Ablauf war immer derselbe: Ich beschreibe, was die nächste Anforderung verlangt, bekomme einen Vorschlag mit konkreter DAX-Formel zurück, setze ihn im Modell um – und nehme ihn dann auseinander. Warum steht diese Funktion hier? Was passiert, wenn ich sie weglasse? Stimmt das Ergebnis auch dann noch, wenn ich einen Filter setze, an den der Vorschlag nicht gedacht hat?

Das ist eine bewusste Entscheidung. Ich lerne schneller, wenn ein funktionierendes Ergebnis vor mir liegt, das ich rückwärts durchdringen kann. Wer bei null anfängt, verbringt die erste Woche mit Syntaxfehlern statt mit dem Datenmodell – und Syntax ist nicht das, was ein Dashboard richtig oder falsch macht.

Interessant wird es an den Stellen, an denen der Vorschlag nicht trägt. Davon gab es drei, und sie haben mir mehr beigebracht als der Rest zusammen.

1. Das unvollständige Jahr

Der Datenstand endete Ende Juli. Mein erster Jahresvergleich stellte sieben Monate gegen zwölf und zeigte einen Umsatzeinbruch von über vierzig Prozent. Die Zahl war falsch, sah aber vollkommen plausibel aus – das ist das Gefährliche daran. Ein Bericht, der offensichtlich kaputt ist, wird korrigiert. Einer, der glaubhaft das Falsche behauptet, landet in einer Sitzung.

Die Lösung ist keine Formel, sondern eine Modellentscheidung: eine eigene Kalendertabelle, als Datumstabelle markiert, und Zeitintelligenz darauf statt Vergleiche über Jahreszahlen.

Umsatz VJ =
CALCULATE (
    [Umsatz],
    SAMEPERIODLASTYEAR ( Dim_Calendar[Datum] )
)

Damit vergleicht der Bericht Januar bis Juli gegen Januar bis Juli, ohne dass irgendwo eine Jahreszahl fest verdrahtet ist.

2. Prozentziele lassen sich nicht mitteln

Jedes Produkt hatte eine eigene Zielmarge, von 18 bis 40 Prozent. Ich habe zuerst den Durchschnitt dieser sechs Werte als Konzernziel genommen. Das ist bequem und es ist falsch: Ein Produkt mit CHF 0,6 Millionen Umsatz zählt dann genauso viel wie eines mit CHF 2,5 Millionen.

Die Folge ist keine kleine Ungenauigkeit, sondern eine Prioritätenliste, die in die falsche Richtung zeigt. Fünf Punkte Rückstand auf einem kleinen Produkt sehen dramatischer aus als zwei Punkte auf dem Umsatzträger – in Franken ist es umgekehrt. Richtig ist die zeilenweise Gewichtung nach effektivem Volumen:

Zielmarge gewichtet =
DIVIDE (
    SUMX (
        Fact_Financials,
        Fact_Financials[Revenue_CHF]
            * RELATED ( Dim_Products[Margin_Target_%] ) / 100
    ),
    [Umsatz]
)

Seitdem prüfe ich bei jeder Prozentkennzahl zuerst, ob sie über eine Ebene hinweg überhaupt aggregierbar ist. Marge, Quote, Anteil – bei allen dreien lautet die Antwort fast immer: nicht als Durchschnitt.

3. Die Margenbrücke und die Ringabhängigkeit

Ein Wasserfalldiagramm braucht Kategorien, die es in den Daten nicht gibt: Startwert, Umsatzeffekt, COGS-Effekt, OpEx-Effekt, Endwert. Die kommen aus einer Hilfstabelle ohne Beziehung zum Modell, die Werte über eine SWITCH-Logik.

Mein Fehler war die Sortierung. Ich wollte die Kategorien nach ihrem Wert ordnen – und der Wert stammt aus dem Measure, das seinerseits die Kategorie liest. Power BI meldete eine zirkuläre Abhängigkeit und baute das Modell nicht mehr. Die Lösung ist eine simple, konstante Sortierspalte in der Hilfstabelle. Zwei Minuten Arbeit, nachdem ich einen halben Tag in die falsche Richtung gesucht hatte.

Was mir das über die Zusammenarbeit gezeigt hat

Die drei Punkte oben haben eines gemeinsam: Kein Werkzeug hat sie gemeldet. Der falsche Jahresvergleich lief ohne Fehlermeldung durch – er fiel mir auf, weil die Zahl nicht zu dem passte, was im Briefing über das Unternehmen stand. Dass ein Prozentdurchschnitt als Konzernziel unbrauchbar ist, steht in keiner Dokumentation, das ergibt sich erst, wenn man fragt, wofür die Zahl gebraucht wird. Und die Ringabhängigkeit war ein Verständnisproblem des Datenmodells, keine Syntaxfrage.

Ein Assistent liefert eine Formel, die zu deiner Frage passt. Ob es die richtige Frage war, entscheidet niemand ausser dir. Genau da liegt die Arbeit – und genau deshalb funktioniert die Methode: Ich sehe schnell ein Ergebnis, und das Nachvollziehen zwingt mich, jeden Schritt gegen die Anforderung zu halten, statt ihn hinzunehmen.

Auch das Briefing selbst stammt von einer KI – ich habe es mit Claude erzeugt. Das war rückblickend der wertvollste Teil: Eine selbst geschriebene Aufgabenstellung enthält nur Anforderungen, die man ohnehin erfüllen kann. Eine fremd formulierte verlangt eine Margenbrücke, einen Szenario-Simulator und ein Rollenkonzept – und stellt damit Fragen, die man noch nicht beantworten kann.

Mein Massstab: Ich behaupte nicht, das freihändig gebaut zu haben. Aber ich kann jede Zeile DAX in diesem Projekt erklären – warum sie so aussieht, was passiert, wenn man sie ändert, und woran sie scheitert. Was ich nicht erklären kann, kommt nicht ins Portfolio. Wie ich mit KI arbeite, steht ausführlich auf der Seite Transparenz.

Was als Nächstes kommt

Die visuelle Ausarbeitung läuft noch, danach wird der Bericht in der Fallstudie interaktiv eingebettet. Drei weitere Projekte sind in Arbeit. Wenn du ein Modell hast, das sich merkwürdig verhält: Schreib mir, die besten Beiträge entstehen aus echten Fällen.