Schlagwort-Archive: Data Governance Manager

#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…

#2 – Was ist Data Governance?

Veröffentlicht am von
Antworten

Der englische Begriff „Governance“ wird nach dict.cc u. a. mit „Regierung“, „Steuerung“ oder „Lenkung“ übersetzt. Das „Steuern“ oder „Lenken“ von Daten bzw. der Nutzung dieser Daten steht somit im Fokus von Data Governance.

Wie auch eine Regierung zum Durchsetzen ihrer Ziele Gesetze und Regeln definiert, so legt auch ein Data Governance-Manager Richtlinien fest, um die Verwaltung und Nutzung von Daten zu steuern und zu lenken. Darüber muss eine Regierung festlegen, wie Entscheidungen sowohl im Regel- als auch im Zweifelsfall durch Exekutive und Judikative durchgesetzt werden. Analog legt Data Governance die Entscheidungsprozesse und Verantwortlichkeiten für datenbezogene Themen fest.

Wer steuert und lenkt?

Da Data Governance „nicht nebenher“ passiert, müssen sich Personen in der Organisation um Data Governance kümmern. Hierfür definiert man dedizierte Rollen. Als Leiter eines Data Governance Programms wird i. d. R. der „Data Governance Manager“ betraut. Dieser definiert das Programm sowie dessen Ziele und Struktur. Ebenso legt er das Organisationsmodell für Data Governance fest, welches diverse weitere Rollen etabliert:

  • Data Owner: Fachliche Verantwortung und Zuständigkeit für eine Datendomäne wie bspw. „Kunde“, „Material“ oder „Rechnung“
  • Data Steward: Fachexpert(en) je Datendomäne, die Inhalte, Struktur, Richtlinien für ihre Datendomäne festlegen und durchsetzen.
  • Data Stakeholders: Alle Anwender und Nutzer von Daten.
  • Data Governance Office, in dem der Data Governance Manager plus einige Data Governance Mitarbeiter zusammen arbeiten

Weitere Details zu den Data Governance-Rollen erläutere ich in einem späteren Blog-Beitrag.

Was lenkt und steuert man mit Data Governance?

Alles, was mit Daten zu tun hat: deren Struktur, deren Inhalte, die Art und Weise wie Daten erzeugt, verarbeitet und weiter genutzt werden. Letztlich betrachtet man den gesamten Lebenszyklus von Daten und strukturiert diesen so, dass eine effiziente Verarbeitung der Daten ermöglicht und eine hohe Datenqualität erreicht wird. Einzelne Themen, die in Data Governance-Richtlinien festgelegt werden, sind bspw.

  • Data Strategy & Architecture
  • Datenintegration (ETL, Transformationen)
  • Metadaten-Management
  • Business Data Model (BDM) & Business Glossary
  • Datenmodellierung
  • Data Quality und Profiling
  • Information Lifecycle Management

Wie macht man das?

Neben der Etablierung eines Organisations- und Rollenmodells beruht Data Governance auf der Definition und Durchsetzung von Richtlinien (engl. „Policies“). Solche Data Policies legen fest, wie etwa die oben genannten Themen in der Organisation gehandhabt werden. So kann eine Richtlinie für Datenmodellierung sicherstellen, dass alle Systeme und Daten in analoger Art und Weise modelliert werden. Dabei wird dann u. a. neben der Notationsmethode (bspw. ER-Modellierung, ADAPT o. ä.) auch die Vorgehensweise mit der Methode selbst (von Namenskonventionen über Modellierungsstandards bis zur Prozesseriung der Modellierung) festgelegt.

Wie misst und überwacht man Data Governance?

Da Richtlinien nur hilfreich sind, wenn sie auch eingehalten werden, ist es wichtig, dass das Data Governance-Team bereits bei der Definition einer Richtlinie deren Überprüfung und Messbarkeit überlegt und festlegt. Damit kann das Team im täglichen Data Governance-Betrieb die Einhaltung der Richtlinien überwachen. Dies erlaubt dem Team das Nachsteuern im Fall von Lücken und insbesondere auch das Nachweisen der Wirksamkeit von Data Governance-Richtlinien.

Die zweite Ebene der Messung in einem Data Governance-Programm fokussiert auf die Qualität der Daten selbst. In Richtlinien zum Data Quality-Management werden Data Quality-Indizes (DQI) zur Messung der Datenqualität festgelegt. Eingebaut in Data Quality-Dashboards zeigen DQIs die Qualität der Daten sowie die Entwicklung dieser Qualität an. Durch die dadurch entstehende Transparenz der Datenqualität sind erst Maßnahmen zur Verbesserung derselben möglich.