Gelassenheit herrscht vor. Schließlich ist am 1. Januar 2000 die Welt nicht untergegangen. Die Umstellung auf vierstellige Jahreszahlen hat - wenn auch zuletzt mit reichlich Hektik - immerhin so gut geklappt, dass es keine Probleme gab, die sich nicht in einigermaßen akzeptabler Zeit in den Griff bekommen ließen. Die DV-Spezialisten haben bewiesen, dass sie ihr Geschäft verstehen. Wer die Y2K-Umstellung gemacht hat, ahnt, was mit dem Euro auf ihn zukommen könnte.

"Euro-fähig" ist bisher herzlich wenig: Man kann in der Regel nicht viel mehr als Geldein- und -ausgänge in Euro annehmen und ausgeben, wobei jedes Mal eine Umrechnung zur heutigen Hauswährung Mark erfolgen muss. Druckformulare und einige für den Verkehr mit Geschäftspartnern wichtige Masken sind angepasst. Den Standards DTAUS und Swift MT-940 für den elektronischen Zahlungsverkehr mit den Banken wird entsprochen. Die Triangulation, die Umrechnung zwischen der Mark und einer Fremdwährung über den Euro, funktioniert ebenso wie die Rundungsregeln.

Nur leider war es das noch nicht; denn nur für den Finanzverkehr nach außen wurden die Hausaufgaben erledigt. Intern wird weiter mit der Mark gerechnet - doch das ist ab dem 1. Januar 2002 nicht mehr gestattet. Dann muss die interne Währungseinheit, die Hauswährung, der Euro sein. Auch danach gibt es die Mark, aber nur noch bis zum 28. Februar 2002 und nur für Barzahlungen. Diese zwei Monate sind keine Karenzzeit für Nachzügler. Die Gesetze sind in diesem Punkt unerbittlich, weder in Brüssel noch in Berlin denkt jemand an Verlängerungsfristen.

Es sind noch gut eineinhalb Jahre bis zum Finale, aber das ist wenig Zeit. Es mehren sich Stimmen, dass der Aufwand größer sein könnte als beim Problem 2000. Peter Gerte, Leiter Professional Services Euro bei der Software AG (SAG), warnt: "Neben den bereits bekannten Datumsfeldern sind Betragsfelder die am meisten vorkommenden Informationsträger in den Programm- und Datenbeständen."

"Die Euro-Umstellung ist viel komplexer, schwieriger und wesentlich aufwändiger, als man es auf den ersten Blick glauben möchte", erklärt Eberhard Ramm, Geschäftsführer der Sibra GmbH, Gröbenzell. Er war schon bei einigen großen Umstellungsprojekten von Banken als Berater und Anbieter eines Umstellungs-Tools dabei. Sein Befund: "Bei den Banken sind 20 bis 50 Prozent des Coding von der Euro-Umstellung betroffen, während die Jahr-2000-Umstellung nur fünf bis zehn Prozent betraf."

Nun mag man einwenden, dass Anwender aus dem Finanzwesen vom Euro stärker betroffen sind als beispielsweise ein mittelständisches Fertigungunternehmen. Aber auch dort geht es um mehr als nur die Multiplikation von ein paar tausend Mark-Beträgen. "Bei der Euro-Umstellung muss meist sehr stark in die Daten- und Programmlogik eingegriffen werden", berichtet Euro-Spezialist Gerte.

Die Y2K-Arbeiten machen sich bezahltFür Anwender betriebswirtschaftlicher Standardsoftware ist das ein geringeres Problem. Ihre Softwarelieferanten bieten Euro-fähige Versionen und Umstellungswerkzeuge. Das kostet viel Geld - und leider auch Zeit. So spricht SAP von einer durchschnittlichen Dauer von sechs Monaten für die Anpassung.

Ralf Hoffmann, Leiter der hausinternen Euro-Umstellung beim SAP-Partner Saardata, fand dies in seinem Projekt weitgehend bestätigt. Aber mit Blick darauf, dass er trotz optimaler technischer Voraussetzungen eine Menge Überraschungen erlebt hat, mochte er in einem Interview mit der "Computerwoche" (siehe CW 15/00, Seite 17) keine Projektzeiträume mehr voraussagen.

