Mitarbeiter- und Organisationshierarchien als Steuerdaten

Manager-Hierarchie steuert Row-Level Access auf sales_otc — HR ändert den Baum, BI filtert falsch. Org-Hierarchien sind Control Data mit Freigabe und Historie, nicht nur Stammdaten-Export.

zeitig.

Lösung: Behandeln Sie Mitarbeiter- und Organisationshierarchien als governte Steuerdatenprodukte — eine gepflegte Hierarchie (pro Zweck), viele Consumers.

In einem Satz: Behandeln Sie Mitarbeiter- und Organisationshierarchien als governte Steuerdatenprodukte — eine gepflegte Hierarchie (pro Zweck), viele Consumers.

Problem

Die meisten Landschaften pflegen Personen- und Organisationsstrukturen an mehreren Stellen gleichzeitig:

• HR hält die Beschäftigungs-Hierarchie (Manager, Abteilung, Cost-Center-Zuordnung);
• Finance pflegt eine Reporting-/Management-Hierarchie für GuV und Cost Center;
• Sales unterhält Territory- oder Account-Team-Bäume für Quota und Pipeline;
• BI-Apps betten noch eine Version als INLINE, Excel oder hardcodierte Parent–Child-Loads ein.

Jede Kopie driftet. Monatsabschluss-Finance rollt zu einem anderen Cost-Center-Parent als der HR-Org-Chart. Eine Qlik-App zeigt nach dem Reorg noch den Manager des Vorquartals. Power-BI-RLS nutzt einen Regionsbaum, den Sales in einer Tabelle aktualisiert hat, die das Warehouse nie gesehen hat.

Zwei weitere Verwechslungen verschärfen das Chaos.

Source of Record versus Reporting-Hierarchie. Der legale bzw. HR-Baum ist nicht automatisch der Baum, den Finance für Management Reporting nutzt. Matrix- (Dotted-Line-) Beziehungen sind für People Management real und für ein einzelnes Parent–Child-Beschäftigungsmodell unsichtbar. Teams, die so tun, als sei „HR immer recht für Reporting“ oder „Finance-Excel die einzige Wahrheit“, erzeugen stille Widersprüche statt zwei Produkte zu benennen.

Zeit. Manager-Beziehungen ändern sich. Menschen wechseln, Interims decken ab, Reorgs schneiden durch Fiskalperioden. Ohne Effective Dating (SCD-artige valid_from / valid_to) schreibt jedes historische Report entweder die Vergangenheit um oder kann „wer hat dieses Team im März geleitet?“ nicht beantworten.

Als Nächstes kommen ragged Trees (ungleiche Tiefe), übersprungene Levels und Dual Parents. Eine dreistufige Sales-Region sitzt neben einer fünfstufigen Corporate Org. Apps „reparieren“ Tiefe mit leeren Knoten oder duplizierten Leaves; jedes Power-BI-Semantikmodell und jede Qlik-App hält oft noch eine Kopie. Ohne explizites Hierarchie-Datenmodell — Parent–Child plus Closure oder Bridge wo nötig — und einen Steward of Record erfindet jeder Consumer seine eigene Flatten-Logik.

Die operative Signatur entspricht dem Rest dieser Serie: duplizierte Hierarchien in BI-Skripten, kein Katalog-Owner, keine Consumer-Liste, kein Dual-Run wenn jemand „nur schnell das Excel“ aktualisiert. Vor dem Umzug klassifizieren listet Hierarchy bereits als Steuerdaten-Klasse; dieser Teil macht die Betriebsentscheidung konkret.

Entscheidung

Behandeln Sie Mitarbeiter- und Organisationshierarchien als governte Steuerdatenprodukte — eine gepflegte Hierarchie (pro Zweck), viele Consumers. Apps ergänzen nur Presentation und lokale Durchsetzung; sie besitzen den Baum nicht.

Produkte explizit benennen

Veröffentlichen Sie mindestens die Produkte, die Sie wirklich nutzen. Verdichten Sie sie nicht zu einem mehrdeutigen „Org-Chart“:

