Im Umgang mit dem Euro ist für Deutschlands Unternehmen und Behörden nur zweierlei sicher: Am Neujahrstag 1999 startet die neue Europa-Währung, und spätestens am 1. Januar 2002 müssen alle Marktteilnehmer Euro-fähig sein. Doch innerhalb des dreijährigen Übergangszeitraums, in dem der Euro der Mark formal gleichgestellt ist, steht es jeder Organisation frei, wann und in welcher Form sie die neue Währung in ihre betrieblichen und DV-technischen Abläufe integriert.
Kein Teilnehmer des europäischen Binnenmarktes ist per Gesetz gezwungen, vor dem 1. Januar 2002 seine Geschäfts- und Abwicklungssysteme auf den Euro umzustellen. Trotzdem wächst kurz vor dem Starttermin die Nervosität bei den für die Euro-Strategie verantwortlichen Managern.
Während vor allem international tätige Konzerne auf einen raschen Euro-Umstieg drängen, zeigen andere Organisationen großes Beharrungsvermögen. Im Spannungsfeld zwischen diesen beiden Extremen bewegen sich eine große Zahl mittelständischer Unternehmen. Für sie gilt es, genau zu prüfen, ob sich durch den Euro ihr Wettbewerbsumfeld signifikant verändert. Da mit dem neuen Einheitsgeld bisherige Währungsrisiken entfallen, könnte ihnen verstärkte Konkurrenz auf heimischen Märkten drohen. Umgekehrt bieten sich agilen Mittelständlern durch den Euro womöglich einfachere Zugangswege auf Nachbarmärkte, da die Risiken von Fremdwährungsgeschäften entfallen.
Die Strategien zur betrieblichen Euro-Einführung lassen sich in vier Typen klassifizieren: Das notwendige Minimum an Umstellungsarbeiten beschreibt die "Big-Bang"-Methode. Dieser eher taktische Ansatz findet viele Anhänger unter denjenigen, die sich die Währungswelt ab dem 1. Januar 2002 als wieder "heil" vorstellen. Wo bis dato Mark stand, wird dieses Währungszeichen aus ihrer Sicht einfach durch den Euro ersetzt. Dementsprechend planen sie, bis zum Ende der Umstellungsperiode alles beim alten zu belassen und dann lediglich die "DM" gegen den "EUR" zu ersetzen.
Mit einer derart begrenzten Umstellung werden jedoch nur die wenigsten das Ufer von Euro-Land trockenen Fußes erreichen. Vielmehr müssen sie auch beim "Big Bang" über die Änderung der Währungsliterale "DM" und "Pfg" hinaus sowohl die Daten wie auch die Anwendungslogik anpassen.
Eher kosmetischen Charakter besitzt der Ansatz der "Euro-Unterstützung". Er zielt darauf ab, dem Verbraucher per doppelter Preisauszeichnung während der Übergangsphase zusätzlich zur lokalen Währung die Euro-Summen zu präsentieren. Euro-Unterstützung ersetzt allerdings nicht den finalen "Big Bang", erlaubt es aber beispielsweise Handelshäusern, während der Doppelwährungsphase mit minimalem Aufwand zumindest einen Imagegewinn aus dem Euro zu ziehen.
Um schon in der Übergangsphase "Euro"-Produkte verkaufen zu können, bietet das "Mixed-Mode"-Verfahren eine effiziente Umstellungsform. Es stellt einen strategischen Ansatz dar, der darauf abzielt, bedarfsweise bereits in Euro zu handeln, während die Hauswährung vorläufig die D-Mark bleibt. Um diese Flexibilität zu erlangen, arbeiten die DV-Abteilungen heute daran, alle nach außen wirkenden Systeme wie etwa Bestell- und Rechnungswesen sowie Auftragsabwicklung zukünftig auf parallele Euro- und D-Mark-Verarbeitung zu trimmen. Die internen Systeme, etwa für Finanzbuchhaltung, Controlling und Personalabrechnung, werden hingegen erst zu einem späteren Zeitpunkt auf einen Schlag von D-Mark auf Euro umgestellt.
In der Zwischenzeit müssen alle Beträge, die von den externen Systemen in Euro geführt werden, beim Übergang in die internen Systeme in D-Mark umgerechnet werden. Erfolgt diese Implementierung korrekt im Mixed-Mode, erübrigt sich am Ende der Übergangsperiode eine nochmalige Umstellung der betroffenen Anwendungsteile.
In der Regel abzuraten ist von einem vierten Ansatz, der eine generelle Schattenwährung mit durchgehend paralleler Verarbeitung beider Beträge vorsieht. Die daraus resultierenden Aufwände erscheinen angesichts der Kürze der Zweiwährungsphase ökonomisch nicht gerechtfertigt. Ausnahmen sind lediglich die Abwicklungssysteme der Banken. Die Finanzdienstleister treiben derzeit einen immensen Umstellungsaufwand, um jedes Konto zukünftig alternativ in zwei Währungen führen zu können. Der Sinn dieses Vorgehens liegt in einer geringeren Anzahl von Konvertierungen und dadurch vermeidbaren Rundungsdifferenzen.
Beginnt ein Unternehmen mit der Umstellung seiner DV-Systeme, begegnet ihm die größte Unbill bei den im Programm hart codierten Betrags- und Mengenkonstanten. Diese werden besonders in Individualanwendungen massenhaft verwendet. Der Grund hierfür scheint allzu menschlich: Die meisten Programmierer vermochten sich vor zehn oder 20 Jahren nicht auszumalen, daß die Mark keine beständige Größe ist. Deswegen haben sie absolute Werte nicht auf parametrisierbare Felder gelegt, sondern ohne Scheu feste Wertzuweisungen in ihren Sourcecode eingebaut.
Erst variable Tools führen zu konstanten Größen
Als Faustregel für die Häufigkeit von Konstanten kann gelten: Je stärker eine Anwendung Abläufe mit Hilfe von Batch-Prozessen automatisiert, um so häufiger werden Betrags- und Mengenkonstanten auftreten. Mit gutem Grund werden Betragskonstanten in einem Cobol-Programm an solchen zentralen Stellen verwendet, wo sie eine hohe Revisionssicherheit verbürgen. "Hart" codierte Konstanten vermitteln jedem Revisor die Gewißheit, daß die von ihm gesehenen Werte tatsächlich vom Programm benutzt und nicht durch Veränderung externer Parameter zeitweise verfälscht werden können.
Am Beispiel der Konstanten wird sichtbar, daß bei der Euro-Einführung weit mehr als bei der Jahr-2000-Umstellung die Fachabteilungen gefragt sind. Denn durch sie sind die Konstanten ursprünglich einmal in die Anwendungen hineingebracht worden. Heute werden sich die Fachabteilungen nur noch eines kleinen Teils der "festen Werte" bewußt sein - um so mehr, wenn "alte", eingefahrene Geschäftsprozesse dominieren, die im Hintergrund von den DV-Systemen ausgeführt werden.
Die Konstanten verursachen den größten Teil des Euro-Analyseaufwandes - denn sie liegen versteckt. Auch der naheliegende Versuch, aus der Menge aller Konstanten die relevanten zu finden, ist durch manuelle Suche faktisch nicht zu leisten. Denn viele Anwendungen beinhalten Tausende von Betragsliteralen in unterschiedlichster Gestalt. Welche unter ihnen Währungsbegriffe repräsentieren, ist nur schwer auszumachen. Ob ein Wert "100" für 100 Mark steht oder als Return-Code einer SQL-Anweisung arbeitet, hängt vom Programmkontext ab.
Im Vergleich zum Suchen der Konstanten erscheint die Analyse der Währungsliterale geradewegs als Fingerübung. Am erfolgversprechendsten ist sie in Programmen, deren Währungsliterale schulbuchmäßig mit "DM" oder "Pfg" oder "D-Mark" benannt sind. Ist dies nicht der Fall, gilt eine zunächst tautologisch anmutende Regel: Bei der Suche nach Literalen ist es erforderlich, sich auf die "Klasse" der Literale zu beschränken. Eine solche Beschränkung gelingt nur mit "intelligenten" Werkzeugen, die die programminterne Logik verstehen. Eine einfache Textmustersuche würde demgegenüber in der Regel zu viele Treffer erzeugen, da sie Literale nicht von Kommentaren und Feldnamen unterscheiden kann.
Anders als bei der Jahr-2000-Umstellung wird die Marschrichtung beim Euro-Übergang nicht von der DV-Abteilung, sondern von der Unternehmensleitung sowie den Fachabteilungen vorgegeben. Welcher Weg eingeschlagen wird, hängt zunächst davon ab, ob das Management den Euro nur als notwendiges Übel betrachtet oder willens ist, seine Vorteile aktiv zu nutzen. Ist diesbezüglich eine grundsätzliche Entscheidung gefallen, sind die Fachabteilungen gefragt: Ihr Wissen, wo in den Anwendungen buchstäblich "das Geld steckt", sollte von Anbeginn in die Inventarisierung und Analyse der DV-Systeme einfließen.
Dies bedeutet freilich nicht, daß das Rechenzentrum auf die passive Rolle des ausführenden Organs beschränkt bleibt. Da auch die Kosten des Umstiegs bei der Umsetzung der Euro-Strategie eine wichtige Rolle spielen, sollte die DV-Leitung vielmehr frühzeitig in die Entscheidungsprozesse einbezogen werden. Dies kann nicht zuletzt dazu dienen, praxisfernen Maximalforderungen seitens der Fachabteilungen - etwa nach der Entwicklung eines Euro-Schattensystems - mit realistischen Aufwand- und Nutzenschätzungen zu begegnen. Voraussetzung einer solchen Abschätzung sind sowohl die Systeminventur wie die Euro-spezifische Codeanalyse. Entsprechende Untersuchungs-Tools können sehr schnell diejenigen Informationen liefern, aus denen die benötigten Aufwände zu ermitteln sind.
Analog zum Vorgehensmodell in Jahr 2000-Projekten ist die Inventarisierung der erste Schritt einer jeden Euro-Einführung. Die Inventur klärt, wo gemeinsam genutzter Code und relevante Schnittstellen vorliegen. Ihre Kenntnis ist vor allem dann vonnöten, wenn ein Mischbetrieb angestrebt wird, bei dem die nach außen wirkenden Anwendungen früher als die internen Buchhaltungssysteme umgestellt werden sollen.
Bei der Inventur und Analyse ist angesichts der nahenden Doppelwährungsphase prinzipiell Eile geboten. Die Unternehmen sollten in der Lage sein, ihre Euro-Strategie im Laufe des Übergangszeitraums schnell und flexibel an veränderte wirtschaftliche Rahmenbedingungen anzupassen.
Das alles erfordert den Einsatz von Analysewerkzeugen, die das Auffinden Euro-relevanter Sourcecode-Stellen vereinfachen und automatisieren. Derartige Tools kompensieren durch "intelligente" Suchmechanismen den Mangel an Programmierkonventionen, der die Identifizierung von Betragsfeldern und ihren Kontexten erschwert. Denn Betragsfelder, Längen und Gewichte sind in ihrer systeminternen Darstellung nicht unterscheidbar.
Auch Zahlenkonstanten üben, optisch gleich, in Anwendungen unterschiedlichste Funktionen aus - mal als Euro-relevanter Wert, mal beispielsweise als simple Return- oder Tastencodes. Verglichen mit der Jahr-2000-Problematik ist der Kreis potentieller Untersuchungskandidaten aus diesem Grund riesig - die Zahl wirklich relevanter Wertkonstanten hingegen überschaubar.
Mit einem massiven Regelwerk leistungsfähiger mengentheoretischer Operationen sind Analysewerkzeuge in der Lage, die Semantik monetärer Bewegungen im Sourcecode zu erkennen. Die damit erzielten Ergebnismengen sind so klein und gut dokumentiert, daß sie sich auch manuell weiterverarbeiten lassen.
*Joachim Blome ist Business Development Manager bei Micro Focus.