Steigende regulatorische Anforderungen, Herausforderungen und das Projektvorgehen

Die Flut von neuen regulatorischen Anforderungen an die Banken scheint weiterhin ungebrochen, wie es die Vielzahl der Reformwerke wie Basel III, CRR/CRD IV, die BRRD und ganz aktuell Basel IV zeigen. Die Banken schaffen es kaum noch, bei der Umsetzung der Vorgaben Luft zu holen.


Effizientes Arbeiten in einem Umfeld der Niedrigzinsen und einer immer stärkeren Regulierung gleicht einem Drahtseilakt. Bildnachweis: iStock.com/alphaspirit

BCBS239, Fundamental Review of the Trading Book, die Überarbeitung der Vorschriften zur Nutzung interner Modelle sowie der neue SREP, um nur einige zu nennen, halten die Banken bereits in Atem. Die anhaltende Niedrigzinsphase lässt jedoch kaum mehr Erträge im klassischen Bankgeschäft zu. Hohe Anforderungen, die ebenso hohe Investitionen erfordern, sind daher nur schwer zu realisieren. Gleichzeitig müssen die Anforderungen in immer kürzerer Zeit umgesetzt werden, und oftmals sind die Ressourcen gerade im Fachbereich begrenzt.

Zentrale Anforderungen und Lösungsdimensionen

Es muss sich die Frage gestellt werden, wie die kommenden regulatorischen Anforderungen möglichst effizient umgesetzt werden können. Zur Beantwortung dieser Frage habe ich aus den bestehenden und kommenden regulatorischen Papieren zentrale Anforderungen, wie beispielsweise die differenzierte Messung aller Risikotreiber oder die stark vereinfachte Datengranularität im Meldewesen, herausgearbeitet. Den zentralen Anforderungen wurden Lösungsdimensionen wie beispielsweise Programm- und Projektmanagement oder Data Governance zugeordnet. Die aktuelle Anwendung der Lösungsdimensionen wurde anhand einer Onlineumfrage mit 100 Teilnehmern (in 2015; www.fitforbasel.de) abgefragt. Dabei hat die Lösungsdimension Data Governance eine sehr schlechte Einschätzung erhalten (vgl. Björn Fehrenbach, Fit for Basel IV: Anforderungen + Lösungsdimensionen, Neopubli, ISBN 978-3-7418-1571-3).

Das ist sicherlich nicht weiter überraschend. Doch wirken neben den regulatorischen Anforderungen auch weitere Entwicklungen, wie die Digitalisierung, und auch neue technische Möglichkeiten im Bereich der BI-Systeme, wie beispielsweise In-Memory oder Predicitve Analytics, auf diese Lösungsdimension. Diese Tatsache erhöht den Handlungsdruck, sich mit der Architektur und dem Datenhaushalt zu beschäftigen. Zudem scheinen die wesentlichen Anforderungen direkt aus den regulatorischen Papieren ablesbar zu sein. Damit kann die Frage gestellt werden, in welchem Umfang es eine Definitionsphase in der Projektumsetzung braucht. Daran schließt sich die Überlegung an, zu welchem Zeitpunkt der Fachbereich direkt ins Projekt einbezogen werden soll und ab wann Tests durchgeführt werden sollen.

Projektvorgehen

Doch selbst wenn die Handlungsfelder bekannt sind und man sogar eine Aufteilung in verschiedene Projekte vornehmen kann, stellt sich die Frage, wie man in der konkreten Projektumsetzung (im Change) vorgehen soll. Verschiedene Studien zeigen auf, dass sich immer mehr Unternehmen in Richtung von agilen Vorgehensmodellen bewegen. Hiermit soll mehr Transparenz geschaffen werden, um auch eine höhere Qualität des Projektergebnisses zu erhalten. Die genaue Definition der agilen Vorgehensweise und deren Inhalt wird von Unternehmen zu Unternehmen anders verwendet und ist damit nicht vergleichbar. So gibt es einen großen Spielraum zwischen traditionellen Wasserfallprojekten und rein agilen Scrum-Projekten. Jegliche Mischform zwischen traditioneller und agiler Vorgehensweise wird als hybrides Vorgehen bezeichnet. Generell besteht die Gefahr, ein rein agiles Vorgehen immer dann zu wählen, wenn man zu wenig Zeit für eine ausreichende Definitionsphase hat oder viele Dinge unklar sind.

Neben den gefühlten Vorzügen von agilen und hybriden Methoden lassen sich bis heute noch keine fundierten Aussagen finden, ob die im Projekt eingesetzten agilen Techniken wirklich zu einem Mehrwert führen. Auch ist nicht bekannt, auf welche Business Values (beispielsweise Qualität, Time-to-Market, Kosten) die eingesetzten agilen Techniken wirken. Eine Antwort auf diese Frage soll eine weltweit laufende Studie zum Thema „business value of current software development methodologies“ geben. Die Studie ist an Entwickler und alle Beteiligten (inkl. Auftraggeber und Fachbereich) eines Softwareprojekts ausgelegt. Eine Teilnahme ist noch möglich.

Vorläufige Ergebnisse der Studie

Von den bis jetzt 210 Teilnehmern gaben 32% an, traditionelle, 34% hybride und 31% agile Vorgehensweisen zu verwenden. Bezogen auf die 39 Teilnehmer aus Banken sieht die Verteilung wie folgt aus: 38% traditionelle, 46% hybride und 15% agile Vorgehensweisen. Damit werden nach Einschätzung der Teilnehmer aus der Bankbranche in Banken mehr hybride und weniger agile Vorgehensweisen als im Durchschnitt eingesetzt. Spannend wird es, nach Abschluss der Studie zu analysieren, welche agilen Prinzipien sich auf welche Business Values auswirken, und ob sich dies nach Branchen unterscheiden lässt. Ein Bezug der exklusiven Ergebnisse ist durch die Teilnahme an der Studie möglich.