SAP-Anwender bewegt das Thema Migration. Viele von ihnen wechseln von der Grossrechnervariante R/2 - entweder direkt von Release- Stand 4.3 oder bereits von 5.0 - auf die Client-Server-Software R/3. Andere Unternehmen steigen neu in die SAP-Welt ein und muessen den Wechsel aus ihrer bisherigen Individualsoftware-Umgebung vollziehen. Thomas Schmischke* und Thomas Schulze* haben wertvolle Tips fuer eine sichere Migration parat.

Bei der Migration auf SAP-Plattformen ist wie bei allen Projekten besonderes Augenmerk auf die Planung und die realistische Einschaetzung des jeweiligen Aufwands zu lenken. Gerade die Anwender aus den Fachabteilungen unterschaetzen den zeitlichen Aufwand fuer die Mitarbeit.

Eine genaue Projektplanung beseitigt auch die Verunsicherung von Unternehmen, die bei der Problemstellung "Migration" zunaechst nicht wissen, wie sie vorgehen sollen. Daher haben sich ein oder mehrere Workshops zu Projektbeginn bewaehrt, die der genauen Zielermittlung und der Aufgabenstrukturierung dienen.

Prinzipiell kann man das Vorgehen bei Migrationsprojekten in vier Teile gliedern:

- notwendige oder gewollte Organisationsanpassungen;

- technische Migration von Anwendungen und Daten;

- Migration zu einer neuen DV-technischen Infrastruktur sowie

- Planung und Durchfuehrung der Mitarbeiterqualifizierung.

Diese Aufgabenbereiche sind zwar durch die gemeinsame Softwarebasis miteinander verzahnt, koennen aber in Abhaengigkeit vom individuellen Umfeld jeweils einen so betraechtlichen Umfang annehmen, dass sie als eigene Teilprojekte betrachtet werden sollten. Diskussionen entzuenden sich meistens an der Daten- und Anwendungsmigration, die aber nur ein Teil der gesamten Aufgabe ist.

Bevor man sich mit technischen Fragestellungen beschaeftigt, muessen die organisatorischen Ziele definiert werden. In der Regel geht es bei einem Migrations-, aber auch bei einem Einfuehrungsprojekt von R/3 um die optimale Abbildung der im Unternehmen vorhandenen Geschaeftsablaeufe in der Standardsoftware der SAP. Grundlage dafuer ist es, die entsprechenden Vorgangsketten zu definieren und zu optimieren.

Die Definition der Vorgangsketten

Hier lassen sich zwei Ansaetze unterscheiden:

1. Unternehmen betrachten die Migration unter rein DV-technischen Gesichtspunkten und lassen ihre im Rahmen der R/2-Einfuehrung abgebildeten Geschaeftsvorgaenge lediglich in eine Client-Server- basierende Infrastruktur migrieren. Fuer ein solches Vorgehen koennen viele Argumente sprechen, meistens ist jedoch entscheidend, dass man sich erst kurz zuvor fuer die R/2-Einfuehrung entschlossen hat.

Mitunter ist auch eine hohe Akzeptanz der bestehenden Ablaeufe beim Anwender ausschlaggebend, oder das begrenzte Projektbudget verbietet einen anderen Weg. Der Nachteil dieser Vorgehensweise besteht darin, dass durch die zum Teil erweiterte Funktionalitaet von R/3 Luecken im vorhandenen organisatorischen Fachkonzept auftreten koennen, die ein Re-Engineering notwendig machen. Die Integration in das "alte" Fachkonzept kann sich als kritisch erweisen.

2. Unternehmen begreifen die Einfuehrung von R/3 als Chance, ueberfaellige oder naheliegende Fachkonzept-Ueberarbeitungen zur Neudefinition, Optimierung und Anpassung von Geschaeftsprozessen durchzufuehren. Typischerweise sind diese Massnahmen eigenstaendige Projekte im Vorfeld einer Migration beziehungsweise Einfuehrung von R/3. Sie dienen der kompletten Ueberarbeitung der Ablaeufe mit Schwachstellenanalyse, Lean-Management-Ansaetzen etc., unter dem Gesichtspunkt des modernen Business Re-Engineering. Dieses Vorgehen kann auch aus wirtschaftlichen Gruenden sehr nuetzlich sein.

