Computerwoche-Serie

SAP-Migration Teil 2: Neun Regeln für den SAP-Wechsel

08.11.2007
Von Thomas Fellger
SAP-Anwender sind unter Zugzwang. Nach dem Ende der Standardwartung für R/3 4.6C steht vielen ein Upgrade auf SAP ERP 6.0 bevor. Wird die Migration sorgfältig geplant, ist der Wechsel einfacher als befürchtet.

Etwa 39 Prozent der traditionell im Frühjahr von der Deutschsprachigen SAP-Anwendergruppe (DSAG) befragten Unternehmen beabsichtigen, auf die aktuelle ERP-Version der SAP umzusteigen. Gespräche mit Kunden bestätigen das wachsende Interesse an SAP ERP 6.0 (früher: Mysap ERP 2005). Allerdings herrscht unter den Anwendern nach wie vor ein gewisses Unbehagen, da sie Aufwand und Risiko des Umstiegs nicht richtig einschätzen können. Erste erfolgreiche Upgrade-Projekte belegen jedoch, dass die Scheu unbegründet ist.

Auf das Wesentliche konzentrieren

Damit der Wechsel auf SAP ERP 6.0 gelingt, sollten die einzelnen Schritte sorgfältig aufeinander abgestimmt werden.
Damit der Wechsel auf SAP ERP 6.0 gelingt, sollten die einzelnen Schritte sorgfältig aufeinander abgestimmt werden.

Die erste und vielleicht wichtigste Regel im Vorfeld der Planung lautet: Konzentration auf das Wesentliche. Dies klingt zunächst ein wenig abgedroschen. Im Kontext von SAP-Vorhaben kann man es jedoch nicht häufig genug wiederholen. Das beginnt bereits mit unsauberen Begrifflichkeiten im Vorfeld eines SAP-ERP-6.0-Projekts. Vielfach wird der Begriff Migration verwendet, obgleich es sich im Prinzip nur um ein Upgrade mit einem weitaus geringeren Aufwand handelt. Eine Migration beinhaltet dagegen stets die Umstellung auf eine neue Technik. Das bedeutet beispielsweise, dass Datenformate umgewandelt oder grundlegende Software ausgetauscht werden müssen. Im Vergleich dazu bezeichnet ein Upgrade den Umstieg auf eine neue Version einer Software, die zusätzliche Funktionen enthält.

Diese Unterscheidung mag akademisch klingen, nimmt den SAP-ERP-6.0-Vorhaben jedoch die gefühlte Brisanz. Denn in der Mehrzahl der Fälle sollte man hier von einem Upgrade sprechen. Dabei lassen sich im Grundsatz drei Upgrade-Konzepte unterscheiden:

  • Technische Upgrades,

  • funktionale Upgrades,

  • strategische Upgrades.

Wie der Name nahelegt, erneuert der technische Release-Wechsel den technischen Unterbau, während ein ergänzendes funktionales Upgrade bereits genutzte Anwendungsfunktionen aktualisiert und gegebenenfalls frühere Modifikationen wieder auf den Standard zurückführt. Ein strategisches Upgrade beinhaltet die erstmalige Einführung neuer Funktionen und Komponenten wie des neuen Hauptbuchs, die zugleich organisatorische Änderungen nach sich ziehen.

Einen Upgrade-Fahrplan aufstellen

Anwender, die langfristig SAP als ERP-Lösung einsetzen möchten, werden um einen Release-Wechsel nicht herumkommen. Die entscheidende Stellgröße zur Bestimmung des Zeitpunkts bildet die Vertragssituation. Das letzte R/3-Release, welches mit einem klassischen SAP-R/3-Wert- beziehungsweise Volumenkontrakt lizenzierbar ist, ist SAP R/3 Enterprise (SAP R/3 4.7). Ab Mysap ERP 2004 müssen die Anwender neue Lizenzverträge abschließen. Obwohl SAP dabei Altverträge mit anrechnet 2007 sind das noch 45 Prozent eines R/3-Wertkontrakts , liegen die Kosten für den neuen Lizenzvertrag höher als die anfallenden Wartungskosten im Rahmen der Altverträge. Abwarten bietet jedoch keine wirkliche Alternative: Denn neben dem Nachteil, dass R/3 definitiv nicht weiterentwickelt wird, reduziert sich die Anrechnungsrate von Altverträgen mit jedem weiteren Jahr, während sich die Wartungsgebühren weiter erhöhen.

Upgrade-Checkliste

  • Konzentration auf das Wesentliche.

  • Nicht vom wohlklingenden SAP-Marketing (Business Process Platform, Enterprise SOA u.ä.) blenden lassen: Der Umstieg auf SAP ERP 6.0 ist ein ganz normaler Release-Wechsel.

  • Mit technischem Release-Wechsel das Fundament legen, um im Anschluss mit Change-Request-Projekten neue Funktionalitäten einzuführen.

  • Überzeugungsarbeit in den Fachabteilungen: Deren Hilfe ist für den Projekterfolg entscheidend.

  • Überzeugungsarbeit im Topmanagement: geeigneten Projektsponsor gewinnen (kann für Motivationsschub beziehungsweise Prioritätenklärung sorgen).

