SlideShare ist ein Scribd-Unternehmen logo
Finanzrechtliche	Aufsichtsregeln	für	die	Risikosteuerung	in	Finanzinstituten	
	
Wie	kann	Data	Vault	bei	der	Modernisierung	der	Risikosteuerung	in	
Banken	helfen?	
Die	 Folgen	 der	 Finanzmarkt-	 und	 Staatsschuldenkrise	 sind	 teuer,	 vor	 allem	 für	 uns	 Steuerzahler.	 Die	
Regulierungsbehörden	 in	 Europa	 und	 Deutschland	 versuchen	 jetzt	 die	 Steuerbarkeit	 der	 Finanzinstitute	 zu	
gewährleisten	und	eine	Wiederholung	der	Krise	zu	verhindern.	Die	Regulatoren	von	BCBS	239	(einer	Vorschrift	vom	
„Basel	Comittee	on	Banking	Supervision“	kurz	BCBS)		schätzen	für	die	Umsetzung	dieser	Maßnahme	einen	mittleren,	
zweistelligen	 Millionenbetrag	 pro	 Institut	 insgesamt	 und	 in	 Einzelfällen	 einen	 dreistelligen	 Millionenbetrag	 an	
Investitionen.	 Anhand	 der	 Handlungsbedarfe,	 die	 sich	 aus	 BCBS	 239	 ergeben	 erläutere	 ich	 wie	 die	 Data	 Vault	
Methodik	bei	der	Realisierung	helfen	kann.	
	
Die	 Vorgaben	 der	 internationalen	 Aufsichtsbehörden,	
Finanzgremien	 und	 –organisationen	 verstecken	 sich	 hinter	
Begriffen	 wie	 MaRisk,	 IFRS	 9-13,	 FinRep,	 CoRep	 usw.	
Gemeinsam	 ist	 ihnen	 heutzutage	 vor	 allem	 das	 Ziel	 das	
Risikomanagement,	 die	 Rechnungslegung	 und	 die	
Finanzmarktprodukte	im	Bankensystem	so	zu	regulieren	und	
wieder	steuerbar	zu	machen,	dass	sich	eine	Finanzmarktkrise	
nicht	mehr	wiederholen	kann.		
	
	
Abbildung	 1	 Regulierungsbehörden	 International	 und	
National	gemäß	(Quelle	3)		
Über	den	Sinn	oder	die	Fähigkeit	dieser	Maßnahmen	dieses	
Ziel	 tatsächlich	 zu	 erreichen	 lässt	 sich	 streiten,	 aber	 darum	
soll	es	in	diesem	Artikel	nicht	gehen.	Vielmehr	soll	es	darum	
gehen,	 welche	 konkreten	 Realisierungsmaßnahmen	
beispielhaft	hinter	BCBS	239	–	einer	weiteren	Regulierung	in	
diesem	 Zuge	 –	 vor	 den	 Finanzinstitutionen	 stehen	 und	
inwiefern	die	Data	Vault	Methode	dabei	helfen	kann	diese	zu	
implementieren.	
Bei	 der	 Aufarbeitung	 und	 Analyse	 der	 Ursachen	 für	 die	
Finanzmarktkrise	 sind	 wir	 bestimmt	 noch	 nicht	 und	 werden	
vielleicht	auch	nie	am	Ende	ankommen.	Dafür	ist	es	auch	ein	
zu	 komplexes	 Gebilde	 mit	 vielen	 Einflussfaktoren	 und	 viel	
Politik.	 Allgemein	 anerkannt	 ist	 die	 Erkenntnis	 dass	 es	 auch	
um	 ein	 Regulierungsversagen	 ging	 und	 effiziente	
Frühwarnsysteme	 basierend	 auf	 einem	 standardisierten	 und	
umfassenden	Risikomanagement	in	den	Instituten	eine	solche	
Krise	 verhindern	 könnten,	 wenn	 dies	 die	 Qualität	 der	
analytischen	 Datengrundlage	 in	 den	 Finanzinstitutionen	
hergäbe.	 Diese	 Qualität	 wiederum	 hängt	 von	
Datenmanagement	Prozessen	und	der	Infrastruktur	innerhalb	
dieser	Institutionen	ab.	Risikodaten	existierten	häufig	lediglich	
in	Silos	in	Geschäften	und	Funktionen	und	sind	dann	weder	
übergreifend,	noch	granular	nachvollziehbar.	
Verkürzt	 könnte	 man	 also	 sagen,	 dass	 Banken	 es	 nicht	
geschafft	haben	valide	Risikodaten	in	angemessener	Zeit	so	zu	
aggregieren	 und	 auszuwerten,	 dass	 Risiken	 wie	 die	
Immobilienblase,	 undurchsichtige	 Finanzprodukte	 und	 die	
allgemeine	Marktlage	tatsächlich	steuerbar	gewesen	wären	–	
die	Risiken	wurden	nicht	quantifiziert	und	standen	somit	auch	
weder	 im	 Fokus	 der	 Entscheider	 noch	 in	 dem	 der	
Kontrolleure.	 Institutionen	 haben	 zudem	 nicht	 mehr	 die	
Möglichkeit	 ihre	 Probleme	 mit	 dem	 Datenmanagement	 in	
intensiven	 und	 langen	 Projekten	 zu	 verifizieren	 -	 auch	 hier	
wird	der	Druck	nach	schneller	Reaktionszeit	höher	–	nicht	nur	
für	 die	 Befriedigung	 der	 Regulatoren,	 sondern	 auch	 beim	
Erfüllen	von	Anforderungen	für	das	Management.	
	
	
Abbildung	 2	 BCBCS	 239	 Themenbereiche	 und	 Prinzipien	
(Quelle	3)	
Die	BCBS	239	im	Detail	
Um	das	Risikomanagement,	Datenmanagement	und	erstmalig	
auch	ganz	konkret	um	die	IT	der	Banken	geht	es	in	der	BCBS
239,	 einer	 Vorgabe	 der	 Bank	 of	 International	 Settlements	
(www.bis.org)	 und	 seinem	 „Basel	 Commitee	 on	 Banking	
Supervision“.		
Es	 werden	 14	 Grundsätze	 formuliert,	 die	 konkrete	
Einzelforderungen	 zu	 vier	 Themenbereichen	 beinhalten.	 Die	
Grundsätze	regeln	Prozesse	und	Daten	zur	Bankensteuerung	
und	Risikotragfähigkeit.	Außerdem	im	Fokus	steht	die	ad-hoc	
Fähigkeit	in	Stresssituationen	Ergebnisse	automatisiert	liefern	
zu	 können.	 Es	 sollen	 auch	 Szenarien	 und	
Simulationsrechnungen	ermöglicht	werden.		
Beispielhaft	sind	dies:	
• Governance	und	Infrastruktur	
o Vollständige	 Dokumentation	 der	
Datenaggregation	auf	granularem	Level	
o Einheitliche	 Taxonomien	 und	 zentrales	
Metadatenmanagement	
o Transparenz	 zu	 Lebenszyklus	 von	 Daten	 –	
konsistenter	Business	und	IT	View	
• Aggregation	von	Risikodaten	
o Vollständige	 Dokumentation	 der	
technischen	und	organisatorischen	Prozesse	
rund	um	die	Erstellung	des	Risikoberichtes.	
o Technische	 und	 organisatorische	 Prozesse	
rund	um	die	Erzeugung	des	Risikoberichtes	
müssen	dokumentiert	sein	
• Risikoreporting	
o Glossar	 mit	 Risikobegriffen	 –	 Verlinkung	 in	
Risikoreports	
Die	Anforderungen	sind	im	Detail	vielschichtig	und	komplex,	
weil	 eine	 solche	 Konsolidierung	 von	 Risikokennzahlen	 auf	
granularer	 Ebene	 bisher	 noch	 nicht	 im	 Fokus	 der	 Banken	
stand	und	auf	dieser	Ebene	diverse	Quellsystem	wie	Kredite,	
Liquidität,	 Marktdaten,	 Immobilien	 integriert	 sein	 müssen,	
um	 dann	 auch	 die	 notwendigen	 Metadaten	 für	 die	
Nachvollziehbarkeit	der	aggregierten	Risikodaten	anbieten	zu	
können.	 Hinzukommt	 dass	 die	 Zeit	 zur	 Umsetzung	
verhältnismäßig	knapp	bemessen	wurde.	
Nachdruck	wurde	dieser	Regelung	dadurch	verliehen,	dass	die	
Geschäftsleitung	 selbst	 für	 die	 Umsetzungsverantwortung	
eingeteilt	worden	ist.	
	
Handlungsbedarfe	
Somit	 ergeben	 sich	 sehr	 konkrete	 Handlungsbedarfe	 für	 die	
Organisation	und	den	Ablauf	der	Risikofunktionen	und	die	IT-
Architektur	bzw.	das	Datenmanagement:		
• Automatisierung	der	Reportauslieferung	und	Ad-hoc	
Auswertungen	
• Flexible	Anpassungen	regulatorischer	Änderungen	
• Integrierte	 Datenhaltung	 (Insbesondere	 Risiko-	 und	
Finanzdaten),	einheitliches	Datenmodell	
• Schnellere	Bereitstellung	(Reporterstellung	innerhalb	
von	10	Tagen	nach	Stichtag	–	zuvor	waren	es	56)		
• Fokus	 auf	 Kreditrisiko,	 Kontrahentenrisiko,	
Handelsrisiken,	 Marktrisiken,	 Liquiditätsrisiken	 und	
Operationelle	Risiken	
• Eine	einheitliche	technologische	Plattformen	und	IT-
Anwendungen	
• Deutliche	 Reduzierung	 von	 Medienbrüchen	 und	
Integration	von	Insellösungen	
• Einführung	von	modernen	und	effektiven	Systemen	
und	Verfahren	zur	Datenverarbeitung	und	-analyse	
• Verankerung	 der	 Gesamtlösung	 in	 das	 Governance-
Framework	
Es	 wird	 seitens	 der	 Regulierer	 von	 Investitionskosten	 in	 der	
Größenordnung	von	dreistelliger	Millionenhöhe	ausgegangen	
–	 zumindest	 bei	 den	 großen,	 systemrelevanten	 Banken	 (G-
SIBs).	
	
