Versionsupgrade EPM – was ist zu bedenken?

Kunden sprechen uns regelmäßig an mit der Frage: Sollen wir nun Upgraden oder nicht?
Abgesehen von den betriebsinternen Regeln, die diese Frage beantworten, ist es für uns Berater oft schwierig, dem Kunden die beste Empfehlung zu geben. Soll man upgraden und wenn ja, wann, und auf welche Version?

Ein Versionsupgrade kostet Geld, Zeit und oft Wohlwillen der Benutzer. Schnell kommen weitere Überlegungen hinzu: Soll man bestimmte Dinge anders einrichten, welche neue Funktionalität könnte direkt ausgerollt werden, sollte man auf neue Hardware portieren, oder virtualisieren, usw.

Die Annahme: „Ein Upgrade der Version, was ist das schon? Einfach drüber installieren und fertig!“ ist aus meiner Erfahrung nicht empfehlenswert bzw. wird gar nicht funktionieren. Denken Sie nur an die Integration von Oracle BI und Oracle EPM, Produkte werden auf einmal gemeinsam administriert, es gibt neue Produkte, andere fallen weg, bekannte Produkte erhalten neue Funktionalität, die nicht sichtbare, darunterliegende Architektur ändert sich, etc.! Da gab es schon verschiedene unangenehme Überraschungen.…

Daher empfehle ich immer, ein Versions-Upgrade als Projekt zu planen, auszuführen und zu betreuen.

Ein guter Projektplan sollte auch auf die folgenden Fragen eine Antwort geben:

Welche Version?
Je früher auf eine neue Version migriert wird, desto länger dauert es, bis diese nicht mehr unterstützt wird. Auf der anderen Seite empfehle ich, erst zu migrieren, wenn das erste Patch dazu verfügbar ist. Hier sind dann erfahrungsgemäß viele bekannte Kinderkrankheiten behoben.

Man sollte aber immer prüfen, wie lange eine Version noch unterstützt wird oder es einen Extended Support zu dieser Version gibt.

In der Projekt-Vorbereitung sollte auch deutlich werden, ob alle internen und externen Software- Komponenten noch unterstützt werden. Zum Beispiel bedeutet der Wegfall der Hyperion Business Rules in 11.1.2.x einen sehr viel größeren Aufwand für die Umstellung auf Calc Manager-Rules.
Wichtig zu erfahren ist auch, welche Betriebssystem-softwar künftig ausgerollt wird. Der Upgrade eines Webbrowsers oder einer Microsoft Office-Version kann bestimmend sein, welche Version der EPM-Software verwendet werden soll.

Es sollte auch geklärt werden, ob es Änderungen in der Software-Architektur gab und die aktuelle Hardware noch ausreicht.

Welche Reihenfolge?
In der Regel gibt es eine Entwicklungs-, Test- und Produktionsumgebung, alle mit ein- und derselben Version. Es ist logisch, mit der Entwicklungsumgebung zu beginnen und dort auch den Testplan durchzuführen.

Möglicherweise fallen bei der Migration Probleme auf, für diese können Lösungen gefunden und auf der Test- und Produktionsumgebung angewendet werden.

Es gibt Vorteile, wenn die neue Version auf neue Hardware installiert werden kann, in dieser Konstellation können die Versionen eine Zeitlang parallel betrieben werden. Wir sprechen dann aber von einer Migration und einem Upgrade.

Es kann auch bei der Produktionsmaschine angefangen werden. Hier können oft viel mehr Ressourcen zum Testen aktiviert werden in einem Parallelbetrieb als das dieses auf der Testumgebung der Fall wäre. Dann steht die Funktionalität mehr im Blickpunkt und weniger die Technik.

Was Testen?
Das Testen sollte das Risiko auf unbekannte Produktfehler oder Inkompatibilität deutlich verringern, mit der Möglichkeit, im Vorfeld eine Lösung dafür zu finden und umzusetzen.

Wurden Applikationen in die neue Version gebracht, wird es Zeit, den Testplan auszuführen. Der Schwerpunkt der Testaktivitäten sollte besonders auf sehr spezifischen Funktionen und Nutzungen der existierenden Applikation liegen. Das kann ein sehr spezifische Zuweisung von Rechten sein oder ein nicht alltäglicher Treiber für Datenbanken. Wir können annehmen, dass die 08/15 Funktionalitäten bei der Qualitätskontrolle von Oracle getestet wurden.

Die neue Funktionalität, wenn sie nicht unbedingt sofort genutzt werden soll, kann im späteren Kontext entwickelt und getestet werden.

In den Test sollten auf jeden Fall die Frontend-Tools mit aufgenommen werden. Wenn es hier Probleme gibt, sind die Auswirkungen (wegen der Außenwirkung) meist größer und die Work-Arounds meist schwieriger.

Bei den Tests kann auch direkt eine End-User-Dokumentation erstellt werden, die den Benutzern später an die Hand gegeben wird.

Wann anfangen?
Ein Versionsupgrade fängt mit einer gründlichen Planung an. Ein Projektplan, Testplan und gute Kommunikation gehören hierzu. Dann ist eine günstige Periode auszuwählen, in der die Produktionsapplikation weniger genutzt wird, also außerhalb der Zeiten für die Jahresplanung oder den Monatsabschluss. Es sollte aber nicht unbedingt in der Urlaubszeit stattfinden, wo es generell weniger Ressourcen gibt, um die Arbeiten auszuführen.

Ferner sollten auf der Entwicklungsumgebung auch keine großen Releases geplant sein, denn diese Umgebung wird eine Zeitlang für keine anderen Tätigkeiten als den Versionsupgrade verfügbar sein.

Weitere Informationen zum Life-Time Support finden Sie hier: http://www.oracle.com/us/support/library/lifetime-support-applications-069216.pdf