SAP-Projektplanung und -steuerung: Projekte auf Kurs halten

Die meisten SAP-Programme haben einen Plan. Deutlich weniger haben Steuerung. Die Planung legt Umfang, Zeitplan, Budget und Risiken fest. Steuerung ist die wöchentliche Arbeit, den Fortschritt gegen diesen Plan zu verfolgen, Abhängigkeiten zu managen, früh zu eskalieren und jede Änderung vor der Freigabe zu bewerten. Dieser Leitfaden richtet sich an Programmleiter, PMOs und Sponsoren, deren SAP-Programm abdriftet oder die verhindern wollen, dass es abdriftet. Er zeigt, wie Steuerung aussieht, nennt drei öffentlich bekannte Fehlschläge, die zeigen, was ohne sie passiert, und beschreibt einen wöchentlichen Steuerungsrhythmus mit Verantwortlichen, den Sie noch diese Woche übernehmen können.

Als ich anfing, arbeitete ich an einem SAP-Programm, das auf dem Papier großartig aussah. Zeitpläne, Risikoregister, Änderungsprotokolle, alles, was man erwartet. Niemand hielt sich daran. Der Lenkungsausschuss tagte selten. Das Finanzwesen wartete auf die Datenmigration. Die IT hatte noch nicht begonnen. Niemand verfolgte Abhängigkeiten. Alle gingen davon aus, dass jemand anderes das Programm auf Kurs hielt.

Im sechsten Monat lag die Hälfte des Projekts hinter dem Zeitplan, und wir liefen unseren eigenen Fehlern hinterher. Das Schlimmste: Niemand hatte es kommen sehen.

Es war kein Planungsproblem. Es war ein Steuerungsproblem. Es gab keine echte Ressourcenzuteilung, keine ordentliche Risikominderung und keinen Eskalationsweg. Der Plan war einmal erstellt und dann zugunsten von Meetings aufgegeben worden.

Planung umfasst Umfang, Zeitplan, Budget, Ressourcen, das Risikoregister und Meilenstein-Zusagen. Die meisten Teams erstellen das. Die Frage ist, ob es jemand Woche für Woche nutzt.

Steuerung heißt, den tatsächlichen Fortschritt gegen den Plan zu verfolgen, Abweichungen früh sichtbar zu machen, Abhängigkeiten zu managen, bei Verzug zu eskalieren und die Baseline neu festzulegen, wenn sich Umfang oder Zeitplan formal ändern. Die meisten Teams machen das schlecht.

1. 01Fortschritt verfolgenIst gegen Plan, je Arbeitspaket
2. 02Abweichungen aufdeckenJede Aufgabe mit drei Tagen Verzug
3. 03Abhängigkeiten prüfenWer blockiert ist, wenn das rutscht
4. 04EskalierenAuf einem vorab vereinbarten Weg
5. 05Änderungen bewertenZuerst Zeit, Kosten und Ressourcen
6. 06Baseline neu setzenErst nach einer formalen Änderung

Jede Woche, mit benannten Verantwortlichen

Das bricht, wenn Steuerung fehlt:

Was ohne Steuerung bricht	Warum es passiert
Termine rutschen unbemerkt	Zwischen den Meilenstein-Reviews prüft niemand
Annahmen bleiben ungeprüft	Jedes Team erwartet, dass ein anderes die Abhängigkeit übernimmt
Der Umfang wächst informell	Änderungen werden in Meetings ohne Auswirkungsanalyse genehmigt
Risiken werden ignoriert, bis sie eintreten	Das Risikoprotokoll wird vierteljährlich statt wöchentlich gepflegt
Kosten überschreiten das Budget	Der Aufwand steht in den Zeitnachweisen, ist aber nicht Arbeitspaketen zugeordnet
Teams hören auf zu kommunizieren	Statusmeetings werden zu Berichtsrunden ohne Aktionen

Das sind öffentlich dokumentierte Fälle, keine Kundengeschichten. Ihre Ursachen sind die, die ich in der Beratung immer wieder sehe.

Lidl: rund sieben Jahre und geschätzte 500 Millionen Euro, dann gestoppt

