Integrierte Finanzarchitektur in Banken

Ausgangssituation

Seit mehr als fünf Jahren ist das Thema integrierte Finanz- und Risikoarchitektur in der Diskussion und Umsetzung. Viele Kreditinstitute haben mit Projekten begonnen, die eine Integration zum Thema haben. Überwiegend wurde das Thema aus Sicht des Bereichs Finanzen (internes und externes Rechnungswesen und Meldewesen) getrieben. Denn an diesen Bereich bestehen derzeit die größten Anforderungen. Sei es aufgrund neuer HGB und IFRS Anforderungen oder die Anforderungen der Aufsicht. Um diese Anforderungen erfüllen zu können, wurden und werden Daten, Informationen und Ergebnisse anderer Bereiche, zum Beispiel des Risiko Managements, benötigt. Darüber hinaus musste die IT Überlegungen anstellen und Lösungen liefern, wie der Informationsdurst der Bereiche gestillt werden kann. In anderen Fällen wurden strategische Initiativen ins Leben gerufen. Ziel der strategischen Ausrichtung war und ist es, die Kosten der Informationsgewinnung und –verarbeitung (TCI = Total Costof Information^[1] ) zu reduzieren. Aus dieser Gesamtsituation heraus wurden die Projekte, gar Programme gestartet. In seltenen Fällen wurde ein gesamtheitlicher Ansatz verfolgt. Es gab und gibt einen Bereich, der ein Interesse an zusätzlichen und abstimmbaren Informationen hat.

Heutiges Vorgehen

Das heutige Vorgehen bei der Entwicklung und dem Aufbau einer integrierten Finanz- und Risikoarchitektur ist sehr stark durch einen fachlichen Bereich^[2] und der IT als Interessenten getrieben. Daraus resultiert, dass Lösungen immer mit dem Fokus auf den Anforderer bereitgestellt werden. Schließlich hat ein Bereich eine konkrete Anforderung. Die IT treibt oder unterstützt zumindest diesen Prozess, weil sich durch eine bessere Integration Einsparungen im eigenen Bereich ergeben sollten.

Das heutige Vorgehen soll kurz an dem nachfolgenden Schaubild verdeutlicht werden.

Abbildung in dieser Leseprobe nicht enthalten

Bei diesem Vorgehen werden die Aspekte des aktuellen Anforderungsbedarfs und ggf. die strategische Ausrichtung der IT betrachtet. Aufgrund der Anforderungen, dass Daten, Informationen, Ergebnisse anderer Bereiche benötigt werden, wird von einem integrativen Ansatz gesprochen.

Entscheidung für einen integrierten Ansatz

Unter einem integrativen Ansatz werden in der Regel die folgenden Punkte und Ziele verstanden:

- Reduzierung oder möglichst minimaler Abstimmungsaufwand zwischen den Bereichen.
- Nutzung von Ergebnissen und Berechnungen, wenn diese bereits irgendwo vorhanden sind und den eigenen fachlichen Anforderungen entsprechen.
- Möglichst große Datenkonsistenz, wenn die fachlichen Prozessen das erlauben.
- Reduzierung der Schnittstellen zwischen dem Nutzer der Daten und dem Lieferanten der Daten. Resultiert in einer großen Daten-Box, Data Warehouse System, Datenpool, Datensenke (oder auch Data Lake genannt).
- Harmonisierung und Reduzierung der Datenpools, Data Warehouse Systeme, …
- Mögliche Harmonisierung der Datenmodelle.
- Neue Verortung von Funktionen entsprechend der Funktionen neuer Software- und Hardwarekomponenten.
- Reduzierung der Durchlauf- und Bearbeitungszeiten aufgrund des integrativen Ansatzes.
- Soweit ein System, ein Data Warehouse, ein Datenpool existiert, wird dieser analysiert und in der Regel um die Anforderungen erweitert.

Was das heißt, soll an dem nachfolgenden Beispiel kurz verdeutlicht werden.

Ausgangssituation:

- Für IFRS 9, Impairment, werden zusätzlich Risikodaten benötigt. Die Hoheit über die Berechnung des Bonitätsrisikos und weiterer Marktpreisrisiken liegt beim Risiko Management.
- Das Rechnungswesen benötigt jedoch die Informationen, um Impairment kalkulieren zu können.
- Bisher gibt es einen Datenpool für das Risiko Management und einen Datenpool für das Rechnungswesen.
- Im Berichtswesen werden die Ergebnisse abgestimmt und Ergebnisse des einen Bereichs auf aggregierter Ebene mit den Ergebnissen des anderen Bereichs kombiniert.

Lösungsansatz:

- Das Risiko Management ist weiterhin für die Lieferung der Ergebnisse verantwortlich.
- Die Lieferung soll auf granularer Ebene, das heißt soweit möglich auf Ebene der einzelnen Verträge (z.B. Darlehen) erfolgen.
- Um die Konsistenz bei der Berechnung sicherzustellen (sowohl im Rechnungswesen als auch im Risiko Management) werden die Buchwerte und Salden des Rechnungswesens mit den Eingangsdaten des Risiko Managements abgestimmt. Hierfür werden die beiden Datenpools in einem Punkt vereinheitlicht.
- Die Versorgung mit Stammdaten und zusätzlichen Daten erfolgt jedoch immer noch separat, da das Rechnungswesen andere Informationen benötigt, als das Risiko Management.
- Um Impairment abbilden zu können, stellt das Risiko Management auf Einzelvertrags- und Geschäftspartner-Ebene Risikoinformationen zur Verfügung. Diese werden im Datenpool des Rechnungswesens aufgenommen. Die Verantwortung für diese zusätzliche Information liegt jedoch weiterhin beim Risiko Management.
- Die Ergebnisse des Risiko Managements werden ebenfalls dem Rechnungswesen zur Verfügung gestellt. Auf Einzelvertragsebene. Die entsprechenden Risikoparameter, stehen für Plausibilisierungszwecke zur Verfügung und können durch das Rechnungswesen ausgewertet werden. Die Ergebnisse werden in den Datenpool des Rechnungswesens geschrieben. Es wird vereinbart, dass die Daten am 3. Arbeitstag nach Monatsultimo durch das Risiko Management zur Verfügung gestellt werden müssen.
- Jeder Bereich ist für seine eigenen Daten verantwortlich, auch wenn diese aus einer Quelle bezogen werden. Soweit Daten angepasst werden müssen, passt jeder Bereich seine Daten individuell an.
- Am Ende der Abschlussarbeiten wird eine Plausibilisierung der Ergebnisse durchgeführt.

