SAP S/4HANA Migration: Stabilisierung & Weiterentwicklung – Das System lebt (Teil 6)

movisco Transition Strategie – Wo stehen wir?

Diese Serie begleitete die S/4HANA Migration als End-to-End-Reise entlang der movisco Transition Strategie – von der ersten strategischen Einordnung bis zur dauerhaften Exzellenz im Betrieb.

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?

Teil 5 zeigt: Wie wird aus einem fertig gebauten System ein produktiv laufendes – sicher, kontrolliert und mit klarem Fallback?

Teil 6 beantwortet die abschließende Frage: Wie wird aus einem erfolgreichen Go-Live ein dauerhaft exzellentes, innovationsfähiges System?

Kernaussage

Der Go-Live ist nicht das Ende – er ist der Anfang des eigentlichen Betriebs.

Wer nach dem Go-Live in den Ruhemodus fällt, verliert in wenigen Jahren die Updatefähigkeit, die Datenqualität und die Akzeptanz der User – trotz eines perfekten Projekts.

Stabilisierung bedeutet: Betrieb absichern. Weiterentwicklung bedeutet: Innovationspotenziale heben, ohne Clean Core zu opfern. Beides gehört zusammen – und beides braucht Steuerung.

Zentrale Ergebnisse dieses Teils

Übergang von Hyper-Care zu nachhaltigem Application Management (AMS)
Clean Core im Betrieb: ATC, Architecture Board und Technical-Debt-Steuerung als Dauerprozesse
SAP-Release-Management: Upgrade-Strategie, Sandbox-Tests und Regressionsabsicherung
Prozessverbesserung im Betrieb: Signavio Process Mining, Embedded Analytics, BTP-Automatisierung
BTP-Innovationen gezielt heben: SAP Build, AI-Services und Side-by-Side-Extensions
MDG, GRC und SoD als operative Daueraufgaben – nicht als Projekteinmalthemen
Serienrückblick: Die movisco Transition Strategie im Gesamtüberblick

1. Von Hyper-Care zu stabilem Betrieb: Der Übergang

Die Hyper-Care-Phase aus Teil 5 hat das System stabilisiert und die häufigsten Anfangsdefekte behoben. Der Übergang in den normalen Betrieb ist keine automatische Konsequenz des Zeitablaufs – er ist eine formelle Entscheidung mit definierten Kriterien.

Checkliste für den strukturierten Übergang von der Hypercare-Phase in das Application Management nach einer SAP S/4HANA Migration.

Praxisregel: Kein Betriebsübergang ohne schriftliche Abnahme durch den Fachbereich. Eine mündliche 'läuft ja eigentlich ganz gut'-Aussage ist keine Abnahme. Das AMS-Team braucht einen klaren Übergabepunkt – sonst ist niemand verantwortlich.

2. Application Management Support (AMS): Betrieb strukturiert gestalten

Ein professionelles AMS-Modell ist der Unterschied zwischen reaktivem Feuerlöschen und proaktiver Systemexzellenz. Es definiert Verantwortlichkeiten, Prozesse und Eskalationswege für den laufenden Betrieb.

Übersicht der vier Support-Ebenen eines SAP S/4HANA Application Management Supports – vom User Support bis zum SAP Support.

Incident & Problem Management

Incident: Einmaliges Ereignis mit Systemauswirkung – wird schnell behoben und geschlossen
Problem: Wiederkehrendes Incident-Muster – Root-Cause-Analyse führt zu dauerhafter Lösung; ITIL-konform
SLA-Definition: P1: 4h Reaktion / 24h Lösung; P2: 8h / 48h; P3: 48h / 5 Werktage – je nach Vereinbarung
Monitoring-Tools: SAP Cloud ALM (Application Operations), SAP Solution Manager (System Monitoring), CCMS-Alerts. RISE with SAP / Cloud ERP: Im Cloud-Betrieb übernimmt SAP Cloud ALM for Operations das reaktive Monitoring (Incidents, Systemverfügbarkeit, Alert-Management). SAP Signavio Process Intelligence steuert komplementär die proaktive Prozessoptimierung: Cloud ALM sieht, ob das System läuft – Signavio sieht, ob die Prozesse richtig laufen. Beide Werkzeuge zusammen ergeben das vollständige Betriebsbild.

3. Release- und Upgrade-Management: SAP-Innovation sicher einführen

SAP S/4HANA wird kontinuierlich weiterentwickelt. SAP veröffentlicht jährliche Releases mit neuen Funktionen, Korrekturen und geänderten Prozessen. Wer diese Zyklen ignoriert, verliert in wenigen Jahren den SAP-Support und riskiert steigende technische Schulden.

Übersicht der SAP S/4HANA Release-Strategie mit Biennial Releases, Feature Package Stacks und Support Package Stacks. — SAP S/4HANA Release-Strategie

