Planungsanwendungen entwickeln mitunter eine starke (Eigen-)Dynamik.
Die Planer wollen während der Dateneingabe schon auswerten können, wo sie stehen. Sie wollen Szenarien “durchspielen” können. Keine noch so krude Idee ist es nicht wert, einmal beleuchtet zu werden. Wir hatten hier schon einmal typische Planungsanforderungen beschrieben und Lösungsansätze geliefert.

Es besteht die Anforderung, dass gleichzeitig mehrere Werte in die Datenbank geschrieben werden sollen. Nichts ist in dieser Situation für den Planer schlimmer, als nach der Erfassung seines Planungsstandes auf die nächste Datenaufbereitung warten zu müssen, damit alle Kennzahlen auf Basis des neuen Planungsstandes durchgerechnet und zur Auswertung aufbereitet werden. Ein Kunde sagte einmal zu mir: “Das hat etwas von einem Autohausbesuch. Man darf sich in die schicken neuen Wagen hineinsetzen – man darf aber nicht losfahren.” Damit dies nicht passiert, haben wir in DeltaMaster die Wertweitergabe implementiert. Wie damit umzugehen ist, zeigt der heutige Blogbeitrag.

Wertweitergabe – Das Wo und das Wie

Bevor wir hier einsteigen, soll aber zuerst ein wenig Aufklärung erfolgen.
Werden Zahlen eingegeben, so besteht die Möglichkeit, gleichzeitig einen oder mehrere weitere Werte in die Datenbank zu schreiben. Der Anwender bekommt davon erst einmal nichts mit. Um dies zu tun, muss natürlich ein Regelwerk eingebaut werden, das die Abhängigkeiten aufzeigt und gleichzeitig festlegt, was im Eingabefall passieren soll.

Aber Achtung, die berüchtigte Erfassung “des einen Wertes” (auf zum Beispiel Alle Kunden, Alle Produkte und Alle Standorte), der mit einem Druck auf die Entertaste mehrere Millionen Planwerte erzeugt und damit die Eingabeanwendung für längere Zeit mit dem Aufteilen und Wegschreiben beschäftigt, würde diese Zeit mit einer Wertweitergabe natürlich vervielfachen.

Die Definition der Wertweitergabe verbirgt sich ganz unscheinbar im Reiter Dateneingabe der Analysewerteigenschaften der zu planenden Kennzahl.

Abb. 1: Dialog Wertweitergabe

Wir legen im oberen Fensterteil fest, welche Werte gleichzeitig geschrieben werden sollen.
Im mittleren Teil legen wir für jede dieser Kennzahlen separat fest, nach welchen Regeln der zu schreibende Wert gebildet werden soll.
Der untere Fensterteil enthält Angaben zur Fixierung, Gleichverteilung und ob die (eingegebene) Kennzahl selbst geschrieben werden soll oder nicht.

Im dargestellten Beispiel soll die Kennzahl selbst gar nicht in die Datenbank geschrieben werden, da es sich um eine berechnete Kennzahl handelt.

Abb. 2: Fehlermeldung berechnete Kennzahl

In DeltaMaster berechnete Kennzahlen können per se nicht in die Datenbank geschrieben werden, da ihnen das entsprechende Feld in der Rückschreibetabelle fehlt. Es erscheint auch ein entsprechender Hinweis, wie in Abb. 2 dargestellt.

Regeln, Regeln, Regeln

Bei der Wertbildung muss zwischen zwei Fällen unterschieden werden:

a) proportionale Änderung
Dies ist für das Regelwerk der einfachste Fall. Die Regel kann einfach frei bleiben.
Die Änderung der eingegebenen Zahl zur zuvor im System vorhandenen Zahl wird proportional an die zu ändernde Kennzahl weitergegeben.

b) Berechnung
Wird eine Berechnung hinterlegt, kann man den vollen MDX-Funktionsumfang verwenden, um zu seinem Ziel zu gelangen.
Zusätzlich stehen zwei Platzhalter zur Verfügung, die sehr gute Hilfestellung leisten können:

#new – neu eingegebener Wert
#old – gerade überschriebener Wert

Es muss hier weiterhin beachtet werden, dass die Ermittlung des zu schreibenden Wertes am besten nicht auf anderen berechneten Werten basieren sollte, da die Berechnung der Wertweitergabe erst nach dem Schreiben des ursprünglichen Wertes erfolgt und damit unter Umständen schon ein anderer Wert zugrunde liegt. Ich konnte gute Erfahrungen damit machen, immer die gesamte Kette neu zu berechnen – die berechnete Kennzahl Preis findet demnach keine Verwendung. So wird die Weitergabe etwa für den Umsatz wie folgt berechnet:

