ERP: SAP-Release-Wechsel mit System Landscape Optimization (SLO) kombinieren

19.11.2007
Von Andreas Schneider-Neureither
System Landscape Optimization (SLO) eignet sich für Migrationen in SAP-Umgebungen. Die Methoden und Werkzeuge können Firmen aber auch beim Umstieg von SAP R/3 auf ERP 6.0 helfen.

Viele betriebliche Veränderungen haben starke Auswirkungen auf die vorhandenen SAP-Systeme, zumal die IT-Abteilungen immer weniger Zeit zur Anpassung haben. Zu den typischen Anforderungen zählt es, Mandanten, Buchungskreise und sonstige SAP-Organisationseinheiten zu zerlegen oder zusammenzuführen sowie Stammdaten zu harmonisieren. Zudem wollen Unternehmen ihre älteren SAP-Releases auf ERP 6.0 migrieren. Der größte Engpass bei diesen Projekten sind die Fachbereiche, die durch ihr Tagesgeschäft bereits ausgelastet sind und zusätzlich noch die veränderten Systeme intensiv testen müssen. System Landscape Optimization (SLO) bietet die Möglichkeit, einen Release-Wechsel mit Standardisierungs-, Harmonisierungs- und Konsolidierungs-Projekten zu verbinden.

Zugriff auf Tabellenebene

SLO ist ein Migrationsvorgehen im SAP-Umfeld, das nicht, wie üblich, über die Anwendungsschicht die Daten in Systeme überführt, sondern unmittelbar in den Tabellen Geschäftsinformationen manipuliert. Das Vorgehen stammt aus der Zeit, als Firmen von R/2 auf R/3 umgestiegen sind. Es wurde dann zur R/3-R/3-Migrationsmethode weiterentwickelt und stellt heute Tools für die aktuellen SAP-Releases bereit.

SLO-Projekte fallen an, wenn Firmen Unternehmensteile ausgliedern, etwa Werke oder Profit-Center. Dabei müssen Mandanten, Buchungskreise und Werke verschmolzen werden. Hinzu kommt die Umstrukturierung von Unternehmen, wie das rückwirkende Splitten von einem Buchungskreis auf einen bestimmten Stichtag. SLO-Tools erlauben es, Tabelleninhalte zu verändern, zu löschen und einem anderen Schlüssel zuzuordnen. Durch ein systematisches Vorgehen lassen sich inkonsistente Datenbestände vermeiden.

SLO-Projekte beginnen mit der Systemanalyse

Den Auftakt von SLO-Projekten bildet eine genaue Analyse der betroffenen Systeme. Will ein Unternehmen beispielsweise zwei Mandanten, die in zwei unterschiedlichen Systemen angelegt wurden, in eine einzige ERP-Umgebung konsolidieren, muss das Werkzeug zuerst das Repository und dann das Mandanten-unabhängige Customizing auf mögliche Konflikte untersuchen. Danach prüfen Experten, ob die implementierten Prozesse sowie Nummernkreise von Stamm- und Bewegungsdaten kompatibel sind. Dabei kommen mögliche Konflikte zum Vorschein.

Die identifizierten Konflikte lassen sich fachlich in Form von Regeln lösen. Aus dem Regelwerk erzeugt das SLO-Werkzeug Umsetzungsprogramme. Um die Konsistenz der Daten entsprechend dem SAP-Datenmodell sicherzustellen, findet zusätzlich eine Fremdschlüsselprüfung statt, welche die im Data-Dictionary definierten Schlüsselbeziehungen prüft. Die Tools protokollieren diese Schritte, um den Anforderungen der Wirtschaftsprüfer zu genügen.

Grundsätzlich ist es möglich, die SLO-Methode auch mit Standardmethoden zu kombinieren. So kann eine Umsetzung von Logistikdaten mit SLO erfolgen, die Konvertierung der Finanzdaten hingegen nach herkömmlichen Migrationsverfahren wie SAP Legacy System Migration Workbench (LSMW) oder Batch Input.

Bei SAP-Upgrades kaum Ausfallzeit

Darüber hinaus können SLO-Verfahren beim SAP-Release-Wechsel helfen. Es ist möglich, unter Einsatz von SLO die alte und neue ERP-Software parallel zu betreiben und die Daten stückweise (mandantenweise) vom alten ins neue Release zu übertragen. Auf diese Weise lässt sich der Systemstillstand (Downtime) auf mehrere Wartungsfenster verteilen: Immer nur ein Mandant fällt kurzzeitig aus. Durch Logging-Funktionen können Anwender den Dialogbetrieb in einzelnen SAP-Transaktionen sogar während der Migration des betreffenden Mandanten aufrechterhalten und so die effektive Downtime auf unter eine Stunde senken. Da dies selbst bei Krankenhäusern einem üblichen Wartungsfenster entspricht, bezeichnet man dieses Verfahren bereits als "Zero Downtime".

Konsistente SAP-Migration

