Zum Hauptinhalt springen

Strategische S/4HANA-Vorbereitung:
Was vor dem Start zählt

Eine S/4HANA-Migrationsstrategie vor dem Projektstart abzusichern bedeutet, zehn konkrete Entscheidungen zu treffen, bevor der erste externe Implementierungspartner beauftragt wird. Diese Entscheidungen betreffen Zielbild und Business Case, Migrationsansatz, Prozessklassifizierung, Systemlandschaft und Schnittstellen, Datenqualität, Custom Code, Ressourcenplanung, Teststrategie, Change Management und Governance-Strukturen. Wer hier zu früh ins Umsetzen geht, zahlt später oft doppelt.

Checkliste und Entscheidungen für die S/4HANA-Migration vor dem Projektstart

Das Wichtigste auf einen Blick

  • Strategie vor Umsetzung: Zielbild, Migrationsansatz und Governance müssen vor dem Kick-off schriftlich vorliegen, nicht danach.
  • Datenqualität ist kein reines IT-Thema: Die fachliche Abnahme durch Data Owner aus Finance, Einkauf, Vertrieb und Logistik ist unverzichtbar. Technische Fehlerfreiheit allein reicht nicht.
  • Custom Code zuerst eingrenzen: Nutzung über mindestens ein Jahr messen, ungenutzten Code identifizieren und stilllegen, bevor Anpassungsaufwände geschätzt werden.
  • Migrationsansatz begründen: Brownfield, Greenfield oder Hybrid entscheidet sich anhand von Prozessreife, Datenqualität, Zeitrahmen und Veränderungsbereitschaft, nicht aus Präferenz.
  • Governance ist keine Formalie: Ohne klare Entscheidungsbefugnisse und Eskalationswege vor Projektstart fehlt dem Lenkungsausschuss die Grundlage für belastbare Entscheidungen.

Warum S/4HANA-Projekte so oft Budget und Zeitplan verfehlen

Mehr als 60 Prozent der Unternehmen melden bei ihrer S/4HANA-Migration Abweichungen bei Budget, Zeitplan und Ergebnisqualität. Das zeigt die Horváth-Studie „Business Transformation Unlocked“ unter 200 SAP-Anwenderunternehmen ab 200 Millionen Euro Jahresumsatz (Befragung im ersten Quartal 2025). Die Projekte dauerten im Schnitt 30 Prozent länger als geplant, und nur acht Prozent der bereits abgeschlossenen Projekte blieben im Zeitplan (Computerwoche).

Der ISG-Report „The State of SAP Migrations“ zeichnet ein ähnliches Bild: Fast 60 Prozent der Migrationen liegen hinter Zeit- und Budgetplan. ISG führt die Verzögerungen eher auf schwache Governance als auf technische Herausforderungen zurück (Bericht der Computerwoche, Februar 2026).

Als Hauptgründe für die Abweichungen nennen die Horváth-Befragten:

  • Erweiterung des Projektumfangs im Projektverlauf
  • Schwächen im Projektmanagement
  • unterschätzte Test- und Datenmigrationsphasen
  • Überarbeitungsschleifen bei Konzepten und Prozessen
  • mangelnde Entscheidungsfindung

Das sind überwiegend Fragen von Planung und Steuerung, keine reinen Technikprobleme. Die Studienautoren sehen die Wurzel vieler Probleme bereits im Programm-Setup: Komplexität und Ressourcenbedarf werden unterschätzt, die eigene Organisationskompetenz wird überschätzt. Drei Viertel der befragten Führungskräfte sagen außerdem, dass Auswahl und Verfügbarkeit des Projektpersonals vorab nicht genug Beachtung finden.

In der Praxis zeigt sich das so: Projekte starten, bevor Ziele, Nutzen und Abgrenzung verbindlich definiert sind. Das erzeugt Umfangszuwachs, der sich später kaum noch eindämmen lässt. Gleichzeitig entstehen unrealistische Zeit- und Budgetpläne, weil Aufwände für Prozessharmonisierung, Datenbereinigung, Tests und Change Management unterschätzt werden.

