Governance in HR — Workforce-Daten, Workday und PII zweckgebunden steuern

Was diese Landschaft besonders macht

HR-Daten sind besonders durch Zeitbezug und Nutzungskontext geprägt. Eine Person, ein Beschäftigungsverhältnis, eine Stelle und eine Organisationszuordnung sind verschiedene Objekte. Headcount, FTE und Kosten unterscheiden sich je nach Stichtag und Berechnungsregel; operative Personalbearbeitung und breites Workforce-Reporting brauchen unterschiedliche Sichtrechte.

• Person, Beschäftigung, Stelle und Organisation getrennt zählen.
• Rückwirkende Änderungen und Organisationshistorie behalten.
• Kleine Gruppen und sensible Attribute bei Analytics gezielt begrenzen.

Welche Werkzeuge zu welcher Aufgabe passen

Ausgangspunkt sind die Aufgabe und die vorhandenen Systeme. Die Beispiele zeigen geeignete Einsatzgebiete; vor einer Auswahl müssen Datenzugriff, Funktionsumfang und laufender Betriebsaufwand im eigenen Bestand geprüft werden.

Die folgenden Kapitel vertiefen die einzelnen Grenzen und Problemfelder:

• Beschäftigten- und Organisationsvereinbarungen — Identität und Zählebene
• Zweckbindung und Maskierung — Sensible HR-Attribute kontrolliert nutzen
• Analytics-Allowlist — Welche HR-Felder in BI gehören
• DSDR und Workforce-Exporte — Betroffenenrechte bis in BI durchziehen

Wenn du nur fünf Minuten hast

1. Starte mit Zweck und Population: Worker, Position, FTE, Candidate oder Compensation.
2. Trenne HRIS-Quelle, Analytics-Kopie, Export und BI-Sicht sichtbar.
3. Nutze Freigabelisten statt “alle HR-Felder ins Reporting”.
4. Prüfe PII, Betriebsrat/Legal, Aufbewahrung und Auskunftsrechte vor dem Export.
5. Übergib an Tech nur Felder mit Zweck, Empfänger, Maskierung und Retention.

Begriffe vor dem Lesen

• Zweckbindung — dokumentierter Zweck, Nutzergruppe und Aufbewahrung vor jeder Nutzung außerhalb des Quellsystems — kein „wir könnten das Feld laden“.
• Workforce-fachliche Zählebene — Worker, Position oder FTE mit Regel für Mehrfachbeschäftigung — kein Headcount aus Mail-Adressen.
• Auskunfts- und Löschrechte — Betroffenenrechte bis in Auswertungstabelle, Export und BI — keine Löschung nur im HRIS.
• Freigabeliste — explizit freigegebene HR-Felder je Zweck und Rolle — kein Self-Service mit allen Worker-Attributen.
• Maskierung — Klartext, maskiert, nur aggregiert oder kein Zugriff je Rolle — kein technisches Default-Mitliefern.

Folgelink, ohne die HR-Serie umzunummerieren: Finden, nicht durchleuchten — Arbeit auffindbar, Akten im HR-Pfad, Directory-Wahl.

Die Beispiele verwenden erfundene Daten. Prüfe die beschriebenen Entscheidungen an einem begrenzten Fall aus den eigenen Systemen und dokumentiere Abweichungen.

Fachlicher Zusammenhang: Verantwortung klärt, wer die Aussage entscheidet; Kennzahlen-Governance beschreibt ihre Bedeutung; Datenqualität prüft die benötigte Datengrundlage. Das Governance-Konzept verbindet diese Aufgaben zu einem gemeinsamen Arbeitsweg.

Orientierung — Workforce ohne HRIS zu übernehmen

Download: PDF dieser Seite · Vertriebshub: Governance als Dienstleistung · Wen rufen: Delegation

Produkte und Entscheidungen

Workforce-Core-Produkt

Das Core-Produkt beschreibt:

