Ressourcenplanung für SAP-Projekte

Ressourcenplanung für ein SAP-Projekt heißt: entscheiden, welche Rollen Sie in welcher SAP-Activate-Phase für wie viele Wochenstunden brauchen, und dann jede Woche prüfen, ob die Realität noch zum Plan passt. Planen Sie nach Rollen, nicht nach allgemeiner Kopfzahl. Formen Sie den Plan nach der Phasenkurve: Funktionsberater in Explore, technische Spezialisten in Realize, Daten, Basis und Change in Deploy. Lassen Sie sich die Verfügbarkeit von den Linienvorgesetzten schriftlich bestätigen. Dieser Leitfaden richtet sich an Programmleiter, PMOs und CIOs, die einen Ressourcenplan für S/4HANA aufstellen oder retten. Nutzen Sie die FTE-Tabellen und Tagessatzspannen unten als Ausgangsanker.

Ich habe Dutzende von Einführungen mit denselben Ressourcenproblemen kämpfen sehen. Der Plan unterstellt eine Stabilität, die verschwindet, sobald die Umsetzung beginnt.

Einmal habe ich erlebt, wie ein Team eine ganze Woche verlor, weil niemand gemerkt hatte, dass der Security Lead direkt hintereinander Urlaub und Schulung hatte. Es wurde nicht gemeldet und nicht nachgehalten, und es verzögerte eine kritische Prüfung der Systemzugriffe um neun Tage.

Die meisten SAP-Pläne beruhen auf sauberen Schätzungen, Vollzeitverfügbarkeit und planbaren Abläufen. Diese Version der Welt überlebt selten den ersten Monat von Realize.

Ich plane entlang von drei Fragen: was die Arbeit tatsächlich verlangt, was die verfügbaren Personen tatsächlich leisten werden und was sich ändert, wenn die Realität vom Plan abweicht. Ein tragfähiger Plan deckt sechs Dimensionen ab:

1. Personalbedarf je Rolle und Activate-Phase. Keine pauschale Zuteilung. Explore sieht ganz anders aus als Realize.
2. Vom Linienvorgesetzten bestätigte Wochenstunden. Schriftlich, nicht angenommen.
3. Parallele Verpflichtungen je Person. Wer mit 100 % geführt wird und zusätzlich den Produktionssupport abdeckt, liefert deutlich weniger.
4. Vertretung für jede Rolle auf dem kritischen Pfad. Cross-Training ist bei einem Programm über 18 Monate keine Option.
5. Abhängigkeiten zwischen den Workstreams. Jeweils mit benanntem Verantwortlichen, Fälligkeitsdatum und Eskalationsweg, sichtbar am Tag des Verzugs.
6. Aktualisierungsrhythmus. Wöchentlich in den aktiven Phasen. Der Plan beim Kick-off ist Version eins.

Pläne scheitern, wenn der Planer generische IT-Rollen verwendet. SAP braucht spezifische funktionale und technische Spezialisierung. Das Standardset für ein S/4HANA-Programm:

Programmleitung. Programmleiter, PMO-Leiter und Lösungsarchitekt. Der Architekt verantwortet die Konsistenz des Designs über alle Module hinweg.

Funktionsberater. Ein Lead je Modul im Scope: Finanzwesen (FI), Controlling (CO), Materialwirtschaft (MM), Vertrieb (SD), Produktionsplanung (PP), Extended Warehouse Management (EWM), dazu Personalwirtschaft (HCM), Instandhaltung (PM) und Projektsystem (PS), soweit im Scope. Wenn Sie noch das klassische Warehouse Management (WM) betreiben, planen Sie den Umstieg: Die Nutzungsrechte über das Compatibility Pack für S/4HANA On-Premise sind Ende 2025 ausgelaufen.