Lidl startete sein Projekt eLWIS auf SAP Retail im Jahr 2011. Die Praxis der Bestandsbewertung bei Lidl wich von SAPs Standardmodell ab, und Lidl entschied sich, die Software anzupassen statt die Praxis. Bis 2018 war das System in Österreich, Nordirland und den USA live, aber der Vorstand kam zu dem Schluss, dass sich die ursprünglichen Ziele zu vertretbaren Kosten nicht erreichen ließen. Lidl stoppte das Projekt und entwickelte sein eigenes System weiter. Die Fachpresse schätzte die Ausgaben auf rund 500 Millionen Euro, und das für IT zuständige Vorstandsmitglied hatte das Unternehmen 2017 verlassen. Heise berichtete über die Entscheidung im Juli 2018. Die Lehre: Jahrelange Anpassung, um eine Altpraxis zu schützen, ist ein Steuerungsversagen, kein Softwareversagen.

Hershey: Halloween-Aufträge im Wert von rund 100 Millionen Dollar nicht ausgeliefert

Hersheys neues System aus SAP, Siebel und Manugistics sollte im April 1999 live gehen, in einem ruhigen Monat für Süßwaren. Der Start verschob sich um drei Monate auf Juli, genau als die Halloween-Bestellungen eintrafen. Aufträge kamen aus dem System nicht zu den Lagern. Der CEO sagte Analysten, die Probleme würden Hershey daran hindern, Waren im Wert von rund 100 Millionen Dollar für Halloween auszuliefern, und der Umsatz im dritten Quartal sank um 12,4 %. Der Bericht des CIO Magazine führt das eigentliche Versagen auf das Timing zurück. Eine Terminsteuerung, die die Hochsaison geschützt hätte, hätte einen anderen Go-live-Termin erzwungen.

Revlon: ein gestörtes Werk und eine wesentliche Schwäche in den Kontrollen

Revlon schaltete SAP im Februar 2018 in seinem Werk in Oxford, North Carolina, dem größten Produktionsstandort, ein. Serviceunterbrechungen trafen die Fertigung und die Lieferungen an große US-Händler. Im März 2019 legte Revlon eine wesentliche Schwäche der internen Kontrolle im Zusammenhang mit dem Rollout offen und nannte dabei eine fehlende wirksame laufende Risikobewertung und zu wenig geschulte Mitarbeiter in den betroffenen Bereichen. Investoren klagten; TechTarget berichtete über die Klage, in der Lieferungen von rund 64 Millionen Dollar als nicht erfüllt angegeben wurden.

Keiner dieser Fälle scheiterte, weil SAP die falsche Wahl war. Sie scheiterten an Grundlagen von Planung und Steuerung, die es seit Jahrzehnten gibt.

Projektstrukturplan

Ein Projektstrukturplan (PSP, englisch Work Breakdown Structure oder WBS) gliedert den gesamten Umfang in Liefergegenstände mit klaren Verantwortlichen. Ohne ihn bleibt Arbeit unsichtbar, bis sie überfällig ist. Bei einem SAP-Programm umfasst er Prozessdesign, Konfiguration, Datenmigration, Integration, Test, Schulung und Cutover, jeweils heruntergebrochen auf Aufgaben mit Verantwortlichem und Fälligkeitsdatum.

Der Wert liegt nicht im Dokument. Es erzwingt das Gespräch darüber, was getan werden muss, wer es tut und wovon es abhängt. Abhängigkeiten sind es, die Projekte töten. Eine Verzögerung bei der Datenmigration blockiert den Integrationstest, der den Abnahmetest (UAT) blockiert, was das Cutover-Fenster zusammendrückt. Ein PSP macht diese Kette sichtbar.

Terminmanagement

Zeitpläne scheitern aus vorhersehbaren Gründen. Leute werden abgezogen. Schätzungen waren falsch. Entscheidungen dauern länger als geplant. Bauen Sie von Anfang an Puffer ein, als expliziten Puffer bei den Aufgaben, die ihn am ehesten brauchen, nicht als Polster, das überall verteilt ist.

Verfolgen Sie den Zeitplan wöchentlich. Eine Woche Verzug in Woche vier ist ein Gespräch. Vier Wochen Verzug in Woche sechzehn sind eine Krise. Dasselbe Problem, ganz andere Kosten für die Behebung.

