SAP S/4HANA Migration: Blueprint & Zielbild – Vom Verständnis zur konkreten Gestaltung (Teil 3)

movisco Transition Strategie – Wo stehen wir?

Diese Serie begleitet die S/4HANA Migration als End-to-End-Reise entlang der movisco Transition Strategie.

Teil 1 beschreibt Einordnung & Mindset.

Teil 2 vertieft das Assessment und lieferte die Entscheidungsgrundlage.

Teil 3 zeigt: Wie wird aus Assessment-Erkenntnis ein verbindliches, umsetzbares Zielbild.

Teil 4 zeigt: Wie wird ein verbindlicher Blueprint in konfiguriertes System, bereinigten Custom Code und migrierte Daten überführt?

Kernaussage

Der Blueprint ist kein statisches Dokument, sondern ein lebendiges Steuerungsinstrument. Er verdichtet alle Assessment-Erkenntnisse (Readiness Check, ATC-Backlog, Datenqualitätsmetriken, Migrationsstrategie) zu einer verbindlichen Designgrundlage und legt damit die Basis für eine erfolgreiche Realize-Phase.

Zentrale Ergebnisse dieses Teils

Klar strukturiertes Zielbild für Prozesse, Daten und Architektur
Konkrete Operationalisierung von Fit-to-Standard und Clean-Core-Guardrails
Verbindliche Datenstrategie inkl. ILM, Historienentscheidung und MDG-Governance
Integrierte Daten-, Integrations- und Security-Architektur mit konkreten KPIs
Blueprint-Checkliste als Qualitätssicherung vor dem Eintritt in die Realize-Phase

1. Vom Assessment zum Blueprint: Der entscheidende Übergang

Während das Assessment die strategische Entscheidungsbasis schafft – Greenfield, Brownfield oder Selective Data Transition; On-Premise, Private oder Public Cloud –, beantwortet der Blueprint die entscheidende Anschlussfrage:

Wie sieht die zukünftige S/4HANA-Landschaft konkret aus – und wie wird jede Gestaltungsentscheidung begründet und abgesichert?

Die direkte Verknüpfung zum Assessment ist kein Formalismus, sondern inhaltliche Notwendigkeit:

Übersicht der Assessment-Ergebnisse einer SAP S/4HANA Migration mit Auswirkungen auf Blueprint, Clean Core, Datenqualität und Integrationsstrategie.

Der Blueprint ist damit keine theoretische Beschreibung, sondern eine verbindliche Designgrundlage, die Interpretationsspielräume minimiert und alle Projektbeteiligten auf ein einheitliches Zielbild ausrichtet.

2. Zielbild definieren: Drei Perspektiven, ein kohärentes Bild

Ein wirksamer Blueprint integriert drei zentrale Perspektiven, die nicht isoliert, sondern verzahnt gestaltet werden:

Darstellung des SAP S/4HANA Zielbilds mit End-to-End-Prozessen, Clean-Core-Architektur und Governance-Rollen.

3. Fit-to-Standard als Leitprinzip

Der Fit-to-Standard-Ansatz ist keine Einschränkung – er ist die konsequente Nutzung des SAP-Innovationsvorsprungs. Jede unnötige Abweichung vom Standard ist eine technische Schuld, die Upgrade-Fähigkeit, Release-Zyklen und Betriebskosten belastet.

Strukturiertes Vorgehen

Analyse der SAP Best Practice Prozesse (L1–L3) je Prozessdomäne
Identifikation und Dokumentation von Abweichungen (Delta-Liste)
Fachliche Bewertung: Ist die Abweichung ein echter Wettbewerbsvorteil oder historisch gewachsene Komplexität?
Entscheidung und Dokumentation je Delta-Position

Entscheidungsmodell für Fit-to-Standard mit In-App Extensions, Side-by-Side-Erweiterungen auf der SAP BTP und ABAP Cloud.

Praxisregel:

Jede Abweichung vom Standard benötigt eine fachliche Begründung, keine technische.

Frage:

Welchen messbaren Geschäftsvorteil bringt diese Individualentwicklung, den der Standard-SAP-Prozess nicht bietet?

4. Clean Core operationalisieren: Guardrails statt Absichtserklärungen

"Clean Core" bleibt eine Worthülse, solange er nicht in konkrete Leitplanken übersetzt wird, die im täglichen Entwicklungsalltag gelten und durchgesetzt werden. Das Assessment liefert dazu den ATC-Backlog – der Blueprint definiert die Guardrails für alle zukünftigen Entwicklungen.

Verbindliche Clean-Core-Guardrails (Beispiele):

