ERP On-Prem nach SaaS

Von Quelle zum Mart schneidet Grain, nachdem eine Quelle autoritativ ist. Lade-Entscheidungen wählen Tabellen in einem System. Diese Serie schneidet den Plattformwechsel: dieselbe Fachwahrheit auf On-Prem und SaaS — mit Map, Vergleichspack, Consumer-Cutover und Sunset.

Nächster Teil →

Entscheidung

1. Zwei Plattformen, zwei Sources. Produktlinie ist kein Identifier.
2. Ein Data Owner für den gewählten Belegkreis — Alias Business Owner. Plattform-Admin ist Custodian.
3. Ein Grain je Vergleich (Belegkopf oder Belegzeile oder G/L-Zeile) — nicht gemischt.
4. Customization-Gap schriftlich, bevor der erste Mart-Join gebaut wird.
5. Kein stiller Dual-Run. Parallele Zahlen brauchen Authority, Toleranz und Exit — Teil 3.

Produkte und Entscheidungen

Der Lift braucht keine „Migrationsplattform“, sondern geschnittene Produkte.

Plattform-Authority-Karte

• On-Prem-Umfang und SaaS-Umfang; Zweck; Periode; führende Plattform; Ausnahme mit Ablauf.

Entscheidungen: Welche Company und welcher Belegkreis in dieser Welle?; Wer entscheidet, wenn die Zahlen abweichen?

Identifier-Map

• Business Key, SystemId, Company, Belegnummer, was in SaaS fehlt.

Entscheidungen: Welcher Key überlebt den Join?; Welche Custom-Tabelle ist Scope-out?

Comparison Pack

• KPI oder Beleg, Toleranz, Defect-Klasse, Freigabe, Enddatum.

Entscheidungen: Was gilt als „gleich genug“?; Wann endet Dual-Run je Consumer?

Consumer-Cutover

• Report, Schnittstelle, Warehouse-Feed; Stichtag; Redirect.

Sunset On-Prem

• Attestation, Legal Hold, Print/Localizations, technische Deaktivierung.

Wo Governance hängt

Zwischen Produktname und Source

„Wir haben Navision“ und „wir haben Business Central“ beschreiben Lizenzen, nicht Authority.

Zwischen Customization und SaaS-Standard

Eine On-Prem-Zusatztabelle ohne Map landet als Schattenwahrheit im Warehouse.

Zwischen zwei grünen Jobs und einer führenden Zahl

Reconcile ohne Owner ist Folienarbeit.

Zwischen Report-Cutover und Feed-Cutover

Das Dashboard zeigt SaaS, die Schnittstelle schreibt noch On-Prem.

Zwischen Stop-Switch und unbekanntem Consumer

Ohne Attestation ist Abschalten ein Blindflug — Teil 5.

Rollen-Mapping

Data Owner (Finance Close / AR)

Accountable für Zweck, führende Plattform und die Handlung, wenn die Toleranz reißt. Nicht der Warehouse-Join.

Lift Owner

Orchestriert Wellen, Map und Cutover-Fenster. Nicht fachlicher Owner jedes Belegs.

Data Steward

Triagiert Defects, pflegt die Map, eskaliert Authority-Konflikte.

Data Architect

Schützt Grain, Identifier-Kardinalität und Breaking Changes an der SaaS-API.

Data Custodian

On-Prem-DBA und BC-Admin setzen Extract, Rechte und Job-Pausen um. Konfigurationsmacht ist keine Close-Autorität.

Control Owner

Definiert Comparison-Pack-Tests, Negativpfad und Exit.

Data Consumer

Controller, Billing, Analytics — nur mit Zweck. Abweichungen über denselben Intake.

Hilfskarte — wen zuerst fragen

Hüte: Wer hilft wem an der Quelle.

Mini-Fall

Symptom: In der Praxis zeigt On-Prem 1,02 Mio. Umsatz, SaaS 0,97 Mio. Beide Loads sind grün. Das Migrations-Cockpit ist „done“.

