So starten Sie Ihr SAP-Einführungsprojekt richtig

Damit eine SAP-Einführung gelingt, klären Sie fünf Dinge, bevor jemand eine Transaktion konfiguriert. Wählen Sie das Bereitstellungsmodell. Unterzeichnen Sie eine Projektcharta mit Umfang und Entscheidungsrechten. Benennen Sie Fachverantwortliche, die tatsächlich an den Design-Workshops teilnehmen. Beginnen Sie früh mit den Arbeiten an Daten und Cutover. Erstellen Sie einen Zeitplan mit echtem Puffer. Wenn Sie diese Punkte im ersten Monat richtig setzen, bleiben die meisten teuren Fehlschläge aus.

Ich dachte immer, eine SAP-Einführung laufe einwandfrei, wenn das System richtig konfiguriert ist. Blueprint, Aufbau, Test, Go-live. Nach diesem Denkmodell habe ich jahrelang gearbeitet.

Ich führe seit 25 Jahren ERP-Systeme ein, darunter SAP, im Nahen Osten, in Südostasien und in Europa. Selbst wenn die Teams SAP Activate Schritt für Schritt befolgten, gerieten Projekte in Schwierigkeiten. Die Ursachen waren fast nie technischer Natur. Schwache Verantwortlichkeit. Annahmen, die niemand geprüft hat. Cutover-Planung, die zu spät begann. Diese Risse wirken am Anfang harmlos. Haben sie sich erst ausgebreitet, kann späterer Aufwand nicht reparieren, was frühe Transparenz verhindert hätte.

Eine SAP-Einführung ist ein Veränderungsprogramm für das Unternehmen mit einer Softwarekomponente. Die Arbeitspakete sind Prozessdesign, Konfiguration, Datenmigration, Integration, Test, Schulung und Change Management. Jedes hat seinen eigenen Zeitplan, seine eigenen Risiken und seinen eigenen Verantwortlichen.

Teams, die sie als Konfigurationsübung behandeln, unterfinanzieren alles, was nicht Konfiguration ist. Das ist die häufigste Ursache schwieriger Go-lives, die ich erlebe.

Bei einem Programm, das jetzt startet, ist zuerst noch ein weiterer Punkt zu klären: das Bereitstellungsmodell. S/4HANA Cloud Public Edition (GROW with SAP), Private Edition (RISE with SAP) oder On-Premise. Diese Entscheidung prägt, wie jedes andere Arbeitspaket abläuft.

SAP Activate ist die Projektmethode von SAP. Sie hat sechs Phasen, jede mit Quality Gates am Ende. Hier steht, wofür jede Phase da ist und was ich nicht schleifen lassen würde.

Phase	Was geschieht	Worauf ich achte
Discover	Business Case, grober Umfang, Bereitstellungsmodell	Realistische Kosten und ein realistischer Zeitplan, nicht der optimistische
Prepare	Governance, Charta, Team, Risikoregister, Umgebungen	Benannte Entscheidungsträger mit echter Befugnis
Explore	Fit-to-Standard-Workshops, Entscheidungen zu Lücken, Design-Freigabe	Fachverantwortliche im Raum, nicht nur die IT
Realize	Konfiguration, Entwicklung, Integration, Systemtest	Cutover-Planung läuft bereits
Deploy	Benutzerabnahmetest, Datenladungen, Schulung, Cutover	Mindestens eine vollständige Generalprobe
Run	Go-live, Hypercare, Übergabe an den Support	Hypercare ist bis einschließlich des ersten Monatsabschlusses besetzt

Der häufigste Terminfehler ist ein schleppendes Explore. Es drückt Realize zusammen, und das drückt Deploy zusammen. Der Benutzerabnahmetest (UAT) wird gekürzt, die Datenprobe fällt aus, und der Go-live findet trotzdem statt, weil der Termin bereits verkündet war. Die ersten 90 Tage nach dem Go-live bezahlen dafür.

1. 01Explore verzögert sichFit-to-Standard und Design-Freigabe rutschen
2. 02Realize wird gestauchtWeniger Zeit für Aufbau und Test
3. 03Deploy wird gestauchtWeniger Zeit für UAT, Datenladungen und Schulung
4. 04Testen wird gekürztUAT verkürzt, Datenprobe entfällt
5. 05Go-live zum verkündeten TerminWeil der Termin verkündet war

