"Die Jahrtausendwende kann ich leider nicht verschieben", konstatiert Alfred Siegel, stellvertretender Vorstandsvorsitzender der Barmer Ersatzkasse mit Sitz in Wuppertal. Projekte, die direkt oder auch nur mittelbar die Umstellung der Datumsfelder betreffen, haben - im Gegensatz zu den meisten anderen IT-Projekten - einen unverrückbaren Endtermin.
Schon 1996 hatte die Barmer die in vielen anderen Unternehmen damals noch verharmloste Jahr-2000-Problematik in Angriff genommen - mit einem ehrgeizigen Unterfangen: Das Projekt "Zentrale Umstellung", kurz "Zeus", zielte darauf, das gesamte DV-System auf eine neue Grundlage zu stellen. Nachdem die IBM angekündigt hatte, sie werde das Betriebssystem "Distributed Processing Programming Executive" (DPPX) aus der Wartung nehmen, waren die Wuppertaler ohnehin gezwungen, sich früher oder später nach einer Alternative umzusehen. Also planten sie eine Client-Server-Architektur auf der Basis von OS/390 und AIX.
Auch ihre Softwaresysteme wollte die Barmer neu entwickeln und so die Themen Datumsumstellung und Euro-Einführung in einem Aufwasch abhaken. Aber dieser Teil des Vorhabens war in der Realität offenbar weit aufwendiger als in der Planung. "Wir hätten nicht die Sicherheit gehabt, daß wir das zeitlich schaffen", erläutert Siegel. Er meint damit nicht nur die Jahrtausendwende, sondern auch die Einführung der europäischen Einheitswährung und weist darauf hin, daß beide Umstellungen bereits vor der Jahrtausendwende notwendig seien. Schon zu Beginn des kommenden Jahres wolle die Barmer neben D-Mark auch Euro-Werte berechnen. Auch die vierstelligen Jahreszahlen würden nicht am 1. Januar 2000 akut, sondern sobald die ersten Fristen bis in das nächste Jahrtausend reichen.
Anstatt unzumutbare Abstriche an der Qualität des neuen Systems hinzunehmen, zog das Management der Barmer frühzeitig Konsequenzen: "Wir werden nicht mehr alles selbst entwickeln", bestätigt Siegel. Die Strategie der Barmer sieht jetzt vor, die Währungsumstellung mit Hilfe einer Standardsoftware zu bewältigen. Bei der KPMG gab die Versicherung eine Machbarkeitsstudie bezüglich der SAP-Software R/3 in Auftrag - mit offenbar positivem Ausgang. Jedenfalls äußert Siegel die Zuversicht, daß Anfang des kommenden Jahres die von der Euro-Einführung betroffenen Teile der Finanzbuchhaltung mit R/3 arbeiten werden.
Material- und Personalwirtschaft, Einkauf und Lager sowie die Logistik sollen diesem Beispiel später folgen. Doch trotz dieser pragmatischen Entscheidung weiß Siegel: "Standardsoftware ist kein Allheilmittel." R/3 decke bislang nur "einen Bruchteil" der Anforderungen ab, die das Geschäft eines gesetzlichen Krankenversicherers mit sich bringe. Nicht unterstützt würden beispielsweise Leistungsgewährung, Beitragseinzug, Mitglieder- und Firmenbestandsführung sowie Meldewesen. Diese Lücken in den marktgängigen Standardsoftware-Systemen hatten die Barmer ursprünglich bewogen, ihre Anwendungssysteme komplett selbst zu entwickeln.Daß der Versicherer seinen Kurs korrigierte, hängt nicht nur mit der akuten Zeitnot zusammen. Vielmehr hat er mittlerweile eine kostensparende Alternative zur Individualprogrammierung im Auge: Siegel will andere gesetzliche Krankenkassen für die Idee gewinnen, auf der Grundlage einer Standardsoftware gemeinsam eine Branchensoftware zu entwickeln. Als Partner auf seiten der Software-Industrie ist die SAP AG im Gespräch, die schon in einigen vertikalen Märkten - Chemie, Bekleidungsindustrie, Baunebengewerbe etc. - gemeinsame Entwicklungsprojekte mit Anwenderunternehmen gestartet hat. Für eine Entscheidung ist es aber noch zu früh, denn zunächst muß einmal geklärt werden, wer sich an den Kosten dieses Vorhabens beteiligt. Allerdings gibt sich Siegel optimistisch: "Ich hoffe sehr, daß hier noch in diesem Jahr Bewegung hineinkommt."
Wie auch immer - eine solche Branchenlösung wird mit Sicherheit nicht mehr rechtzeitig fertig sein, um das Jahr-2000-Problem der Barmer zu lösen. Folglich haben sich die Mitarbeiter der Krankenkasse schon damit abgefunden, daß sie ihre geschäftsspezifischen Assembler- und PL/1-Anwendungen noch einige Zeit weiterverwenden werden. Für die Entwickler heißt das aber: Mehr als 4000 Einzelprogramme müssen in die Lage versetzt werden, zweistellige Jahreszahlen korrekt zu erkennen.
Die Umstellung der PL/1-Applikationen vertraute die Barmer der CGI Deutschland GmbH an. Das Unternehmen, ein Teil des IBM-Konzerns, hat sich unter anderem darauf spezialisiert, in Cobol, RPG und PL/1 geschriebene Anwendungen mit Hilfe von Software-Tools fit für das nächste Jahrtausend zu machen.
Ein kniffligeres Problem war hingegen die kosmetische Operation an den Assembler-Programmen. Wie Siegel versichert, gab es am Markt bis dato kein Werkzeug für eine automatische Umsetzung der Jahreszahlen zu kaufen. Die Datumsfelder von Hand zu suchen und zu ändern, würde aber ein Vielfaches dessen kosten, was für den Einsatz von Automatisierungs-Tools aufzuwenden wäre.
Diese Mehrinvestition konnten sich die Wuppertaler glücklicherweise sparen. In der Düsseldorfer Compartner GmbH fanden sie ein Beratungs- und Dienstleistungsunternehmen, das mit ihnen zusammen Werkzeuge für die automatische Datumsumstellung von Assembler-Code entwickeln wollte.
Dem 20köpfigen Team - zu zwei Dritteln aus Compartner-, zu einem Drittel aus Barmer-Mitarbeitern zusammengesetzt - gelang es bis zum Ende des vergangenen Jahres, einen Prototyp für dieses Toolset zu basteln. Dem Projektplan zufolge sollen die Werkzeuge noch in diesem Monat in der Kundenumgebung ausgetestet und für eine weitere Vermarktung freigegeben werden. Die anschließende Einführungsphase dauert voraussichtlich bis zum Frühling kommenden Jahres.
Das von Compartner entwickelte Umsetzungsverfahren arbeitet mit alphanumerischen Zeichenkombinationen, die nur Jahreszahlen bis 2035 abbilden können. Aber so lange sollen die Assembler-Programme der Barmer ohnehin nicht mehr Dienst tun. Vielmehr läßt Vorstandsmitglied Siegel keinen Zweifel daran, daß die Anwendungen, die jetzt jahrtausendfähig gemacht werden, in wenigen Jahren schon zum alten Eisen wandern.
Sobald sichergestellt ist, daß die Barmer-DV den Millenniumswechsel unbeschadet übersteht, will sich der Krankenversicherer wieder höheren Zielen widmen: Die Ablösung der DPPX-Systeme sowie die Weiterentwicklung der DB2-Datenbanken sind zwar momentan aufgeschoben, stehen aber ziemlich weit oben auf der Prioritätenliste. Daran ändert auch die neue Anwendungsstrategie nichts, beteuert Siegel: "Wir brauchen eine dezentrale Struktur, auf die wir die Branchensoftware draufsetzen können."
DAS SYSTEM
Die Informationsverarbeitung der Barmer Ersatzkasse geschieht derzeit in einer MVS-basierten Mainframe-Umgebung mit Abteilungsrechnern unter DPPX. Geplant ist die Umstellung auf eine Client-Server-Lösung mit OS/390 und AIX. Die operationalen Anwendungen setzen sich aus jeweils rund 2000 Assembler- und PL/1-Programmen sowie einigen hundert CSP-Applikationen zusammen. Die meisten davon sollen mittel- bis langfristig durch Standardsoftware und eine noch zu entwickelnde Branchensoftware ersetzt werden.
DAS UNTERNEHMEN
Die Barmer Ersatzkasse ist eine gesetzliche Krankenversicherung mit mehr als neun Millionen Mitgliedern. Sie beschäftigt rund 18 000 Mitarbeiter, die sich auf 1400 Niederlassungen verteilen. Neben der Datumsumstellung seiner alten Anwendungsprogramme und der Einführung mehrerer R/3-Module betreibt das Unternehmen derzeit auch den Aufbau eines Data-Warehouse und die Entwicklung einer Anwendung für die Deckungsbeitrags-Rechnung.