Wer ohne belastbares Zielbild startet, behandelt eine S/4HANA-Migration wie ein technisches Upgrade. Sie ist eine geschäftliche und organisatorische Transformation, die technisch umgesetzt wird. Dieser Unterschied bestimmt, ob ein Unternehmen am Ende ein steuerbares Projekt hat oder ein Vorhaben, das täglich neu verhandelt werden muss.

S/4HANA-Migrationsstrategie vor Projektstart absichern: Risikoanalyse als Ausgangspunkt

Eine fundierte S/4HANA-Risikoanalyse vor Projektstart muss zwei Fragen klar beantworten:

  • Welche Entscheidungen kann das Unternehmen heute noch treffen, ohne großen Aufwand?
  • Welche Entscheidungen werden deutlich teurer, wenn sie erst während der Implementierung getroffen werden?

Diese Trennung zwischen technischer Bereitschaft und strategischer Reife ist der eigentliche Ausgangspunkt jeder soliden Vorbereitung.

Brownfield, Greenfield oder Hybrid: Warum diese Entscheidung nicht warten kann

Die Wahl des Migrationsansatzes ist keine technische Feinheit. Sie bestimmt Projektlaufzeit, Budget, Datenanforderungen und den Umfang organisatorischer Veränderungen. Wer diese Entscheidung aufschiebt oder aus Zeitdruck trifft, ohne die eigene Ausgangslage zu analysieren, kauft sich Probleme ein, die später nur mit hohem Aufwand zu korrigieren sind.

Als erste Orientierung gilt: „Alles funktioniert und muss schnell migriert werden“ spricht für Brownfield. „Wir wollen grundlegend anders arbeiten“ spricht für Greenfield. „Ein Teil soll bleiben, ein Teil soll neu werden“ weist in Richtung Hybrid. In der Praxis sollte die Entscheidung anhand einer gewichteten Bewertung getroffen werden, nicht anhand einer Daumenregel allein.

Kriterium Brownfield Greenfield Hybrid
Bestehende Prozesse stabil und weiterhin passend ineffizient oder grundlegend neu zu gestalten teils bewahrenswert, teils neu
Datenqualität sauber und vollständig hoher Bereinigungsbedarf Kernbestand wird übernommen
Geschwindigkeit tendenziell kurze Umstellungszeit längere Vorbereitungsphase mittlerer Zeitbedarf
Transformationstiefe technische Modernisierung strategische Neuausrichtung gezielte Transformation
Typischer Anlass schnelle technische Migration Clean Core, Standardisierung M&A, Carve-out, Konsolidierung

Die Tabelle zeigt Tendenzen, keine festen Regeln: Sie beschreibt, unter welchen Bedingungen ein Ansatz eher passt. Die Gewichtung der Kriterien hängt vom Einzelfall ab.

Was bei falscher Wahl teuer wird: Wer sich für Brownfield entscheidet, ohne die tatsächliche Prozessreife zu prüfen, zieht bestehende Ineffizienzen und Datenaltlasten direkt in das neue System. Wer Greenfield wählt, ohne ausreichend Zeit und Budget einzuplanen, riskiert, an der organisatorischen Veränderungsarbeit zu scheitern. Die Wahl des Migrationsansatzes hängt direkt von Datenqualität und technischer Ausgangslage ab. Wer beides nicht kennt, trifft eine Entscheidung im Blindflug.

Datenqualität: Welche Prüfungen vor dem Projektstart abgeschlossen sein müssen

Unterschätzte Datenmigrationsphasen zählen zu den Hauptgründen, warum S/4HANA-Projekte teurer und langsamer werden als geplant (Horváth). Die meisten Probleme tauchen nicht erst beim technischen Ladevorgang auf. Sie entstehen, weil Unternehmen die Datenprüfung zu spät beginnen und dann unter Zeitdruck migrieren, was migrierbar ist, nicht was migriert werden sollte. Im Brownfield-Pfad wandert die vorhandene Datenqualität direkt in das neue System (Computer Weekly).

Die kritischen Prüffelder umfassen:

  • Vollständigkeit bei Pflichtfeldern, Geschäftspartnern, Materialstämmen, offenen Posten und Anlagenwerten.
  • Eindeutigkeit durch Dubletten-Analysen für Kunden, Lieferanten und Materialien.
  • Konsistenz zwischen Stamm- und Bewegungsdaten.
  • Aktualität durch Identifikation veralteter oder nie verwendeter Datensätze.