[Measures].
[Umsatz]/#old*#new

Fallstricke

Leider ist die Wertweitergabe nicht völlig frei von unerwarteten Phänomenen.

1) Deadlock
Es gibt die Anforderung, dass man eine Preis-, Umsatz oder eine Mengenplanung durchführen können soll. Dabei sollen jeweils zwei der drei Kennzahlen beplant werden, die nicht beplante Kennzahl ergibt sich dann jeweils als Resultat einer Berechnung.
Nach bisherigem Kenntnisstand würden wir auf den Kennzahlen Umsatz und Absatz jeweils eine Wertweitergabe auf die jeweils andere Kennzahl Absatz bzw. Umsatz einrichten, der Preis würde sich durch die Berechnungsformel in beiden Fällen ergeben und kann, wie oben bereits gesagt, nicht selbst geschrieben werden. Leider führt eine solche Wertweitergabe zu einem Deadlock beim Schreiben.
Was passiert…?
Man erfasst einen Absatz und durch die hinterlegte Regel wird auch der richtige Umsatz geschrieben. Die im Umsatz hinterlegte Regel zur Wertweitergabe zum Absatz würde erneut den Absatz schreiben. Jetzt kann sich jeder selbst ausmalen, was dann passiert: Absatz schreibt Umsatz, Umsatz schreibt Absatz und von vorn. Diese Weitergabekaskade muss durchbrochen werden, um die Anforderung dennoch erfüllen zu können.
Man muss für beide Kennzahlen eine “Erfassungsfilterkennzahl” anlegen. Die Weitergabe erfolgt dann auf die ursprüngliche Kennzahl.

Abb. 3: Deadlock umgehen

Wichtig ist hierbei, dass man Filterkennzahlen für die Eingabe verwendet (Filter meist sinnvoll mit der Periodenansichts- bzw. der Kumulationsdimension).

2) berechnete Kennzahlen
Da berechnete Kennzahlen selbst nicht geschrieben werden können, müssen wir mit der Option “nicht, sondern nur abhängige Analysewerte ändern” arbeiten. Dies schützt uns aber leider nicht vor einem inhaltlichen Problem: Welche der beiden Berechnungsgrundlagen des Preises soll denn geändert werden, wenn sich der Preis ändert? Die Antwort kommt meist sehr schnell: Beide… Alles Weitere ist eine Grundsatzdiskussion bis zurück zum ehemaligen Staffelsteiner Bürger Adam Ries, da man bei einer Preisänderung nicht den Absatz und gleichzeitig auch den Umsatz ändern kann, sondern nur eine der beiden Zahlen.
Es ist natürlich sehr gut vorstellbar, dass man die Wertweitergabe dahingehend flexibel gestaltet, dass der Anwender “auswählen” kann, welcher Wert zurück geschrieben wird.

Man erfasst eine Hilfsgröße “Absatz schreiben” und erweitert die Berechnung der Wertweitergabe um die entsprechende Bedingung:

iif(      [Measures].[Absatz schreiben] = 1,
          [Measures].[Umsatz]/#old*#new,
          [Measures].[Umsatz]/#old*#old
)

Natürlich muss es eine entsprechend gegenläufige Bedingung für die Wertweitergabe an die Umsatzkennzahl geben.

3) mehrfache proportionale Weitergabe
Damit die Änderungen immer synchron laufen, sollte die Weitergabe immer nur aus einer Quelle erfolgen. Sonst kann der resultierende Wert auf der Zielkennzahl nur noch sehr schwer nachvollzogen werden, wie das folgende Beispiel plastisch zeigt:

Abb. 4: Mehrfache proportionale Weitergabe

Zur Ermittlung des Resultats auf der Kennzahl Umsatz ist die Eingabereihenfolge von entscheidender Bedeutung. Folgende Reihenfolge wurde gewählt:

Letztlich wird schon nach drei Eingabeschritten deutlich, dass die Entstehung der Umsatzzahl praktisch nicht nachvollziehbar ist, wenn man die Eingabereihenfolge nicht kennt. Die Herausforderung besteht also letztlich darin zu verhindern, dass man von diversen Kennzahlen an eine einzige resultierende Kennzahl weitergibt.

Beachtet man diese Hinweise, kann mit Hilfe der Wertweitergabe ein sehr gutes Planungssystem aufgebaut werden. Dies ermöglicht dem Planer dann den Gang direkt auf die Rennstrecke und nicht zum Probesitzen ins Autohaus.