Schlagwort-Archive: Data Governance

#8 Was ist ein Business Glossar?

Veröffentlicht am von
Antworten

Jede und jeder, die bzw. der eine neue Arbeitsstelle antritt, kennt das: Neue Prozesse, neue Regeln und vor allem neue Begrifflichkeiten und Abkürzungen. Die neuen Kollegen sprechen eine „wunderliche“ Sprache mit Spezialbegriffen. Aber alle schon länger in der Organisation arbeitenden Personen scheinen virtuos mit den Begriffen umzugehen und sich zu verstehen. Neue und Außenstehende verstehen evtl. nur Teile oder haben vielleicht auch ein falsches Verständnis von verwendeten Begriffen. Grund dafür kann sein, dass sie deren Bedeutung aus ihrem vorigen Umfeld anwenden – und diese nicht passt.

Manche Organisationen haben fast eine eigene Sprache oder zumindest eine eigene Begriffswelt etabliert. Für die „Eingeweihten“ ist alles klar, alle „Neuen“ und von außen kommenden Personen können nicht mitreden.

Glossar zur zentralen und eindeutigen Begriffserklärung

Um hier Transparenz zu schaffen, kann der Aufbau und die dauerhafte Pflege einer Übersicht von Begriffen und Abkürzungen sowie deren Erklärung hilfreich sein. Solch eine Übersicht können wir als „Glossar“ oder – im Geschäftsumfeld – als „Business Glossar“ (englisch: business glossary) bezeichnen.

Wikipedia definiert ein Glossar als „…eine Liste von Wörtern mit beigefügten Bedeutungserklärungen oder Übersetzungen. […] Im erweiterten Sinn wird ein Glossar auch Begriffserklärung genannt (im Unterschied zu einer Begriffsklärung). Insbesondere wenn es um die Beschreibung oder Erklärung einzelner Begriffe geht, wird ein Glossar auch als (Begriffs-)Abgrenzung oder als Definition bezeichnet.“

Was soll ein Business Glossar erreichen?

Die Verwendung eines konzernweiten Business Glossars fördert ein gemeinsames, konsistentes Verständnis von Geschäftsbegriffen und Definition innerhalb der Organisation und ermöglicht allen Anwendern den Zugriff auf die gleichen Informationen mit Begriffen aus Sicht der Fachanwender.

Das Business Glossar definiert somit ein Vokabular von Wörtern und Phrasen oder ein Notationssystem, einschließlich Fachbegriffen, die innerhalb der Organisation genutzt werden. Anfänglich deckt dieses Vokabular nicht alle Themen und Inhalte ab. Die Anwenderinnen und Anwender können nach Inhalten suchen, indem sie vertrautes Geschäftsvokabular und Synonyme verwenden oder effizient in den Definitionen navigieren.

So baut man ein Business Glossar strukturiert auf

Glossareinträge sind eigentlich relativ einfach strukturiert:

  • Glossarbegriff: der Begriff als Wort oder mehrere Worte, der erklärt wird
  • Erläuterung: Die verbale Beschreibung zu dem Glossarbegriff. Dies kann als Prosa erfolgen, es können ggf. auch Links zu internen oder externen Dokumenten oder Seiten enthalten sein. Eine ausschließliche Erläuterung nur durch Verlinkung anderswo hin halte ich für nicht empfehlenswert, zumindest einige Sätze sollten im Glossar direkt zu finden sein.

Das wäre eigentlich die Grundstruktur. Darüber hinaus protokolliert man auch organisatorische und prozessuale Informationen:

  • Datendomäne, zu der dieser Begriff gehört. Die Zuordnung zu Datendomänen (näher erläutert in meinem vorherigen Blog-Beitrag) kann auch nicht eindeutig sein, d. h. ein Begriff wie bspw. „Adresse“ ist sowohl der Kunde- als auch der Lieferant-Datendomäne zuzuordnen.
  • Status: nicht geprüft, in Arbeit, freigegeben/bestätigt
  • Erstell- und/oder Freigabedatum
  • Datum der letzten Prüfung
  • Geprüft/freigegeben durch: Hier ist m. E. die Verantwortung bei dem/der/den Data Steward(s) der zugeordneten Datendomäne(n) zu sehen. Data Stewards prüfen die Begriffe und deren Erklärung – oder erstellen die Erklärung auch selber – und geben diese frei.

Will eine Organisation ein Business Glossar aufbauen, ist es sinnvoll, zunächst die vorhandenen Erklärungslisten zu sammeln und zu konsolidieren. Viele Mitarbeiterinnen und Mitarbeiter führen für sich selbst Listen mit Begriffserklärungen. Insbesondere neue Mitarbeiterinnen oder Mitarbeiter, die in ein neues Umfeld mit vielen neuen unbekannten Begriffen kommen, erstellen sich solche Listen.

Das Sammeln von Begriffen kann man ggf. durch Wettbewerbe mit kleinen Preisen erfolgreicher machen. Ebenso können neue Mitarbeiterinnen und Mitarbeiter – die natürlich in ihrem Einarbeitungspaket das Business Glossar bekommen haben – das vorhandene Glossar auf Lücken prüfen. „Neulinge“ erkennen oftmals eher die Lücken bzw. fehlende Begriffe, die für „Alteingesessene“ Standard sind und deshalb nicht für das Glossar vorgesehen wurden.

Nach einer gewissen Zeit der Sammlung und Verarbeitung wird ein Business Glossar dann wahrscheinlich stabil werden, d. h. neue Einträge werden seltener. Die regelmäßige Sichtung und Prüfung bestehender Einträge auf Aktualität und Korrektheit ist aber dennoch notwendig.

