Wie Data Vault Organisationen helfen kann regulatorische Anforderungen wie die BCBS-239 zu erfüllen.

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