Erfahren Sie, wie Sie den Wechsel einfach meistern
Sie haben sich entschieden, von Ihrem SAP TM 9.5-System auf SAP S/4HANA Transportation Management zu migrieren? Doch wie geht es nun weiter? Was muss überhaupt alles migriert werden? Welche Tools und S/4HANA Utilities gibt es und was decken diese ab? Und welche S/4HANA Best Practices gibt es?
Zuerst stellt sich die Frage, wie das neue System aufgebaut sein soll: Welche SAP S/4HANA Architektur erscheint sinnvoll für Ihr Unternehmen? Soll es wieder wie in der Vergangenheit ein Side-by-Side Setup sein, wo ein SAP S/4HANA Transportation Management System neben anderen SAP-Systemen betrieben wurde (Variante 3 in der Abbildung)? Oder soll es lieber ein eingebettetes System werden? Reichen die grundlegenden Funktionen in der Lizenzform S/4HANA TM Basic Shipping oder soll es doch das S/4HANA TM Advanced, welches die Funktionstiefe des SAP TM 9.5 hat, werden? Gesichtspunkte hierbei sind neben den wegfallenden Schnittstellen, hinzukommenden Funktionalitäten, der Systemlast und dem Systeminhaber im Fall von Tochterorganisation auch Release- und Wartungszyklen.
Darüber hinaus stellt sich die Frage, wie das System gehostet werden soll. Drei Varianten stehen zur Verfügung:
- On-Premise
- Private Cloud
- Public Cloud (das SAP-Produkt unterscheidet sich hier in Einzelheiten)
Wir empfehlen einen selektiven Umstieg nach S/4HANA
In den meisten Fällen ist bei der Conversion oder Datenmigration von klassischen SAP-Systemen auf neue SAP S/4HANA-Systeme von Digital-Core- und dem Greenfield oder Brownfield Ansatz die Rede. Falls Sie Ihre Transporte im SAP ERP mit der Komponente LE-TRA verwalten, ist eine Migration von Daten in das SAP S/4HANA Transportation Management leider nicht möglich. Hier muss ein green field approach gewählt werden. Dieser bietet jedoch die Chance, bestehende Geschäftsprozesse neu zu überdenken und eine optimierte Transportmanagementlösung zu implementieren. Näheres zu dem Thema finden Sie in unserem Beitrag zum Thema LE-TRA vs. SAP S/4HANA TM Basic Shipping.
Im Fall einer Migration von SAP TM 9.5 auf ein S/4HANA TM bietet sich aber zudem die Möglichkeit einer selektiven Migrationsstrategie, oft blue field oder s.m.a.r.t approach genannt an.
Unter diesem Ansatz versteht man, dass ein Teil der Daten aus dem bisherigen System migriert wird. Hier stehen nun neben Stammdaten auch Bewegungsdaten, Customizing und Entwicklungen zur Auswahl. Je nach Migrationsart kann es Sinn ergeben, die Daten nur anteilig zu überführen. Dank der kontinuierlichen Weiterentwicklung durch die SAP oder zwischenzeitliche Umstellungen in Ihrem Betrieb besteht die Möglichkeit, Prozesse standardnäher und/oder besser mit dem S/4HANA Transportation Management abzubilden, als es mit SAP TM 9.5 noch möglich war.
Falls Sie unsere Software leogistics d.s.c auf Ihrer SAP TM-Systeminstanz nutzen, finden Sie hier mehr Informationen: Ihr Wegweiser für eine erfolgreiche Umsetzung eines Upgrades
Diese vier Bereiche sollten Sie bei Ihrem Migrationsprojekt beachten
Nun gibt es verschiedenste Bereiche, die migriert werden können. Diese unterteilen sich in Stammdaten, Customizing, Entwicklungen und Bewegungsdaten, welche wir nachfolgend einzeln durchgehen und für die wir Migrationswege aufzeigen.
Customizing
Zunächst ist das Customizing der einzelnen Komponenten zwingend notwendig, damit die bisherigen systemischen Prozessabläufe weiterhin beibehalten werden. Hier ist natürlich zu beachten, dass es einige Funktionalitätsanpassungen gab.
- Keine Schnittstelle mehr zum Transport (Shipment) im ERP (LE-TRA)
- Das SAP TM Collaboration Portal wurde durch SAP Logistics Business Network ersetzt, die Nutzung des Collaboration Portals ist in gewissen Fällen aber weiterhin möglich
- Keine Integration mehr zum SAP CRM und SAP EAM
Für den Transfer des Customizings kann das SAP TM Migration Cockpit verwendet werden. Über eine SAP Note können Sie das Migration Cockpit (Transaktion /SCMTMS/2S4H) implementieren. Alle Migrationsobjekte für Customizing beginnen mit einem „CUST_“ als Präfix.
Während das Migrationsobjekt CUST_SCMB SCM Basis Settings wie bspw. Geocoding Level, Produktfrachtgruppen, Process-Controller-Einstellungen, das Package-Building-Profile oder PPF-Konfigurationen beinhaltet, enthält CUST_BF die Event-Gründe, Handling Codes, Textarten und Anhangsarten. CUST_PLN hingegen umfasst die Kontingentarten, Seitenlayouts für das Transportation Cockpit oder Frachtauftragsarten.
Es ist also möglich, zahlreiche Customizing-Einstellungen mit diesem Tool zu migrieren. Sobald hier Möglichkeiten fehlen, kann das SAP TM Migration Tool erweitert werden.
Stammdaten
Für Stammdaten, die bei einem Side-by-Side-Setup aus einem SAP ERP oder S/4HANA-System kommen, empfehlen wir, diese auch weiterhin zentral zu verteilen. Statt dem Core Interface Framework (CIF) stehen hierfür das Data Replication Framework (DRF) und die Transaktion BD10 zur Verfügung. Näheres dazu hier.
Aufwendiger wird es bei den Stammdaten, die im SAP TM angelegt wurden. Hier empfiehlt es sich, eine Checkliste zu machen, welche Daten relevant sind und welche davon manuell oder automatisch migriert werden sollten. So kann es beispielsweise bei wenigen Bedingungen leichter sein, die integrierte Up- und Downloadfunktion zu verwenden, als eine automatische Migration durchzuführen. Anbei hierfür unsere Checkliste für Stammdaten-Migration, die Sie gerne eigenständig ergänzen können:
- Fahrzeug-Ressourcen
- Handling-Ressourcen
- Kalenderressourcen
- Fahrer
- Frachteinheitsbildungsregeln
- Bedingungen
- Planungsprofile
- Selektionsprofile
- Kapazitätsprofile
- Inkompatibilitäten
- Speditionsvereinbarungen
- Interne Vereinbarungen
- Frachtvereinbarungen
- Tarifpreistabellen
Bei Geschäftspartnern, Lokationen und Produkten handelt es sich normalerweise um Stammdaten, die repliziert werden. Jedoch gibt es auch hier Datensätze, die migriert werden müssen, wie beispielsweise Umladelokationen, Dummy-Geschäftspartner oder Dummy-Produkte. Diese müssen im SAP S/4HANA TM angelegt werden. Für die Migration hat die SAP ab der SAP TM Version 9.5 das SAP TM Migration Cockpit bereitgestellt.
Die Migrationsobjekte für Stammdaten beginnen mit dem Präfix „MD_“ oder „US_“, einzige Ausnahme sind die Organisationseinheiten, diese befinden sich im Migrationsobjekt ORG_HIERARCHY.
Zu beachten ist außerdem, dass mit SAP S/4HANA TM die bedingungsbasierte Berechnung von Be- und Entladezeiten ebenso wie das bedingungsbasierte Filtern in Selektionsprofilen nicht mehr unterstützt wird und somit auf anderen Wegen abgebildet werden müssen.
Entwicklungen
Bei den Entwicklungen stellt sich die Frage, ob man hier an einigen Stellen nicht auch den technologischen Wechsel mitvollziehen sollte. Während häufig noch klassische ABAP Reports in Kundensystemen entwickelt wurden, setzte das SAP TM maßgeblich auf Webdynpros. Statt der Webdynpros verwendet das S/4HANA Transportation Management nun auch Fiori-Anwendungen. Das S/4HANA Embedded Analytics ist hierfür ein Beispiel und eine gute Möglichkeit, operative Reporting-Lösungen zu substituieren.
Die Hauptaufgabe besteht somit darin, zunächst, die zu transferierenden Entwicklungsobjekte zu ermitteln. Neben dem Modifikationsbrowser (SE95) und der Simulation Kundenerweiterung (SE94) eignen sich auch der Code-Scanner oder der ABAP Call-Monitor, um diese zu identifizieren.
Neben diesen bietet unsere Muttergesellschaft cbs corporate business solutions eine Lösung zur Identifikation und Bündelung der Eigenentwicklungen, welche die Arbeit erheblich erleichtern.
An einigen Stellen wird eine Code-Migration problemlos möglich sein, vor allem in Strategien und BAdIs. Beim Großteil wird jedoch der Entwickler manuelle Änderungen nach der Migration vornehmen müssen.
Bewegungsdaten
Bewegungsdaten stellen die am schwersten zu migrierenden Objekte dar. Wir empfehlen im Normalfall, dass Bewegungsdaten nicht migriert werden sollten. So wird ein „Abschluss“ des Altsystems garantiert. Falls statt einer Archivierung eine Migration jedoch der bevorzugte Weg sein soll, könnte der cbs Enterprise Transformer eine Möglichkeit der Übertragung der Daten sein.
Nun gibt es jedoch auch Situationen, in denen es nicht möglich ist, ein System auf einen Schlag vollständig durch ein neues abzulösen. Ein Grund hierfür kann in der Projektorganisation liegen: Ein SAP TM System, welches an 20 Standorten produktiv gesetzt ist, die sich auch Umlagerungen zusenden, kann gegebenenfalls nur schwer an allen 20 Standorten von einem Tag auf den anderen auf ein anderes System umgestellt und supported werden. Eine andere Herausforderung stellt sich bei extrem hoher Automatisierung. In diesem Fall darf das System nicht eine Minute ausfallen. Hier sind wir in einer Situation, wo Belege zwischen den Systemen nicht wirklich migriert, sondern zur Laufzeit gespiegelt werden müssen.
Wir sind für Sie da
Es lohnt sich, die Migrationsoptionen genauer zu betrachten. Identifizieren Sie die Optimierungspotenziale bei Ihrem Umzug von SAP TM 9.5 auf SAP S/4HANA TM. Wir unterstützen Sie bei der Entscheidungsfindung Ihres Transformationskonzeptes und begleiten Sie mit geballtem Expertenwissen.
Bei Fragen zu diesem oder anderen Themen im Blog wenden Sie sich an blog@leogistics.com.
Christian Sachse
Senior Consultant SAP Logistics
Das TM in der SAP S/4HANA Public Cloud
Lagerungskosten sparen: So integrieren Sie den Cross Docking Prozess in SAP EWM
Mit dem SAP EWM Versandcockpit alles im Blick
Was ist Kitting und wie wird es in SAP EWM umgesetzt?
Innovationen in der Schüttgut-Logistik: Automatisierung und Planung im Einklang
EWM Business Suite Migration – Mit dem richtigen Vorgehen zum Ziel
1 Jahr leogistics: Jonte & Marco stellen sich vor
Warum Digitalisierung und KI künftig über den Erfolg der Lagerlogistik entscheiden
Viel Flexibilität für Ihre Transportprozesse mit Bedingungen in SAP S/4HANA TM
BLOG &
NEWS
Aktuelle Nachrichten und Blog-Beiträge aus der Welt des intelligenten Supply Chain Managements
