
Inhoud
- Planning en controle zijn verschillende klussen
- Drie publieke SAP-mislukkingen die het patroon laten zien
- Lidl: ongeveer zeven jaar en naar schatting €500 miljoen, daarna stopgezet
- Hershey: ongeveer $100 miljoen aan Halloween-orders niet geleverd
- Revlon: een ontregelde fabriek en een materiële zwakte in de beheersing
- De kerndisciplines
- Work breakdown structure
- Planningsbeheer
- Budgetbeheer
- Risicomanagement
- Communicatie en escalatie
- Hoe RISE, GROW en AI de controle in 2026 veranderen
- RISE verandert naar wie u escaleert
- Clean core geeft scopebeheer een technische rugdekking
- AI schrijft de rapporten, mensen nemen de besluiten
- Een wekelijks controleritme met eigenaren
- Veelgestelde vragen
De meeste SAP-programma's hebben een plan. Veel minder hebben controle. Planning bepaalt scope, tijdlijn, budget en risico's. Controle is het wekelijkse werk om de voortgang tegen dat plan te volgen, afhankelijkheden te beheren, vroeg te escaleren en elke wijziging te beoordelen voordat ze wordt goedgekeurd. Deze gids is voor programmadirecteuren, PMO's en opdrachtgevers van wie het SAP-programma aan het afdrijven is, of die dat willen voorkomen. Ze behandelt hoe controle eruitziet, drie publieke mislukkingen die laten zien wat er zonder gebeurt, en een wekelijks controleritme met eigenaren dat u deze week kunt overnemen.
Toen ik begon, werkte ik aan een SAP-programma dat op papier uitstekend oogde. Tijdlijnen, risicoregisters, wijzigingslogs, alles wat u verwacht. Niemand hield zich eraan. De stuurgroep kwam zelden bijeen. Finance wachtte op datamigratie. IT was nog niet begonnen. Niemand volgde afhankelijkheden. Iedereen nam aan dat een ander de zaak op koers hield.
Tegen maand zes liep de helft van het project achter op schema en jaagden we op onze eigen fouten. Het ergste was dat niemand het zag aankomen.
Het was geen planningsprobleem. Het was een controleprobleem. Er was geen echte inzet van capaciteit, geen degelijke risicobeheersing en geen escalatiepad. Het plan was één keer opgesteld en daarna verlaten ten gunste van vergaderingen.
Planning omvat scope, tijdlijn, budget, resources, het risicoregister en toezeggingen voor mijlpalen. De meeste teams leveren dit op. De vraag is of iemand er van week tot week mee werkt.
Controle omvat het volgen van de werkelijke voortgang tegen het plan, afwijkingen vroeg zichtbaar maken, afhankelijkheden beheren, escaleren als het uitloopt en de baseline herzien wanneer scope of tijdlijn formeel verandert. De meeste teams doen dit slecht.
- Voortgang volgenWerkelijk versus plan, per werkpakket
- Afwijkingen signalerenElke taak die drie dagen te laat is
- Afhankelijkheden checkenWie geblokkeerd raakt als dit uitloopt
- EscalerenVia een vooraf afgesproken route
- Wijzigingen beoordelenEerst tijd, kosten en resources
- Baseline herzienPas na een formele wijziging
Elke week, met benoemde eigenaren
Dit gaat stuk als controle ontbreekt:
| Wat er stukgaat zonder controle | Waarom het gebeurt |
|---|---|
| Deadlines schuiven ongemerkt op | Niemand controleert tussen de mijlpaalreviews |
| Aannames blijven ongetoetst | Elk team verwacht dat een ander de afhankelijkheid oppakt |
| Scope breidt informeel uit | Wijzigingen worden in vergaderingen goedgekeurd zonder impactanalyse |
| Risico's worden genegeerd tot ze toeslaan | Risicolog wordt per kwartaal bijgewerkt in plaats van wekelijks |
| Kosten lopen over het budget heen | Inspanning staat in de urenstaten maar is niet aan werkpakketten gekoppeld |
| Teams houden op met communiceren | Statusoverleggen worden updates zonder acties |
Dit zijn publieke zaken, geen klantverhalen. De grondoorzaken zijn dezelfde als die ik steeds weer zie in adviesopdrachten.
Lidl: ongeveer zeven jaar en naar schatting €500 miljoen, daarna stopgezet
Lidl startte zijn eLWIS-project op SAP Retail in 2011. De waardering van voorraden bij Lidl week af van het standaardmodel van SAP, en Lidl koos ervoor de software aan te passen in plaats van de werkwijze. In 2018 was het systeem live in Oostenrijk, Noord-Ierland en de VS, maar de directie concludeerde dat de oorspronkelijke doelen tegen redelijke kosten niet haalbaar waren. Lidl stopte het project en ging terug naar de ontwikkeling van het eigen systeem. De vakpers schatte de uitgaven op rond €500 miljoen, en de bestuurder voor IT was in 2017 al vertrokken. Heise meldde het besluit in juli 2018. De les: jarenlang maatwerk om een legacy-werkwijze te beschermen is een controlefout, geen softwarefout.
Hershey: ongeveer $100 miljoen aan Halloween-orders niet geleverd
Het nieuwe SAP-, Siebel- en Manugistics-systeem van Hershey zou in april 1999 live gaan, een rustige maand voor de snoepindustrie. Het liep drie maanden uit en ging in juli live, net toen de Halloween-orders binnenkwamen. Orders kwamen niet van het systeem naar de magazijnen. De CEO vertelde analisten dat de problemen Hershey zouden beletten om voor ongeveer $100 miljoen aan product voor Halloween te leveren, en de omzet in het derde kwartaal daalde met 12,4%. Het verslag van CIO magazine schrijft de echte mislukking toe aan timing. Een planningscontrole die het hoogseizoen beschermde, had een andere go-live-datum afgedwongen.
Revlon: een ontregelde fabriek en een materiële zwakte in de beheersing
Revlon zette SAP in februari 2018 aan in zijn fabriek in Oxford, North Carolina, de grootste productielocatie. Verstoringen troffen de productie en de leveringen aan grote Amerikaanse retailers. In maart 2019 maakte Revlon een materiële zwakte in de interne beheersing bekend die aan de uitrol was gekoppeld, met als redenen dat er geen effectieve voortdurende risicobeoordeling was en te weinig opgeleide mensen in de getroffen operaties. Beleggers spanden een rechtszaak aan; TechTarget deed verslag van de rechtszaak, waarin werd gesteld dat voor ongeveer $64 miljoen aan leveringen niet was uitgevoerd.
Geen van deze projecten mislukte omdat SAP de verkeerde keuze was. Ze mislukten op de basis van planning en controle, die al tientallen jaren bestaat.
Work breakdown structure
Een work breakdown structure (WBS) knipt de totale scope op in deliverables met duidelijke eigenaren. Zonder WBS blijft werk onzichtbaar tot het te laat is. Voor een SAP-programma omvat ze procesontwerp, configuratie, datamigratie, integratie, testen, training en cutover, elk uitgesplitst naar taken met een eigenaar en een einddatum.
De waarde zit niet in het document. Het dwingt het gesprek af over wat er moet gebeuren, wie het doet en waarvan het afhangt. Afhankelijkheden zijn wat projecten de das omdoet. Een vertraging in datamigratie blokkeert integratietests, die UAT blokkeren, die het cutovervenster inkrimpen. Een WBS maakt die keten zichtbaar.
Planningsbeheer
Tijdlijnen falen om voorspelbare redenen. Mensen worden weggehaald. Schattingen klopten niet. Beslissingen kosten meer tijd dan gepland. Bouw vanaf dag één buffer in, als expliciete marge naast de taken die er het meest waarschijnlijk behoefte aan hebben, niet als overal verspreide opvulling.
Volg de planning wekelijks. Een week vertraging in week vier is een gesprek. Vier weken vertraging in week zestien is een crisis. Hetzelfde probleem, een heel andere prijs om het op te lossen.
Behandel het moment van go-live als een aparte beslissing. Ga nooit live in een drukke periode voor het bedrijf. De les van Hershey geldt voor elk bedrijf.
Budgetbeheer
Budgetten breken om drie redenen: ongecontroleerde scopewijzigingen, onderschatte datamigratie en hypercarekosten die hoger uitvallen dan de eerste raming. Volg de werkelijke uitgaven vanaf week één tegen het plan. Als een afwijking de stuurgroep bereikt, is het meestal te laat om nog bij te sturen zonder verstoring.
Wijzigingsbeheer is de belangrijkste bescherming van het budget. Elke scopewijziging krijgt vóór goedkeuring een impactanalyse op tijd, kosten en resources. Komt de analyse na de goedkeuring, dan is de wijziging langs het budget heen gegaan. Mijn gids over scope creep voorkomen bij SAP-implementaties gaat dieper in op de wijzigingscommissie.
Risicomanagement
Een risicoregister dat per kwartaal wordt bijgehouden is schijnvertoning. Risico's vragen wekelijkse beoordeling, benoemde eigenaren en responsplannen. Benoem deze bij elk SAP-programma: laat ontdekte datakwaliteit, vertragingen in integratie, gaten in beschikbare capaciteit, een ingekrompen cutovervenster en slechte acceptatie door gebruikers.
Eén klant verloor drie maanden toen de leverancier van de datamigratie deadline na deadline miste. We bleven horen “nog maar twee weken”, tot het te laat was om nog van leverancier te wisselen zonder het budget op te blazen. Een risico met een eigenaar en een triggerdatum had die beslissing maanden eerder afgedwongen. Mijn SAP-risicobeoordelingsmatrix biedt een sjabloon om deze risico's te scoren en te beleggen.
Communicatie en escalatie
Bestuurders hebben koppen nodig. Deliveryteams hebben details nodig. Projectmanagers hebben afwijkingscijfers nodig. Eén update voor iedereen helpt niemand.
Leg escalatiepaden vast en oefen ze vóór een crisis. Bij één SAP-implementatie ging IT ervan uit dat finance de configuratie beoordeelde, en finance ging ervan uit dat IT dat deed. Niemand sloeg alarm tot de go-live nog drie maanden weg was en cruciale goedkeuringen ontbraken; de oplossing werd een haastklus op het laatste moment, extra kosten en een uitgestelde uitrol. Een ander bedrijf deed het goed: de rapportage was gestructureerd en gekoppeld aan acties, dus toen er een probleem opdook, wist iedereen wie het bezat, wat de impact was en hoe het zou worden opgelost.
Bij scope verdient escalatie zijn geld. Ik werkte met een luchtvaartmaatschappij die begon met een eenvoudige boekingsupgrade. Zes maanden later had ze wijzigingen in loyaliteit, bemanningsplanning en financemodules toegevoegd. Geen enkele was urgent. Niemand zei nee. De doorlooptijd verdubbelde en de kosten stegen met 70%.
Planning ziet er op dag één goed uit, maar zonder actieve controle schuiven deadlines op en zwellen de kosten aan. Teams houden op met communiceren, en de stuurgroep begint de verkeerde vragen te stellen.
Het on-premise draaiboek overleeft RISE with SAP niet ongewijzigd. Drie dingen zijn anders.
RISE verandert naar wie u escaleert
Onder RISE with SAP draait SAP de infrastructuur en technische operaties en levert het een customer success-team dat de adoptie volgt. Uw controlestructuur moet hen omvatten. Voor platformkwesties (systeemprestaties, hyperscaler-regio, SAP-serviceniveaus) heeft de programmamanager een gedocumenteerd escalatiepad naar SAP nodig dat niet via de implementatiepartner loopt. Leg het vast voordat u het nodig hebt.
Clean core geeft scopebeheer een technische rugdekking
Elke gap vraagt nu een beslissing: configureren, uitbreiden via vrijgegeven API's (on-stack met ABAP Cloud of side-by-side op SAP BTP), of afwijzen. Op S/4HANA Cloud Public Edition is het aanpassen van de kern geen optie. Op de private editie en on-premise kan het wel, maar de clean core-richtlijnen van SAP zien het als laatste redmiddel, omdat elke aanpassing extra upgradewerk oplevert.
Dat helpt bij scopebeheer. Een verzoek om “het standaard order-to-cash-proces even aan te passen” is geen vrijblijvend configuratiegesprek meer, maar een extensie met ontwerp-, bouw- en testinspanning. Zet onder de stuurgroep een klein forum voor extensiebeoordeling, met één architect die bevoegd is om goed te keuren of af te wijzen. Zonder dat forum belandt elke discussie over maatwerk bij de stuurgroep.
AI schrijft de rapporten, mensen nemen de besluiten
AI helpt nu bij het papierwerk van controle. SAP Cloud ALM, de applicatielifecycletool van SAP, bevat projecttaken, requirements en teststatus, en kan conceptrequirements genereren uit transcripties van workshops. Microsoft Copilot schrijft concepten van afwijkingssamenvattingen voor stuurgroeppakketten op basis van dashboards en statusrapporten. Anomaliedetectie in Power BI of SAP Analytics Cloud signaleert KPI's die afwijken van hun gebruikelijke patroon. Dat is nuttig voor inzet van capaciteit, het aantal wijzigingsverzoeken en supporttickets, minder voor meetwaarden die van nature schommelen.
Wat AI niet doet, is handelen. Een dashboard kan zes weken lang planningsvertraging in het rood tonen. Als de stuurgroep niets doet, gaat de vertraging gewoon door.
Dit is het minimale ritme voor een programma in actieve uitvoering. Ontbreekt een rij, voeg die dan toe vóór al het andere.
| Controle | Minimale praktijk | Eigenaar | Frequentie |
|---|---|---|---|
| Work breakdown structure | Elke taak heeft een eigenaar, een einddatum en zijn afhankelijkheden | PMO-lead | Wekelijks bijgewerkt |
| Planningsreview | Markeer elke taak die meer dan drie dagen te laat is; controleer het kritieke pad | Programmamanager | Wekelijks |
| Budgetbewaking | Werkelijk versus plan per werkpakket | Finance-lead van het programma | Wekelijks, maandelijks gerapporteerd |
| Risicoreview | Elk actief risico heeft een eigenaar, een trigger en een respons | Workstream-leads | Wekelijks |
| Wijzigingsbeheer | Impactanalyse op tijd, kosten en resources vóór goedkeuring | Voorzitter wijzigingscommissie | Wekelijks of zodra verzoeken binnenkomen |
| Extensiebeoordeling (RISE en GROW) | Besluit configureren, uitbreiden of afwijzen voor elke gap | Solution architect | Tweewekelijks |
| Stuurgroep | Besluiten, geen status; stukken vooraf verstuurd | Executive sponsor | Tweewekelijks; wekelijks tijdens cutover en hypercare |
De meeste planning en controle faalt niet omdat de methode fout was, maar omdat de discipline rond maand vier werd losgelaten. Houd het ritme klein genoeg dat het team het in maand veertien nog steeds draait. Voor de stuurgroep zelf verwijs ik naar mijn gids over het inrichten van een effectieve SAP-stuurgroep.
Wat is het verschil tussen projectplanning en projectcontrole?
Planning levert de roadmap op: scope, tijdlijn, budget, resources en risico's. Ze bepaalt aan het begin de richting.
Controle is het doorlopende werk om de voortgang tegen dat plan te volgen, afwijkingen zichtbaar te maken, afhankelijkheden te beheren en de baseline te herzien wanneer er formele wijzigingen zijn. Het gebeurt elke week, zolang het programma duurt.
De meeste SAP-programma's investeren fors in planning en te weinig in controle. Tegen de tijd dat afwijkingen bij de stuurgroep zichtbaar worden, zijn er al weken of maanden aan herstelkosten opgebouwd.
Waarom mislukken SAP-projecten ondanks een projectplan?
Omdat niemand met het plan werkt. Afhankelijkheden worden niet gevolgd, dus de vertraging van de ene workstream blokkeert ongemerkt een andere. Risicologs worden per kwartaal bijgewerkt. Scopewijzigingen worden informeel goedgekeurd. De stuurgroep komt maandelijks bijeen en ziet mijlpaalsamenvattingen die verbergen wat er op de werkvloer gebeurt.
Lidl, Hershey en Revlon hadden allemaal plannen. Wat ze misten, was actieve controle: eerlijke voortgangsbewaking, vroege escalatie en een echte reactie toen de waarschuwingssignalen verschenen.
Hoe beheers ik scope creep in een lang SAP-programma?
Geef elke scopewijziging vóór goedkeuring een schriftelijke impactanalyse: tijd, kosten en resources. Zonder die analyse betekent een wijziging goedkeuren dat u iets onbekends goedkeurt.
De meest effectieve regel: elke toevoeging moet iets anders verdringen. Die ene beperking dwingt de business leads om eerlijk te prioriteren.
Het topmanagement moet het steunen. Als een CFO of COO wijzigingsbeheer openlijk steunt, nemen informele verzoeken snel af. Bij RISE- en GROW-programma's komt daar de extensiebeslissing voor elke gap als technische toets bovenop.
Wat is een work breakdown structure en waarom is die belangrijk voor SAP?
Een WBS knipt de totale scope op in deliverables, elk met een eigenaar en een einddatum. Bij een SAP-programma betekent dat procesontwerp, configuratie, datamigratie, integratie, testen, training en cutover, allemaal uitgesplitst naar taken.
De praktische waarde is het in kaart brengen van afhankelijkheden. Datamigratie voedt integratietests, die UAT voeden, die de cutover voeden. Als er één uitloopt, is de impact verderop meteen zichtbaar.
Hoe verandert RISE with SAP de projectplanning en -controle?
SAP wordt een deelnemer aan de uitvoering. Het draait de infrastructuur en technische operaties, en zijn customer success-team hanteert een eigen ritme voor adoptie en waarde.
Daaruit volgen drie veranderingen. U hebt een gedocumenteerd escalatiepad naar SAP nodig voor platformkwesties, dat niet via de partner loopt. U hebt onder de stuurgroep een forum voor extensiebeoordeling nodig dat bepaalt hoe elke gap onder clean core wordt aangepakt. En u moet het customer success-ritme van SAP in uw governance opnemen in plaats van het parallel te laten lopen.
Wat hoort een stuurgroep bij een SAP-programma te doen?
Besluiten nemen. De taak is op te lossen wat het programmateam niet kan: conflicten over capaciteit, scopegeschillen, budgetwijzigingen en alles wat bevoegdheid over functies heen vraagt. Een stuurgroepoverleg dat zonder besluiten eindigt, was een statusupdate.
Maandelijkse stuurgroepen bij een groot programma laten kwesties tot vier weken wachten. Tweewekelijks is het minimum tijdens actieve uitvoering, wekelijks tijdens cutover en hypercare. Stuur voortgangsrapporten vooraf en gebruik het overleg voor de besluiten die daaruit voortkomen.
Volgende stap
Leidt u nu een ERP-programma?
Raakt dit artikel aan een programma waar u nu middenin zit? Een gesprek van 30 minuten brengt u meestal verder dan nog een week interne analyse.




