Een projectcharter voor een SAP-implementatie opstellen

Een projectcharter voor een SAP-implementatie is het korte document dat het programma formeel autoriseert. Het legt schriftelijk vast wat het programma oplevert, wat niet, wie beslist, hoe succes wordt gemeten en tegen wanneer. Schrijf het voordat de werkomschrijvingen van leveranciers worden getekend, laat de sponsor aan klantzijde er eigenaar van zijn en maak het specifiek genoeg om een discussie te beslechten. Hieronder staat een outline per onderdeel.

Teams stappen vol zelfvertrouwen de SAP-kickoff in. Dan blijkt dat rollen vaag zijn omschreven, dat niemand de grenzen van de scope heeft afgesproken en dat niemand kan zeggen hoe succes eruitziet. Een charter moet dat voorkomen. De meeste doen dat niet, omdat ze zijn geschreven om aan een governance-eis te voldoen in plaats van om het werk te verankeren.

Ik heb projectcharters gezien die er netjes uitzagen maar niet aansloten op de echte plannen. De versie die werkt, is de versie waarover mensen discussiëren tijdens het opstellen. Zo weet u dat ze eerlijk is.

Drie documenten worden bij elk groot SAP-programma door elkaar gehaald. Ze doen verschillend werk.

Document	Doel	Opgesteld door	Moment
Projectvoorstel	Onderbouwen waarom het project moet doorgaan	Business sponsor	Vóór goedkeuring
Projectcharter	Het project autoriseren; scope, doelstellingen, benoemde eigenaren en governance vastleggen	Sponsor samen met de programmamanager	Bij de start
Projectplan	Bepalen hoe het werk wordt gedaan: taken, resources, afhankelijkheden	Programmamanager	Nadat het charter is goedgekeurd

Het charter is het governancedocument. Het trekt grenzen. Loopt uw S/4HANA-programma over meerdere modules, landen en leveranciers, dan beslist u in het charter wat erbij hoort, voordat mensen hun eigen aannames gaan maken.

Doelstellingen gekoppeld aan een bedrijfsresultaat

Niet “systeemmodernisering”. Elke doelstelling heeft een getal nodig. De test: kunt u de visie in 30 seconden en zonder slides uitleggen aan een bestuurslid?

Ik heb aan SAP-programma's gewerkt waar iedereen de go-live vierde en waar twee maanden later niemand kon zeggen of de beloofde waarde was geleverd. Een klant in de maakindustrie gaf meer dan $4 miljoen uit en kon geen enkel rendement aantonen. De CFO vroeg om meetgegevens. Niemand had ze, en het vertraagde hun volgende financieringsronde.

Zet daar een retailklant tegenover die ik begeleidde. In het charter stonden vanaf dag één KPI's. Zij konden een daling van 32 procent in de orderverwerkingskosten aantonen, en fase 2 werd direct goedgekeurd.

Scope met expliciete uitsluitingen

Dit is het meest over het hoofd geziene onderdeel. Teams schrijven gedetailleerde lijsten van wat binnen de scope valt en laten de uitsluitingen weg, terwijl juist daar de discussies ontstaan.

Ik werkte met een zorgbedrijf dat zijn SAP-uitrol op deze manier gefocust hield. Het hoofd marketing wilde tijdens de gebruikersacceptatietest (UAT) analytics toevoegen voor campagnetracking. Het charter bood daar geen ruimte voor, en de stuurgroep maakte er meteen een punt van. Die ene beslissing bespaarde $850.000 en voorkwam een vertraging van zes weken.

Namen van personen, niet van afdelingen

“Team Finance: levert input voor de rapportage” maakt niemand verantwoordelijk. “Finance lead, [naam]: bepaalt de rapportagevereisten, tekent de FI/CO-configuratie af, keurt de gereedheid van de datamigratie goed” wel.

Mijlpalen als toezeggingen

Een retailklant stelde zijn go-live vier maanden uit. De eerste vertraging was een uitloop van drie weken bij het verzamelen van de requirements, die niemand in de planning verwerkte. Men nam aan dat het verderop in te halen was. In plaats daarvan gaf men $1,8 miljoen uit aan overschrijdingen.

Het werkt ook andersom. Bij een opdracht in de maakindustrie hield het team zich aan het gepubliceerde plan. Toen het datamigratieteam een vertraging meldde, autoriseerde de stuurgroep meteen extra bezetting, omdat het charter de mijlpaal zichtbaar maakte. Die beslissing bespaarde zowel tijd als $600.000.

Budget, risico's en afhankelijkheden

Een budget op hoofdlijnen, de drie of vier risico's die het programma kunnen laten ontsporen, en de andere programma's die om dezelfde mensen en middelen concurreren. Een retailklant gaf $3,2 miljoen uit aan een implementatie die nooit live ging. Het financeherontwerp en het SAP-project liepen parallel, met dezelfde resources en hetzelfde budgetvenster, en geen van beide charters noemde het andere. De directie zag het te laat.

