Warum ungenutzte Assets zu Governance-Debt werden
Unbenutzte Tabellen, Pipelines und Berichte verursachen weiter Pflege, Rechenkosten und falsche Erwartungen an ihre Verlässlichkeit. Bestände erhalten eine begründete Entscheidung über Behalten, Archivieren oder Stilllegen und einen sicheren Umgang mit Abhängigkeiten und Rückkehrpfaden.
Das Unternehmensproblem und der umsetzbare Auftrag
Unbenutzte Tabellen, Pipelines und Berichte verursachen weiter Pflege, Rechenkosten und falsche Erwartungen an ihre Verlässlichkeit.
Bestände erhalten eine begründete Entscheidung über Behalten, Archivieren oder Stilllegen und einen sicheren Umgang mit Abhängigkeiten und Rückkehrpfaden.
Wirtschaftliche Wirkung prüfen
Messe tatsächlich beendete Jobs, vermeidbare Speicher- oder Verarbeitungsausgaben und entfallene Pflege. Ziehe Stilllegungsprüfung, Migration und laufende Bestandsprüfung ab. Kapazitätsgewinn, tatsächlich vermeidbare Ausgaben und Qualitätswirkung werden getrennt ausgewiesen.
Veränderung im Alltag verankern
Owner und Nutzende entscheiden gemeinsam, welche Nutzung noch besteht. Die Ablösung bietet einen verlässlichen Ersatz und verhindert, dass Kopien aus Gewohnheit wieder entstehen.
Für die Nutzenentscheidung dient Nutzen im ersten Review prüfen; für Mandat, Kapazität und tatsächliche Übernahme Change und Adoption. Wähle den kleinsten Umfang, der das Problem nachweisbar verbessert.
Hygiene-Governance startet nicht mit einer Löschwelle. Sie startet mit der Frage, welche Pipeline, welcher Mart, welches Dashboard oder Workbook noch einen Zweck hat, aktiv genutzt wird und eine zuständige Person besitzt. Fehlt eines dieser drei Signale, ist das Asset nicht automatisch falsch, aber es ist ein offener Governance-Befund.
Wenn Katalog, Zeitplan und Nutzung auseinanderlaufen, gilt ein Dashboard weiter als live, obwohl die zuständige Person gegangen ist und niemand es mehr nutzt. Access Reviews, Kostenalarme und Incident-Pfade behandeln es trotzdem wie ein Leitprodukt. Das Problem ist nicht der Orchestrator. Das Problem ist der fehlende Vertrag zwischen Inventar, Zweck, Nutzung und Disposition.
Gute Datenhygiene macht Ungenutztes entscheidbar: Zweck, Nutzung und Verantwortung stehen am selben Asset, nicht verteilt über Katalog, Jobplan und Erinnerungen im Team.
Anschluss an Data Lifecycle & Retention, Data Product Lifecycle Governance und Redundanz Deep Dive.
Nachts läuft eine Pipeline, die niemand mehr abfragt. Ein Dashboard hängt im Katalog, die zuständige Person ist gegangen, und ein toter Job schreibt weiter in eine Tabelle. Daneben lebt ein Shadow-Excel als stille Wahrheit. Teams kaufen dann eine Hygiene-Plattform oder taggen Assets deprecated, aber der nächste Clone entsteht, weil niemand entscheidet, was behalten, archiviert, stillgelegt oder gelöscht wird.
Die Beispiele sind Anwendungsbeispiele, keine Kundendaten. Ersetzt Asset-, Job- und Toolnamen durch eure Katalog-, BI- und Prozessquellen.
Begriffe vor dem Lesen
- Datenhygiene — Regelmäßige Pflege von Datenassets, damit ungenutzte, veraltete oder nicht verantwortete Arbeitsartefakte nicht weiterwirken.
- Orphan — Asset ohne fachlich benannte zuständige Person.
- Zombie — Asset ohne aktive Nutzung, das technisch weiterlebt.
- Shadow-Kopie — Inoffizielle Kopie neben der freigegebenen Quelle oder Kennzahl.
- Disposition — Entscheidung: behalten, archivieren, stilllegen oder löschen.
Qualität, Quellkorrektur und AI-Nutzung
Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit zuständiger Person. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidenz: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.
Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.
Produkte und Entscheidungen
Hygiene braucht nicht „eine Aufräum-Platform“, sondern geschnittene Produkte.
Hygiene Debt Register
Dieses Produkt beschreibt:
- Asset-ID; Typ (
pipeline,mart,dashboard,job,workbook,other); Domain/Plattform; Purpose-Status; zuständige Person/Backup; Nutzer-Evidenz und Messfenster; Hygiene-Klasse; Kosten-/Blast-Score; Disposition-Platzhalter; Reviewdatum.
Entscheidungen:
- Welche Top zehn einer Domain sind materiell genug für v1?; Wer darf eine Zeile schließen — Domain-Verantwortung oder Steward?; Welche
unknown-Triade gilt als Befund, nicht als Keep?
Zweck-/Nutzung-/Zuständigkeits-Triade
Drei Signale, ein Asset.
Es benötigt:
- Purpose
documented|assumed|unknown; letzter View/Load/API-Call; zuständige Person und Backup (leer = Orphan).
Entscheidungen:
- Welches Fenster zählt als „keine Nutzung“ — 90 oder 180 Tage je Klasse?; Wer ist Backup, bevor die zuständige Person geht?; Welche Katalogzeile suggeriert live, obwohl niemand konsumiert?
Klassen-Tag
Noch nicht lösen — nur trennen.
Entscheidungen:
- Orphan, Zombie, Dead Job, Shadow, mixed?; Welche Shadow-Excel ist Hygiene, welche Redundanz-Fork wandert in den Redundanz Deep Dive?; Welche Retention-Richtlinie existiert, ohne Stilllegungsbetrieb (Missing Pieces)?
Disposition-Platzhalter
inventory / keep / archive / retire / delete — Entscheidung in Teil 3.
Entscheidungen:
- Was bleibt bewusst inventory, bis Evidenz da ist?; Welche Benachrichtigung brauchen Nutzer vor einer Stilllegung?; Welches Blind-Delete würde neue Shadows züchten?
Wo Governance hängt
Zwischen null Klicks und weiterlaufenden Kosten
Ungenutzt ist nicht Nullrisiko. Compute, Lizenz und Access-Review bleiben.
Zwischen Katalog-„live“ und fehlendem Nutzer
Der Eintrag suggeriert Autorität. Stewards finden Leitprodukte nicht.
Zwischen weggegangener Zuständigkeit und Incident-Pfad
Zombie-Jobs treffen dieselben On-Call-Wege wie Live-Produkte.
Zwischen Clone und fehlender Stilllegungsansage
Neue Teams kopieren, weil niemand sagt, was tot ist.
Zwischen Retention-Policy und fehlendem Inventar
Policy heilt Hygiene nicht, wenn niemand weiß, was noch lebt.
Zwischen Hygiene-Befund und Redundanz-Fork
Zwei Metrik-Logiken sind ein anderes Problem. Ein Register für beides verwischt Disposition.
Rollen-Mapping
Zuständige Fachrolle
Verantwortet Zweck und die Entscheidung, ob ein Asset behalten oder später stillgelegt wird. Die zuständige Fachrolle löscht nicht allein und nicht blind.
Hygiene Steward
Führt Register, Klasse, Reviewdatum und die Grenze zur Redundanz-Serie. Stewardship braucht Kapazität, nicht die Restzeit zwischen Kostenalarm und Sprint.
Technischer Betreiber
Liefert Schedule-, Storage- und Compute-Signale. Konfigurationsmacht ist keine Disposition.
BI- oder Report-Verantwortliche
Nutzer-Evidenz und Backup für Dashboards. Ein View-Log ersetzt nicht den fachlichen Purpose.
Architect
Blast Radius und Downstream-Lineage-Hinweis. Architektur ersetzt nicht das Register.
Audit / Cost Nutzer
Empfängt Hotlist und Orphan-Queue. Sie erfinden keine parallele Löschliste.
Mini-Fall
Alltagssituation: Eine Nacht-Pipeline hat seit 90 Tagen keinen nachgelagerten Nutzer. Ein Dashboard wurde seit über 180 Tagen nicht geöffnet und hat keine zuständige Person. Ein Job schreibt weiter in eine unveränderte Tabelle. Daneben liegt eine Shadow-Excel-Liste.
Was schiefläuft: Ungenutzte Assets werden nicht automatisch harmlos. Sie kosten Betrieb, verwirren KI-Suche und können als scheinbar gültige Quelle wieder auftauchen.
Vereinbarung: Ein Hygiene-Schuldenregister sammelt Assets ohne Zweck, Nutzer oder zuständige Person. Jede Zeile bekommt Klasse, Entscheidungstrio, Disposition und Nachweis. Erst inventarisieren und einordnen, dann löschen oder archivieren.
Kritische Übergabe
| Von | An | Arbeitsartefakt |
|---|---|---|
| Zuständige Fachrolle | Hygiene Steward | Purpose-Status und Keep-Intuition |
| Technischer Betreiber | Steward | Schedule-, View- und Kosten-Signale |
| BI- oder Report-Verantwortliche | Steward | Nutzer-Evidenz und Backup |
| Steward | Architect | Blast-Radius-Kandidaten |
| Steward | Redundanz-Serie | Forks mit doppelter Bedeutung |
| Steward | Teil 2 / 3 | Inventory-Matrix und Disposition-Backlog |
Anti-Patterns
- Ungenutzt als Nullrisiko führen
- Sofort löschen ohne Evidenz und Notify
- Hygiene und Redundanz in ein Register mischen
- Plattform kaufen vor dem Register
- Katalog-Tag
deprecatedohne Queue für fehlende Zuständigkeit - Plattform-Admin als alleinige Hygiene-Verantwortung führen
- Retention-Richtlinie als Ersatz für Inventar behandeln
Im Alltag betreiben
Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Im verlinkten Arbeitsplan hältst du fest, wer die einzelnen Aufgaben übernimmt, bis wann sie erledigt werden und welche Entscheidungen noch offen sind.
- Arbeitsplan — Data Hygiene Ops Starte mit dem kleinsten echten 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.
Schritt 1: Rahmen und Entscheidung klären
Asset-Klassen einer Domain listen. Zweck, Nutzung und Zuständigkeit grob füllen. Zuständige Fachrolle und Steward benennen. Top-zehn-Hotlist öffnen.
Schritt 2: Control und Nachweis umsetzen
Register schließen. Klassen taggen. Redundanz-Forks auslagern. Kosten- und Blast-Hinweise ergänzen.
Schritt 3: Testen und Ausnahmen sichtbar machen
Orphan-Queue starten. Negativtest: Blind-Delete eines Zombies ohne Notify gilt als Fehlschlag. Teil-2-Matrix vorbereiten.
Schritt 4: Messen und begrenzt ausrollen
Aufwand und Lücken messen. Nur bestandene Muster auf eine zweite Domain übertragen. Scorecard folgt am Serienende, nicht als erstes Tool.
Exit-Kriterien
- Die Pilot-Domain hat ein Register mit Triade und Klasse je Top-Asset.
- Ungenutzt ist als Debt geführt, nicht als Nullrisiko.
- Disposition-Platzhalter existiert — Delete ist nicht der Default.
- Hygiene-Befunde sind von Redundanz-Forks getrennt.
- technischer Betreiber liefert Nutzungs- und Kosten-Signale; Zuständige Fachrolle bleibt für Purpose verantwortlich.
Weiterlesen
- Data Lifecycle & Retention
- Missing Pieces: Lifecycle & Stilllegung
- Data Product Lifecycle Governance
- Measuring Dashboard Governance
- Redundanz Deep Dive
Data Hygiene
Part 1 of 6
View series