Behandeln Sie den Go-live-Zeitpunkt als eigene Entscheidung. Gehen Sie nie in einer Spitzenzeit des Geschäfts live. Die Lehre aus Hershey gilt für jedes Unternehmen.

Budgetsteuerung

Budgets brechen aus drei Gründen: ungesteuerte Umfangsänderungen, unterschätzte Datenmigration und Hypercare-Kosten über den frühen Schätzungen. Verfolgen Sie die Ist-Ausgaben ab Woche eins gegen den Plan. Wenn eine Abweichung den Lenkungsausschuss erreicht, ist es meist zu spät, sie ohne Störungen zu korrigieren.

Änderungskontrolle ist der wichtigste Budgetschutz. Jede Umfangsänderung bekommt vor der Genehmigung eine Auswirkungsanalyse zu Zeit, Kosten und Ressourcen. Kommt die Analyse nach der Genehmigung, hat die Änderung das Budget umgangen. Mein Leitfaden zum Vermeiden von Scope Creep bei SAP-Einführungen geht tiefer auf das Change Board ein.

Risikomanagement

Ein Risikoregister, das vierteljährlich gepflegt wird, ist Theater. Risiken brauchen eine wöchentliche Prüfung, benannte Verantwortliche und Reaktionspläne. Benennen Sie bei jedem SAP-Programm diese: zu spät entdeckte Datenqualität, Integrationsverzögerungen, Lücken bei der Verfügbarkeit von Ressourcen, ein zusammengedrücktes Cutover-Fenster und mangelnde Nutzerakzeptanz.

Bei einem Kunden gingen drei Monate verloren, weil der Anbieter der Datenmigration einen Termin nach dem anderen verpasste. Wir hörten immer wieder „nur noch zwei Wochen", bis es zu spät war, den Anbieter zu wechseln, ohne das Budget zu sprengen. Ein Risiko mit Verantwortlichem und Auslösedatum hätte diese Entscheidung Monate früher erzwungen. Meine Risikobewertungsmatrix für SAP-Projekte bietet eine Vorlage, um diese Risiken zu bewerten und zuzuordnen.

Kommunikation und Eskalation

Führungskräfte brauchen Schlagzeilen. Delivery-Teams brauchen Details. Projektmanager brauchen Abweichungsdaten. Ein Update für alle hilft niemandem.

Dokumentieren und proben Sie Eskalationswege vor einer Krise. Bei einer SAP-Einführung ging die IT davon aus, dass das Finanzwesen die Konfiguration prüft, und das Finanzwesen ging davon aus, dass es die IT tut. Niemand sprach es an, bis das Go-live noch drei Monate entfernt war und wichtige Freigaben fehlten; die Lösung war eine hektische Last-Minute-Aktion, Zusatzkosten und ein verspäteter Rollout. Ein anderes Unternehmen machte es richtig: Das Reporting war strukturiert und an Aktionen gekoppelt, sodass bei jedem Problem klar war, wer es verantwortet, welche Auswirkung es hat und wie es gelöst wird.

Beim Umfang zahlt sich Eskalation aus. Ich habe mit einer Fluggesellschaft gearbeitet, die mit einem einfachen Buchungs-Upgrade begann. Sechs Monate später waren Änderungen am Treueprogramm, die Crew-Planung und Finanzmodule dazugekommen. Nichts davon war dringend. Niemand sagte Nein. Der Zeitplan verdoppelte sich, die Kosten stiegen um 70 %.

Das On-Premise-Playbook übersteht RISE with SAP nicht unverändert. Drei Dinge sind anders.

RISE verändert, an wen Sie eskalieren

Bei RISE with SAP betreibt SAP die Infrastruktur und den technischen Betrieb und stellt ein Customer-Success-Team, das die Nutzung verfolgt. Ihre Steuerungsstruktur muss es einbeziehen. Bei Plattformproblemen (Systemleistung, Hyperscaler-Region, SAP-Servicelevel) braucht der Programmmanager einen dokumentierten Eskalationsweg zu SAP, der nicht über den Implementierungspartner läuft. Schreiben Sie ihn auf, bevor Sie ihn brauchen.

Clean Core gibt der Umfangssteuerung einen technischen Rückhalt

