Sergey Tarasov - stock.adobe.com
Das SAP S/4HANA-Vorprojekt reduziert das Projektrisiko
Das Wartungsende der SAP Business Suite 7 rückt näher. Vor der Konvertierung entscheidet ein Vorprojekt darüber, ob die Migration auf S/4HANA im Zeit- und Kostenrahmen bleibt.
Der Umstieg auf SAP S/4HANA bindet Budget, Personal und Zeit über mehrere Geschäftsjahre. Ein vorgelagertes Projekt sortiert die Migrationspfade, prüft die Systemlandschaft mit dem SAP Readiness Check und bereinigt Stammdaten, Custom Code und Finance-Strukturen. So bleiben Greenfield, Brownfield und Selective Data Transition als reale Optionen für das Hauptprojekt erhalten.
SAP beendet die Mainstream-Wartung der Business Suite 7 zum Jahresende 2027 und bietet eine kostenpflichtige Extended Maintenance bis Ende 2030. Unternehmen, die den Stichtag erst spät adressieren, schieben das Kernprojekt in eine knapp bemessene Endphase. Vorprojekte verteilen die Last über mehrere Geschäftsjahre und klären Architekturfragen früh.
SAP Activate gliedert das Vorgehen in die Phasen Discover, Prepare, Explore, Realize, Deploy und Run, wobei Discover und Prepare die vorbereitenden Aktivitäten abdecken. Innerhalb dieser beiden Phasen lassen sich technische Voraussetzungen, prozessuale Lücken und organisatorische Hürden abarbeiten, ohne den Produktionsbetrieb zu belasten. Empirische Befunde aus abgeschlossenen Projekten stützen diesen Ansatz, da viele Migrationen länger dauern als geplant und höhere Kosten verursachen als ursprünglich kalkuliert.
Strategische Entscheidungen vor der ersten Codezeile
Die Discover-Phase beantwortet die grundlegende Frage nach dem Migrationspfad. SAP nennt drei offizielle Optionen. New Implementation steht für einen kompletten Neuaufbau, System Conversion für die technische Konvertierung des bestehenden ECC-Systems (ERP Central Component) und Selective Data Transition für eine selektive Übernahme einzelner Datenbereiche, Module oder Mandanten. In der Praxis stehen die Begriffe Greenfield, Brownfield und Bluefield für diese drei Wege. Marktdaten aus dem Jahr 2026 zeigen eine deutliche Verschiebung. Rund 48 Prozent der Migrationsprojekte folgen inzwischen dem selektiven Ansatz, 34 Prozent dem Brownfield-Weg und 18 Prozent der Greenfield-Variante.
Jeder Pfad hat eigene Konsequenzen für Daten, Customizing und Time-to-Value. Eine System Conversion erhält Historie, ABAP-Eigenentwicklungen und Customizing und führt das Unternehmen mit geringerem Schulungsaufwand in das neue System. Im Gegenzug wandert die angesammelte technische Schuld aus SAP ECC in die neue Landschaft. Eine Greenfield-Einführung baut Prozesse, Datenmodell und Berechtigungen neu auf, fordert dafür intensive Schulungen und einen längeren Projektzeitraum. Selective Data Transition kombiniert beide Ansätze und greift dafür auf Shell Conversion oder Mix-and-Match-Varianten zurück. Der Weg passt zu komplexen Landschaften mit Carve-outs, Fusionen oder regional unterschiedlichen Anforderungen.
Die Festlegung dieser Strategie sollte fachlich erfolgen, nicht technisch. Eine vorschnelle Wahl der Migrationsart bringt das Projekt früh in eine Sackgasse, wenn Zielprozessmodell, Datenstrategie und Customizing-Tiefe noch nicht abgestimmt sind. Genauso früh entscheidet sich das Betriebsmodell. Private Edition, Public Edition oder On-Premises ziehen unterschiedliche Update-Zyklen, Erweiterbarkeitsoptionen und Verantwortlichkeiten nach sich. Ein Vorprojekt liefert hier die Bewertungsgrundlage, statt diese Entscheidungen ins Hauptprojekt zu verlagern, wo sie unter Zeitdruck fallen.
Readiness Check und Simplification Item Catalog als Faktencheck
Der SAP Readiness Check ist das zentrale Analyseinstrument der Vorbereitungsphase. Er wertet Konfiguration, Datenbestand und Transaktionsnutzung des produktiven ECC-Systems aus und liefert eine Liste relevanter Simplification Items, eine Custom-Code-Bewertung auf hoher Aggregationsebene, eine Add-on-Kompatibilitätsprüfung sowie Empfehlungen für SAP Fiori-Apps. Ergänzend zeigt der Report Anpassungsbedarf bei aktiven Business Functions an, da SAP einzelne Funktionen als always_on, customer_switchable oder always_off klassifiziert. Eine Business Function im Status always_off im Ziel-Release verhindert die Conversion, solange sie im Quellsystem aktiv ist.
Der Simplification Item Catalog ergänzt die Vorgehensweise. Er bündelt sämtliche Vereinfachungen einer SAP S/4HANA-Version nach Anwendungsbereichen und Funktionsblöcken. Während der Readiness Check automatisch eine projektbezogene Auswahl trifft, enthält der Catalog die vollständige Sammlung. Der Readiness Check funktioniert als Planungsinstrument für die ersten Wochen, der Simplification Item Check (Report /SDF/RC_START_CHECK in den Transaktionen SE38 oder SA38) übernimmt die operative Konsistenzprüfung bis kurz vor der Downtime.
Datenbereinigung und Custom Code als Pflichtprogramm
Die wenigsten ECC-Systeme starten ohne Altlasten in die Konvertierung. Vorprojekte räumen typische Baustellen ab, bevor sie zu Blockaden werden. Dazu zählt die Umstellung auf Unicode. SAP S/4HANA setzt Unicode zwingend voraus und verlangt zudem einen reinen Application Server ABAP. Dual-Stack-Systeme mit kombiniertem ABAP- und Java-Anteil müssen vor der Conversion gesplittet werden. Auch Mandant 066 als Relikt der Early-Watch-Konfiguration sollte bereinigt sein, da er in SAP S/4HANA nicht mehr verwendet wird und Probleme bei der Jobsteuerung verursacht.
Die Custom-Code-Analyse bildet eine eigene Disziplin. Die Custom Code Migration Worklist vergleicht ABAP-Eigenentwicklungen gegen eine Datenbank der S/4HANA-Vereinfachungen und liefert Treffer für nicht mehr unterstützte Strukturen, geänderte Datenmodelle und obsolete Funktionsbausteine. Lokale Läufe des ABAP Test Cockpit mit der Checkvariante S4HANA_READINESS ergänzen die Analyse nach der technischen Conversion. Ein Vorprojekt nutzt diese Werkzeuge, um den Bestand zu konsolidieren, ungenutzten Code zu entfernen und produktiv eingesetzte Z-Programme zu bewerten. Wer hier sauber vorarbeitet, vermeidet doppelte Adaption nach dem SUM-Lauf (Software Update Manager).
Stammdaten verdienen besondere Aufmerksamkeit. Im Brownfield-Pfad wandert die vorhandene Datenqualität direkt in das neue System. Inkonsistenzen, doppelt geführte Kunden- oder Lieferantendatensätze und unvollständige Adressen verursachen nach dem Go-Live Folgekosten in Form von Korrekturläufen und manuellen Eingriffen.
Geschäftspartner und neues Hauptbuch als finanzielle Vorarbeit
In SAP S/4HANA bildet das Datenobjekt Geschäftspartner (Business Partner, BP) den verbindlichen Rahmen für Kunden- und Lieferantendaten. Die Customer-Vendor-Integration synchronisiert Bestandsdaten aus den Tabellen KNA1 und LFA1 mit dem zentralen Geschäftspartner-Stammsatz in BUT000. Der Synchronisierungsmechanismus setzt eine hohe Stammdatenqualität voraus. Die Pflege der Geschäftspartner-Rollen, Gruppierungen und Nummernkreise sowie die Richtung der Synchronisation gehören zu den vorbereitenden Konfigurationsschritten.
Der Upgradation Check Report (Programm PRECHEK_UPGRADATION_REPORT) prüft die Systembereitschaft für die BP-Migration, der Simplification Item Check sichert die Konsistenz modulübergreifend ab. Ein vorgelagertes BP-Projekt in SAP ECC reduziert die Komplexität des Hauptprojekts erheblich, da diese Umstellung erfahrungsgemäß zu den aufwendigsten Bestandteilen einer Conversion gehört.
Auch das neue Hauptbuch zählt zu den klassischen Vorprojekt-Kandidaten. SAP S/4HANA verlangt das Universal Journal mit der Tabelle ACDOCA als zentralem Speicher für Finanzbuchhaltung und Controlling. Wer von einem klassischen Hauptbuch oder vom New GL ohne Document Splitting kommt, hat in der Conversion zusätzliche Schritte zu bewältigen. Eine fachliche Reorganisation der Anlagenbuchhaltung, die Klärung paralleler Ledger für IFRS, HGB oder US-GAAP sowie die Bereinigung des Kontenplans gehören in die Vorbereitung.
Schnittstellen, Berechtigungen und Datenvolumen
Schnittstellen werden in Vorprojekten häufig unterschätzt. Externe Partneranbindungen über EDI, IDoc-Strecken zu Drittsystemen, Anbindungen an Bankenkommunikation oder Steuerbehörden bestehen oft seit Jahren ohne aktuelle Dokumentation. In der Conversion ändern sich Datenmodelle, Feldlängen und Pflichtfelder. Pricing-Konditionen wandern beispielsweise aus der KONV-Tabelle in die neue Struktur PRCD_ELEMENTS. Wer die Schnittstellenseite erst während der Realize-Phase aufmacht, riskiert Nachbesserungen unter Zeitdruck und Konflikte mit Partnern, die ebenfalls Tests durchführen müssen. Ein Vorprojekt nimmt den Bestand der Schnittstellen auf, dokumentiert Felder und Mappings und klärt, welche Partner welche Anpassungen erwarten.
Das Berechtigungswesen bildet eine eigene Baustelle. SAP S/4HANA empfiehlt den Zugang über SAP Fiori Launchpad mit rollenbasierten Katalogen und Spaces. Vorhandene PFCG-Rollen, deren Menüs auf SAP-GUI-Transaktionen ausgerichtet sind, lassen sich nicht eins zu eins übernehmen. Ein Vorprojekt prüft Rollen auf obsolete Transaktionen mit dem Report aus Transaktion SU25, identifiziert kritische Funktionstrennungskonflikte (Segregation of Duties) und konsolidiert das Rollendesign vor der Migration. Der gleichzeitige Aufbau von Frontend-Katalogen für SAP Fiori, die Replikation der App-Descriptors und die Integration der OData-Startberechtigungen in die Backend-Rollen lassen sich parallel zur Prepare-Phase planen.
Die Reduktion des Datenvolumens senkt die SUM-Laufzeit und damit die technische Downtime. Data Volume Management bietet Werkzeuge zur Simulation, zur Archivierung historischer Belege und zur Komprimierung umfangreicher Tabellen. Ein Vorprojekt definiert hier eine Strategie für Massendaten in Modulen wie FI (Financial Accounting), SD (Sales and Distribution) und MM (Materials Management). Zusätzlich planen Projektteams den Einsatz der Database Migration Option (DMO) des SUM, die Datenbankmigration und Konvertierung in einem Schritt durchführt, sowie der Silent Data Migration Infrastructure (SDMI), die Teile der Datenmigration nach dem Go-Live während des laufenden Betriebs abwickelt. Beide Mechanismen verkürzen die Downtime spürbar, setzen jedoch eine saubere Vorbereitung der technischen Benutzer voraus, die in der Transaktion SDM_USER angelegt werden.
Sandbox-Erprobung und Auswirkungen auf das Hauptprojekt
Eine technische Sandbox-Conversion liefert die belastbarste Grundlage für die spätere Realize-Phase. Eine Kopie des produktiven ECC-Systems wird in einer abgeschotteten Umgebung in das Ziel-Release überführt. Dabei lassen sich Erfahrungswerte zu Laufzeiten, Speicherbedarf, Custom-Code-Verhalten und konkreten Konfigurationsschritten herausfinden. Transportaufträge mit Customizing-Anpassungen aus der Sandbox lassen sich später dem produktiven Lauf beifügen und sparen Arbeitsaufwand. Auch der Solution Manager und SAP Cloud ALM unterstützen die Sandbox-Erprobung mit Testautomatisierung, Defect-Tracking und Projekt-Cockpits.
Die Wirkung des Vorprojekts auf das Hauptprojekt ist messbar. Die Realize-Phase verläuft kalkulierbarer, da Blocker im SI-Check vorab eliminiert wurden und das Stammdatenvolumen reduziert ist. Die Downtime sinkt durch DMO und SDMI, der Custom-Code-Aufwand nach dem SUM-Lauf verteilt sich auf vorab gesetzte Korrekturpakete. Die Datenmigration in Finance läuft entlang der Sandbox-Ergebnisse, was kostspielige Nacharbeiten im produktiven Lauf vermeidet.
Ein Vorprojekt ersetzt das Kernprojekt nicht. Es liefert die Voraussetzungen, unter denen das Kernprojekt in einem realistischen Zeit- und Kostenrahmen gelingt. Die Wahl der Migrationsstrategie, die Sauberkeit der Stammdaten, der Zustand des Custom Code, die Vorbereitung von Finance, das Rollendesign und die Schnittstellen entscheiden über den Verlauf der Realize-Phase deutlich stärker als die rein technische Ausführung mit dem SUM.
