SAP-Lösungen sind für ihre Langlebigkeit bekannt. Erfahrene IT-Leiter kalkulieren mit einer Nutzungsdauer von weit über zehn Jahren. Aufgrund der kontinuierlichen Weiterentwicklung der SAP-Lösungen ist jedoch nach einigen Jahren ein Releasewechsel sinnvoll. Bei einer solchen, nicht zum Tagesgeschäft gehörenden Sondermaßnahme stellt sich naturgemäß die Frage, inwieweit professionelle Unterstützung notwendig ist.
Manche Unternehmen führen in Eigenregie SAP-R/3-Releasewechsel durch. Dabei laufen sie Gefahr, dass es zu Kapazitätsengpässen kommt, die Systeme überfordert werden, Antwortzeiten unerträglich lange geraten und Arbeitsprozesse zu blockieren drohen. Mit der SAP-Releasestrategie steht dagegen ein professionelles Solution Management über erfahrende externe Berater zur Verfügung. Es schließt eine mehrfache Assistenz ein: Zunächst geht es um die rein technische Umsetzung, darüber hinaus aber um ein umfassendes Projektmanagement und Projektcoaching mit dem Service für effiziente Anpassungsleistungen einschließlich der Schulung der Anwender.

Leistung und Einstellungen überprüfen

Zwei Monate vor der geplanten Systemumstellung setzt mit dem von SAP standardmäßig angebotenen Service GoingLive Functional Upgrade Check die SAP-Releasestrategie ein. Der GoingLiveService umfasst eine Bestandsaufnahme jeweils vor und nach dem Releasewechsel. Die erste Phase hat zum Ziel, die Kunden vorab individuell auf den Wechsel vorzubereiten. Im Rahmen einer Analyse wird mit dem Service geprüft und dokumentiert, ob die Performance auf Basis der vorhandenen Hardware und Anwenderdaten erhalten bleibt, wenn sich der Releasestand und damit eventuell die Anforderungen ändern. Schwerpunkte hierbei sind Systemauslastung und Antwortzeiten. Ein Plausibilitätscheck gilt der Hardware, dem Betriebssystem, den Datenbanken sowie der Workload, also den systembezogenen Funktionen und Arbeitsbelastungen der betroffenen Mitarbeiter.
Die Prüfergebnisse münden in Empfehlungen für die Basiseinstellungen der Datenbank, des Betriebssystems und der SAP-Lösung. In einem Upgrade-Zeitplan wird Schritt für Schritt die Abfolge der durchzuführenden Maßnahmen festgehalten sowie die Updates von Betriebssystem oder Datenbank definiert.

Neues Release testen, Anwender schulen

Die nächste Phase betrifft den technischen Upgrade. Zunächst wird das Testsystem unter Berücksichtigung des neuen Release aufgebaut. Dieses wird auf die Kundenanforderungen, auf Modifikationen und Eigenentwicklungen angepasst. Ein sensibler und iterativer Vorgang, der eine Reihe von Test- und Sicherungsläufen erfordert, bis die kundenspezifischen Modifikationen und die dazu notwendigen Schnittstellen wie gewünscht umgesetzt sind. Für den eigentlichen Releasewechsel ist genügend Pufferzeit einzuplanen, um eventuelle Ausfallzeiten abzufangen. Steht dann das Testsystem und läuft es sicher, so erhalten auch die ersten Anwender die Möglichkeit, sich schulen zu lassen, um frühest möglich mit der Lösung vertraut zu werden.
Hat also das Testsystem die Vorgaben erfüllt, wird diese neue Konfiguration in das Produktivsystem überspielt. Die Vorbereitungsphase ist abgeschlossen, der eigentliche Releasewechsel erfolgt. Dabei stehen grundsätzlich zwei Strategien zur Auswahl. Entweder werden die Ausfallzeit oder die Systemressourcen so gering wie möglich gehalten, was die Kunden beziehungsweise Anwender zu entscheiden haben. Möglichst kurze Ausfallzeiten sind durch eine Dopplung oder Spiegelung des Produktivsystems zu erreichen, was natürlich einen erhöhten Bedarf an Systemressourcen erfordert. Hier bleibt der Betrieb des Altsystems während des parallel betriebenen Upgradings ungestört. Das Neusystem wird in einem relativ kurzen EinspieIvorgang live geschaltet. Ressourcen schonender, aber mit zwangsläufig längeren Ausfallzeiten erweist sich ein schrittweises Upgrading des Produktivsystems mit den neuen Systemkomponenten. Die gesamte Prozesslaufzeit eines SAP-R/3-Upgrades ist ferner abhängig von Faktoren, wie etwa der verwendeten Hardware, der installierten “Geschäftssprache”, der Anzahl der Mandanten, dem Umfang der Eigenentwicklungen sowie den Modifikationen an SAP-Standardtabellen, der Add-On-Software und der Integration von Support Packages.
Sollte ein Releasewechsel beim Kunden mit einem Austausch der Hardwareplattform, etwa von UNIX auf Windows, verbunden sein, so ist nicht zu empfehlen, beides zeitgleich durchzuführen. Eine stufenweise Vorgehensweise erscheint auch hier als der sichere Weg. Der Releasewechsel der Software sollte hierbei nach dem Wechsel der Hardwareplattform erfolgen, um im Fall von Problemen die Ursache besser lokalisieren zu können.

Eigene Anforderungen umsetzen

Vier Wochen nach erfolgtem Releasewechsel steht dann im Rahmen einer weiteren Verifikation des GoingLive-Service der Releasewechsel abschließend auf dem Prüfstand. Die Performance nach dem Upgrade wird gemessen und mit dem Zustand davor verglichen. Die Basiseinstellungen von SAP R/3 sind zu prüfen. Der Kunde erhält einen Bericht mit Empfehlungen, wie sich seine SAP-Lösung weiter optimieren lässt, um mit den vorhandenen Ressourcen die optimale Leistung zu erzielen.
Es wäre ein Irrtum anzunehmen, von Release zu Release müssten die zur Verfügung stehenden Hardware-Ressourcen praktisch “naturgemäß” exorbitant ausgebaut werden. Ganz im Gegenteil: Der Ressourcenmehrbedarf ist abnehmend. Beim SAP Release 4.0B (im Vergleich zu Release 3.1I) war noch ein Mehrbedarf von 30 Prozent bei CPU und RAM auf den Applikationsservern sowie fünf Prozent auf Seiten des Datenbankservers nötig. Der Releasewechsel von SAP R/3 4.6c auf SAP R/3 Enterprise erfordert hingegen üblicherweise nur rund fünf Prozent Mehrbedarf bei CPU, RAM (Applikationsserver) und DB-Server.