Mit Strategie zu einer integrierten Finanz- und Risikoarchitektur (IFRA)

Spätestens mit Basel II begann für viele Banken im Risikobereich der Aufbau von Warehouse-Lösungen, die Daten über die gesamte Gruppe sammeln und für die regulatorische Meldung aufbereiten. Im Rechnungswesen existierten bereits Mechanismen zur Erstellung der Bilanz. Daneben entstanden oft ähnliche parallele Datensammel- und Aufbereitungslösungen für das Controlling oder das interne Marktpreisrisiko und für das Liquiditätsrisiko.

Problem der Daten-Silos

Die Folge der verschiedenen Verarbeitungsstränge waren Silo-Architekturen, die ab den Kernbanksystemen getrennt Daten sammelten, aufbereiteten und den jeweiligen Fachbereichen zur Steuerung zur Verfügung stellten. Bereits damals waren die Daten der Silos untereinander sehr ähnlich, aber aufgrund von unterschiedlichen Verarbeitungen, Filterungen oder Definitionen der Dimensionen auf Reportebene nur schwer vergleich- bzw. überleitbar. Hohe Aufwände in den Fachbereichen zur Validierung der Daten sowie hohe IT Kosten sind die Folge, von einer integrierten Steuerungsarchitektur kann keine Rede sein.

Regulatorik als Treiber der Konsolidierung von Daten-Silos

Die neueren regulatorische Anforderungen zeigen eine zunehmende Konvergenz zwischen den Steuerungsbereichen im Rechnungswesen, Meldewesen, Controlling, Risiko und Treasury. Anforderungen wie FINREP, COREP, CRD IV, IFRS 9, IAS 39, Ad-Hoc Anfragen der Aufsicht oder BCBS 239 (Risk Data Aggregation) etc. sind schwer mit den bestehenden Siloarchitekturen umzusetzen. Neben regulatorischen Anforderungen wird auch bei der internen Steuerung immer mehr eine bereichsübergreifende Konsistenz in Berichten auf Gruppenebene gefordert. Viele Banken stehen daher vor einem umfassenden Umbau ihrer dispositiven Architekturen bzw. haben diesen bereits begonnen.

Zentrale und integrierte Datenhaltung als Zielbild

Das architektonische Ziel ist auf einer abstrakten Ebene einigermaßen klar umrissen: Ein Großteil der Informationen für Banksteuerungszwecke soll integriert vorliegen, um so gleichzeitig mehrere Steuerungsbereiche bedienen zu können, also eine integrierte Finanz- und Risikoarchitektur (IFRA). Der Weg von der aktuellen Ausgangssituation zu diesem Ziel ist allerdings nicht auf den ersten Blick klar definiert. Oft wird dieser Weg auch als IFRA-Strategie bezeichnet. Im Folgenden werden die möglichen prinzipiellen Ansätze, Handlungsalternativen und die wesentlichen Hauptherausforderungen diskutiert.

Big-Bang Ansatz ist häufig problematisch

Die bestehenden Siloarchitekturen erfüllen innerhalb des Silos ihren Zweck. Oft sind die Verarbeitungen sehr ausgefeilt, wurden über Jahre immer weiter verfeinert und auf die Bedürfnisse angepasst. Allein um diesen Status Quo aus Sicht der Anwender über eine neue integrierte Plattform zu etablieren, sind viele Herausforderungen zu meistern. Ein Implementierungszeitraum von 5 Jahren und mehr ist realistisch. Zudem werden während der Implementierung weitere neue Anforderungen auftauchen, die auch berücksichtigt werden müssen. Ein Big-Bang-Ansatz würde der Zeit immer hinterherlaufen. Lange Parallelphasen müssten eingeplant und Anforderungen doppelt implementiert werden. Bereits eine qualitative Beurteilung führt zu dem Schluss, dass ein Big-Bang-Szenario eher unwirtschaftlich ist.

Stufenweiser Umbau als Alternative

Dies führt zu dem Szenario, das aktuell die meisten Banken wählen: ein stufenweiser Ausbau. Die grundsätzliche Idee ist recht einfach. Die Vorhaben, die ohnehin anstehen, bilden das Gerüst für die einzelnen Ausbaustufen. So entsteht sukzessive die IFRA. Bei genauerer Betrachtung ist aber auch der stufenweise oder auch opportunistisch genannte Ansatz nicht zu unterschätzen. Im Folgenden werden einige Fallstricke diskutiert.

