Verantwortung finden und verankern

Begriffe vor dem Lesen

• Data Owner — Fachlich verantwortliche Rolle für Bedeutung, Zweck, zulässige Nutzung und Risikoentscheidungen eines Datenprodukts.
• Data Steward — Bereitet Entscheidungen vor, pflegt Definitionen und Qualitätsregeln und verfolgt offene Konflikte.
• Data Custodian — Setzt freigegebene Regeln technisch um, etwa durch Zugriffe, Prüfungen oder Sperren.
• Entscheidungsrecht — Klar benannte Befugnis, zu einer abgegrenzten Frage Ja oder Nein zu sagen.
• Nachweis — Auffindbarer Beleg dafür, was entschieden, umgesetzt oder ausnahmsweise zugelassen wurde.

Was eine verantwortliche Rolle wirklich verantwortet

Ein Data Owner besitzt Daten nicht wie Privateigentum. Die Rolle entscheidet beispielsweise, was „aktiver Kunde“ bedeutet, welche Zwecke zulässig sind, welche Qualitätsabweichung noch tragbar ist und wann eine neue Nutzung eine erneute Prüfung braucht. Datenschutz, Informationssicherheit und Legal bringen ihre eigene Fachverantwortung ein; sie werden nicht durch den Data Owner ersetzt.

Technische Teams entscheiden wiederum über eine belastbare Umsetzung innerhalb des freigegebenen Rahmens. Sie dürfen aber nicht still die fachliche Bedeutung verändern, nur weil eine bestimmte Modellierung oder Plattform einfacher wäre. Governance funktioniert, wenn diese Verantwortungen zusammenarbeiten und ihre Grenzen sichtbar bleiben.

Woran gute Verantwortung erkennbar ist

Eine Zuordnung ist erst brauchbar, wenn sie sechs Fragen beantwortet:

1. Welche konkrete Entscheidung ist gemeint?
2. Für welches Datenprodukt und welchen Anwendungsbereich gilt sie?
3. Welche Rolle darf verbindlich Ja oder Nein sagen?
4. Wer liefert fachliche, rechtliche und technische Informationen?
5. Wer setzt die Entscheidung um und prüft ihre Wirkung?
6. Wo bleiben Entscheidung, Ausnahme und Ablaufdatum nachvollziehbar?

Fehlt eine dieser Antworten, ist die eingetragene Person meist nur Kontaktstelle. Ein Organigramm oder eine RACI-Tabelle hilft dann wenig, solange das eigentliche Entscheidungsobjekt unklar bleibt.

Beispiel

Für die Kennzahl „aktive Kunden“ entscheidet der fachliche Owner, welche Vertragszustände zählen. Der Steward dokumentiert Definition, Beispiele und bekannte Grenzfälle. Finance und Sales prüfen die Folgen für ihre Berichte. Das Plattformteam setzt die Regel in der gemeinsamen Kennzahlenlogik um. Ein automatischer Vergleich zeigt, ob lokale Berichte davon abweichen. So wird Verantwortung als Entscheidung, Umsetzung und Nachweis sichtbar.

Für Beratung und Vertrieb

Governance sollte nicht als Übernahme der Kundenverantwortung verkauft werden. Ein gutes Angebot hilft dem Unternehmen, eigene Entscheidungsrechte zu klären, Konflikte moderiert zu lösen und die technische Umsetzung nachweisbar zu machen. Die Fachbereiche behalten ihre Verantwortung; Beratung schafft Struktur, Arbeitsfähigkeit und eine gemeinsame Sprache.

Erster Praxistest

Wählt eine umstrittene Kennzahl oder einen häufig genutzten Datensatz. Formuliert eine echte Ja-Nein-Entscheidung, benennt die verantwortliche Rolle sowie Steward und Custodian und dokumentiert anschließend eine Entscheidung mit ihrer technischen Wirkung. Wenn nur ein Name ergänzt wurde, ist der Test nicht bestanden.

Ausgangslage

Ein Datensatz hat viele Beteiligte: Ein Team erzeugt ihn, ein anderes verarbeitet ihn, mehrere Bereiche nutzen ihn und Datenschutz oder Legal prüfen bestimmte Verwendungen. Die Frage „Wem gehört diese Tabelle?“ führt deshalb oft zur falschen Person. Nähe zum System, hierarchischer Rang und fachliche Entscheidungsbefugnis sind nicht dasselbe.