Erfolgsmessung – auch für ein Business Glossar?

Da es bei und mit Daten immer auch um KPIs und das Messen der Zielerreichung geht, stellt sich diese Anforderung durchaus auch für ein Business Glossar. Um den Nutzen eines Glossars zu messen, verwenden wir Kennzahlen wie etwa die folgenden:

  • Anzahl – bzw. besser: Anteil von vollständig beschriebenen Glossar-Begriffen: „Vollständig“ wäre hier eine ausreichend detaillierte Erläuterung – diese Definition von „vollständig“ muss leider vage bleiben, da sie sich m. E. nicht in „Anzahl Worte“ o. ä. messen lässt. Alternativ oder zusätzlich setzen wir auf Interaktion durch die Anwenderinnen und Anwender. Diese bewerten dabei Glossarbegriffe („like“ oder „dislike“ oder andere Wertungen). Dann könnte die Messung wie folgt sein:
  • Anzahl – bzw. besser: Anteil von Glossar-Begriffen mit positiver Like-Quote – also Begriffe, die mehr „like“ als „dislike“ haben. Glossar-Einträge, die gar keine Reaktion haben, werden als „negativ“ gewertet.
  • Anzahl – bzw. besser: Anteil von geänderten Glossar-Begriffen im Auswertezeitraum: Darüber ist zu erkennen, wie regelmäßig Aktualisierungen von Glossar-Einträgen erfolgen. Nachteil bzw. Herausforderung hierbei ist aber, dass im Grunde Glossar-Begriffe sich nach ihrer Fixierung nicht mehr wirklich ändern sollten. Daher ist eher folgende Kennzahl sinnvoll:
  • Durchschnittliches Alter seit letzter Revision der Glossar-Begriffe. „Alter“ wird hier nicht über Anlagedatum, sondern über ein Revisionsdatum ermittelt. Zum Revisionsdatum wird der Glossar-Begriff gesichtet und entweder aktualisiert und bestätigt oder als weiterhin korrekt bestätigt. Darüber wird die kontinuierliche Korrektheit und Aktualität von Begriffen sicher gestellt – und mit dieser Kennzahl gemessen.

Diese Liste erhebt nicht den Anspruch auf Vollständigkeit, sondern soll als Einstieg und Anregung für weitere Kennzahlen und die Messung generell dienen.

Denn, wie dieser Blog-Text hoffentlich gezeigt hat: ein Business Glossar entsteht nicht von alleine, sondern bedeutet und benötigt Anstrengung und Aufwand. Und der Nutzen soll sich dann eben auch einstellen – was man dann auch messen muss.

Die oben vorgestellten Kennzahlen – in diesem Fall für das Glossar – sind mal eine erste Idee, wie man den Nutzen bzw. den Reifegrad von Data Governance bzw. hier dem Business Glossar messen kann. In einem der nächsten Blog-Beiträge werde ich mal eine umfangreichere Darstellung von Data Governance-KPIs geben. Bis dahin…

#6 – Data Governance Prozesse und Werkzeuge

Veröffentlicht am von
Antworten

Prozesse und Werkzeuge werden benötigt, um das Data Governance-Programm überhaupt „am Laufen“ zu halten. Sie beziehen sich dabei hauptsächlich auf die beiden anderen Kernelemente eines Data Governance-Programms, nämlich zum einen auf die Rollen & Verantwortlichkeiten, zum anderen auf die Richtlinien.

Während Prozesse die jeweiligen Vorgehensweisen, Verantwortlichkeiten und Abläufe festlegen, sind Werkzeuge dazu da, die Prozesse in deren Durchführung zu unterstützen oder gar erst zu ermöglichen.

So kann etwa der Prozess zur kontinuierlichen Messung von Kennzahlen hinsichtlich des Data Governance-Programms (also DG-KPIs) zwar durchaus manuell durchgeführt werden. Es ist jedoch vermutlich einfacher und (bei regelmäßiger Auswertung) effizienter, wenn so viele DG-KPIs wie möglich automatisiert gemessen werden.

Beispiel: Die Durchlaufzeit beim Anlegen neuen Kundenstammdaten ermittelt man entweder manuell per Stichprobe mit Stoppuhr oder die für die Pflege genutzte Software protokolliert die Zeiten. Im zweiten Fall ermittelt sich eine DG-KPI „Durchschnittliche Zeit für die Anlage eines neuen Kundenstammsatzes“ automatisch.

Prozesse vs. Richtlinien

Manchmal wird der Begriff „Prozess“ auch im Sinne von Richtlinien für Daten verwendet, da solche Richtlinien meist auch einen Prozess beschreiben bzw. definieren. Also einen Prozess, wie die Richtlinie durchzuführen ist, um die Regeln und Standards bzgl. der Daten einzuhalten und sicherzustellen.

Das kann man so definieren, dann wären die „Prozesse“, die ich in diesem Beitrag meine, etwas anderes und anders zu benennen.

Ich definiere Data Governance-Prozesse im oben beschriebenen Sinn: die Prozesse, die das Data Governance-Programm bzw. das Data Governance-Team braucht bzw. definiert und vereinbart, um die Data Governance-Aufgaben durchzuführen. Diese Festlegung kann sicherlich auch kritisch oder anders gesehen werden – gerne unterhalb dieses Beitrags kommentieren und eine Diskussion bzw. Austausch beginnen.

Welche Prozesse braucht Data Governance?

Im Folgenden erläutere ich die aus meiner Sicht wichtigsten Prozesse zum Betrieb eines Data Governance-Programms. Manches davon ist „einfach Management“ eines Programms. Einige Prozesse sind jedoch spezifisch für das Data Governance-Programm auszuprägen und für dessen Erfolg m. E. entscheidend.

