SAP Landscape Optimization

Inhalt dieses Artikels:
Mehraufwand vermeiden | Schnittstellen beachten | Reorganisation

Landscape Optimization Projekten haftet oft ein Manko an: Die beiden Phasen Konzeption und technische Umsetzung verlaufen häufig organisatorisch und ablauftechnisch nahezu unabhängig voneinander – und Prozess-Spezialisten skizzieren ein Übergangsszenario bis hin zu einem Sollkonzept, das im Konflikt steht mit einer technisch optimalen Umsetzung. Wie man einen solchen Bruch vermeiden kann, dies erläutern Heinz-Jürgen Klatte und Harald Kreutzer in der aktuellen Ausgabe des Spezial-Magazins S@PPORT:

Fusionieren zwei Unternehmen, sollen durch eine Verschmelzung der beiden SAP-Systeme in der Regel Synergien im Bereich Infrastruktur sowie in der Abwicklung gemeinsamer Prozesse genutzt werden. Eine solche Systemverschmelzung ist ein tiefer Eingriff in bestehende Systeme und Prozesse, so dass neben der IT potenziell auch alle Fachabteilungen betroffen sind. Die Aufwände für Konzeption, Test und System Downtime für die Zusammenführung sind erheblich – eine verlässliche Planung und Einschätzung der Machbarkeit wird essenziell.

Durch die frühzeitige Einbeziehung des für die Umsetzung notwendigen technischen Know-hows können ungeplante Mehraufwände vermieden werden, die durch zeitliche Verzögerungen, Zusatz- bzw. Eigenentwicklungen, Tool-Anpassungen, Mehrfacharbeiten sowie manuelle Arbeiten entstehen. Nicht zuletzt muss die Revisionssicherheit gewährleistet sein.

Andernfalls tauchen oft folgende Probleme auf:

	Für Analysezwecke werden unnötig Eigenentwicklungen produziert, obwohl verlässliche Tools existieren. So kennt nicht jeder das SAP-Standard-Tool „Cross System Viewer“. Mit ihm können zum Beispiel die Tabellen zweier Systeme verglichen werden, um unterschiedliche Objekte mit gleichen Schlüsseln aufzufinden. Ebenfalls eher unbekannt ist ein Tool, das alle Programme und Formulare auffindet, die von einer Datenumstellung bzw. -umbenennung betroffen sind.
	Berechtigungskonzepte werden bereits in der Analysephase eingehend untersucht. Eine Arbeit, die auch später erfolgen kann, da kein Werkzeug für deren automatische Übertragung existiert.
	Datenmigrationen werden per Batch-Input eingeplant, obwohl Tools zur Verfügung stehen, bei denen ein eigentlich gewünschter Erhalt von Historien- bzw. Altdaten möglich ist.
	Analyseergebnisse werden nicht in der spezifischen, vom später eingesetzten Tool benötigten Form, dokumentiert. Die Folge sind Mehrfacharbeiten.
	Die Entscheidung, ob die Systemzusammenführung mit Eigenentwicklungen oder mit professionellen Tools vorgenommen werden soll, erfolgt ohne ausreichende fachliche Grundlage. Häufig wird "mit Kanonen auf Spatzen geschossen". Beispielsweise benötigt die Ausgliederung einer Vertriebsgesellschaft nicht per se ein mächtiges Tool. Je nach Ausgangslage reichen dafür die relativ einfachen Standardkopierfunktionen von SAP aus. Anders herum erkennt man oft zu spät, dass ein Tool-Einsatz unumgänglich ist.
	Das Zielsystem wird primär aufgrund des zu bewegenden Datenvolumens gewählt. Vor dem Hintergrund kostenintensiver Laufzeit – die Datenmigration soll möglichst nur ein Wochenende beanspruchen – wird vielfach die Überführung des kleineren Datenbestandes (A) in den großen (B) eingeplant. Angesichts mehrerer technischer Aspekte muss diese Wahl aber nicht die beste sein. Umnummerierungen beispielsweise lassen sich einfacher während des Datentransfers als später im Zielsystem durchführen. Müssen die Daten in B also später umnummeriert werden, könnte der Datenweg von B nach A günstiger sein. Handelt es sich bei A zum Beispiel um ein Finanzsystem und bei B um ein Logistiksystem, empfiehlt sich die Datenmigration von B nach A aufgrund der sensiblen Finanzdaten, bei denen die Beziehung Buchung-Beleg erhalten bleiben muss. Ein Erhalt dieser Beziehung in B als Zielsystem wäre zudem nur mit sehr komplexen Datenumsetzungen möglich und würde letztlich die Revisionssicherheit gefährden.

