(Last Updated On: 26. Juni 2017)

Was sind die Hauptgründe hinter SAP S/4HANA

Warum hat sich SAP überhaupt dazu entschlossen, ein neues Produkt, namentlich SAP S/4HANA, einzuführen? Was soll dieser Marketing-Schritt beim SAP-Endkunden hervorrufen? Hauptsächlich geht es hierbei um die Nachricht, dass SAP als Softwareentwickler verstanden hat, dass sich die Geschäfte der Kunden verändert haben. Die „New Economy“ oder „Digital Economy“ war ein essentieller betriebswirtschaftlicher Treiber für die Entwicklung von SAP S/4HANA. Aktuell (2017) gibt es mehr als 4.000 lizenzierte Anwender für S/4HANA in 25 Industrien und 77 Ländern.

Viele sehen diesen Wortebrei als „Marketing-Hype“ an. Doch steckt ein wahrer Kern dahinter. 52% der Fortune 500 Unternehmen aus dem Jahr 2000 sind vergangen. Dies zeigt den Impact der Digital Economy. Dies liegt am hohen Grad der Innovation und Disruption in der Digital Economy. Die hohe Verdrängungsrate in den Fortune 500 Unternehmen zeigt, dass sich viele Unternehmen in der Vergangenheit auf ihren Lorbeeren ausgeruht haben und durch neue Innovationen und Disruptionen im Markt von Konkurrenten verdrängt wurden. Das heißt ein Business muss heute wesentlich agiler sein, um seine Vorreiterposition in der New Economy halten zu können.

Das Ziel des Unternehmens ist, SAP S/4HANA zur Standard Business Suite für Digital Economy Unternehmen zu machen. Deswegen konzentriert sich das Leistungsspektrum von S/4HANA auf die Implementierung technologischer Prozesse zur digitalen Transformation von Geschäftsprozessen. Wichtige Buzzwords hierbei sind industrie 4.0, das internet of Things, die zunehmende Digitalisierung von papiergetriebenen Geschäftsprozessen und die Echtzeit-Analyse von transaktionalen Daten im Business Suite System selbst.

ein weiterer Trend, der sich statistisch in der New Economy zeigt, ist dass die einzelnen Produkte und Dienstleistungen aufgrund der zunehmenden Digitalisierung und der damit möglichen Kosteneinsparung zwar immer günstiger werden, jedoch die Unternehmen wachsende Gewinne erwirtschaften. Das liegt schlicht und einfach daran, dass zwar der Wert einer einzelnen Rechnung durch den zunehmenden Wettbewerb und die gesunkenen Kosten immer weniger werden, jedoch das Volumen an Rechnungen und damit auch Aufträgen massiv gestiegen ist. Das heißt das Transaktionsvolumen ist in der New Economy wesentlich höher als früher, weil Dienstleistungen und Produkte sofort verfügbar sind.

Ein wichtiges Buzzword in diesem Bereich nennt sich „Segment of One“ bzw. „Unit of One“. Das heißt im Zentrum moderner Unternehmensstrategien steckt der Käufer als Individuum. Was in der Automobil-Industrie schon seit längerem Gang und Gäbe ist, nämlich dass mein sein persönliches Produkt auf die eigenen Bedürfnisse individualisieren kann, ist jetzt auch in anderen Industrien vorzufinden. So lassen sich heutzutage beispielsweise schon Sneaker auf das eigene Körpergewicht abstimmen usw. Dieser Segment of One Approach macht es unter Anderem möglich, dass ich als anbietendes Unternehmen ein solch hohes Transaktionsvolumen generieren kann. Wenn ich die Bedürfnisse eines großen Spektrums der Marktteilnehmer erfüllen kann, schöpfe ich auch ein großes Spektrum an Conversions aus dieser Zielgruppe.

Fassen wir also einmal zusammen, die New Economy bringt neue betriebswirtschaftliche Herausforderungen, und zwar

• zunehmende Dynamik und Geschwindigkeit im Markt. Es ist schwieriger, Vorreiter im Markt zu bleiben
• Produkte und Dienstleistungen werden immer günstiger. Höhere Umsätze sind oft nur durch Erhöhung des Transaktionsvolumens möglich.
• Dazu ist es nötig, die individuellen Bedürfnisse der Kunden anzusprechen (Segment of One).

Um diese betriebswirtschaftlichen Herausforderungen zu meistern, müssen wiederum technische Herausforderungen gemeistert werden.

• die zunehmende Dynamik und Geschwindigkeit im Markt macht es notwendig, dass ich schnell auf Veränderungen im Markt reagieren muss. Wesentlicher Treiber in diesem Bereich ist die Möglichkeit, durch Predictive Analysis auf diese Veränderungen im Markt reagieren zu können, bevor die Konkurrenz dies tut.

  Ich muss also frühzeitig auf Basis von Daten erkennen, was ich in meinem Unternehmen verändern muss, um erfolgreich zu bleiben. Wichtige Treiber in diesem Bereich sind das Sammeln von Daten durch Wearables und das Internet of Things, die Bevorratung dieser Daten in einem Data Lake, die Near-Realtime-Verteilung dieser Daten durch Synchronisierungstechnologien und die Echtzeit-Analyse von transaktionalen Daten durch die Integration der OLTP- und OLAP-Welt durch das Insert Only Prinzip.

  Desweiteren wird mit Hilfe von Machine Learning eine automatische Datenmodellierung vorgenommen, die versteckte Einsichten in Massendaten generiert, ohne dass spezifische Analyse-Reports geschrieben werden müssen.

• die hohe Veränderung im Markt erfordert außerdem die Fähigkeit, schnell neue Innovationen in der Software meines Business Suite Systems in meine Geschäftsprozesse integrieren zu können. Deswegen pocht die SAP so stark darauf, dass man SAP S/4HANA am besten in der Cloud betreiben sollte, um hier quartalsweise die Releasezyklen der SAP mitzunehmen, ohne sich selbst darum kümmern zu müssen. Aber auch on-Premise soll man stets schnellstmöglich das aktuellste Release adaptieren, um auf dem aktuellen Stand zu und damit wettbewerbsfähig zu bleiben. Ein sehr wichtiger dogmatischer Ansatz in diesem Bereich ist die „Keeping the Core Clean“-Philosophie, um schnelle Releasewechsel durchführen zu können.
• Das hohe Transaktionsvolumen macht es notwendig, dass meine Geschäftsprozesse schnell abgewickelt werden müssen und ich Time-To-Market Ideen schneller als je zuvor an den Markt bringen muss. Wichtige Treiber für diesen Bereich sind beispielsweise Microservices, die einen neuen Grad der Business Collaboration bewerkstelligen, und die Erstellung eines funktionierenden Integration Frameworks.
  Weiterhin muss ich hierfür schnell skalieren können. Wenn sich innerhalb von nur einem Monat mein Kundenkreis verdoppelt, muss ich dazu in der Lage sein, die dadurch gestiegene Auftragslage bewältigen zu können, mit all meinen Ressourcen. Dazu zählt beispielsweise Personal, Material, IT-infrastruktur und -Hardware sowie Lagerraum. Dies wird wiederum durch Predictive Analysis gewährleistet.

  Die IT-Infrastruktur sollte durch die Inanspruchnahme von Cloud-Services skaliert werden, da ein dedizierter Cloud-Anbieterin der Regel wesentlich schneller skalieren kann als der eigentliche Endkunde. Hierbei kann jedoch darüber nachgedacht werden, SAP S/4HANA beispieslweise weiterhin on-Premise zu betreiben und nur ausgelagerte Satellitensysteme wie beispielsweise das HR-System in Form von SuccessFactors etwa in die Cloud auszulagern.

• Das hohe Transkationsvolumen schreit außerdem nach einem hohen Grad der Automatisierung. Geschäftskritische Prozesse wie etwa das Invoicing müssen dadurch weitestgehend digitalisiert werden. Die SAP treibt beispielsweise die Digitalisierung des Invoicings durch SAP Nota Fiscal Electronica in Brasilien voran, der Trend ist aber auch in Mexiko und Spanien ersichtlich. Sehr viele Kunden implementieren in diesen Regionen aktuelle die elektronische Rechnungslegung.

  Doch nicht nur dort herrscht hohes Automatisierungspotential, wie Sie meinem Beitrag zur Digital Transformation entnehmen können. Diese Automatisierung bedeutet auch, dass Geschäftsprozesse exception-based gesteuert werden, etwa wenn ein Kreditlimit ausgereizt wird oder eine Lieferung um den Faktor x zu spät kommt. Somit verschwenden Mitarbeiter keine Zeit mehr mit dem Bearbeiten von Vorfällen, die innerhalb der Tolleranzgrenzen sind.

die technischen Treiber hinter SAP S/4HANA

Das INSERT ONLY Prinzip zur Vereinigung von OLTP- und OLAP-Werten

Klassische zeilenorientierte Datenbanken unterstützten vier Arten von Datenmanipulationen: Abfrage (SELECT), Einfügen (INSERT), Verändern (UPDATE) und Löschen (DELETE). Jedesmal, wenn eine destruktive Art der Datenmanipulation, also UPDATE oder DELETE, ausgeführt wird, werden die Betroffenen Datensätze so lange für neue Aktionen gesperrt, bis die Aktion abgeschlossen ist. Das heißt der Datensatz kann solange nicht bearbeitet oder neu angelegt werden, bis das vorherige UPDATE- oder DELETE-Statement abgeschlossen ist.

Die Datenbank erzeugt hierzu Datenbank-Sperren auf den Datensätzen und löst dieser erst dann wieder, wenn das Statement abgeschlossen ist. Das INSERT-ONLY Prinzip erlaubt keine destruktiven Datenmanipulationen mehr, sondern nur noch SELECT- und INSERT-Operationen auf die Daten. Das heißt einfach ausgedrückt, wenn ich einen Datensatz in meiner Datensatz ändere, wird der bestehende Datensatz nicht geändert, sondern ein neuer Datensatz erzeugt, aber auch nur mit dem Delta der Daten, also mit der eigentlichen Änderung.

