Versicherungsbetriebe > Strategie

23.02.2018 von Markus Alberth, Managing Principal bei Capco

Sanierung der Kernbanksysteme

Fast jede Bank kümmert sich um das Thema ­Digitalisierung. Dabei fällt auf, dass die IT-Landschaften vieler Banken dafür zum großen Teil überhaupt nicht vorbereitet sind. Wer glaubt, dass dies nur ein paar Nachzügler ­betrifft, der irrt. Es betrifft große Teile der Finanzbranche und nur die wenigsten sind ­bereits auf den Start neuer, digitaler Zeiten vorbereitet.

Standardanwendungen versprechen Kosteneinsparungen

Die IT der Banken ist über Jahrzehnte organisch gewachsen. IT wurde erstmals in den 1970er Jahren im großen Stil in der Branche eingeführt. Alles war neu, Institute befanden sich in einer Pionierphase. Dementsprechend gab es so gut wie keine Standardprogramme. Jede Bank oder auch Bankengruppe entwickelte ihre Anwendungen für den Eigenbedarf selbst. 

An diesen IT-Kern wurde angebaut, umgebaut, erneuert, jeweils mit den aktuell besten Technologien, nur manches Alte wurde ersetzt. Um die Gesamtperspektive – zumindest für die jeweilige Geschäftseinheit – zu behalten, wurden die Landschaften IT-architektonisch immer wieder strukturell umgeformt, wobei diese Restrukturierungen aus Budgetgründen nicht immer finalisiert wurden: erst Einzelbetrieb, dann Application to Application Integration, dann ­Layerarchitektur mit Enterprise Integration Bus sowie Service-orientied Architecture (SOA). Standardanwendungen wurden plötzlich am Markt verfügbar, aber bis zur Unkenntlichkeit customized. Die steigende Anzahl regulatorischer Vorgaben führte zu weiteren Eingriffen, Verbindungen, Reparaturen und Änderungen. Viele Projekte wurden oft kostenoptimiert, d. h. komplexere Probleme mit teureren Lösungen wurden nicht direkt gelöst, sondern über Work­arounds. Quick Wins waren wichtiger als echte Lösungen. Outsourcings im Betrieb oder in der Entwicklung „veredelten“ das Ganze noch. Durch den Merger von Banken wurden einige dieser IT-Landschaften auch noch teilweise zu einem neuen Ganzen ­verbunden. Ergebnis ist heute ein zähes, ­inhomogenes IT-Geflecht verschiedenster Technologien und Altersstufen.

Das hat seinen Preis. Es entstehen Risiken wie regulatorische Compliance-Probleme und BaFin-Moniten: das „Liegenlassen“ von Umsatzpotenzialen, das Verpassen vieler Möglichkeiten der digitalen Welt machen den Instituten zu schaffen. Viele Technologien stehen kurz vor oder bereits nach ihrem End of Lifecycle, d. h. sie sind ohne Support und werden nicht weiterentwickelt. Auch Ressourcenknappheit und Wissensverlust für proprietäre, d. h. selbsterstellte Technologien (z. B. durch Pension von Mitarbeitern mit Kenntnissen exotischer alter IT-Sprachen) gehen oft mit schlechter Dokumentation einher und werden so zum Problem. Technisch führt das unüberschaubare IT-Gewebe immer wieder zu Betriebsausfällen an Terminals und IT-Arbeitsplätzen in Filialen und im Bereich Operations. Mitarbeiter und Maschinen stehen still und das Kundengeschäft bleibt liegen. Notwendige Änderungen werden immer teurer, da Eingriffe immer komplexer werden. Die Situation wird zum Bremsklotz für den ­Anschluss an die digitale Welt. Und so wächst die Einsicht, dass die IT-Landschaften saniert werden müssen. Dafür braucht es Ziele wie regulatorische Compliance, Kontrolle, Betriebsstabilität, Skalierbarkeit, Schnelligkeit im Betrieb (Near-Realtime) sowie Schnelligkeit in der Einführung von geschäftlichen oder regulatorischen Neuerungen (Time to Market), technologische Unabhängigkeit und größeren Handlungsspielraum gegenüber Partnern. Ein aktuell sehr starkes Motiv ist außerdem substanzielle Kostensenkung. Und alles sollte ­strategisch nachhaltig sein, also eher nicht ­Workaround oder Quick-Win orientiert.

