Referenzen

Projektdauer:

Weitere Projekte:

Im Jahr 2016 hat die Unternehmensgruppe Moritz J. Weig GmbH & Co. KG, ihrer IT-Strategie folgend, die weltweiten Aktivitäten auf eine IT-Plattform migriert - und damit eine Konvertierung (System Conversion) realisiert.

In einer Reihe von Referenzanfragen wurden ähnliche Fragenstellungen häufig diskutiert. Da wir mit der Unternehmensgruppe WEIG weltweit die dritte S/4 System Conversion im Release 1511 und weltweit die erste produktive 1610 Applikation betrieben haben, habe ich die gemachten Erfahrungen und meine Meinung zu diesem Themenkomplex zusammengeschrieben. Für interessierte S/4-Anwender oder solche, die es noch werden wollen, können die Hinweise sinnvoll sein.

Ausgangslage war eine zerklüftete IT-Landschaft: vier ERP-Systeme auf zwei Kontinenten im Unternehmensverbund in Europa und Südamerika, darunter ein SAP R/3 im aktuellen Release, ein klassisches SAP BI, ein SAP SRM sowie drei weitere ERP-Fremdsysteme.

Im Jahr 2014 wurde eine IT-Strategie als Bestandteil der Unternehmensstrategie 2020 entworfen, die den Wandel eines klassischen, mittelständischen, industriellen Produktionsunternehmen hin zum industriellen Dienstleister und "production provider" aufzeigt. Die Folge war nun eine Neuausrichtung der IT hin zur einer Plattformtechnologie, die die erforderliche Flexibilität der Märkte, Kunden und Produkte mit individueller Konfigurierbarkeit sowie mit flexibler Skalierbarkeit realisierbar macht. Kernstück unseres Weges bildet die SAP S/4HANA Plattformtechnologie.

Erste Grundsatzentscheidung: es werden Prozesse standardisiert in das SAP S/4HANA überführt - kein Greenfield-Ansatz. Hintergrund ist die fachliche und funktionale Nähe der SAP S/4HANA-Welt zur alten R/3-Welt. Das Rad bzgl. der S/4-Applikationen wurde nicht neu erfunden, es wurden viele Themengebiete vereinfacht aber eben nicht gänzlich neu entwickelt - es wurde die "Lauffähigkeit der Applikationen" sichergestellt. Auch im S/4HANA wird "nur mit Wasser gekocht" und der Umstellungsprozess innerhalb der SAP wird noch sehr viel Ressourceneinsatz und Zeit bei der SAP benötigen. Es gibt einige neue Applikationen, wie z.B. das New Cash Management oder neue Technologien, wie z.B. Fiori-APPs. Daneben gibt es Aufgabenstellungen, wie die Zusammenführung der Geschäftspartner oder das neue Hauptbuch, die beachtet werden sollten. Diese Themen sind aber bereits im aktuellen R/3-Release vorhanden und können vor der eigentlichen System Conversion im R/3 umgestellt werden.

Der Vorteil der Vorgehensweise: die Tools zur System Conversion sind sehr gut, sehr sicher und auch recht schnell. Damit können Daten ohne größere Probleme aus dem Altsystem in die neue Datenbank migriert werden. Die Vereinfachung im Datenmodell wird von SAP sehr gut, schnell und weitestgehend fehlerfrei unterstützt. Eine vorgezogene Umstellung von Geschäftspartner etc. entspannt das eigentliche Migrationsprojekt und verlagert erhebliche fachliche Aufgabenstellungen im Vorfeld der Projekte in die Fachabteilungen.

Das sind die positiven Aspekte. Weniger schön ist, dass die Prozessvereinfachungen mit der System Conversion nur bedingt unterstützt werden. Wer zum Beispiel das New Cash Management einsetzen möchte, wird erkennen, dass IT-technisch die Daten zwar richtig auf der neuen Datenbank ankommen, die Applikation aber leider "optimale" Datensätze voraussetzt. Was "optimal" bedeutet ist leider selbst der SAP und deren Beratern nicht immer bekannt. Die neuen Applikationen erwarten Datensätze, wie sie mit der neuen Applikation erzeugt werden - die System Conversion passt leider die alten Datensätze nicht immer den neuen Bedürfnissen an. Gut, wenn es dann, um in unserem Beispiel zu bleiben, noch eine Liquiditätsplanung im BI gibt.