Soweit zum integrativen Ansatz. Es wird versucht, die gemeinsame Basis zu vereinheitlichen. Das heißt, soweit die gleichen Quellen verwendet werden, diese nur einmal „anzuzapfen“. Ist die Granularität eine andere, so wird versucht, diese ebenfalls anzupassen. Hat ein Bereich bereits ein Ergebnis, dann wird es wieder verwendet. Das gilt aber nur, wenn der andere Bereich, das Ergebnis so gar nicht kennt. Eine häufige Diskussion in diesem Zusammenhang sind Cashflows. Viele Systeme und Prozesse kennen einen Cashflow oder zumindest den Begriff. Aber jeder Fachbereich hat eine andere Sicht auf den Cashflow. Daher lässt sich die Verwendung von Cashflows nicht vereinheitlichen. Die Abstimmung wird an der einen oder anderen Stelle vereinfacht, da die Basis die gleiche ist.

Bei diesem integrativen Ansatz handelt es sich jedoch eine Vereinfachung in Bezug auf die Abstimmbarkeit. Als positiver Nebeneffekt oder auch Ziel ist die Reduzierung von Punkt-zu-Punkt-Schnittstellen. Das wird in der Regel über einen gemeinschaftlichen Datenpool oder ein gemeinschaftliches Data Warehouse erreicht.

IT-Systeme und IT-Architektur

Aus Sicht der IT wird die Vereinheitlichung und Integration der Finanz- und Risikodaten meistens als „Datenversorgen“ und „Datensammeln“ verstanden. Dabei stellen sich jedoch wesentliche fachliche Fragestellungen, die von der IT nicht beantwortet werden können. Das sind, bspw.:

- Gibt es ein einheitliches Datenmodell? Wie sieht das Datenmodell aus?
- Welche Semantik soll im Datenmodell verwendet werden?
- Wann benötigt wer, welche Daten?
- Wann ist eine fachliche Konsistenz erfüllt?

Da diese Fragestellungen nicht beantwortet werden können, beantwortet die IT in der Regel IT-seitige Fragen. Zum Beispiel die Frage, wie sieht eine technische Integrationsarchitektur aus und welche Schnittstellen können reduziert werden. Diese Fragestellung soll an den nachfolgenden zwei Schaubildern verdeutlicht werden.

Abbildung in dieser Leseprobe nicht enthalten

Ohne eine Integrationsarchitektur bestehen viele Punkt-zu-Punkt-Schnittstellen, die alle separat gewartet werden müssen. Der Vorteil an dieser Architektur ist, dass jeder Empfänger für sich die notwendigen Daten definieren und auch die Verantwortung für die Schnittstelle übernehmen kann. Unter IT-Gesichtspunkten ist es aber eine sehr teure und pflegeintensive Lösungsalternative. Aus diesem Grund strebt die IT einen zentralen Lösungsansatz an.

Abbildung in dieser Leseprobe nicht enthalten

Mit dem Fokus auf den zentralistischen Lösungsansatz beschäftigt und beschäftigte sich die IT mit Systemauswahl und Systemaufbau. Es wurden und werden IT-Lösungen gesucht, die es ermöglichen ein möglichst flexibles, performantes und skalierbares Data Warehouse aufzubauen. Soweit ein Data Warehouse bereits im Einsatz war, was die Regel ist, wird eines „ausgedeutet“, das geeignet erscheint, die Anforderungen abzudecken. Das Problem an diesem Lösungsansatz ist, dass die Anforderungen zum Zeitpunkt der Auswahl nicht bekannt sind. Man spekuliert, was passen könnte. Ob die Spekulationen und Annahmen zutreffend sind, stellt sich in der Regel erst Jahre später heraus.

Wie bereits gesagt, sind die wichtigsten Aspekte bei der Auswahl aus Sicht der IT:

- Flexibilität: Können neue Systeme einfach angebunden werden. Ist das Datenmodell erweiterbar. Sind die Informationen auswertbar. Können Daten angepasst werden.
- Skalierbarkeit: Kann die Menge und Komplexität der Daten erweitert werden. Wie verhält sich die Erweiterung (linear).
- Sicherheit: Sind die Daten wiederherstellbar. Können die Daten geschützt werden. Kann eine Stabilität in der Laufzeit hergestellt werden.

Darüber hinaus werden noch weitere Aspekte betrachtet. Hierunter zählen zum Beispiel:

- Gibt es bereits ein Datenmodell
- Wie breit ist das KnowHow im Markt
- Standardsoftware versus Eigenentwicklung
- Abdeckung moderner Integrationstechniken (bspw. Nutzung von Services)
- Zukunftssicherheit der Lösung