Kein direkter Datenbankzugriff: SELECT auf SAP-Kerntabellen (z. B. BKPF, VBAK) nur über freigegebene CDS-Views oder APIs – keine nativen SQL-Statements
Keine Modifikationen am SAP-Standard-Code: USER-EXITs vermeiden; in Brownfield-Szenarien weiterhin nutzbar, aber nur als begründete Ausnahme mit Architecture-Board-Freigabe; BAdIs und Erweiterungspunkte sind der Standardweg
API-first für alle Integrationen: Keine Direktzugriffe auf Fremdsystemdatenbanken – ausschließlich definierte APIs oder Events
ABAP Cloud als Entwicklungsparadigma: Neue Entwicklungen folgen dem ABAP RESTful Application Programming Model (RAP); Legacy-Code wird migriert oder abgelöst
Side-by-Side statt In-Core für komplexe Logik: Business-Logik, die über einfache Felder/BAdIs hinausgeht, wird auf der BTP implementiert

Übersicht zur Modernisierung von Custom Code im SAP S/4HANA Clean Core mit Kategorien wie Eliminieren, Ersetzen und Modernisieren. — Portfolio-Backlog aus dem Assessment

5. Datenstrategie konkretisieren: Von der Analyse zum verbindlichen Modell

Daten und Prozesse sind keine getrennten Themen – sie sind zwei Seiten derselben Medaille. Eine Prozessänderung ohne Datenanpassung ist unvollständig. Eine Datenmigration ohne Prozesskontext ist riskant. Der Blueprint definiert beides gemeinsam.

Stammdatenmodell und Governance

Harmonisierung der Stammdatendomänen: Material, Debitor, Kreditor, Kostenstelle, Profitcenter
Einführung oder Konsolidierung von SAP MDG als zentrale Governance-Plattform
Definition von Pflichtattributen, Freigabe-Workflows und Verantwortlichkeiten je Domäne (Data Owner)
Datenqualitäts-KPIs: Vollständigkeitsquote, Dublettenquote, Aktualitätsgrad – messbar und im Blueprint festgelegt

Historienentscheidung: Was kommt mit, was bleibt?

Die Historienentscheidung ist eine der folgenreichsten im gesamten Migrationsprojekt – sie beeinflusst Migrationsaufwand, Systemperformance, Betriebskosten und rechtliche Compliance.

Datenstrategie für SAP S/4HANA Migration mit Historienentscheidung, SAP ILM, MDG-Governance und Datenmigration.

SAP ILM: Archivierung, Aufbewahrung und DSGVO-Konformität

ILM steuert Aufbewahrungs- und Löschregeln auf Basis gesetzlicher und regulatorischer Anforderungen
Archivierte Objekte bleiben über Archive Information System (AIS) oder Read Access Logging (RAL) prüfbar
DSGVO: Personenbezogene Daten werden nach Ablauf der Aufbewahrungsfrist regelkonform gelöscht
Schlanke Datenstrategie reduziert Migrationsaufwand, verbessert Performance und senkt Betriebskosten

6. Integrationsarchitektur: API-first und eventgetrieben

Im Assessment wurden alle Schnittstellen inventarisiert und kategorisiert. Der Blueprint übersetzt dieses Inventar in ein Zielmuster je Schnittstellentyp – unter konsequenter Nutzung der SAP Integration Suite als zentraler Middleware.

ntegrationsarchitektur für SAP S/4HANA mit REST APIs, SAP Integration Suite, Event Mesh und EDI-Anbindungen.

Ergebnis ist eine reduzierte Punkt-zu-Punkt-Komplexität, ein zentrales Integrationsmonitoring und eine zukunftsfähige Integrationslandschaft mit Security-by-Design.

7. Security und Berechtigungen: Von Anfang an, nicht am Schluss

Ein häufiger Projektverzögerungsgrund: Security und Berechtigungen werden als "letzter Schritt" behandelt. Das Ergebnis sind inkonsistente Rollenmodelle, SoD-Konflikte und aufwendige Nacharbeiten kurz vor dem Go-Live. Der Blueprint verankert Security als integrales Gestaltungsprinzip.

Kernelemente

Fiori-Rollenmodell: Rollenbasierte Fiori-Apps je Business Role – kein technischer Transaktionszugriff mehr; UX und Berechtigung sind eine Einheit
IAM-Struktur: Rollendesign auf Basis von Business Roles (nicht technischer Einzelrollen); Integration mit Identity Provider (IdP)
SoD-Analyse: Segregation of Duties entlang kritischer Prozesskombinationen (z. B. Anlage Kreditor + Freigabe Zahlung); Konflikte werden im Blueprint adressiert, nicht im Projekt reaktiv behandelt
Notfallzugriffe: Firefighter-Konzept mit Protokollierung (SAP GRC Access Control oder vergleichbar)