Durch die spaltenorientierten Architektur der HANA-Datenbank kann ich sehr schnell alle Datensätze abfragen, um alle Datenänderungen auf die fragliche Entität abzufragen, um mir den aktuellen Stand der Daten im Falle einer SELECT-Abfrage blitzschnell zusammen zu bauen. Der Vorteil der INSERT-Only Architektur ist der, dass ich keine Datenbanksperren habe.

Ich kann mehrere Änderungen an einer Entität parallel in die Datenbank persistieren, indem ich mehrere Änderungsvektoren an dieser Entität parallel in Form mehrerer INSERT-Statements in die Datenbank einfüge. Dadurch, dass es keine Datenbanksperren mehr gibt, kann ich eine wesentliche höhere Anzahl von Transaktionen gleichzeitig verarbeiten. Statistisch handelt es sich hier um den Faktor 16. Mehr informationen warum mit SAP HANA die OLTP- und OLAP-Welt zusammen geführt werden kann finden Sie in meinem Einführungspost zu SAP HANA.

Die Cloud

Aus Sicht von SAP ist die Cloud einer der Haupttreiber von SAP S/4HANA. Viele Beratungsunternehmen und Kunden sehen dies aus gutem Grund noch etwas skeptisch. Speziell für Kunden, die viele kundeneigene Entwicklungen machen, ist die Cloud-Lösung noch nicht optimal, daher gibt es auch weiterhin die Option für on-Premise.

Jedoch ist die grundsätzliche Argumentation hinter einem einfach zu konsumierenden Cloud-Services durchaus nachvollziehbar. Zum einen ist die Lösung schnell eingeführt. Innerhalb weniger Minuten nach der Bestellung steht die Lösung für Sie bereit. In einer Public Cloud Lösung können neue Innovationen schnell und quartalsweise ausgerollt werden, das heißt Ihr Business erhält zu jeder Zeit topaktuelle Software welche an den sich rasch entwickelnden Markt angepasst ist. Der Service ist schnell skalierbar, da Sie sich nicht selbst als Kunde um den Ausbau von Räumen, die Anschaffung von neuer Hardware und die Einstellung von neuem Personal kümmern muss, sondern das zentral durch den Dienstleister für Sie erledigt wird.

Aus dieser Sicht der Dinge macht es auch Sinn, dass Sie SAP S/4HANA mit den anderen Cloud-Produkten der SAP verbinden können. So können Sie beispielsweise einen Mitarbeiter, den Sie in SuccessFactors angelegt haben, automatisch in Ihrer SAP S/4HANA-Lösung als SAP-User anlegen lassen, der sofort alle notwendigen Berechtigungen, Screens und Transaktionen für die ihm zugewiesene Position zur Verfügung hat.

Hauptbenefits von S/4HANA

Neben den mit S/4HANA geplanten Innovationen, die wir weiter unten besprechen und welche vor allem die einzelnen Fachbereiche (Lines of Business LoB) ansprechen, gibt es auch übergreifend bereits einige Argumente, die für S/4HANA sprechen könnten.

S/4HANA versteht es sehr gut, die Vorteile von SAP HANA zu nutzen. Auch wenn Sie bereits in Ihrem SAP ERP System on HANA den Vorteil genießen können, dass Sie OLTP und OLAP-Daten in einer einzigen Datenbank („OLTP and OLAP together„) zusammenführen können, bietet S/4HANA mit seiner sogenannte Embedded Analytics Funktionalität bereits die Möglichkeit, zumindest das operationale Reporting komfortabel und zielgerichtet in Form von Fiori Apps anzubieten.

Bei S/4HANA wurde sehr viel Wert auf die User Experience gelegt. Das bereits schon aus Simple Finance bekannte Fiori Launchpad ist rollenbasiert (jeder User sieht also zunächst nur „seine“ Transaktionen als Kacheln, die er selbst braucht) und soll in der Version 2.0 den gesamten Transaktionsspielraum abdecken können, so dass die Desktop-Software SAP Logon und mehr obsolet werden wird. Die Systemkonfiguration von S/4HANA wird mit Hilfe von SAP Activate und den Guided Configuration Procedures ähnlich denen des Solution Manager 7.2 (bspw. SOLMAN_SETUP) wesentlich agiler und einfacher werden.

Neue Funktionalitäten für das Portfolio- und Projektmanagement

