FreiForm – ein neuer Applikationstyp für Planning

In der Planning Enterprise Cloud gibt es einen neuen Anwendungstyp mit dem Namen „Frei Form“ (engl. Free Form). Diese verspricht mehr Freiheit im Aufbau von Planungsanwendungen, und das ist natürlich immer willkommen, denn alle Firmen sind anders und haben oft spezifische Wünsche. In diesem Beitrag zeige ich interessante Dinge zu diesem Planungstyp.

Essbase mit Formularen

Schon bei der ersten Präsentation vom Produkt Management wurde auf „Essbase mit Formulare“ referenziert, und jetzt, dass ich dieses ausprobiert habe, kann ich dieses auch bestätigen. Es ist eine sehr starke Kombination, die viel eingesetzt werden wird.

Jede Planungsanwendung hat einige festgeschriebene Objekte, die nicht oder nur minimal geändert werden können. Dieses gewährleistet die Planungsfunktionalität der Anwendung auf die Essbase Datenbank. So gibt es die Plicht-Dimensionen Account, Entität, Szenario, Version, Jahr und Periode. Diese konnten zwar umbenannt und zweckentfremdet werden, aber z.B. eine Szenario Dimension blieb immer eine Dimension, wo die Zeitperioden geöffnet und geschlossen werden konnten. Ein anderes Beispiel ist die Trennung von Jahre und Monate in zwei Dimensionen, welches nicht immer praktisch ist und oft in Essbase zu bessere Lösungen führte.

Planning hat dafür aber andere Funktionalität, die wir in Essbase nicht, oder nur schwierig umsetzen konnten, und dazu gehören unter vielen Anderen die Formulare.

Anlegen einer Free Form Anwendung

Beim Anlegen einer neuen Planungsanwendung sieht man direkt im ersten Fenster unter Application Type die Option „Free Form“.

Auswahl von Free Form Applikationstyp.

Abbildung 1: Application Type „Free Form“.

Danach erscheint unter Application Setup die Option, um eine Essbase Anwendung zu importieren. Derzeitig hat das Selektionsfenster nur einen Eintrag, nämlich eine Outline (in XML Format oder .otl), doch ich erwarte hier weitere Optionen in zukünftige Updates.

Menu um Datei mit Outline hochzuladen.

Abbildung 2: Importieren einer Essbase Anwendung.

Weil in dieser Outline schon alle Dimensionen und übrige Dinge spezifiziert sind, geht es direkt weiter zur Übersicht und dem Startknopf zum Erstellen der Anwendung.

Anlegen der Anwendung.

Abbildung 3: Die Anwendung kann jetzt angelegt werden.

Nach einer kurzen Zeit kommt dann die Nachricht, dass die Anwendung erfolgreich angelegt wurde. Zum Erstellen dieser Anwenung hatte ich einen Essbase Cube genommen, den ich für Schulungszwecke erstellt hatte und eine Vielzahl von Dimensionen mit viel Funktionalität enthält. Man könnte auch eine kleine Outline als Basis nehmen, diese dann zum Erstellen der Anwendung verwenden und alle weiteren Elemente und Dimensionen später einfügen. Wichtig ist, dass diese eine Accounts und Periode dimension hat, denn alle weiteren sind generische Dimensionen.

Das Free Form sollte nicht verwechselt werden mit dem “Free-Form Budgeting” oder dem “Free Form Planning Business Process”. Diese beschreiben Business Prozesse und hier ist der Anwendungstyp gemeint. Dieser Plantyp wird innerhalb von Oracle auch Operational Planning genannt.

Dimensionen und deren Eigenschaften

Auf dem ersten Blick sieht man keinen Unterschied: man hat die Kacheln und unter Overview gibt es die Dimensionen. Mein Essbase Modell hat keine Dimension von dem Typ Version. Dieses führte nicht zu einem Problem beim Anlegen der Anwendung.

Ubersicht der Dimensionen.

Abbildung 4: Eine Übersicht der Dimensionen

Und dann auch einen Blick in die Account Dimension zeigt, dass alles da ist. Beim Import der Outline wurde die Dimensionseigenschaft mit übertragen. Diese kann später nicht mehr geändert werden.

Dimension Account.

Abbildung 5: Die Accountsdimension mit allen Eigenschaften ist vorhanden.

Details von einem Account.

Abbildung 6: Elementeigenschaften in der Accounts Dimension

Die Elementeigenschaften von einem Account sind unverändert. Interessant ist das es hier auch eine Option für den Quellcube (Source Cube) gibt. Derzeitig hat ein Free Form Modell nur einen Cube. Dieser ist entweder vom Typ ASO oder Hybrid und wird bestimmt durch die Outline, die hochgeladen wird.

Nun wollte ich aber mal nachsehen, ob ich in der Jahre-Dimension Elemente anlegen konnte ohne das Pflicht-Präfix „FY“ und zweistelliger Jahreszahl. Ich mag gern ID’s mit Buchstaben, aber das Format der Jahreszahl in Planning ist ab und zu sehr unpraktisch, wenn eine Integration mit Relationalen Datenbanken gemacht werden muss. Wie schön wäre es, wenn man Perioden wie 01-2019 in Planning haben könnte…

Anlegen neuer Jahre.

Abbildung 7: Anlegen von neuen Jahren.

Die Dimension Year ist eine generische Dimension, genau wie die Dimension Scenario. Wie in den Eigenschaften von dem Element Actual zu sehen ist, gibt es hier keine der Planning typischen Szenario Eigenschaften. Also das öffenen und schliessen von Perioden in den Formularen muss auf eine andere Weise geschehen, z.B. über die Zugriffsrechte.

Eigenschaften eines Szenarios.