Abbildung	3	Bis	wann	muss	BCBS	239	umgesetzt	werden?	(Quelle	
3)	
Die	Regelung	wird	bis	2016	bereits	für	die	sogenannten	G-SIBs	
verpflichtend	und	somit	bereits	in	der	Realisierung,	allerdings	
gibt	es	anschließend	noch	die	weiteren	Institute,	die	national	
systemrelevant	eingestuft	(D-SIB)	und	nach	und	nach	benannt	
werden.	Diese	Institute	haben	für	die	Umsetzung	3	Jahre	Zeit	
nach	 ihrer	 Benennung;	 alle	 anderen	 Institute	 haben	 keine	
zwingende	Bindung	an	die	Regelung,	allerdings	kommt	BCBS	
239	 auch	 zur	 Aufnahme	 in	 den	 MaRisk	 Standard.	 Letzten	
Endes	 bedeutet	 dies	 also	 dass	 BCBS	 239	 die	 Institute	 noch	
einige	Zeit	beschäftigen	wird,	sofern	das	Thema	nicht	bereits	
schon		angegangen	wurde.	
	
Sind	Banken	gut	vorbereitet?	
Interessant	ist	in	diesem	Zusammenhang	auch	eine	Umfrage,	
die		msgGillardon	im	IT-Finanzmagazin	veröffentlichte	(siehe	
Quelle		4).		
	
	
Abbildung	 4	 Integrationsgrad	 von	 Finanz-,	 Risiko-	 und	 Treasury-
Daten	gemäß	Quelle	4
Demnach	 sind	 viele	 deutsche	 Institute	 gerade	 was	 die	
geforderten	 Bereiche	 von	 BCBS	 239	 angeht	 nicht	 gut	
aufgestellt.	 29%	 der	 Banken	 seien	 ohne	 Daten-	 und	
Prozessverantwortlichkeiten,	 45%	 der	 Banken	 haben	 keine	
durchgängige	 Messung	 der	 Datenqualität.	 Unter	 Sparkassen	
haben	 61%	 noch	 Nachholbedarf	 und	 20%	 der	 Institute	
korrigieren	ihre	zu	Grunde	liegenden	Daten	nicht	regelmäßig.	
Außerdem	 schneiden	 die	 Institute	 schlecht	 bei	 der	
Governance	ab,	wo	nur	13%	der	Befragten	unterhalb	der	2.	
Hierarchiestufe	 Wissen	 zu	 Datenqualitätsprozessen	 hatten.	
Beim	 Thema	 Datenintegration	 gibt	 die	 Studie	 vom	
Faktenkontor	 (Abb.	 4)	 Auskunft	 darüber,	 dass	 Risiko-	 und	
Finanzdaten	 nur	 in	 50%	 der	 Institute	 integriert	 vorliegen.	
Weiter	 wird	 zitiert,	 dass	 Metadatenverwaltung	 in	 27%	 der	
Fälle	 existiert	 und	 bei	 56%	 der	 Banken	 nur	 unvollständige	
Metadaten	im	Datamart	aufweisen.	
	
Traditioneller	DWH	Ansatz	in	Finanzinstituten	
Häufig	 wird	 bisher	 versucht	 in	 Ladeprogrammen	 im	 Data	
Warehouse	eine	Kombination	vieler	Anliegen	in	einem	Schritt	
zu	erledigen.	So	müssen	im	klassischen	Data	Warehouse	das	
3NF-Modell	 erzeugt,	 Daten	 bereinigt	 und	 die	 	 technische	
Historisierung	 und	 Harmonisierung	 berücksichtigt	 werden.	
Die	daraus	resultierenden	ETL-Mappings	werden	zu	komplex	
und	sorgen	für	Inflexibilität	bei	Änderungen.		
Das	weitere	Problem	bei	diesem	Ansatz	ist	die	Veränderung	
der	Quelldaten	vor	Aufnahme	in	das	Data	Warehouse,	so	dass	
unter	Umständen	die	Nachvollziehbarkeit	der	Daten	und	die	
Rückverfolgung	in	das	Quellsystem	gar	nicht	mehr	möglich	ist.	
Hinzu	kommt,	dass	gerade	DWHs	in	finanziellen	Institutionen	
starken	 Änderungen	 und	 Schwankungen	 in	 den	
Geschäftsregeln	 unterliegen.	 Die	 Komplexität	 in	
Berechnungsmethoden	 und	 die	 Anforderungen	 in	 den	
verschiedenen	 Geschäftsbereichen	 machen	 einen	
monolithischen,		zentralistischen	DWH-Ansatz	problematisch:	
• Fokus	 auf	 Datenakquisition	 und	 Bereinigung	 der	
Quelldaten	auf	dem	Weg	in	das	DWH	
o ETL	als	manueller	Aufwandstreiber	
o „Enterprise	 Data	 Model“,	 EDM	
(unternehmensweites	 Datenmodell)	 mit	 zu	
großem	 Scope	 und	 3NF-Modellierung,	
Quellsystem	 sind	 häufig	 fragmentiert	 und	
überlappend,	 was	 zu	 Schwierigkeiten	 bei	
der	Integration	nach	EDM	führt	
• Analytische	Prozesse	außerhalb	des	DWH	
o DWH	 Ersteller	 und	 Nutzer	 driften	 zu	 weit	
auseinander	
o Datenflüsse	umgehen	das	DWH	
o Unternehmensübergreifende	 Sichten	 über	
mehrere	Risikogruppen	wird	unmöglich	
• Data	 Mart	 Silos	 mit	 Logik,	 die	 ins	 Data	 Warehouse	
gehört	
Durch	 solch	 eine	 Situation	 kommt	 es	 bei	 diesen	 DWH-
Ansätzen	 häufig	 zu	 einem	 Veränderungsstau	 nach	 einigen	
Jahren,	 weil	 das	 Umsetzen	 neuer	 Anforderungen	 durch	 die	
laufend	 gestiegene	 Komplexität	 des	 ETL	 immer	 	 teurer	
werden.	Konzepte	zur	Datenqualität	und	Metadaten	werden	
dann	gerne	auch	unter	dem	Druck	der	ständig	eintreffenden	
Fachbereichsanforderungen	 immer	 weiter	 nach	 hinten	
verschoben.	
	
	
Data	Vault	Architektur	im	Einsatz	
Vor	 diesem	 Hintergrund	 kann	 es	 Sinn	 machen	 die	
anstehenden	 Aufgaben	 und	 Herausforderungen	 durch	 BCBS	
239	 ernst	 zu	 nehmen	 und	 die	 bestehende	 Data	 Warehouse	
Lösung	durch	eine	neue,	moderne	Architektur	und	Methodik	
zu	ergänzen	oder	ersetzen.	
Zusätzlich	 zur	 Data	 Vault	 Architektur	 möchte	 ich	 noch	 das	
Quadrantenmodell	 von	 Ronald	 Damhoff	 (Abb.	 5)	 vorstellen,	
da	 es	 sich	 hervorragend	 dazu	 eignet	 eine	 Data	 Vault	
Architektur	abseits	von	Technik	zu	vermitteln.	Es	verwendet	
eine	Analogie	aus	der	Wirtschaft:	Datenaufbereitung	im	DWH	
wird	mit	einem	Lieferprozess	verglichen.	Unterschieden	wird,	
ob	das	Produkt	(die	Daten)	vom	Kunden	spezifiziert	sind	oder	
seitens	 der	 IT	 auf	 Lager	 produziert	 wird.	 Die	 horizontale	
Unterscheidung	 spielt	 für	 unsere	 Betrachtung	 nur	 eine	
sekundäre	 Rolle.	 In	 Q1	 wird	 also	 zu	 möglichst	 niedrigen	
Stückkosten	produziert,	um	die	Läger	zu	füllen.	Das	bedeutet	
wir	 haben	 einfache	 Fertigungsprozesse	 und	 einen	 hohen	
Automationsgrad.	Im	Q2	allerdings	bestimmt	der	Kunde	(den	
Kontext)	 und	 damit	 wie	 das	 Produkt	 aussehen	 soll.	 Im	
Ergebnis	 bedeutet	 dies	 also	 einen	 manuellen	
DM	Strategie	„Data	Quadranten	Modell“	von	Ronald	Damhof	
						
	 	
	
Quadrant	1:	„Single	Version	of	Facts“,	automatisierte	Bereitstellung	
„Simple/Order“	
Quadrant	2:	Kontextinformation,	„Complicated/Order“	
Quadrant	4:	„Complex/Un-order“	
Quadrant	3:	Chaos	
Quadrant	2	und	Quadrant	4:	„Multiple	Versions	of	the	Truth“	
http://prudenza.typepad.com/dwh/2015/05/data-quadrant-model-decreasing-entropy.html	
	
