Die besten SAP-Einführungsstrategien, um teure Fehler zu vermeiden

Die beste SAP-Einführungsstrategie ist die, die zu Ihrem Unternehmen passt und die Ihr Team durchhalten kann. Sie läuft auf drei Entscheidungen hinaus. Erstens das Bereitstellungsmodell: S/4HANA Cloud Public Edition (meist über GROW with SAP), Private Edition (meist über RISE with SAP) oder On-Premise. Zweitens der Migrationspfad: Greenfield, Brownfield oder Bluefield. Und drittens das Rollout-Muster: Big Bang, phasenweise oder hybrid. Dieser Leitfaden richtet sich an CIOs, Programmleiter und Sponsoren, die einen Ansatz für S/4HANA wählen. Beantworten Sie die fünf Fragen unten, treffen Sie zuerst die Entscheidung zum Bereitstellungsmodell und legen Sie dann mit der Vergleichstabelle und dem Entscheidungsbaum die beiden anderen fest.

Über die 21 Programme, an denen ich gearbeitet habe, sind die Muster konsistent. Die Strategiewahl ist real, aber sie ist die kleinere Hälfte der Entscheidung. Die größere Hälfte ist die Frage, ob das Team die Disziplin über 14 Monate Umsetzung durchhält, wenn die Optionstabelle längst abgelegt ist.

Das Ziel ist nicht die schnellste oder günstigste Option. Es ist der Ansatz, der zum Unternehmen passt: zu Struktur, Kultur, Tempo, regulatorischem Profil und langfristigen Zielen.

Fünf Fragen vorab

1. Wie komplex ist Ihre Struktur: eine Gesellschaft, mehrere Gesellschaften, mehrere Länder?
2. Brauchen Ihre Teams Zeit, um sich umzustellen, oder sind sie jetzt bereit für den Wandel?
3. Kommen Sie von mehreren Altsystemen, von einem ERP oder starten Sie bei null?
4. Haben Sie internes SAP-Know-how, oder sind Sie auf Partner angewiesen?
5. Wie viel Störung können Sie beim Go-live verkraften?

Eine allgemeingültige Antwort gibt es nicht. Ihre Strategie sollte Ihre Realität abbilden, nicht die Erfolgsgeschichte eines anderen.

Was sich zwischen 2023 und 2026 geändert hat

RISE und GROW sind zu den Standardwegen geworden, S/4HANA in der Cloud zu kaufen. RISE with SAP bündelt die Software (meist Private Edition), von SAP betriebene Infrastruktur und technischen Betrieb sowie BTP-Credits in einem Abonnement. GROW with SAP bündelt die Public Edition für mittelgroße Unternehmen mit Standardprozessen. Das klassische Modell „erst Lizenz, dann Implementierung“ gibt es für On-Premise weiterhin, aber die meisten neuen Gespräche beginnen mit RISE oder GROW.

Clean Core ist vom Ratschlag zur Architektur geworden. In der Public Edition können Sie den Kern nicht verändern: Erweiterungen nutzen freigegebene APIs, entweder On-Stack mit ABAP Cloud oder Side-by-Side auf SAP BTP. In der Private Edition und On-Premise geht das weiterhin, aber SAPs Leitlinie behandelt Modifikationen als letztes Mittel, weil jede Modifikation zusätzlichen Upgrade-Aufwand erzeugt. Partner ohne Clean-Core-Erfahrung erzeugen vom ersten Tag an technische Schulden.

KI ist in den Werkzeugen für die Projektumsetzung angekommen. SAP Joule for Consultants (allgemein verfügbar seit Mai 2025) beantwortet Konfigurationsfragen aus SAPs eigenen Inhalten. SAP Cloud ALM kann aus Transkripten von Fit-to-Standard-Workshops Anforderungen entwerfen. SAP Build Code (allgemein verfügbar seit März 2024) nutzt Joule, um Java- und JavaScript-Erweiterungen zu generieren, und Joule for developers hat ab Ende 2024 die Generierung und Erklärung von ABAP-Code ergänzt. Nichts davon ändert die strategische Wahl. Es ändert Kosten und Zeit innerhalb der jeweils gewählten Variante.