Rollen und Verantwortlichkeiten etablieren

Das festgelegte Rollen- und Verantwortlichkeitsmodell (ein Vorschlag siehe hier) muss zum Leben erweckt und am Laufen gehalten werden. Konkret bedeutet dies: Rollen besetzen, RolleninhaberInnen in deren Ausgestaltung unterstützen, Zusammenarbeit fördern und bei Wechseln oder Fluktuation die Wiederbesetzung der Rollen sicherstellen. Ohne handelnde Personen wird ein Data Governance-Modell nicht „zum Fliegen“ kommen.
Es ist nicht die alleinige Aufgabe der Data Governance Managerin oder des Data Governance Managers, die Rollenbesetzungen sicherzustellen. Die Verantwortung hierfür liegt beim Data Executive. Das Werben, Gewinnen, Erklären, Motivieren der RolleninhaberInnen ist aus meiner Sicht durchaus in der Zuständigkeit des/der Data Governance ManagerIn.

Organisation und Durchführung Data Governance Board-Meetings

Die benannten Data Owner jeder Datendomäne zusammen mit der/dem Data Executive und der/dem Data Governance Manager bilden das Data Governance Board, siehe auch meinen Beitrag zum DG-Rollenmodell.
Die regelmäßigen Meetings müssen vorbereitet, organisiert, durchgeführt und nachbearbeitet werden. Eine Standard-Agenda ist empfehlenswert. Diese kann auch etwaige Sonderthemen plus ggf. Einbindung von Personen außerhalb des DG-Boards vorsehen. Eine Themen- und Aufgabenliste ist ebenso anzuraten, diese muss geführt, verfolgt und aktuell gehalten werden.

Fehlerbehandlung

Datenfehler, also Verletzungen von Richtlinien, Datenstandards, Qualitätsregeln etc. müssen zeitnah gesichtet und idealerweise schnellstmöglich gelöst werden. Hierfür nutzen Unternehmen i. d. R. ein Ticketsystem; dieses ist meist sowieso schon vorhanden und kann dann wird dann auch für die Behandlung von Datenfehlern genutzt oder erweitert.
In einer weiteren Ausbaustufe wird das Data Governance-Programm hier dann ggf. überlegen, ob Reaktions- und Lösungszeiten (als sog. „service levels“) vereinbart werden. Dies erfordert natürlich zum einen die entsprechende Etablierung von Lösungsteams, zum anderen kann dies aber auch sowohl die Datenqualität schneller und nachhaltiger verbessern.

Richtlinienmanagement (engl. „Policy Management“)

Die in meinem vorigen Beitrag erläuterten Richtlinien und Datenstandards definieren Vorgaben. Diese müssen sowohl strukturiert erstellt, verteilt und überwacht werden. Zum einen muss festgelegt werden, welche Rollen/Abteilungen in die Definition einer jeweiligen Richtlinie einzubinden sind. Zum anderen muss insbesondere auch die Verteilung und Kommunikation der Richtlinie vorab definiert werden. Eine Richtlinie einfach nur bspw. im Intranet abzulegen dürfte in den meisten Fällen nicht ausreichend sein.

Datenqualitätsmanagement

Ein Hauptziel von Data Governance-Initiativen ist oft die Verbesserung der Datenqualität. Eine entsprechende Richtlinie dazu diverse Dinge fest:

  • Strategie für Datenqualität: Wo messen, wo verbessern/ändern, wie messen, Verantwortlichkeiten
  • Definition von Data Quality Indicators (DQI)
  • Messen von Data Quality: Werkzeuge, Verfahren
  • Überwachen: Prozess der Überwachung, wie wird mit DQ-Fehlern umgegangen, Ticketverarbeitung
  • Optimieren: Verfahren für notwendige Datenkorrekturen

Kommunikation

Das Data Governance-Team sollte sowohl das DG-Programm selbst als auch die dazu definierten und besetzten Rollen proaktiv in der Organisation kommunizieren. Erzielt das Data Governance-Programm Erfolge durch bspw. objektiv messbar bessere Datenqualität, so sind solche „success stories“ ebenfalls wichtig in der „Außendarstellung“ des Data Governance-Programms.

Weiterhin informiert der Data Governance Manager alle Stakeholder, also sowohl die Rolleninhaber wie Data Owner oder Data Stewards als auch insbesondere das Management regelmäßig über Weiterentwicklungen, Erfolge, aber auch Herausforderungen.

Mit welchen Werkzeugen können die Data Governance-Prozesse unterstützt werden?

Um die oben beschriebenen DG-Prozesse zu unterstützen, setzt das Data Governance-Team verschiedene Werkzeuge ein:

  • Dokumentation- bzw. Office-Software: Erstellen von Dokumenten, Präsentation für Stakeholder etc.
  • Kommunikationssoftware, bspw. für Intranet-Seiten: Darstellung des Data Governance-Programms für die gesamte Organisation
  • Spezielle Data Governance-Software mit Funktionen für Metadaten Management, Profiling oder Glossar-Verwaltung
  • Policy Management: Software zum Verwalten, Publizieren und ggf. Überwachen von Richtlinien

Diese Aufstellung ist sicherlich sehr grob und verkürzt. Da jedoch die jeweiligen Werkzeuge verschiedene Funktionen anbieten (oder eben auch nicht) oder auch ggf. zusammenfassen, ist eine weitere allgemeine Detaillierung wenig sinnvoll. Ich werde in einem der folgenden Beiträge konkreter auf einzelne Werkzeuge eingehen, ggf. auch eine Übersicht machen.

