Capaciteitsplanning voor SAP-projecten

Capaciteitsplanning voor een SAP-project betekent bepalen welke rollen u nodig hebt, in welke SAP Activate-fase en voor hoeveel uur per week, en daarna elke week nagaan of de werkelijkheid er nog mee overeenkomt. Bemand per rol, niet met een generiek aantal koppen. Vorm het plan naar de fasecurve: functionele mensen in Explore, technische mensen in Realize, data, Basis en verandermanagement in Deploy. Laat beschikbaarheid schriftelijk bevestigen door de leidinggevenden. Deze gids is bedoeld voor programmadirecteuren, PMO's en CIO's die een S/4HANA-capaciteitsplan opstellen of redden. Gebruik de FTE-tabellen en dagtariefbereiken hieronder als uitgangspunt.

Ik heb tientallen implementaties zien worstelen met dezelfde capaciteitsproblemen. Het plan gaat uit van een stabiliteit die verdwijnt zodra de uitvoering begint.

Ik heb ooit een team een hele week zien verliezen omdat niemand doorhad dat de securitylead achter elkaar verlof en training had. Het werd niet gesignaleerd en niet bijgehouden, en het vertraagde een kritieke review van systeemtoegang met negen dagen.

De meeste SAP-plannen steunen op nette schattingen, voltijdse beschikbaarheid en voorspelbare werkstromen. Die versie van de werkelijkheid overleeft zelden de eerste maand van Realize.

Ik plan rond drie dingen: wat het werk daadwerkelijk vraagt, wat de beschikbare mensen daadwerkelijk leveren en wat er verandert als de werkelijkheid afwijkt van het plan. Een plan dat standhoudt, dekt zes dimensies af:

1. Aantal mensen per rol per Activate-fase. Geen vlakke toewijzing. Explore lijkt in niets op Realize.
2. Uren per week, bevestigd door de leidinggevende. Schriftelijk, niet aangenomen.
3. Gelijktijdige verplichtingen per persoon. Iemand die op 100% staat en ook productiesupport doet, levert veel minder.
4. Een back-up voor elke rol op het kritieke pad. Cross-training is niet optioneel in een programma van 18 maanden.
5. Afhankelijkheden tussen workstreams. Elk met een benoemde eigenaar, een deadline en een escalatiepad, zichtbaar op de dag dat het uitloopt.
6. Updatefrequentie. Wekelijks in actieve fasen. Het plan bij de kick-off is versie één.

Plannen gaan mis wanneer de planner generieke IT-rollen hanteert. SAP vraagt om specifieke functionele en technische specialisatie. De standaardset voor een S/4HANA-programma:

Programmaleiding. Programmamanager, PMO-lead en oplossingsarchitect. De architect is verantwoordelijk voor de samenhang van het ontwerp over modules heen.

Functionele consultants. Eén lead per module binnen de scope: financiële boekhouding (FI), controlling (CO), Materials Management (MM), Sales and Distribution (SD), Production Planning (PP), Extended Warehouse Management (EWM), plus Human Capital Management (HCM), Plant Maintenance (PM) en Project System (PS) waar die in scope zijn. Gebruikt u nog het klassieke Warehouse Management (WM), plan dan de overstap: de gebruiksrechten via het compatibility pack voor S/4HANA on-premise zijn eind 2025 verlopen.

Technische consultants. ABAP-ontwikkelaars voor rapporten, interfaces, conversies, uitbreidingen, formulieren en workflows (RICEFW), en voor clean-core-extensies op vrijgegeven API's of SAP BTP. Integratiespecialisten voor SAP Integration Suite (Cloud Integration, voorheen CPI), SAP Process Orchestration waar dat nog draait en eventuele middleware van derden.

Platform. Basis-consultants voor HANA, kernelpatches, transporten, systeemkopieën en performancetuning. Securityconsultants voor rolontwerp, analyse van functiescheiding en SAP GRC Access Control waar in scope.

Data. Migratiespecialisten die werken met de app „Migrate Your Data” van de SAP S/4HANA Migration Cockpit (de oudere LTMC-transactie is deprecated), de Migration Object Modeler voor maatwerkobjecten en SAP Data Services voor complexe transformaties. In mijn gids over waarom SAP-datamigratie mislukt leg ik uit waarom dit team eerder moet starten dan de meeste plannen toestaan.

