SAP S/4HANA-Projekte gelingen mit der richtigen Vorbereitung

Die Migration verändert die Organisation tiefgreifend

Eine häufige Fehleinschätzung ist, dass man von einem reinen System-Upgrade ausgeht. Das technische Setup auf eine spaltenorientierte In-Memory-Plattform mit neuem Datenmodell, neuem Code und modernisierter Weboberfläche bildet nur die äußere Schicht des Vorhabens. Im Kern modifiziert die Migration Buchungslogiken, Stammdatenstrukturen, Berechtigungskonzepte und die Art, wie Geschäftsprozesse modelliert werden. Konsolidierte Finanzbücher, vereinheitlichte Geschäftspartnerstammdaten und rollenbasierte App-Oberflächen bringen funktionale Verschiebungen, die in die Fachbereiche hineinwirken.

Unternehmen, die das Vorhaben rein als IT-Initiative aufsetzen, übersehen die organisatorische Dimension. Prozesse, Verantwortlichkeiten und Entscheidungslogiken verändern sich. Eine Materialbuchung in einem konsolidierten Hauptbuch wirkt anders auf das Controlling als unter dem klassischen Ledger-Modell. Eine Kreditorenanlage über das vereinheitlichte Geschäftspartnerobjekt berührt zugleich Vertrieb und Einkauf. Solche Verschiebungen erfordern fachliche Entscheidungen, die ein IT-Team allein nicht treffen kann.

Daraus folgen mehrere Anforderungen an die Projektaufstellung. Der Projektauftrag braucht eine Verankerung auf Geschäftsführungsebene mit aktivem Sponsoring. Der Fachbereich braucht eine Rolle vom ersten Workshop an, nicht erst in der Testphase nach abgeschlossener Konfiguration. Die Programmsteuerung braucht ein Mandat, das auch unter Druck Standardentscheidungen gegen partikulare Sonderwünsche durchsetzt.

Altlasten und Datenbestände vor der Migration prüfen

Die meisten Bestands-ERP-Systeme sind teilweise über Jahrzehnte hinweg gewachsen. In den Tabellen liegen Belege aus Buchungsperioden, die operativ längst geschlossen sind. Im Quellcode finden sich kundenspezifische Z-Programme, Modifikationen am Standard, individuelle User Exits und Punkt-zu-Punkt-Schnittstellen, deren Geschäftslogik selten vollständig dokumentiert ist. Den Bestand unverändert in das Zielsystem zu überführen bedeutet, die alte Komplexität auf einer neuen Plattform zu replizieren.

Eine Bereinigung vor der Migration setzt an mehreren Hebeln an. Die Datenarchivierung reduziert das Volumen, das ins neue System konvertiert wird, und verkürzt Konvertierungsfenster und Testzyklen. Eine Code-Analyse über die im Standard verfügbaren Werkzeuge filtert Z-Objekte, die im Zielsystem mittlerweile abgedeckt sind, und legt obsolete Eigenentwicklungen offen. Die Prozessanalyse hinterfragt Workarounds, die im Laufe der Jahre gewachsen sind und für die das Zielsystem oft eine Standardfunktion vorhält.

Den Kern des Zielsystems schlank zu halten, also das Clean-Core-Prinzip umzusetzen, hat technische und betriebswirtschaftliche Gründe. Anpassungen am Standard erschweren spätere Release-Wechsel und blockieren Innovationen, darunter eingebettete KI-Funktionen und vorgefertigte Cloud-Erweiterungen. Erweiterungen über eine separate Cloud-Plattform und über im Standard verankerte Extensibility-Mechanismen lassen sich versionsstabil pflegen und entkoppeln Eigenlogik vom Kernsystem.

Der Implementierungsansatz prägt den Projektcharakter