Abbildung	5	Data	Deployment	Quadrant	von	Ronald	Damhoff	
gemäß	Quelle	2
Fertigungsprozess	 zu	 höheren	 	 Stückkosten,	 aber	 dafür	 mit	
individuell	angepassten	Produkten.		
Im	Q1	sind	unsere	Standardprodukte	die	nach	übergreifenden	
Business	 Keys	 integrierten	 Quelldaten,	 die	 gemäß	 der	 Data	
Vault	 Modellierung	 und	 den	 zugehörigen	 Lademustern	 voll		
automatisiert	und	historisiert	geladen	werden	können.	Im	Q2	
allerdings	gibt	es	unterschiedliche	Abnehmer	und	Szenarien,	
die	 dafür	 sorgen	 dass	 wir	 Kontext	 vom	 Kunden	
berücksichtigen	 und	 Geschäftsregeln	 implementieren	
müssen,	 um	 die	 Daten	 so	 anzupassen,	 wie	 der	 Kunde	 diese	
auch	verwerten	möchte.	
	
	
Abbildung	 6	 Datenmodellierung	 und	 Datenfluss	 im	 Data	
Vault	DWH	
Dies	 beschreibt	 dann	 auch	 schon	 sehr	 gut	 das	 Prinzip	 des		
„Separation	of	Concerns“	bei	der	Datenaufbereitung	im	Data	
Warehouse.	 Die	 Ladeprozesse	 im	 Raw	 Vault	 sind	 so	 trivial,	
dass	sie	anhand	der	physischen	Datenmodelle	von	Stage	und	
Raw	Data	Vault	und	einem	einfachen	1:1	Mapping	generiert	
werden	können,	ohne	dass	hier	manuelle	Programmierung	zu	
tätigen	 ist	 –	 dank	der	Lademuster	 zu	 Hub,	 Link	 und	 Satellit.	
Außerdem	sind	die	Daten	bereits	nach	der	technischen	Sicht	
des	 Data	 Warehouse	 historisiert,	 so	 dass	 häufig	 für	
Anforderungen	 ohne	 weitere	 Timelines	 in	 späteren	
Ladeprozessen	nichts	mehr	hinzugefügt	werden	muss.	
Der	 zweite,	 wichtige	 Aspekt	 dieser	 Vorgehensweise	 im	 Raw	
Vault	 ist	 die	 vollständige	 Nachvollziehbarkeit	 der	 Daten	
zurück	 in	 die	 Quelle,	 weil	 alle	 Attribute	 1:1	 abgebildet	 sind	
und	granulare	Daten	geladen	werden.	
In	diesem	ersten	Schritt	werden	aber	nicht	nur	Quelltabellen	
kopiert,	sondern	es	findet	auch	eine	Integration	nach	Business	
Keys	 statt.	 Hierüber	 wird	 gewährleistet,	 dass	 sich	
wiederholende	 Entitäten	 der	 Quellsysteme	 im	 Data	
Warehouse	 in	 identische	 Strukturen	 geladen	 werden	
(Integration	über	die	Hubs).		
Somit	 folgt	 der	 Data	 Vault	 auch	 einem	 logischen	 oder	
konzeptionellen	 Unternehmensmodell,	 bleibt	 dabei	 aber	
aufgrund	 der	 physischen	 Trennung	 von	 fachspezifischen	
Attributen	und	Relationen	flexibler	als	die	3NF-Modellierung.		
Diese	 flexiblere	 Ausgestaltung	 der	 Tabellenstrukturen	
ermöglicht	 dabei	 auch	 die	 iterative	 –	 also	 die	
anforderungsgetriebene	 Vorgehensweise.	 Analyseprozesse,	
die	 bereits	 auf	 bestehende	 Tabellenstrukturen	 zugreifen	
werden	 für	 neue	 Anforderungen	 nicht	 in	 Mitleidenschaft	
gezogen,	 da	 neue	 oder	 geänderte	 fachliche	 Relationen	 und	
Attribute	keine	Veränderungen	mehr	in	der	Tabellenstruktur	
der	 Datenbank	 nach	 sich	 ziehen.	 (Non-Destructive	 Data	
Model).	 Somit	 sollte	 auch	 das	 Problem	 von	 komplexen,	
überlappenden	 Quellsystemen	 in	 den	 Griff	 zu	 bekommen	
sein.	
Zusätzlich	 soll	 hier	 auch	 noch	 erwähnt	 werden,	 dass	 einige	
Datenmodellierungswerkzeuge	 das	 Mapping	 von	
Datenelementen	beherrschen,	so	dass	in	den	Situationen,	wo	
Datenmodelle	 transformiert	 werden	 tatsächlich	 anhand	 der	
Metadaten	 vom	 Modellierungswerkzeug	 Ladeprozesse	
generiert	 werden	 können,	 ohne	 die	 Notwendigkeit	 das	
Modellierungswerkzeug	zu	verlassen	(siehe	Abb.	5).	
Im	 nächsten	 Schritt	 werden	 im	 Business	 Vault	 ebenfalls	
wieder	 Datenelemente	 per	 Mapping	 umgeschrieben	 –	
diesmal	 von	 DataVault	 nach	 DataVault	 –	 aber	 unter	
Anwendung	 von	 Geschäftsregeln.	 Hier	 werden	 dann	 die	
tatsächlichen	 Berechnungen	 ausgeführt,	 die	 zum	
Risikomanagement	 gehören	 und	 manuellen	 Aufwand	 in	
einem	 ETL-Werkzeug	 verlangen.	 Die	 komplexen	 fachlichen	
Regeln	 der	 Anwender	 werden	 hier	 in	 den	 unterschiedlichen	
Sichten	 implementiert	 und	 bedeuten	 Datenaufbereitung,	
Zeitsichten,	 BI-temporale	 Sichten,	 Point-In-Time	 und	 Bridge	
Tabellen	 für	 dimensionale	 Sichten	 und	 vieles	 mehr.	 Hier	
konzentriert	 sich	 die	 fachliche	 Arbeit	 der	 Beteiligten.	
Entsprechend	 sind	 wir	 dann	 auf	 die	 Möglichkeiten	 des	 ETL-
Werkzeuges	 oder	 des	 zugehörigen	 Metadatenservers	 zur	
Nachvollziehbarkeit	der	Daten	angewiesen.	
Der	letzte	Schritt	ist	dann	wieder	eine	Modelltransformation	
vom	 Data	 Vault	 Modell	 des	 Business	 Vault	 in	 ein	
dimensionales	 Modell	 oder	 andere	 Berichtsstrukturen,	 auf	
denen	das	BI	Frontend	aufsetzt.	
Wenn	 man	 sich	 diesen	 Prozess	 anhand	 der	 Grafik	 und	 der	
Datenmodellierung	 vorstellt,	 wird	 denke	 ich	 klar,	 dass	 auch	
eine	Annäherung	von	Fachbereichen	und	IT-Personal	erreicht	
werden	 kann.	 Die	 Quellsystemintegration	 rückt	 durch	 die	
Automatisierung	komplett	in	den	Hintergrund	und	an	dessen	
Stelle	rücken	die	Datenmodellierung	und	die	Geschäftsregeln.	
Als	 gemeinsame	 Kommunikationsgrundlage	 sollte	 die	
konzeptionelle	oder	logische	Ebene	des	Datenmodells	dienen.		
Gleichermaßen	 steuert	 auch	 die	 Automatisierung	 zur	
Kommunikationsförderung	 bei.	 Denn	 durch	 die	 schnelle	
Bereitstellung	 der	 Daten	 können	 Feedbackschleifen	 mit	
Fachanwendern	 sehr	 schnell	 erfolgen.	 Hierzu	 können	 zum	
Beispiel	auch	sogenannte	virtualisierte	Marts	erstellt	werden,	
die	 ein	 Star	 Schema	 mit	 SQL-Views	 abbilden.	 Diese	
temporären	Sichten	dienen	dann	als	Grundlage	für	Gespräche	
bei	 denen	 man	 bereits	 konkrete	 Fälle	 basierend	 auf	
integrierten	 Daten	 durchspielen	 kann,	 anstatt	 auf	 das	
Vorstellungsvermögen	 der	 Beteiligten	 alleine	 angewiesen	 zu	
sein.	
	
Metadaten	und	Datenqualität	
Um	 nun	 die	 vollständige	 Dokumentation	 zu	 erreichen,	 die	
gemäß	 BCBS	 239	 gefordert	 ist,	 bedarf	 es	 mehr	 als	 der	
Datenmodelle	und	der	Geschäftsregeln	in	ETL	Mappings	des	
Business	 Vaults.	 Einige	 Metadatenserver	 auf	 dem	 Markt	
können	die	BI	Frontendmodelle,	Datenmodelle,	Glossary	und	
andere	 fachliche	 Beschreibungen	 importieren.	 Anschließend	
lassen	 sich	 Verbindungen	 zwischen	 diesen	 Elementen	
herstellen	 und	 somit	 fachliche	 und	 technische	 Metadaten	
gemeinsam	 darstellen.	 Das	 bedeutet	 dann	 manuellen	
Aufwand,	kann	aber	 ausreichen,	um	die	Anforderungen	von	
BCBS	 239	 zu	 erfüllen.	 Hier	 stellt	 sich	 dann	 wieder	 die	 Frage	
nach	der	Governance	und	den	entsprechenden	prozessualen	
Vorgaben	zur	Umsetzung	dieser	Maßnahmen.
Durch	 die	 „Single	 Version	 of	 Facts“	 im	 Raw	 Vault	 können	
Datenprobleme	 der	 Quellsysteme	 nachvollzogen	 und	
überprüft	 werden.	 Die	 Entscheidung	 im	 Data	 Warehouse	
zunächst	alle	Daten	ohne	Harmonisierung	oder	Bereinigungen	
zu	 laden	 ermöglicht	 die	 GAP-Analyse.	 Hier	 kann	 auch	 eine	
historische	Entwicklung	der	Datenqualität	dargestellt	werden,	
weil	im	Raw	Vault		historisiert	wird.	Dies	setzt	natürlich	immer	
voraus,	 dass	 die	 Datenqualitätsprobleme	 in	 den	
Quellsystemen	 auch	 behoben	 worden	 sind	 und	 nicht	 nur	
entsprechende	Geschäftsregeln	im	DWH	implementiert	sind.	
Die	klare	Empfehlung	kann	daher	nur	sein	die	Korrektur	von	
Datenqualitätsproblemen	 und	 auch	 die	 Erzeugung	 von	
Stammdaten	 –	 also	 MDM	 –	 außerhalb	 des	 DWH	 zu	
realisieren.	 Der	 Raw	 Vault	 ist	 als	 historisierte	 „System	 of	
Record“	 der	 Quellsysteme	 als	 Quelle	 für	 diese	 Art	 von	
Vorhaben	geeignet	–	nicht	aber	als	Ziel.	Im	Idealfall	werden	
korrigierte	 Quelldaten	 aus	 dem	 MDM	 oder	 direkt	 aus	 der	
Quelle	 zurück	 in	 das	 DWH	 geladen,	 was	 dann	 auch	 die	
Grundlage	 für	 die	 zuvor	 erwähnte	 Darstellung	 der	
(hoffentlich)	positiven	Entwicklung	der	Datenqualität	ist.		
	