Technische Berater. ABAP-Entwickler für Reports, Schnittstellen, Konvertierungen, Erweiterungen, Formulare und Workflows (RICEFW) sowie für Clean-Core-Erweiterungen auf freigegebenen APIs oder SAP BTP. Integrationsspezialisten für SAP Integration Suite (Cloud Integration, früher CPI), SAP Process Orchestration, wo es noch läuft, und jede Middleware von Drittanbietern.

Plattform. Basis-Berater für HANA, Kernel-Patches, Transporte, Systemkopien und Performance-Tuning. Security-Berater für Rollenkonzept, Funktionstrennungsanalyse und SAP GRC Access Control, soweit im Scope.

Daten. Migrationsspezialisten, die die App „Migrate Your Data“ des SAP S/4HANA Migration Cockpit nutzen (die ältere Transaktion LTMC ist veraltet), den Migration Object Modeler für kundeneigene Objekte und SAP Data Services für komplexe Transformationen. In meinem Leitfaden zu den Gründen für das Scheitern von SAP-Datenmigrationen erkläre ich, warum dieses Team früher starten muss, als die meisten Pläne es zulassen.

Change. Change Lead, Schulungsleiter und Verantwortlicher für die Bereitschaft der Fachbereiche. Meist unterbesetzt, weil der Bedarf erst in Deploy sichtbar wird.

Kundenseite. Business-Analysten (einer je größerem Modul), Prozessverantwortliche (einer je Prozessdomäne) und Tester aus dem operativen Geschäft für UAT.

Diese Rollen als austauschbare Slots zu behandeln, ist der häufigste Planungsfehler. Ein erfahrener FI-Berater kann keinen SD-Design-Workshop leiten. Ein junger ABAP-Entwickler kann keine Integration architektonisch auslegen. Die Zuständigkeiten je Rolle finden Sie in meiner Liste der wichtigsten Rollen im SAP-Einführungsteam.

Der Ressourcenbedarf ist nicht konstant. Die Activate-Phasen erzeugen vorhersehbare Kurven, die eine pauschale Zuteilung verfehlt.

Prepare (typischerweise Woche 1 bis 4). Leicht. Programmleiter, Architekt und ein Lead je Modul für die Abgrenzung. Fachanwender bestätigen den Scope. Basis und Security beginnen mit dem Aufbau der Umgebung.

Explore (typischerweise Monat 2 bis 5). Stark belastet sind Funktionsberater und Fachanwender, die Design-Workshops bestimmen den Zeitplan. ABAP und Integration sind gering ausgelastet, bis Designentscheidungen vorliegen. Basis bereitet Sandbox- und Qualitätssysteme vor.

Realize (typischerweise Monat 5 bis 12). Stark belastet sind die technischen Spezialisten: Konfiguration, Entwicklung, Unit- und Integrationstests. Die ABAP-Last erreicht ihren Höchstwert. Fachanwender steigen in die Testzyklen ein. Das Datenteam baut Migrationsobjekte und fährt Probeläufe.

Deploy (typischerweise Monat 12 bis 14). Hohe Last bei Datenmigration, Basis, Security, Change und Schulung. UAT bindet Kapazität der Fachbereiche. Cutover-Proben brauchen Teams am selben Ort. Die Hypercare-Planung beginnt.

Run (ab Monat 14; Hypercare typischerweise 30 bis 90 Tage). Ein schlankes Kernteam und umfangreiche Support-Abdeckung. Basis und Anwendungsbetrieb fahren hoch, während die Berater abziehen.

Behandeln Sie diese Phasen als gleich große Bedarfsfenster, werden Sie Prepare überbesetzen, Realize unterbesetzen und in Deploy bei der Datenmigration zu knapp sein. Die Phasenkurve ist die wichtigste Form im Plan.

