So vermeiden Sie Scope Creep bei einer SAP-Einführung

Scope Creep bei einer SAP-Einführung vermeiden Sie, indem Sie jede Änderung sichtbar und ihre Freigabe teuer machen. Halten Sie schriftlich fest, was nicht zum Umfang gehört, und zwar so sorgfältig wie das, was dazugehört. Leiten Sie jede Anforderung durch die Change Control, mit einer Auswirkungsanalyse zu Zeit, Kosten und Qualität. Verlangen Sie bei jeder Ergänzung einen Trade-off. Setzen Sie einen Termin für den Scope Freeze, den die Unternehmensleitung mitträgt, und übertragen Sie dieselbe Disziplin auf den Vertrag mit dem Systemintegrator (SI). Dieser Leitfaden richtet sich an Programmleiter, Sponsoren und PMOs von S/4HANA-Programmen. Nutzen Sie die Tabelle zu den Änderungskosten und die Vertragsklauseln weiter unten in Ihren nächsten Unterlagen für den Lenkungsausschuss.

Die meisten SAP-Projekte überschreiten Budget und Termine, und Scope Creep ist der häufigste Grund dafür. Ich habe mit Dutzenden von Unternehmen gearbeitet, deren SAP-Projekte aus dem Ruder liefen. Drei Signale zeigen sich, bevor die Überschreitung im Bericht an den Lenkungsausschuss ankommt. Kleine Änderungen häufen sich ohne Auswirkungsanalyse. Die Change Control läuft über persönliche Beziehungen statt über dokumentierte Entscheidungsbefugnis. Und der Sponsor genehmigt beim Kaffee Dinge, von denen das Projektteam erst eine Woche später erfährt.

Ein Pharmakunde startete mit einem klaren Zeitplan von 18 Monaten. Drei Jahre später war er noch immer in der Einführung, und die Kosten hatten sich verdoppelt. Der CIO eines Fertigungsunternehmens erzählte mir, sein Team habe ganze Module verworfen, an deren Konfiguration es monatelang gearbeitet hatte, weil sich die Anforderungen ständig änderten. Der Umfang war so weit gewachsen, dass niemand den ursprünglichen Plan wiedererkannte.

Das sind keine Randfälle. So scheitern SAP-Programme am häufigsten.

Es beginnt harmlos. Ein Fachbereichsleiter bittet um „nur eine kleine Änderung“. Dann um die nächste. Der Satz „Wenn wir schon dabei sind, dann doch noch …“ hat mehr SAP-Einführungen aus der Spur geworfen als jede technische Herausforderung.

Bei einem Handelskunden fingen wir sauber an: das Finanzwesen im Kern und die einfache Materialwirtschaft. Nach sechs Monaten wollte der CMO Kundenanalysen. Dann brauchte der COO erweiterte Lagerfunktionen. Der ursprüngliche Zeitplan von neun Monaten geriet in Gefahr. Ich habe dagegengehalten und beide Anforderungen abgelehnt. Genau diese Disziplin macht die Aufgabe aus.

Nicht jede Änderung ist Scope Creep. Manchmal stößt man im Design auf kritische Lücken, die niemand vorhergesehen hat. Manchmal ändern sich mitten im Projekt Vorschriften. Das sind berechtigte Änderungen, und sie durchlaufen einen Prozess mit Anpassung von Zeitplan und Budget. Scope Creep dagegen taucht einfach auf, meist nach einem Gespräch auf dem Flur.

Ein Fertigungskunde begann mit 10 eigenen Berichten und endete bei 47, und jeder einzelne brachte zusätzlichen Aufwand für Design, Entwicklung und Test. Allein der Berichts-Workstream lag 200 % über dem Budget.

200 %

Budgetüberschreitung im Berichts-Workstream, nachdem Scope Drift die Zahl der eigenen Berichte von 10 auf 47 getrieben hatte

