Archiv der Kategorie: Berater

Datenqualitäts-Management als Teil der Data Governance (2/2)


Vorheriger Beitrag  Ebene hoch


Zusammenfassung

Data-Governance-Serie, Teil 5.2: Im letzten Teil haben wir sowohl Unterschiede als auch Zusammenhänge und Gemeinsamkeiten zwischen Datenqualität und Data Governance heraus gearbeitet. Hier knüpfen wir an – ebenfalls verweise ich auf den Teil 2 dieser Artikkel-Serie zur vertikalen Dimension der DG, wobei hier nicht die technischen Felder bzw. BDEs im Vordergrund stehen, sondern Datenqualitäts­regeln, welche auf diese referenzieren bzw. mit ihnen verlinkt sind. Das vorgestellte Metamodell mit den beschriebenen Abstraktionsebenen stellt ein Data-Governance-Hilfsmittel dar, um Datenqualitätsregeln im fachlichen Kontext zu formulieren und nachzuverfolgen.

Ansatz

Formulierung von DQ-Regeln auf mehreren Abstraktionsebenen.

Analog zur bereits vorgestellten „vertikalen Struktur“ führen wir eine Hierarchie der DQ-Regeln ein: Es gibt dann also mehrere Verwaltungs- bzw. Abstraktionsebenen im DQ-Regelwerk, mit denen die verschiedenen Stakeholder typischerweise im BI-Umfeld zu tun haben. In aufsteigender Abstraktionsfolge sind dies also:

[…]

Ganzer Artikel


Nächster Beitrag


 

Datenqualitäts-Management als Teil der Data Governance (1/2)


Vorheriger Beitrag  Ebene hoch


Zusammenfassung

Data-Governance-Serie, Teil 5.1: Nachdem wir in den letzten beiden Artikeln die sog. vertikale und horizontale Dimension der Data Governance behandelt haben, gehen wir in diesem Artikel auf Datenqualitätsmaßnahmen im Rahmen einer Data Governance-Initiative ein.

Henne und Ei

Data Governance und Datenqualitätsmanagement (DQ-Management) sind zwar separate Datenmanagement-Disziplinen, obgleich sie in enger Beziehung und gegenseitiger Abhängigkeit zueinander stehen.

Datenqualitätsmanagement dient dazu, die Datenqualität – definiert nach unterschiedlichen Dimensionen (Vollständigkeit, Korrektheit, Aktualität, Konsistenz etc..) – im Einklang mit den fachlichen Anforderungen zu beschreiben, zu messen und zu bereinigen (DQ-Anforderungen, Daten-Analyse (Profiling), Data Standardisation und Data Cleansing ).

[…]

Ganzer Artikel


Nächster Beitrag


 

Die horizontale Dimension der Data Governance


Vorheriger Beitrag  Ebene hoch


Zusammenfassung

Data-Governance-Serie, Teil 4: Im Teil 3 haben wir die sog. vertikale Dimension der Data Governance als Teil eines gesamthaften Ansatzes zur Lösung der klassischen Probleme beschrieben. Nun gehen wir auf die sog. horizontale Dimension ein.

Grundidee

Zunächst einmal: Was meinen wir mit der horizontalen Dimension? Es wird klar, wenn wir uns noch einmal kurz vor Augen führen, in welchem Zusammenhang Data Governance typischerweise nötig ist und am meisten gebraucht wird: Im Umfeld von BI und DWH.

Anker: DWH-Architektur

Nun gibt es, auf abstrahierter Ebene, einen typischen System- und Prozess-Aufbau, den man in diesem Umfeld immer wieder vorfindet und der häufig auch grafisch so dargestellt wird:

Ganzer Artikel


Nächster Beitrag


 

Die vertikale Dimension der Data Governance


Vorheriger Beitrag  Ebene hoch


Zusammenfassung

Data-Governance-Serie, Teil 3: Im Teil 1 haben wir die klassichen Probleme der Data Governance beschrieben. IN den folgenden Teilen beschreiben wir konzeptionell einen effektiven und Praxis-erprobten Lösungsansatz. Entgegen häufigen Vermutungen basiert dieser nicht auf Tools bekannter Hersteller, die i.W. die Buchhaltung der technischen Felder der Überleitungen zwischen ihnen vereinfachen, sondern er basiert auf Aggregation und fachlicher Abstraktion.

In diesem Artikel gehen wir auf die sog. vertikale Dimension der Data Governance ein.

Ansatz

Wir führen mehrere Verwaltungs-Ebenen ein, die die Haupt-Entitäten enthalten, mit denen es ein Data Governor typischerweise im BI-Umfeld zu tun hat. In auf­steigender Abstraktionsfolge sind dies:

Ganzer Artikel


Nächster Beitrag


 

Die Informations-Dimension der Data Governance


Vorheriger Beitrag  Ebene hoch


Zusammenfassung

Data-Governance-Serie, Teil 2: Im Teil 1 haben wir die klassischen Probleme der Data Governance beschrieben. In den folgenden Teilen beschreiben wir konzeptionell einen effektiven und Praxis-erprobten Lösungsansatz. Entgegen häufigen Vermutungen basiert dieser nicht auf Tools bekannter Hersteller, die i.W. die Buchhaltung der technischen Felder der Überleitungen zwischen ihnen vereinfachen, sondern er basiert auf Aggregation und fachlicher Abstraktion.

