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.