KPI-Switch oder flaches Aggregat? Wann der SWITCH-Baum überflüssig wird

In vielen Reporting-Modellen wählt man die Kennzahl über einen Slicer, und ein großes SWITCH-Measure routet auf das passende Detail-Measure. Das Muster ist solide. Aber es wächst, und irgendwann fragt man sich, ob es das überhaupt noch braucht. Die Antwort hängt an der Form der Datenquelle.

Die Ausgangslage

Ein Controlling-Bericht ließ den Nutzer aus mehreren Dutzend Kennzahlen wählen. Umgesetzt war das klassisch: ein zentrales KPI-Measure mit einem großen SWITCH, das je nach Slicer-Auswahl auf ein eigenes Calc-Measure verzweigte. Mit jeder neuen Kennzahl wuchs der Baum. Und mit ihm die Wartung.

Das Problem: Logik im Switch

Sauber bleibt der KPI-Switch nur unter klaren Regeln:

• Der Switch referenziert ausschließlich Base- oder Calc-Measures. keine Logik im Switch selbst.
• Eine neue Kennzahl heißt: Calc-Measure hinzufügen, Switch erweitern, Kennzahlen-Dimension pflegen, Definition dokumentieren.
• Keine „versteckten" KPI-Varianten außerhalb dieses Musters.

Selbst sauber gepflegt bleibt die Frage: Muss jede Kennzahl ein eigenes Measure sein?

Die Lösung: flaches Aggregat statt Verzweigung

Liegt eine flache Aggregat-Tabelle vor, mit dem Korn Kennzahl × Version × Szenario × Jahr × Periode × Wert, dann steckt die ganze Bucket-, Versions- und Szenario-Logik bereits in der Daten-Pipeline. Die Measures rechnen dann thin:

KPI FC = CALCULATE( SUM( Aggregat[Wert] ), Aggregat[Szenario] = "FC" )

Die Kennzahl-Auswahl läuft über einen Slicer auf der Kennzahlen-Spalte. Der große SWITCH-Baum mit seinen Bucket-Measures entfällt. Übrig bleibt der Switch nur noch für nicht-additive Verhältniskennzahlen wie ROCE, Kosten pro FTE oder Vermietungsquote: Die lassen sich nicht aus SUM(Wert) ableiten und brauchen ein eigenes Calc-Measure pro Zweig.

Der Gewinn: weniger DAX-Oberfläche, Logik an einer Stelle (der Pipeline), und neue additive Kennzahlen erscheinen automatisch, sobald sie in der Aggregat-Tabelle liegen. Ganz ohne Modelländerung.

Die Stolperfallen

1. Passthrough-Measures. Ein Calc-Measure, das nur = [Base X] ist, gehört gelöscht. Der Switch kann direkt auf das Base-Measure zeigen. Jedes Measure soll eigenständige Logik tragen.
2. Das Measure ohne Body. Beim Umbau bleibt leicht ein Measure-Kopf ohne Ausdruck stehen. Das liefert still BLANK und bricht abhängige Divisionen. Ohne Fehlermeldung. Nach dem Aufräumen die Kette gegenprüfen.
3. Verhältniskennzahlen ins Aggregat zwingen. Eine Quote aus eigenem Zähler und Nenner im Aggregat zu rekonstruieren weicht numerisch oft vom korrekt gewichteten Quellwert ab. Im Zweifel die fertige Verhältniskennzahl laden, statt sie nachzurechnen.

Das Takeaway

Der KPI-Switch ist kein Selbstzweck. Liegt die Logik schon in einem flachen Aggregat, gehört sie dort hin. Die Measures bleiben dünn, und der Switch schrumpft auf die wenigen Verhältniskennzahlen, die ihn wirklich brauchen. Die Faustregel: Bucket-, Versions- und Szenario-Logik in die Pipeline, nicht ins DAX. Das Modell wird kleiner, schneller verständlich und wächst von selbst mit.