Fallstudien
Fallstudie zur Migration von SAP ECC zu S/4HANA: Einzelhandelsriese im Nahen Osten
Noel D. Costa
- Letztes Update :
Das ist also meine Lieblingsfallstudie! Diese Fallstudie zur Migration von SAP ECC zu S/4HANA befasst sich mit einem bekannten Einzelhändler aus dem Nahen Osten, der viele Jahre lang auf ECC gesetzt hatte. Das System hatte seinen Zweck erfüllt, wurde aber nach so viel kundenspezifischer Programmierung schwieriger zu verwalten.
Das größte Problem war die Anpassung. 44 % der Systemobjekte wurden angepasst, was einen erheblichen Aufwand darstellt. Wie Sie sich vorstellen können, erfolgten diese Anpassungen über einen längeren Zeitraum.
Kleinere Fehlerbehebungen zogen sich hin, und der Aufwand, die Plattform stabil zu halten, überstieg den Nutzen, den sie brachte. Die Unternehmensleitung gab schließlich zu, dass die Plattform sie eher ausbremste als half.
Der Wechsel zu S/4HANA war mehr als nur eine IT-Übung. Er bot den Geschäfts- und IT-Teams die Chance, Prozesse aufzuräumen, die sich im Laufe der Zeit angesammelt hatten.
Ich erinnere mich an eine Sitzung, in der das Supply-Chain-Team ein wenig lachte, als es zugab, dass Dutzende seiner „kritischen“ Berichte kaum noch bearbeitet wurden. Sie zu streichen war sowohl praktisch als auch seltsam befreiend.
Einige echte Ergebnisse stachen hervor:
Die Finanzteams berichteten, dass ihr Monatsabschluss vor dem Mittagessen abgeschlossen war, während er früher bis ins Wochenende hineinreichte. Der CFO war sehr erfreut, dass er seine Berichte nun viel schneller erhalten konnte!
Die Werbeaktionen im Geschäft wurden schneller live geschaltet, was weniger Supportanrufe zu später Stunde bedeutete. Der Prozess wurde dadurch optimiert.
Der benutzerdefinierte Code wurde um fast die Hälfte reduziert, was den langfristigen Supportaufwand verringerte. SAP Signavio spielte dabei eine große Rolle.
Die Eigentumsverhältnisse bei den Daten, insbesondere im Zusammenhang mit Treueprogrammen, führten zu langen Debatten, die zwar die Dinge verlangsamten, aber nützliche Entscheidungen erzwangen.
Die Integration mit älteren Einzelhandelstools erwies sich als schwieriger als geplant, zeigte jedoch, wo die Reihenfolge wirklich wichtig war.
Die Reaktionen der Mitarbeiter waren oft aussagekräftiger als Kennzahlen. Ein Finanzleiter scherzte, das System funktioniere endlich „schneller als die Kaffeemaschine“. Solche Momente vermittelten mehr Vertrauen als jede Präsentation.
Der Weg war alles andere als einfach, doch das Endergebnis war eine vereinfachte IT-Infrastruktur für das Unternehmen. Weitere praktische Einblicke finden Sie unter ECC-zu-S/4HANA-Migration und Leitfaden zur SAP-Projektplanung und -steuerung.
Diese Fallstudie zur Migration von SAP ECC zu S/4HANA zeigt, wie ein Einzelhändler im Nahen Osten mit 18,000 Mitarbeitern in sieben Ländern ein stark individualisiertes ECC-System vereinfachte, in dem 7 % der Objekte benutzerdefiniert waren. Die Umstellung reduzierte technische Schulden, stabilisierte komplexe Integrationen und ermöglichte den Geschäftsteams schnellere Berichte und mehr Flexibilität, die SAP ECC nicht mehr unterstützen konnte.
10 wichtige Erkenntnisse aus der Fallstudie zur Migration von SAP ECC zu S/4HANA
Der Einzelhändler nutzte SAP ECC seit Jahren, doch 44 % seiner Objekte waren kundenspezifisch angepasst. Dieser hohe Grad an Anpassung erschwerte die Stabilität, und jede kleine Fehlerbehebung zog sich über einen längeren Zeitraum hin.
Der Umstieg auf S/4HANA war nicht nur ein Upgrade, sondern auch eine Transformationsübung. Fach- und IT-Teams hinterfragten gemeinsam die bestehenden alten Prozesse und entschieden, welche wirklich wichtig waren.
Berichte, die einst als „kritisch“ gekennzeichnet waren, wurden nicht einmal verwendet. Durch das Entfernen dieser Berichte wurde Unordnung beseitigt und der Supportbedarf reduziert.
Die Finanzteams erzielten schnelle Ergebnisse. Der Monatsabschluss, der früher ganze Wochenenden in Anspruch genommen hatte, war vor dem Mittagessen abgeschlossen. Der CFO schätzte den schnelleren Zugriff auf Berichte ausdrücklich.
Die Verkaufsförderungsaktionen erreichten die Filialen schneller, und es mussten weniger nächtliche Anrufe bei der IT-Abteilung getätigt werden. Dies vereinfachte die einst stressige Routine.
Die Anpassung des Codes wurde erheblich reduziert, wobei SAP Signavio dabei half, die neuen Prozesse auf der Grundlage bewährter Verfahren zu definieren.
Zwar kam es zu Debatten über die Eigentumsverhältnisse bei den Treueprogrammdaten, die das Projekt etwas verlangsamten, doch wurde dadurch Klarheit über Verantwortlichkeiten geschaffen, die lange Zeit ignoriert worden waren.
Ältere Einzelhandelssysteme stellten eine Herausforderung bei der Integration dar. Die richtige Reihenfolge der Migrationsschritte erwies sich als ebenso wichtig wie die Technologie selbst.
Kleine Benutzerreaktionen verrieten die Geschichte am besten. Ein Finanzleiter scherzte, dass S/4HANA endlich schneller sei als die Kaffeemaschine, was bedeutete, dass Vertrauen aufgebaut wurde.
Das Endergebnis war zwar nicht perfekt, aber solide. Die Prozesse wurden vereinfacht, die IT-Infrastruktur schlanker gestaltet und das Unternehmen erhielt eine solide Basis für weiteres Wachstum. Siehe dazu auch: Warum SAP-Datenmigrationen scheitern und wie Change-Management-Pläne erfolgreich sind.
Der Hintergrund der Fallstudie zur Migration von SAP ECC zu S/4HANA
Diese Fallstudie zur Migration von SAP ECC zu S/4HANA konzentriert sich auf die Umstellung einer zehn Jahre alten ECC-Landschaft auf S/4HANA. Das System hatte lange Zeit Wachstum unterstützt, wurde jedoch mit zunehmender Nutzungsdauer immer schwerer.
Das Unternehmen stützte sich bei fast allen Aufgaben auf die SAP ECC 6.0-Landschaft, und die IT hatte Mühe, mit den neuen Anforderungen Schritt zu halten. Lassen Sie mich Ihnen daher den Hintergrund dieser Fallstudie erläutern.
Zehn Jahre SAP ECC im Produktivbetrieb haben eine große und komplexe Infrastruktur geschaffen. Die anfängliche Implementierung verlief recht standardisiert, doch mit der Zeit entwickelte sie sich zu einem deutlich schwerer zu verwaltenden System. Jedes Jahr brachte mehr WRICEFs und damit verbundene Komplikationen.
44 % der Objekte waren kundenspezifisch angepasst – ein alarmierend hoher Wert. Diese Änderungen erfolgten schrittweise, meist aufgrund dringender Bedürfnisse. Niemand ahnte das Ausmaß der Anpassungen, bis deutlich wurde, dass selbst einfache Updates Risiken bargen. Die SAP-ECC-Umgebung war instabil geworden, und Stabilität hatte ihren Preis.
Die Integrationen waren unübersichtlich und schlecht gemanagt. ECC war mit Kassensystemen, Lagerverwaltung, Finanzwesen, Personalwesen und diversen Lieferantenportalen verknüpft. Die Teams beklagten sich häufig, dass selbst kleine Änderungen im Finanzbereich unerwartet zu Problemen im Einzelhandel führen konnten. Es klang wie ein Witz, war es aber nicht.
Die technischen Schulden wuchsen stetig. Die Wartungskosten verschlangen jedes Jahr mehr Budget, und die IT-Verantwortlichen begannen, die durch Fehlerbehebungen verlorenen Stunden zu erfassen. Die Zahlen entwickelten sich nur in eine Richtung. Zum Vergleich: Wie ähnliche Probleme in der SAP-Projektrisikobewertung angegangen werden.
Die Beziehung zwischen Fachabteilung und IT war angespannt. Die Fachabteilung forderte Flexibilität und schnellere Reaktionszeiten. Die IT war mit der Bewältigung akuter Probleme beschäftigt. Beide Seiten räumten ein, aneinander vorbei zu arbeiten.
Letztendlich war die SAP-ECC-Landschaft kein Wegbereiter mehr. Sie war zu einer Barriere geworden. Der benutzerdefinierte Code, die Integrationen und die anhaltenden Probleme zwangen den Einzelhändler zu der Erkenntnis, dass Vereinfachung keine Option mehr war.
Fallstudie Kundenprofil: Middle East Retail Group
| Kategorie | Details |
|---|---|
| Kunden | Ein Mode- und Konsumgüterhändler im Nahen Osten mit stationären Geschäften und starkem Online-Umsatz. |
| Größe und Reichweite | Rund 18,000 Mitarbeiter in 7 Ländern der Region, mit mehr als 1,200 Verkaufsstellen und einem aktiven E-Commerce-Kanal. |
| Schlüsselprozesse |
|
| Programmziel | Wechseln Sie von ECC 6.0 zu SAP S/4HANA, reduzieren Sie benutzerdefinierten Code, verbessern Sie die Abschlussgeschwindigkeit und ermöglichen Sie Echtzeit-Einblicke in alle Einzelhandelsabläufe. |
| Anfängliche Herausforderungen |
|
| Wichtiges Unterscheidungsmerkmal | Das Programm balancierte klare Kernziele mit den Anforderungen des Einzelhandels mit hohem Volumen und plante gleichzeitig Umstellungen für den Nachthandel und die regionale Hochsaison. |
Fallstudie zur Migration von SAP ECC zu S/4HANA: Treiber für Veränderungen
Ich muss sagen, diese Fallstudie zur Migration von SAP ECC zu S/4HANA entstand aus einer einfachen Tatsache. Der SAP ECC-Kern hatte einen Punkt erreicht, an dem seine Aufrechterhaltung mehr Energie kostete als die Weiterentwicklung. Ich erinnere mich, dass es im Raum still wurde, als die Wartungsprognosen zur Sprache kamen, was für sich selbst sprach.
1. Ende des Mainstream-Supports für SAP ECC
Da der Mainstream-Support für SAP ECC bald auslief, stand die Geschäftsleitung vor einer Entscheidung über den Zeitpunkt, die keinen Aufschub zuließ. Die Option einer erweiterten Wartung erschien teuer und einschränkend. Dieses Problem haben auch viele Unternehmen, die noch SAP ECC 6.0 nutzen.
Da ein einfaches Upgrade die Probleme nur verschärft hätte, wog das Team verschiedene Migrationspfade ab, z. B. Greenfield, Brownfield usw. In meinem Artikel zur S/4HANA-Migrationsstrategie habe ich dazu einige Hinweise gegeben . Die Diskussion verlagerte sich von den Tools hin zu den Ergebnissen, was eine konstruktivere Auseinandersetzung ermöglichte (etwas, das ich stets befürworte).
Da die Wartungskosten stiegen, forderte der Finanzchef eine verständlichere Wirtschaftlichkeitsberechnung. Das Prinzip war einfach: Kosten senken und die Implementierung sich selbst finanzieren lassen. Die Struktur aus meinem Artikel zur Erstellung einer überzeugenden SAP-Wirtschaftlichkeitsberechnung half dabei, Kosten, Risiken und Nutzen so darzustellen, dass der Vorstand sie mittragen konnte.
Da Risiken frühzeitig kontrolliert werden mussten, planten wir Meilensteine, die dem Ansatz der SAP-Qualitätskriterien entsprachen . Ich denke, diese Disziplin sorgte dafür, dass die Komplexität in stressigen Phasen gering blieb.
2. Echtzeit-Reporting und Vereinfachung erforderlich
Da Filialentscheidungen an Aussagekraft verlieren, wenn Zahlen verspätet eintreffen, drängte der operative Bereich verstärkt auf schnellere und verlässliche Berichterstattung. Der Fokus auf Leistung basierte auf Ideen aus dem SAP-Performance-Testing , wodurch alle Beteiligten hinsichtlich des Durchsatzes transparent informiert wurden.
Da die bestehende Infrastruktur jahrelang WRICEF-Anfragen enthielt, haben wir uns für eine saubere Kernarchitektur entschieden. Dies ist von entscheidender Bedeutung. Es ist wichtig, die Kernarchitektur sauber zu halten und Anpassungen auf Basis von BTP zu entwickeln. Eine saubere Kernarchitektur erleichtert zukünftige Upgrades. Die praktischen Leitlinien der SAP-Strategie für eine saubere Kernarchitektur halfen ihnen bei der Entscheidung, welche Komponenten ersetzt und welche beibehalten werden sollten.
Die Datenmigration war ein zentraler Bestandteil. Als Datenprobleme auftauchten, überarbeitete das Team die Staging- und Cutover-Pläne. Daten wurden als wichtig erachtet, und spezielle Teams arbeiteten an der Datenbereinigung. Mir ist im Laufe der Zeit aufgefallen, dass Daten oft erst während des Projekts und nicht vorher berücksichtigt werden. Ich bevorzuge hier immer noch eine übermäßige Kommunikation, da kleine Fehler schnell zu einem großen Aufsehen erregen können.
Da jede Berichtsanfrage um Zeit konkurriert, haben wir Umfang und Zuständigkeit an die Vorgaben im Projektumfangsmanagement angepasst . Die Reduzierung fiel uns schwer, doch später stellten die Nutzer fest, dass die Dashboards nun endlich Sinn ergaben.
3. Ausrichtung der digitalen Transformation
Da die Roadmap dieses Einzelhandelskunden auf Omnichannel-Wachstum ausgerichtet war, musste die Kernplattform schnellere Veränderungen unterstützen. Eine schlanke Kernstrategie und ein starker Integrationsansatz spielten hier eine entscheidende Rolle. Ziel war die Modernisierung des ERP-Systems , nicht nur ein Upgrade.
Integrationsstrategie und -muster entscheiden über die Stabilität im laufenden Betrieb – das ist allgemein bekannt. In diesem Fall haben wir Schnittstellen abgebildet, und ich habe meine Ansichten in diesem Artikel dokumentiert: SAP-Integrationsplattformen . Einige Integrationen blieben erhalten, viele wurden neu aufgebaut, und einige wenige wurden stillschweigend entfernt. Ziel war es, die Komplexität zu reduzieren und den Fokus auf Einfachheit zu legen.
Mit der Veränderung der Rollen entwickelten wir Stakeholder-Routinen aus der Stakeholder-Management-Strategie . Die Menschen wollten gehört werden, und regelmäßige Foren reduzierten Nebengespräche, die ein Programm normalerweise verlangsamen.
Die Einführung neuer Ansätze war das Herzstück des Programms. 26,000 Mitarbeiter in sechs Ländern – das ist wahrlich keine Kleinigkeit. Da die Einführung neuer Ansätze Vorteile bringt, haben wir Schulungs- und Veränderungspläne auf Basis bewährter Change-Management-Methoden entwickelt . Ein Filialleiter meinte später, die einfachen Arbeitsanweisungen hätten mehr bewirkt als jede Mitarbeiterversammlung, was ich teilweise nachvollziehen kann.
Am Ende waren die Treiber der Modernisierung klar. Das Ende des SAP-Supports gab den Takt vor, während Geschäftsagilität und eine digitale Strategie für den Einzelhandel die Richtung vorgaben. Die Mischung wirkte manchmal etwas chaotisch, hielt das Programm jedoch realistisch und geerdet.
Fallstudie: Treiber: Migration von SAP ECC zu S/4HANA
| Kategorie | Zusammenfassung |
|---|---|
| Ende des Supports für SAP ECC |
Das System hatte ein Stadium erreicht, in dem seine Wartung kostspieliger war als die Weiterentwicklung. Wichtige Punkte waren:
|
| Echtzeit-Reporting und Vereinfachung |
Für den Einzelhandel wurden eine schnellere Berichterstattung und Vereinfachung dringend erforderlich.
|
| Ausrichtung der digitalen Transformation |
Die Migration unterstützte eine umfassendere Transformationsagenda für den Einzelhandel.
|
Fallstudie zur Bewertung und Strategie für die Migration von SAP ECC zu S/4HANA
Eine Sache, die mir in dieser Fallstudie zur Migration von SAP ECC zu S/4HANA aufgefallen ist, ist, dass wir mehr Klarheit hatten, als die S/4HANA-Bereitschaftsbewertung begann. Die Tools sagten uns, was viele bereits vermutet hatten.
Die Landschaft war schwerfällig geworden, und sie so zu verändern, wie sie ist, hätte nur alte Fehler wiederholt. Daher war die Strategie genauso wichtig wie die Umsetzung.
1. SAP Readiness Check und Vereinfachungsliste
- Das Team führte die S/4HANA-Readiness-Check Wir haben uns frühzeitig mit der Problemlösung befasst und Hunderte von Elementen im Zusammenhang mit benutzerdefiniertem Code, veralteten Transaktionen und obligatorischen Prozessänderungen identifiziert. Ehrlich gesagt, ist dies Ihr Ausgangspunkt. Die Liste war viel länger als erwartet, gab aber dem, was sich hätte überwältigend anfühlen können, Struktur.
- Das Vereinfachungselementliste Die Finanzabteilung zeigte, wo der Standard-S/4HANA-Footprint bereits das ersetzte, worauf sich SAP ECC verlassen hatte. Die Finanzabteilung stellte fest, dass einige lange gepflegte benutzerdefinierte Berichte nun überflüssig waren. Die Erleichterung in diesem Meeting war deutlich zu spüren.
- Das Benutzerdefinierter Code-Analysator half dabei, technische Schulden im Detail zu identifizieren. Von Tausenden von benutzerdefinierten Objekten war nur ein Bruchteil wirklich kritisch. Ich erinnere mich, dass Entwickler zugaben, dass einige benutzerdefinierte Routinen seit Jahren nicht mehr angerührt worden waren.
- Lektionen von SAP-Qualitätstore beeinflusste die Reihenfolge dieser Beurteilungen. Durch die Festlegung klarer Kontrollpunkte wurde verhindert, dass die Beteiligten zu weit vom Thema abdrifteten, bevor Entscheidungen getroffen wurden.
2. Sortieren redundanter und kritischer Anpassungen
- Da 44 % der Objekte individuell angepasst waren, bestand die größte Herausforderung darin, nützlichen Code vom Rauschen zu trennen. Die Bereitschaftsergebnisse fungierten als Filter.
- Fachabteilung und IT arbeiteten zusammen, um jedes Objekt zu kennzeichnen. Einige waren eindeutig redundant, wie etwa Berichte, an deren Ausführung sich niemand erinnern konnte. Andere unterstützten einzigartige Einzelhandelsprozesse, die sorgfältig überarbeitet werden mussten. Die Teams mussten entscheiden, nicht aufschieben.
- Einige Debatten zogen sich hin, insbesondere im Zusammenhang mit Treueprogrammen. Doch selbst diese Auseinandersetzungen brachten Klarheit über die Eigentumsverhältnisse, die auf lange Sicht wichtiger waren.
3. Migrationsansatz: Brownfield mit selektivem Redesign
- Der Migrationsansatz tendierte zu Brach weil dadurch bestehende Investitionen geschützt wurden. Nach der Genehmigung durch den Programm-Lenkungsausschuss wurde jedoch bewusst eine selektive Neugestaltung in den Plan eingebaut.
- Durch diesen Weg konnte das Unternehmen den Schock einer kompletten Neugründung vermeiden und gleichzeitig langjährige Prozessprobleme lösen. Der Kompromiss erschien praktikabel.
- Wir haben Strategien überprüft von Greenfield vs. Brownfield. Diese Ressource half dabei, Entscheidungen in einer Sprache zu formulieren, die sowohl technische als auch geschäftliche Führungskräfte akzeptieren konnten.
- Einige Manager befürchteten, dass Brownfield „Lift and Shift“ bedeute. Die Antwort war, dass eine selektive Neugestaltung genügend Raum für Vereinfachungen biete, ohne dass die Kontinuität verloren gehe.
4. Roadmap und schrittweise Einführung
- Der Fahrplan war stufenweise aufgebaut. Zuerst wurden die Kernbereiche Finanzen und Lieferkette bearbeitet, später folgten HR und Lieferantenportale. Diese Reihenfolge reduzierte das Risiko, da die Supportteams nicht überlastet wurden.
- Bei der Planung wurden Richtlinien von Projektplanung und -steuerung. Das Aufteilen der Meilensteine in kleinere, überschaubare Abschnitte gab allen mehr Selbstvertrauen.
- Jede Einführungsphase wurde an die Spitzen- und Nebensaison im Einzelhandel angepasst. Da sich die Geschäfte in der Hochsaison keine Systemausfälle leisten konnten, war der Zeitpunkt nicht verhandelbar.
- Durch die Ressourcenzuweisung konnte die Arbeitsbelastung der Mitarbeiter ausgeglichen werden. Die Teams konnten Burnouts vermeiden, obwohl ich mich an Wochenenden erinnere, an denen der Kaffee knapp wurde.
Am Ende der Bewertung bestätigten wir, was das Unternehmen schon seit Jahren spürte: Die SAP ECC-Landschaft wurde stark angepasst, und die Umstellung auf S/4HANA musste reibungslos erfolgen.
Bei der Roadmap, die auf Bereitschaftsprüfungen und benutzerdefinierten Codeanalysen basierte, ging es weniger darum, Kästchen anzukreuzen, sondern vielmehr darum, eine Plattform zu schaffen, die endlich mit den geschäftlichen Veränderungen Schritt halten konnte.
S/4HANA-Bereitschaft und Migrationsansatz
| Gebiet | Wichtige Punkte |
|---|---|
| Bereitschaftsbewertung |
|
| Benutzerdefinierte Codesortierung |
|
| Migrationsansatz |
|
| Roadmap & Rollout |
|
Sehen Sie, wie ich Ihr ERP und AI Die richtige Systemauswahl oder Implementierung für Sie.
ERP- und KI-Systemauswahl – Identifizieren und wählen Sie die richtige ERP- oder KI-fähige Plattform, die Ihren Geschäftsanforderungen entspricht.
Projektunterstützung & -wiederherstellung – Halten Sie Ihr Projekt auf Kurs oder bringen Sie gescheiterte Implementierungen wieder unter Kontrolle.
ERP-Modernisierung – Transformation bestehender ERP-Systeme in moderne, effiziente und skalierbare ERP-Umgebungen.
KONTAKTVerwandte Artikel: Herausforderungen bei der ERP-Auswahl und -Integration
Wählen Sie das richtige ERP für kleine Unternehmen im Jahr 2025
Eine Untersuchung darüber, wie kleine Unternehmen im Jahr 2025 ERP-Systeme auswählen können, die hinsichtlich Kosten, Umfang und Wachstum geeignet sind.
ERP-Systemauswahl für einen mittelständischen Hersteller in Asien
Ein reales Beispiel für die ERP-Bewertung mit Schwerpunkt auf Fertigungsprioritäten im asiatischen Kontext.
Oracle ERP vs. SAP
Eine Gegenüberstellung zweier wichtiger ERP-Plattformen mit praktischen Überlegungen für Entscheidungsträger.
Lieferverzögerungen bei der SAP Integration Suite
Einblicke in wiederkehrende Engpässe bei der Einführung der SAP Integration Suite und Lehren für Projektmanager.
Unser Migrationsansatz in der Fallstudie zur Migration von SAP ECC zu S/4HANA
Unser Ansatz war praxisorientiert und wir mussten Kompromisse eingehen. Deshalb benötigten wir für diese Fallstudie zur Migration von SAP ECC zu S/4HANA einen Plan, der funktionierte und dem das Team folgen konnte. Dabei mussten wir mehrere Bereiche berücksichtigen:
1. Benutzerdefinierte Codestrategie
Das Team entfernte redundante Objekte und passte rund 56 % der kritischen Objekte an. Die Aufteilung der Objekte erfolgte im Rahmen gemeinsamer Überprüfungen, an denen die Prozessverantwortlichen mit dem SAP-Implementierungsteam zusammenarbeiteten. Dies war eine sehr detaillierte Übung, die jedoch alle Teams zusammenbrachte, um die richtigen Ergebnisse zu erzielen.
Wo sinnvoll, setzten wir automatisierte Korrekturen ein. SmartShift unterstützt Code-Scans und Schnellkorrekturen. Ziel war es, Änderungen mit geringem Wert zu beschleunigen und gleichzeitig Zeit für die Neugestaltung zu sparen. Warum fiel die Wahl auf SmartShift? Weil es die Konvertierung von SAP ECC zu S/4HANA automatisiert und Kompatibilitätsprobleme mit benutzerdefiniertem Code behebt.
Die Entscheidungen basierten auf einem Clean-Core-Ansatz, unterstützt durch die Praktiken der SAP Clean Core Strategie . Dadurch blieb der kundenspezifische Code auf die wesentlichen Alleinstellungsmerkmale im Einzelhandel fokussiert. Besonders hilfreich war dabei, dass der Lenkungsausschuss den Grundsatz durchsetzte, den SAP-Standard zu verwenden und die Anpassungen auf ein absolutes Minimum zu beschränken.
Die Testtiefe war entscheidend, daher haben wir Unit-Tests, Systemintegrationstests (SIT), Benutzerakzeptanztests (UAT) und Regressionstests an den Konzepten der SAP-Test- und Validierungstools ausgerichtet . Die Mitarbeiter waren beruhigter, als wir Ergebnisse vorweisen konnten. Es war ein sehr detaillierter Prozess, und wir nutzten Cloud ALM, um den Testlebenszyklus zu verfolgen.
2. Datenmigrationspfad
Wir führten die technische Konvertierung mit SAP SUM und DMO durch und stellten die Geschäftsdaten über das SAP Migration Cockpit bereit . Diese Vorgehensweise reduzierte den Aufwand und das Risiko während der Umstellung.
Die Regeln für die Datenqualität wurden frühzeitig definiert und Ausnahmen täglich erfasst. Die daraus gewonnenen Erkenntnisse über die Gründe für das Scheitern der Datenmigration halfen uns, eine Ausweitung des Projektumfangs zu verhindern. Ich empfehle Ihnen daher dringend, Ihre Datenmigrationsstrategie im Voraus festzulegen. Beschreiben Sie Ihr Vorgehen detailliert und definieren Sie KPIs für jeden Ihrer Testläufe.
Die Leistungsziele wurden bei jeder Probe anhand der Vorgaben des SAP-Leistungstests gemessen . Ich denke, diese Kontrollen haben uns vor einigen unangenehmen Überraschungen bewahrt.
3. Integration und Schnittstellen-Redesign
Wir vereinfachten Integrationsmuster und ersetzten fehleranfällige Punkt-zu-Punkt-Verbindungen durch API-basierte Architekturen. Die Referenzmaterialien zu SAP-Integrationsplattformen beeinflussten unsere Auswahl an Middleware und Monitoring-Lösungen.
Wo Nachrichtenflüsse komplex blieben, nutzten wir SAP-CPI- Muster, um Zuordnungen, Fehlerbehandlung und Wiederholungsregeln zu standardisieren. Ziel war es, weniger Probleme zu verursachen und die Fehlerbehebung zu beschleunigen.
Die Verantwortung für die Schnittstellen ging mit vereinbarten SLAs an die Produktteams über. Diese Verlagerung der Verantwortlichkeiten, obwohl nur geringfügig, führte zu schnelleren Entscheidungen und weniger Eskalationen.
4. Proben und Umstellungsvorbereitung
Während der Umstellung führten wir zunächst Sandbox-Konvertierungen durch, anschließend Generalproben mit vollständigen Datenmengen. Jeder Durchlauf nutzte Prüfpunkte und Ein- bzw. Austrittskriterien, die den SAP-Qualitätskriterien nachempfunden waren.
Die Umstellungspläne waren zeitlich begrenzt und versioniert, mit Rollen, Ausweichlösungen und Stopp-Go-Regeln, die gemäß den Methoden der Projektplanung und -steuerung dokumentiert wurden . Die Checklisten waren zwar lang, aber sie halfen, Ruhe zu bewahren. Ein detaillierter Umstellungsplan ist besser als ein oberflächlicher, bei dem Fehler passieren können.
Die Ressourcenauslastung erfolgte gemäß den Vorgaben der Ressourcenplanung . Wochenendschichten wurden rotiert und die Übergaben im Supportbereich minutengenau geplant. Dies ist notwendig, um Überlastung im Team zu vermeiden.
Nach der Inbetriebnahme verwendete Hypercare klare SLAs, einen gemeinsamen War Room und tägliche Aktionsprotokolle. Normalerweise erinnern sich die Leute an Zahlen, aber ich erinnere mich am besten an die erste ruhige Nacht.
Kurz gesagt: Die Migrations-Roadmap balancierte die SAP SUM DMO-Mechanik, die S/4HANA-Datenmigrationsdisziplin und eine Integrationsstrategie, die fragile Verbindungen beseitigte. Die Struktur wirkte auf dem Papier einfach und erwies sich in der Praxis als praktikabel.
Ansatz für die Migration von SAP ECC zu S/4HANA
| Schwerpunkte | Schlüsselaktionen |
|---|---|
| Strategie für benutzerdefinierten Code |
|
| Datenmigrationspfad |
|
| Integration & Schnittstellen |
|
| Proben & Cutover |
|
Die wichtigsten Herausforderungen bei der Migration von SAP ECC zu S/4HANA
Die Herausforderungen, denen wir gegenüberstanden, waren nicht überraschend, obwohl jede einzelne aufgrund ihrer Tiefe sorgfältig angegangen werden musste. Zu den wichtigsten Herausforderungen zählten:
1. 44 % der benutzerdefinierten Objekte werden verwaltet
Da fast die Hälfte der Systemlandschaft kundenspezifisch war, gruppierten wir die Objekte zunächst nach Geschäftswert und technischem Risiko. Der Clean-Core-Ansatz der SAP Clean Core-Strategie half dem Team, sich auf die wesentlichen Alleinstellungsmerkmale des Einzelhandels zu konzentrieren. Die Nutzung von smaryShift hat den Prozess für uns deutlich vereinfacht.
Da unüberlegte Maßnahmen zu Verwirrung führen, haben wir Entwickler und Prozessverantwortliche zusammengebracht, um über Außerbetriebnahme, Ersatz oder Anpassung zu entscheiden. Die im Projektmanagement üblicherweise verwendeten Abgrenzungen des Projektumfangs halfen, die damit einhergehende schleichende Ausweitung zu verhindern.
Als das Vertrauen wuchs, setzten wir Qualitätskontrollpunkte mit messbaren Ausstiegskriterien. Ich denke, diese Kontrollpunkte ersparten uns wochenlange Nacharbeit. Vor allem aber halfen uns die Qualitätskontrollpunkte, unsere Implementierungen auf Basis des SAP-Standards zu verstehen und zu verfolgen.
2. Regression mit nachgelagerten Systemen
Wir alle wissen, dass Integrationen fehleranfällig waren. Daher erstellten wir einen Regressionstestplan, der POS, WMS, Finanzwesen, Personalwesen und Lieferantenportale umfasste. Die Überwachungskonzepte von SAP-Integrationsplattformen dienten als Grundlage für unsere Vorgehensweise bei Warnmeldungen und Wiederholungsversuchen. So testeten wir beispielsweise nach Abschluss einer Konfiguration für die Kreditorenbuchhaltung stets den gesamten Prozess, um sicherzustellen, dass keine Fehler auftraten.
Da einige Integrationen überarbeitet werden mussten, haben wir die Zuordnungen und die Fehlerbehandlung anhand von Mustern aus SAP CPI standardisiert . Das Ergebnis waren weniger nächtliche Anrufe und eine schnellere Fehlerbehebung.
Da die Leistung Mängel verschleiern kann, haben wir Durchsatz und Latenz mithilfe von Routinen aus dem SAP-Leistungstest validiert . Die Leute vertrauten den Zahlen mehr als den Versprechungen, was sich angemessen anfühlte.
3. Datenqualität und -bereinigung
Wir wissen, dass Datenkonvertierungen manchmal fehlschlagen lassen. Wir haben Geschäftsregeln festgelegt, die Duplikate, ungültige Masterdatensätze und fehlende Verweise kennzeichnen. Die Lehren aus den Fehlern bei der Datenmigration halfen uns, uns auf die eigentlichen Ursachen und nicht auf die Symptome zu konzentrieren.
Da die Verantwortlichen oft nicht in der IT-Abteilung angesiedelt sind, haben wir in jeder Funktion Datenverantwortliche mit klaren Service-Level-Agreements (SLAs) benannt. Die bewährten Planungsmethoden aus Projektplanung und -steuerung sorgten für einen reibungslosen Entscheidungsprozess, auch wenn Kompromisse schwierig erschienen.
Als die Umstellungsphase näher rückte, haben wir viele End-to-End-Tests durchgeführt und die Fehler täglich verfolgt. Diese einfache Routine funktionierte besser als jedes ausgefallene Dashboard, was mich immer noch überrascht. Es dauerte zwar einige Zeit, den Umstellungsplan zu erstellen, aber dank mehrerer Überprüfungsiterationen gelang es uns, alles richtig zu machen.
4. Übernahme von Geschäftsänderungen und Änderungsmanagement
Die Einführung sollte sich auszahlen. Wir haben einen praxisorientierten Veränderungsplan entwickelt, der auf bewährten Change-Management-Methoden basiert . Der Plan verknüpfte Schulungen mit konkreten Arbeitsaufgaben, nicht nur mit einzelnen Modulen. Ich ermutige Teams stets, sich auf den Prozess und nicht auf einzelne Aufgaben zu konzentrieren.
Da die Beteiligten unterschiedliche Ziele verfolgten, setzten wir Routinen aus unserer Stakeholder-Management-Strategie ein . Regelmäßige Foren reduzierten Spannungen und verringerten die Anzahl der Nebenabsprachen, die die Umsetzung normalerweise verzögern.
Als der Druck kurz vor der Inbetriebnahme zunahm, setzten wir rollenbasierte Arbeitsanweisungen und Begehungen im Verkaufsraum ein. Dieser Ansatz orientierte sich an Ideen aus Mitarbeiterschulungen . Ein Filialleiter sagte später, die zweiseitige Anleitung sei wichtiger gewesen als jede Betriebsversammlung.
Da KPIs die Teams zur Einhaltung der Vorgaben anhalten, haben wir Zykluszeiten, die Quote fehlerfreier Anfragen beim ersten Mal und die Themen im Helpdesk anhand der Richtlinien für ERP-Implementierungs-KPIs erfasst . Die frühzeitige Trendlinie gab der Führungsebene die Zuversicht, den eingeschlagenen Kurs beizubehalten.
Letztendlich waren diese SAP-Migrationsrisiken beherrschbar, da das Team diszipliniert blieb. Die Kombination aus benutzerdefiniertem Code, Datenbereinigungsaufwand und menschlichem Wandel war nicht einfach, doch dank stetiger Routinen konnte das Blatt zu unseren Gunsten gewendet werden.
Die wichtigsten Herausforderungen bei der Migration von SAP ECC zu S/4HANA
| Herausforderung | Details |
|---|---|
| 44 % der benutzerdefinierten Objekte werden verwaltet |
|
| Regression mit nachgelagerten Systemen |
|
| Datenqualität und -bereinigung |
|
| Geschäftsänderungen und -akzeptanz |
|
„Als ich mir unser ECC-System zum ersten Mal ansah, dachte ich, der benutzerdefinierte Code sei einfach die Standardfunktion. Was ich nicht sah, war, wie sehr es uns verlangsamte. Der Readiness-Check öffnete mir die Augen. Fast die Hälfte davon waren benutzerdefinierte Objekte, die kaum Mehrwert boten. Die Umstellung auf S/4HANA hat uns geholfen, das zu vermeiden. Der größte Gewinn war, dass unsere Teams wieder Zeit hatten, sich auf Wachstum zu konzentrieren, anstatt Probleme zu beheben.“ – CIO, Einzelhandelsunternehmen im Nahen Osten
Verwandte Artikel: ERP-Modernisierung und Strategieeinblicke
10 ERP-Modernisierungsfehler, die Sie in Ihrer ERP-Strategie vermeiden sollten
Ein detaillierter Blick auf häufige Fallstricke bei ERP-Modernisierungsprojekten und wie man sie vermeidet.
Oracle ERP vs. SAP: Was jeder CEO, CFO oder CIO bedenken muss
Wichtige Entscheidungspunkte für Führungskräfte, die Oracle ERP und SAP hinsichtlich Kosten, Umfang und langfristigem Wert bewerten.
Wählen Sie das richtige ERP für kleine Unternehmen im Jahr 2025
Leitfaden für kleine Unternehmen bei der Auswahl von ERP-Lösungen, die auf Agilität, Kosten und Wachstum im Jahr 2025 zugeschnitten sind.
ERP-Systemauswahl für einen mittelständischen Hersteller in Asien
Eine Fallstudie zu den Herausforderungen bei der ERP-Bewertung und -Auswahl, mit denen ein Fertigungsunternehmen in Asien konfrontiert war.
Der Ausführungsprozess bei der Migration von SAP ECC zu S/4HANA
Sie verstehen sicher, dass diese Fallstudie zur S/4HANA-Migration zeigt, dass die Umsetzung sorgfältig geplant werden musste. In unserem Fall erfüllte jede Phase unseres Projekts einen Zweck, und Abstriche hätten später zu Problemen geführt.
Natürlich sind wir dem SAP Activate-Ansatz gefolgt, aber ich möchte auf die wichtigsten Dinge eingehen, die wir getan haben:
1. Phasenweise Ausführung basierend auf SAP Activate
- Unsere Konfiguration und Tests durchliefen Sandbox, Entwicklung, Qualitätssicherung, Generalprobe/Vorproduktion und Go-Live.
Wir haben den Pfad zunächst in der Sandbox validiert und den Umfang mit SAP Activate-Vorlagen festgelegt . Dadurch erhielt das Team eine Ausgangsbasis, ohne zu viel Design zu verwenden.
In der Entwicklungsumgebung haben wir die Transportprozesse gehärtet und Qualitätsprüfungen pro Arbeitsablauf implementiert. Die Kriterien wurden bewusst einfach gehalten, da sonst die Mitarbeiter im Prozess den Überblick verloren hätten.
Die Qualitätssicherungszyklen liefen parallel zum realen Geschäftsvolumen. Aufträge wurden optimiert, bevor Engpässe sichtbar wurden. Eine sorgfältige Projektplanung und -steuerung trugen dazu bei, realistische Termine einzuhalten.
Die Vorproduktion wurde eher zu einer Probe der Umstellung als zu einer Theorie. Das Go-Live-Playbook wurde auf jedes Geschäft und Lager abgestimmt.
2. Paralleles Testen mit Geschäftseinheiten
Die Leiter der Finanz- und Lieferkettenabteilungen wurden anhand tatsächlicher Periodenabschlüsse und Werbeaktionen getestet, wodurch die Skripte die Geschäftsrealität widerspiegeln mussten. Ich erinnere mich noch gut daran, wie aufwendig die Überprüfung unserer Testskripte war.
Fehler wurden nach ihrer geschäftlichen Priorität und nicht nur nach ihrer technischen Schwere erfasst. Dieser Ansatz basierte auf gesundem Menschenverstand, spiegelte aber die KPI-orientierten ERP-Praktiken wider.
Nachtläufe deckten Probleme mit der Zeitplanung auf. Ich erinnere mich an einen Lagerleiter, der lächelte, als der zweite Schnitt nach wochenlanger Frustration reibungslos lief. Ein riesiger Seufzer der Erleichterung!
3. Cutover-Proben zur Minimierung von Ausfallzeiten
Jede Aufgabe wurde zeitlich festgelegt, gekürzt oder zusammengeführt. Allein der Probelauf sparte Stunden, die eine Kalkulationstabelle nie aufdecken würde.
Fallback-Checkpoints für Datenladevorgänge wurden kurz gehalten und Wiederherstellungspläne als einseitige Handouts bereitgestellt. Die Leute sagten, dass diese einfache Liste den Stress stärker reduzierte als jedes Dashboard.
Ein Pilotprojekt in einer Filiale bewies die Stabilität des Kassensystems und des Warenwirtschaftssystems. Die dabei gewonnenen Erkenntnisse prägten den breiter angelegten Rollout-Ansatz.
4. Hypercare nach der Inbetriebnahme
Der War Room blieb zwischen IT und Fachabteilungen vernetzt und verfügte über klare Verantwortlichkeiten. Probleme wurden in Sprints gelöst, was den Verantwortlichen sichtlich Zuversicht gab.
Rollenbasierte Anleitungen und Schritt-für-Schritt-Anleitungen reduzierten die Supportanfragen. Dies knüpfte an die zuvor vom Projektteam entwickelten Schulungsstrategien an.
Die Kostenverfolgung wurde transparent veröffentlicht. Die Ablaufdiagramme der Einsätze wurden mit Aktualisierungen der Einsparungen verknüpft, was einer bewährten Praxis im Budgetmanagement entspricht.
Kurz gesagt, bei der Umsetzung ging es weniger um Tools als vielmehr um das Tempo. Jeder Schritt in den Projektphasen, von der Sandbox bis zum Hypercare-Support, prägte die Akzeptanz auf eine Weise, die kein Foliensatz hätte vorhersagen können.
Ergebnisse und Vorteile dieser Implementierung
Ich muss sagen – Zahlen waren hilfreich, aber die kleinen Veränderungen in der Arbeitsweise waren noch wirkungsvoller. Und das haben wir erreicht:
1. Reduzierter kundenspezifischer Platzbedarf und niedrigere Gesamtbetriebskosten
Fast die Hälfte des benutzerdefinierten Codes wurde entfernt, wodurch das System leichter wurde.
Die Kosten für die Aufrechterhaltung der Stromversorgung sanken und es wurde Geld für Upgrades und Schulungen frei.
Dieser Schritt steht im Einklang mit den Ideen der SAP Clean Core Strategie , nach der weniger kundenspezifische Objekte auch ein geringeres Risiko in der Zukunft bedeuten.
2. Schnellere Berichterstattung, Echtzeitanalysen und Self-Service
Finanzteams sagten, dass der Monatsabschluss 5 Werktage dauern könnte, anstatt sich über ein paar Wochen hinzuziehen.
Durch Echtzeitberichte hatten Einzelhandelsmanager die Möglichkeit, Werbeaktionen noch am selben Tag und nicht erst Tage später anzupassen.
Diese Erfahrung hat mich daran erinnert, wie SAP Analytics Cloud das Reporting in den Mittelpunkt der Entscheidungsfindung stellt und nicht als etwas betrachtet, das man erst im Nachhinein untersucht.
3. Verbessertes Benutzererlebnis mit Fiori-Apps
Filialleiter begannen, Fiori-Apps anstelle der alten SAP ECC-Bildschirme zu verwenden, die sie verlangsamten.
Der Schulungsaufwand verringerte sich, da die Apps auf eine Weise funktionierten, die die Leute bereits kannten. Ein Manager bezeichnete es sogar als „erfrischend“.
Das Ergebnis deckt sich mit dem, was ich bei SAP-Schulungsstrategien beobachtet habe , wo Komfort eher zur Akzeptanz führt als jegliche Verpflichtung.
4. Verbesserte Systemintegration und Leistung
Die Verbindungen zwischen POS, WMS und Finanzwesen wurden stabiler und es traten weniger Folgeprobleme auf.
Stapelverarbeitungsaufträge wurden über Nacht schneller abgeschlossen, was bedeutete, dass die Berichte der Lagerteams schon beim Morgenkaffee bereitlagen.
Sorgfältige Planung machte den Unterschied, ganz ähnlich wie die Erkenntnisse beim SAP-Performance-Testing.
Einige Teams hielten noch an alten Berichten fest, obwohl bessere bereits verfügbar waren. Die Veränderungen waren nicht überall gleichmäßig. Insgesamt verschaffte die Migration dem Einzelhändler jedoch ein einfacheres Grundgerüst und ein Maß an Effizienz, das ECC nicht mehr bieten konnte.
Lehren aus diesem Kundenengagement
Wenn ich auf dieses S/4HANA-Migrationsprojekt zurückblicke, sind mir einige Erkenntnisse besonders in Erinnerung geblieben. Sie beruhten auf realen Situationen und manchmal auf Fehlern, die uns Zeit und schlaflose Nächte kosteten.
1. Frühzeitige Abstimmung der Stakeholder
Das Projekt verlief reibungsloser, nachdem die Geschäftsführung und die IT-Leiter von Anfang an offen miteinander sprachen. In Workshops konnten die Teams Bedenken äußern, die sonst verborgen geblieben wären.
Mir ist eine Sitzung im Gedächtnis geblieben, in der Filialleiter erklärten, dass ihre Berichtsanforderungen sich von denen der Finanzabteilung unterschieden, was alle zur Anpassung zwang. Ohne diese frühzeitige Abstimmung wäre der Konflikt kurz vor der Umstellung aufgetreten.
In den Werkstätten wurden Probleme frühzeitig aufgedeckt
Weniger Reibungen zwischen den Teams in letzter Minute
2. Benutzerdefinierte Codeoptimierung
Wir haben die Code-Überprüfung zu spät angesetzt, was das Projekt verlangsamt hat. Mehrere benutzerdefinierte Objekte mussten schnell neu geschrieben werden, was zu großem Druck führte. Hätten wir, wie in der SAP Clean Core Strategie betont, früher den Clean-Core-Ansatz verfolgt , wäre diese Hektik vermieden worden.
Späte Überprüfungen führten zu Nacharbeiten
Saubere Kernführung kam zu spät
3. Datenqualität sollte Ihre oberste Priorität sein
Unsere Testphase zog sich nur deshalb so lange hin, weil unsere Stammdaten unübersichtlich waren. Doppelte Lieferantendatensätze und veraltete Einträge kosteten uns wertvolle Stunden. Kein System kann funktionieren, wenn die zugrundeliegenden Daten fehlerhaft sind. Dies erinnerte alle daran, warum so viele SAP-Datenmigrationsprojekte scheitern.
Mangelhafte Stammdaten verlangsamten das Testen
Die Reinigung hätte viel früher abgeschlossen sein sollen
4. Mehrere Proben minimieren Risiken
Die Proben waren manchmal ermüdend, brachten aber echte Probleme ans Licht. Ein Probelauf offenbarte Sequenzierungskonflikte zwischen POS und WMS, die niemand vorhergesehen hatte.
Jede Übungsrunde beruhigte die Teams, insbesondere diejenigen, die für den Nachtbetrieb zuständig waren. Die Vorgehensweise spiegelte Erkenntnisse aus der Projektplanung und -steuerung wider.
Bei den Proben kamen Probleme ans Licht, mit denen wir nicht gerechnet hatten.
Sie haben auch vor dem Go-Live Vertrauen aufgebaut
Nicht alles lief reibungslos. Manche fanden die Workshops zu lang, andere die Proben repetitiv. Doch im Nachhinein betrachtet waren diese Schritte ein Sicherheitsnetz. Ohne sie wäre die Migration nicht so stabil gewesen.
Erkenntnisse aus der Migration von SAP ECC zu S/4HANA
| Lektion | Wichtige Erkenntnisse |
|---|---|
| Frühzeitige Abstimmung der Stakeholder |
|
| Benutzerdefinierte Codeoptimierung |
|
| Datenqualität als Priorität |
|
| Mehrere Proben |
|
| Gesamtreflexion |
|
Testen Sie Ihr SAP-Migrationswissen
Wie gut verstehen Sie Migrationen von ECC zu S/4HANA?
Fazit
Dies war ein langer Artikel. Wenn Sie es bis hierher geschafft haben, werden Sie feststellen, dass diese Fallstudie zur Migration von SAP ECC zu S/4HANA zeigt, wie das Einzelhandelsunternehmen nicht nur seine Systeme modernisierte, sondern auch eine Grundlage für langfristige Agilität schuf.
Die zehn Jahre alte SAP ECC-Umgebung war fragil geworden. Durch die Umstellung auf S/4HANA konnte das Unternehmen seine Prozesse vereinfachen, unnötigen benutzerdefinierten Code entfernen und die Integration in Drittsysteme stabilisieren.
Durch den Umzug wurde außerdem sichergestellt, dass die IT-Landschaft mit dem zukünftigen Wachstum Schritt halten kann, was im schnelllebigen Einzelhandelssektor von entscheidender Bedeutung ist.
Durch die Umstellung konnte sich der Kunde in einem hart umkämpften Marktumfeld sicherer positionieren. Dank Echtzeitanalysen konnten die Finanzteams ihre Bücher schneller abschließen als je zuvor, und die Filialleiter reagierten auf Basis von Echtzeit-Bestandsdaten, anstatt tagelang zu warten.
Die Partnerintegrationen wurden durch die Anwendung der in den SAP-Integrationsplattformen beschriebenen Methoden stabiler . Die Verbesserungen waren nicht perfekt, da einige Benutzer weiterhin nach alten Berichten fragten, aber die umfassende Transformation des Einzelhandels machte den Wechsel lohnenswert.
Zu den wichtigsten Punkten, die den Teams im Gedächtnis blieben, zählen:
Der reduzierte benutzerdefinierte Platzbedarf senkte die Gesamtbetriebskosten und gab Budget für Upgrades und Schulungen frei.
Finanz- und Einzelhandelsgeschäfte erhielten Echtzeitberichte, wodurch Verzögerungen reduziert wurden.
Fiori-Apps verbesserten die Benutzerakzeptanz und verkürzten die Schulungszeit.
Durch mehrere Proben und eine enge Abstimmung mit den Geschäfts- und IT-Teams wurden die Umstellungsrisiken minimiert.
Am Ende zeigte sich, dass sich der Aufwand definitiv gelohnt hatte. Das Unternehmen verfügte endlich über ein System, das einfacher zu bedienen war, und die IT verbrachte nicht mehr die meiste Zeit damit, Probleme von gestern zu beheben.
Die Kunden meinten, es sei weniger eine Belastung, sondern vielmehr etwas, mit dem sie tatsächlich wachsen könnten. Der Einzelhändler erhielt eine Plattform, die Veränderungen bewältigen konnte, ohne alle Beteiligten auszubremsen.
Wenn Sie Fragen haben oder eine Situation bei Ihrer ERP-Implementierung besprechen möchten, zögern Sie bitte nicht, sich an uns zu wenden!
Fragen, die Sie möglicherweise haben ...
1. Warum wechseln Unternehmen von SAP ECC zu S/4HANA?
Wenn Sie noch ECC nutzen, wissen Sie bereits, dass der Support bald ausläuft. Ich habe Unternehmen erlebt, die mehr für den Erhalt von ECC ausgeben als für dessen Weiterentwicklung. In einer Fallstudie zur Migration von SAP ECC zu S/4HANA wurde selbst ein kleines Update als riskant empfunden. Durch die Migration reduzieren Sie technische Schulden, vereinfachen das System und erhalten endlich Echtzeit-Reporting, das Ihnen ECC nie ermöglichte.
2. Was sagt Ihnen ein Readiness-Check eigentlich?
Wenn ich eine Bereitschaftsprüfung durchführe, bestätigt sich meist der Verdacht. Das System ist überlastet. Es weist auf benutzerdefinierten Code, veraltete Prozesse und notwendige Änderungen hin. Ich habe einmal erlebt, wie ein Finanzteam feststellte, dass die Hälfte seiner benutzerdefinierten Berichte bereits in S/4HANA vorhanden war. Sie werden wahrscheinlich dasselbe feststellen.
3. Ist benutzerdefinierter Code wirklich ein so großes Problem?
Ja, und ich möchte Ihnen sagen, wie groß. In einem Projekt waren 44 % der Objekte benutzerdefiniert. Fast die Hälfte. Viele davon waren jahrelang nicht mehr angefasst worden. Die eigentliche Arbeit besteht darin, gemeinsam mit Ihren Geschäftsanwendern zu entscheiden, welche bleiben und welche endgültig verschwinden können.
4. Was passiert, wenn Sie die Datenbereinigung überspringen?
Sie werden es bereuen. Ich habe schon erlebt, dass sich Tests aufgrund unzureichender Daten über Monate hinzogen. In einem Fall verursachten doppelte Lieferantendatensätze so viele Verzögerungen, dass die Umstellungsproben beinahe scheiterten. Wenn Sie frühzeitig beginnen, vermeiden Sie diesen Ärger. Weisen Sie Eigentümer zu und bereinigen Sie die Datensätze, bevor Sie mit dem Testen beginnen.
5. Sollten Sie sich für Greenfield oder Brownfield entscheiden?
Sie müssen entscheiden, wie viel Veränderung Sie bereit sind. Greenfield ist ein kompletter Neuaufbau, aber kostspielig und störend. Brownfield schützt Ihre alten Investitionen, kann aber auch Altlasten mit sich bringen. Ich empfehle Brownfield oft mit selektiver Neugestaltung. Das sorgt für Ausgewogenheit.
6. Warum werden weiterhin Proben durchgeführt?
Ich weiß, Proben sind anstrengend, aber sie retten einen später. In einem Durchgang haben wir Konflikte zwischen POS und WMS erkannt, die niemand vorhergesehen hatte. Jede Runde stärkt das Vertrauen. Wenn man sie überspringt, wird sich der Go-Live wie ein Glücksspiel anfühlen.
7. Inwiefern erschweren Integrationen die Dinge?
Wenn Ihr ECC mit POS-, WMS-, Finanz-, HR- und Lieferantenportalen verbunden ist, wissen Sie bereits, wie anfällig es ist. Ich habe erlebt, wie eine kleine Änderung im Finanzwesen den Einzelhandel zum Erliegen brachte. Während der Migration ersetzten wir Punkt-zu-Punkt-Verbindungen durch APIs. Dieser Schritt reduzierte Fehler und half den Teams, Probleme schneller zu lösen.
8. Warum ist die Abstimmung der Stakeholder so wichtig?
Denn ohne sie entstehen Konflikte erst spät und kosten mehr. Ich erinnere mich an einen Workshop, bei dem Filialleiter sagten, ihre Berichtsanforderungen unterschieden sich stark von denen der Finanzabteilung. Das wurde früh deutlich, und wir haben uns angepasst. Hätten wir gewartet, wäre es bei der Umstellung eskaliert.
9. Welche Vorteile sehen Sie nach der Migration?
Sie werden als Erstes eine schnellere Berichterstellung bemerken. Die Finanzteams, mit denen ich zusammengearbeitet habe, schlossen ihre Bücher bereits zur Mittagszeit, anstatt am Wochenende zu arbeiten. Filialleiter nutzten Echtzeit-Dashboards, um noch am selben Tag über Werbeaktionen zu entscheiden. Die IT-Teams mussten nicht mehr ständig Fehler machen, weil benutzerdefinierter Code reduziert wurde.
10. Welche Lehren sollten Sie mitnehmen?
Meiner Erfahrung nach sind vier Dinge am wichtigsten: Binden Sie Ihre Stakeholder frühzeitig ein. Beginnen Sie früher mit der Bereinigung von benutzerdefiniertem Code. Vernachlässigen Sie die Datenqualität nicht. Führen Sie vor dem Go-Live genügend Proben durch, um sich sicher zu fühlen. So vermeiden Sie die schlimmsten Überraschungen.
Verwandte Artikel: Finanz- und SAP-Implementierungspraktiken
Modernisierung der Finanzprozesse für einen familiengeführten Mischkonzern
Wie ein großes Familienunternehmen seine Finanzgeschäfte durch ERP-gesteuerte Modernisierung umstrukturierte.
SAP-Leistungstests: Was IT-Leiter im Jahr 2025 wissen müssen
Wichtige Schritte, die IT-Leiter für Leistungstests in SAP-Umgebungen benötigen, um die Systemstabilität sicherzustellen.
Oracle ERP vs. SAP
Ein Vergleich von Oracle ERP und SAP mit praktischen Überlegungen für Führungskräfte, die eine Plattformauswahl treffen.
Lieferverzögerungen bei der SAP Integration Suite
Lehren aus Integrationsherausforderungen, die die Einführung der SAP Suite verlangsamten, und wie Teams diese bewältigten.
