Die Migration von R/2 zu R/3 ist ein Vorgang, der schwerwiegende Folgen

hat und nicht ohne Risiko vonstatten geht. In diesem Beitrag soll daher der

Frage nachgegangen werden, welche Probleme ein Systemwechsel im Gefolge

von Downsizing-Überlegungen aufwirft und wie der IV -Verantwortliche

diese in den Griff bekommen kann.

Die Anforderungen und das Risiko einer Migration ergeben sich letztlich aus den Unterschieden zwischen Herkunftsund Zielsystem. Aus diesem Grund scheint es angebracht, zunächst einen Blick auf die Charakteristika und die Leistungsmerkmale der bei

den Systemwelten zu werfen und dabei die Unterschiede und Gemeinsamkeiten der Systeme, die Art der Installation und auch die jeweiligen Besonderheiten in der Betriebsweise zu betrachten.

Der heutige System-Generationswechsel bei SAP zeichnet sich dadurch aus, daß die Innovation weniger auf der Anwendungsseite als auf der technologischen Seite stattfindet. SAP hat, um dies zu rekapitulieren, unter R/2 ein nahezu umfassendes betrie

bswirtschaftliches Modell realisiert, das dem aktuellen Stand der wirtschaftswissenschaftlichen Forschung entspricht.

Hierin unterscheidet sich R/2 auch von vielen anderen Standardsoftware-Paketen und Individuallösungen, die auf dem konkreten Anwendungshintergrund eines spezifischen Unternehmens entstanden sind und dementsprechend weniger das zugrunde liegende b

etriebswirtschaftliche Modell berücksichtigten - zum Beispiel Abbildung einer Kostenstellenrechnung im Rahmen der Hauptbuchhaltung - als die speziellen Vorstellungen der jeweiligen Anwender. Da dieses Entwicklungskonzept von R/2 seine Praxistauglichkeit n

achgewiesen hat, wurde die R/3-Entwicklung nach demselben Anspruch aufgesetzt; die vorhandenen Modelle wurden deshalb übertragen.

Ausgehend von diesem Designkonzept ist es somit nur plausibel, daß mit R/3 keine grundsätzlich neue Funktionalität geliefert werden wird.

Beide Systeme, soweit heute verfügbar, beinhalten also dieselbe Funktionalität, wobei sich SAP darüber hinaus dazu verpflichtet hat, für die nächsten Jahre die funktionalen Weiterentwicklungen in beiden Systemen deckungsgleich zu halten.

Mitgelieferte funktionale Abweichungen sind allenfalls marginal; ähnlich wie die CUA-Orientierung der grafischen Oberfläche, die den Ablauf einzelner Transaktionen beeinflussen kann, verbessern sie lediglich die unmittelbare Benutzerfreundlichkei

t.

Viel bedeutender ist allerdings, daß das Integrationsmodell des R/2-Systems fortgeführt wird und damit die bereichsübergreifende Abstimmung und Synchronisierung der Mengen- und Werteflüsse in ihren konstruktiven Merkmalen erhalten bleiben, genaus

o wie die logische Trennung von Basis- und Anwendungskomponente, die das Anwendungssystem Betriebssystem-neutral werden läßt und damit auch den Übergang zwischen den technologischen Plattformen erleichtert .Die erreichte funktionale Identität der beiden

Systeme und des Verarbeitungskonzeptes wirkt sich daher eher günstig auf eine anstehende Migration aus.

SAP-R/2 hat zwar eine eindeutige und spezifische Sicht der Daten, besitzt aber im Gegensatz zum R/3 kein Entity-Relationship-Datenmodell. Aus der Verwendung des ERM-Ansatzes beim R/3-Entwurf und der Abkehr vom ablauf-orientierten Datenbankentwurf

hat sich die Sicht auf die Unternehmensdaten zwangsläufig verändert, was in der Konsequenz zu konstruktiven Änderungen des Datenmodells geführt hat. Dieser Umstand ist für die Migration von erheblicher Bedeutung.

