Die Zeit kann man ja bekanntlich nicht zurückdrehen und somit die Vergangenheit auch nicht verändern. Dies erscheint jedem Erdenbürger einigermaßen logisch – zumindest wenn er nicht Dr. Emmett Brown heißt. Leider gilt das nicht für OLAP-Server. Diese engstirnigen Lebensformen lassen Änderungen in jedem zeitlichen Kontext zu, zumindest sofern wir sie nicht vom Gegenteil überzeugen. In einer monatsbasierten Planung ist das noch relativ einfach. Die zukünftigen Monate dürfen verändert werden, die vergangenen nicht. Selbst im aktuellen Jahr ist die Abgrenzung noch relativ einfach. Meist werden alle noch nicht vollständig abgeschlossenen Monate geplant, sprich der aktuelle Monat bleibt außen vor. Soweit so gut, wäre da nicht das schon oft erwähnte, unberechenbare Moment der Anwender. Diese wollen auch gern mal den Jahresendwert in Summe eingeben. Liegen im aktuellen Jahr dann schon Ist-Monate hinter uns, dürfen diese natürlich nicht verändert werden. Ein Splashing-Problem der besonderen Art. Ob und wie man diese Herausforderung löst, ganz ohne Flux-Kompensator, wird Thema des nachfolgenden Blogbeitrags sein.
Die unspektakuläre Gegenwart
Schauen wir uns zunächst die Ausgangssituation und Datenlage an, die wir üblicherweise in einem solchen Planungsmodell vorfinden. Es gibt historische Ist-Werte und zukünftige Plan- oder Forecast-Werte:
Abb. 1: Ausgangssituation
Die Unterscheidung in „Plan“ oder „Forecast“ wird dabei häufig nur anhand der Zeitachse vorgenommen, nicht jedoch über eine gesonderte Wertart. Das bedeutet, dass unsere Kunden häufig Plandaten in den Monaten des aktuellen Jahres als „Forecast“ und die Plandaten in den Folgejahren als „Plan“ oder „Budget“ bezeichnen. Technisch liegen alle Plandaten meist auf derselben Wertart „Plan“.
Genau genommen ist der eigentliche „Forecast“ eine Mischung aus Wertarten, nämlich „Ist“ in der Vergangenheit und „Plan“ in der Zukunft. Die Jahressumme aus den beiden Wertarten bildet den Jahresend-Forecast. Damit wir im OLAP-Modell mit diesem Forecast bzw. der Jahressumme auch arbeiten können, legen wir eine neue (leere) Wertart im Modell an und befüllen diese mit folgendem Cube-Skript:
------------------------------------ --CALCULATE VALUETYPE FORECAST ------------------------------------ SCOPE( [Wertart].[Wertart].[Wertart].&[3] ,[Periode].[Periode].[Monat].Members ); this = iif( [Wertart].[Wertart].[Wertart].&[1] <> 0 ,[Wertart].[Wertart].[Wertart].&[1] ,[Wertart].[Wertart].[Wertart].&[2] ); END SCOPE;
Wichtig ist, dass der oben gezeigte Scope immer auf der Monatsebene rechnet. Andernfalls würde auf der Jahressumme ebenfalls schlicht der Jahreswert der Datenart Ist (ohne Plan) gezeigt werden. Uns interessiert aber die Summe aus Ist und Plan. Daher übertragen wir die Daten auf Monatsebene und lassen später die normale OLAP-Aggregation den Jahreswert ausrechnen.
Weiterhin sei noch erwähnt, dass die oben verwendete iif-Prüfung für diesen Blogbeitrag stark vereinfacht wurde. In der Praxis würden im laufenden Monat in der Regel schon Ist-Daten auflaufen, wodurch der aktuelle, aber noch nicht abgeschlossene Monat fälschlicherweise in den Forecast übernommen würde. In der Praxis empfiehlt es sich, ein Flag in einer Hilfs-MeasureGroup zu erstellen, über welches das Umschalten von Ist auf Plan gesteuert werden kann.
Im Ergebnis zeigt sich damit folgende Datenlage (der Übergang von Ist zu Plan ist rot markiert):
Abb. 2: Sicht auf das Ergebnis
Alternativ könnten wir die Datenlage auch durch eine Befüllung mit entsprechenden Vorschlagswerten herbeiführen. Warum dies allerdings eher hinderlich bis unhandlich ist, werden wir im Folgenden beleuchten.
Die fabulöse Zukunft
Umreißen wir die Zielsetzung nochmal kurz. Wir wollen die blau markierte Zelle „beplanen“ können, ohne jedoch die rot markierten Zellen zu verändern:
Abb. 3: Eingabeoption
Gehen wir für den Moment einmal naiv vor und geben einfach auf die berechnete Wertart Forecast ein. Was wird passieren?
Das Gute ist: Die roten Zellen werden nicht verändert. Das Schlechte: Die blaue Zelle auch nicht…
Der Grund dafür ist ganz banal, wir überschreiben ja die Werte per Cube-Skript. Sprich, die Eingaben landen tatsächlich in der relationalen Rückschreibtabelle, wir sehen sie aber nicht. Hier der Beweis (Wertart 3 entspricht Forecast):
Abb. 4: Rückschreibetabelle
Schreiben auf die berechnete Größe geht also schon mal nicht. Was wäre also, wenn wir die Werte physisch in die Wertart schreiben und dann verändern? Sobald wir den Jahreswert eingeben, würde ein Splashing auf Serverseite ausgelöst werden. Dieses Splashing würde im oben gezeigten Fall eine proportionale Verteilung auf alle gefüllten Monate auslösen. Das Vertrackte daran ist das Wörtchen „alle“. Es würden also auch die Ist-Monate mit verändert werden. Dem könnte man in DeltaMaster zwar mit einer Fixierung der Ist-Monate entgegenwirken, da diese Fixierungen aber durch den Anwender manuell gesetzt werden müssten, wäre das eine ziemliche Zumutung.
Würden wir jetzt noch in der Vergangenheit leben, könnten wir natürlich auch einen Flexreport verwenden, da hier eine bedingte Fixierung von Zellen möglich ist. Aufgrund der rasanten Rückreise in die Zukunft ist aber unser Fusionsgenerator noch überhitzt, daher werden wir diesen Schritt definitiv nicht in Betracht ziehen.
Damit fällt ein direktes Schreiben auf die Wertart Forecast definitiv aus. Mit unserem Hightech-Werkzeug, dem DM(C-12) finden wir aber dennoch eine probate Lösung für die Herausforderungen des einundzwanzigsten Jahrhunderts. Neben vielen anderen hilfreichen Planungsfunktionen bietet der DeltaMaster für solch einen Fall die sogenannte Wertweitergabe an. Mit dieser Technik können abhängige Kennzahlen verändert werden (z.B. Rabatt bei Umsatzänderung) oder eine Eingabe auf berechnete Kennzahlen kann umgeleitet werden. Diese zweite Option machen wir uns hier zunutze und beschleunigen auf die notwendige 140-km/h-Geschwindigkeitsbarriere.
Der Zeitsprung
Der Trick an der Wertweitergabe besteht in der Verteilung der Daten über die Wertarten. Wenn auf Forecast eingegeben wird, geben wir im Hintergrund die Daten auf die Wertart Plan weiter. Da dort nur die Monate gefüllt sind, die auch tatsächlich geplant werden sollen, funktioniert hier ein Splashing auf Jahresebene wunderbar. Bei Änderung des Jahreswertes werden nur die Forecast-Monate proportional verändert. Wichtig ist, dass hier mit Filter-Measures gearbeitet wird. Nur wenn im Ziel der Wertweitergabe auch eine Filter-Measure mit Wertart-Filter auf Plan verwendet wird, landen die Daten auch tatsächlich auf dem Plan. Andernfalls würde in der Interpretation der Wertweitergabe immer das Wertart-Element der aktuellen Sicht verwendet werden.
Diese Technik funktioniert natürlich nur bei existierenden Werten in dem Jahr und wenn die Datenlage genau so sauber abgegrenzt ist wie in dem Beispiel gezeigt. Eine Überlappung von Ist- und Plandaten darf es nicht geben. Soll ein neues Produkt (ohne Vorschlagswerte) geplant werden, sind zwangsläufig erstmal die Monate zu füllen oder per Kopierprozess die Daten eines Referenzprodukts zu kopieren.
Jetzt gilt es nur noch ein kleines Detail zu berücksichtigen. In dem gezeigten Beispiel wird der Jahresgesamtwert von 33.400 verändert, beispielsweise auf 35.000. Würden wir jetzt einfach diesen Wert an den Plan weitergeben, käme ein vollkommen falsches Ergebnis, nämlich 35.000 + 15.100 = 50.100 heraus. Wir dürfen lediglich das Delta zu dem vorherigen Wert (35.000 – 33.400 = 1.600) an den Planwert weitergeben und diesen um das Delta erhöhen. Die Wertweitergabeformel dafür sieht folgendermaßen aus:
Abb. 5: Wertweitergabe
Wenn wir das Beispiel nachrechnen, kommen wir auf folgendes Ergebnis:
#new = 35.000 #old = 33.400 [Measures].[Menge, Plan] = 18.300 => Neuer Wert [Menge, Plan] = (35.000 – 33.400) + 18.300 = 19.900
Probieren wir es aus…
Abb. 6: Ergebnis
Damit sind wir im Jahre 2015 angelangt und haben die Zeit mal wieder erfolgreich besiegt – oder war es doch 1985 – egal, Hauptsache, wir sind da!
Wie gewohnt können die Beispieldatenbank und die DAS an dieser Stelle heruntergeladen werden.
Und wer mit meinen verbalen Ausflügen nichts anfangen konnte, kann sich hier fortbilden.