Transparente Priorisierung und erste Ausbaustufe.

Die anstehenden Vorhaben müssen priorisiert werden. Sinnvoll ist die Wahl mindestens eines Vorhabens, das für die Bank ein Muss ist. Tendenziell sind dies regulatorische Anforderungen. Damit werden automatisch zwei fast zwingende Nebenbedingungen erfüllt. Die Erfolgswahrscheinlichkeit ist mit einem Muss-Vorhaben deutlich höher; nicht zuletzt aufgrund der nötigen Unterstützung im oberen Management. Zudem ist damit auch stets eine fachliche Notwendigkeit gegeben und das Ergebnis stiftet einen sichtbaren Nutzen für die Bank. Grundsatzfragen, die das Vorhaben in Frage stellen wird so entgegnet. Ein Aufhänger wäre z.B. BCBS 239.
Kann-Themen – also Vorhaben, die nicht unbedingt jetzt in Angriff genommen werden müssen – sind nicht kategorisch auszuschließen. Eine Möglichkeit ist die Bündelung von z.B. kleineren Kann-Themen mit mindestens einem Muss-Thema sofern diese auch gegenseitig Synergien aufweisen.
In der ersten Ausbaustufe wird der Grundstein gelegt. Faktoren wie Akzeptanz, Time-to-Market, Kosten für Change und Run, die den gesamten Lebenszyklus entscheidend beeinflussen, müssen bereits zu Beginn beachtet werden. In der ersten Ausbaustufe muss daher mit Weitblick in ein Fundament in Form von architektonischen und ablauforganisatorischen Rahmenkonzeptionen investiert werden, das das angestrebte Ziel auch wirklich tragen kann.

Sinnvoller Scope und Komplexität

Die erste, wie auch alle weiteren Ausbaustufen sollen eine sinnvolle Größe bzw. Komplexität aufweisen, die von der Bank einerseits beherrschbar ist, andererseits für einen Grundstock für weitere Ausbaustufen sorgt. Die erste Ausbaustufe muss ein Erfolg sein. Durch den Quick Win wird so auch Widerständen potentieller Nutzergruppen entgegnet. Ein wichtiger Faktor ist in diesem Zusammenhang der Reifegrad der Bank im Bezug auf ähnliche Projekte. Eine realistische Einschätzung der Faktoren vorhandene Erfahrung, vorhandene Ressourcen, Umsetzungswille in Fach- und IT-Bereichen und Reife vorhandener Methoden vom Anforderungsmanagement bis zur Abnahme sind dabei ein erster Schritt.
Die erste Ausbaustufe darf aber auch nicht zu klein sein. Für eine nachhaltige Lösung sind zu Beginn vergleichsweise hohe Aufwände nötig, die eigentlich nicht erforderlich wären. Um diese Aufwände erstens rechtfertigen und zweitens die IFRA tatsächlich im Sinne eines Proof of Concepts validieren zu können, ist eine zu kleine Variante ebenfalls nicht ratsam.
Daher ist eine sinnvolle Balance zwischen einem zu großen Scope, der durch die Bank nicht mehr beherrschbar wäre und einem zu kleinen Scope, der die initialen Aufwände nicht rechtfertigt zu wählen.

Erweiterbarkeit

Die Erweiterbarkeit umschreibt die Fähigkeit, neue Anforderungen schnell (Time-to-Market) und kosteneffizient einzuarbeiten. Diese Fähigkeit muss von Beginn an geplant werden. Sie ist ein hohes Gut, da sie direkten Einfluss auf den Lebenszyklus der IFRA nimmt. Faktoren, die einen hohen Einfluss auf die Erweiterbarkeit haben sind v.a. die Datenmodelle und Ausgestaltung der Architektur.
Für Details hierzu sei auf weitere Artikel verwiesen. Hier nur so viel: Bei der Ausgestaltung ist meist ein Trade-off einzugehen. Siloarchitekturen sind dezentral organisiert, schwer zu integrieren, dafür aber flexibel und relativ leicht erweiterbar. Eine zentral organisierte Architektur ist eher einfach zu integrieren, büßt aber Flexibilität ein. Wird die Architektur also nicht sorgfältig von Beginn an auch für die Zukunft konzipiert, werden spätere Erweiterungen unnötig aufwendig. Ab einem bestimmten Punkt werden wieder schnelle und kostengünstige Insellösungen entstehen, die der Anfang von einer Rückkehr in die alten Siloarchitekturen sein werden.

