Von Axel Szelepusa, REALTECH AG
Gründe, warum Unternehmen ein SAP-System nach Unicode migrieren müssen, können vielfältig sein. Zum einen ist die Erschließung weiterer Wirtschaftsräume zu nennen. SAP-Kunden werden unter Umständen dazu gezwungen Unicode einzuführen, da sich die dafür notwendigen Sprachen innerhalb der Software nur mit einer anderen Codepage darstellen lassen als der aktuell genutzten. Zum anderen lässt die SAP-Releasepolitik bei neueren Produkten kein MDMP (Multi-Display, Multi-Processing) mehr zu. Dies bedeutet, dass nur noch eine Codepage verarbeitet werden kann.
Bei der SAP wird nicht mehr diskutiert, ob es in Zukunft nur noch Unicode basierte Produkte geben wird, sondern ausschließlich darüber ab wann dies der Fall sein wird. Über kurz oder lang wird also jeder Betreiber eines SAP-Produktes vor der Herausforderung stehen, seine Systeme auf die Unicode-Codepage umstellen zu müssen. Bei der Migration ist allerdings zu beachten, dass in der Regel mit erheblichen Ausfallzeiten der betroffenen Systeme zu rechnen ist.
Das von der SAP entwickelte Unicode-Migrationsverfahren entspricht zum größten Teil dem Verfahren zur Migration von SAP-Systemen auf andere Betriebssysteme oder Datenbanken, mit dem einzigen Unterschied, dass hier zunächst die Programme in der Datenbank auf Unicodefähigkeit geprüft und angepasst werden müssen. Bei MDMP-Systemen müssen darüber hinaus Datensätze, die nicht automatisch (über einen Sprachenschlüssel) einer Codepage zugeordnet werden können, manuell nachgepflegt werden. Diese Schritte können sehr aufwendig sein, aber noch im laufenden Betrieb durchgeführt werden.
Die eigentliche Konvertierung der Daten findet während eines Exports aller relevanten Datensätze statt. Um diese konsistent halten zu können, muss das System jedoch während dieses Vorgangs angehalten werden. Danach wird die Datenbank gelöscht und mit den nach Unicode konvertierten Daten wieder neu geladen. Die Ausfallzeit der Systeme ist direkt von der Größe der Datenbank und den verfügbaren Hardwareressourcen abhängig. Erst nach abschließenden Tests zur Überprüfung von Funktionalitäten und der Vollständigkeit aller Daten, kann das System wieder in Betrieb genommen werden. Anwender können jetzt wieder in vollem Umfang arbeiten.
Die beschriebene Situation fordert von IT-Verantwortlichen eine genaue Planung der Umstellung. Das Management muss involviert sein, da während der Migration unternehmenskritische Geschäftsprozesse stillstehen. Produktionsausfälle müssen unter Umständen in Kauf genommen werden, die mit erheblichen finanziellen Einbußen verbunden sein können. Resultierend daraus gibt es kaum Termine, an denen die Migration geplant werden kann. Scheitert diese, so können bis zur Wiederholung des Projektes Monate vergehen. Dies kann dramatische Auswirkungen auf das Business des Unternehmens mit sich bringen.
Ein Verfahren, diese Migration unterbrechungsfrei durchführen zu können, wird seit kurzem von der REALTECH AG, mit Sitz in Walldorf, angeboten. Aufgrund konkreter Marktanforderungen wurde das sogenannte ZERO DOWNTIME-Verfahren entwickelt, das den einzukalkulierenden Produktionsausfall gegen Null gehen läßt.
Das REALTECH ZERO-DOWNTIME-Verfahren
Erste Voraussetzung für die Durchführung einer ZERO DOWNTIME-Migration ist der Aufbau eines Schatten-Systems als identische Kopie des produktiven SAP-Systems. Dieses übernimmt während der technischen Migration alle Funktionen des produktiven Betriebs. Unmittelbar nach dem Umschalten der Benutzer und Interfaces auf die System-Kopie wird die technische Migration mit dem von der SAP standardisierten Verfahren auf dem Produktiv-System durchgeführt. Alle Interaktionen der Benutzer und Schnittstellen werden aufgezeichnet und nach erfolgreicher Umstellung des Produktiv-Systems dort exakt so verbucht, wie es in der System-Kopie der Fall war.
Zur Aufzeichnung der Interaktionen während der Umstellung wird das von SAP validierte Add-On IM/3 (REALTECH’s Interface Manager) genutzt. Der Interface Manager zeichnet jede Transaktion auf und verbucht diese nach erfolgreicher Migration im Produktivsystem. Transparenz der Aktionen wird durch die Monitoring-Funktionen des IM/3 gewährleistet.
Als Alternative zum IM/3 kann SAP-XI (Exchange Infrastructure) die Aufzeichnung und das „Reprocessing“ der Interaktionen übernehmen. In dieser Variante muss allerdings mit erhöhtem Aufwand in der Vorbereitung gerechnet werden.
Der nach der Migration entstehende Aufwand für Konfiguration und das Nachbuchen der Interaktionen hängt direkt vom Umfang der aufgezeichneten Daten ab. Sinnvoll ist es, den Betrieb für diese Zeitspanne auf genau die kritischen Geschäftsprozesse einzuschränken, die das ZERO DOWNTIME-Verfahren betriebswirtschaftlich sinnvoll machen.
Für Produkte wie mySAP ERP2005 ist kein MDMP mehr zugelassen. Besteht die Notwendigkeit eines Releasewechsels von Release 4.6x als bestehendes MDMP-System (eine häufige Konstellation) auf mySAP ERP2005 werden Zwischenschritte über den Releasewechsel nach SAP 4.70 Enterprise und die anschließende Migration nach Unicode notwendig, um den gewünschten Releasestand zu erreichen. Das wären bei dieser ungünstigen, aber nicht unüblichen Ausgangslage, drei zu planende Systemausfälle für die Produktion. Zu viele Ausfälle, auch für Unternehmen deren Geschäftsprozesse nicht zwingend rund um die Uhr zur Verfügung stehen müssen.