Wenn heute über SAP S/4HANA gesprochen wird, stehen häufig Migrationspfade, technische Voraussetzungen und der Zeitplan bis 2027 im Vordergrund. Das ist nachvollziehbar: Für die Kernanwendungen der SAP Business Suite 7 endet die Mainstream Maintenance Ende 2027; optional kann sich eine Extended Maintenance bis Ende 2030 anschließen.
Damit wird aus einer lang geplanten Transformation für viele Unternehmen ein konkretes Programm mit zunehmendem Zeitdruck.
In der Praxis liegt die größere Herausforderung allerdings nicht allein im Termin. Ein technischer Wechsel auf SAP S/4HANA kann gelingen und trotzdem kaum etwas an gewachsenen Prozessen, Eigenentwicklungen und komplexen Integrationen verändern.
Die interessantere Frage lautet deshalb:
Wie schaffen wir den Wechsel auf SAP S/4HANA, ohne die Komplexität der vergangenen Jahre einfach in die neue ERP-Landschaft mitzunehmen?
SAP Activate liefert dafür einen methodischen Rahmen.
SAP Activate ist das Implementierungsframework von SAP für die Einführung und Transformation von SAP-Lösungen. Es verbindet SAP Best Practices, Implementierungswerkzeuge und eine strukturierte Methodik. Die sechs Phasen Discover, Prepare, Explore, Realize, Deploy und Run reichen von der strategischen Vorbereitung bis zum kontinuierlichen Betrieb.
Wer SAP Activate lediglich als Projektplan mit sechs Phasen versteht, greift allerdings zu kurz.
Im Kern greifen drei Elemente ineinander:
SAP Best Practices liefern vorkonfigurierte Prozesse und Inhalte, auf denen ein Projekt aufsetzen kann. Das Projekt startet damit nicht bei null.
Die Implementierungswerkzeuge unterstützen beispielsweise Prozessgestaltung, Konfiguration, Architekturarbeit, Anforderungsmanagement und Test.
Die SAP Activate Methodology strukturiert die Projektdurchführung über Phasen, Workstreams, Aufgaben, Deliverables, Accelerators und Quality Gates.
Für das Projekt verändert sich dadurch vor allem der Ausgangspunkt. Statt zuerst sämtliche individuellen Anforderungen zu sammeln und das System anschließend daran auszurichten, wird zunächst geprüft, wie weit der SAP-Standard die Geschäftsanforderungen bereits abdeckt.
Das ist mehr als eine methodische Änderung. Es beeinflusst unmittelbar, wie viel Komplexität später im System entsteht.
SAP Activate gliedert die Transformation in:
Discover → Prepare → Explore → Realize → Deploy → Run
In Discover geht es um Business Value, Zielbild und grundlegende Transformationsentscheidungen. Hier sollte beispielsweise geklärt werden, welchen Beitrag SAP S/4HANA zur Unternehmensstrategie leisten soll und welcher Transformationsweg grundsätzlich geeignet erscheint.
Gerade in dieser frühen Phase lohnt es sich, SAP S/4HANA nicht als reinen Systemwechsel zu behandeln. Eine technische Migration und eine echte Business Transformation können auf den ersten Blick ähnlich beginnen, führen aber zu sehr unterschiedlichen Zielbildern.
Wie sich eine solche End-to-End-Perspektive aufbauen lässt, zeigen wir im Beitrag „SAP S/4HANA Migration: Warum der Weg entscheidend ist – Teil 1“.
In Prepare werden die organisatorischen und methodischen Voraussetzungen für die Umsetzung geschaffen. Governance, Rollen, Verantwortlichkeiten, Projektorganisation und Standards müssen so definiert sein, dass aus dem strategischen Zielbild ein tatsächlich steuerbares Transformationsprogramm wird.
In Projekten zeigt sich an dieser Stelle schnell, wie belastbar die vorangegangenen Entscheidungen sind. Unklare Verantwortlichkeiten oder ein noch nicht ausreichend bewerteter Transition Path führen später häufig zu unnötigen Schleifen.
Ein strukturiertes S/4HANA Migration Assessment unterstützt dabei, Ausgangslage und Transformationsoptionen systematisch zu bewerten und daraus Roadmap, Business Case, Projektplanung und Governance abzuleiten.
In Explore wird es konkret. In Fit-to-Standard-Workshops werden die zukünftigen Geschäftsprozesse mit den verfügbaren SAP-Standardprozessen abgeglichen.
Die zentrale Aufgabe besteht nicht darin, bestehende Abläufe möglichst detailgetreu in SAP S/4HANA nachzubauen. Vielmehr muss das Projektteam gemeinsam mit den Fachbereichen entscheiden, welche bisherigen Besonderheiten tatsächlich einen geschäftlichen Mehrwert bieten und welche lediglich historisch gewachsen sind.
Aus den fachlich begründeten Abweichungen entstehen Delta-Anforderungen für die weitere Umsetzung.
Wie aus Fit-to-Standard ein belastbares Zielbild entsteht und wie sich dabei Clean-Core-Prinzipien berücksichtigen lassen, erläutern wir im Beitrag „SAP S/4HANA Migration: Blueprint & Zielbild – Vom Verständnis zur konkreten Gestaltung“.
In Realize wird der priorisierte Backlog umgesetzt. Konfiguration, Erweiterungen, Integrationen, Datenmigration und Tests greifen dabei ineinander.
Der iterative Ansatz ist insbesondere deshalb hilfreich, weil Ergebnisse nicht erst am Ende einer langen Build-Phase sichtbar werden. Fachbereiche können frühzeitig prüfen, ob die Lösung tatsächlich den vereinbarten Anforderungen entspricht.
Einen vertiefenden Blick auf diese Phase bietet unser Beitrag „Build & Migration in der Realize-Phase“.
Deploy umfasst weit mehr als den eigentlichen Go-live-Termin. Produktionsbereitschaft, Tests, Cutover, organisatorische Vorbereitung und Hypercare müssen aufeinander abgestimmt sein.
Gerade bei komplexen Transformationen zeigt sich hier, wie gut die Arbeit aus den vorherigen Phasen zusammengeführt wurde.
Mehr dazu im Beitrag „Test, Cutover & Go-Live“.
Mit Run beginnt der produktive Lebenszyklus der neuen Lösung.
Das bedeutet nicht nur stabilen Betrieb und Support. Release-Management, Prozessoptimierung, Clean-Core-Governance und neue Innovationen werden zu kontinuierlichen Aufgaben.
Wie sich dieser Übergang gestalten lässt, behandeln wir in „Stabilisierung & Weiterentwicklung nach dem Go-live“.
Fit-to-Standard gehört inzwischen zum Vokabular nahezu jedes S/4HANA-Projekts. Das bedeutet allerdings noch nicht, dass der Ansatz überall konsequent angewendet wird.
In der Praxis erleben Projektteams immer wieder Workshops, die zwar „Fit-to-Standard“ heißen, inhaltlich aber weiterhin einer klassischen Anforderungserhebung folgen: Der Fachbereich beschreibt seinen bisherigen Prozess, anschließend wird diskutiert, wie sich dieser möglichst vollständig im neuen System abbilden lässt.
Der eigentliche Fit-to-Standard-Gedanke setzt anders an:
SAP Activate, Fit-to-Standard und Clean Core: Wie hängt das zusammen?
Ein funktionierender Standardprozess wird gemeinsam mit dem Fachbereich betrachtet. Erst wenn eine relevante Geschäftsanforderung damit nicht abgedeckt werden kann, entsteht eine Delta-Anforderung.
Diese muss anschließend fachlich bewertet und priorisiert werden.
Ein Grundsatz hilft dabei:
Nicht der SAP-Standard muss begründen, warum er verwendet wird. Die Abweichung vom Standard sollte begründen, warum sie notwendig ist.
Diese Haltung hat unmittelbare Auswirkungen auf die spätere Systemlandschaft. Jede zusätzliche Sonderlösung bringt nicht nur einmaligen Entwicklungsaufwand mit sich. Sie kann später auch Tests, Dokumentation, Wartung und Upgrades komplexer machen.
In unserem Beitrag zu Blueprint, Zielbild und Clean Core beschreiben wir deshalb, wie Abweichungen bewertet werden können: Liefert eine Anpassung tatsächlich einen geschäftlichen Mehrwert – oder wird lediglich eine historische Besonderheit in die Zukunft übernommen?
Fit-to-Standard und Clean Core werden häufig als zwei eigenständige Themen behandelt. Aus Projektsicht hängen sie unmittelbar zusammen.
Clean Core bedeutet dabei deutlich mehr als weniger Custom Code.
Ein dauerhaft wartbarer ERP-Kern betrifft ebenso Geschäftsprozesse, Erweiterungen, Integrationen, Daten und Architekturentscheidungen. Das Ziel besteht darin, die Lösung so zu gestalten, dass Upgrades, neue Releases und Innovationen nicht regelmäßig umfangreiche Nacharbeiten auslösen.
Fit-to-Standard klärt zunächst:
Wo benötigen wir überhaupt eine Abweichung vom SAP-Standard?
Clean Core stellt anschließend die zweite Frage:
Wie setzen wir die wirklich notwendigen Abweichungen so um, dass die Upgrade- und Veränderungsfähigkeit erhalten bleibt?
Das zeigt auch, warum Clean Core nicht erst nach dem Go-live relevant wird. Zu diesem Zeitpunkt sind viele der entscheidenden Architektur- und Designentscheidungen längst getroffen.
Wer einen Clean Core erreichen möchte, muss deshalb bereits während Explore und Realize entsprechende Leitplanken setzen.
Agile Projektarbeit wird in Transformationsprogrammen häufig mit Geschwindigkeit gleichgesetzt. Das ist aus meiner Sicht eine unglückliche Verkürzung.
Der eigentliche Nutzen liegt im früheren Lernen.
Statt eine große Zahl von Anforderungen lange im Voraus vollständig zu spezifizieren, wird die Lösung schrittweise aufgebaut und regelmäßig mit den Fachbereichen validiert.
Product Backlog, Sprint Reviews und eine klare Definition of Done sorgen für kurze Feedbackzyklen. Fehlannahmen werden damit früher sichtbar – zu einem Zeitpunkt, an dem Korrekturen noch deutlich weniger Aufwand verursachen.
Das funktioniert allerdings nur, wenn nicht lediglich agile Rituale eingeführt werden. Rollen, Governance und Entscheidungswege müssen ebenfalls dazu passen.
Diesen Aspekt greifen wir im Beitrag „Agilität im Banking: Warum Scrum allein nicht reicht“ ausführlicher auf.
Ein Transformationsprogramm erzeugt große Mengen miteinander verbundener Informationen: Prozessmodelle, Architekturentscheidungen, Anforderungen, Aufgaben, Tests und Releases.
Werden diese Informationen unabhängig voneinander in verschiedenen Werkzeugen gepflegt, entstehen schnell Medienbrüche und widersprüchliche Datenstände. Dann ist zwar jedes einzelne Tool sauber gepflegt, aber die Verbindung zwischen strategischer Entscheidung und konkreter Umsetzung fehlt.
Für die integrierte SAP-Toolchain lässt sich die Verantwortung vereinfacht so einordnen:
Der Nutzen entsteht nicht dadurch, möglichst viele Werkzeuge einzusetzen. Er entsteht aus ihrer Verbindung und aus klaren Verantwortlichkeiten für die jeweiligen Informationen.
Im Idealfall lässt sich eine Veränderung über eine durchgängige Kette nachvollziehen:
Business Capability → Anwendung → Geschäftsprozess → Anforderung → Umsetzung → Test → Deployment
Das ist gerade in großen Transformationsprogrammen relevant. Eine Anforderung sollte nicht nur technisch umgesetzt werden können. Es sollte auch nachvollziehbar bleiben, aus welchem Prozess und welchem geschäftlichen Ziel sie entstanden ist.
SAP Activate ist kein Einheitsrezept. Die Methodik lässt sich auf unterschiedliche Ausgangssituationen und Transition Paths anwenden.
Eine New Implementation (Greenfield) bietet den größten Spielraum, Prozesse und Strukturen neu zu gestalten und stärker am Standard auszurichten.
Bei einer System Conversion (Brownfield) wird eine bestehende SAP-Landschaft nach SAP S/4HANA überführt. Bestehende Daten, Konfigurationen und Prozesse bleiben dabei in deutlich größerem Umfang erhalten.
Eine Selective Data Transition verbindet Elemente beider Ansätze. Aus bestehenden SAP-Systemen werden gezielt Daten und Strukturen übernommen, während andere Teile neu gestaltet werden können.
Welche Variante geeignet ist, sollte deshalb nicht allein von technischen Kriterien abhängen.
Prozessreife, Custom Code, Datenqualität, Integrationskomplexität, regulatorische Anforderungen, Transformationsambition und verfügbare Zeit spielen ebenfalls eine Rolle.
Diese Kriterien haben wir im S/4HANA Migration Assessment ausführlicher gegenübergestellt.
SAP Activate und RISE with SAP werden häufig gemeinsam genannt. Sie beantworten jedoch unterschiedliche Fragen.
RISE with SAP ist ein kommerzielles Cloud- und Transformationsangebot von SAP. Unternehmen schließen dafür einen Vertrag beziehungsweise eine Subscription mit SAP ab. Das Angebot richtet sich insbesondere an bestehende SAP-ERP-Kunden, die ihre ERP-Landschaft modernisieren und in ein Cloud-Betriebsmodell überführen möchten.
RISE with SAP bündelt dabei Cloud ERP, Betriebsleistungen, Transformationsunterstützung sowie weitere Services und Werkzeuge.
SAP Activate ist dagegen kein Produkt und kein Cloud-Paket. Es ist ein methodisches Framework.
SAP Activate beschreibt, wie eine SAP-Implementierung beziehungsweise -Transformation strukturiert durchgeführt wird. Dazu gehören SAP Best Practices, Roadmaps, Workstreams, Quality Gates und die sechs Phasen von Discover bis Run.
Eine einfache Abgrenzung lautet daher:
RISE with SAP kann man kaufen. SAP Activate wendet man an.
In einem RISE-Projekt greifen beide Ebenen ineinander: Das RISE-Angebot bildet den kommerziellen und technologischen Rahmen, während SAP Activate beziehungsweise die darauf aufbauende Methodik die konkrete Projektdurchführung strukturiert.
Diese Trennung ist wichtig. Sonst werden Produktangebot, zukünftiges Betriebsmodell und Implementierungsmethodik schnell miteinander vermischt.
Ob im Projektplan offiziell „SAP Activate“ steht, ist letztlich weniger interessant als die Frage, ob die Grundprinzipien tatsächlich gelebt werden.
Aus unserer Sicht lohnt sich deshalb ein kritischer Blick auf fünf Punkte:
Wenn diese Fragen im Programm noch unterschiedlich beantwortet werden, fehlt meist nicht nur eine methodische Detailentscheidung. Häufig ist das ein Hinweis darauf, dass Zielbild und Transformationslogik noch nicht vollständig zusammenpassen.
Einen übergeordneten Einstieg in den Migrationsweg bietet unsere Seite zur SAP S/4HANA Migration – von Strategy Workshop und Assessment bis Blueprint und Umsetzung.
Mit dem Ende der Mainstream Maintenance für zentrale Anwendungen der SAP Business Suite 7 im Jahr 2027 steigt der Zeitdruck. Der Projektplan muss deshalb belastbar sein. Genauso wichtig ist aber die Frage, was nach der Migration übrig bleibt.
Ein Unternehmen kann den technischen Wechsel auf SAP S/4HANA rechtzeitig abschließen und trotzdem einen großen Teil seiner bisherigen Komplexität weiterführen. Historisch gewachsene Sonderprozesse, Eigenentwicklungen und enge Integrationen verschwinden nicht automatisch durch eine neue ERP-Plattform.
Hier liegt die eigentliche Stärke von SAP Activate.
Fit-to-Standard zwingt das Projekt, Abweichungen bewusst zu hinterfragen. Clean Core setzt Leitplanken für ihre Umsetzung. Agile Arbeitsweisen schaffen frühes Feedback. Eine integrierte Toolchain sorgt dafür, dass Entscheidungen und Anforderungen über den Projektverlauf nachvollziehbar bleiben.
Die relevante Frage lautet deshalb weniger:
"Nutzen wir SAP Activate?“
Sondern:
„Nutzen wir SAP Activate konsequent genug, um unter dem Zeitdruck Richtung 2027 nicht nur zu migrieren, sondern unsere SAP-Landschaft tatsächlich zu vereinfachen?“
Wer ausschließlich auf den rechtzeitigen technischen Systemwechsel optimiert, riskiert, die Komplexität der Vergangenheit in die nächste Plattform zu übertragen.
Wer die anstehende Migration dagegen nutzt, um Prozesse zu standardisieren, Erweiterungen sauber zu gestalten und Verantwortlichkeiten neu zu ordnen, verbindet die notwendige S/4HANA-Transformation mit einem langfristigen Ziel: einer SAP-Landschaft, die auch nach 2027 einfacher weiterentwickelt und modernisiert werden kann.
Je näher 2027 rückt, desto weniger Spielraum bleibt für grundlegende Richtungswechsel während der laufenden Umsetzung.
Ein strukturierter S/4HANA Strategy Workshop oder Assessment schafft früh Klarheit über Ausgangslage, Zielbild, Transition Path und wesentliche Projektrisiken.
movisco unterstützt Unternehmen dabei, aus dem Zeitdruck Richtung 2027 eine belastbare Transformationsstrategie zu entwickeln – vom Assessment und Zielbild bis zur strukturierten Umsetzung mit SAP Activate.
Weitere Beiträge dieses Autors
Kontakt
movisco AG
Osterbekstraße 90a
22083 Hamburg
Fon + 49 40 767 53 777
Fax + 49 40 767 53 377
E-Mail info@movisco.com
Hier können Sie uns auch antreffen:
movisco AG
Fritz-Schäffer-Straße 1
53113 Bonn
Fon + 49 40 767 53 777
E-Mail info@movisco.com
Mitarbeiterbewertungen
Zertifikate
Wir freuen uns über Ihre direkte Kontaktaufnahme!