Upgrade-Prozess: Sicher und getestet

Sandbox-Test: Upgrade zuerst im Sandbox-System; Auswirkungen auf Custom Code (ATC), Prozesse und Schnittstellen bewerten
Regressionstest-Paket ausführen: Automatisierte Regressionstests aus Teil 5 sichern Clean-Core-Konformität; Abweichungen identifizieren
Entwicklungsanpassungen: ATC-Findings aus dem Upgrade-Test bereinigen; Clean-Core-Guardrails einhalten
QAS-Upgrade und Integrationstest: Alle Schnittstellen und kritischen Prozesse in QAS validieren
Produktiv-Upgrade in vereinbartem Wartungsfenster: ChaRM-dokumentiert; Fallback-Plan aktiv

Clean-Core-Dividende: Wer im Projekt konsequent auf Clean Core geachtet hat, merkt es beim ersten Upgrade. Systeme mit hohem Custom-Code-Anteil benötigen oft Wochen für Upgrade-Anpassungen. Clean-Core-Systeme schaffen dasselbe Upgrade in Tagen – mit automatisierten Regressionstests als Sicherheitsnetz.

4. Clean Core im Betrieb: Dauerhaft, nicht einmalig

Clean Core ist kein Projektergebnis, das einmal erreicht und dann festgehalten wird. Es ist eine Betriebsdisziplin, die aktiv gepflegt werden muss – denn jede neue Anforderung ist eine potenzielle Clean-Core-Abweichung.

Architecture Board im Run-Betrieb

Takt: Mindestens monatlich; bei aktiver Entwicklungsphase 2-wöchig
Agenda: Neue Entwicklungsanforderungen bewerten; Ausnahme-Log reviewen; Upgrade-Auswirkungen einschätzen
Ausnahme-Register: Jede genehmigte Abweichung vom Standard ist dokumentiert – mit Begründung, Verantwortlichem und geplantem Ablösedatum
Clean-Core-Score: Monatlicher Bericht: Anteil ABAP-Cloud-konformer Objekte, offene ATC-Findings, Ausnahmen gesamt

Technical Debt Management

Technische Schulden entstehen auch in gut geführten S/4HANA-Systemen – durch Zeitdruck, pragmatische Entscheidungen oder neue SAP-Standards, die alte Lösungen überholen. Das Ziel ist nicht Null-Schulden, sondern ein gesteuerter Abbau.

Maßnahmen zur kontinuierlichen Sicherung eines Clean-Core-Ansatzes und zum Management technischer Schulden im SAP S/4HANA Betrieb.

5. Kontinuierliche Prozessverbesserung: Das System lernt

Mit Go-Live beginnt das echte Prozess-Leben. Nutzungsdaten, Prozessabweichungen und neue Anforderungen liefern täglich Informationen, die für Verbesserungen genutzt werden können – wenn die richtigen Werkzeuge aktiv sind.

SAP Signavio Process Mining im Betrieb

Was es liefert: Echte Prozessdurchläufe aus S/4HANA-Daten; Variantenanalyse; Engpassidentifikation; Vergleich Soll vs. Ist
Typische Erkenntnisse: Welche Prozesse werden umgangen? Wo entstehen manuelle Workarounds, die im Projekt nicht sichtbar waren? Welche Varianten dominieren?
Aktionsrahmen: Signavio-Erkenntnisse sind Backlog-Input; Process Owner priorisiert Verbesserungen im monatlichen Rhythm

Embedded Analytics: Daten sichtbar machen

SAP Analytics Cloud (SAC): Managementberichte, KPI-Dashboards, Planungsszenarien – direkt auf S/4HANA-Daten
CDS-View-basierte Reports: Operative Berichte direkt in Fiori-Apps; keine separate Datentransformation nötig
Selbstservice-Analytics: Key User können eigene Reports erstellen (SAC Stories); Entlastung der IT von Standard-Reportingaufgaben

Automatisierung: Prozesse schlanker machen

Überblick über Workflow-Automatisierung, RPA, KI-Services und Event Mesh für die kontinuierliche Optimierung von SAP S/4HANA Prozessen.

6. BTP-Innovationen gezielt heben: Innovation ohne Risiko

Die SAP Business Technology Platform ist die Innovationsschicht über dem S/4HANA-Kern. Sie ermöglicht neue Anwendungen, Integrationen und KI-Funktionen – ohne den SAP-Standard zu berühren. Das ist das Versprechen von Clean Core: Kern stabil, Innovation auf der Platform.

Einsatzmöglichkeiten der SAP Business Technology Platform für Low-Code, Automatisierung, KI, Integration und Analytics in SAP S/4HANA.

