SAP-Projektrettung: ein Programm zurück in die Spur bringen

SAP-Projektrettung heißt, eine Migration oder Implementierung, die aus der Spur geraten ist, anzuhalten, herauszufinden, was an ihr wirklich wahr ist, und von dieser Wahrheit aus neu zu planen. Die erste Woche entscheidet, ob es funktioniert: Bewerten Sie den Programmstatus, prüfen Sie das Design und bewerten Sie, was tatsächlich im System bereitgestellt ist.

Kurz gesagt: Wenn diese drei Prüfungen untereinander und mit dem Plan übereinstimmen, braucht das Programm Anschub, keine Rettung. Wenn sie sich widersprechen, wird kein zusätzlicher Aufwand am aktuellen Plan es reparieren, und Sie brauchen eine formelle Rettung mit einer neuen Baseline.

In diesem Artikel geht es um diese Diagnose und um das, was darauf folgt. Er ist ein Teil meines Leitfadens zur Migration von ECC auf S/4HANA, der Wege, Zeitpläne und Fristen behandelt. Hier ist die Frage enger: Ihr Programm steckt in Schwierigkeiten, was nun?

Die meisten Programme, die verspätet sind, brauchen keine Rettung. Sie brauchen schnellere Entscheidungen, einen freigestellten Key User oder einen Anbieter, der an einen Termin gebunden wird. Das ist Anschub.

Eine Rettung ist etwas anderes. Die Anzeichen kommen aus denselben drei Prüfungen, die ich in Woche eins durchführe, und das Signal ist einfach: Status, Design und das, was bereitgestellt ist, stimmen weder untereinander noch mit dem Plan überein.

Einige Muster, die ich als Rettungssignale werten würde:

1. Der Status ist grün, das System nicht. Die Berichte sagen, der Großteil des Builds sei fertig, aber das Testsystem kann kein einfaches Order-to-Cash durchlaufen.
2. Das Design ist unterschrieben, der Build ignoriert es. Das Customizing wurde nach Workshop-Notizen gemacht, nicht nach dem freigegebenen Design.
3. Der Plan hat einen Go-live-Termin, niemand kann den Weg dorthin erklären. Tests, Datenladungen und Cutover-Generalproben haben kein realistisches Zeitfenster.
4. Der Umfang wächst nur. Die WRICEF-Liste (Reports, Schnittstellen, Konvertierungen, Erweiterungen, Formulare und Workflows) steigt noch lange nach der Explore-Phase.

Jedes einzelne davon lässt sich mit Anschub beheben. Zwei oder mehr gleichzeitig meistens nicht.

Woche eins dient dazu herauszufinden, was wahr ist. Nicht zum Reparieren, nicht zum Schuldzuweisen und nicht zum Schreiben eines neuen Plans. Ich bewerte drei Dinge, in dieser Reihenfolge: den Status, das Design und das, was tatsächlich bereitgestellt ist.

Das deckt jede Prüfung ab, und das sagt Ihnen ein Widerspruch:

Prüfung	Was ich mir ansehe	Die Frage, die sie beantwortet	Wenn sie den anderen widerspricht
Programmstatus	Plan, Statusberichte, RAID-Log, offene Change Requests, Ausgaben gegen Budget	Was glaubt das Programm über sich selbst?	Das Berichtswesen ist zu optimistisch oder von der Lieferung abgekoppelt
Design	Geschäftsprozessdesign, Ergebnisse aus Fit-to-Standard, WRICEF-Liste, offene Designentscheidungen	Was wurde dem Fachbereich versprochen?	Der Build hat sich vom Vereinbarten entfernt, oder das Design wurde nie fertiggestellt
Was bereitgestellt ist	Die Entwicklungs- und Testsysteme, Customizing, Transporte, Eigenentwicklungen, bisherige Datenladungen	Was existiert heute tatsächlich?	Es wurde Fortschritt bei Arbeit gemeldet, die nicht im System ist

Die dritte Prüfung ist die, die die meisten Reviews auslassen. Sie bedeutet, vor dem System zu sitzen und Prozesse durchzuspielen, nicht Dokumente über das System zu lesen.

Statusberichte und Designdokumente sind Behauptungen. Das System ist der Beleg.