Dazu kommt ein S/4HANA-spezifisches Thema: die Umstellung von Kunden- und Lieferantenstämmen auf den Geschäftspartneransatz. In S/4HANA ist der Geschäftspartner das verbindliche Stammdatenobjekt. Die Customer-Vendor-Integration (CVI) synchronisiert die Bestandsdaten mit dem zentralen Geschäftspartner-Stammsatz und setzt eine hohe Stammdatenqualität voraus. Rollen, Gruppierungen, Nummernkreise und die Synchronisationsrichtung gehören zu den vorbereitenden Konfigurationsschritten (Computer Weekly).

Technische Fehlerfreiheit allein reicht nicht aus. Die fachliche Abnahme durch Data Owner aus Finance, Einkauf, Vertrieb und Logistik ist unverzichtbar, weil technisch sauber gemappte Daten fachlich trotzdem falsch sein können. Kontrollsummen und Mengengerüste müssen vorab definiert werden, damit jeder Simulationslauf quantitativ und qualitativ abgeglichen werden kann.

Die empfohlene Reihenfolge für die Datenqualitätsprüfung vor S/4HANA:

  1. Inventur
  2. Profiling
  3. Bereinigung
  4. Mapping
  5. Simulationsläufe
  6. Fachliche Freigabe

Custom Code und Schnittstellen frühzeitig analysieren

Der erste Schritt beim Custom Code ist nicht Anpassen, sondern Eingrenzen. Historisch gewachsene SAP-Landschaften enthalten regelmäßig mehr kundenspezifischen ABAP-Code, als irgendjemand im Unternehmen noch überblickt. Ungenutzter Code muss identifiziert und stillgelegt werden, bevor Anpassungsaufwand geschätzt wird. Das entspricht dem Vorgehen, das SAP selbst empfiehlt: erst ungenutzten Code bereinigen, dann den Rest gegen die Simplification Database prüfen (SAP Community).

Ablauf der Custom-Code-Analyse: 1. Nutzung messen (SCMON und SUSG, alternativ UPL), 2. Auswirkungen prüfen (Fiori-App Custom Code Migration), 3. je Objekt entscheiden: eliminieren, anpassen, optimieren, neu implementieren oder beibehalten.

SCMON erfasst und SUSG aggregiert die Nutzung. Danach prüft die Fiori-App Custom Code Migration den genutzten Code, und je Objekt fällt eine Behandlungsentscheidung.

Schritt 1: Nutzung messen. SAP empfiehlt, die Nutzung mit dem ABAP Call Monitor (SCMON) zu erfassen. SCMON hält seine Daten standardmäßig nur etwa sieben Tage vor, deshalb werden sie im Produktivsystem fortlaufend mit der Transaktion SUSG aggregiert (SAP-FAQ).

SUSG verarbeitet ausschließlich SCMON-Daten. Das Usage and Procedure Logging (UPL) ist die ältere Alternative; seine Daten werden im SAP Solution Manager (BW) aggregiert. SAP bezeichnet SCMON als empfohlenen Nachfolger von UPL (SAP-FAQ).

Die Nutzungsdaten sollten mindestens ein Jahr lang gesammelt werden, damit auch selten genutzter Code, zum Beispiel aus Jahresabschlussprozessen, nicht fälschlich als ungenutzt gilt (SAP Community).

Schritt 2: Auswirkungen prüfen. Die verbleibenden Objekte werden gegen die Simplification Database geprüft. SAP empfiehlt dafür die Fiori-App „Custom Code Migration“: Sie führt die S/4HANA-Prüfungen auf Basis der Remote-ATC-Infrastruktur durch und berücksichtigt die Nutzungsdaten. Sie läuft in einem S/4HANA-System ab Release 1809 oder in der SAP BTP ABAP Environment (SAP Community). Steht kein solches System bereit, lässt sich alternativ die SAP-GUI-basierte Remote-ATC-Infrastruktur mit einem zentralen ATC-Prüfsystem nutzen (SAP-FAQ).