Die Benutzeroberflächen beider Systeme sind bekanntermaßen vollständig verschieden, ein Umstand, der für die vorliegende Betrachtung allerdings irrelevant ist. Zunächst sollen Unterschiede und Gemeinsamkeiten der Basistechnologie aufgezeigt werde

n

Eine wesentliche Gemeinsamkeit vo

- R/2 und R/3 ist das Verarbeitungskonzept , nach dem Dialogprogramme und Verbuchungsprogramme strikt voneinander getrennt und asynchron über eine Protokolleinrichtung gekoppelt sind.

Sämtliche R/3- und zunehmend mehr, in jedem Falle aber alle neuen R/2-Anwendungsprogramme sind in der Abap/4-Sprache entwickelt, die in beiden Systemwelten denselben Sprachumfang besitzt. Beide Systeme verfügen über Screen Painter und CUA-Painter

, so daß eine identische Entwicklungsplattform gegeben ist. Das bedeutet mit zunehmender Weiterentwicklung eine verbesserte Portierbarkeit auch von Eigenentwicklungen .

Beide Systeme werden vom jeweiligen SAP-Data-Dictionary unterstützt. Dieser Umstand bedeutet zwar nicht die Beseitigung aller Migrationsprobleme, aber doch eine erhebliche Hilfe bei der Planung und Durchführung des Umstiegs.

Die Kommunikationskomponente beider Systeme läßt dieselbe Art der Verarbeitung von Massendaten aus externen Systemen mit Batch-lnput zu kennt dasselbe Interfacing zu Kommunikationseinrichtungen der Telekom, arbeitet mit denselben Spooling-feature

s und verwendet dieselbe LU6.2-Rechnerkommunikation mit CPI-C.

Letzteres ist heute die Voraussetzung für die Anbindung der Satellitenanwendungen des Lagerverwaltungssystems LVS und des Dass-Leitstandes und öffnet die SAP-Systeme zu den Fremdsystemen beim Kunden.

Diese Gemeinsamkeiten reduzieren die beim Systemwechsel notwendigerweise umzustellenden Objekte und tragen damit ebenfalls zur Erleichterung der Migration bei.

Wie hinreichend bekannt, unterstützt R/3 im Release 1.1 nur Unix-Systeme und die Betriebssysteme der HP3000 (MPE/XL) von HP und der VAX (VMS) von DEC und wird erst in zukünftigen Releases die heutigen R/2-Mainframe-Betriebssysteme MVS, VSE/ESA und BS2000

wieder begleiten.

Unterschiede in den

Hardwareplattformen

Damit unterscheiden sich beide Systeme auch in der Installation und der Betriebsweise erheblich .R/2-Systeme setzen einen organisierten Rechenzentrumsbetrieb voraus, der alle Aufgaben des Rechnerbetriebes wahrnimmt, also Hard- und Softwarewartung

, Betrieb der Anwendung, Gewährleistung der Datensicherheit, Schutz des Rechenzentrums durch Zugangskontrollen etc.

R/3-Systeme mit dem Charakter von Workstation-Anwendungen brauchen kein Rechenzentrum. Im Gegenteil - sie sind ausgelegt auf eine Installation vor Ort. Sie erfordern deshalb bei ihrer Einführung ein Umdenken in der Organisation des Rechnerbetriebe

s und im Sicherheitskonzept.

R/2-Systeme sind aufgrund der Anwendungsgröße und der Vielzahl der gleichzeitig aktiven Nutzer auf kontinuierliches Monitoring und Tuning der Anwendung und der Datenbanken angewiesen. Als Beispiel für das Anwendungs-Monitoring gilt das auf viele

Großanwendungen zutreffende Problem der Abap

Report-Nutzung zur Online-Zeit. Ein Benutzer startet einen Abap, der die komplette Belegdatenbank sequentiell abarbeitet und damit zum typischen Resourcenfresser wird und die Arbeit aller übrigen Anwender extrem belastet. Dieses Problem wird zum Thema de

