Für Banken und Finanzdienstleister ist das Thema Datenmanagement nicht ganz neu, weil schon lange die Notwendigkeit besteht, Kunden- und Vertragsdaten granular für Unternehmenssteuerung und Risikomanagement nutzen zu können. Neuerdings rückt mit regulatorischen Initiativen wie BCBS 239 (Risikodatenaggregation und -reporting) oder der MaRisk-Novelle jedoch das Datenmanagement selbst in den Fokus der Aufsicht, also die Infrastruktur und die Prozesse, mit denen risiko- und steuerungsrelevante Daten verwaltet und verarbeitet werden.
Hierbei sind vor allem ein hoher Automatisierungsgrad, eine flexible Datenarchitektur, einheitliche Datenliefer- und Verarbeitungsprozesse sowie eine dazugehörige transparente und vollständige Dokumentation besonders wichtig. Die Nachhaltigkeit der Infrastruktur wird hierbei insbesondere durch die Flexibilität und Adaptierbarkeit der Systeme inklusive der darauf implementierten Architektur bestimmt, um auch zukünftigen Änderungen im geschäftspolitischen und regulatorischen Umfeld möglichst zeitnah gerecht werden zu können.
Fehlende "Data Governance"
Zwischen den Zielvorstellungen und der Realität klaffen jedoch teilweise erhebliche Lücken, für deren Erklärung meist auf "historisch gewachsene Strukturen" verwiesen wird. Neben Fusionen und Übernahmen oder der Erschließung neuer Geschäftsfelder spielt hierbei auch die fortlaufende Änderung und Ausweitung regulatorischer Anforderungen an Banken eine wesentliche Rolle. Das Datenmanagement vieler Banken ist beispielsweise durch neue Anforderungen aus der CRR, IFRS9, MiFID II und Ana-Credit gleichzeitig betroffen. Die Anzahl der Change Requests und die damit verbundenen technischen und fachlichen Abhängigkeiten untereinander sind derart komplex, dass alleine die Planung und Organisation der einzelnen Themen zu einem Kraftakt geworden ist.
Verschärft wird diese Situation zusätzlich durch das Fehlen einer konsequent angewendeten "Data Governance" im Sinne eines Zielbildes über alle Bereiche der Bank hinweg, was in der Folge zu Inkonsistenzen im Datenhaushalt und zu inkompatiblen Systemen zwischen den einzelnen Anwendungsbereichen führen kann. Die Herausforderungen im Datenmanagement der Bankenwelt liegen folglich zu einem Großteil in der Beherrschung von Komplexität. Bei der Entstehung dieser Komplexität sind mehrere Einflussfaktoren zu unterscheiden, wie zum Beispiel Finanzprodukte, Systeme und bankfachliche Anforderungen.
- Finanzprodukte: Produktinnovationen und Vielfalt in Produktvarianten ergeben stetige Anpassungsbedarfe in der Datenverarbeitungskette; typischerweise laufen die internen Prozessanpassungen systematisch den Anforderungen des Marktes hinterher.
- Systeme: Der hohe Grad an Spezialisierung verschiedener Banksoftware von Handel über Vertragsverwaltung bis zum Risikosystem erschweren eine integrative Architektur; gerade in größeren Instituten laufen zu jedem Zeitpunkt Projekte zu Software-Updates oder Systemerneuerungen.
- Bankfachliche Anforderungen: Zum Beispiel führen neue Regularien, neue Berichte oder überarbeitete Methoden oft zu Fachprojekten, die typischerweise neue Daten anfordern oder unterschiedliche Daten auf neue Art zusammenführen.
Komplexe Aufgabe
Aus diesen Einflussfaktoren ergibt sich eine Vielzahl von Einzelthemen, welche für sich genommen zwar jeweils relativ einfach zu lösen sind, deren nachhaltige Lösung jedoch im Zusammenhang erforderlich ist, was die resultierende Komplexität der Aufgabe deutlich steigert. Durch Kopplung und Rückkopplung sowie die fachlichen und technischen Abhängigkeiten entstehen in der Praxis wesentliche Herausforderungen, deren Bewältigung nicht nur umfangreiche Analyse- und Konzeptionsleistungen, sondern auch das Zusammenbringen von technischem und fachlichem Know-how (oft fachbereichsübergreifend) erfordert. Aufgrund der fortlaufenden Änderungsbedarfe ist eine auf dem "Reißbrett" entworfene Implementierung schwer vorstellbar.
Genauso wenig garantieren verbesserte Datenbankstrukturen sowie Produkt- und Prozessmodelle für sich genommen einen Erfolg. Tragfähige Lösungen basieren vielmehr auf einem einheitlichen Framework und dessen konsequenter Implementierung sowohl in den IT-Systemen als auch in den relevanten Fachbereichsprozessen und insbesondere der Governance. Nur durch dieses Zusammenwirken kann ein fachliches Datenmanagement entstehen.
Was in der Theorie einfach klingt, ist in der Praxis oft mit zahlreichen Fallstricken verbunden. Mit dem vorliegenden Beitrag werden mögliche Fallstricke anhand konkreter Beispielfälle vorgestellt und Lösungsaspekte aufgezeigt. Im Zentrum der Darstellung steht hierbei der Leitgedanke des fachlichen Datenmanagements als wichtiges Konzept, welches sich erwartungsgemäß als notwendige Kompetenz entwickeln muss.
Fachliches Datenmanagement in der Praxis
Daten im Sinne von Informationen stellen sich als eine der wertvollsten Ressourcen einer Bank heraus. Aber was genau macht diesen Wert aus? Ein Hinweis ergibt sich, wenn der Begriff "Wert" interpretiert wird als "aus-wert-bar". Der Wert von Daten leitet sich alleine aus ihrer Verwendbarkeit ab, zum Beispiel um schnellere und bessere Entscheidungen zu treffen, um Kunden an das Unternehmen zu binden und ihre Bedürfnisse besser zu verstehen.
Noch vor wenigen Jahren wäre der klassische Ansatz gewesen, einen Anwendungsfall zu identifizieren, zum Beispiel einen bestimmten Bericht, und diesen dann anforderungsgerecht einmalig zu implementieren. Mittlerweile ist in vielen Instituten die Frequenz an neuen Erhebungen, Verarbeitungen und Bereitstellungen von Daten so hoch, dass sich Datenmanagement als eigenständige dauerhafte Kompetenz entwickeln muss, in der technische Expertise und das Verständnis der Datenstrukturen und -inhalte gebündelt werden.
Derzeit sind das inhaltliche Verständnis von Datenmanagement und den damit verbundenen Aufgaben und Kompetenzen in den einzelnen Instituten noch sehr unterschiedlich entwickelt. Unstrittig ist dabei die IT-technische Dimension des Datenmanagements. In vielen Instituten wird Datenmanagement daher als primäre Aufgabe der Bank-IT gesehen. Zum einen werden Daten direkt mit den Systemen assoziiert, die diese Information speichern und verwenden. Für diese Systeme wiederum steht die Bank-IT in der Verantwortung. Zum anderen nimmt die Bank-IT als Ansprechpartner für verschiedene Bereiche eine Querschnittsverantwortung wahr und ist deshalb der natürliche Anlaufpunkt für den Aufbau und Betrieb von Datenpools, die von mehreren Abnehmern verwendet werden.
Die Bedeutung des fachlichen Datenmanagements als Querschnittskompetenz etabliert sich jedoch immer stärker in den Banken. Ein vor allem IT-fokussierter Ansatz des Datenmanagements stößt im Kontext neuer, ineinandergreifender regulatorischer Anforderungen sowie der durch BCBS 239 geforderten übergreifenden Datenkonsistenz an Grenzen. Die Aufgabe, Datenmodelle und Prozesse aufzubauen und nachhaltig zu warten, die über verschiedene fachliche Disziplinen hinweg konsistent integriert sind und gleichzeitig die Flexibilität für künftige Änderungen bieten, kann ohne eine disziplinübergreifende fachliche Expertise nicht geleistet werden. Dadurch ist die Erweiterung des Begriffs Datenmanagement um die dauerhafte Kompetenz und Funktion des fachlichen Datenmanagements notwendig. "Dauerhaft" bedeutet hierbei auch, dass diese Kompetenz über unterschiedliche Projekte hinweg bestehen bleibt und fest in der Organisation verankert wird.
Fachliche Integrations- und Konzeptionsaufgaben fallen in Banken generell bei jeder Änderung an, unabhängig davon, ob diese in Projekten oder einer eigenen Organisationseinheit geleistet werden. Im Folgenden wird anhand von Fallbeispielen gezeigt, wie sich dies im Kontext zweier konträrer Architekturansätze und Organisationsmodelle darstellt. Das Ziel ist dabei, grundsätzliche Zusammenhänge von Architektur, Organisation und Datenmanagement zu illustrieren und universelle Aspekte des fachlichen Datenmanagements herauszuarbeiten.
Als erstes Fallbeispiel dient eine mittelgroße Bank, die über Jahre hinweg mit pragmatischen Lösungskonzepten erfolgreich war - im Folgenden Opportunity Bank genannt (Fallbeispiel A).
Unterproportionale Berücksichtigung übergeordneter Aspekte
An diesem Fallbeispiel zeigt sich deutlich, welche Lösungen sich im Datenmanagement durchsetzen können, wenn keine zentralen Vorgaben bestehen. Im konkreten Fall wird die Aufgabe der fachlichen Integration an die einzelnen Datenabnehmer delegiert, sei es Risikocontrolling, Meldewesen oder Accounting. Jeder Abnehmer hat dadurch die Möglichkeit, auf die für ihn relevanten Daten zuzugreifen, diese zu verarbeiten und in die von ihm benötigte oder bevorzugte Sicht zu transformieren. Übergeordnete Aspekte werden hierbei allerdings (deutlich) unterproportional berücksichtigt.
In dieser Konstellation ist es daher extrem schwierig (wenn auch nicht unmöglich), die Konsistenz von Daten und Ergebnissen über verschiedene Anwendungsbereiche hinweg dauerhaft zu gewährleisten (wofür in dem gegebenen Organisationsbeispiel auch insbesondere würde niemand die Verantwortung übernehmen wollen). Dies würde nämlich erfordern, dass die Ergebnisse der einzelnen Anwender in einem gemeinsamen fachlichen Rahmen interpretiert werden können, sodass Überleitungen möglich sind:
- Übergreifende Definition von Grundmengen, das heißt Selektionen, Filtern und Konsolidierung.
- Übergreifende Definition von (Kalkulations-)Funktionen, das heißt insbesondere auch der Definition von fachlichen Größen wie zum Beispiel Positionswert oder Ähnliches, aber auch der Segmentierung und Aggregationen.
- Übergreifende Definition von Kennzahlen und Taxonomien.
Die Schaffung dieses Rahmens ist eine der zentralen Aufgaben des fachlichen Datenmanagements. Die konsequente Umsetzung des Rahmens erfordert Eingriffe in die Methodenhoheit und Definitionen der Bereiche, auch wenn weiterhin auf eine IT-technische Integration verzichtet wird, welche an dieser Stelle keine zwingende Voraussetzung für die Arbeit des fachlichen Datenmanagements darstellt. Die Umsetzung für die Opportunity Bank wäre in der Praxis also sehr schwierig, da Funktionen und Datenstrukturen redundant implementiert sind und in unabhängigen Verantwortungsbereichen (Silos) liegen. Dass dieser Architekturzugang daher dennoch gewisse Vorteile bieten kann, wird in der Abbildung dargestellt.
Prinzip "Golden Source"
Ein bekannter Ansatz, mit dem Thema Datenintegration strukturell umzugehen, ist der Aufbau einer zentralen Datenquelle (Prinzip Golden Source oder Single Point of Truth), zum Beispiel in Form eines Data Warehouses (DWH). Die grundsätzliche Idee ist, dass die Datenintegration mit ausreichender Breite und Tiefe im Datenhaushalt bereits erfolgt ist, um verschiedene Datenabnehmer spezifisch beliefern zu können. Mit den derzeitigen regulatorischen Entwicklungen in Bezug auf übergreifende Datenkonsistenz und als mögliche Antwort auf die konsistente Umsetzung verschiedener, fachlich abhängiger regulatorischer Berichtsanforderungen, erhält das Lösungsprinzip DWH eine neue Aktualität.
In vielen Instituten gibt es bereits Erfahrungen im Data Warehousing. Mit Blick auf die Fähigkeiten und Rahmenbedingungen im Datenmanagement kann die Ausgangssituation daher eine andere sein, als im oben beschriebenen Fallbeispiel A. Da für den Aufbau und Betrieb eines DWH ein von den Fachanwendern unabhängiges daten- und systemspezifisches Wissen erforderlich ist, entstehen im Umfeld von großen DWH-Lösungen oft spezialisierte Einheiten und Teams, deren Verantwortungsbereich von der Entwicklung bis zur fachlichen Analyse reichen kann, und die im Ansatz das Aufgabenspektrum eines umfassenden Datamanagements abdecken.
Grenzen des Data-Warehouse-Ansatzes
Dass auch diese Organisationsform nicht notwendigerweise ausreicht, um das Ziel der fachlichen Konsistenz über Anwendungsbereiche und Systeme hinweg zu gewährleisten, soll am Fallbeispiel einer Bank illustriert werden, die die Strategie verfolgt, über eine technische Plattform die Integration von Basisdaten und Ergebnisdaten zu erzwingen - im Folgenden Ambitious Bank genannt (Fallbeispiel B).
Eindeutige Erfolge eher die Ausnahme
Bei klassischen DWH-Projekten ist die Floprate erfahrungsgemäß sehr hoch. Eindeutige Erfolge sind eher die Ausnahme als die Regel. Das Fallbeispiel B zeigt einige Gründe dafür auf: Oftmals wird versucht, zu viele und zu unterschiedliche Informationen in nicht geeigneter Struktur abzubilden, mit dem Ergebnis, dass ein unflexibles Gesamtkonstrukt entsteht, dessen zukünftige Pflege und Erweiterbarkeit sich sehr aufwändig gestaltet. Die Projekte verfolgen in dieser Situation oft einfache Wege zum Ziel und vermeiden dadurch die fachliche Datenintegration, das heißt, neue Sachverhalte werden neben bestehenden implementiert, ohne zu prüfen, ob mit geeigneten Maßnahmen eine Übereinstimmung oder Überleitbarkeit hergestellt werden kann. Gerade bei ambitionierten, hochintegrativen Lösungen ist der schiere Umfang der fachlichen Integrationsleistung groß: Prinzipiell muss jede Kombination von Produktvariante, Datenfeld und fachlicher Auswertungslogik gegen den Hintergrund bestehender Strukturen analysiert und nachhaltig integriert werden.
Aus diesem Grund ist es ein Fehler, die Verantwortung für Themen wie Data Warehousing und Datenmanagement alleine in der IT-Organisation zu verorten, und gleichzeitig die fachliche Konzeption des Zielbildes in der Datenarchitektur zu vernachlässigen. Konsequent an einer nachhaltigen Lösungen zu arbeiten, umfasst nicht zuletzt auch die Bereitschaft, den Wert von Umsetzungsänderungen, die aus dem fachlichen Datenmanagement motiviert sind, zu erkennen und explizit in Priorisierung, Planung und Budgetierung vorzusehen, auch wenn sich für die konkreten Fachprojekte keine unmittelbaren Vorteile ergeben.
Die Nachteile zeigen sich hingegen erst langsam in Form zunehmender Inflexibilität und Intransparenz, die langfristig alle Datenabnehmer betreffen. Unklare Erwartungen in Verbindung mit einer nachrangigen Behandlung hinsichtlich der aufbauorganisatorischen Verankerung sind hier Vorboten des Scheiterns.
Prototypische Architekturansätze
Die Abbildung zeigt schematisch drei prototypische Architekturansätze. In der Praxis kommen diese Ansätze zwar typischerweise nicht in der Reinform vor. Dennoch liefern sie als Idealbilder nützliche Hinweise für die möglichen Konsequenzen, die sich aus Architekturentscheidungen ergeben. Die gezeigten Ansätze haben jeweils Vor- und Nachteile, womit die Entscheidung stets eine Abwägungsfrage ist, die die institutsspezifischen Umstände berücksichtigen muss, zum Beispiel Konzernstrukturen, Breite und Komplexität des Produktportfolios sowie die Systemlandschaft.
Die Fallbeispiele A (entspricht der Pointto-Point-Architektur) und B (entspricht der vollintegrierten DWH-Architektur) sollen nicht suggerieren, dass es für Banken einen richtigen und einen falschen Ansatz im Datenmanagement gibt. Gerade für kleine Banken ist der opportunistische Ansatz einer Point-to-Point-Architektur gegebenenfalls sogar der sinnvollste, auch wenn in diesem Fall die Datenkonsistenz nur durch zusätzliche Anstrengungen gewährleistet werden kann. Die Schaffung einer konsistenten Datenbasis wird auf der anderen Seite oft gleichgesetzt mit der Einführung eines (zentralen) DWH, auf dessen Basis alle technischen und fachlichen Integrationsprobleme gelöst werden sollen. Obwohl eine technisch erzwungene Datenintegration dies sicherlich begünstigt, ist es jedoch keineswegs garantiert, dass damit die Entwicklung hin zu einer fachlich konsistenten Datenbasis auch erreicht wird.
Die Gegenüberstellung der Architekturvarianten anhand der beiden Fallbeispiele mit den jeweiligen Vor- und Nachteilen soll an dieser Stelle nur illustrieren, dass die Datenarchitektur zwar die Anforderungen einer fachlichen Integration beeinflusst, aber in keiner Lösungsvariante vollständig entbehrlich macht. Das fachliche Datenmanagement beschreibt folglich die Bündelung der Aufgaben, die nicht allein durch die IT-technischen Implementierungen und durch einzelne Fachprojekte gelöst werden können. Je nach Ausgangslage, Komplexität des Instituts und zugrundeliegender Datenarchitektur umfasst das fachliche Datenmanagement ein großes Spektrum von Aufgaben, das weit über die in den Fallbeispielen motivierten Punkte hinausgeht, unter anderem:
- Definition und Management von Grundmengen, (Kalkulations-)Funktionen, Kennzahlen und Taxonomien,
- Übergreifende fachliche Datenmodellierung von Geschäftsobjekten bis Feldebene,
- Analyse von Quellsystemen,
- Wartung von Metadaten,
- Priorisierung und Planung von Systemänderungen,
- Datenqualitätsmanagement.
Verbesserte Prozesse im Bereich der Datenerfassung, -verarbeitung und -auswertung vor dem Hintergrund einer flexiblen, modular erweiterbaren Daten- und Systemarchitektur sind wichtige Voraussetzungen für den praktischen Erfolg eines fachlichen Datenmanagements. Es gilt dabei jedoch auch, die generelle Bedeutung des Datenmanagements allen Mitarbeitern des Instituts transparent zu machen und für die damit einhergehenden Veränderungen zu werben - eine Aufgabe, die daher idealerweise im Senior-Management angesiedelt ist.
Insgesamt wird das zukünftige Bankgeschäft mehr denn je durch Daten repräsentiert werden. Themen wie Digitalisierung und Big Data zwingen viele Institute zum Handeln, in dessen Zentrum dann oft das individuelle Bedienen von Kundenwünschen steht. Damit einher geht dann oft auch die bewusste Weiterentwicklung der Daten und vor allem Metadaten im Sinne einer Optimierung des Vertriebspotenzials (Up-Selling, Cross-Selling) sowie zur Erbringung neuer Dienstleistungen.
Die Transformation hin zu einer datengetriebenen Bankenwelt, in der Daten als eigenständiger Unternehmenswert verstanden werden, ist ein umfassender Prozess, in dem die in diesem Artikel behandelten Themen nur Bausteine darstellen können.