Typischer Fehlstart: Ein drittes Dashboard mit beiden Zahlen und ein Katalog-Tag migrated.

Vereinbarung: Authority-Karte für den Belegkreis, Identifier-Map für Customer und Beleg, Comparison Pack mit Toleranz und Ausstieg. Der verantwortliche Person kann denselben „passt schon“-Ask ablehnen.

Kritische Übergaben

Anti-Patterns

• On-Prem und SaaS als eine Source behandeln, weil der Vendorname gleich klingt
• Dual-Run ohne führende Plattform, Toleranz und Ausstieg
• Custom-Tabellen still mitladen „falls sie gebraucht werden“
• Dataverse-CRM (dynamics365) mit Business Central verwechseln
• M&A-Dual-Run kopieren, obwohl derselbe Data Owner beide Plattformen besitzt
• Auswertungstabelle bauen, bevor die Map steht — Von Quelle zum Auswertungstabelle kommt danach

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.

• Arbeitsplan — ERP On-Prem nach SaaS
• Lernpfad — ERP On-Prem nach SaaS

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.

1. Eine Company und einen Belegkreis wählen (AR-Rechnungen oder G/L einer Periode).
2. Owner, Steward, Custodian und Control Owner benennen.
3. Authority-Satz schreiben: welche Plattform für diesen Zweck in dieser Periode führt.
4. Customization-Gap als Liste beginnen — noch keinen Warehouse-Join.

Zwei Plattformen ohne Map erzeugen doppelte Kunden und stille Beleglücken. Dieser Teil legt den Mindestvertrag für Identifier und Customization-Gap — bevor der erste Join als „Migration“ gilt.

Vorher: Dieselbe Buchhaltung, zwei Plattformen. Weiter: Vergleich als Produkt.

zwei Firmen zusammen. Custom-Tabellen fehlen in SaaS und niemand hat Scope-out geschrieben.

Lösung: Eine Identifier-Map je Entity (Business Key, SystemId, Company) plus Customization-Gap als Scope-out oder Map-Zeile. Kein Warehouse-Join ohne freigegebene Map.

In einem Satz: Kein Lift-Join ohne Map für Key, Company und das, was in SaaS nicht existiert.

Entscheidung

Für den gewählten Belegkreis gilt vor dem Load:

1. Business Key (z. B. Customer No., Belegnummer) und Surrogate (SystemId) getrennt halten;
2. Company / Mandant als Dimension, nicht als stiller Filter im Job;
3. Grain der Map-Zeile (eine Entity, nicht Header und Zeile gemischt);
4. Customization-Gap als Liste: laden, mappen, oder bewusst skip;
5. Owner der Map (Steward pflegt, Architect schützt Kardinalität, Owner gibt frei).

Lehrfall-Hints (keine Pflicht-DDL): Navision-Tabelle 18 Customer, 23 Vendor, 27 Item, 36/37 Sales Header/Line, 17 G/L Entry, 21 Cust. Ledger Entry. Business Central trägt dieselben Objekte über APIs und SystemId.

Map-Workflow

1. Entity-Kreis schneiden

Customer, Vendor, Item, Sales Header, Sales Line, G/L Entry, Cust. Ledger Entry — nur was der Belegkreis braucht. Kein Voll-ERP.

2. Keys nebeneinanderlegen

On-Prem Business Key, SaaS SystemId, stabile Natural Keys (Belegnummer + Company). Name und Adresse sind Match-Hinweise, keine Keys.

3. Company binden

Zwei Companies mit derselben Kundennummer sind nicht derselbe Kunde. Test-Mandanten nie in Prod-Marts.

4. Customization-Gap listen

C/AL-/AL-Zusatztabellen, Felder ohne SaaS-Äquivalent, Print-Layouts. Jede Zeile: map, skip, oder später. Still mitladen ist kein Status.

5. Negativtest

Ein Join über Display-Name muss scheitern oder in die Defect Queue. Ein unmapped Custom-Feld darf nicht im Mart erscheinen.