1. PrepareEtwa 11 FTEWoche 1 bis 4. Leads grenzen den Scope ab, Basis baut auf
2. ExploreEtwa 36 FTEMonat 2 bis 5. Funktionsberater und Fachanwender
3. RealizeEtwa 56 FTE, der HöchstwertMonat 5 bis 12. Entwicklung, und die ABAP-Last erreicht ihren Höchstwert
4. DeployEtwa 42 FTEMonat 12 bis 14. Daten, Basis, Security, Change
5. RunEtwa 12 FTEAb Monat 14. Hypercare typischerweise 30 bis 90 Tage

Dauernde Notfälle. Wenn das Team ständig Brände löscht, sagt der Plan die Realität nicht mehr voraus. Eine einzige Abwesenheit darf einen Workstream nicht aus der Bahn werfen.

Fachanwender verschwinden, wenn Sie sie brauchen. Design-Sitzungen und UAT stocken, weil Fachanwender nicht verfügbar sind. Das ist eine der häufigsten Ursachen für Verzug. Die Ursache ist fast immer dieselbe: Die Zeit wurde angenommen, nicht verbindlich zugesagt. Wo die Zusage nicht formalisiert war, gewinnt jedes Mal der operative Druck.

Technische Spezialisten zu dünn verteilt. Gerald Weinbergs Arbeiten zum Software-Management schätzten, dass jemand, der sich auf drei Projekte verteilt, etwa 60 % seiner Gesamtkapazität liefert, der Rest geht durch das Umschalten verloren. Die Zusammenfassung der American Psychological Association zur Forschung über Aufgabenwechsel nennt dieselbe Größenordnung: Kurze mentale Blockaden beim Wechsel zwischen Aufgaben können bis zu 40 % der produktiven Zeit kosten. Der Plan sieht effizient aus. Das Ergebnis nicht.

Der kritische Pfad ändert sich jede Woche. Ständiges Umsortieren, spät startende Workstreams und wöchentliche Prioritätswechsel lassen sich meist auf unklaren Scope oder schlecht geordnete Abhängigkeiten zurückführen. Klären Sie den Scope, bevor Sie den Ressourcenplan reparieren.

1. Scheinverfügbarkeit. Jemand wird mit 100 % geführt und betreut zugleich den Monatsabschluss und den Produktionssupport. Fragen Sie, wie viele Stunden pro Woche, woran die Person sonst noch arbeitet und ob ihr Linienvorgesetzter es schriftlich bestätigt hat.
2. Geteilte Rollen ohne Abgrenzung. Eine Person macht Lösungsdesign, Tests und Change-Management zugleich. Teilen Sie die Verantwortung nach Aufgabe, nicht nach Titel, und machen Sie niemanden an zwei Stellen gleichzeitig kritisch.
3. Fehlende Zeit der Fachanwender. Workshops verschieben sich, UAT-Freigaben dauern Wochen länger. Lassen Sie sich die Zeit schriftlich zusagen und vom Bereichsleiter unterzeichnen, verfolgen Sie die Teilnahme und eskalieren Sie Muster früh.
4. Kein Puffer. Eine Abwesenheit legt einen Workstream lahm. Bauen Sie Puffer auf Aufgabenebene ein, nicht nur auf Phasenebene, und schulen Sie für jede Kernrolle mindestens eine weitere Person ein.
5. Ein Plan, der nie aktualisiert wird. Beim Kick-off erstellt und nie überarbeitet. Prüfen Sie ihn in der aktiven Umsetzung wöchentlich, koppeln Sie ihn an die Phasen-Gates und passen Sie ihn an, wenn sich die Realität verschiebt.

Beginnen Sie mit bestätigter Verfügbarkeit. Gehen Sie vor Projektstart zu den Linienvorgesetzten. Bestätigen Sie die Wochenstunden und andere Verpflichtungen und dokumentieren Sie sie. Ändert sich die Verfügbarkeit mitten im Projekt, ist diese Basis Ihre Grundlage für die Eskalation.

Formen Sie ihn nach Phasen. Die Last eines ABAP-Entwicklers ist in Explore eine andere als in Realize. Fachanwender erreichen ihren Höchstwert in Explore für das Design und in Deploy für UAT. Eine pauschale Zuteilung wirkt auf dem Papier ausgewogen und scheitert in der Praxis.

