BCBS 239: Chancen für die Data-Warehouse-Sanierung

BCBS 239 schreibt vor, dass Geldhäuser die Herkunft ihrer Daten immer einwandfrei belegen und die Transparenz jederzeit gewährleisten müssen. Darüber hinaus stellt die Richtlinie strengere Anforderungen an die Datenqualität. Viele Banken und Sparkassen tun sich allerdings schwer damit, diese Forderung umzusetzen. Der Grund ist in vielen Fällen ein veraltetes Data Warehouse.

Der Leitfaden zur Data Warehouse-Sanierung der PPI

Institute müssen dringend ihre bestehenden Systeme erneuern wenn Sie BCBS 239 ernst nehmen. Doch eine Sanierung kann dabei eine effektive und günstige Alternative zum Neubau darstellen. Es sind oftmals Kleinigkeiten, die einem die Grenzen der bestehenden Systeme aufzeigen. Zum Beispiel bei der Berechnung des Währungsrisikos. In Deutschland erfolgt diese in der Regel in Euro. Komplizierter wird es, wenn der Kurs bei Fremdwährungsrisiken, zum Beispiel bei Anlagen in Asien oder den USA, umgerechnet werden muss. Welcher Stichtag gilt dann? Und dient der Tagesanfangs- oder -endkurs als Maßstab?
Bei dezentralen Data Warehouses besteht in diesen Fällen die Gefahr, dass unterschiedliche Abteilungen unterschiedliche Berechnungen zugrunde legen. So kann es vorkommen, dass der Vertrieb andere Kennzahlen ermittelt als das Risikomanagement. Selbst eine so einfache Zahl wie das Währungsrisiko kann deshalb für Verwirrung sorgen. Und die Nachforschungen, wie die verschiedenen Abteilungen zu ihren Ergebnissen gekommen sind, gestalten sich schwierig, wenn die dahinter stehenden Logiken nicht zentral erfasst und im Rahmen des Metadatenmanagements mit ausgeliefert werden.

Übergangs- und Schatten-BI-Lösungen erschweren die Arbeit

Dies ist nur ein Beispiel dafür, wie schnell historisch gewachsene Data-Warehouse-Systeme bei Banken und Sparkassen an ihre Grenzen stoßen. Der Begriff „System“ ist dabei eigentlich nicht ganz korrekt. Denn es handelt sich um eine Vielzahl von Systemen. Dazu zählen Übergangslösungen, die zur Dauerlösung gerieten ebenso wie „Schatten-BI-Lösungen“, die meist auf Basis von Excel oder Access in den Fachabteilungen entstanden sind. So entstehen intransparente Systemwelten, denen darüber hinaus oft Aktualitätsprobleme ihrer Daten sowie eine unzureichende Performance bei Beladung oder Abfragen zu schaffen machen.

Doch was tun? Ein Neubau ist für viele Institute keine Option. Zu hoch sind die personellen, zeitlichen und finanziellen Ressourcen, die dafür eingesetzt werden müssen. Die Sanierung des bestehenden Data Warehouses kann in diesen Fällen eine gute Alternative darstellen. Der wesentliche Vorteil: Die Sanierung erfolgt im laufenden Betrieb. Unternehmen müssen damit nicht zwei Data Warehouses parallel betreiben, wie es beim Neubau der Fall ist. Darüber hinaus schafft die Sanierung im Idealfall nach jedem Schritt einen konkreten Nutzen für den Anwender, zum Beispiel die höhere Aktualität der zur Verfügung stehenden Daten durch die Verbesserung der ETL-Prozesse.

Ein weiterer wichtiger Punkt, der für die Sanierung spricht, ist die Reduzierung des betriebswirtschaftlichen Risikos. Denn zum einen sind die Kosten meist geringer als beim Neubau und fallen in Tranchen an. Zum anderen kann die Sanierung zwischendurch ausgesetzt werden, etwa wenn andere Projekte Vorrang haben oder sich die finanzielle Situation ändert.

Sanierung oder Neubau?

Grundsätzlich gilt jedoch: Die Frage „Sanierung oder Neubau?“. Sie muss im Einzelfall geklärt werden. Dabei wird es sicher auch DWH-Systeme geben, für die es keine Alternative zum Neubau gibt. Ist die Entscheidung für eine Sanierung getroffen, sind für eine erfolgreiche Umsetzung eine strukturierte Analyse und Konzeption der DWH-Sanierung erforderlich. Diese besteht aus vier Schritten.

Schritt 1: Ziele definieren
Was ist das Ziel der Maßnahmen? Soll zum Beispiel die Leistungsfähigkeit erhöht werden? Oder wird eine Senkung der Betriebskosten angestrebt? Diese generelle Stoßrichtung muss im Vorfeld bestimmt werden. Die Ziele können sich auf die einzelnen Phasen (Plan-Build-Run-Use) und das Zielkonfliktdreieck (Kosten-Qualität-Flexibilität) beziehen.
Es müssen klare Prioritäten definiert und mögliche Auswirkungen der Maßnahmen ins Kalkül gezogen werden. Dabei sollte neben der bestehenden Systemlandschaft auch die strategische Ausrichtung des Unternehmens berücksichtigt werden.