Doch regelmäßig werden die Entscheidungen so getroffen, dass die eigene Organisation in der Lage ist, die Lösung zu beherrschen. Die Punkt-zu-Punkt-Schnittstellen werden sukzessive auf den Datenpool / das Data Warehouse migriert. In der Regel können nicht alle Punkt-zu-Punkt-Schnittstellen „umgehängt“ werden, da manche der Informationen so abnehmerspezifisch sind, dass eine Vereinheitlichung keinen Sinn macht.

Welche Funktionen, Prozesse, Anbindungen an einen Datenpool / Data Warehouse Sinn machen oder nicht, wird in der Regel in Rahmenrichtlinien festgehalten. Diese Richtlinien gelten grundsätzlich für die Integrationsarchitektur. Je nach Entwicklungsstand, Entwicklung und KnowHow in der IT werden auch fachliche Funktionen im Datenpool / Data Warehouse abgedeckt. Die fachliche Verantwortung für diese Funktion liegt bei jedem Bereich.

Fachprozesse und Facharchitektur

So wie die IT sich in Bezug auf die Anforderungen neu aufstellt, stellen sich auch die Fachbereiche neu auf. Die Integrationsarchitektur erfordert, dass Fachprozesse und die Facharchitektur neu definiert werden. Facharchitektur heißt in diesem Kontext: Welche Funktionen werden benötigt und wo werden diese ausgeführt.

Die wesentlichen Anpassungen an den Fachprozessen entstehen immer dann, wenn

- Funktionen automatisiert werden. Das heißt, bisher manuell durchgeführte Prozesse werden durch ein IT-System übernommen.
- Funktionen verlagert werden.
- Abstimmungen wegfallen oder neu dazu kommen.
- Berichte sich inhaltlich verändern und neu bearbeitet werden müssen.
- Verantwortungsbereiche sich verschieben.

Die Themen Fachprozesse und Facharchitektur sind sehr eng verwoben. Erfahrungsgemäß denken viele fachliche Mitarbeiter auch in Systemen und dv-technischen Funktionen. Der Grad dieses Denkens ist abhängig von den historischen Gegebenheiten. So wie viele andere Dinge im Rahmen einer integrierten Finanz- und Risikoarchitektur. Hatten die Fachbereiche in der Vergangenheit einen maßgeblichen Einfluss auf die Systeme und die dort umgesetzten Funktionen, so denken diese Mitarbeiter in der Regel auch in Systemen. Beispielsweise war die Bewertungsfunktion (Ermittlung des Fair Values) in den bestandsführenden Systemen. So werden Mitarbeiter wie bisher immer in erster Linie an das System und erst dann an die Funktion denken. Der entsprechende Prozess wird in der Regel entlang der Systeme und dort verankerten Funktionen definiert. Auch dieses Vorgehen ist historisch gewachsen, da in der Regel die Prozesse erst im Nachgang nach der Implementierung dokumentiert wurden. Selten wurden zuerst die Prozesse und dann die Funktionen definiert.

Dieses Verhalten ändert sich in der Regel erst langsam mit dem Aufbau einer integrierten Finanz- und Risikoarchitektur. Werden Funktionen neu umgesetzt, ist mittlerweile der Ansatz, dass nach der fachlichen Funktion gefragt wird. Die Verortung, also in welchem System soll die Funktion abgebildet werden, erfolgt in Zusammenarbeit mit der IT.

In Bezug auf die oben beschriebene Ausgangssituation ist es aber so, dass sich zunächst jeder Bereich um seine eigenen Funktionen und Prozesse kümmert. Ergo der Bereich Finanzen definiert für ihn notwendige Funktionen und Prozesse. Soweit es übergreifende Prozesse gibt, so werden diese regelmäßig nicht beachtet. Es entstehen „schwarze Löcher“, um die sich keiner so richtig kümmern möchte. Eines dieser „schwarzen Löcher“ ist die Verantwortung für die zentral bereitgestellten Daten. Welcher Bereich sagt, dass die Daten richtig sind.

Diese Problemstellung wurde mittlerweile erkannt, aber nur in wenigen Fällen wurden Maßnahmen ergriffen, Abhilfe zu schaffen. Denn solche übergreifenden Maßnahmen bedürfen auch einer organisatorischen Änderung.

Veränderungen in der Organisation (Change Management)

Organisatorische Veränderungen, die die Gesamtorganisation „Bank“ betreffen, werden und wurden bei Projekten und Programmen „Integrierte Finanz- und Risikoarchitektur“ spät oder gar nicht ergriffen. Zum besseren Verständnis. Als Change Management werden die folgenden Sachverhalte verstanden:

Abbildung in dieser Leseprobe nicht enthalten

Organisatorische Veränderungen. Hier wird die Frage beantwortet, wie sieht die zukünftige Organisation aus. Aus pragmatischen Gründen geht man immer davon aus, dass sich die Organisation, wie sie vor der Integration aussah, nicht wesentlich verändert. Auch wenn systemseitig Funktionen zentralisiert oder verlagert werden, reflektiert sich das nicht in der Organisation. Jede organisatorische Veränderung hat nach Art und Größe des Unternehmens auch unterschiedliche Durchlaufzeiten. Denn manche organisatorische Veränderungen bedürfen auch der arbeitsrechtlichen Anpassung. Diese versuchen die Unternehmen in der Regel soweit wie möglich nach hinten zu verschieben. Je nach Fortschritt, Umsetzungsdauer und Flexibilität der Organisation wurden jedoch bereits erste Schritte unternommen, die Organisationsänderungen aufzunehmen. So zum Beispiel, dass zentrale Stellen bzgl. Data Management und Data Governance geschaffen wurden. Die Verankerung dieser Stellen innerhalb der Organisation ist zum Großteil noch nicht abgeschlossen, da die Aufgabenteilung nicht immer klar ist. Somit ist die Akzeptanz dieser Stellen in den Unternehmen eher gering.

Prozessuale Veränderungen: Hier wird die Frage beantwortet, wie sehen die neuen Prozesse aus. Auch das ist eine mittelgroße Herausforderung. Denn das bedeutet, dass die aktuellen Prozesse vollständig bekannt und idealerweise dokumentiert sind. Das ist leider nicht immer der Fall. Demzufolge erfolgt in der Regel erst die Analyse der aktuellen Prozesse bis überhaupt die zukünftigen Prozesse definiert werden. Im Grunde müssten zuerst die Prozesse definiert werden und dann die Organisation festgelegt werden. Denn über die Definition der Prozesse kann auch der Prozessverantwortliche benannt werden.

Um zum Ausgangspunkt zurück zu kommen, werden die Change Management Themen in der Regel nach hinten verschoben. Das hat die folgenden Ursachen:

- Aufgrund der Komplexität des eigentlichen Vorhabens „Integrierte Finanz- und Risikoarchitektur“ werden scheinbar zeitlich nicht kritische Sachverhalte nach hinten verschoben.
- Die Basis insbesondere bzgl. der Prozesse ist in der Regel nicht bekannt oder stabil genug, um Veränderungen ableiten zu können. Denn hierfür müssten die zukünftigen Prozesse bekannt sein.
- Soweit eine integrierte Architektur noch in der Entwicklung ist, werden keine organisatorischen Veränderungen in Angriff genommen. Man möchte erst einmal sehen, wie das Zusammenspiel im „tatsächlichen“ Leben ist. Schließlich kann es sein, dass sich die neuen Prozesse in der alten Struktur wiederspiegeln.
- Verantwortungsbereiche werden im Laufe des Projektes nicht neu geschnitten. Es wird damit argumentiert, dass es im Projekt Aufgabe des Projektes ist, Entscheidungen zu treffen. Sind von den Entscheidungen Linienaufgaben betroffen, so wird die Linie einbezogen. Die Linienmitarbeiter achten jedoch in der Regel nur darauf, ob die aktuellen Prozesse betroffen sind oder nicht.
- Während des Projektes entstehen Gremien, die Entscheidungen treffen. Man verlässt sich darauf oder hofft, dass diese Gremien auch nach dem Projekt bestand haben werden. Hier vergisst man jedoch, dass in diesen Fällen, solche Gremien in der Linienorganisation verankert werden müssten.

Somit bleibt festzuhalten, dass das Thema „Change Management“ in der Regel vernachlässigt wird. Die Hauptursache liegt darin, dass keiner die Notwendigkeit sieht, bereits in einem frühen Stadium, die organisatorischen und prozessualen Voraussetzungen zu schaffen.

Wo stehen die Unternehmen heute

Betrachtet man eine integrierte Finanz- und Risikoarchitektur gesamtheitlich, so drängt sich einem die Schlussfolgerung auf, dass viele Unternehmen maximal die Hälfte des Weges zurückgelegt haben. Zur Verdeutlichung. Gesamtheitliche Betrachtung beinhaltet:

- Fachprozesse und Funktionen
- IT-Systeme und IT-Architektur
- Organisation

Unternehmen die sich mit dem Thema auseinandersetzen, hatten konkrete und spezifische Anforderungen. Diese Anforderungen galt es umzusetzen. Zwar wurden übergreifende Aspekte berücksichtigt, aber immer nur soweit, wie sie für die konkrete Anforderung relevant waren. Themen, die außerhalb des eigentlichen Zeithorizonts lagen, wurden und werden auch nach hinten verschoben. In der Regel gibt es eine Vision, wo das Unternehmen nach x Jahren stehen möchte. Doch diese Visionen beziehen sich in der Regel auf IT-Systeme und die Vereinheitlichung oder Abschaffung von Systemen. Das Thema Organisation und Prozesse werden dabei oft vernachlässigt. Somit entsteht eine Situation, die die Organisation später nicht verkraften kann.

Dieser Zustand hat auch maßgeblichen Einfluss auf den Fortschritt und den Erfolg des konkreten Vorhabens. Denn, wenn die Menschen nicht wissen, wofür sie etwas tun und wo sie am Ende der Tage stehen werden, ist die Motivation aktiv und zielgerichtet mitzuarbeiten eher gering. Denn es besteht immer die Angst, dass die aktive Mitarbeit dazu führt, später nicht mehr gebraucht zu werden.

Welches Vorgehen ist notwendig

Aus meiner Sicht müsste das Vorgehensmodell idealtypisch gedreht werden. Das Vorgehen soll an dem nachfolgenden Schaubild verdeutlicht werden.

Abbildung in dieser Leseprobe nicht enthalten

Im Kontext einer integrierten Finanz- und Risikoarchitektur muss man sich Gedanken machen, welche Funktionen und Prozesse in der Zukunft benötigt werden. Diese Überlegungen münden in einer entsprechenden Zielarchitektur.

Ausgehend von diesen Überlegungen muss die Zielorganisation abgeleitet werden. Das bedeutet nicht, dass die Zielorganisation sofort umgesetzt werden muss. Das lässt sich in der Regel nicht durchführen. Aber die Organisation kann auf die bevorstehenden Veränderungen ausgerichtet werden.

Eine wesentliche Veränderung besteht darin, dass sich die Organisation und die Prozesse in einer integrierten Finanz- und Risikoarchitektur Front-to-End ausrichten muss. Denn mit einer Integration sollen bestehende Silos aufgebrochen werden, demzufolge muss auch die Verantwortung verlagert werden.

Daneben müssen zentrale Stellen geschaffen werden, die zentrale Aufgaben übernehmen. Eine essenzielle Stelle in dem Zusammenhang integrierte Finanz- und Risikoarchitektur ist die Data Governance und das Data Management. Teilweise wurden solche Stellen bereits geschaffen. Ihr Aufgabengebiet muss jedoch ausgeweitet werden.

