Mit Strategie zum Erfolg: Die 8 Bausteine für Ihre SAP S/4HANA-Transformation – Teil 2

An S/4HANA transformation affects much more than the core ERP system – it impacts the entire technological ecosystem of a company. Therefore, connected satellite systems such as Business Intelligence (BI), Human Capital Management (HCM), or Enterprise Content Management (ECM) must be considered early in the planning process.

Equally critical is the choice of the target environment: whether Cloud, On-Premise, Hybrid, or part of SAP RISE or SAP GROW – each variant brings its own requirements for architecture, timing, and testing.

A comprehensive test system landscape, including all interfaces, is essential to prepare for the switch to S/4HANA. Another crucial factor is setting up a temporary project landscape. Only a dedicated transformation environment allows for efficient execution of migration, test cycles, and potential rollbacks.

Recommendation: Plan your technical transformation environment right from the start – holistically, proactively, and aligned with your target architecture. This is the only way to ensure a smooth and future-proof transition into the S/4HANA world.

Einer der wichtigsten Erfolgsfaktoren ist ein clever definierter Scope. Im Rahmen strukturierter Workshops wird definiert: Welche Daten müssen mit – und welche können archiviert oder gelöscht werden? Welche Organisationseinheiten sind betroffen? Welche Transformationen (z. B. Harmonisierung, Mappings) sind erforderlich?

Die Tools cbs Enterprise Analyzer (EA) und cbs Master Data Validation (MDV) unterstützen bei dieser Analyse mit faktenbasierten Einblicken – etwa zur Datenmenge und Nutzungshäufigkeit, aber auch zu S/4HANA Komplexitätsindikatoren wie das Fehlen essenzieller S/4HANA Must-Do-Funktionalitäten (z.B. New GL oder Material Ledger) oder zum Harmonisierungspotenzial in Bezug auf Business Partner oder auch essenzieller OneFinance Elemente. Besonders im Kontext von SAP RISE oder Public Cloud spielt der Umfang der zu migrierenden Daten eine wichtige Rolle: Ein schlankes Zielsystem sorgt nicht nur für bessere Performance, sondern hilft auch, Kosten für Infrastruktur und Lizenzen zu optimieren.

Ein präzise gesteckter Scope schafft außerdem Klarheit zwischen IT und Fachbereich und verhindert späteren Mehraufwand sowie unnötige Komplexität im Projekt. Außerdem legt er die Basis für zukünftige AI- und Machine-Learning-Funktionalitäten.

Empfehlung: Sehen Sie Scoping nicht als einmaligen Akt, sondern als iterativen Prozess – abgestimmt mit Business, IT und Compliance. Ein gut definierter Scope ist der Schlüssel zu Aufwand, Laufzeit und Projekterfolg.

Neben den essenziellen Phasen Scoping, Design und Build, besteht eine gute Strategie auch darin, dass Testzyklen frühzeitig geplant und im Projektplan eingebettet werden. Insbesondere bei der Verlagerung einer bestehenden On-Premise-Systemlandschaft zu einem Hyperscaler ist eine valide Planung zu einem frühen Zeitpunkt ausschlaggeben, um mögliche Verzögerungen in Bezug auf die Systembereitstellung vorzubeugen.

Typischerweise sieht ein SDT-Projekt drei Testphasen vor:

• Zwei Integrations-Testzyklen (inkl. Mapping-Validierung)
• ein User Acceptance Test
• optional: Regressionstests und Performance-Tests.

Wichtig ist: Jeder Testzyklus braucht klare Milestones (wie z.B. Mappingfreezes), Verantwortlichkeiten und Quality Gates. Nur so lassen sich Überraschungen beim Go-live vermeiden.

Bei einem wellenbasierten Ansatz gilt es, ein besonderes Augenmerk auf das Thema Regressionstests zu legen: Wenn einzelne Organisationseinheiten bereits live im Zielsystem arbeiten, muss sichergestellt sein, dass nachgezogene Migrationen bestehende Einheiten nicht beeinträchtigen. Gleichzeitig können durch den Einzug neuer Einheiten systemübergreifende Prozesse ins Zielsystem verlagert und verändert werden – was neue Wechselwirkungen mit sich bringt. Eine präzise Planung der Wellen sowie gezielte Regressionstests sind hier unverzichtbar, um Stabilität und Prozesskonsistenz zu gewährleisten.

Empfehlung: Integrieren Sie Ihre Testplanung eng in Ihre Gesamtprojektplanung – inklusive Ressourcen, Zeitfenster, Systemkopien und Drittanbieterkoordination. Fokussieren Sie zudem auf eine frühe Kommunikation, damit die Ressourcenverfügbarkeit gewährleistet ist.

Der letzte – und oft unterschätzte – Baustein einer erfolgreichen Transformationsstrategie ist die Cutover-Planung, also der kontrollierte Übergang in das neue System. Ziel bei der Migration mittels SDT-Ansatzes ist es, diesen Schritt so unterbrechungsfrei und reibungslos wie möglich zu gestalten, um den laufenden Geschäftsbetrieb nicht zu beeinträchtigen.

Ein zentrales Element des SDT-Ansatzes ist die direkte Übernahme von Daten auf Tabellenebene. Dadurch wird der manuelle Aufwand für Business und IT während der Cutover-Phase deutlich reduziert. Egal in welchem Status sich Belege befinden – ob offen, teilabgeschlossen oder abgeschlossen – sie können konsistent übernommen werden. Das bedeutet: Die Fachbereiche müssen nicht umfangreich in die Vorbereitungen eingebunden werden. Das spart Zeit und sichert eine verlässliche Datenbasis.

Ein weiterer Vorteil: Unsere Methode erlaubt es, den Go-live flexibel zu terminieren – unabhängig von Monats- oder Jahresabschlüssen. Und für besonders kritische Bereich bieten wir spezielle Near-Zero-Downtime-Szenarien an. Diese reduzieren die Ausfallzeit auf ein Minimum und ermöglichen selbst unter anspruchsvollsten Bedingungen einen unterbrechungsarmen Wechsel.

Empfehlung: Planen Sie den Cutover nicht als letzten Projektschritt, sondern integrieren Sie ihn frühzeitig in Ihre Gesamtstrategie. Führen Sie mehrere Testdurchläufe und Reconciliation-Checks durch und definieren Sie klare Go-/No-Go-Kriterien. Nur mit einem erprobten und strukturierten Vorgehen lässt sich ein stabiler und transparenter Übergang sicherstellen – für IT, Fachbereiche und Geschäftsführung gleichermaßen.