Fuer den technischen Loesungsansatz lassen sich einige Alternativen betrachten, die in Abhaengigkeit der folgenden Faktoren individuell ermittelt werden muessen:

- eingesetzte Module,

- vorhandene Funktionalitaet in neuen Releases,

- allgemeine Rahmenbedingungen,

- notwendiger Verbleib oder sofortige Abloesung von Host-Systemen.

Hier ist generell zu beachten, dass einigen Branchenpaketen aus der R/2-Welt noch keine entsprechenden Umsetzungen in R/3 gegenueberstehen.

Die meistgewaehlte Alternative fuer den Uebergang zu R/3 ist der sogenannte Big-Bang-Ansatz; zu einem fixen Termin wird das R/2- System quasi ueber Nacht abgeloest. Bei ausreichend guter Vorbereitung ist diese Methode dem Koexistenz-Ansatz vorzuziehen. Die Ad-hoc-Abloesung ist weniger aufwendig, da sie die Definition und Implementierung von temporaeren Schnittstellen zum Altsystem ueberfluessig macht.

Diesem Effekt steht allerdings ein Mehraufwand in der Abloesungsplanung und insbesondere im Systemtest gegenueber - nur so laesst sich das zweifellos hoehere Risiko des Big-Bang-Ansatzes in Grenzen halten. Bei einigen Projekten ist diese Vorgehensweise ohnehin nicht moeglich: Gruende hierfuer koennen in zeitlichen, aber auch Release-abhaengig funktionalen Umstaenden liegen. In diesen Faellen ist der bereits erwaehnte Koexistenz-Ansatz zu waehlen. Einzelne Funktionen, meist Module, werden dabei im R/3-System produktiv gesetzt, waehrend andere fuer einen begrenzten Zeitraum (in der Regel sechs Monate bis zwei Jahre) weiterhin vom R/2- System wahrgenommen werden.

Als kritisch erweisen sich bei diesem Vorgehen die Aufteilung der Funktionen zwischen R/2 und R/3 sowie der notwendige Datenabgleich. Bei der sogenannten Batch-Koexistenz werden die abzugleichenden Daten meist nachts im Batch-Betrieb uebertragen. Da in vielen Faellen ein taeglicher beziehungsweise naechtlicher Abgleich notwendig und das Batch-Fenster ohnehin meist knapp ist, wird diese Loesung nicht selten als undurchfuehrbar abgelehnt. Als weitere Moeglichkeit gibt es die sogenannte Online-Koexistenz. Sie laesst sich DV-technisch allerdings sehr viel schwieriger realisieren, da die Daten hier im laufenden Betrieb abgeglichen werden muessen.

Um in der Einstiegsphase eine Vorgehensweise einzuhalten, die den Aufwand reduziert, empfiehlt es sich, mit methodisch unterstuetzten Workshops zu arbeiten. Organisatorische Modelle lassen sich auf diese Weise am besten entwickeln, da die differenzierten Kenntnisse der Anwender ueber die Ablaeufe im eigenen Unternehmen direkt einfliessen. Zusaetzlich sollten externe Berater ihr Know-how aus bereits erfolgreich abgeschlossenen Projekten einbringen und die Anwender methodisch unterweisen.

In mehreren ein- bis zweitaegigen Workshops werden zunaechst aus dem Zielsystem des Unternehmens die Projektziele formuliert. Aufgrund einer groben Bestandsaufnahme des Ist-Zustands der wichtigsten Prozesse koennen dann die Schwachstellen ermittelt werden. Darauf aufbauend laesst sich ein erstes optimiertes Organisationsmodell entwickeln. Die Ausrichtung dieser Workshops kann je nach Unternehmenszielen verschiedenen Konzeptvorgaben wie Kundenorientierung, Kostenersparnis, Durchlaufoptimierung etc. unterworfen werden.

Bei der spaeteren Abbildung dieses Modells in das System

(Customizing-Phase) wird nach dem Prototyping-Verfahren vorgegangen, das dem Kunden gegenueber der klassischen Vorgehensweise einen nicht zu unterschaetzenden Zeitvorteil bei der Generierung eines noch nicht kompletten, aber sehr wohl lauffaehigen Systems bringt. Zudem wird der Anwender frueh in diese Projektphase eingebunden, was dessen Akzeptanz des Systems nachhaltig foerdert.