Das ABAP Test Cockpit (ATC) bildet die technische Grundlage der statischen Analyse. Mit einem zentralen Prüfsystem für die gesamte Landschaft (Remote Code Analysis) zeigt es Kompatibilitätsprobleme und HANA-spezifische SQL-Schwächen auf. Cloud-Readiness-Prüfungen decken zusätzlich Verstöße gegen die Clean-Core-Vorgaben von ABAP Cloud auf, etwa die Nutzung nicht freigegebener APIs (SAP Community).

Schritt 3: Behandlungsentscheidung je Objekt. Für jedes Objekt braucht es eine klare Entscheidung: eliminieren, anpassen, optimieren, neu implementieren oder beibehalten. Technische Befunde allein reichen dafür nicht. Nutzungshäufigkeit, Geschäftskritikalität, Risiko und Änderungsaufwand müssen gemeinsam bewertet werden. Diese Entscheidungen vor Projektstart zu treffen ist entscheidend, weil Änderungen in der Implementierung erfahrungsgemäß deutlich mehr kosten.

Schnittstellen und Drittanwendungen. Gleiches gilt für Schnittstellen und Drittanwendungen: Historisch gewachsene Landschaften enthalten Modul- und Systemabhängigkeiten, die im Projektplan regelmäßig unterschätzt werden. In der Horváth-Studie nennen 23 Prozent der Befragten mangelndes Wissen und fehlende Dokumentation über Third-Party-Systeme und Schnittstellen als eine der größten Herausforderungen (Computerwoche).

Governance: Welche Strukturen vor dem Kick-off schriftlich vorliegen müssen

Ein Lenkungsausschuss ist kein Selbstläufer: Er steuert nur, wenn er entscheidbare Vorlagen bekommt, klare Genehmigungsschwellen kennt und weiß, wer bei Eskalationen zuständig ist. Ohne diese Grundlage passiert, was in der Praxis häufig zu sehen ist: IT und Fachbereiche kommunizieren aneinander vorbei, Prioritäten werden täglich neu verhandelt, und Grundsatzfragen werden in die Implementierung verschoben, wo Änderungen deutlich teurer werden.

Auch ISG sieht in unklaren Entscheidungsrechten, Akzeptanzkriterien und Verantwortlichkeiten eine Ursache für Scope Creep und Verzögerungen. Der Report rät, Governance als zentrales Instrument der Risikominimierung zu begreifen und nicht als rein administrative Funktion (Computerwoche).

Die Mindestdokumente, die vor dem Kick-off schriftlich vorliegen müssen:

  • ein Projektauftrag mit Zielen, Umfang und Erfolgskriterien
  • eine RACI-Matrix für zentrale Ergebnisse und Entscheidungen
  • ein Stakeholder-Register samt Kommunikationsplan
  • ein Risiko- und Eskalationsprozess mit benannten Risikoeigentümern und Eskalationsgrenzen
  • ein Änderungs- und Berichtskalender

Das Startkriterium ist einfach formuliert: Keine kritische Aufgabe ohne verantwortliche Person. Keine kritische Entscheidung ohne befugtes Gremium. Kein wesentliches Risiko ohne benannten Risikoeigner. Wer dieses Prinzip vor Projektstart durchsetzt, schafft eine zentrale Voraussetzung dafür, dass ein Lenkungsausschuss tatsächlich steuern kann.

Die 10 Prüfpunkte: Checkliste zur Absicherung Ihrer S/4HANA-Migrationsstrategie

Bevor ein Implementierungspartner beauftragt wird, sollten diese zehn Punkte abgehakt sein. Nicht als Formalie, sondern als Nachweis, dass die wichtigsten Entscheidungen tatsächlich getroffen wurden.

  1. Zielbild und Business Case verbindlich dokumentiert.
  2. Migrationsansatz nach strukturierter Analyse gewählt: Brownfield, Greenfield oder Hybrid.
  3. Prozesse klassifiziert: beibehalten, optimieren oder neu gestalten.
  4. Systemlandschaft und Schnittstellen vollständig erfasst.
  5. Datenqualitätsanalyse abgeschlossen, Bereinigungsplan vorhanden.
  6. Custom-Code-Inventur mit Nutzungsanalyse (Nutzungsdaten über mindestens ein Jahr) und Behandlungsentscheidung je Objekt.
  7. Ressourcen für Fachbereiche und IT realistisch geplant und bestätigt.
  8. Validierungs- und Teststrategie für S/4HANA sowie Cutover-Konzept in Grundzügen definiert.
  9. Change-Management-Bedarf identifiziert, Schulungsplanung begonnen.
  10. Governance-Dokumente unterzeichnet, Lenkungsausschuss konstituiert.