Abbildung 8: Generische Elementeigenschaften in der Szenario Dimension.

Als letztes schaue ich mir die Dimension Periode an. Hier sieht man schon schnell, dass beim Import die Eigenschaften einer Zeitdimension erkannt und diese auch als Periode in Planning angelegt wurde.

Import der Struktur von Periode.

Abbildung 9: Die importierte Struktur der Dimension Periode

Wenn man sich dann die Elementeigenschaften ansieht, dann sieht man dass diese auf eine 12-monatige Struktur aufgebaut ist.

Dimensions-element Periode.

Abbildung 10: Dimensionselement Period.

Man ist aber nicht so frei in dem Anlegen von Perioden wie im Essbase. Die Struktur unterhalb von YearTotal ist festgelegt. In einem anderen Test möchte ich mal eine Outline hochladen, die eine abweichende Struktur in der Zeitdimension hat, und sehen wie diese in Planning übertragen wird.

Funktionalität in dem Applikationstyp Free Form

Essbase ist kein Planning – und andersherum. Doch wo treffen diese sich jetzt in diesem Applikationstyp? Was gibt es in Essbase, was wir nicht in Planning haben?

Aus der Planning-Perspektive: Wir haben kein Workflow, Smart Push, Sandboxes, Predictive Planning und keine Wechselkursumrechnung.

Aus der Essbase-Perspektive: Wir haben keine Rule Files, Report Scripts, LRO, Calc Scripts, Partitioning, Essbase Zugriffsrechte-Konzept und kein MaxL.

Doch wir haben vieles was wir in Essbase nicht hätten: Formulare, Dashboards, ….

Wenn wir uns das Navigator Menü ansehen dann ist fast alles da was wir aus Planning kennen.

Navigator Menu.

Abbildung 11: Das Navigator Menü (immer noch in English)

Formulare

Ein Formular, wie wir dieses aus Planning nur zu gut kennen. Doch hier direkt auf eine Essbase Outline gesetzt. Einige Zahlen in das Formular eingetragen und auf Speichern gedrückt.

Formular in Freiform

Abbildung 12: Formular auf der Essbase Outline.

Wie sie in dem unteren Teil der Abbildung 12 sehen können, werden die Daten direkt aggregiert. Dieses ist so, denn es wurde Hybrid Essbase aktiviert, welches dann für die sofortige Aggregation sorgt.

Dashboards

Dashboards sind nichts Neues in Planning, doch hier geht diese direkt auf die Essbase Outline. Dieses ist Funktionalität, die wir in auch in dem Essbase Datenbankumfeld wieder brauchen, nachdem das WebAnalysis das End-Of-Live bekommen hat.

Dashboards haben eine gute Anbindung an die Strukturen, wie sie typisch sind in Essbase. Das OBI ist ja auf relationaler Struktur (mit Generationen) basiert.

Ein Dashboard auf eine Essbase Outline.

Abbildung 13: Ein Dashboard auf der Essbase Outline

Aufgabenlisten

Eine der sehr starken Funktionen, die es in Essbase Anwendungen nicht gibt, sind Aufgabenlisten. Hier können Benutzer durch Aufgaben geführt werden, wie bestimmte Formulare, Berechnungen und auf Instruktionen gewiesen werden. In den Business Rules können sogar Befehle auf die Kommandozeile ausgeführt werden, und dann öffnet sich eine ganz neue Welt der Möglichkeiten.

Aufgabenlisten.

Abbildung 14: Aufgabenlisten

Von Essbase nach Free Form Planning

Dieses Free Form Planning ist wie ich mir „Essbase in der Cloud“ vorstellte. Deshalb sehe ich eine grosse Zukunft für dieses Modul. Doch gibt es noch einige Herausforderungen wenn man bestehende Essbase Umgebungen überführen möchte…

Die drei wichtigsten sind:

  • Kein Essbase Zugriffsrechtemodell (Matrix bis auf Zellen-ebene vs. ein-dimensionale Zugriffsrechte)
  • Automatisierung (EPMAutomate und Jobs anstatt MaxL)
  • Schnittstellen (Data Management anstatt von Rule Files)

Was muss aber konkret gemacht werden?

Outline: der Import sollte keine Probleme bereiten. Ansonsten kann die Outline vereinfacht, und später wieder Komplett gemacht werden.

Daten: der Übertrag von Level-0 Daten ist nicht schwierig.

Calc Scripte: diese werden in Business Rules übertragen.

Rule Files: hier ist Aufwand notwendig, um diese in Data Management zu Überführen.

Report Skripte: diese gibt es auch nicht mehr und müssen in Data Exporte umgebaut werden. Diese haben aber weniger Funktionalität. In speziellen Fällen bietet die REST API eine Lösung.

MDX Queries: wie die Report Skripte.

Smart View: in den meisten Fällen wird die Abfrage möglich sein.

Financial Reports: die Datenbank verbindung muss auf Planning umgestellt werden. Auch sollte geschaut werden ob das Reporting nicht auf Management Reporting Cloud umgestellt werden sollte.

Fazit

Bei diesem ersten Kennenlernen bin ich sehr begeistert geworden von dem neuen Planungstyp FreiForm. Sie bietet viel Funktionalität, die es in Essbase nicht gibt und viel Freiheit welches wir in Planning nicht hatten. Nun bringt Oracle die Essbase- und Planning Anwendungen dichter zusammen, welches uns Entwickler viele neue Möglichkeiten für unsere Kunden bietet.

Es ist perfekt geeignet um einfache Essbase Anwendungen in die Cloud zu migrieren.

Ihr Philip Hulsebosch.

Veröffentlicht unter EPM Cloud, Planung & Berichtswesen Getagged mit: , , , , , ,