Ausgestaltung weiterer Ausbaustufen oder Roadmap

Wie oben bereits erwähnt, wird das Gesamtvorhaben einer IFRA nicht nach der ersten Ausbaustufe abgeschlossen sein. Zunächst ist ein grobes architektonisches Ziel zu entwickeln. Ausgangspunkt sind einerseits harmonisierte Methoden bzw. Funktionen zwischen den einzelnen Steuerungsbereichen sowie andererseits strategische, nicht funktionale Ziele hinsichtlich angestrebter Time-to-Market, Qualität, Aktualität, Frequenz und weiterer Faktoren. Aktualität meint die Zeit, die zwischen einem Stichtag und der tatsächlichen Verfügbarkeit in einem Report verstreicht. Mit der Frequenz ist die Häufigkeit der Aktualisierung gemeint. BCBS 239 geht beispielsweise von einer Aktualität von 10 Tagen nach dem Monatsultimo mit einer monatlichen Frequenz aus, in Krisenzeiten ggf. noch kürzer.
Die Roadmap beschreibt dann den strategischen Weg von der aktuellen Situation zu diesem Ziel. Ein optimaler Weg kann daher nie entwickelt werden, wenn die Ausgangssituation und die Zielarchitektur nicht klar abgestimmt und beschlossen sind. Der Startpunkt ist also immer eine silo-übergreifende Darstellung der Ist-Architektur.
Daraus können dann die Haupthandlungsfelder und die weitere Priorisierung transparent abgeleitet werden.
Anforderung an die einzelnen Ausbaustufen ist eine Balance zwischen fachlichem Nutzen und Umbau der Architektur, d.h. Alt-Systeme werden tatsächlich abgeschaltet oder zurück gebaut unter Wahrung der Erweiterbarkeit. Integration heißt auch Standardisierung, Vereinfachung und Rückbau.

Organisatorischer Rahmen oder Governance

Die Governance definiert die nötigen Rollen und Prozesse für bereichsübergreifende und nachhaltige Entscheidungen über strategische Ziele aber auch konkrete Ausbaustufen im Change entlang der Roadmap. Sie durchdringt die Organisation aber auch in der täglichen konzernweiten Aufbereitung und zeitgerechten Lieferung von qualitativ hochwertigen Informationen im Run. Die Governance definiert damit den ablauf- und aufbauorganisatorischen Rahmen, um den Wert von Information stetig zu erhöhen.
Voraussetzung für bereichsübergreifende Entscheidungen ist die Beachtung der tatsächlichen Machtverhältnisse, oft abhängig von der Kultur und der Weisungsbefugnisse in der Linie. Eine Verantwortung auf dem Papier, ohne die Möglichkeit sie tatsächlich ausfüllen zu können, ist nicht sinnvoll. Eine Verankerung auf Vorstandsebene ist daher immer mehr üblich, durch BCBS 239 sogar nötig.
Je nach Institut, kann die Governance unterschiedlich ausgestaltet sein. Daher ist es nötig, die Ausgestaltung zwar zu konzipieren, aber recht bald umzusetzen und ggf. anzupassen.
Die Governance soll den Wert von Information stetig steigern und nicht selbst zum Hindernis werden. Daher wächst sie typtischerweise mit den Ausbaustufen der IFRA mit und hinterfragt sich selbst. Eine gesunde Balance zwischen Formalismus und Zentralität sowie Pragmatismus und dezentralem Gestaltungsspielraum ist daher wie in jeder anderen Aufbaustruktur nötig.

Da in diesem Artikel die genannten Herausforderungen nur kurz andiskutiert wurden, werden in folgenden Artikeln auf BankingHub einzelne Themen weiter verfeinert.

Sprechen Sie uns gerne an!

Artikel teilen

Kommentare

Eine Antwort auf “Mit Strategie zu einer integrierten Finanz- und Risikoarchitektur (IFRA)

  • BankingHub

    Ein sehr guter Artikel. Für mich schlüssig ist es, priorisierte (Kann-, Muß-) Vorhaben iterative zu realisieren. Hierbei ist dem Datenmodell ein großes Gewicht beizumessen. Moderne Methoden wie Data Vault Modellierung tragen dem Umstand Rechnung.

    Antworten

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

BankingHub-Newsletter

Analysen, Artikel sowie Interviews rund um Trends und Innovationen
im Banking alle 2 Wochen direkt in Ihr Postfach