Regulierte Branchen (GxP/GAMP)

In Finanzdienstleistung, Pharma, Medizintechnik und weiteren regulierten Branchen gelten zusätzliche Anforderungen: Validierungsplanung, Audit Trail, Computer System Validation (CSV) und GAMP-5-Klassifizierung. Diese werden im Blueprint als eigenständiger Workstream definiert und sind keine nachträgliche Ergänzung.

8. Governance und Entscheidungsstrukturen

Ein Blueprint ohne Governance ist ein Dokument, das niemand durchsetzt. Die folgende Struktur hat sich in der Praxis als belastbar erwiesen:

Rollen und Verantwortlichkeiten im SAP S/4HANA Blueprint mit Steering Committee, Architecture Board und Data Ownern.

9. KPIs für den Blueprint: Was wir nicht messen, steuern wir nicht

Bereits im Blueprint werden messbare Zielgrößen definiert. Sie bilden die Grundlage für das Projekt-Cockpit in SAP Cloud ALM / Solution Manager und werden im Run-Betrieb fortgeführt.

KPI-Übersicht für SAP S/4HANA Migration mit Datenqualität, Testabdeckung, Custom Code und Nutzerakzeptanz.

10. Typische Fehler im Blueprint – und was dahintersteckt

Die folgende Analyse basiert auf wiederkehrenden Mustern aus S/4HANA-Projekten. Jedes Fehlerbild hat eine erkennbare Ursache und eine konkrete Gegenmaßnahme.

Fehler 1: Technische Fokussierung ohne Fachsicht

Projektmuster: Das Blueprint-Dokument enthält detaillierte Systemarchitektur und Datenbankmodelle – aber keine validierten End-to-End-Prozesse.

Folge: Die Realize-Phase beginnt ohne fachlichen Konsens. Prozessdesign-Entscheidungen werden "im Sprint" getroffen – mit hohem Nacharbeitsaufwand und Widerstand aus den Fachbereichen.

Gegenmaßnahme: Process Owner sind von Tag 1 an in die Blueprint-Erstellung eingebunden. Fit-to-Standard-Workshops sind Pflicht, nicht optional. Jede Architekturentscheidung hat einen benannten fachlichen Sponsor.

Fehler 2: Zu viele Abweichungen vom Standard

Projektmuster: Das Delta-Log aus den Fit-to-Standard-Workshops umfasst 200+ Positionen. Jede Fachbereichsanforderung wird als "unverzichtbar" eingestuft.

Folge: Hoher Custom-Code-Anteil, aufwendige Migrationstests, eingeschränkte Upgrade-Fähigkeit – kurz: die technische Schuld aus dem Altsystem wird ins neue System kopiert.

Gegenmaßnahme: Architecture Board bewertet jede Abweichung nach dem Prinzip: Fachlicher Mehrwert vs. langfristige Betriebskosten. Entscheidungen werden dokumentiert und sind reversibel prüfbar. Orientierungskorridor: 10–20 % Custom-Code-Anteil an neuen Entwicklungen (stark branchenabhängig – kein universeller Festwert).

Fehler 3: Unklare Datenverantwortung

Projektmuster: Die Datenmigration startet, aber niemand ist verantwortlich für die Datenqualität im Quellsystem. Bereinigungsaufgaben werden zwischen IT und Fachbereich hin- und hergeschoben.

Folge: Datenmigrations-Iterationen verzögern das Projekt. Go-Live-Datum ist gefährdet. Schlechte Datenqualität im Produktivsystem führt zu Supportaufwand und Prozessfehlern in den ersten Wochen.

Gegenmaßnahme: Blueprint definiert Data Owner je Stammdatendomäne mit namentlicher Verantwortung. MDG-Governance-Regeln gelten ab Blueprint-Freigabe. Datenqualitäts-KPIs werden wöchentlich gemessen.

Fehler 4: Integrationsstrategie als Anhang

Projektmuster: Schnittstellen werden im Blueprint als Liste vermerkt, aber nicht detailliert gestaltet. Die Integrationsarchitektur wird an externe Consultants "delegiert".

Folge: Inkonsistente Integrationsmuster, fehlende zentrale Überwachung, Security-Lücken in Schnittstellenkommunikation. Schnittstellenfehler sind die häufigste Ursache für Go-Live-Krisen.

Gegenmaßnahme: Integrationsstrategie ist ein vollwertiger Blueprint-Bestandteil mit Verantwortlichem (Integration Architect), definiertem Zielmuster je Schnittstelle und Monitoring-Konzept ab Tag 1.

Fehler 5: Governance existiert auf Papier, nicht in der Praxis