HR bleibt Source of Record für Beschäftigungs-Kanten, wo das zutrifft. Reporting- und Territory-Bäume sind eigene Produkte mit eigenen Ownern, auch wenn viele Knoten geteilt sind. Verknüpfen Sie Produkte über stabile Personen- / Org- / Cost-Center-Keys; kopieren Sie keine Excel-Sheets zwischen Domains.

Eine Hierarchie, viele Consumers

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

Governte Hierarchie-Produkt(e)
        │
        ├─→ Warehouse- / Mart-Roll-up-Dimensionen
        ├─→ Qlik-Hierarchy- / As-of-Loads
        ├─→ Power-BI-Parent–Child- / Path-Spalten
        ├─→ Berechtigung-Reduktionen (Region, Cost Center, Manager-Scope)
        └─→ Allokations- und Planungsmodelle

Folgen Sie Fachliche Logik außerhalb der BI-Apps halten: geteilte strukturelle Wahrheit außerhalb der App; toolspezifisches Auf-/Zuklappen darf innen bleiben. Lassen Sie keine App zum zweiten Steward werden.

Ragged Trees und Matrix-Linien modellieren

Standard-Strukturmuster:

1. Parent–Child-Edge-Tabelle — node_id, parent_id, hierarchy_id, Gültigkeit, Attribute.
2. Closure-Tabelle oder Bridge — Ancestor/Descendant-Paare mit Depth, aus Edges neu gebaut (oder gepflegt, wo Performance es verlangt).
3. Optionale Path- / Level-Attribute — denormalisiert für BI-Komfort, aus den governten Edges generiert, nie handeditiert als führende Quelle.

Für Matrix / Dotted-Line:

• behalten Sie einen Primary Parent für das Reporting-Produkt, das einen einzelnen Roll-up braucht;
• speichern Sie sekundäre Beziehungen als typisierte Edges (relationship_type = matrix) in derselben Familie oder einem Schwesterprodukt;
• kodieren Sie Dotted-Line nie nur als Free-Text-„Notes“-Spalte in einer App.

Ragged Depth ist normal. Erzwingen Sie keine Fake-Zwischenknoten im führenden Produkt nur, um ein BI-Visual zu erfreuen. Generieren Sie Presentation-Levels in Consumer-Views, wenn ein Tool feste Tiefe verlangt.

Effective Dating und SCD für Manager-Beziehungen

Behandeln Sie Manager- und Org-Mitgliedschaft als slowly changing Control-Beziehungen:

• jede Edge trägt valid_from und valid_to (offen endende aktuelle Zeile erlaubt);
• Point-in-Time-Queries nutzen As-of-Prädikate, keine „nur Latest“-Überschreibungen;
• Reorgs veröffentlichen eine neue Version oder ein datiertes Edge-Set mit Change-Ticket;
• historische Fakten behalten die Keys, die sie hatten; sie joinen die Hierarchie as-of Fact-Datum (oder einer erklärten Business Rule).

SCD Type 2 auf Edges ist das übliche Muster. Vermeiden Sie Type-1-Overwrite für Manager-Historie, es sei denn, ein Produktvertrag sagt explizit Current-State only — und dann nutzen Sie dieses Produkt nicht für historische Roll-ups.

Alignen Sie Change Windows mit Steuerdaten als Datenprodukte betreiben: angekündigte Reorg-Cuts, Dual-Run alter vs. neuer Baum für kritische Consumers, Tests auf Zyklen, Orphans und gebrochene Closure-Rebuilds.

Entscheidungsregel

Ein gepflegtes Hierarchie-Produkt pro erklärtem Zweck; HR-Beschäftigungswahrheit und Reporting-Bäume werden getrennt benannt; Apps konsumieren veröffentlichte Views und ergänzen nur Presentation. INLINE-Org-Tabellen und Mailbox-Excel-Bäume sind technische Schuld.

Checkliste