• Worker oder Contingent Worker; Beschäftigungsstatus; Position; Job Profile; Organisation; Company; Cost Center; Location; Manager-Beziehung; Effective Dates.

Entscheidungen:

• Wer gehört zu welcher Grundgesamtheit?; Welcher Zustand gilt zu einem Stichtag?; Wie werden Mehrfachbeschäftigungen behandelt?; Welche organisatorische Beziehung ist autoritativ?

Organizational-Structure-Produkt

Dieses Produkt hält:

• Supervisory Organization; Legal Entity; Cost Center; Position Hierarchy; Management Chain; Reorganisationen; gültige Zeiträume.

Entscheidungen:

• Welche Hierarchie gilt für welchen Zweck?; Wie werden historische Zustände erhalten?; Wann ist eine Reorganisation analytisch wirksam?

Recruiting-Produkt

Das Recruiting-Produkt umfasst:

• Requisition; Position; Candidate; Application; Stage; Offer; Hire Event; Source; Zeitpunkte.

Es braucht eine eigene Purpose- und Retention-Grenze. Bewerberdaten dürfen nicht still in das allgemeine Workforce-Produkt wandern.

Compensation-Produkt

Vergütungsdaten benötigen besonders enge Kontrolle.

Der Contract definiert:

• Grundgesamtheit; Komponenten; Währung; Zeitraum; Zugriff; Aggregationsschwellen; zulässige Analysen; Aufbewahrung; Exportregeln.

Time-, Absence- und Leave-Produkt

Abwesenheitsdaten können sensible Ursachen oder Gesundheitsbezug enthalten.

Für viele Entscheidungen genügt:

• Status; Zeitraum; Dauer; organisatorischer Kontext; freigegebene Kategorie.

Detailgründe sind nicht automatisch erforderlich.

Workforce-KPI-Produkt

KPIs wie Headcount, Attrition, Time to Hire und Pay Gap benötigen:

• genaue Grundgesamtheit; Event-Definition; Zeitraum; Nenner; Ausschlüsse; Stichtag; Gruppierung; Mindestgruppengröße; Version; verantwortliche Person.

Wo Governance hängt

Am Zweck

„People Analytics“ ist zu breit.

Ein zulässiger Zweck benennt:

• konkrete Entscheidung; Nutzergruppe; Grundgesamtheit; benötigte Felder; erwartete Wirkung; Aufbewahrungsdauer; Ausschlüsse.

An Effective Dates

Workday und andere HR-Systeme modellieren zeitabhängige Beziehungen. Ein aktueller Export beantwortet keine historische Frage.

Governance muss unterscheiden:

• aktueller Zustand; Zustand zu einem Stichtag; Event-Historie; freigegebener Snapshot; rückwirkende Korrektur.

An Freitext und Anhängen

Notes, Documents und Case Text sind analytisch verlockend. Sie enthalten häufig unerwartete PII und Kontext, der nicht für breite Analyse bestimmt ist.

Standardentscheidung:

Nicht laden, bis ein benannter Zweck, eine Rechtsgrundlage, ein Zugriffspfad und eine Retention existieren.

Zwischen HR und Führungskraft

Eine Führungskraft benötigt nicht automatisch alle Daten ihrer Reporting Line.

Zugriff hängt ab von:

• Zweck; Granularität; Rolle; Zeitpunkt;
• Sensitivität;
• Mindestpopulation;
• lokaler Rechtslage.

Zwischen HR und Data Team

Das Data Team darf technische Machbarkeit nicht als Freigabe interpretieren. HR darf umgekehrt technische Risiken nicht als reine Implementierungsdetails abtun. Beide brauchen einen gemeinsamen Data Contract.

An Exports

Ein geschütztes Workday-Feld verliert Schutz, wenn es in CSV, BI Extract oder Notebook kopiert wird. Governance muss den gesamten Nutzungspfad betrachten.

An abgeleiteten Merkmalen