Woran Strategien gelingen oder scheitern

Die Umsetzung zählt mehr als die Wahl. Vier Fehlermuster tauchen auf, egal welcher Ansatz gewählt wurde.

1. Engagement der Führungsebene, das verschwindet. Bei einer S/4HANA-Einführung für eine Bank kam der CEO zu jedem wichtigen Meeting, stellte gute Fragen und stärkte dem Team den Rücken. Das Projekt wurde pünktlich fertig und kostete weniger als geplant. Die Führungskräfte einer Ladenkette gaben nach dem Kick-off alles ab. Das Projekt stand monatelang still, weil niemand Entscheidungen treffen konnte.
2. Datenmigration als IT-Aufgabe behandelt. Ein Kunde bestand darauf, seine Produktstammdaten seien „sauber genug“. Am ersten Tag erhielt sein Lager Aufträge für Produkte, die seit drei Jahren ausgelaufen waren. Die Bereinigung dauerte Wochen und kostete ihn einen Großkunden. Die Datenmigration braucht Verantwortung im Fachbereich.
3. Schulung ausgelassen oder verkürzt. Ich besuchte ein Büro zwei Wochen nach dem SAP-Start. Das Rechnungswesen hatte Haftnotizen mit Erinnerungen für einfache Aufgaben rund um die Monitore geklebt; es hatte einen einzigen Tag Schulung gehabt. Der Teamleiter sagte mir: „Wir versuchen nur, zu überleben.“ Dieses Unternehmen gab im ersten Jahr zusätzliche 200.000 US-Dollar für Support aus.
4. Menschen, die das System umgehen. Ich arbeitete mit einer Fabrik, die Schulung für ausreichend hielt. Die Mitarbeiter trauten dem neuen System nicht und gingen zurück zu Tabellenkalkulationen. Das nach dem Go-live zu beheben, war teuer. Change-Management heißt Kommunikation, Einbindung und Fürsprecher im Fachbereich; die Schulung ist nur ein Teil davon.

Die zwei wichtigsten Rollout-Muster

Big Bang

• Alles geht in einem Cutover live
• Schnellster Weg zu standardisierten Prozessen
• Geringere Anfangskosten, höheres Risiko am ersten Tag
• Verlangt straffe Proben und saubere Daten

Phasenweise

• Live in Wellen nach Modul, Region oder Funktion
• Mehr Spielraum zur Kurskorrektur zwischen den Wellen
• Längere Supportkosten, mehr Integration zu pflegen
• Verlangt anhaltende Disziplin und Governance

Big Bang

Ich war einmal beim SAP-Go-live eines Fertigungsunternehmens dabei, bei dem an einem Wochenende alles umgestellt wurde. Finanzen, Einkauf, Vertrieb und Fertigung gingen am Montagmorgen live. Es war intensiv, aber die Klarheit war stark. Alle bewegten sich gemeinsam, und es gab keine Unsicherheit darüber, welchem System oder welchen Daten man trauen sollte.

Was es gelingen ließ: Das Team probte den Cutover mehrfach, bereinigte die Daten Wochen vorher und schulte die Anwender an realen Testfällen. Der Vorteil sind schnellere Abstimmung und schnellere Erträge. Der Nachteil ist, dass es keinen Spielraum für Fehler gibt. Als am ersten Tag ein Preisproblem die Kundenaufträge traf, traf es jede Region.

Funktioniert, wenn: die Prozesse standardisiert sind, die Teams vorbereitet sind und die Führung beim Umfang hart bleibt.

Phasenweise

In einem anderen Projekt, bei einer Handelskette, gingen wir phasenweise vor: zuerst Finanzen, Personal und Einkauf, dann Logistik und Point of Sale. Es dauerte über ein Jahr, gab den Teams aber Luft zum Atmen. Das Personalteam verbrachte seinen ersten Monat damit, Workflows zu klären, bevor alle anderen geschult wurden. Bei einem Big Bang wäre das nicht möglich gewesen.

Der Kompromiss ist eine längere Supportphase, und Daten, die zwischen produktiven und noch nicht produktiven Systemen fließen, brauchen besondere Sorgfalt.