Verandermanagement. Change lead, traininglead en eigenaar van de gereedheid van de business. Meestal onderbezet, omdat de behoefte pas zichtbaar wordt in Deploy.

Kant van de klant. Businessanalisten (één per grote module), procesverantwoordelijken (één per procesdomein) en testers uit de operatie voor de UAT.

Deze rollen als onderling verwisselbare plekken behandelen is de meest gemaakte planningsfout. Een senior FI-consultant kan geen ontwerpsessie voor SD leiden. Een junior ABAP-ontwikkelaar kan geen integratie ontwerpen. Voor de verantwoordelijkheden per rol verwijs ik naar mijn overzicht van essentiële rollen in een SAP-implementatieteam.

De vraag naar capaciteit is niet vlak. De Activate-fasen veroorzaken voorspelbare curves die een vlakke toewijzing mist.

Prepare (doorgaans week 1 tot 4). Licht. Programmamanager, architect en een lead per module voor de scoping. Businessgebruikers bevestigen de scope. Basis en security starten met de inrichting van de omgevingen.

Explore (doorgaans maand 2 tot 5). Zwaar op functionele consultants en businessgebruikers, met ontwerpworkshops die de planning bepalen. ABAP en integratie zijn licht totdat ontwerpbeslissingen vallen. Basis bereidt de sandbox- en kwaliteitssystemen voor.

Realize (doorgaans maand 5 tot 12). Zwaar op technische mensen: configuratie, bouw, unit- en integratietesten. De ABAP-belasting piekt. Businessgebruikers sluiten aan bij de testcycli. Het datateam bouwt migratieobjecten en voert proefmigraties uit.

Deploy (doorgaans maand 12 tot 14). Zwaar op datamigratie, Basis, security, verandermanagement en training. De UAT slokt capaciteit van de business op. Cutover-repetities vragen om teams op dezelfde locatie. De planning van de hypercare begint.

Run (vanaf maand 14; hypercare doorgaans 30 tot 90 dagen). Een licht kernteam en zware supportdekking. Basis en applicatiebeheer schalen op terwijl consultants afschalen.

Behandelt u deze fasen als even zware vraagvensters, dan bemant u Prepare te ruim, Realize te krap en komt u in Deploy mensen tekort voor de datamigratie. De fasecurve is de belangrijkste vorm in het plan.

1. PrepareCirca 11 FTEWeek 1 tot 4. Leads bepalen de scope, Basis richt in
2. ExploreCirca 36 FTEMaand 2 tot 5. Functionele mensen en businessgebruikers
3. RealizeCirca 56 FTE, de piekMaand 5 tot 12. Bouw, en de ABAP-belasting piekt
4. DeployCirca 42 FTEMaand 12 tot 14. Data, Basis, security, verandermanagement
5. RunCirca 12 FTEVanaf maand 14. Hypercare doorgaans 30 tot 90 dagen

Voortdurende crises. Als het team constant brandjes blust, voorspelt het plan de werkelijkheid niet meer. Eén afwezigheid mag een workstream niet kunnen ontsporen.

Businessgebruikers verdwijnen als u ze nodig hebt. Ontwerpsessies en UAT lopen vast omdat businessgebruikers niet beschikbaar zijn. Het is een van de meest voorkomende bronnen van uitloop. De oorzaak is bijna altijd dezelfde: de tijd werd aangenomen, niet formeel toegezegd. Operationele druk wint elke keer dat de toezegging niet was vastgelegd.

Technische mensen te dun verdeeld. Uit het werk van Gerald Weinberg over softwaremanagement volgt de schatting dat iemand die over drie projecten is verdeeld ongeveer 60% van de totale capaciteit levert, terwijl de rest verloren gaat aan schakelen. De samenvatting van onderzoek naar taakwisselingen door de American Psychological Association komt op dezelfde orde van verlies uit: korte mentale blokkades door te wisselen tussen taken kunnen tot 40% van de productieve tijd kosten. Het plan ziet er efficiënt uit. De output niet.