Gemischte Projektteams haben sich bewaehrt

Bei all diesen Schritten hat sich die Umsetzung mit gemischt besetzten Workshop- beziehungsweise Projektteams aus Externen und Mitarbeitern des SAP-Kunden bewehrt. Werden den einzelnen Workshops konkrete Ergebnistypen vorgegeben, gewaehrleistet diese kurzzyklische Vorgehensmethodik eine exakte Erfolgskontrolle.

Es ist sinnvoll, die technische Migration hinsichtlich der zu migrierenden Objekte bereits bei der Projektplanung folgendermassen zu untergliedern:

- Migration von selbstgeschriebenen Anwendungsteilen (Reports, "Rucksack"-Applikationen) und Schnittstellen (Abaps);

- Migration von Stamm- und Bewegungsdaten (Belegen);

- Uebernahme von Modifikationen und gegebenenfalls

- Migration der Funktionalitaeten von Nicht-SAP-Software und Abbildung in der R/3-Umgebung.

Wie geht man die Uebernahme dieser Objekte an? Die Projektleitung sollte jeden Bereich vor Beginn der eigentlichen Arbeiten kritisch untersuchen. Hinsichtlich der Abaps sind beispielsweise folgende Fragen relevant:

- Fuer welche Abaps ist eine Eins-zu-eins-Uebernahme sinnvoll?

- Wo sollten bei der Migration funktionale Erweiterungen programmiert werden?

- Welche Abaps muessen nicht uebernommen werden, da eine vergleichbare Funktionalitaet im R/3-Standard vorhanden ist?

- Gibt es Abaps, die sinnvollerweise nicht migriert, sondern in R/3 neu entwickelt werden?

- Welche Abaps muessen in R/3 neu entwickelt werden, um benoetigte, aber (noch) nicht vorhandene R/2-Funktionalitaet abzudecken?

Die Arbeit, diese Punkte abzuschaetzen, betraegt nur einen Bruchteil des gesamten Migrationsaufwands und rechnet sich in der Regel durch die erkannten Einsparpotentiale. Es empfiehlt sich dringend, neben Migrationsexperten auch spaetere Nutzer der Programme in den Pruefungsprozess einzubeziehen, um die Akzeptanz der gefundenen Loesungen zu gewaehrleisten.

Die Abap-Migration ist am aufwendigsten

Nach Tagen gerechnet, nimmt der Bereich der Abap-Migration oft die Haelfte oder mehr des gesamten Personalbudgets eines Migrationsprojekts in Anspruch. Betrachtet man zunaechst die Summe der selbstgeschriebenen Abap-Programme, so koennen in der Regel zwischen 20 und 60 Prozent entfallen - alljene, die in den letzten Monaten nie aufgerufen wurden (dies ist durch eine Auswertung SAP- interner Tabellen zu ermitteln).

Vom Rest sind typischerweise 40 bis 60 Prozent im R/3-Standard abbildbar, wobei der Endanwender schon einmal guten Willen - beispielsweise bei veraenderten List-Layouts - zeigen sollte. Die verbleibenden Abaps werden etwa zu gleichen Teilen uebernommen, bei der Uebernahme funktional erweitert oder zusammengefasst beziehungsweise in R/3 neu erstellt.

Ein Zahlenbeispiel: Ausgehend von nicht untypischen 1000 eigenen Abaps, werden schaetzungsweise 400 nicht mehr benoetigt. Weitere 300 lassen sich im R/3-Standard abbilden, so dass fuer die eigentliche Uebernahme 300 verbleiben. Von diesen sind etwa 50 bis 70 Prozent einfachen bis mittleren Schwierigkeitsgrades, sie koennen durch die "Bordmannschaft" migriert werden. Durch externe Unterstuetzung muessten im Beispiel also nur zirka 120 Programme umgesetzt werden.

Diese Zahlen koennen natuerlich nur Anhaltspunkte bieten und muessen fallweise vom Beispiel abweichen. Sie stehen in Abhaengigkeit von den jeweils zur Debatte stehenden SAP-Modulen und der generellen Bereitschaft, vom Standard abzuweichen und Abaps einzusetzen. Fuer die Ablaufplanung im Projekt ist zudem die Verzahnung mit dem Customizing zu beachten.

