Whiteboard-Session: Key Learnings aus der EWM-Migration nach S/4HANA

Bewerten
15 Bewertungen,
Durchschnitt 2,1

Michael Adam und sein Team haben bereits mehrere EWM-Migrationen auf S/4HANA durchgeführt. In diesem Video beantwortet er die wichtigsten Fragen rund um solche Projekte.

Video-Transkription


Hallo und herzlich willkommen zur Whiteboard-Session S/4HANA und EWM-Migration! Ich möchte heute auf ein paar Fragen zur S/4-Migration eingehen, zum Beispiel:

  • Warum migrieren wir?
  • Was muss ich migrieren?
  • Was muss ich eigentlich aus dem ERP übertragen?
  • Und wie gehe ich dabei vor?

Warum migriere ich mein SAP EWM auf S/4HANA?

Mein Name ist Michael Adam, ich habe letztes Jahr zwei S/4-Migrationen mit meinem Team durchgeführt. Und ich starte direkt mit dem "Warum migriere ich?“ Diese Frage ist relativ leicht zu beantworten: Die SCM-Plattform wird von der SAP abgekündigt. Das heißt, dass grundsätzlich jeder sich irgendwann mit seinem EWM Richtung S/4HANA bewegen bewegen muss. Man könnte jetzt natürlich sagen: da hat man noch Zeit.

Deswegen gibt es noch weitere Treiber dafür. Das sind vor in der nahen Zukunft anstehende Logistikprojekte, zum Beispiel ein Lagerneubau, oder eine Produktionsversorgungsintegration, oder ähnliches. Also alles, was ein größeres Projekt ist, bei dem man sich die Frage stellen kann: Mache ich das vielleicht gleich auf meiner neuen S/4-Plattform? Oder führe ich das Projekt noch auf der alten Plattform durch?

Wenn ich das neue Projekt noch auf der alten Plattform durchführe, habe ich den Nachteil, dass ich beide migrieren muss. Wenn ich die Migration allerdings vorher mache, dann habe ich natürlich ein kleineres Migrationsprojekt, das natürlich dadurch auch etwas beherrschbarer wird und leichter umzusetzen, und ich kann für mein neues Projekt direkt auf neue Features von S/4 zugreifen, zum Beispiel die Fiori-Oberflächen oder, im Fall vom EWM, die Warehouse-Analytics.

Was muss ich bei der EWM-Migration eigentlich migrieren?

Wenn ich mich dann dazu entschlossen habe zu migrieren, dann ist die erste Frage: Was muss ich eigentlich migrieren? Das sind auf jeden Fall Entwicklung und Customizing, plus die Bestände. Zu den Beständen komme ich etwas später, das ist eigentlich so das Kernstück.

Entwicklung und Customizing ist „relativ einfach“: Die Entwicklungsobjekte und die Customizingobjekte packe ich in einen Transportauftrag und bringe das aufs neue System. Wie hier aufgezeichnet ist, sieht man schon: das sind zwei verschiedene Systemschienen. Ich habe hier einmal die alte Landschaft und ich habe hier unten einmal die neue Landschaft.

Das liegt daran, dass ich für die S/4-EWM-Migration immer einen Greenfield-Ansatz machen muss. Es gibt nicht die Möglichkeit, das System upzudaten. Die SCM-Plattform ist leider zu inkompatibel zur neuen S/4-Plattform. An der Stelle wird also parallel ein System aufgebaut und ich muss tatsächlich Softwareobjekte in das neue S/4 bringen. Customizing genauso. Wenn ich das dann auf dem neuen System habe, dann kann ich meine Softwareobjekte auch entsprechend S/4HANA-ready machen. Da kann ich sie auch gleich testen. Ich kann auch berücksichtigen, was aus der Simplyfication DB der SAP, also sprich, das neue Datenmodell das hier zugrunde liegt, rauskommt und kann meine Software-Objekte dort auch letztendlich anpassen. Das kommt häufiger vor, wenn man einen größeren MFS-Anteil hat, viel Automation im Lager, dann sind hier durchaus die ein oder anderen Tätigkeiten dabei, die man vornehmen muss.

Was muss ich aus dem ERP verteilen?

