Planungsanwendungen lassen sich mit DeltaMaster sehr gut umsetzen. Mit dem integrierten Splashing, Wertweiterleitung und Wertfixierung lassen sich viele Anforderungen sogar ohne datenbankseitige Anpassungen simpel umsetzen. Häufig erfordert die Komplexität individueller Planungsbedingungen eine Lösung im Backend.
Dieser Blog-Beitrag beschäftigt sich mit einem Planungsszenario unter Berücksichtigung von festen Wertvorgaben. Dabei wird geklärt:
- Welche Anforderungen ergeben sich aus diesem Planungsszenario?
- Wann und warum stoßen die integrierten Planungsfeatures von DeltaMaster an ihre Grenzen?
- Wie lässt sich die Anforderung datenbankseitig erfüllen?
Was ist die Anforderung?
Die Chair AG organisiert ihre Planung zweistufig. In einem ersten Schritt gibt das Controlling Umsätze auf grober Ebene vor. Umsätze werden jährlich festgelegt – für Kunden nach Gebiet und für Produkte nach Produkthauptgruppen (siehe Abbildung 1).
Abbildung 1: Ursprüngliche Verteilung der Vorgabenwerte über Jahre, Produkthauptgruppen und Gebiete.
In einem zweiten Schritt wird die Planung dann in allen Dimensionen verfeinert, sodass Planwerte sowohl für jeden Monat als auch für Kunden-Gebiete und für Produktgruppen (siehe Abbildung 2) zur Verfügung stehen.
Abbildung 2: Ursprüngliche Befüllung der Planwerte über Monate, Produktgruppen und Gebiete.
Dabei sollen die Vorgabewerte jederzeit exakt erreicht werden. Wird zum Beispiel der Umsatz für Luxusmodelle im Januar erhöht, muss die entstandene Differenz durch Reduktion in den restlichen Monaten ausgeglichen werden.
Wann und warum stoßen die integrierten Planungsfeatures von DeltaMaster an ihre Grenzen?
Der herkömmliche Planungsansatz unterstützt dieses Verhalten nicht. Bei Änderungen auf untergeordneten Ebenen, würde sich die Aggregation entlang der Hierarchie korrigieren und keinen Ausgleich anstellen.
Nativ bringt DeltaMaster die Option „Werte fixieren“ mit. Damit kann eine Dimension festgelegt werden, entlang der beliebige Werte eingefroren werden können. Eine Fixierung des Jahresumsatzes führt dann dazu, dass Anpassungen durch die restlichen Monate ausgeglichen werden. Dies ist in Abbildung 3 dargestellt.
Abbildung 3: Funktionsweise der Option „Werte fixieren“.
Allerdings funktioniert dies nur entlang einer Dimension. Soll beispielsweise eine Anpassung des Umsatzes im Dezember für die Produktgruppe Arcade stattfinden und gleichzeitig die Jahressumme über alle Luxusmodelle fixiert werden, kommt man mit der Option nicht zum gewünschten Ergebnis und muss auf eine datenbankseitige Lösung umsteigen.
Welche Idee steckt hinter der datenbankseitigen Lösung?
Spielen wir zu Beginn das Szenario an dem bekannten Beispiel durch. Daran können wir die entstehenden Probleme gut erkennen und Lösungsansätze formulieren.
Wie in Abbildung 4 gezeigt, soll im Gebiet Süd 1 für die Produktgruppe Arcade eine Umsatzerhöhung um 10 Prozent im Dezember 2024 erfolgen. Dadurch erhöht sich der Wert von 380.273 auf 418.300. Die korrespondierende Vorgabe für das Gebiet Süd 1, die Produkthauptgruppe Luxusmodelle und das Jahr 2024 sieht einen Wert von 13.689.810 vor.
Abbildung 4: Initiale Nutzereingabe. Umsatzerhöhung von 10% im Dezember 2024 auf Arcade in Süd 1.
Die Eingabe würde den Aufruf der P_WriteBackSQL_FACT-Prozedur bewirken. Diese nimmt standardmäßig eine Aktualisierung der Datenbank vor.
Nach der Anpassung ist die Vorgabe überschritten, wie es in Abbildung 5 zu sehen ist. Die datenbankseitigen Prozeduren sollen die Überschreitung nun abfangen und korrigieren. Dazu eignet sich eine Implementierung innerhalb der P_WriteBackSQL_FACT…_PostProcess-Prozedur.
Abbildung 5: Initiale Wertänderung. Erhöhung wird entlang aller Hierarchien aggregiert.
Wie funktioniert das nun konkret? Aus der ursprünglichen Anpassung ist bekannt, welcher Datenraum aktualisiert wurde. Hier sollen die Werte fixiert werden und sich nicht verändern. Außerdem lassen sich aus der ursprünglichen Anpassung auch der Wert und der zugehörige Datenraum der korrespondierenden Vorgabe ermitteln. Der verbleibende Datenraum der Vorgabe (in Abbildung 6 blau markiert) soll die Überschreitung ausgleichen.
Abbildung 6: Berechnung des Ausgleichswerts aus Eingabe und Vorgabe.
Es muss sich ermitteln lassen, welche proportionale Änderung für Zellen im verbleibenden Datenraum notwendig ist. Im einfachsten Fall genügen dafür die Vorgabe sowie der Wert vor und nach der Anpassung.
Der Ausgleich ist in Abbildung 7 dargestellt und kann als zusätzliche Dateneingabe gesehen werden. Für unser Beispiel bedeutet das, dass der Umsatz bei nicht fixierten Zeilen im Gebiet Süd 1, der Produkthauptgruppe Luxusmodelle und dem Jahr 2024 auf 99,72% des aktuellen Wertes reduziert werden soll. Innerhalb der PostProcess-Logik wird also erneut die P_WriteBackSQL_FACT-Prozedur aufgerufen.
Abbildung 7: Zusätzliche Dateneingabe zum Ausgleich der initialen Eingabe.
Welche Probleme gilt es zu lösen?
Für eine vollständige Lösung müssen die folgenden zwei Probleme noch gelöst werden:
Problem 1: Es ist nicht bekannt, auf welchen Zellen eingegeben wurde, und auf welchen Zellen ein Ausgleich stattfinden kann. Damit würden wir also die Differenz auch auf die aktuelle Eingabe verteilen. In der Konsequenz würde sich die ursprüngliche Eingabe verändern und erneut eine Differenz zur Vorgabe bewirken.
Lösung: Durch eine weitere Dimension werden Zellen der Dateneingaben von Ausgleichszellen isoliert. Mit der flachen Dimension Check wird der aktuelle Zustand signalisiert. Einträge mit CheckID „1“ können als Ausgleichswert genutzt werden. Einträge mit CheckID „2“ haben eine Eingabe erfahren und sollen unverändert bleiben. Wichtig: Für eine konkrete Zelle unseres Datenraums ist CheckID zu einem Zeitpunkt genau eines von beiden – entweder „1“ oder „2“.
Initial werden alle Werte mit der CheckID „1“ befüllt. Die PostProcess-Logik kümmert sich um das Setzen und Zurücksetzen der CheckID bei entsprechenden Datensätzen.
Die EntryID ist ein idealer Indikator zur Ermittlung fixierter Datensätze.
Für den Berichtsbau in DeltaMaster ist die Dimension irrelevant. Der Filter sollte immer auf dem AllMember der Dimension stehen oder die Dimension gänzlich ausgeblendet sein.
Problem 2: Mit dem Aufruf der P_WriteBackSQL_FACT-Prozedur innerhalb der PostProcess-Logik erzeugen wir eine endlose Verkettung. Die Verteilung der Differenz darf aber nur einmalig geschehen.
Lösung: Ein nativer Parameter der P_WriteBackSQL_FACT-Prozedur ist die SourceID. Anhand der SourceID lässt sich differenzieren, ob es sich bei dem Aufruf um eine Nutzereingabe oder einen Wertausgleich handelt.
Wie sieht der vollständige Ablauf aus?
Gehen wir abschließend den vollständigen Ablauf an unserem Beispiel durch. Die Ausgangslage bleibt die Gleiche:
1. Eingabe in Zelle bewirkt Aufruf der P_WriteBackSQL_FACT-Prozedur
- Produktgruppe: Arcade
- Gebiet: Süd 1
- Monat: Dezember 2024
- Check: All
- Aktualisierung: 10% +
2. Ermittle die korrespondierende Vorgabe für die Eingabe
- Produkthauptgruppe: Luxusmodelle
- Gebiet: Süd 1
- Jahr: 2024
- Wert: 13.389.810
3. Prüfe anhand der SourceID, ob es sich um eine Nutzereingabe handelt (SourceID = 4)
4. Setze CheckID für betroffene Zellen auf „2“
5. Berechne die proportionale Veränderung, die zum Ausgleich der Eingabe notwendig ist.
6. Führe erneut die P_WriteBackSQL_FACT-Prozedur aus:
- Produkthauptgruppe: Luxusmodelle
- Gebiet: Süd 1
- Jahr: 2024
- Check: 1
- Aktualisierung: * 99,72%
- SourceID: 5
7. Setze CheckID für betroffene Zellen auf „1“ zurück
Das Resultat der Eingabe im Dezember 2024 auf der Produktgruppe Arcade im Gebiet Süd 1 mit Wertausgleich entlang mehrerer Dimensionen zeigt Abbildung 8. Im Vergleich zum initialen Zustand lässt sich erkennen, dass der Umsatz für Luxusmodelle über das gesamte Jahr unverändert ist. Der Wert der restlichen Produktgruppen hat sich auf Monatsebene von 380.273 auf 379.186 leicht verringert.
Abbildung 8: Ergebnis der Dateneingabe mit Vorgabenausgleich.
Variation: Verzögertes Zurücksetzen der CheckID
In der hier erläuterten Variante wurde die Eingabezelle nur für eine einzige Eingabe fixiert. Weitere Eingaben auf anderen Zellen würden den Wert wieder verändern können. Schritt 7, das Zurücksetzen der CheckID auf „1“, lässt sich beliebig verzögern. So kann der Schritt in die Commit- und Cancel-Prozeduren aufgenommen werden, um veränderte Werte für den gesamten Zeitraum einer Transaktion zu fixieren, oder sogar an den Abschluss einer Planungsrunde gekoppelt werden, um manuell Eingaben dauerhaft zu fixieren. Die proportionale Änderung für Ausgleichswerte muss dann allerdings anders berechnet werden.
Eine vollständige Herleitung würde den Fokus dieses Artikels überschreiten. Interessierte LeserInnen finden im beigelegten Quellcode eine Implementierung der Variation.
Weiterführende Informationen
Mehr Einblicke in den Funktionsumfang der Planungslösung von Bissantz finden Sie im Beitrag „Top-down-Planung mit Bissantz: Automatische Verteilungslogik ohne Aufwand“ sowie im Überblick zum Thema „Daten in Planungsanwendungen eingeben“. Wer das Planungsszenario einmal selbst nachvollziehen und testen möchte, kann die Datenbank und Demoanwendung hier herunterladen.
Demoanwendung herunterladen