Jede Lücke braucht heute eine Entscheidung: konfigurieren, über freigegebene APIs erweitern (on-stack mit ABAP Cloud oder side-by-side auf SAP BTP) oder ablehnen. In S/4HANA Cloud Public Edition ist eine Änderung des Kerns keine Option. In der Private Edition und On-Premise ist sie möglich, aber SAPs Clean-Core-Leitlinien behandeln sie als letzten Ausweg, weil jede Modifikation Upgrade-Aufwand erzeugt.

Das hilft der Umfangssteuerung. Eine Anfrage, den Standardprozess Order-to-Cash „einfach ein wenig anzupassen", ist kein beiläufiges Konfigurationsgespräch mehr, sondern eine Erweiterung mit Design-, Build- und Testaufwand. Setzen Sie unterhalb des Lenkungsausschusses ein kleines Gremium für die Prüfung von Erweiterungen ein, mit einem Architekten, der die Befugnis hat, zu genehmigen oder abzulehnen. Ohne es landet jede Diskussion über Anpassungen im Lenkungsausschuss.

KI entwirft die Berichte, Menschen treffen die Entscheidungen

KI hilft heute beim Papierkram der Steuerung. SAP Cloud ALM, SAPs Werkzeug für das Application-Lifecycle-Management, hält Projektaufgaben, Anforderungen und Teststatus und kann aus Workshop-Transkripten Anforderungsentwürfe erzeugen. Microsoft Copilot entwirft aus Dashboards und Statusberichten Abweichungszusammenfassungen für die Unterlagen des Lenkungsausschusses. Anomalieerkennung in Power BI oder SAP Analytics Cloud markiert KPIs, die von ihrem üblichen Muster abweichen. Das ist nützlich für Ressourceneinsatz, die Zahl der Change Requests und Support-Tickets, weniger für Kennzahlen, die von Natur aus schwanken.

Was KI nicht tut, ist handeln. Ein Dashboard kann Terminverzug sechs Wochen lang rot anzeigen. Unternimmt der Lenkungsausschuss nichts, geht der Verzug weiter.

Das ist der Mindestrhythmus für ein Programm in aktiver Umsetzung. Fehlt eine Zeile, ergänzen Sie sie vor allem anderen.

Steuerung	Mindestpraxis	Verantwortlich	Häufigkeit
Projektstrukturplan	Jede Aufgabe hat einen Verantwortlichen, ein Fälligkeitsdatum und ihre Abhängigkeiten	PMO-Leiter	Wöchentlich aktualisiert
Terminprüfung	Jede Aufgabe mit mehr als drei Tagen Verzug markieren; den kritischen Pfad prüfen	Programmmanager	Wöchentlich
Budgetverfolgung	Ist gegen Plan je Arbeitspaket	Finanzverantwortlicher des Programms	Wöchentlich, monatlich berichtet
Risikoprüfung	Jedes aktive Risiko hat einen Verantwortlichen, einen Auslöser und eine Reaktion	Workstream-Leiter	Wöchentlich
Änderungskontrolle	Auswirkungsanalyse zu Zeit, Kosten und Ressourcen vor der Genehmigung	Vorsitz des Change Boards	Wöchentlich oder bei Eingang von Anfragen
Erweiterungsprüfung (RISE und GROW)	Entscheidung zu konfigurieren, zu erweitern oder abzulehnen für jede Lücke	Lösungsarchitekt	Alle zwei Wochen
Lenkungsausschuss	Entscheidungen, kein Status; Unterlagen vorab versandt	Executive Sponsor	Alle zwei Wochen; wöchentlich in Cutover und Hypercare

Planung und Steuerung scheitern meist nicht daran, dass die Methode falsch war, sondern daran, dass die Disziplin bis Monat vier nachließ. Halten Sie den Rhythmus klein genug, dass das Team ihn auch in Monat vierzehn noch durchhält. Zum Lenkungsausschuss selbst lesen Sie meinen Leitfaden zum Aufbau eines wirksamen SAP-Lenkungsausschusses.

Was ist der Unterschied zwischen Projektplanung und Projektsteuerung?

Die Planung erzeugt die Roadmap: Umfang, Zeitplan, Budget, Ressourcen und Risiken. Sie gibt zu Beginn die Richtung vor.

