Von Inline und Excel zu governeden Steuerdaten migrieren

Das INLINE für sales_otc soll „dieses Wochenende“ raus — Dual-Run und Consumer-Liste fehlen. Migration ist sequenzierte Betriebsänderung, kein Cutover-Event.

Lösung: Betreiben Sie eine gestufte Migrationsfabrik für Steuer-Assets.

In einem Satz: Betreiben Sie eine gestufte Migrationsfabrik für Steuer-Assets.

Problem

Bis Teil 9 ist das Ziel klar: Steuer- und Berechtigung-Daten als Produkte, Postgres (oder entschiedene Platzierung) als Persistenz, optionale UI oder DIY-Schreibpfad, Katalog-Evidenz, zentrale Matrizen mit lokalem Durchsetzung. Landschaften scheitern trotzdem an der Migration.

Typische Failure Patterns:

• Big Bang: jedes INLINE und jedes Sheet in einem Release — Rollbacks unklar, Schuld verteilt sich.
• Technology-first: „alle Mappings in den Lake“ ohne Klassifikation oder Verträge.
• UI-first: NocoDB vor Schlüsseln, Tests oder Nutzeransichten.
• Inventar für immer: Scanner laufen, nichts dual-runnt.
• Zu früh retiren: Excel gelöscht, während ein kritisches Arbeitsmappe noch Month-End speist.
• Zu spät retiren: Dual-Run wird permanente Dual-Truth.

Ohne Backlog und Scorecard bleiben Teile 1–9 guter Rat neben denselben vierzig Inlines und zwölf Spreadsheets, die Governance zum technischen Albtraum gemacht haben.

Entscheidung

Betreiben Sie eine gestufte Migrationsfabrik für Steuer-Assets. Jedes Asset durchläuft dieselben Gates; der Schreibpfad kann OSS-UI oder DIY sein; der Produktvertrag ist Pflicht, bevor Consumer umschalten.

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

Inventory → Classify → Contract → Place
    → Write path (OSS UI or DIY)
    → Dual-run + reconcile
    → Switch consumers
    → Retire inline / file leading source

Priorisieren Sie nach Kritikalität × Consumer-Anzahl × Änderungsfrequenz × Berechtigung-Sensitivität — nicht danach, wie leicht das Sheet hochzuladen ist.

Stufen-Notizen

Inventar — Erweitern Sie das Risk Register aus Teil 1 und die Inline-Scan-Regeln aus Teil 2. Erfassen Sie Ort, Typ, Consumer, Owner bekannt?, letzte Änderung, Kritikalität. Schließen Sie Section-Access-INLINE und Berechtigung-Excels aus Teil 9 ein.

Klassifizieren — Nutzen Sie die Karten aus Teil 4, bevor Technologie angefasst wird. Falsche Klasse erzeugt falsche Platzierung und falschen Schreibpfad.

Vertrag — Entwerfen Sie den Produktvertrag aus Teil 8 früh (Schlüssel, Grain, Breaking-Regeln, Owner). Leerer Owner blockiert Go-Live.

Platzieren — Entscheidungsrecord aus Teil 5: Steuer-DB Default; Lake/Warehouse nur für Verteilungs-Snapshots.

Schreibpfad — Teil-6-UI, wenn Fit-Assessment besteht; sonst Teil-7-DIY auf der niedrigsten ausreichenden Stufe. Berechtigungs default Richtung B/D.

Dual-Run — Veröffentlichen Sie die Vertrags-View; halten Sie die Legacy-Quelle für ein vereinbartes Fenster in einem Shadow-Compare. Reconcilen Sie mit Counts, Key Diffs und Hashes — nicht nur Screenshots.

Umschalten — Zeigen Sie Consumer auf die veröffentlichte View; frieren Sie Legacy-Writes ein; beobachten Sie die Break Rate.

Retiren — Entfernen Sie INLINE / retiren Sie Datei-als-Quelle / archivieren Sie Kopien; behalten Sie Evidenz von Reconciliation und Owner-Sign-off. Für Excel gilt die Dispositionssprache aus Excel-Schatten-BI und Kennzahlen-Drift, wenn Workbooks auch Schatten-BI waren — hier ist das Gate „nicht mehr führende Quelle für die Steuertabelle.“

Reconciliation-Minimum

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

legacy_extract ⟷ contract_view
- row counts (valid rows)
- key set symmetric difference
- attribute hash for matched keys
- entitlement: user×reduction grants equal within tolerance 0

Null unerklärte Key Diffs vor dem Switch. Dokumentieren Sie Waivers mit Ablaufdatum.

Operating Scorecard