Wer die Prüfungen durchführen sollte

Die Personen, die die Statusberichte geschrieben haben, sollten nicht die sein, die sie überprüfen. Das ist kein Vorwurf. Es ist derselbe Grund, aus dem Prüfer nicht ihre eigene Arbeit prüfen.

Ich würde jemanden, der vom Implementierungspartner unabhängig ist, mit der Leitung von Woche eins betrauen, mit vollem Zugriff auf die Systeme und dem Recht, mit jedem im Programm zu sprechen. Wenn das nicht möglich ist, lassen Sie sich vom Partner wenigstens das bereitgestellte System live zeigen statt auf Folien.

2018 habe ich an der Rettung eines Luftfahrtprogramms gearbeitet. Die Module waren bereitgestellt, aber nichts war auf Basis der fachlichen Anforderungen konfiguriert.

Genau diese Situation sollen die drei Prüfungen in Woche eins aufdecken. Bereitgestellte Module sind nicht dasselbe wie ein funktionierendes Design, und nur der Blick ins System zeigt den Unterschied.

Fluggesellschaften verknüpfen Instandhaltung, Einkauf und Finanzen eng, eine Lücke in einem Bereich wandert also weiter. Wie SAP zu dieser Branche passt, behandle ich auf meiner Seite zu SAP für die Luftfahrt.

In den 21 SAP-Programmen, die ich geleitet oder gerettet habe, ist der größte Fehler, den ich sehe, zu Beginn der Implementierung nicht richtig zu planen. Eine Rettung ist oft genau diese fehlende Planung, spät und unter Druck nachgeholt.

Zwei weitere Ursachen tauchen immer wieder auf:

1. Der Anbieter steuert den Umfang. Wenn der Systemintegrator den Umfang schreibt, beschreibt er, was der Integrator zu liefern plant. Die Lücken kommen später als Change Requests, bepreist vom selben Anbieter.
2. Eigenentwicklungen überziehen. Nach meiner Erfahrung sind Eigenentwicklungen die Migrationsphase, die am häufigsten überzieht, und zugleich die versteckten Kosten, die am häufigsten vergessen werden.

Die Budgetseite davon, einschließlich der Frage, warum die Kosten gerade in der Explore-Phase springen, behandle ich in meinem Artikel darüber, warum SAP-Projekte das Budget sprengen. Ich wiederhole sie hier nicht.

Schwache Steuerung ist der andere gemeinsame Faden. Hatte das Programm nie einen wöchentlichen Rhythmus aus Nachverfolgung, Eskalation und Änderungsmanagement, muss die Rettung einen einführen. Mein Leitfaden zu Planung und Steuerung von SAP-Projekten legt diesen Takt mit Verantwortlichen dar.

Sobald Sie wissen, was wahr ist, hat die Rettung eine klare Abfolge. Wer einen Schritt überspringt, macht die Rettung meist zweimal.

Ablauf einer SAP-Programmrettung

1. 01

   Diagnose

   Status, Design und was bereitgestellt ist, gegeneinander geprüft.

2. 02

   Umfang zurückholen

   Umfang in der Hand des Kunden, eingefroren, jede Änderung bepreist.

3. 03

   Neue Baseline

   Ein neuer Plan auf Basis von Belegen, mit Reserve auf Ihrer Seite.

4. 04

   Phasen absichern

   Ein Quality Gate am Ende jeder verbleibenden Phase.

5. 05

   Generalprobe und Cutover

   Vollständige Generalproben, bevor ein Go-live-Termin bestätigt wird.

1. Die Verantwortung für den Umfang zurückholen

Bevor jemand neu plant, entscheiden Sie, wer den Umfang verantwortet. Lautet die Antwort immer noch „der Anbieter“, scheitert der neue Plan auf dieselbe Weise wie der alte.

Schreiben Sie den Umfang auf Kundenseite, vergleichen Sie ihn mit dem, was bereitgestellt ist, und frieren Sie ihn ein. Von da an ist jede Änderung eine bepreiste Entscheidung mit einem Verantwortlichen.

2. Einmal eine neue Baseline setzen, auf Basis von Belegen