Het kritieke pad verandert elke week. Voortdurend herschikken, workstreams die laat starten en wekelijkse wijzigingen in prioriteiten zijn meestal terug te voeren op een onduidelijke scope of slecht gesequenceerde afhankelijkheden. Repareer de scope voordat u het capaciteitsplan repareert.

1. Schijnbare beschikbaarheid. Iemand staat op 100% maar doet ook de maandafsluiting en productiesupport. Vraag hoeveel uur per week, waar die persoon nog meer aan werkt en of de leidinggevende dat schriftelijk heeft bevestigd.
2. Gedeelde rollen zonder grenzen. Eén persoon doet tegelijk oplossingsontwerp, testen en verandermanagement. Verdeel verantwoordelijkheden per taak, niet per functietitel, en maak nooit één persoon op twee plekken tegelijk kritiek.
3. Ontbrekende tijd van businessgebruikers. Workshops lopen uit en UAT-akkoorden duren weken langer. Laat tijd schriftelijk toezeggen en door het afdelingshoofd ondertekenen, houd aanwezigheid bij en escaleer patronen vroeg.
4. Geen buffer. Eén afwezigheid legt een workstream stil. Bouw buffer in op taakniveau, niet alleen op faseniveau, en zorg voor cross-training van minstens één persoon per kernrol.
5. Een plan dat nooit wordt bijgewerkt. Opgesteld bij de kick-off en nooit herzien. Herzie het wekelijks tijdens actieve oplevering, koppel het aan fasepoorten en werk het bij als de werkelijkheid verschuift.

Begin met bevestigde beschikbaarheid. Ga voor de start van het project naar de leidinggevenden. Bevestig uren per week en andere verplichtingen en leg ze vast. Verandert de beschikbaarheid halverwege het project, dan is die uitgangssituatie uw basis voor escalatie.

Vorm het per fase. De belasting van een ABAP-ontwikkelaar in Explore verschilt van die in Realize. Businessgebruikers pieken in Explore voor het ontwerp en in Deploy voor de UAT. Een vlakke toewijzing ziet er op papier evenwichtig uit en faalt in de praktijk.

Breng afhankelijkheden expliciet in kaart. Datamigratie voedt de integratietesten, die voeden de UAT, die het cutover aansturen. Geef elke afhankelijkheid een eigenaar, een datum en een vlag, zodat uitloop dezelfde dag zichtbaar is.

Bescherm de tijd van businessgebruikers op stuurgroepniveau. Hun dagelijkse werk gaat door. Zonder expliciete goedkeuring van hun management over het aantal uren per week laten ze het project vallen zodra de operationele druk toeneemt. De sponsor, niet de projectmanager, hoort de afdelingshoofden om die tijd te vragen.

Werk het plan wekelijks bij. Een plan dat twee weken onaangeroerd blijft, klopt waarschijnlijk niet. Volg de werkelijke tegenover de geplande bezettingsgraad. Iemand die twee weken achter elkaar op 120% zit, is een signaal dat die persoon overbelast is of dat het plan niet klopt.

Dit zijn indicatieve aantallen en tariefbereiken om als uitgangspunt te gebruiken. Sector, scope, geografie en partner verschuiven ze allemaal. Gebruik de tabellen als realiteitscheck, niet als offerte.

Brownfield in het middensegment ($5 tot $15 miljoen, ongeveer 12 maanden)

Typische scope: één juridische entiteit of een kleine groep, drie of vier modules (meestal FI, CO, MM, SD), standaardprocessen en beperkte maatwerkontwikkeling.

Workstream	Prepare	Explore	Realize	Deploy	Run
Programmamanager	1	1	1	1	0,5
Oplossingsarchitect	1	1	1	0,5	0
Functionele consultants (FI/CO, MM, SD plus één)	1	4	4	2	1
ABAP en techniek	0	1	3	1	0,5
Integratie	0	0,5	2	1	0,5
Basis	0,5	0,5	1	2	1
Security en autorisaties	0	0,5	1	1,5	0,5
Datamigratie	0	1	2	3	0
Testlead	0	0,5	1	1	0
Verandermanagement en training	0,5	1	1	2	0,5
Businessanalisten aan klantzijde	1	4	3	2	1
Totaal piek-FTE	5	14	20	17	5

Enterprise-brownfield ($30 tot $80 miljoen, 15 tot 18 maanden)

Typische scope: meerdere entiteiten, zes tot negen modules, complexe integratie, substantiële maatwerkontwikkeling en meerdere landenuitrollen.

Workstream	Prepare	Explore	Realize	Deploy	Run
Programmamanager en PMO	2	2	3	3	1
Oplossingsarchitecten (lead plus module)	2	3	3	1,5	0,5
Functionele consultants (alle modules in scope)	2	10	12	5	2
ABAP en techniek	0	3	8	3	1
Integratie en middleware	0,5	2	5	2	1
Fiori en UI5	0	1	3	1	0,5
Basis	1	1	2	4	2
Security en GRC	0,5	1,5	2	3	1
Datamigratie	0	2	5	6	0,5
Testen	0,5	1	3	4	0
Verandermanagement en training	1	2	3	5	1
Businessanalisten aan klantzijde	2	8	7	5	2
Totaal piek-FTE	11	36	56	42	12

Dagtarieven per rol en regio (2024 tot 2025)

Dit zijn door partners gefactureerde tarieven per specialist, geen salarissen. Het gemengde programmatarief komt meestal 30 tot 50% onder het senior onshoretarief uit, omdat de meeste programma's onshore architecten combineren met offshore oplevering.

Rol	Onshore VS/VK/DE	GCC (VAE/KSA)	Nearshore (Latijns-Amerika/Oost-Europa)	Offshore (India)
Oplossingsarchitect (senior)	$2.000 tot $3.500	$1.500 tot $2.500	$900 tot $1.500	$500 tot $1.000
Functioneel consultant (senior)	$1.500 tot $2.800	$1.200 tot $2.000	$700 tot $1.400	$300 tot $700
Functioneel consultant (medior)	$1.000 tot $1.800	$800 tot $1.400	$500 tot $900	$200 tot $500
ABAP en techniek (senior)	$1.400 tot $2.500	$1.000 tot $1.800	$600 tot $1.200	$300 tot $700
Integratiespecialist	$1.500 tot $2.800	$1.100 tot $1.900	$700 tot $1.300	$350 tot $800
Basis	$1.400 tot $2.200	$1.000 tot $1.800	$600 tot $1.100	$300 tot $700
Security en GRC	$1.500 tot $2.500	$1.100 tot $1.900	$700 tot $1.300	$350 tot $800
Datamigratie	$1.300 tot $2.200	$1.000 tot $1.700	$600 tot $1.100	$300 tot $700
Lead verandermanagement en training	$1.200 tot $2.000	$900 tot $1.500	$500 tot $1.000	$250 tot $600
Junior consultant (elke rol)	$800 tot $1.400	$500 tot $900	$400 tot $700	$150 tot $350

De verdeling over onshore, nearshore en offshore

De meeste SAP-programma's mengen regio's. Het is een afweging tussen kosten en snelheid, geen ja-of-nee-keuze.

Programma's in de Amerikaanse private sector zijn doorgaans voor 30 tot 60% onshore, gemeten in FTE. Onshore zit geconcentreerd in architectuur, verandermanagement, businessanalyse en senior functionele rollen, waar nabijheid van de business telt. Offshore zit geconcentreerd in ABAP, het bouwen van integraties en de uitvoering van datamigratie, waar het werk makkelijker te specificeren is. Amerikaanse federale programma's zijn vaak volledig onshore met US-person-beperkingen, afhankelijk van de werklast.

GCC-programma's zijn doorgaans voor 60 tot 70% onshore, omdat lokale aannameregels en eisen rond de Arabische taal het aandeel opdrijven. Offshore werk neigt naar Zuid-Aziatische centra vanwege de overlap in tijdzones. Europese programma's variëren: in de maakindustrie is vaak ongeveer 50% onshore, terwijl de publieke sector en gereguleerde sectoren hoger uitkomen vanwege dataresidentie.