Projektmuster: Architecture Board und Process Owner sind benannt, tagen aber unregelmäßig. Entscheidungen werden trotzdem "im Sprint" getroffen, oft inkompatibel mit den definierten Leitplanken.

Folge: Inkonsistentes System, technische Schulden, wachsende Ausnahmeliste. Das Endprodukt ist kein Clean Core, sondern ein Flickenteppich.

Gegenmaßnahme: Governance-Gremien haben feste Taktung (Architecture Board: 2-wöchig), verbindliche Entscheidungsvorlagen und ein dokumentiertes Ausnahme-Log. Non-Compliance mit Guardrails blockiert den Transport ins Produktivsystem (ChaRM-Integration).

11. Praxisnahe Checkliste: Blueprint-Qualitätssicherung vor der Realize-Phase

Diese Checkliste dient als Qualitätsgate. Alle Punkte sollten vor dem Eintritt in die Explore/Realize-Phase abgehakt sein.

Checkliste zur Qualitätssicherung eines SAP S/4HANA Blueprints vor dem Übergang in die Explore- und Realize-Phase.

Tipp für die Praxis:

Führe die Blueprint-Checkliste als lebendes Dokument in SAP Cloud ALM. Offene Punkte sind automatisch Backlog-Items für den Explore-Start.

Ein unvollständiger Blueprint ist kein Startpunkt für Realize – er ist ein Risiko.

12. Konkrete Testfälle aus dem Blueprint: Drei Beispiele

Der Blueprint definiert nicht nur Prozesse und Architektur – er legt auch die Basis für das Testkonzept. Testfälle, die sich direkt aus Blueprint-Entscheidungen ableiten, vermeiden späte Überraschungen in der Realize-Phase. Drei repräsentative Beispiele:

Beispiel für einen End-to-End Order-to-Cash-Testfall im SAP S/4HANA Blueprint mit Fit-to-Standard-Prüfung. — Testfall 1: End-to-End Order-to-Cash (O2C)

Testfall für die Integration eines externen Logistikdienstleisters via OData API und SAP Integration Suite CPI. — Testfall 2: Schnittstellentest – Externer Logistikdienstleister (API)

Security-Test zur Prüfung von Segregation-of-Duties-Konflikten im SAP S/4HANA Rollen- und Berechtigungskonzept. — Testfall 3: SoD-Konfliktprüfung – Kreditorenanlage und Zahlungsfreigabe

Praxistipp:

Hinterlege alle drei Testfalltypen bereits im Blueprint als Testkonzept-Skelett in SAP Cloud ALM.

Je Testfall: Testdaten, erwartetes Ergebnis, Verantwortlicher und Freigabekriterium sind Pflichtfelder – kein Testfall ohne Definition of Done.

Ausblick: Teil 4 – Build & Migration

Im nächsten Teil der movisco Transition Strategie konkretisieren wir die Umsetzungsphase: Wie wird der Blueprint in konfigurierten, getesteten und migrierten Code überführt? Wir zeigen das SAP-Activate-Vorgehen in der Realize-Phase, die strukturierte Datenübernahme mit dem S/4HANA Migration Cockpit und die Bedeutung einer iterativen, wellenbasierten Umsetzung.

Fazit: movisco Transition Strategie – Fazit Teil 3

Der Blueprint ist der zentrale Wendepunkt der S/4HANA Migration – aber nur, wenn er wirklich als Steuerungsinstrument genutzt wird. Er entscheidet darüber, ob aus einer fundierten Analyse (Teil 2) eine nachhaltige, updatefähige und sichere Zielarchitektur entsteht – oder ob die Migration lediglich technisch stattfindet, ohne den fachlichen und organisatorischen Mehrwert zu heben. Wer den Blueprint datenbasiert (Assessment-Ergebnisse), prozessorientiert (Fit-to-Standard), architekturell konsequent (Clean Core, API-first) und organisatorisch verankert (Governance, Data Owner, KPIs) erarbeitet, schafft die Grundlage für eine erfolgreiche Realize-Phase – im Sinne eines echten Digital Core.

Über den Autor

Marcel Peters

Marcel Peters ist Managing Consultant bei der movisco AG am Standort Bonn mit mehrjähriger Berufserfahrung in der Beratung von Banken und Versicherungen und hält einen Bachelor Professional of Trade and Commerce (CCI). Seine IT-Expertise umfasst vor allem die SAP Business Suite SAP S/4HANA, die Migration von SAP ECC / R3, die Implementierung von SAP FI/CO und SD/MM in Banken, die Stabilisierung und den Betrieb von SAP S/4HANA, sowie die fachliche und technische Beratung im Bereich FINREP-konformer Meldungen. Seine analytische Expertise basiert vor allem auf jahrelanger Erfahrung in den Bereichen HGB, IFRS 9 und IFRS 17.