Funktioniert, wenn: die Organisation groß oder verteilt ist, die Prozesse je Region variieren oder die Führung Spielraum zur Kurskorrektur will.

Hybrid

Manchmal ist die Antwort beides.

Ein Distributor für Unterhaltungselektronik in Großbritannien, mit dem ich arbeitete, brauchte Finanzen und Einkauf schnell live. Sein Lager war wegen zu vieler Abhängigkeiten nicht bereit. Also gingen Finanzen und Einkauf zuerst, Logistik und Lagerwirtschaft folgten. Big Bang in einem Bereich, phasenweise in einem anderen.

Hybrid bringt Koordinationsaufwand mit sich. Wenn der Einkauf in SAP läuft und der Vertrieb nicht, muss die Datensynchronisation zwischen beiden sorgfältig gestaltet werden, und die Governance muss durchgehend scharf bleiben.

Funktioniert, wenn: Geschäftsbereiche unterschiedlich schnell vorankommen, einzelne Abteilungen schneller umstellen müssen oder saisonale Spitzen bestimmte Go-live-Termine ausschließen.

So schneiden die drei im Vergleich ab:

Kriterium	Big Bang	Phasenweise	Hybrid
Zeitplan	Am kürzesten: alles auf einmal	Länger: auf Wellen verteilt	Mittel: einige Bereiche schnell, andere langsamer
Geschäftsunterbrechung	Hoch, wenn der Go-live Probleme hat	Geringer: der Wandel geschieht schrittweise	Hoch in der ersten Welle, danach geringer
Risiko	Probleme treffen das ganze Unternehmen	Probleme bleiben innerhalb einer Phase	Konzentriert auf die Big-Bang-Teile
Kosten	Geringer am Anfang, Fehler sind teuer	Insgesamt höher, weniger Notfälle	Dazwischen; die Koordination ist der Unsicherheitsfaktor
Datenmigration	Ein Fenster; muss vollständig sein	Geteilte Ladungen, weniger pro Phase	Schnittstellen zwischen produktiven und noch nicht produktiven Systemen sind die Hürde
Anwenderakzeptanz	Schwierig: Umstellung über Nacht	Leichter: schrittweise Gewöhnung	Die erste Welle sind die Pioniere; spätere Wellen lernen von ihnen
Beste Eignung	Kleinere Organisationen, Standardprozesse, hohe Bereitschaft	Große, verteilte Unternehmen mit unterschiedlichen Prozessen	Organisationen mit mehreren Einheiten, in denen einige bereit sind und andere nicht

Decide

Welcher Migrationspfad passt zu Ihrer Situation?

Die Altlandschaft ist fragmentiert und Sie wollen Prozesse neu gestalten

→Greenfield

Prozesse sind solide, ECC ist stabil, die Historie muss bleiben

→Brownfield

Mehrere Gesellschaften, teilweise Wiederverwendung und selektive Daten gewünscht

→Bluefield

Greenfield: neu starten

Diesen Ansatz habe ich in einem Projekt für ein Handelsunternehmen erlebt, das durch Übernahmen schnell gewachsen war und dessen Systeme fragmentiert waren. Wir starteten sauber und gestalteten einheitliche Prozesse auf S/4HANA. Teams, die ihre eigenen Wege gewohnt waren, wehrten sich zuerst. Das Ergebnis war mehr Konsistenz über die Regionen hinweg, ein sauberes Reporting und Systeme, die miteinander sprachen.

Einsetzen, wenn: die Altsysteme zu fragmentiert oder zu stark angepasst sind, um sie sauber zu migrieren, und das Unternehmen neu überdenken will, wie es arbeitet, statt alte Gewohnheiten zu digitalisieren.

Brownfield: konvertieren und aktualisieren

In einem meiner früheren Projekte, bei einem Fertigungsunternehmen, war Brownfield die richtige Wahl. Der Kunde hatte sein ECC-System stark angepasst, und ein Neustart erschien zu riskant. Wir konzentrierten uns auf die technische Konvertierung nach S/4HANA. Die Anwender fanden sich schneller zurecht, und wir gingen früher live, aber wir übernahmen umständliche Workflows, die man hätte neu gestalten sollen.