Schließlich erfolgt die Auswahl an IT-Systemen und somit die Festlegung der IT-Architektur. Die Auswahl der „richtigen“ Systeme ist vergleichbar mit einem Autokauf. In der Regel macht man sich Gedanken, wofür man ein Auto benötigt, welche Funktionen das Auto haben muss und kauft danach ein Auto. So sollte man es mit den IT-Systemen auch machen. Bei den IT-Systemen ist es teilweise aber so, dass man zuerst das System hat und überlegt sich danach, wie man es in die Architektur integrieren kann.

Die oben angesprochenen Punkte werden in den nachfolgenden Abschnitten vertieft.

Funktionale und prozessuale Zielarchitektur

Bei der Entwicklung einer integrierten Finanz- und Risikoarchitektur sollte man immer von den benötigten Funktionen und Prozessen ausgehen. Das heißt nicht, dass alles neu erfunden werden muss. Die fachlichen Funktionen und Prozesse sollten in einem Unternehmen bekannt sein. Ich meine wirklich bekannt und nicht unbedingt dokumentiert.

Wenn man von einer integrierten Architektur spricht, bedeutet das natürlich auch, dass zu einem Zeitpunkt irgendwann in der Zukunft alle Bereiche, die Finanzen und Risiko abdecken, auch die gleiche Architektur nutzen. Somit ist auch der Schluss zulässig, dass man mit allen Bereichen die funktionale und prozessuale Zielarchitektur diskutieren müsste. Das kann in Abhängigkeit von der Größe des Hauses eine unendliche Aufgabe sein.Aus diesem Grund empfiehlt es sich, mit einem Bereich zu beginnen. Jedoch sollte diesen Prozess jemand begleiten oder mit durchführen, der einen übergreifenden Blick auf die Dinge hat.

Die Dokumentation der Zielfunktionen und Zielprozesse erfolgt unter den folgenden Aspekten:

- Funktionen:
- Sind ohne Systembezug definiert. Beispielsweise: Fair Value Ermittlung durchführen.
- Nutzen bekannte und im Unternehmen allgemeingültige Begriffe. Das erfordert, dass Begriffe im Vorfeld allgemeingültig definiert sind.
- Werden gruppiert, so dass sie einem fachlichen Owner zugeordnet werden können.
- Werden mit den folgenden Informationen versehen:
- Wann wird die Funktion benötigt (am Tagesende, durch Aufruf, …)
- Wie häufig wird die Funktion benötigt (einmal am Tag, einmal im Monat, immer bei bestimmter Konstellation, …)
- Wer benötigt die Funktion
- Zuordnung der Funktion zu einer Domäne
- Welche Informationen werden benötigt, um die Funktion auszuführen. Bspw. Marktdaten und Stammdaten für die Berechnung des Fair Values
- Prozesse:
- Ausgangsbasis sind die aktuellen Prozesse
- Sind zunächst ohne konkrete Zuordnung der Funktionen und der Verantwortlichen Stelle zu definieren
- Sind nach Prozessgruppen zu unterteilen. Hierbei wird unterschieden zwischen übergreifenden und spezifischen Prozessen
- Benötigen einen Vorgänger- und Nachfolgeprozess
- Zuordnung der folgenden Informationen
- Wann wird der Prozess ausgeführt
- Häufigkeit des Prozesses
- Eingangsinformationen für den Prozess
- Ergebnis des Prozesses

Dieses Vorgehen stellt für so manche Unternehmen eine Neuerung vor. Denn in der Vergangenheit wurden Funktionen und Prozesse immer mit einem Systembezug definiert. Denn man wusste, wo die Funktion zu finden ist. Um eine idealtypische Zielarchitektur zu definieren, ist es aber notwendig, diesen Systembezug aufzugeben. Daher ist es auch notwendig, dass dieser Prozess übergreifend begleitet wird. Die Begleitung sollte darauf ausgerichtet sein, ein fachliches Verständnis für die Funktionen und Prozesse zu schaffen sowie Abhängigkeiten zu erkennen.

Der Fortschritt der Arbeit wird regelmäßig in einem übergreifenden Gremium FunctionalandProcessArchitecture Board besprochen und analysiert. Dieses Gremium sollte mit den fachlich verantwortlichen Abteilungsleitern besetzt sein. Gemeinschaftlich erfolgt die Zuordnung der Funktionen und Prozesse an die fachlich Verantwortlichen.

Damit wird in einem frühen Stadium die Gesamtorganisation mit dem Vorgehensmodell vertraut gemacht und Diskussionspunkte können schnell geklärt werden. Da bei diesem Vorgehen mit regelmäßigen Diskussionen zu rechnen ist, ist auf oberster Management Ebene eine Instanz einzurichten, die eine Entscheidung trifft. Die Ergebnisse sind die Basis für die Festlegung der Zielorganisation.

Umstrukturierung der Organisation

Auf Basis der definierten Funktionen und Prozesse ist die Zielorganisation abzuleiten. Bei der Festlegung der Zielorganisation ist wie folgt vorzugehen:

- Welche Skills werden benötigt
- Wer trägt die Verantwortung für das Ergebnis
- An welcher Stelle sind organisatorische Schnitte sinnvoll
- Umsetzung in einer Matrix-Organisation
- Welche Funktionen und Prozesse sind übergreifend

Idealtypisch wird die Organisation nicht danach aufgebaut, wer die meisten Mitarbeiter hat, hat auch die größte Bedeutung. Wenn man von einer integrierten Finanz- und Risikoarchitektur spricht und die Umsetzung vorantreibt, muss man davon ausgehen, dass die organisatorischen Einschnitte recht groß werden. Denn bei einer integrierten Finanz- und Risikoarchitektur werden:

