Homogene Business-Intelligence-Landschaft

Kundendaten und -informationen sind heutzutage Gold wert: Je mehr und vor allem je detaillierter die Informationen über Kunden, Produktabsatz und Kontobewegungen sind, desto gezielter lassen sich passende Produkte an den Mann bringen – und erhöhen so die Bindung an das Unternehmen. Dieser Ansicht ist auch die DAB Bank, die aus ihren Daten möglichst viele Erkenntnisse gewinnen möchte. Dabei geht es zum einen um die Optimierung des Produktportfolios. Zum anderen möchte die Bank die Bedürfnisse ihrer Kunden zielgerichtet ansprechen, denn insbesondere beim Onlinebanking herrscht ein harter Wettbewerb.

Die DAB Bank, 1994 als „Direkt Anlage Bank“ gegründet, war Deutschlands erste Direktbank. Mittlerweile gehört man zur BNP Paribas und bietet als Direktbank verschiedene Produkte und Dienstleistungen rund um die Themen Banking, Geldanlage sowie Trading. Im Firmenkundengeschäft ist das Finanzinstitut Partner für Vermögensverwalter, Fondsvermittler, Anlageberater sowie Banken und Sparkassen. Dies ist aber nur möglich, wenn das Haus nicht nur die Übersicht über alle im Unternehmen gespeicherten Daten hat, sondern daraus auch die notwendigen Erkenntnisse ziehen kann.

Die Bank investiert bereits seit vielen Jahren, um Erkenntnisse aus ihren Kundendaten zu ziehen und implementierte im Zuge dessen bereits 2002 ein Siebel CRM-System. 2005 entschied man sich, ein Data Warehouse mit dem Reporting-Tool SAP Business Objects einzuführen. Im darauffolgenden Jahr wurde Siebel Analytics mit dem dazugehörigen Data Warehouse eingeführt.

Konsolidierung der Business-Intelligence-Systeme

Somit gehörten zu den Lösungen, die man zwischen 2002 und 2006 implementierte, ein CRM-System, Siebel Analytics inklusive Data Warehouse sowie ein Enterprise Data Warehouse. Nachdem mit SAP Business Objects noch ein zweites analytisches Reporting-Werkzeug im Einsatz war, wollte die Bank auch dieses konsolidieren. „Siebel Analytics sowie das Business-Objects-System liefen parallel nebeneinander und verursachten Lizenz- sowie Wartungskosten. Darüber hinaus gab es Redundanzen beim Erstellen von Berichten und überlappende Funktionen. Eine Anwendung musste daher weichen, wir entschieden uns dafür, die Siebel-Software weiter zu verwenden“, erklärt Martin Schinharl, Bereichsleiter IT bei der Bank.

Bei der Einführung der Business-Intelligence-Systeme (BI) legten die Verantwortlichen auf verschiedene Merkmale Wert: So besteht das Enterprise Data Warehouse aus einem Operational Datastore (ODS), das die Daten aller angeschlossenen Quellsysteme konsolidiert. Es erfüllt zudem hohe Anforderungen an die Ausfallsicherheit und die Stabilität – für eine Bank wichtige Faktoren. Darüber hinaus dient das ODS als Datenpool für eine Reihe nachgelagerter Systeme. Das eigentliche Data Warehouse ist physisch vom ODS getrennt und enthält Daten in historisierter Form. Beide, ODS sowie das Data Warehouse, basieren auf einem relationalen Datenbanksystem (RDBMS) von Oracle und verwenden den Oracle Warehouse Builder (OWB) als ETL-Werkzeug.

Da sowohl das Enterprise Data Warehouse sowie das Siebel Data Warehouse auf der gleichen Oracle-Instanz installiert sind, ließen sich beide Datenhaushalte von Anfang an verknüpfen. Damit war von Beginn an eine Kampagnenselektion über alle Fakten hinweg aus dem Enterprise Data Warehouse heraus möglich – und zwar ohne zusätzlichen ETL-Aufwand.

Im Laufe der Zeit kamen jedoch neben der Ineffizienz bei der Berichtserstellung, doppelten Lizenz- und Wartungskosten weitere Probleme hinzu. So gab es beispielsweise keinen zentralen Datenpool zur Versorgung der Systeme für Banksteuerung (darunter Meldewesen, Risikomanagement, Compliance, etc.). Diese Systeme wurden über Punkt-zu-Punkt-Schnittstellen mit den operativen Quellsystemen verbunden. Jedes dieser Systeme entwickelte damit eine eigene Sicht auf die Daten – die Gefahr von Inkonsistenzen zwischen diesen nachgelagerten Systemen bestand zunehmend. Überdies entstanden im Laufe der Jahre zunehmend dezentrale „Fachbereichs-Data-Marts“ für Analyse- und Auswertezwecke. Diese dezentralen Systeme unterlagen keiner zentralen Governance und Steuerung, sodass auch hier das Problem inkonsistenter und veralteter Daten bestand. Weitere Herausforderungen waren eine fehlende einheitliche Lösung für Batch-Reporting sowie eine zunehmend verschlechterte Wartbarkeit der SAP Business Objects Anwendung.