Ein nicht sensibles Feld kann in Kombination sensible Aussagen ermöglichen.

Modelle und Scores brauchen deshalb:

• Zweckprüfung;
• Feature-Dokumentation;
• Bias- und Wirkungsprüfung;
• menschliche Kontrolle;
• Einspruchspfad;
• Monitoring.

Rollen-Mapping

Data Owner

Der HR Data Owner sitzt dort, wo Zweck und Auswirkung verstanden werden.

Je Produkt kann dies sein:

• Head of HR Operations;
• Recruiting Lead;
• Compensation Lead;
• Workforce Planning Lead;
• HR Executive.

Der Owner entscheidet über:

• Zweck;
• Grundgesamtheit;
• Zugriff;
• akzeptables Risiko;
• Freigabe;
• Retention;
• Ausnahmen.

Privacy und Legal werden konsultiert oder müssen zustimmen, übernehmen aber nicht automatisch operative Verantwortung.

Betriebsrat — Consulted, nicht Owner

In DACH haben Beschäftigtendaten-Produkte ein Consulted-Gate, das nicht HR-Verantwortung ist: der Betriebsrat bei Verarbeitungen, die Beschäftigte betreffen. Der HR-Data-Owner bleibt A für Zweck, Population und Zugriff. Der Rat ist C — Wirkung, Timing und das Recht, einem Verarbeitungsdesign zu widersprechen — kein zweiter Data Owner und kein Stempel.

Parkt das nicht unter „Legal macht das schon.“ Die bindende Tiefe steht in Beschäftigtendaten und Betriebsrat in der DACH-Serie. Diese Landscape benennt nur den Hut: C bei Beschäftigtenwirkung, niemals A für Bedeutung.

Gibt es keinen Betriebsrat, die Vakanz trotzdem festhalten: wer C wäre, und welche Verarbeitung pausiert, bis der Sitz existiert.

Data Steward

HR Operations oder People Analytics kann Stewardship tragen.

Der Steward:

• pflegt Definitionen;
• kontrolliert Grundgesamtheit und Effective Dates;
• triagiert Quality-Issues;
• prüft Klassifikation;
• koordiniert Access Reviews;
• verfolgt Lösch- und Korrekturanfragen;
• bereitet Entscheidung der verantwortlichen Personen vor.

Data Product Owner

Der Product Owner priorisiert:

• Workforce Auswertungstabelle;
• People Analytics;
• Recruiting Analytics;
• HR Reporting;
• Self-Service;
• Lifecycle und Deprecation.

Delivery-Druck darf Purpose Limitation nicht überstimmen.

Data Architect

Der Architect schützt:

• Worker- und Position-fachliche Zählebene;
• effective-dated Beziehungen;
• Identitätstrennung;
• Pseudonymisierung;
• Produktgrenzen;
• sichere Aggregation;
• Lineage und Löschpfade.

Data Custodian

Workday Admins, Integration Teams und Data Platform betreiben:

• Rollen und Security Domains;
• Extraktionen;
• Masking;
• Verschlüsselung;
• Logs;
• Backup;
• technische Löschung;
• Incident Response.

Custodian bedeutet technische Obhut. Die Rolle entscheidet nicht allein, ob Compensation-Daten für eine Analyse genutzt werden dürfen.

Data Consumer

Consumer sind:

• HR Business Partner;
• Recruiting;
• Compensation;
• Führungskräfte;
• Finance;
• Workforce Planning;
• People Analytics;
• Betriebsrat oder Kontrollfunktionen im passenden Kontext.

Consumer müssen Zweck und Nutzungsgrenzen kennen.

Hilfskarte — wen zuerst fragen

Das Rollen-Mapping sagt, wer entscheidet. Die Hilfskarte sagt, wen man zuerst fragt, damit die Entscheidung nicht leer ist. Hüte: Wer hilft wem an der Quelle.