Begriffe vor dem Lesen

• Entscheidungsfolge — Fachliche oder wirtschaftliche Konsequenz einer Definition, Freigabe oder Ausnahme.
• Domäne — Fachlicher Verantwortungsbereich, etwa Kunde, Produkt, Personal oder Finanzen.
• Kandidat — Rolle, die aufgrund ihres Mandats als möglicher Data Owner geprüft wird.
• Eskalation — Geregelter Weg, wenn mehrere Bereiche betroffen sind oder niemand allein entscheiden darf.

Owner findet man über Entscheidungsfolgen

Beginnt nicht beim Speicherort, sondern bei der Entscheidung. Wer trägt die Folgen, wenn eine Definition falsch ist, eine Nutzung untersagt werden muss oder ein Qualitätsproblem akzeptiert wird? Für Kundensegmentierung kann das Sales oder Marketing sein; für Umsatzrealisierung Finance; für Beschäftigtendaten HR. Das Plattformteam kennt die Technik, besitzt aber üblicherweise nicht das fachliche Mandat.

Ein Datensatz kann mehrere Entscheidungsklassen besitzen. Die Bedeutung einer Kennzahl, die Erlaubnis einer personenbezogenen Nutzung und die technische Zugriffsumsetzung dürfen bei unterschiedlichen Rollen liegen. Das ist kein Fehler, solange jede Entscheidung genau eine accountable Rolle und einen klaren Übergabepunkt hat.

Praktischer Ablauf

1. Datenprodukt und Nutzung eingrenzen. Nennt nicht „Kundendaten allgemein“, sondern etwa „Kundenstatus für Vertriebsforecast und Servicepriorisierung“.
2. Drei strittige Entscheidungen sammeln. Beispiele sind Definition, zulässiger Zweck und akzeptierbare Qualitätsabweichung.
3. Folgen zuordnen. Welcher Fachbereich verantwortet Ergebnis, Prozess oder Bericht, wenn die Entscheidung falsch ist?
4. Kandidaten anhand ihres Mandats prüfen. Kann die Rolle entscheiden, Ressourcen bereitstellen und Konflikte eskalieren?
5. Nachbarrollen benennen. Steward, Custodian, Datenschutz, Security und betroffene Nutzende liefern Input oder setzen um.
6. Mit einem echten Fall testen. Lasst die vorgeschlagene Rolle eine offene Entscheidung treffen. Reicht das Mandat nicht, korrigiert die Zuordnung.

Wenn mehrere Bereiche betroffen sind

Gemeinsame Nutzung bedeutet nicht automatisch gemeinsames Eigentum. Häufig bleibt ein Fachbereich für die Kerndefinition verantwortlich, während ein bereichsübergreifendes Gremium nur Konflikte oder Änderungen mit großer Wirkung behandelt. Vermeidet Gruppenverantwortung ohne letzte Entscheidungsinstanz: „Sales und Finance gemeinsam“ klingt kooperativ, lässt aber bei Uneinigkeit die entscheidende Frage offen.

Typische Fehlzuordnungen

• Die Person mit den meisten Datenbankrechten wird zum fachlichen Owner.
• Die höchste Führungskraft wird eingetragen, obwohl sie die Entscheidung nie praktisch trifft.
• Der Steward erhält Verantwortung ohne das notwendige Mandat.
• Datenschutz soll allein über fachlichen Nutzen entscheiden.
• Für jedes Feld wird eine andere Person gesucht, obwohl die Entscheidung auf Produktebene fällt.

Für Beratung und Vertrieb

Ein Ownership-Workshop sollte keine Namensliste versprechen. Das verkaufbare Ergebnis ist eine belastbare Entscheidungslandkarte: Welche Fragen müssen beantwortet werden, wer besitzt das Mandat, welche Rollen wirken mit und wo wird eskaliert? So entsteht eine Grundlage, die später in Katalog, Datenvertrag und Betriebsprozess übernommen werden kann.

Erster Praxistest

Nehmt ein Datenprodukt mit ungeklärter Verantwortung. Formuliert drei Entscheidungen, ordnet ihre Folgen einem Fachbereich zu und prüft einen Kandidaten an einem offenen Fall. Dokumentiert auch, warum Technik, Stewardship oder ein zentrales Governance-Team nicht automatisch fachlich accountable sind.

Ausgangslage

