Countdown für R/3-Upgrade

29.10.2003
Von 
Vice President Software & SaaS Markets PAC Germany

Dagegen können sich Nutzer neuerer Versionen wie etwa 4.6B zurücklehnen. Ihre Hardwareausstattung sollte für das aktuelle Release ausreichen. Wer die Unicode-Option von R/3 Enterprise freischalten will, muss für die Datenbank 90 bis 110 Prozent mehr Plattenplatz reservieren. Die Zahlen stammen zwar vom Hersteller, laut Unilog decken sie sich aber mit eigenen Erfahrungen in Kundenprojekten.

Doch selbst wenn die Systemvoraussetzungen für R/3 Enterprise erfüllt sind, bleiben Fragen offen. Wie sollen Firmen mit ihren kundenspezifischen Erweiterungen verfahren? Viele Anwender haben zusätzliche Funktionen in ihre R/3-Systeme eingefügt, auf die sie auch nach einem Upgrade nicht verzichten wollen. SAP hat hierzu mit "Modification Assistant" ein Tool entwickelt, das es Kunden erlaubt, Erweiterungen, sprich Abweichungen vom Standardsystem, zu identifizieren. Diese lassen sich nach dem Release-Wechsel in die veränderte ERP-Umgebung integrieren. Zudem können Experten mit dem Werkzeug feststellen, ob sie ihre eigenen Entwicklungen aufgegeben können, weil sie nun vom Funktionsumfang des Ziel-Release abgedeckt werden. SAP spricht hierbei vom "Zurückführen in den Standard".

Was sich so leicht anhört, ist in der Praxis jedoch keineswegs trivial, warnt Unilog. So muss jede Modifikation nach dem Upgrade getestet werden, was das Migrationsprojekt beträchtlich in die Länge zieht. Auch das Zurückführen von Erweiterungen in den Standard lässt sich nicht per Knopfdruck bewerkstelligen, da Anwender genau prüfen müssen, ob die neuen R/3-Funktionen die selbstentwickelten Features wirklich adäquat ersetzen.

Bevor Firmen sich mit dem Thema Modifikationen beschäftigen, sollten sie zunächst ermitteln, ob überhaupt alle ihre kundenspezifischen Anpassungen noch brauchen. Unilog hat mit "R/3 Analyzer" ein Tool gebaut, mit dem sich ungenutzte Erweiterungen ausfindig machen lassen. Ein Kunde habe auf diese Weise herausgefunden, dass 60 Prozent seiner 4500 R/3-Modifikationen eigentlich überflüssig sind. Ein ähnliches Werkzeug bietet die Firma Axantis AG aus Stuttgart mit "U:R for U" an.

Wie die Anwender die Downtime minimieren

Release-Wechsel sind für Firmen nicht zuletzt deshalb unangenehm, weil sie mit einem Stillstand von R/3 und damit den Kernprozessen des Unternehmens verbunden sind. Anwender sind darauf bedacht, die Auszeit kurz zu halten und das Einspielen der neuen Software beziehungsweise den Übergang vom Test- zum Produktionssystem möglichst an einem Wochenende abzuwickeln. Prinzipiell ist das auch machbar, meinen Experten und verweisen auf Erfahrungswerte. So nimmt die Umstellung von R/3 4.5B auf R/3 Enterprise bei einer Datenbankgröße von 130 bis 270 Gigabyte zwischen sieben und 30 Stunden in Anspruch.

Nach Angaben von Ralf Strassner, Rollout Manager für R/3 Enterprise bei SAP, beeinflusst die Größe der Datenbank die erzwungene Pause nicht wesentlich: "Die Übertragung der Daten nimmt nicht so viel Zeit in Anspruch, die Downtime hängt viel mehr davon ab, wie viele Veränderungen in den Datenstrukturen vorzunehmen sind." Darüber hinaus können die Anwender die Länge des Systemstillstands selbst beeinflussen: Die Upgrade-Werkzeuge der SAP gestatten es dem Administrator, zu wählen, ob der Umstieg auf R/3 Enterprise mit möglichst wenig Hardwareressourcen ("Resource minimized") oder mit der geringstmöglichen Stillstandszeit ("Downtime minimized"), dann aber mit viel Hardware-Power, stattfinden soll. Unilog-Experten zufolge lässt sich mit der zeitoptimierten Option die Downtime halbieren.

Im Modus Downtime minimized richtet das Upgrade-Tool eine Schatteninstanz zum bestehenden R/3-System auf einem separaten Rechner ein, auf dem ein temporärer Web Application Server läuft. Er ist die Ablaufumgebung von R/3 Enterprise. Im nächsten Schritt wird das Repository des Schattensystems aktiviert. Zu diesem Zeitpunkt findet auch der Modifikationsabgleich statt. Danach kann der Anwender das gesamte Altsystem herunterfahren und auf die Schatteninstanz migrieren. Während dieser Phase passt das Werkzeug die Datenstrukturen an.

Die Resource-Optimized-Methode kommt dagegen ohne zusätzlichen Server aus. Sie benötigt zum Upgrade nur Teile der Schatteninstanz, die auf dem Produktivsystem eingerichtet werden.