Die Entscheidung zwischen Konvertierung des Bestands, Neuimplementierung und einem hybriden Vorgehen ist Grundstock das gesamte Vorhaben. Eine reine Konvertierung überführt die bekannte Lösung in das neue Datenmodell. Das Risiko bleibt überschaubar, die Veränderung in den Geschäftsprozessen fällt gering aus. Allerdings verlängern die bestehenden Eigenentwicklungen und Workarounds ihre Wirkung in das neue System hinein.

Eine Neuimplementierung beginnt mit einem leeren Mandanten und übernimmt nur Stammdaten und ausgewählte historische Bewegungsdaten. Die Prozesse werden auf Basis vorkonfigurierter Standard-Pakete neu aufgebaut. Der Aufwand ist höher, der Veränderungsdruck ist sichtbar, das Potenzial für eine modernisierte Prozesslandschaft ebenfalls.

Ein selektives Vorgehen kombiniert beide Wege. Buchungskreise oder Gesellschaften, deren Prozesse standardnah arbeiten, lassen sich konvertieren. Bereiche mit hohem Veränderungsbedarf werden neu aufgesetzt. Eine solche Vorgehensweise eignet sich für Konzerne mit heterogener Landschaft und für Unternehmen, die ihre Transformation in Wellen ausrollen wollen.

Die Auswahl folgt mehreren Kriterien. Die strategische Ausrichtung gibt vor, ob das Projekt eine IT-Modernisierung oder ein Business-Transformationsprogramm darstellt. Die Systemvoraussetzungen, also Datenqualität, Modifikationen und Schnittstellen, definieren den technischen Aufwand. Und die Bereitschaft der Anwender, sich auf Standardprozesse einzulassen, beeinflusst, wie viel Customizing am Ende vermeidbar ist.

Das Betriebsmodell richtet sich nach den Anforderungen

Parallel zur Frage des Ansatzes steht die Wahl der Bereitstellungsform. Die Public Cloud arbeitet mit kürzeren Einführungszyklen und verlagert Betrieb und Updates zum Hersteller. Anpassungen am Kernsystem sind stark eingeschränkt, was die Standardnähe erzwingt und die langfristige Wartbarkeit erleichtert. Funktional sind nicht alle Module der On-Premises-Welt deckungsgleich abgebildet.

Die Private Cloud bietet eine erweiterte Anpassungsfläche, die nahe an eine On-Premises-Umgebung heranreicht. Der Hersteller stellt eine dedizierte Umgebung bereit, das Customizing fällt breiter aus, der Innovationszyklus bleibt versionsgebunden. Eine solche Bereitstellung passt zu Unternehmen mit komplexen Prozessen, die Cloud-Vorteile bei Infrastruktur und Wartung nutzen wollen, ohne den vollen Standardrahmen der Public Cloud zu akzeptieren.

Der On-Premises-Betrieb bleibt die Wahl für Organisationen mit hohen regulatorischen Anforderungen, mit erhöhtem Schutzbedarf bei Daten oder mit branchenspezifischen Modifikationen, die in keinem Cloud-Modell unverändert abbildbar sind. Der Eigenaufwand für Betrieb, Patching und Lifecycle steigt entsprechend.

Die Wahl wirkt über die Technik hinaus auf Investitionsstruktur, Skalierbarkeit, Integration mit anderen Cloud-Diensten und auf die Frage, wie eng eine Organisation die Innovations-Roadmap der ERP-Plattform verfolgen will.

Organisation und Schulung entscheiden über die Akzeptanz

Die organisatorische Vorbereitung prägt den Projekterfolg stärker als die technische Konfiguration. Ein Vorhaben dieser Tragweite braucht ein Sponsorship auf Vorstands- oder Geschäftsführungsebene, eine Programmleitung mit ausreichendem Mandat und Schlüsselrollen. Dazu zählen Modulverantwortliche aus den Fachbereichen, eine Solution-Architekten-Funktion mit Übersicht über die Zielarchitektur und ein Datenmigrationsteam mit Tiefenkenntnis der Bestandssysteme.