Fazit	
Zum	 Schluss	 kann	 man	 sagen,	 dass	 vor	 allem	 die	
Automatisierung	 und	 die	 anforderungsgetriebene	
Ausrichtung	 von	 Data	 Vault	 die	 Einstiegsbarrieren	 für	 diese	
Methodik	 recht	 niedrig	 aufhängen.	 Schließlich	 ist	 es	 sogar	
empfohlen	 klein	 zu	 starten	 und	 dann	 iterativ	 vor	 zu	 gehen.	
Auch	 eine	 parallele	 und	 schrittweise	 Einführung	 	 zum	
bestehenden	System	ist	möglich.	
Natürlich	 gibt	 es	 auch	 eine	 Anfangsinvestition	 für	 die	
Ausbildung,	 Etablierung	 der	 Methoden	 in	 der	 Infrastruktur	
und	 eventuell	 auch	 neue	 Werkzeuge.	 Erfahrungsgemäß	
können	durch	den	Einsatz	von	Automatisierung	im	Data	Vault	
Umfeld	die	Entwicklungsaufwände	der	ETL-Strecken	im	Core	
Warehouse	 auf	 1/4	 sinken	 –	 verglichen	 mit	 der	 manuellen	
Erstellung	der	gleichen	Mappings	im	Werkzeug.	Da	kann	man	
von	einer	schnellen	Amortisation	ausgehen.	
Angesichts	 der	 weiteren	 Regulierungsrunden,	 die	 noch	
erwartet	 werden,	 ist	 es	 nicht	 zuletzt	 auch	 eine	 sinnvolle	
Investition	 die	 Anpassungsfähigkeit	 des	 Data	 Warehouse	 zu	
erhöhen	 und	 somit	 die	 Kosten	 dauerhaft	 zu	 senken,	 das	
erreicht	man	sicher	durch	dieses,	agile	Vorgehen.	
In	 Bezug	 auf	 die	 Anforderungen	 für	 BCBS	 239	 erfüllt	 Data	
Vault	 die	 Anforderungen	 zur	 Integration	 der	 Daten	 mittels	
eines	einheitlichen	Datenmodells	und	auch	die	Forderungen	
zur	Nachvollziehbarkeit	der	Zahlen	in	den	Quellsystemen.		
Die	Datenqualität	kann	im	Raw	Vault	gemessen	werden	und	
entsprechend	eine	GAP-Analyse	durchgeführt	werden.		
Bei	den	Anforderungen	zur	Data	Lineage	und	Metadaten	hilft	
Data	Vault	durch	die	Fokussierung	auf	die	Datenmodellierung,	
die	maßgeblich	wird	für	die	Erstellung	von	Beladungsstrecken	
und	somit	auch	zu	einer	Standardisierung	in	diesem	Bereich	
führt.	 Es	 gibt	 am	 Markt	 eine	 gute	 Unterstützung	 für	 diese	
Werkzeuge.	
Die	 Anforderung	 zur	 Performance	 ist	 kaum	 zu	 bewerten.	
Aufgrund	der	Vereinfachung	und	Aufteilung	der	Prozesskette	
(Raw	Vault	und	Business	Vault)	und	der	Tatsache	dass	nur	die	
Geschäftsregeln	 und	 nicht	 die	 Basisdaten	 neu	 berechnet	
werden	 müssen,	 ist	 aber	 alleine	 dadurch	 von	 einer	
Performanceverbesserung	auszugehen.	
Ein	 wesentlicher	 Erfolgsfaktor	 ist	 aus	 meiner	 Sicht	 die	
Förderung	 der	 Kommunikation	 zwischen	 den	 Beteiligten,	
denn	 Projekterfahrung	 zeigt	 doch	 immer	 wieder	 dass	 die	
Menschen	das	Wichtigste	im	Projekt	sind.	Die	Kommunikation	
kann	 mittels	 des	 Quadrantenmodells	 auch	 über	 die	 reinen	
Data	Vault	Interessenten	hinaus	bis	ins	Management	genutzt	
werden.	Die	(Re-)Fokussierung	aller	Beteiligten	auf	fachliche	
Inhalte	 und	 die	 Geschäftsregeln	 wird	 sich	 mehrfach	
auszahlen.	
	
Literatur	
(1)	 Linstedt	 D.,	 Olschimke	 M.	 „Building	 a	 Scalable	 Data	
Warehouse	With	Data	Vault	2.0“	
(2)	 Damhoff	 R.,	 Data	 Quadrant	 Model,	
http://prudenza.typepad.com/dwh/2015/05/data-quadrant-model-
decreasing-entropy.html	
(3)	 Bachinger	 S.,	 Arnsberg	 T.,	 TME-AG	 „Whitepaper	
Modernisierung	 der	 Risikosteuerung	 in	 Banken“,		
http://www.tme-ag.de/fileadmin/customer/documents/Whitepaper_-
_Modernisierung_der_Risikosteuerung_in_Banken.pdf	
(4)	Prellwith	C.,	Nicklas	M.,	msGiilardon,	„BCBS	239	macht	
effizient,	transparent	&	krisenfest“	http://www.it-
finanzmagazin.de/bcbs-239-macht-effizient-transparent-krisenfest-9566/	
	
	
	
	
Torsten	Glunde	ist	Mitgründer	und	CEO	der	Alligator	Company	GmbH	in	Bremen	und	als	Business	Intelligence	Berater	seit	über	20	Jahren	
im	Projektgeschäft	tätig.	E-Mail:	t.glunde@alligator-company.de

Weitere ähnliche Inhalte

Andere mochten auch

Подсистема Статистика, МИС Пациент
Подсистема Статистика, МИС ПациентПодсистема Статистика, МИС Пациент
Подсистема Статистика, МИС ПациентMedotrade
 
Каталог книжной выставки "Зеленая волна" 2013
Каталог книжной выставки "Зеленая волна" 2013Каталог книжной выставки "Зеленая волна" 2013
Каталог книжной выставки "Зеленая волна" 2013
Anna Yermolayeva
 
Van social media naar social business - Workshop CommunicatieBreak 2014
Van social media naar social business - Workshop CommunicatieBreak 2014Van social media naar social business - Workshop CommunicatieBreak 2014
Van social media naar social business - Workshop CommunicatieBreak 2014
Jochem Koole
 
Ekonomika
EkonomikaEkonomika
Ekonomika
Medotrade
 
User activity monitoring with SysKit
User activity monitoring with SysKitUser activity monitoring with SysKit
User activity monitoring with SysKit
SysKit Ltd
 
20082454 taekkyun nam television
20082454 taekkyun nam television20082454 taekkyun nam television
20082454 taekkyun nam television
Taekkyun Nam
 
Oracle notes
Oracle notesOracle notes
Oracle notes
Prashant Dadmode
 
Analysis of the music video
Analysis of the music videoAnalysis of the music video
Analysis of the music video
Presto2012media
 
Media Pembelajaran Biologi Kelas X
Media Pembelajaran Biologi Kelas XMedia Pembelajaran Biologi Kelas X
Media Pembelajaran Biologi Kelas Xpreute
 
Local Nexus Network at Birmingham Business School 19th April 2016
Local Nexus Network at Birmingham Business School 19th April 2016Local Nexus Network at Birmingham Business School 19th April 2016
Local Nexus Network at Birmingham Business School 19th April 2016
Kate Cooper
 
Cloud First, On-Premises First = SharePoint Hibridi
Cloud First, On-Premises First = SharePoint HibridiCloud First, On-Premises First = SharePoint Hibridi
Cloud First, On-Premises First = SharePoint Hibridi
SysKit Ltd
 
MedPacs
MedPacsMedPacs
MedPacs
Medotrade
 
2013 medical mission1
2013 medical mission12013 medical mission1
2013 medical mission1Lily Hung
 
Itlm topic 4
Itlm topic 4Itlm topic 4
Itlm topic 4
m_rinaldi
 
Benarkahpksprorakyat testimoniiniditulisolehseorangmantankaderpksdariuibernam...
Benarkahpksprorakyat testimoniiniditulisolehseorangmantankaderpksdariuibernam...Benarkahpksprorakyat testimoniiniditulisolehseorangmantankaderpksdariuibernam...
Benarkahpksprorakyat testimoniiniditulisolehseorangmantankaderpksdariuibernam...Denny Wahyudi
 

Andere mochten auch (15)

Подсистема Статистика, МИС Пациент
Подсистема Статистика, МИС ПациентПодсистема Статистика, МИС Пациент
Подсистема Статистика, МИС Пациент
 
Каталог книжной выставки "Зеленая волна" 2013
Каталог книжной выставки "Зеленая волна" 2013Каталог книжной выставки "Зеленая волна" 2013
Каталог книжной выставки "Зеленая волна" 2013
 