Tracken Sie monatlich für das Steuerdaten-Portfolio:

Scorecard-Targets gehören zum Serien-Operating-Review, nicht zu einem einmaligen Projekt-Slide.

Checkliste

• Portfolio-Inventar existiert (Inline, Datei, Berechtigung, Parameter, Hierarchien).
• Jedes Pilot-Asset hat Klassifikation + Platzierung + Produktvertrag.
• Schreibpfad gewählt (OSS oder DIY) mit AuthZ, Validierung und Audit.
• Dual-Run-Fenster, Abgleich-Methode und Pass-Kriterien vereinbart.
• Nutzer gelistet mit Switch-Ownern und Reload-/Test-Kontakten.
• Berechtigung-Migrationen enthalten Fail-Closed-Tests und Rezertifizierungs-Hook.
• Retirement-Evidenz gespeichert (Diff-Report, Freigabe, Katalog-Update).
• Scorecard-Baseline vor dem 90-Tage-Push gemessen.
• Kein Big Bang ohne Rückbau: Switch-Gates pro Asset.
• Serien-Learnings in Warehouse- / BI- / Access- / Katalog-Betriebsrhythmen verlinkt.

Artefakt

90-Tage Control Data Migration Backlog

Nutzen Sie ein Board (oder eine Tabelle) mit Spalten: asset_id, class, source_location, criticality, consumers, owner, contract_ready, placement, write_path, dual_run_start, reconcile_status, switch_date, retire_date, scorecard_tags.

Tage 0–15 — Baseline

• Inventar für Top-Domains abschließen (Sales, Finance, Access).
• Kritikalität scoren; 3–5 Pilot-Assets wählen (ein Berechtigung einschließen, falls vorhanden).
• verantwortliche Person/Stewards benennen oder Mandate-Lücken eskalieren.
• Scorecard-Baseline veröffentlichen.

Tage 16–45 — Erste Produkte live

• Verträge + Postgres- (oder entschiedene) Platzierung für Piloten.
• Schreibpfade live (OSS oder DIY); Katalogeinträge angelegt.
• Dual-Run gestartet; tägliche/periodische Abgleich für Piloten.
• Inline-Scan-Regeln für verbleibende Apps geplant.

Tage 46–75 — Umschalten und erweitern

• Pilot-Nutzer nach null unerklärten Diffs umschalten.
• Pilot-INLINE-/Datei-führende Quellen mit Evidenz retiren.
• Nächste Tranche onboarden (Ziel: Pilot-Anzahl verdoppeln).
• Berechtigung-Rezertifizierung an Access-Zyklus ausrichten.

Schritt 4 — Stabilisieren

• Dual-Run-Aging über Schwellwert abbauen.
• Scorecard-Review mit Sponsoren; Targets für nächstes Quartal setzen.
• Neues INLINE für geteiltes Kontrollregel in CI/Review-Checkliste einfrieren, wo machbar.
• Backlog an Steady-State-Stewardship-Kapazität übergeben.

Beispiel-Backlog-Zeilen:

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

asset_id          class         source                 write_path   gate
status_map_sales  mapping       qlik/Sales_App INLINE  diy-B        dual-run
fx_override_fin   parameter     sharepoint/fx.xlsx     oss-ui       contract
sa_region_matrix  entitlement   excel/sa_users.xlsx    diy-D        approve+dual
cost_center_hier  hierarchy     dbt seed hardcoded     diy-C        place+test

Tools

• Inventar + Risk Register (Artefakt Teil 1) und Inline-Scan-Regeln (Teil 2).
• Produktvertrags-Template (Teil 8) und Berechtigung-Vertrag (Teil 9).
• Abgleich-SQL/Hashes; BI-Reload-Tests.
• Report Inventory — Nutzer und Schatten-Workbooks finden.
• Architecture Fit — Platzierungsstreitigkeiten.
• Katalog — Evidenz und Lineage nach dem Switch.

Ressourcen

• Serienindex: Steuer- und Referenzdaten Deep Dive
• Alle Teile: Warum unkontrollierte Steuerdaten Governance zum technischen Alptraum machen · Inline-Tabellen · Excel/CSV führende Quelle · Klassifizieren · Platzieren · OSS-Stack · DIY-Stewardship · Produktbetrieb · Berechtigungs · Mitarbeiter- & Org-Hierarchien
• Schwesterserien und Stories:
  • Ein modernes Data Warehouse aufbauen
  • BI-Governance-Entscheidungen
  • Catalog Deep Dive
  • Fachlogik außerhalb der BI-Apps halten
  • Excel-Schatten-BI und Kennzahlen-Drift
  • Access Security Governance