Die Arbeit finden, nicht die Person
Anti-Silo ohne gläserne Person: Catalog, Owner, Pack und Join-Keys auffindbar machen — Metadaten der Arbeit, nicht Inhalt der Akte.
Die drei Defaults aus Teil 1 nützen wenig, wenn Owner, Pack und KPI wieder in Chat und privatem Drive liegen. Silos entstehen in Schicht 1 — nicht weil HR schützt, sondern weil Arbeit unauffindbar bleibt. Gegenreaktion „alles auf“ öffnet Schicht 2. Dieser Teil schneidet die Allowlist der Arbeit.
Der Korridor macht Keys joinbar. Hier wird sichtbar, wo das Pack liegt — ohne die Person hinter dem Owner-Namen zu öffnen.
z der Person versteckt das Arbeitsprodukt. Die nächste Funktion findet weder Owner noch Pack und baut ein Schatten-Mart.
Lösung: Eine Work-Allowlist im Catalog: Titel, Owner-Rolle, Status, Zweck, Join-Keys. Keine Aktenfelder, keine privaten Kanäle als führende Quelle.
In einem Satz: Die Arbeit muss auffindbar sein — die Person dahinter nicht.
Entscheidung
- Allowlist der Arbeit, nicht des Menschen. Catalog zeigt Pack-Titel, KPI-ID, Owner-Rolle, Vertreter, Status, Zweck. Kein Gehalt, kein Foto-Zwang, kein Aktenlink.
- Owner ist eine Rolle am Produkt. Name und dienstliche Mail dürfen Schicht-1-Metadaten sein. Sie ziehen Schicht 2 nicht nach.
- Standard-Dateinamen bleiben Need-to-share.
kpi-cards.csv,join-pack.md,visibility-contract.md— Welche Artefakte entstehen?. - Kontrolliertes Local bleibt erlaubt. Unkontrolliertes Shadow bleibt verboten — When Shadow BI is allowed. Verstecken ins Private Drive ist kein Schutz.
- Nachbar findet den Join, nicht die Vita. Consulted prüft Auffindbarkeit und Joinbarkeit. Kein zweites A, kein People-Profil als Pflicht.
Sizing
| Größe | Arbeit auffindbar |
|---|---|
| SMB | Ein Pack im Catalog mit Owner und Dateiname |
| Mid | Allowlist je Domain; privater Channel ist nicht führend |
| Enterprise | Föderierte Catalog-Produkte; Aktenfelder bleiben außerhalb der Work-Suche |
Anwendungsbeispiel: Owner versteckt, Finance startet neu
Ausgangslage: Nach dem HR-Crawl-Stop löscht Sales den Catalog-Eintrag „aus Datenschutz“. Das Forecast-Pack lebt in einem privaten Teams-Channel. Controlling sucht den Owner, findet eine alte Mail und baut forecast_v3.xlsx. Der Join zum Close fehlt. Der Korridor war nie das Problem — die Auffindbarkeit war es.
Korrektur:
- Pack zurück in den Catalog: Titel, Status, KPI-IDs, Deal-ID.
- Owner = Rolle plus dienstliche Mail. Kein Link zur Personalakte.
- Privater Channel wird Local mit Ablauf, nicht führende Wahrheit.
- Finance findet das Pack in Search ohne HR-Treffer.
- Visibility-Contract: Schicht 1 Allowlist ja, Schicht 2 weiter Deny.
Betriebsablauf (nummeriert)
- Ein Arbeitsprodukt benennen, das die nächste Funktion braucht.
- Mindestfelder der Work-Allowlist schreiben: Titel, Owner-Rolle, Status, Zweck, Dateiname.
- Akten- und Profilfelder explizit ausschließen.
- Shadow-Pfad inventarisieren und als Local oder Stop markieren.
- Search-Probe: Pack gefunden, Akte nicht.
Handoffs
| Von | An | Artefakt | Erfolgskriterium |
|---|---|---|---|
| Data Owner | Steward | Work-Allowlist | Catalog-Zeile ohne Aktenfelder |
| Steward | Custodian | Search-Scope Arbeit | Pack gefunden, HR-Site nicht |
| Practice | Nachbar-Owner | Auffindbarkeits-Test | Nachbar findet Pack in einem Satz |
| Data Owner | Consumer | Pack-Link + Zweck | Kein privater Channel als Quelle |
Anti-Patterns (und warum sie scheitern)
- Datenschutz = Catalog leeren. Scheitert als Silo; Finance baut Schatten.
- verantwortliche Person-Name als Akte. Scheitert, weil Metadaten der Arbeit mit Schicht 2 vermischt werden.
- Privater Channel als führendes Pack. Scheitert, weil die nächste Funktion nichts findet.
- Metadatenimport der Personenprofile. Scheitert als Durchleuchtung unter dem Label Transparenz.
- Join-Pack ohne Catalog-Zeile. Scheitert, weil Keys existieren, aber niemand sie findet.
- Ein Search für Arbeit und HR. Scheitert in Teil 3.
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
30 Tage: Ein Pack im Catalog mit Owner-Rolle. Search-Probe: Arbeit ja, Akte nein.
90 Tage: Allowlist je erster Domain. Kein privater Channel als führende Quelle. Dann Teil 3.
Checkliste
- Work-Freigabeliste nennt Titel, verantwortliche Person-Rolle, Status, Zweck, Dateiname.
- Aktenfelder sind aus der Work-Suche ausgeschlossen.
- Privater Channel ist Local oder Stop, nicht führend.
- Nachbar findet das Pack ohne Vita des Owners.
- Join-Keys bleiben im Korridor; Auffindbarkeit ist dieser Teil.
Artefakt
Work-Allowlist (eine Seite): Produkte, Mindestfelder, ausgeschlossene Personenfelder, Search-Scope, Local-vs-Shadow.
Tools
- Visibility-Vereinbarung — Schicht 1 Freigabeliste im selben Pack.
- Join-Pack — Keys, die die nächste Domain erbt.
- Stakeholder Matrix — verantwortliche Person vs. HR vs. technischer Betreiber.
Weiterführend
- Die nächste Funktion nicht verbauen
- Metadata Catalog Lineage
- When Shadow BI is allowed
- Welche Artefakte entstehen?
Find, do not expose
Part 2 of 4
View series