Van social media naar social business - Workshop CommunicatieBreak 2014
Van social media naar social business - Workshop CommunicatieBreak 2014Van social media naar social business - Workshop CommunicatieBreak 2014
Van social media naar social business - Workshop CommunicatieBreak 2014
 
Ekonomika
EkonomikaEkonomika
Ekonomika
 
User activity monitoring with SysKit
User activity monitoring with SysKitUser activity monitoring with SysKit
User activity monitoring with SysKit
 
20082454 taekkyun nam television
20082454 taekkyun nam television20082454 taekkyun nam television
20082454 taekkyun nam television
 
Oracle notes
Oracle notesOracle notes
Oracle notes
 
Analysis of the music video
Analysis of the music videoAnalysis of the music video
Analysis of the music video
 
Media Pembelajaran Biologi Kelas X
Media Pembelajaran Biologi Kelas XMedia Pembelajaran Biologi Kelas X
Media Pembelajaran Biologi Kelas X
 
Local Nexus Network at Birmingham Business School 19th April 2016
Local Nexus Network at Birmingham Business School 19th April 2016Local Nexus Network at Birmingham Business School 19th April 2016
Local Nexus Network at Birmingham Business School 19th April 2016
 
Cloud First, On-Premises First = SharePoint Hibridi
Cloud First, On-Premises First = SharePoint HibridiCloud First, On-Premises First = SharePoint Hibridi
Cloud First, On-Premises First = SharePoint Hibridi
 
MedPacs
MedPacsMedPacs
MedPacs
 
2013 medical mission1
2013 medical mission12013 medical mission1
2013 medical mission1
 
Itlm topic 4
Itlm topic 4Itlm topic 4
Itlm topic 4
 
Benarkahpksprorakyat testimoniiniditulisolehseorangmantankaderpksdariuibernam...
Benarkahpksprorakyat testimoniiniditulisolehseorangmantankaderpksdariuibernam...Benarkahpksprorakyat testimoniiniditulisolehseorangmantankaderpksdariuibernam...
Benarkahpksprorakyat testimoniiniditulisolehseorangmantankaderpksdariuibernam...
 

Ähnlich wie BCBS 239 - Data Vault hilft

Audit des BCM
Audit des BCMAudit des BCM
Audit des BCM
haemmerle-consulting
 
kes BCM in der Supply Chain
kes BCM in der Supply Chainkes BCM in der Supply Chain
kes BCM in der Supply Chain
haemmerle-consulting
 
Vorschau der PPI-Studie "Regulatorischer Stauatlas 2017"
Vorschau der PPI-Studie "Regulatorischer Stauatlas 2017"Vorschau der PPI-Studie "Regulatorischer Stauatlas 2017"
Vorschau der PPI-Studie "Regulatorischer Stauatlas 2017"
PPI AG
 
Revidiertes Geldwaeschereigesetz
Revidiertes GeldwaeschereigesetzRevidiertes Geldwaeschereigesetz
Revidiertes Geldwaeschereigesetz
TALOSCommunications
 
Compliance Organisation Health Check
Compliance Organisation Health CheckCompliance Organisation Health Check
Compliance Organisation Health Check
TALOSCommunications
 
Eine erste Bewertung makroprudenzieller Instrumente in der Immobilienfinanzie...
Eine erste Bewertung makroprudenzieller Instrumente in der Immobilienfinanzie...Eine erste Bewertung makroprudenzieller Instrumente in der Immobilienfinanzie...
Eine erste Bewertung makroprudenzieller Instrumente in der Immobilienfinanzie...
I W
 
Risiko- und wertorientierte Banksteuerung
Risiko- und wertorientierte BanksteuerungRisiko- und wertorientierte Banksteuerung
Risiko- und wertorientierte Banksteuerung
Torben Haagh
 
Pressegespräch Single Supervisory Mechanism
Pressegespräch Single Supervisory MechanismPressegespräch Single Supervisory Mechanism
Pressegespräch Single Supervisory Mechanism
Bankenverband
 
LCR Portfoliooptimierung
LCR PortfoliooptimierungLCR Portfoliooptimierung
LCR Portfoliooptimierung
Peter Bichl
 
Teilnehmerumfrage der Handelsblatt Jahrestagung Betriebliche Altersversorgung...
Teilnehmerumfrage der Handelsblatt Jahrestagung Betriebliche Altersversorgung...Teilnehmerumfrage der Handelsblatt Jahrestagung Betriebliche Altersversorgung...
Teilnehmerumfrage der Handelsblatt Jahrestagung Betriebliche Altersversorgung...
Astrid Mestrovic
 
Selbstberatungslösungen für Banken und Finanzdienstleister
Selbstberatungslösungen für Banken und FinanzdienstleisterSelbstberatungslösungen für Banken und Finanzdienstleister
Selbstberatungslösungen für Banken und Finanzdienstleister
WG-DATA GmbH
 
Solvency II: Kombiniertes Rechenmodell erfüllt EU-Pflichten und ermöglicht in...
Solvency II: Kombiniertes Rechenmodell erfüllt EU-Pflichten und ermöglicht in...Solvency II: Kombiniertes Rechenmodell erfüllt EU-Pflichten und ermöglicht in...
Solvency II: Kombiniertes Rechenmodell erfüllt EU-Pflichten und ermöglicht in...
metafinanz Informationssysteme GmbH
 
Whitepaper Banking
Whitepaper BankingWhitepaper Banking
Whitepaper Banking
Hays
 
Studie: Maastricht 2.0 Eine neue Finanzregel für Europa
Studie: Maastricht 2.0 Eine neue Finanzregel für EuropaStudie: Maastricht 2.0 Eine neue Finanzregel für Europa
Studie: Maastricht 2.0 Eine neue Finanzregel für Europa
GED Project - Global Economic Dynamics
 
Risikomanagement in Versicherungsunternehmen - MaRisk VA, Risikokategorien un...
Risikomanagement in Versicherungsunternehmen - MaRisk VA, Risikokategorien un...Risikomanagement in Versicherungsunternehmen - MaRisk VA, Risikokategorien un...
Risikomanagement in Versicherungsunternehmen - MaRisk VA, Risikokategorien un...
metafinanz Informationssysteme GmbH
 
Navigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias LeisiNavigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias LeisiMatthias Leisi
 
Verbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für MedizinprodukteVerbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für Medizinprodukte
Denis Werner
 
Studie: Exzellenz im Zahlungsverkehr
Studie: Exzellenz im ZahlungsverkehrStudie: Exzellenz im Zahlungsverkehr
Studie: Exzellenz im Zahlungsverkehr
PPI AG
 
Ita Oktober 09 Automotive It
Ita Oktober 09 Automotive ItIta Oktober 09 Automotive It
Ita Oktober 09 Automotive It
brox IT Solutions GmbH
 
Modul 22 - Frühwarnsystem.pptx
Modul 22 - Frühwarnsystem.pptxModul 22 - Frühwarnsystem.pptx
Modul 22 - Frühwarnsystem.pptx
caniceconsulting
 

Ähnlich wie BCBS 239 - Data Vault hilft (20)

Audit des BCM
Audit des BCMAudit des BCM
Audit des BCM
 
kes BCM in der Supply Chain
kes BCM in der Supply Chainkes BCM in der Supply Chain
kes BCM in der Supply Chain
 
Vorschau der PPI-Studie "Regulatorischer Stauatlas 2017"
Vorschau der PPI-Studie "Regulatorischer Stauatlas 2017"Vorschau der PPI-Studie "Regulatorischer Stauatlas 2017"
Vorschau der PPI-Studie "Regulatorischer Stauatlas 2017"
 
Revidiertes Geldwaeschereigesetz
Revidiertes GeldwaeschereigesetzRevidiertes Geldwaeschereigesetz
Revidiertes Geldwaeschereigesetz
 
Compliance Organisation Health Check
Compliance Organisation Health CheckCompliance Organisation Health Check
Compliance Organisation Health Check
 
Eine erste Bewertung makroprudenzieller Instrumente in der Immobilienfinanzie...
Eine erste Bewertung makroprudenzieller Instrumente in der Immobilienfinanzie...Eine erste Bewertung makroprudenzieller Instrumente in der Immobilienfinanzie...
Eine erste Bewertung makroprudenzieller Instrumente in der Immobilienfinanzie...
 
Risiko- und wertorientierte Banksteuerung
Risiko- und wertorientierte BanksteuerungRisiko- und wertorientierte Banksteuerung
Risiko- und wertorientierte Banksteuerung
 
Pressegespräch Single Supervisory Mechanism
Pressegespräch Single Supervisory MechanismPressegespräch Single Supervisory Mechanism
Pressegespräch Single Supervisory Mechanism
 
LCR Portfoliooptimierung
LCR PortfoliooptimierungLCR Portfoliooptimierung
LCR Portfoliooptimierung
 
Teilnehmerumfrage der Handelsblatt Jahrestagung Betriebliche Altersversorgung...
Teilnehmerumfrage der Handelsblatt Jahrestagung Betriebliche Altersversorgung...Teilnehmerumfrage der Handelsblatt Jahrestagung Betriebliche Altersversorgung...
Teilnehmerumfrage der Handelsblatt Jahrestagung Betriebliche Altersversorgung...
 
Selbstberatungslösungen für Banken und Finanzdienstleister
Selbstberatungslösungen für Banken und FinanzdienstleisterSelbstberatungslösungen für Banken und Finanzdienstleister
Selbstberatungslösungen für Banken und Finanzdienstleister
 
Solvency II: Kombiniertes Rechenmodell erfüllt EU-Pflichten und ermöglicht in...
Solvency II: Kombiniertes Rechenmodell erfüllt EU-Pflichten und ermöglicht in...Solvency II: Kombiniertes Rechenmodell erfüllt EU-Pflichten und ermöglicht in...
Solvency II: Kombiniertes Rechenmodell erfüllt EU-Pflichten und ermöglicht in...
 