Externe Unterstützung kann in dieser Phase sinnvoll sein, wenn Klarheit über Struktur, Verantwortlichkeiten und Risikoeinschätzung gefragt ist, bevor Implementierungspartner beauftragt werden. Ein Berater ohne wirtschaftliches Interesse an einem bestimmten Werkzeug oder Ansatz kann diese Fragen mit mehr Abstand bewerten. Project-Enabler begleitet Unternehmen genau in dieser Phase: beim Aufsetzen einer belastbaren Migrationsstrategie, ohne die interne Projekthoheit abzugeben.

Wer diese zehn Punkte vor dem Start klärt, hat keine Garantie für ein problemfreies Projekt. Aber er vermeidet die teuersten Fehler.

Fazit: Vorbereitung ist eine Führungsaufgabe

Die S/4HANA-Migrationsstrategie vor Projektstart zu sichern ist keine Fleißaufgabe, sondern eine Führungsaufgabe. CFOs und CIOs, die diese zehn Prüfpunkte vor dem Kick-off konsequent klären, treffen Entscheidungen zu dem Zeitpunkt, zu dem sie noch kalkulierbar sind. Wer das auf die Implementierungsphase verschiebt, zahlt den Aufschlag in Form von Nacharbeiten, Eskalationen und Budgetüberschreitungen.

Die zehn Prüfpunkte aus diesem Artikel sind eine sofort nutzbare Grundlage für interne Diskussionen auf Leitungsebene. Sie ersetzen keine detaillierte Vorstudie, aber sie zeigen, welche Fragen beantwortet sein müssen, bevor das Projekt startet. Für Unternehmen, die dabei eine externe Einschätzung suchen, steht Project-Enabler als Berater bereit. Nehmen Sie Kontakt mit uns auf, bevor der erste Implementierungspartner beauftragt wird.

Sie benötigen Unterstützung

Häufig gestellte Fragen

Welche Werkzeuge empfehlen sich zur Eingrenzung und Analyse von Custom Code vor dem Projektstart?

Wir empfehlen das von SAP vorgesehene Vorgehen. Die Nutzung wird mit dem ABAP Call Monitor (SCMON) erfasst und im Produktivsystem mit der Transaktion SUSG aggregiert. Als ältere Alternative steht das Usage and Procedure Logging (UPL) mit Aggregation im SAP Solution Manager zur Verfügung. Die Nutzungsdaten sollten mindestens ein Jahr lang gesammelt werden.

Anschließend prüft die Fiori-App „Custom Code Migration“ die verbleibenden Objekte auf Basis der Simplification Database und des ABAP Test Cockpits (Remote Code Analysis) auf S/4HANA-Auswirkungen und berücksichtigt dabei die Nutzungsdaten. Für jedes Objekt wird danach entschieden: eliminieren, anpassen, optimieren, neu implementieren oder beibehalten.

Was passiert, wenn die zehn Prüfpunkte nicht vor der Beauftragung eines Implementierungspartners geklärt sind?

Dann drohen unkontrollierter Umfangszuwachs, unrealistische Zeit- und Budgetpläne sowie teure Nacharbeiten und Eskalationen. Wir stellen fest, dass fehlende Zielbilder und unklare Verantwortlichkeiten dazu führen, dass Grundsatzfragen in die Implementierungsphase verschoben werden, wo Änderungen deutlich teurer sind. Auch die Befragten der Horváth-Studie nennen die Erweiterung des Projektumfangs und mangelnde Entscheidungsfindung als Hauptgründe für Abweichungen.

Sind die Prüfpunkte geklärt, ist das keine Garantie für ein problemfreies Projekt. Aber die teuersten Fehler lassen sich vermeiden.

Quellen