Anwender mit einer großen Zahl selbst entwickelter Programme fangen immerhin auch nicht bei Null an. Durch die Jahr-2000-Projekte kennen sie die Vielfalt ihrer Programme, haben den Sourcecode weitgehend aktuell vorliegen und verlorene Dokumente rekonstruiert.

Aus den Jahr-2000-Arbeiten lässt sich noch etwas ableiten, meint SAG-Manager Gerte: "Als Faustformel für die Euro-Umstellung gilt: Dauer des Y2K-Projekts, multipliziert mit dem Faktor zwei bis drei - je nach Unternehmensgröße und gewählter Umstellungsstrategie." Konsequenz: "Die verbleibende Zeit wird für die meisten Unternehmen sehr eng."

Wichtig ist die Kalkulation der Projektdauer in Hinsicht auf den Zeitpunkt der endgültigen Umstellung. Es vereinfacht die Projektabwicklung, wenn man unmittelbar nach Abschluss und Testat eines Geschäftsjahrs umstellt, so dass man möglichst wenig neue Mark-Daten in Euro nachtragen muss. Weil die meisten Geschäftsjahre sich an den Kalenderjahren orientieren, das Testat für das Jahr 2001 also erst im Februar bis März 2002 vorläge, käme dann eine Umstellung zu spät.

Also wäre das Geschäftsjahr 2000 das letzte Mark-Jahr. Die meisten Euro-Experten teilen die Einschätzung von Saardata-Spezialist Hoffmann: "Wer an eine Umstellung bald nach dem Ende des Geschäftsjahrs, im Januar 2001, denkt, sollte bei mindestens einem halben Jahr Aufwand jetzt mit den Planungen beginnen." Woraus auch gleich folgt, dass es Anfang 2001 den größten Teil der Umstellungen geben dürfte - sowie den größten Bedarf an Beratern und Programmierern.

Die Einführung der neuen Hauswährung geht an den sensibelsten Nerv jedes Unternehmens, die Finanzen. Es sollte daher selbstverständlich sein, dass dieses Projekt Chefsache ist. Der Mentor des Umstellungsteams im Topmanagement muss in der Lage und willens sein, sehr schnell sehr viel zu bewegen.

Das ist deswegen so wichtig, weil die Umstellung zahlreiche Fachbereiche betrifft, die unterschiedliche Vorstellungen hinsichtlich der Zeitpläne und Wichtigkeit von Einzelmaßnahmen haben. Das Berichtswesen hantiert mit Tausenderbeträgen, der Buchhaltung hingegen ist es ein Graus, dass Rückrechnungen von Euro nach Mark immer wieder Rundungsdifferenzen von einem Pfennig oder Euro-Umrechnungen von Einzelbeträgen in den Summen kumulierte Rundungsdifferenzen im Nachkommastellen-Bereich mit sich bringen. Wie damit im Rechnungswesen umgegangen wird, muss "von oben" entschieden werden.

Die Umstellung betrifft sowohl Datenbestände als auch Programme. Eine sture Umrechnung aller Beträge aus Bestandsdaten zu einem Zeitpunkt würde viel zu lange dauern, um ein realistisches Ziel zu sein. Sibra-Geschäftsführer Ramm weist darauf hin, dass sich bei Einführung zusätzlicher Euro-Felder zum Beispiel in IMS-Datenbanken die Segmentlängen ändern und man Probleme mit den Speicherressourcen bekommen kann. Ein weiteres Problem sind die aggregierten Beträge: Summen dürfen nicht einfach umgerechnet, sondern müssen neu errechnet werden.

Hinzu kommt, dass sich auch Daten aus zurückliegenden Jahren umrechnen lassen müssen, weil man sonst keine Vergleichszahlen zur Geschäftsentwicklung mehr hätte. Dies ist ein besonderes Problem für Data-Warehouse-Anwendungen. Hier sind Entscheidungen gefordert, die auf Jahre den Informationsgehalt der Altdaten bestimmen. Wer die Umrechnungsmöglichkeiten beschneidet, beraubt sich möglicherweise äußerst wichtiger Informationsquellen.