Whitepaper Banking
Whitepaper BankingWhitepaper Banking
Whitepaper Banking
 
Studie: Maastricht 2.0 Eine neue Finanzregel für Europa
Studie: Maastricht 2.0 Eine neue Finanzregel für EuropaStudie: Maastricht 2.0 Eine neue Finanzregel für Europa
Studie: Maastricht 2.0 Eine neue Finanzregel für Europa
 
Risikomanagement in Versicherungsunternehmen - MaRisk VA, Risikokategorien un...
Risikomanagement in Versicherungsunternehmen - MaRisk VA, Risikokategorien un...Risikomanagement in Versicherungsunternehmen - MaRisk VA, Risikokategorien un...
Risikomanagement in Versicherungsunternehmen - MaRisk VA, Risikokategorien un...
 
Navigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias LeisiNavigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
 
Verbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für MedizinprodukteVerbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für Medizinprodukte
 
Studie: Exzellenz im Zahlungsverkehr
Studie: Exzellenz im ZahlungsverkehrStudie: Exzellenz im Zahlungsverkehr
Studie: Exzellenz im Zahlungsverkehr
 
Ita Oktober 09 Automotive It
Ita Oktober 09 Automotive ItIta Oktober 09 Automotive It
Ita Oktober 09 Automotive It
 
Modul 22 - Frühwarnsystem.pptx
Modul 22 - Frühwarnsystem.pptxModul 22 - Frühwarnsystem.pptx
Modul 22 - Frühwarnsystem.pptx
 

Mehr von Torsten Glunde

#PinkDB DataVault
#PinkDB DataVault#PinkDB DataVault
#PinkDB DataVault
Torsten Glunde
 
Conceptional Data Vault
Conceptional Data VaultConceptional Data Vault
Conceptional Data Vault
Torsten Glunde
 
Raus aus dem Data Vault - Virtualisierung und Logical Warheouse
Raus aus dem Data Vault - Virtualisierung und Logical WarheouseRaus aus dem Data Vault - Virtualisierung und Logical Warheouse
Raus aus dem Data Vault - Virtualisierung und Logical Warheouse
Torsten Glunde
 
Data Virtualization - Supernova
Data Virtualization - SupernovaData Virtualization - Supernova
Data Virtualization - Supernova
Torsten Glunde
 
Data Quadrant - Daten Management Methode
Data Quadrant - Daten Management MethodeData Quadrant - Daten Management Methode
Data Quadrant - Daten Management Methode
Torsten Glunde
 
OpenDMA - Daten Management Solution
OpenDMA  - Daten Management SolutionOpenDMA  - Daten Management Solution
OpenDMA - Daten Management Solution
Torsten Glunde
 
Data Vault Architektur
Data Vault ArchitekturData Vault Architektur
Data Vault Architektur
Torsten Glunde
 
Data Vault Vor- und Nachteile
Data Vault Vor- und NachteileData Vault Vor- und Nachteile
Data Vault Vor- und Nachteile
Torsten Glunde
 
Data Vault DWH Automation
Data Vault DWH AutomationData Vault DWH Automation
Data Vault DWH Automation
Torsten Glunde
 
Dv 20 sdlc_oss_automation
Dv 20 sdlc_oss_automationDv 20 sdlc_oss_automation
Dv 20 sdlc_oss_automation
Torsten Glunde
 

Mehr von Torsten Glunde (10)

#PinkDB DataVault
#PinkDB DataVault#PinkDB DataVault
#PinkDB DataVault
 
Conceptional Data Vault
Conceptional Data VaultConceptional Data Vault
Conceptional Data Vault
 
Raus aus dem Data Vault - Virtualisierung und Logical Warheouse
Raus aus dem Data Vault - Virtualisierung und Logical WarheouseRaus aus dem Data Vault - Virtualisierung und Logical Warheouse
Raus aus dem Data Vault - Virtualisierung und Logical Warheouse
 
Data Virtualization - Supernova
Data Virtualization - SupernovaData Virtualization - Supernova
Data Virtualization - Supernova
 
Data Quadrant - Daten Management Methode
Data Quadrant - Daten Management MethodeData Quadrant - Daten Management Methode
Data Quadrant - Daten Management Methode
 
OpenDMA - Daten Management Solution
OpenDMA  - Daten Management SolutionOpenDMA  - Daten Management Solution
OpenDMA - Daten Management Solution
 
Data Vault Architektur
Data Vault ArchitekturData Vault Architektur
Data Vault Architektur
 
Data Vault Vor- und Nachteile
Data Vault Vor- und NachteileData Vault Vor- und Nachteile
Data Vault Vor- und Nachteile
 
Data Vault DWH Automation
Data Vault DWH AutomationData Vault DWH Automation
Data Vault DWH Automation
 
Dv 20 sdlc_oss_automation
Dv 20 sdlc_oss_automationDv 20 sdlc_oss_automation
Dv 20 sdlc_oss_automation
 