Quelle: Programm eines Fertigungskunden

Warnsignale

Auf diese Zeichen achte ich, jeweils mit der passenden Reaktion:

Warnsignal	Eigentliche Ursache	Reaktion
„Nur noch eine Sache“ wird zur Alltagssprache	Unklare Scope-Grenzen	Baseline mit den Fachbereichsleitern neu setzen; formale Change Control durchsetzen
Fachbereichsleiter ergänzen Funktionen informell	Kein Verständnis für die Folgen in nachgelagerten Prozessen	Jede Anforderung durch die Auswirkungsanalyse schicken; die Kosten zeigen
Zeitplan verlängert sich ohne formale Neuplanung	Stille Ausweitung des Umfangs	Scope-Checkpoints abhalten; Neuplanung mit Freigabe des Change Boards
Dokumentation passt nicht mehr zu dem, was gebaut ist	Informeller Umgang mit dem Scope, keine Versionierung	Spezifikationen und Pläne bei jeder genehmigten Änderung aktualisieren
Budgetverbrauch läuft dem Fortschritt davon	Versteckter Aufwand aus nicht dokumentierten Änderungen	Aufwand gegen Arbeitspakete verfolgen; Abweichungen untersuchen
Team arbeitet nachts und am Wochenende, um aufzuholen	Scope übersteigt die Kapazität	An das Change Board eskalieren; eine Scope-Entscheidung erzwingen
Schuldzuweisungen zwischen Fachbereich, IT und Partner	Der Scope ist bereits außer Kontrolle geraten	Scope einfrieren, Ursachenanalyse durchführen, Baseline zurücksetzen

Alles hängt zusammen

SAP verbindet alles miteinander. Das Finanzwesen wirkt auf die Lieferkette. Das Personalwesen berührt die Abrechnung. Der Vertrieb hängt am Bestand. Eine einzige Änderung kann zehn Dinge kaputt machen.

Ein Kunde ergänzte in seinem Bestellprozess ein einzelnes Feld. Das sah banal aus. Es legte drei Schnittstellen lahm und erzwang das Neuschreiben von Berichten in mehreren Abteilungen. Ein anderer Kunde bat um eine „winzige Änderung“ an seinem Kalkulationsschema. Es stellte sich heraus, dass dafür die gesamte Preisfindung neu konfiguriert werden musste: drei Wochen Arbeit und 40.000 $ an Beratungshonoraren, für eine winzige Änderung.

Eine Chance pro Jahrzehnt

Die meisten Unternehmen führen SAP nur alle 10 bis 15 Jahre ein. Jede Abteilung weiß, dass sie ein Jahrzehnt lang keine zweite Chance bekommt. Niemand will „Phase 2“ hören, was in den meisten Organisationen heißt: nie. Also wird alles in das laufende Projekt gedrückt, und aus der Scope-Liste wird eine Wunschliste.

Was Clean Core ändert

Clean Core bremst Anpassungen technisch aus. In S/4HANA Cloud Public Edition ist eine Modifikation des Kerns nicht möglich: Erweiterungen laufen über freigegebene APIs, On-Stack oder Side-by-Side auf SAP BTP. In der Private Edition und On-Premise sind Modifikationen weiterhin möglich, doch SAP behandelt sie in seinen Empfehlungen als letzten Ausweg, weil jede einzelne zusätzlichen Aufwand bei Upgrades verursacht.

Der nützliche Nebeneffekt ist Scope-Disziplin. Aus der Bitte, „nur schnell diesen Genehmigungsschritt in den Standardprozess Order-to-Cash einzubauen“, wird kein beiläufiges Konfigurationsgespräch mehr, sondern eine Erweiterung mit eigenen Kosten für Design, Entwicklung und Test. Richten Sie unterhalb des Lenkungsausschusses ein Gremium zur Prüfung von Erweiterungen ein, mit einem Architekten, der genehmigen oder ablehnen kann, und viele dieser Anfragen enden, bevor sie in die Baseline gelangen. On-Premise-Programme ohne ein solches Gremium fallen in die alten Muster zurück. Mein Leitfaden zu Clean Core erklärt, wie Sie eines aufsetzen.

