ó BANKING 1
ó BANKING 1 Lösungsdimensionen in einem hierarchischen Architekturmodell Data Governance benötigt IT-Architektur und Laborumgebung Erweiterung und Optimierung Release und Anforderungsmanagement Vorgaben Hier werden beispielhaft die Lösungsdimensionen Geschäftstrategie und IT-Alignment, Projektmethodik und Data Governance umrissen. Quelle: Fit for Basel IV: Anforderungen und Lösungsdimensionen. Compliance Funktion benötigt bildet Rahmen für Geschäftsstrategie und IT-Alignment benötigt Neue Technologien sich durch eine genauere Analyse und einen Abgleich mit dem Change- und Runthe-Bank-Framework einer typischen Bank ein Satz von Lösungsdimensionen erstellen ” 1. Dieses Framework wurde auf ein geschlossenes, hierarchisches Architekturmodell abgebildet, dessen oberste Ebene aus der fachlichen Geschäftsarchitektur, dem Risiko- und Kontrollframework und der Governance bzw. der Aufbauorganisation besteht. Die Vollständigkeit der Lösungsdimensionen wurde damit gewährleistet. Der Satz der Lösungsdimensionen besteht aus der Geschäftsstrategie und einem starken IT-Alignment, Verbesserung der Compliance-Funktion, Projektmethodik, Projekt- und Programm-Management, Release- und Anforderungs-Management, IT-Architektur, Data Governance und neuen Technologien. Geschäftsstrategie und IT-Alignment sind ein Teil von BCBS 239, denn im Prinzip kann die Anforderung als externe Vorgabe für ein IT-Alignment im Bereich Risikoreporting verstanden werden. Das Papier geht dabei sogar so weit, die Verankerung in der Geschäftsstrategie explizit zu fordern. In dieser Lösungsdimension gemachte Missstände lassen sich durch eine der anderen Dimensionen kaum mehr aufholen. Dies gilt für alle wichtigen Geschäftsanforderungen, weshalb das IT- Alignment in Verbindung mit einer klaren Geschäftsstrategie auch für ein Regulatory Transformation Program zentral sind. Eine Anpassung in der Lösungsdimension Projektmethodik erscheint notwendig, da die Zeit von der Anforderung bis zur Umsetzung immer knapper wird – und dies bei oft unklaren Anforderungen. Das führt beim klassischen Projektvorgehensmodell wie dem Wasserfall zu nur schwer lösbaren Herausforderungen. Gleichzeitig besteht in vielen Banken ein Umfeld, das sich sehr stark an sequenziellen Vorgehensmodellen wie dem Wasserfall orientiert. Reine agile Vorgehensmodelle lassen sich nur schwer umsetzen. In vielen Unternehmen wird mehr und mehr eine hybride Form wie z. B. Water- Scrum-Fall 1 eingesetzt, um die Vorteile beider Ansätze zu nutzen – verstärkt im regulatorischen Umfeld, bei dem Scope und Umsetzungszeitpunkt von außen vorgegeben sind. In der Lösungsdimension Projektvorgehen ist es wichtig, mehrere Projektvorgehensmodelle zu beherrschen und diese je nach Art des Projekts anwenden zu können. Innerhalb der Lösungsdimension Data Governance wird ein komplettes Framework für das Datenmanagement beschrieben. Beispielsweise ist festzulegen, wo und in welchen Systemen die Daten zu speichern sind, in denen sich die Lead-Daten befinden und wer für die jeweiligen Daten verantwortlich ist. Auch erfolgt die Definition einer eindeutigen Taxonomie und Semantik der Daten. Jede dieser Dimensionen kann nicht unabhängig voneinander betrachtet werden, sie stehen vielmehr in einem Zusammenhang miteinander und beeinflussen sich gegenseitig, was als kybernetischer Ansatz bezeichnet wird. Status quo Um den Status quo bei Banken zu messen, wurden Fragestellungen für jede Lösungsdimension erarbeitetet, welche diese charakteristisch beschreiben und ihre wesentlichen Ausprägungen darstellen. Die Ergebnisse einer Online-Umfrage 2 unter 100 Teilnehmern aus Deutschland und der Schweiz zeigen, dass die Befragten in vielen Bereichen den Erreichungsgrad als passabel einschätzten. In der Praxis klagen jedoch viele Mitarbeiter von Banken über den aktuellen Zustand. Damit weichen die Ergebnisse des Fragebogens von dem in der Praxis wahrgenommenen Zustand ab. Analysiert man aber die einzelnen Ergebnisse genauer, erkennt man große Abweichungen in der Bewertung der Fragen. So wurde die Lösungsdimension Ge- 32 diebank 12.2016
BANKING ó schäftsstrategie und IT-Alignment mit einem Reifegrad von 72 Prozent bewertet, wobei 100 Prozent eine volle Zustimmung bedeuten. Die darunter liegende Frage, ob die IT-Strategie der Geschäftsstrategie folgt, erhielt mit 64 Prozent eine deutlich niedrigere Zustimmung. Auch lässt sich erkennen, dass teilweise das Ergebnis aufgeschlüsselt nach IT und Fachbereich stark divergiert. So gaben IT-Projektmitarbeiter einen Reifegrad von 63 Prozent an, die Gruppe Leitung im Fachbereich jedoch 73 Prozent. Es stellt sich also die Frage, ob der Wirkungszusammenhang noch zu wenig transparent ist oder ob die Institute an Kompaktheit verlieren. Kompaktheit meint hier insbesondere eine Organisation, in der alle Beteiligten Klarheit über die Geschäftsziele haben und an einem Strang ziehen, ohne dass es einer besonderen Governance bedarf. Der Bereich Data Governance hingegen erhielt mit 66 Prozent einen sehr schlechten Reifegrad, und die Studie zeigt hier Handlungsbedarf auf. Das lässt darauf schließen, dass in einigen Bereichen der „gefühlte“ Reifegrad zu hoch ausgefallen ist. In einem kybernetischen Ansatz ist die Data Governance notwendige Voraussetzung für eine gute Datenqualität. Allerdings fällt die Datenqualität im Vergleich zur Data Governance relativ gut aus. Offenbar spielten inhaltliche Abhängigkeiten der Lösungsdimensionen für die Beantwortung des Fragebogens eine untergeordnete Rolle. Dies lässt den Schluss zu, dass bei den Teilnehmern der Umfrage kein ganzheitliches Bild auf die Problemstellung vorliegt. Umsetzung des Regulatory Transformation Program (RTB) Ein Regulatory Transformation Program zielt auf die Verbesserung in einem breiten Strauß von Lösungsdimensionen ab, woraus sich für das Programm eine hohe Komplexität ableitet, die bewältigt werden muss. Zum einen stellt sich die Frage, wie man das Programm in sinnvolle kleinere Einheiten (Projekte) zerlegen kann, zum anderen, wie der zeitliche Verlauf aussehen sollte. Benötigt wird ein klares Vorgehensmodell, das geeignet ist, diese Fragestellung zu beantworten. Im Idealfall orientiert sich das Vorgehensmodell an einer festgelegten, logischen Hierarchie. Die Betrachtung aller Hierarchieebenen vor dem Hintergrund des RTP bildet die Grundlage zur Festlegung eines klaren Zielbilds für jede Hierarchieebene. Zunächst ist zu definieren, welche Verantwortung und Rollen vom Bereich Regulatory übernommen werden sollen. Dies lässt sich in Form eines RACI 3 -Charts darstellen. Dabei spielt es eine Rolle, ob der Bereich Regulatory vor allem als Ersteller von Berichten gesehen wird oder ob er eine navigierende Funktion übernimmt und die Bank auch in strategischen Fragestellungen unterstützt. Zudem muss geklärt werden, welche Aufgaben intern erbracht werden und welche als Dienstleistung eingekauft werden müssen. Darauf aufbauend ergeben sich die Fähigkeiten und Methoden, die die Mitarbeiter des Bereichs Regulatory besitzen bzw. beherrschen müssen. Wird zukünftig z. B. ein Data Scientist benötigt, der bei Ad-hoc-Anfragen des Vorstands sehr schnell aus großen Datenbeständen die notwendigen Daten schürft? Ebenso kann man sich die Frage stellen, wie wichtig zukünftig die juristische Interpretation von Normen wird. Auf dieser Basis ergibt sich ein Organisations- und Prozessmodell. Dies umfasst sowohl den Regelbetrieb als auch den Bereich der Projekte. Abschließend ergibt sich ein unterstützendes Architekturbild inklusive einer Fach-, Prozess- und IT-Architektur. Zum Erreichen dieses Zielbilds bildet die Definition geeigneter Key Performance Indikatoren (KPI) den wesentlichen ersten Schritt. Die KPI sollten nach ihrer Definition regelmäßig gemessen und überwacht werden. Passende Indikatoren im Kontext eines RTP könnten z. B. sein: ó duchschnittliche Zeit zur Bearbeitung von Linienaufträgen im Bereich Aufsichtsrecht, ó Gesamtdauer und Aufwand zu Erstellung einer konkreten Meldung, ó Anzahl der Defekte nach GoLive, ó Skill-Bilanz der Mitarbeiter. Im nächsten Schritt sollte eine initiale Analyse inklusive einer ersten Messung der KPI erfolgen. Daraus ergibt sich ein Reifegradprofil in den einzelnen Komponenten des Zielbilds. Das Reifegradprofil dient dann als Grundlage zur Entwicklung eines Umsetzungsprogramms, welches im Zeitverlauf alle wesentlichen Lücken schließt. Der Fortschritt wird über die dauerhafte Messung von KPI überwacht. Fazit Eine dauerhafte und sichere Einhaltung regulatorischer Vorgaben ist für jede Bank überlebensnotwenig. Während hierzu bei der Aufsicht und den Banken bereits ein Konsens besteht, spiegeln dies die Bankorganisationen noch nicht wider. Insbesondere wird eine pure Reaktion auf aufsichtsrechtliche Anforderungen nicht ausreichend sein. Vielmehr ist es notwendig, neue Themen proaktiv anzugehen und geschlossen im hier dargestellten hierarchischen Lösungsmodell umzusetzen. Gelingt das, kann es zu einem Wettbewerbsvorteil werden. ó Autoren: Björn Fehrenbach ist Fachprojektleiter bei der Zürcher Kantonalbank. Dr. Kai Oliver- Klauck ist Partner bei der ifb AG, Köln. 1 Schlauderer, S.; Overhage, S.; Fehrenbach, B.: Widely Used but also Highly Valued? Acceptance Factors and Their Perceptions in Water-Scrum-Fall Projects. In: Proceedings of the 36th International Conference on Information Systems (ICIS). Fort Worth, TX, USA 2015, S. 1-19. Rubrik: Completed Research Paper. 2 Die Umfrage wurde mit wissenschaftlicher Unterstützung erarbeitet und adressierte Mitarbeiter und Berater aus dem Bankensektor. Durchführungszeitraum: Ende 2014 bis Anfang 2015. Die Herleitung der Studie und deren Ergebnisse wurden als Monografie unter dem Titel „Fit for Basel IV“, Neopubli,veröffentlicht. 3 RACI steht für (R)esponsible, (A)ccountable, (C)onsulted und (I)nformed. 12.2016 diebank 33
