Ausgangslage
Zur Veranschaulichung der Features des Kalenders dient das folgende Beispiel. Ein Fahrrad-Hersteller bei dem von den Verkaufsmanagern der einzelnen Fahrradsparten (Mountain Bike, Road Bike etc.) eine Umsatzprognose durchzuführen ist. Der Prozess soll folgendermaßen aussehen:
Ausgangspunkt der Planung ist ein planungsbereites Model.
Die Salesmanager sind einzelnen Produktgruppen zugeordnet und planen diese entsprechend als Teil eines Teams. Die einzelnen Planungsaufgaben werden über die Produktgruppe eingeschränkt. Hinter dieser können Verantwortliche in den Stammdaten hinterlegt werden. Da diese Information bei der Anlage des Kalenders kopiert wird, empfehlen wir hier, nicht einzelne User, sondern Gruppen zu hinterlegen. Die Person Responsible wird im weiteren Prozess benötigt.
Die Planung soll zunächst in einer Story stattfinden. Diese beinhaltet nur das Planungsmodell mit einer eingabe-bereiten Tabelle.
Dies soll der Ausgangspunkt des Planungsprozesses sein.
Modellierung des Planungsprozesses in der Analytics Cloud
Der Planungskalender bietet verschiedene Bausteine, sog. Tasks, aus denen der Prozess modelliert werden kann. In allen Tasks können Working Files hinterlegt werden, also Storys oder Analytic Applications sowie Beschreibungen und persönliche Notizen. Ein Task braucht einen Startpunkt, dieser kann immer zeitlich gesetzt sein. Einige Tasks können auch über den Parent Process oder in Abhängigkeit von anderen gestartet werden. Der übergeordnete Prozess, unter dem alle weitere Tasks liegen, wird über die Startbedingungen der Tasks definiert.
Die einzelnen Tasks im Überblick:
- General Task: Dieser Task übergibt Storys oder Analytic Applications direkt an Personen oder Teams mit einem eingestellten Filterbereich, zuständige Viewer oder Reviewer, einem zeitlichen Rahmen und weiteren Dateien, die bei der Planung helfen könnten. Hier sind Reporting Masken mit der letzten Planungsrunde oder Ähnliches denkbar.
- Review Task: Diese übergeben die Ergebnisse einer Planrunde zur Abnahme. Der Review Task ist immer in Abhängigkeit zu einem anderen Task oder einem Parent Process.
- Composite Task: Sind eine Kombination aus General Task und Review Task. Wenn der Prozess nicht zu granular werden soll, kann anstelle des General und Review Task auch der Composite Task genutzt werden. Diese starten entweder zu einem bestimmten Zeitpunkt, in Abhängigkeit von einem anderen Task oder einem Parent Process.
- Process: Dient als ordnendes Element für den Prozess. Hat die gleichen Fähigkeiten wie ein General Task.
- Data Locking Task: Für das automatische oder manuelle Einstellen von Datensperren.
- Data Action Task und Multi Action Task: Zum Ausführen von Data Actions.
- Input Task: Ein alter Task, der nicht mehr genutzt wird.
Ein erster Aufbau des Prozesses könnte wie folgt aussehen.
Der erste Prozess dient als Einsortierung und hat keine Aufgaben. Er ist der Parent Process für alle unterliegenden Tasks.
Im Revenue_Forecast_Planning Task sollen die Planungs- und Review-Runden stattfinden. Der zweite Task ist eine Data Action, die die Actuals des Vorjahres als Grundlage für den Forecast in diesem Jahr in den Forecast kopiert. Dieser Task startet, nachdem der Parent Process gestartet ist.
Der Revenue_Forecast_Locking Task setzt eine Datensperre auf die Datenbereiche, die nach der Planung nicht mehr verändert werden sollen. Die Ausführung dieser Aufgabe hängt nicht am Parent Task, sondern am Revenue Forecast_Planning Task. Sobald dieser erfolgreich abgeschlossen ist, wird die Datensperre ausgeführt.
Mit diesen vier Objekten haben wir eine Grundlage aufeinander aufbauender Ereignisse, die den Planungsprozess nachbilden.
- Starten des überliegenden Prozesses.
- Automatische Ausführung der Data Action und Kopie der Actuals in die Forecast Version
- Start der eigentlichen Planung.
- Datensperre
Jetzt muss der Revenue_Forecast_Planning Prozess mit Inhalt gefüllt werden. Der Event Wizard erzeugt alle nötigen Input Tasks. Unsere Planungsstory ist die Grundlage der Planung für alle Aufgaben im Prozess.
Die Planung wird in Produktgruppen unterteilt, deswegen wählen wir diese als Driving Dimension.
Die in der Produktgruppen Dimension definierte „Person Responsable“ sind die Bearbeiter der Tasks. Der Reviewer ist nicht notwendig, der Review Task übernimmt diese Aufgabe.
Der genau Eventname kann im vierten Schritt definiert werden. Die Beschreibung ist für unser Beispiel ausreichend.
Nach einer Preview werden die Tasks automatisch angelegt.
Diese Tasks sind zeitlich abhängig, der Event Wizard erlaubt keine andere Einstellung. Die einzelnen Tasks können aber zum abhängigen Start mit dem Parent Prozess geändert werden.
Es können direkt in den Tasks einzelne Reviewer hinzugefügt werden. Dies ist nützlich, wenn jede Planung eine andere Personengruppe prüft. Für diesen Prozess benutzen wir einen Review Task, der starten soll, sobald alle Planungen abgeschlossen sind, da alle Ergebnisse von der gleichen Gruppe geprüft werden sollen.
Der Review Task hängt direkt von den Plan Tasks ab. Sobald diese abgeschlossen sind, beginnt die Review.
Der komplette Prozess sieht so aus:
Damit die Planung starten kann, muss der Prozess noch aktiviert werden.
Nach der Aktivierung wird die Data Action zur Kopie der Daten ausgeführt, daraufhin beginnen die Tasks für die Planung. Der Erfolg eines Tasks ist im Kalender direkt sichtbar, genau wie der Fortschritt einzelner Tasks. Die Zielerreichung kann selbst definiert werden. Bei einem Task mit mehreren Reviewrunden könnte so die eigentliche Planung den Fortschritt um 50% füllen, die erste Reviewrunde um 25% und die zweite ebenfalls um 25%.
Die Planer können per Mail oder innerhalb der SAC auf ihre neue Aufgabe Aufmerksam gemacht werden. In beiden Fällen führt ein Link zur Planungsstory, in der die definierten Planungsaufgaben mit den entsprechenden Filtern warten. Wenn diese Story oder Analytic Application aus dem Kalender heraus aufgerufen wird, ist eine neue Leiste sichtbar, die es ermöglicht, die eigenen Eingaben zu submitten oder zu declinen.
Durch den Submit wird die Aufgabe abgeschlossen und entsprechend im Kalender markiert. Decline setzt die Aufgabe erstmal auf „on Hold“. Im Kalender kann dann ein neuer Bearbeiter ausgesucht oder die Aufgabe an die gleiche Person nochmals verschickt werden. Submit gilt immer für alle Bearbeiter dieses Tasks, decline kann nur für einen selbst oder alle ausgeführt werden.
Nachdem auch der letzte Task submitted wurde, beginnt der Review Task. Für diesen zeigt sich ein ähnliches Layout wie schon bei den Input Tasks.
Approve entspricht dem Submit, mit Reject wird die Aufgabe wieder an die Planer von vorher übergeben und der Status wird zurückgesetzt. Da wir einen Review Task für alle drei Planungen haben, wären also alle wieder offen. Mit Approve ist auch dieser Teil der Planung abgeschlossen. Der überordnete Prozess Revenue_Forecast_Planning kann im Kalender Submitted und damit für abgeschlossen erklärt werden. Der Submit erfolgt im Task im Kalender selbst. Das Data Locking sperrt automatisch nach Abschluss des Planungsprozesses den definierten Datenbereich. Somit ist die gesamte Planung fertig und ist bereit im Reporting geprüft zu werden.
Schwierigkeiten bei der Kalendernutzung
Manuelle Nacharbeiten je generierten Einzelschritt
Es sind viele manuelle Schritte nötig, um den Prozess aufzusetzen. In dem Beispiel wird nur auf drei Produktkategorien aufgeteilt, bei einer weit höheren Anzahl steigt der Anpassungsaufwand entsprechend. Der Wizard zum Erzeugen der Tasks erlaubt keine Einstellung der Dependencies, was manuelle Korrekturen in allen einzelnen Aufgaben erforderlich macht. Es fehlen Komfortfeatures, die eine einfache Modellierung ermöglichen. Der hier modellierte Prozess könnte für den Januar so genutzt werden, er müsste aber für den Februar erst kopiert und gegebenenfalls angepasst werden. Auch hier zeigt sich wieder der erhöhte manuelle Aufwand.
Zeitabhängige Darstellung, nicht Prozessabhängige
Das Layout und die zwingende Zeitabhängigkeit aller Prozesse sind sehr gewöhnungsbedürftig. Die Sicht ist stets auf den Zeitraum und nicht auf die einzelnen Prozesse ausgelegt. Beim Einstieg in die Monatssicht werden Prozesse des nächsten Monats nicht angezeigt, beim Einstieg in die Jahressicht leidet die Performance stark, sobald viele einzelne Task genutzt werden.
Keine Verzahnung mit der Beladung möglich
Grundlegend wäre ein Task zur Beladung des Planungsmodels wünschenswert. Die Import- und Export Jobs sind derzeit, ohne Coding, über das Datenmanagement im Model einstellbar und hier auch nur zeitabhängig. Ein ereignisbasiertes Im- und Exportieren basierend auf Kalendertasks wäre wünschenswert.
Analytic Applications erweitern die Kalendermöglichkeiten
Einige Handling Probleme lassen sich innerhalb einer Analytic Application mit der Calender API umgehen. Primär können die Approvals und Submits, die automatisch beim Aufruf der Kalenderaufgaben erscheinen, mit der API selbst eingebunden werden. Zusätzlich können Composite Task direkt angelegt werden. Damit lassen sich aber keine Prozesse modellieren und die Aufgaben können auch nur zeitlich abhängig geschalten werden.
Fazit
Zusammenfassend ist der Kalender zur Modellierung von einfachen Planungsprozessen gut geeignet. Die Kollaborationsmöglichkeiten sind eine Stärke in der Analytics Cloud und kommen hier voll zur Geltung. Allerdings müssen Änderungen in der Planung oder einzelnen Tasks stets fachkundig begleitet werden. Damit ist fraglich, ob der Kalender vom Business Nutzer allein betreut werden kann oder auch IT-seitig unterstützt werden muss.
Ansprechpartner
Dominik Dussa
Consultant
