Ein vierteljährlicher Personalstandsbericht, dessen Zusammenstellung eigentlich nur einen Vormittag dauern sollte, nimmt stattdessen vier Tage in Anspruch – und zwei dieser Tage verbringt ein Analyst damit, Mitarbeiter manuell neu zu taggen, deren Status sich im Monatsverlauf geändert hat. Der Workflow scheitert nicht daran, dass das HRIS unzuverlässig oder die Tabelle veraltet ist. Er scheitert, weil im Rahmen von Governance-Praktiken der Definition von „aktiver Personalstand“ nie ein Eigentümer zugewiesen wurde, nie dokumentiert wurde, wo sich die Abgleichslogik befindet, und keine Prüfung dafür eingerichtet wurde, was passiert, wenn ein externer Mitarbeiter mitten im Zyklus in eine Vollzeitbeschäftigung wechselt.
Diese Lücke ist weit verbreitet, und sie kostet Arbeitsstunden, nicht nur ein höheres Risiko. Die Lösung ist kein Ordner mit Governance-Richtlinien, den niemand liest. Es handelt sich um eine kleine Reihe konkreter, wiederholbarer Praktiken, die direkt in die Arbeit integriert sind: ein namentlich benannter Eigentümer für jede Governance-Entscheidung, Logik, die nicht nur im Gedächtnis einer einzelnen Person existiert, und Prüfungen, die fehlerhafte Daten abfangen, bevor sie in einen Bericht gelangen, und nicht erst danach.
Bevor Sie weiterlesen, nennen Sie die letzte Governance-Entscheidung, die Ihr Team bezüglich Analysedaten getroffen hat. Wer ist dafür zuständig und wo ist diese Entscheidung niedergeschrieben? Wenn die ehrliche Antwort „niemand“ und „nirgends“ lautet, sind die nächsten drei Abschnitte die Lösung.
Was „Governance für Analystenteams“ tatsächlich bedeutet
Data Governance, die Analysten nutzen, sieht jede Woche gleich aus: Sie ist direkt am Arbeitsplatz sichtbar, einer namentlich genannten Person zugeordnet und wird automatisch überprüft. Es wird nie zu etwas, das auf einem gemeinsamen Laufwerk liegt, anstatt der Bericht selbst zu sein.
Die meisten Governance-Bemühungen scheitern daran, dass sie sich in das Gegenteil verwandeln: in einen Ordner, ein PDF oder einen reinen Compliance-Prozess, den ein einziges Team öffnet und den sonst niemand je zu Gesicht bekommt. Analysten, die den eigentlichen Bericht erstellen, begegnen ihm nie, sodass er keinerlei Einfluss darauf hat, was dieser Bericht enthält. Gartner prognostiziert, dass bis 2027 80 % der Data-and-Analytics-Governance-Initiativen scheitern werden, größtenteils weil die Bemühungen nie mit einem Geschäftsergebnis verknüpft waren, dessen Wegfall jemand bemerken würde.
Um dies zu beheben, ist weder eine Plattformmigration noch ein ständiger Ausschuss erforderlich. Es erfordert drei toolunabhängige Praktiken: einen namentlich benannten Eigentümer für jede Governance-Entscheidung, eine Dokumentation, die der nächste Analyst auch tatsächlich lesen kann, und automatisierte Prüfungen, die fehlerhafte Daten erkennen, bevor sie einen Bericht erreichen.
Schritt 1: Jeder Governance-Entscheidung einen Namen geben
Verantwortung scheitert in dem Moment, in dem sie einem Team statt einer Person zugewiesen wird. „Das Datenteam ist dafür verantwortlich“ beantwortet keine Frage, wenn eine Zahl eine Stunde vor einer Vorstandssitzung falsch aussieht.
Die Lösung beginnt mit einer einfachen Übung: Listen Sie für jeden wiederkehrenden Bericht jede darin enthaltene Ermessensentscheidung auf – beispielsweise, was als „aktiv“ gilt oder wer eine geteilte Definition bearbeiten darf – und weisen Sie jeder Entscheidung genau einen namentlich genannten Eigentümer zu. Keine Abteilung. Keine Rollenbeschreibung. Der Name einer einzelnen Person.
Dieser Name muss auf dem Artefakt selbst stehen, dem Workflow oder dem Bericht, und nicht in einem separaten RACI-Dokument, das nach dem Kick-off-Meeting niemand mehr öffnet. Die Zuständigkeit muss auch personelle Veränderungen überstehen: Die Praxis funktioniert auch dann weiter, wenn die Person, die sie entwickelt hat, zu einer anderen Stelle wechselt.
Richtig umgesetzt kann ein neuer Analyst mit einer einzigen Suche den richtigen Eigentümer für jede Governance-Entscheidung finden, anstatt im Team herumzufragen, bis sich jemand erinnert.
Wie Eigenverantwortung im Alltag aussieht
Ein namentlich genannter Eigentümer wird direkt im Bericht oder Workflow aufgeführt und nicht in einem separaten Dokument abgelegt. Jede Änderung an einer verwalteten Definition wird über diesen Eigentümer weitergeleitet und mit einem Zeitstempel protokolliert. Jemand, der neu im Team ist, kann den richtigen Eigentümer ermitteln, ohne zuerst Kollegen fragen zu müssen.
Wo Inhaberschaft unbemerkt verschwindet
Die Eigentümerschaft geht auf einige vorhersehbare Weisen verloren. Sie wird einer Rolle oder einem Team zugewiesen, wodurch die Verantwortlichkeit zerstreut wird und bei niemandem Bestimmten mehr liegt. Der ursprüngliche Eigentümer verlässt das Unternehmen, und die Entscheidung gehört gleichzeitig allen und niemandem. Oder der Datensatz zur Eigentümerschaft existiert nur auf einer Wiki-Seite oder in einem Onboarding-Dokument, das nach dem ersten Monat nicht mehr aktualisiert wird.
Schritt 2: Notieren Sie die Logik dort, wo die nächste Person sie finden kann
Dokumentation ist keine Wiki-Seite, die in Fließtext zusammenfasst, was ein Bericht tut. Es sind die tatsächlichen Filter, Verknüpfungen und Ausschlussregeln, die offen daliegen, lesbar für jemanden, der sie nicht selbst erstellt hat.
Jede Ausschlussregel benötigt eine einzeilige Begründung genau an der Stelle, an der sie angewendet wird, und sollte nicht in einem separaten Änderungsprotokoll drei Registerkarten entfernt vergraben sein. Die „Data Governance Solutions Wave“ von Forrester für Q3 2025 hat ergeben, dass manuelle Dokumentation nach wie vor eine der am häufigsten von Teams genannten Schwachstellen ist – selbst nach der Einführung von Governance-Tools. Dies erinnert daran, dass die Disziplin wichtiger ist als jedes Tool, das zu ihrer Durchsetzung angeschafft wird.
Eine dokumentierte Regel sollte die Frage „Warum gibt es diesen Filter?“ beantworten, ohne dass ein Meeting mit der Person erforderlich ist, die ihn geschrieben hat. Der Versionsverlauf gehört genau in diese Dokumentation und nicht separat an den Rand: „Was wurde wann geändert?“ erfordert eine nachvollziehbare Antwort und keine Vermutung, die darauf basiert, wer sich daran erinnert, die Datei zuletzt bearbeitet zu haben.
Wie Dokumentation im Alltag aussieht
Der Grund für einen Umwandlungsschritt befindet sich direkt neben dem Schritt selbst, nicht in einem separaten Dokument, nach dem erst jemand suchen muss. Ein neuer Analyst kann jede Zahl im Bericht bis zu ihren Quellfeldern zurückverfolgen, ohne ein Meeting vereinbaren zu müssen. Änderungen an der Logik werden versioniert, sodass die Frage „Warum hat sich das im letzten Monat geändert?“ eine Antwort hat, die nicht von der Erinnerung abhängt.
Wo Dokumentation unbemerkt verschwindet
Dokumentation geht verloren, wenn sich Logik in den ausgeblendeten Hilfs-Registerkarten einer Tabellenkalkulation oder in einem ungeprüften Makro befindet, das seit Jahren niemand mehr geöffnet hat. Manchmal ist „Dokumentation“ in Wirklichkeit eine Rollout-Präsentation, die inzwischen seit Jahren veraltet ist. Und wenn die einzige Person das Unternehmen verlässt, die eine bestimmte Ausschlussregel verstanden hat, wird diese Regel meist ungeprüft weitergeführt, weil niemand die Person sein möchte, die dafür verantwortlich ist, dass eine nicht vollständig verstandene Zahl nicht mehr stimmt.
Schritt 3: Fehlerhafte Daten erkennen, bevor sie den Bericht erreichen, nicht danach
Eine Prüfung, die nicht in den Workflow integriert ist, nicht auf einen bestimmten Fehlermodus abzielt und keinen Eigentümer hat, ist keine Prüfung. Es sieht auf einer Folie nach Sorgfalt aus, ändert aber nichts daran, was tatsächlich ausgeliefert wird.
Effektive Prüfungen zielen auf Fehlerszenarien ab, die das Team bereits erlebt hat: ein Statuscode, der sich während des Zyklus ändert, eine Verknüpfung, die unbemerkt Zeilen verwirft. Generische Vollständigkeitsprüfungen nach dem Motto „Zahlen überprüfen“ erfassen fast nichts davon, weil sie von vornherein gar nicht wissen, wonach sie suchen sollen.
Jede Prüfung erfordert einen namentlich benannten Eigentümer und einen Eskalationspfad. Ein Hinweis, der in einem Posteingang landet, den niemand abonniert hat, ändert nichts am Ergebnis. Die Prüfung muss außerdem im selben Rhythmus wie der Bericht selbst ausgeführt werden und nicht als gelegentliches Audit, das nur stattfindet, wenn jemand daran denkt.
Es gibt einen echten Unterschied zwischen einer Prüfung, die ein Symptom erfasst, und einer, die die Ursache erfasst. Festzustellen, dass Summen sich nicht abgleichen lassen, ist eine Symptomprüfung. Das spezifische verantwortliche Feld oder die zuständige Regel zu benennen, ist eine Ursachenprüfung, und nur die zweite Art verhindert, dass ein Team dasselbe Problem jeden Monat manuell nachbessern muss.
Wie eine echte Qualitätsprüfung aussieht
Eine echte Qualitätsprüfung wird automatisch bei jedem Zyklus durchgeführt, bevor die Zahl irgendwo veröffentlicht wird. Sie kennzeichnet einen spezifischen, bereits bekannten Fehlermodus namentlich, nicht anhand eines allgemeinen Anomalie-Scores. Es gibt einen benannten Verantwortlichen, von dem erwartet wird, dass er innerhalb eines definierten Zeitfensters handelt, nicht erst, wenn er dazu kommt.
Wo Qualitätsprüfungen unbemerkt verschwinden
Qualitätsprüfungen verschwinden auf drei Arten. Die Prüfung existiert in einem Spezifikationsdokument, wurde aber nie tatsächlich in den Workflow eingebunden. Die Prüfung wird ausgelöst, aber niemand hat die Warnmeldung abonniert. Oder die Prüfung weist auf das Symptom hin – Summen stimmen nicht überein –, ohne die Ursache zu nennen, sodass jemand dies bei jedem Durchlauf manuell korrigiert, anstatt es ein für alle Mal zu beheben.
Wie das im Headcount-Bericht eines Teams aussieht
Ein dreiköpfiges People-Analytics-Team im Büro des CHRO eines Unternehmens mit rund 6.000 Mitarbeitenden verantwortet den monatlichen Bericht zum Personalbestand und zur Personalplanung, der an den CFO und den Vorstand geht. Das Team ruft den „aktiven Personalbestand“ aus Workday sowie Stellenausschreibungen aus Greenhouse ab und führt beides in einem Abstimmungsmodell zusammen, das vor drei Jahren in Excel von einem Analysten erstellt wurde, der das Unternehmen vor 18 Monaten verlassen hat.
Hier ist der konkrete Mechanismus, der jeden Monat zu Problemen führt: Auftragnehmer, die in ein Vollzeitbeschäftigungsverhältnis wechseln, behalten ihren ursprünglichen Kostenstellencode für Auftragnehmer, bis der nächste vollständige Lohnabrechnungszyklus mit Workday synchronisiert wird. Diese Verzögerung ist nirgendwo dokumentiert, und sie führt jeden Monat zu einer doppelten Zählung von etwa einem Dutzend Personen, bis jemand bemerkt, dass die Gesamtzahl nicht mit der Zahl der Finanzabteilung übereinstimmt, und jede einzelne Person manuell neu kennzeichnet.
Niemand verantwortet die Entscheidung darüber, wann eine übernommene externe Fachkraft zum Personalbestand zählt. HRBPs gehen davon aus, dass die Finanzabteilung sich darum kümmert. Die Finanzabteilung geht davon aus, dass People Analytics sich darum kümmert. Die Logik, die diese Frage klären würde, befindet sich in einer ausgeblendeten Registerkarte des Excel-Modells, die nur der ausgeschiedene Analyst jemals geöffnet hat.
Die Kosten liegen auf der Hand: Der Bericht wird jeden Monat mit vier Tagen Verspätung abgeschlossen. Zwei dieser Tage entfallen auf manuelles Re-Tagging und zwei weitere darauf, dass Finanzen und People Analytics Summen abgleichen, die eigentlich gar nicht erst hätten voneinander abweichen dürfen.
Jede Lücke lässt sich direkt einem der drei oben genannten Schritte zuordnen. Kein Eigentümer für die Definition des „aktiven Personalbestands“ ist ein Fehler in Schritt 1. In einer Tabellenregisterkarte verborgene Logik, die nur ein ausgeschiedener Analyst verstanden hat, ist ein Fehler in Schritt 2. Keine automatisierte Prüfung der Kostenstellenverzögerung ist ein Fehler in Schritt 3.
Wann eine regulierte Plattform nicht die richtige Wahl ist
Nicht jede Governance-Lücke erfordert eine neue Plattform. Wenn ein Team Daten aus einem einzigen, bereits verwalteten Quellsystem abruft und keine toolübergreifende Zusammenführung stattfindet, kann die Verschärfung der Kontrollen innerhalb dieses einen Systems bereits die gesamte Lösung sein.
Teams, deren Data Engineers bereits eine gut dokumentierte Pipeline mit Versionskontrolle, Lineage und Tests pflegen, die bereits in ein ausgereiftes dbt-Setup integriert sind, würden durch das Überlagern einer Governance-Plattform vorhandene Kontrollmechanismen duplizieren, anstatt einen Mehrwert zu schaffen. In diesem Fall ist ein Ansatz sinnvoller, der auf ein dediziertes Governance-Tool setzt: Ein Katalog wie Atlan oder Collibra, der über die bestehende, manuell programmierte Pipeline gelegt wird und sich an Teams richtet, deren eigentliche Lücke eher in der Sichtbarkeit von Metadaten und Katalogen als in der Zugriffskontrolle auf Workflow-Ebene liegt.
Der ehrliche Diagnosetest ist einfach. Wenn die Lücke „Unsere Pipeline hat keinen Eigentümer und keine Dokumentation“ lautet, hilft eine Plattform, sie zu schließen. Wenn die Lücke „Wir haben Dokumentation, aber niemand setzt sie durch“ lautet, liegt die Lösung in Prozessen und Verantwortlichkeit, nicht in weiteren Tools.
Teams, die vor der Evaluierung einer Plattform ihre eigenen Lücken bei Zuständigkeiten, Dokumentation und Risikoprüfungen erfassen möchten, können mit dem E-Book „Analytics Governance Framework“ von Alteryx beginnen, das dieselben drei Kategorien eingehender behandelt – mit einem Framework zur Überprüfung, wo die einzelnen Aspekte derzeit fehlen.
Was eine geregelte, wiederholbare Umgebung erfordert
Sobald Verantwortlichkeiten, Dokumentation und Prüfungen als Praktiken definiert sind, stellt sich die eigentliche Frage, welche Art von Umgebung sie unterstützt, ohne selbst zum Wartungsaufwand zu werden. Für ein einzelnes Team ist dies längst kein hypothetisches Szenario mehr: 51% der CDOs nannten Data Governance ihre wichtigste Priorität für das kommende Jahr in Deloittes jüngster Chief Data Officer Survey, was bedeutet, dass Governance zu einer Anforderung auf Plattformebene wird, statt eine Lösung zu bleiben, die ein Team manuell pflegt.
Eine geregelte, wiederholbare Umgebung muss fünf Anforderungen erfüllen. Die erste sind rollenbasierte Zugriffskontrollen, bezogen auf das spezifische Asset, einen Workflow, ein Dataset oder eine Verbindung, anstatt als pauschale teamweite Berechtigungen vergeben zu werden, die allen denselben Zugriff gewähren, unabhängig davon, was sie tatsächlich benötigen.
Der zweite Punkt sind Prüfprotokolle, die abfragbar und exportierbar sowie nach Benutzer, Aktion und Datum filterbar sind, statt lediglich irgendwo in einem System protokolliert zu werden, das niemand überprüft. Der dritte Punkt ist die automatisch erzeugte Datenherkunft, während Workflows ausgeführt werden, statt sie nachträglich von einem Analysten rekonstruieren zu lassen, wenn schließlich jemand fragt, woher eine Zahl stammt.
Die vierte Anforderung sind Vertrauenssignale, Zertifizierungsstatus und Vertraulichkeits-Tags, die genau an der Stelle sichtbar sind, an der der nächste Analyst das Asset übernimmt, und nicht ein paar Klicks tief in einem Admin-Panel vergraben sind. Die fünfte ist Identity Federation, sodass der Zugriff mit dem vorhandenen Identitätsanbieter der Organisation skaliert, anstatt eine parallele Benutzerliste zu erfordern, die jemand manuell pflegen muss.
Jede Plattform in dieser Kategorie sollte alle fünf erfüllen. Das sind die Kriterien, unabhängig davon, welchen Anbieter ein Team letztendlich evaluiert.
Wie eine für Governance konzipierte Plattform aussieht
Alteryx One ist ein Beispiel für eine Plattform, die genau für die oben genannten Anforderungen konzipiert wurde. Egal, ob Sie ein Alteryx One-Benutzer sind oder nicht, die folgenden Funktionssätze bieten ein nützliches Beispiel dafür, wie Governance über eine einzige Plattform gehandhabt werden kann.
Für den rollenbasierten Zugriff grenzt Alteryx One Berechtigungen und Rollen auf das jeweilige Asset, Workflows, Flows, Verbindungen, Datasets und Pläne ein – auf den Zugriffsebenen Betrachter, Redakteur oder Autor sowie mit den Anwendungsrollen Consumer und Creator. Dadurch wird der Zugriff an das gebunden, womit jemand tatsächlich arbeitet, statt an eine einzige teamweite Berechtigungsstufe.
Für Prüfprotokolle können die Audit-Protokolle der Plattform nach Ereignis, Aktion, Benutzer, Arbeitsbereich und Datum gefiltert und nach CSV exportiert werden. Audit-Daten verbleiben standardmäßig 90 Tage auf der Plattform, und Teams, die eine längere Aufbewahrung benötigen, können diese mit AWS S3 synchronisieren.
Für die Datenherkunft stellt Alteryx One auf Dataset- und Spaltenebene native Datenherkunft über den OpenLineage-Standard bereit und bindet externe Katalog-Tools wie Atlan oder Collibra an, anstatt diese zu ersetzen. Diese Unterscheidung ist wichtig: Diese Kataloge bleiben das System of Record für die Metadaten-Governance, und Alteryx liefert die benötigten Daten zur Datenherkunft.
Für Vertrauenssignale kennzeichnen Data Labels und die Objektzertifizierung den Status eines Objekts (zertifiziert, Entwurf, veraltet) und dessen Sensibilität (PII, eingeschränkt) direkt in der Objektbibliothek, wo der nächste Analyst, der die Arbeit übernimmt, sie tatsächlich sieht, statt in einem Admin-Panel, das er erst kennen müsste, um es zu prüfen.
Für die Identitätsföderation unterstützt Alteryx One SSO über SAML 2.0 und OIDC mit Identitätsanbietern wie Okta und Microsoft Entra ID, sodass der Zugriff mit jedem Identitätssystem skaliert, das das Unternehmen bereits verwendet. Leser, die sich ein umfassenderes Bild machen möchten, können den Governance-Ansatz von Alteryx direkt einsehen.
Zurück beim People-Analytics-Team: Im zuvor beschriebenen Beispiel entspricht jede Korrektur etwas Konkretem. Der Definition für „aktiver Personalbestand“ wird ein namentlich genannter Eigentümer zugewiesen. Die Regel zur Umwandlung von Auftragnehmern wird zu einem dokumentierten, sichtbaren Schritt innerhalb des Workflows anstelle einer ausgeblendeten Tabellenregisterkarte. Eine geplante Überprüfung meldet die Kostenstellenabweichung automatisch in jedem Zyklus. Der Monatsabschluss verkürzt sich von vier Tagen auf denselben Tag, da die zwei Tage, die früher für das manuelle Neukennzeichnen anfielen, nun eine Regel sind, die der Workflow bei jeder Ausführung erzwingt, und keine Aufgabe mehr, an die eine Person denken muss.
Beginnen Sie mit einem Workflow, nicht mit dem gesamten Framework
Wählen Sie den am meisten gefürchteten wiederkehrenden Bericht, etwa den oben erwähnten Personalabgleich, als Pilotprojekt aus. Verzichten Sie vorerst auf den unternehmensweiten Governance-Rollout.
Weisen Sie jeder Ermessensentscheidung, die in diesem einen Bericht verborgen liegt, einen namentlich benannten Eigentümer zu, bevor Sie etwas anderes anrühren. Dokumentieren Sie die Logik in einer Form, die der nächste Analyst tatsächlich ohne ein Meeting lesen kann. Erstellen Sie eine automatisierte Prüfung, die gezielt auf die spezifische Fehlerart ausgerichtet ist, die dem Team schon einmal Probleme bereitet hat – und keine allgemeine Vollständigkeitsprüfung, die alles und nichts markiert.
Erst wenn dieser einzelne Workflow über einige Zyklen hinweg fehlerfrei ausgeführt wird, sollte diese Praxis auf den nächsten Bericht ausgeweitet werden. Skalierbare Governance beginnt als Nachweis an einem einzelnen Workflow, nicht als Vorgabe, die für alle auf einmal verordnet wird.
Das ist der ganze Unterschied zwischen Governance, die Analysten nutzen, und Governance, die sie umgehen. Die eine wird direkt in den Bericht selbst integriert, am Arbeitsplatz, von jemandem mit Namen. Die andere wird zu einem Richtliniendokument, das zu lesen niemand Zeit hat.
Die kostenlose Testversion von Alteryx One ermöglicht es einem Team, diesen ersten Workflow mit bereits integriertem rollenbasiertem Zugriff, Audit-Protokollen und Datenherkunft zu erstellen und zu verwalten, bevor entschieden wird, ob diese Praxis weiter ausgebaut werden soll.