Dit is de structuur waarmee ik zou beginnen. Elk onderdeel moet op een pagina of minder passen.

1. Doel en achtergrond: waarom nu, wat er kapot is, wat er gebeurt als u niets doet.
2. Doelstellingen en succesmaatstaven: elke doelstelling met een nulmeting, een streefwaarde en een datum.
3. Scope: modules, processen, juridische entiteiten, landen, vestigingen, integraties en data die binnen de scope vallen.
4. Buiten scope: even zorgvuldig geschreven als de scope, met de fase waarnaar elk uitgesloten onderdeel is uitgesteld.
5. Deploymentmodel en extensieregels: S/4HANA Cloud Public Edition, Private Edition onder RISE of on-premise, en hoe maatwerkontwikkeling wordt goedgekeurd.
6. Governance: sponsor, stuurgroep, design authority, wijzigingsbeheer en escalatiepad, met benoemde personen.
7. Rollen en verantwoordelijkheden: benoemde personen voor elk procesgebied, data, testen, verandermanagement en cutover.
8. Mijlpalen: fasepoorten met data en de criteria om ze te passeren. Mijn gids over quality gates bevat voorbeelden.
9. Budget en reserve: het bedrag, de reserve en wie die mag vrijgeven.
10. Risico's, aannames en afhankelijkheden: inclusief parallelle programma's en wettelijke deadlines.
11. Complianceregels: bijvoorbeeld HIPAA in de Amerikaanse zorg, GxP in de farmacie, SOX voor Amerikaanse beursgenoteerde bedrijven.
12. Goedkeuring: sponsor en businessleads, met versienummer en datum.

1. 01Vraag het de mensen die het werk kennenSponsors, businessleads en eindgebruikers
2. 02Scheid must-haves van nice-to-havesNodig voor go-live, fase 2 of niet in dit project
3. 03Begin met een sjabloonVoeg daarna integratie, data en compliance toe
4. 04Wees specifiek genoeg om discussies te beslechtenKunt u van elke doelstelling bewijzen dat ze is gehaald?
5. 05Zorg voor echte goedkeuringGelezen, bevraagd en geaccepteerd, onderdeel voor onderdeel

Een charter waarnaar u kunt verwijzen als de scope in maand drie wordt betwist

1. Vraag het de mensen die het werk kennen

Ga voordat u iets schrijft zitten met sponsors, businessleads en eindgebruikers. Vraag wat er kapot is en wat eerder is geprobeerd. Ik werkte ooit met een klant in de maakindustrie die $1,8 miljoen verspilde aan een SAP-implementatie, omdat men aannam te weten wat de werkvloer nodig had. Na zes maanden bleek dat de echte problemen in de werkprocessen niet werden aangepakt.

Bij een financetransformatie waar ik aan werkte, wilde IT SAP uitrollen om efficiencyproblemen op te lossen. Gesprekken met finance lieten zien dat het echte probleem de slechte datakwaliteit was. Hadden we het niet gevraagd, dan hadden we miljoenen uitgegeven aan het oplossen van het verkeerde probleem.

2. Scheid must-haves van nice-to-haves voordat u de scope schrijft

Categoriseer elke input als nodig voor go-live, fase 2 of niet in dit project. Een klant van mij in de professionele dienstverlening ging 40 procent over budget omdat requirements op drie plekken stonden en maanden na de start telkens opnieuw werden “ontdekt”. Mijn gids met scopesjabloon helpt bij deze stap.

3. Begin met een sjabloon en voeg dan de SAP-specifieke onderdelen toe

Een generiek sjabloon mist wat SAP-programma's duur maakt: integratiepunten, eigenaarschap van datamigratie en datacleansing, aannames per module, complianceregels en de regels voor maatwerkontwikkeling. Ik hoorde van een SAP-project dat startte met een generiek charter waarin datacleanup nooit werd genoemd. Zes maanden later bleek de legacydata een puinhoop, wat $750.000 en drie maanden extra kostte.

4. Wees specifiek genoeg om discussies te beslechten

Ik leidde de implementatie voor een retailklant in Singapore wiens charter zei: “inventarisbeheer moderniseren”. De helft van het team dacht aan snellere verwerking. De andere helft richtte zich op forecasting. Het resultaat: $1,8 miljoen uitgegeven en geen overeenstemming over wat succes was. Vraag bij elke doelstelling: kan ik bewijzen dat dit is gehaald?

5. Zorg voor echte goedkeuring