Ansatz fürs Handeln 

Ausgangspunkt sollte die betrieblich-funktionale Gesamtsicht der Bank sein mit Blick „nach vorne“ – und nicht die bestehende IT-Landschaft mit Blick „nach hinten“, denn es soll ja ein Geschäftszweck bestmöglich erreicht werden. Es macht also Sinn, sich vom Bestehenden mental frei zu machen und gedanklich auf der grünen Wiese zu beginnen und dann auf die Ausgangslage ­zurückzukommen, um den besten Weg zu finden. So erhalten dringend benötigte übergreifende Datenkonzepte, größtmögliche Automatisierungsquoten, neue Organisationskonzepte wie DevOps und digitale Umsatzpotenziale wie Internet der Dinge oder die Bedienung neuer, digitaler Assistenten der Kunden die richtige Priorität ohne gleich am Status Quo zu scheitern.

 

Geänderte Rahmenbedingungen

Dies ist einfacher gesagt als getan. Mit der Digitalisierung ändern sich die Geschäftsmodelle der gesamten Branche. Der Finanz­intermediär wird durch die neuen Peer-to-Peer Finanztransaktionen immer weniger benötigt: Bitcoin ermöglicht Zahlungen ohne die Einbindung eines Zahlungsdienstleisters, zukünftige Blockchain-Aktien ermöglichen den Handel ohne Depotbank, Kreditplattformen ermöglichen gegensei­tige Kreditgewährung ohne Fristen- und Risikotransformation eines Kreditinstituts. Dafür entstehen neue Rollen, in welche Banken hineinwachsen können, etwa als Treuhänder, Garantieinstitute, Plattformanbieter, Datenclearer für Finanztransaktionen im Internet der Dinge usw. Die daraus entstehenden neuen Anforderungen schlagen voll durch auf die Neuausrichtung Kernbanksysteme. Um diese zu formulieren steht gerade eine neue Position, nämlich die des Chief Digital Officers (CDO) auf der Businessseite im Tandem mit dem ­altbekannten CIO auf der Technologieseite.

Kosteneffizienzen heben

Ein weiterer Aspekt bei der Systemsanierung der Kernbanksysteme ist die Erwartung zukünftiger Kosteneffizienzen. Wenn schon so viel investiert wird, dann soll sich das auch im ROI bemerkbar machen. Ein wesentliches Kriterium für einen solchen Erfolg ist die Einbeziehung aller Beteiligten mit Beiträgen zu den Total Costs of Ownership. Eine Modernisierung der Kernbanksysteme wird häufig durch die IT betrieben. Die zukünftige Kostenstruktur entsteht aber vor allem in der Bedienung dieser Systeme, also im Vertrieb und den Operations. Wenn diese nicht von Anfang an einbezogen werden, führt dies später sehr häufig zu Überraschungen. Die Effektivität und Effizienz der IT hängt dabei vor allem erst mal von der Effektivität und der Effizienz der technisch umgesetzten Prozesse und der später noch manuell zu erbringenden Prozesse ab. Effizienzen bei den IT-Kosten können an anderer Stelle mit Ineffizienzen in der Bedienung teuer erkauft werden. Einen großen Einfluss auf die Prozesse hat auch die „Sperrigkeit“ der neuen Kernbanksysteme. Um IT-Kosten zu sparen, sollen die neuen Standardsysteme gewöhnlich so wenig wie möglich customized werden. Dann muss sich der Bankbetrieb aber oft an den neuen Systemen ausrichten, statt umgekehrt. Selbst die benötigten Profile der Mitarbeiter können sich dadurch ändern. Unterstützen die neuen Standardsysteme z. B. eher tay­lorisierte Arbeitsteilung in den industrialisierten Operations oder werden spezialisierte Know-how-Träger bedient, die mehr handwerklich arbeiten? Die Planung der zukünftigen Kosten sollte also weniger auf Annahmen beruhen als auf detaillierter Kenntnis der konkreten Umstände.