Zum Owner nur bei Definitions- oder Risiko-Streit. Schema- und Join-Fragen bleiben bei Expert oder Custodian. Achtundvierzig Stunden Antwort — nicht stilles Slack.

SMB versus Enterprise

SMB

Ein SMB sollte besonders wenig kopieren.

Praktische Besetzung:

• Head of People als Data Owner;
• Betriebsrat als Consulted bei Beschäftigtendaten (DACH), nicht verantwortliche Person;
• HR Operations als Steward;
• Analytics Lead als Product Owner und Architect;
• HRIS Admin oder IT Partner als technischer Betreiber;
• HR Business Partner als Nutzer Representative.

Das Minimum:

• drei bis fünf benannte Workforce-Entscheidungen;
• enger Source Umfang;
• rollenbasierter Zugriff;
• Trennung von Core, Recruiting und Compensation;
• definierte Aufbewahrung;
• Stichtagslogik;
• regelmäßiger Access Review;
• dokumentierter Incident-Pfad.

Kleine Firmen brauchen kein großes Privacy-Gremium. Sie brauchen klare Stop-Regeln.

Beispiele:

• keine Freitextfelder ohne Einzelprüfung;
• keine Vergütungsdetails in allgemeinem BI;
• keine Gruppen unter Mindestgröße;
• keine neuen Zwecke durch „interessante“ Korrelationen.

Enterprise

Ein Enterprise benötigt föderierte HR Governance.

Typische Struktur:

• Global HR Data Owner;
• Product Owner je Workforce-Produkt;
• regionale oder funktionale verantwortliche Person;
• Lead Steward plus lokales Steward-Netzwerk;
• HR Data Architects;
• Workday- und Plattform-Custodians;
• Privacy, Legal, Security und Arbeitnehmervertretung als definierte Kontrollpartner.

Globale Standards:

• gemeinsame Worker- und Position-Definitionen;
• Klassifikation;
• Mindestgruppengrößen;
• Access Patterns;
• Retention;
• Exportkontrollen;
• Lösch- und Korrekturpfade;
• zulässige Analytics-Zwecke.

Lokale Regeln können strenger sein. Der Contract muss Region und Gültigkeit sichtbar machen.

Workday richtig einordnen

Workday Business Objects, Custom Reports und RaaS Outputs sind Implementierungen. Sie sind nicht die Business-Definition des Datenprodukts.

Der Scope wird in dieser Reihenfolge bestimmt:

1. Entscheidung und Nutzer benennen.
2. Population und Ziel-Bezugs- und Detailebene festlegen.
3. benötigte Beziehungen bestimmen.
4. sensible Felder minimieren.
5. Zeitmodell festlegen.
6. Security Domain und Zugriff prüfen.
7. Output und Extraktion auswählen.
8. Retention und Löschung testen.

Nicht jedes verfügbare Objekt gehört in die Plattform. Technische Detailstory: Welche Workday-Objekte laden.

Kritische Übergaben

Mini-Fall

Alltagssituation: Ein Headcount-Dashboard soll zeigen, wie viele Mitarbeitende je Bereich, Standort und Monat im Unternehmen sind. Dafür wird aber der vollständige HR-Export geladen, inklusive Feldern, die für diese Kennzahl nicht gebraucht werden.

Was schiefläuft: Der Betriebsrat erfährt erst nachträglich, welche personenbezogenen Daten verarbeitet wurden. Ein Katalog-Tag „HR-personenbezogene Daten“ macht den Export nicht automatisch angemessen, wenn Zweck, Datenumfang und Empfängerkreis nicht vorher begrenzt wurden.

Vereinbarung: Vor dem Feed werden Zweck, erlaubte Felder, Empfänger und Aufbewahrung festgelegt. Der Betriebsrat wird nachweisbar einbezogen, die fachliche Verantwortung bleibt aber bei HR. Das Dashboard bekommt nur die Daten, die es für die Kennzahl wirklich braucht.

Anti-Patterns