Eine Rettung bekommt eine neue Baseline, keine Reihe kleiner Verschiebungen. Bauen Sie sie aus dem auf, was das System zeigt, nicht aus dem, was der alte Plan erhofft hat.

Schätzen Sie zuerst die Eigenentwicklungen neu, denn von dort kommen Überschreitungen am häufigsten. Dann die Daten, denn die Datenmigration macht 30 bis 40 Prozent des Aufwands aus und hängt in einem angeschlagenen Programm meist hinterher.

Halten Sie 10 bis 20 Prozent Reserve auf Ihrer Seite, freigegeben nur gegen benannte Risiken. Mein Schwesterartikel zu den Kosten einer S/4HANA-Migration erklärt, was die Zahlen treibt.

3. Ein Quality Gate am Ende jeder Phase setzen

Programme in Schwierigkeiten sind meist nach Terminen von Phase zu Phase gewechselt statt nach Belegen. Korrigieren Sie das.

In SAP Activate führt die Explore-Phase Fit-to-Standard-Workshops durch, und freigegebene Delta-Anforderungen kommen für Realize in das Product Backlog. Hat das Programm Explore ohne fertiges Design verlassen, gehen Sie zurück und stellen Sie es fertig. SAP Cloud ALM unterstützt Quality Gates als Kontrollpunkte mit Checklisten, angezeigt in der Projektübersicht, sodass das Gate nicht in einer Tabellenkalkulation leben muss.

4. Proben, bevor Sie sich auf einen Termin festlegen

Bei einer Brownfield-Konvertierung plane ich drei Probekonvertierungen vor dem Cutover. Angeschlagene Programme streichen oft Generalproben, um Zeit zu sparen, und verlagern das Risiko damit auf das Go-live-Wochenende.

Die Cutover-Downtime, die ich erlebt habe, reicht von einem Wochenende bis zu einer Woche. Ein gerettetes Programm sollte seine Zahl aus einer Generalprobe kennen, nicht aus einer Schätzung.

5. Die Frist prüfen, auf die Sie wirklich hinarbeiten

Für SAP ERP 6.0 auf den Erweiterungspaketen 6 bis 8 endet die Standardwartung am 31. Dezember 2027, mit optionaler erweiterter Wartung bis Ende 2030 gegen einen Aufschlag von zwei Prozentpunkten (SAP News). Eine Rettung, die eine ECC-Migration über 2027 hinausschiebt, sollte die erweiterte Wartung offen budgetieren.

Lassen Sie nicht zu, dass das Datum 2027 einen Go-live erzwingt, den die Generalproben nicht tragen. Ein später Go-live kostet Wartungsgebühren. Ein gescheiterter kostet weit mehr.

Eine Rettung wirft oft die Frage auf, ob man den aktuellen Systemintegrator behält. Manchmal ist es richtig, den Partner zu ersetzen. Oft liegt das größere Problem darin, wie das Programm aufgesetzt wurde, und ein neuer Partner erbt es.

Das sind die Fragen, die ich vor der Entscheidung stellen würde:

1. Können Sie uns das bereitgestellte System live zeigen, gegen das unterschriebene Design? Keine Demo-Umgebung und keine Folien.
2. Welche WRICEF-Objekte sind gebaut, getestet und transportiert, und welche sind nur als erledigt gemeldet?
3. Wie sieht Ihr Grobdesign für den Abschluss aus, und welche Referenzen können wir anrufen, bei denen Sie ein Programm wie unseres gerettet haben? Referenzen und das Grobdesign sind die zwei Dinge, die ich von jedem Partner vor der Unterschrift verlange.
4. Was brauchen Sie von uns, das Sie nicht bekommen? Fehlende Entscheidungen und Key User in Teilzeit sind oft die halbe Geschichte.
5. Für Kunden von RISE with SAP: Welche Probleme liegen bei SAP statt beim Partner, und wer eskaliert sie?

Das Warnsignal ist dasselbe, bei dem ich mich schon bei der Auswahl von einem Partner verabschiede: allgemeine Antworten. Wenn der Rettungsplan auf jedes Unternehmen passen könnte, wurde er nicht für Ihres geschrieben. Mein Leitfaden zur Wahl eines Partners für die S/4HANA-Migration behandelt die Auswahlseite.