Die Kosten fallen in der Hypercare an, in den ersten 90 Tagen

1. Design-Freigabe ohne den Fachbereich

Explore liefert ein Design. Seine Qualität hängt davon ab, ob die Prozessverantwortlichen, die es freigegeben haben, verstanden haben, was sie unterschreiben. Nehmen an den Workshops nur IT und Berater teil, kann das Design technisch korrekt und für die späteren Anwender trotzdem nicht wiederzuerkennen sein. Dann deckt der UAT erst auf, was gebaut wurde, statt es zu validieren.

Ein einfacher Test: Bitten Sie drei Monate nach der Freigabe einen Prozessverantwortlichen, Ihnen zu erklären, wie eine Bestellung nach dem Go-live ablaufen wird. Kann er es nicht, war die Freigabe nicht echt.

2. Governance, die nur auf dem Papier existiert

Ohne durchgesetzte Governance wächst der Umfang informell, und Entscheidungen werden vertagt. Gute Governance heißt: ein benannter Executive Sponsor, ein Lenkungsausschuss mit definierten Entscheidungsrechten, ein Projektleiter, der ein Phase Gate halten kann, und ein Prozess zur Änderungssteuerung mit einem benannten Genehmiger.

In den meisten meiner Projekte übernahm die CFO die Rolle des Projekt-Champions. Konnten sich Abteilungen nicht auf einen Prozess einigen, traf sie die letzte Entscheidung. So blieben die Wochen Verzug aus, die entstehen, wenn Fragen ungeklärt liegen bleiben. In meinem Leitfaden zu SAP-Lenkungsausschüssen steht, wie Sie das aufsetzen.

3. Zu späte Cutover-Planung

Der Cutover ist der operativ komplexeste Teil des Programms. Ein Plan, der wenige Wochen vor dem Go-live beginnt, wird nicht geprobt, übersieht Abhängigkeiten und hat keinen echten Rückfallpunkt.

Beginnen Sie die Cutover-Planung in Realize. Dokumentieren Sie die Abfolge, führen Sie mindestens eine vollständige Generalprobe durch und legen Sie die Rückfallkriterien vorab fest. Cutover-Entscheidungen unter Druck, getroffen von Menschen, die seit zwanzig Stunden wach sind, ohne vorab vereinbarte Kriterien: Hier beginnen die Katastrophen nach dem Go-live.

4. Integrationstests, die verdrängt werden

Ehrlich gesagt hielt ich Testen früher für einen Punkt auf der Checkliste. System konfigurieren, ein paar Testfälle durchlaufen, weiter. Dann sah ich ein Projekt auseinanderfallen, nur weil niemand geprüft hatte, wie sich Bestellfreigaben auf Buchungen im Finanzwesen auswirken. Dieser Moment hat meinen Blick auf SAP-Tests verändert.

Einzeltests belegen, dass eine Transaktion für sich funktioniert. Die Fehler, die nach dem Go-live wehtun, treten auf, wenn ein vollständiger Prozess über mehrere Module läuft. Ein Wareneingang, den ein Bestellstatus blockiert. Ein Fakturalauf, den eine fehlende Kontenfindung stoppt. Testen Sie komplette Prozessketten, Order-to-Cash und Procure-to-Pay, und lassen Sie sie nicht in die letzten Wochen vor dem UAT rutschen.

5. Datenmigration unterschätzt

Quelldaten sind fast immer schlechter, als die erste Einschätzung vermuten lässt. Feldzuordnungen, die einfach aussehen, scheitern beim Laden. Datensatzzahlen enthalten inaktive Daten. Bereinigungsregeln brauchen fachliche Entscheidungen, und die dauern.

Ein Fertigungsunternehmen entdeckte bei der Migration Tausende doppelter Kundenstammsätze und musste den Go-live um drei Wochen verschieben, um sie zu bereinigen. Planen Sie von Anfang an zusätzliche Ladezyklen ein. Die Details finden Sie in meinem Artikel über die Gründe, warum SAP-Datenmigrationen scheitern.

6. Change Management als Option behandelt

Ich habe Projekte erlebt, in denen das System einwandfrei lief und die Anwender trotzdem an alten Prozessen festhielten. Nicht, weil sie schwierig waren, sondern weil niemand sie durch den Wandel begleitet hatte. Wird das Change Management gestrichen, entstehen schon in der ersten Woche Behelfslösungen, die dauerhaft bleiben, und die Zahl der Support-Tickets bleibt monatelang hoch.

Starke Anpassungen am Standard gehören in dieselbe Kategorie. Ich habe einmal mit einem Kunden gearbeitet, der über 60 Prozent des Systems individuell angepasst hatte. Später kam er mit Upgrades kaum zurecht und verlor den Herstellersupport.

Die oben genannten Grundlagen haben sich nicht geändert. Drei Dinge müssen heute zu Beginn eines Programms geklärt sein.

Das Bereitstellungsmodell kommt zuerst. Die Public Edition bietet die engsten Anpassungsmöglichkeiten, und SAP betreibt das System. Die Private Edition unter RISE bietet mehr Spielraum, und SAP betreibt die Infrastruktur. On-Premise bietet die meiste Kontrolle und die meiste Verantwortung. Entscheiden Sie es in Discover. Programme, die es aufschieben, verbringen Explore mit Streiten darüber.

Clean Core gehört in die Projektcharta. Die Public Edition erlaubt Erweiterungen nur über freigegebene Schnittstellen und setzt Clean Core damit technisch durch. Private Edition und On-Premise tun das nicht, also wird es zu einer Governance-Entscheidung. SAP stuft Erweiterungen inzwischen von Level A (nur freigegebene APIs) bis Level D (Modifikationen) ein, wie im Clean-Core-Update vom August 2025 beschrieben. Schreiben Sie das Ziellevel und das Freigabegremium in die Charta, sonst greifen Partner standardmäßig zu Modifikationen.

KI-Werkzeuge gehören vom ersten Tag an in die Methode. Joule steht im SAP Activate Roadmap Viewer zur Verfügung. Joule for Consultants beantwortet Konfigurationsfragen, und Joule for Developers erzeugt ABAP-Cloud-Code. Damit lassen sich Entwurfs- und Aufbauaufgaben beschleunigen. Sie nehmen Ihnen weder die fachlichen Entscheidungen noch die Datenarbeit oder den Change-Aufwand ab. Fragen Sie Ihren Partner, wo er sie einsetzt und wie sich das im Plan niederschlägt.

Der Ansatz sollte sich nach Ihrer Risikobereitschaft, der Komplexität und Ihrer Veränderungskapazität richten. Das sind die gängigen Optionen.

Ansatz	Was es bedeutet	Am besten geeignet für
Big Bang	Alle Module und Gesellschaften gehen gemeinsam live	Kleinere Organisationen mit Standardumfang, die ein höheres Go-live-Risiko in Kauf nehmen
Phasenweise nach Modul	Zuerst das Finanzwesen, dann die Lieferkette, dann HR	Module mit wenigen Abhängigkeiten; das Team lernt zwischen den Phasen
Phasenweise nach Land oder Gesellschaft	Ein Template geht in einer Gesellschaft live, danach folgt der Rollout	Konzerne mit globalem Template
Brownfield-Umstellung	Bestehendes ECC wird auf S/4HANA umgestellt	Ausgereiftes ECC mit stabilen Prozessen
Greenfield	Neue S/4HANA-Einführung	Nicht-SAP-Altsystem oder ECC mit hohen technischen Schulden
Selektive Datenübernahme	Ausgewählte Gesellschaften oder Daten wandern in ein neu gestaltetes System	Fusionen, Carve-outs, teilweise Wiederverwendung

Ich habe kleine Rollouts in weniger als sechs Monaten live gehen sehen. Ich habe auch Projekte erlebt, die sich zwei Jahre hinzogen, weil Entscheidungen nicht rechtzeitig fielen. Wenn Sie eine Erstimplementierung gegen einen Template-Rollout abwägen, vergleicht mein Leitfaden zu Einführung und Rollout die beiden.

Nutzen Sie sie im ersten Monat, bevor die Konfiguration beginnt. Jeder Punkt hat einen Verantwortlichen auf Kundenseite.