1. Definieren Sie den Scope mit ausdrücklichen Ausschlüssen. Dokumentieren Sie, was nicht zum Umfang gehört, so sorgfältig wie das, was dazugehört, und lassen Sie beides unterzeichnen. Wo etwas unklar bleibt, beginnen die Streitigkeiten.
2. Führen Sie eine formale Change Control mit Konsequenzen. Jede Änderung braucht eine Auswirkungsanalyse zu Kosten, Zeit und Qualität, die für den Genehmigenden sichtbar ist.
3. Kommunizieren Sie die Scope-Grenzen in jeder Sitzung des Lenkungsausschusses. Zeigen Sie den Scope-Status in einer einfachen Ampelansicht aus Rot, Gelb und Grün. Vieles an Drift ist schlicht Missverständnis.
4. Schreiben Sie einen Scope-Management-Plan. Legen Sie fest, wie Änderungen bewertet, genehmigt, eskaliert und nachverfolgt werden, damit jeder Workstream sie gleich behandelt. Meine Vorlage für den SAP-Projektumfang liefert eine Grundstruktur.
5. Priorisieren Sie mit MoSCoW. Must have, Should have, Could have und Won't have für diesmal. Achten Sie streng darauf, die Must-have-Liste kurz zu halten.
6. Versionieren Sie jede Entscheidung. Jede genehmigte Änderung aktualisiert die Baseline. Jede abgelehnte Änderung wird mit der Begründung protokolliert.
7. Verlangen Sie Trade-offs. Kommt eine neue Anforderung herein, muss etwas anderes raus. Must-haves werden schnell optional, wenn sie etwas kosten.

Drei Techniken, die ich eingesetzt habe, sorgen dafür, dass das hält.

Disziplin bei der Unterschrift. Lassen Sie die Fachbereichsleiter genehmigte Anforderungen unterschreiben. In einem Programm schwor ein Fachbereichsleiter, er habe einen bestimmten Prozessablauf nie freigegeben. Wir legten das Dokument mit seiner Unterschrift vor, und die Diskussion war beendet. Die Unterschrift ist keine Bürokratie. Sie verhindert, dass dieselbe Diskussion sechs Monate später von vorn beginnt.

Zeigen Sie die Folgewirkungen. Für einen Kunden habe ich eine Demonstration gebaut, die zeigte, wie sich die Änderung eines einzigen Feldes im Kundenauftrag auf 14 Bereiche auswirken würde, von Berichten über Schnittstellen bis zu Berechtigungsrollen. Das Verhalten änderte sich. Aufklärung kostet Stunden. Fehlendes Verständnis für Folgewirkungen kostet Monate.

Zeigen Sie die Kosten der Änderung. Eine Änderung während des Designs kann 5.000 $ kosten. Dieselbe Änderung während des Tests kann 50.000 $ kosten. Legen Sie den Leuten dazu eine einfache Grafik vor, und beiläufige Anfragen werden seltener.

Das sind Richtwerte für die Änderungskosten bei S/4HANA-Programmen im US-Markt. Sie schwanken mit Komplexität und Partner. Verstehen Sie sie als Anhaltspunkte, nicht als Angebote.

Phase	Typische Kosten einer kleinen Änderung	Typische Kosten einer mittleren Änderung
Explore (Design)	2 bis 10 Tsd. $	10 bis 30 Tsd. $
Frühe Realize-Phase	5 bis 20 Tsd. $	20 bis 80 Tsd. $
Mittlere Realize-Phase (Entwicklung)	15 bis 50 Tsd. $	50 bis 200 Tsd. $
Späte Realize-Phase (Test)	30 bis 100 Tsd. $	100 bis 400 Tsd. $
Deploy und Cutover	80 bis 300 Tsd. $	300 Tsd. bis 1 Mio. $ und mehr
Hypercare (nach dem Go-live)	150 bis 500 Tsd. $	500 Tsd. bis 2 Mio. $ und mehr