• Hierarchie-Assets sind als Steuerdaten (hierarchy) klassifiziert und im Katalog registriert.
• Beschäftigungs- / Legal- / Reporting- / Matrix- / Territory-Produkte haben eigene verantwortliche Person — kein mehrdeutiges Spreadsheet.
• Unterschiede Source of Record (HRIS) versus Reporting-Hierarchie sind dokumentiert, nicht übertüncht.
• Führende Struktur sind Parent–Child-Edges mit valid_from / valid_to; Closure/Bridge wird generiert oder owned.
• Keine Produktions-Qlik- oder Power-BI-App nutzt INLINE oder Mailbox-Excel als führenden Org-Baum.
• Nutzeransichten bedienen Warehouse, Qlik, Power BI und Berechtigung-Reduktionen aus demselben Vertrag.
• Cycle-, Orphan-, Duplicate-Parent- (wo verboten) und Closure-Rebuild-Tests laufen beim Publish.
• Point-in-Time- (As-of-) Verhalten ist für historische Fakten und Manager-Dashboards definiert.
• Reorg-Change-Window, Dual-Run und Rückbau-Pfad existieren für kritische Nutzer.
• personenbezogene Daten- / Personenattribute auf Hierarchieknoten folgen HR-Zugriffsregeln; Reduktionskeys bleiben Business Keys.
• Lineage vom Hierarchie-Produkt → Apps ist sichtbar; Nutzer stehen im Vertrag.
• Matrix- / Dotted-Line-Edges sind typisiert und owned, nicht in App-Skripten versteckt.

Artefakt

Org Hierarchy Control Contract (Mindestfelder)

product_id: ctrl.org.reporting_hierarchy
classification: hierarchy
hierarchy_type: reporting   # reporting | legal | matrix | employment | territory
owner: finance-fpa-lead
steward: controlling-steward
custodian: analytics-platform
grain: hierarchy_id × node_id × valid_from
contract:
  edge_view: control_org.v_hierarchy_edge
  closure_view: control_org.v_hierarchy_closure
  fields:
    - hierarchy_id
    - node_id
    - parent_id          # null = root
    - valid_from
    - valid_to
    - hierarchy_type     # reporting | legal | matrix | employment | territory
    - relationship_type  # primary | matrix | interim  (optional)
    - node_label
    - business_key       # cost_center, person_id, org_unit_id, ...
  owner: finance-fpa-lead
  consumers:
    - warehouse.dim_cost_center_hier
    - qlik.Finance_Mgmt_App
    - powerbi.Pnl_Dataset
    - control_access.v_entitlement_matrix  # abgeleitete Reduktionskeys
tests:
  - no_cycles
  - single_primary_parent_per_node_per_day
  - closure_matches_edges
  - no_orphan_non_root
change_window: announced_reorg_cuts
as_of_rule: fact_date_joins_edge_validity

Pflichtfelder im Katalog sichtbar halten: hierarchy_id, node_id, parent_id, valid_from / valid_to, hierarchy_type (reporting | legal | matrix), owner, consumers.

Outputs: benannte Hierarchie-Produkte, as-of-fähiger Edge-Store, generierte Closure für Consumers und eine Reorg-Dual-Run-Checkliste, angebunden an die Migrations-Scorecard aus Teil 10.

Tools

• Kontrollregel-Datenbank + veröffentlichte Edge-/Closure-Views — führende Struktur.
• HRIS- / Finance-MDM-Extrakte — Quellen in das Produkt, keine parallelen führenden Excel-Bäume.
• Qlik-Hierarchy-Loads / Power-BI-Parent–Child- oder Path-Spalten — nur Presentation und lokale Navigation.
• Berechtigung-Matrizen (Teil 9) — konsumieren hierarchieabgeleitete Reduktionskeys; definieren den Baum nicht neu.
• Katalog-Lineage — beweisen, welche Apps welchen hierarchy_id binden.
• Report Inventory — duplizierte Org-Excel- und INLINE-Bäume finden.
• Stewardship-Schreibpfad (Teil 6 OSS oder Teil 7 DIY) für kontrollierte Edge-Edits, wo HRIS nicht schreibt.

Ressourcen

• Serienindex: Steuer- und Referenzdaten Deep Dive
• Warum unkontrollierte Steuerdaten Governance zum technischen Alptraum machen
• Steuerdaten klassifizieren, bevor man sie verschiebt
• Steuerdaten als Datenprodukte betreiben
• Fachliche Logik außerhalb der BI-Apps halten
• Von Inline und Excel zu governeden Steuerdaten migrieren
• Berechtigungsmatrizen und Section Access gehören in die DB
• Schwesterkontext: Access Security Governance, BI-Governance-Entscheidungen