r Anwendungsbetreuer und verlangt zumindest deren steuernden Einsatz.

R/3-Systeme werden zunächst erheblich kleiner dimensioniert sein und von einer begrenzten Anzahl von Anwendern genutzt werden. Die eingesetzte Client-Server-Architektur mit verteilten Anwendungen und verteilter Präsentation verlagert zudem die Sy

stemlast an den Ort des Geschehens, das heißt zum verursachenden Anwender und kann dafür sorgen, daß Lastprobleme wie unter R/2 im R/3 nur selten auftreten.

Für R/2-Systeme ist im laufen

den Betrieb üblicherweise ein Team von Systemprogrammierern zuständig, von denen jeder einzelne Spezialist in einer spezifischen Systemkomponente ist.

R/3-Systeme erfordern im Hinblick auf die Konfiguration der Anwendung, das Design des Netzwerkes sowie die Betreuung der Anwendung und des laufenden Rechnerbetriebs ein einerseits umfassendes, andererseits aber auch spezialisiertes Knowhow .Sie e

rlauben jedoch aufgrund der Systemgröße nicht unbedingt den Aufbau einer großen Support-Mannschaft, so daß an die Qualität der Mitarbeiter gehobene Ansprüche zu stellen sind.

Welchen Einfluß besitzen nun diese Charakteristika des Herkunftssystems R/2 und des Zielsystems R/3 insgesamt auf das Migrationsvorhaben?

Bedingt durch die konsequente Weiterentwicklung der Systeme, die sich darstellt in der Konsistenz von Funktionen, Verarbeitungsweisen, Entwicklungsumgebung und Schnittstellen-Technologie, hat SAP den Systemübergang erleichtert. Die Migration redu

ziert sich im wesentlichen auf die Daten .Anders als bei der Umstellung anderer Systeme entfällt hier die sonst kritische Migration der Programme.

Migration verändert die Hardwareplattform

Nachdem klar ist, welchen Umfang die Migration inhaltlich annehmen wird, gilt das Augenmerk den möglichen Migrationsstrategien. SAP hat zu Beginn des Jahres ein umfassendes Migrationsszenario gezeichnet. Es umfaßt in etwa den Zeitraum der nächste

- zehn Jahre und beschreibt einerseits solche Situationen, in denen ein vollständiger Wechsel von der 370- beziehungsweise 390-Architektur auf die offene Systemplattform vollzogen wird, und andererseits solche, in denen an die 370-oder 390-Umgebung R/3-S

atelliten-Systeme wie LVS angedockt werden.

Für unsere Betrachtung ist allerdings die Anbindung eines Satellitensystems nicht relevant, da hierbei ausschließlich eine Kommunikationsaufgabe zu lösen ist, nicht aber die Veränderung der Datenbasis realisiert werden muß. Eine weitere Situation kann mi

t dem Begriff Mixed-Hardware-Konfiguration beschrieben werden, wenn nämlich heterogene Strukturen und Teile der Mainframe-Infrastruktur gemeinsam genutzt werden. Dies setzt allerdings voraus, daß die Mainframe-Umgebung R/3-gestützt ist.

Die Darstellung von SAP in Abbildung 2 zeigt, daß es keine Konstellation geben können wird, in der ein Teil heutiger Mainframe-Applikationen, zum Beispiel RM, in die R/3-Umgebung ausgelagert wird, während der Rest, zum Beispiel RF und RK-S, auf d

em Mainframe als R/2-Anwendung verbleibt .Es sei denn, SAP bereitet sich heute in den Labors auch hierauf vor

Im Sinne dieses Szenarios muß also unter Migration im wesentlichen die Veränderung der Hardwareplattform verstanden werden.