Das Muster entspricht dem, was die Forschung seit Jahrzehnten feststellt. Eine NASA-Studie zur Kostenentwicklung von Fehlern fand heraus, dass ein Anforderungsfehler, der erst in Integration und Test auffiel, 21- bis 78-mal so viel in der Behebung kostete wie einer, der schon in der Anforderungsphase entdeckt wurde, und im laufenden Betrieb noch weit mehr. Scope Governance soll Änderungen auf der günstigen Seite dieser Kurve halten.

Vertragsklauseln, auf die es ankommt

Vage Verträge schaffen teure Probleme. Ich habe erlebt, wie ein Kunde einen Vertrag unterschrieb, in dem nur stand: „S/4HANA einführen“. Der Partner behauptete später, bestimmte Prozesse seien Zusatzleistungen mit eigenen Gebühren, und der Kunde zahlte am Ende doppelt. Diese Klauseln verhindern das:

Klausel	Zweck
Scope mit ausdrücklichen Ausschlüssen	Begrenzt, was der Festpreis abdeckt, und beseitigt Unklarheit bei Zusatzleistungen
Vorab vereinbarte Sätze für häufige Änderungen	Fixiert die Preise für Berichte, Schnittstellen und Konfigurationsänderungen, bevor Druck entsteht
Kontinuität der Berater	Verhindert, dass neue Berater abgeschlossene Entscheidungen wieder aufmachen und den Scope ausweiten
Genehmigungsbefugnis auf beiden Seiten	Verhindert, dass Junior-Berater Funktionen zusagen, die niemand autorisiert hat
Abrechnung nach Meilensteinen	Bindet die Zahlung an abgenommene Liefergegenstände statt an verstrichene Zeit
Abnahmekriterien je Liefergegenstand	Definiert „fertig“, bevor jemand darüber streitet
Klausel zu Clean-Core-Erweiterungen	Verlangt, dass Erweiterungen freigegebene APIs oder SAP BTP nutzen; erspart Nacharbeit beim ersten großen Upgrade

Meine Hinweise zur Verhandlung von ERP-Verträgen zeigen, wie Sie diese Klauseln durchsetzen.

Change Control Board

Ein Change Board funktioniert, wenn die richtigen Leute darin sitzen. Meines besetze ich mit drei Rollen: einem fachlichen Entscheider, dem es um die Funktion geht, einem Projektleiter, dem es um den Zeitplan geht, und einem Finanzverantwortlichen, dem es um das Budget geht. Dieses Gleichgewicht verhindert, dass eine einzelne Priorität dominiert.

1. 01Anforderung gestelltSchriftlich, nicht beim Kaffee
2. 02AuswirkungsanalyseZeit, Kosten und Qualität, bevor jemand genehmigt
3. 03Trade-off benanntEtwas anderes entfällt, um Platz zu schaffen
4. 04Change Board entscheidetFachbereich, Projekt und Finanzen am Tisch
5. 05Baseline aktualisiertAbgelehnte Änderungen mit Begründung protokolliert

Der Scope bewegt sich nur über das Board

Das Board braucht echte Entscheidungsbefugnis. In einem Programm fand keine einzige Scope-Änderung ohne seine Freigabe statt. Nicht eine. Absprachen auf dem Flur hörten auf. Als der Vertriebsleiter neue Anforderungen durchzuschmuggeln versuchte, konnte das Team auf eine dokumentierte Genehmigungsmatrix verweisen.