Im nächsten Blog-Beitrag werde ich die vielfach schon erwähnten „Datendomänen“ näher betrachten: was ist eine Datendomäne, wie sind Datendomänen strukturell definiert und welche unterschiedlichen Datendomänen findet man klassischerweise in Organisationen.

#5 – Richtlinien als Mittel zur Durchsetzung von Data Governance

Veröffentlicht am von
Antworten

Daten sind bzw. werden nicht „von alleine“ gut und Datenqualitätsprobleme lösen sich nicht von alleine. Ferner ändern sich auch Verhaltensweisen nicht von alleine und das Vertrauen darauf, dass alle involvierten Personen „es schon richtig“ machen, ist eher „gewagt“. Und schließlich können nicht alle notwendigen Regeln und Vorgaben durch Software oder Technik erzwungen werden. Somit ist es notwendig, manche „data standards“, also Regeln, Vorgaben, Standards zur Verwaltung und Nutzung von Daten anderweitig zu etablieren. Hierfür bietet sich der Begriff der „Richtlinie“ (engl.: policy) an: eine Richtlinie ist eine von der Organisation formal vorgegebene Verhaltensweise, die von allen Mitarbeiterinnen und Mitarbeitern einzuhalten ist. Und die in unserem Fall dazu dient, die Ziele von Data Governance durchzusetzen.

Je nach Ausprägung und Definition innerhalb der Organisation sind Richtlinien bindend für alle in der Organisation tätigen Personen (also sowohl Festangestellte als auch Externe oder Zeitarbeiter oder sonstige). Im Extremfall sind Richtlinien durchaus auch bzgl. Arbeitsvertrag wirksam, d. h. ein Verhalten, das nicht den Richtlinien entspricht, wird möglicherweise sanktioniert werden.

Formale Kriterien für Richtlinien

Zunächst muss definiert werden, wie Daten-Richtlinien aussehen und dokumentiert werden. Dies kann auf verschiedene Arten erfolgen:

  • Formale Prozessbeschreibung mit einer idealerweise grafischen Prozessdefinition, Zuordnung von Rollen und Verantwortlichkeiten und klarer Beschreibung, wer was in welchem Prozessschritt zu tun hat. Als Beispiel nehmen wir die Vergabe von Berechtigungen auf Daten: Person erstellt Anfrage/Anforderung nach Datenzugriff, die Anforderung geht an einer definierten Stelle ein, wird dort geprüft, es wird eine Freigabe von einer weiteren Stelle/Rolle angefordert und nach deren Erteilung wird die Berechtigung eingerichtet und die Anfordererin oder der Anforderer entsprechend informiert.
  • Textuelle Beschreibung: Sind Abläufe nicht klar beschreibbar, kann eine textuelle Beschreibung genutzt werden, ähnlich dem Text im vorigen Punkt. Hier ist auf Eindeutigkeit, Klarheit und Vollständigkeit zu achten.

Richtlinien müssen Entscheidungsverfahren definieren

Je klarer und somit formaler solche Beschreibungen sind, desto besser. Jedoch kann es trotz aller Klarheit und Struktur in jeder solchen Vorgabe Konstellationen geben, die einen Konflikt erzeugen bzw. eine Klärung und Entscheidung erfordern.

Beispiel: Ist der Stammsatz eines Geschäftspartners sowohl als Kunde als auch als Lieferant in Verwendung und wir ändern Stammdaten-Attribute, kann ein Konflikt entstehen: Der Einkaufsbereich möchte die Schreibweise der Anschrift ändern oder eine andere Bankverbindung hinterlegen, während der Vertriebsbereich diese Änderung aus Kundendaten-Sicht kritisch sieht.

Für solche „Konflikt-Potenziale“ sollte jede Richtlinie entsprechende Verfahren definieren:

  • Wie werden Entscheidungen getroffen? Im Konsens, Mehrheitsentscheidung, eine Person entscheidet?
  • Welche Eskalationsstufen gibt es? Wann wird jeweils auf die nächste Stufe eskaliert?
  • Wer ist je Eskalationsstufe anzusprechen und wie wird dann jeweils entschieden?

Kategorien von Daten-Richtlinien

