So erstellen Sie einen Projektauftrag für eine SAP-Einführung

Ein SAP-Projektauftrag (Project Charter) ist das kurze Dokument, das das Programm formal autorisiert. Er legt schriftlich fest, was das Programm liefert und was nicht, wer entscheidet, wie Erfolg gemessen wird und bis wann. Schreiben Sie ihn, bevor die Statements of Work der Anbieter unterzeichnet werden, lassen Sie den Sponsor auf Kundenseite ihn besitzen und machen Sie ihn konkret genug, um einen Streit zu entscheiden. Unten folgt eine Gliederung Abschnitt für Abschnitt.

Teams stürzen sich mit Zuversicht in SAP-Kickoff-Meetings. Dann stellen sie fest, dass Rollen vage definiert waren, Umfangsgrenzen nie vereinbart wurden und niemand sagen kann, wie Erfolg aussieht. Ein Projektauftrag sollte das verhindern. Die meisten tun es nicht, weil sie geschrieben werden, um eine Governance-Anforderung zu erfüllen, nicht um die Arbeit zu verankern.

Ich habe Projektaufträge gesehen, die sauber aussehen, aber nicht mit den echten Plänen verbunden sind. Die Fassung, die funktioniert, ist die, über die beim Entwurf gestritten wird. Daran erkennen Sie, dass sie ehrlich ist.

Drei Dokumente werden in jedem großen SAP-Programm verwechselt. Sie haben unterschiedliche Aufgaben.

Dokument	Zweck	Erstellt von	Zeitpunkt
Projektantrag	Begründen, warum das Projekt stattfinden soll	Fachlicher Sponsor	Vor der Genehmigung
Projektauftrag	Das Projekt autorisieren; Umfang, Ziele, benannte Verantwortliche und Governance festlegen	Sponsor mit dem Programmmanager	Bei der Initiierung
Projektplan	Festlegen, wie die Arbeit erledigt wird: Aufgaben, Ressourcen, Abhängigkeiten	Programmmanager	Nach Genehmigung des Projektauftrags

Der Projektauftrag ist das Governance-Dokument. Er zieht Linien. Erstreckt sich Ihr S/4HANA-Programm über mehrere Module, Länder und Anbieter, legen Sie im Projektauftrag fest, was dazugehört, bevor die Leute anfangen, eigene Annahmen zu treffen.

Ziele, die an ein Geschäftsergebnis gebunden sind

Nicht „Systemmodernisierung". Jedes Ziel braucht eine Zahl. Der Test: Können Sie einem Vorstandsmitglied die Vision in 30 Sekunden ohne Folien erklären?

Ich habe an SAP-Programmen gearbeitet, bei denen beim Go-live alle feierten und zwei Monate später niemand sagen konnte, ob der versprochene Nutzen geliefert wurde. Ein Fertigungskunde gab über 4 Millionen US-Dollar aus und konnte keinerlei Ertrag nachweisen. Der CFO bat um Kennzahlen. Niemand hatte welche, und es verzögerte die nächste Finanzierungsrunde.

Dagegen ein Einzelhandelskunde, den ich begleitet habe. Sein Projektauftrag hatte vom ersten Tag an definierte KPIs. Er wies einen Rückgang der Kosten für die Auftragsabwicklung um 32 Prozent aus, und Phase 2 wurde sofort genehmigt.

Umfang mit ausdrücklichen Ausschlüssen

Das ist der am meisten übersehene Abschnitt. Teams schreiben detaillierte Listen dessen, was zum Umfang gehört, und lassen die Ausschlüsse weg, obwohl genau dort die Streitigkeiten entstehen.

Ich habe mit einem Unternehmen im Gesundheitswesen gearbeitet, das seinen SAP-Rollout auf diese Weise fokussiert hielt. Der Marketingleiter wollte während des Abnahmetests (User Acceptance Testing, UAT) Analysen für die Kampagnenverfolgung ergänzen. Im Projektauftrag war dafür kein Platz, und der Lenkungsausschuss wies sofort darauf hin. Diese eine Entscheidung ersparte 850.000 US-Dollar und vermied sechs Wochen Verzug.

Namen von Personen, nicht von Abteilungen

