Data Governance@DKB – Roadmap zum DQM bei DKB Deutsche Kreditbank

Grundsätzlich kann man sicherlich festhalten, dass die regulatorischen Vorgaben aus BCBS 239 der Treiber für den Aufbau professioneller Data-Governance-Strukturen in Banken waren bzw. sind. Auch in der DKB wurde der Startpunkt für ein zentral gesteuertes Datenqualitätsmanagement (DQM) mit den ersten BCBS-Umsetzungsprojekten gelegt.

Ron Neumann von der DKB Deutsche Kreditbank AG wirft für Sie einen Blick in die Praxis der Data Governance@DKB und schildert, was mit dem DQM bei DKB erreicht und was gelernt wurde.

Gerade am Anfang unserer Umsetzungsinitiativen stand die regulatorische Compliance ganz klar im Fokus unseres Zielbildes. Der Scope war ausgerichtet an den steuerungsrelevanten Berichten der Bank und deren Kennzahlen, konkret interessierten wir uns also für alle ökonomischen und risikorelevanten Daten im Sinne der internen und externen Steuerung. Diese enge Auslegung des Wirkungskreises unseres DQMs haben wir jedoch im Verlauf der Operationalisierung gelockert und das DQM auch für Datenkategorien außerhalb der Regulatorik geöffnet. Wobei „eng“ hier nicht fehlinterpretiert werden darf, da allein der Scope zur Erreichung der regulatorischen Compliance gewaltig ist. Durch die Öffnung des Scopes sind wir mittlerweile in der Lage, mit dem DQM konkreten Business Cases in der Bank zu folgen und auch im Umfeld von zum Beispiel Kampagnenmanagement, Data Analytics oder CRM für qualitätsgesicherte Daten zu sorgen.

Der Scope des DQM der DKB konzentriert sich also primär auf die Einhaltung regulatorischer Vorgaben, lässt aber gleichzeitig Raum, um aus konkreten „Data Governance Business Cases“ Mehrwerte für die Bank zu schöpfen.

In der DKB verfolgen wir den Ansatz einer hybriden Data-Governance-Organisation. Im Kern baut dieser Ansatz darauf auf, dass wir für das Betreiben unseres DQMs sowohl umfassende Datenmanagement-Kompetenzen als auch tiefes fachliches Know-how benötigen. Das fachliche Know-how finden wir bei unseren Kolleginnen und Kollegen in den Fachbereichen, die Datenmanagement-Kompetenzen bei den Rollen in der zentralen Data-Governance-Einheit (= Datenmanager). „Hybrid“ stellt also auf die Kapselung von zentralen und dezentralen Kompetenzfeldern ab.

Die jeweiligen fachlichen Know-how-Träger werden dabei im Rahmen eines Data-Ownership-Modells formalisiert. Alle Daten unseres (regulatorischen) Scopes sind dadurch mit einer konkreten fachlichen Verantwortlichkeit verbunden.

Durch diesen Ansatz konnten wir ein robustes und praxistaugliches Zusammenarbeitsmodell in der Bank etablieren. Das Modell lebt von kontinuierlicher Kommunikation und verursacht daher nicht unerheblichen Aufwand in der Data Governance, ermöglicht im Gegenzug aber die Etablierung des DQM bei DKB auf der gesamten Bandbreite bankfachlicher Prozesse.

Betrachtet man den klassischen DQ-Kreislauf, trennen wir das DQM in einen CHANGE- und einen RUN-Teil. Beide Teile des DQ-Kreislaufs sind auf die aktive Mitwirkung der Rollen aus der hybriden Data-Governance-Organisation ausgerichtet.

Beginnen wir mit dem CHANGE, oder einfacher ausgedrückt: Wie wird eine neue DQ-Regel umgesetzt? Diesen Prozess starten wir immer mit der Frage nach der fachlichen Motivation hinter einer DQ-Regel. Beantwortet wird diese Frage von den jeweiligen Data Ownern und erzeugt im Ergebnis eine fachliche DQ-Regel als Basis für den CHANGE-Prozess.

Wir haben sehr gute Erfahrungen damit gemacht, die technische Umsetzung der DQ-Regeln als „Dataquality as a Service“ anzubieten. Das heißt, die Datenmanager (zentrale Data-Governance-Einheit) nehmen die fachlichen DQ-Regeln entgegen, bringen sie technisch bis zur produktiven Reife und liefern sie als fertiges Produkt an die Data Owner aus. Mit Blick auf das Zusammenarbeitsmodell vereint dieser Ansatz für uns diverse Vorteile:

Ist die DQ-Regel technisch implementiert, greift automatisch der RUN-Teil. Das heißt, abhängig von der jeweiligen Parametrisierung wird eine DQ-Regel automatisiert in einem definierten Rhythmus ausgeführt. Als Bestandteil der Produktauslieferung im Rahmen unseres „Dataquality as a Service“-Ansatzes, werden alle DQ-Messergebnisse durch ein DQ-Reporting begleitet. Damit die Data Owner (ggf. unterstützt durch die Datenmanager) in der Lage sind, die Inhalte der DQ-Issues zu verstehen und fachlich zu analysieren (= Issue Management), benötigen sie punktuelle Transparenz. Diese Transparenz wird durch ein zielgerichtetes DQ-Reporting erzeugt. Zusätzlich können Metadaten in die fachlichen Analysen einfließen, so dass durch konkrete Data-Lineage-Auszüge die Wirkzusammenhänge sowohl upstream (wo kommen die Daten her) als auch downstream (wo gehen die Daten hin) erkannt werden. Der operative Einsatz von DQ-Reportings und Metadaten im Rahmen des Issue Managments ist nicht zwangsläufig selbsterklärend, weshalb auch der RUN-Teil von intensivem Austausch zwischen Data Owner und Datenmanager gekennzeichnet ist.

Wenn wir wissen, was das DQ-Reporting für uns leisten soll, können wir definieren, wie es ausgestaltet sein muss. Das Leistungsspektrum hängt maßgeblich davon ab, welche Nutzergruppen wir mit dem DQ-Reporting erreichen wollen. Neben dem reinen Transparenzgedanken, zum Beispiel eine Aussage über die Datenqualität an steuerungsrelevante Kennzahlen zu projizieren, setzen wir das DQ-Reporting gezielt für DQ-Verbesserungsmaßnahmen ein. Das bedeutet, wir produzieren verschiedene Produkte im Umfeld des DQ-Reportings, die sich hinsichtlich ihres Einsatzzwecks und der Nutzergruppen unterscheiden, zum Beispiel:

Auf dem Weg zu einem effizienten DQM gibt es natürlich viele Entscheidungen, die individuell getroffen werden müssen. Mit Blick auf die Data Governance@DKB lassen sich zwei wesentliche Leitplanken erkennen, die unsere Prozesslandschaft im DQM bei DKB nachhaltig positiv beeinflusst haben: