Zeitplan für die SAP-Einführung: 5 Fehler, die Sie vermeiden sollten

Ein SAP-Einführungszeitplan ist der Plan Phase für Phase von Discover bis zur Hypercare. Bei einem Public-Cloud-Projekt liegt der typische Go-live laut der Auswertung mehrerer hundert Projekte durch einen SAP-Produktexperten bei fünf bis sieben Monaten. Enterprise-Programme in der Private Cloud oder On-Premise brauchen deutlich über ein Jahr. Ob Ihr Plan hält, hängt weniger von der Methodik ab als von fünf Planungsfehlern: Termine, die vor dem Umfang feststehen, eine spät gestartete Datenmigration, übersprungene Quality Gates, zu frühe Schulungen und Go-lives in der Hochsaison. Dieser Leitfaden richtet sich an Programmverantwortliche und Sponsoren, die einen Plan aufsetzen oder retten müssen. Nutzen Sie die Phasentabelle als Gerüst und prüfen Sie sie dann gegen die fünf Fehler. Jeder zusätzliche Monat Verzögerung kann 100.000 $ oder mehr an Beratungskosten bedeuten.

Ich traf einen Projektleiter eines Fertigungsunternehmens, dessen SAP-Projekt sechs Monate hinter dem Plan lag. Nachdem sie das Projekt strikt an den Phasen von SAP Activate neu aufgesetzt hatten, schlossen sie die verbleibende Arbeit in vier Monaten ab. Seine Worte: „Klare Phasen mit konkreten Ergebnissen haben den Unterschied gemacht. Wir wussten immer genau, was als Nächstes zu tun war.“

Die Zeitpläne, die halten, haben drei Dinge gemeinsam. Realistische Puffer. Annahmen, die vor dem Festzurren geprüft wurden. Quality Gates, die als harte Stopps gelten.

Fünf Fehler erklären die meisten Überschreitungen. Jeder ist vorhersehbar, und für jeden gibt es ein Gegenmittel.

Fehler 1: Termine setzen, bevor der Umfang verstanden ist

Ich habe einmal mit einem Unternehmen gearbeitet, das seinem Vorstand eine Einführung in neun Monaten ohne jeden Puffer versprochen hatte. Als die Datenmigration länger dauerte als erwartet, verfehlte es den Termin um drei Monate, und die Führungskräfte verloren das Vertrauen in das Team. Als man mich als Berater um meine Meinung bat, sagte ich ohne Umschweife, der Zeitplan sei zu aggressiv. Der Projektleiter hatte ihn akzeptieren müssen.

Die Lösung: Legen Sie den Zeitplan nach Explore fest, nicht zum Kickoff, und sagen Sie das dem Vorstand von Anfang an. Planen Sie 15-20 % Puffer über der Schätzung des Anbieters ein.

Fehler 2: Datenmigration als Arbeitspaket behandeln, das spät beginnt

Die meisten Teams benennen den Verantwortlichen für die Datenmigration spät und stellen zu wenig Ressourcen bereit. Erste Datenanalysen unterschätzen das Problem fast immer. Es folgen drei Monate Bereinigung unter dem Druck des laufenden Systems.

Die Lösung: Starten Sie das Data Profiling in Discover, nicht in Realize. Führen Sie in Realize eine vollständige Probemigration durch, bevor die Integrationstests beginnen. Scheitert die Probe, haben Sie noch Zeit zur Korrektur. Erfahren Sie es erst beim Cutover, haben Sie sie nicht. Mein Beitrag dazu, warum die SAP-Datenmigration scheitert, behandelt den Probezyklus im Detail.

Fehler 3: Quality Gates unter Termindruck überspringen

Das Gate zwischen Realize und Deploy überspringen Teams am häufigsten, weil der Druck, „einfach live zu gehen“, genau dort am größten ist. Wer Quality Gates überspringt, um „im Plan zu bleiben“, verursacht später größere Verzögerungen.

Die Lösung: Schreiben Sie messbare Exit-Kriterien in die Projektcharta und lassen Sie den Lenkungsausschuss sie durchsetzen. Ein Abschluss-Probelauf im Finanzwesen ist hier ein nützliches Gate. Kann das Finanzteam ihn nicht sauber durchlaufen, ist das System nicht bereit. Mehr zur Gestaltung von Gates finden Sie in meinem Leitfaden zu SAP Quality Gates.

Fehler 4: Anwender zwei Monate vor dem Go-live schulen

Ich habe mit einem Handelsunternehmen gearbeitet, das alle Anwender zwei Monate vor dem Go-live geschult hat. Am Starttag hatten alle vergessen, wie man das System bedient. Wir mussten an jedem Arbeitsplatz „Auffrischungs“-Kurzanleitungen bereitstellen und die Unterstützung direkt am Arbeitsplatz verdoppeln. Der größte Teil des Schulungsbudgets war verschwendet.

Die Lösung: Legen Sie die Schulung zwei bis drei Wochen vor dem Go-live. Setzen Sie Power-User als Trainer ein, denn Menschen lernen von Kollegen, denen sie vertrauen. Planen Sie Auffrischungstermine während der Hypercare ein. Den vollständigen Ansatz finden Sie in meinem Artikel zu SAP-Schulungsstrategien.

Fehler 5: Den Go-live in die Spitzenzeiten des Geschäfts legen

Hershey ging im Juli 1999 mit seinem System aus SAP R/3, Siebel und Manugistics live, drei Monate später als geplant und mitten in die Halloween-Bestellsaison. Der CEO sagte Analysten, die Probleme würden Hershey daran hindern, Halloween-Bestellungen im Wert von 100 Millionen US-Dollar auszuliefern. Die Lehre liegt auf der Hand und wird dennoch ignoriert.

Die Lösung: Erfassen Sie die Spitzenzeiten jeder betroffenen Geschäftseinheit, einschließlich Monats- und Quartalsabschluss. Gehen Sie in einem Zeitfenster mit geringem Volumen live, auch wenn das eine Verschiebung um sechs Wochen bedeutet. Die Verschiebung lässt sich aufholen. Ein gescheiterter Go-live in der Hochsaison nicht.

SAP Activate hat die alte ASAP-Methodik abgelöst. Seine sechs Phasen sind das Gerüst für jeden S/4HANA-Plan, ob Cloud oder On-Premise. Die folgenden Dauern sind Planungsausgangswerte für ein Enterprise-Programm, keine Zusagen.

1. 1Discover2 bis 4 Wochen. Exit: Umfang und Erfolgskriterien unterzeichnet
2. 2Prepare3 bis 6 Wochen. Exit: Charta genehmigt, Ressourcen schriftlich zugesagt
3. 3Explore4 bis 8 Wochen. Exit: Gap-Entscheidungen mit Verantwortlichen, Zeitplan fixiert
4. 4Realize8 bis 16 Wochen. Exit: Probemigration bestanden, Integrationstests abgeschlossen
5. 5Deploy2 bis 4 Wochen. Exit: UAT-Abnahme, Abschluss-Probelauf, Go/No-go
6. 6Run4 bis 8 Wochen Hypercare. Exit: Defekte unter Schwellenwert, Support-Übergabe unterzeichnet

Phase	Typische Dauer	Was passiert	Exit-Gate vor dem nächsten Schritt
Discover	2-4 Wochen	Business Case, Umfang, Wahl des Betriebsmodells (Public Cloud, Private Cloud oder On-Premise)	Unterzeichneter Umfang und messbare Erfolgskriterien
Prepare	3-6 Wochen	Onboarding des Teams, Governance, Systemlandschaft, Basisplan, Risikoregister	Charta genehmigt, benannte Entscheider je Modul, schriftliche Ressourcenzusagen
Explore	4-8 Wochen	Fit-to-Standard-Workshops, Gap-Liste, RICEFW-Inventar (Reports, Schnittstellen, Konvertierungen, Erweiterungen, Formulare, Workflows)	Gap-Entscheidungen mit Verantwortlichen dokumentiert; Zeitplan fixiert
Realize	8-16 Wochen	Konfiguration, Entwicklung, Unit- und Integrationstests, Probemigrationen	Probemigration bestanden; Integrationstests abgeschlossen
Deploy	2-4 Wochen	Benutzerabnahmetest (UAT), Cutover-Probe, Anwenderschulung, finaler Ladelauf	UAT-Abnahme, Abschluss-Probelauf bestanden, Go/No-go
Run	4-8 Wochen Hypercare	Support am Arbeitsplatz, tägliche Triage, Übergabe an den Support	Offene Defekte unter dem vereinbarten Schwellenwert; Support-Übergang unterzeichnet

Wo die Zeit tatsächlich bleibt

Discover wird überhastet. Teams setzen einen Termin, bevor sie den Umfang verstehen, und lassen messbare Erfolgskriterien weg. Sie brauchen Ziele wie „den Monatsabschluss um drei Tage verkürzen“.

Prepare ist der Ort, an dem technische Verzögerungen beginnen. Bei RISE with SAP stellt SAP die Infrastruktur bereit. On-Premise bauen Kunde und Partner sie auf, und Verzug pflanzt sich hier fort. Holen Sie sich Ressourcenzusagen schriftlich. Mündliche Verfügbarkeit verflüchtigt sich.

Explore ist der Ort, an dem Dokumentation zählt. Sechs Monate später weiß niemand mehr, warum Retouren auf eine bestimmte Weise abgewickelt werden, es sei denn, die Entscheidung und ihr Verantwortlicher wurden festgehalten. Außerdem unterschätzen Teams die Anzahl der Gaps.

Realize ist die längste Phase, und hier landen die meisten Überschreitungen, meist weil Explore eine zu optimistische Gap-Liste geliefert hat. Ihre erste Probemigration wird scheitern. Sie muss im Test scheitern, nicht in der Produktion. Dauerhafte 60-Stunden-Wochen führen zu Fehlern und Fluktuation.

Deploy braucht einen Cutover-Plan mit genauen Schritten, Zeiten und Verantwortlichen. „Daten migrieren“ ist kein Schritt.

Run läuft schief, wenn kritische Probleme hinter Bagatellen warten. Priorisieren Sie nach Geschäftsauswirkung, nicht nach Eingangsreihenfolge, und halten Sie jede Korrektur schriftlich fest. Ihr Support-Team wird dasselbe Problem wieder sehen.

Ich habe mit einem Gesundheitsdienstleister gearbeitet, der drei Monate hinter dem Plan lag und vor einer Budgetüberschreitung von 2 Millionen US-Dollar stand. Wir haben mit den Fit-to-Standard-Workshops von SAP Activate neu aufgesetzt. Das Team fand 28 Prozesse aus Finanzwesen und Supply Chain, die sich ganz ohne Anpassung abbilden ließen. Die Worte seines Projektleiters: „Wir haben Monate damit verschwendet, Dinge zu entwerfen, die SAP längst gebaut hatte.“ Innerhalb von sechs Wochen waren sie wieder im Plan und gingen pünktlich live.

Ich habe mit einem Handelsunternehmen gearbeitet, das feststellte, dass 70 % seines Bedarfs durch SAP-Standardprozesse abgedeckt waren. Es hatte umfangreiche Anpassungen geplant, bis es das System im Einsatz sah.

Clean Core schärft das noch. In S/4HANA Cloud Public Edition sind Standardprozesse die einzige Option, und Erweiterungen liegen auf SAP BTP oder freigegebenen APIs. In Private Cloud und On-Premise können Sie weiterhin modifizieren, aber die Clean-Core-Leitlinien von SAP weisen in dieselbe Richtung. Wenn jeder Gap eine BTP-Erweiterungsentscheidung mit einem Preisschild verlangt, wird das Gespräch über Anpassungen ehrlicher.

Das Betriebsmodell verändert den Zeitplan stärker als jede andere Entscheidung.

1. Public Cloud (GROW with SAP, S/4HANA Cloud Public Edition, heute als SAP Cloud ERP vertrieben). Ein SAP-Produktexperte, der Hunderte von Projekten ausgewertet hat, beziffert den typischen Go-live auf fünf bis sieben Monate. Das Angebot GROW Fast von SAP, Anfang 2026 gestartet, zielt bei festem Umfang auf zwei bis vier Monate. Große Public-Cloud-Projekte dauern 12 Monate oder länger.
2. Private Cloud (RISE with SAP, heute SAP Cloud ERP Private) und On-Premise. Ein Enterprise-Umfang dauert typischerweise 12-24 Monate. Bei RISE betreibt SAP die Infrastruktur, wodurch ein Teil der Prepare-Arbeit entfällt. Der Aufwand für Daten, Tests und Change Management bleibt bestehen.

Die Branche bringt eigenen Ballast mit. Das sind typische Spannen für ein vollständiges S/4HANA-Enterprise-Programm:

Branche	Planungsspanne	Was den Zeitplan verlängert
Fertigung	14-20 Monate	Qualität von Stücklisten und Arbeitsplänen, MRP-Feinabstimmung, QM-Anforderungen
Handel und Konsumgüter	12-18 Monate	Kassenanbindung (POS), Stammdatenvolumen, Zeitfenster der Hochsaison
Pharma	16-22 Monate	GxP-Validierung, Chargenrückverfolgbarkeit, Serialisierung
Versorgungsunternehmen	15-20 Monate	Geräteverwaltung, Abrechnungstarifstrukturen, GIS- und SCADA-Integration
Öffentlicher Sektor	18-24 Monate	Fondsbuchhaltung, Vergaberegeln, Freigabeaufwand, Datenresidenz
Automobil	16-22 Monate	Just-in-time-Lieferketten, Änderungsmanagement in der Konstruktion
Luft- und Raumfahrt sowie Verteidigung	20-26 Monate	Behördenberichte, Programmbuchhaltung, gesicherte Lieferketten
Öl und Gas	18-24 Monate	Joint-Venture-Abrechnung, anlagenintensive Betriebe
Finanzdienstleistungen	14-20 Monate	Rollenkonzept mit Funktionstrennung, regulatorische Validierung

Was KI-Werkzeuge verändern und was nicht

SAP Joule for Consultants wurde 2025 allgemein verfügbar. Es beantwortet Konfigurationsfragen aus der eigenen Wissensbasis von SAP, einschließlich SAP-Hinweisen, und erklärt ABAP-Code. SAP Build Code, seit März 2024 allgemein verfügbar, erzeugt mit Joule Java- und JavaScript-Erweiterungscode auf SAP BTP.

Beides hilft einzelnen Beratern und Entwicklern. Beides ändert nichts daran, wie lange Workshops, Entscheidungen, Datenbereinigung oder Benutzerabnahme dauern. Planen Sie mit diesen Werkzeugen, aber streichen Sie keine Wochen aus dem Plan, bis Ihr eigenes Team den Effekt gemessen hat.

Diese Risiken setze ich auf die wöchentliche Programmagenda. Jedes davon verschiebt Termine, wenn man es dem monatlichen Lenkungsausschuss überlässt.

1. Späte Änderungen am Umfang. Frieren Sie den Umfang am Ende von Explore ein. Danach genehmigt ein Change-Control-Board jede Änderung samt Auswirkung auf Zeitplan und Budget.
2. Datenqualität. Die meisten Unternehmen überspringen in der Planung eine Datenbewertung. Starten Sie jetzt eine. Schlechte Daten sind die häufigste Ursache für gescheiterte Probemigrationen.
3. Ressourcenengpässe. Holen Sie schriftliche Zusagen der Bereichsleiter für benannte Personen und Termine ein. Bilden Sie für jede kritische Rolle eine Vertretung aus.
4. Verzögerte Entscheidungen. Eskalieren Sie Meinungsverschiedenheiten zum Umfang innerhalb von 48 Stunden. Lassen Sie Entscheidungen nicht auf monatliche Reviews warten.
5. Spätes Change Management. Sprechen Sie in Prepare mit den Endanwendern, nicht erst zwei Wochen vor dem Go-live.

Eine Risikobewertungsmatrix macht aus dieser Liste etwas, das der Lenkungsausschuss bewerten kann.

Zum Werkzeug: SAP Cloud ALM ist die zentrale Plattform von SAP für das Management von Einführungsprojekten. Die Standardwartung von SAP Solution Manager 7.2 endet Ende 2027, mit erweiterter Wartung für ausgewählte Funktionen bis 2030 für Kunden, die die erweiterte Wartung für die Business Suite buchen. Der SAP Best Practices Explorer wurde 2023 abgekündigt; die Prozessinhalte liegen jetzt im SAP Signavio Process Navigator.

Wie lange dauert eine SAP-Einführung im Jahr 2026?

Das hängt von Betriebsmodell, Umfang und Branche ab. Nach der Auswertung mehrerer hundert Projekte durch einen SAP-Produktexperten liegt S/4HANA Cloud Public Edition bei fünf bis sieben Monaten, das Festumfang-Angebot GROW Fast von SAP bei zwei bis vier. Enterprise-Programme in der Private Cloud von RISE with SAP oder On-Premise dauern in der Regel 12 bis 24 Monate. Programme im öffentlichen Sektor und in der Luft- und Raumfahrt laufen regelmäßig über 20 Monate hinaus.

Wie wirkt sich RISE with SAP auf den Zeitplan aus?

RISE verlagert die Verantwortung für die Infrastruktur zu SAP, wodurch ein Teil der Arbeit in der Prepare-Phase entfällt. Datenmigration, Tests, Schulung und Entscheidungsfindung, wo die meiste Zeit bleibt, werden dadurch nicht kürzer. Clean-Core-Disziplin kann Realize verkürzen, wenn sie Eigenentwicklung stoppt, bevor sie beginnt.

Wie erstelle ich einen Meilensteinplan für eine SAP-Einführung?

Beginnen Sie mit den sechs Phasen von SAP Activate und schreiben Sie für jedes Gate messbare Exit-Kriterien auf. Bestimmen Sie in jeder Phase die Aktivitäten und Abhängigkeiten auf dem kritischen Pfad. Behandeln Sie die Gates als harte Stopps, verfolgen Sie den Plan wöchentlich und steuern Sie ihn in SAP Cloud ALM.

Welche Faktoren beeinflussen die Dauer einer SAP-Einführung?

Die größten sind Umfang (Module, Gesellschaften, Integrationen), Anpassungsvolumen, Datenqualität, Anwenderzahl und Geografie, Entscheidungsgeschwindigkeit sowie regulatorische Validierung. Das Betriebsmodell liegt über allem. Public Cloud ist am schnellsten, weil Umfang und Prozesse begrenzt sind. On-Premise mit starken Anpassungen ist am langsamsten.

Wie kann ich eine SAP-Einführung beschleunigen?

Führen Sie Fit-to-Standard konsequent durch, denn jede Anpassung, die Sie vermeiden, spart Wochen. Starten Sie die Datenbereinigung in Discover. Stellen Sie Fachbereichsressourcen in Vollzeit ab, statt sie in Teilzeit auszuleihen. Legen Sie die Freigabewege fest, bevor die Konfiguration beginnt, und bereiten Sie den Cutover-Plan während Realize vor, nicht danach.

Sollte ich einen Big-Bang- oder einen phasenweisen SAP-Rollout wählen?

Big Bang bringt alles auf einmal live. Er ist insgesamt schneller und riskanter und passt zu kleinerem Umfang oder zu Organisationen mit starkem Change Management. Ein phasenweiser Rollout geht nach Modul, Standort oder Geschäftseinheit vor. Er ist risikoärmer und dauert länger und passt zu großen Konzernen mit mehreren Gesellschaften. Viele mittelgroße Programme wählen einen Hybrid: das Finanzwesen in einem Zug, die Operations phasenweise.

Was sind die häufigsten Ursachen für Verzögerungen in SAP-Projekten?

Unkontrollierte Änderungswünsche, Überraschungen bei der Datenqualität, spätes Change Management, Ausfälle bei Integrationen mit Drittsystemen, der Verlust von Schlüsselpersonen mitten im Projekt und langsame Entscheidungen im Lenkungsausschuss. Die Datenqualität überrascht die meisten Teams. Alle gehen davon aus, dass Altdaten sauber sind. Fast nie sind sie es.

Was passiert nach dem SAP-Go-live?

Die Hypercare beginnt: vier bis acht Wochen Support am Arbeitsplatz, tägliche Triage von Problemen und Performance-Monitoring. Danach geht das System an ein Anwendungssupport-Team oder ein internes Kompetenzzentrum über. Planen Sie Ihr erstes Erweiterungsrelease drei bis sechs Monate nach dem Go-live ein.