S/4HANA-Transformation als End-to-End-Programm – vier Layer, ein Plan

Eine S/4-Transformation ist kein technisches Upgrade – sie ist ein 12-18-monatiges Programm über vier Layer (Prozess, Code, Basis, Daten). Wer einen Layer übersieht, zahlt das im Hypercare. Dieser Insight zeigt, wie die vier Layer zusammen- spielen und welche Werkzeuge wir pro Layer einsetzen – mit konkreten Verweisen auf die SFOUR-Use-Cases je Layer.

Warum vier Layer

Eine S/4HANA-Transformation wird oft als technisches Upgrade verkauft. SUM DMO konvertiert, ein paar Z-Programme werden angepasst, Universal Journal ist auf einmal aktiv. Wer so arbeitet, lernt im Hypercare welche Layer übersehen wurden – und der Lernpreis ist meist hoch.

In Wirklichkeit sind vier Layer zu bearbeiten, und sie hängen voneinander ab: Prozess, Code, Basis, Daten. Jeder Layer hat eigene Werkzeuge, eigene Verantwortliche und eigene Risiken. Ein gutes Programm denkt sie zusammen.

Layer 1 – Prozess

Was bedeutet S/4 für die Geschäftsprozesse? Universal Journal verändert die Buchungs-Realität in FI/CO, aATP ersetzt klassisches ATP in SD/MM, Fiori-Apps lösen SAPgui- Transaktionen ab. Pro Modul-Bereich braucht es eine Prozess- Sicht: was ändert sich für den Fachbereich, welche Workflows werden anders, welche Pauschal-Rollen werden aufgesplittet.

SFOUR-Anker: die SD-, MM-, FI/CO-Service-Bereiche (service.sap.sales-distribution, service.sap.materials- procurement, service.sap.finance-controlling) mit ihren Modul-Use-Cases zum O2C-/S2P-/Closing-Redesign.

Layer 2 – Code

Was bedeutet S/4 für die Custom-Code-Basis? ATC-Befund, SPDD/SPAU-Disziplin bei SUM DMO, Migrations-Sequenz für Z-Programme, RAP-vs-CAP-Entscheidung für neue Erweiterungen. Der Code-Layer entscheidet über das Migrations-Risiko im Cutover – und über die Lifecycle-Last für die nächsten 8-10 Jahre.

SFOUR-Anker: der ABAP-Bereich (service.sap.abap-development) mit usecase.sap.abap-custom-code-cleanup, usecase.sap.abap- spdd-spau-migration, usecase.sap.abap-rap-applikation-im- stack, insight.atc-checks-pipeline-cicd.

Layer 3 – Basis

Was bedeutet S/4 für Betrieb und Identity? Mandanten- Strategie ändert sich besonders bei RISE, Berechtigungs- konzept ist die seltene Chance auf einen Redesign auf grünem Boden, ChaRM/Cloud-ALM bringt den geordneten Run, Hyperscaler-Wahl beeinflusst Disaster-Recovery und Sizing.

SFOUR-Anker: der Basis-Bereich (service.sap.basis-platform) mit usecase.basis.berechtigungskonzept-redesign-s4, usecase.basis.solman-charm-itsm, insight.basis-readiness- fuer-s4.

Layer 4 – Daten

Was bedeutet S/4 für Stammdaten und Reporting? Business- Partner-Migration für Customer und Vendor, Hauptbuch-Konten- Mapping bei Konzern-Strukturen, Datasphere als Konsoli- dierungs- und Reporting-Schicht, GPC-/eCl@ss-Klassifikation für Material-Stammdaten. Daten-Layer ist der oft unter- schätzte Hebel – ohne ihn taugt das ganze Programm wenig.

SFOUR-Anker: usecase.sap.fi-hauptbuchharmonisierung, usecase.ai.gpc_product_classifier für Material-Stammdaten, usecase.sap.datasphere_bdc für Reporting-Schicht.

Wie die vier Layer ineinandergreifen

Ein gutes Programm balanciert die Layer:

In unseren Mandaten (Refstory refstory.midmarket.s4-rise: Schweizer Anlagenbauer, 11 Monate Brownfield, ~8'000 Z-Programme via ATC bereinigt, ~38 % Custom-Code-Reduktion) arbeiten wir explizit über alle vier Layer – und das ist der Grund, warum das Hypercare entspannt verläuft statt zur Schadensbegrenzung zu werden.

Was Sie mit uns klären können

Eine Standortbestimmung (60 Min) mit Layer-Diagnose ist meist der Einstieg: wir gehen die vier Layer durch, schauen pro Layer auf den heutigen Stand und identifizieren die drei grössten Lücken. Daraus entsteht eine Layer-Roadmap, mit klarer Sequenz und konkreten Modul-Use-Cases je Layer.

SFOUR Consulting — Übersicht · Kontakt