Die Anzahl der Migrationsmöglichkeiten, die SAP heute sieht, und deren mögliche Zwischenformen eröffnen den in Frage kommenden Unternehmen eine Vielzahl von Alternativen, was die Notwendigkeit nach sich zieht, die unternehmensspezifische Migratio

nsstrategie klar zu definieren.

Im letzten Abschnitt wird dieses Thema noch vertieft. Es werden einige der Kriterien zur Migrationsentscheidung diskutiert. Zunächst sind aber noch die Durchführungsdetails der R/2-R/3-Migration näher zu betrachten.

Wie bereits angedeutet, ist Migration in der SAP-Welt auf die Datenumsetzung aus der hierarchischen in die relationale Welt reduziert. Zwischen beiden Datensituationen bestehen allerdings gravierende Unterschiede, was diesen Datenwechsel zu einer

nichttrivialen Aufgabe werden läßt.

Um einen Eindruck von der Komplexität der Datensituation zu geben, sind hier einige der Besonderheiten dargestellt

Zuordnung zu Tabellen: In vielen Bereichen haben sich die Feldzuordnungen (Entities) zu Tabellen erheblich geändert, nach altem Sprachgebrauch haben also Wanderungen zwischen den Segmenten stattgefunden

Eine Variante davon sind neue R/3-Entities, zu denen kein R/2-Pendant existiert. Beides gilt es bei einer Migration zu berücksichtigen.

Feldlängen verändert, zumeist verlängert. Diese Änderungen erzwingen nun Umsetzregeln

Mitwirkung der Atab-Tabellen: In allen R/2-Applikationen wirken die Atab-Tabellen auf die gespeicherten Daten ein. So werden zum Beispiel Tabellen-Keys in den Daten gespeichert, die nur über die Tabelle wieder interpretierbar sind .

Eine Umsetzung der Daten ist deshalb nur sinnvoll, wenn gleichzeitig auch die entsprechenden Atab-Tabellen mit transportiert und umgesetzt werden.

Zur Identifikation der verwendeten A-Tabelle kann das Data Dictionary einen entscheidenden Beitrag leisten.

Veränderte Formate: SAP hat im R/2-System eine Vielzahl von

spezifischen Datenformaten kreiert, die dazu dienten, die Verarbeitung zu optimieren und die ganz gezielt auf die Assembler- und später auch Abap-Syntax ausgerichtet waren. Von diesem Ansatz mußte SAP mit R/3 Abschied nehmen, wollte man die Systeme offe

- gestalten und Standards nutzen, da zum Beispiel der Oracle-Standard solche Spezialformate nicht zuläßt. Letztlich bedeutet dies, mit der Datenumsetzung auch Formatkonvertierungen vornehmen zu müssen.

Veränderte Codierung: Mit dem Umstieg auf Unix-Systeme geht eine Umstellung der Datenspeicherung von EBCDIC-auf ASCII-Code einher, die es bei der Datenumsetzung zu berücksichtigen gilt.

Vorrangig ist die Umstellung der Standards. Es liegt nun an SAP, die oben auszugsweise genannten Anforderungen mit einem Transfersystem zu lösen ,das weitgehend automatisiert den Kunden bei der Umsetzung des Standardsystems entlastet.

Nach Auskunft der SAP-Entwicklung wird ein solches System gerade erarbeitet und soll in rund 18 Monaten zur Verfügung stehen, das heißt, nachdem der funktionale Gleichstand zwischen R/2 und R/3 erreicht ist Im Groben soll es folgende Funktionen b

einhalten:

Erfassung der Konvertierungsregeln mit eigenen Transaktionen beziehungsweise komplexeren Abaps,

Export von R/2-Daten und Strukturen mit Abap-Mitteln und Bereitstellung in einem Transferfile,

Komprimierung der Dateien,

Transfer

Dekomprimierung und

Konvertierung der Daten nach den vorgegebenen Regeln und Insert durch ein Importprogramm.

