SAP S/4HANA Go-live: Warum die eigentliche Transformation erst danach beginnt
Der Go-live ist geschafft. S/4HANA läuft, die kritischen Prozesse funktionieren, der neue Core steht. Damit ist ein wichtiger Meilenstein erreicht. Aber für Unternehmen beginnt jetzt eine mindestens ebenso wichtige Phase. Hat sich für das Business nicht bereits genug verändert? Ganz im Gegenteil: Viele Anforderungen und Verbesserungen konnten während der Transformation nicht umgesetzt werden. Nicht, weil sie unwichtig waren, sondern weil während der Transformation andere Prioritäten gesetzt werden mussten. Gleichzeitig lassen sich jetzt viele neue Möglichkeiten schneller und einfacher umsetzen, als noch vor der Transformation.
Der Go-live ist deshalb weniger das Ende einer Transformation als vielmehr die Grundlage für die nächste Phase: In diesem Blogpost erklärt Christian Heinrich, Chief Solutions Officer bei sovanta, wie aus der neuen technologischen Basis konkreter Business Value entsteht.
Warum nach dem Go-live oft eine Lücke entsteht
Während einer S/4-Transformation gibt es ein klares Ziel: sicher live gehen.
Dafür werden Prioritäten gesetzt, Risiken reduziert und Themen bewusst verschoben. Das ist sinnvoll und häufig sogar notwendig. Gerade Anforderungen aus den Fachbereichen, die für den Go-live nicht zwingend erforderlich sind, werden bewusst auf die Zeit nach der Transformation verschoben. So entsteht über die Laufzeit des Programms ein Backlog, der nach dem Go-live wieder relevant wird. Nicht jede Prozessverbesserung passt in den Scope eines großen Transformationsprogramms. Nicht jede Anforderung aus dem Fachbereich kann gleichzeitig umgesetzt werden. Und nicht jeder etablierte Ablauf lässt sich mitten in einer Migration grundsätzlich neu denken.
Hinzu kommt die begrenzte Kapazität:
Bis zum SAP S/4HANA Go-live liegt der Fokus zunächst auf Business Continuity – und danach?
Nach dem Go-live verändert sich die Perspektive. Das System ist produktiv, die technische Basis stabilisiert sich – und damit wird wieder sichtbar, was während der Transformation bewusst oder unbewusst liegen geblieben ist. Typische Beispiele sind manuelle Arbeitsschritte, bekannte Workarounds oder Anforderungen aus den Fachbereichen, die mehrfach vertagt wurden.
Auch bestehender Custom Code gehört dazu. Erweiterungen werden während einer Transformation teilweise bewusst zunächst übernommen, weil eine Ablösung oder komplette Neugestaltung zu komplex oder umfangreich wäre. Damit ist der Clean Core nach dem Go-live noch nicht automatisch erreicht – und gleichzeitig ist das Potenzial neuer Technologien für diese Lösungen noch nicht ausgeschöpft.
Daneben gibt es Prozesse, bei denen im Rahmen der Transformation bewusst pragmatische Kompromisse eingegangen wurden. S/4 funktioniert an manchen Stellen anders als die bisherige Lösung. Der Prozess funktioniert zwar, entspricht aber noch nicht vollständig den Erwartungen der Fachbereiche. Nach dem Go-live kann gezielt optimiert und erweitert werden.
Genau hier entsteht eine Erwartungslücke: Das Transformationsprogramm ist abgeschlossen, die Erwartungen des Business an bessere Prozesse bestehen jedoch weiter. Ein Teil dieser Lücke ist offensichtlich. Ein anderer bleibt zunächst unsichtbar. Prozesse funktionieren zwar, verursachen aber weiterhin unnötigen Aufwand. Medienbrüche bestehen fort. Informationen müssen gesucht, übertragen oder mehrfach gepflegt werden. Entscheidungen dauern länger als nötig.
Solange nichts akut kaputtgeht, geraten solche Abläufe leicht aus dem Fokus. Dabei liegt gerade hier häufig erhebliches ungenutztes Potenzial.
Migration und Innovation sind zwei unterschiedliche Aufgaben
Es hilft, eine S/4-Transformation gedanklich in zwei Phasen zu unterteilen.
- Die erste Phase ist die Migration. Ihr Ziel ist Business Continuity: sicher live gehen, Stabilität schaffen, Risiken reduzieren und einen möglichst sauberen Core etablieren.
- Die zweite Phase ist die Innovation. Ihr Ziel ist Business Value: Prozesse verbessern, Arbeit vereinfachen und die Möglichkeiten der neuen technologischen Basis gezielt nutzen.
Diese Unterscheidung ist wichtig, weil beide Phasen unterschiedlichen Logiken folgen. Eine Migration optimiert auf Stabilität, Standardnähe und Risikoreduktion. Teams, Vorgehensmodelle und Erfolgskriterien sind genau darauf ausgerichtet. Nach dem Go-live verändert sich der Auftrag. Jetzt geht es darum, wirtschaftlich relevante Potenziale zu identifizieren und gezielt dort zu investieren, wo Prozesse besser, schneller oder intelligenter werden können.
Das bedeutet nicht, dass diese Themen während der Transformation übersehen wurden. Häufig wurden sie bewusst vertagt oder pragmatische Zwischenlösungen gewählt, um Komplexität zu reduzieren und den Go-live nicht zu gefährden. Nach dem Go-live verändert sich die Optimierungslogik.
Neben technischen SAP-Know-how werden damit andere Fähigkeiten wichtiger: Prozessinnovation, Business-Case-Orientierung, User Experience, SAP BTP/ SAP BAIP, AI und die Fähigkeit, Ideen schnell produktiv umzusetzen.
Das bedeutet nicht, dass bestehende Transformationspartner diese Fähigkeiten grundsätzlich nicht besitzen. Sie waren jedoch häufig nicht der Kern des ursprünglichen Migrationsmandats. Die entscheidende Frage nach dem Go-live lautet deshalb nicht mehr nur: Wer kennt unser System? Sondern zunehmend: Wer erkennt relevante Verbesserungspotenziale und kann daraus schnell eine wirtschaftlich sinnvolle Lösung machen?
Clean Core und Innovation sind kein Widerspruch
Innovation nach dem Go-live bedeutet nicht, den gerade geschaffenen Core wieder mit individuellen Entwicklungen zu überladen. Im Gegenteil.
Der SAP-Standard sollte dort genutzt werden, wo er die Anforderungen sinnvoll erfüllt. Dort aber, wo Prozesse ein Unternehmen differenzieren oder eine Erweiterung einen klaren wirtschaftlichen Nutzen bringt, können Side-by-Side Extensions eine Alternative zur Individualisierung des Core sein.
Die SAP BTP bzw. SAP BAIP schafft dafür eine technische Grundlage: Erweiterungen, Integrationen, Anwendungen und neue Services können außerhalb des eigentlichen S/4-Core umgesetzt werden. So wird aus einem Clean Core ein Smart Core: stabil und möglichst standardnah im Kern, aber gezielt erweitert, wo daraus messbarer Nutzen entsteht.
Nicht jede gute Idee ist ein guter Use Case
Mit den technologischen Möglichkeiten wächst allerdings auch die Zahl möglicher Ideen. Gerade AI verstärkt diesen Effekt. Die Technologie eröffnet neue Möglichkeiten. Wissen verfügbar zu machen, Dokumente zu verarbeiten, Entscheidungen zu unterstützen oder repetitive Tätigkeiten zu automatisieren.
Doch eine interessante Technologie ist noch lange kein guter Business Case. Entscheidend ist nicht, was technisch möglich ist, sondern welches konkrete Problem gelöst wird und welcher Business Value daraus entsteht.
Für diese Entscheidung sind vor allem drei Perspektiven relevant:
- Business Value: Welcher wirtschaftliche oder operative Nutzen ist zu erwarten?
- Machbarkeit: Lässt sich die Verbesserung technisch und organisatorisch sinnvoll umsetzen?
- Time to Value: Wie schnell kann aus der Idee ein in der Praxis nutzbarer Nutzen entstehen?
Erst wenn diese Fragen zusammen betrachtet werden, wird aus einer offenen Anforderung eine belastbare Investitionsentscheidung.
AI ist ein Werkzeug – nicht der Ausgangspunkt
AI kann dabei ein großer Hebel sein.
Wenn Mitarbeitende viel Zeit mit der Suche nach Informationen verbringen, Dokumente manuell auswerten, wiederkehrende Entscheidungen vorbereiten oder repetitive Tätigkeiten ausführen, können AI-basierte Lösungen erheblich Potenzial bieten.
Aber AI ist nicht automatisch die beste Antwort. Manchmal liegt der größere Hebel in einer Vereinfachung des Prozesses. Manchmal reicht eine kleine Extension. In anderen Fällen verbessert eine durchdachte User Experience die tägliche Arbeit stärker als ein komplexes AI-Szenario. Und gelegentlich ist eine bessere Integration zwischen bestehenden Systemen die wirtschaftlich sinnvollste Lösung.
Der Ausgangspunkt sollte deshalb immer der Prozess sein – nicht die Technologie. Die entscheidende Frage lautet: Was muss sich verändern, damit für das Business tatsächlich ein messbarer Vorteil entsteht? Erst danach sollte entschieden werden, welche Technologie dafür geeignet ist.
Vom Verbesserungspotenzial zur Investitionsentscheidung
Für Unternehmen ergibt sich daraus eine praktische Herausforderung: Nach einem großen Transformationsprogramm gibt es meist mehr Verbesserungsideen als Zeit, Budget und Kapazitäten.
Eine strategische Roadmap bleibt dabei wichtig. Entscheidend ist aber, nach der Transformation nicht unmittelbar das nächste mehrjährige Großprogramm aufzusetzen. Stattdessen gilt es, aus dem vorhandenen Backlog die richtigen Themen zu identifizieren, fundiert zu priorisieren und möglichst schnell erste Ergebnisse zu erzielen.
Ein pragmatischer Ansatz beginnt deshalb mit der Arbeit an einem konkreten Prozess. Wo entsteht heute unnötiger manueller Aufwand? Wo gibt es Workarounds? Welche Anforderungen wurden während der Transformation mehrfach verschoben? Wo verlieren Mitarbeitende Zeit? Und wo würde eine Verbesserung einen erkennbaren wirtschaftlichen Effekt erzeugen?
Ein solcher Prozess kann anschließend gezielt auf Nutzen, Aufwand und technische Machbarkeit untersucht werden. Die mögliche Konsequenz muss dabei ausdrücklich auch lauten können: nicht investieren. Denn Wert entsteht nicht dadurch, möglichst viele neue Lösungen in Betrieb zu nehmen, sondern durch die richtigen Probleme zu lösen.
Von der Analyse möglichst schnell in die Realität
Ist ein belastbarer Business Case vorhanden, sollte der Weg zur produktiven Lösung möglichst kurz sein.
Das ist auch organisatorisch relevant: Nach einer mehrjährigen Transformation sind viele Beteiligte stark beansprucht. Statt erneut lange Workshop-Ketten aufzusetzen, braucht es Formate, die schnell zu Klarheit, Entscheidungen und sichtbaren Ergebnissen führen.
Das spricht für kleine, fokussierte Umsetzungseinheiten statt für das nächste mehrjährige Transformationsprogramm. Ein klar abgegrenzter Prozess, ein nachvollziehbarer Business Case und ein überschaubarer Scope erleichtern es, Nutzen früh sichtbar zu machen und anschließend auf Basis realer Erfahrungen weiterzuentwickeln.
Gleichzeitig braucht diese Geschwindigkeit eine stabile technische und organisatorische Grundlage. Governance, Security, Architektur, Integration und der Umgang mit der SAP BTP sollten deshalb nicht für jeden Use Case neu erfunden werden. Die eigentliche Skalierbarkeit entsteht, wenn einzelne Innovationen auf einer gemeinsamen Plattform und klaren Leitplanken aufbauen.
Wie sovanta diesen Ansatz umsetzt
Bei sovanta beschäftigen wir uns seit Jahren mit genau dieser Schnittstelle: Innovation auf einem laufenden SAP-Core. Über verschiedene Technologie- und Prozessansätze, haben wir dabei unter anderem mit Unternehmen wie Bosch, BASF und Munich Re gearbeitet. Im Mittelpunkt steht die Verbindung von Prozessverständnis, Requirements und neuen Technologien.
Unser Ansatz beginnt bewusst nicht mit der Umsetzung. In einer Process Innovation Value Analysis betrachten wir zunächst einen konkreten Prozess und bewerten Business Value, Machbarkeit und Aufwand. Daraus entsteht eine Lösungsvision und – wenn die Investition sinnvoll erscheint – eine konkrete Grundlage für die Umsetzung.
Für Unternehmen, die zunächst einen kleineren Einstieg suchen, gibt es den Process Quick Check: In einem kostenlosen einstündigen Gespräch betrachten wir gemeinsam einen konkreten Prozess und geben eine erste Einschätzung zu dessen Verbesserungspotenzial.
Das Ziel ist dabei nicht, möglichst schnell ein Technologieprojekt zu starten. Sondern zunächst herauszufinden, ob und wo sich eine Investition tatsächlich lohnt.
Sie wollen mehr erfahren?
Schicken Sie uns Ihre Fragen und wir kommen direkt auf Sie zu.