Handoffs

Mini-Fall

Symptom: SaaS-Umsatz fehlt zehn Kunden. Der Join lief über Name. Zwei Firmen heißen „Müller GmbH“.

Typischer Fehlstart: Fuzzy-Match im Dashboard und ein Katalog-Tag golden-record.

Vereinbarung: Map-Zeile Customer mit Business Key + Company; Name nur als Hinweis; ungematchte Belege in die Defect Queue, nicht in den Auswertungstabelle.

Anti-Patterns

• Join über Kundenname oder E-Mail
• SystemId als alleinigen historischen Key ohne Business Key
• Test-Company in denselben Auswertungstabelle wie Produktion
• Custom-Tabellen „vorsichtshalber“ laden
• Map nur im Wiki, nicht als versioniertes Artefakt

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: Arbeitsplan · Lernpfad

1. Eine Entity (Customer oder G/L Account) für den Belegkreis mappen.
2. Company-Regel schreiben und einen Test-Mandanten ausschließen.
3. Fünf Custom-Objekte als map/skip/later markieren.
4. Negativtest: Name-Join darf den Mart nicht füllen.

Zwei parallele Zahlen ohne Vertrag bleiben Zahlenstreit. Dieser Teil macht den Vergleich zum Produkt — nachdem Authority und Map stehen, bevor Consumer umgestellt werden.

M&A-Dual-Run ist ein anderer Owner-Wechsel: Controls für den Dual Run. Hier besitzt derselbe Data Owner beide Plattformen.

Vorher: Objekt- und Identifier-Map. Weiter: Cutover der Consumer.

zwei Umsatzzahlen. Teams legen zwei Dashboards nebeneinander. Abweichungen werden diskutiert, nicht klassifiziert. Dual-Run hat kein Ende.

Lösung: Ein Comparison Pack mit Scope, Grain, Toleranz, Defect-Klasse, Sign-off und Exit-Datum. Der Finance Owner entscheidet, welche Wahrheit Consumer nutzen dürfen.

In einem Satz: Vergleich ist ein Produkt mit Owner und Exit, kein zweites Dashboard.

Entscheidung

Das Pack für den Belegkreis enthält:

1. Scope — Company, Periode, Belegtyp; Scope-out ebenso;
2. Grain — derselbe Grain wie die Map (Belegkopf oder Zeile, nicht gemischt);
3. Toleranz — Betrag, Menge oder Beleganzahl; was außerhalb liegt, ist Defect;
4. Defect-Klassen — Map-Fehler, Timing (nicht gebucht), Customization-Gap, echte Differenz;
5. Sign-off und Exit — wer schließt den Dual-Run je Consumer; Datum, kein „bis es passt“.

Pack-Workflow

1. Eine Zahl wählen

Dieselbe Startwahl wie bei KPIs: ein Zahlenstreit, nicht zwanzig Konzernkennzahlen. Ein KPI ist eine Entscheidung.

2. Führende Plattform im Pack nennen

Authority aus Teil 1 binden. Ohne führende Quelle ist jede Differenz Meinung.

3. Defects triagieren

Steward klassifiziert. Architect prüft Keys. Owner entscheidet echte Fachdifferenzen. Custodian setzt Job-Fixes um.

4. Negativtest

Eine absichtliche Map-Lücke muss als Defect erscheinen, nicht als „fast gleich“.

5. Exit je Consumer

Das Pack endet nicht, wenn Jobs grün sind. Es endet, wenn der genannte Consumer auf die führende Plattform darf — Teil 4.

Handoffs

Mini-Fall

Symptom: 50 000 € Differenz. Beide Dashboards sind „richtig“. Dual-Run läuft seit vier Monaten.

Typischer Fehlstart: Ein dritter Tab „Delta“ ohne Klasse und ohne Ausstieg.

Vereinbarung: Pack auf Beleggrain, Toleranz 0,1 % oder 1 Beleg, Klassen Map/Timing/Gap/Fach, Freigabe des Owners, Enddatum für den Close-Report.

