SAP ECC zu S/4HANA: Fallstudie aus dem Handel im Nahen Osten

Das ist meine Lieblingsfallstudie. Ein bekannter Händler für Mode und Konsumgüter im Nahen Osten stieg von SAP ECC 6.0 auf S/4HANA um. Er hatte rund 18.000 Mitarbeitende, mehr als 1.200 Filialen in sieben Ländern und einen wachsenden E-Commerce-Kanal. ECC lief dort seit Jahren, und 44 Prozent der Systemobjekte waren angepasst. Wir entschieden uns für eine Brownfield-Konvertierung mit selektivem Redesign. Der Monatsabschluss, der früher bis ins Wochenende reichte, war vor dem Mittagessen fertig, und der Custom Code sank um fast die Hälfte.

Wenn Sie ein stark angepasstes ECC-System betreiben und sich fragen, wie viel davon Sie mitnehmen sollen, zeigt dieses Beispiel, wie ein Programm diese Frage beantwortet hat.

Die Anpassungen waren langsam gewachsen, eine dringende Korrektur nach der anderen. Als wir anfingen, war schon ein kleines Update riskant. Die Integrationen waren fragil: Eine kleine Änderung im Finanzwesen konnte im operativen Handelsgeschäft etwas kaputt machen. Der Fachbereich wollte Flexibilität und Tempo. Die IT ging im Feuerlöschen auf. Beide Seiten räumten ein, dass sie aneinander vorbei arbeiteten.

Ich erinnere mich an eine Sitzung, in der das Supply-Chain-Team ein wenig lachte, als es zugab, dass Dutzende ihrer „kritischen“ Berichte kaum noch angefasst wurden. Sie zu streichen war praktisch und seltsam befreiend.

Auslöser war das Ende der Standardwartung für ECC. SAP ERP 6.0 auf den Erweiterungspaketen 6 bis 8 verlässt die Standardwartung Ende 2027 (SAP News). Die eigentlichen Treiber lagen tiefer. Das Finanzwesen zog jeden Monatsabschluss manuelle Extrakte. Die Filialen brauchten Bestandstransparenz, die nächtliche Batch-Jobs nicht liefern konnten. Der größte Teil des IT-Aufwands ging in den Erhalt von Custom Code.

Der SAP Readiness Check bestätigte, was wir vermutet hatten: ein stark angepasstes System mit erheblichem Anpassungsaufwand. Die Simplification Item List zeigte, wo der S/4HANA-Standard bereits leistete, was der kundeneigene ECC-Code bisher geleistet hatte. Das Finanzwesen stellte fest, dass einige lange gepflegte Eigenberichte nun überflüssig waren. Die Erleichterung in dieser Sitzung war nicht zu übersehen.

Eine reine technische Konvertierung hätte die Probleme nur weitergeschoben. Ein vollständiger Greenfield-Neuaufbau hätte ein Jahrzehnt funktionierender Konfiguration weggeworfen. Brownfield mit selektivem Redesign war der Ausgleich: Solides behalten, bereinigen, was Bereinigung brauchte, und nur neu bauen, was kaputt war. Wie Sie diese Wege abwägen, erkläre ich in meinem Leitfaden zur ECC-zu-S/4HANA-Migration.

Reine KonvertierungBrownfield mit selektivem RedesignVollständiger Greenfield-Neuaufbau

Konfiguration übernommenReine KonvertierungAlles, samt ProblemenBrownfield mit selektivem RedesignWas solide warVollständiger Greenfield-NeuaufbauNichts, ein Jahrzehnt Arbeit verworfen

44 Prozent angepasste ObjekteReine KonvertierungUnverändert übernommenBrownfield mit selektivem RedesignJedes zum Stilllegen, Ersetzen oder Anpassen markiertVollständiger Greenfield-NeuaufbauNicht übernommen

Was das bedeutetReine KonvertierungDie Probleme ziehen nach S/4HANA umBrownfield mit selektivem RedesignBereinigen, was Bereinigung braucht, nur neu bauen, was kaputt istVollständiger Greenfield-NeuaufbauJeder funktionierende Prozess wird von Grund auf neu gebaut

Herausforderung	Was wir getan haben
44 Prozent angepasste Objekte	Fachbereich und IT haben jedes Objekt gemeinsam markiert: stilllegen, ersetzen oder anpassen; Quality Gates je Phase
Fragile Integrationen	Regressionsplan für POS, WMS, Finanzwesen, HR und Lieferantenportale; Punkt-zu-Punkt-Verbindungen auf SAP-Integration-Suite-Muster umgestellt
Datenqualität	Data Stewards je Funktion mit SLAs; tägliche Fehlerverfolgung; Bereinigung vor der QA abgeschlossen
Akzeptanz über Ländergrenzen hinweg	Rollenbasierte Arbeitsanleitungen, Floor-Walks kurz vor dem Go-live, Schulungen an realen Arbeitsaufgaben

Custom Code im großen Maßstab