Hatte das Programm nie eine ordentliche Bewertung des Quellsystems, holen Sie sie jetzt nach. Der SAP Readiness Check analysiert Ihr bestehendes System, und SAP empfiehlt, ihn in der Produktion auszuführen, um ein genaues Bild der tatsächlichen Nutzung zu erhalten. Mein Artikel zum SAP Readiness Check und zur Migrationsbewertung erklärt, was er übersieht, angefangen bei den kundeneigenen Objekten.

Planen Sie einen halben Tag mit Ihrem Programmdirektor und Ihrer SAP-Leitung ein und bitten Sie sie, Ihnen drei Dinge nebeneinander zu zeigen: den neuesten Statusbericht, das unterschriebene Design und das Testsystem, das einen vollständigen Geschäftsprozess durchläuft. Wenn diese drei dieselbe Geschichte erzählen, geben Sie Anschub. Wenn nicht, starten Sie eine formelle Rettung vor dem nächsten Lenkungsausschuss.

Wenn Sie eine unabhängige Sicht auf ein Programm möchten, das aus der Spur geraten ist, helfe ich Unternehmen genau bei dieser Art von Diagnose. Sie können ein Gespräch mit mir buchen.

Was ist SAP-Projektrettung?

SAP-Projektrettung ist die Arbeit, eine SAP-Implementierung oder -Migration, die aus der Spur geraten ist, wieder unter Kontrolle zu bringen. Sie beginnt mit einer Diagnose von Programmstatus, Design und dem, was tatsächlich bereitgestellt ist, holt dann die Verantwortung für den Umfang zurück, setzt eine neue Baseline und ergänzt die verbleibenden Phasen um Quality Gates.

Woran erkenne ich, ob mein SAP-Projekt eine Rettung braucht?

Vergleichen Sie drei Dinge: was die Statusberichte sagen, was das unterschriebene Design sagt und was tatsächlich im System bereitgestellt ist. Stimmen sie untereinander und mit dem Plan überein, braucht das Programm Anschub. Widersprechen sie sich, wird mehr Aufwand am aktuellen Plan es nicht reparieren, und Sie brauchen eine formelle Rettung.

Was sollte in der ersten Woche einer Rettung einer SAP-Implementierung passieren?

Nur Diagnose. Bewerten Sie den Programmstatus, prüfen Sie das Design und bewerten Sie, was tatsächlich bereitgestellt ist, idealerweise geleitet von jemandem, der vom Implementierungspartner unabhängig ist. Schreiben Sie den neuen Plan erst, wenn diese drei Prüfungen abgeschlossen sind.

Sollten wir unseren SAP-Implementierungspartner während einer Rettung ersetzen?

Nicht automatisch. Bitten Sie den Partner, das bereitgestellte System gegen das unterschriebene Design zu zeigen und Ihnen ein Grobdesign für den Abschluss mit Referenzen aus ähnlichen Rettungen zu geben.

Sind die Antworten allgemein, ist das ein starkes Signal für einen Wechsel. Liegt das eigentliche Problem bei der Verantwortung für den Umfang oder bei fehlenden Entscheidungen auf Ihrer Seite, wird ein neuer Partner es erben.

Warum geraten SAP-S/4HANA-Migrationen aus der Spur?

Die häufigste Grundursache, die ich sehe, ist, zu Beginn der Implementierung nicht richtig zu planen. Dem Anbieter die Steuerung des Umfangs zu überlassen, ist eine weitere, und Eigenentwicklungen sind die Phase, die am häufigsten überzieht. Die Datenmigration, mit 30 bis 40 Prozent des Aufwands, hängt meist ebenfalls hinterher.

Schiebt eine Rettung unsere ECC-Migration über die Frist 2027 hinaus?

Möglicherweise. Die Standardwartung für SAP ERP 6.0 auf den Erweiterungspaketen 6 bis 8 endet am 31. Dezember 2027, und die optionale erweiterte Wartung läuft bis Ende 2030 gegen einen Aufschlag von zwei Prozentpunkten. Budgetieren Sie die erweiterte Wartung, statt einen Go-live zu erzwingen, den Ihre Generalproben nicht tragen.