Einsetzen, wenn: die bestehenden Prozesse solide und dokumentiert sind, die Bewegungshistorie für Revision oder Compliance wichtig ist, Budget oder Zeit knapp sind und die Organisation sich nicht umstrukturiert.

Bluefield: selektive Transition

Bluefield (selektive Datenübernahme) verlagert bestimmte Buchungskreise, Geschäftsbereiche oder Zeiträume statt alles. Es eignet sich für Unternehmen, die durch Fusionen oder Carve-outs geprägt sind, oder für Systeme mit Jahren an Daten, die niemand braucht. Sie erhalten die Prozessfreiheit von Greenfield mit der Kontinuität von Brownfield für die Teile, die Sie behalten wollen. Mein Leitfaden zur Migration von ECC nach S/4HANA geht tiefer auf die drei Pfade und ihre Zeitpläne ein.

Im Jahr 2018 waren Rollout-Muster und Migrationspfad die ganze Strategie. 2026 gibt es eine dritte Entscheidung, und sie begrenzt die beiden anderen: welche Edition von S/4HANA Sie betreiben und wie Sie sie kaufen.

1. 03Rollout-MusterBig Bang, phasenweise oder hybrid, je nachdem, wie viel Störung Sie auffangen können
2. 02MigrationspfadGreenfield, Brownfield oder Bluefield, im Rahmen dessen, was die Edition unterstützt
3. 01BereitstellungsmodellPublic Edition, Private Edition oder On-Premise. Entscheiden Sie das zuerst

S/4HANA Cloud Public Edition (meist über GROW with SAP gekauft und von SAP als SAP Cloud ERP vermarktet). Multi-Tenant-SaaS, SAP-Standardprozesse, Upgrades alle sechs Monate, keine Modifikation des Kerns. Nur Greenfield. Kürzeste Time-to-Value, geringste Flexibilität. Am besten für mittelgroße Unternehmen, die bereit sind, den SAP-Standard zu übernehmen. Wenn Ihre Prozesse erhebliche Abweichungen brauchen, ist sie die falsche Antwort.

S/4HANA Cloud Private Edition (meist über RISE with SAP gekauft). Single-Tenant, von SAP betriebene Infrastruktur, alle zwei Jahre ein neues Release mit sieben Jahren Mainstream-Wartung und mehr Spielraum für Konfiguration und Erweiterung. Unterstützt Brownfield, Greenfield und selektive Transitionen. Der Standard für die meisten großen Enterprise-Programme.

S/4HANA On-Premise. Sie oder Ihr Hyperscaler betreiben die Infrastruktur. Die meiste Erweiterbarkeit und Kontrolle, der langsamste Upgrade-Rhythmus. Clean Core wird empfohlen, aber nicht erzwungen. Passt bei strengen Anforderungen an die Datenresidenz und für Organisationen mit starken internen Basis-Teams. Neue Funktionen von SAP erreichen zunehmend zuerst die Cloud-Editionen.

Rollout-Muster und Migrationspfad liegen dann innerhalb der gewählten Edition. Ein Projekt auf der Public Edition ist per Definition Greenfield. Ein Programm auf der Private Edition, das ein stark angepasstes ECC-System konvertiert, ist meist Brownfield oder Bluefield und im großen Maßstab meist phasenweise. Zur kommerziellen Seite von RISE und GROW siehe meine Seiten zu GROW with SAP und RISE with SAP.

Es war ein Donnerstagmorgen, mitten in einem Design-Workshop. Der IT-Leiter hatte gerade den Standardprozess Order-to-Cash von SAP vorgeführt. Jemand aus dem Vertrieb sagte: „Ja, aber so machen wir das nicht.“ Im Raum wurde es still. Dieser Moment passiert in fast jedem Projekt.

Fit-to-Standard