Die meisten Entscheidungen sollten auf Board-Ebene bleiben. Nur echte Streitfälle gehen zum Sponsor, so bleibt der Sponsor eingebunden, ohne unterzugehen. Halten Sie alle zwei Wochen einen Scope-Review mit den Workstream-Leitern ab und berichten Sie, wie viele Anforderungen gestellt, genehmigt und abgelehnt wurden. Wenn Menschen in einem Statusbericht „15 % Scope-Wachstum in diesem Monat“ lesen, ändert sich das Verhalten.

Manche Änderungen sind notwendig. Einen meiner Pharmakunden trafen mitten in der Einführung neue FDA-Vorschriften. Sie mussten umgesetzt werden. Das ist kein Scope Creep. Das ist die Realität.

Kommt eine berechtigte Änderung, stellen Sie zwei Fragen. Was ist die kleinste Lösung, die funktioniert? Und an den Antragsteller gerichtet: Was sind Sie bereit zu streichen, um Platz zu schaffen? Die Dringlichkeit sinkt schnell, wenn eine Anforderung etwas kostet.

Die Optionen sind: den Zeitplan verlängern, Budget aufstocken, andere Anforderungen streichen, Personal aufstocken oder eine Mischung davon. Was auch immer Sie wählen, dokumentieren Sie es und aktualisieren Sie alle Baseline-Dokumente auf einmal. Veraltete Dokumente schaffen die nächste Runde an Scope-Problemen.

KI hilft inzwischen beim Papierkram. Assistenten wie Microsoft Copilot fassen lange Threads zu Änderungsanträgen zu einer entscheidungsreifen Vorlage für das Board zusammen, und SAP Cloud ALM hält Anforderungen, Änderungen und Tests verknüpft, sodass sich die Auswirkung einer Änderung leichter nachverfolgen lässt. KI kann zeigen, dass eine Änderung 14 Bereiche berührt. Sie kann der COO nicht sagen, dass ihre Anforderung bedeutet, dass die Anforderung des CFO nicht umgesetzt wird. Dieses Gespräch bleibt Ihres.

Ein Fertigungsunternehmen, mit dem ich gearbeitet habe, schloss sein SAP-Projekt pünktlich ab, was seltener vorkommt, als es sollte. Es legte früh einen Termin für den Scope Freeze fest, und jede Änderung danach brauchte die persönliche Freigabe des CEO. Das Projekt endete mit Restbudget, und beim Go-live arbeitete niemand am Wochenende.

Ein anderer Kunde arbeitete mit einem Token-System: Jede Abteilung erhielt für das gesamte Projekt drei Change-Tokens. Sie wollen eine Änderung? Dann geben Sie einen Token aus. Die Leute überlegten genau, was wirklich zählte, und „Must-haves“ wurden neu bewertet, sobald sie mit einer begrenzten Währung bezahlt werden mussten.

Keiner der beiden Ansätze ist kompliziert. Beide brauchen Disziplin und Rückhalt der Führung. Der Test für jeden Scope-Prozess ist der Tag, an dem der COO mit „nur einer kleinen Änderung“ in den Projektraum kommt. Bauen Sie ihn für diesen Tag.

Was ist Scope Creep in einem SAP-Projekt?

Das schleichende, unkontrollierte Wachstum von Anforderungen, ohne dass Zeitplan, Budget oder Ressourcen entsprechend angepasst werden. In SAP beginnt es meist mit kleinen Ergänzungen: zusätzliche Berichte, zusätzliche Felder, „nur eine kurze Workflow-Änderung“. Jede wirkt harmlos. Zusammen kosten sie Monate.

Berechtigte Scope-Änderungen durchlaufen einen Prozess und gehen mit Anpassungen bei Zeitplan und Budget einher. Scope Creep kommt informell und umgeht die Change Control.

Was sind die häufigsten Ursachen für Scope Creep in SAP-Projekten?