- Bisher dezentrale Funktionen und Prozesse zentralisiert
- Die Hoheit über Prozesse und Funktionen wird ggf. auf andere Einheiten verlagert
- Neue und übergreifende Stellen geschaffen, die keinem Bereich direkt zugeordnet werden, da diese bereichsübergreifend agieren müssen
- Verantwortungsbereiche zusammengefasst oder getrennt werden
- Unterschieden wird zwischen disziplinarischer und fachlicher Verantwortung

Das soll an dem folgenden Beispiel verdeutlicht werden.

Im Rahmen der funktionalen Analyse wurde identifiziert, dass alle Bereiche einen Cashflow benötigen. Jeder Bereich definiert den Cashflow aber auf eine andere Art und Weise.

- Risiko: Betrachtung nur bis zum Zinsänderungszeitpunkt
- Rechnungswesen: Gesamten vertraglichen Cashflow
- Liquiditätssteuerung: Cashflow bis zum wahrscheinlichen Rückzahlungszeitpunkt

In der Vergangenheit hat sich jeder Bereich um SEINEN Cashflow gekümmert. In der Zielarchitektur wurde festgelegt, dass es eine zentrale Stelle gibt, die Cashflow(s) berechnet und den Abnehmern zur Verfügung stellt. Somit entfallen in drei Bereichen die fachlich Verantwortlichen für die Ermittlung des Cashflows. Diese müssen zukünftig ihre Anforderungen an den zentralen Cashflow-Versorger stellen. Der zentrale Cashflow-Versorger wird ggf. in der Organisation in einer neuen übergreifenden Position verankert. Somit muss entschieden werden, wo diese Position verankert wird und durch wen die Position besetzt wird. Der Zuschnitt der Aufgaben der anderen Bereiche muss angepasst werden.

Daraus folgt, dass der Aufbau einer neuen Organisation mit wesentlichen Inhalten verbunden ist und je nach Organisation unterschiedliche Vorlaufzeiten benötigt. Denn die folgenden Dinge sind im Rahmen der Organisationsänderung zu beachten:

- Skills
- Sind die benötigten Skills vorhanden. Ist ggf. ein Up-Skilling notwendig. Das fängt alleine bei der sprachlichen Eignung an, wenn bspw. Aufgaben, Funktionen und Prozesse zentralisiert werden sollen und davon ggf. Tochtergesellschaften betroffen sind.
- Müssen Skills und KnowHow angeheuert werden.
- Wie lange sind Skills noch im Unternehmen verfügbar? Herrscht ggf. eine Überalterung vor.
- Welcher Entwicklungspfad kann ggf. eingeführt werden, damit Skills zum richtigen Zeitpunkt verfügbar sind.
- Stellen
- Müssen neue Planstellen geschaffen werden oder kann es innerhalb der bestehenden Stellenstruktur abgedeckt werden.
- Ist die Anpassung von Stellenbeschreibungen notwendig.
- Falls neue Stellen geschaffen werden müssen, wie sollen diese besetzt werden.
- Ist eine Anpassung der Arbeitsverträge notwendig.
- Welche Gefahren gehen davon aus, wenn die Arbeitsverträge angepasst werden müssen.
- Wo werden die Stellen organisatorisch verankert.
- Aufbauorganisation
- Welche Organisationsstruktur ist zu wählen.
- Lässt sich eine Matrix-Organisation in der Gesamtorganisation durchsetzen.
- Sieht man grundsätzlich fachliche Karrierepfade vor oder sind diese hart an disziplinarische Karrierepfade gekoppelt.
- Welche Incetivierungsmaßnahmen können in der Aufbauorganisation eingebettet werden.

Darüber hinaus gibt es viele weitere Punkte, die rechtzeitig und ausführlich diskutiert werden müssen. Erst wenn die organisatorischen Rahmenbedingungen geklärt sind, kann eine offene und verständliche Kommunikation nach außen stattfinden. Außerdem muss den Mitarbeitern das Ziel bekannt und transparent sein, damit sie sich auch in der zukünftigen Organisation wiederfinden und gezielt mitarbeiten können.

Verantwortung für den Front-to-End Prozess

Eine wesentliche Änderung ist die Umsetzung einer Front-to-End Verantwortung im Gesamtprozess. Diese Verantwortung spiegelt sich in einer Matrix-Organisation, die in dem nachfolgenden Schaubild kurz dargestellt wird.

Abbildung in dieser Leseprobe nicht enthalten

Beispielsweise zeichnet der Bereich Finanzen verantwortlich für den Front-to-End Prozess aus Sicht Finanzen. Das bedeutet, bereits bei der Produkt- und Prozessdefinition wirkt er aktiv mit, indem die fachlichen und funktionalen Anforderungen definiert werden. Der Bereich Finanzen muss die Produkte und Prozesse bereits von „vorne“ verstehen. Nur so ist es möglich, die fachlich funktionalen Anforderungen angemessen zu formulieren.

Selbstverständlich muss sich jeder Bereich mit den Verantwortlichen innerhalb der Matrix abstimmen. Die Verantwortlichen für Produkte, Prozesse, Operative Abbildung, usw. haben den Gesamtblick auf die Anforderungen. Mit dem Gesamtblick haben sie auch die Hoheit über die dort eingesetzten Funktionen und Methoden. Die Zusammenarbeit soll an einem Beispiel verdeutlicht werden:

