Vorlage für den SAP-Projektumfang: was Sie definieren und ausschließen

Eine Vorlage für den SAP-Projektumfang definiert, was das Programm liefern wird, was es bewusst nicht liefern wird, wer jeden Teil verantwortet und wie sich der Umfang ändern darf. Die neun Abschnitte unten decken das ab. Die zwei, auf die es am meisten ankommt, sind die, die Teams überspringen: ausdrückliche Ausschlüsse und der Umfang der Datenmigration. Füllen Sie die Vorlage vor Beginn der Konfiguration aus und lassen Sie sie von Sponsor und Prozessverantwortlichen unterzeichnen.

Manchmal füllen Teams eine Umfangsvorlage aus und gehen weiter. Dieser Teil fühlt sich leicht an. Wochen später, im Design oder Build, weist jemand auf einen Prozess hin, der „als im Umfang enthalten angenommen“ wurde. Das Gespräch wird unangenehm. Niemand hat es aufgeschrieben. Niemand wollte es weglassen. Ich habe das zu oft erlebt. Ein paar ungeprüfte Annahmen am Anfang bringen das Projekt unbemerkt um Wochen vom Kurs ab.

Aufgabe des Umfangsdokuments ist es nicht, festzuhalten, was die Leute im Raum gesagt haben. Es soll Klarheit erzwingen, bevor die Konfiguration Annahmen festschreibt, die sich nur teuer rückgängig machen lassen.

Das sind die neun Abschnitte, jeweils mit den Fragen, die sie beantworten müssen.

1. Ziele

Warum wird diese Arbeit gemacht, und was sieht das Unternehmen, wenn sie abgeschlossen ist? Verknüpfen Sie jedes Ziel mit einem messbaren Ergebnis: den Monatsabschluss um drei Tage verkürzen, manuelle Abstimmungen über drei Gesellschaften beseitigen, eine einheitliche Sicht auf den Bestand über alle Werke. Vage Ziele erzeugen vage Erfolgskriterien, und die Meinungsverschiedenheit tritt im Anwenderakzeptanztest (UAT) zutage.

2. Umfangsdefinition

Module, rechtliche Einheiten, Werke, Länder, Sprachen, Integrationen und das Bereitstellungsmodell. Seien Sie konkret. „Finanzen“ ist kein Umfang. „Finanzwesen und Controlling (FI/CO) für Kreditoren, Debitoren, Hauptbuch und Kostenstellenrechnung der VAE-Gesellschaft auf S/4HANA Cloud Private Edition“ ist Umfang.

3. Ausschlüsse

Hier scheitern die meisten Umfangsvorlagen. Ist etwas nicht als ausgeschlossen aufgeschrieben, nimmt jemand an, dass es enthalten ist. Ausschlüsse, die Sie namentlich festhalten sollten:

1. Länder oder Gesellschaften, die auf eine spätere Phase verschoben werden.
2. Altintegrationen, die vorerst unverändert bleiben.
3. Historische Daten vor einem definierten Stichtag.
4. Berichte, die auf eine Erweiterungsliste nach dem Go-live verschoben werden.
5. Regulatorische Anforderungen, die bis zur rechtlichen Bestätigung zurückgestellt werden.

Geben Sie jedem Ausschluss die Phase an, in die er verschoben wird, falls es eine gibt. Ein unterzeichneter Ausschluss macht aus einem zweiwöchigen Streit ein kurzes Gespräch.

4. Umfang der Datenmigration

Ein durchgängiger blinder Fleck. Beantworten Sie drei Fragen schriftlich:

1. Was wird migriert? Nur offene Posten oder auch die Historie? Alle Kunden und Lieferanten oder nur die aktiven? Materialien für jedes Werk oder nur für die Gesellschaften im Go-live?
2. Wie lauten die Stichtagsregeln? Das Stichtagsdatum für offene Einkaufs-, Verkaufs- und Arbeitsaufträge und was mit Vorgängen geschieht, die beim Cutover in Bearbeitung sind.
3. Was wird stattdessen archiviert? Gesetzliche Aufbewahrungsregeln für die Historie und wie lange das Altsystem lesbar bleibt.

Annahmen, die hier undokumentiert bleiben, werden im Build zu Streitfällen. Mein Artikel dazu, warum die SAP-Datenmigration scheitert, behandelt die Planung ausführlich.

5. Nichtfunktionaler Umfang

Diese Punkte fallen in der Planung weg und tauchen spät im Test als Blocker auf. Nehmen Sie sie in den Umfang auf:

1. Verfügbarkeit und Wartungsfenster. Verweisen Sie bei RISE auf die Verfügbarkeitsbedingungen in Ihrem Vertrag.
2. Performance bei Spitzenlast, etwa beim Monatsabschluss.
3. Audit-Logging: welche Transaktionen und wie lange die Protokolle aufbewahrt werden.
4. Sicherheit und rollenbasierte Zugriffssteuerung.
5. Berichtslatenz: Echtzeit, nahezu in Echtzeit oder täglich.