Het charter is af als de mensen die het tekenen het hebben gelezen, ter discussie hebben gesteld en de toezeggingen hebben geaccepteerd. Loop de sponsor en de businessleads er onderdeel voor onderdeel doorheen. Ik heb retailklanten drie volle dagen zien besteden aan afstemming over het charter. Het scheelde hen later maanden aan discussies en scopewijzigingen.

Fout	Wat het veroorzaakt	Wat u in plaats daarvan doet
Vage doelstellingen (“efficiëntie verbeteren”)	Teams trekken verschillende kanten op	Zet een getal bij elke doelstelling
Geen uitsluitingen	De scope groeit ongemerkt	Schrijf de lijst met wat buiten scope valt even zorgvuldig als de scope
Eigenaren alleen met functietitel of afdeling genoemd	Besluiten worden uitgesteld	Noem personen bij naam
Geen succesmaatstaven	De go-live wordt gevierd, de waarde wordt nooit aangetoond	Definieer KPI's vóór de kickoff
Parallelle programma's niet in kaart gebracht	Botsingen om resources en budget	Leg afhankelijkheden vast in beide charters
Charter geschreven door de implementatiepartner	De scope weerspiegelt wat de partner wil leveren	De klant is eigenaar; de partner levert het detail

Over het laatste punt ben ik stellig. Uw implementatiepartner moet uw charter niet schrijven. Zijn prikkel is om het project te starten. De uwe is om het af te bakenen.

Bij RISE with SAP (Private Edition) voegt u twee dingen toe aan het governance-onderdeel. Ten eerste een clean core-goedkeuringsforum. SAP classificeert extensies nu van level A, uitsluitend vrijgegeven API's, tot level D, modificaties (SAP News, augustus 2025). Private Edition laat u de core nog steeds aanpassen, dus het forum is wat voorkomt dat technische schuld zich opstapelt. Ten tweede een escalatiepad naar SAP. Onder RISE beheert SAP de infrastructuur en de technische operatie. De CIO moet weten wie hij bij SAP moet bellen als er iets faalt op platformniveau, en niet alleen bij de partner.

Bij GROW with SAP (Public Edition) wordt het charter kleiner. Extensies zijn beperkt tot vrijgegeven interfaces, dus het platform dwingt clean core voor u af, en de integratieopties zijn smaller. Visie, succesmaatstaven, benoemde eigenaren en uitsluitingen blijven even belangrijk.

AI-tools kunnen interviewnotities sneller omzetten in een eerste concept. Het politieke werk van het charter kunnen ze niet doen: sponsors laten afspreken waar ze eigenaar van zijn.

Wat is een projectcharter bij een SAP-implementatie?

Het document dat het SAP-programma formeel autoriseert. Het legt scope en uitsluitingen vast, noemt de sponsor en de verantwoordelijke personen, definieert succesmaatstaven, stelt mijlpalen en governance vast en somt de belangrijkste risico's op. Een bruikbaar charter is specifiek genoeg om een meningsverschil over scope of eigenaarschap te beslechten.

Wat moet een SAP-projectcharter bevatten?

Doel, doelstellingen met meetbare streefwaarden, scope, expliciete uitsluitingen, deploymentmodel en extensieregels, governance met benoemde personen, rollen, mijlpalen met poortcriteria, budget en reserve, risico's en afhankelijkheden, complianceregels en goedkeuring. De outline hierboven toont elk onderdeel.

Wat is het verschil tussen een projectcharter en een projectplan?

Het charter autoriseert en definieert: scope, sponsor, governance en mijlpalen op hoofdlijnen. Het plan voert uit: taken, afhankelijkheden, resources en volgorde. Een plan zonder charter drijft af, omdat de scope nooit is afgesproken. Elke toezegging in het plan moet terug te voeren zijn op het charter.

Wie moet het SAP-projectcharter schrijven?

De sponsor aan klantzijde is eigenaar en de programmamanager schrijft het concept, met finance-, IT- en operationsleads die het detail aanleveren. Ik raad af om de implementatiepartner het te laten schrijven. Zijn prikkel is om het project te starten, niet om u te beschermen tegen scope die u niet nodig hebt.

Hoe verandert RISE with SAP het projectcharter?

Voeg een clean core-goedkeuringsforum toe dat besluit welke extensies zijn toegestaan en op welk level. Voeg een escalatiepad naar SAP toe voor platformproblemen, omdat SAP onder RISE de infrastructuur beheert. Bij GROW with SAP is het charter lichter, omdat Public Edition clean core technisch afdwingt.

Kan het projectcharter tijdens de implementatie veranderen?

Ja, via wijzigingsbeheer. Behandel het charter als baseline. Wijzigen scope, sponsor, budget of een belangrijke mijlpaal, werk het dan bij met een versienummer, een notitie over wat er veranderde en waarom, en nieuwe goedkeuring. Laat het niet stilletjes herzien worden telkens als het project afdrijft.