Dabei ist zu beachten, dass man testierte Daten nicht verändern darf. Der Umgang mit den Archivbeständen ist eines der größten Probleme der Euro-Konvertierung. Schon in der Projektplanung sollten die Firmen hierzu ihre testierenden Wirtschaftsprüfer konsultieren. Große Dienstleister wie Pricewaterhouse Coopers bieten nicht nur eine Menge schriftlicher Informationen, sondern haben auch auf solche Euro-Probleme spezialisierte Berater.

Man wird in jedem Fall gezwungen sein, mehr oder weniger große Mengen an Daten seit dem letzten Testat umrechnen zu müssen. Dabei werden, so die Erfahrungen von Saardata, mit Sicherheit Inkonsistenzen zu Tage treten. Die Gründe dafür sollten analysiert werden. Es gibt kaum eine günstigere Möglichkeit, Grundlagen für eine künftig bessere Qualität der Datenpflege zu schaffen.

Ein zweites großes Problem berührt schon die Programme: die Schnittstellen. Mit der Unzahl von Verknüpfungen zwischen Programmen haben Anwender schon in den Y2K-Projekten leidige Erfahrungen gemacht. Immerhin, darauf kann man zurückgreifen.

Auch die Schnittstellen nach außen sind zu überprüfen. Das betrifft besonders die standardisierten Verfahren DTAUS und Swift (siehe Beitrag auf Seite 76). Bereits jetzt klagen Banken, manche Firmenkunden würden Euro-Projekte ohne Rücksprache mit ihnen beginnen und alsbald Probleme melden. Die Geldinstitute haben ebenfalls spezialisierte Beratergruppen aufgebaut.

Die Anwendungsprogramme haben einige Überraschungen zu bieten, wenn man sie nicht auf die Euro-Konsequenzen untersucht. Ein einfaches Beispiel demonstriert das Problem der Literale:

IF Gehalt > 5000

THEN Praemie = 1000

ELSE Praemie = 500

Die stillschweigende Annahme, "Gehalt" würde immer einen Mark-Betrag enthalten, ergibt für das Literal automatisch die Bedeutung von 5000 Mark. Nach der Euro-Umstellung enthält "Gehalt" jedoch einen Euro-Betrag, und das Literal muss dann den entsprechenden Wert in Euro haben, weil sonst die Abfrage und die Programmlogik nicht mehr der gewünschten Funktionalität entspricht. Gleiche Überlegungen gelten für das Feld "Prämie". Außerdem muss vorher bei der Analyse geklärt werden, ob der Ausdruck beispielsweise nicht auch stoffliche Reinheit bedeuten könnte.

Zu einem Wimmelbild gerät die Regelung der Rabattstaffeln. Preisnachlässe gibt es für alles: Gesamtmengen, Zeitmengen, Rechnungswerte, Lieferschnelligkeit, durchschnittliche Pünktlichkeit, Qualität der Produkte etc., von Sondervereinbarungen ganz zu schweigen. 1500 verschiedene Rabatte für 5000 Produkte am Warenein- und -ausgang sind nichts Besonderes. Und wer will schon Geschäftspartner vergraulen?

Da nimmt es nicht Wunder, dass Euro-Spezialisten immer wieder die Notwendigkeit genauer Analysen und Projektplanung betonen. Es gibt Hinweise, dass diese Phase bis zum ersten Griff in die Tastaturen durchaus ein Viertel der Projektzeit verschlingt. Und sie ist es wert, denn es gilt, über die optimale Umstellungsstrategie zu entscheiden. In jedem Fall gibt es dermaßen viel Arbeit, dass es nicht zu empfehlen ist, erst einmal abzuwarten, was "die anderen" machen.

Allgemein wird zwischen vier Herangehensweisen unterschieden: Cloning, Wrapping, Big Bang und On-the-Fly. Die Herangehensweise kann von Fachbereich zu Fachbereich und je nach Detailaufgabe durchaus unterschiedlich sein, so dass sich auch Mischformen ergeben können.

