Mehr als 3000 Unternehmen in Deutschland nutzen derzeit noch das bewährte SAP-System R/3. Ein Großteil dieser Firmen beabsichtigt allerdings, 2010 ein Upgrade auf das aktuelle SAP-Release "ERP 6.0" zu starten. Die Gründe sind einleuchtend: So wollen die Anwender der Erhöhung der SAP-Wartungsgebühren für ältere Versionen zuvorkommen. Zudem schafft ein technischer Release-Wechsel die Voraussetzungen, um neue Funktionen rund um die Service-orientierten Architektur (SOA) nutzen zu können. Allerdings herrscht in vielen Anwenderunternehmen noch Unsicherheit, welches Upgrade-Vorgehen für sie das richtige ist. Die Verantwortlichen sehen sich mit einer Fülle von Fragen konfrontiert: Welche Anforderungen, welcher Aufwand und welche Risiken sind mit einem Release-Wechsel verbunden?
Wer sein Upgrade-Projekt jedoch genau plant, kann die damit verbundenen Risiken exakt kalkulieren. Für einen reibungslosen Release-Wechsel auch komplexer SAP-Systemlandschaften hat sich ein Industrieansatz bewährt, der standardisierte Methoden mit automatisierten Systemanalysen und Quellcode-Anpassungen kombiniert. Mit diesem Best-Practice-Konzept kann beispielsweise eines der größten Risiken und einer der größten Aufwandstreiber eines Upgrades - die Anpassung der kundeneigenen Entwicklungen - kalkulierbar gemacht und auf ein Minimum reduziert werden.
Dabei empfiehlt es sich, jedes Projekt in zwei Phasen zu unterteilen, die jeweils mehrere Meilensteine umfassen. Wichtig ist in jeder Phase, dass das Management den Upgrade nachdrücklich unterstützt und dies auch klar an die Mitarbeiter in den IT- und Fachbereichen kommuniziert. Denn prinzipiell sind von einem Release-Wechsel alle Unternehmensbereiche betroffen: von der Technik und SAP-Basis über die Entwickler und Systembetreuer bis hin zu den Anwendern in den Fachabteilungen.
Lesen Sie mehr zum Thema SAP-Migration:
Phase 1: Planung und Analyse
Automatisierte Analyse kundeneigener Entwicklungsobjekte
Der Upgrade-Projektaufwand hängt maßgeblich vom Anteil der kundenindividuellen Entwicklungen in den vorhandenen SAP R/3-Systemen ab. Da viele dieser Objekte mit den Anforderungen des neuen ERP-Release kollidieren können, muss ihr Quellcode an die neue Programmumgebung angepasst werden.
Durch den Einsatz eines speziellen Software-Werkzeugs lassen sich diese Programmerweiterungen automatisiert identifizieren und analysieren. Damit ist innerhalb kurzer Zeit klar, wie viel Quellcode verändert werden muss und welcher Zeit- und Kostenaufwand dafür erforderlich ist. Ebenso können die Verantwortlichen die nicht mehr genutzten Eigenentwicklungen in den SAP R/3-Applikationen ausfindig machen und herausfiltern. Da dies erfahrungsgemäß für durchschnittlich die Hälfte aller selbst geschriebenen Programme zutrifft, kann eine frühzeitige Auslese den späteren Upgrade-Aufwand signifikant senken.
Darüber hinaus ermittelt das Analysewerkzeug die erforderlichen Anpassungen im SAP-Berechtigungskonzept: Davon sind rund 60 Prozent der im Altsystem vorhandenen Berechtigungsrollen betroffen, das zeigen unter anderem die Erfahrungen von Accenture.
Workshop zur Analyse der technischen Infrastruktur
In einem begleitenden, komprimierten Workshop beleuchten die IT-Mitarbeiter die technischen Rahmenbedingungen für einen Upgrade: dazu zählen beispielsweise die vorhandenen IT-Systeme und Schnittstellen, andere geplante oder bereits laufende IT-Projekte sowie die für einen Release-Wechsel notwendigen Ressourcen.
Dabei sollte auch geklärt werden, ob sich parallel zum Upgrade eine Unicode-Umstellung oder eine Modernisierung der SAP-Systemumgebung empfiehlt, zum Beispiel von Hardware, Datenbanken und Betriebssystem.
Fazit: Vorteile der industrialisierten Analyse
-
Die Kunden erhalten bereits nach kurzer Zeit einen detaillierten Projektplan mit Angaben zu Projektlaufzeit und -kosten, zu Anforderungen und Ressourcenbedarf.
-
Anwender können auf dieser Basis entscheiden, ob sie den Upgrade in eigener Regie anpacken oder - was gerade bei sehr komplexen Projekten zu empfehlen ist - externe Unterstützung in Anspruch nehmen sollten.
-
Erfordert eine manuelle Quellcode-Anpassung mehrere hundert Personentage, sollten die Unternehmen zudem einen industrialisierten Konvertierungsansatz wählen.
Phase 2: Umsetzung und Go-Live
Standardisiertes Projektmanagement
Im Rahmen eines SAP-Upgrades sind vorgefertigte Projektpläne, Checklisten, Cutover-Pläne, Lessons Learned und How-to-Dokumente äußerst hilfreich. Standardisierte Methoden ermöglichen es den Anwendern, das Projekt zügig und wirksam zu steuern sowie Erfahrungen aus anderen Vorhaben zu nutzen.
Paralleler Aufbau von zwei Wartungslandschaften
Damit sich das Produktivsystem auch während des Upgrade-Projekts warten lässt, ist eine parallele Systemlandschaft erforderlich. Dazu werden Kopien vom Entwicklungs- und Testsystem hergestellt, die im alten Release-Stand verbleiben und an das Produktivsystem angebunden werden. Das bereits vorhandene Entwicklungs- und Testsystem dient der eigentlichen Projektarbeit, denn beide Systeme werden nacheinander auf das neue Release SAP ERP 6.0 umgestellt.
Automatisierte Konvertierung des kundeneigenen Quellcodes
Spezielle Konvertierungswerkzeuge sorgen für eine automatisierte, regelbasierte Anpassung des Kunden-Quellcodes. Nach Erfahrungen von Accenture können damit in der Regel bis zu 90 Prozent der betreffenden Prozesse automatisiert werden. Der manuelle Aufwand reduziert sich auf ein Minimum, die Umstellungszeiten werden erheblich verkürzt. Darüber hinaus trägt die hohe Bearbeitungsqualität der Konvertierungs-Tools dazu bei, die Testaufwände zu verringern.
Sandbox-Upgrades zur Generalprobe
Für viele Unternehmen ist der Systemstillstand einer der kritischsten Zeitpunkte im gesamten Upgrade-Projekt, zum Beispiel wenn rund um die Uhr im Schichtbetrieb gearbeitet wird. Im Regelfall kommt allenfalls eine Downtime des SAP-Systems während eines Wochenendes in Betracht. Das Upgrade-Projektteam kann einer solchen Kundenanforderung besser genügen, wenn die geplante Downtime im Rahmen von Sandbox-Upgrades verifiziert wird. Dabei handelt es sich um eine Art "Generalprobe" auf einer Sandbox, die dem produktiven System ähnlich ist. Die Sandbox-Upgrades machen es möglich, Probleme und Schwachstellen, die zu einer Verlängerung der Downtime führen können, bereits im Vorfeld zu erkennen und zu beseitigen.
Go-Live und Downtime
Nach erfolgreichem Abschluss der Integrations- und Anwendertests erfolgt der Upgrade des Produktivsystems auf das neue Release SAP ERP 6.0. Prinzipiell hängt die Dauer der damit verbundenen Downtime von einer Reihe von Faktoren ab: zum Beispiel vom Release-Stand des eingesetzten SAP R/3-Systems, von Hardware, Konfiguration und Datenbank sowie der Komplexität der gesamten Systemlandschaft. Ein gut geplanter Cutover ist jedoch entscheidend, um die mit dem Kunden vereinbarte Downtime und Geschäftskontinuität im Go-Live zu erreichen.
Komplexität schwankt beträchtlich
Wie die Praxiserfahrungen von Unternehmen aller Größen und Branchen zeigen, weisen SAP-Upgrade-Projekte eine enorme Bandbreite auf: Sie reichen von hochkomplexen Vorhaben, die bis zu 6000 Personentage verschlingen und mehrere Millionen Euro Kosten verursachen, bis hin zu einfachen Release-Wechseln, die nur 200 Personentage erfordern, obwohl parallel dazu eine Unicode-Konvertierung oder ein Datenbank-, Betriebssystem- und Hardware-Wechsel erfolgt.
Angesichts dieser Bandbreite ist es für die Unternehmen wichtig, das Upgrade-Projekt bereits im Vorfeld möglichst exakt zu planen. Nur so lässt sich der damit verbundene Aufwand einschätzen. Eine industrialisierte Analyse sorgt frühzeitig für Klarheit, mit welchen möglichen Problemen und Hürden ein Unternehmen zu rechnen hat. Sie bietet jedem Kunden eine verbindliche Planungs- und Entscheidungsgrundlage, ob sich ein Upgrade mit Bordmitteln abwickeln lässt.
Unternehmen, die externe Unterstützung benötigen und mit einem hohen Anpassungsaufwand zu rechnen haben, sollten einen IT-Dienstleister wählen, der auch in der Umsetzungsphase einen konsequenten Industrieansatz verfolgt. Denn nur durch eine methodische Standardisierung und technische Automatisierung ist es möglich, den Release-Wechsel sicher und wirksam zu steuern und die Hauptaufwandstreiber - Quellcode-Anpassungen und dadurch erforderliche Tests - nachhaltig zu minimieren.
Darüber hinaus sollte die Entscheidung für einen Service-Partner fallen, der über umfassende Upgrade-Erfahrungen mit den unterschiedlichen SAP-Lösungen verfügt: vom klassischen ERP-Standard über Applikationen aus der neuen SAP Business Suite bis hin zu speziellen SAP-Industrielösungen. Denn obwohl die technischen Abläufe ähnlich sein mögen, sind gezielte Branchen- und SAP-Modulkenntnisse für eine optimale fachliche und technische ERP-Upgrade-Umsetzung unverzichtbar.
Elf Checkpunkte für ein Upgrade-Projekt mit industriellem Ansatz
-
Projektindividuell entscheiden über werkzeugunterstützte Analyse, industrialisierten Ansatz und automatisierte Codeumstellung für die Durchführung des Upgrade-Projektes.
-
Managementunterstützung sicherstellen und interne Ressourcen einbeziehen aus den Bereichen IT-Management, IT-Systemadministration, IT-Entwicklung, Business.
-
Rechtzeitig Entscheidungen treffen über Systemlandschaft, Hardwareinvestitionen, Sizingerweiterungen.
-
Einplanen von Sandbox-Systemen und Sandbox Upgrades, um Downtime-Zeiten zu verifizieren und damit die Downtime-Risiken zu minimieren.
-
Parallele Systemlandschaft aufbauen, um die Wartung der existierenden Systemlandschaft zu gewährleisten.
-
Konzept für Wartung und parallele Entwicklung aufsetzen, um die Anpassungen auf Wartungs- und Upgrade-Systemlandschaft synchron zu halten.
-
Möglichst reduzieren: parallele Projekte und parallele Entwicklungsaktivitäten während des Upgrade-Projektes.
-
Identifizieren von nicht mehr verwendeten kundeneigenen ABAP-Programmen (Systemhistorie nutzen) und möglichst nur die aktuell verwendeten kundeneigenen ABAP-Programme in die Codeumstellung einbeziehen.
-
Prüfen und einplanen: durch den Upgrade erzwungene funktionale Anpassungen, Berechtigungsanpassungen und Schnittstellenanpassungen.
-
Umfassenden User Acceptance-Test einplanen, der neben den Business Prozessen die im Upgrade geänderten Objekte (kundeneigene ABAP-Programme, Berechtigungen, Schnittstellen) umfasst.
-
Cutover sorgfältig planen, um die Downtime-Anforderungen und damit die vereinbarte Geschäftskontinuität im Go-Live zu erreichen (erhöhte Support-Bereitschaft nach Go-Live von maximal 2 Wochen einplanen).