Wenn jede Spalte eine eigene verantwortliche Person erhält, wird Governance unwartbar. Wird dagegen ein ganzer Unternehmensbereich pauschal für alle Daten eingetragen, entscheidet im Alltag niemand. Eine brauchbare Zuordnung braucht die richtige Ebene: klein genug für eine klare Entscheidung und groß genug für stabilen Betrieb.

Begriffe vor dem Lesen

• Bezugs- und Detailebene — Ebene, auf der eine Verantwortung sinnvoll entschieden und betrieben werden kann.
• Datenprodukt — Abgegrenzte, betreute Bereitstellung von Daten mit Zweck, Nutzenden und Qualitätsversprechen.
• Entscheidungsklasse — Wiederkehrende Art von Entscheidung, etwa Definition, Nutzung, Qualität oder Außerbetriebnahme.
• Stellvertretung — Benannte Rolle, die bei Abwesenheit innerhalb desselben Mandats handeln darf.

Die passende Ebene wählen

Verantwortung liegt meist auf Ebene eines fachlichen Datenprodukts oder einer stabilen Begriffsfamilie. „Kunde“, „Auftrag“ oder „gebuchter Umsatz“ können sinnvolle Grenzen sein. Einzelne technische Tabellen sind häufig nur Implementierungen; ein gesamter Geschäftsbereich ist meist zu grob.

Die richtige Ebene erkennt man daran, dass Änderungen ähnliche Folgen besitzen, dieselbe fachliche Rolle entscheiden kann und Nutzende einen gemeinsamen Zweck erkennen. Haben zwei Felder unterschiedliche Rechtsgrundlagen, Freigabewege oder fachliche Bedeutungen, kann eine Trennung nötig sein. Werden sie nur in verschiedenen Tabellen gespeichert, ist das allein kein Grund für getrennte Ownership.

Rollen getrennt halten

Der Data Owner entscheidet fachliche Bedeutung, Zweck und Risiko. Der Steward bereitet vor, dokumentiert und verfolgt. Der Custodian setzt technisch um. Ein Data Product Owner koordiniert Nutzen, Lieferfähigkeit und Lebenszyklus. Eine Person kann mehrere Hüte tragen, doch die Entscheidungen müssen unterscheidbar bleiben. Sonst wird aus technischer Administrationsmacht unbemerkt fachliche Herrschaft.

Eine belastbare Zuordnung dokumentieren

Haltet je Datenprodukt mindestens fest:

1. Produktname, Zweck und betroffene Nutzende.
2. Entscheidungsklassen des Owners.
3. Abgrenzung zu Datenschutz, Security und Technik.
4. Steward und Custodian für Vorbereitung und Umsetzung.
5. Stellvertretung und Eskalationsweg.
6. Prüfdatum und Auslöser für eine erneute Zuordnung, etwa Reorganisation oder Zweckänderung.

Die Zuordnung gehört an einen auffindbaren Ort und muss mit realen Arbeitsabläufen verbunden sein. Ein Katalogeintrag ohne Ticketweg, Entscheidungsprotokoll oder Übergabe bleibt Dekoration.

Beispiel

Finance verantwortet das Datenprodukt „gebuchter Umsatz“. Der Owner entscheidet Definition, Buchungszeitpunkt und zulässige Berichtszwecke. Ein Steward pflegt Regeln und Grenzfälle. Data Engineering betreibt die Transformation, darf aber die Definition nicht eigenmächtig ändern. Für personenbezogene Detaildaten prüft Datenschutz den zulässigen Zweck. Die Verantwortung endet damit weder an einer Tabellengrenze noch umfasst sie pauschal alle Finance-Daten.

Für Beratung und Vertrieb

Das Ergebnis eines Ownership-Pakets sollte nicht die größtmögliche Matrix sein. Wertvoll sind wenige, klar geschnittene Produkte mit erprobten Entscheidungen, benannten Übergaben und einem Verfahren für Konflikte. Das lässt sich als Discovery, Rollenworkshop und anschließende Verankerung in Katalog und Arbeitsabläufen anbieten.

Erster Praxistest

Wählt ein Datenprodukt mit zu grober oder zu feiner Zuordnung. Schneidet seine Grenze anhand von Zweck und Entscheidungen neu, benennt Owner, Steward, Custodian und Stellvertretung und lasst eine echte Änderung durch diesen Weg laufen. Prüft danach, ob alle Beteiligten dieselbe Verantwortung verstanden haben.