Onsite oder outsourcen?

Das Lösungsmosaik bietet Alternativen: Heute werden alle gängigen Bankleistungen als Standardsoftware angeboten mit onsite oder outgesourctem Betrieb oder gleich in der Cloud (SaaS). Diese können die bestehende IT-Landschaft komplett oder modulweise ersetzen. Wer sich gar nicht mehr mit IT-Technologie belasten möchte, kann auch fast alle Bankleistungen als Gesamtpaket inklusive der Operations-Leistung als Business Process Outsourcing von außen zukaufen und zwar als klassisches Outsourcing oder auch als Cloud-Service-Leistung (XaaS). Ob diese von einem freien Anbieter bezogen werden oder von einem gebundenen Anbieter eines IT-Bank-Verbunds ist nicht relevant, solange die festgelegten Ziele bzw. Anforderungen optimal erfüllt werden. Die Notwendigkeit der Datenschutz-Compliance wird mittlerweile von vielen Anbietern verstanden und durch entsprechende Maßnahmen sehr gut gewährleistet. Es verbleiben je nach Entscheidung einzelne IT- bzw. BP-Steuerungsthemen wie beispielsweise ein einheitliches Datenkonzept oder die Netzwerksteuerung, z. B. im Bereich API-Banking, sowie natürlich die Providersteuerung. Noch konsequenter kann sich eine Bank auf die Vertriebskompetenz beschränken und gleich komplette Brand- oder White-Label-Produkte ins Sortiment aufnehmen. Hier wandert sogar das Risiko auf die Seite des Providers, der dann auch eine Banklizenz mitbringen muss. Der easyCredit der ­­­Volks- und Raiffeisenbanken ist so ein Beispiel, der von der Teambank produziert wird.

Es kann durchaus Sinn machen, die heute zum Großteil vergleichbaren Bankleistungen komplett zuzukaufen und nur noch die Themen in der IT selbst voranzutreiben, die tatsächlich eine Differenzierung am Markt versprechen. Auch Standardsoftware kann erst mal schwerlich differenzieren, es sei denn wieder um den Preis eines starken Customizings. Das Bankhaus Metzler geht diesen Weg z. B. seit Jahrzehnten.

Auch das Umsetzungsprojekt hat Wahlmöglichkeiten. Je nach Risikoappetit und Budgetverfügbarkeit kann der Übergang entweder über „1000 Releases“, über klar definierte wenige Phasen (typisch sind zwei bis fünf Phasen) oder über einen einzigen Big Bang organisiert werden. Je mehr Releases gewünscht sind, desto mehr müssen Alt- und Neulandschaft interimsweise über „Durchstiche“ verbunden werden. Alt­systeme werden mit Daten aus Neusystemen „rückversorgt“, Neusysteme greifen auf historische Daten aus Altarchiven zurück, solange diese nicht migriert wurden. Regulatorische Neuerungen müssen in der Parallelphase gleichzeitig in Alt- und Neusystemen implementiert werden. Da dies Schritt für Schritt vorangeht, sinkt das Unfallrisiko, denn die Probleme und Komplexitäten werden kleingeschnitten, und ein fehlerhafter Release kann jederzeit zurückgenommen oder durch einen Hotfix geheilt werden. Die ständige „Neuverdrahtung“ der Systeme dauert aber dafür substanziell länger als ein Big Bang und ist deshalb auch entsprechend und spürbar teurer.

Aktive Entscheidung gefordert 