Um die Vorgehensweise und Umsetzung der Richtlinien besser planen und dann auch angehen zu können, ist es sinnvoll, Kategorien zu definieren, für die Richtlinien sinnvoll / notwendig sein können. Nachfolgend ein Vorschlag, welche Kategorien von Daten-Richtlinien sinnvoll sein können:

  • Data Integration: Diese Kategorie fokussiert auf Datenintegrationsprozesse im BI- und DWH-Kontext. Dort werden regelmäßig Daten aus verschiedenen operativen Systemen in ein zentrales Data Warehouse transferiert. Richtlinien definieren hier, wie solche Integrationsprozesse generell ablaufen hinsichtlich Architektur (Welche Software? Punkt-zu-Punkt-Integration oder Middleware-Architektur? etc.), Protokollierung, Ladelogik, Fehlerbehandlung etc.
  • Metadata Management: Wo werden Metadaten gesammelt und verwaltet? Was soll/muss je System an Metadaten definiert werden, damit ein sinnvolles Metadaten-Management möglich ist? Was soll mit Metadaten-Management erreicht werden?
  • Business Data Model (BDM): Unter dieser Überschrift können Dinge zusammengefasst werden wie Datendefinitionen (wie werden diese vorgenommen, Struktur, Vorgehen etc.), KPI-Definitionen oder die Definition von Dimensionen/Stammdaten,
  • Data Modeling: Hier werden Richtlinien definiert, um die Modellierung von Datenstrukturen zu optimieren und einheitliche Standards zu etablieren. Neben allgemeinen Modellierungsrichtlinien (ER-Modellierung mit/ohne Normalformen, Data Vault im Enterprise DWH, Star Schema für Data Marts o. ä.)
  • Business Glossary: Sammeln, klassifizieren, prüfen und freigeben von Glossarbegriffen für die Organisation – wer entscheidet, wer gibt frei?
  • Data Security & Authorization: Wie werden Zugänge zu Daten geregelt, beantragt, freigegeben? Wer entscheidet über die Erteilung von Zugriffsberechtigungen? Wie wird mit Berechtigungen im Falle von Abteilungswechsel oder Austritt umgegangen?
  • Data Sensitivity Classification: Verfahren und Struktur der Klassifikation von Daten in Sensitivitätskategorien wie bspw. „offen“, „geheim“, „nur intern“ etc.
  • Reference Data Management: Referenzdaten wie Liste der Länder, Region, Branchenschlüssel werden gepflegt und aktuell gehalten. Hierfür sollten Zuständigkeiten und Verfahren der Verwaltung und Nutzung definiert werden. Ferner sind Referenzdaten idealerweise nur an einer Stelle zentral verwaltet und werden mehrfach in allen relevanten Systemen genutzt.
  • Data Maintenance Processes: Definition der Pflegeprozess, insbesondere mit Bezug zu Qualitätsregeln und Governance-Schritte bzw. -Vorgaben.
  • Data Quality Management: Vorgehen, Prozesse und Verantwortlichkeiten zur Definition, Überwachung und Optimierung der Datenqualität.
  • Information Lifecycle Management: Definition des Lebenszyklus von Daten diverser Datendomänen sowie dessen organisatorische, fachliche und technische Prozessierung.

Einzelne Elemente dieser Liste können wir ggf. zusammenfassen oder auch weiter aufteilen. In weiteren Blog-Beiträgen werde ich mal einzelne Policies beispielhaft detaillieren.

Im nächsten Beitrag geht es aber zunächst noch um den dritten Baustein eines Data Governance-Rahmenwerks, nämlich die Data Governance-Prozesse und -Werkzeuge.

#4 – Rollen und Verantwortlichkeiten in Data Governance

Veröffentlicht am von
Antworten

Um alle im vorangegangenen Blog-Beitrag beschriebenen Elemente von Data Goverance bearbeiten zu können, müssen klare Verantwortlichkeiten und Rollen definiert werden. Dies ist umso relevanter, je mehr Datendomänen in einer Organisation vorliegen und je komplexer die Pflege- und Nutzungsprozesse der Daten sind.

Zunächst gebe ich anhand des RACI-Schemas einen kurze Beschreibung, wie Verantwortlichkeiten definiert und dargestellt werden können. Über die Zuordnung von verschiedenen Ebenen der Verantwortlchkeit in einem Data Governance-Programm beschreibe ich dann einen Vorschlag eines konkreten Rollenmodells für Data Governance.

Arten und Darstellung von Verantwortlichkeiten

Verantwortung als die Übernahme von Rechten und Pflichten betrifft bzgl. Data Governance ebendieses für bestimmte Daten bzw. Daten-Domänen. Diese Verantwortung äußert sich dann bspw. darin, die Struktur und/oder die Inhalte von Datenelementen einer Daten-Domäne vorzugeben bzw. zu entscheiden, welche Daten gespeichert werden und welche nicht.

Verantwortung kann unterschiedlich vergeben bzw. übernommen werden. Für die Zwecke dieser Darstellung relevant scheinen mir zwei Unterscheidungen:

  • Rechenschaft (engl. „accountability“) als Management-Verantwortung einer Entscheiderin oder eines Entscheiders zu allen für die Daten-Domäne relevanten Themen. Die Person mit „accountability“ entscheidet formal und ist letztlich auch Eskalationsinstanz, falls andere Rollen/Personen innerhalb der Daten-Domäne einen Konflikt nicht alleine lösen können.
  • Zuständigkeit (engl. „responsibility“) ist dann die Verantwortung für die Durchführung aller notwendigen bzw. definierten Tätigkeiten innerhalb der Daten-Domäne. Während die zuständige Person bspw. die Anbindung externer Daten zur Anreicherung und Qualitätsverbesserung durchführt bzw. die Daten beschafft, wir die Management-Ebene mit Rechenschafts-Verantwortung die Entscheidung treffen, welcher Datenanbieter für die externen Daten beauftragt wird.

Werden diese zwei Verantwortlichkeiten noch um „beratend“ und „informiert“ (engl. „consulted“ und „informed“) erweitert, ergibt sich mit den Anfangsbuchstaben der englischen Begriffe das so genannte „RACI-Schema“. Mit diesem Schema könnten Aufgaben gemäß der dafür definierten Verantwortlichkeiten bewertet werden. Je Aufgabe gibt es eine Person oder Rolle mit Rechenschaft („accountability“) und idealerweise auch nur eine Person/Rolle mit Zuständigkeit („responsibility“); Beratung und Information können mehrere Personen/Rollen haben. Mehr Details zum RACI-Schema sind bspw. in Wikipedia zu finden.

Über eine RACI-Zuordnung werden somit die Verantwortungen für alle in unserem Fall für Data Governance relevanten Aufgaben übersichtlich festgelegt. Für diese Zuordnung von R, A, C und I werden nun Personen oder abstrakt Rollen benötigt. Welche Rollen sind nun vorzusehen? Um dies näher betrachten zu können, ist zunächst eine Unterscheidung in verschiedene Ebenen der Verantwortlichkeiten sinnvoll.