Das Gute am aktuellen Portfolio an SAP-Standard-APPs ist, dass man S/4HANA ganz entspannt auch mit dem GUI bedienen kann. Das vereinfacht die Umstellung in den Fachbereichen sehr. Die Anwender arbeiten quasi in der gewohnten Umgebung. Es ist von Vorteil, dass die Fiori-APPs dann von Fachbereich zu Fachbereich, Stück für Stück entwickelt, installiert und produktiv gesetzt werden können. Es können so wesentliche Projektinhalte nach der eigentlichen System Conversion zeitlich entzerrt in die Produktion überführt werden.

Wir haben unsere Prozesslandschaft in Prozesskettenanteile aufgetrennt und diese Anteile dann als APP (über transaktionale Grenzen hinweg und inkl. der erforderlichen Analytik) entwickelt. Die Zusammensetzung der APPs bilden unsere Prozesse ganzheitlich ab, die aber individuell zusammengesetzt werden können. So bildet sich am Ende ein Baukasten aus APPs, die wie ein Getriebe aus Zahnrädern ineinandergreifen. Wir begegnen der Flexibilität der Märkte, Kunden und Produkte mit der individuellen Konfigurierbarkeit der APPs.

Kritisch bei diesem strategischen Ansatz: die Entwicklung der Fiori-APPs. Das Design mittels Design Thinking Workshops bis zur Realisierung ist ressourcen-, zeit- und kostenintensiv - für Unternehmen aus dem Mittelstand ist es meistens auch eine neue Erfahrung Applikationsentwicklung in dieser Intensität zu betreiben.

Ziel der System Conversion ist somit zu aller erst der Sprung auf eine Plattformtechnologie - auf die SAP S/4HANA-Plattform. Mehrwerte werden in weiteren Teilprojekten Schritt für Schritt realisiert. Die System Conversion ist somit nur ein Projekt innerhalb der Umstellung auf die S/4-Plattformtechnologie.

Ein weiteres kritisches Thema ist die Performance der SAP-Applikation. SAP bewirbt die In-Memory-DB HANA. Man könnte glauben, "alle Daten immer im Hauptspeicher" zu haben, schafft eine tolle Performance. Beim Lesen auf der Datenbank hat man wirklich seinen Spaß, wenn man denn größere Datenmengen auswertet. Die transaktionale Welt liest aber meist nur sehr begrenzte Datenmengen aus und schreibt auch nur sehr begrenzte Datenmengen zurück. Mir ist nicht klar, ob man bei dem zuvor beschriebenen Auslesen und Zurückmelden von nur geringen Datenmengen eine positive Wirkung messen kann, sehen kann man diesen Performancegewinn nicht.

Da SAP die meisten Datenbankzugriffe der altbekannten Applikationen (FI, CO, MM, PM, SD etc.) nur über eine "Übersetzungsschicht" realisiert hat - die meist nur die Lauffähigkeit der Applikationen sichergestellt hat - sind diese Applikationsanteile eher etwas langsamer als schneller geworden. Überall dort, wo direkt und "richtig" auf die Datenbank zugegriffen wird, sind die Analysen deutlich schneller als früher. Die eigenentwickelten alten Analysen werden nicht schneller, sondern eher langsamer. Neue Eigenentwicklungen können natürlich erheblich von den technologischen Möglichkeiten profitieren.

Wenn man den Mehrwert von S/4HANA richtig heben möchte, kommt man nicht umher die transaktionale Welt mit analytischen Ergebnissen anzureichern. Wir wollen ja besser und an Kennzahlen orientiert arbeiten und bei Entscheidungen früher die Wirkung erkennen. Wir wollen im operativen Handeln Simulationsverfahren den Anwendern zur Verfügung stellen. Dazu müssen die benötigten operativen Analysen aus dem BI wieder in die eigentliche S/4-Installation verlagert werden. Diese sind nur aufgrund der mangelhaften Performance aus dem R/3 ins BI verlagert worden. Dieses Rad wird jetzt wieder zurückgedreht. Vorteil: nichts muss im ersten Schritt vollständig umgesetzt werden. Aber der Investitionsschutz der Zukunft gebietet, jetzt alles Neue direkt im S/4HANA zu realisieren und operative BI-Entwicklungen Stück für Stück in das S/4HANA zu verlagern.