Anti-Patterns

• Zwei Dashboards als Abgleich
• Toleranz „ungefähr“ ohne Zahl
• Alle Differenzen als Map-Bug behandeln — oder alle als Fachdifferenz
• Dual-Run ohne Ausstieg, weil „noch ein Mandant kommt“
• M&A-Dual-Run 1:1 kopieren (Seller/Buyer statt derselbe verantwortliche Person)

Umsetzung im Alltag

Arbeitsweise: Arbeitsplan · Lernpfad

1. Eine Periode und einen Belegtyp in das Pack schreiben.
2. Toleranz als Zahl festlegen.
3. Fünf Differenzen klassifizieren.
4. Exit-Datum für einen Consumer nennen.

Das Comparison Pack kann bestanden sein, und die Schnittstelle schreibt trotzdem On-Prem. Dieser Teil bindet den Wahrheitswechsel an Consumer, Stichtag und Redirect.

Vorher: Vergleich als Produkt. Weiter: On-Prem kontrolliert abschalten.

zeigt SaaS. Die EDI-Schnittstelle und ein Excel-Feed lesen weiter On-Prem. Niemand besitzt den Stichtag. Consumer erfahren die Umstellung als Überraschung.

Lösung: Jeder materielle Consumer (Report, Schnittstelle, Warehouse-Feed) erhält erlaubte Wahrheit, Stichtag, Redirect und einen Owner, der den Wechsel bestätigt.

In einem Satz: Cutover ist der Wechsel der erlaubten Wahrheit je Consumer — nicht ein umgestelltes Dashboard.

Entscheidung

Vor dem Cutover eines Consumers:

1. Consumer-Inventar — Report, Schnittstelle, Feed, manueller Export; Scope-out der Restliste;
2. Erlaubte Wahrheit ab Datum — On-Prem, SaaS, oder Dual-Read nur mit Pack-Exit;
3. Stichtag und Freeze — wer darf nach dem Datum noch On-Prem schreiben oder lesen;
4. Redirect — alte URL, alte Queue, alter Extract zeigen auf die neue Wahrheit oder auf eine Absage;
5. Kommunikation und Ausnahme mit Ablauf — kein stiller Report-Swap.

Cutover-Workflow

1. Consumer schneiden

Nicht „alle Reports“. Ein Close-Report, eine Ausgangsrechnungsschnittstelle, ein Warehouse-Feed.

2. Abhängigkeit am Identifier

Dieselbe Beleg-ID wie Map und Pack. Sonst schneidet Cutover eine andere Sache als der Vergleich.

3. Freeze-Fenster

Buchungen und Exporte im Fenster sind geregelt, nicht „bitte vorsichtig“.

4. Probe mit Negativtest

Ein Consumer, der nach dem Stichtag On-Prem weiterliest, muss blockiert oder als Exception sichtbar sein.

5. Erst Cutover, dann Sunset

On-Prem bleibt stehen, bis die genannten Consumer attestiert haben — Teil 5.

Handoffs

Mini-Fall

Symptom: Der Vorstandsbericht nutzt schon die neue SaaS-Plattform. Ein alter Nachtlauf schreibt aber weiterhin Daten aus dem alten lokalen System in dieselbe Auswertungstabelle. Dadurch springen die Zahlen über Nacht wieder auf den alten Stand zurück.

Typischer Fehlstart: Report-Theme wechseln und den Job „später“ anfassen.

Vereinbarung: Feed als eigener Nutzer mit Stichtag; Redirect oder Job-Pause; Negativtest, dass On-Prem den Auswertungstabelle nach dem Datum nicht mehr schreibt.

Anti-Patterns

• Dashboard umstellen, Feeds vergessen
• Ein Stichtag für alle Nutzer ohne Inventar
• Stiller Swap ohne Kommunikation
• Dual-Read nach Pack-Ausstieg „zur Sicherheit“
• Cutover und Sunset am selben In der Praxis ohne Attestation

