Donnerstag, 8. Januar 2015

Warum die Auswechslung des Kernbankensystems nicht "die" Lösung ist

Von Ralf Keuper

Wer sich etwas mit Kernbankensystemem auskennt, der kann David Gibbard in Why a Core Banking System Conversion is the Wrong Approach nur schwer widersprechen.
Die Zahl gescheiterter oder nur halb vollendeter Kernbanken-Transformationsprojekte ist nicht unbeträchtlich. Häufiger Grund ist, dass man sich zu viel auf einmal vorgenommen hat, und im Laufe des Projekts erkennen muss, dass Komplexität und Abhängigkeiten schlicht unterschätzt wurden. Es ist schon viel gewonnen, wenn es gelingt, den Buchungskern zu ersetzen, wie es die Finanz Informatik mit S-Buchen getan hat (Vgl. dazu: „Der Best-of-breed-Ansatz scheitert in der Praxis sehr oft“). Danach können dann sukzessive die anderen Module in Angriff genommen werden.

Dennoch konnten einige Banken wie Santander und die HypoVereinsbank ihre Kernbankenprojekt erfolgreich abschließen. Und auch die australische Common Wealth Bank (CBA) sieht sich durch die Einführung ihres auf SAP basierenden Kernbankensystems vollauf bestätigt. Inzwischen hat die Bank mit ihrer Plattform-Strategie eine neue Phase eingeläutet. Seit einiger Zeit tobt in Australien zwischen der ANZ Banking Group und CBA so etwas wie ein Glaubenskrieg, was die Erwartungen an Kernbankensysteme angeht. 

Es scheint so, als würde sich das Pendel in Richtung ANZ bewegen, d.h. der Weg der kleinen Schritte, wie ihn neben Gibbard auch Tom Groenfeldt in Core Banking Systems -- Gartner Says The Debate Has Shifted thematisiert. Mittels offener Schnittstellen (Open API) sei es mittlerweile möglich, Banksysteme schrittweise umzubauen, ohne gleich die ganze Applikationslandschaft auswechseln bzw. anpassen zu müssen. Überdies würden Standards wie BIAN dafür sorgen, dass dem Wildwuchs in der Banken-IT, auch bekannt als "Spaghetti-Phänomen", Einhalt geboten werden kann. 

Gibbard empfiehlt das folgende Vorgehen: 
Combining a presentation platform on top of a security layer, an integration layer with business and workflow engines, data analytics tied to back-end and stripped down core banking legacy systems will provide credit unions and banks with the flexibility, agility and lower risk profile necessary to offer members and customers the solutions they demand in order to compete in the rapidly changing retail financial services market.
Mit seinem Ansatz befindet Gibbard sich in erstaunlicher Nähe zu dem Modell, das vor einiger Zeit Jack Gavigan in What would a disruptive bank look like? vorgestellt hat. 

Das schrittweise, modulare Vorgehen hat darüber hinaus noch den Charme, dass die Entscheidungsträger in der IT nicht einen Big Bang zu verantworten haben, bei es dem letztlich nur heißen kann: Sieg oder Niederlage. 

So weit so gut. Allerdings besteht die Gefahr des modularen Vorgehens darin, irgendwann den Überblick zu verlieren und damit die alten Probleme wieder auf der Tagesordnung, wenn auch in anderer Form, auftauchen. 

Die Leserkommentare zu dem Beitrag von Gibbard versprühen nicht allzu großen Optimismus. Nach wie vor sei die Scheu in vielen Banken, überhaupt irgendetwas an der bestehenden Systemlandschaft zu ändern, stark ausgeprägt, was angesichts des dynamischen Marktumfelds doch ein wenig überrascht. 


Weitere Informationen:






Keine Kommentare:

Kommentar veröffentlichen