In 5 Schritten zum Release-Wechsel

Release-Wechsel wollen stets gut überlegt und geplant sein, um Ausfälle, Performance-Probleme und Funktionsfehler zu vermeiden. Eine beispielhafte Release-Wechsel-Vorbereitung zeigt der folgende Success Case unseres Kunden.

Support-Sicherheit dank neuer Version

Unser Kunde, ein großer, multinationaler Versicherungskonzern, nutzte die IBM Cognos TM1-Version 10.2.2, deren Support im Jahr 2019 eingestellt werden soll. Um die Sicherheit, Performance und Stabilität des Systems auch weiterhin zu gewährleisten und bei Systemfehlern auf Hersteller-Support zurückgreifen zu können, wollte unser Kunde auf eine neuere TM1-Version migrieren – in diesem Fall Planning Analytics 2.0. Um den Release-Wechsel perfekt vorzubereiten, haben wir unseren Kunden in den folgenden fünf Schritten unterstützt, wobei neben dem reinen Release-Wechsel auch neue Komponenten separat getestet wurden.

Schritt 1 – Evaluierung

Zuerst sollten die alte (hier TM1 10.2.2) und die neue Version (hier Planning Analytics) miteinander verglichen werden – welche Funktionen stimmen überein, welche Software-Komponenten müssen übernommen werden, welche sind überflüssig? Es bedarf hierfür einer genauen Vorstellung und Definition der eigenen Anforderungen. Im Falle unseres Kunden ging es konkret darum zu prüfen, ob es besser wäre, TM1 Perspectives und TM1 WEB zu übernehmen oder die neuen Planning-Analytics-Komponenten IBM Planning Analytics for Excel (PAX) und IBM Planning Analytics Workspace (PAW) in den Release-Wechsel zu integrieren.

Schritt 2 – Testvorbereitung

Zunächst gilt es zu definieren, welche Funktionen des bestehenden Systems mit dem neuen Release getestet werden sollen. Diese umfassen im Allgemeinen TM1-Grundfunktionen wie Anmelden, Navigation in den Cubes, das Ziehen von Ansichten in die Programme Excel und PDF, Security-Einstellungen und Verbindungstests zu den Datenquellen. Als Testinstanz wurde ein separater Server/VM verwendet, sodass die bestehenden Anwendungen nach wie vor zu Verfügung stehen.

Schritt 3 – Testing

Zum besseren Tracking wurden mithilfe der Testing-Software HP ALM das Release Planning Analytics Basis und Planning Analytics WEB basierend auf einer Reihe der definierten Test Cases getestet:

  • An- und Abmelden vom Server
  • Arbeiten mit aktiven Formularen
  • Arbeiten mit MDX und Subsets
  • Anlegen/Löschen von Dimensionen und Würfeln
  • Anlegen/Löschen von Prozessen
  • Anlegen/Löschen von Jobs oder Anwendungen
  • Funktionen kundenspezifischer Tools
  • WEB Performance

Im Rahmen des Wechsels zu Planning Analytics 2.0 (PA) wurden 87 von 87 Testfällen fehlerfrei getestet. Da die getesteten Module unabhängig von PAW und PAX waren, wurde die Empfehlung ausgesprochen, einen Release-Wechsel von TM1 V10.2.2. auf PA Basis und PA WEB V2.03 vorzunehmen. Die neuen Komponenten wurden daraufhin im folgenden Schritt getestet.

Schritt 4 – Prüfung der Integration neuer Software-Komponenten und Zusatzfunktionen

Die neuen Software-Komponenten PAX und PAW wurden anhand einer Funktionsliste in Excel getestet, da diese Tests nur von einem kleinem Team durchgeführt wurden. Bei den Tests wurden bestehende Probleme genauer analysiert und Lösungen gesucht. Beispielsweise wurde festgestellt, dass PAW nicht parallel zu Perspective arbeiten kann, da der Server sonst nur sehr langsam läuft. Eine Verteilung auf verschiedene Server kann dieses Problem lösen, aber aufgrund des damit verbundenen zusätzlichen Aufwands wurde dieses Projekt vorerst nicht umgesetzt. Es erfolgte dann eine Evaluation der Zusatzfunktionen wie das Chiffrieren von Logs und Datenbankdateien, um zu überprüfen, ob Planning Analytics reibungslos funktioniert. Dieser Test verlief erfolgreich, eine Produktivsetzung dieses Systems muss jedoch noch mit dem Security-Board des Konzerns abgestimmt werden.

Schritt 5 – Release-Wechsel-Planung

Nun kann festgelegt werden, wann genau der Release-Wechsel durchgeführt werden soll. Da BI-Systeme die Grundlage für die Arbeit vieler Unternehmensbereiche sind (z. B. Controlling), kann der Zeitpunkt nicht willkürlich gewählt werden, sondern muss so liegen, dass der Arbeitsausfall so gering wie möglich ist. Da TM1 bei unserem Kunden vor allem für die Arbeit des Controllings grundlegend ist, wurde besonderer Wert draufgelegt, dass der Release-Wechsel nicht mit Planungs- und Reporting-Phasen kollidiert.

Nun konnte der eigentliche Release-Wechsel beginnen – die Installation, Einrichtung und Konfiguration, welche in den vorherigen Schritten klar definiert wurden.

Herausforderungen beim Release-Wechsel

In jedem Projekt gibt es stets Risiken und Herausforderungen, die Sie mithilfe erfahrener Projektmitarbeiter reduzieren können. Im Falle eines Release-Wechsels sollten Sie auf folgende Stolpersteine achten:

  • Definieren Sie klare Rollenverteilungen und Ansprechpartner in den involvierten Abteilungen.
  • Planen Sie Zeit für die zahlreichen zeitintensiven, administrativen Tätigkeiten wie Dokumentation, Meetings und Abstimmungsprozesse ein.
  • Beachten Sie interne Prozesse und Vorgaben, z. B. zur Qualitätssicherung, die gerade für externe Dienstleister einen merkbaren Mehraufwand bedeuten können.
  • Identifizieren Sie IT-Herausforderungen, z. B. wenn das System nur mit einem bestimmten Server-Betriebssystem kompatibel ist.
  • Kommunizieren Sie kundenspezifische Herausforderungen, z. B. wenn bestimmte Firewall-Einrichtungen erforderlich sind.
  • Ziehen Sie gegebenenfalls einen Umzug auf neue Server in Betracht, wenn Ihre bereits ein bestimmtes Alter erreicht haben.
  • Erfragen Sie, ob Release-Wechsel anderer Software-Komponenten geplant sind, die kombiniert den Testaufwand reduzieren können (z. B. Betriebssysteme etc.).

Erfahrene Projektmitarbeiter und Standardvorgehen können Ihnen in solchen Fällen unterstützend zur Seite stehen und den Projekterfolg positiv beeinflussen. Wenn Sie mehr darüber erfahren möchten, kontaktieren Sie uns. Wir sind gern für Sie da.

By | 2019-01-23T09:07:05+00:00 23. Januar 2019|Categories: BI Success|