Interview mit Arne Schultz, Innobis

Software Development im Bankenbereich

Im Interview betont Arne Schultz, Leiter Development & Integration Services bei der Innobis AG, welchen Stellenwert Standard Banking Software wie SAP Finance im Vergleich zu Individualsoftware bei der Software-Entwicklung im Bankenbereich hat.

Arne Schultz, Innobis

SAP-Berater Arne Schultz: „Individual Software ist vor allem in jenen Bereichen empfehlenswert, die für die Differenzierung gegenüber dem Wettbewerb kritisch sind.“

IT-DIRECTOR: Herr Schultz, welchen aktuellen Stellenwert genießt Standard Banking Software?
A. Schultz:
Der Einsatz von Standardsoftware insbesondere im Bereich der sogenannten Kernbankensysteme ist in deutschsprachigen Finanzinstituten allgemein ein positiv belegtes Thema. Dazu passt auch der Trend, dass die Anzahl der auf Standardsoftware setzenden Banken zunimmt. Aktuelle prominente Beispiele in Deutschland sind u.a. die Deutsche Bank und ihr Magellan-Projekt sowie die KfW mit der Einführung von SAP Finance. Individualsoftware wird im Gegensatz dazu häufig mit veralteten Legacy-Systemen gleichgesetzt, die in der Regel noch auf Großrechnersystemen laufen. Gleichzeitig lässt sich erkennen, dass der Anteil der Legacy-Kernbankensysteme weiterhin hoch ist. Bedeutsam ist in diesem Zusammenhang die Tatsache, dass offenbar mit dem Einsatz von Standardsoftware nicht zwangsläufig der Verzicht auf – durchaus umfängliche – Individualentwicklung einhergeht. So erklärten 54 Prozent der befragten Banken in einer PWC-Studie, an der Nutzung von individuellen Datenverarbeitungen festhalten zu wollen.

IT-DIRECTOR: Welche Erwartungshaltung haben Finanzinstitute an die Standard-Software-Hersteller?
A. Schultz:
Um sich dieser Frage zu nähern, ist es wichtig, zunächst einmal die Begrifflichkeiten genauer anzusehen. So wird Standardsoftware u.a. als Softwaresystem definiert, das einen klar definierten Anwendungsbereich abdeckt und als vorgefertigtes Produkt erworben werden kann. Die Erwartung von Finanzinstituten an die Standard-Software-Hersteller geht aber meist deutlich über diese Definition hinaus. Gegenüber einem vollständigen Individualansatz fordern Banken insbesondere Kosteneinsparungen, Sicherheit, Zukunftsfähigkeit und Flexibilität. Auch ist mit Standardsoftware oft die Erwartung vereinfachter Standardprozesse verbunden sowie der Anspruch, sie fortlaufend weiterentwickeln zu können – beispielsweise aufgrund gesetzlicher Änderungen.

IT-DIRECTOR: Was sind geeignete Einsatzbereiche für Standardsoftware im Bankenbereich?
A. Schultz:
Standardsoftware hat überall dort gute Chancen, wo viele Banken sich eine gleichartige Motivation und ähnliche Anforderungen teilen. Prominentes und wichtigstes Beispiel sind die Kernbankensysteme, wobei der Trend hier klar in Richtung Servicebaukästen geht, die dann von weiteren Systemen, insbesondere Front-Ends, verwendet werden können. Auch für regulatorische Themen, zu denen vornehmlich das Meldewesen und Risiko-Controlling gehören, eignet sich Standardsoftware. Zudem kann sie als Rechenkern sinnvoll sein. Beispielsweise dann, wenn diese von gesetzlichen Auf­lagen beeinflusst sind. Ich denke hier an die Rechenkerne für die Berechnung von Effektivzinsen oder ­Vorfälligkeitsentschädigungen.

IT-DIRECTOR: Mit welchen Herausforderungen ist der Einsatz von Standardsoftware im Bankenbereich verbunden?
A. Schultz:
Mit Sicherheit ist eine der größten Herausforderungen, die Erwartungen der Banken an die Standardsoftware realistisch zu halten. Es muss klar sein, dass die Einführung von Standardsoftware nicht zwangsläufig dazu führt, dass die Ausgaben für die Erstellung und Pflege von Eigenentwicklungen deutlich zurückgehen. Darüber hinaus gelingt es selten, den vollen Funktionsumfang der teilweise über mehrere Jahrzehnte gewachsenen „Alt“-Systeme in einem Schritt zu übernehmen. Summa summarum – Standardsoftware allein ist kein Allheilmittel. Der erfolgreiche Einsatz hängt stark von der Berücksichtigung einiger grundlegender Rahmenbedingungen ab, die über den reinen Abgleich des benötigten Funktionsumfangs hinausgehen. So muss beispielsweise der Einsatz gezielt erfolgen. Denn Standardprodukte haben ihren höchsten Nutzen in für Banken differenzierungsunkritischen Bereichen, die im Normalfall institutsübergreifend ähnlich abgebildet werden können. Und die Grenzen müssen akzeptiert werden, da jedes Institut über Prozesse und Berechnungsvorschriften verfügt, bei denen auch ausgefeilte Konfigurationsmöglichkeiten von Standardprodukten nicht weiterhelfen.