So viel zum "Was muss ich eigentlich migrieren?", ausgenommen noch die Bestände. Dann zur Frage "Was muss ich aus dem ERP verteilen?" Früher gab es die CIF-Schnittstelle oder, jetzt, eigentlich gibt es die CIF-Schnittstelle und IDOCs, für Lieferungen beispielsweise, CIF für Materialstamm und so weiter. Stammdaten werden zukünftig über das Data Replication Framework übertragen. Da habe ich mehrere Möglichkeiten. Die wesentlichen sind Web Services zum einen, oder eben IDOCs. In unserem Fall haben wir IDOCs verwendet. Das ist erst mal auch so empfohlen für die EWM-Systeme und hat sich im Grunde auch soweit bewährt. Die muss man wiederum einrichten auf ERP-Seite und auf EWM-Seite. Aufgrund des neuen Datenmodells kann sich da auch ergeben, dass kundeneigene Felder, also Z-Felder, an Material zum Beispiel, dass dann auch wieder Coding-Änderungen entstehen. Muss man eben auf beiden Seiten entsprechend berücksichtigen. Diese Stammdaten werden aus dem ERP über IDOCs übertragen. Da ändern sich logischerweise ein paar Dinge dadurch. Da gibt es Änderungszeiger und ähnliches, um Material zu übertragen. Das ist anders als beim CIF – muss man an der ein oder anderen Stelle berücksichtigen – aber eine sehr stabile Form der Datenübertragung. Genau, dann ist die Frage: Ok, Entwicklung, Customizing schaffe ich rüber. Die Stammdaten bekomme ich ins S/4S-System. Das alles ist etwas, was man glücklicherweise auch vorbereitend machen kann.

Wie gehe ich dabei vor?

Wenn es jetzt um die Bestände geht, dann habe ich da nur zu einem gewissen Go-live-Zeitpunkt Zeit. In der Logistik habe ich in der Regel die Herausforderung, dass ich das System nicht ewig abschalten kann. Go-live war nun in unserem Fall so, dass wir zwei, drei Tage hatten, beziehungsweise in einem extremeren Fall, maximal 24 Stunden Zeit, um das Ganze durchzuführen. Der knappe Zeithorizont führt schon dazu, dass man für den Go-live im Endeffekt schauen muss, welche Daten man mitnimmt. Im Grunde ist so wenig wie möglich am besten. Das heißt, Bestände ja, Bewegungsdaten nein. Vor allem historische Bewegungsdaten nicht.

Beim Go-live ist es eben ganz kritisch, dass das auch funktioniert. Wenn ich die Bestände nicht korrekt übertragen kann, habe ich ganz schön Schiefstände. Und mit Bestandschiefständen in einem so knappen Zeitfenster hätte ich schon ein relativ großes Problem. Das würde bedeuten, dass ich womöglich in den Lieferverzug reinlaufe oder dass ich die Produktion nicht versorgen kann, was auch immer das EWM an der Stelle tut, und es kostet letztendlich einfach Geld.

Das heißt, dass das ganze Thema sehr gut geplant werden muss. Da braucht es ein Konzept dazu: Was tue ich wann? Das braucht einen sehr detaillierten Cut-over-Plan und das muss davor auch geübt werden. Es muss vorher alles sehr gut durchgetestet werden. Der Go-live ist meistens knapp abgesteckt und es muss alles in einer gewissen Zeit durchlaufen.

Die gute Nachricht an der Stelle ist: Wir haben die Erfahrung gemacht, dass das Systemverhalten, das sich aus Tests zeigt und das sich vor allem auch nach Fehlerkorrekturen zeigt, sich beim Go-live genauso widerspiegelt. Wir hatten an sich immer recht gute Go-lives. Die sind recht zügig durchgelaufen und so in ihrem Zeitplan geblieben und wir hatten vor allem sehr ruhige Hypercare-Phasen danach, die alle vorzeitig beendet wurden, weil das System dann auf der neuen Plattform auch wirklich funktioniert hat und läuft.

Ja, das war im Wesentlichen ein kurzer Überblick über das Thema S/4-Migration für EWM. Ich hoffe, Sie konnten da was Interessantes für sich herauspicken und sage: „Tschüss!“

Projekt thyssenkrupp Marine Systems - Schiffbau: Automatisierte Lagersteuerung mit SAP EWM

20 Jahre leistete das Lagerführungssystem von thyssenkrupp Marine Systems am Standort Kiel hervorragende Dienste. Jetzt galt es, den Technologiestandard für die kommenden 20 Jahre auszurichten. Mit SAP EWM brachte SALT Solutions das Lager wieder auf Kurs. Mehr dazu erfahren Sie im Projektbericht!

Keine Updates
mehr verpassen:
1

Zurück