- Für ein bestehendes Produkt, bspw. Baudarlehen soll aus Sicht des Risiko Management die Bewertung geändert werden.
- Risiko Management: Stellt die fachliche Anforderung an den Methoden Verantwortlichen „Fair Value Bewertung“
- Der Methoden-Verantwortliche „Fair Value Bewertung“ prüft die Anforderung bzgl.
- Fachliche Beschreibung
- Funktionale Anforderung
- Notwendige Eingangsdaten
- Nutzer der Funktion
- Der Methoden-Verantwortliche stellt fest, dass die bisherige Methode „Fair Value Bewertung“ auch von Finanzen genutzt wurde. Er prüft mit dem Bereich Finanzen, ob die neue Methode ebenfalls für den Bereich Finanzen anwendbar ist oder nicht. Ist die Methode nicht im Bereich Finanzen anwendbar, so muss er entscheiden, ob eine neue Methode entwickelt wird.
- Nach der Entscheidung wird die neue Methode implementiert und die Funktionsweise der Methode mit dem Risiko Management abgestimmt.

Selbstverständlich ist somit der Entscheidungsweg für den einzelnen Betroffenen, in diesem Fall das Risiko Management, scheinbar komplexer und langwieriger. Denn in einer nicht integrierten Welt, hat das Risiko Management einfach eine neue Methode umgesetzt, ungeachtet dessen, wer die Ergebnisse verwendet hat.

Bei diesem Ansatz wird somit sichergestellt, dass sowohl die Vorgänger und Nachfolger von der Änderung erfahren und aktiv entscheiden können, ob sie die Änderung mitgehen oder nicht. Auf der anderen Seite ist das Risiko Management oder jeder andere Bereich des eigenen Front-to-End Prozesses bewusst und kann diesen aktiv gestalten. Denn die Verantwortung für die Front-to-End Betrachtung liegt bei dem Bereich.

Data Management und Data Governance

Eine zentrale Rolle in der integrierten Finanz- und Risikoarchitektur fällt dem Data Management und der Data Governance zu. Aufgrund des integrativen Ansatzes ist es zwingend notwendig, dass das Datenmodell und die Datenqualität außerhalb der „Beherrschungsbereiche“ einzelner Fachbereiche liegen. Denn in einem idealtypischen Zustand einer Finanz- und Risikoarchitektur gibt es ein allgemeingültiges Datenmodell, das in der Gesamtorganisation bekannt ist. Dieses Datenmodell ist durchgängig Front-to-End und allgemein verständlich. Alleine die Schaffung eines solchen Datenmodells ist eine „Herkules-Aufgabe“. Die Verwaltung, Betreuung und Weiterentwicklung dieses Datenmodells benötigt wahrscheinlich vier bis fünf Herkules. Aus diesem Grund muss die Verantwortung dafür auf der Top Management Ebene angesiedelt sein. Idealerweise im COO Bereich, wenn nicht sogar im CEO Bereich. Schließlich betrifft das Datenmodell die Gesamtorganisation.

Im Rahmen des Data Managements sind die folgenden Sachverhalte festzulegen:

- Definition der Schichten innerhalb der Datenbereitstellung und –verarbeitung
- Definition des Datenmodells
- Festlegung der allgemeinen Attribute und deren Ausprägung
- Festlegung abnehmerspezifischen Attribute und deren Ausprägungen
- Modellierung der Objekte und die Beziehungen der Attribute untereinander sowie zueinander
- Definition der einheitlichen Begriffe
- Definition und Überwachung des Anforderungs- sowie Anpassungsprozesses
- Nachhalten der Verarbeitungskette. Das heißt
- Mapping des Attributs auf die Quelle
- Zuordnung der Berechnungs- und Ableitungsfunktionen
- Mapping auf die Schichten innerhalb der Verarbeitung
- Mapping auf die Abnehmer der Information
- Nutzung der Information bei den Abnehmern
- Festlegung der Ausprägungen
- Festlegung von Validierungs-, Plausibilisierungs- und Qualitätssicherungsregeln
- Kontinuierliche Weiterentwicklung des Datenmodells

Somit liegt die Hoheit des Datenmodells bei einer Gruppe. Hier kann entschieden werden, ob sich die Gruppe sowohl um das fachliche und das technische Datenmodell kümmert oder ausschließlich um das fachliche. Idealerweise setzt sich das Data Management Team aus Fach- und IT-Mitarbeitern zusammen, da dies den Anpassungsprozess in der Regel beschleunigen wird.

Darüber hinaus wird im Data Management Team der fachliche Owner der Daten identifiziert und vorgehalten. Ein fachlicher Owner ist insofern wichtig, da das Team einen Ansprechpartner braucht, der bei der Qualitätssicherung der Daten mitwirken muss. Zum Teil, bzw. im Laufe der Zeit kann diese Aufgabe auch durch das Team übernommen werden. Jedoch ist das Team nicht verantwortlich für die richtige und vollständige Erfassung der Daten in den Systemen. Diese Aufgabe verbleibt in der Regel bei den Data Ownern.

Das Data Management Team wirkt sowohl in der Linie als auch in Projekten mit. Das Datenmodell wird regelmäßig auf seine Gültigkeit, Aktualität und Nutzbarkeit überprüft. Der Aufbau des Datenmodells ist wie folgt:

- Strukturierung nach
- Stammdaten
- Bewegungsdaten
- Referenzdaten
- Technische Attribute, die spezifisch von Systemen verwendet werden
- Allgemeine Attribute, die von allen verwendet werden.
- Bereichsspezifische Attribute, die ausschließlich von einem Bereich genutzt werden
- Rohdaten und Ergebnisse
- Zuordnung zu Verarbeitungsregeln und –prozesse

Darüber hinaus muss das Team darauf achten, dass die zeitlichen und periodischen Anforderungen der Abnehmer abgedeckt werden.