Steuerung ist die laufende Arbeit, den Fortschritt gegen diesen Plan zu verfolgen, Abweichungen sichtbar zu machen, Abhängigkeiten zu managen und die Baseline neu zu setzen, wenn formale Änderungen anfallen. Sie findet jede Woche statt, solange das Programm läuft.

Die meisten SAP-Programme investieren stark in Planung und zu wenig in Steuerung. Bis eine Abweichung im Lenkungsausschuss auftaucht, haben sich Wochen oder Monate an Korrekturkosten aufgebaut.

Warum scheitern SAP-Projekte trotz Projektplan?

Weil niemand mit dem Plan arbeitet. Abhängigkeiten werden nicht verfolgt, sodass die Verzögerung in einem Workstream einen anderen stillschweigend blockiert. Risikoprotokolle werden vierteljährlich aktualisiert. Umfangsänderungen werden informell genehmigt. Der Lenkungsausschuss tagt monatlich und sieht Meilenstein-Zusammenfassungen, die verbergen, was vor Ort passiert.

Lidl, Hershey und Revlon hatten alle Pläne. Was ihnen fehlte, war aktive Steuerung: ehrliches Tracking, frühe Eskalation und eine echte Reaktion, als Warnsignale auftauchten.

Wie gehe ich mit Scope Creep in einem langen SAP-Programm um?

Geben Sie jeder Umfangsänderung vor der Genehmigung eine schriftliche Auswirkungsanalyse: Zeit, Kosten und Ressourcen. Ohne sie bedeutet die Genehmigung einer Änderung die Genehmigung einer Unbekannten.

Die wirksamste Regel: Jede Ergänzung muss etwas anderes verdrängen. Diese eine Einschränkung zwingt die Fachbereichsleiter, ehrlich zu priorisieren.

Die Führungsebene muss dahinterstehen. Wenn ein CFO oder COO die Änderungskontrolle öffentlich unterstützt, gehen informelle Anfragen schnell zurück. Bei RISE- und GROW-Programmen ergänzt die Erweiterungsentscheidung für jede Lücke eine technische Prüfung.

Was ist ein Projektstrukturplan, und warum ist er bei SAP wichtig?

Ein PSP gliedert den gesamten Umfang in Liefergegenstände, jeweils mit Verantwortlichem und Fälligkeitsdatum. Bei einem SAP-Programm sind das Prozessdesign, Konfiguration, Datenmigration, Integration, Test, Schulung und Cutover, alles heruntergebrochen auf Aufgaben.

Sein praktischer Wert liegt in der Abbildung der Abhängigkeiten. Die Datenmigration speist den Integrationstest, dieser den UAT, dieser das Cutover. Rutscht eines davon, sind die Folgen weiter unten in der Kette sofort sichtbar.

Wie verändert RISE with SAP die Projektplanung und -steuerung?

SAP wird Teilnehmer an der Umsetzung. Es betreibt die Infrastruktur und den technischen Betrieb, und sein Customer-Success-Team fährt einen eigenen Rhythmus zu Nutzung und Wertbeitrag.

Daraus folgen drei Änderungen. Sie brauchen einen dokumentierten Eskalationsweg zu SAP für Plattformprobleme, der nicht über den Partner läuft. Sie brauchen unterhalb des Lenkungsausschusses ein Gremium für die Erweiterungsprüfung, das entscheidet, wie jede Lücke unter Clean Core behandelt wird. Und Sie sollten SAPs Customer-Success-Rhythmus in Ihre Governance einbinden, statt ihn parallel laufen zu lassen.

Was sollte ein Lenkungsausschuss in einem SAP-Programm tun?

Entscheidungen treffen. Seine Aufgabe ist es, zu lösen, was das Programmteam nicht lösen kann: Ressourcenkonflikte, Umfangsstreitigkeiten, Budgetänderungen und alles, was bereichsübergreifende Befugnis braucht. Ein Lenkungsausschuss, der ohne Entscheidungen endet, war ein Status-Update.

Ein monatlicher Lenkungsausschuss bei einem großen Programm lässt Probleme bis zu vier Wochen liegen. Alle zwei Wochen ist das Minimum in der aktiven Umsetzung, wöchentlich in Cutover und Hypercare. Versenden Sie Fortschrittsberichte vorab und nutzen Sie die Sitzung für die Entscheidungen, die sie aufwerfen.