Vorab: Abgrenzung, Grundsätzliches usw.


Ebene hoch


Definition und Abgrenzung

Robert Wieland (Homepage) und ich haben’s etwas mit den korrekten Abgrenzungen, daher vorab die große Heinz-Rühmann-Frage: „Nu stelle mer uns mal janz domm und frage uns: Wat is ejentlich en ‚Data Governance‘?“

Sowohl aufgrund unserer langjährigen Praxis als auch aus methodischen Überlegungen (abends im Office oder beim zweiten Frühstück im Café) heraus sind wir zum Schluss gekommen, dass Data Governance oft missverstanden wird. Das beginnt schon beim Namen, den wir nicht besonders mögen: Data Governance. Natürlich sind die letztlich abgespeicherten Daten ein wichtiger Punkt, aber sie sind nicht alles. Mindestens genau so wichtig sind Meta-Daten, Organisation, fachliche Konzepte, Prozesse, Medienwahl zur Dokumentation usw. usw. Aber der Name „Data Governance“ veranlasst viele in diesem Bereich nicht so erfahrene Häuser dazu, das alles viel zu sehr auf technische, bestenfalls halb-fachliche Aspekte der Datenablage und dem Management von Datenredundanzen zu reduzieren.

Teilweise ist es sogar richtig hanebüchen, was da an Stellen für Projekte und Linie ausgeschrieben wird: Da schreiben nicht wenige „Data Governor gesucht“, damit es wichtig klingt, und dann stellen wir bei genauerem Hinsehen fest, dass ein DB-Admin gesucht wird, der ein paar gezielte SQL-Abfragen absetzen soll, und der sich ein bisschen hinter den Kulissen um die Datenredundanzen kümmern soll. Bei allem Respekt vor den Leuten, die solche Arbeit machen (auch das ist nötig und nicht leicht): Als „Data Governor“ kann so jemand beim besten Willen nicht bezeichnet werden! Das ist ungefähr so, als wenn man den neu eingestellten Programmierer „IT-Leiter“ oder gar „CIO“ nennen wollte, nur weil er nicht ganz unerfahren ist, jüngere anleiten über den Tag hinaus denken kann (was wir tatsächlich auch schon erlebt haben!). Wenn man dann die Ansprechpartner darauf aufmerksam macht, kommen abenteuerliche Begründungen, warum es aber trotzdem so sein müsse, und dass doch die IT der Dreh- und Angelpunkt der Welt sei! (Da geht es natürlich auch oft um übermäßige Sparsamkeit, maßlos überzogene Erwartungen und auch um verletzten Stolz…)

Das ist jedenfalls einer der Gründe, warum wir den Namen „Business Intelligence (BI) Governance“ bevorzugen, den wir wie folgt in ein übergreifendes Framework einordnen:

Schema Governance, Level 1
Schema Governance, Level 1

Schon das werden Sie so nicht unbedingt in der einschlägigen Literatur finden. Und wenn wir geistig einen „Doppelklick“ auf den Block „BI Governance“, dann sieht das ganze eine Ebene tiefer so aus:

Schema Governance, Level 2
Schema Governance, Level 2

Auch dies eine nicht unbedingt alltägliche Sicht. Für sich allein, aus dem Zusammenhang gerissen, sagen diese Bilder noch nicht allzu viel aus, aber man kann schon ganze Bücher darüber schreiben. Wir werden uns in unserer Artikelserie notgedrungen etwas beschränken müssen:

Schwerpunkte Governance, Level 1
Schwerpunkte Governance, Level 1
Schwerpunkte Governance, Level 2
Schwerpunkte Governance, Level 2

Und nach dieser Klarstellung: Nachdem sich „da draußen“ nun einmal der Begriff „Data Governance“ durchgesetzt hat, werden wir ihn trotzdem hier und da verwenden — wir benutzen ihn nur (leider ungenau) synonym zu BI Governance.

Form follows Function!

Leider haben wir das schon zig-mal beobachtet: Da wird ein schickes Tool gekauft, das auch vielleicht die Techniker (aus gutem Grund) mögen, und der Hersteller behauptet, mit diesem wundersamen, allumfassenden, sogar Kaffee-kochenden und Krebs-heilenden Tool könne man alles im gesamten BI- und DWH-Bereich machen und regeln. Man hätte da 2 Erweiterungen eingebaut, und — tataaa! — schon hätten wir ein Data Governance Tool.