BI-Strategie und externe Unterstützung

Bevor die DAB Bank begann, ihre Systeme zu konsolidieren, wurde eine neue BI-Strategie sowie eine BI-Zielarchitektur entwickelt. Berücksichtigt wurde dabei auch, dass alle Compliance- und Sicherheitsrichtlinien eingehalten wurden. „Mit unseren bisherigen Anwendungen war es eine Herausforderung, alle Compliance-Richtlinien einzuhalten. Neben operationellen Risiken bestand auch die Gefahr, dass wir veraltete und/oder inkonsistente Daten nutzten – für eine Bank undenkbar“, so Martin Schinharl.

Das IT-Team entschied sich dafür, dass die neue Architektur folgende Merkmale aufweisen sollte:

•    State-of-the-Art ETL-Architektur für eine große Entwicklungseffizienz und Neartime-Datenaktualisierung
•    Aufbau des ODS zu einem zentralen Datenpool, der auch die Grundlage für die Meldewesen-, Risikomanagement- und andere Systeme sein kann
•    Konsolidierung der Analyse-Tools: Oracle BI Enterprise Edition (EE) als einzige Anwendung
•    Implementierung einer einzigen Reporting-Engine für das Batch-Massen-Reporting

Mit der Unterstützung des BI-Dienstleisters B.telligent wurde die Konsolidierung der Analyse-Tools in Angriff genommen. Dabei verfolgte man von Beginn an das Ziel, gleichzeitig einen Nutzen für die BI-Anwender zu bieten: Zusätzliche Analyse- und Reporting-Funktionen, eine höhere Performance sowie eine einfachere Nutzung der Anwendung gehörten dazu. Ein weiteres Ziel war es, die IT-Systemlandschaft und die Wartung zu vereinfachen sowie eine zukunftssichere Lösung zu implementieren. Nicht zuletzt wollte man die Kosten reduzieren und die Effizienz für die Anwender steigern.

Das Projekt wurde weitgehend den inkrementellen und iterativen Vorgaben entsprechend umgesetzt. Insgesamt bestand die Implementierung aus verschiedenen Inkrementen, die je nach Komplexität in bis zu drei Themenbereiche unterteilt und nach Wichtigkeit geordnet waren. Die Priorisierung erfolgt auf Basis der folgenden Parameter: Anzahl der Zugriffe durch den Fachbereich, Anzahl der Reports, die auf den Themenbereich zugreifen sowie die Wichtigkeit der Berichte. Durch die manuelle Erstellung der Berichte in OBI EE wurden die Altlasten beseitigt: Die Anzahl der 9.000 Business-Objects-Berichte konnte auf knapp 670 Berichte reduziert werden. Die Erstellung der Berichte erfolgte hauptsächlich durch die Fachbereiche. Das hatte den Vorteil, dass die beteiligten Fachbereiche sich frühzeitig mit dem neuen Tool auseinandersetzten und somit auch Erfahrung sammeln konnten.

Im dritten Quartal 2014 löste Oracle BI (OBI) EE die bisherige Business-Objects-Anwendung ab. Zum Abschluss des Projekts fehlte nur noch ein Schritt: Damit die Daten des Siebel-Repository weiterhin Bestand hatten, wurde während des Projekts ein eigenes OBI-Repository angelegt. Diese beiden separaten Repositories mussten zusammengeführt werden, damit die Bank über einen einzigen Datenpool verfügt.

Allerdings wurde bereits vor diesem letzten Schritt ein Nutzen durch die Konsolidierung erzielt: So gibt es nur noch ein einziges Tool für das gesamte Reporting und die Analyse – und damit auch einen reduzierten Trainings- und Schulungsaufwand, da die Mitarbeiter nur noch ein Werkzeug bedienen müssen. Die Lizenzgebühren sind ebenso gesunken wie die Wartungskosten. Abgesehen von den Kosteneinsparungen erhöhte sich aber auch die Effizienz in der Entwicklung und im Betrieb der homogenen BI-Landschaft. Ein solches Projekt zeigt einmal mehr, dass Geschäfts- und IT-Ziele im Einklang miteinander stehen können.