Entscheidungsprinzip für BTP-Projekte: Löst dieses Vorhaben ein echtes Geschäftsproblem? Ist die Lösung Clean-Core-konform? Ist der Nutzen messbar? BTP-Projekte ohne klaren Business Case und ohne Architecture-Board-Freigabe sind Technologie um der Technologie willen – und erzeugen neue technische Schulden auf einer neuen Plattform.

7. Stammdaten, Compliance und Security: Daueraufgaben, keine Einmalthemen

MDG-Governance, SoD-Monitoring und Security-Patches sind keine Projekte, die nach Go-Live abgeschlossen werden. Sie sind operative Daueraufgaben, die in den Betriebsrhythmus integriert sein müssen.

MDG: Stammdaten-Qualität dauerhaft sichern

Governance-Rhythmus: Monatlicher Datenqualitätsbericht je Domäne (Material, Debitor, Kreditor); KPIs aus Blueprint sind weiterhin aktiv
MDG-Workflows: Neuanlage und Änderung von Stammdaten nur über freigegebene MDG-Workflows – kein Backdoor-Zugriff via Transaktion
Dublettenprüfung: Quartalsweise automatisierter Abgleich; Dubletten werden durch Data Owner bereinigt, nicht von der IT
Stammdaten-Reviews: Jährlicher Review aller Stammdatendomänen auf Vollständigkeit, Aktualität und Relevanz

GRC / SoD: Compliance dauerhaft

Kontinuierliches SoD-Monitoring: SAP GRC Access Control prüft laufend alle Rollenzuweisungen gegen die SoD-Matrix – nicht nur beim Rollout
Access Risk Analysis: Quartalsweise formelle Risikoanalyse; Ergebnisse an interne Revision
Rollenreview: Jährlicher Review aller Business Roles; nicht mehr genutzte Rollen werden deaktiviert
Firefighter-Log-Review: Notfallzugriffe (Firefighter) werden monatlich durch Compliance-Team ausgewertet

Security und Patch Management

SAP Security Notes: SAP veröffentlicht monatlich (Patch Tuesday) Security Notes; kritische Patches innerhalb von 72h eingespielt
Vulnerability-Scanning: Quartalsweise Schwachstellenscans auf SAP-Systemen; Ergebnisse sind AMS-Aufgabe
Verschlüsselung und Protokollierung: Transport-Verschlüsselung, Read Access Logging (RAL) für sensitive Daten – laufend überwacht

8. KPIs für Stabilisierung & Weiterentwicklung

Der Betrieb braucht eigene Kennzahlen – andere als das Projekt. Sie messen nicht Fortschritt, sondern Qualität und Entwicklung im laufenden Betrieb.

Kennzahlen zur Messung von Systemstabilität, Clean Core, Datenqualität und User-Akzeptanz im laufenden SAP S/4HANA Betrieb.

9. Typische Fehler nach dem Go-Live

Die größten Risiken im Betrieb entstehen nicht durch einen einzelnen Fehler, sondern durch schleichende Vernachlässigung. Die folgenden Muster sind in realen S/4HANA-Umgebungen nach 12–24 Monaten Betrieb wiederholt beobachtet worden.

Fehler 1: Architecture Board tagt nicht mehr

Projektmuster: Nach dem Go-Live trifft das Architecture Board immer seltener zusammen. Entwicklungsanforderungen werden direkt im AMS-Team entschieden – ohne Guardrail-Prüfung. Folge: Innerhalb von 12 Monaten wächst der Custom-Code-Anteil wieder. Ausnahmen werden zur Regel. Das nächste Upgrade dauert dreimal länger als geplant. Gegenmaßnahme: Architecture Board hat festen monatlichen Takt – auch im Betrieb. Ein monatlicher Clean-Core-Score wird an das Steering Committee berichtet. Ausnahmen sind sichtbar und werden aktiv abgebaut.

Fehler 2: Upgrades werden aufgeschoben

Projektmuster: Das Annual Release erscheint, aber das Projekt-Team ist aufgelöst und niemand fühlt sich verantwortlich. Das Upgrade wird auf 'nächstes Jahr' verschoben – drei Jahre in Folge. Folge: Das System ist drei Major-Releases hinter dem aktuellen SAP-Stand. SAP-Support läuft aus. Aufholarbeit kostet ein Vielfaches eines rechtzeitigen jährlichen Upgrades. Gegenmaßnahme: Upgrade-Rhythmus ist Teil des Betriebsvertrags (AMS-SLA). Jährlicher Upgrade-Plan wird im ersten Quartal erstellt. Sandbox-Tests laufen automatisiert – keine Ausrede für Verschiebungen.

Fehler 3: Stammdatenqualität verfällt