Wir sind bei solchen Behauptungen mittlerweile sehr skeptisch. Bisher haben sich in unseren Projekten noch jedes Mal solche großspurigen Versprechungen als nicht annähernd haltbar erwiesen, und mittlerweile wissen wir auch, welche Fragen wir da stellen müssen, um es nicht nur zu vermuten, sondern auch zu wissen.

Ohne, dass wir hier in die Details gehen möchten: Die Denkweise ist meistens so: Wir haben eine gegebene IT-Lösung („gegeben“ deshalb, weil sie jetzt einfach mal gekauft worden ist), nach deren Funktionsweise sich selbstverständlich künftig alles richten muss. Aus ihr werden dann also Methoden, Prozesse und die Organisationsstruktur abgeleitet. Nicht schlecht für ein Tool! Variation: Wir wissen, dass im Data/BI-Governance-Bereich eigentlich nichts so recht klappt und man mal ein bisschen grundsätzlicher an die Sache herangehen müssten. Aus politischen Gründen wird festgelegt, dass die bestehende Organisationsstruktur, ganz gleich, was wir sonst feststellen, auf keinen Fall geändert werden darf. Aus ihr soll sich also alles ableiten.

Wir sind der Ansicht: Zuerst kommen das, worum es eigentlich geht, nämlich die Geschäftsobjekte, die Methoden und die Prozesse. Aus ihnen leitet sich die IT ab (= die technischen Lösungen, nicht der gleichnamige Bereich), und aus ihr wiederum die Organisationsstruktur. Es mag politische Gründe geben, es anders zu machen, aber mit Verlaub: Politische Gründe sind selten gute Gründe! Auf eine einfaches Bild gebracht:

Ableitungen BI-Governance
Ableitungen BI-Governance

Entwicklungspfad

Eine wichtige Frage, mit der man es in einem größeren Vorhaben (egal ob als Externer oder als Interner) immer zu tun hat: Wie bringen wir die Organisation und die Leute eigentlich von ihrer jetzigen Position zur künftigen? Wie sieht der Entwicklungspfad aus?

Das ist natürlich immer eine hochgradig individuelle Geschichte, die nicht allgemein beantwortet werden kann. Aber im Zusammenhang mit unseren Artikeln, die folgen, möchten wir eines klarstellen, um Missverständnisse zu vermeiden:

Wir wissen, dass die Welt nicht ideal ist, und dass man immer aus allen möglichen Gründen Kompromisse eingehen muss. Abgesehen davon, dass es gute und weniger gute Kompromisse gibt, und dass die Gründe für sie auch mehr oder weniger legitim sein können: Das ist zunächst einmal eine Tatsache.

Wir sind keine Träumer, und wir haben unsere Berufsleben nicht im Elfenbeinturm verbracht. Aber wir wissen auch, dass nicht jede Ausrede, die von irgendjemandem geäußert wird, Grund sein kann, Sachen nicht so zu machen, wie sie gemacht werden sollten. Mit dem immer geforderten „Pragmatismus“ ist das so eine Sache… Und damit man weiß, wie die Dinge gemacht werden sollten, muss man zunächst einmal ein ideales Bild im Kopf haben (besser noch: richtig dokumentiert). Und auf Basis dessen kann man sich dann überlegen,

  • wo man die Organisation abholt, und wie man sie aufs nächste (realistische) Niveau hebt,
  • welche Kompromisse dabei noch tragbar sind und welche nicht, und
  • welche Schritte danach noch zu tun sein werden, die wir uns für später aufheben.
Entwicklungspfad BI Governance
Entwicklungspfad BI Governance

Und weil wir, wie gesagt, nicht über alles und jedes schreiben können und wollen, und weil sich bestimmte Fragen gar nicht allgemein, sondern nur im Kontext eines konkreten Projekts beantworten lassen, bleiben wir in der ersten Staffel unserer Artikel nur auf der linken Seite der obigen Abbildung: Der idealen Welt. Wie dann die Transition in der Wirklichkeit exemplarisch aussieht (also der Rest der Abbildung), darauf wollen wir in einer zweiten Staffel eingehen (vstl. im Sommer 2015).

Wir wünschen Ihnen gute Lektüre!


Nächster Beitrag