![]() |
Quelle: Wikipedia.org |
Wenn sich eine Bank entscheidet selber Software zu entwickeln, dann stellt sich auch die Frage, wo es denn sinnvoll ist, selber zu entwickeln.
Die alte Frage nach Make or Buy - die Frage nach Standardsoftware einkaufen, oder individuell entwickeln, lässt sich längst nicht mehr so schwarz/weiss formulieren.
Alles komplett selber entwickeln kann niemand, auch die ganz grossen nicht - es rechnet sich einfach nicht. Die Vorteile von Standardkomponenten sind betriebswirtschaftlich zu gross. Aber nur auf Standardsoftware setzen? Dadurch wird sich eine Bank künftig zu wenig differenzieren können - first oder late mover nur mit Standardsoftware? Kaum vorstellbar.
Die Frage ist daher nicht ob selber entwickelt werden soll, sondern was.
Im Detail hängt dies natürlich von den individuellen Stärken der Mitarbeiter ab und nicht zuletzt vom Geschäftsmodell.
Wenn die Bank einen Spezialisten für Namensabgleiche hat, kann es unter Umständen interessant sein, die diesbezügliche Software selber zu entwickeln. Hat die Bank keine eigene Expertise, wird es sich kaum lohnen dieses aufzubauen und selber eine solche Software zu entwickeln. Ist eine Bank hauptsächlich im Bereich Zahlungsverkehr oder Konsumkredite tätig, so wird der Entscheid der Eigenentwicklung auch anders ausfallen, als bei einer normalen Retailbank.
Auf einer etwas abstrakteren Ebenen lässt sich aber durchaus allgemein diskutieren, wo der Fokus einer Eigenentwicklung unter Umständen sinnvoller ist.
CORE bei CORE-Bankingsystemen steht für Centralized Online Realt-time Exchange. Als der Begriff mit einer neuen Generation von solchen Bank-IT-Systemen aufkam, war zentral und realtime tatsächlich neu. Heute würde man diese beschriebenen Eigenschaften vielen verschiedenen Systemen/System-Architekturen geben. Neue Trends wie IoT oder Blockchain gehen weg von "centralized", aber der "Online-Realtime-Charakter bleibt.
Die Frage, was den zu einem CORE-Banking-System dazu gehört und was nicht, ist so alt wie der Begriff selber.
Mehr und mehr macht sich im Markt die Meinung breit, dass das CORE-Banking-System die zentrale Auftrags- und Buchungsmaschine im Hintergrund ist. Die Diskussion, welche Teilsystem denn nun dazugehören sollen und welche nicht, würde hier zuweit führen.
Es gibt aber vermehrt einen Konsens, dass die eigentliche Kundenschnittstelle, also alle Systeme die der Endkunde zu Gesicht bekommt, eigentlich nicht zum CORE-Bankingsystem als solches gehört. Dazu gehört sicher das klassische E-Banking, Mobile-Banking, Bezahl-Apps, Personal Finance Manager-Applikationen, Berechnungs-Tools etc.
Wenn wir das Bild haben, dass es zwischen dem CORE-Bankingsystem - der zuverlässigen zentralen Auftrags- und Buchungsmaschine - und den Kundenapplikationen einen Unterschied gibt, dann können wir die Frage stellen: Soll eine Bank am CORE-Bankingsystem und deren Funktionen selber programmieren, oder an den Kundenapplikationen. Sollen externe Entwicklungsaufträge eher für CORE-Funktionen an Dritte vergeben werden, oder für Funktionen der Kundenapplikation?
Wenn wir zurück zur Frage der betriebswirtschaftlichen Leistung kommen, werden wir feststellen, dass CORE-Funktionen für die meisten Banken gleich sein werden. Ein Auftrag bei der Bank A wird nicht massgeblich anders abgewickelt als bei der Bank B. Eben so wenig unterscheidet sich die Zinsrechnung der Bank A von jener der Bank B. Selbst bei den Gebühren sind die Unterschiede nicht derart gross, als dass sie nicht in einem generischen Modell modelliert werden könnten (auch wenn gewisse Banker hier vielleicht leicht anderer Meinung sind). Eine Bank wird sich dadurch kaum je von der Konkurrenz unterscheiden können. Anders sieht es bei den Kundenapplikationen aus. Hier geht es um das Kundenerlebnis und darum, auch im digitalen Bereich den individuellen Fussabdruck hinterlassen zu können.
Mit Standardsoftware im Endkundenbereich wird sich eine Bank kaum massgeblich von der Konkurrenz abgrenzen können. Auch Time-to-Market wird schwierig, wenn man auf den Standardsoftware-Anbieter warten muss.
Auf Grund des möglichen USP und den betriebswirtschaftlichen Überlegungen wird es sich für eine Bank in aller Regel mehr lohnen, die Kundenschnittstelle mit eigenen Software-Entwicklern zu beherrschen als die dargelegten CORE-Banking-Funktionen. Zumal es im Endkundenbereich ohnehin keine fertige Standardsoftware für alle Kanäle gibt. Da braucht es ohnehin immer noch individuelle Entwicklungsaufträge. Umso mehr stellt sich die Frage, weshalb nicht gleich (fast) alles selber entwickeln im Endkundenbereich.
In der Schweiz sind bereits mehrere Banken (teils seit längerem) so aufgeteilt. Diese Aufteilung lässt sich auch schön im Bimodalen-Modell von Gartner modellieren. Im Mod1 mehrheitlich die (robusten, etablierten) CORE-Funktionen von Standardanbietern und im Mod2 mehrheitlich die flexiblere Eigenentwicklung im Endkundenbereich.
Das kommt auch der Compliance entgegen. Werden Compliance relevante Aspekte im robusten Mod1 (für mehrheitlich Aufsichts- und Strafrechtliche Themen) umgesetzt und bei vielen Banken eingesetzt, erhöht dies die Sicherheit und das Vertrauen. Compliance relevante Aspekte in der Kundenschnittstelle beziehen sich dann mehrheitlich auf das zivilrechtliche vertragliche Verhältnis mit dem Kunden. Dort muss Compliance ohnehin die sauber Umsetzung unter Berücksichtigung der bankindividuellen Verträge sicherstellen.
Keine Kommentare:
Kommentar veröffentlichen