SPDD/SPAU minimalinvasiv bei SUM DMO
SPDD- und SPAU-Bearbeitung bei einer Brownfield-Konvertierung minimal- invasiv halten – Repository-Anpassungen (SPDD) und Quellcode-Anpassungen (SPAU) ohne Funktionsänderung. Wir trennen klar zwischen Pflicht- Adjustment (Migration läuft sonst nicht durch) und Refactoring (gehört NACH den Go-Live). Das ist der Unterschied zwischen einem Cutover in drei Wochenenden und einem Cutover in 18 Monaten.
Was SPDD und SPAU eigentlich sind
SUM DMO führt während der Brownfield-Konvertierung zwei Adjustment- Phasen ein – und beide treffen genau die Stellen, an denen Ihr Custom-Code mit dem SAP-Standard kollidiert:
- SPDD (Repository-Anpassungen) – wenn Sie Standard-Daten-Elemente, Domänen, Strukturen oder Tabellen erweitert haben und SAP diese in S/4HANA verändert, müssen Sie entscheiden: SAP-Variante übernehmen oder eigene Erweiterung beibehalten. SPDD ist die Phase, wo das Repository konsistent wird.
- SPAU (Quellcode-Anpassungen) – wenn Sie Standard-Programme, Function Modules, Klassen modifiziert haben und SAP diese in S/4 verändert, müssen Sie entscheiden: SAP-Variante übernehmen, Ihre Modifikation neu anwenden oder zusammenführen. SPAU ist die Phase, wo der Quellcode auf dem neuen Stack lauffähig wird.
Die meisten Brownfield-Programme scheitern hier nicht an der technischen Komplexität – sie scheitern an fehlender Disziplin. Die Versuchung "wenn wir schon dran sind, schreiben wir das Programm mal sauber" ist gross. Sie killt aber Cutover-Termine.
Unsere Regel – "Funktion bleibt, Form passt"
Wir trennen während SUM DMO bewusst zwischen drei Aktionen:
Pflicht-Anpassungen (in SPDD/SPAU drin)
Repository-Konflikte die das System auf S/4HANA nicht hochfährt (SPDD) und Quellcode-Konflikte wo Standard-Methoden umbenannt oder Datentypen geändert wurden (SPAU). Hier wird nur der minimale Schnitt gemacht, der für die Konvertierung notwendig ist. Wenn es zwei Wege gibt – den minimalen und den eleganten – wählen wir den minimalen.
Optimierungen (NICHT in SPDD/SPAU)
Bessere Variablennamen, sauberere Modul-Strukturen, Code-Aufteilung, moderne ABAP-Patterns. Das gehört in den Tier-2-Refactoring- Backlog und wird nach Go-Live in geplanten Releases gemacht. Während SUM DMO ist die Devise: Form bleibt wie sie war, sonst verändert sich das Verhalten unbemerkt.
Funktions-Änderungen (überhaupt nicht in der Migration)
Neue Geschäftslogik, andere Berechnungsformeln, geänderte Workflow- Pfade. Diese gehören niemals in eine Brownfield-Konvertierung – sondern in eine eigenständige Anforderung mit eigener Test-Linie. Funktion-Änderungen im SPAU sind die häufigste Ursache für stille Regressionsfehler die erst nach Wochen auffallen.
Vorgehen
1. Custom-Code-Inventur (Vor-SUM)
Aus dem ATC-Befund (siehe Custom-Code-Cleanup) wissen wir welche Z-Programme nach S/4 erwartet brechen. Diese Tier-1- Findings werden bereits in einer Pre-SUM-Sandbox reparariert. Wenn sie dort sauber laufen, gibt es im echten SUM DMO weniger SPAU-Konflikte zu lösen.
2. SPDD-Adjustment-Liste
Bevor SUM DMO startet, simulieren wir die Konvertierung in einer Dry-Run-Sandbox. Aus der entsteht eine SPDD-Adjustment-Liste mit Entscheidung je Konflikt – SAP-Variante, eigene Erweiterung, Hybrid. Diese Liste wird mit Ihrem Datenmodell-Verantwortlichen reviewt, NICHT mit dem Entwickler allein. Repository-Entscheidungen sind Datenstruktur-Entscheidungen.
3. SPAU-Reviews als Pair-Sessions
Während des SUM DMO werden SPAU-Konflikte direkt im Tool gelöst – aber nicht von einem einzelnen Entwickler. Wir machen das als Pair-Sessions: ein Entwickler löst, ein zweiter reviewt synchron. Die "Form bleibt, Funktion passt"-Regel wird so doppelt geprüft.
4. Regressionstest pro Modul
Nach jedem Conversion-Pass läuft ein reiner Regressionstest über die bisher genutzten Transaktionen. Die Testfälle bleiben identisch – wenn das Ergebnis abweicht, war eine SPAU-Anpassung doch nicht so funktions-neutral wie gedacht. Diese Findings gehen zurück in das Adjustment, nicht in den Cutover.
Wer mit uns arbeitet
Dieses Angebot richtet sich an ABAP-Leads und Tech-Architekten in einer Brownfield-Migration. Eine kompakte SUM-DMO-Vorbereitungs- Sitzung (60 Min) mit Ihrer aktuellen ATC-Liste reicht meist, um die ersten SPDD-Treiber zu identifizieren und den Pair-Review- Prozess zu schneiden.
