Komplexität kostet Geld, viel Geld. Rund 40 Prozent ihrer Kapitalmarktkosten gehen allein bei den größeren Instituten inzwischen drauf, um regulatorische Vorgaben einzuhalten. Wer heute sagt, wir hätten seit der Finanzkrise vor etwas mehr als zehn Jahren immer noch nichts gelernt, kennt diese Zahl nicht. Mag sein, dass wir falsch regulieren, auf jeden Fall regulieren wir nicht zu wenig. Das Problem: Was gesetzlich vorgegeben ist, ist noch lange nicht alles, was Banken versuchen in geregelte Bahnen zu lenken.
Wo Komplexität entsteht
Komplexität entsteht beispielsweise dadurch, dass veraltete IT-Systeme auf Apps, Fintechs und Open Banking treffen. Sie entsteht auch durch immer mehr Kanäle, die Banken bedienen müssen, und durch branchenfremde Konkurrenten, die auf den Markt drängen und die letzten lukrativen Bastionen ihrer Geschäftsmodelle angreifen. Robinhood (Trading), Square mit der Cash App (P2P Payments) oder Neobanken wie N26 und Revolut zielen darauf, Banking viel leichter zugänglich zu machen, also die Komplexität aufzulösen oder zumindest vor ihren Kunden zu verstecken. Das gelingt ihnen typischerweise mit diesem Dreiklang:
- Greenfield IT
- Digital Ecosystems
- Agile Mindset
Warum sich Komplexität leichter bewältigen lässt, wenn eine Bank keine Rücksicht auf ihre digitalen Altlasten nehmen muss, ist ziemlich offensichtlich. Dass es digitalen Angreifern aus dem gleichen Grund leichter fällt, ihr Geschäft weiterzuentwickeln, leuchtet auch ein. Square hat erst vor kurzem 29 Milliarden US-Dollar hingeblättert, um den australischen Bezahldienst Afterpay zu kaufen. Das ergibt Sinn: Später zu bezahlen ist eine tolle Funktion, die gut in das eigene Ecosystem passt. Die unbelastete IT macht‘s möglich. Mindestens genauso wichtig ist aber auch die richtige Einstellung – ein Mindset, das sich Banken antrainieren können.
Die Rede ist von Agilität. Sie gilt als die entscheidende Fähigkeit, in komplexen Situationen die richtige Entscheidung zu treffen; oder überhaupt zu entscheiden. Viele Banken sitzen wie das Kaninchen vor der Schlange, weil sie jahrelang geübt haben zu planen, zu steuern und zu warten. Sie warten auf den nächsten Kunden, der gemäß ihren dokumentierten Abläufen auch heute noch bevorzugt in die Filiale kommt. Sie warten auf den nächsten Release-Termin und sie pressen alles, was sie verändern wollen, in diese zeitlichen Korsetts. Und sie tun das, weil sie dadurch Unklares klarer machen und Unsicheres sicherer.
Zweidimensionale Komplexität
Eine Aufgabe lässt sich besonders leicht lösen, wenn sie besonders klar formuliert ist und jeder sofort versteht, was zu tun ist, um sie zu lösen. Solche Aufgaben sind simpel. Schwerer wird’s, wenn eine Aufgabe unbestimmt formuliert ist. Wie: Kunden wollen nicht mehr in die Filialen gehen, sondern…? Nicht immer lässt sich beobachten, was Kunden wollen, immer aber, was sie nicht wollen. Zudem handelt es sich um zweidimensionale Unsicherheit, weil nur handeln kann, wer das Problem konkret versteht und zugleich über das richtige Besteck verfügt, um es zu bearbeiten.
Methoden wie kontinuierliche Verbesserungsprozesse (KVP) oder Projekt- und Multiprojekt-Management versuchen, die daraus entstehende Komplexität aufzufangen und bearbeitbar zu machen. Dahinter steckt die Idee, den sich ausdehnenden Entscheidungsraum besser zu kontrollieren. Dashboards, Visualisierungen und Technologie helfen dabei, möglichst viele Parameter zu erfassen, um entscheiden zu können. Insofern ist viel von der Komplexität, die wir bearbeiten wollen, selbstgemacht. Die technischen Möglichkeiten führen aber auch dazu, viel von der Komplexität erst aufzudecken, die von vornherein in einer Aufgabe steckt. Sie ist also nicht nur selbstgemacht, sondern zumindest teilweise immanent.
Agile Methoden schlagen nun vor, sich dieser Komplexität nicht mehr durch Planen, Steuern und Kontrollieren zu nähern, sondern durch Probieren, Erkennen und Reagieren. Oder flapsig formuliert: durch Trial and Error. Ähnlich wie bei der Komplexität, die in zwei Dimensionen ansteigt, kämmt dieser Spruch gleich doppelt gegen den Strich vieler Banken. Einerseits läuft dieses Prinzip dem vielfach immer noch streng hierarchischen Planungsprimat zuwider und andererseits verlagert sich das Ausprobieren und Scheitern von oben nach unten. Agile Teams ziehen das Problem nicht näher an sich heran, sondern bewegen sich darauf zu.
Das richtige Operationsbesteck
Ralph Douglas Stacey hat diese Bewegung beziehungsweise den Spielplan, auf dem sich die agilen Teams bewegen, kartographiert. Die nach ihm benannte Stacey-Matrix spannt von den Kategorien klar bis unklar die beiden Dimensionen „Anforderungen“ und „Technologie“ auf (vgl. Abb.1). Wer sich auf diesen beiden Achsen nach oben oder nach rechts bewegt, verlässt also früher oder später bekannte Räume und gelangt von einfachen über komplizierte und komplexe bis hin zu chaotischen Situationen. Je weiter die Teams in unentdeckte Länder geraten, desto eher drohen die bisher verwendeten Instrumente zu scheitern.
Abb. 1: Die Stacey-Matrix zeigt Problemlagen und geeignete agile Methoden, um sie zu lösen. Quelle: Eigene Darstellung.
Die Stacey-Matrix soll dabei helfen, die richtigen agilen Werkzeuge auszuwählen. Kanban oder Scrum, Design Thinking oder Lean Startup – je nachdem, wo sich das Problem verortet, eignen sich andere dieser Methoden. Wie immer bei solchen Schemata gilt: Vorsicht ist die Mutter der Porzellankiste. Sich zu früh für ein Framework zu entscheiden, kann dem Projekt auch schaden. Was die Stacy-Matrix aber perfekt visualisiert, ist die Tatsache, dass nicht mehr im Nullpunkt oder an der Spitze des Wasserfalls entschieden werden kann. Das muss an der Front passieren, dort also, wo die agilen Teams arbeiten und konkret auf das reagieren, was sie vorfinden.
Darin steckt ein ernstzunehmender kultureller Wandel: Wenn vor Ort entschieden wird, ist die gesamte organisationale Infrastruktur, also die gewachsene Hierarchie – von Lenkungskreisen über Planungsstäbe – praktisch überflüssig. Umgekehrt bedeutet das aber auch, dass schneller am Ziel ist, wer sich auf diese neue Entscheidungskultur einlässt. Ohnehin reißen gerade mehr und mehr Mauern ein, weil Data Scientists, Fachabteilungen und die IT mehr gemeinsam statt nacheinander in ihren jeweils eigenen Silos arbeiten. DevOps und MLOps (für KI) setzen sich zunehmend auch in den gewachsenen Organisationen von Banken durch.
Nicht von ungefähr bekennt sich eine wachsende Zahl von Vorständen dazu, keiner Bank, sondern einer Technologiefirma vorzustehen. Schon vor fünf Jahren erklärt Marianne Lake, CFO von JPMorgan: „We are a technology company.“ Kurz darauf, 2017, der häufiger damit zitierte CEO von Goldman Sachs, Lloyd Blankfein, nahezu wortgleich: „We are a technology firm. We are a platform". Das Phänomen bleibt aber nicht auf den US-amerikanischen Markt beschränkt. Im gleichen Jahr erklärt der damalige ING-Chef Ralph Hamers, heute UBS, sein Unternehmen sei eine „Tech Company with a Banking Licence“. Es liegt nahe, sich dann auch damit zu beschäftigen, wie eine Techfirma arbeitet – und zwar agil, weil sich Software in einer klassischen Wasserfall-Organisation nicht gut entwickeln lässt.
Agil handeln versus agil sein
Vielen Banken fällt schwer, wirklich zu verinnerlichen, was agil bedeutet. Agil ist nicht, wer sich einmal die Woche morgens am Stehpult mit seinem Team austauscht, nur weil auch der Scrum-Master das so macht. Agilität lässt sich nicht auswendig lernen und anwenden, es geht vor allem um die innere Haltung. Warum und wie gerade kleinere Institute davon besonders profitieren, erläutert Jörg Ruwe, Bereichsleiter IT bei der Hypo Vorarlberg, in seinem Vortrag auf der „Banking & Technology“-Konferenz vom 30. Sept. - 1. Okt. 2021 in Wien.
Autor
Kay Wossidlo ist Partner bei Senacor Technologies und spezialisiert auf die digitale Transformation von Banken und Versicherungen.
Veranstaltungstipp:
Banking & Technology | 30. Sept / 1. Okt 2021, Wien