Drei tauchen immer wieder auf: vage Anforderungen am Anfang, sodass sich alles als zum Umfang gehörig begründen lässt; keine formale Change Control, sodass Änderungen auf jeder Ebene hineinrutschen; und die Denkweise „einmal pro Jahrzehnt“, bei der jede Abteilung versucht, die Probleme von Jahren in diesem einen Projekt zu lösen.

Die enge Verzahnung in SAP verstärkt alle drei. Eine Änderung kann zehn verbundene Prozesse beschädigen, und wenn die Fachbereichsleiter diese Zusammenhänge nicht sehen, zeigt sich die Wirkung erst im Test, wo sie ein Vielfaches kostet.

Wie verändert Clean Core das Risiko von Scope Creep?

Es wirkt als technische Bremse. In S/4HANA Cloud Public Edition lässt sich der Kern nicht modifizieren, also wird jede Lücke zu einer Erweiterung mit eigenen Kosten für Design, Entwicklung und Test. In der Private Edition und On-Premise sind Modifikationen möglich, verursachen aber Aufwand bei Upgrades, weshalb SAP in seinen Empfehlungen davon abrät.

Ein Gremium zur Prüfung von Erweiterungen, mit einem Architekten, der entscheiden darf, stoppt viele Anfragen, bevor sie in die Baseline gelangen. Ohne ein solches Gremium rutschen On-Premise-Programme in alte Gewohnheiten zurück.

Was ist der Unterschied zwischen Scope Creep und Gold-Plating?

Scope Creep geht vom Fachbereich aus: Anforderungen über das Vereinbarte hinaus. Gold-Plating geht vom Umsetzungsteam aus: Komplexität, die niemand verlangt hat.

Auf SAP bezogen heißt Gold-Plating: Ein Berater baut aufwendige Workflow-Logik, wo einfaches Routing genügt hätte. Scope Creep heißt: Der COO verlangt sechs Monate nach Projektstart erweiterte Lagerfunktionen in einem Projekt, das nur die einfache Materialwirtschaft (MM) vorsah. Beide treiben Kosten und Zeit in die Höhe, und beide verlangen dieselbe Disziplin.

Wie bauen Sie eine Change Control auf, die wirklich funktioniert?

Drei Elemente. Jede Anforderung bringt eine Auswirkungsanalyse zu Zeitplan, Budget und Ressourcen mit. Im Genehmigungsgremium sitzt für jeden dieser drei Punkte jemand, dem er wichtig ist, nicht nur Fachbereichsleiter, die alles genehmigen würden. Und jede Ergänzung verlangt einen Trade-off: Etwas anderes fliegt raus.

Allein diese letzte Regel filtert Anforderungen heraus, die nicht wirklich kritisch sind.

Lässt sich Scope Creep ganz vermeiden?

Nein. In jedem Programm, das länger als einige Monate läuft, verschieben sich die Geschäftsbedingungen, ändern sich Vorschriften und deckt das Design Lücken auf.

Das Ziel ist Kontrolle, nicht Beseitigung. Kontrollierte Änderungen folgen einem dokumentierten Prozess, werden auf ihre Auswirkung geprüft und aktualisieren die Baseline. Unkontrollierte Änderungen umgehen den Prozess und tauchen im Test oder nach dem Go-live als Kosten auf, die niemand eingeplant hat.

Wie gehen Sie mit einem Scope Freeze in einem langen SAP-Programm am besten um?

Geben Sie ihm eine Konsequenz und sichtbaren Rückhalt der Führung. Die wirksamste Variante, die ich eingesetzt habe: Der Termin des Freeze steht von Tag eins an in der Projektcharta, der Änderungsprozess legt fest, was „Freeze“ in der Praxis bedeutet, und der Sponsor bekräftigt ihn im Lenkungsausschuss öffentlich, bevor der Termin erreicht ist.

Wenn der CEO nach dem Freeze jede Änderung persönlich genehmigen muss, bleibt die Liste sehr kurz.