Vollständiges Worker Profile laden

Verfügbarkeit ist kein Zweck. Minimiere Felder vor der Extraktion.

Managerzugriff pauschal erlauben

Hierarchie allein begründet keine unbegrenzte Einsicht.

Current State für historische Analyse

Damit werden Reorganisationen und rückwirkende Korrekturen falsch interpretiert.

Hashing als Anonymisierung verkaufen

Stabile Pseudonyme können weiterhin personenbezogen und rückführbar sein.

Privacy-Team als Data Owner

Privacy kontrolliert Rechtmäßigkeit und Leitplanken. Der fachliche Zweck bleibt bei HR.

Sensible Details zur späteren Nutzung aufheben

„Vielleicht brauchen wir es“ ist keine Retention-Begründung.

BI-Export außerhalb der Kontrollkette

Lokale Dateien benötigen dieselben Zweck- und Schutzgrenzen.

Kleine Gruppen anzeigen

Aggregation schützt nur bei ausreichender Population und Kontext.

HR-Modell ohne Wirkungskontrolle

Ein technisch gutes Modell kann unfaire Personalentscheidungen verstärken.

Mini-Scorecard

Bewerte jede Aussage mit 0, 1 oder 2 Punkten.

Zweck und Produkte

• Jeder HR-Datensatz besitzt einen benannten Zweck.
• Core, Recruiting, Compensation und Absence sind getrennt.
• Grundgesamtheit und fachliche Zählebene sind dokumentiert.

Zeit und Identität

• Effective Dates werden korrekt verarbeitet.
• historische Snapshots sind reproduzierbar.
• Identitäten sind nur soweit nötig verbunden.

Rollen und Zugriff

• verantwortliche Person entscheidet Zweck und Risiko.
• technischer Betreiber setzt Zugriff technisch um.
• Nutzer kennen Nutzungsgrenzen.

Lifecycle

• Retention ist durchsetzbar.
• Exporte bleiben kontrolliert.
• Lösch- und Korrekturpfade sind getestet.

0–7 Punkte: technisch verfügbare HR-Daten ohne Zweckkette.

8–16 Punkte: kontrollierte Basis mit Lifecycle-Lücken.

17–24 Punkte: zweckgebundene, nachweisbare HR Governance.

Erster Umsetzungsschnitt

Wähle einen begrenzten betrieblichen Fall, an dem sich die beschriebene Entscheidung und ihre Umsetzung gemeinsam prüfen lassen.

• Arbeitsplan — HR Landscape
• Lernpfad — HR Landscape
• Functions Hub — HR

Beginne nicht mit einer vollständigen Landkarte aller Beschäftigtendaten, sondern mit einer erlaubten analytischen Ableitung.

Erste Entscheidung im Fachbereich · Tool

Der Pilot beschreibt Entscheidung, Nutzergruppe und betroffene Beschäftigtenpopulation, inventarisiert vorhandene Exporte und entfernt Felder ohne nachgewiesenen Zweck. Aktueller Stand, Historie und Stichtagskopie werden getrennt. Positivtests zeigen erlaubte Auswertungen; Negativtests blockieren zu kleine Gruppen, Freitext, Anhänge und unzulässige Einzelfallansichten.

Der Einstieg ist abgeschlossen, wenn die Ableitung auf ihre HR-Quelle zurückgeführt werden kann, Zugriff und Löschpfad funktionieren, die fachliche Verantwortung benannt ist und eine unbeteiligte Person Zweck, Felder und Grenzen ohne mündliche Erklärung versteht.

Weiterlesen

• Welche Workday-Objekte laden — und welche skippen
• personenbezogene Daten und Privacy Governance
• Auskunfts- und Löschrechte Governance
• Mails und Dokumente: Zweckbindung vor KI
• Functions Hub — HR
• Rollen-Hub

In der Serie weiterlesen

• Beschäftigten- und Organisationsvereinbarungen — Identität und Zählebene