Die wichtigste Frage beim Start in die S/4HANA Transformation: Wo will ich in Zukunft den SAP S/4HANA Standard nutzen, wo benötige ich Individuallösungen – und wie werden diese realisiert? Hier den individuellen Weg zu finden, stellt eine große Herausforderung dar! Die zentralen Fragen sind „Was kann bzw. könnte man bei der S/4HANA Transformation weiter nutzen und was will man weiter nutzen?“ und „wie komme ich möglichst schnell zumindest zu einem ersten Überblick?“ Auch wenn das schwierig erscheint (Verweis auf anderen Blog), irgendwann im Zuge einer S/4HANA Transformation muss man unweigerlich die Prozesse auf den Prüfstand stellen, man muss ran an den heißen Brei… Mit etwas Vorsicht kann man aber verbrannte Finger vermeiden. Das individuell richtige Verhältnis von Standard oder Individuallösungen ist ein entscheidender Erfolgsfaktor bei der S/4HANA Transformation.
Herausforderung Historie – Technical Debt bei der Umstellung auf S/4HANA
Dazu ein kurzer Blick in die Vergangenheit. Die SAP stellte R/3 vor über 30 Jahren vor, den Nachfolger SAP ECC 2004, 2013 endete die erweiterte Wartung für die Vorgängerversionen. Dementsprechend hatten spätestens zu diesem Zeitpunkt nahezu alle Kunden auf ECC gewechselt. Die Umstellung sollte möglichst schnell und mit geringem Aufwand erfolgen. Frühere SAP Releasewechsel waren in der Folge häufig nur eine rein technische Migration. In erster Linie waren die Basisberater gefordert. Mit ausreichend Kaffee und sonstigen Betriebsmitteln versorgt haben sie die notwendigen technischen Schritte durchgeführt. Sarkastisch formuliert: Beim „idealen“ Migrationsprojekt änderte sich für die Benutzer wenig bis gar nichts. Das war teilweise sogar ein explizites Ziel. Man scheute den Schulungsaufwand und wollte die Testumfänge, insbesondere für die Fachbereiche, möglichst geringhalten. Ressourcen waren offensichtlich schon vor der S/4HANA Transformation knapp…
Die unmittelbare Folge: Die Prozessabläufe entsprechen mancherorts noch nicht einmal den Möglichkeiten von SAP ECC sondern sind auf dem Stand der älteren Releases wie 4.6c oder 4.7. Und je länger die initiale Implementierung zurückliegt, desto mehr Eigenentwicklungen sind im SAP-System zu finden. Schließlich kamen gerade mit ECC 6.0 im Laufe der Jahre eine Vielzahl neuer Funktionen hinzu. Diese unerledigten Arbeiten am System werden allgemein als „Technische Schulden“ (Technical Debt) Technical Debt in SAP Projects – IgniteSAP bezeichnet. Schnelle und einfache Lösungen aus Zeit- und Aufwandsgründen erzeugen eine Bugwelle an unerledigter Arbeit. Fairerweise muss man sagen, dass es das nicht nur im SAP-Kontext gibt. Man kennt das z.B. von der eigenen Wohnung. Nichts hält länger als ein Provisorium, das man nicht gleich beim Einzug erledigt hat….
Die S/4HANA Transformation als Chance zu einer Standortbestimmung
Grundsätzlich besteht die Option einer eher technisch orientierten Migration (Brownfield) auch bei der S/4HANA Transformation. Das Kompatibilitätsversprechen der SAP gilt weiterhin und nicht nur bei einem Releasewechsel. Auch der Umstieg auf das neue Produkt SAP S/4HANA wird durch entsprechende Tools zur Systemkonvertierung (Optional mit Minimum Downtime Option) sehr gut und umfangreich unterstützt. Chancen zur Reduzierung der Komplexität oder der Zahl der Systeme können so jedoch nicht genutzt werden. Im schlimmsten Fall entstehen hohe Kosten ohne adäquates Ergebnis. Es ist für einen CIO keine einfache Argumentation, hohe Projektkosten für eine Umstellung zu rechtfertigen, ohne zugleich fundamentale, finanzielle oder funktionale Verbesserungen zu erzielen. Hieraus resultiert auch in wesentlichen Teilen der Unmut über die von der SAP durch das Wartungsende bis Ende 2027 erzwungene S/4HANA Transformation. Dazu unten mehr
Die Systemkonvertierung ist der vermeintlich schnellste Weg um in einem relativ kurzen Zeitfenster die S/4HANA Transformation zu absolvieren. Die scheinbar einfachste und schnellste Lösung kann das Unternehmen jedoch langfristig behindern. Die Kunden sollten sich der möglichen Auswirkungen bewusst sein. Wenn bei der Umstellung auf SAP S/4HANA der einstufige Ansatz (Infrastruktur plus Anwendung) gewählt wird, empfiehlt die SAP deshalb dringend, anschliessend in einer sog. Innovationsphase einen Blick auf Funktionen und Prozesse zu werfen. Die S/4HANA Transformation bietet die Chance, technische Schulden zu reduzieren, man sollte die Gelegenheit nicht verstreichen lassen!
Standard oder Individuallösungen als Erfolgsfaktor bei S/4HANA – Wohin soll die Reise gehen?
Eine Reise beginnt nicht mit dem ersten Schritt, sondern mit einer Bestandsaufnahme. Ein Architekt beispielsweise schaut zunächst auf das Grundstück und die örtlichen Gegebenheiten. So zeigen Tools wie z.B. der SAP Readiness Check for SAP S/4HANA genau, welche technischen Voraussetzungen erfüllt sein müssen, um auf S/4HANA zu migrieren. Auf dieser Basis sollten die bisherigen Prozesse danach auf Aktualität und Tauglichkeit überprüft werden, insbesondere auch im Hinblick auf die Vorteile von S/4HANA. Genau das ist es aber, wovor viele Organisationen zurückschrecken. Zudem drängen viele Beteiligte, unter Umständen auch die Berater, häufig auf eine schnelle Umsetzung.
Bei der Frage Standard- oder Individuallösungen bei SAP S/4HANA Transformationen gibt es einige technische Hintergründe, die zentrale Erfolgsfaktoren darstellen. Diese sollten im Unternehmen möglichst allgemein bekannt sein und verstanden werden. Ich will hier bewusst nicht so sehr auf die technischen Details im Einzelnen eingehen. (Das spare ich mir für einen weiteren Blog auf, das ist nämlich auch ein sehr spannendes Thema!) Wie ein guter Architekt die konstruktiven und rechtlichen Rahmenbedingungen im Auge behält und seinem Auftraggeber die wichtigsten Punkte vermitteln kann möchte ich hier einen Überblick geben:
S/4HANA und Kompatibilität mit früheren Releases
Wie oben gezeigt, hat die SAP in der Vergangenheit sehr umfangreiche Garantien zur Kompatibilität gegeben. An definierten Punkten im Code, sog. User Exits, beispielsweise wurde zugesichert, dass Zusatzentwicklungen, die an dieser Stelle ansetzen, auch in zukünftigen Releases unverändert lauffähig sein werden. Gerade z.B. im Modul SD gibt es unzählige dieser vorgedachten Erweiterungsmöglichkeiten. Die Folge ist, dass die Software und damit der Prozess deshalb nur in engen Grenzen neu definiert werden kann. Die SAP hat deshalb seit der Einführung von S/4HANA klar kommuniziert, dass sie die technischen Möglichkeiten von SAP HANA nutzen möchte, um die Software zu vereinfachen und schneller zu machen. Dazu benötigt sie bei der Softwareentwicklung aber entsprechenden Handlungsspielraum. Die Kompatibilität ist weiter gewährleistet, aber nicht mehr in dem bisher gekannten Ausmaß.
Vereinfachungen durch S/4HANA
Die SAP gewährt in gewissen Bereichen (insbesondere in den Modulen CS und WM) für eine gewisse Zeit Nutzungsrechte der alten Softwarekomponenten auch unter S/4HANA. Dies ist der sog. Kompatibilitätsscope. Die Module entsprechen nicht mehr der neuen Zielarchitektur und dürfen nur noch für eine Übergangszeit (in den meisten Fällen bis Ende 2025, dem ursprünglich geplanten Wartungsende für ECC) genutzt werden. Spätestens dann muss auch unter S/4HANA auf die neuen Komponenten umgestellt werden.
Kompatibilität von Zusatzentwicklungen
In der Vergangenheit erfolgte wohl keine SAP Implementierung ohne Zusatzentwicklungen. Bei Kundenerweiterungen konzentrierte sich das insbesondere auf Reporting und User Interface. In einzelnen Branchen wie z.B. der diskreten Fertigung wurden häufig auch Prozesse verändert und erweitert. Dabei gab und gibt es auch eine Vielzahl von Software-AddOns von SAP Partnern.
Im Rahmen der Bestandsaufnahme wird die Kompatibilität dieser Programme überprüft. Bei S/4HANA-kompatiblen Zusatzentwicklungen, stellt sich die Frage, ob das auch sinnvoll ist. Der Readiness Check zeigt oft, dass bei der Einführung als wichtig erachtete Erweiterungen überhaupt nicht (mehr) genutzt werden. Auch wenn sie noch aktuell sind, gibt es unter S/4HANA heute ganz andere Möglichkeiten im Bereich von Auswertungen und Ergänzungen des User Interfaces. Damit unmittelbar verbunden ist die Frage, ob eine Rückführung in den Standard möglich bzw. sogar sinnvoll ist? Für jede Abweichung muss ich als Kunde die Kosten und die Verantwortung tragen. Schliesslich wollen wir ja keinen Technical Debt…
Weiterer Support der Zusatzlösungen
Diese Fragen haben sich auch viele SAP Partner gestellt. Sie unterstützen viele Angebote unter S/4HANA nicht mehr. Teilweise bieten sie den bisherigen Kunden sogar an, die unter S/4HANA grundsätzlich lauffähige Software künftig weiter nutzen zu dürfen, aber eben ohne irgendwelche Verantwortungsübernahme. Wenn aber schon der Hersteller selbst in Kenntnis der Hintergründe und Erfolgsfaktoren von SAP S/4HANA die Frage nach Standard- oder Individuallösungen aus betriebswirtschaftlichen Gründen so sieht, ist das dann wirklich eine Option? Bei den kundeneigenen Zusatzentwicklungen stellt sich diese Frage prinzipiell genauso. Wo früher (s.o.) grundsätzlich von einer langfristigen Stabilität ausgegangen werden konnte, besteht heute eine große Dynamik. Und selbst bei Stabilität ist der Support ein vor allem langfristig nicht unerheblicher Kostenfaktor.
Flexibilität
Selbst wenn man vorhandene Zusatzentwicklungen auch unter S/4HANA gerne beibehalten möchte, ergibt sich daraus keine Sicherheit, dass das auch in Zukunft so sein wird! Ich erinnere mich an ein interessantes Gespräch mit einem CIO vor einigen Jahren: „Wir haben unsere internen Prozesse teilweise bewusst vom Kunden abgeschirmt und auf Effizienz gebracht. Die Erweiterungen unterstützen den Prozess sehr gut. Aber was machen wir, wenn wir morgen einen anderen Kunden bedienen sollen und wir unsere internen Prozesse an dessen Anforderungen anpassen müssen?“
Letzten Endes machen die die geschilderten Hintergründe deutlich, warum die Frage „Standard oder Individuallösungen“ solch einen zentralen Erfolgsfaktor bei der S/4HANA Transformation darstellt. In Kombination mit den heutigen technologischen Möglichkeiten führt dies zu zwei klaren Empfehlungen bei den Entscheidungen über Standard oder Individuallösungen: Zum einen sollte grundsätzlich eine Rückführung in den Standard angestrebt werden wo immer das möglich erscheint. Zum anderen sollte überall, wo das nicht möglich ist, eine sog. Keep the Core Clean Strategie zur Anwednung kommen. Das heisst, dass im Kernsystem der SAP das Spielfeld überlassen wird (in SAP S/4HANA Public Cloud ist das ohnehin der Fall) und nur über sog. APIs erweitert wird. (Weitere Details folgen eventuell in einem weiteren Blog.) Und das gilt sowohl für die Integration von Third-Party-Software als auch für Eigenentwicklungen des Kunden.
Standard oder Individuallösungen als Erfolgsfaktor bei S/4HANA – Herausforderung Prozessworkshop
Diese Empfehlung lässt sich aber nur mit Hilfe von jeweils individuellen Antworten in die Realität umsetzen. Und hier führt kein Weg am Blick auf die jeweiligen Prozesse des Unternehmens vorbei. Das kann auch (erst mal) an der Oberfläche bleiben! Der individuell richtige Umgang mit Standard oder Individuallösungen ist ein zentraler Erfolgsfaktor bei S/4HANA. Aber diese Betrachtung ist nicht statisch sondern bezogen auf den Zeitpunkt bzw. die jeweilige Situation.
Es gibt sehr gute Gründe, die S/4HANA Transformation möglichst schnell und mit möglichst geringem Aufwand hinter sich zu bringen. Wenn das eine bewusste Entscheidung ist, alles wunderbar! Problematisch wird es, wenn die Fallgruben erst im Laufe der Zeit „hochpoppen“. Aus vielen Gesprächen mit Praktikern weiss ich leider nur zu gut, dass in vielen Unternehmen die S/4HANA Transformation als eine Aufgabe für die IT gesehen wird. Damit einher geht viel verschenktes Potential. Wenn ich in ein altes Haus eine neue Heizung einbaue, aber Leitungen und Dämmungen nicht verändere, wird der Effekt der Investition deutlich kleiner ausfallen… Ich hoffe, hier ein wenig Überblick und Bewusstsein vermittelt zu haben: Was man alles im Auge, welche Fragen man zumindest einmal durchdacht haben sollte. Und Informationen, wie man das konkret angehen kann, gibt es hier.
No responses yet