Kritisch bei der Umsetzung des Standardsystems dürfte sich das Datenvolumen auswirken. Dieses kann aufgrund der notwendigerweise aufwendigen Umsetzprozeduren bei größeren Systemen wie RM-MAT oder RM-PPS beziehungsweise großen Datenbanken wie der

Abez einen enormen Zeitbedarf bedeuten. Derzeit ergeben sich nach Aussagen des Herstellers noch sehr lange Laufzeiten.

Eine Abez-Portierung mit zirka 250 000 Belegköpfen und zirka 500 000 Belegsegmenten benötigte unter Nutzung einer schnellen Bandstation im Juni noch zirka acht Stunden. Nach unserer Ansicht müssen die Anstrengungen der SAP dazu führen, daß die La

ufzeiten entweder erheblich verkürzt werden, oder daß das Konzept stufenweise Umsetzungen erlaubt. In jedem Fall müssen Laufzeiten erreicht werden, die ein produktives Unternehmen nicht zu tagelangem Betriebsstillstand zwingen.

Die Konvertierung der Erweiterungen und Modifikationen wird letztlich eine Aufgabe sein, die der Kunde in eigener Regie durchführen und für deren Erfolg er letztlich selbst sorgen

. Zur Erleichterung muß an das genannte Transfersystem der SAP die Forderung nach Transparenz und Ease -of-use -gestellt werden .

Transparenz bedeutet dabei letztlich auch Dokumentation der vollzogenen Migration. Es muß deutlich sein, welche Elemente auf welche Art und Weise migriert wurden (Zuweisung, Konvertierungsregel) ;welche nicht migriert wurden und welche Bestandtei

le des R/3 lediglich initialisiert wurden.

Weiche Umstellung ist eine Alternative

Neben der harten Umstellung könnte sich allerdings bis zum Zeitpunkt der Verfügbarkeit des Transfersystems auch der weiche Umstellungsweg anbieten. Er ist an die herkömmliche Methode des R/2 angelehnt, mit der dort der Datenübernahmeprozeß aus Fr

emdsystemen abgewickelt wird und basiert auf dem Prinzip von Datenextrakt und Batch-Input. Dieser Ansatz könnte sich bei kleineren Anwendungen mit reduziertem Datenvolumen empfehlen.

Allerdings verlangt diese Vorgehensweise eigene Programmierungsleistung des Kunden und damit erhebliches eigenes Investment.

Welcher der beiden Wege sich nun im Einzelfall anbietet, hängt von den spezifischen Anforderungen ab und bestimmt sich letztlich aus dem geforderten Einsatzzeitpunkt des neuen R/3-Systems und der Größe der zu übernehmenden Datenbanken.

Die Planung eines

Migrationsprojektes

Trotz aller Reduzierung auf die reine Datenumsetzung stellt die Migration im Zuge der Einführung des R/3 beziehungsweise Ablösung des R/2 zumindest ein separates Teilprojekt dar. Es kann neben der Konvertierung gegebenenfalls auch Komponenten ein

es Releasewechsel-Projektes beinhalten.

Im einzelnen müssen folgende Phasen durchlaufen werden:

- Installation des Standardsystems R13,

- Training,

-Customizing

- Überprüfung alter R/2-Modifikationen und Zusätze

- gegebenenfalls Nachziehen der der Modifikationen,

-Vorbereitung der Migration,

- Testumsetzung,

- Dimensionierung der temporären Umsetzungssysteme,

- produktive Umsetzung und

-Abnahme und Produktionsstart.

Die Erfahrung in der Migration - die in unserer CAP-Debis-Terminologie "Conversion " heißt - von Anwendungssystemen läßt sich in Teilen auch auf den spezifischen Fall der R/2 -R/3-Migration übertragen und zeigt, daß vor allem auf die Vorbereitung der

Migration und die Dimensionierung der temporären Umsetzungssysteme besonderes Augenmerk gelegt werden muß.