In diesem Artikel gehen wir auf die sog. Informations-Dimension der Data Governance ein.

Begriffsklärung

Im BI-Umfeld haben wir es nicht „einfach nur mit Daten“ zu tun, die wir in einem DWH aus verschiedenen Quellen zusammentragen. Es geht vielmehr um die Steuerung eines Unternehmens auf Basis von Informationen, die aus diesen Daten gewonnen werden.

Diese Informationen werden auf fachlicher und teilw. auch auf Management-Ebene klar definiert und zu einem Report kompiliert. Damit sie entsprechend kompiliert werden können, müssen sie wiederum nach bestimmten Dimensionen aufgefächert vorliegen. Die klassischen BI-Informations-Dimensionen sind hierbei:

Ganzer Artikel


Nächster Beitrag


 

Die klassischen Probleme der Data Governance


Vorheriger Beitrag  Ebene hoch


Zusammenfassung

Data Governance ist ein komplexes und vielschichtiges Thema. Herkömmliche Ansätze versuchen in zu starkem Maße (und letztlich erfolglos), alles auf Buchhaltung der technischen Felder zurückzuführen. Der Autor hat jedoch die Erfahrung gemacht, dass Data Governance, die auf fachlichen Vereinfachungen, Aggregationen und Abstraktionen beruht, weitaus effektiver und erfolgversprechender ist. In diesem Teil betrachten wir die sog. vertikale Dimension.

Abgrenzungs- und Verständnisprobleme

Was macht Data Governance aus? Wir hatten bereits im Eröffnungs-Beitrag im Blog geschrieben, dass wir festgestellt haben, dass Data Governance zwar ein überall verwendeter, aber auch überall anders verstandener Begriff ist.

Ganzer Artikel


Nächster Beitrag


 

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

Über-Spezifikation

Kennen Sie das?: IT-Projekt bei großem Kunden, ganz oberwichtiges Vorhaben. Total Business-kritisch. Wenn das jetzt nicht gemacht wird, dann geht die Firma unter (die des Kunden, versteht sich). Und wenn schon, denn schon: ein Riesending soll’s werden, denn es sollen / müssen ja auch ein paar Sachen nachgeholt werden, die die letzten Jahre versäumt worden sind.

Außerdem ist es natürlich – wie kann es anders sein – wahnsinnig dringend. Eigentlich sollte alles schon bis gestern erledigt sein. Aber weil das Management vom IT-Projekthaus nochmal ernsthaft mit dem Management vom Kunden geredet hat, hat man sich geeinigt: Na gut, dann halt nicht bis gestern, sondern bis Jahresende; das ist dann aber der allerletzte Termin, ja?! (und natürlich genauso wenig zu halten.) Also eigentlich der übliche Auftrag, ein Wunder zu vollbringen.

Das mit dem Termin setzt natürlich alle unter Druck. Also müssen „kreative“ und „pragmatische“ Lösungen gefunden werden, denn mit normalem Vorgehen kommt man da nicht weiter. Also wird alles weggelassen, was bekanntermaßen sowieso unnötig ist:

[…]

ganzer Artikel

Die ID, die ganze ID und nichts als die ID

Es ist immer sehr gefährlich, sich abfällig über Kollegen zu äußern, noch dazu pauschal, aber in diesem Fall geht es nicht anders. Ich muss mich hier mal aus dem Fenster lehnen:

Ich arbeite seit jeher in der IT. Wie in jedem Fach, so gibt es auch in der IT ein gewisses Grund-Basiswissen der meisten, die sich auf dem Feld tummeln; auch bei denen, die nicht mehr „aktiv“ sind. Einem Krankenhaus-Leiter müssen sie gewisse Grundlagen der Medizin nicht erklären, auch wenn er selbst schon lange nicht mehr selbst operiert. In der IT gibt es dazu Parallelen: Auch denjenigen, die nicht mehr selbst ganz tief in den Gedärmen der Datenbanken oder des Codes arbeiten (was ich selbst übrigens auch selbst nur noch selten mache), müssen Sie im Allgemeinen nicht mehr Grundlagen wie die z.B. die grundlegende Funktionsweise einer relationalen Datenbank erklären.

Umso mehr wundert es mich immer wieder, wie wenig so genannte IT-Experten davon verstehen, was eine ID ist.

Übliche Fehler, die ich immer wieder sehe, sind:

[…]

ganzer Artikel

Der Hund und die Alarmanlage

Gerade in IT-Projekten ist man immer wieder mit der Herausforderung konfrontiert, dass sich die Anforderungen laufend ändern, die Kommunikation und die Änderungsabläufe ineffizient sind und man es im Nachgang mit hohen Kosten für Entwicklung und Wartung zu tun hat. Bekannte Auto­ren identifizieren gar „dynamische“ Anforderungen als das Top-Risiko in Software-Projekten. Pro­fes­sio­nelles Anforderungs-Management, eingebettet in ein – richtig verstandenes – iteratives Vorgehen, wird diese Risiken beträchtlich vermindern.

[…]

ganzer Artikel