Bilden Sie Abhängigkeiten explizit ab. Die Datenmigration speist die Integrationstests, diese speisen UAT, und UAT treibt den Cutover. Geben Sie jeder Abhängigkeit einen Verantwortlichen, ein Datum und ein Signal, damit ein Verzug am selben Tag sichtbar wird.

Schützen Sie die Zeit der Fachanwender auf Lenkungsebene. Ihr Tagesgeschäft läuft weiter. Ohne ausdrückliche Freigabe ihres Managements für die Wochenstunden lassen sie das Projekt fallen, sobald operativer Druck entsteht. Die Zeit sollte der Sponsor bei den Bereichsleitern einfordern, nicht der Projektleiter.

Aktualisieren Sie den Plan wöchentlich. Ein Plan, der zwei Wochen unberührt bleibt, ist wahrscheinlich falsch. Verfolgen Sie die tatsächliche gegen die geplante Auslastung. Liegt jemand zwei Wochen in Folge bei 120 %, ist das ein Signal: Entweder ist die Person überlastet oder der Plan ist falsch.

Das sind Richtwerte für Personalstärke und Sätze, die Sie als Ausgangsanker nutzen. Branche, Scope, Region und Partner verschieben sie. Verwenden Sie die Tabellen als Plausibilitätsprüfung, nicht als Angebot.

Mittelstands-Brownfield (5 bis 15 Mio. $, etwa 12 Monate)

Typischer Scope: eine einzelne juristische Einheit oder kleine Gruppe, drei oder vier Module (meist FI, CO, MM, SD), Standardprozesse und begrenzte Eigenentwicklung.

Workstream	Prepare	Explore	Realize	Deploy	Run
Programmleiter	1	1	1	1	0,5
Lösungsarchitekt	1	1	1	0,5	0
Funktionsberater (FI/CO, MM, SD plus einer)	1	4	4	2	1
ABAP und Technik	0	1	3	1	0,5
Integration	0	0,5	2	1	0,5
Basis	0,5	0,5	1	2	1
Sicherheit und Berechtigungen	0	0,5	1	1,5	0,5
Datenmigration	0	1	2	3	0
Testleiter	0	0,5	1	1	0
Change und Schulung	0,5	1	1	2	0,5
Business-Analysten (Kundenseite)	1	4	3	2	1
Spitzenwert gesamt (FTE)	5	14	20	17	5

Enterprise-Brownfield (30 bis 80 Mio. $, 15 bis 18 Monate)

Typischer Scope: mehrere Gesellschaften, sechs bis neun Module, komplexe Integration, nennenswerte Eigenentwicklung und mehrere Länder-Rollouts.

Workstream	Prepare	Explore	Realize	Deploy	Run
Programmleiter und PMO	2	2	3	3	1
Lösungsarchitekten (Lead plus Modul)	2	3	3	1,5	0,5
Funktionsberater (alle Module im Scope)	2	10	12	5	2
ABAP und Technik	0	3	8	3	1
Integration und Middleware	0,5	2	5	2	1
Fiori und UI5	0	1	3	1	0,5
Basis	1	1	2	4	2
Sicherheit und GRC	0,5	1,5	2	3	1
Datenmigration	0	2	5	6	0,5
Tests	0,5	1	3	4	0
Change und Schulung	1	2	3	5	1
Business-Analysten (Kundenseite)	2	8	7	5	2
Spitzenwert gesamt (FTE)	11	36	56	42	12

Tagessätze nach Rolle und Region (2024 bis 2025)

Das sind vom Partner abgerechnete Sätze je Spezialist, keine Gehälter. Der Programm-Mischsatz liegt meist 30 bis 50 % unter dem Onshore-Satz für Senior-Rollen, weil die meisten Programme Onshore-Architekten mit Offshore-Umsetzung mischen.