Unterstellt, daß die Konvertierungsregeln für die Datenelemente des Standardsystems nicht mehr verifiziert werden müssen, so sind in jedem Fall die Standardannahmen des Herstellers für die Umsetzungsdimensionen wie Speicherplatz etc. zu überarbeiten und

an die Live-Gegebenheiten des Unternehmens anzupassen, nötigenfalls über mehrere Iterationsschritte. Das Operating-System muß für die eigentliche Durchführung installiert und vorbereitet werden. Eine Besonderheit ergibt sich, sobald Modifikationen am Dat

enteil des R/2-Systems durchgeführt wurden. Wie ausgeführt, liegt die Verantwortung für die Portierung hier beim Kunden, was Zusatzprogrammierung mit all ihren Test- und Abnahmeaktivitäten bedeutet. Diese vorbereitenden Phasen entscheiden damit letztlich

über die Sicherheit und den Erfolg der Umstellung.

Was spricht für die Migration?

Die Determinanten der Migration zu bestimmen, bedeutet, die Motivationen zu finden, die heute ein Unternehmen bewegen können, die R/2-Welt zu verlassen und in Client-Server-Architekturen einzutreten. Es geht hier also nicht darum, die Entscheidun

gslage für den Wechsel von einem Fremdsystem zu R/3 zu eruieren.

Der Übergang in die Client-Server-Welt mit verteilten Anwendungen ist nicht nur eine Hard- und Software-Entscheidung. Er bedeutet letztlich auch, sich dem organisatorischen Wandel vom zentralisierten zum dezentral geführten Unternehmen zu stellen

.

Deshalb genügt es nach unserer Überzeugung nicht, allein

über die Hardwareplattform und deren mögliche Kostenvorteile zu entscheiden. Es muß vielmehr zunächst über die für die Unternehmensziele notwendige Aufbau- und Ablauforganisation befunden werden. Die Verantwortungsbereiche, die für eine dezentrale Organi

sation adäquate Aufgabenverteilung und deren Durchführung sind neu zu definieren; die notwendigen Informationsflüsse und deren Integration müssen klar festgelegt sein. Es wird demnach notwendig, eine dem gerecht werdende Anwendungsarchitektur zu entwerfe

n. Daraus ergeben sich dann Auswirkungen auf die Bereitstellung und Verteilung der Rechnerleistung und das Netzwerkdesign.

Es liegt auf der Hand, daß nur eine derartig gestützte Hard-und Software-Entscheidung auch geeignet ist, dem Unternehmen auf Dauer Kosten einzusparen:

Wir sehen deshalb die Organisationsentscheidung als Conditio sine qua non für den Entschluß zur Migration. Sie kann in letzter Konsequenz auch den sinnvollen Migrationszeitpunkt aufzeigen.

Der Migrationszeitpunkt kann sich darüber hinaus aber auch aus einem Leistungsmerkmal des Systems bestimmen, das bislang noch nicht angesprochen wurde, nämlich den Möglichkeiten der verteilten Datenhaltung. In verschiedenen Anwendungssituationen

ergeben sich aus dem Tagesgeschäft einzelner Abteilungen unterschiedlich starke Belastungen der Datenbanken durch hohe Änderungs- bzw. Update-Raten. Im zentralisierten R/2-System kann dies mitunter negative Auswirkungen auf die Leistung der Nachbarber

eiche nach sich ziehen. Es entsteht also ein Engpaß, den nur der Einsatz einer verteilten Datenbank grundlegend beseitigen könnte.

Da aber die technischen Möglichkeiten heute noch keine verteilte Datenhaltung erlauben, ist das Problem auch in R/3 bisher nicht gelöst.

Dementsprechend kann auch der R/3-Einsatz nicht die entscheidende Entlastung bringen; eine Situation, die für den mittelfristigen Verbleib im R/2 sprechen kann.

Aufgrund der heute noch begrenzten Leistungsfähigkeit der Client-Server-Architekturen

