DeltaMaster kann hervorragend zur Daten- und Abweichungsanalyse verwendet werden. Standard ist die herkömmliche Plan-Ist-Analyse. Jetzt soll es da draußen aber Planer geben, die nicht auf Anhieb wissen, was genau sie in 5 Jahren an Kunden XY verkaufen. Aus dem Grund wird im Planungssystem häufig mit Planversionen gearbeitet, um verschiedene Szenarien durchspielen zu können. Oft kommen dabei Best-Case- oder Worst-Case-Annahmen zum Einsatz. Ebenso denkbar ist eine Gegenstromplanung, in der die Geschäftsführung und die Unternehmensbasis parallel plant und die Planungen anschließend ver- und angeglichen werden. Auch hier kommen Planversionen zum Einsatz. Wie so oft sind aber selten die absoluten Zahlen das spannende, sondern der Vergleich zwischen einzelnen Versionen. Da es hier aber sehr viele geben kann, stellt sich die Frage, wie wir die Abweichungen möglichst elegant berechnen. Eine statische Berechnung ist zwar auch möglich, aber hierfür müsste man sehr viele Abweichungselemente anlegen, was sehr „uncool“ wäre. Wie man die Anforderung „cool“ löst, zeigt dieser Blogbeitrag.
Versionswahnsinn
Flexibilität, Dynamik und eine schier endlose Auswahl an Alternativen scheint eine Krankheit unserer heutigen Zeit zu sein. Dies wirkt sich leider auch auf Planungssysteme aus, was man gut an der teilweise endlosen Anzahl existierender Planungsvarianten ablesen kann. Da wird ein Plan initial mit großer Mühe erstellt, plötzlich ändert die Geschäftsführung die Ziele, dann ändern die Analysten die Marktprognosen und obendrein sehen die Währungskursprognosen plötzlich vollkommen anders aus. Ist man dann fast fertig, kommt die Produktentwicklung plötzlich mit DEM strategischen Produkt um die Ecke, was natürlich die prognostizierten Absatzzahlen wieder komplett über den Haufen wirft. Droht dann noch ein neuer Großkunde mit einem Auftrag ist das Chaos perfekt. In der Regel führt jedes Ereignis für sich bereits zu einer eigenen Planversion. Die alten werden lieber mal aufgehoben – wer weiß? Sollen dann noch Worst-Case, Best-Case und Real-Case nebeneinander gestellt werden, kommt man schnell auf zwanzig oder mehr Planversionen.
Möchte man den „uncoolen“ BI-Architekten richtig ärgern, fragt man diesen dann nach der Umsatzabweichung zwischen Version 21 und 17, um sich am nächsten Tag dann zu korrigieren – 18 war ja die gewünschte Version… Dieser wird in dem Fall jedes Mal ein neues Abweichungselement in der Dimension Planversion anlegen und die Versionen statisch verlinken. Das sieht dann ungefähr so aus:
Abb. 1: Einfache Abweichungsberechnung
Wie groß die Kombinatorik in solch einem Fall wird kann man sich leicht vorstellen. Zumal die Objekte auch gern in den Achsen eines Berichts verwendet werden. Wenn sich dann die Versionen noch regelmäßig ändern, kommt man in Teufels Küche.
Cool Analytics
Wie könnte jetzt eine möglichst coole Lösung für das Problem aussehen? Sonnenbrillen und lässige Anzüge helfen immerhin schonmal dem Berichtsredakteur selbst, aber die vielen Abweichungselemente wären wir damit noch nicht los. Wenn wir uns mal die bestmögliche Alternative überlegen, so wäre das doch die Möglichkeit die Parameter für unsere Abweichungslogik selbst wählen zu können. Also sowohl die Referenzversion gegen die verglichen werden soll als auch die Vergleichsversion. Die Auswahl sollte dabei dem Anwender überlassen werden. Und das bei nur einem absoluten und einem relativen Abweichungselement, welches bedenkenlos in allen Berichten verwendet werden kann. Wie kommen wir nun dahin?
Denken wir zunächst einmal über die Auswählbarkeit nach. Üblicherweise werden unsere Berichtsempfänger den Viewer-Modus in DeltaMaster bemühen. Sprich, sie sehen den Bericht und die Sicht ungefähr so:
Abb. 2: Einfache Planversion in der Sicht
Die verwendete Planversion ist in der Sicht zu sehen und wählbar. Und da beißt sich nun die Katze in den Schwanz. Unser berechnetes Abweichungselement haben wir natürlich auch in der Planversion angelegt, da wir ja aus dieser Dimension Elemente miteinander vergleichen wollen. Was ist also zu tun um beide Parameter wählen zu können?
Eigentlich total logisch – damit man die beiden Parameter wählen kann, müssen wir sie für den Anwender als Zeile, sprich als Dimension in der Sicht verfügbar machen. Da wir diese Dimensionen allerdings lediglich zum Umschalten von berechneten DeltaMaster-Elementen benötigen, müssen wir diese nicht in der MeasureGroup verknüpfen. Eine Erzeugung als schlichte CubeDimension reicht völlig aus. Dies beherrscht der „Master of Coolness“, das Programm DeltaMaster Modeler seit der Version 212 auch im Standard:
Abb. 3: Cube Dimension im Modeler einfügen
Nach einem erneuten Öffnen der Analysesitzung werden diese Dimensionen ganz normal in der Sicht angezeigt, so als hätte man diese der Faktentabelle angehängt:
Abb. 4: Sicht mit neuen Dimensionen
Wichtig bei den neuen Dimensionen ist, dass die Elemente in der Dimension exakt so heißen wie in der Original-Dimension „Planversion“. Am einfachsten verwendet man die selbe Quelltabelle zum Dimensionsaufbau.
Jetzt sind wir schon fast fertig. Lediglich der letzte Kniff fehlt noch, um eine richtig lässige Lösung vorweisen zu können. Wie verknüpfen wir die Dimensionsauswahl in der Vergleichs- oder Referenzversion nun mit der Berechnung in der Planversion. Dem anglophilen Leser wird beim Wort „verknüpfen“ vielleicht schon eine Idee gekommen sein – das MDX-Konstrukt LinkMember erledigt den notwendigen Brückenschlag für uns. Hiermit kann man von dem Element einer Dimension auf ein Element einer anderen Dimension zugreifen. Bedingung ist lediglich die Namensgleichheit. Wenn wir nun also in der Referenzversion ein Element auswählen, verweisen wir in der Berechnung auf das gleichnamige Element aus der Dimension „Planversion“. Die Berechnung definieren wir wie vorhin auch in der Dimension Planversion, allerdings diesmal als Userdefined MDX. Diese Berechnung sieht dann im Ergebnis ungefähr so aus:
Abb. 5: Die coole Abweichungsberechnung
Also zur Abwechslung mal ein wirklich kurzes und einfaches MDX-Statement was unser Problem löst. Wenn wir uns das Ergebnis in DeltaMaster anschauen, sehen wir das einfache wie beeindruckende Ergebnis:
Abb. 6: Die lässige Lösung
Es ist Ihnen überlassen, wie oft Sie nun Vergleichs- und Referenzversion hin und her verstellen, um die Funktionsweise zu testen.
Nun das i-Tüpfelchen der Lösung. Wer ein bisschen Wert auf die Ästhetik seiner Berichte legt (und bei Bissantz & Company ist uns gerade dieser Punkt besonders wichtig) wird gleich einwenden, dass die Überschrift des Delta-Elements nicht wirklich cool aussieht. Aber auch das ist kein Problem und durch einen kleinen Kniff zu lösen. Wir ändern den Namen des berechneten Elements einfach folgendermaßen ab:
Abb. 7: Dynamischer Elementname
Durch die geschweiften Klammern weisen wir DeltaMaster darauf hin, dass zwischen den Klammern ein MDX-Ausdruck zu finden ist. Durch die <viewX>-Ausdrücke verweisen wir auf das gerade selektierte Element der Dimension X. Was in Ihrem Modell „X“ ist, finden Sie am einfachsten über das Modellfenster links unten im Dialog heraus. Einfach mit gedrückter Alt-Taste über Ihren Dimensionsnamen fahren. Die Zahl hinter der „Dimension ID“ setzen Sie einfach für X ein – voilà. Beim nächsten Öffnen des Berichts wid DeltaMaster die Ausdrücke interpretieren und durch Klartext ersetzen. Mit der gleichen Technik können Sie natürlich auch relative oder gewichtete Abweichungen anlegen. Cool, oder?
Und jetzt Sonnenbrille auf die Nase und bei der nächsten Planversion einfach mit souveränem Lächeln die Sicht umschalten und den Bericht neu abspeichern. Viel Spaß dabei!