Projektmuster: MDG-Governance-Regeln werden nach dem Go-Live als 'zu aufwendig' empfunden. Fachbereiche beginnen, Stammdaten über Hilfswege anzulegen. Data Owner nehmen ihre Rolle nicht mehr wahr. Folge: Dubletten, veraltete Konditionen, fehlerhafte Lieferantenprofile – die Datenqualität fällt innerhalb von 18 Monaten auf Vor-Migrationsniveau. Der Business Case des Projekts wird rückgängig gemacht. Gegenmaßnahme: Data Owner sind Betriebsrollen, keine Projektrollen. Monatliche Datenqualitäts-KPIs sind verpflichtend. Bei Unterschreitung von Schwellenwerten wird an das Steering Committee eskaliert.

Fehler 4: BTP-Aktionismus ohne Steuerung

Projektmuster: Nach Go-Live entstehen mehrere BTP-Projekte parallel, initiiert von verschiedenen Fachbereichen und IT-Teams. Jedes Projekt entwickelt eigene Integrationsmuster, eigene Governance und eigene Datenzugriffe. Folge: BTP-Wildwuchs: Inkompatible iFlows, redundante Entwicklungen, unkontrollierte Datenzugriffe auf S/4HANA. Die Integrationslandschaft ist komplexer als vor dem Projekt. Gegenmaßnahme: Jede BTP-Initiative durchläuft das Architecture Board. Es gibt eine BTP-Plattform-Governance mit definierten Standards für Naming, Authentifizierung, Monitoring und Kostensteuerung. Der Integration Architect verantwortet die Gesamtarchitektur.

Fehler 5: User-Akzeptanz wird nicht gemessen

Projektmuster: Drei Monate nach Go-Live weiß niemand, wie viele User das System tatsächlich produktiv nutzen und wie viele heimlich auf alte Workarounds ausweichen. Folge: Prozesse, die theoretisch im System abgebildet sind, werden in der Praxis weiterhin manuell abgewickelt. Der Nutzen des Projekts wird nicht realisiert. Die Investition amortisiert sich nicht. Gegenmaßnahme: Aktive-User-Rate und Fiori-App-Nutzung werden monatlich ausgewertet (Cloud ALM / Analytics Cloud). Unter der 80%-Schwelle wird eine Ursachenanalyse durch den Process Owner ausgelöst.

10. Checkliste Stabilisierung & Weiterentwicklung

Diese Checkliste ist kein Einmalwerkzeug – sie ist ein jährliches Review-Instrument, das sicherstellt, dass das S/4HANA-System dauerhaft auf dem Weg der Exzellenz bleibt.

Checkliste mit den wichtigsten Maßnahmen für den langfristig erfolgreichen Betrieb eines SAP S/4HANA Systems.

11. Serienrückblick: Die movisco Transition Strategie im Gesamtüberblick

Diese Serie hat die S/4HANA Migration als durchgängige End-to-End-Reise beschrieben – von der ersten Frage "Warum S/4HANA?" bis zur dauerhaften Betriebsexzellenz. Hier ist der vollständige Weg im Überblick:

Übersicht aller sechs Teile der movisco Blogserie zur SAP S/4HANA Migration – von der strategischen Einordnung bis zur nachhaltigen Weiterentwicklung.

Was die sechs Teile verbindet, ist mehr als ein gemeinsames Thema. Es ist eine Haltung:

Entscheidungen vor Technik: Jede Phase beginnt mit Klarheit über Ziele und Kriterien – nicht mit Tools und Konfiguration
Messen statt vermuten: Assessment-Metriken, ATC-Reports, Mock-Fehlerquoten, KPI-Dashboards – Fakten führen, Bauchgefühl folgt
Menschen im Mittelpunkt: Change-Management, Key-User-Einbindung, Superuser-Netzwerke – Technologie wird nur genutzt, wenn Menschen sie annehmen
Qualität als Prozess: Checklisten, Qualitätsgates, Abbruchkriterien und Architecture Boards sind keine Bürokratie – sie sind der Unterschied zwischen nachhaltiger Transformation und kurzfristigem Go-Live

Gesamtfazit: Der Weg war das Ziel

SAP S/4HANA ist kein Ziel, das man einmal erreicht. Es ist eine Plattform, auf der ein Unternehmen dauerhaft besser wird – schneller, datenbasierter, innovationsfähiger. Wer die sechs Phasen der movisco Transition Strategie konsequent durchläuft – von Einordnung über Assessment, Blueprint, Build und Test bis zur Stabilisierung – schafft nicht nur ein neues System. Er schafft eine belastbare Grundlage für die nächsten Jahre.

Der Go-Live war wichtig. Aber was danach kommt, entscheidet über den echten Return on Investment: ein System, das täglich besser wird, weil die Menschen dahinter täglich besser damit umgehen. Das ist das Versprechen der movisco Transition-Strategie – und der rote Faden dieser Serie.

Ü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.