Grundsätzliches zur Projektvorgehensweise: ich freue mich sehr, dass wir nun agile Entwicklungsansätze in SAP S/4HANA-Projekten anwenden. Bedeutet konkret, dass wir sehr stark an Prototypen orientiert mit dem Fachbereich das System diskutieren und ausprägen. Es wird in Iterationsstufen eine produktive Lösung erarbeitet und ausgetestet. Durch die frühzeitige Einbindung des Fachbereichs verschlankt sich die Dokumentation eines vorgelagerten Blueprints erheblich, wie sich auch der Schulungsaufwand bei der Inbetriebnahme der Systemlandschaft erheblich reduziert. Durch diese Art der Vorgehensweise wird die Lösung für den Fachbereich verständlich, nachvollziehbar und transparent. 

Ich werde häufige gefragt, ob ich diesen Weg wieder gehen würde und was ich anders machen würde. Auch hierauf möchte ich kurz eingehen: Bei aller Kritik, die man zwischen den Zeilen lesen kann, bin ich fest davon überzeugt, dass der Weg in die SAP S/4HANA-Plattformtechnologie gerade für den Mittelstand ein richtiger Schritt ist, auch heute schon. Im Sinne des Schutzes der Investition in die heutigen IT-Landschaften kann der Weg in die Cloud in den beschriebenen Fachbereichen besser heute als morgen stattfinden. Ich sehe keinen Mehrwert in der Individualisierung der Prozesse in Fachbereichen wie Einkauf, Finanzbuchhaltung oder Personal. Es macht mehr Sinn, dass diese Applikationsbestandteile in eine Cloud verlagert werden und das hierdurch eingesparte Kapital in Funktionen und Prozesse zu investieren, die das Unternehmen am Markt differenzieren.

Die Projekte werden in den Realisierungsphasen deutlich kürzer. Die Projektvorbereitung, eine Evaluierung dessen, was man wie und wann machen möchte, ist dafür zwingend erforderlich und nimmt meiner Meinung nach deutlich mehr Zeit als die eigentliche Projektrealisierung in Anspruch. Es ist mehr als die Kaufentscheidung zu einer Hardware, sondern der Entwurf einer verteilten Systemlandschaft.

Bedeutet in der Konsequenz: bevor eine Systementscheidung bzgl. des Weges zum Systemaufbau SAP S/4HANA getroffen wird, muss die Systemarchitektur durchdacht und festgelegt werden.

Zum eigentlichen S/4-Projekt zurück: Ziel einer S/4-Einführung ist nicht der zeitgemäße Austausch einer R/3-Applikation, sondern die Art und Weise der Arbeit in den Fachbereichen zu vereinfachen. Ziel ist die transaktionale und die analytische Welt grundlegend miteinander zu verknüpfen. Dazu bedarf es APPs - im SAP-Kontext Fiori-APPs. Zwar gibt es bereits eine große Auswahl an APPs in der SAP-Bibliothek aber es ist sehr wenig Verwertbares im Hinblick auf Verbindung transaktionaler und analytischer Funktionen dabei. Folglich beginnt man eigene APPs zu entwickeln. Ich finde das gut: wenn schon die standardisierten Applikationen in eine Cloud abwandern, kommt die Individualität, der Wettbewerbsvorteil durch Prozess-KnowHow in den wertschöpfenden Tätigkeiten der Unternehmen über die eigenen APPs wieder zum Vorschein.

Hier ist meiner Meinung nach die größte Baustelle für die SAP. Die Lösung muss an diesem Anspruch gemessen werden: Es gilt mit einem Wechsel auf die SAP S/4HANA-Plattform einen Mehrwert zu generieren, nicht nur ein wenig schneller zu werden, sondern inhaltlich besser zu werden.

Das Gute am aktuellen Portfolio an SAP-Standard-APPs ist, dass man S/4HANA ganz entspannt auch mit dem GUI bedienen kann. Das vereinfacht die Umstellung in den Fachbereichen sehr. Die Anwender arbeiten quasi in der gewohnten Umgebung. Es ist von Vorteil, dass die Fiori-APPs dann von Fachbereich zu Fachbereich, Stück für Stück entwickelt, installiert und produktiv gesetzt werden können. Es können so wesentliche Projektinhalte nach der eigentlichen System Conversion zeitlich entzerrt in die Produktion überführt werden.