Cloning bedeutet, neben dem bisherigen Mark-basierten System eine funktional identische Euro-Umgebung auf einem zweiten Rechner aufzubauen. Die Vorteile bestehen in einer hohen Betriebssicherheit und garantierter Funktionsfähigkeit beim Umschalten auf den Euro zu einem Stichtag. Aber dafür ist ein hoher Preis zu zahlen: Hard- und Software müssen doppelt vorhanden sein, die Programme und Daten müssen auf dem Neu-System Eurofähig sein, und beide Systeme müssen sich gegenseitig aktuell halten.

Eine Variante dieses Konzepts ist der Aufbau eines separaten Entwicklungs- und Testsystems für den Euro nur zwischen Analyse und der tatsächlichen Umstellung. Diesen Weg hat beispielsweise die Saardata bei ihrer Konvertierung verfolgt. SAP-Partner bieten inzwischen die Kapazitäten ihrer Systeme als Cloning-Dienstleistung an, was diese Strategie finanziell bedeutend attraktiver macht.

Immer weniger ist vom Konzept des Wrapping die Rede. Damit ist nicht eine Technik aus der Objektorientierung gemeint. Tatsächlich ist es vor allem ein Weg für die derzeitige Doppelwährungsphase. Dabei wird nur festgelegt, welche Betragsfelder sich auf dem Bildschirm und im Druck in Euro und Mark darstellen lassen. Zwischen beiden Möglichkeiten wird bei Masken per Tastaturbefehl gewechselt.

Sibra-Geschäftsführer Ramm meint: "Das kann nur eine Übergangslösung für eine schnelle Euro-Darstellung sein, die eine Umstellung auf die Hauswährung EUR später aber gleichwohl erfordert." Außerdem seien auch beim Wrapping die Eingriffe in die Systemarchitektur nicht unerheblich.

Das dritte Lösungskonzept, Big Bang, wird oft unterschiedlich verstanden. Im Prinzip bedeutet es zunächst nur, alle Anwendungen zu einem Stichtag herunterzufahren und durch Euro-fähige Datenbestände und Programme zu ersetzen. Weil Letztere aber zuvor auf Zweitsystemen geänderte und getestete Varianten der alten Mark-Anwendungen sind, unterscheidet sich das Big-Bang-Konzept in der Praxis vom Cloning nur durch die zusätzliche Euro-Konvertierung aller Datenbestände.

Big Bang kann das logisch nahe liegende Konzept sein. Den Grund nennt Saardata-Projektleiter Hoffmann: "Geschäftsprozesse finden in der Regel modulübergreifend statt. Die Umstellung erfolgt bei SAP R/3 auf Mandantenebene und greift somit auf alle dort eingesetzten Einheiten zurück." Bei dieser Standardsoftware kann man laut Hoffmann nur die Module Personalwirtschaft und Konsolidierung unabhängig umstellen. Wie "big" der "Bang" bei einer Individualsoftware ausfiele, hängt also letztlich davon ab, wie tief und komplex die einzelnen Programmteile und Datenbestände miteinander verzahnt sind.

Damit erreicht man schon den Übergang zur vierten Strategie: On-the-Fly. Dies dürfte bei großen Mengen von Programmen und Datenbeständen die einzige realistische Herangehensweise sein, wenn man nicht das Gesamtsystem für eine Woche oder länger stoppen will. Entsprechend haben es die Frühumsteller, und das waren in erster Linie Banken und Versicherungen, bevorzugt.

Euro-Fachmann Ramm erläutert das Konzept: "Basis dieser Lösung ist eine intelligente und dynamische Programmsteuerung, welche dem umzustellenden Programm per Funktionsaufruf eine Reihe von Euro-relevanten Steuerungsdaten liefert, die auf ein vom Programm vorgegebenes Buchungs- oder Verarbeitungsdatum bezogen sind. Diese Steuerungsdaten stellen die Programme je nach Phase der Euro-Umstellung auf Mark und/oder Euro ein, liefern die Hauswährung in den Datenbeständen und legen mit dem Schnittstellen-Management die Währung an den Schnittstellen zwischen umgestellten und noch nicht umgestellten Programmen fest."

