Allokationen oder Umlagen – jetzt mit EPCM

Wenn das Wort Allokationen (Umlage) fällt, sollten sie an Profitability and Cost Management denken. Ein Werkzeug welches stark verbessert wurde und ganz und gar für dieses geschaffen ist. In diesem Beitrag nehme ich sie mit und zeige, warum mir dieses so gefällt.

Was ist EPCM?

Das Profitabilty and Cost Management ist kein neues Produkt im EPM, aber es gab eine komplette Überarbeitung was es zu einem richtig guten Werkzeug macht. Es ist Teil der Enterprise Performance Management Suite und hat zum Ziel Allokationen und Activity Based Costing einfacher und schneller zu machen. Hierbei ist das Ziel, dass keine Calc Scripte geschrieben werden müssen, auch erreicht.

Unter der Haube besteht die Anwendung aus zwei ASO Datenbanken. Ja, sie lesen richtig. In ASO Datenbanken kann man zwei typen von Berechnungen mit Skripte machen. Eine ist ein (einfaches) Custom Calc Skript welches ich in meinem Beitrag „Datacopy in einer ASO Datenbank“ beschrieben habe. Die andere ist eine Allokation von Daten, und diese wird im Hintergrund verwendet. Ferner ähnelt sich viel einer Planning Cloud Anwendung.

Modellierung

Das Herzstück von Profitability and Cost Management ist unter der Kachel „Modellierung“ zu finden. Hier gibt es die Menüpunkte Modelle, Designer, Modellvalidierung, Berechnungssteuerung, Berechnungsanalyse und Regelabgleich. Ich werde diese zuerst ihnen vorstellen, und dann ein Allokationsbeispiel zeigen.

Abbildung 1: Modellierung Kachel

Die Allokationen werden in Modelle verteilt. Die Einteilung kann auf verschiedene Kriterien geschehen und in der Beispielanwendung wurde unterschieden zwischen Szenarien. Ziel ist es eine bestimmte Allokationsanforderung zusammen zu fassen.

Abbildung 2: Modelle

In dem Modell kann der erste Schritt vom Kontext ausgewählt werden. Hier kann man z.B. das Szenario festlegen und dann braucht man sich darum nicht mehr zu kümmern. Es ist wie ein FIX oben im Skript.

Abbildung 3: Modell bearbeiten und der Kontext ist hier NoDriver in der Dimension Driver.

Regelset

In dem Designer werden die Regeln erstellt. In dem Beispiel in Abbildung 4 sind verschiedene Regelsets und darunter Regeln dargestellt.

Abbildung 4: Designer mit Regelsets und darunter Umlageregeln.

In einem Regelset bringt man Allokationsschritte zusammen wie die Verteilung von Gebäudekosten auf Abteilungen mit verschiedene Logiken.

Hier kann die Abfolge der Regelsets eingestellt werden. Auch kann man diese leicht aktivieren oder deaktivieren. Dann kann definiert werden, ob die Berechnung der Regeln seriell oder parallel stattfinden muss. Auch ob iterative Berechnungen notwendig sind.

Abbildung 5: Bearbeiten von einem Regelset.

Auch hier ist in dem Reiter Elementauswahl ein Kontext zu definieren. In diesem Fall wird für die unterliegenden Regeln die angezeigten Dimensionen auf die Elemente gesetzt.

Abbildung 6: Kontext von dem Regelset.

Umlageregel

In der Umlageregel ist der Rechenschritt untergebracht. Der Regelname wird ein Element in der Outline. Dieses hat den Vorteil, dass man hier die Ergebnisse von diesem Rechenschritt sehen und analysieren kann.

Auch hier ist eine Abfolge einzugeben und man kann hier den Regelkontext übernehmen. Besonders finde ich, dass hier entweder ein Betrag (Wert oder Prozentsatz) angegeben werden kann, der von der Quelle aus verteilt wird. Der Rest bleibt erst einmal auf der Quelle und kann in weiteren Umlageregeln anders verteilt werden.

Abbildung 7: Umlageregel mit verschiedene Reiter

Die Quelle und das Ziel werden ausgewählt. Das Gute daran ist, dass immer auf Level0, also dem untersten Level gerechnet wird, und entsprechend kann man die Parent Elemente auswählen. In dem Beispiel in Abbildung 8 wird von dem Knoten Corporate auf 7 verschiedene Entities verteilt.