Ebenen der Verantwortlichkeiten

Wir unterscheiden zunächst vier Ebenen, beginnend von der strategischen Betrachtung bis hin zur Anwender-Ebene.

Strategische Ebene

Die strategische Ebene ist im Management-Bereich der Organisation anzusiedeln. Entweder gibt es eine im Vorstand oder der Geschäftsleitung direkt verantwortliche Person oder der gesamte Vorstand oder die gesamte Geschäftsleitung ist für die Festlegung von Zielen, Richtung und Prioritäten für Datenthemen und Data Governance sowie die finale Entscheidung bei Konflikten zuständig. Die strategische Ebene benennt auch die weiteren Rollen zumindest der direkt darunter liegenden Ebene

Taktische Ebene

Auf der taktischen Ebene ist vor allem die Verantwortung für die Daten-Domänen angesiedelt. Für Daten-Domänen wie „Kunde“ oder „Material“ müssen fachliche und inhaltliche Vorgaben gemacht und Entscheidungen getroffen werden. Dies erfordert dann auch das Setzen von Prioritäten, das Definieren und Finanzieren von Projekten sowie das Eskalationsmanagement bei Konflikten zu Themen innerhalb der Daten-Domäne.

Zusätzlich ist auf dieser Ebene auch die generelle inhaltliche und konzeptionelle Verantwortung für Data Governance an sich angesiedelt. Hierzu wird i. d. R. die Rolle des Data Governance Managers definiert und besetzt.

Operative Ebene

Operative Tätigkeiten und Verantwortungen sind jeweils innerhalb einer Daten-Domäne zu etablieren. Dabei geht es dann um konkrete inhaltliche Themen wie die Definition von Datenstrukturen und Festlegung der Inhalte. Weiterhin ist Ableitung von Datenqualitätsvorgaben und -Regeln zur Messung und Verbesserung der Datenqualität wichtig.

Anwender-Ebene

Die Anwender-Ebene schließlich umfasst alle Personen und Rollen, die Anwender oder Produzenten von Daten sind. Dies können Sachbearbeiterinnen und Sachbearbeiter für die Stammdaten oder auch IT-Administratoren für die genutzten Software-Systeme sein.

Ebenen der Verantwortlichkeiten bei Data Governance

Vorschlag eines Rollen-Modells

Aus dieser Ebenen-Unterteilung der Verantwortlichkeiten wird nun ein Rollenmodell abgeleitet bzw. wir definieren Rollen und ordnen diese den Ebenen zu.

  • Data Executive: Die strategische Ebene wird durch die Rolle „Data Executive“ besetzt bzw. – da nur eine Rolle auf dieser Ebene direkt angesiedelt ist – gebildet. Die Rolle kann von einem Vorstands- oder Geschäftsführungsmitglied besetzt werden. Oder es gibt gar eine oder einen „Chief Data Officer“ (CDO) oder „Chief Digital Officer“ (ebenfalls CDO). Oftmals wird hier auch die bzw. der CIO zugeordnet – weil Daten = IT und damit IT-Bereich.
  • Data Owner: Die Data Owner als rechenschaftspflichtige Rollen auf der taktischen Ebene übernehmen die Verantwortung für Daten-Domänen.
  • Data Governance Manager: Neben den Data Ownern ist weiterhin die Ausprägung einer Rolle „Data Governance Manager“ auf der taktischen Ebene sinnvoll, siehe Ausführungen oben.
  • Lead Data Steward: Auf der operativen Ebene verantwortlich (als Zuständigkeit) ein (oder mehrere) Lead Data Stewards je Daten-Domäne die Inhalte und Struktur der Datenelemente der Daten-Domäne. „Lead DS“ sind darüber hinaus zuständig für die Planung und Durchführung von Aufgaben und Projekten „in der Daten-Domäne“ – sowohl inhaltlich als auch bzgl. der Ressourcen (Mitarbeiter, Hardware, Software, Budget). Und schließlich steuern sie die Local Data Stewards, sofern vorhanden.
  • (Local) Data Stewards: Lokale Data Stewards bzw. (falls die Organisationsstruktur keine Verteilung sinnvoll erscheinen lässt) „normale“ Data Stewards unterstützen die bzw. den Lead Data Steward in spezifischen Themen oder vertreten eine lokale bzw. für den Organisationsbereich relevante Sichtweise.

Dieses Modell der Data Governance-Rollen kann nun beliebig verfeinert oder vereinfacht werden. In jedem Fall lässt sich sagen, dass mindestens die Rollen

  • Data Executive
  • Data Owner (mehrere)
  • Data Governance Manager

unerlässlich sind, um überhaupt mit Data Governance loslegen zu können.

Fragestellungen wie bspw. „Eine bzw. einen Lead Data Steward je Daten-Domäne oder mehrere?“ sind jeweils im Details zu bewerten und zu entscheiden. Vielleicht mache ich dazu später einen Blog-Beitrag…

Wofür ich auf jeden Fall einen Blog-Beitrag machen werde: Was ist Daten-Domäne? Ich habe in diesem Beitrag hier sehr oft diesen Begriff verwendet, eine Definition aber (hoffentlich elegant) umschifft. Stay tuned, kommt in einem der nächsten Blog-Beiträge…

#1 – Welche Folgen hat fehlende Data Governance?

Veröffentlicht am von
Antworten

Wenn eine Organisation die von ihr erzeugten und genutzten Daten nicht bewusst nutzt und dafür Regeln, Richtlinien und Vorgehensweisen vereinbart, um die Qualität dieser Daten sicherzustellen, kann das diverse negative Auswirkungen haben. Diese können durchaus weit über die eigentliche „Datensituation“ hinaus gehen.