Die Entscheidung, wo architektonisch begonnen und in welche Richtung gearbeitet wird, ist aktiv zu treffen. Außer beim Big Bang, bei dem die Umstellung in einem Zeitpunkt erfolgt, müssen Abhängigkeiten jeweils im Alt- und Neusystem sowie zwischen diesen Systemen beachtet werden. Ehemals integrierte Funktionen einer Software können zukünftig in Standardmodulen völlig neu geschnitten sein. Altsysteme im Backend enthalten z. B. oft noch Code für die Aufbereitung des Outputs, etwa eines Druckbildes, was in neueren Architekturen durch einen eigenen Presentation Layer und entsprechende Output Management Systeme separiert wird. Dadurch können Änderungen in Layout, Sprachen und die Anreicherung des Outputs mit weiteren Informationen aus anderen Systemen unkompliziert gesteuert werden – und zwar kanalübergreifend. Ein weiteres Beispiel ist die Entkopplung von Kernbanksystemen und den Multikanal-Frontends. Neue Kernbanksysteme bieten gewöhnlich einen eigenen Integration Layer, mit dem einerseits die Kernbanksysteme, andererseits die Frontends standardisiert verbunden werden. So kann z. B. zunächst ein neuer Integration Layer zwischen beide Altkomponenten „getrieben“ werden, wodurch die ­Erneuerung von Front- und Backends ­ent­koppelt wird und unterschiedliche Geschwindigkeiten möglich werden. Gerade der Frontendbereich verlangt heute ja größere Releasehäufigkeiten als die Backends. Die Erneuerung der Kernbanksysteme erfolgt dann häufig serviceorientiert, also ­entlang der Kunden, Kredit-, Konto-, Wertpapiersysteme usw. Im Parallelbetrieb von Alt- und Neusystemen ist dabei die Fest­legung der Master-Slave-Beziehungen ­notwendig, damit immer ein eindeutiger juristischer Datenbestand definiert ist.

Auch die Programmorganisation ist höchst relevant. Zunächst ist die Governance erfolgskritisch. Ein solches Projekt benötigt einen Sponsor direkt im Vorstand. Die bereits oben angeregte Einbeziehung aller für die zukünftige Nutzung und die Gesamtkostenstruktur relevanten Stakeholder sollten in einem effizient auf Entscheidungen ausgerichteten Steering Committee erfolgen. Ein disziplinierter Change Request Prozess sichert das Projekt gegen äußere Einflüsse ab. Neben die klassische Wasserfallorganisation im Projektvorgehen tritt ein modernes Fabrikkonzept, das für jeden Prozess einen eigenen kleinen Wasserfall ermöglicht. Dies erhöht die Agilität und sichert während der Projektlaufzeit kontinuierliche Ergebnisse. Change Requests sind besser steuerbar und entfalten keine Breitenwirkung auf das Gesamtkonzept eines Gesamtwasserfalls. So bieten sich z. B. Fabriken für die Überarbeitung von Prozessen, die Umsetzung in Datenkonzepte, die technische Konzeptionierung, das Testen und den Rollout an. Erfolg und Misserfolg großer Vorhaben wie der Sanierung von Kernbanksystemen können dadurch entschieden werden. Das Risikomanagement hat Projektrisiken laufend zu erfassen, zu bewerten und proaktiv zu entschärfen, noch bevor das Risiko zum Issue wird. Ein Issue Management ist konsequent zu steuern und Eskalationswege müssen vorab definiert werden. Transparenz für alle Beteiligten erzeugt Buy-in und stärkt die Motivation. Hier sind die Interessen aller Beteiligten von Anfang an klar zu adressieren. Durch ein solches Großprojekt ­ändern sich zukünftige Aufgaben und ­Verantwortlichkeiten, so dass Ängste und Widerstände entstehen können. Diese müssen mit eigens dafür geplanter Kapazität begleitet werden. Darüber hinaus ist auch die externe Governance durch den Regulator zu beachten und BaFin/Bundesbank sind frühzeitig in die Planungen mit einzubeziehen. Hilfreich sind hierbei auch Pre-Implementation-Audits der eigenen Revision, um die größten Überraschungen zu vermeiden.