Herausforderung Releasewechsel

Seit der Einführung des SAP ERP 6.0 2006 wird die ERP-Anwendung im Rahmen ihrer aktuellen Releasestrategie funktional nur durch sogenannte Enhancement Packages (EHP) erweitert. Neben der üblichen Wartung durch Support Packages hat SAP mit den SAP Enhancement Packages ein Erweiterungskonzept geschaffen, das einerseits für Stabilität bei bestehenden Funktionen sorgt und andererseits einen vereinfachten und selektiven Zugang zu neuen Funktionen ermöglicht. Dabei ist durch den Einsatz der Switch-Framework-Technologie sichergestellt, dass es keine funktionalen Änderungen bei der Installation gibt. Es gibt viele Gründe, warum sich SAP-Kunden für einen Releasewechsel entscheiden, die zwei gängigsten sind: 

• auslaufende Wartungsverträge, insbesondere bei Kunden mit SAP Release < ERP 6.0 und dadurch bedingt erhöhten Aufwänden bei den Wartungskosten
• funktionale Erweiterungen und Improvements, die mit den EHPs eingeführt werden

Die Berater von noventum consulting sind für einen internationalen Energiekonzern mit der Einführung eines Customer Templates bzw. Neuaufbau der aktuellen SAP-Systemlandschaft bereits seit >7 Jahren mit der SAP-Technologieberatung durchgehend beauftragt. In diesem Kontext und für den nachfolgend betrachteten Releasewechsel unterstützen 3 Berater Vollzeit an der konkreten Umsetzung (Konzeption, Teilprojektleitung, Realisierung und Dokumentation) seiner SAP-Releasestrategie.

Software Lifecycle Management für internationalen Energiekonzern

Das Change Board des Konzerns hatte die Vorgaben gemacht: Sämtliche SAP-Systeme sollten alle 2-3 Jahre gemäß den Anforderungen aus den Fachbereichen mit dem jeweils aktuellen Enhancement Package bzw. ERP-Release aktualisiert werden. Die Service Level Agreements für das konzernweite ERP-Projekt waren die Grundlage dieser Entscheidung.

Upgrades dieser Qualität sind notwendig, um 

• allgemeine System Bugs zu beheben
• neue Funktionalitäten zu ermöglichen
• das SAP-System softwaretechnisch auf einem aktuellen Stand zu halten
• vollständig konform zu den Wartungsempfehlungen des Herstellers (SAP) zu sein.

Mit der Software wechselt oft die Hardware

So wie bei der Software sind die Hardware bzw. die den SAP-Systemen zugeordneten Hardwareressourcen einem definierten Wartungszyklus bzw. Hardware Lifecycle Management unterworfen. Im Allgemeinen benötigen neue SAP-
Releases neben höheren Storageanforderungen ebenfalls eine größere Dimensionierung bzw. ein Sizing der Applikationsserver. So liegt es nahe, derartige Implementierungsprojekte ebenfalls in Abstimmung mit den Hardware-Austauschzyklen zu koordinieren und im Kontext eines ganzheitlichen IT Lifecycle Managements zu behandeln.

Auch wenn SAP, wie bspw. in der SAP Note 1723135 – Ressourcenbedarf für SAP ERP Central Component 6.0 EHP6, eine vergleichsweise geringe Erhöhung der Hardwareressourcen (Prozessor, Speicher, Storage) ohne Aktivierung der Business Functions ~0-5 % schätzt, zeigen die Erfahrungen aus diversen EHP-Implementierungen, dass der Ressourcenbedarf durchschnittlich erheblich höher liegt. In der nachfolgend exemplarisch betrachteten EHP 7-Implementierung lagen die durchschnittlichen Dialog-Antwortzeiten bei gleichbleibender Hardwareausstattung ~20 % über denen vor dem Upgrade.

EHP 7-Implementierung

Im Zuge der Implementierung eines EHP-Upgrades unterscheidet man zwischen: 

Technischem Upgrade

• der Fokus liegt auf dem rein technologischen Upgrade
• keine Änderung der Standardfunktionalitäten
• keine Änderung bei den Modifikationen

 

Funktionalem Upgrade

• Rückführung von kundenspezifischen Modifikationen zum SAP-Standard
• neue Funktionalitäten können via Switch Framework bei Bedarf aktiviert und im Zuge des technischen Upgrades eingeführt werden

Im Rahmen der Projektplanung müssen sowohl einige Grundabhängigkeiten als auch die gängige Zielkonkurrenz des magischen Dreiecks (Zeit, Kosten, Qualität > Projektmanagement) mit der Erwartungshaltung des Kunden bzw. Endanwenders definiert und abgestimmt werden. In diesem EHP 7-Projekt ergaben sich die folgenden Schwerpunkte:

Technisch

Bedingt durch die Interoperabilität des ECC- und HCM-Systems und z.B. deren Datenaustausch (via  ALE bzw. RFC) resultierte für den produktiven technischen Upgradeprozess, dass dieser gleichzeitig bzw. am gleichen Wochenende erfolgen musste. Zudem ergaben sich natürlich auch Abhängigkeiten für das Fallback-Szenario (dazu im Folgenden mehr).

Da gewisse Funktionaltäten und Kompatibilitäten zu weiteren SAP-Systemen (Portal, BI, Solution Manager, Business Connector, usw.) sowie anderen externen Systemen (MS Biztalk, xFlow, usw.) geprüft werden mussten, vergrößerte sich der Testaufwand entsprechend. In diesem Zusammenhang wurde entschieden, auch das SAP-Portal von 7.0 auf SAP Netweaver 7.4 upzugraden.

Die ursprünglich 5 Systemlandschaften (Sandbox, Development, Quality, Pre-Production und Production) pro SAP-Lösung  (ECC, HCM, Portal) wurden jeweils erweitert durch ein temporäres Entwicklungssystem (MxC siehe  Abb .1), um während der ‚Freezing Period‘ sogenannte Notfalltransporte zu ermöglichen (s.u. „Laufende Entwicklung und Projekte“).

Ressourcen

Folgende Ressourcen, die an dem Projekt von der Konzeptionsphase über die Implementierung und die verschiedenen Testphasen beteiligt waren, mussten eingeplant und verteilt werden:

Projektmanagement, IT-Team, Key User, modulbezogene Fachteams (FI, PP&L, HCM), Berechtigungsteam, ABAP-Team, usw.

Laufende Entwicklung und Projekte

Laufende Entwicklungen mussten bis zum Upgrade des Entwicklungssystems abgeschlossen sein. Danach startete für 3 Monate eine sogenannte ‚Freezing Period‘ (auch „Frozen Zone“), in der keine neuen Entwicklungen oder Änderungen durchgeführt werden sollten. Eine Ausnahme bildeten Notfalltransporte, die zur Behebung von schwerwiegenden Fehlern im operativen Betrieb implementiert werden konnten. Neue Projekte oder Entwicklungen durften erst nach dem Go-Live des EHP 7-Releasewechsels gestartet werden.