„Finanzteam: liefert Input zur Berichterstattung" macht niemanden verantwortlich. „Finanzleiter, [Name]: definiert die Berichtsanforderungen, nimmt die FI/CO-Konfiguration ab, genehmigt die Bereitschaft der Datenmigration" tut es.

Meilensteine als Zusagen

Ein Einzelhandelskunde verschob sein Go-live um vier Monate. Die anfängliche Verzögerung war ein dreiwöchiger Verzug bei der Anforderungserhebung, den niemand in den Zeitplan aufnahm. Man ging davon aus, es später aufholen zu können. Stattdessen gab man 1,8 Millionen US-Dollar an Überschreitungen aus.

Es funktioniert auch andersherum. In einem Fertigungsprojekt hielt sich das Team an den veröffentlichten Plan. Als das Team der Datenmigration eine Verzögerung meldete, genehmigte der Lenkungsausschuss sofort Personalunterstützung, weil der Projektauftrag den Meilenstein sichtbar gemacht hatte. Diese Entscheidung sparte Zeit und 600.000 US-Dollar.

Budget, Risiken und Abhängigkeiten

Ein grobes Budget, die drei oder vier Risiken, die das Programm entgleisen lassen könnten, und die anderen Programme, die um dieselben Leute und dasselbe Geld konkurrieren. Ein Einzelhandelskunde gab 3,2 Millionen US-Dollar für eine Einführung aus, die nie live ging. Sein Finanz-Redesign und das SAP-Projekt liefen parallel mit denselben Ressourcen und im selben Budgetfenster, und keiner der beiden Projektaufträge erwähnte das andere. Die Führung bemerkte es zu spät.

Das ist die Struktur, mit der ich beginnen würde. Jeder Abschnitt sollte auf eine Seite oder weniger passen.

1. Zweck und Hintergrund: warum jetzt, was nicht funktioniert, was passiert, wenn Sie nichts tun.
2. Ziele und Erfolgsmessgrößen: jedes Ziel mit Ausgangswert, Zielwert und Datum.
3. Umfang: Module, Prozesse, Gesellschaften, Länder, Standorte, Integrationen und Daten im Umfang.
4. Nicht im Umfang: so sorgfältig geschrieben wie der Umfang, mit der Phase, auf die jeder ausgeschlossene Punkt verschoben wird.
5. Bereitstellungsmodell und Erweiterungsregeln: S/4HANA Cloud Public Edition, Private Edition unter RISE oder On-Premise, und wie individuelle Entwicklung genehmigt wird.
6. Governance: Sponsor, Lenkungsausschuss, Design Authority, Änderungskontrolle, Eskalationsweg, mit benannten Personen.
7. Rollen und Verantwortlichkeiten: benannte Personen für jeden Prozessbereich, Daten, Test, Change und Cutover.
8. Meilensteine: Phasen-Gates mit Terminen und den Kriterien, sie zu passieren. Mein Leitfaden zu Quality Gates enthält Beispiele.
9. Budget und Reserve: der Rahmen, die Reserve und wer sie freigeben darf.
10. Risiken, Annahmen und Abhängigkeiten: einschließlich paralleler Programme und regulatorischer Fristen.
11. Compliance-Anforderungen: zum Beispiel HIPAA im US-Gesundheitswesen, GxP in der Pharmaindustrie, SOX für börsennotierte US-Unternehmen.
12. Freigabe: Sponsor und Fachbereichsleiter, mit Versionsnummer und Datum.

1. 01Fragen Sie die Leute, die die Arbeit kennenSponsoren, Fachbereichsleiter und Endanwender
2. 02Trennen Sie Muss von KannGo-live, Phase 2 oder nicht dieses Projekt
3. 03Beginnen Sie mit einer VorlageDann Integration, Daten und Compliance ergänzen
4. 04Seien Sie konkret genug, um Streit zu entscheidenKönnen Sie belegen, dass jedes Ziel erreicht wurde?
5. 05Holen Sie echte Freigabe einAbschnitt für Abschnitt gelesen, hinterfragt und akzeptiert

Ein Projektauftrag, auf den Sie zeigen können, wenn im dritten Monat der Umfang strittig ist

1. Fragen Sie die Leute, die die Arbeit kennen