Een veelgemaakte fout is de verdeling alleen op kosten optimaliseren. Een team dat voor 80% offshore is, met 20% onshore architecten, ziet er in het spreadsheet goedkoop uit. De verborgen kosten zijn de dagelijkse overdrachtscyclus en tragere ontwerpworkshops zonder context van de business. Het goedkoopste team levert zelden het goedkoopste programma. Als u partners vergelijkt, behandelt mijn gids over SAP-implementatiepartners per tier hoe tarieven en teamsamenstelling tussen hen verschillen.

Een plan dat eenmaal is gebouwd en nooit opnieuw wordt bekeken, is geen plan. Behandel elke aanname erin als een hypothese die u test in de eerste week van de uitvoering, en elke week daarna.

Wat is capaciteitsplanning in SAP-projecten en waarom is het belangrijk?

Het is bepalen welke mensen het project nodig heeft, wanneer en voor hoeveel van hun tijd, en daarna bijhouden of dat overeenkomt met de werkelijkheid.

SAP-projecten hangen af van specifieke personen: de FI/CO-lead die uw rekeningschema begrijpt, de migratiespecialist die uw legacydata kent, de change lead met relaties in de business. Zijn zij op het juiste moment niet beschikbaar, dan staat het werk stil of wordt het verkeerd gedaan. Veel vertragingen die technisch lijken, zijn in werkelijkheid capaciteitsproblemen.

Hoe veroorzaakt slechte capaciteitsplanning vertraging in SAP-projecten?

Via afhankelijkheden. Een configuratielead wordt in Realize naar een ander project gehaald. Het werk stokt, wat de integratietesten vertraagt, daarna de UAT en daarna de gereedheid voor cutover. Een afwezigheid van twee weken in week acht kan tegen de go-live uitgroeien tot een uitloop van zes weken.

Kleine gaten aan het begin worden grote vertragingen aan het eind. Tegen de tijd dat de impact zichtbaar is, kost herstel een veelvoud van wat een vroege oplossing had gekost.

Hoe krijg ik businessgebruikers betrokken bij een SAP-project als ze ook hun gewone werk hebben?

Haal vóór de start van het project een schriftelijke toezegging van hun leidinggevende op: uren per week, in welke fasen ze het hardst nodig zijn en welke goedkeuring vereist is als de beschikbaarheid verandert.

Houd hun aanwezigheid bij zoals bij elke andere resource. Neemt die af, escaleer dan op stuurgroepniveau. Afdelingshoofden kunnen de toezegging afdwingen; het projectteam kan dat niet.

Hoe ga ik om met een sleutelpersoon die halverwege het project vertrekt?

Voorkom om te beginnen single points of failure: minstens één andere persoon moet elke kritieke workstream goed genoeg begrijpen om die op gang te houden.

Vertrekt iemand, leg dan direct vast wat die persoon weet: ongedocumenteerde beslissingen en de redenering achter de configuratie. Dat is vaak moeilijker dan een vervanger vinden. Voor de vervanging zijn een overdrachtsdocument, opgenomen sessies en een week overlap het minimum.

Wanneer moet ik een capaciteitsprobleem escaleren?

Eerder dan prettig voelt. Escaleer wanneer een benoemde eigenaar van een afhankelijkheid langer dan een week niet beschikbaar is, een businessgebruiker sessies blijft missen, een technische resource twee weken boven 120% bezetting zit of een workstream wordt geblokkeerd door een uitgestelde bemanningsbeslissing.

De prijs van te vroeg escaleren is een ongemakkelijk gesprek. De prijs van te laat escaleren is weken uitloop.

Hoe ga ik om met resources die over meerdere projecten worden gedeeld?

Ga ervan uit dat gedeelde mensen iets anders voorrang geven zodra de druk oploopt. Spreek specifieke uren per week af met hun primaire leidinggevende, bouw buffer in voor werk dat van hen afhangt en houd ze van uw kritieke pad af, tenzij u een terugvaloptie hebt.

Bij gedeelde businessgebruikers moet het verzoek van de sponsor komen. Een projectmanager die een afdelingshoofd om tijd vraagt, verliest het elke keer van operationele prioriteiten.