 |
| Quelle: Wikipedia.org |
Die Rolle der IT wird für Banken immer wichtiger. Viele Banken haben denn inzwischen auch eigene Software-Entwickler angestellt. Auch wenn die Bank keine Tradition in der Software-Entwicklung hat.
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.
 |
| Quelle: Wikipedia.org |
Heute sagt eine Mehrzahl von Firmen von sich, dass sie sogenannt "agil" Software entwickeln. In Bezug auf den kompletten Software-Entwicklungsprozess handelt es sich aber in aller Regel um eine Pseudo-Agilität. So geben den bei Umfragen auch immer mehr Firmen an, dass sie nicht so ganz genau wissen, nach welcher Methode sie entwickeln.
Diese Pseudo-Agilität äussert sich etwa darin, dass meist nur die Software-Entwickler selber agile arbeiten. Der Auftraggeber und die Fachvertreter in der Regel nicht oder nur ungenügend. Oder es gibt trotz agilem Vorgehen einen Endtermin mit klaren Abnahmekriterien.
Diese Pseudo-Agilität hat zwei Ursachen:
1] Meist kennen nur die Software-Entwickler selber das agile Vorgehen und können sich mit diesem auch identifizieren. Andere Stakeholder schätzen zwar die Flexibilität, wollen die Nachteile aber trotzdem nicht akzeptieren.
2] Das agile Manifest hat einzelne Prinzipien, die sich so in der Praxis meist nicht 1:1 so umsetzen lassen.
Die Prinzipien vom agilen Manifest:
1] Zufriedenstellung des Kunden durch frühe und kontinuierliche Auslieferung von wertvoller Software:
Sicher ein wichtiger Aspekt. Wobei es hier nicht nur einfach um die Zufriedenstellung geht. Es ist vor allem auch eine vertrauensbildende Massnahme.
2] Agile Prozesse nutzen Veränderungen (auch spät in der Entwicklung) zum Wettbewerbsvorteil des Kunden:
Das wäre zwar schön, ist aber leider in der Realität ein Stück weit ein Feigenblatt des Manifests. Durch eine Änderung der Anforderung müsste allenfalls eine komplett andere Architektur der Software gewählt werden. Und alle bis dahin entwickelten Iterationen müssten gegeben falls nochmals entwickelt werden. Diese Zeit hat in der Praxis aber niemand - resp. will sich niemand nehmen und auch nicht bezahlen. Die Änderungen werden also in der Praxis mit den bereits vorhandenen Mitteln umgesetzt. Ob dies mittel- bis langfristig ein Wettbewerbsvorteil bringt, bleibt offen.
3] Lieferung von funktionierender Software in regelmässigen, kurzen Zeitspannen:
Ein guter Punkt, der zwei Aspekte abdeckt: Er dient auch der Stärkung des Vertrauens in die Entwicklung wie der Punkt 1. Weiter dient er auch der Motivation der Entwickler. Lauffähige Software motiviert mehr, auch wenn sie nur klein ist, als eine Menge Code wo man noch nicht weiss, ob er läuft.
4] Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes:
Ein guter Punkt - der leider in der Praxis längst nicht bei allen Projekten möglich ist. Gerade die echten wichtigen Fachexperten sind häufig im Tagesgeschäft. Dort werden sie gebraucht weil sie wichtig sind und deshalb sind sie auch Fachexperten. Ein Fachexperte der immer Zeit hat, ist wahrscheinlich kein echter Experte.
5] Bereitstellung des Umfeldes und der Unterstützung, welche von motivierten Individuen für die Aufgabenerfüllung benötigt werden:
Wichtiger Punkt. Gehört aber eher zu den allgemeinen Führungsaufgaben. Dies betrifft längst nicht nur die Software-Entwicklung oder ein agiles Vorgehen.
6] Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht:
Persönliche Kommunikation ist sehr wichtig und für grössere Projekte über eine längere Zeit nicht komplett ersetzbar. Dennoch bieten die neuen Technologien von Video-Telefonie/-Konferenzen und die Teilung von Inhalten hier effiziente Möglichkeiten.
7] Als wichtigstes Fortschrittsmass gilt die Funktionsfähigkeit der Software:
Das ist ein kleiner Trugschluss im agilen Manifest. Gerade zusammen mit Punkt 2] lässt sich der Fortschritt kaum messen. In der aktuellen Iteration hat man viele lauffähige Funktionen - und im nächsten Schritt muss man sie auf Grund von Veränderungen umschreiben und ergänzen. Damit lässt sich kaum ein Fortschritt messen. Es zeigt sich, dass gar nicht alle Prinzipien gleichermassen angewendet werden können.
8] Einhalten eines gleichmässigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern für eine nachhaltige Entwicklung:
Das wünscht sich jeder Fabrik-Manager. Ist aber eine Illusion. Gerade Softwareware-Entwickler in der kreativen Phase haben ein unregelmässiges Arbeitstempo. Auch sind die Auftraggeber und Benutzer meist nicht zu 100 % für ein Projekt zur Verfügung. Entsprechend können auch sie in aller Regel kein gleichmässiges Arbeitstempo erbringen.
9] Ständiges Augenmerk auf technische Exzellenz und gutes Design:
Ein sehr guter Vorsatz. Wie in Punkt 2] schon erwähnt würde dies aber dazu führen, dass man häufiger wieder ganz von vorne beginnen müsste. Das macht niemand. Die technische Exzellenz und das gute Design werden daher in der Praxis bei notwendigen Änderungen schön gefärbt. Man versucht so viel wie möglich mit der bereits entwickelten Lösung/Architektur zu realisieren.
10] Einfachheit ist essenziell:
Das ist ein weites Prinzip mit viel Spielraum für Interpretation. So in der Form in der Praxis wenig hilfreich.
11] Selbstorganisation der Teams bei Planung und Umsetzung:
Wäre ein schöner Ansatz, der in der Praxis aber selten funktioniert. Häufig alleine aus dem Grund, dass nicht alle Stakeholder nur dem Team angehören. Über deren Ressourcen lässt sich dann nicht einfach so verfügen, auch nicht über die Fachverantwortlichen als Beispiel. Das Prinzip reduziert sich dabei in der Praxis meist auf die Software-Entwickler selber. Auch kann in der Realität häufig nicht selbstbestimmt über Test-Ressourcen etc. verfügt werden. Diese müssen ordentlich geplant und bestellt werden.
12] Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung:
Guter Ansatz, der natürlich nicht nur für Software-Entwicklung gelten sollte. Als Team ist es in der Praxis meist deshalb nicht ganz einfach umsetzbar, weil die Teams als ganzes von Projekt zu Projekt nicht so stabil sind. Die Teams werden je nach Anforderungen und Themen jeweils (teilweise) neu zusammen gesetzt. Auch hier gilt. dass sich das Prinzip in der Praxis meist nur auf die Software-Entwickler selber bezieht.
Zwischenfazit:
Das agile Manifest kommt von Software-Entwickler und betrifft in erster Linie auch nur Software-Entwickler. Es ist aber auch für diese kaum möglich, allen Prinzipien gleichermassen gerecht zu werden. Es gibt potentielle inhärente Zielkonflikte. An einer Software-Entwicklung sind jedoch verschiedene Parteien beteiligt. Das Vorhaben der Software-Entwicklung als Ganzes mit allen Beteiligten, lässt sich daher kaum rein agil wie proklamiert umsetzen.
Braucht es ein Meta-Manifest?
Die Welt da draussen ist komplexer als einfache Methoden. Wo Menschen sind, gibt es Meinungen, Standpunkte und persönliche Interessen. Häufig wird mit einem Software-Projekt nicht nur das Ziel der Software selber verfolgt. Und das ist auch richtig so. Software soll Mittel zum Zweck sein. Aber welcher Zweck soll erfüllt werden? Nicht selten spielen Business-Strategien und Taktiken eine wichtige Rolle. All diese Themen sind im agilen Manifest überhaupt nicht adressiert.
Es stellt sich daher die Frage: Brauchen wir ein Meta-Manifest? Ein Manifest, wo andere Stakeholder und Betroffene als Software-Entwickler auch angesprochen werden? Ein Manifest, dass den ganzen Prozess der Software-Entwicklung abdeckt? Ein Manifest das Hinweise gibt, wie mit Zielkonflikten innerhalb der Prinzipien umzugehen ist?