Umstieg richtig planen

Ist die lizenzrechtliche (Übergangs-)Situation geklärt, steht die Planung an. Das vorrangige Ziel lautet dabei, bestehende Funktionalität unter dem neuen Release lauffähig zu halten sowie Modifikationen in den Standard zurückzuführen. Erst wenn dieses Fundament liegt, ist der Weg frei, sich intensiver mit zusätzlichen Funktionen und Gestaltungsspielräumen für Geschäftsprozesse auseinanderzusetzen.

SAP-Upgrade die Vorarbeiten

  • Detaillierte Bestandsaufnahme einleiten (Projekte, Ressourcen, Abhängigkeiten, etc.).

  • Systemumgebung (SAP GUI, Datenbank, Betriebssystem etc.) aufnehmen.

  • Transportqueue bereinigen, das heißt offene Transporte produktiv setzen oder ablehnen.

  • Zusätzliches Release-Wechselsystem installieren.

  • Zusätzlichen Bedarf an Systemressourcen prüfen.

SAP-Bestand aufnehmen

Eine solide Planung im Vorfeld des eigentlichen Projekts legt die Basis für den späteren Upgrade-Erfolg. Hierzu zählt zuerst eine Bestandsaufnahme der aktuellen SAP-Landschaft. Neben dem Auflisten der Release-Stände wie beispielsweise SAP Kernel, SAP GUI, Betriebssystem und Datenbank gehört dazu ebenso das Erfassen der SAP-bezogenen Modifikationen, Schnittstellen und Eigenentwicklungen. Insbesondere die Abweichungen vom SAP-Standard beeinflussen den zeitlichen und personellen Aufwand eines technisch angelegten Release-Wechsels. Leider ist es die Regel, dass diese firmenspezifischen Eigenarten einer SAP-Installation nur unzureichend dokumentiert sind. Dass die früheren Entwickler das Unternehmen wahr-scheinlich schon verlassen haben, macht die Ausgangslage nicht einfacher. Im Vorgriff auf den eigentlichen Release-Wechsel ist es daher angebracht, zunächst die Änderungen konsequent zu dokumentieren.

SAP-Upgrade Projektplanung

  • Meilensteine definieren.

  • Ausreichend Tester aus den Fachabteilungen gewinnen.

  • Fachbereiche so früh und intensiv wie möglich testen lassen (genügend Zeit für Korrektur einplanen).

  • Zeitaufwand für Unicode-Umstellung nicht unterschätzen.

  • Sehr gute Entwickler für SPDD-/SPAU-/SPAM-Abgleich auswählen.

  • Sehr gute Entwickler für Rückführung Modifikationen, Anpassung Eigenentwicklungen etc. auswählen.

  • Ausreichend Programmierkapazitäten für Unicode-Umstellung einplanen.

Aufwand abschätzen

Mit diesem Wissen lässt sich der Aufwand für das technische Upgrade abschätzen. In einer bis dato noch groben Meilenstein- und Zeitplanung werden die einzelnen Projektschritte einschließlich der notwendigen Systemressourcen sowie Skills festgeschrieben und gegebenenfalls neue Hardware für ein temporäres Release-Wechselsystem (Upgrade Sandbox) beschafft. Im Anschluss sollten sich die SAP-Anwender an den Modifikationsabgleich machen. Die Werkzeuge und Transaktionen der Abap-Workbench SPAM (SAP Patch Manager) oder SPAU/SPDD helfen, die Unterschiede bei Support Packages und Objekten zwischen den Releases transparent zu machen.

SAP-Upgrade - Modifikationen

  • Je weniger Modifikationen, umso einfacher der Releasewechsel.

  • Ursprüngliche Entwickler der Modifikationen frühzeitig einbinden.

  • Modifikationen gut dokumentieren.

  • Chance zur Rückführung der Modifikationen konsequent nutzen.

  • Mit neuen Erweiterungstechniken (Explicit & Implicit Enhancementspoints, neue BAdIs, BTEs etc.) ergeben sich neue Möglichkeiten.

Die vollständige Transparenz ist gerade im Falle des SAP-ERP-6.0-Upgrades unabdingbar, da der Hersteller mit dem neuen Release eine Abkehr von den gewohnten Anpassungsmöglichkeiten einläutet. An die Stelle von User-Exits, Customer-Exits, BAdIs (Business Add-ins) oder BTE (Business Transactions Events) tritt mit dem Enhancement Framework ein neues Erweiterungskonzept. Damit verbindet SAP das Ziel, die nicht Upgrade-fähigen Modifikationen künftig durch ein modifikationsfreies Einfügen von Programm-Sourcen sowie Variablen- und Parameterdeklarationen in den SAP-Standard zu versetzen. Mit den Kernel-BAdls zur Realisierung von Zusatzfunktionen wird eine zusätzliche Add-in-Technik eingeführt, die in das Switch-Framework integriert ist. Diese Schaltertechnik soll eine schnellere Erweiterung erlauben als der traditionelle BAdIs-Weg.

Inhalt dieses Artikels