Bevor Sie etwas schreiben, setzen Sie sich mit Sponsoren, Fachbereichsleitern und Endanwendern zusammen. Fragen Sie, was nicht funktioniert und was früher schon versucht wurde. Ich habe einmal mit einem Fertigungskunden gearbeitet, der 1,8 Millionen US-Dollar für eine SAP-Einführung verschwendete, weil er annahm, er wisse, was die Fertigung vor Ort braucht. Sechs Monate später stellte er fest, dass die echten Workflow-Probleme gar nicht angegangen wurden.

Bei einer Finanztransformation, an der ich beteiligt war, plante die IT den SAP-Rollout, um Effizienzprobleme zu lösen. Gespräche mit dem Finanzbereich zeigten, dass das eigentliche Problem die schlechte Datenqualität war. Hätten wir nicht gefragt, hätten wir Millionen ausgegeben, um das falsche Problem zu beheben.

2. Trennen Sie Muss von Kann, bevor Sie den Umfang schreiben

Ordnen Sie jede Eingabe ein: nötig fürs Go-live, Phase 2 oder nicht dieses Projekt. Ein Dienstleistungskunde von mir überschritt sein Budget um 40 Prozent, weil Anforderungen an drei verschiedenen Orten lagen und Monate nach Projektstart immer wieder „neu entdeckt" wurden. Mein Leitfaden zur Umfangsvorlage hilft bei diesem Schritt.

3. Beginnen Sie mit einer Vorlage, dann ergänzen Sie die SAP-Besonderheiten

Eine generische Vorlage übersieht, was SAP-Programme teuer macht: Integrationspunkte, Verantwortung für Datenmigration und -bereinigung, Modulannahmen, Compliance-Anforderungen und die Regeln für individuelle Entwicklung. Ich habe von einem SAP-Projekt gehört, das mit einem generischen Projektauftrag begann, in dem Datenbereinigung nie erwähnt wurde. Sechs Monate später erwiesen sich die Altdaten als Chaos, was 750.000 US-Dollar und drei Monate zusätzlich kostete.

4. Seien Sie konkret genug, um Streit zu entscheiden

Ich leitete die Einführung für einen Einzelhandelskunden in Singapur, dessen Projektauftrag lautete: „Bestandsmanagement modernisieren". Die eine Hälfte des Teams verstand darunter schnellere Verarbeitung. Die andere konzentrierte sich auf Prognosen. Das Ergebnis: 1,8 Millionen US-Dollar ausgegeben und keine Einigkeit darüber, wie Erfolg aussieht. Fragen Sie sich bei jedem Ziel: Kann ich belegen, dass es erreicht wurde?

5. Holen Sie echte Freigabe ein

Der Projektauftrag ist fertig, wenn die Unterzeichner ihn gelesen, hinterfragt und seine Zusagen akzeptiert haben. Gehen Sie ihn mit Sponsor und Fachbereichsleitern Abschnitt für Abschnitt durch. Ich habe erlebt, dass Einzelhandelskunden drei volle Tage für die Abstimmung des Projektauftrags aufwandten. Das ersparte ihnen später Monate voller Streit und Umfangsänderungen.