Umsetzung im Alltag

Arbeitsweise: Arbeitsplan · Lernpfad

1. Drei Consumer listen (ein Report, eine Schnittstelle, ein Feed).
2. Für einen Consumer Stichtag und erlaubte Wahrheit schreiben.
3. Redirect oder Job-Pause testen.
4. Negativtest: alter Pfad nach dem Datum.

Consumer können auf SaaS stehen, und On-Prem bleibt die heimliche Wahrheit für Drucke, Localizations und einen unbekannten Export. Dieser Teil schließt die Serie mit Sunset — nach Map, Pack und Cutover.

Nachbar für Artefakt-Retirement allgemein: Retirement über Artefakte. M&A-Sunset ist Seller-Mandat: Legacy-Quellen kontrolliert abschalten.

Vorher: Cutover der Consumer.

zations und ein Schattenexport leben weiter auf On-Prem. Niemand hat attestiert, dass keine Pflicht mehr an der alten Umgebung hängt.

Lösung: Sunset als Produkt: Usage Evidence, Consumer-Attestation, Legal Hold / Retention, Redirect, dann technische Deaktivierung. Der Finance Owner gibt frei; Custodian schaltet.

In einem Satz: On-Prem geht aus, nachdem Attestation und Hold stehen — nicht wenn der Job grün war.

Entscheidung

Sunset On-Prem für den Belegkreis erst wenn:

1. Usage Evidence — wer in der letzten Periode noch gelesen oder gebucht hat;
2. Attestation der im Cutover genannten Consumer;
3. Legal Hold / Retention — GoBD-ähnliche Aufbewahrung, nicht „Disk löschen“;
4. Customization- und Print-Register geschlossen oder bewusst archiviert;
5. Technische Deaktivierung mit Rollback-Fenster und Negativtest (Login/Extract muss scheitern).

Sunset-Workflow

1. Restabhängigkeiten listen

Drucke, Localizations, Zusatzmodule, manuelle SQL-Exporte, Integrationsuser.

2. Attestation einholen

Dieselben Consumer wie Teil 4. Eine fehlende Unterschrift stoppt den Switch.

3. Hold von Analytics trennen

Archiv und Legal Hold sind nicht der Mart. PII- und Belegarchive folgen Retention, nicht Dual-Run.

4. Deaktivieren in Stufen

Read-only, Extract-Stop, Login-Stop. Nicht alles in einer Minute.

5. Negativtest und Evidence

Ein Unbeteiligter muss rekonstruieren können: wann aus, wer frei gegeben hat, welcher Consumer attestiert hat.

Handoffs

Mini-Fall

Symptom: Datenbank offline. Die Spedition druckt Lieferscheine aus On-Prem. Billing öffnet eine Notfallkopie ohne verantwortliche Person.

Typischer Fehlstart: Backup zurückspielen und den Lift als gescheitert taggen — ohne Print-Register.

Vereinbarung: Print und Localization im Sunset-Register; Attestation der Disposition; Hold für Belege; Deaktivierung erst danach. Auswertungstabelle bleibt SaaS.

Anti-Patterns

• Abschalter vor Attestation
• Archiv und Auswertungstabelle in derselben Datenbank belassen und „aus“ nennen
• Print/Localizations vergessen
• Rückbau-Fenster ohne verantwortliche Person
• On-Prem als Schatten-BI weiterlaufen lassen

Umsetzung im Alltag

Arbeitsweise: Arbeitsplan · Lernpfad

1. Usage Evidence für 14 Tage ziehen.
2. Attestation von einem Cutover-Consumer einholen.
3. Print/Localization-Zeilen listen.
4. Read-only-Stufe an einer Nonprod-Kopie proben, nicht Prod killen.

Exit der Serie

• Zwei Plattformen sind zwei Sources mit einem verantwortliche Person.
• Map, Pack, Cutover und Sunset existieren als Artefakte.
• Auswertungstabelle-fachliche Ebene folgt erst danach: Von Quelle zum Auswertungstabelle.