Ein Wert, drei Wahrheiten: Vorjahr, Vormonat und Vorversion sauber trennen

„Zeig mir den Wert im Vergleich zum Vorher." Dieser harmlose Satz aus dem Controlling enthält eine Mehrdeutigkeit, die ganze Reportings durcheinanderbringt. Denn „vorher" kann dreierlei bedeuten. Und wer die drei Bedeutungen in einem einzigen Slicer-Wert „Vergleich" zusammenfasst, produziert Measures, die je nach Kontext etwas anderes rechnen.

Die Ausgangslage

In einem Monatsreporting sollten Ist-Werte „gegen vorher" verglichen werden. In der Anforderung stand schlicht „Vergleich zum Vorjahr". Beim Nachfragen kamen aber drei verschiedene Bedürfnisse zum Vorschein:

• der Vergleich zum gleichen Monat im Vorjahr,
• der Vergleich zum direkten Vormonat,
• und der Vergleich zu einer früheren Planungsversion desselben Zeitraums.

Alles drei wurde umgangssprachlich „Vorjahr" oder „Vergleich" genannt. Im Modell sind es drei grundverschiedene Operationen.

Das Problem: drei Konzepte, ein Wort

Sauberes Reporting trennt drei Achsen, die nichts miteinander zu tun haben:

Konzept	Rolle im Modell	Logik
Kalender	Periode, MoM, YoY, YTD	SAMEPERIODLASTYEAR, DATEADD, DATESYTD auf der Kalenderdimension
Szenario	Ist / Forecast / Budget	Spalte bzw. Dimension in den Fakten. nicht mit „Vorjahr" vermischen
Version	Planungs-/Forecast-Stand (z. B. Stand Januar)	eigene Versionsdimension; Vergleich Version A ↔ Version B

Daraus ergeben sich drei eindeutige Vergleichstypen:

• Vorjahr (PY): gleiche Kalenderperiode, ein Jahr zurück. SAMEPERIODLASTYEAR(DIM_Kalender[Datum]) auf einem Measure, das bereits das gewünschte Szenario abbildet (meist Ist).
• Vormonat (MoM): eine Periode zurück, gleiche Szenario- und Versionsebene. DATEADD(DIM_Kalender[Datum], -1, MONTH). Ein eigenständiger Vergleich. Nicht „Vorjahr".
• Vorversion: anderer Versions-Slice, gleiche Periode. Filter auf die Versionsdimension. nicht SAMEPERIODLASTYEAR.

Wer diese drei in einem Slicer-Wert „Vergleich" zusammenzieht, bekommt ein Measure, das im selben Bericht mal die Periode, mal den Plan-Stand verschiebt. Das Ergebnis ist nicht reproduzierbar. Und im Zweifel merkt es niemand, bis eine Zahl im Lenkungskreis nicht zur anderen passt.

Die Lösung: erst klären, dann modellieren

Bevor ein einziges Vergleichs-Measure entsteht, wird in der Modell-Dokumentation festgehalten, was „Vergleich" fachlich heißt. Konzept für Konzept:

Praktischer Nebeneffekt: Der Vorjahresvergleich lässt sich einmal generisch bauen. KPI PY = CALCULATE([KPI Ist], SAMEPERIODLASTYEAR(DIM_Kalender[Datum])). Und funktioniert auch für Bestandskennzahlen, weil der Stichtag die Filterverschiebung automatisch erbt. Es braucht keine separaten PY-Measures je Kennzahl.

Die Stolperfallen

1. „PY" als Sammelbegriff. Sobald ein Slicer-Wert „PY" auch Vormonat oder Vorversion mit abdeckt, sind die Measures mehrdeutig. Drei Konzepte = drei benannte Vergleiche.
2. Vorversion über die Kalenderlogik bauen. Eine frühere Planungsversion ist kein Kalender-Vergleich. SAMEPERIODLASTYEAR auf eine Version anzuwenden liefert Unsinn. Die Version gehört in eine eigene Dimension.
3. Die Vorversion nicht robust bestimmen. „Vorherige Version" ist die größte Version, die kleiner als die aktuelle ist. Aus der Versionsdimension ermittelt, nicht über das Refresh-Datum. Das bleibt korrekt auch bei Lücken und über den Jahreswechsel.

Das Takeaway

„Vergleich zum Vorher" ist keine Anforderung, sondern drei. Wer Kalender, Szenario und Version als getrennte Achsen modelliert und die drei Vergleichstypen ausbuchstabiert, bekommt eindeutige Measures und Visuals, die im Lenkungskreis standhalten. Die Klärung kostet ein Gespräch und zwei Sätze in der Doku. Die Vermischung kostet später eine Fehlersuche unter Zeitdruck.