Voraussetzung für eine konsistente Migration ist, dass es im Zielsystem keine abweichenden Programme und Datenstrukturen (Repository-Objekte) gibt. Dabei sind zwei Fälle zu unterscheiden: Entweder es gibt bereits ein Zielsystem mit dem gewünschten höheren oder gleichen Release-Stand, in das die Mandanten des Quellsystems eingefügt werden. Oder das Unternehmen muss das Zielsystem erst errichten. Im ersten Fall ist das Repository abzugleichen, bei Letztgenanntem erfolgt der Aufbau, wie aus den Abbildungen hervorgeht.

Das Projektteam kopiert das Quellsystem im Release-Stand 4.6C oder 4.7 und löscht mit Hilfe des "Client Carriers" daraufhin die mandantenabhängigen Daten. Unabhängig vom Produktivbetrieb laufen im leeren Zielsystem die SAP-Standardverfahren für Upgrades und die Unicode-Konvertierungen ab. Da weder Stamm- noch Bewegungsdaten vorliegen, dauert dieser Vorgang nicht lange.

Unabhängig davon, wie das Zielsystem erstellt wurde, beinhaltet das "Zero Downtime"-Verfahren einen Testzyklus, bei dem das Qualitätssicherungssystem als Datenquelle dient.

Unicode-Konvertierung beim SAP-Umstieg

Dabei werden die Konsistenz, Funktionalität, Performance und gegebenenfalls erfolgreiche Unicode-Konvertierung geprüft. Die Echt-Migration erfolgt nach erneuter Löschung der mandantenabhängigen Daten im Zielsystem. In einem Mehrmandanten-System kann während der Übertragung in anderen Mandanten weitergearbeitet werden.

Schreibzugriffe auf den betroffenen Mandant sind nur beim "Zero Downtime"-Verfahren und nur in vereinbarten Transaktionen möglich. Um dabei Datenkonsistenz zu gewährleisten, werden die von diesen Transaktionen betroffenen Tabellen identifiziert und Logging-Funktionen aktiviert. Nach der Hauptmigration erfolgt eine "Delta-Migration", in deren Rahmen das Projektteam die aufgelaufenen Änderungen ins Zielsystem überträgt. Danach kann der Dialogbetrieb zum Zielsystem übergehen. Während der Datenübertragung lassen sich Geschäftsinformationen nach Unicode konvertieren, also in einem Schritt mit dem Upgrade, nicht in einem separaten Vorgang.

Das Problem von MDMP-Systemen bei der Konvertierung zu Unicode ist, dass unter Verwendung von unterschiedlichen Codepages in die gleiche Datenbank geschrieben wurde. Die jeweilige Codepage muss bekannt sein, um einen Datensatz inhaltlich korrekt in Unicode zu überführen. Nicht alle SAP-Tabellen enthalten jedoch einen Sprachschlüssel, der dies ermöglicht. Im Standardverfahren wird mit Zeichenkettenvergleichen gearbeitet, um Datensätze einer Codepage zuzuordnen, die keinen solchen Schlüssel besitzen. Dabei sind manuelle Nacharbeiten nötig.

"Zero Downtime"-Verfahren wenden dagegen einfachere Methoden an, die Ersatzschlüssel heranziehen, um die Codepage zu bestimmen. Das kann beispielsweise der Mandant oder Buchungskreis sein. Mit dem "Zero Downtime"-Verfahren soll sich die Ausfallzeit des produktiven SAP-Systems bei Upgrades und Unicode-Konvertierungen so verringern lassen, dass sie den Standard-Wartungsfenstern des Unternehmens entspricht und somit keine Zusatzkosten anfallen.

ERP-Bewegungsdaten übernehmen

Die SLO-Methode hat den großen Vorteil, dass sich historische Daten, also alle Bewegungsdaten, Änderungsbelege und der Belegfluss, komplett übernehmen oder umsetzen lassen. Somit sind Unternehmen nicht gezwungen, vor der Migration laufende Kontrakte, Projekte oder Belege abzuschließen. Da das SLO-Verfahren die Nummernkreise für Stamm- und Bewegungsdaten beliebig konvertieren kann, fallen für den Nutzer nach der Migration praktisch keine Umstellungsarbeiten an. Sie können sofort im konvertierten System arbeiten, was zudem Schulungsaufwand und die Einarbeitungszeit erspart.

Tabellendaten im ERP-System rückwirkend anpassen

Das SLO-Verfahren erlaubt es, historische Daten beliebig zu verändern, das heißt es können alle Tabellen der Datenbank rückwirkend an die betriebswirtschaftlichen Anforderungen angepasst werden. Die Standardverfahren für Migrationsprojekte – neues Customizing, Übernahme von Stammdaten, Salden, Beständen und offenen Posten – genügen diesen Anforderungen nicht.

Darüber hinaus kann beim SLO-Einsatz die Umstellung der Systeme in der Regel an jedem beliebigen Wochenende stattfinden. Das Standardvorgehen ist dazu im Gegensatz immer auf den Beginn eines Geschäftsjahres oder –quartals festgelegt, was eine massive Einschränkung darstellt: Der Migrationszeitpunkt muss mit den Quartals- und Jahresabschlüssen zusammenfallen.

Einige Anbieter sind in der Lage, SLO auch Release-übergreifend anzubieten. Auf diese Weise lassen sich SAP-Harmonisierungs- und –Release-Wechsel-Projekte in einem Schritt vorzunehmen, was die Belastung der Fachbereiche minimiert. (fn)