Die Ergebnisse des Readiness Checks wirkten wie ein Filter. Fachbereich und IT setzten sich zusammen und markierten jedes Objekt. Manche waren eindeutig überflüssig, etwa Berichte, von denen niemand mehr wusste, wann sie zuletzt gelaufen waren. Andere trugen wirklich einzigartige Handelsprozesse und brauchten ein sorgfältiges Redesign. Das zwang die Teams zu entscheiden, statt zu vertagen. SAP Signavio half, die neuen Prozesse an Best Practices auszurichten, und smartShift übernahm automatisierte Code-Scans und Korrekturen mit geringem Wert, sodass die Zeit der Senior-Leute für das Redesign blieb. Wie ich Custom Code heute klassifiziere, steht in meinem Clean-Core-Leitfaden.

Integrationen

ECC war an Kassensysteme (POS), das Lagerverwaltungssystem (WMS), das Finanzwesen, HR und mehrere Lieferantenportale angebunden. Wir bauten einen Regressionsplan über alle und testeten nach jeder wesentlichen Konfigurationsänderung, nicht erst am Ende. Nächtliche Batch-Jobs mussten in S/4HANA schneller fertig werden, sonst wären die Morgenberichte des Lagers nicht rechtzeitig fertig gewesen.

Datenqualität

Doppelte Lieferantenstammsätze und veraltete Stammdaten zogen das Testen in die Länge. Die Lösung war strukturell: ein Data Steward in jeder Funktion, mit SLAs für die Klärung. War die Datenlage zu Beginn der QA nicht sauber, ging sie an den Steward zurück. Als der Cutover näher rückte, probten wir die Ladevorgänge durchgängig und verfolgten Fehler täglich. Diese einfache Routine funktionierte besser als jedes schicke Dashboard, was mich bis heute überrascht. Das Muster beschreibe ich in meinem Artikel darüber, warum SAP-Datenmigrationen scheitern.

Akzeptanz

Die Schulungen erreichten 26.000 Mitarbeitende. Finanzwesen und Handelsbetrieb hatten unterschiedliche Prioritäten, was in einem frühen Workshop zutage trat und das Schulungsdesign veränderte. Als der Druck kurz vor dem Go-live stieg, setzten wir rollenbasierte Arbeitsanleitungen und Floor-Walks ein. Eine Filialleiterin sagte später, die zweiseitige Anleitung habe mehr bewirkt als jede Mitarbeiterversammlung. Ich glaubte ihr.

Phasenweise Umsetzung mit SAP Activate. Das Kernfinanzwesen und die Supply Chain wurden zuerst umgestellt, HR und Lieferantenportale später, damit die Support-Teams nie überlastet waren. Jede Umgebung hatte genau eine Aufgabe. Die Sandbox validierte den Weg und fixierte den Umfang. Die Entwicklung stabilisierte die Transporte. Die QA fuhr reale Geschäftsvolumen und optimierte Jobs. Die Vorproduktion war eine echte Generalprobe. Die Einführungstermine richteten sich nach Spitzen- und Nebensaison im Handel.

Testen mit dem Fachbereich. Die Verantwortlichen aus Finanzwesen und Supply Chain testeten gegen reale Periodenabschluss- und Aktionszyklen, mit Skripten, die an der geschäftlichen Realität statt an der Systemlogik ausgerichtet waren. Nachtläufe deckten Timing-Probleme auf. Ich erinnere mich, wie jemand aus der Lagerleitung lächelte, als der zweite Lauf nach Wochen der Frustration reibungslos durchging.

Cutover-Proben. Jede Aufgabe wurde zeitlich erfasst, gekürzt oder zusammengelegt. Allein der Probelauf sparte Stunden, die eine Tabelle nie offenbart hätte. Wiederherstellungspläne standen auf einseitigen Handzetteln, und die Leute sagten, diese einfache Liste habe mehr Stress abgebaut als jedes Dashboard. Eine Pilotfiliale bewies die Stabilität von POS und WMS vor dem breiteren Rollout.

Hypercare. Ein gemeinsamer War Room für IT und Fachbereich, klare SLAs und tägliche Maßnahmenlisten. Wochenendschichten wurden rotiert, und die Support-Übergaben waren minutengenau geskriptet. Meist erinnert man sich an Zahlen. Ich erinnere mich am meisten an die erste ruhige Nacht.

Finanzabschluss. Die Teams sagten, der Monatsabschluss sei nun vor dem Mittagessen fertig, wo er früher bis ins Wochenende reichte. Am meisten freute sich der CFO, dass er seine Berichte viel schneller hatte. Jemand aus der Finanzleitung scherzte, das System laufe endlich „schneller als die Kaffeemaschine“. Solche Momente schaffen mehr Vertrauen als jede Präsentation.

Custom Code. Um fast die Hälfte gesunken, was die langfristige Support-Last und das Regressionsrisiko bei jedem künftigen Upgrade senkte.

Reporting und Benutzererlebnis. Filialleiter wechselten von alten Transaktionsmasken zu SAP-Fiori-Apps. Die Schulungszeit sank, weil die Apps so funktionierten, wie die Leute es erwarteten. Eine Führungskraft nannte es „erfrischend“.