Rolle	Onshore USA/UK/DE	GCC (VAE/KSA)	Nearshore (Lateinamerika/Osteuropa)	Offshore (Indien)
Lösungsarchitekt (Senior)	2.000 bis 3.500 $	1.500 bis 2.500 $	900 bis 1.500 $	500 bis 1.000 $
Funktionsberater (Senior)	1.500 bis 2.800 $	1.200 bis 2.000 $	700 bis 1.400 $	300 bis 700 $
Funktionsberater (Mid-Level)	1.000 bis 1.800 $	800 bis 1.400 $	500 bis 900 $	200 bis 500 $
ABAP und Technik (Senior)	1.400 bis 2.500 $	1.000 bis 1.800 $	600 bis 1.200 $	300 bis 700 $
Integrationsspezialist	1.500 bis 2.800 $	1.100 bis 1.900 $	700 bis 1.300 $	350 bis 800 $
Basis	1.400 bis 2.200 $	1.000 bis 1.800 $	600 bis 1.100 $	300 bis 700 $
Sicherheit und GRC	1.500 bis 2.500 $	1.100 bis 1.900 $	700 bis 1.300 $	350 bis 800 $
Datenmigration	1.300 bis 2.200 $	1.000 bis 1.700 $	600 bis 1.100 $	300 bis 700 $
Change- und Schulungsleiter	1.200 bis 2.000 $	900 bis 1.500 $	500 bis 1.000 $	250 bis 600 $
Junior-Berater (jede Rolle)	800 bis 1.400 $	500 bis 900 $	400 bis 700 $	150 bis 350 $

Die Aufteilung zwischen Onshore, Nearshore und Offshore

Die meisten SAP-Programme mischen Regionen. Es ist eine Abwägung zwischen Kosten und Geschwindigkeit, keine Entweder-oder-Entscheidung.

Programme im US-Privatsektor laufen typischerweise mit 30 bis 60 % Onshore-Anteil nach FTE. Onshore konzentriert sich auf Architektur, Change, Business-Analyse und Senior-Funktionsrollen, wo die Nähe zum Fachbereich zählt. Offshore konzentriert sich auf ABAP, Integrationsentwicklung und die Durchführung der Datenmigration, wo sich die Arbeit leichter spezifizieren lässt. US-Bundesprogramme laufen je nach Arbeitsumfang oft vollständig Onshore mit Beschränkungen auf US-Personen.

GCC-Programme laufen typischerweise mit 60 bis 70 % Onshore, weil lokale Einstellungsvorgaben und arabischsprachige Anforderungen den Anteil nach oben treiben. Offshore-Arbeit tendiert wegen der Zeitzonenüberlappung zu südasiatischen Zentren. Europäische Programme unterscheiden sich: In der Fertigung liegt der Onshore-Anteil oft bei etwa 50 %, während öffentlicher Sektor und regulierte Branchen aus Gründen der Datenresidenz höher gehen.

Ein häufiger Fehler ist, die Aufteilung allein nach Kosten zu optimieren. Ein Team mit 80 % Offshore und 20 % Onshore-Architekten sieht in der Tabellenkalkulation günstig aus. Die versteckten Kosten sind der tägliche Übergabezyklus und langsamere Design-Workshops ohne Kontext aus dem Fachbereich. Das billigste Team liefert selten das billigste Programm. Wenn Sie Partner vergleichen, zeigt mein Leitfaden zu SAP-Implementierungspartnern nach Tier, wie sich Sätze und Teamzuschnitt zwischen ihnen unterscheiden.

Ein Plan, der einmal gebaut und nie wieder hinterfragt wird, ist kein Plan. Behandeln Sie jede Annahme darin als Hypothese, die Sie in der ersten Woche der Umsetzung prüfen, und danach jede Woche.

Was ist Ressourcenplanung in SAP-Projekten, und warum ist sie wichtig?

