Planung von Migrationswellen
Stand 2026-09-03
Nach Geschäftsdomäne in Abhängigkeitsreihenfolge migrieren, nie nach technischer Schicht oder Finance-first. Kanonische Wellen: Pilot (geringes Risiko, Kette nachweisen) → Kernfinanzwesen (maximaler Abgleich, paralleler 2-Close-Lauf) → Supply Chain → HR (datenschutzgated) → Stilllegung. Abhängigkeitsmapping (gemeinsame Dimensionen erzwingen benachbarte Wellen) ist die eigentliche Planungsarbeit. Parallelbetrieb ist im Finanzwesen nicht verhandelbar und muss ehrlich bepreist werden. Der verteidigbare Wellenplan ist das Senior-Tagessatz-Ergebnis.
Was Sie lernen
- Eine BW/4HANA-zu-BDC-Migration nach Geschäftsdomäne in Abhängigkeitsreihenfolge sequenzieren (Pilotwelle, dann Kernfinanzwesen, dann Supply Chain/Operations, dann HR, dann Stilllegung) statt nach technischer Schicht
- Einen Abhängigkeitsgraphen gemeinsamer Dimensionen aufbauen (Kostenstelle, Materialstamm und ähnliche gemeinsame Stammdaten), um zu identifizieren, welche Domänen in benachbarte Wellen gruppiert werden müssen, und Nacharbeit in Welle 3 vermeiden
- Einen verpflichtenden Parallelbetrieb für die Kernfinanzwelle entwerfen (mindestens 2 Abschlusszyklen mit formalem Abgleich) und die Kosten des Doppelbetriebs dem Kunden gegenüber ehrlich bepreisen
- Einen abhängigkeitsbewussten Wellenplan erstellen und ihn vor einem Steering Committee vertreten — das Liefergut, das Programm-Architekten-Tagessätze rechtfertigt
Modulüberblick
Die Planung von Migrationswellen ist die Disziplin, die über die Reihenfolge entscheidet, in der eine Organisation ihren Analytics-Bestand von BW/4HANA- und ECC-Reporting auf SAP Business Data Cloud verlagert — und an der Reihenfolge entscheidet sich, ob die meisten Programme gewinnen oder verlieren. Der Junior-Instinkt besteht darin, nach technischer Schicht zu migrieren (zuerst alle InfoProvider, dann alle Queries). Der erfahrene Ansatz besteht darin, nach Geschäftsdomäne in Abhängigkeitsreihenfolge zu migrieren, in jeder Welle Wert zu liefern und das Altsystem betriebsbereit zu halten, bis jede Domäne vollständig umgestellt ist.
Warum Wellen, kein Big Bang. Eine Big-Bang-Analytics-Migration friert das Reporting für das gesamte Unternehmen während der Umstellung ein und konzentriert das gesamte Risiko auf einen einzigen Go-Live. Bei 17.000 ECC-Kunden und rund 4.000 im deutschsprachigen Raum, die vor der BW-Migrationsklippe stehen, ist die Marktrealität ein mehrjähriges Parallelbetriebsprogramm — kein Wochenend-Rip-and-Replace. Wellen erlauben es, (a) die Zielarchitektur an einer risikoarmen Domäne zu beweisen, (b) Umsetzungsmuskeln und Tooling aufzubauen, bevor das Finanzwesen angefasst wird, und (c) das Altsystem Domäne für Domäne stillzulegen, sodass Lizenz- und Infrastruktureinsparungen bereits mitten im Programm zu greifen beginnen.
Voraussetzungen
- Mittleres praktisches Erfahrungsniveau in SAP-Analytics-Projekten
- Zuerst Kernkonzepte wiederholen: C036, C034, C035
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Mittelständischer Fertigungsbetrieb, BW/4HANA on-premise + ECC, ~140 BEx-Queries über Finanzwesen, Einkauf, Produktion, HR.
- Das Anti-Pattern erkennen und vermeiden: Migration nach technischer Schicht (alle InfoProvider, dann alle Queries) — kein Geschäftswert bis ganz zum Schluss; Risiko auf eine einzige finale Umstellung konzentriert.
- Die zentrale Entscheidung des Moduls anwenden: Domäne der ersten Welle — eine risikoarme, in sich geschlossene Domäne wählen (Einkauf/Operations eines einzelnen Werks), nicht zuerst das Finanzwesen oder eine übergreifende Domäne mit gemeinsamen Dimensionen.
- Den Lernfortschritt mit dem KPI verfolgen: Pro Welle gelieferter Wert (Ziel: Jede Welle liefert ≥ 1 Produktivdomäne; Warnsignal: zwei aufeinanderfolgende Wellen ohne Produktivumstellung).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.