Waehrend sich isolierte, selbstgeschriebene Anwendungspakete zeitlich unabhaengig migrieren lassen, sollte die Menge der List- und Schnittstellen-Abaps erst nach erfolgtem Customizing uebernommen werden. Wartet man diesen Schritt nicht ab, kann der Aenderungsaufwand an eigentlich fertigen Abaps leicht auf weitere 50 Prozent des urspruenglichen Uebernahmeaufwands anwachsen.

Bei der Betrachtung der Datenmigration ergeben sich aehnliche Fragestellungen fuer die Beurteilung von sinnvollen Datenuebernahmen wie bei den Abaps. Ziel der Planung ist es hier, die Datenmenge zu reduzieren, die im "kritischen Zeitfenster" migriert werden muss. Unter einem kritischen Zeitfenster ist der Zeitraum zwischen Ausserbetriebstellung des alten und Inbetriebnahme des neuen Systems zu verstehen. Verstaendlicherweise darf diese Phase nur sehr kurz sein, weil sonst das ganze Unternehmen stillgelegt wird.

Daher muessen folgende Fragen beantwortet werden:

- Welche Daten sind fuer den produktiven Betrieb von R/3 taeglich notwendig?

- Koennen sie eventuell vor oder nach dem kritischen Zeitfenster migriert werden?

- Welche Daten sind archivierbar?

- Steht nach der Migration eventuell das Altsystem fuer den Zugriff auf Altdaten zur Verfuegung?

- Gibt es Daten, die nicht uebernommen werden muessen?

Ausgehend von diesen Fragenstellungen muss die technische Uebernahme festgelegt werden. Je nach Migrationsszenario ergeben sich folgende Moeglichkeiten:

1. Uebernahme von Stammdaten, Historiendaten und offenen Posten mit einem im Rahmen aehnlicher Projekte erstellten Werkzeug. Diese Datenuebernahme fuehrt zu einer Stichtagsumstellung mit einer kurzen, dualen Pflegeperiode der Daten.

2. Uebernahme aller Daten inklusive abgeschlossener Belege mit Hilfe von nachtraeglich erweiterten Werkzeugen der SAP, wobei heute fuer einige Module noch Erweiterungen notwendig sind.

3. Koexistenzloesung zwischen R/2 und R/3 mit der Moeglichkeit von Batch- oder Online-Datenaustausch.

Bei der Betrachtung der anfangs erwaehnten dritten Teilaufgabe eines Migrationsprojekts, dem Aufbau einer neuen technischen Infrastruktur, ist es wie bei einer Neueinfuehrung wichtig, der Planung volle Aufmerksamkeit zu widmen. Schon im Vorfeld des eigentlichen Migrationsprojekts ist die Planung und Realisierung der notwendigen technischen Infrastruktur (Netzwerk, dezentrales Rechenzentrum, unter Umstaenden Host-Server-Kopplung) in Angriff zu nehmen.

So lassen sich bei der Durchfuehrung des Migrationsprojekts technische Probleme weitgehend verringern. Abhaengig von Art und Anzahl der zu integrierenden Module kann es sinnvoll sein, mit einem kleinen, abgrenzbaren Modul zu beginnen. In diesem Teilprojekt ist der Schwerpunkt auf die Einrichtung der neuen Systembasis und der Infrastruktur zu legen.

Als letzter wichtiger Teilaspekt ist die Qualifizierung der am Projekt beteiligten Mitarbeiter und der spaeteren Endanwender zu nennen: Um die Akzeptanz des R/3-Systems, aber auch die Effizienz bei der Migration und spaeteren Nutzung zu gewaehrleisten, sind Schulungen erforderlich. Schon frueh sollte damit begonnen werden, ein Mengengeruest der zu schulenden Projektteam-Mitarbeiter, Fachanwender und Systembetreuer zu erstellen. Besonders bei unterschiedlich vorgebildeten SAP-Endanwendern ist es am besten, wenn diese Schulungen am System des Kunden mit den auf ihn zugeschnittenen Inhalten durchgefuehrt werden.

* Thomas Schmischke und Thomas Schulze leiten das Competence Center SAP der Integrata AG (ICCS) in Frankfurt.