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

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.

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-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.

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.

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.