Das sind keine Funktionen. Es sind Rahmenbedingungen, die das System erfüllen muss. Gehören sie nicht zum Umfang, entwirft niemand dafür.

6. Rollen und Verantwortlichkeiten

Jeder Workstream braucht einen Beraterverantwortlichen und einen Ansprechpartner im Fachbereich mit Entscheidungsbefugnis, beide namentlich benannt. Die Lücke, die ich am häufigsten sehe, ist die Verantwortung für das UAT: Wer kann bestätigen, dass ein Prozess getestet und abgenommen ist? Entscheiden Sie das, bevor der Build beginnt, nicht zwei Wochen vor dem Go-live.

7. Änderungssteuerung

Nicht „Änderungen erfordern eine formelle Genehmigung“. Ein konkreter Prozess: Was löst einen Änderungsantrag aus, wer bewertet die Auswirkung auf Zeit und Budget, wer genehmigt, und was wird festgehalten. Ohne ihn wird aus „Können wir das noch aufnehmen?“ ein „Wir dachten, das sei enthalten“ und dann eine dreiwöchige Verlängerung, die niemand geplant hat.

8. Erweiterungsregeln

Wie individuelle Entwicklung genehmigt wird. SAP klassifiziert Erweiterungen inzwischen von Stufe A, nur freigegebene APIs, bis Stufe D, Modifikationen am Core (SAP News, August 2025). In der Public Edition unter GROW lässt das System nur freigegebene Schnittstellen zu. In der Private Edition unter RISE und On-Premise lässt sich der Core weiterhin verändern, daher sollte der Umfang die Zielstufe nennen und wer Ausnahmen genehmigt. Mein Leitfaden zu Clean Core erklärt die Stufen.

9. Annahmen und Randbedingungen

Listen Sie die Annahmen hinter dem Umfang auf, damit jemand sie prüfen muss. Dann die Randbedingungen: regulatorische Fristen, die einen Go-live-Termin festlegen, Budgetobergrenzen, Personen, die nur in Teilzeit verfügbar sind, und Termine für die Abschaltung von Altsystemen.

Anpassung ist die Form von Scope Creep, die am längsten braucht, um sichtbar zu werden. Ein genehmigter Eigenbericht wird zu fünf. Eine Workflow-Ausnahme wird zum Präzedenzfall für jede weitere Anfrage.

Klassifizieren Sie jede Anfrage, bevor Sie etwas genehmigen:

Kategorie	Prüfkriterium	Vorgehen
Essenziell	Der Prozess kann ohne sie rechtlich oder betrieblich nicht funktionieren	Genehmigen, mit der günstigsten upgradesicheren Erweiterung
Wichtig, nicht kritisch	Verbessert die Effizienz, ist aber kein Showstopper	Nur mit klarer Kosten-Nutzen-Begründung genehmigen
Unnötig	Eine Präferenz oder die Kopie der Arbeitsweise des Altsystems	Hinterfragen, dann ablehnen oder verschieben

Die meisten unnötigen Anpassungen gibt es, weil jemand seine Arbeitsweise nicht ändern wollte, nicht weil SAP den Prozess nicht abbilden konnte. Und die Build-Kosten sind erst der Anfang. Jedes Eigenobjekt verursacht Test-, Schulungs-, Dokumentations- und Upgradeaufwand, solange es existiert.

Legen Sie einen Change Freeze fest. Wählen Sie ein Datum, typischerweise vier bis sechs Wochen vor dem Go-live, ab dem für das Release keine neuen Anfragen mehr angenommen werden. Alles Spätere geht in das Backlog nach dem Go-live. Der Change Freeze braucht die Unterschrift des Lenkungsausschusses. Ein Datum, das nur der Projektleiter verkündet, wird beim ersten Druck eines Abteilungsleiters überstimmt.

1. 01Änderung beantragtWas als Änderung gilt, wird vorab festgelegt
2. 02KlassifiziertEssenziell, wichtig oder unnötig
3. 03Auswirkung bewertetZeit und Budget, durch einen benannten Bewerter
4. 04EntscheidungEin benannter Genehmiger genehmigt, lehnt ab oder verschiebt
5. 05Umfang versioniertNeue Versionsnummer und eine Liste der Änderungen

Nach dem Change Freeze gehen neue Anfragen in das Backlog nach dem Go-live

Bei der Analytik werden Umfangsgespräche hitzig. Alle wollen Berichte, und niemand sagt, wie viele.

Vereinbaren Sie im Design eine feste Berichtsliste. Fragen Sie, was die Leute brauchen, nicht, was sie vielleicht wollen. Kennzeichnen Sie jeden Bericht als SAP-Standardausgabe oder Eigenentwicklung und lassen Sie die Liste zusammen mit dem übrigen Umfang unterzeichnen. Standardberichte kosten einen Bruchteil der Eigenentwicklungen. Identifizieren Sie zugleich die Datenquellen jedes Berichts; ein Bericht, der aus drei Systemen zieht, ist eine Integrationsanforderung. Gehören Dashboards und Planung zum Umfang, behandelt mein Leitfaden zu SAP Analytics Cloud, was Sie zuerst klären sollten.