Es bedeutet zu entscheiden, welche Personen das Projekt wann und für wie viel ihrer Zeit braucht, und dann nachzuhalten, ob das mit der Realität übereinstimmt.

SAP-Projekte hängen an bestimmten Personen: dem FI/CO-Lead, der Ihren Kontenplan versteht, dem Migrationsspezialisten, der Ihre Altdaten kennt, dem Change Lead mit Beziehungen im Fachbereich. Sind sie im entscheidenden Moment nicht verfügbar, steht die Arbeit still oder wird falsch erledigt. Viele Verzögerungen, die technisch aussehen, sind in Wahrheit Ressourcenprobleme.

Wie führt schlechte Ressourcenzuteilung zu Verzögerungen in SAP-Projekten?

Über Abhängigkeiten. Ein Konfigurations-Lead wird in Realize auf ein anderes Projekt gezogen. Seine Arbeit stockt, was die Integrationstests verzögert, dann UAT, dann die Cutover-Bereitschaft. Eine zweiwöchige Abwesenheit in Woche acht kann sich bis zum Go-live zu sechs Wochen Verzug auswachsen.

Kleine Lücken am Anfang werden spät zu großen Verzögerungen. Wenn die Auswirkung sichtbar wird, kostet die Behebung ein Mehrfaches dessen, was eine frühe Korrektur gekostet hätte.

Wie bekomme ich Fachanwender für ein SAP-Projekt verbindlich dazu, obwohl sie ein Tagesgeschäft haben?

Holen Sie sich vor Projektstart die schriftliche Zusage ihres Linienvorgesetzten: Wochenstunden, in welchen Phasen sie am dringendsten gebraucht werden und welche Freigabe nötig ist, wenn sich die Verfügbarkeit ändert.

Verfolgen Sie ihre Teilnahme wie bei jeder anderen Ressource. Sinkt sie, eskalieren Sie auf Lenkungsebene. Bereichsleiter können die Zusage durchsetzen, das Projektteam kann es nicht.

Wie gehe ich damit um, wenn eine Schlüsselperson mitten im Projekt geht?

Vermeiden Sie von vornherein Single Points of Failure: Mindestens eine weitere Person sollte jeden kritischen Workstream gut genug verstehen, um ihn am Laufen zu halten.

Wenn jemand geht, sichern Sie sofort sein Wissen: undokumentierte Entscheidungen und die Begründung der Konfiguration. Das ist oft schwieriger, als einen Ersatz zu finden. Für den Ersatz sind ein Übergabedokument, aufgezeichnete Sitzungen und eine Woche Überlappung das Minimum.

Wann sollte ich ein Ressourcenproblem eskalieren?

Früher, als es sich angenehm anfühlt. Eskalieren Sie, wenn ein benannter Abhängigkeitsverantwortlicher länger als eine Woche nicht verfügbar war, ein Fachanwender immer wieder Sitzungen versäumt, eine technische Ressource zwei Wochen lang über 120 % Auslastung liegt oder ein Workstream durch eine aufgeschobene Besetzungsentscheidung blockiert ist.

Zu frühes Eskalieren kostet ein unangenehmes Gespräch. Zu spätes Eskalieren kostet Wochen Verzug.

Wie sollten Ressourcen behandelt werden, die auf mehrere Projekte verteilt sind?

Gehen Sie davon aus, dass geteilte Personen etwas anderes priorisieren, sobald Druck entsteht. Vereinbaren Sie mit ihrem Hauptvorgesetzten konkrete Wochenstunden, bauen Sie Puffer in die Arbeit ein, die von ihnen abhängt, und halten Sie sie vom kritischen Pfad fern, solange Sie keine Rückfalloption haben.

Bei geteilten Fachanwendern muss die Anfrage vom Sponsor kommen. Ein Projektleiter, der einen Bereichsleiter um Zeit bittet, verliert jedes Mal gegen operative Prioritäten.