Finanzplanung der nächsten Generation

Als ich damals Teil des Projektteams wurde, ahnte ich noch nicht, dass ich das gesamte System zur integrierten Finanzplanung selbst einmal neu entwickeln würde. Ein Projekt, das nicht fordernder und fördernder hätte sein können.

Wenn Maintenance die Weiterentwicklung der Finanzplanung blockiert

Meine ersten Wochen im Projektteam verbrachte ich damit kleinere Fehler zu korrigieren, die die Fachbereiche meldeten und erste Erweiterungen zu konzeptionieren. Der erfahrene Kollege vor Ort unterstütze tatkräftig meine Einarbeitung in dieses hoch komplexe und historisch gewachsenes System. Ich kannte die eingesetzte Software bereits aus einigen anderen Projekten, aber die schiere Größe und damit verbundene Komplexität dieses System war zudem Zeitpunkt im deutschen Markt nicht anzutreffen. Allen Beteiligten war bewusst, dass trotz umfassender Dokumentationen viel KnowHow ausschließlich in den Köpfen der Mitarbeiter, die täglich den Betrieb und die Weiterentwicklung betreuten, vorhanden war.

Immer wieder führten vermeintlich kleinere Anpassungen und Weiterentwicklungen an der einen Stelle zu mehr oder weniger massiven Fehlern und Ausfallzeiten an anderer Stelle. Die vorhandenen Ressourcen des Kernteams waren mit bis zu 80% nur mit Maintenance blockiert. Die Weiterentwicklung galt als risikobehaftet, sehr aufwendig und bald auch als quasi-unmöglich.

Zurück an das Whiteboard

Nachdem man in einer vermeintlich ruhigeren Phase versucht hatte die offensichtlich kritischsten Komponenten des System zu identifizieren, wurde analysiert wie aufwendig und wie risikobehaftet eine Neuentwicklung einzelner Bestandteile sei. Mittlerweile kannte ich das System gut genug um den Erfolg solcher Bemühungen einschätzen zu können und war erleichtert, dass man sich gegen einen solchen „Flickenteppich“ entschied.

Wieso entwickeln wir nicht ein radikal einfaches Datenmodell, welches so generisch ist, dass Änderungen in den Finanzplanungsprozessen die Datenhaltung und -verarbeitung unberührt lassen? Was haben wir mit den Köpfen geschüttelt, als wir die ersten Drafts auf Papier brachten. Aber Papier ist bekanntlich geduldig und wir entwickelten einen Prototypen (anfänglich eher einen MVP!), auch als Diskussionsgrundlage für die Kollegen.

Wir sind diesen Weg konsequent weitergegangen. Im kleinen interdisziplinären Team wurden sämtliche Anforderungen der Fachbereiche auf bspw. Granularität der Daten, Abhängigkeit zu anderen Planungsbereichen, Timings und berühmten Sonderlocken hin überprüft. Die Anforderungen und Anpassungen verprobten wir immer wieder gegen den Prototypen. So gewann jeder Beteiligt zunehmend ein besseres Gefühl für das zukünftige Planungssystem. Gemeinsam analysierte man, was technisch einfach umzusetzen wäre und fachlich einen signifikanten Nutzen darstellen würde. Jeder Prozess, jede fachliche Anforderung, jede technische Änderung wurde auf diese Weise erst überprüft und danach als Anforderungen für das neue Planungssystem gemeinsam verabschiedet.

Jeder Prozess im Anforderungskatalog wurde auf die verarbeitenden Daten, die generierten Daten und die relevanten Merkmale und Attribute untersucht. Weiterhin wurde berücksichtigt, wer bzw. welche Gruppe von Personen wann und wo Daten ins System eingibt und welche Erwartungshaltung an welche vor- und nachgelagerten Planungsprozesse hat. Genau, d.h. zum Zeitpunkt des fertiggestellten Anforderungskatalog bzw. FitGap Dokumentes war bereits klar: „was, wie und wieso umgesetzt wird“.

Vom Prototyp zum produktivem System

Es folgte die Kür. Der Prototyp sollte nach erfolgreicher Anforderungsphase nun zu einem integrierten Planungssystem weiterentwickelt werden. Entwicklung, Testing und GoLive Vorbereitungen musste im Parallelbetrieb des Altsystem stattfinden.

Wir entschieden uns für den Aufbau einer komplett neuen Landschaft, d.h. wir haben mit frisch installierten Windows Servern gestartet. Zuerst installierten wir die IBM Landschaft – im Schwerpunkt TM1 bzw. PlanningAnalytics für die Finanzplanung. Danach entwickelten wir die Datenanbindungen an das SAP BW on Hana. Ladestrecken und Zyklen wurden fein justiert. Security und Workflow Konzepte umgesetzt. Load und Init Prozesse geschrieben. Wir versuchten so viele wiederverwendbare Standard zu schaffen, wie es nur irgendwie ging. Was in Phase 1 noch nach mehr Aufwand klingt, zahlt sich mit Phase 2 und weiteren Entwicklungen aus, weil es bereits den einen Prozess gibt, der allgemein gültig Daten von A nach B kopiert und eine standardisierte Prozesskette verwendet werden kann, die bspw. den Workflow korrekt schaltet.

Jede Iteration wurde mehrstufig und prozessual getestet. Die Fachbereiche wurden in die Verantwortung gezogen, sie kannten die Änderungen von Standorten, Kunden und Projekten schließlich besser und wussten viel schneller, wo sie bspw. nach einem Init hinzuschauen und etwas zu überprüfen haben.

GoLive Finanzplanung ohne lange Nächte

Trotzdem herrschte etwas Unbehagen im Projektteam, als wir die neue Lösung für die Finanzplanung live schalteten. Wir erwarteten für diesen Zeitraum ein erhebliches Supportaufkommen. Schließlich hatten wir eine vollkommen neue Lösung aufgebaut und ausgerollt. Einige sehr innovative Konzepte waren zum Einsatz gekommen, die direkten Einfluss auf die User Interfaces hatten. Trotzdem blieb es sehr ruhig. Wieso? Die intensiven Bemühungen, als man Anforderungen und Prototyp gegeneinander hielt, zahlten sich aus. Viele der Key User kannten bereits „ihren“ neuen Weg. Die neue Lösung war flexibler und schneller. Die Leute arbeiteten gerne mit dem System.

Fazit

Das Projekt war ein Erfolg. In Time und Budget abgeschlossen. Viele der Key User sind zufrieden und viele nachgelagerte Änderungen bzw. Change Request sind lediglich Konfiguration. Die Fehleranalyse durch Entwickler ist beträchtlich vereinfacht. Der Maintenance Aufwand konnte signifikant reduziert werden. Das schafft Ressourcen für neue spannende Projekte!