BCBS 239 - Data Vault hilft

  • 1. Finanzrechtliche Aufsichtsregeln für die Risikosteuerung in Finanzinstituten Wie kann Data Vault bei der Modernisierung der Risikosteuerung in Banken helfen? Die Folgen der Finanzmarkt- und Staatsschuldenkrise sind teuer, vor allem für uns Steuerzahler. Die Regulierungsbehörden in Europa und Deutschland versuchen jetzt die Steuerbarkeit der Finanzinstitute zu gewährleisten und eine Wiederholung der Krise zu verhindern. Die Regulatoren von BCBS 239 (einer Vorschrift vom „Basel Comittee on Banking Supervision“ kurz BCBS) schätzen für die Umsetzung dieser Maßnahme einen mittleren, zweistelligen Millionenbetrag pro Institut insgesamt und in Einzelfällen einen dreistelligen Millionenbetrag an Investitionen. Anhand der Handlungsbedarfe, die sich aus BCBS 239 ergeben erläutere ich wie die Data Vault Methodik bei der Realisierung helfen kann. Die Vorgaben der internationalen Aufsichtsbehörden, Finanzgremien und –organisationen verstecken sich hinter Begriffen wie MaRisk, IFRS 9-13, FinRep, CoRep usw. Gemeinsam ist ihnen heutzutage vor allem das Ziel das Risikomanagement, die Rechnungslegung und die Finanzmarktprodukte im Bankensystem so zu regulieren und wieder steuerbar zu machen, dass sich eine Finanzmarktkrise nicht mehr wiederholen kann. Abbildung 1 Regulierungsbehörden International und National gemäß (Quelle 3) Über den Sinn oder die Fähigkeit dieser Maßnahmen dieses Ziel tatsächlich zu erreichen lässt sich streiten, aber darum soll es in diesem Artikel nicht gehen. Vielmehr soll es darum gehen, welche konkreten Realisierungsmaßnahmen beispielhaft hinter BCBS 239 – einer weiteren Regulierung in diesem Zuge – vor den Finanzinstitutionen stehen und inwiefern die Data Vault Methode dabei helfen kann diese zu implementieren. Bei der Aufarbeitung und Analyse der Ursachen für die Finanzmarktkrise sind wir bestimmt noch nicht und werden vielleicht auch nie am Ende ankommen. Dafür ist es auch ein zu komplexes Gebilde mit vielen Einflussfaktoren und viel Politik. Allgemein anerkannt ist die Erkenntnis dass es auch um ein Regulierungsversagen ging und effiziente Frühwarnsysteme basierend auf einem standardisierten und umfassenden Risikomanagement in den Instituten eine solche Krise verhindern könnten, wenn dies die Qualität der analytischen Datengrundlage in den Finanzinstitutionen hergäbe. Diese Qualität wiederum hängt von Datenmanagement Prozessen und der Infrastruktur innerhalb dieser Institutionen ab. Risikodaten existierten häufig lediglich in Silos in Geschäften und Funktionen und sind dann weder übergreifend, noch granular nachvollziehbar. Verkürzt könnte man also sagen, dass Banken es nicht geschafft haben valide Risikodaten in angemessener Zeit so zu aggregieren und auszuwerten, dass Risiken wie die Immobilienblase, undurchsichtige Finanzprodukte und die allgemeine Marktlage tatsächlich steuerbar gewesen wären – die Risiken wurden nicht quantifiziert und standen somit auch weder im Fokus der Entscheider noch in dem der Kontrolleure. Institutionen haben zudem nicht mehr die Möglichkeit ihre Probleme mit dem Datenmanagement in intensiven und langen Projekten zu verifizieren - auch hier wird der Druck nach schneller Reaktionszeit höher – nicht nur für die Befriedigung der Regulatoren, sondern auch beim Erfüllen von Anforderungen für das Management. Abbildung 2 BCBCS 239 Themenbereiche und Prinzipien (Quelle 3) Die BCBS 239 im Detail Um das Risikomanagement, Datenmanagement und erstmalig auch ganz konkret um die IT der Banken geht es in der BCBS
  • 2. 239, einer Vorgabe der Bank of International Settlements (www.bis.org) und seinem „Basel Commitee on Banking Supervision“. Es werden 14 Grundsätze formuliert, die konkrete Einzelforderungen zu vier Themenbereichen beinhalten. Die Grundsätze regeln Prozesse und Daten zur Bankensteuerung und Risikotragfähigkeit. Außerdem im Fokus steht die ad-hoc Fähigkeit in Stresssituationen Ergebnisse automatisiert liefern zu können. Es sollen auch Szenarien und Simulationsrechnungen ermöglicht werden. Beispielhaft sind dies: • Governance und Infrastruktur o Vollständige Dokumentation der Datenaggregation auf granularem Level o Einheitliche Taxonomien und zentrales Metadatenmanagement o Transparenz zu Lebenszyklus von Daten – konsistenter Business und IT View • Aggregation von Risikodaten o Vollständige Dokumentation der technischen und organisatorischen Prozesse rund um die Erstellung des Risikoberichtes. o Technische und organisatorische Prozesse rund um die Erzeugung des Risikoberichtes müssen dokumentiert sein • Risikoreporting o Glossar mit Risikobegriffen – Verlinkung in Risikoreports Die Anforderungen sind im Detail vielschichtig und komplex, weil eine solche Konsolidierung von Risikokennzahlen auf granularer Ebene bisher noch nicht im Fokus der Banken stand und auf dieser Ebene diverse Quellsystem wie Kredite, Liquidität, Marktdaten, Immobilien integriert sein müssen, um dann auch die notwendigen Metadaten für die Nachvollziehbarkeit der aggregierten Risikodaten anbieten zu können. Hinzukommt dass die Zeit zur Umsetzung verhältnismäßig knapp bemessen wurde. Nachdruck wurde dieser Regelung dadurch verliehen, dass die Geschäftsleitung selbst für die Umsetzungsverantwortung eingeteilt worden ist. Handlungsbedarfe Somit ergeben sich sehr konkrete Handlungsbedarfe für die Organisation und den Ablauf der Risikofunktionen und die IT- Architektur bzw. das Datenmanagement: • Automatisierung der Reportauslieferung und Ad-hoc Auswertungen • Flexible Anpassungen regulatorischer Änderungen • Integrierte Datenhaltung (Insbesondere Risiko- und Finanzdaten), einheitliches Datenmodell • Schnellere Bereitstellung (Reporterstellung innerhalb von 10 Tagen nach Stichtag – zuvor waren es 56) • Fokus auf Kreditrisiko, Kontrahentenrisiko, Handelsrisiken, Marktrisiken, Liquiditätsrisiken und Operationelle Risiken • Eine einheitliche technologische Plattformen und IT- Anwendungen • Deutliche Reduzierung von Medienbrüchen und Integration von Insellösungen • Einführung von modernen und effektiven Systemen und Verfahren zur Datenverarbeitung und -analyse • Verankerung der Gesamtlösung in das Governance- Framework Es wird seitens der Regulierer von Investitionskosten in der Größenordnung von dreistelliger Millionenhöhe ausgegangen – zumindest bei den großen, systemrelevanten Banken (G- SIBs). Abbildung 3 Bis wann muss BCBS 239 umgesetzt werden? (Quelle 3) Die Regelung wird bis 2016 bereits für die sogenannten G-SIBs verpflichtend und somit bereits in der Realisierung, allerdings gibt es anschließend noch die weiteren Institute, die national systemrelevant eingestuft (D-SIB) und nach und nach benannt werden. Diese Institute haben für die Umsetzung 3 Jahre Zeit nach ihrer Benennung; alle anderen Institute haben keine zwingende Bindung an die Regelung, allerdings kommt BCBS 239 auch zur Aufnahme in den MaRisk Standard. Letzten Endes bedeutet dies also dass BCBS 239 die Institute noch einige Zeit beschäftigen wird, sofern das Thema nicht bereits schon angegangen wurde. Sind Banken gut vorbereitet? Interessant ist in diesem Zusammenhang auch eine Umfrage, die msgGillardon im IT-Finanzmagazin veröffentlichte (siehe Quelle 4). Abbildung 4 Integrationsgrad von Finanz-, Risiko- und Treasury- Daten gemäß Quelle 4
  • 3. Demnach sind viele deutsche Institute gerade was die geforderten Bereiche von BCBS 239 angeht nicht gut aufgestellt. 29% der Banken seien ohne Daten- und Prozessverantwortlichkeiten, 45% der Banken haben keine durchgängige Messung der Datenqualität. Unter Sparkassen haben 61% noch Nachholbedarf und 20% der Institute korrigieren ihre zu Grunde liegenden Daten nicht regelmäßig. Außerdem schneiden die Institute schlecht bei der Governance ab, wo nur 13% der Befragten unterhalb der 2. Hierarchiestufe Wissen zu Datenqualitätsprozessen hatten. Beim Thema Datenintegration gibt die Studie vom Faktenkontor (Abb. 4) Auskunft darüber, dass Risiko- und Finanzdaten nur in 50% der Institute integriert vorliegen. Weiter wird zitiert, dass Metadatenverwaltung in 27% der Fälle existiert und bei 56% der Banken nur unvollständige Metadaten im Datamart aufweisen. Traditioneller DWH Ansatz in Finanzinstituten Häufig wird bisher versucht in Ladeprogrammen im Data Warehouse eine Kombination vieler Anliegen in einem Schritt zu erledigen. So müssen im klassischen Data Warehouse das 3NF-Modell erzeugt, Daten bereinigt und die technische Historisierung und Harmonisierung berücksichtigt werden. Die daraus resultierenden ETL-Mappings werden zu komplex und sorgen für Inflexibilität bei Änderungen. Das weitere Problem bei diesem Ansatz ist die Veränderung der Quelldaten vor Aufnahme in das Data Warehouse, so dass unter Umständen die Nachvollziehbarkeit der Daten und die Rückverfolgung in das Quellsystem gar nicht mehr möglich ist. Hinzu kommt, dass gerade DWHs in finanziellen Institutionen starken Änderungen und Schwankungen in den Geschäftsregeln unterliegen. Die Komplexität in Berechnungsmethoden und die Anforderungen in den verschiedenen Geschäftsbereichen machen einen monolithischen, zentralistischen DWH-Ansatz problematisch: • Fokus auf Datenakquisition und Bereinigung der Quelldaten auf dem Weg in das DWH o ETL als manueller Aufwandstreiber o „Enterprise Data Model“, EDM (unternehmensweites Datenmodell) mit zu großem Scope und 3NF-Modellierung, Quellsystem sind häufig fragmentiert und überlappend, was zu Schwierigkeiten bei der Integration nach EDM führt • Analytische Prozesse außerhalb des DWH o DWH Ersteller und Nutzer driften zu weit auseinander o Datenflüsse umgehen das DWH o Unternehmensübergreifende Sichten über mehrere Risikogruppen wird unmöglich • Data Mart Silos mit Logik, die ins Data Warehouse gehört Durch solch eine Situation kommt es bei diesen DWH- Ansätzen häufig zu einem Veränderungsstau nach einigen Jahren, weil das Umsetzen neuer Anforderungen durch die laufend gestiegene Komplexität des ETL immer teurer werden. Konzepte zur Datenqualität und Metadaten werden dann gerne auch unter dem Druck der ständig eintreffenden Fachbereichsanforderungen immer weiter nach hinten verschoben. Data Vault Architektur im Einsatz Vor diesem Hintergrund kann es Sinn machen die anstehenden Aufgaben und Herausforderungen durch BCBS 239 ernst zu nehmen und die bestehende Data Warehouse Lösung durch eine neue, moderne Architektur und Methodik zu ergänzen oder ersetzen. Zusätzlich zur Data Vault Architektur möchte ich noch das Quadrantenmodell von Ronald Damhoff (Abb. 5) vorstellen, da es sich hervorragend dazu eignet eine Data Vault Architektur abseits von Technik zu vermitteln. Es verwendet eine Analogie aus der Wirtschaft: Datenaufbereitung im DWH wird mit einem Lieferprozess verglichen. Unterschieden wird, ob das Produkt (die Daten) vom Kunden spezifiziert sind oder seitens der IT auf Lager produziert wird. Die horizontale Unterscheidung spielt für unsere Betrachtung nur eine sekundäre Rolle. In Q1 wird also zu möglichst niedrigen Stückkosten produziert, um die Läger zu füllen. Das bedeutet wir haben einfache Fertigungsprozesse und einen hohen Automationsgrad. Im Q2 allerdings bestimmt der Kunde (den Kontext) und damit wie das Produkt aussehen soll. Im Ergebnis bedeutet dies also einen manuellen DM Strategie „Data Quadranten Modell“ von Ronald Damhof Quadrant 1: „Single Version of Facts“, automatisierte Bereitstellung „Simple/Order“ Quadrant 2: Kontextinformation, „Complicated/Order“ Quadrant 4: „Complex/Un-order“ Quadrant 3: Chaos Quadrant 2 und Quadrant 4: „Multiple Versions of the Truth“ http://prudenza.typepad.com/dwh/2015/05/data-quadrant-model-decreasing-entropy.html Abbildung 5 Data Deployment Quadrant von Ronald Damhoff gemäß Quelle 2
  • 4. Fertigungsprozess zu höheren Stückkosten, aber dafür mit individuell angepassten Produkten. Im Q1 sind unsere Standardprodukte die nach übergreifenden Business Keys integrierten Quelldaten, die gemäß der Data Vault Modellierung und den zugehörigen Lademustern voll automatisiert und historisiert geladen werden können. Im Q2 allerdings gibt es unterschiedliche Abnehmer und Szenarien, die dafür sorgen dass wir Kontext vom Kunden berücksichtigen und Geschäftsregeln implementieren müssen, um die Daten so anzupassen, wie der Kunde diese auch verwerten möchte. Abbildung 6 Datenmodellierung und Datenfluss im Data Vault DWH Dies beschreibt dann auch schon sehr gut das Prinzip des „Separation of Concerns“ bei der Datenaufbereitung im Data Warehouse. Die Ladeprozesse im Raw Vault sind so trivial, dass sie anhand der physischen Datenmodelle von Stage und Raw Data Vault und einem einfachen 1:1 Mapping generiert werden können, ohne dass hier manuelle Programmierung zu tätigen ist – dank der Lademuster zu Hub, Link und Satellit. Außerdem sind die Daten bereits nach der technischen Sicht des Data Warehouse historisiert, so dass häufig für Anforderungen ohne weitere Timelines in späteren Ladeprozessen nichts mehr hinzugefügt werden muss. Der zweite, wichtige Aspekt dieser Vorgehensweise im Raw Vault ist die vollständige Nachvollziehbarkeit der Daten zurück in die Quelle, weil alle Attribute 1:1 abgebildet sind und granulare Daten geladen werden. In diesem ersten Schritt werden aber nicht nur Quelltabellen kopiert, sondern es findet auch eine Integration nach Business Keys statt. Hierüber wird gewährleistet, dass sich wiederholende Entitäten der Quellsysteme im Data Warehouse in identische Strukturen geladen werden (Integration über die Hubs). Somit folgt der Data Vault auch einem logischen oder konzeptionellen Unternehmensmodell, bleibt dabei aber aufgrund der physischen Trennung von fachspezifischen Attributen und Relationen flexibler als die 3NF-Modellierung. Diese flexiblere Ausgestaltung der Tabellenstrukturen ermöglicht dabei auch die iterative – also die anforderungsgetriebene Vorgehensweise. Analyseprozesse, die bereits auf bestehende Tabellenstrukturen zugreifen werden für neue Anforderungen nicht in Mitleidenschaft gezogen, da neue oder geänderte fachliche Relationen und Attribute keine Veränderungen mehr in der Tabellenstruktur der Datenbank nach sich ziehen. (Non-Destructive Data Model). Somit sollte auch das Problem von komplexen, überlappenden Quellsystemen in den Griff zu bekommen sein. Zusätzlich soll hier auch noch erwähnt werden, dass einige Datenmodellierungswerkzeuge das Mapping von Datenelementen beherrschen, so dass in den Situationen, wo Datenmodelle transformiert werden tatsächlich anhand der Metadaten vom Modellierungswerkzeug Ladeprozesse generiert werden können, ohne die Notwendigkeit das Modellierungswerkzeug zu verlassen (siehe Abb. 5). Im nächsten Schritt werden im Business Vault ebenfalls wieder Datenelemente per Mapping umgeschrieben – diesmal von DataVault nach DataVault – aber unter Anwendung von Geschäftsregeln. Hier werden dann die tatsächlichen Berechnungen ausgeführt, die zum Risikomanagement gehören und manuellen Aufwand in einem ETL-Werkzeug verlangen. Die komplexen fachlichen Regeln der Anwender werden hier in den unterschiedlichen Sichten implementiert und bedeuten Datenaufbereitung, Zeitsichten, BI-temporale Sichten, Point-In-Time und Bridge Tabellen für dimensionale Sichten und vieles mehr. Hier konzentriert sich die fachliche Arbeit der Beteiligten. Entsprechend sind wir dann auf die Möglichkeiten des ETL- Werkzeuges oder des zugehörigen Metadatenservers zur Nachvollziehbarkeit der Daten angewiesen. Der letzte Schritt ist dann wieder eine Modelltransformation vom Data Vault Modell des Business Vault in ein dimensionales Modell oder andere Berichtsstrukturen, auf denen das BI Frontend aufsetzt. Wenn man sich diesen Prozess anhand der Grafik und der Datenmodellierung vorstellt, wird denke ich klar, dass auch eine Annäherung von Fachbereichen und IT-Personal erreicht werden kann. Die Quellsystemintegration rückt durch die Automatisierung komplett in den Hintergrund und an dessen Stelle rücken die Datenmodellierung und die Geschäftsregeln. Als gemeinsame Kommunikationsgrundlage sollte die konzeptionelle oder logische Ebene des Datenmodells dienen. Gleichermaßen steuert auch die Automatisierung zur Kommunikationsförderung bei. Denn durch die schnelle Bereitstellung der Daten können Feedbackschleifen mit Fachanwendern sehr schnell erfolgen. Hierzu können zum Beispiel auch sogenannte virtualisierte Marts erstellt werden, die ein Star Schema mit SQL-Views abbilden. Diese temporären Sichten dienen dann als Grundlage für Gespräche bei denen man bereits konkrete Fälle basierend auf integrierten Daten durchspielen kann, anstatt auf das Vorstellungsvermögen der Beteiligten alleine angewiesen zu sein. Metadaten und Datenqualität Um nun die vollständige Dokumentation zu erreichen, die gemäß BCBS 239 gefordert ist, bedarf es mehr als der Datenmodelle und der Geschäftsregeln in ETL Mappings des Business Vaults. Einige Metadatenserver auf dem Markt können die BI Frontendmodelle, Datenmodelle, Glossary und andere fachliche Beschreibungen importieren. Anschließend lassen sich Verbindungen zwischen diesen Elementen herstellen und somit fachliche und technische Metadaten gemeinsam darstellen. Das bedeutet dann manuellen Aufwand, kann aber ausreichen, um die Anforderungen von BCBS 239 zu erfüllen. Hier stellt sich dann wieder die Frage nach der Governance und den entsprechenden prozessualen Vorgaben zur Umsetzung dieser Maßnahmen.
  • 5. Durch die „Single Version of Facts“ im Raw Vault können Datenprobleme der Quellsysteme nachvollzogen und überprüft werden. Die Entscheidung im Data Warehouse zunächst alle Daten ohne Harmonisierung oder Bereinigungen zu laden ermöglicht die GAP-Analyse. Hier kann auch eine historische Entwicklung der Datenqualität dargestellt werden, weil im Raw Vault historisiert wird. Dies setzt natürlich immer voraus, dass die Datenqualitätsprobleme in den Quellsystemen auch behoben worden sind und nicht nur entsprechende Geschäftsregeln im DWH implementiert sind. Die klare Empfehlung kann daher nur sein die Korrektur von Datenqualitätsproblemen und auch die Erzeugung von Stammdaten – also MDM – außerhalb des DWH zu realisieren. Der Raw Vault ist als historisierte „System of Record“ der Quellsysteme als Quelle für diese Art von Vorhaben geeignet – nicht aber als Ziel. Im Idealfall werden korrigierte Quelldaten aus dem MDM oder direkt aus der Quelle zurück in das DWH geladen, was dann auch die Grundlage für die zuvor erwähnte Darstellung der (hoffentlich) positiven Entwicklung der Datenqualität ist. Fazit Zum Schluss kann man sagen, dass vor allem die Automatisierung und die anforderungsgetriebene Ausrichtung von Data Vault die Einstiegsbarrieren für diese Methodik recht niedrig aufhängen. Schließlich ist es sogar empfohlen klein zu starten und dann iterativ vor zu gehen. Auch eine parallele und schrittweise Einführung zum bestehenden System ist möglich. Natürlich gibt es auch eine Anfangsinvestition für die Ausbildung, Etablierung der Methoden in der Infrastruktur und eventuell auch neue Werkzeuge. Erfahrungsgemäß können durch den Einsatz von Automatisierung im Data Vault Umfeld die Entwicklungsaufwände der ETL-Strecken im Core Warehouse auf 1/4 sinken – verglichen mit der manuellen Erstellung der gleichen Mappings im Werkzeug. Da kann man von einer schnellen Amortisation ausgehen. Angesichts der weiteren Regulierungsrunden, die noch erwartet werden, ist es nicht zuletzt auch eine sinnvolle Investition die Anpassungsfähigkeit des Data Warehouse zu erhöhen und somit die Kosten dauerhaft zu senken, das erreicht man sicher durch dieses, agile Vorgehen. In Bezug auf die Anforderungen für BCBS 239 erfüllt Data Vault die Anforderungen zur Integration der Daten mittels eines einheitlichen Datenmodells und auch die Forderungen zur Nachvollziehbarkeit der Zahlen in den Quellsystemen. Die Datenqualität kann im Raw Vault gemessen werden und entsprechend eine GAP-Analyse durchgeführt werden. Bei den Anforderungen zur Data Lineage und Metadaten hilft Data Vault durch die Fokussierung auf die Datenmodellierung, die maßgeblich wird für die Erstellung von Beladungsstrecken und somit auch zu einer Standardisierung in diesem Bereich führt. Es gibt am Markt eine gute Unterstützung für diese Werkzeuge. Die Anforderung zur Performance ist kaum zu bewerten. Aufgrund der Vereinfachung und Aufteilung der Prozesskette (Raw Vault und Business Vault) und der Tatsache dass nur die Geschäftsregeln und nicht die Basisdaten neu berechnet werden müssen, ist aber alleine dadurch von einer Performanceverbesserung auszugehen. Ein wesentlicher Erfolgsfaktor ist aus meiner Sicht die Förderung der Kommunikation zwischen den Beteiligten, denn Projekterfahrung zeigt doch immer wieder dass die Menschen das Wichtigste im Projekt sind. Die Kommunikation kann mittels des Quadrantenmodells auch über die reinen Data Vault Interessenten hinaus bis ins Management genutzt werden. Die (Re-)Fokussierung aller Beteiligten auf fachliche Inhalte und die Geschäftsregeln wird sich mehrfach auszahlen. Literatur (1) Linstedt D., Olschimke M. „Building a Scalable Data Warehouse With Data Vault 2.0“ (2) Damhoff R., Data Quadrant Model, http://prudenza.typepad.com/dwh/2015/05/data-quadrant-model- decreasing-entropy.html (3) Bachinger S., Arnsberg T., TME-AG „Whitepaper Modernisierung der Risikosteuerung in Banken“, http://www.tme-ag.de/fileadmin/customer/documents/Whitepaper_- _Modernisierung_der_Risikosteuerung_in_Banken.pdf (4) Prellwith C., Nicklas M., msGiilardon, „BCBS 239 macht effizient, transparent & krisenfest“ http://www.it- finanzmagazin.de/bcbs-239-macht-effizient-transparent-krisenfest-9566/ Torsten Glunde ist Mitgründer und CEO der Alligator Company GmbH in Bremen und als Business Intelligence Berater seit über 20 Jahren im Projektgeschäft tätig. E-Mail: t.glunde@alligator-company.de