Schritt 2: Schwachstellen identifizieren
Im zweiten Schritt müssen mögliche Schwachstellen des jeweiligen Systems identifiziert werden – und zwar für jeden einzelnen Schritt eines Prozesses. Möglich wird dies unter anderem durch die Aufstellung von Hypothesen, die durch Testläufe überprüft werden. Weitere Möglichkeiten sind die Kontrolle der Datenqualität durch das Data Profiling und Gespräche mit Beteiligten auf IT- und Anwenderseite.
Die Schwachstellen werden auf einer Matrix in Verbindung zu den übergeordneten Zielen (Effektivität, Performance, Stabilität und so weiter) gesetzt. So wissen Unternehmen sofort, an welchen Punkten sie ansetzen müssen, um ihre zuvor festgelegten Ziele zu erreichen.

Schritt 3: Rahmenbedingungen klären
Durch die Klärung der spezifischen Rahmenbedingungen lässt sich verhindern, dass Maßnahmen entwickelt werden, die nicht zu den Rahmenbedingungen des Unternehmens passen. Wenn zum Beispiel die IT-Strategie den Einsatz eines bestimmten Datenbanksystems oder BI-Werkzeugs erfordert, muss das im Sanierungsplan berücksichtigt werden. Auch laufende Projekte und regulatorische Rahmenbedingungen wie BCBS-239 müssen in die zeitliche und inhaltliche Sanierungsplanung eingebunden werden. Generell ist es wichtig, vorausschauend zu planen und das System so aufzustellen, dass es auch künftigen Herausforderungen gewachsen ist.

Schritt 4: Maßnahmen ableiten
Auf Basis der in den ersten drei Schritten gewonnenen Erkenntnisse werden schließlich konkrete Maßnahmen entwickelt. Sie können von technischen Anpassungen bis zu organisatorischen Umstrukturierungen reichen. Wichtig dabei ist, dass die Sanierungsmaßnahmen in Abhängigkeit zueinander stehen. So sollte etwa die Standardisierung von ETL-Prozessen erst nach den Optimierungen am Datenmodell oder den Anpassungen an der Schichtenarchitektur durchgeführt werden.

Umsetzung der Maßnahmen erfolgt in drei Phasen

Hat man diese vier Schritte erfolgreich durchlaufen, kann als nächstes eine Umsetzungsplanung vorgenommen werden. Diese berücksichtigt alle inhaltlichen Abhängigkeiten und priorisiert die Maßnahmen entlang der Sanierungsziele. Diese Umsetzungsplanung lässt sich in drei wesentlich Phasen unterteilen.

In Phase 1 wird zunächst die Leistungsfähigkeit und Stabilität wiederhergestellt. Die Maßnahmen sind entsprechend kurzfristig ausgelegt. Dies kann zum Beispiel durch die Optimierung der SQL-Prozesse erfolgen. Dadurch werden die ETL-Prozesse beschleunigt. Im Alltag äußert sich dies durch schnellere Ladezeiten bei Abfragen, zum Beispiel die für die aktuellen Vertriebszahlen zu Wochenbeginn. Positiver Nebeneffekt: Der Erfolg motiviert alle Beteiligten und gibt Rückenwind im eigenen Haus für die weitere Sanierung.

In der zweiten Phase der Umsetzung wird die Zukunftsfähigkeit gewährleistet. Um bei dem Beispiel der SQL-Prozesse zu bleiben bedeutet dies, dass durch klare und schlanke Strukturen die ETL-Prozesse dauerhaft beschleunigt werden. Maßnahmen in diesem Bereich können zum Beispiel die Anpassung des Datenmodells und die Einrichtung von eindeutigen technischen Zugriffsberechtigungen für die Schichtenarchitektur sein.

Die dritte Phase dient schließlich dem langfristigen Schutz der Investitionen. Hier stehen Themen wie Effizienz und Transparenz im Vordergrund. Im Beispiel der ETL-Prozesse geht es unter anderem darum, die Prozesse weiter zu standardisieren, etwa durch die Einführung eines ETL-Frameworks, um automatische Testläufe zu etablieren.

Unterbrechungen sind jederzeit möglich

Ein wesentlicher Vorteil dieses stufenweisen Vorgehens ist, dass nach jeder Stufe der Sanierungserfolg überprüft werden kann. Unter Umständen werden weitere Maßnahmen überflüssig, wenn das gesteckte Ziel schon früher als gedacht erreicht wird. Oder es werden neue Anforderungen in den Maßnahmen berücksichtigt, die sich aus den Markterfordernissen oder durch Aufsichtsbehörden ergeben.

Dies macht die Data-Warehouse-Sanierung zu einer risikoarmen Alternative zum Neubau. IT-Verantwortliche können ihr System damit mit vergleichsweise wenig Aufwand an die steigenden Anforderungen anpassen und gleichzeitig die Leistungsfähigkeit erhöhen. Die Vorgaben von BCBS 239 sind eine gute Gelegenheit, damit anzufangen.