Somit sind der Definitions- und Pflegeaufwand und damit auch die Verantwortung beim Data Management Team. Ausgehend von den Anforderungen, der Prozesse, des Datenmodells können die Anforderungen an die entsprechenden IT-Systeme und Tools gestellt werden.

Ableitung der notwendigen IT-Systeme und IT-Tools

Ausgehend von den fachlich angeforderten Funktionen, den definierten Prozessen sowie des Datenmodells wird die Entscheidung bzgl. der notwendigen IT-Systeme und IT-Tools getroffen. Hierfür ist eine Bestandsaufnahme der Funktionen und Prozesse der bestehenden IT-Systeme notwendig.

Die identifizierten Funktionen werden auf die IT-Systeme und IT-Tools zugeordnet. Hier kann man von einer Konsolidierung der Funktionen sprechen. Die Konsolidierung hat zum Ziel:

- Funktionen soweit wie möglich, sinnvoll und angefordert zu zentralisieren
- Neue Funktionen zu allokieren
- Erweiterungs- und Rückbaubedarf identifizieren
- Anforderungen an
- Workflow Management
- Datenflüsse und technische Schnittstellen
- Historisierung und Archivierung
- Zugriffs- und Berechtigungsverwaltung
- Datensicherheit

müssen soweit abgedeckt werden.

Die getroffene Verortung der Funktionen und Prozesse sowie der Abdeckungsgrad der Systeme wird dokumentiert. Soweit funktionale Lücken in den bestehenden Systemen bestehen, werden Alternativen entwickelt, wie die Lücken geschlossen werden sollen. Sollen neue IT-Systeme und IT-Tools zum Einsatz kommen, so werden nicht nur die fehlenden Funktionen betrachtet. Hier ist eine vollständige Analyse des funktionalen Umfangs durchzuführen. Daraus kann sich ergeben, dass Funktionen vollständig auf neuen IT-Systemen und IT-Tools verortet werden.

Neben der funktionalen Analyse müssen auch die folgenden Sachverhalte berücksichtigt werden:

- KnowHow im Markt und im eigenen Haus
- Integrierbarkeit in die Gesamtarchitektur der Bank
- Zukunftssicherheit bzgl. der Erweiterbarkeit und Wartung von Funktionen
- Performance und Anforderungen an die Datenverarbeitung. Bspw. Near-Time
- Technologischer Fortschritt bzgl. der Schnittstellen (können Services konsumiert werden)
- Anforderungen an die Datenhaltung

Das Ergebnis der Identifizierung der IT-Systeme und IT-Tools ist eine IT-Architektur.

Conclusio und Zusammenfassung

Als Conclusio bleibt Folgendes festzuhalten:

- Die bisherigen Ansätze zu einer integrierten Finanz- und Risikoarchitektur sind zum Großteil durch einzelne Bereiche getrieben. Daher bleiben Aspekte des großen Bildes meistens außen vor.
- Die Banken, die auf dem Weg zu einer integrierten Finanz- und Risikoarchitektur sind oder den Weg bereits eingeschlagen haben, lassen in der Regel, Change Management Aspekte außer Acht oder behandeln diese zeitlich nachgelagert.
- Bei der Festlegung der Komponenten, die in der Architektur verortet sind, wird auf dem Status Quo aufgesetzt. Das heißt, man betrachtet das System, was es bereits heute kann. Ist im Status Quo wenig bis nichts vorhanden, so werden in der Regel politische Entscheidungen für oder gegen eine Lösung getroffen.
- Funktionale Anforderungen und Prozesse, als Kombination, werden in der Regel vernachlässigt. Wenn funktionale Anforderungen betrachtet werden, dann ohne die dazu gehörigen Prozesse.
- Die Organisation als Ganzes wird auf das Projekt, das Programm, den Change in Summe nicht ausreichend vorbereitet.

Aus meiner Sicht ergeben sich dadurch nachhaltige Nachteile bei der Festlegung der integrierten Finanz- und Risikoarchitektur. Denn die Organisation folgt den Systemen und nicht die Systeme der Organisation. Somit wird verhindert, dass neben einer systemseitigen Integration auch eine organisatorische und prozessuale Integration entstehen kann.

Das Bewusstsein, dass die bereits gewählten Vorgehensmodelle nicht schlagartig geändert werden können. Daher sind zwei Sachverhalte in der Zukunft zu berücksichtigen:

1. Das gewählte Vorgehensmodell ist darauf zu überprüfen, wie weit es angepasst und neu ausgerichtet werden kann. Teilweise können organisatorische und prozessuale Maßnahmen ergriffen werden, die in einer neuen Stufe des Gesamtprogramms zum Tragen kommen.
2. Werden Vorhaben, die zum Ziel eine integrierte Finanz- und Risikoarchitektur haben, neu aufgesetzt, so sollte die hier beschriebene Vorgehensweise gewählt mindestens jedoch kritisch geprüft werden.

Verfasser

Patrik Halada, HiPo Consulting GmbH

Seit mehr als fünf Jahren im Umfeld Gesamtbanksteuerung, integrierte Finanz- und Risikoarchitektur, Integration Kernbankensysteme und analytische Bankensysteme und fachlich funktionaler Architekt tätig.

[...]

---

^[1] TCI = Total Cost of Information. In diesem Zusammenhang werden darunter alle Kosten verstanden, die mit dem Prozess der Informationsgewinnung, der Informationsverarbeitung, der Speicherung der Daten zusammenhängen. Hierunter fallen alle Prozess-, Software- und Hardwarekosten.

^[2] Bereich: Organisatorisch die Ebene unter dem Vorstand oder der Geschäftsführung. Bspw. Bereich Finanzen (Rechnungswesen, Controlling und Meldewesen).