Ein weiterer Aspekt bei der Wahl der Datenmigrationsrichtung ist die Anzahl der Schnittstellen, mit denen die Systeme nach außen kommunizieren. Findet bei den zu transferierenden Daten eine Umnummerierung statt, muss diese auch in den dazugehörigen Schnittstellen durch ein temporäres Mapping nachvollzogen werden. Nur so bleibt gesichert, dass zum Beispiel eine eingehende Bestellbestätigung eines Lieferanten der Bestellung zugeordnet werden kann, die vor der Umstellung versendet wurde.

Verfügt nun ein System über sehr viele Schnittstellen, so kann deren Anpassung aufwändiger sein als die gesamte Datenmigration. Das eigentlich zu transferierende System sollte dann eher zum Zielsystem werden, bei dem keine Umnummerierung stattfindet.

Schließlich wird die Übertragungsrichtung der Daten vom Regelwerk des eingesetzten Tools sowie seiner für die spezielle Datenmigration benötigte Anpassung beeinflusst. Wurde zum Beispiel der Materialstamm in A um eigene Felder erweitert, bedarf deren Übertragung in der Regel einer individuellen Tool-Anpassung. Der Aufwand dafür ist abzuwägen gegen den Aufwand der umgekehrten Datenübertragungsrichtung.

Die Frage der Umsetzung wird mit dem Verweis auf mächtige Tools beantwortet, ohne dass die nicht maschinell umstellbaren Objekte bekannt sind. Deren Umstellung sollte aber parallel zur maschinellen Umstellung eingeplant werden, um zeitliche Verzögerungen und Mehraufwände zu vermeiden. Maschinell nicht umsetzbar sind der Umbau von Schnittstellen, die Umorganisation von Jobs bzw. Programmen, die im Hintergrund oder nachts laufen oder auch der Wegfall von Jobs, die zwischen den Systemen Daten austauschen, zum Beispiel für eine Kalkulation über bisherige Systemgrenzen hinweg.

Ohne Kenntnis der Tools wird schließlich der Zeitbedarf einer Umstellung oft falsch eingeschätzt, da die genauen Zeiten für Tests, manuelle Vorgänge und Nachlaufprogramme fehlen.

Auch bei der Umstellung der Organisationsstruktur innerhalb eines SAP-Systems führt der frühzeitige Blick auf die konkrete Datenmigration sowie die dafür benötigten Landscape Optimization Tools zur Minimierung von Projektkosten und Zeitaufwand. Der oftmals wichtigste Aspekt, der sich aus der technischen Sicht ergibt, ist die Entscheidung, ein neues Zielkonzept in zwei oder mehr Schritten statt in nur einem zu erreichen.

Der Grund hierfür liegt in folgendem Konflikt: Je größer die Veränderungen zwischen Ausgangs- und Zielsituation sind, desto aufwändiger ist die Anpassung von Stamm- und Bewegungsdaten und umso komplexer muss dies in einem Tool abgebildet werden. Deshalb kann der Weg über einen Zwischenschritt günstiger sein, weil dann die aufwändige Tool-Anpassung entfällt. Vielmehr führen einfache Datenumsetzungsregeln und geringer manueller Aufwand zu schnellem Erfolg. Beispielsweise kann die bei einer Reorganisation gleichzeitig eingeplante Einführung neuer Funktionen in der Regel einfacher erreicht werden, wenn sie in einem extra Schritt hinzugenommen werden. Und bei genauer Kenntnis der Landscape Optimization Tools ist eine Datenvorbereitung im Produktivsystem bereits im Vorfeld der eigentlichen Umstellung möglich, was zu verkürzter System Downtime führt.

Manchmal eröffnet der Blick auf die Technik auch neue Alternativen. Soll zum Beispiel eine bestehende Gesellschaft in eine Produktions- und eine Vertriebsgesellschaft aufgetrennt werden, so besteht nicht nur die Möglichkeit, die Gesellschaften nacheinander auszugliedern. Man kann einfach einen Schritt sparen und die bestehende Gesellschaft jeweils abspecken – hin zu einer Vertriebs- bzw. zu einer Produktionsgesellschaft.

Landscape Optimization Projekte werden umso erfolgreicher, je frühzeitiger diejenigen, die Konzepte und Übergansszenarien unter einem betriebswirtschaftlichen Blickwinkel erstellen, in die stete Diskussion mit den Verantwortlichen der technischen Datenmigration treten. So werden die Projektphasen organisatorisch und ablauftechnisch miteinander verzahnt und der Projektablauf optimiert.

Nähere Informationen in der neuesten Ausgabe von S@PPORT .
Der Verlag GmbH behält sich alle Rechte am Artikel vor. © 2005 MarkIT Communication