kann R/3 zum aktuellen Zeitpunkt noch kein Zielsystem für Installationen mit mehr als 250 Usern sein. Diese Kunden werden die Migrationsentscheidung sinnvollerweise vertagen.

Migrationskandidaten sehen wir daher eher im R/2-Mittelstandsbereich - wie zum Beispiel bei Kunden der Kompaktrechnerklasse. Diese müssen allerdings ihre Entscheidung von der Verfügbarkeit der einzelnen R/3-Applikationen abhängig machen.

Der Mitarbeiter-Skill muß gut geplant sein

Von wesentlichem Einfluß auf die R/3-Entscheidung ist der Skill und die Erfahrung der Mitarbeiter mit Unix-Umgebungen und Client -Server -Architekturen. Erfahrungsgemäß bedarf es eines hohen Aufwandes, Mitarbeiter der System- und Anwendungsentwic

klung beziehungsweise -betreuung in ihrem Know-how grundsätzlich und vollständig umzustellen. Neben Motivationsproblemen, die möglicherweise bestehen ,bedeutet der Wechsel für langjährige Mitarbeiter mit Mainframe-Orientierung eine erhebliche Umstellung

in ihrer Denk- und Arbeitsweise, die bedacht und vorbereitet werden muß.

Alles in allem kann dieser Faktor zwar nicht die grundsätzliche Entscheidung für oder gegen R/3 beeinflussen. Er ist aber bedeutsam für das Timing der Migration (vgl. Abbildung 3).

R/2-Modifikationen erschweren den Übergang

Die Migrations- beziehungsweise Systementscheidung hängt letztlich auch vom Anteil der SAP-Anwendungen am Gesamt-Anwendungsportfolio und damit von der Notwendigkeit ab, eigene Anwendungsentwicklung und maintenance betreiben zu müssen. Unternehmen

, in denen die SAP-Anwendungen eine untergeordnete Rolle spielen, werden zwangsläufig weniger auf die Verfügbarkeit der R/3-Welt angewiesen sein .Ihre Entscheidung wird vielmehr davon abhängen, welche Aktualität die übrigen Anwendungen besitzen und welc

hen Weg die vorhandenen Eigenentwicklungen nehmen.

Wichtig für die Migrationsentscheidung ist auch die Erwartung und die Einstellung des Managements zur Downsizing -Strategie. Verfolgt das Unternehmen das Ziel, die Informationsverarbeitung auf diesem Weg zu flexibilisieren, so bedeutet dies zwang

släufig eine höhere Priorität der Migrationsfrage

Umfangreiche Modifikationen am bisherigen R/2-System lassen die Migration zu einem sehr aufwendigen Projekt werden. Die Entscheidung zur Migration ist nach unserer Einschätzung ein günstiger Zeitpunkt, die Modifikationen kritisch zu hinterfragen

und soweit möglich zu beseitigen. Künftige Releasewechsel profitieren in jedem Fall von dieser Maßnahme.

Migration ist nicht nebenbei zu schaffen

Die Entscheidung für die Migration von R/2 nach R/3 ist folgenreich und sollte entscheidend von den strategischen Festlegungen des Unternehmens zur Struktur- und Ablauforganisation und zur zugehörigen IV-Plattform bestimmt werden. Sie muß über di

e bestehenden R/2-Anwendungen hinaus das gesamte Anwendungsportfolio, dessen Lifecycle-Status und das Potential der Mitarbeiter berücksichtigen.

Das Problem der technischen Migration ist durch die Entwicklungspolitik der SAP etwas entschärft. Es ist reduziert auf die Datenkonvertierungs -Problematik. SAP wird für die Konvertierung des Standards Werkzeuge bereitstellen, die allerdings heut

e noch nicht verfügbar sind. Die Fragen der Konvertierung sind noch nicht abschließend gelöst.

Die Migration ist vom Kunden als Projektaufgabe aufzufassen. Sie kann nicht en passant erledigt werden, sondern erfordert eine entsprechende Beachtung des Managements.