Fehler	Was er verursacht	Was Sie stattdessen tun
Vage Ziele („Effizienz steigern")	Teams ziehen in verschiedene Richtungen	Geben Sie jedem Ziel eine Zahl
Keine Ausschlüsse	Der Umfang wächst leise	Schreiben Sie die Liste des Nicht-Umfangs so sorgfältig wie den Umfang
Verantwortliche nur mit Titel oder Abteilung benannt	Entscheidungen werden vertagt	Nennen Sie Personen
Keine Erfolgsmessgrößen	Das Go-live wird gefeiert, der Nutzen nie gezeigt	Definieren Sie KPIs vor dem Kickoff
Parallele Programme nicht erfasst	Kollisionen bei Ressourcen und Budget	Halten Sie Abhängigkeiten in beiden Projektaufträgen fest
Projektauftrag vom Implementierungspartner geschrieben	Der Umfang spiegelt wider, was der Partner liefern will	Der Auftraggeber besitzt ihn; der Partner liefert Details

Beim letzten Punkt bin ich unnachgiebig. Ihr Implementierungspartner sollte Ihren Projektauftrag nicht schreiben. Sein Anreiz ist, das Projekt zu starten. Ihrer ist, es abzugrenzen.

Bei RISE with SAP (Private Edition) ergänzen Sie im Abschnitt Governance zwei Dinge. Erstens ein Gremium für die Clean-Core-Freigabe. SAP klassifiziert Erweiterungen inzwischen von Level A, nur freigegebene APIs, bis Level D, Modifikationen (SAP News, August 2025). Die Private Edition erlaubt weiterhin Änderungen am Kern, sodass das Gremium verhindert, dass sich technische Schuld aufbaut. Zweitens ein Eskalationsweg zu SAP. Unter RISE betreibt SAP die Infrastruktur und den technischen Betrieb. Der CIO muss wissen, wen er bei SAP anrufen kann, wenn auf Plattformebene etwas ausfällt, nicht nur beim Partner.

Bei GROW with SAP (Public Edition) wird der Projektauftrag kleiner. Erweiterungen sind auf freigegebene Schnittstellen beschränkt, sodass die Plattform Clean Core für Sie durchsetzt, und die Integrationsoptionen sind enger. Vision, Erfolgsmessgrößen, benannte Verantwortliche und Ausschlüsse sind genauso wichtig.

KI-Werkzeuge können aus Interviewnotizen schneller einen ersten Entwurf machen. Die politische Arbeit des Projektauftrags können sie nicht leisten: Sponsoren dazu zu bringen, sich darauf zu einigen, was sie verantworten.

Was ist ein Projektauftrag bei einer SAP-Einführung?

Das Dokument, das das SAP-Programm formal autorisiert. Es legt Umfang und Ausschlüsse fest, benennt den Sponsor und die verantwortlichen Personen, definiert Erfolgsmessgrößen, setzt Meilensteine und Governance und listet die Hauptrisiken auf. Ein brauchbarer Projektauftrag ist konkret genug, um einen Streit über Umfang oder Verantwortung zu entscheiden.

Was sollte ein SAP-Projektauftrag enthalten?

Zweck, Ziele mit messbaren Zielwerten, Umfang, ausdrückliche Ausschlüsse, Bereitstellungsmodell und Erweiterungsregeln, Governance mit benannten Personen, Rollen, Meilensteine mit Gate-Kriterien, Budget und Reserve, Risiken und Abhängigkeiten, Compliance-Anforderungen und Freigabe. Die Gliederung oben zeigt jeden Abschnitt.

Was ist der Unterschied zwischen Projektauftrag und Projektplan?

Der Projektauftrag autorisiert und definiert: Umfang, Sponsor, Governance und grobe Meilensteine. Der Plan führt aus: Aufgaben, Abhängigkeiten, Ressourcen und Reihenfolge. Ein Plan ohne Projektauftrag driftet, weil der Umfang nie vereinbart wurde. Jede Zusage im Plan sollte sich auf den Projektauftrag zurückführen lassen.

Wer sollte den SAP-Projektauftrag schreiben?

Der Sponsor auf Kundenseite besitzt ihn, und der Programmmanager entwirft ihn, mit Details von den Leitern aus Finanzwesen, IT und Betrieb. Ich rate davon ab, den Implementierungspartner ihn schreiben zu lassen. Sein Anreiz ist, das Projekt zu starten, nicht Sie vor Umfang zu schützen, den Sie nicht brauchen.

Wie verändert RISE with SAP den Projektauftrag?

Ergänzen Sie ein Gremium für die Clean-Core-Freigabe, das entscheidet, welche Erweiterungen auf welchem Level erlaubt sind. Ergänzen Sie einen Eskalationsweg zu SAP für Plattformprobleme, da SAP unter RISE die Infrastruktur betreibt. Bei GROW with SAP ist der Projektauftrag schlanker, weil die Public Edition Clean Core technisch durchsetzt.

Kann sich der Projektauftrag während der Einführung ändern?

Ja, über die Änderungskontrolle. Behandeln Sie den Projektauftrag als Baseline. Ändern sich Umfang, Sponsor, Budget oder ein wichtiger Meilenstein, aktualisieren Sie ihn mit einer Versionsnummer, einem Vermerk, was sich warum geändert hat, und neuer Freigabe. Lassen Sie ihn nicht still überarbeiten, wann immer das Projekt abdriftet.