Der Vorteil dieser Herangehensweise besteht primär darin, dass die Programmsteuerung zwischen Anwendungen und Datenbeständen unterscheidet. Daraus leiten sich weitere Vorteile ab: Paralleler Betrieb von alten und umgestellten Programmen ist möglich, es können zuerst die Programme und dann die Datenbestände Euro-fähig gemacht werden.

Folglich lassen sich auch die Umstellungszeitpunkte für einzelne Anwendungen und Datenbestände unabhängiger von anderen Arbeiten bestimmen. Ramm: "Ein fachlicher Big Bang trotz DV-technisch schrittweiser Umstellung." Eine zusätzliche Annehmlichkeit besteht darin, dass die Langzeitarchivierung kein mehr Problem ist, weil die Programmsteuerung meldet, welche Daten in ihrer Altform Mark oder als Euro zwecks Weiterverarbeitung zur Verfügung stehen.

Natürlich hat auch diese Lösung einen Haken, den Ramm so beschreibt: "Je nach benötigter Funktionalität und Paketbildung bei Programmen, Datenbeständen und Schnittstellen können die Programmmodifikationen mehr oder weniger umfangreich werden. Und der folgende Testaufwand steht damit in direkter Relation, weil teilweise auch in die Anwendungslogik eingegriffen wird."

Der Test- und Nachbearbeitungsaufwand ist bei Euro-Projekten genau wie beim Problem 2000 außerordentlich groß. Bei Saardata verging fast ein Monat, rund ein Viertel der Projektdauer, zwischen dem ersten Test und der Umstellung. Das war wohl noch wenig. SAG-Experte Gerte meint: "Bei einer Euro-Umstellung ist ein zeitlicher Anteil von 40 bis 50 Prozent der gesamten Projektdauer für das Testen nicht zu hoch."

Es ist also durchaus angebracht, sich alsbald die Zeit für die Vorbereitung der Euro-Umstellung zu nehmen, um die Projekte unverzüglich starten zu können. Zeit, die jetzt verstreicht, muss später unter hektischeren Umständen wieder gutgemacht werden. Und wer am Ende in der Not weniger testet, was sicher wieder die erste Maßnahme zur Projektverkürzung sein wird, fährt ein hohes Risiko.

Eine schon vom Problem 2000 bekannte Schwierigkeit ist auch hier bereits abzusehen: Schon jetzt wächst die Nachfrage nach Beratern, und noch gegen Ende dieses Jahres wird sie stark ansteigen. In der ersten Hälfte 2001 wird der Markt plötzlich leer gefegt sein. Dann wird man nur zum Ziel einer sauberen Umstellung kommen, wenn man bereit ist, astronomische Preise zu zahlen.

Euro-Projektmodell

Eberhard Ramm, Geschäftsführer des Umstellungs-Tool-Anbieters Sibra und Verfechter einer schrittweisen On-the-Fly-Konvertierung, empfiehlt folgende Vorgehensweise zur Euro-Umstellung der Programme und Datenbestände:

-Durchführen einer Bestandsaufnahme,

-Ermitteln aller fachlichen Vorgaben und erste Festlegung der Umstellungsstrategie (diese unter Vorbehalt),

-Analyse aller Programme und Datenbestände auf Euro-relevante Felder sowie Überprüfung und eventuelle Änderung der Umstellungsstrategie auf Anwendungsebene,

-Festlegung des Lösungskonzepts der Umstellung auf Programm- und Datenpaketebene, Ausarbeiten der Detailkonzepte mit Umstellungsmaßnahmen, Reihenfolgeplanung, Schnittstellen-Management und Aufwandsschätzung,

-Implementierung der Programm-, Datenbestands- und Schnittstellen-Umstellung mit Dokumentation,

-Einzeltests, Integrationstest und Generalproben simulierter Verarbeitungstage mit Währungsphasenwechsel,

-Einführung der Euro-fähigen Anwendungen in die Produktion.