Bevor wir uns hier intensiver mit Data Governance beschäftigen, ist es hilfreich, einige dieser möglichen negativen Auswirkungen zu kennen. Dazu haben sich Analysten und Beratungsunternehmen bereits Gedanken gemacht und Umfragen durchgeführt.

Einige Zahlen

So hat BARC eine bis zu 72% reduzierte Mitarbeiterzufriedenheit durch unzulängliche Data Governance identifiziert. Gartner verweist auf 25% verminderte Umsatzzuwächse auf Grund fehlender Daten-Richtlinien. Und Leadjen hat bis zu 28% weniger Zeit für Verkäufer durch fehlende Data Governance errechnet.

Ob diese Zahlen nun exakt stimmen oder sie eher als Anhaltspunkte dienen: sie verweisen auf einige Grundprobleme, die durch eine nicht strukturierte „Behandlung“ von Daten entstehen:

  • Zeitverlust für Mitarbeiter beim Verwenden von Daten, weil die Daten bspw. nicht oder nur aufwändig zu finden und zu nutzen sind. Oder weil Daten unvollständig oder falsch sind. Oder weil deren Inhalte und Bedeutung unklar sind.
  • Durch dieses manuelle Suchen nach den richtigen Daten und Informationen steigt die Unzufriedenheit. Mitarbeiter haben dadurch weniger Zeit für ihre eigentlichen Aufgaben.
  • Schlechte Daten wirken sich auf die Haupttreiber jedes Unternehmens aus:
    • Umsatzsteigerung: Unvollständige Daten von Kunden oder potenziellen Kunden erschweren oder verhindern Neugeschäft oder Cross-Selling. Mangelhafte Kontaktdaten führen zu hoher Anzahl von Rückläufern in Kampagnen etc.
    • Kostenreduktion: Nicht korrekte Kunden- oder Lieferantendaten verhindern die Automatisierung von Rechnungsprüfungen. Nicht aktuelle oder fehlerhafte Lagerinformationen resultieren in noch nicht notwendigen Nachbestellungen und damit verbundener Kapitalbindung
    • Regeleinhaltung (Compliance): Löschanforderungen zu personenbezogenen Daten (Art. 17 DSGVO) können nur korrekt durchgeführt werden, wenn diese Daten auch aufgefunden werden können.

Damit diese drei Treiber mit Daten richtig unterstützt werden, ist eine durchgängige Data Governance das Mittel der Wahl. Im nächsten Blog-Beitrag werde ich Data Governance grundsätzlich beschreiben. Danach schauen wir uns die einzelnen Elemente genauer an.

#0 – Herzlich willkommen!

Veröffentlicht am von

Herzlich Willkommen auf den Themen- und Blog-Seiten des Data Governance-Managers.

„Daten sind das neue Öl“ – „Das datengetriebene Unternehmen“ – „Digitale Transformation“ – es scheint, als ob Daten das neue (oder auch nicht mehr so neue) Wundermittel für Unternehmens-Erfolg sind. Begriffe wie Business Intelligence, Analytics oder Big Data sind nicht mehr nur in Fachmagazinen oder Expertenrunden zu finden, sondern auch in Tageszeiten oder Fernsehnachrichten.

Wenn nun aus Daten Erkenntnisse gewonnen und Nutzen gezogen werden soll, müssen diese Daten entsprechend zielführend verarbeitet und ausgewertet werden. Damit die Auswertungen und die Analyse der Daten auch sinnvoll ist und qualitativ hochwertige Daten hierfür Verwendung finden, muss etwas getan werden: Daten müssen vollständig ermittelt, sauber strukturiert, korrekt eingegeben und logisch richtig korreliert und auswertet werden.

All dies passiert nicht von alleine. Ein Unternehmen überlässt seinen finanziellen Erfolg nicht dem Zufall, sondern behandelt alle finanziellen „assets“, also Vermögensgegenstände, entsprechend fokussiert und vollumfänglich. Soll mit Daten ein Nutzen geschaffen und Wert daraus gezogen werden, müssen auch Daten als „asset“ behandelt werden.

Dies ist das Ziel und die Aufgabe von Data Governance!

Diese Webseite und mein Blog behandeln, beschreiben, diskutieren das Thema „Data Governance“ – und natürlich alle anverwandten und verbundenen Themen wie Datenmanagement, Data Warehouse, Business Intelligence oder Analytics.

Wenn für den Besucher dieses Blogs etwas interessantes dabei ist, freue ich mich – auch über Kommentare, Kritik, Rückmeldung.

Der erste Blog-Beitrag ist dann direkt schon hier…

#7 Datendomänen – eine Strukturierung des Datenuniversums

Veröffentlicht am von
Antworten

In einer Organisation gibt es sehr viele, sehr unterschiedliche Arten von Daten. Stammdaten wie Kunden und Mitarbeiter, Bewegungsdaten wie Rechnungen und Aufträge oder Referenzdaten wie die Standorte-Liste oder das Postleitzahlen-Verzeichnis. Diese Vielzahl von Datenarten zu beherrschen und effizient und effektiv zu verwalten kann sehr herausfordernd sein. Um die Komplexität des Daten-Universums meistern zu können, strukturieren wir Daten in so genannten „Domänen“. Eine Datendomäne ist dabei ein inhaltliche Zusammenfassung gleichartiger Datenelemente.

Was bedeutet das genau? Wie definiert man Datendomänen und was ist der Nutzen der Strukturierung in Datendomänen?

Charakteristiken einer Datendomäne