IT-DIRECTOR: In welchen Fällen ist eine Individualentwicklung empfehlenswert?
A. Schultz:
Individualentwicklungen sind vor allem in jenen Bereichen empfehlenswert, die für die Differenzierung gegenüber dem Wettbewerb kritisch sind. Dies könnten je nach Ausrichtung der Bank etwa spezialisierte Vertriebs-Front-Ends sein, aber auch hoc­hautomatisierte Backend-Prozesse in der Straßenbearbeitung im Massengeschäft. Für die erfolgreiche ­Integration von Individualsoftware in die bestehenden Standardsysteme lassen sich dann einige Best-Practice-Ansätze ausmachen. Die Basis für die Eigenentwicklungen sollte eine möglichst offene und technologisch reife Standardplattform bilden, die sich im Hinblick auf In-frastruktur, Vorgehensmodelle und technologische Ansätze möglichst nicht von der der wichtigsten Standardanbieter unterscheidet. Zudem sollten Eigenentwicklungen „nach dem Modell des Herstellers“ geschehen – d.h., Aspekte wie Mandantenfähigkeit, Releasefestigkeit und die Nutzung von Infrastrukturwerkzeugen wie Logging sollten auch bei Individualsoftware möglichst nach den Standards des Herstellers erfolgen.

IT-DIRECTOR: Was sind häufige Stolpersteine für die Anwender beim Einsatz von Standardsoftware?
A. Schultz:
In einigen Fällen ist es sehr schwer, die verschiedenen Anwender innerhalb einer Standardanwendung unter einen Hut zu bekommen. Das Generalisieren von Problemfeldern ist dort derart komplex, dass prinzipiell funktionierende Lösungsansätze von anwendenden Unternehmen nicht mehr zielführend einsetzbar sind. Hierzu zählen aus meiner Sicht u.a. nischenspezifische Fachfunktionen mit einer zu kleinen gemeinsamen Anforderungsbasis, Workflow-Management-Systeme, bei denen die Komplexität der Problemstellung zu hoch ist, sowie Out-of-the-box-Lösungen für regulatorische Themen. Hier erwarten die Banken von Tag eins an eine reife Lösung und benötigen fachlichen Input vom Hersteller.

IT-DIRECTOR: Wie lässt sich ein erfolgreiches „Nebeneinander“ von Standardsoftware und Individualsoftware-Entwicklung bewerkstelligen?
A. Schultz:
Die eigentliche Herausforderung besteht ja darin, die beiden Teile zu einem Ganzen mit Mehrwert und nicht zu zwei isolierten Welten werden zu lassen. Dies gelingt am besten, indem die Vorgehensweise und Methodik bei Individualentwicklungen an der des Herstellers der eingesetzten Standardsoftware ausgerichtet wird und indem so weit wie möglich Plattformen einheitlich genutzt werden. Zudem sollte die enge Kopplung von Individual- an Standardsoftware dort erlaubt sein, wo diese nicht allein lebensfähig wären. Damit entgehen die Banken teuren Overhead-Kosten beispielsweise durch SOA-Ansätze ohne erkennbaren Mehrwert. Auch das Einhalten des Single-Point-of-Truth-Prinzips über die gesamte Applikationslandschaft hinweg unterstützt ein erfolgreiches Nebeneinander. Dieses Prinzip gilt für Daten ebenso wie für zentrale bankfachliche Berechnungen wie die Ermittlung von Partnerverbünden oder Obligoberechnungen. Wenn dazu noch einheitliche Zielbilder im Sinne einer Standardarchitektur als Grundlage von Designprozessen genutzt werden, dann sind im Zeitablauf auch Kostenvorteile gegenüber getrennten Ansätzen realisierbar.

©2018Alle Rechte bei MEDIENHAUS Verlag GmbH

Unsere Website verwendet Cookies, um Ihnen den bestmöglichen Service zu bieten. Durch die weitere Nutzung der Seite stimmen Sie der Verwendung zu. Weitere Infos finden Sie in unserer Datenschutzerklärung.

ok