Etwa 39 Prozent der traditionell im Frühjahr von der Deutschsprachi-gen 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.

Am Standard orientieren

Der von SAP eingeschlagene Weg, wie künftig mit Modifikationen umgegangen wird, folgt strikt der Strategie, Änderungen am Standard Release-fähig zu halten. Zwar werden User Exits und die klassischen BAdls zunächst weiter unterstützt. In der Regel bietet es sich für die Firmen aber an, mit dem Umstieg die Chance zur Rück-führung ihrer Veränderungen und Modifikationen in den Standard zu ergreifen.

Die damit anfallende Arbeit darf indes nicht unterschätzt werden, weil gerade an dieser Stelle die Tücke im technischen Detail liegt. Wie gewohnt liefert SAP ein umfangreiches Informationsangebot an Checklisten und technischen Release-Notes, die bei konkreten Problemen schnell zu einem wahren "Hinweis-Hindernislauf" führen.

Zusatzaufgaben einplanen

Zwei Aspekte geben dem SAP-ERP-6.0-Upgrade ein besonderes Gesicht: die Einführung des "SAP Solution Managers" und die Unicode-Umstellung. Wer in seinem SAP-System mehrere Zeichensätze verarbeiten muss, sollte insbesondere den Umstieg auf Unicode nicht hinauszögern. Denn die bislang von SAP gebotenen Lösungsansätze Blended-Codepage-Systeme und Multiple Display Multiple Processing (MDMP) werden in dem neuen Release zwar noch unterstützt. Dies geschieht aber in einem eher geduldeten Modus. SAP übernimmt folglich bei Problemen keine Verantwortung. Die Migration hier haben wir es wirklich mit einer Migration zu tun ist noch aus einem weiteren Grund empfehlenswert: Da es im Rahmen der Upgrade-Vorbereitung ohnehin notwendig wird, die eigene SAP-Umgebung grundlegend unter die Lupe zu nehmen, lassen sich die in-folge der Unicode-Einführung erforderlichen Anpassungen quasi gleich mit analysieren und mit den Upgrade-Arbeiten kombinieren. Ein solches abgestimmtes Vorgehen besitzt den Vorteil, dass nur ein einmaliger Testaufwand anfällt.

Die Einführung des SAP Solution Managers ist wiederum ratsam, da das Tool künftig als einzige Instanz für den Bezug von Wartungs-Updates dient. Mitarbeiter im SAP-Betrieb sollten sich insbesondere mit der Maintenance-Optimizer-Funktion des Werkzeugs vertraut machen, die ei-nen zentralen Zugang zu allen Aktivitäten im Rahmen des Software-Lifecycles (insbesondere des Software-Updates) bietet. Der Ausbau des Werkzeugs mit Administrationsfunktionen wie beispielsweise Root-Cause-Analyse, Performance-Monitoring oder Help/Service-Desk lässt sich für einen späteren Zeitpunkt vorsehen. Allerdings verlangt der Einsatz des Solu-tion Managers, dessen Bezug über die Softwarelizenz abgedeckt ist, für den Betrieb einen eigenen SAP Netweaver Application Server.

Externe Ressourcen berücksichtigen

Das Projekt lässt sich nach den bewährten Upgrade-Roadmaps organisieren. In seinen prinzipiellen Risiken weist das Upgrade-Vorhaben keine Eigenarten auf. Die Budget-, Ressourcen- und Terminplanung müssen mit der geforderten Sorgfalt in Angriff genommen werden. Auf der technischen Seite müssen die Anwender dafür Vorsorge treffen, dass die Infrastrukturvoraussetzungen für das neue Release fristgerecht bereitstehen. Ansonsten sind neben den produktiven Modulen die Anzahl der Modifikationen und Eigenentwicklungen die eigentlichen Aufwands- beziehungs-weise Komplexitätstreiber für den Release-Wechsel. Dabei sollte der Einsatz externer Spezialisten frühzeitig geplant werden, falls er erforderlich ist. Schließlich laufen Upgrades typischerweise nur alle drei bis fünf Jahre. Die Mitarbeiter eines Unternehmens verfügen deshalb bestenfalls über punktuelle Kenntnisse der technischen Details.

Fachbereiche früh einbeziehen

Es empfiehlt sich, die Fachbereiche frühzeitig in die Planung der Testphase einzubinden. Wenn die Key User der Fachabteilung zu spät mittesten, werden vielleicht erst kurz vor der Schlussabnahme Fehler entdeckt. Es bleibt dann kaum noch Zeit, diese zu beheben.

In der Regel sind die Änderungen, auf die sich ein Endanwender bei SAP ERP 6.0 einstellen muss, äußerst gering. Falls das Upgrade wie beschrieben eher technischer oder funktionaler Natur ist, wird seine tägliche Arbeit davon kaum berührt. Anders als bei früheren Wechseln beispielsweise auf R/3 4.6B und höher muss er sich nicht mit einer neuen Oberfläche vertraut machen. Einzig der Blauton ist neu im Erscheinungsbild.

Diese Ruhe wird auf Dauer sicher keinen Bestand haben. Denn schließlich schaffen sich die Unternehmen mit dem neuen Release eine langfristige Wartungssicherheit (Mainstream Maintenance bis 2013, Extended Maintenance bis 2016). Da mit dem Release-Wechsel das SAP-System zugleich technisch bereinigt und optimiert wird, sind die Voraussetzungen geschaffen, darüber hinaus anwendungsbezogene strategische Updates ins Auge zu fassen.

(ba)