Fehler	Was er verursacht	Wie Sie ihn vermeiden
Ziele nicht messbar	UAT-Streit darüber, was „funktioniert“ heißt	Messbare Ergebnisse von Anfang an festlegen
Ausschlüsse nicht aufgeschrieben	Arbeit wird ohne Genehmigung aufgenommen	Auflisten, was nicht im Umfang ist, namentlich
Umfang der Datenmigration vage	Falsche Volumina, verschobener Cutover, Nacharbeit	Definieren, was migriert wird, Stichtage und Archivierung
Nichtfunktionale Anforderungen fehlen	Audit- und Performance-Probleme beim Go-live	Verfügbarkeit, Performance, Logging und Sicherheit in den Umfang aufnehmen
Keine benannten UAT-Verantwortlichen	Tests ziehen sich hin, niemand kann abnehmen	Einzelpersonen mit Befugnis benennen
Keine Änderungssteuerung	Informelle Ergänzungen, verkürzte Tests	Den Änderungsprozess in den Umfang schreiben
Keine Unterschrift	Umfang wird später ohne Verantwortlichkeit angefochten	Sponsor und Prozessverantwortliche unterzeichnen
Analytik auf später verschoben	Berichtswünsche zwei Wochen vor dem Go-live	Berichtsliste im Design vereinbaren
Bereitstellungsmodell oder Erweiterungsregeln offen	Die Debatte zieht sich in die Build-Phase	Beides entscheiden, bevor der Umfang unterzeichnet wird

Prüfen Sie den Umfang an jedem Phase-Gate von SAP Activate und nach jeder genehmigten Änderung, mit einer Versionsnummer und einer Liste der Änderungen. Der Umfang gehört per Verweis in die Projektcharta, damit beide Dokumente dieselbe Geschichte erzählen.

Was sollte eine Vorlage für den SAP-Projektumfang enthalten?

Neun Abschnitte: Ziele mit messbaren Ergebnissen, Umfangsdefinition (Module, Gesellschaften, Länder, Integrationen, Bereitstellungsmodell), ausdrückliche Ausschlüsse, Umfang der Datenmigration, nichtfunktionale Anforderungen, benannte Rollen, Änderungssteuerung, Erweiterungsregeln sowie Annahmen mit Randbedingungen. Die Ausschlüsse sind der Abschnitt, der am häufigsten fehlt.

Wie verhindert man Scope Creep in SAP-Projekten?

Schreiben Sie Ausschlüsse ausdrücklich auf, führen Sie jede Änderung über einen formellen Antrag mit Auswirkungsbewertung und benanntem Genehmiger, klassifizieren Sie Anpassungen vor der Genehmigung und legen Sie vier bis sechs Wochen vor dem Go-live einen unterzeichneten Change Freeze fest. Das Ziel ist nicht, jede Änderung abzulehnen. Es ist, Änderungen sichtbar, bewertet und autorisiert zu machen.

Was ist der Umfang der Datenmigration in einem SAP-Projekt?

Die Festlegung, welche Daten nach SAP migriert werden und nach welchen Regeln: welche Objekte (Kunden, Lieferanten, Materialien, offene Aufträge, Historie), die Stichtage und was stattdessen archiviert statt migriert wird. Er bestimmt Aufwand und Zeitplan und entscheidet darüber, wie lange Altsysteme zugänglich bleiben müssen.

Was ist der nichtfunktionale Umfang in SAP-Projekten?

Die Rahmenbedingungen, die das System erfüllen muss, im Unterschied zu den Prozessen, die es unterstützt: Verfügbarkeit, Performance bei Spitzenlast, Audit-Logging, Sicherheit und Zugriffssteuerung sowie Berichtslatenz. Sie werden oft aus dem Umfang ausgelassen und dann im Test entdeckt. In regulierten Branchen ist Audit-Logging eine gesetzliche Pflicht.

Wie sollten Anpassungen im Umfang behandelt werden?

Klassifizieren Sie jede Anfrage als essenziell, wichtig oder unnötig. Halten Sie für jede genehmigte Anpassung die Anforderung fest, warum Standard-SAP sie nicht erfüllt, den Aufwand, die Auswirkung auf Tests, die Wartungskosten und den Erweiterungsansatz. Nennen Sie in der Private Edition und On-Premise die angestrebte Clean-Core-Stufe und wer Ausnahmen genehmigt.

Wann sollte der Umfang eines SAP-Projekts überprüft werden?

An jedem Phase-Gate von SAP Activate, nach jedem genehmigten Änderungsantrag und immer dann, wenn sich Budget, Ressourcen oder Zeitplan ändern. Bewahren Sie jede Version mit Datum, Versionsnummer und einer Zusammenfassung der Änderungen auf. Diese Historie schützt das Team, wenn der Umfang später angefochten wird.