Wir haben unsere Prozesslandschaft in Prozesskettenanteile aufgetrennt und diese Anteile dann als APP (über transaktionale Grenzen hinweg und inkl. der erforderlichen Analytik) entwickelt. Die Zusammensetzung der APPs bilden unsere Prozesse ganzheitlich ab, die aber individuell zusammengesetzt werden können. So bildet sich am Ende ein Baukasten aus APPs, die wie ein Getriebe aus Zahnrädern ineinandergreifen. Wir begegnen der Flexibilität der Märkte, Kunden und Produkte mit der individuellen Konfigurierbarkeit der APPs.

Kritisch bei diesem strategischen Ansatz: die Entwicklung der Fiori-APPs. Das Design mittels Design Thinking Workshops bis zur Realisierung ist ressourcen-, zeit- und kostenintensiv - für Unternehmen aus dem Mittelstand ist es meistens auch eine neue Erfahrung Applikationsentwicklung in dieser Intensität zu betreiben.

Ziel der System Conversion ist somit zu aller erst der Sprung auf eine Plattformtechnologie - auf die SAP S/4HANA-Plattform. Mehrwerte werden in weiteren Teilprojekten Schritt für Schritt realisiert. Die System Conversion ist somit nur ein Projekt innerhalb der Umstellung auf die S/4-Plattformtechnologie.

Ein weiteres kritisches Thema ist die Performance der SAP-Applikation. SAP bewirbt die In-Memory-DB HANA. Man könnte glauben, "alle Daten immer im Hauptspeicher" zu haben, schafft eine tolle Performance. Beim Lesen auf der Datenbank hat man wirklich seinen Spaß, wenn man denn größere Datenmengen auswertet. Die transaktionale Welt liest aber meist nur sehr begrenzte Datenmengen aus und schreibt auch nur sehr begrenzte Datenmengen zurück. Mir ist nicht klar, ob man bei dem zuvor beschriebenen Auslesen und Zurückmelden von nur geringen Datenmengen eine positive Wirkung messen kann, sehen kann man diesen Performancegewinn nicht.

Da SAP die meisten Datenbankzugriffe der altbekannten Applikationen (FI, CO, MM, PM, SD etc.) nur über eine "Übersetzungsschicht" realisiert hat - die meist nur die Lauffähigkeit der Applikationen sichergestellt hat - sind diese Applikationsanteile eher etwas langsamer als schneller geworden. Überall dort, wo direkt und "richtig" auf die Datenbank zugegriffen wird, sind die Analysen deutlich schneller als früher. Die eigenentwickelten alten Analysen werden nicht schneller, sondern eher langsamer. Neue Eigenentwicklungen können natürlich erheblich von den technologischen Möglichkeiten profitieren.

Wenn man den Mehrwert von S/4HANA richtig heben möchte, kommt man nicht umher die transaktionale Welt mit analytischen Ergebnissen anzureichern. Wir wollen ja besser und an Kennzahlen orientiert arbeiten und bei Entscheidungen früher die Wirkung erkennen. Wir wollen im operativen Handeln Simulationsverfahren den Anwendern zur Verfügung stellen. Dazu müssen die benötigten operativen Analysen aus dem BI wieder in die eigentliche S/4-Installation verlagert werden. Diese sind nur aufgrund der mangelhaften Performance aus dem R/3 ins BI verlagert worden. Dieses Rad wird jetzt wieder zurückgedreht. Vorteil: nichts muss im ersten Schritt vollständig umgesetzt werden. Aber der Investitionsschutz der Zukunft gebietet, jetzt alles Neue direkt im S/4HANA zu realisieren und operative BI-Entwicklungen Stück für Stück in das S/4HANA zu verlagern.

Grundsätzliches zur Projektvorgehensweise: ich freue mich sehr, dass wir nun agile Entwicklungsansätze in SAP S/4HANA-Projekten anwenden. Bedeutet konkret, dass wir sehr stark an Prototypen orientiert mit dem Fachbereich das System diskutieren und ausprägen. Es wird in Iterationsstufen eine produktive Lösung erarbeitet und ausgetestet. Durch die frühzeitige Einbindung des Fachbereichs verschlankt sich die Dokumentation eines vorgelagerten Blueprints erheblich, wie sich auch der Schulungsaufwand bei der Inbetriebnahme der Systemlandschaft erheblich reduziert. Durch diese Art der Vorgehensweise wird die Lösung für den Fachbereich verständlich, nachvollziehbar und transparent.