Neben den verschiedenen Herausforderungen für Banken befassen sich viele Finanzinstitute auch mit der Prüfung ihres bestehenden Kernbankanbieters oder stehen vor der Auswahl eines neuen Kernbanksystems, um dem Wandel am Markt und einer zukunftssicheren Aufstellung ihrer IT gerecht zu werden. Sowohl eine grundlegende Neuausrichtung als auch ein Wechsel des Kernbanksystems sind zweifellos komplexe Unterfangen, sowohl für die Bank als auch den jeweiligen Anbieter. Die entsprechenden Projekte und Migration laufen oft über mehrere Jahre und sind mit hohen Kosten und Belastungen für das Team der Bank als auch signifikanten Risiken verbunden.
Trotz des sich hieraus ergebenden lukrativen Marktumfelds für Kernbankanbieter aufgrund des großen Veränderungs- und Anpassungsbedarfs bei den Banken, konnte sich kein Marktführer etablieren. Weder eines der großen Verbundrechenzentren noch eines der neuen Unternehmen aus der Start-up/Fintech-Szene überrennen den Markt mit ihrer Kernbanklösung. Dies liegt unter anderem daran, dass jede Bank unterschiedliche Anforderungen und Rahmenbedingungen mit sich bringt und dass auch der jeweilige Geschäftszweig zu berücksichtigen ist.
Da es im Kernbankenumfeld keine One-size-fits-all-Lösung gibt, besteht weiterhin ein großer Beratungsbedarf bei den entsprechenden Migrations- und Transformationsprojekten. Ein aus unserer Sicht unterbewertetes Thema in diesem Kontext ist das Releasemanagement. Hierbei sollte dem Releasemanagement bereits im Auswahlprozess einer Software-Lösung eine gewichtige Rolle beigemessen werden. In vielen Fällen beschränkt sich der gesamte Bewertungs- und Auswahlprozess fast ausschließlich auf die funktionale Sicht und offensichtliche, Kosten-bestimmende IT-Kriterien. Natürlich sind Themen wie der funktionale Umfang oder auch die Kosten maßgeblich und somit meist die primären Elemente für die gesamte Bewertung. Als etablierte Managementberatung hat EGC bereits verschiedene Kernbankmigrationen sowie die dazugehörenden Anbieterauswahlprozesse erfolgreich begleitet. Erfahrungsgemäß lässt sich daher sagen, dass neben diesen fachlichen und betriebswirtschaftlichen Themen ebenso die Strategie zur Weiterentwicklung und Erhaltung der Zukunftsfähigkeit des Kernbanksystems entscheidend für eine langfristig erfolgreiche Kernbankmigration ist. Vor diesem Hintergrund ist das Releasemanagement bei der System- und Anbieterauswahl als weiteres Fokusthema bezüglich des späteren Lebenszyklus der Kernbankanwendung mit zu betrachten. Erfahrungsgemäß tritt regelmäßig das Releasemanagement bei nicht ausreichender Betrachtung und Berücksichtigung bei der Anbieterentscheidung und der Erstimplementierung als Problemfeld auf, das ab diesem Punkt aber nicht mehr weitgehend zu verändern ist.
Die Bedeutung des Releasemanagements für Banken
Unter Releasemanagement verstehen wir die Prozesse, das Zusammenarbeitsmodell und die Strategie zur Weiterentwicklung eines Kernbanksystems samt seiner Umsysteme und Schnittstellen im Rahmen des laufenden Betriebs. Ziel des Releasemanagements ist es, das Kernbanksystem immer auf dem aktuellen Stand zu halten. Dies bedeutet, dass das Kernbanksystem regelmäßig an neue Anforderungen angepasst wird. Hierunter fallen neue oder sich ändernde regulatorische Anforderungen, Änderungen durch Kundenwünsche und -anforderungen oder technische Updates im Sinne der Modernisierung des Systems, Anpassung an geänderte Kapazitätsanforderungen sowie die Sicherstellung der IT-Security und IT-Compliance. Das Releasemanagement und die damit verbundenen Test- und Changeverfahren verbinden damit Kernbankanbieter und Bank langfristig in der gemeinsamen operativen Arbeit. Seitens EGC konnten wir auch hier an verschiedenen Stellen Herausforderungen und Hindernisse in der Releaseplanung und -bearbeitung unserer Kunden sowie im Markt wahrnehmen. Beispielsweise sind hier die Art und Weise der Einbindung von Bankressourcen in die inhaltliche Weiterentwicklung des Kernbanksystems – zumal, wenn eigenentwickelte Teile des Systems fortbestehen bleiben – oder auch die Häufigkeit von erforderlichen bzw. möglichen Releases inkl. deren zeitlichen Planung und verbundener Aufwände zu nennen.
Wesentliche Unterschiede in den ReleaseStrategien
Um die Auswirkungen einer gewählten Releasestrategie auf den laufenden Betrieb konkreter fassen zu können, werden nachfolgende Dimensionen des Releasemanagements näher beleuchtet.
Um die Unterschiede verschiedener Releasestrategien in diesen Dimensionen besser aufzeigen zu können, wird hierfür zwischen zwei Extremen am Beispiel der Häufigkeit von Releases unterschieden. Zum einen ein großes Release pro Jahr, zum anderen, bei einer eher agilen Herangehensweise, viele kleine z.B. wöchentliche Releases.
Die Releasestrategie eines jeden Kernbankanbieters lässt sich demnach zwischen diesen beiden Extremen verorten. Es ist zu beachten, dass je nach Einzelfall eine Ausprägung in den Dimensionen als Vor- oder Nachteil, entsprechend der Ausgangslage und Strategie einer Bank unterschiedlich interpretiert werden kann.
Planung und Zyklen:
Die Strategie eines großen Jahresreleases zeichnet sich meist durch sehr lange Vorlaufzeiten in der Planung und Bearbeitung des Releases aus. Es ist nicht unüblich, dass die Planung ein bis zwei Jahre im Voraus angestoßen wird. Der oftmals sehr große und langwierige Planungsaufwand bewirkt jedoch, dass weitere Eigenschaften dieser Releaseausprägung geringe Ausfallzeiten sowie geringere Verspätungen bei den Inbetriebnahmeterminen der Releases sind. Dem gegenüber steht ein großer Aufwand bei Änderungen in dem einmal festgelegten Releaseplan. Zum Teil unauflösbare Abhängigkeiten der im Release enthaltenen Komponenten, verdichten sich zu einem „Alle oder keiner“-Problem. Dies macht aufwändige Planungen und Vorbereitungen für einen eventuell erforderlichen Rollback notwendig. Hierfür können jedoch prozessuale Alternativen oder Möglichkeiten geschaffen werden, um dem entgegenzuwirken.
In einer eher agilen Vorgehensweise mit mehreren kleinen Releases pro Jahr sind die konkreten Planungszeiträume in der Regel mit einer deutlich kürzeren Vorlaufszeit versehen als bei wenigen großen Releases. In einer agilen Arbeitsweise werden hier die Releases aus einem Pool an Anforderungen, dem Product Backlog, implementiert und in Betrieb genommen.
Kundeneinbindung:
Die Einbindung einzelner Kunden mit individuellen Wünschen ist bei einem Jahresrelease oftmals begrenzt möglich. Bei vielen individuellen Anforderungen einzelner Kunden ist eine strikte Priorisierung und Bewertung dieser Anforderungen notwendig. Bei begrenzten Ressourcen des Kernbankanbieters ist eine Umsetzung aller Wünsche und Anforderungen oftmals nicht möglich. Die Einbindung einzelner Kunden ist hierbei stark von der Gesamtzahl an Kunden des jeweiligen Kernbankanbieters abhängig. Bei einer hohen Anzahl an Kunden sind die individuellen Wünsche begrenzt umsetzbar, bzw. nur mit gesondertem Auftrag inklusive Bezahlung möglich. Zudem gibt es Grenzen in der Anpassbarkeit der Kernbanksoftware, damit nicht aus einem gemeinsamen Kern oder Template mit wohldefinierten Kundenspezifika eine Menge an Individualimplementierungen ohne hilfreiche Standards und Skaleneffekte entsteht.
Bei der Einbindung in die Produktgestaltung stehen verschiedene Kunden und ihre Anforderungen unter Umständen in Konkurrenz oder gar im inhaltlichen Widerspruch zueinander – explizit, wenn es darum geht, eigene Wünsche und Anforderungen in den Releases unterzubringen bei nur begrenzt verfügbaren Ressourcen in den Phasen Releasebearbeitung und -vorbereitung. Oftmals haben die kleineren und „weniger wichtigen“ Banken in diesem Fall mit ihren Anforderungen das Nachsehen. In dieser Hinsicht positiv zu werten ist, dass eigene Ressourcen geschont werden können, wenn man nicht oder nur geringfügig in die Releasebearbeitung eingebunden ist und auch ohne eigene Initiative von dem Input anderer Kunden profitiert. Beispielsweise bei regulatorischen Anforderungen, die ja meist alle Marktteilnehmer betreffen.
Ein anderer Ansatz des Themas Kundeneinbindung geht in die Richtung „Rundum-sorglos-Paket“. Der Kunde erwartet vom Kernbankanbieter, dass Veränderungen bspw. aus regulatorischer Sicht eigenständig gegenüber dem Kunden aufgezeigt und das Kernbanksystem entsprechend weiterentwickelt wird. Der Kunde setzt und vertraut hierbei weitestgehend auf den durch den Vendor angebotenen Standard, um eigene Ressourcen und Kapazitäten zu schonen.
Flexibilität:
Mit etablierten agilen Arbeitsmethoden, meist im Zusammenhang mit vielen kleineren Releases, ist die Flexibilität bezüglich Planungsänderungen oftmals höher. Kurzfristige Wünsche und Anforderungen von Kunden können leichter umgesetzt werden. Diese Flexibilität muss zum einen jedoch durch eine entsprechende Gremienstruktur ermöglicht werden, welche kurzfristige Neu- und Umpriorisierungen erlaubt – also keine behördliche Pflichtenheftdenke, sondern agiles Anforderungsmanagement mit entsprechenden Entscheidungen. Zum anderen müssen die Architektur des Kernbanksystems und seiner Schnittstellen zu Umsystemen, die Testeinrichtungen und die Deployment- und Fehlerkorrekturverfahren durch Entkopplung von Komponenten diese Flexibilität ermöglichen, z.B. in einer „forward-only and fast fixing“-Strategie. Dem gegenüber steht ein höherer Aufwand für die notwendigen Abstimmungen mit verschiedenen Ansprechpartnern bei diesen Neu- und Umplanungen.
Die aufgezählten Eigenschaften sind nicht als abschließende Aufzählung anzusehen, sondern verdeutlichen, dass je nach Ausgangslage und eigenen Fähigkeiten der Bank die verschiedenen Aspekte des Releasemanagements unterschiedlich zu betrachten und zu bewerten sind. Bezogen auf die verschiedenen Eigenschaften muss jede Bank individuell bewerten, in welche Richtung sie ihr Releasemanagement ausrichten möchte und für wie wichtig sie dieses Kriterium für die Zusammenarbeit mit ihrem Kernbankanbieter erachtet.
Fazit
Die Auswahl eines Kernbanksystems und -anbieters ist eine strategische Entscheidung mit weitreichenden Folgen. Aufgrund des großen Aufwands und der Risiken beim Wechsel eines Kernbanksystems ist die einmal getroffene Entscheidung meist sehr langfristig. Da offensichtliche Faktoren wie der funktionale Umfang oder auch die anfallenden Kosten der Anschaffung und des Wechsels berechtigterweise im Fokus stehen, möchten wir seitens EGC am Beispiel des Releasemanagements aufzeigen, dass auch weitere, oftmals erst im laufenden Betrieb schlagende Faktoren mit in die Entscheidung für oder gegen einen Kernbankanbieter einbezogen werden müssen. Das Beispiel Releasemanagement zeigt hierbei deutlich, dass es wesentliche Unterschiede in einer langfristigen Zusammenarbeit zwischen Bank und Kernbankanbieter geben kann, welche es sorgfältig im Voraus zu prüfen gilt. Wichtig hierbei ist, dass es keine Musterlösung für den einen richtigen Kernbankanbieter gibt, sondern eher eine Abwägung, wie kompatibel der Anbieter zu den Bedürfnissen und realistischen eigenen Fähigkeiten der Bank und ihrer Kunden ist. Denken Sie heute bereits an Morgen!
Im Regelfall umfassen die Auswahlprozesse eines Kernbankanbieters deutlich mehr Aspekte als die zuvor dargestellten. Dennoch konnten wir als EGC feststellen, dass die unzureichende Gewichtung und der Grad der Betrachtung vermeintlich unwichtiger Kriterien im Nachhinein zu Unzufriedenheit, kostspieligen Folgeprojekten oder einer erneut notwendigen Kernbanksystemauswahl geführt haben. Dies gilt es gleich zu Beginn des Auswahlprozesses zu vermeiden – EGC unterstützt Sie mit der entsprechenden Erfahrung gerne in diesen Fragen.
Autor: Dennis Wildner