Beim SAP-Standard zu bleiben verkürzt die Implementierung und senkt den langfristigen Wartungsaufwand. Upgrades können keine individuelle Logik zerstören, die es nicht gibt. In einem Handelsprojekt, an dem ich beteiligt war, half Fit-to-Standard dem Kunden, in weniger als sechs Monaten live zu gehen: weniger bewegliche Teile, weniger Hin und Her, ein saubereres System für künftige Upgrades.

Faustregel: Passen Sie nur an, wenn die Regulierung es verlangt oder der Prozess Ihnen einen echten Wettbewerbsvorteil verschafft. Niemals, weil „wir es immer so gemacht haben“.

Clean Core in der Praxis

Fragen Sie jeden Partner nach Beispielen für Erweiterungen, die er auf freigegebenen APIs oder SAP BTP gebaut hat. Wenn die Antwort vage ausfällt, werten Sie das als Warnsignal. Partner, die On-Premise-Gewohnheiten in ein Cloud-Programm mitbringen, häufen vom ersten Sprint an technische Schulden an.

Wenn Code unvermeidlich ist

Etwas Eigenentwicklung ist notwendig. KI-Werkzeuge wie SAP Build Code und Joule for developers senken die Kosten, sie zu schreiben. Sie senken nicht die Kosten, sie zu warten.

Individuelle Logik, die niemand dokumentiert hat, wird zu Logik, die niemand anfassen will, und das verzögert jede spätere Änderung. Kein KI-Werkzeug löst das. Dokumentationsdisziplin tut es. Wenn Sie anpassen müssen, dokumentieren Sie von Anfang an, bauen Sie auf freigegebenen APIs oder BTP und halten Sie es vom Kern getrennt. Saubere Anpassung hat Kosten, die Sie wieder hereinholen können. Unsaubere Anpassung hat Kosten, die Sie immer weiter zahlen.

Das sind die Spannen der Gesamtprogrammkosten, die ich 2026 im US-Markt für S/4HANA sehe. Sie variieren je nach Umfang, Komplexität, Branche, Partner und Edition. Nutzen Sie sie als Anker für die Budgetplanung, nicht als Angebote.

Strategie und Umfang	Typische Gesamtprogrammkosten
Mittelstand, Brownfield, phasenweise	5 bis 15 Mio. $
Mittelstand, Greenfield, Big Bang	8 bis 20 Mio. $
Mittelstand, GROW with SAP (Abonnement und Umsetzung)	2 bis 6 Mio. $
Großunternehmen, Brownfield, phasenweise	25 bis 80 Mio. $
Großunternehmen, Greenfield, Big Bang	35 bis 120 Mio. $
Großunternehmen, RISE with SAP (Abonnement und Umsetzung)	20 bis 80 Mio. $
Global, mehrere Regionen, beliebige Kombination	100 bis 300 Mio. $ und mehr

Das Bereitstellungsmodell ist die Kostenvariable, die am häufigsten unterschätzt wird. RISE- und GROW-Abonnements sind nicht günstiger als On-Premise-Lizenzen, sobald man die mehrjährige Bindung zusammenrechnet. Ihr Wert liegt in der verlagerten Verantwortung für die Infrastruktur, der schnelleren Time-to-Value und den planbaren Abonnementkosten. Das Argument für RISE oder GROW sind selten die Gesamtkosten. Es ist das Betriebsmodell.

Was ist eine SAP-Einführungsstrategie?

Es ist der Ansatz, mit dem ein Unternehmen SAP einführt: Umfang, Methode, Bereitstellungsmodell, Migrationspfad, Rollout-Muster und Zeitplan. Die wichtigsten Entscheidungen 2026 betreffen das Bereitstellungsmodell (Public Edition, Private Edition oder On-Premise), den Migrationspfad (Greenfield, Brownfield oder Bluefield) und das Rollout-Muster (Big Bang, phasenweise oder hybrid).

Entscheidend ist, ob die Kombination zu Bereitschaft, Prozesskomplexität, regulatorischem Profil und Störungstoleranz der Organisation passt.

Wann funktioniert eine Big-Bang-Einführung?

Wenn die Prozesse bereits standardisiert sind, die Anwender gut geschult sind, die Daten vor der Migration bereinigt wurden und die Führung beim Umfang hart bleibt. Fehlt eines davon, vor allem saubere Daten und Anwenderbereitschaft, ist es ein Glücksspiel.

