Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

28.11.1997 - 

Euro-Umstellung/Die Methoden der Währungsumstellung

Die Vor- und Nachteile verschiedener Lösungswege

Der Euro-Fahrplan eröffnet die Möglichkeit, grundsätzlich zwei Phasen für die DV-technische Umstellung zu differenzieren. Diese stellen an die Programme bei den Anwendern unterschiedliche Anforderungen.

In der ersten Phase der Euro-Einführung muß das Unternehmen in der Lage sein, Geschäftsvorfälle mit Lieferanten und Kunden in Euro abzuwickeln, ohne die internen Abläufe bereits auf Euro umgestellt zu haben. Das heißt, es können Lieferantenrechnungen in Euro eingehen, oder Kunden können eine Rechnungsstellung in Euro verlangen.

Hierzu reicht die bloße Fremdwährungsfähigkeit des Systems nicht aus. Vielmehr muß sichergestellt sein, daß sich der Euro-Kurs auf sechs Nachkommastellen genau umrechnen läßt und Fremdwährungen über den Euro zu konvertieren sind.

Die zweite Phase betrifft die Umstellung des internen Berichtswesens auf den Euro. Mit ihr erfolgen alle Bewertungen neu. Die Abwicklung der Geschäftsvorfälle erfolgt grundsätzlich in Euro, ebenso die Deklaration der Preise. Die Mark ist dann eine Fremdwährung. Für diesen Problemkreis gibt es grundsätzlich drei Lösungsansätze.

Der erste: Alle Beträge, die in der bisherigen Mandantenwährung gespeichert sind, sind in Euro umzurechnen und zu speichern. Nach dieser Konvertierung liegen alle Preise und Werte in der neuen Einheitswährung vor. Dies verlangt relativ wenig Entwicklungsaufwand und keine tiefen Eingriffe in das System.

Die Nachteile allerdings liegen nicht nur darin, daß riesige Datenmengen zu konvertieren sind, die entsprechend große Rechner- und Plattenkapazitäten erfordern. Auch beim Support sind große Nachfragespitzen zu erwarten. Historische Daten werden verändert, und während der Konvertierung ist der laufende Betrieb unterbrochen.

Der zweite Ansatz sieht vor, alle Preise und Beträge doppelt einzuführen. Dabei lassen sich mehrere Mandantenwährungen parallel führen. Alle Preise und Werte werden in einer Währung eingegeben, in alle hinterlegten Mandantenwährungen umgerechnet und gespeichert.

Für diese Lösungen spricht vor allem, daß ursprünglich erfaßte Werte und Preise erhalten bleiben und flexible Auswertungen über unterschiedliche Währungen möglich sind. Doch sie belastet die DV: Der Bedarf an Plattenkapazität steigt stark an, es sind Performance-Probleme durch zusätzlich zu speichernde Daten zu erwarten, außerdem gerät der Entwicklungsaufwand sehr hoch.

Eine dritte Variante ist die Online-Umrechnung aller Preise und Werte zur Laufzeit. Alle Preise und Werte bleiben bei diesem Konzept in der Währung gespeichert, in der sie erfaßt wurden. Ein zentrales Umrechnungsmodul rechnet beim Einlesen der Daten in die von der jeweiligen Applikation geforderte Währung um.

Dieser Ansatz ist in mehreren Punkten von Vorteil: Die Implementierung der geforderten Funktionalitäten erfolgt zentral, was die Funktionssicherheit verbessert. Konvertierungsläufe sind nicht erforderlich, Betriebsunterbrechungen und Spitzenbelastungen im Support lassen sich vermeiden.

Darüber hinaus ist es möglich, Preise im voraus zu steuern ("politische" Preise) und flexible Auswertungen über alle Währungen zu erstellen. Ursprünglich erfaßte Werte und Preise bleiben erhalten, es kommt zu keiner Veränderung abgeschlossener Geschäftsvorfälle, und das bedeutet eine hohe Revisionssicherheit. Gegenüber den beiden anderen Methoden entsteht für den Anwender kein Nachteil.

Daraus lassen sich für den Anwender einige Empfehlungen zur Währungsmodifikation ableiten. Er sollte sich von jedem Softwarelieferanten gleichzeitig aber auch von der internen DV-Abteilung bestätigen lassen, daß es ein Euro-fähiges Release der einzelnen Programme gibt. Der Hersteller soll dabei auch Auskunft darüber geben, nach welcher Methode seine Lösung zur Euro-Umstellung arbeitet.

Jedes Unternehmen muß prüfen, ob dieses Verfahren mit den eigenen Anforderungen übereinstimmt, ob man es sich beispielsweise leisten kann, gegebenenfalls den Betrieb für mehrere Tage zu unterbrechen. Ebenso wichtig ist es, die Kompatibilität der Systeme und Lösungen verschiedener Hersteller zu prüfen.

Aufwand für Schulung der Mitarbeiter ist hoch

Nicht zuletzt sind auch Budgets aufzustellen. Neben den Kosten für Euro-Releases fallen oftmals umfangreiche Ausgaben für Hardware an, falls die neue Programmversion höhere Anforderungen stellt. Wenn für die Konvertierungsphase hohe Datenvolumen zwischenzuspeichern sind, empfehlen einige Softwarehersteller, Hardware zu leasen. Des weiteren ist der Schulungsaufwand für die Mitarbeiter nicht zu unterschätzen.

Wer mit einer gezielten Planung und einem realistischen Budget an das Projekt Euro herangeht und zudem das für ihn richtige Verfahren wählt, hat trotz hohen Aufwands gute Chancen, die Vorteile der neuen Währung frühzeitig zu nutzen. Ein gegebenenfalls notwendiger Systemwechsel kann zudem einen Re-Engineering-Prozeß nach sich ziehen, der die Aufwendungen wieder ausgleicht.

Der Euro ist in erster Linie ein Management-Problem auf seiten derer, die eine Software geschrieben haben. Die Unternehmen haben die Aufgabe, zu entscheiden, welches Konzept und welcher Anbieter für eine Lösung in Frage kommen. Das Risiko einer Fehlentscheidung ist für Anwender um so geringer, je weniger sie bestehende Geschäftsvorfälle verändern und je weniger sie in Programmstrukturen eingreifen.

Dr. Peter Schimitzek ist Geschäftsführer der CSB-System - Software-Entwicklung & Unternehmensberatung AG in Geilenkirchen.