 | |||||||||||||
|
Vom Jahr-2000-Projekt zur Euro-Umstellung Artikel aus der Computer Woche, 23. Juni 2000 Autor: Ludger Schmitz Ab dem 1. Januar 2002 darf die Mark nur noch im Bargeldverkehr verwendet werden. Von diesem Zeitpunkt an ist im internen Rechnungswesen der Unternehmen nur noch der Euro zulässig. Diese Umstellung der Hauswährung ist aufwendiger und zeitraubender, als es die meisten Unternehmen erwarten. Für eine Anpassung zum strategisch günstigsten Zeitpunkt sollten die Projekte schnellstmöglichst beginnen. 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 kriegen 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 liefern, 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 Regeln zur Rundung der Nachkommastellen. Nur leider war es das nicht; denn nur für den Finanzverkehr nach außen wurden die Hausaufgaben erledigt. Intern wird weiter mit der Mark gerechnet - aber 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 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 aufwendiger, 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. Der ihn selbst überraschende 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. Fü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 Zeitdauer von sechs Monaten für die Anpassung. Ralf Hoffmann, Leiter der hausinternen Euro-Umstellung beim SAP-Partner Saardata, fand dies bei seinem Projekt weitgehend bestätigt. Aber mit Blick darauf, dass er trotz optimaler technischer Voraussetzungen eine Menge Überraschungen erlebt hatte, 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 selbstentwickelter 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ück-Umrechnungen von Euro nach Mark immer wieder Rundungsdifferenzen von einem Pfennig oder Euro-Umrechnungen von Summen mit ihren Einzelbeträgen 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 bei Einführung zusätzlicher Euro-Felder sich dabei z. B. in IMS-Datenbanken die Segmentlängen ändern und man Probleme mit den Speicherressourcen bekommen kann. Ein weiteres Problem sind die aggregierten Beträge wie Summen, die nicht einfach umgerechnet sondern neu errechnet werden müssen. 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 xx). Bereits jetzt klagen Banken, manche Firmenkunden würden Euro-Projekte ohne Rücksprache mit ihnen angehen 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 damit die Programmlogik nicht mehr der gewünschten Funktionalität entspricht. Gleiche Überlegungen gelten für das Feld "Praemie". Vorher muss 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 die Planung 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 in 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 Euro-System Euro-fä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 nicht immer in gleicher Weise 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 naheliegende 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: 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-Funktionalität 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 als Steuerungsobjekte 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. Die Umstellungszeitpunkte für einzelne Anwendungen und Datenbestände lassen sich unabhängiger von anderen Arbeiten bestimmen. Ramm: "Ein fachlicher Big Bang trotz DV-technisch schrittweiser Umstellung". Und eine zusätzliche Annehmlichkeit besteht darin, dass die Langzeitarchivierung kein Problem mehr 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 ausführt: "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 schon jetzt wieder abzusehen: Noch gegen Ende dieses Jahres wird die Nachfrage nach Beratern spürbar ansteigen. In der ersten Hälfte 2001 wird der Markt plötzlich leergefegt sein. Dann wird man nur zum Ziel 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. SIBRA GmbH Ihr zuverlässiger und kompetenter Partner bei der Euro-Umstellung Die SIBRA GmbH arbeitet als unabhängige und herstellerneutrale Ingenieurgesellschaft für Datentechnik für Kunden aus allen Wirtschaftsbereichen. Unter Einsatz moderner Methoden und Werkzeugen werden für alle Branchen vornehmlich individuelle, maßgeschneiderte Problemlösungen erarbeitet mit dem Ziel, die Wirtschaftlichkeit und Marktsituation des Auftraggebers zu verbessern und für das Management die Transparenz des Unternehmens zu erhöhen. Schwerpunkte sind Auftrags- und Produktentwicklungen sowie das Projekt-geschäft für Mainframe- und PC-Plattformen. Die SIBRA GmbH wurde im April 1980 gegründet und beschäftigt zur Zeit 14 Mitarbeiter. SIBRA Ingenieurgesellschaft für Datentechnik mbH Industriestraße 35 und Leiblstraße 14 82194 Gröbenzell Tel 08142/57264 und 9025 Fax 08142/57265 und 9028 Internet: www.SibraGmbh.com email: SibraGmbh@aol.com |
|
|
|
|||||||||
|
|
|
||