Technische Konvertierung zu S/4HANA

Viele Unternehmen haben SAP schon einige Jahre im Einsatz und haben sich auch das entsprechende Wissen zu ihrem SAP System aufgebaut und die entsprechenden Vorgehensweisen entwickelt. Zentrale Prozesse sind im SAP System abgebildet und stellen das digitale Rückgrat für das Unternehmen dar.

Ein zwingender Bedarf für grundlegende Veränderungen besteht daher nicht immer. Über kurz oder lang lässt sich aber die Abkündigung der SAP für das System ECC 6.0 auch nicht wegdiskutieren. Die IT ist somit in Zugzwang gebracht: wie soll es mit dem eigenen SAP System nach einem Wartungsende weitergehen? Was würde die Einführung eines S/4HANA für das Unternehmen bedeuten?

Auf der Suche nach einer Strategie für den Umstieg auf S/4HANA

Die Unternehmen befinden sich oft in einem Dilemma: hat das System aktuell eine Reife und Stabilität erreicht, besteht kein zwingender Änderungsbedarf. Die Fachbereiche haben sich mit dem System arrangiert, die Prozesse laufen und man kommt mit dem System klar. Wenn es hier keinen klar erkennbaren Mehrwert für die Fachbereiche und IT gibt, wird es oft schwierig bei der S/4HANA-Strategie:

  • SAP wird mit S/4HANA nicht immer intuitiver bedienbar
  • der Business Case für die S/4-Umstellung lässt sich schwer berechnen
  • schlechte Erfahrungen und Ängste durch die vergangene SAP-Einführung
  • die Fachbereiche haben eine gute Auslastung und nur geringe Kapazitäten/Ressourcen für eine Mitarbeit in einem Großprojekt

Daher werden die verschieden Einführungsstrategien Greenfield, Brownfield/Conversion oder hybrider Ansatz geprüft, aber die grundlegende Entscheidung zu schnell getroffen:

Eine Konvertierung im Hintergrund auf S/4HANA.

Das klingt nach einer rein technischen Migration und somit sollte ja kein Fachbereich benötigt sein. Somit scheinen die Aufwände geringer und besser planbar zu sein!

Hier muss ich aber leider enttäuschen. Das wird so leider nichts!

Trick mit der Tischdecke

Die Vorstellung, die dahinter steht, ist ja ein bisschen wie der Trick mit der Tischdecke: die Tischdecke soll von einem Tisch, der gedeckt ist mit feinsten Porzellan und Gläsern, weggezogen werden, ohne dass etwas vom Tisch fällt und zerbricht. Soweit ja noch physikalisch machbar, bedarf nur etwas Mut und Übung.

Jetzt kommt aber die tatsächliche Herausforderung: eine Tischdecke unter einen gedeckten Tisch legen/ ziehen/ schieben, ohne dass etwas umfällt? Ohne Zaubertrick nicht machbar! Und dass bei einem SAP System in den seltensten Fällen ein Zaubertrick funktioniert, weiß jeder der sich auch nur ein bisschen mit SAP beschäftigt hat.

Die Aufwände sind nicht geringer zu anderen möglichen Szenarien. Denn die Anforderungen bei einer Brownfield-Einführung sind sehr hoch an das Projekt:

  • es müssen alle Daten gemappt sein,
  • alle Migrationsregeln müssen definiert werden,
  • die Eigenentwicklungen gilt es zu prüfen und
  • zur Risikominimierung eines Big-Bang-Szenario („alles oder nichts!“) sollten möglichst viele Probeläufe durchgeführt werden.

Diese Test- und Probeläufe für die technische Migration auf ein S/4HANA-System sind eine zwingende Vorausaussetzung und führen zu hohen Aufwänden, eben auch in den Fachbereichen:

  • Sind alle Daten migriert und performant?
  • Funktionieren die Prozesse nach der Migration noch?

Aber auch bei den z-Programmen und Transaktionen gibt es etwas tun: neben der technischen Prüfung der Eigenentwicklungen muss auch eine fachliche Prüfung erfolgen. Da es sich bei einer HANA Datenbank um eine In-Memory Datenbank handelt, ist die implizite Ordnung einer SQL Abfrage im Vergleich zu traditionellen Datenbanken nicht mehr gewährleistet. Dies kann unter Umständen zu Fehlern in Programmen führen, die fachlich zu beurteilen sind.

Auch die Anforderungen an das Projektmanagement sind in einer technischen Konvertierung hoch: die Anzahl und die Einplanung der Probeläufe erfordern viele Abstimmungen mit allen Fachbereichen und hier ist Kommunikation sicher eine wertvolle Schlüsselkompetenz. Und die Steuerung der Downtime, also dem Zeitraum, in dem das bisherige System in ein sogenanntes Schattensystem konvertiert wird, steht nicht zu Beginn des Projektes fest. Je mehr Daten vorhanden sind, umso länger die Dauer. Als Faustregel sind hier Tage anzusetzen und nicht nur Stunden! Und auch hier ist für die Bearbeitung und Freigabe der Input aus dem Fachbereich notwendig.

Aufwände und Anforderungen nicht unterschätzen

Diese Erfahrungen lassen mich zu folgendem Fazit kommen: unterschätzen Sie die Aufwände der technischen Konvertierung nicht! Ein richtiger Beratungspartner für Ihr Unternehmen erarbeitet gemeinsam das Für und Wider für Sie und verfügt auch über die richtigen Erfahrungen! Daher unsere klare Empfehlung: treffen Sie nicht zu schnell Ihre strategische Entscheidung für Ihre Implementierung. Informieren Sie sich welche Strategie tatsächlich passt.

Melden Sie sich zu unserem Webinar an oder buchen Sie einen Workshop mit uns: https://blog.pikon.de/s4hana-strategie-workshop/

 

Bildnachweise

© Vidar Nordli-Mathisen – Unsplash

Teilen Sie diesen Beitrag