Eine häufige Fehlkonstellation liegt in der Doppelbelastung interner Schlüsselpersonen. Die Key User aus Finance, Logistik, Einkauf und Vertrieb sollen das Projekt fachlich verantworten und gleichzeitig im Tagesgeschäft eingebunden bleiben. Die Folge sind verspätete Workshop-Vorbereitungen, halbherzige Testphasen und eine Konfiguration, die an den realen Abläufen vorbeiläuft. Eine Freistellung mit definierten Vertretungsregeln in der Linie sichert die Verfügbarkeit dieser Rollen.

Die Schulung der Endanwender steht in zahlreichen Projekten am Ende des Zeitplans. Mit dem Produktivstart wechselt die Belegschaft auf eine Plattform mit neuer Oberfläche, anderen Transaktionen und einem geänderten Navigationskonzept über rollenbasierte App-Kataloge. Ohne ein frühzeitiges Train-the-Trainer-Konzept, fachbereichsspezifische Lernpfade und eine Plattform für die laufende Weiterbildung nach Produktivstart bleibt die Investition in das System produktiv ungenutzt.

Methodik und Steuerung bestimmen den Projektrhythmus

Die Methodik des Projekts gibt den Takt vor. Klassische Wasserfallansätze mit vollständigem Blueprint vor jeder Umsetzung passen schlecht zur Geschwindigkeit, in der Anforderungen aus Markt und Regulatorik heute auf Unternehmen zukommen. Iterative Vorgehensweisen mit Fit-to-Standard-Workshops, kurzen Sprints in der Realisierungsphase und einem laufenden Backlog aus Delta-Anforderungen liefern frühzeitig sichtbare Ergebnisse und reduzieren den Anteil späterer Change-Request-Eskalationen.

Ein Vorprojekt vor der eigentlichen Einführung schafft die Grundlage für die Steuerung. Eine Readiness-Analyse erfasst Datenqualität, Eigenentwicklungen, Integrationslandschaft und Lizenzlage. Aus der Bestandsaufnahme leiten sich konkrete Arbeitspakete ab, jeweils mit benannten Zuständigkeiten und vorgelagerten Abhängigkeiten. Solche Vorarbeit reduziert den Anteil von späteren Überraschungen im Projekt.

Externe Unterstützung erfüllt in der Praxis mehrere Funktionen. Spezialisten ergänzen das interne Team um Wissen, das in der Stammbelegschaft selten in der nötigen Tiefe vorhanden ist. Dazu zählen Schemata für die Datenmigration, Erfahrung mit Cutover-Plänen und Kenntnis branchenspezifischer Erweiterungen. Externe können dem Top-Management außerdem Sachverhalte mitteilen, die intern aus Karriere- oder Loyalitätsgründen schwerfallen. Unrealistische Zeitlinien gehören dazu, ebenso Budgetlücken in der Schätzung. Die Auswahl des Beratungspartners verdient dieselbe Sorgfalt wie die Auswahl der Software selbst.

Fazit

S/4HANA-Projekte scheitern selten an der Technologie. Die Ursachen liegen in einer unterschätzten Tragweite, in unbereinigten Altsystemen, in zu spät einbezogenen Fachbereichen und in einer Ansatzentscheidung ohne strategische Schärfe. Eine strukturierte Vorstudie schafft die Entscheidungsbasis. Eine konsequente Reduktion von Altlogik vor der Migration verkleinert das technische Risiko. Eine bewusste Wahl zwischen Konvertierung, Neuimplementierung und selektivem Vorgehen prägt den Projektcharakter. Ein Betriebsmodell, das zur Anforderungslage passt, sichert Wartbarkeit und Investitionsschutz. Hinzu kommt die Bereitschaft, das Vorhaben als organisatorische Transformation zu führen. Eine isolierte IT-Initiative liefert die erhofften Effekte nicht.