SAPs cProjects (auch bekannt unter den Namen SAP Resource and Portfolio Management (RPM) und SAP Project Portfolio Manageent (PPM) fand im Kundenstamm nicht gerade auf große Zustimmung. Das lag an der schlechten Integration in die SAP-Module.

cProject war zwar zu einem gewissen Grad in SAP PS und SAP FI/CO integriert, hatte jedoch dadurch noch nicht genügend Vorteile parat, um sich gegen Konkurrenzprodukte wie etwa MS Project durchzusetzen. SAP RPM und SAP PPM sind nun in SAP S/4HANA integriert und sollen noch enger mit den Core-Modulen verdrahtet werden.

Zudem ist eine Import/Export-basierte Integration mit Microsoft Project möglich, siehe SAP Note 2340078. Dies soll die Relevanz der SAP-internen Tools beim Projektmanagement erhöhen.

Integration zahlreicher Softwarekomponenten in den Kern

SAP Enterprise Warehouse Management (EWM) ist in SAP S/4HANA integriert und kann somit beispielsweise als ausgelagertes oder zentrales EWM-System in S/4HANA selbst betrieben werden. Discrete Industries and Mil Products (DIMP), was zuvor als Addon in ein SAP ERP-System eingespielt werden musste, ist nun in den S4CORE integriert.

Mit S/4HANA 1610 ist außerdem IS-RETAIL inkludiert und das Industry Addon IS-OIL kann dynamisch out of the box aktiviert werden ohne manuellen Integrationsaufwand im Vorfeld. Und diese Integration von Daten in S/4HANA ist auch ein sehr wichtiger Vorteil von S/4HANA: Es gibt nur noch einen Single Point of Truth, redundante Daten werden dadurch weitestgehend reduziert.

Advanced availability to promise

Die Availablity to Promise (ADP)-Funktion bedeutet, dass ich einem Kundne ganz genau zusichern kann, ob eine gewisse Anzahl meiner Produkte gerade verfügbar ist und ich sie ihm zum gewünschten Termin liefern kann. In älteren Releases galt hier häufig das first come – first serve Prinzip. Das heißt der Kunde, der als erstes bestellt hat, hat die Ware bekommen.

Mit Hilfe von vorausschauenden Analysen ist es möglich, hier beispielsweise andere Compliance-Regeln des Unternehmens wie Rush Orders. Die SAP nennt das neue Prinzip das „Winner – Gainer – Loser“-Konzept. Damit können Kundenbestellung priorisiert werden, je nachdem welchen Wert diese für das eigene Unternehmen haben.

Wenn beispielsweise nicht genügend Produkt da ist, um alle Kundenbestellungen zu erfüllen, wird als aller erstes der Kunde bedient, dessen Vertrag bald erneuert wird. Dazu muss der bereits reservierte Materialstamm neu verteilt werden. So kann man beispielsweise Material von Kundenbestellungen abziehen, die ihr Kreditlimit erreicht haben und daher ohnehin nicht beliefert werden können, oder die mehr als die vertraglich zugesicherte Mindestlieferungsmenge bestellt haben.

Simplifications

Simplifications bezeichnen die Zusammenführung von Business Entities, die früher in mehreren Systemen unter verschiedenem Namen geführt wurden, als unter S/4HANA. So wurde früher beispielsweise im SAP ERP System die Entitäten „Customer/Vendor“ und in SAP CRM der „Business Partner“ gepflegt.

Häufig glichen sich hier die Daten in beiden Systemen häufig, so dass mit Master Data Governance (SAP MDG) hier häufig eine Konsistenz herbeigeführt werden musste. In SAP S/4HANA sind die Entitäten Customer/Vendor und Business Partner zusammengeführt, so dass dieser Prozess entfällt (was jedoch nicht bedeutet, dass Master Data Governance in Zukunft unbedeutend sein wird, gerade mit den ganzen Cloud-Services als Datensatelliten und dem Data Mining aus der Social Media wird es wichtiger denn je).

Unter SAP S/4HANA 1610 gibt es ca. 400 dieser sogenannten Simplification Items. Dies bedeutet auch, dass die veschiedenen Transaktionen zusammengelegt wurden. Sie finden einen Überblick über diese Simplifikationen in der sogenannte Simplification List, die Sie hier betrachten können.

Embedded Analytics

wie wir bereits gelernt haben, ist es durch das INSERT ONLY Prinzip von SAP HANA und die spaltenorientierte In-Memory-technologie möglich, die OLTP- und OLAP-Welt zusammenzubringen. Das heißt User, die in einem transaktionalen System Daten pflegen, können während der Pflege und Verarbeitung dieser Daten von Echtzeit-Analysen profitieren. Somit ist es unter SAP S/4HANA möglich, dem User kontextbezogene Informationen  in Echtzeit anzubieten.

Ein mögliches Szenario wäre beispielsweise, dass ein User, der eine Materialbestellung anlegt, sofort einen Überblick über die aktuelle Budget-Situation des Unternehmens haben möchte. Gleichzeitig möchte er eine Liste aller Lieferanten für ein bestimmtes Material und die durchschnittliche Lieferzeit jedes einzelnen Lieferanten haben.

In Legacy-OLTP-Systemen war dies häufig nicht möglich, denn die Analyse der durchschnittlichen Lieferzeiten war häufig ein Prozess, der mehr als 10 Minuten gedauert hat (abhängig vom Volumen der Lieferanten-Datensätze in der datenbank). Das heißt eine Echtzeit-Einsicht war hier nicht möglich. Mit Hilfe der kontextbasierten Echtzeit-Einsicht von Budget und Lieferzeiten aller Lieferanten ist es dem Mitarbeiter unter SAP S/4HANA möglich, zu entscheiden, ob ein Lieferant mit teuereren Konditionen, aber dafür schnellerer Lieferzeit, beim aktuellen Budget abhängig von den unternehmensinternen Compliance-Regeln die richtige Wahl ist.

Diese Entscheidung hätte früher wesentlich länger gedauert, weil dazu erst der Analyseprozess entweder auf dem OLTP-System selbst oder auf einem externen OLAP-System hätte stattfinden müssen. Jetzt können solche Entscheidungen beinahe on-the-fly getroffen werden. Aber nicht nur die Datenbankschicht alleine, sondern auch die Gestaltung von SAP Fiori 2.0 und die Implementierung von Virtual Data models auf Basis von Core Data Services (CDS) sowie die Fähigkeit von SAP S/4HANA, direkt auf SQL Views von SAP HANA zugreifen zu können, ermöglichen diese kontextbezogene Informationsbereitstellung.

Die SAP hat hier bereits die wichtigsten KPIs als „SAP Smart Business KPIs“ in seinen Standard-Fiori-Applikationen für den User zusammengefasst, so dass für diese Informationen kein Programmier- und Modellierungsaufwand betrieben werden muss.

Mit seinen Virtual Data Model Views liefert die SAP außerdem viele vorgefertigte Views, die von Entwicklern genutzt werden können, um ihre eigenen analytischen Fiori-Apps zu entwickeln. Desweiteren können eigene CDS Views erstellt werden. Die SAP Fiori Query Designer App erleichtert außerdem die Erstellung die Verwaltung von analytischen Queries für Entwickler.

Geplante Innovationen in S/4HANA

SAP S/4HANA wird rapide weiterentwickelt. Jedes Jahr soll ein neuer Main-Release heraus kommen, dazwischen gibt es jedes Quartal einen sogenannten Feature Pack Stack (FPS). Jedes FPS und jeder Release bringt neuen Innovationen mit sich, die das Business Ihres Enterprises grundlegend verändern können.

Wie finden Sie heraus, welche Innovationen in einem S/4HANA Release enthalten sind? Eine hilfreiche Quelle hierzu ist immer der sogenannte Product Scope Guide für das jeweilige Release. Den Product Scope Guide für 1511 FPS2 finden Sie beispielsweise hier.

Weitere interessante Doumente für Sie sind das What’s New sowie das Dokument zum jeweils aktuellen Feature Package Stack sowie die Feature Scope Description

Geplante Innovationen in künftigen Releases finden Sie immer unter der sogenannten Product Vision https://www.sap.com/roadmaps

Grundsätzlich kann es jedoch für einen Anwender sehr schwierig sein, durch diesen Product Scope Guide durchzusteigen. Daher ist eine Vorstellung bzw. eine Kunden-Demo durch eine Unternehmensberatung hier für viele Kunden der wesentlich einfachere Weg.

Was die Innovationen in der Zukunft betrifft, so ist es für Anwenderkunden nicht gerade einfach, auf diese Informationen zugreifen zu können. Ein Beratungsunternehmen hingegen kann diese Informationen bis zu einem gewissen Grad liefern. Aktuell sind die Innovationen bis in das Release 1705 bekannt, was einem Zukunftsblick bis Ende 2017 entspricht.

SAP S/4HANA evaluieren

Es ist schön, dass ich Ihnen hier Benefits und Features von SAP S/4HANA aufliste. Jedoch möchten Sie vielleicht das System selber anfassen, bevor Sie im Rahmen Ihres Evaluierungsprojekts eine konkrete Kaufentscheidung treffen. Die schnellste und unkomplizierste Verfahren, um SAP S/4HANA zu evaluieren, ist die 30-Tage-Trial, die in der SAP Cloud Appliance Library (CAL) zur Verfügung gestellt wird.

Wie schnell gehen Sie auf SAP S/4HANA?

Bevor Sie sich entscheiden, über welches technische Verfahren Sie einmal auf SAP S/4HANA gehen wollen, sollten Sie sich Gedanken darüber machen, wie Sie ihre S/4HANA Adaption einplanen wollen.

Eine frühe Konvertierung zu SAP S/4HANA bietet Ihnen gewisse Vorteile, denn Sie profitieren sofort von Innovationen der Software und adaptieren diese Schritt für Schritt. So können Sie in Ihrem Unternehmen bereits früh und vor allem stückweise Know-How aufbauen, ohne gleich mit den Neuerungen mehrerer Releasewechsel auf einen Schlag konfrontiert zu werden.

Und: Sie entwickeln Ihre Customer Enhancements und Ihr Customizing bereits auf dem aktuellen S/4HANA Release, was bedeutet, dass Sie diese später nicht mehr umständlich anpassen müssen, was Zeit spart. In diesem Schritt geht man also baldmöglichst den Schritt auf SAP S/4HANA. Dies hat als Konsequenz, dass man sich keine Mühe mehr macht, seine SAP Business Suite Systeme zu aktualisieren, also beispielsweise von SAP ERP 6.0 EHP4 auf EHP8 zu gehen, sondern man plant lieber gleich ein Projekt für die Migration auf S/4HANA.

Der Nachteil bei diesem Adopter Programm: Sie müssen sich sehr früh mit den Neuerungen von SAP S/4HANA auseinander setzen und holen sich daher sehr früh die Kuh auf’s Eis, und zumindest als on-Premise Kunde müssen Sie wesentlich öfter Upgrade-Projekte fahren, um auf dem aktuellen Softwarestand zu bleiben.

Bei der SAP Business Suite hingegen hätten Sie unter Umständen zwei Jahre lang Ruhe gehabt, in Ruhe weiter zu entwickeln, ohne dass es Ihren Geschäftsbetrieb gestört hätte. Diesen Nachteil haben Sie freilich nicht, wenn Sie in der Public Cloud sind, da hier die Upgrades für Sie als Service durchgeführt werden, jedoch können Sie dann keine Eigenentwicklungen fahren.

Als Spät-Adaptierer hingegen arbeitet man möglichst lange noch auf seiner alten Business Suite weiter, bevor man den Schritt auf SAP S/4HANA geht. Das heißt man zögert den Schritt auf S/4HANA auf einen Punkt hinaus, an dem man zum ersten mal ein Feature von S/4HANA entweder wirklich in seinem Business benötigt oder aber die SAP durch seine Support-Strategie dem Kunden keine andere Wahl mehr lässt.

Das heißt in dieser Strategie plant man durchaus noch mit EHP-Upgrades seiner bestehenden Business Suite Systeme, geht also beispielsweise vor dem Schritt auf S/4HANA nochmal den Weg und aktualisiert SAP ERP 6.0 von EHP4 auf EHP8 o. Ä., um nur die nötigsten Features mitzunehmen. Hier sind die Vor- und Nachteile umgekehrt.

Sie entwickeln länger auf dem aktuellen Produktstand, ohne ein Softwareupgrade vornehmen zu müssen, verlieren jedoch im Gegenzug wertvolle Zeit beim Sammeln von Know How in S/4HANA und profitieren nicht schon früh von den gelieferten Innovationen.

Ein sinnvoller Zwischenschritt in diesem Programm ist meist die Integration von Simple Finance 2.0 bzw. SAP S/4HANA Finance, da Sie damit schon von einem vereinfachten Datenmodell (Stichwort „No Aggregates„) sowie von dem Single Point of Truth Ansatz profitieren.

Der Zwischenschritt wird einfach nur als „Adapt at own speed“ bezeichnet. Das heißt der Kunde geht zum Zeitpunkt X auf S/4HANA, wenn er gezielt eine Innovationen eines bevorstehenden Zielreleases nutze möchte. Dies bedeutet auch, dass der Kunde mitunter einige FPS-/Release-Upgrades von S/4HANA überspringt, also sein Coding teilweise auch auf einem älteren Softwarestand entwickelt.

Letztendlich kommt es auf Ihren Business Case an, welche Adaptionsstrategie Sie wählen sollten. Hierbei gilt es sehr gezielt festzustellen, warum Sie auf S/4HANA gehen wollen und was Ihnen hierbei wichtig ist. Geht es Ihnen gezielt um einzelne Innovationen in der Software, wäre der zuletzt erwähnte Zwischenschritt der beste für Sie.

Wenn Sie für SAP S/4HANA gezielt Know-How sammeln und kundenspezifische Software auf dem neuesten Releasestand entwickeln wollen, ist eine frühe Adaption die Strategie der Wahl. Dafür spricht außerdem, dass ein Upgrade auf ERP 6.0 EHP8 einen ähnlichen Umfang an abzuarbeitenden SPDD/SPAU-Einträgen aufweisen würde als eine System Conversion auf S/4HANA (rund 1/3 aller Customer Code Objekte müssen in der Regel nach einer Conversion durch SPDD/SPAU bearbeitet werden).

Sehen Sie trotzdem derzeit keinen akuten Mehrwert von S/4HANA (bei großen Enterprises eher die Seltenheit), sollten Sie erst spät auf S/4HANA gehen und mitunter den Support Zeitraum der Business Suite ausnutzen.

Deployment Optionen

wenn Sie sich entschieden haben, wie rasch Sie auf S/4HANA gehen wollen, macht es Sinn darüber nachzudenken, welche Deployment Option Sie angreifen wollen.

Option	On Premise	HANA Enterprise Cloud	SAP S/4HANA Enterprise Management Cloud – Private Cloud Option	SAP S/4HANA Enterprise Management Cloud – Public Cloud Option
Funktionsumfang	Voller Funktionsumfang	Voller Funktionsumfang	Voller Funktionsumfang	spezielle Szenarios für verschiedene Branchen
Flexibilität	Volle Konfigurations- und Modifikationsmöglichkeiten. Extensions erlaubt.	Volle Konfigurationsmöglichkeiten. Modifikationen zum Großteil möglich, aber wenig ABAP-Modifikationsspielraum. extensions erlaubt	Voller Konfigurationsumfang. Extensions erlaubt. Keine Customer Modifications erlaubt.	Extensions nur über Custom Code Services, keine Modifikationen.
Lizenzmodell	Traditionell (Kaufbetrag + Lizenzvermessung + Support-Vertrag)	Traditionell und als Abonnement	Abonnementmodell	Abonnementmodell
Application Management	Komplett in Kundenverantwortung	Als Service Verfügbar als zusätzliche kundenspezifische Option	Als Service im Abonnement enthalten	Als Service im Abonnement enthalten
Infrastructure Management	Komplett in Kundenverantwortung	Als Service Verfügbar als zusätzliche kundenspezifische Option	Als Service im Abonnement enthalten	Als Service im Abonnement enthalten
Support	SAP-Supportvertrag bestimmend	Spezielle Serviceoptionen für Kunden	Cloud Enterprise Support	Cloud Enterprise Support
System Governance	Kunde	Kunde
Kundenverantwortung für Weiterentwiclkungen und Upgrades	Kunde	Starke Einbeziehung des Kunden bei Weiterentwicklungen	Kunde nur für’s Testen zuständig	Zuständigkeiten größtenteils bei SAP
Frontend Technologien	Webbrowser + SAP GUI	Webbrowser + SAP GUI	Webbrowser + SAP GUI	Nur Webbrowser

Für ein Deployment on Premise spricht beispielsweise wenn Sie als Kunde Ihr SAP-System bisher sehr stark eigenständig mittels ABAP-Coding modifiziert haben, also die Erfahrung gemacht haben, dass Sie in Ihrem Business Funktionalitäten über den SAP Standard hinaus benötigen. Dort haben Sie in Punkto Weiterentwicklung on-Premise immer noch die besten Möglichkeiten.

Denn nur on-Premise haben Sie die volle sogenannte „Classic Extensibility“, in welcher Sie aus den vollen möglichkeiten von ABAP schöpfen. In der Cloud wird Ihnen nur die sogenannte „Key User Extensibility“ gegeben, also die Möglichkeit etwa kundeneigene Felder, Tabellen, Views, Analysen und Formulare  zu definieren. Hier können sie also nur auf Frontend-Ebene Modifikationen vornehmen, nicht jedoch auf Applikations- und Datenbank-Ebene.

Für ein Deployment in der Cloud hingegen spricht etwa, wenn Sie bisher wenig selbst modifiziert haben und stattdessen lieber immer auf dem aktuellen Releasestand sein wollen. Denn in der Cloud wird ein neuer Release immer nach einem fixen Terminplan eingespielt, was automatisch dazu führt, dass Sie als Kunde immer ohne relativ großes Eigenrisiko auf dem aktuellen Stand bleiben und immer die neuesten Funktionalitäten mitnehmen, ohne sich um ein eigenes Upgrade-Projekt kümmern zu müssen.

Roadmaps zu SAP S/4HANA

Die erste Option, Landscape Transformation, bietet sich vor allem an,  mehrere SAP ERP-Systeme zu einem System zusammenführen wollen. Am häufigsten treffen Kunden diese Entscheidung, wenn Sie sich dazu entscheiden, ein Central Finance System aufzubauen. in diesem Fall müssen die Daten aus mehreren ERP-Systemen in ein einziges SAP S/4HANA Finance System synchronisiert werden.

Auch interessant ist diese Option für Sie, wenn sie beispielsweise Business Entities aus einem Non-SAP-System oder aus einem Legacy SAP-System in S/4HANA migrieren wollen. So könnten Sie etwa lediglich den Company Code aus einem älteren System in ein Greenfield SAP S/4HANA System synchronisieren und dann unter SAP S/4HANA mit den Daten weiter arbeiten. Diese Upgrade-Option ist verfügbar sowohl für Kunden, die ein on-Premise Deployment von SAP S/4HANA fahren wollen, als auch für das Cloud-Deployment.

Die Landscape transformation Option setzt immer auf ein zur Verfügung gestelltes SAP S/4HANA-System auf, das heißt für die Landscape Transformation Option wurde im Vorfeld durch eine der beiden anderen Implementation Options, also entweder durch Neuimplementierung oder durch eine System Conversion, ein SAP S/4HANA System zur Verfügung gestellt. Die Landscape Transformation Option ist also keine alleinstehende Roadmap.

die Landscape Transformation Option besteht aus einem oder mehreren Quellsystemen auf der einen, einem SAP S/4HANA System auf der anderen Seite, und dem SAP Solution Manager 7.2 in der Mitte. der SAP Solution Manager 7.2 kümmert sich hierbei um die Erweiterung und die Transformation der Daten in die Zielstruktur von SAP S/4HANA.

Haben Sie die SAP S/4HANA Cloud Edition gewählt, liefert SAP vorkonfigurierten Transformation Content bereit. Die Daten von SAP-Quellsystemen können Sie über eine RFC-Schnittstelle oder über Direct DB Connection (für sehr alte Systeme) übertragen, Daten von Non-SAP-Systemen werden über Flat file Export/Import migriert.

Ein Landscape Transformation Projekt muss IMMER unter Einbeziehung des SAP Supports statt finden. Dies heißt jedoch nicht, dass sämtliche Arbeit durch SAP-internes Consulting statt finden muss. Je nach Wunsch können Aktivitäten an den Kunden selbst oder einen offiziellen SAP-Partner ausgelagert werden. als absolutes Minimum muss das Transformations-Projekt jedoch durch die SAP selbst geplant und überwacht werden.

Die zweite Option, eine System Conversion Ihres aktuellen Systems, bietet sich an, wenn Sie einen Release von ERP 6.0 (2005) EHP0 oder neuer haben und vor allen Dingen Ihre bisherigen Customer Code Enhancements mitnehmen wollen. Für eine System Conversion muss Ihr Quellsystem zusätzlich bereits ein Unicode-System sein.

Es ist nicht möglich, ein Non-Unicode-System direkt zu konvertieren. Die System Conversion ist nur für das on-Premise Deployment von SAP S/4HANA verfügbar, weil der Hautpgrund für eine System Conversion ja die Mitnahme von kundeneigenen Entwicklungen ist. Da kundeneigene Entwicklungen im Cloud-Deployment nicht möglich sind, ist der Migrationspfad der System Conversion für das Cloud-Deployment nicht verfügbar.

Bei der System Conversion können Sie entweder ein SAP CRM, SAP Business Suite on HANA, SAP Business Suite on AnyDB oder ein SAP-ERP-System in die SAP S/4HANA Familie konvertieren. Alle der genannten Systeme können Sie in ein SAP S/4HANA Enterprise Management  System konvertieren, nur ein SAP ERP-System hingegen können Sie nach SAP S/4HANA Finance konvertieren, um beispielsweise ein zentrales Finance System aufzubauen.

Um Ihre Verwirrung aufzulösen: Wenn man von SAP S/4HANA spricht, meint man in der Regel SAP S/4HANA Enterprise Management. Einige Unternehmen wählen die Strategie, als Zwischenschritt erst auf SAP Simple Finance bzw. SAP S/4HANA Finance zu gehen. Diese Strategie wird häufig gewählt um möglichst schnell die Innovationen im Finance-Bereich zu adaptieren oder um die Business Downtime nicht auf einmal so riesengroß ausfallen zu lassen, sondern diese auf zwei Downtimes aufzuteilen.

Es ist aber grundsätzlich nicht empfehlenswert, ein SAP ERP beispielsweise erst nach SAP Simple Finance bzw. SAP S/4HANA Finance und dann später zu SAP S/4HANA Enterprise Management zu konvertieren. Sollten Sie SAP S/4HANA Enterprise Management als Ziel für ein bestehendes SAP ERP-System bestimmt haben, sollten Sie direkt auf Enterprise Management konvertieren.

Bitte beachten Sie: Wenn Sie darüber nachdenken, erst auf SAP S/4HANA Finance zu gehen und danach auf SAP S/4HANA Enterprise Management wollen, können Sie immer nur auf eine höhere Release-Nummer. sie können also beispielsweise nicht von SAP S/4HANA Finance 1605 auf SAP S/4HANA Enterprise Management 1511, sondern nur auf 1610.

Zu guter letzt gibt es natürlich die Option einer kompletten Neueinführung von SAP S/4HANA, die sich vor allem für SAP-Neukunden anbietet, die ihre alten Daten nicht mit führen müssen oder die von einer Drittanbieter-ERP-Lösung auf SAP S/4HANA umstellen wollen.

In dem Fall installieren Sie beispielsweise SAP S/4HANA neu, migrieren anschließend die Daten des Drittanbieter non-SAP-Systems über SAP Data Services oder das Migration Cockpit ins System und führen im Anschluss eine Grundkonfiguration durch. Es ist außerdem empfehlenswert über eine Neuimplementierung und eine anschileßende Datenmigration nachzudenken, wenn es Ihnen nicht möglich ist, in einer One-Step-Procedure auf SAP S/4HANA zu gehen.

Das ist beispielsweise dann der Fall, wenn Ihr System noch nicht Unicode ist. Denn dann müssen Sie vor der System Conversion noch eine Unicode Conversion oder alternativ eine Database Migration Option auf ein anderes Release durchführen. In diesem Fall kann es für sie günstiger sein, statt einer Two-Step-Procedure mit System Conversion stattdessen eine Neuimplementierung mit anschließender Datenmigration durchzuführen.

Einen Überblick über die existierenden Migrationspfade finden Sie auch vom Hersteller selbst unter http://sap.com/S4-paths.

Sandboxing von SAP S/4HANA

Nachdem Sie sich jetzt dazu entschieden haben, ob und wie Sie auf SAP S/4HANA gehen wollen, müssen Sie in einer Sandboxing-Phase versuchen, die wichtigsten Geschäftsprozesse, die derzeit von Ihren Legacy-Systemen zur Verfügung gestellt wurden, unter SAP S/4HANA zu realisieren. dazu reicht in der Regel die 30-Day-Trial aus der SAP CAL nicht.

Deshalb können Sie sich entweder selbst oder wiederum über die SAP CAL eine SAP S/4HANA Appliance aufbauen und in dieser einen IDES-ähnlichen Content einspiele, um damit dann die entsprechenden Szenarien nachzustellen. Entscheiden Sie sich für die vorkonfigurierte Appliance aus der SAP CAL, sind in dieser bereits folgende Mandanten vorkonfiguriert

Mandant	Beschreibung	geeignet für
100. Trial Client	voraktivierte Best Practice Konfiguration und stammdaten für Deutschland und die USA. zusätzliche Konfiguration für ende-zu-Ende Beispiel-Geschäftsprozessen Transaktionale Daten in einem company Code für Deutschland. Integration mit SAP ariba und dem SAP Financial Services Network ist noch nicht vorhanden, kann aber vom Kunden oder einem Partner konfiguriert werden.	Trial, ausprobieren
200. ready-to-Activate Client	Geeignet für die Aktivierung des BestPractices content, da hier die technsiche Vorbereitung bereits durchgeführt wurde	Proof of Concept von Beginn an
300. Best Practices Referenz-Mandant	Der Best Practices content für alle Lokalisierungen wurde hier bereits aktiviert (im Gegensatz zum Mandant 200).	Sandbox
400 IBP Mandant	Voraktivierter Content für SAP Integrated business planning (IBP) for finance	Szenarios für IBP for Finance
500 Best practices client	ähnlich Mandant 300	Sandbox

Haben Sie sich für ein on-Premise Deployment ihrer SAP S/4HANA Sandbox entschieden, müssen Sie diese Mandanten selbst vorbereiten. Führen
Sie hierzu eine Mandantenkopie des Mandanten 000 mit dem Profil „SAP_CUST“ durch und aktivieren Sie danach den SAP Best Practices Content.

Natürlich müssen Sie nicht den SAP Best Practices Content nutzen, wenn Sie das nicht wollen. In diesem Fall führen Sie ein Sandboxing-Projekt wie bei einem Legacy-SAP System durch. Dazu kopieren Sie den mandant 000 mit seinem gesamten Inhalt (Profil SAP_ALL) und führen dann ein Standard-Customizing über den SAP Implementation Management Guide (IMG, Transaktion SPRO) durch.

Eine vollständige SAP S/4HANA Sandboxing Landschaft besteht in der Regel nicht nur aus einer einzelnen SAP S/4HANA Appliance, sondern zusätzlich aus einem externen SAP Fiori Frontend Server, dem SAP Solution Manager 7.2, einem SAP NW AS Java mit der technischen Rolle eines Adobe Document Services Providers und diversen Frontend-Clients welche mit SAP HANA Studio, den ABAP Dev Tools, SAP Lumira und dem SAP Design Studio ausgestattet sind. Mit dieser Landschaft sandboxen Sie einen kompletten SAP S/4HANA Business Workflow.

Später sollten Sie daran denken, einen SAP Fiori Frontend Server pro Systemlinie, also DEV, Q und P, zu betreiben. Es macht keinen Sinn, einen Fiori Frontend Server für alle Systeme einer Transportlinie zu verwenden. Sie können jedoch einen einzigen Fiori Frontend server für alle Ihre DEV-Systeme in der Systemlandschaft verwenden usw.

SAP Solution Manager 7.2 als wichtiger Bestandteil der Systemlandschaft

Für ein SAP S/4HANA Implementierungsprojekt ist SAP Solution Manager 7.2 unverzichtbar, da Sie mit dem SolMan 7.1 und dessen Maintenance Optimizer (MOPZ) alleine schon keine valide stack.xml für das Ziel-Release mehr generieren können. Aber der SolMan 7.2 bringt auch aus funktionaler Sicht entscheidende Vorteile beim Sandboxing von SAP S/4HANA durch die Implementierung des Best Practices Content.

Desweiteren ist der SolMan 7.2 ein wichtiger Unterstützer bei der Analyse Ihres Legacy-Codings über das Usage Procedure Log (UPL). Durch diese statistische Auswertung finden Sie heraus, welcher Teil Ihres Customer Codings nie genutzt wird und daher nicht für die System conversion berücksichtigt werden muss.

Sie sollten also parallel zum Aufbau Ihrer SAP S/4HANA Sadbox ein Upgrade oder eine Neuinstallation von SAP Solution Manager 7.2  durchführen. Nach der Installation und der Grundkonfiguration von SolMan 7.2 (Transaktion SOLMAN_SETUP) sollten Sie Ihre Systemlandschaft in logische Gruppen einteilen und all Ihre Systeme in der LMDB entsprechend abbilden.

Binden Sie dann die Systeme, deren ABAP-Coding für eine SAP S/4HANA System Conversion geprüft werden sollen, an das Usage Procedure Log (UPL) an, implementieren Sie Change Request Management und Quality Gate Management für die Entwicklungssysteme und bereiten Sie ein geschäftsprozessbasiertes Monitoring Ihrer Systemlandschaft vor. Danach, wenn Ihr SAP S/4HANA Projekt beginnt, erstellen Sie ein SAP Activate Projekt und implementieren mit Hilfe des SolMan 7.2 den Best Practices Content.

Wenn Sie außerdem entweder nach der Neuinstallation oder nach der System Conversion von SAP S/4HANA Daten aus anderen Quellsystemen nach S/4HANA migrieren möchten, liefert der Solution Manager 7.2 mit seiner Landscape Transformation Platform die notwendigen Tools zur Migration dieser Daten.

Empfehlenswert ist außerdem, ein möglichst automatisiertes und zentral verwaltetes Testing Ihrer SAP-Systeme über den Solution Maanger 7.2 und Selenium zu implementieren. Je mehr Tests Sie automatisieren können, desto weniger müssen ihre Softwaretester bei einem Go-Live Projekt ackern und können sich auf das Testen wichtiger Kernfunktionalitäten der Power-User konzentrieren. Wenn Ihre Tests zentral verwaltet werden, kann es nicht passsieren, dass etwa die Testresultate eines einzelnen Sofwtaretesters unter den Tisch fallen und es nach einem Go-Live zu bösen Überraschungen kommt.

der SAP Best Practices Content

Der SAP Best Practices Content ist ein einspielbarer Inhalt in eine SAP S/4HANA Trial Sandbox, welche die von SAP ausgedachten Best Practices zur Abwicklung geschäftsrelevanter Prozesse darstellen soll. Der Kunde soll dadurch die Möglichkeit haben, häufige Geschäftsprozesse unter SAP S/4HANA nachspielen und evaluieren zu können.

Der SAP Best Practices Content besteht nicht nur aus dem eigentlichen Content, der heruntergeladen und in die Trial Sandbox eingepielt werden kann, sondern auch aus der SAP Best Practices Documentation, welche in einem Geschäftsprozessidagramm genau beschreibt, wie der Prozess funktioniert. Desweiteren liefert die Best Practices Documentation Skripte zum Testen der Lösung, einen Überblick über die Stammdaten, welche der jeweilige Best Practices Content enthält, sowie Präsentationen zur Erklärung des Prozessablaufes.

In der Regel sollten Sie beim Ausprobieren des Best Practices Contents fest halten, welche Ihrer individuellen Kundenwünsche vom SAP Best Practices Content noch nicht erfüllt werden wie sie diese Lücken schließen können. Dies wird zentral im SAP Solution Manager 7.2 im sogenannten Backlog festgehalten.

Hierdurch haben Sie in der Realisierungsphase von SAP S/4HANA einen Überblick darüber, welche zusätzlichen Konfigurationsschritte, Berechtigungen, Workflows, ABAP-Reports, Interfaces und andere Erweiterungen Sie benötigen, um Ihren gewünschten Kunden-Scope im neuen Produkt abdecken zu können. Das Backlog unterscheidet hierbei Business Requirements auf der einen und IT Requirements auf der anderen Seite.

In den Business Requirements steht beispielsweise ein Bedarf auf einen neuen analytischen monatlichen Kosten Soll/Ist-Report drin. In den IT Requirements stehen dann die entsprechenden Konfigurationsschritte im Embedded Analytics Umfeld von SAP S/4HANA drin, die zur Erfüllung dieses Business Requirements notwendig sind. Diese Konfigurationsschritte können im Solution Manager als Guided Procedure speichern, so dass Sie hier eine gut dokumentierte Schritt-für-Schritt Anleitung bereitstellen können.

So können Sie beispielsweise festlegen, dass vor dem Go-Live auf SAP S/4HANA in dem Sandboxing-System bewiesen worden sein muss, dass alle Business Requirements im Sandbox-System erfolgreich erfüllt werden konnten. Erst, wenn die zugewiesenen Process Owner Ihr OK für das Erfüllen Ihrer Business Requirements gegeben haben, wird live gegangen.

Der Solution Manager bietet Ihnen hierbei entsprechende Tools zur Implementierung eines Validierungsprozesses. Aber auch im laufenden Operating können aus neuen Business- und IT requirements Change Requests erzeugt werden, die genehmigt und im Anschluss in das Produktivsystem überspielt werden können. Sie sehen also: Mit dem SAP Solution Manager 7.2 haben Sie eine gute geschäftsorientierte Verwaltungsbasis für Änderungen an Ihrer Systemlandschaft im Haus.

Mehr Informationen zum SAP Best Practices Content erhalten Sie in den SAP Notes 2246714 und 2226371 (für 1511) bzw. 2328546 und 2328518 (1610).  Die Anpassung des Best Practices Content an Ihre Bedürfnisse über das IMG wird in SAP Note 2272406 behandelt. Zusätzlich könnte für Sie die Installation von Sprachpaketen im Rahmen der Best Practices Implementierung interessant sein (SAP Note 2309549).

Branches unterteilen Ihre System-Landschaft

Neu in der Organisation der Systeme im SAP Solution Manager 7.2 im Vergleich zu den Vorgängerversionen ist das Konzept der System Branches. In der Regel erstellen Sie die folgenden Branches für eine Systemlinie

• Der Import Branch enthält den unveränderten Best-Practices content, der direkt von der SAP kommt. Er repräsentiert also den Inhalt von Trial-Systemen, die den aktivierten Best-Practices Content enthalten
• Im Design Branch  wird der aktivierte Best PracticesCcontent verwertet. In diesem Zweig wird also entschieden, was und wie man etwas im System tun möchte.
• Im Development-Branch sind das DEV- und das Q-System gepflegt. In diesem Zweig baut man die letztendlichen Implementierungen der Ergebnisse aus dem Design-Branch. Diese Implementierungen sind change-controlled, das heißt ein Change- and Request Management (ChaRM) ist hier platziert. Erst wenn die Änderungen freigegeben werden, werden die Änderungen in den Production Branch transportiert
• der Production Branch enthält das P-System und dessen Entwicklungsstand. Änderungen am P-System können nie direkt im P-System selbst durchgeführt werden, sondern müssen entweder über den Development- oder den Maintenance-Branch gehen
• Der Maintenance Branch enthält das DEV- und Q-System. In diesem Branch werden keine Neuentwicklungen implementiert (dafür ist der Development-Branch da), sondern Notfall-Fixes, SAP-Hinweise und Support Packages gegen Probleme im P-System eingespielt. Auch der Maintenance-Branch wird durch ChaRM abgewickelt.
• der Operations Branch enthält die Systeme, die für das Monitoring der Systemlösung zuständig sind.

innerhalb dieser Branches arbeiten Sie mit den Business und IT Requirements, die Sie bereits im Abschnitt „SAP Best Practices Content“ kennengelernt haben. Das heißt innerhalb dieser Branches kümmern Sie sich jetzt nicht mehr nur um den Transport klassischer „SAP-Transportaufträge“, sondern Sie geben beispielsweise auch die Guided Procedures zur Konfiguration von bestimmten Einstellungen im Produktivsystem frei.

Erst wenn die Konfiguration freigegeben wurde, darf der Administrator die Guided Procedure zur Hand nehmen und die entsprechenden Konfigurationsschritte im Produktivsystem durchführen. Aber auch die Geschäftsprozesse können über diese Branches geändert werden. Wenn Sie beispielsweise im Development Branch einen Geschäftsprozess ändern und in diesem Zuge das Prozessdiagramm verändern, kann diese Änderung am Prozess durch das Change Management zum Datum X auf das Produktivsystem angewandt werden.

 

Keeping the Core Clean

Ein zentraler Gedankengang bei der einführung von SAP S/4HANA in der on-premise Edition ist das Dogma „Keeping the core clean“. Damit ist gemeint, dass möglichst viele customer enhancements nicht auf dem eigentlichen SAP S/4HANA System entwickelt werden sollen, sondern auf einem Sidecar-System implementiert und betreiben werden. Das heißt dieses Sidecar-System holt sich die daten über Schnittstellen aus dem eigentlichen SAP S/4HANA System ab und verarbeitet diese daten dann mit hilfe von Reports, die auf diesem System ausgeführt werden.

Dadurch, dass das Coding auf dem Sidecar-System ist und nicht in Ihrem SAP S/4HANA-System, haben Sie mit diesem Coding in der Regel keine Schwierigkeiten bei einem Upgrade. die SAP fördert diesen Gedanken durch die Möglichkeit der CDS-Views. Das heißt auch wenn sich das Datenmodell von SAP S/4HANA einmal ändert, kann auf die alten tabellen und Views immer noch über eine korrespondierende CDS-View zugegriffen werden, so dass wir in den meisten Fällen hier eine Art abwärtskomaptibilität bei einem SAP S/4HANA Releasewechsel erwarten können, auch bei sich änderndem Datenmodell.

Technische Vorbereitungen einer System Conversion

Unicode conversion

Wie bereits weiter oben erwähnt ist die Voraussetzung zur erfolgreichen Durchführung einer SAP S/4HANA System Conversion, dass das Quellsystembereits Unicode ist. Non-Unicode Systeme können nicht migriert werden, daher ist es unbedingt notwendig, ein Non-Unicode System zunächst auf Unicode zu konvertieren. Grundsätzlich empfiehlt die SAP, keine System Conversion durchzuführen, wenn man die System Conversion nicht als One-Sep-Procedure durchführen kann, was im Falle eines Non-Unicode Systems der Fall wäre, da hier vor der eigentlichen System Conversion eine UnicodeCconversion statt finden muss. die SAP empfiehlt in diesem Fall lieber eine Greenfield-Neuimplementierung von S/4HANA und eine anschließende Datenmigration. Das muss aber nicht heißen, dass diese Regel immer befolgt werden muss.

In diesem Zusammenhang macht es vielleicht Sinn, als Zwischenschritt mit Hilfe der Database Migration Option des Software Update Managers (SUM) zur System Conversion auf Business Suite on HANA oder sogar S/4HANA Finance zu gehen, da eine Unicode Conversion bereits während der DMO stattfinden kann und sich durch diesen Zwischenschritt das Datenvolumen des Quellsytems durch das neue Datenmodell für die spätere System Conversion deutlich reduziert.

Installation von Solution Manager 7.2

Der Solution Manager 7.2 wird in einem SAP S/4HANA Einführungsprojekt eine zentrale Rolle spielen, wie wir bereits weiter oben erläutert haben. Daher sollten Sie vor der System Conversion frühzeitig mit der Einführung von SolMan 7.2 beginnen. Hierbei ist es vorteilhaft für Ihr Konvertierungsprojekt, wenn Sie folgende Szenarien des Solution Maangers 7.2 implementieren, bevor ihr SAP S/4HANA Proejkt beginnt.

• Data Volume Management (DVM)
• Custom Code Lifecycle Management
• Change and Request Management (ChaRM)
• Test Management
• Einspielen des aktuellen Contents für das SLD
• Neu-Anbindung all Ihrer Systeme an das SLD, die LMDB und den Maintenance Planner (bzw. das SAP Help Portal).
• Analyse der Ausführungshäufigkeit ihres customer Codings über das usage Procedure Log (UPL)
• Implementierung der Landscape Transformation Platform, wenn Sie nach der system Conversion die Daten von anderen Quellsystemen nach SAPS/4HANA migrieren wollen.

Studieren der Simplification List

die Simplification List enthält viele wichtige Punkte, die erfüllt sein müssen, um eine erfoglreiche System Conversion durchführen zu können. So finden Sie etwa in der aktuellen Simplification List zum Initial Shipment Stack von SAP S/4HANA Enterprise Management 1610, dass Sie in SAP S/4HANA zwingend den sogenannten Business Partner Approach realisiert haben müssen.

Das heißt dass die Entität „Business Partner“ der zentrale Verwaltungspunkt für die Pflege der Entitäten customer, partners und vendors ist.Ssolange der Business Partner Approach im Quellsystem nicht realisiert ist, wird die System Conversion nicht funktionieren. Deshalb müssen Sie hier beispieslweise im Quellsystem in der SFW5 die Business Functions CA_SUPPLIER_SOA, CA_BP_SOA/ ‘VENDOR_SFWS_SC1’ und CA_BP_SOA/‘VENDOR_SFWS_SC2’ aktivieren und im Anschluss diverse Konfigurationsschritte durchführen.

Ein wichtiger Anhaltspunkt ist die sogenannte Simplification List sowie die Liste der Top Simplification List Items. Einige der Simplification Items können auf Wunsch erst im Nachhinein oder im Laufe der System conversion implementiert werden, doch viele müssen vorbereitet sein. Durchschnittlich müssen bei einem System Conversion Objekt 30-40 Ssimplification Items berücksichtigt werden.

Studieren der länderspezifischen Restriction Lists

Es gibt einige Restriktionen für die Funktionalität von SAP S/4HANA in bestimmten Regionen. Mit diesen Restriktionen sollten Sie sich frühzeitig vertraut machen. Konsultieren Sie hierzu SAP Note 2228890.

Prüfen der Softwarekomponenten und Deinstallation von Addons

Wie Sie weiter oben bereits erfahren haben, werden mit SAP S/4HANA bestimmte Softwarekomponenten in die Softwarekomponente S4CORE integriert. Dies bedeutet, dass das Quellsystem, welches Sie durch eine System Conversion ggf. auf SAP S/4HANA aktualisieren wollen, evtl. von Addons befreit werden muss, die Sie vorher deinstallieren müssen. Addons, die grundsätzlich nicht deinstalliert werden können, müssen durch entsprechende SAP Hinweise auf die System Conversion vorbereitet werden.

Reduktion des Datenvolumens

Bevor Sie eine System Conversion durchführen, sollten Sie das Datenvolumen Ihres Quellsystems so stark reduzieren wie möglich. Dies erzielen Sie zum einen durch die Archivierung von Altdaten und zum Anderen durch die Verbesserung der Datenqualität. SAP empfiehlt SAP Data Volume Management des SAP Solution Managers zu nutzen.

Das Data Volume Management das SAP Solution Managers stellt sicher, dass die archivierten Daten aus dem Legacy Quellsystem unter SAP S/4HANA immer noch erreichbar sind, obwohl sich das Datenmodell unter SAP S/4HANA ändert.  Wenn sie im Zielrelease SAP S/4HANA auf ein Datenarchiv zugreifen, welches noch unter dem alten Datenmodell erstellt wurde, konvertiert das Data Volume Management das Archiv zum Zeitpunkt des Zugriffs on-the-fly, so dass SAP S/4HANA das Archiv lesen und darstellen kann.

Zusätzlich reduzieren Sie das Datenvolumen, indem Sie beispielsweise  die System Conversion in Zwischenschritten angehen. Upgraden Sie beispielsweise Ihr SAP ERP-System in einem Zwischenschritt auf SAP Simple Finance bzw. SAP S/4HANA Finance, reduzieren Sie die Datengröße Ihres Systems für die finale System Conversion auf SAP S/4HANA enteprrise Management enorm, da viele redundante Daten im neuen Datenmodell weg fallen.

Customer Code Checks

Wenn Sie eine System Conversion eines SAP ERP-Systems durchführen wollen, müssen grundsätzlich drei verschiedene Coding-Checks durchführen

• Obsoletes ABAP-Coding gemäß den Ergebnissen der Checks aus dem Usage Procedure Log (UPL) entfernen
• SAP HANA-relevante Änderungen beachten wie etwa das Wegfallen der ORDER BY-Klausel. Dieser check ist nur notwendig, wenn Ihr ERP-System noch nicht auf SAP HANA läuft, sondern noch auf AnyDB. diese checks führen Sie in der Regel direkt auf dem ERP-System in der Transaktion SCI durch.

Legen Sie hier ein neues Object Set mit beliebigem Namen an und wählen sie in den Packages alle Pakete die mit Z* und Y* starten sowie die Pakete unter $TMP. Speichern Sie das Object Set. Legen Sie nun eine neue Inspection an mit einem beliebigen Namen. Wählen Sie das zuvor festgelegte Object Set aus und wählen Sie eine Check Varaint an. FUNCTIONAL_DB ist hier die richtige Variante. Führen Sie die Inspektion aus. Prüfen Sie die Resultate. Legen Sie nun eine weitere Inspection an. Wählen Sie wieder das selbe Object Set aus, diesmal allerdigns die Check Variante FUNCTIONAL_DB_ADDITION. Führen Sie nun auch diese Inspektion aus.

• SAP S/4HANA spezifische Coding Checks. Diese prüfen etwa, ob ihr ABAP-coding auf dem Quellsystem auch im S/4HANA Zielrelease noch funktionieren wird, oder ob es Probleme mit dem neuen Datenmodell geben wird.

Wichtige Tools für Ihre Customer Code Checks sind

• das Usage Proceudre Log (UPL) des solution Manager 7.2
• Der ABAP Code Inspector
• Das ABAP Test Cockpit (ATC)
• Ihr unternehmensinternes Custom Code Lifecycle Management (Solution Manager)
• die Custom Code Migration worklist
• Der Custom Code Guide der SAP.

Für die Durchführung aller Coding checks brauchen Sie folgende Systeme

• das eigentliche Quellsystem
• ein SAP Netweaver AS ABAP 7.50 System oder neuer (sofern Ihr quellsystem noch nicht auf NW 7.50 ist)
• SAP solution Manager 7.2

Auslagerung von Coding und anderen Customer Enhancements auf ein Sidecar-System

Im Zusammenhang mit der Keeping the Core clean Philosophie macht es Sinn, darüber nachzudenken, möglichst viele Bestandteile Ihrer customer Enhancements im Quellsystem bereits vor der system Conversion auf ein Sidecar-system auszulagern. So halten Sie Ihren S/4HANA Core möglichst frei von Customer Enhancements.

Landscape Transformation only: Analyse Ihrer Daten mit dem Transformation & analysis Framework und Studieren der Service Map.

Wenn Sie zusätzlich zur System conversion vor haben, Daten aus weiteren Quellsystemen mit in die SAP S/4HANA Welt zu migrieren, also die System Conversion mit einer Landscape Transformation kombinieren, dann sollten Sie bereits in den übrigen Quellsystemen die Daten mit dem sogenannten Transformation & Analysis Framework analysieren. Dazu spielen Sie auf den Quellsystemen das aktuelle DMIS Addon ein, welches die Client-Komponente für den SAP LT Replication Server darstellt. In diesem Addon ist das Framework enthalten. Mit dem Framework prüfen Sie Ihre Daten auf Redundanz und Datenqualität.

Zusätzlich bietet die SAP eine Service Map für das von Ihnen gewünschte Landscape Transformation Szenario an, welches Sie studieren sollten. Vergessen Sie außerdem nicht, dass bei jedem Landscape Transformation Projekt der SAP Support involviert sein muss, weshalb Sie daran denken sollte, diesen frühzeitig einzuschalten.

Download & Upload des Custom Object Repositorys und der Simplification DB

In diesem Schritt laden Sie vom SAP ERP Quellsystem das Custom Object Repository herunter und die SAP S/4HANA Simplification Database herunter, um mit Hilfe dieser Inhalte  eine Custom Code Migration Work List zu erzeugen. Sie laden dann die Simplification Database auf ein SAP NetWeaver 7.50 Evaluation System hoch und generieren die Custom Code Variante. Auf dieses System laden Sie dann auch das Custom Object Repository aus dem Quellsystem zur Evaluierung hoch. Im Anschluss daran führen Sie einen Report auf dem SAP NW 7.50 System durch um das Custom Code Repository zu analysieren.

Um das Repository aus dem Quellsystem herunterzuladen gehen Sie dort in die Transaktion SE38 und führen Sie das Programm „SYCM_DOWNLOAD_REPOSITORY_INFO“ aus. Im Feld Customer Namespace wählen Sie den Kundennamensraum aus, den Sie analysieren wollen. Der standardmäßig festgelegte Kundennamensraum  /0CUST/ repräsentiert alle Objekte, die mit Z* oder Y* starten. Sofern das alle kundeneigenenen Objekte einschließt, können Sie den Report so ausführen und das .zip-File auf Ihren Arbeitsplatz herunterladen.

Nun laden sie die Simplification DB herunter. der Download-Name, nach dem Sie im SWDC suchen können, lautet „CCMSIDB 1.0“. Laden Sie die .zip-Datei herunter.

Begeben Sie sich nun auf das NW 7.50 System und führen dort in der TX SE38 den Report SYCM_UPLOAD_SIMPLIFIC_INFO aus. Laden Sie hier die .zip-Datei der  Simplification DB CCMISDB hoch. Warten Sie bis der Report abgeschlossen ist. Führen Sie nun den Report SYCM_UPLOAD_REPOSITORY_INFO aus. Laden Sie die .zip-Datei Ihres custom Object Repositorys hoch. Vergeben Sie im Folgefenster einen Resultatsnamen für die Analyse und führen Sie die Analyse aus.

Gehen sie nun in die Transkation SYCM und geben Sie den Resultatsnamen Ihres Systems im Feld Analysis Result Name an. Klicken sie ffu den Button Show Analysis Overview. Sie sehen nun eine Liste der Elemente die vom Check als relevant markiert wurden. Gehen Sie zurück und klicken sie diesmal auf den Button Show Worklist. Dies zeigt Ihnen im Detail alle Objekte die von der S/4HANA-Migration beeinflusst werden.

Gehen Sie nun wieder in die Transaktion SYCM und gehen sie auf Custom Code Worklist – Import Simplification Database. Wählen Sie wieder die .ZIP-Datei der CCMISDB aus und klicken Sie auf Allow. Daraufhin wird die Simplification Database eingespielt. Eventuell werden Sie dazu aufgefordert, SAP Hinweise einzuspielen, die Sie in der Transaktion SNOTE implementieren sollten, damit die Analyse sauber funktioniert.

Gehen Sie nun in SYCM auf Custom Code Worklist -> Display Simplification Database Content. Lassen Sie im Folgefenster alle Felder leer und führen Sie den Report aus.

SAP Activate als Managment-Framework für SAP S/4HANA Einführungsprojekte

SAP Activate ist ein Management-Framework, welches aus mehreren sogenannten Building Blocks besteht. Diese sollen einen Leitfaden geben, wann der Kunde sich mit welchen Arbeitspaketen während der Einführung von SAP S/4HANA beschäftigen sollte.

So beschäftigt man sich zunächst mit den weiter oben bereits angeschnittenen Themen, etwa der Auswahl eines Adopter Programs, einer Deployment Option und eines Einführungspfades. Zusätzlich sollte man, um SAP S/4HANA als Lösung zu evaluieren, den SAP Best Practices Content nutzen, um sich die Lösung in der Evaluierungsphase in einem realitätsnahen Szenario ansehen zu können. Der zentrale Einstiegspunkt für die SAP Best Practices ist der SAP Best Practices Explorer.

Sie finden im Best Practices Explorer Migration und Integration Content für verschiedene Standard-Anwendungsszenarien. Man kann diesen Content in etwa mit dem IDES-Content aus der damaligen ECC 6-Welt vergleichen. Das heißt Sie bekommen mit diesem Content ein vorkonfiguriertes System mit Dummy-Daten, um sich die Arbeit mit SAP S/4HANA in Ruhe ansehen zu können.

Sie können sich sogar einen von SAP vorgefertigten Projektplan herunterladen. Gehen Sie dazu auf go.support.sap.com/roadmapviewer, wählen Sie die Kachel „Solution Specific“ und dann „Transtition to SAP S/4HANA“. Dort finden Sie dann einen Link „Projektplan herunterladen“, wie die Abbildung unten zeigt.

Den Projektplan können Sie dann entweder im .xml-Format in den SAP Solution Manager importieren oder alternativ mit Microsoft Project öffnen.

Typische Projektzeitplanung für eine SAP S/4HANA System Conversion

Wenn wir davon ausgehen, dass Sie SAP S/4HANA bereits evaluiert und ausprobiert haben (und sich logischerweise für das Produkt entschieden haben), die technischen Vorbereitungen durchgeführt haben und sich bereits für die strategischen Rahmenbedingungen wie etwa ein Adopter Program und eine Deployment Option entschieden haben, dann ist ein guter Zeitrahmen für die System Conversion in der Regel wie folgt.

• Sie haben zunächst eine Sandboxing-Phase, in welcher Sie den Business Impact der System Conversion auf Ihr System austesten. Diese Phase dauert erfahrungsgemäß bei vielen Kunden um die 6 Wochen. Bereits hier versuchen Sie, den Migration Speed der System Conversion so gut wie möglich zu optimieren. Ziel ist ein Migration Speed von mindestens 500 GB/h.In diesem Zeitplan geht man davon aus, dass Sie bereits einen SAP Solution Manager 7.2 installiert und Ihr Coding seit längerer Zeit mit dem Usage Procedure Log (UPL) des SolMan 7.2 analysiert haben.

  Bitte verwechseln Sie diese System Conversion Sandbox nicht mit der SAP S/4HANA Sanbdox im Zielrelease, die Sie beispielsweise in der SAP CAL zur Verfügung gestellt bekommen. Die SAP S/4HANA Sandbox, die sich bereits im Zielrelease befindet, ist zum Sandboxing von Entwicklungen und Geschäftsprozessen vorgesehen.

• Sie führen die System Conversion auf dem Entwicklungssystem durch. Nach dieser System Conversion entwerfen Sie außerdem die sogenannte Conversion Blueprint, in welcher Sie versuchen, auf Basis der Laufzeiten aus der Sandbox-Phase und den Erkenntnissen im Postprocessing in den Entwicklungen eine Cutover-Liste mit den Laufzeiten und Tätigkeiten der Business Owner zu erstellen.Zusätzlich werden hier bereits die ersten Tests gefahren, um kritische Fehler im neuen Release möglichst frühzeitig zu erkennen und zu beheben. Diese Phase dauert in der Regel 10 Wochen.
• Sie führen die System Conversion des Q-Systems durch. Hier können Sie versuchen, die Business Downtime noch weiter zu reduzieren. Dies ist die Generalprobe für Ihren Go-Live, in der Sie möglichst nahe bestimmen sollten, wie lange Ihre Business Downtime sein wird.Gleichzeitig ist dies die wichtigste Testphase, in der es darum geht, sicher zu stellen, dass die geschäftskritischen Prozesse im neuen Release funktionieren und die User das neue System akzeptieren. Für diesen Zeitraum sollten Sie in der Regel noch einmal 5 Wochen einplanen, sofern es Ihnen gelungen ist, bereits in der letzten Phase viele der Fehler im neuen Release zu beheben.
• Als heiße Phase kommt nun der Go-Live. Hier sollten Sie zur Vorbereitung aller Schritte bis vor der Downtime 3 Tage exklusive 1 Tag Puffer einplanen. Danach kommt die Downtime, deren Länge selbstverständlich vom Datenvolumen Ihres Systems abhängig ist. In meinem Beispiel hat die Business Downtime (nicht zu verwechseln mit der technischen Downtime) aufgrund der enormen Größe des Systems trotz Migration Speed von 800 GB/h 40 Stunden gedauert.
• Nach dem Go-Live haben Sie in der Regel noch etwas Systempflege zu betreiben. Hierfür sollten Sie 3 Wochen einplanen, in welcher zwar die geschäftskritischen Prozesse bereits laufen sollten, jedoch noch Auffälligkeiten für Prozesse aufkommen werden, die vorher niemand getestet hat (meistens technische Transaktionen die keine betriebswirtschaftliche Relevanz haben) und für die Neuheiten in Punkto Business Intelligence.

Eine gute dokumentarische Grundlage zur Einführung von SAP S/4HANA ist das Cookbook. Desweiteren müssen Sie die weiter oben bereits erwähnte Simplification List durchgehen, um festzustellen, wie viele Simplification Items Ihr Projekt beeinflussen. Dies hilft bei der Einschätzung, wie umfangreich Ihr Einführungsprojekt sein wird. So wird es beispielsweise sehr aufwendig sein, die Customer/Vendor und Business-Partner Integration durchzuführen, wenn die Stammdaten für viele Jahre nicht archiviert worden sind.

Datenmigration nach SAP S/4HANA

eine Datenmigration nach SAP S/4HANA wird verwendet, wenn Sie sich für die Ladnscape Transformation Roadmap nach SAP S/4HANA entschieden haben. hiebrei können Sie verschiedene Ziele haben.

• Sie wollen aus  einem oder merheren SAP-Quellsytemen bestimmte einzelne business entities in das SAP S/4HANA Zielsystem replizieren. das heißt sie haben kein Interesse daran, einen kompletten Mandanten oder einen kompletten Company Code zu migrieren.SAP hat hierzu einige business entities wie beispielsweise eine Purchase Order oder einen Business Partner vordefiniert. Sie können SAP Note 50130953 konsultieren, wenn Sie vordefinierte Business Objects nach SAP S/4HANA Cloud Edition migrieren wollen, und SAP Note 5131848, wenn Sie Business Entities nach SAP S/4HANA on-premise migrieren wollen.
• Sie wollen zwei oder mehrere Mandanten unterschiedlicher ERP Quellsysteme in einen einzelnen SAP S/4HANA Mandanten zusammenführen (Client Merge)
• Sie wollen einen kompletten einzelnen Mandanten mit seinen gesamten daten (customizing, Stammdaten und transaktionalen Daten) in einen SAP S/4HANA Mandanten überführen
• sie wollen einen kompletten company code inkl. custpmizing und Stammdaten von einem ERP System in einen SAP S/4HANA Mandanten importieren
• Sie wollen einen kompletten Company Code inkl. customizing, Stammdaten und transaktioneln Daten von eniem ERP quellsystem in einen SAP S/4HANA Client importieren.
• sie wollen die Finanzdaten mehrerer SAP-ERP-Systeme in ein SAP S/4HANA (Finance) System zusammenführen, um ein Central Finance System aufzubauen.
• sie wollen einzelne business entities aus Non-SAP-Systemen in SAP S/4HANA migrieren.

Das SAP S/4HANA Migration Cockpit (MC) ist ein Migrationstool innerhalb von SAP S/4HANA, aber auch Bestandteil des DMIS 2011 Addons und kann somit sowohl auf dem SAP S/4HANA Zielsystem als auch auf einem zentralen System wie dem SAP Solution Maanger genutzt werden, um Daten zu migrieren.

Das Migration Cockpit ist als Fiori-App innerhalb des Implementation Cockpits verfügbar. In diesem Cockpit erstellen Sie ein Migration Project. Dort erfassen Sie zunächst alle Objekte von Legacy SAP-Systemen und non-SAP-Systemen, die Sie migrieren müssen, und definieren für diese Objekte Transformationsregeln. Für SAP-Objekte liefert SAP bereits vorgefertigte Templates, die angeben, welche Datenstruktur das Zielsystem SAP S/4HANA für ein bestimmtes Objekt erwartet.

So werden Ihnen die feldnamen, der Datentyp, die feldlänge, die Decimal-Eigenschaft (bei Dezimalzahlen) usw. angezeigt. Somit wissen Sie, auf welches Zielformat Sie die Daten aus den Quellsystemen transformieren müssen. Hierbei gilt es zu erwähnen, dass diese Templates nur die nötigsten Datenfelder aufzählen, die SAP S/4HANA braucht, um mit den Daten weiterarbeiten zu können. So braucht etwa das Migration Object BANK_MASTER nur 10 Datenfelder, hat jedoch in einem SAP-Standardsystems über 300 Datenfelder in der Datenbank.

In dem Migration cockpit können Sie für jedes Migration Object .xml- bzw. Flat File-basierte Datenmigration durchführen. Das heißt Sei können die Daten aus dem Quellsystem vorab als Datei hochladen und dann zum Stichtag X in das System in einem geführten Wizard importieren. Hierbei werden die Daten bereits vor dem Import validiert, so dass das System eventuelle Fehler in der Datenstruktur signalisiert, die vom Zielsystem nicht  verarbeitet werden können.

Der SAP S/4HANA migraton Object modeler (MOM) ist ein Design Tool für die Definition von Erweiterungen und modifikationen an vordefinierten Migrationsobjekten für SAP S/4HANA on-premise (die Cloud Edition enthält dieses tool also nicht).  Sie können somit beispielsweise zu einem Migration Object mehr Felder hinzufügen, als vom Migration Cockpit für ein bestimmtes Migration Object vorgesehen sind, und können somit mehr Logik in Ihr Zielsystem importieren. Dazu fügen Sie beispielsweise Felder hinzu, die sie zusätzlich vom quellsystem migrieren wollen, und mappen das Feld in der Quell-Tabelle zu einem ziel-Feld in der SAP S/4HANA-Tabelle.

die Funktionalitäten vom SAP Migration Cockpit (MC) und demMigration boject modeler (MOM) haben jedoch einen Nachteil: Es handelt sich hier immer nur eine file-basierte datenmigration. das heißt Sie müssen für jedes migration Object einzeln Flat Files erzeugen, diese hochladen und danach geführt über eine Browseroberfläche importieren. Das braucht natürlich Zeit.

die SAP Data Services  (DS)sidn ein extra installierbares Tool und stehen nur für SAP S/4HANA on-premise zur Verfügung (also nicht für die Cloud) und haben im Vergleich zur dateibasierten  Migration über das Migration Cockpit einige Vorteile. Das Tool hat volle ETL-Fähigkeiten. Während Sie sich also beim migration cockpit noch selbst um die Extraktion der Datena us dem Quellsystem kümmern müsse (etwa über Funktionalitäten in der darunterliegenden Datenbank)n, kann das SAP Data services Tool die Extraktion für die unterstützten Datenbankpalttformen für Sie übernemen.

Zum einen bieten die SAP Data Services eine Funktion zum Data Cleansing an. So ist es beispielsweise möglich, den Inhalt eines  „Namen“-Feldes in der Tabelle des Quellsystems  im Zielsystem SAP S/4HANA aufzusplitten in ein „Vorname“ und „Nachname“ Feld. Außerdem können automatisch Schreibfehler, wie etwa kleingeschriebene Ortsnamen, korrigiert werden. So wird mit den SAP Data Services aus einem „köln“ ein „Köln“ oder aus einem „Beerlin“ ein „Berlin“.

Desweiteren können Sie Duplikate erkennen und synchronisieren. Wenn es beispielsweise einen Datensatz für „Josef Mayer“ und „Sepp Mayer“ im System gibt, können Sie die erkannten Duplikate prüfen und die Datena us den beiden Datensätzen in eienn einzigen zusammenführen. Desweiteren können Sie die Daten vor der Migration mit neuen informationen anreichern. Haben Sie in einer Datenbank eine tabelle mit den Daten zu einem Kunden und in einer anderen Datenbank die Daten zu den zugehörigen geografischen Daten bestehend aus Längen- und Breitengrad, können Sie diese Daten aus den zwei fremden Tabellen zusammenführen.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!