Probleme beim Go-live treffen alles auf einmal. Mit Vorbereitung ist das beherrschbar. Ohne sie ist es eine Krise.

Was ist der Unterschied zwischen einer Greenfield- und einer Brownfield-Einführung von SAP?

Greenfield beginnt mit einem neuen System, ohne dass Altkonfiguration übernommen wird. Sie gestalten die Prozesse von Grund auf rund um den SAP-Standard. Brownfield konvertiert das bestehende System und behält Bewegungshistorie und Konfiguration.

Greenfield kostet anfangs mehr und ergibt ein saubereres, zukunftsfähigeres System. Brownfield ist schneller und weniger störend, übernimmt aber Umgehungslösungen und individuellen Code. Bluefield ist der Mittelweg: die selektive Migration der Gesellschaften und Daten, die Sie auswählen.

Was ist der Unterschied zwischen RISE with SAP und GROW with SAP?

RISE with SAP ist das Abonnementangebot von SAP für Großunternehmen, meist auf Basis von S/4HANA Cloud Private Edition, mit von SAP betriebener Infrastruktur und technischem Betrieb in einem Vertrag. Im US-Markt sehe ich typischerweise Gesamtprogramme von 20 bis 80 Mio. US-Dollar einschließlich Umsetzung.

GROW with SAP richtet sich an mittelgroße Unternehmen und läuft auf S/4HANA Cloud Public Edition mit SAP-Standardprozessen. Ich sehe typischerweise 2 bis 6 Mio. US-Dollar einschließlich Umsetzung.

Über die Wahl entscheiden die Unternehmensgröße und wie weit Ihre Prozesse vom SAP-Standard abweichen müssen.

Was ist Fit-to-Standard in SAP und warum ist es heute wichtiger?

Fit-to-Standard bedeutet, Ihre Prozesse an die Standardfunktionalität von SAP anzupassen, statt SAP so anzupassen, wie Sie heute arbeiten. Es verkürzt die Implementierung, senkt den Wartungsaufwand und macht Upgrades sauberer.

Wichtiger ist es heute wegen Clean Core. In der Public Edition ist die Modifikation des Kerns gar nicht möglich. In der Private Edition und On-Premise erzeugt jede Modifikation zusätzlichen Upgrade-Aufwand. Die Frage lautet, ob es einen echten geschäftlichen Grund gibt, den der SAP-Standard nicht abdecken kann, und wenn ja, ob Ihr Partner die Erweiterung auf freigegebenen APIs oder SAP BTP bauen kann.

Welche Phasen hat die Methodik SAP Activate?

SAP Activate hat sechs Phasen. Discover (SAPs Angebote und den Business Case erkunden), dann vier zentrale Umsetzungsphasen: Prepare (planen, steuern, das Team aufstellen), Explore (Fit-to-Standard-Workshops und das Backlog), Realize (konfigurieren, erweitern, in Sprints testen) und Deploy (Cutover, Go-live und Hypercare). Run umfasst den Betrieb nach dem Go-live.

Realize ist die Phase, in der die meisten Projekte Zeit verlieren, besonders wenn Datenqualitätsprobleme in den Tests auftauchen oder der Anpassungsumfang wächst. Eine straffe Umfangsbasis durch Realize hindurch trennt Projekte, die pünktlich live gehen, von denen, die abdriften.

Warum scheitern SAP-Einführungen?

Vier Ursachen erklären die meisten Fehlschläge: Engagement der Führungsebene, das nach dem Kick-off verschwindet, Datenmigration als IT-Aufgabe, ein auf Schulungsunterlagen beschränktes Change-Management und Partner ohne Clean-Core-Erfahrung, die technische Schulden erzeugen, die beim ersten Upgrade sichtbar werden.

Die Technik versagt selten. Programme scheitern, wenn Entscheidungen nicht getroffen werden, schmutzige Daten im neuen System landen, Anwender Umgehungen finden oder Anpassungen neu gebaut werden müssen. Die Strategie zählt. Die Umsetzungsdisziplin zählt mehr.