MÜNCHEN (COMPUTERWOCHE) - Sie laufen und laufen und laufen: Cobol-, PL1- und Assembler-Programme bilden vor allem in Banken und Versicherungen noch häufig das Herzstück der IT. Sie abzulösen oder zu modernisieren ist ein komplexes Unterfangen und rechnet sich in vielen Fällen nicht. Dennoch gehen etliche Unternehmen diesen Weg.
Bild: Argum
"Es war eine Operation am offenen Herzen", berichtet Volker Lösch, Leiter Transaction Banking, Payments, bei der Commerzbank. Im April 2002 ersetzte das Frankfurter Geldinstitut die noch aus den 80er Jahren stammenden Cobol-Programme für den elektronischen Massen-Zahlungsverkehr vollständig. Während das IT-Team noch an den Funktionen des eigenentwickelten Neusystems feilte, galt es, auch die bestehenden Anwendungen weiter zu pflegen und zu warten. Unterm Strich investierte die Bank einen zweistelligen Millionenbetrag in das Projekt.
Eine ähnlich hohe Summe veranschlagt Michael Steinbach, Vorstandssprecher beim Transaktionsinstitut für Zahlungsverkehrsdienstleistungen (TAI), für die IT-Umstellung. Vor rund zwei Jahren begann der aus der DZ Bank hervorgegangene Finanzdienstleister, ein Ersatzsystem für die seit 1988 eingesetzten Assembler-Programme zu planen. Aus einer Entwicklungskooperation mit dem Softwarehaus Mosaik Geva entstand eine Java-basierende Anwendungsplattform. Damit einher ging eine umfassende Modernisierung der IT-Plattformen: Die hergebrachte Mainframe-Umgebung musste einer Client-Server-Architektur weichen - mit Sun Solaris als Betriebssystem, der IBM-Middleware Websphere und Oracle-Datenbanken im Backend.
Zu den größten Migrationsprojekten im deutschen Finanzsektor dürfte ein neues Buchungs- und Zahlungsverkehrssystem gehören, das die Postbank gemeinsam mit SAP entwickelt hat. Erst kürzlich ersetzte das Bonner Institut damit mehrere seit 1990 genutzte Anwendungen der Softwareschmiede Kordoba. Zugleich trennte sich die Bank von ihrem 22-prozentigen Anteil an dem Unternehmen, das damit zu 100 Prozent im Besitz von Siemens Business Services ist. Mehr als 200 Millionen Euro investierte IT-Vorstand Dirk Berensmann in das Projekt "IT 2003"; allein auf Seiten der Postbank waren rund 800 Mitarbeiter beteiligt. Der CIO vergleicht den Austausch der Hard- und Software mit einer Herztransplantation: "Unser Patient musste während des Eingriffs nicht nur wach bleiben, er musste in vollem
Umfang arbeitsfähig sein."
Legacy-Ablösung - Tipps von Praktikern
Vor einer Ablösung werterhaltende Maßnahmen prüfen:
- Austausch der Datenhaltung,
- Austausch der Benutzeroberfläche,
- Architekturverbesserungen hinsichtlich Modularisierung und - Schnittstellen,
- fachliche Erweiterungen, beispielsweise durchgängige - Mandantenfähigkeit der Software,
- Neuentwicklung einzelner Komponenten,
- Migration der technischen Plattform, um operationelle Risiken oder hohe Kosten durch alte Hardware zu reduzieren.
Stufenweises Vorgehen ist meist sinnvoller als "Big Bang": geringeres Risiko, Lernkurve.
Know-how-Träger des Altsystems im Boot halten.
Keine Ablösung um der Technik willen.
Prozessorientiertes Vorgehen: Neudefinition/Reorganisation der Prozesse schafft erst den geschäftlichen Nutzen.
Anforderungen begrenzen: Nicht gleichzeitig fachlich und technisch "alles neu" machen wollen.
Komplexität von Prozessen und Funktionen bedenken.
Trotz solcher Mammutprojekte sind Neuentwicklungen im Finanzsektor nicht die Regel, erläutert Rüdiger Azone aus der Geschäftsleitung des Münchner IT-Dienstleisters sd&m. Gerade im Transaction Banking - sprich Zahlungsverkehr, Wertpapier- und Kreditgeschäft - finden sich vielerorts noch klassische Legacy-Systeme mit Cobol-Anwendungen und hierarchischen IMS-Datenbanken auf Großrechnern.
Wichtigster Grund dafür sei der meist ungünstige "Business Case", formuliert der Finanzexperte. Einfacher ausgedrückt: Die Projekte rechnen sich nicht. Einerseits verursachen sie hohe Kosten und Risiken bei der Umstellung, andererseits bieten sie nur wenige Vorteile. Azone: "Die Differenzierungsmöglichkeiten zum Wettbewerb sind gering, wenn es etwa um Zahlungsverkehr oder das Wertpapiergeschäft geht." Die Fälle TAI und Postbank hingegen sind anders gelagert, denn dort gehört der Zahlungsverkehr zum Kerngeschäft. Beide Institute bieten ihre diesbezüglichen Abwicklungsdienste auch anderen Banken an.
Nach Azones Erfahrungen sind Versicherungen im Bereich der Kernanwendungen weiter fortgeschritten. Hintergrund ist der verschärfte Wettbewerb, verbunden mit einer größeren Produktvielfalt und spartenübergreifenden Geschäftsmodellen. Dennoch laufen auch hier viele Altsysteme seit mehr als zwanzig Jahren. "Der Leidensdruck ist einfach noch nicht groß genug", kommentiert auch Georg Fester vom IT-Beratungshaus Bearingpoint (vormals KPMG Consulting). "Die Anwendungen funktionieren ja." Hinzu kommt, dass für die komplexen Backoffice-Funktionen von Banken und Versicherungen bislang kaum Standardsoftware verfügbar ist. Die Beispiele Postbank und TAI zeigen, wie die hohen Entwicklungskosten über Kooperationen mit Softwareherstellern eingedämmt werden können.
Warum Unternehmen migrieren
Die Gründe für eine Ablösung von Backoffice-Systemen sind vielschichtig. Zu einer Migration kommt es typischerweise, wenn etwa die technische Plattform (Hardware, Systemsoftware, Entwicklungswerkzeuge) nicht mehr unterstützt wird. Auch hohe Wartungs- und Betriebskosten spielen häufig eine Rolle. Dringend geboten erscheint vielen Unternehmen eine Migration vor allem dann, wenn das Altsystem neue Produkte und fachliche Anforderungen nicht mehr ausreichend oder gar nicht unterstützen kann.
"Technische Gründe haben bei einer Ablösung immer weniger Gewicht", beobachtet August-Wilhelm Scheer, Gründer der IDS Scheer AG. Galt in den 90er Jahren etwa eine moderne Client-Server-Architektur schon als schlagendes Argument, stehe heute eine nutzenorientierte Sicht im Vordergrund. Auch rein funktionale Überlegungen hält Scheer für den falschen Weg. Er empfiehlt ein "prozessorientiertes Vorgehen".
Bei der Commerzbank gab dieser Aspekt den Ausschlag: "Der wichtigste Grund für die Umstellung war die Reorganisation der Prozesse", sagt Manager Lösch. Damit verbunden war eine Vereinheitlichung der heterogenen IT-Plattformen und eine deutlich höhere Datendurchsatzrate. Auch Postbank-CIO Berensmann hebt die Bedeutung der Prozessoptimierung hervor. Im Rahmen eines Redesigns sei es gelungen, die Komplexität der Operationsprozesse um rund 40 Prozent zu verringern. Von ursprünglich mehr als 120 Geschäftsprozessen seien noch 70 übrig. Deren Zahl soll nach Einführung der neuen SAP-Software auf weniger als 35 sinken.
TAI-Vorstand Steinbach gibt sowohl technische als auch funktionale Gründe an: "Das Altsystem funktionierte gut, aber der Suppport wurde schwierig. Die Leute sterben weg oder gehen in Pension." Ziel der Transaktionsbank sei es gewesen, eine modular aufgebaute und zukunftsfähige Plattform zu schaffen. Kunden könnten nun aus einem Katalog unterschiedlichster Zahlungsverkehrsdienstleistungen auswählen. Mit dem monolithischen Altsystem war dies nicht zu bewerkstelligen.
Vor einer Ablösung von Kernanwendungen sollten IT-Verantwortliche in jedem Fall "Maßnahmen zur Werterhaltung" prüfen, empfiehlt Azone. Denn gerade in den Altsystemen steckten immense Investitionen und Expertenwissen. Um die Nutzungsdauer zu verlängern und damit betriebswirtschaftliche Vorteile zu erzielen, gebe es eine Reihe praxiserprobter Maßnahmen: So ließen sich etwa mit einem Austausch der Datenhaltung moderne Datenbanktechniken und fachliche Erweiterungen nutzen. Eine Umstellung der Benutzeroberfläche auf Graphical User Interfaces (GUIs) oder Browser-basierende Thin Clients könne sowohl die Prozess- als auch die IT-Integration verbessern. Auch gezielte fachliche Erweiterungen wie eine durchgängige Mandantenfähigkeit der Software bringe etwa im Bankensektor zusätzliche Geschäftschancen in Form von
Insourcing.
Beispiel LVM-Versicherungen
Ein Beispiel für den Erhalt älterer Kernsysteme liefern die LVM-Versicherungen in Münster. Im Rahmen einer Neupositionierung der IT setzte CIO Werner Schmidt auf Web-basierende Techniken und eine durchgängige Rezentralisierung. In einem Serviceverbund kooperieren heute Thin Clients im Außendienst - ausgestattet mit Linux und Java-GUIs - stationär und mobil über ein Virtual Private Network (VPN) mit den Legacy-Systemen in der Zentrale. Die Kernanwendungen für sämtliche Sparten hingegen basieren weiterhin auf PL1 und IMS- sowie DB2-Datenbanken. Einige Applikationen stammen in der Urform noch aus den 80er Jahren, wurden allerdings weiterentwickelt: "Eine komplette Ablösung dieser Systeme ist weder bezahlbar noch beherrschbar", so der IT-Vorstand. "Freiwillig packt das keiner an."
Möglichkeiten zum Umstieg
Wer sich dennoch darauf einlässt, hat im Grunde zwei Möglichkeiten, erläutert Azone: Entweder eine stichtagsbezogene vollständige Ablösung ("Big Bang") oder einen stufenweisen Umstieg. Anzuraten sei generell Letzteres, auch wenn damit Nachteile verbunden sind: So führe der parallele Betrieb von Neu- und Altsystemen vorübergehend zu höheren Betriebskosten und einer längeren Projektlaufzeit. Demgegenüber verringere sich das Risiko im Vergleich zum Big Bang erheblich, zudem könnten Erfahrungen aus den ersten Stufen genutzt werden, um das System funktional und technisch zu verbessern.
"Eine Big-Bang-Ablösung ergibt eigentlich nur Sinn, wenn das neue System auf Basis einer Standardsoftware bereits weitgehend existiert und die Zusatzkosten für eine Stufung sehr hoch sind", so der Berater. Die Strategie des Ergo-Konzerns, Kernanwendungen der Versicherungstöchter jeweils in einem Zug auf ein einheitliches System umzustellen, hält er grundsätzlich für richtig (siehe CW 44/03, Seite 1). Denn die zugrunde liegenden Einzelanwendungen lagen in Form des Systems der Victoria-Versicherung schon vor. Trotzdem ergaben sich in dem Projekt ernste Probleme, weil nach der Umstellung etliche bisher genutzte Funktionen nicht mehr oder nur noch unzureichend zur Verfügung standen.
"Ablösungsprojekte scheitern nur selten an der Technik", konstatiert Azone. Schuld seien immer mehrere Faktoren, darunter auch das Projekt-Management. "Nicht selten läuft das Anforderungs-Management aus dem Ruder, wenn technisch und fachlich alles umgestellt werden soll", so seine Erfahrungen. Die schiere Größe der Umstellungsvorhaben scheint häufiger der Knackpunkt zu sein, wie auch TAI-Vorstand Steinbach bestätigt: "Die Komplexität der Prozesse und Funktionen wird häufig unterschätzt." LVM-Vorstand Schmidt hält dem einen evolutionären Ansatz entgegen: "Wir verbinden alte und neue IT-Welten." Fachliche Funktionen unter PL1 in den Legacy-Systemen binde die LVM in gekapselter Form in die neue Java-basierende IT-Struktur ein. Das schließe Anpassungen der Kernfunktionen nicht aus. Schmidt: "In den 80er Jahren galt oft noch die Devise: Nach fünf Jahren Nutzung ist eine Anwendung schrottreif. Diese Wegwerfmentalität ist vom Tisch."