Anders als für die Banken war der 1. Januar 1999 für Versicherungen kein entscheidender Stichtag. Die Mehrzahl, darunter auch die Arag, hat deshalb zunächst lediglich die gedruckten Rechnungen, Mahnungen und Policen um ein Feld für die Ausgabe der Endsumme in Euro und um ein entsprechendes Textfeld ergänzt. Eine doppelte Bestandsführung in Mark und Euro war nicht erforderlich. Da die Mark voraussichtlich ab dem 1. Januar 2002 keine gesetzliche Gültigkeit mehr haben wird, ist dieses Datum für die Versicherungsunternehmen entscheidend und damit auch Endtermin der Euro-Projekte.
Die Arag plant, ihre Versicherungsbestände stichtagsbezogen Mitte 2000 auf den Euro umzustellen. Bis zu diesem Zeitpunkt werden die Datenbestände weiterhin in Mark, danach ausschließlich in Euro geführt. Diese Strategie, die die Arag und ihre IT-Dienstleistungstochter Alldata "Euro-only" nennen, sieht zugleich vor, dass bereits heute die Anwendungen sukzessive Euro-fähig gemacht und mit den neuen, jedoch noch nicht aktiven Euro-Funktionen in den Produktionsbetrieb übernommen werden. Gegen die Doppelwährungsstrategie sprachen vor allem ein um 30 bis 40 Prozent höherer DV-Aufwand und die Tatsache, dass ein doppelwährungsfähiges Anwendungssystem nicht vor Anfang 2001 einsatzbereit gewesen wäre.
Doch auch die "Euro-only"-Strategie - dessen ist man sich bei Arag und Alldata bewusst - birgt Probleme. Michael Reisiger, als Projektleiter der Alldata für die DV-technische Realisierung des Projekts zuständig, erläutert: "Wir wissen, dass Euro-only nicht in allen Bereichen durchführbar ist und es Mitte 2000 noch Anwendungen und Schnittstellen geben wird, bei denen eine Verarbeitung ausschließlich in Euro nicht möglich sein wird. Hier müssen wir zum Teil wieder in Mark zurückrechnen."
Die Provisionsabrechnungen der Außendienstmitarbeiter beispielsweise werden ab Mitte 2000 in Euro erstellt, vom Personalwirtschaftssystem jedoch noch nicht in Euro verarbeitet. Bei der Abwicklung von Mahnungen, die sich teilweise über einen langen Zeitraum erstrecken, kann es vorkommen, dass der Mahnbetrag auf Mark lautet, dass aber in Euro bezahlt wird. Bei der Umrechnung und beim Vergleich von angemahntem und bezahltem Betrag entstehen dann geringfügige Rundungsdifferenzen, die automatisch eine weitere Mahnung nach sich ziehen. Dies ist zwar ein Problem, das sich nicht nur bei "Euro-only" stellt, doch kann man bei der stichtagsbezogenen Umstellung nicht mehr auf ein Mark-Verfahren zurückgreifen.
Rundungsdifferenzen entstehen immer bei der Umrechnung von Mark in Euro und umgekehrt. Es kommen jedoch noch zusätzliche Rundungsdifferenzen hinzu, da wegen der gesetzlichen Vorgabe, dass Euro-Beträge Cent-genau mit zwei Nachkommastellen auszuweisen sind, zahlreiche (Mark-)Betragsfelder erweitert werden müssen. Viele Beträge werden in den Altprogrammen der Arag in Feldern mit keiner oder nur einer Nachkommastelle gespeichert, während intern mit zwei Nachkommastellen gerechnet wird.
Werden die relevanten Betragsfelder nun mit zwei Nachkommastellen versehen, entstehen bei Summenbildungen und anderen Rechenoperationen Rundungsdifferenzen. Solche Abweichungen sind DV-technisch nicht zu lösen. Es müssen deshalb nach sachlichen Erwägungen, das heißt von den Fachabteilungen, entsprechende Toleranzbereiche festgelegt werden. DV-technisch zu lösen ist allerdings das Auffinden der Felder, bei denen eine Entscheidung durch die Fachabteilung erforderlich ist. Codeanalyse-Tools leisten hier wertvolle Hilfestellung.
Sind für die einzelnen Betragsfelder die zulässigen Toleranzbereiche definiert, können die Felderweiterungen vorgenommen werden. In einem anschließenden Paralleltest, den Arag und Alldata mit Produktionsdaten aus mehreren Tages- und Monatsabschlüssen sowie einem Jahresabschluss durchführen, ist dann zu prüfen, ob die durch die Felderweiterungen entstandenen Rundungsdifferenzen die Toleranzen überschreiten.
Auch bei der Umrechnung von Mark in Euro und von Euro in Mark sind Rundungsdifferenzen unausweichlich. Hier ist die Entscheidung der Fachabteilungen ebenfalls gefragt. Das gesamte Euro-Projekt ist ja, anders als das Jahr-2000-Projekt, ein Wartungsprojekt mit einem hohen Anteil an fachlichen Anforderungen. So entstehen bei der Konvertierung nicht nur Rundungsdifferenzen, sondern auch krumme Beträge, die durch geeignete, fachlich begründete Werte ersetzt werden müssen.
Soll eine Mahngebühr von bisher fünf Mark künftig 2,50 oder drei Euro betragen? Wie ist mit Schlüsseln in einstelligen Feldern umzugehen, die Mark-Grenzen repräsentieren - wenn zum Beispiel "1" für eine Million Mark, "2" für zwei Millionen Mark steht? Bei allen Entscheidungen ist zu beachten, dass die Versicherungsnehmer durch die Änderungen im Rahmen der Euro-Anpassungen keine Nachteile haben dürfen oder andernfalls ein Recht auf Vertragsänderung haben.
Die Alldata hat damit begonnen, die Anwendungen der Arag Euro-fähig zu machen und mit den neuen, jedoch noch nicht aktiven Euro-Funktionen in den Produktionsbetrieb zu übernehmen. Deshalb werden nicht nur die relevanten Betragsfelder mit zwei Nachkommastellen versehen, sondern in die Programme auch Abfragen zur aktuell gültigen Währung, Mark oder Euro, eingebaut und die Literale und Konstanten des Euro-Verarbeitungszweigs auf "Euro" gesetzt.
Zum Stichtag nur noch Daten migirierenVor ihrem Produktionseinsatz werden die Euro-fähigen Programme dem Vorher-Nachher-Test unterzogen, der schon bei den Felderweiterungen verwendet wurde - mit dem Unterschied, dass dieses Mal die Rundungsdifferenzen bei den in Euro konvertierten Beträgen geprüft werden. Nur wenn die Abweichungen innerhalb der zulässigen Toleranzen liegen, wird das Euro-fähige Programm in den Echtbetrieb übernommen.
Michael Reisiger kommentiert: "Wir gehen bis Mitte 2000 rollierend mit den Applikationen der verschiedenen Anwendungsgebiete in Produktion. Bis auf Ausnahmen in wenigen Bereichen ist am Stichtag dann lediglich die Datenmigration durchzuführen, also die Konvertierung der Bestände."
Der 1. Januar 2002 stellt deshalb für die Arag und die Alldata kein besonders "spannendes" Datum dar. Durch die Trennung der Umstellung von Programmen und Beständen lösen Arag und Alldata das Problem der Rundungsdifferenzen schon frühzeitig; die Risiken des stichtagsbezogenen Wechsels auf den Euro werden zeitlich verteilt.
Arag und Alldata veranschlagen den Zeitaufwand im Euro-Gesamtprojekt auf etwa 30 Personenjahre, wobei zu berücksichtigen ist, dass ein großer Teil der Anwendungen in Cobol für MVS programmierte Batch-Applikationen sind. Diese Host-basierten Altanwendungen enthalten, wie für Finanzunternehmen typisch, eine Vielzahl unterschiedlich formatierter und teilweise schwer auffindbarer Betrags- und Währungsfelder. Doch müssen sie nicht alle erweitert oder konvertiert werden. Wichtig ist deshalb, erstens alle und zweitens die richtigen Felder zu finden.
Aus den bereits genannten Gründen beschloss die Arag, ein Tool einzusetzen, das die Euro-relevanten Programmstellen und Felder automatisch ermittelt. Reisiger, der auch Leiter des Jahr-2000-Projekts der Arag war, erinnert sich: "Für die Anpassungen zum Jahrtausendwechsel setzen wir schon seit einiger Zeit ein Analyse-Tool von Merant ein. Wir waren so zufrieden, dass wir ,Eurosmart'' auch für dieses Projekt in die engere Wahl gezogen haben."
Es kam hinzu, dass zum damaligen Entscheidungszeitpunkt nur dieses Tool die Möglichkeit bot, die Analyse über die Job Control zu steuern, und deshalb zu erwarten war, dass es eine mehrheitliche Batch-Verarbeitung mit sequenziellen Dateien gut unterstützt. Eurosmart ist ein Inventarisierungs- und Analyse-Tool für den PC, das ausgehend von der JCL(Job Control Language) in Cobol-Haupt- und Unterprogrammen sowie in Copy-Strecken Euro-relevante oder -verdächtige Anweisungen (Statements) und Felder automatisch findet und analysiert. Dabei geht es nicht nur nach formalen Suchmustern (Scan Patterns) vor, sondern auch nach Regeln, logischen und mengentheoretischen Zusammenhängen. Das Werkzeug bezieht auch Abläufe ein und erkennt Feldverwendungsketten.
Ungepackte Betragsfelder ohne Nachkommastellen mit Namen wie "E1"oder "F2" beispielsweise werden von vielen Suchmuster-Tools nicht als Betragsfelder identifiziert. Das von der Arag gewählte Eurosmart berücksichtigt die programminterne oder Compiler-Logik und erkennt, wenn mit Feldern gerechnet wird und diese deshalb mit hoher Wahrscheinlichkeit Betragsfelder sind. Eine solche Impact-Analyse unterstützt die Entwicklung von effizienten Testhilfen. Da die Impact-Analysen aber sehr aufwändig sind, führte das Euro-Projektteam der Alldata sie nur in den besonders komplexen Anwendungsgebieten durch.
Die Basiseinheit in Eurosmart ist das "Projekt", ein Teilgebiet eines fach- oder spartenbezogenen Anwendungsgebiets. Das Anwendungsgebiet "Vertragsverwaltung Rechtsschutz" zum Beispiel ist bei der Arag in sechs Projekte, sogenannte Anwendungsgruppen, unterteilt. Eine dieser Anwendungsgruppen ist der Tagesabschluss, der wiederum aus zehn JCL-Abläufen und etwa 70 Programmen besteht. Zugeschnitten auf die einzelne Anwendungsgruppe, können im Tool die durchgeführten Auswertungen auch als Skripts gespeichert und wiederholt ausgeführt werden. Dies ist nicht zuletzt für Revisionszwecke wichtig.
Starke Beteiligung der FachabteilungenBei der Analyse entstehen projektbezogene Dateien, die alle Auswertungsergebnisse enthalten. Das Tool gibt in detaillierten und aggregierten Übersichten Werte wie die Anzahl der Programme, der Lines of Code, der Euro-verdächtigen Variablen und Statements sowie Referenzen und Cross-Referenzen aus. Die bei den Suchläufen gefundenen Euro-verdächtigen Statements, Variablen, Konstanten und Literale werden mit genauer Angabe der Programmstelle und weiteren Zusatzinformationen in Listen protokolliert.
Erwartungsgemäß fanden sich in den Anwendungen der Arag viele Euro-verdächtige Stellen. Im Anwendungsgebiet "Vertragsverwaltung Rechtsschutz, Batch" beispielsweise wurden in den 130000 Lines of Code der Procedure Division, also in den Verarbeitungs-Statements, zehn Prozent Euro-verdächtige Variablen und fünf Prozent Euro-relevante Anweisungen gefunden. Bei den Variablen ist im Allgemeinen mit einer Rate von höchstens einem Prozent zu rechnen.
Für eine leichtere Weiterverarbeitung exportierte Alldata die vom Umstellungs-Tool als Access-Datenbanktabellen erstellten Dateien in Excel-Spreadsheets, die sie um weitere Tabellen für das Projekt-Management und die Gesamtkalkulation ergänzte. In den neuen Tabellen wurden zum Beispiel die Namen des zuständigen Programmierers und des für die Abnahme verantwortlichen Fachbereichsmitarbeiters oder die Anzahl der Soll- und Ist-Manntage erfasst.
Die Excel-Dateien mit den Auswertungsresultaten und Projekt-Management-Daten verwaltet die Alldata in einer an Microsofts Explorer angelehnten Ordnerstruktur, in der außerdem - aus den Analyseergebnissen abgeleitete - Programmiervorgaben für die Softwareentwickler sowie die Dokumentation und Rückmeldungen der Entwickler gespeichert und gepflegt werden. Reisiger: "Sehr positiv finden wir, dass wir Analysen, Projekt-Management, Programmvorgabenkontrolle und Rückmeldungssystem miteinander kombinieren und vereinheitlichen können. Das gesamte Projektteam arbeitet so in einer konsistenten Struktur."
Eine weitere wichtige Aufgabe bestand darin, unternehmensweit, also über die Anwendungsgruppen und -gebiete hinweg, die Verwendungsketten der von den Applikationen verarbeiteten Dateien zu identifizieren, um die externen und internen Daten-Schnittstellen isolieren zu können. Das verwendete Tool ließ sich so anpassen, dass es gelang, den Prozess weitgehend zu automatisieren. Dies war kein einfaches Unterfangen, denn uneinheitliche Namenskonventionen in den Altprogrammen, eine inkonsequente Verwendung von Copystrecken und die nicht auswertbaren MVS-Utilities erschwerten die Analyse.
Die von "Eurosmart" ausgegebenen Listen mit den Euro-verdächtigen Statements, Variablen, Konstanten und Literalen werden von der Alldata als Offene-Punkte-Liste geführt, mit erläuternden Texten versehen und den Fachabteilungen der Arag zur Entscheidung vorgelegt. In Gesprächen zwischen DV-Projektteam und Sachgebietsmitarbeitern oder in einer Fachbereichs-Entscheidungsrunde wird dann festgelegt, welche Euro-Werte verwendet und wie die Masken- und Drucklayouts angepasst werden sollen.
Im Euro-Gesamtprojekt der Arag ist inzwischen ein Großteil der Analysearbeiten abgeschlossen. Laut Reisiger konnten der Konzern und Alldata dabei einen hohen Produktivitätsgewinn erzielen. Er rechnet vor: "In einem Projekt mit starker Beteiligung der Fachabteilungsseite macht der Analyseanteil üblicherweise 30 Prozent aus. Dies wären bei dem von uns veranschlagten Gesamtaufwand von 30 Mannjahren knapp zehn Mannjahre. Unser Analyseaufwand beträgt dagegen zwei Mannjahre oder weniger als sieben Prozent. Im Test gehen wir von einer weiteren Ersparnis von ungefähr einem Mannjahr aus."
Hinzu kommen die qualitativen Verbesserungen durch eine zuverlässigere Identifizierung der Euro-relevanten Programmstellen und Felder. "Wir können sicher sein, dass das Tool alle Euro-Kandidaten findet." Der Umstellung Mitte 2000 sehen Arag und Alldata beruhigt entgegen.
.*Michael Rufer ist freier Journalist in München