1. Executive Sponsor: Bereitstellungsmodell entschieden und samt Gründen festgehalten.
2. Programmdirektor: Charta unterzeichnet, mit Umfang, ausdrücklichen Ausschlüssen, Erfolgskriterien, Entscheidungsrechten und Änderungssteuerung. Mündliche Absprachen zum Umfang lösen sich in Luft auf. Mein Leitfaden zur Projektcharta enthält eine Vorlage.
3. Fachbereichsleiter: je Bereich ein benannter Prozessverantwortlicher, dem tatsächlich Zeit für die Workshops freigeräumt wird.
4. Lösungsarchitekt: Clean-Core-Ziel und Freigabegremium für Erweiterungen vereinbart.
5. Datenverantwortlicher: Datenprofilierung beginnt in Prepare, nicht erst nach der Design-Freigabe.
6. Cutover-Verantwortlicher: in Realize benannt, mit einem Probetermin, der bereits im Plan steht.
7. Testmanager: Testszenarien für vollständige Prozessketten aufgelistet, einschließlich Freigaben bis hin zu Buchungen im Finanzwesen.
8. CFO: Zeitplan mit vergleichbaren Programmen abgeglichen, mit Puffer für ein langsames Explore und zusätzliche Datenzyklen. Ein Plan, der davon ausgeht, dass alles gut geht, ist kein Plan.

Was ist ein SAP-Einführungsprojekt?

Es ist das Programm, mit dem SAP-Software eingeführt wird, um den Betrieb eines Unternehmens zu steuern. Es umfasst Prozessdesign, Konfiguration, Datenmigration, Integration, Test, Schulung und Change Management und wird meist mit SAP Activate durchgeführt. Der Aufwand schwankt stark mit der Zahl der Gesellschaften, Länder und Module und mit dem Zustand Ihrer vorhandenen Daten.

Welche Phasen hat eine SAP-Einführung?

SAP Activate hat sechs Phasen: Discover, Prepare, Explore, Realize, Deploy und Run. Discover legt Business Case und Umfang fest. Prepare richtet Governance und Team ein. Explore führt die Fit-to-Standard-Workshops durch und bestätigt das Design. Realize baut und testet. Deploy umfasst UAT, Datenladungen, Schulung und Cutover. Run ist Go-live und Hypercare. Jede Phase endet mit einem Quality Gate.

Wie lange dauert eine SAP-Einführung?

Das hängt vom Umfang ab und davon, wie schnell Entscheidungen fallen. Ich habe kleine Rollouts in weniger als sechs Monaten live gehen sehen und Projekte, die sich zwei Jahre hinzogen, weil Entscheidungen nicht rechtzeitig getroffen wurden. Die häufigste Ursache für Überschreitungen ist ein schleppendes Explore, das alles danach zusammendrückt.

Was sind die häufigsten Gründe, warum SAP-Einführungen scheitern?

Ein Design, das ohne echte Beteiligung des Fachbereichs freigegeben wurde, Governance, die nicht durchgesetzt wird, späte Cutover-Planung, gestauchte Integrationstests, unterschätzte Datenmigration und gestrichenes Change Management. Alle sechs sind meist früh erkennbar und zu diesem Zeitpunkt günstig zu beheben.

Was gehört in eine SAP-Projektcharta?

Ziele, die an messbare Ergebnisse geknüpft sind, Umfang nach Modul, Gesellschaft, Land und Integration, ausdrückliche Ausschlüsse, Entscheidungsrechte mit benannten Personen, Governance und Eskalation, Erfolgskriterien, Änderungssteuerung, wichtige Meilensteine und zentrale Annahmen. Bei einem Cloud-Programm kommen das Bereitstellungsmodell und der Clean-Core-Ansatz hinzu. Lassen Sie die Charta vor Beginn der Konfiguration von Sponsor und Fachbereichsleitern unterzeichnen.

Was ist Hypercare nach dem SAP-Go-live?

Hypercare ist die Phase intensiver Unterstützung nach dem Go-live, typischerweise 30 bis 90 Tage. Projektteam und Fachbereich arbeiten Seite an Seite, um Probleme zu beheben und den Betrieb zu stabilisieren. Besetzen Sie sie mindestens über einen vollständigen Geschäftszyklus, einschließlich des ersten Monatsabschlusses, denn dann treten viele Probleme erstmals auf.