CW: Die Jahreszahlen-Umstellung ist gelaufen, jetzt treibt der Euro die Softwarebranche um. Es riecht nach einer Kampagne, um das nächste Geschäft zu inszenieren.
Hoffmann: Nach den Y2K-Erfahrungen wird vielerorts eher locker an das Thema Euro-Umstellung herangegangen. Es herrscht die Ansicht: Das Jahr 2002 ist ja noch weit weg und somit genügend Zeit. Dabei wird die Komplexität der Thematik nicht beachtet, und man läuft am Ende Gefahr, dass es in Sachen Beratung und Personal knapp wird.
CW: Die Doppelwährungsphase scheint Anwendern keine sonderlichen Probleme zu machen. Was sollte sie jetzt noch alarmieren?
Hoffmann: Bei Umstellung auf die Doppelwährungsphase ging es ausschließlich um die Betrachtung und Anpassung des externen Rechnungswesens auf eine neue Währung - die vorhandene Hauswährung blieb davon unberührt. Damals wurde in erster Linie der Euro als neue zusätzliche Fremdwährung eingerichtet, die Formate der Zahlungsträger und das Zahlprogramm selbst wurden angepasst sowie die Währungstabellen ergänzt. Dies war ohne allzu große Anstrengungen machbar.
Die Einführung des Euro stellt einen historisch einmaligen Vorgang dar. Alle betroffenen Unternehmen müssen ihre Hauswährung und damit den kompletten Datenbestand umstellen. Alleine aus diesem Grund sind diese beiden Projekte vom Aufwand her nicht zu vergleichen.
CW: Wie weit sind denn die Euro-Umstellungen gediehen?
Hoffmann: Anfang dieses Jahres war erst bei ungefähr zehn Prozent der SAP-R/3-Systeme die Konvertierung der Hauswährung abgeschlossen. Bei knapp 90 Prozent der Systeme wurde bislang also nur die Doppelwährung eingerichtet.
CW: Was macht diesmal die Arbeit so aufwendig?
Hoffmann: Im Vorfeld der eigentlichen Umstellung müssen zunächst alle währungsrelevanten Felder des R/3-Systems, die firmenspezifische Schnittstellen-Landschaft und letzten Endes der komplette Datenbestand selbst auf Inkonsistenzen untersucht werden. Nach deren Lokalisierung müssen diese beseitigt werden, bevor die Konvertierung auf Euro erfolgen kann.
Die Umrechnung des kompletten Datenbestandes über mehrere Jahre hinweg bringt in erster Linie in Hinblick auf die jeweilige Systemhistorie und die damit einhergehende Datenqualität Probleme an den Tag. Die Analyse und die Behebung dieser Probleme sind tatsächlich sehr zeitaufwendig. So kann sich die Analyse über Monate hinziehen, was im Hinblick auf die Gesamtprojektlaufzeit den überwiegenden Part darstellt.
CW: Welche Vorbereitungsarbeiten sind zu leisten?
Hoffmann: Ich kann jedem Unternehmen nur empfehlen, erstens intern einen Euro-Beauftragten zu benennen, der sich schon frühzeitig mit dem gesamten Thema sowie der Vielzahl der damit verbundenen Teilaspekte vertraut macht. Zweitens sind die mit der Aktion befassten Mitarbeiter möglichst bald für das Thema zu sensibilisieren. Drittens muss man die Euro-Umstellung als ein eigenes Projekt mit all den dabei üblichen Termin- und Organisationsplanungen definieren. Und viertens sollten Anwender wegen der im Einzelfall relevanten Details der gesetzlichen Vorschriften frühzeitig Kontakt mit ihrem Wirtschaftsprüfer aufnehmen.
CW: Warum haben Sie ein separates Euro-Testsystem verwendet? Und wie sollte es gestaltet sein?
Hoffmann: Damit keine Datenschiefstände oder Komplikationen auftreten, braucht man neben den vorhandenen Produktiv- und Entwicklungssystemen in jedem Fall ein eigenes Euro-Testsystem. Bezüglich der Hard- und Softwarekonfiguration sollte dieses genauso wie das Produktivsystem ausgestattet sein, damit man zuverlässige Aussagen über die Dauer der Produktivkonvertierung erhält.
CW: Wie läuft die Umstellung im Wechsel zwischen Euro-Test- und Produktivsystem ab?
Hoffmann: Man lädt für die erste Testkonvertierung den aktuellen Datenbestand des produktiven Systems komplett in das Euro-Testsystem, analysiert und behebt die Inkonsistenzen und konvertiert ausschließlich dieses System. Parallel dazu werden immer die vorgefundenen Inkonsistenzen im produktiven System behoben. Das nun hoffentlich fehlerfreie Produktivsystem wird mit den zwischenzeitlich aufgelaufenen neueren Daten wieder für die nächste Analyserunde auf das Testsystem geladen etc. Erst wenn die letzte Testkonvertierung ordnungsgemäß abgeschlossen ist, wird das produktive System umgestellt.
CW: Bei der Umstellung in Ihrem Unternehmen dauerte die erste gegenüber den folgenden Testphasen auffallend lang. Warum?
Hoffmann: In dieser ersten Phase tauchen besonders viele Dateninkonsistenzen auf. Die eigentliche Schwierigkeit liegt darin, die Probleme zu lokalisieren und zu beheben. Weil die Fehlerbehebung in beiden Systemen parallel erfolgt, ist der Korrekturaufwand des zweiten und dritten Testlaufs nicht mehr so beträchtlich. Dann erscheinen bei optimalem Projekt-Management und Einsatz der erforderlichen Tools überwiegend solche Dateninkonsistenzen, die sich relativ schnell beheben lassen.
CW: Was sind die kritischen Faktoren einer Umstellung, und wo treten die meisten Probleme auf?
Hoffmann: Die entscheidenden Faktoren sind in Stichworten die Systemhistorie, die bisherige Qualität der System- und Datenpflege, der Zustand der Altdaten, die Anzahl und Art der Inkonsistenzen, die Bereiche Personal- und Hardwareressourcen sowie das entsprechende Projekt- und Qualitäts-Management, was auch die ordnungsgemäße Projektdokumentation einschließt. Zwei Faktoren jedoch bedürfen einer genaueren Betrachtung: die Schnittstellen zu Fremdsystemen und das Thema Archivierung. Beide verlangen ausgesprochen detaillierte Konzeptionen, die man sehr frühzeitig erstellen sollte und die der Abstimmung mit der jeweiligen Wirtschaftsprüfungsgesellschaft bedürfen.
CW: Mit welcher Dauer sollten Anwender für das Gesamtprojekt rechnen?
Hoffmann: SAP prognostiziert beispielsweise eine durchschnittliche Projektlaufzeit von etwa sechs Monaten. Der tatsächliche Zeitbedarf für das Gesamtprojekt ist von mehreren Faktoren abhängig. Je umfangreicher, schnittstellenreicher, modifizierter und älter das System und dessen Datenbestand sind, desto länger kann die Laufzeit werden.
CW: Je mehr ein Anwender sein System getuned hat, desto mehr Arbeit?
Hoffmann: Nein. Entscheidend sind der Datenbestand und der Umfang des umzustellenden IT-Systems. Die Ausprägung der Module, ihr Detaillierungsgrad und ihre Nutzungstiefe werden sich im Umstellungsaufwand niederschlagen. Wer beispielsweise das Modul Materialwirtschaft mit allen Funktionalitäten nutzt, kann leichter auf Dateninkonsistenzen stoßen als jemand, der es nur für das Bestellwesen verwendet.
Wer R/3-Module weitreichend nutzt, wird es auch mit einer größeren relevanten Datenmenge zu tun haben. Und je mehr Daten im System sind, desto mehr Schiefstände sind allgemein zu erwarten. Schließlich entstehen in solchen Fällen aus der Systemhistorie hinsichtlich Vorsystem-Nutzung und Schnittstellen zu R/3-fremden Anwendungen mögliche Problemquellen.
CW: Ist der Umstellungsaufwand bei den nicht so verbreiteten SAP-Modulen höher?
Hoffmann: Nicht generell. Es gibt auch bei den gängigen Modulen einigen Aufwand für manuelle Nachbearbeitung, beispielsweise hinsichtlich der Erinnerungswerte in der Anlagenbuchhaltung, der Mahnbeträge, der Betragsangaben beim Zahlungseingang und -ausgang oder aber den Preiskonditionen in der Logistik. Lediglich bei Einsatz des Moduls Konsolidierung können je nach vorliegendem System größere Arbeiten erforderlich werden.
CW: Die effektive Umstellung des Produktivsystems selbst erfordert schließlich einen Systemstopp. Für wie lange?
Hoffmann: Während der eigentlichen Konvertierung ist für den Lauf der Standard- und Sonderprogramme der Phasen: "Fill", "Generation", "Conversion" und "Recon" verfahrensbedingt eine Systemsperre notwendig. Während dieser so genannten Systemsperrzeit hat mit Ausnahme der Mitarbeiter des Projektteams kein User Zugriff auf das umzustellende System. Das dauert in kleinen Umgebungen erfahrungsgemäß einen Tag, bei großen Systemen ist die Zeitskala nach oben offen. In den meisten Fällen dürfte der Stillstand im Bereich von einem bis fünf Tagen liegen. Dies setzt jedoch voraus, dass wirklich alle relevanten Vorarbeiten auf einem separaten Euro-Testsystem erledigt wurden.
CW: Dafür bieten sich natürlich lange Wochenenden wie zu Ostern oder Pfingsten an. Sind das im Jahr 2001 dann die günstigsten Zeitpunkte?
Hoffmann: In der Regel wird man möglichst bald nach einem abgeschlossenen, testierten und dokumentierten Jahresabschluss zu einem Stichtag umstellen. Ein Beispiel: Bei einem Unternehmen endet das Geschäftsjahr mit dem Kalenderjahr. Der testierte Abschluss liegt im Februar vor, so dass man idealerweise im selben Monat konvertiert, rückwirkend zum 1. Januar. Wer also an eine Umstellung bald nach Ende des Geschäftsjahrs im Januar 2001 denkt, sollte bei mindestens einem halben Jahr Aufwand jetzt mit den Planungen beginnen.
CW: Geschäfts- und Kalenderjahr stimmen häufiger überein, ergo dürften wir Anfang 2001 den größten Teil der Umstellungen erleben, weil es sonst nicht in den Euro-Fahrplan passen würde.
Hoffmann: Genau. Das ist der Zeitraum, zu dem wir mit der größten Zahl der Umstellungen rechnen. Generell ist ein Jahresanfang in der Tat der günstigste Termin, nahe am Jahresabschluss, um sowohl innerhalb der vorgeschriebenen Frist als auch ohne großen Termindruck zu konvertieren. Die Deadline ist gesetzlich vorgegeben: Spätestens zum 1. Januar 2002 muss das System auf die neue Hauswährung Euro umgestellt sein.
CW: Was sollten die Unternehmen hinsichtlich der personellen Ressourcen bedenken?
Hoffmann: Sie sollten vor allem nicht vergessen, die eigenen Personalressourcen in den Fachabteilungen für das Konvertierungsprojekt und die Umstellung ausreichend einzuplanen. Das heißt nicht nur, dass die Fibu-Spezialisten an einem entscheidenden Wochenende vor Ort sein müssen, da die Euro-Konvertierung kein reines Problem von DV und Fibu ist. Sie betrifft alle Unternehmensbereiche entsprechend der jeweils eingesetzten SAP-Module und der angeschlossenen Fremdsysteme, sprich Schnittstellen.
Je näher der letztmögliche Umstellungstermin rückt, desto stärker wird sich auf dem Markt die Nachfrage nach R/3-Beratern entwickeln. So werden die Möglichkeiten schwinden, schnell noch externe Ressourcen ins Projekt zu pumpen, um damit das im Vorfeld Verschlafene wettzumachen.
CW: Kann man sicherheitshalber und ökonomischerweise die einzelnen SAP-Module schrittweise umstellen?
Hoffmann: Nein. Geschäftsprozesse finden in der Regel modulübergreifend statt. Beispielsweise muss das Rechnungswesen komplett in einem Zug umgestellt werden. Die Umstellung erfolgt bei SAP R/3 auf Mandantenebene und greift somit auf alle dort eingesetzten Einheiten zurück. Es gibt lediglich zwei Ausnahmen: Die Umstellung der Module Personalwirtschaft und Konsolidierung kann unabhängig, nach Abschluss der Konvertierung des übrigen R/3-Systems, erfolgen. Im Falle des Personalwesens empfiehlt SAP, die Lohn- und Gehaltsabrechnung zusammen mit der des öffentlichen Sektors umzustellen. Die Führung der Löhne und Gehälter in Euro kann bereits vorher stattfinden.
Tschüss, DM - und R/2?Die Euro-Einführung könnte einen guten Anlass geben, gleich das SAP-System zu modernisieren. Eine Migration von R/2 auf R/3 gleichzeitig mit der Umstellung von Mark auf Euro lässt sich allerdings nicht generell empfehlen. Beratungshäuser präferieren zunächst den Umstieg auf R/3 und anschließend die Konvertierung im neuen System. Es gibt aber das alternative Szenario, nur die unbedingt notwendigen Altdaten in ein System mit der Hauswährung Euro zu übernehmen und die Historiendaten des Vorsystems in Papierform oder mittels optischer Archivierungssysteme zu verwalten. Die richtige Wahl des Szenarios hängt von der Bedeutung der Historiendaten für die Unternehmen ab.
Euro-Umstellung bei R/3Voraussetzung einer Umstellung sind die Euro-fähigen R/3-Releases 3.1 I und ab 4.0B. Zur Umstellung wird das in diesen Versionsständen integrierte Programmpaket zur Hauswährungsumstellung verwendet. Dieses Paket enthält unter anderem die erforderliche Konvertierungs- und Rundungslogik. Zusätzlich gibt es das kostenpflichtige Tool "SAP-Euro-Guide", das sich gut zur Projektdokumentation und zur Lokalisierung der fehlerhaften Datenbestände einsetzen lässt. SAP bietet von den Grundlagen bis zu Feinheiten der Umstellung Schulungen für Zielgruppen vom Programmierer bis zum Manager an. Berater halten einen Besuch im Allgemeinen nur bei komplexen Anwendungen für empfehlenswert.
Deadline und Fall-back-StrategienDie Umstellung der Hauswährung auf den Euro muss spätestens am 31. Dezember 2001 abgeschlossen sein. Ab 2002 ist die Mark gesetzlich nicht mehr zugelassen. Bei vielen Unternehmen ist der Glaube vorhanden, es gebe so etwas wie eine Karenzzeit bis zum 30. Juni 2002, dem Datum, zu dem die Mark auch als Cash-Währung verschwindet. Diese Hoffnung trügt; alle EU- und nationalen Behörden bekräftigen, dass es keine Verlängerungsfristen geben wird.
Eine Euro-Umstellung muss auf Anhieb klappen. Der Gesetzgeber hat ausdrücklich die Möglichkeit ausgeschlossen, im Problemfall zur Rechnung in Mark zurückkehren zu können. Um in dieser Vorbereitungszeit Pannen zu vermeiden, die den geplanten Umstellungszeitpunkt gefährden könnten, muss ein Notfallkonzept, das alle möglichen Risiken auflistet und gewichtet sowie das Risiko-Management beschreibt, erstellt werden. Ferner müssen Szenarien für Maßnahmen in diesen Fällen beschrieben sein. Für den Fall, dass ein Programm aussteigt, muss klar sein, wie man bei der Produktivkonvertierung vorgeht. Frühzeitig muss ein Konzept für Systemrückladung und Neuaufsetzen der Datenbank erarbeitet werden.
Abb.: Unter günstigen Voraussetzungen: Saardata war vor Projektbeginn auf dem notwendigen Euro-fähigen R/3-Release-Stand. Umgestellt wurden die Module Finanzwesen, Controlling, Anlagenwirtschaft, Projektsystem, Vertrieb und Materialwirtschaft. Quelle: Hoffmann, Saardata