Eine Datendomäne ist eine logische Gruppierung von Datenobjekten, die einen engen inhaltlichen Bezug zueinander haben. Eine Datendomäne ist dabei nach drei Dimensionen definiert:

  • Struktur: Welche Geschäftsobjekte und Attribute (der Geschäftsobjekte) gehören zu einer Datendomäne? Beispiel: Die Geschäftsobjekte „Kundenadresse“ und „Debitoren-Steuernummern“ werden (neben anderen Geschäftsobjekten) zu einer Datendomäne „Kunde“ zusammengefasst. Im Geschäftsobjekt „Kundenadresse“ sind u. a. Attribute wie „Name“, „Straße“, „PLZ“ und „Ort“ definiert.
  • Verhalten: Datenobjekte der Datendomäne und deren Inhalte werden angelegt, geändert und genutzt. Für die Datendomäne müssen die Verwaltungs- und die Nutzungsprozesse definiert sein. Die Nutzungsprozesse bestimmen die Anforderungen an die Daten, während die Verwaltungsprozesse sicherstellen, dass diese Anforderungen durch die Daten auch erfüllt werden. Beispiel: Der Nutzungsprozess „E-Mail Marketing“ benötigt zu jedem Kunden eine E-Mail-Adresse. Dies muss der Verwaltungsprozess in der Kundenstamm-Pflege entsprechend sicherstellen, Lücken ggf. schließen sowie fehlerhafte E-Mail-Adressen erkennen und korrigieren.
  • Inhalt: Festlegungen, welche Inhalte in den Objekten der Datendomäne gespeichert werden. Je Datenobjekt und je einzelnem Attribut bzw. Feld eines Datenobjekts muss eine solche Festlegung erfolgen. Dies betrifft sowohl Syntax (Länge eines Textfeldes, Anzahl Nachkommastellen einer Dezimalzahl) als auch die Werte an sich, wie bspw. erlaubte Werte, Wertebereich (größte und kleinste zugelassene Zahl oder erlaubter Datumsbereiche. Diese inhaltlichen Festlegungen können dann auch genutzt werden, um Datenqualitätsregeln bzw. Datenqualitäts-Kennzahlen zu definieren und zu messen. Näheres hierzu schreibe ich in einem späteren Blog-Beitrag.

Verantwortung wird Datendomänen zugeordnet

Jede Datendomäne hat spezifische Eigenschaften und an sie gestellte Anforderungen. Damit ist die Ebene der Datendomäne die richtige Stelle, um Verantwortlichkeiten für Daten festzulegen und zuzuordnen.

Somit hat jede Datendomäne eine verantwortliche Entscheiderin oder einen verantwortlichen Entscheider, nämlich die oder den Data Owner. Weiterhin braucht jede Datendomäne eine inhaltliche Verantwortung, die der oder die Data Steward übernimmt. Diese Rollen habe ich in meinem Blog-Beitrag #4 – Rollen und Verantwortlichkeiten in Data Governance ausführlich erläutert. Data Owner und Data Steward werden somit je Datendomäne definiert. Eine Datendomäne ist das „Konstrukt“, auf dem oder bzgl. dem wir Richtlinien definieren, Standards etablieren und Datenqualität messen.

Typische Datendomänen

In jeder Organisation gibt es unterschiedliche Datendomänen. Es kommt auch vor, dass inhaltlich gleiche Datendomänen in einer Organisation anders bezeichnet werden als in einer anderen Organisation.

In Versicherungsunternehmen ist beispielsweise der Begriff „Partner“ für die Daten von Kunden und anderen Geschäftspartnern etabliert, während andere Organisationen dafür vielleicht den Begriff „Kunde“ verwenden. Wirtschaftsunternehmen verwalten Daten zu Produkten und/oder Dienstleistungen sowie zu Kunden und Lieferanten, während Behörden möglicherweise nicht von „Kunden“, sondern von „Bürgern“ sprechen.

Im Folgenden liste ich einige Datendomänen auf, die unter dem angegebenen oder einem anderen Titel in Organisationen vorkommen:

  • Kunde: Daten zu den Kunden einer Organisation mit Informationen wie Name, Adresse, Steuernummern, Bankverbindung, Branche, Umsatz des Kunden, Anzahl Mitarbeiter, Ansprechpartner
  • Material oder Produkt: Daten zu den „Dingen“, die ein Unternehmen verkauft oder auch einkauft mit Attributen wie Name, Beschreibung, Gewicht, Maße, Material, Gruppierung
  • Mitarbeiter: Informationen zu den Mitarbeiterinnen und Mitarbeiter einer Organisation mit Attributen wie Name, Eintrittsdatum, Adresse, Bankverbindung, Geschlecht, Religion, Geburtsdatum oder Arbeitsort

Mit dem Fokus auf seine bzw. ihre Datendomäne können Data Owner und Data Stewards strukturiert und fokussiert ihre Datenwelt strukturieren, steuern und verbessern. Ohne eine solche Einteilung in Bereiche – also Datendomänen – ist das große „Universum der Daten“ kaum handhabbar. Ferner wird das Zuweisen von klaren Verantwortlichkeiten schwierig, wenn der Verantwortungsbereich nicht benannt und abgegrenzt werden kann.

Für eine Datendomäne können nun Data Owner und Data Stewards erste Aktivitäten starten. Dies kann bspw. die Befüllung eines Glossar von Begrifflichkeiten sein, die für die Datendomäne relevant sind. Warum das sinnvoll und wichtig ist, wie man dazu vorgehen kann und welchen Nutzen das hat, darauf gehe ich in meinem nächsten Blog-Beitrag ein.