In dem Account ist links „Facilities Expenses”eingegeben, und auf der rechten Seite wird hierauf Bezug genommen. Hierdurch muss man nichts auswählen – nur was anders ist, muss angegeben werden.

Abbildung 8: Quelle – Ziel Definition

Treiber

Bei der Definition von dem Treiber kann man wieder aus allen Dimensionen eine Auswahl machen. Standard ist auch hier wieder die Referenz auf die schon eingetragenen Elemente von Regelset und Umlageregel eingetragen. Um den Ort, wo der Treiber eingetragen ist, braucht hier nur ein Account angegeben zu werden.

Abbildung 9: Treiberdefinition

Verrechnung

Die Verrechnung ist der Betrag, der nicht Umgelegt wurde. Hier kann man angeben, wo dieser hin gebucht werden muss. In der Regel bleibt dieser in der Quelle.

Abbildung 10: Verrechnung

Berechnungssteuerung

Wir springen jetzt in die Berechnungssteuerung. Dieses ist für den Planning-Kenner etwas ungewöhnlich, denn hier gibt es einen Point Of View (POV) aus Jahre, Periode, Szenario und Version. Ja, die Dimensionen einer Planungseinheit.

Nur wenn der Status auf Entwurf steht, kann dieser POV gerechnet werden.

Abbildung 11: Berechnungssteuerung mit POV Selektion

Wenn mindestens ein POV ausgewählt wurde, wird der Knopf „Modell berechnen“ aktiv. Für diesen Bereich wird jetzt eine Berechnung und Kriterien ausgewählt. Diese gehen in den Berechnungsjob.

Oben wird zuerst das Modell ausgewählt.

Abbildung 12: Der Berechnungsjob

Dann kann man unten im Verarbeitungsbereich eine weitere Selektion der Regelsets oder Umlageregeln machen. In den meisten Fällen möchte man aber alle ausführen, damit alle Kosten umgelegt sind.

Die Performance ist sehr gut. Wir kennen ja die stundenlangen Berechnungen in BSO, wo verteilte Werte zuerst wieder Aggregiert werden müssen, damit diese in dem nächsten Schritt dann weiter verteilt werden können.

Hier vollzieht sich das alles im Minutenbereich.

Berechnungsanalyse

In der Berechnungsanalyse kann man den Fortschritt überwachen, aber auch verschiedene andere Aktionen starten. So gibt es anstatt einer Logdatei, einen Bericht mit den Berechnungsstatistiken und die Möglichkeit einen Vergleich mit einem anderen Modell zu machen.

Abbildung 13: Berechungsanalyse mit verschiedenen Optionen.

Regelabgleich

In dem Regelabgleich sehen wir den Inhalt der Dimension PCM_Balance. Diese Logik ist schon gut aufgebaut. Wir haben die Eingabe – diese wird nie durch die Berechnungen angefasst, und damit sind diese wiederaufsetzbar. In der Anpassung kann man, wenn gewollt noch einen Betrag eingeben. Der Wert in Umverteilung/Eingang wird dann verteilt und kommt dann umgekehrt in der Umverteilung/Ausgang aus. Hierdurch sollte das Saldo dann 0 sein.

Wenn nicht alles in einer Regel verteilt wurde, dann gibt es einen Laufenden Rest. Dieser steht dann im nächsten Schritt, mit z.B. einer andern Logik zur Verfügung um auf andere Weise verteilt zu werden.

Abbildung 14: Die Logik von Eingabe, Umverteilung/Eingang und Umverteilung/Ausgang

Hier kann man sehr schnell sehen, ob die Umlage geklappt hat, und wo sich Delta’s befinden.

Die Werte sind alles anklickbar, wo sich ein Analysefenster öffnet, um nachzusehen, wo es klemmt!

Fazit

Wie sie sehen konnten, ist der Anwendungstyp PCM richtig gut um Umlagen zu berechnen. Ohne Skripte zu schreiben, kann ein Anwender die Regeln erstellen und ausführen. Es gibt direkt eine Dokumentation wie die Allokationen aufgesetzt sind und ferner gibt es Formulare, Berichte und vieles mehr, was sie auch aus dem Planning schon kennen.