Integrationen. Die Verbindungen zwischen POS, WMS und Finanzwesen wurden stabiler, und nächtliche Jobs liefen früher durch.

Nicht alles kam gleichmäßig an. Manche Teams hielten an alten Berichten fest, obwohl es bessere gab. Manche fanden die Workshops zu lang und die Proben repetitiv. Rückblickend waren genau diese Schritte das Sicherheitsnetz.

Lektion	Was passierte	Was ich nächstes Mal tun würde
Früh abstimmen	In einem Workshop sagten die Filialleiter, ihre Reporting-Anforderungen unterschieden sich stark von denen des Finanzwesens. Das kam früh heraus, und wir passten an; später wäre es beim Cutover explodiert	Strukturierte Abstimmungssitzungen vor Designbeginn ansetzen
Die Code-Prüfung am ersten Tag beginnen	Mehrere Objekte wurden kurz vor dem Go-live unter Druck überarbeitet	Entscheidungen zum Stilllegen, Ersetzen oder Anpassen ab dem Kickoff treffen
Daten zur Fachbereichsaufgabe machen	Doppelte Lieferantenstammsätze bremsten das Testen	In Woche eins Data Stewards je Funktion mit SLAs benennen
Mehr proben, als nötig erscheint	Ein Probelauf deckte Sequenzkonflikte zwischen POS und WMS auf, die niemand vorhergesagt hatte	Zusätzliche Proben einplanen; die letzte vor dem Go-live sollte sich langweilig anfühlen

Würde dasselbe Programm heute starten, würden sich drei Dinge ändern. Die meisten Unternehmen in dieser Lage würden sich heute S/4HANA Cloud Private Edition unter RISE with SAP ansehen, statt on-premise zu bleiben. Die Entscheidungen zum Stilllegen, Ersetzen oder Anpassen würden an den Clean-Core-Stufen A bis D von SAP ausgerichtet. Change- und Deployment-Tracking liefe in SAP Cloud ALM, weil Solution Manager 7.2 Ende 2027 die Standardwartung verlässt. Die Data Stewards, die Proben, der gemeinsame War Room und die zweiseitigen Anleitungen blieben genau so, wie sie waren. Für die menschliche Seite siehe meinen Leitfaden zu SAP-Schulungsstrategien.

Warum wechseln Unternehmen von SAP ECC auf S/4HANA?

Auslöser ist das Ende der ECC-Standardwartung im Jahr 2027. Die stärkeren Gründe sind operativ: Reporting in Echtzeit, ein schnellerer Abschluss und weniger Aufwand, um Custom Code und fragile Integrationen am Leben zu halten. In diesem Fall wollte der Fachbereich Live-Analysen für den Handel und einen kürzeren Monatsabschluss.

Was zeigte der SAP Readiness Check in diesem Fall?

Er bestätigte, dass 44 Prozent der Objekte angepasst waren und viele seit Jahren nicht genutzt wurden. Das veränderte, wie die Arbeit am Custom Code aufgebaut wurde: zuerst stilllegen, wo möglich durch Standard ersetzen und nur anpassen, was echten geschäftlichen Wert hatte. Die Simplification Item List zeigte außerdem Berichte, die der S/4HANA-Standard überflüssig machte.

Warum Brownfield mit selektivem Redesign?

Eine reine technische Konvertierung hätte jedes Problem weitergetragen, und ein vollständiger Greenfield-Neuaufbau hätte ein Jahrzehnt funktionierender Konfiguration verworfen. Das selektive Redesign behielt, was solide war, nutzte SAP Signavio, um neue Prozesse dort zu definieren, wo Standard die kundeneigene Logik ersetzen konnte, und baute nur neu, was kaputt war.

Was passiert, wenn die Datenbereinigung zu spät kommt?

Das Testen zieht sich, Proben scheitern und der Go-live verschiebt sich. Hier verursachten doppelte Lieferantenstammsätze und veraltete Stammdaten wochenlange Reibung im Test. Die Lösung waren Data Stewards in jeder Funktion mit SLAs und eine Bereinigung, die als Kennzahl für die Programmgesundheit verfolgt wurde.

Wie wurden die Integrationen während der Migration behandelt?

Indem zuerst jede Verbindung erfasst wurde: POS, WMS, Finanzwesen, HR und Lieferantenportale. Ein Regressionsplan deckte alle ab, Tests liefen nach jeder wesentlichen Konfigurationsänderung, und eine Pilotfiliale bewies die Stabilität von POS und WMS vor dem breiteren Rollout. Ein Probelauf fand trotzdem noch einen Sequenzkonflikt zwischen POS und WMS, den niemand vorhergesagt hatte.

Wie sieht gute Hypercare nach einem S/4HANA-Go-live aus?

Ein gemeinsamer War Room für IT und Fachbereich mit klaren SLAs, täglichen Maßnahmenlisten und Problemen, die zügig geschlossen statt im Backlog geparkt werden. Rollenbasierte Anleitungen und Floor-Walks senken die Zahl der Support-Anrufe schneller als formale Schulungen. Rotieren Sie Wochenendschichten und skripten Sie Übergaben, damit das Team nicht ausbrennt.