Bis in die Jahre 2014/2015 adressierte die Finanzdienstleistungsindustrie in regelmäßigen Abständen Kostenreduktions- und Effizienzthemen. Je nach Wirtschaftszyklus oder individueller Situation wurden in mehr oder weniger häufigen Abständen unterschiedlich große OPEX-Initiativen (Operationelle Exzellenz) oder Erneuerungsprogramme der IT-Architektur durchgeführt. Im Rahmen der Budget-Allokation standen diese Initiativen meist im Wettbewerb mit der Umsetzung regulatorischer Anforderungen, welchen, aufgrund der durch den Regulator vorgegebenen Termine, häufig Vorrang eingeräumt wurde.
Nach 2015 hat sich diese Situation nachhaltig geändert: Die Art und der Umfang neuer regulatorischer Anforderungen haben spürbar abgenommen. Der Druck zur Effizienzsteigerung und zur Kostenreduktion hat signifikant, unter anderem durch neue Wettbewerber wie Fintechs oder Bigtechs, zugenommen. Neue Technologien, wie robotergestützte Prozessautomatisierung, künstliche Intelligenz, Cloud oder auch Event-Streaming, entwickeln sich in einer Geschwindigkeit (weiter) und erreichen Marktreife, die viele Finanzdienstleister aus unterschiedlichen Gründen (beispielsweise Know-how, Compliance oder Architektur) kaum mitgehen können.
Und: Betriebsmodelle, Steuerung, Methoden und Organisation ändern sich ebenfalls so drastisch und schnell, dass Kontrolle und Führung einer permanenten Aktualisierung oder Reform bedürfen. Zum Einsatz kommen hier häufig Methoden, Frameworks oder Betriebsmodelle wie Design Thinking, SaFe, Dev Ops, BizDev Ops, Spotify-Modell oder skillbasierte Produktionssteuerung. Die Liste der sich schnell ändernden Rahmenparameter ließe sich leicht mit veränderten Kundenerwartungen, Fachkräftemangel, Ansprüchen der Generationen Y und Z oder die durch Covid-19 beschleunigten "New Ways of Working" erweitern.
In diesem veränderten Umfeld gestalten sich die Wege zur Effizienzsteigerung je nach Finanzdienstleister individuell und unternehmensspezifisch, was die Beratungsbranche mit ihren allgemeingültigen Schablonen oder dem sonst so geschätzten Benchmarking vor besondere Herausforderungen stellt. So treten im Hinblick auf drei zentrale Effizienzthemen weit verbreitete Mythen auf, die in diesem Artikel gemeinsam mit Lösungsansätzen aufgezeigt werden: Erstens, der Wechsel der Kernbankensystem-Lösung führt zu effizienteren Prozessen und einer optimierten Kostenstruktur. Zweitens, mit einer Lift-and-Shift-Strategie in die Cloud werden kurzfristig IT-Kosten reduziert. Drittens, die agile Gestaltung und Denkweise der Organisation verkürzen die Produkteinführungszeit deutlich.
Wechsel der Kernbankensystem-Lösung
Im Zuge der oben dargestellten Trends besteht seit zwei bis drei Jahren eine signifikant gesteigerte Nachfrage hinsichtlich Fragestellungen im Zusammenhang mit dem Austausch der Kernbankensysteme (unter anderem zu Strategie, Architektur und Integration sowie Systemauswahl). Das ist insofern leicht nachvollziehbar, als dass die meisten Kernbankensysteme in die Jahre gekommen und damit technologisch nicht mehr auf dem neuesten Stand sind. In der Folge generieren sie enorme Lizenz- und Wartungskosten und stellen einen elementaren Eckpfeiler in der aktuellen oder angestrebten Gesamtarchitektur dar.
Die großen Hoffnungen, die mit einem Wechsel des Kernbankensystems einhergehen, liegen neben der Kostenreduktion in Bezug auf Lizenzen und Wartung insbesondere in
- einer reduzierten Produkteinführungszeit,
- einer effizienteren Entwicklung für neue, erweiterte oder digitalisierte Produkte und Dienstleistungen,
- schlankeren Gesamtbankprozessen,
- einer höheren Datenqualität beziehungsweise -nutzung.
Lektionen und Ursachen
Erfahrungsgemäß bleiben die erzielten Resultate allerdings hinter den angestrebten zurück. Hier ein kurzer Auszug aus den gelernten Lektionen und identifizierten Kernursachen: Im Rahmen der Vorbereitungen werden weitere strategisch wichtige Überlegungen wie Sourcing, Banking-as-a-Service oder Cloud-Optionen kaum tiefergehend analysiert und diskutiert.
Außen vor bleiben in den meisten Fällen außerdem konsequente Ansätze zur nachhaltigen Produkt- und Produktvarianten-Simplifizierung. Diese historisch gewachsenen manuellen und technischen Komplexitäten werden aus vermeintlich "vertriebsorientierten Kundenzugeständnissen" in immensen Anforderungen abgebildet und über mehrere Dekaden technisch wie prozessual mitgeschleppt.
Bei der Anforderungsaufnahme orientiert man sich so stark am bisherigen System, dass das neue System mehr oder weniger das alte System abbildet. Prozessstandardisierungen oder -optimierungen werden, wenn überhaupt, nur oberflächlich durchgeführt.
In das bisherige System wurden, historisch gewachsen, so viele Funktionalitäten und Services implementiert, dass zunächst eine Entflechtung stattfinden muss, bevor das Kernbankenprojekt angegangen werden kann. Hier findet zwar keine Standardisierung oder Optimierung statt, aber eine sehr wertvolle Entkopplung.
Je nach Architektur kann es sein, dass die Komplexität von Art und Umfang der Schnittstellen, zu und von dem bisherigen Kernbankensystem, stark unterschätzt werden und hier ebenfalls Entflechtungsanstrengungen notwendig werden.
Die Konsequenz, mit der Leitsätze wie zum Beispiel "Bank follows IT" eingehalten werden, schwankt im Projektverlauf stark, sodass schlussendlich deutlich umfangreichere Anpassungen an dem neuen Kernbankensystem gemacht werden müssen als ursprünglich geplant.
Um das teure und lange Kernbankenprojekt über die Ziellinie zu bringen, werden im letzten Drittel des Projektes Funktionalitäten aus dem Projektumfang gestrichen oder Restanten bei Softwarefehlern in Kauf genommen und dafür sogenannte Behelfslösungen entwickelt. Diese Behelfslösungen haben nicht nur über viele Jahre hinweg Bestand, sondern verursachen durch ihren häufig manuellen Charakter dauerhaft erhöhte Prozesskosten. Dies wird jedoch aus Sicht des Kernbankenprojektes meist billigend in Kauf genommen.
Dies sind nur einige mögliche Ursachen dafür, dass sich die mit dem neuen Kernbankensystem einhergehenden Hoffnungen nicht materialisieren. Darüber hinaus zeigt die Erfahrung, dass ab einem gewissen Zeitpunkt während des Kernbankenprojektes - getrieben durch gesteigerten Ressourcenbedarf, Komplexität und Abhängigkeiten - alle anderen Transformationsanstrengungen für eine längere Periode angehalten oder gestoppt werden. Die angestrebten Effekte dieser Initiativen bleiben in der Konsequenz damit auch auf der Strecke.
Lift-and-Shift-Strategie
Was Effizienz und Kosten betrifft, bietet insbesondere die Cloud mit ihren Möglichkeiten große Chancen. Hardware-, Wartungs- und IT-Personalkosten werden für alle Systeme, die in die Cloud migriert oder dort aufgebaut werden, reduziert oder gar vermieden. Da das allerdings nicht für alle Systeme gleichermaßen möglich oder sinnvoll ist, wird in nahezu allen Fällen eine hybride Cloud-Architektur angestrebt.
Beim Begriff "Cloud-Computing" muss zwischen der "Private" Cloud und der "Public" Cloud unterschieden werden, was erste Einschränkungen im Hinblick auf Kostenreduktion und Effizienz bedeutet. Die insbesondere bezüglich sensibler Daten sicherere private Cloud ist grundsätzlich als reine Virtualisierung von Hardware-Kapazitäten zu verstehen und ermöglicht weder die Reduktion der Wartungs- und IT-Personalkosten, noch können die wertvollen Funktionalitäten wie zum Beispiel hoch skalierte analytische Auswertungen oder schnellere Softwareupdates genutzt werden.
Neben der angestrebten Kostenreduktion gehen diese Initiativen - ähnlich wie bei Kernbankensystemen - mit den Hoffnungen einher, betriebliche Effizienz, Agilität und Flexibilität bei der Integration oder den Performancemerkmalen zu steigern. Indirekt soll damit auch hier die Produkteinführungszeit so verbessert werden, dass bessere Return on Investments (ROIs) und Umsatzsteigerungen möglich werden.
Auch hier zeigen die Erfahrungen, dass die erzielten Effekte nicht den initialen Hoffnungen entsprechen.
Effekte entsprechen nicht Erwartungen
Die Analysen identifizieren auszugsweise folgende Kernursachen: Für größer angelegte Migrationsvorhaben in die Cloud und nachfolgende Weiterentwicklungen, Anbindungen oder Performance-Management fehlt es an ausreichend ausgebildeten oder erfahrenen Ressourcen. Eine erfolgreiche Cloud-Journey erfordert, dass das Unternehmen nicht nur über das Know-how verfügt, um die Cloud-Infrastruktur bereitzustellen, zu konfigurieren und zu verwalten, sondern auch um sicherzustellen, dass die Anwendungen in der Cloud laufen. Während einige Anwendungen migriert werden können, erfordern andere eine Umgestaltung, um kompatibel zu sein.
Die Kosten und Komplexität der Migrationen werden unterschätzt. Dies betrifft alle Schritte eines fabrikorientierten Ansatzes bezüglich Migration und Migrationsunterstützung - inklusive technische und fachliche Bewertung, Validierung, Umgestaltung und Maßnahmenmanagement, Priorisierung und Backlog-Management, Planung und Vorbereitung aller Wellen sowie die operative Produktion.
Ohne die entsprechenden Automatisierungswerkzeuge in der IT sowie der damit verbundenen Flexibilisierung und Modularisierung steigen die Kosten im Betrieb zunächst deutlich an. Zwar bietet die Cloud das Potenzial für eine massive Skalierung, doch kann die Verwaltung dieser Skalierung mit vorhandenen Ressourcen schwierig sein, wenn sie manuell durchgeführt wird.
Die Transparenz und das Know-how im Umgang mit Kapazitäten und Performancemanagement ist nicht in ausreichender Form vorhanden. Die Skalierungsmöglichkeiten von Rechnerkapazitäten sollten exakt auf den Bedarf jeder einzelnen Applikation abgestimmt sein.
Erst in der öffentlichen Cloud können essenzielle Funktionalitäten und die damit einhergehenden Mehrwerte genutzt werden. Trotzdem fällt es den Organisationen teilweise schwer, eine nachhaltige, im besten Fall auf alle Kerngeschäftsfelder abgestimmte Strategie zur Nutzung der bekannten Cloud-Vorteile zu definieren. Gründe dafür können Zweifel an der Technologie selbst oder die Angst vor Datenunsicherheit, etwaigem Datenverlust und den damit einhergehenden Reputationsrisiken sein.
Im Rahmen einer Migration in die Cloud mangelt es oft an der erforderlichen Unterstützung der Fachbereiche. Da es sich aber häufig um einen Lift-and-Shift-Ansatz und keine langfristige Strategie handelt, entsteht für die Geschäftseinheiten zunächst kein spürbarer Mehrwert.
Die Effekte sind Ressourcenkonflikte und Verzögerungen insbesondere bei komplexeren Applikationen. Die meisten der aufgeführten Kernursachen für eine fehlende, geringe oder verspätete Realisierung der initial angestrebten Effekte sind strategischer Natur, deren systematische Aufbereitung insbesondere zusammen mit dem nächsten Mythos erfolgen wird.
Agile Gestaltung und Denkweise
In den vergangenen Jahren haben Finanzdienstleister insbesondere in den Change-the-Bank-Einheiten, also der Transformationsorganisation, in zunehmenden Maße Agilität eingeführt. Dazu wurden Kommunikationsmaßnahmen und Schulungen zu den verschiedenen am Markt befindlichen Rahmenwerken durchgeführt wie zum Beispiel Scrum, SaFe oder LeSS. Darüber hinaus wurde in einigen Fällen sogar eine Agilisierung der Run-the-Bank-Einheiten, also des operativen Betriebs, angegangen. Auch hier gibt es eine Reihe von Methoden wie Spotify, DevOps, BizDev-Ops oder Projekt-zu-Produkt.
Wie bei den ersten beiden Mythen sollen die Prozesse dabei schneller und flexibler werden, Produkte eine höhere Qualität haben, besser auf die Kunden abgestimmt sein und schneller an den Markt gebracht werden. Dezentralere Entscheidungen und eine bessere Kollaboration gehören ebenfalls zu den angestrebten Zielen. Fairerweise kann man anerkennen, dass hier im Vergleich zu den beiden erstgenannten Mythen grundsätzlich ein höherer Deckungsgrad zwischen Ambitionen und Ergebnissen erzielt wird. Bei genauerer Analyse gilt dies jedoch hauptsächlich für die Organisationseinheiten der Transformation. Bei den operativen Einheiten und einer Einführung von DevOps oder BizDevOps bleiben die Ergebnisse aber noch weit hinter den Potenzialen zurück.
Unbefriedigende Resultate
Die erzielten Effekte weichen auch hierbei von den Erwartungen ab. Dies lässt sich hauptsächlich auf folgende Ursachen zurückführen: Die Einführung von Agilität und agilen Methoden ist häufig eine Top-Down-Entscheidung ohne Zieldefinition, Strategie und ausreichende Kommunikation. Sie wirkt damit dem eigentlichen zentralen Ziel eines kulturellen Wandels entgegen. Zusätzlich richtet sich die Einführung agiler Methoden oft an einzelne Projektteams, die in der Zusammenarbeit mit klassischen Projekten und Organisationen schnell an ihre Grenzen stoßen. Sowohl die Motivation als auch die agile Grundeinstellung leiden darunter unmittelbar.
Es werden auch nicht alle Facetten der agilen Transformation berücksichtigt. Häufig bleibt die erforderliche Organisationsstruktur oder eine Steuerung zur einheitlichen Werkzeug-Nutzung auf der Strecke. Ebenso wird eine möglichst heterogene und aus IT und Fachbereichen bestehende Teamzusammensetzung gerne vernachlässigt. Diese hat einen enormen Effekt auf die Projektergebnisse und die Umsetzungsgeschwindigkeit.
Zeit und Budget zur Einführung und zum Know-how-Aufbau bei Schlüsseltechnologien sind nicht ausreichend. Flexibilität, Adaptierbarkeit und Modularisierung werden erst mit Microservices, Continuos-and-Container-based-Deployment sowie Integration erreicht. Der Umgang mit den entsprechenden Werkzeugen muss gemeinsam gelernt und in Prozessen gefestigt werden. Diese Ursachen haben meist zur Folge, dass die Einführung einer agilen Transformation deutlich länger dauert, die Effekte erst später realisiert werden und gerade die talentiertesten Mitarbeiter mit Frustration zu kämpfen haben.
Auflösung der Mythen
Der Idee folgend, dass jedem Mythos ein Wahrheitskern zu eigen ist, liegen interessante Lösungsansätze zur Realisierung der angestrebten Effekte sowohl in einer weiteren Technologie, dem Event-Streaming, als auch in der holistischen und integrierten Betrachtung der drei Themen.
Ereignis-getriebene (Event-getriebene) Architekturen und Prozesse sind ein Weg, viele der oben genannten Kernursachen zu adressieren. Mittels eines "Datennervensystems" (Event-Streaming-Technologie) werden Systeme und Applikationen entkoppelt und komplexe Punkt-zu-Punkt Integrationen aufgelöst.
Events sind dabei Daten, Geschäftsvorfälle und Kundeninteraktionen in beliebiger Granularität, die in einer stringenten und nicht manipulierbaren Reihenfolge (Stream) aufbereitet (Log) und in Echtzeit an beliebig viele Abonnenten der Events gesendet werden können. Im Vergleich zu aktuellen IT-Architekturen erfolgt hier ein Paradigmenwechsel von batch-getriebenen "Pull"-Prozessen zu Echtzeit "Push"-Prozessen mit einem hohen Grad an Automatisierung. Das Log- und Streamverfahren wird dabei hohen Anforderungen an Verfügbarkeit und Integrität gerecht. Einerseits ermöglicht die individuelle Verarbeitung von Events beziehungsweise Geschäftsvorfällen den Übergang zu Mircoservices innerhalb der Event-Streaming-Plattform; andererseits wird diese Technologie durch den Wegfall klassischer Schnittstellen immer mehr als Integrationskomponente auch für Kernbanksysteme genutzt.
Bridge-to-Cloud-Ansatz
Aufbauend auf dieser Grundkonzeption wurde das Konzept der "Bridge-to-Cloud" entwickelt (Abbildung 1). Der Ansatz sieht vor, dass man eine neue Applikation wie zum Beispiel ein Kernbankensystem in der Cloud aufbauen kann und sukzessive mit dem existierenden Kernbankensystem über die Event-Streaming-Technologie synchronisiert.
So lassen sich schrittweise Anforderungen und Funktionalitäten im neuen Kernbankensystem etablieren, testen und wenn nötig mit Ergebnissen des bisherigen Kernbankensystems vergleichen. Ziel ist es gerade nicht, das alte Kernbankensystem zu reproduzieren, sondern gemeinsam mit den damit einhergehenden Prozessen signifikant zu verbessern.
Während dieser Zeit bleibt das bisherige Kernbankensystem vollständig produktiv und ist nach wie vor an alle Schnittstellen angebunden. Sukzessive werden dann die Umsysteme von den Schnittstellen abgekoppelt und über den Event-Stream bedient. Nach der entsprechenden Analyse und Simplifizierung können auch die historisch gewachsenen Funktionalitäten und Services entflochten und neu allokiert werden. Dies gilt umso mehr für ungewünschte Komplexitätstreiber in Produkten oder Produktvarianten, die in diesem Zuge so allokiert werden, dass später eine strategische De-Kommissionierung möglich wird, ohne die Anforderung im neuen Kernbankensystem abbilden und von Version zu Version mitschleppen zu müssen. Durch solche Allokationsmöglichkeiten kann auch anders mit Leitsätzen wie "Bank follows IT" umgegangen werden.
Wenn dann ohne Reduktion des Implementierungsumfangs und den damit einhergehenden behelfslösungsinduzierten Prozesskosten alle erforderlichen Funktionalitäten im neuen Kernbankensystem vorhanden und getestet sind, kann das bisherige Kernbankensystem abgeschaltet werden. Das neue Kernbankensystem geht in Produktion und erstellt den Event-Stream für alle Umsysteme.
Dadurch, dass beide Kernbankensysteme permanent synchronisiert sind, ermöglicht der Bridge-to-Cloud-Ansatz eine graduelle Transformation und senkt dadurch das Projektrisiko. Auch alle anderen Transformationsprojekte können weiterlaufen und ihre Ergebnisse abliefern. Da der Ansatz weder Migration noch Schnittstellen erfordert, ist es darüber hinaus unbedeutend, ob und inwieweit die Umsysteme bereits in die Cloud migriert wurden oder nicht.
Mit diesem Ansatz werden viele der Punkte aus den Mythen 1 und 2 direkt angesprochen und die Wahrscheinlichkeit, die gewünschten Effekte zu erzielen, deutlich erhöht.
Die integrierte Betrachtung
Es besteht ein untrennbarer Zusammenhang zwischen dem Umsetzungs- und damit dem Reifegrad eines Unternehmens im Hinblick auf die Cloud-Aktivitäten auf der einen und dem Automatisierungsgrad beziehungsweise der Agilität der IT auf der anderen Seite (Abbildung 2). Beide Aspekte bedingen sich insofern einander, als dass die Cloud Skalierungsmöglichkeiten bietet, die nur mit einer entsprechenden Automatisierung in der IT und Agilität handhabbar sind. Oder umgekehrt gesehen machen weitere Steigerungen in der Effizienz und Automatisierung der IT nur dann Sinn, wenn auch die dafür erforderliche Infrastruktur gegeben ist.
In diesem Reifegradzusammenhang gibt es eine optimale und natürliche Entwicklung entlang der Winkelhalbierenden, wenn von Anfang an beide Aspekte integriert miteinander betrachtet, weiterentwickelt und gesteuert werden. Werden, aufgrund von Kostendruck oder organisatorischer Ungleichgewichte, die beiden Aspekte nicht integriert entwickelt, ergeben sich entsprechende Abweichungen von der Winkelhalbierenden, welche, im Nachgang analysiert, zu Mehraufwänden im Bereich Zeit und Budget führen. Die Verzerrungszone soll andeuten, dass dies wahrscheinlich häufiger der Fall im Bereich der IT-Automatisierung ist.
Für jeden Reifegrad auf jeder Achse wurden entlang der dahinterliegenden Dimensionen (Strategie/Planung/Steuerung, Transformationskultur, Betriebsmodell, Kompetenzen, Automatisierungs- und Cloud-Prozesse, Werkzeuge) die jeweiligen Zustände beschrieben (beobachten und ad hoc, prüfen und lösen, anwenden und systematisieren, messen und institutionalisieren, optimieren und anpassen). Die hier ausgewählten Dimensionen gelten gleichermaßen für beide Achsen, auch wenn je Reifegrad die Zustandsbeschreibungen voneinander abweichen, da sie einen anderen Betrachtungsgegenstand haben.
Eine zentrale Erkenntnis der Analysen ist, dass auch hier die Dimensionen integriert miteinander betrachtet und entwickelt werden müssen. Ist eine dieser Dimensionen nachhaltig unterentwickelt, können die anderen dies nicht kompensieren. Wenn zum Beispiel die ersten fünf Dimensionen einen fortgeschrittenen Reifegrad haben, die notwendigen Werkzeuge oder Instrumente allerdings nicht zur Verfügung stehen, können die anvisierten Effizienzen weder in der IT-Automatisierung noch in den Cloud-Aktivitäten gehoben werden.
Dies zu erkennen - für jede einzelne Achse, aber auch über beide Achsen hinweg - ist für eine gezielte Budget-Allokation von herausragender Bedeutung. Wird genau die richtige, nachhaltig unterentwickelte Dimension zur Budget-Allokation ausgewählt, kann dies für die gesamte Organisation eine enorme Beschleunigung darstellen. Im anderen Fall werden die ROIs weit hinter den Erwartungen zurückbleiben. Um bei dem Beispiel zu bleiben, wird eine Investition in die richtigen Werkzeuge zu einem wahren Durchbruch führen. Weitere Investitionen in eine der anderen Dimensionen werden aufgrund der fehlenden Werkezuge kaum Effekte generieren.
Zusammenfassend lassen sich über alle drei Themen folgende Kernaussagen formulieren:
- Alle drei Aspekte (sprich Kernbankensysteme, Cloud-Technologie sowie Agilität) sind zentrale Hebel zur nachhaltigen Effizienzsteigerung und Kostenreduktion - sowohl für die Transformation als auch den operativen Betrieb.
- Alle drei Aspekte sind heute so eng miteinander verknüpft, dass es einer integrierten Betrachtung, Planung und Umsetzung über alle Planungs- und Umsetzungshorizonte hinweg bedarf: strategisch, taktisch und operativ.
- Eine möglichst optimale Budget-Allokation zur gezielten und integrierten Weiterentwicklung aller drei Aspekte erfordert eine kontinuierliche Soll-Ist-Analyse der darunterliegenden Dimensionen: Strategie/Planung/ Steuerung, Transformationskultur, Betriebsmodell, Kompetenzen, Automatisierungs- und Cloud-Prozesse sowie Werkzeuge.
Erst durch diese integrierte Betrachtung der Aspekte und Dimensionen wird die Wahrscheinlichkeit maximiert, mit der die anvisierten Effekte sich vollständig realisieren lassen und damit auch die Rentabilität der mit diesen Initiativen einhergehenden Investitionen.
