Vraag twee keer “waarom” en je ERP-vertraging is geen technisch probleem meer

Wie in een ERP-stuurgroep vraagt waarom de go-live opschuift, krijgt meestal een technisch antwoord. De datamigratie loopt achter. Een interface is nog niet stabiel. De testcyclus leverde meer bevindingen op dan verwacht.

Vraag vervolgens waarom de datamigratie achterloopt, en het gesprek verandert van toon. De datadefinities zijn pas laat vastgelegd, omdat twee businessunits het niet eens raakten over het proces. Niemand had het mandaat om te kiezen. En de key users die de data moesten valideren, zaten midden in de jaarafsluiting.

Twee vragen verder zit je niet meer bij de technologie, maar bij besluitvorming, ownership en capaciteit. Daar ontstaat een groot deel van de vertraging in ERP-programma’s, en daar blijft ze ook vaak onzichtbaar. Ze verhoogt de projectkosten, stelt de businesswaarde uit, zet het projectteam onder druk en duwt de business richting Excel-bestanden en workarounds die na go-live moeilijk nog verdwijnen.

Hieronder vind je zeven oorzaken die je in geen enkele technische statusrapportage terugvindt.

In het kort

ERP-implementaties vertragen zelden alleen door de technologie. De meest voorkomende oorzaken liggen op het snijvlak van technologie, governance en organisatie: onduidelijke besluitvorming, onvoldoende alignment tussen IT en business, processen die nog niet geharmoniseerd zijn, afhankelijkheden die te laat zichtbaar worden, te weinig businesscapaciteit, adoptie die pas na de technische implementatie aandacht krijgt en een programma dat symptomen bestrijdt in plaats van de werkelijke bottleneck. Wie de vertraging wil oplossen, moet eerst scherp krijgen waar ze echt ontstaat.

1. Onduidelijke besluitvorming en governance

Een ERP-programma is in essentie een lange reeks beslissingen over processen, data, rollen, uitzonderingen, prioriteiten en scope. Elke beslissing die blijft hangen, houdt werk tegen dat erop wacht.

Op papier is de governance meestal goed geregeld, met een stuurgroep, een design authority en een escalatiepad. In de praktijk weet niemand precies wie de finale beslissing neemt wanneer twee businessunits het oneens zijn. Problemen worden besproken, genoteerd en doorgeschoven naar de volgende vergadering.

Dat verschijnsel heet decision latency: de tijd tussen het moment waarop een beslissing nodig is en het moment waarop ze effectief genomen wordt. Die tijd staat zelden in een planning, maar bepaalt wel hoe snel een programma vooruitgaat.

Herkenbare signalen

• Beslissingen komen meerdere keren terug op de agenda.
• Escalaties gebeuren pas wanneer de deadline al onder druk staat.
• Stuurgroepen rapporteren status, maar hakken weinig knopen door.
• Projectteams bouwen verder op aannames, “in afwachting van een beslissing”.

Wat het kost: elke uitgestelde beslissing veroorzaakt downstream-vertraging. Werk wordt dubbel gedaan, aannames moeten later worden teruggedraaid en het team verliest momentum.

Een betere projectplanning verandert daar weinig aan. Wat wel helpt, is helderheid over wie beslist, op welk niveau en binnen welke termijn.

2. Onvoldoende alignment tussen IT en business

IT en business willen allebei dat het ERP-programma slaagt, maar ze kijken er vanuit een ander vertrekpunt naar.

IT stuurt op systeemdelivery: functionaliteit, integraties, stabiliteit en planning. De business stuurt op operationele continuïteit. Kunnen we blijven leveren, factureren en produceren? En hoe gaan we om met de uitzonderingen die in de dagelijkse praktijk nu eenmaal bestaan?

Komen die perspectieven niet vroeg genoeg samen, dan blijven requirements verschuiven. Vaak is dat geen onwil van de business: pas in een later stadium wordt duidelijk wat een nieuw proces operationeel betekent.

Herkenbare signalen

• Requirements veranderen nog na de designfase.
• Process owners zijn benoemd, maar nemen hun rol beperkt op.
• IT wordt aangesproken op problemen die eigenlijk procesbeslissingen zijn.
• De implementatiepartner krijgt tegenstrijdige input van verschillende stakeholders.

Wat het kost: change requests, herwerk en een groeiende kloof tussen wat gebouwd wordt en wat de business nodig heeft. In het slechtste geval levert het project technisch op, maar zakelijk nog niet.

3. Processen zijn nog niet werkelijk geharmoniseerd

Een ERP-systeem legt verschillen bloot tussen landen, sites, businessunits en afdelingen die jarenlang naast elkaar konden bestaan.

Veel discussies die in het programma als “technisch issue” verschijnen, zijn in werkelijkheid proces- of ownershipdiscussies. Moet elke site dezelfde goedkeuringsflow volgen? Wie bepaalt de standaard? Welke lokale uitzondering is echt noodzakelijk en welke is vooral gewoonte?

Neem een productiebedrijf met meerdere vestigingen dat kiest voor één template. Tijdens de fit-gap-sessies blijkt dat elke site een eigen manier heeft om voorraad te waarderen of orders vrij te geven. Zolang niemand het mandaat heeft om een standaard op te leggen, groeit het aantal uitzonderingen, en daarmee de scope, de complexiteit en de testinspanning.

Herkenbare signalen

• Het aantal lokale varianten blijft groeien.
• Harmonisatiediscussies worden “voorlopig” opgelost met extra configuratie.
• Het globale template wordt steeds minder globaal.

Wat het kost: scope creep, hogere bouw- en onderhoudskosten en een systeem dat de oorspronkelijke businesscase, vaak net standaardisatie, niet meer waarmaakt.

4. Te veel afhankelijkheden worden te laat zichtbaar

In een ERP-programma hangt alles met alles samen. Datamigratie hangt af van procesdesign. Rollen en autorisaties hangen af van de nieuwe organisatie. Training hangt af van stabiele processen. Interfaces hangen af van beslissingen in andere systemen. Business readiness hangt af van al het voorgaande.

Die afhankelijkheden zijn meestal bekend. Ze worden alleen pas zichtbaar wanneer ze al blokkeren. Eén vertraagde workstream kan zo drie andere stilleggen, terwijl elk team afzonderlijk “volgens planning” werkt.

Herkenbare signalen

• Workstreams rapporteren individueel op groen, maar het geheel schuift op.
• Problemen worden ontdekt tijdens integratietesten in plaats van tijdens design.
• Teams wachten op elkaar zonder dat duidelijk is wie de knoop moet doorhakken.

Wat het kost: een planning die op papier klopt, maar in de praktijk telkens herzien moet worden. Een Gantt-chart toont afhankelijkheden, maar beheert ze niet. Dependency management vraagt actieve coördinatie en beslissingen over workstreams heen.

5. De business heeft onvoldoende capaciteit voor de transformatie

Key users en process owners zijn cruciaal in een ERP-programma. Zij kennen de processen, nemen beslissingen, valideren designs, testen en worden later vaak ambassadeurs op de werkvloer.

Ze doen dat bijna altijd naast hun gewone job. Het maandafsluiten gaat door, de klantenorders moeten buiten en het productieplan moet rond. Wanneer de druk stijgt, verliest het project het bijna altijd van de dagelijkse operatie.

“We hebben er geen tijd voor” klinkt als een praktisch probleem, maar is in werkelijkheid een structureel executierisico.

Herkenbare signalen

• Validatierondes en testcycli lopen systematisch uit.
• Dezelfde handvol mensen zit in elke werkgroep.
• Beslissingen worden gedelegeerd naar mensen zonder mandaat.
• Key users zijn in de laatste fase van het project uitgeput.

Wat het kost: tragere beslissingen, oppervlakkigere testing en een grotere kans op problemen na go-live. Bovendien raken precies de mensen die de verandering moeten dragen overbelast op het moment dat je ze het meest nodig hebt.

6. Adoptie wordt behandeld als iets voor na de technische implementatie

In veel ERP-programma’s staat adoptie aan het einde van de planning: training in de laatste weken, communicatie rond go-live en een hypercare-periode om de ergste problemen op te vangen.

Dat is te laat. Adoptie begint bij design, bij de vraag of een nieuw proces operationeel werkbaar is, of rollen helder zijn en of managers begrijpen wat er van hun teams verwacht wordt.

Go-live is geen bewijs van succes, en deployment is niet hetzelfde als adoption. Wanneer gebruikers het systeem omzeilen, heb je technisch misschien geleverd, maar zakelijk nog niet.

Herkenbare signalen

• Training focust op schermen en klikpaden, niet op de nieuwe manier van werken.
• Nieuwe processen zijn formeel ontworpen, maar nog niet gedragen door de teams die ze moeten uitvoeren.
• Na go-live duiken Excel-bestanden en parallelle registraties op.
• Oude systemen blijven “tijdelijk” beschikbaar, en worden gebruikt.

Wat het kost: shadow processes, onbetrouwbare data, dubbel werk en een businesscase die maanden of jaren achterblijft op de verwachtingen. De time-to-value schuift op, ook al is het project formeel afgerond.

7. Het programma reageert op symptomen in plaats van op de echte bottleneck

Wanneer een ERP-programma vertraagt, volgt vaak een voorspelbare reflex: meer overleg, een nieuwe planning, extra reporting en extra mensen.

Soms helpt dat. Vaak raakt de ingreep alleen het symptoom. Een extra wekelijkse statusmeeting lost een ownershipprobleem niet op. Een nieuwe planning maakt onduidelijke governance niet helderder. Extra capaciteit in het projectteam verandert niets aan het feit dat de business nog niet heeft beslist hoe het proces moet lopen.

Het gevolg is een programma dat harder werkt, maar niet sneller vooruitgaat. En een team dat steeds meer tijd besteedt aan rapporteren over de vertraging dan aan het oplossen ervan.

Herkenbare signalen

• De planning is al meerdere keren herzien, zonder structurele verbetering.
• De reporting groeit, maar het inzicht niet.
• Iedereen heeft een verklaring voor de vertraging, maar niemand dezelfde.

Wat het kost: tijd, budget en geloofwaardigheid. Elke ingreep die de werkelijke oorzaak mist, maakt de volgende moeilijker verkoopbaar bij het management.

Dit brengt ons terug bij de stuurgroepvraag uit de inleiding. Wie een vertraagd ERP-programma wil versnellen, moet blijven doorvragen tot de werkelijke oorzaak op tafel ligt. Diagnose gaat vóór interventie.

Symptoom of oorzaak? Een overzicht

Hoe weet je waar jouw ERP-programma werkelijk vertraagt?

Elk programma is anders, maar de volgende vragen helpen om voorbij de statusrapportering te kijken en de echte bottleneck bloot te leggen. Ze zijn bruikbaar voor een CIO die een programma wil doorlichten én voor een program manager die zijn stuurgroep scherper wil laten sturen.

1. Waar blijven beslissingen vandaag het vaakst hangen? En wie zou ze eigenlijk moeten nemen?
2. Welke beslissingen worden telkens opnieuw besproken? Wat verhindert dat ze definitief worden?
3. Welke workstream veroorzaakt de meeste afhankelijkheden? En wie bewaakt die afhankelijkheden over de teams heen?
4. Welke businessrollen zijn structureel overbelast? Wat gebeurt er met het programma als die mensen uitvallen?
5. Welke processen zijn formeel ontworpen, maar operationeel nog niet gedragen?
6. Waar ontstaan lokale uitzonderingen? Zijn ze echt noodzakelijk of vooral historisch gegroeid?
7. Welke activiteiten staan op groen in de planning, terwijl de business er nog niet klaar voor is?
8. Wat gebeurt er met de businesscase als de go-live drie of zes maanden opschuift? Denk aan extra projectkosten, langer lopend onderhoud van oude systemen, uitgestelde efficiëntiewinsten en extra managementtijd.

Wie die laatste vraag concreet kan beantwoorden, weet meteen hoe urgent het probleem is. Vertraging voelt vaak als een planningskwestie, maar wordt pas echt zichtbaar wanneer je ze uitdrukt in gemiste businesswaarde.

Van go-live naar landing

ERP-projecten zijn en blijven technisch complex. Wie alleen naar de technologie kijkt om vertraging te verklaren, mist vaak de plek waar het programma werkelijk vastloopt: tussen de teams, de beslissingen en de processen die samen moeten bewegen.

Een ERP-implementatie is pas geslaagd wanneer de organisatie er daadwerkelijk anders mee werkt. Dat betekent dat beslissingen sneller vallen, processen gedragen worden en de businesswaarde uit de businesscase ook effectief gerealiseerd wordt.

Bij SiRCLE werken we precies op dat snijvlak tussen strategie en uitvoering. Soms is de eerste stap vooral helderheid: objectief in kaart brengen waar een programma vastloopt, welke executierisico’s spelen en waar prioriteiten moeten liggen. Dat is de insteek van de SiRCLE Ambition Scan. In andere gevallen is de richting duidelijk, maar moet het programma momentum herwinnen door structuur, alignment en besluitvorming te herstellen. Daarvoor is de SiRCLE Acceleration Sprint ontworpen.

Het vertrekpunt is altijd dezelfde vraag:

Wat houdt jullie ERP-programma vandaag tegen om sneller vooruit te gaan?

Wil je die vraag samen scherp krijgen? We brengen graag met je in kaart waar het grootste executierisico zit.

Veelgestelde vragen

Waarom lopen ERP-implementaties vaak vertraging op?
ERP-implementaties vertragen vaak door niet-technische oorzaken: onduidelijke besluitvorming, onvoldoende alignment tussen IT en business, processen die niet geharmoniseerd zijn, afhankelijkheden tussen workstreams, beperkte capaciteit bij key users en te late aandacht voor adoptie. De technologie is complex, maar is zelden de enige verklaring.

Wat is decision latency in een ERP-project?
Decision latency is de tijd tussen het moment waarop een beslissing nodig is en het moment waarop ze effectief genomen wordt. In ERP-programma’s veroorzaakt uitgestelde besluitvorming vaak downstream-vertraging, herwerk en blokkerende afhankelijkheden tussen teams.

Wat is het verschil tussen go-live en adoptie?
Go-live betekent dat het systeem technisch in gebruik is genomen. Adoptie betekent dat de organisatie de nieuwe processen en het systeem ook effectief toepast in haar dagelijkse werking. Een project kan technisch live zijn terwijl gebruikers via Excel of oude systemen blijven werken.

Hoe herken je dat een ERP-programma risico loopt?
Signalen zijn onder meer beslissingen die telkens terugkomen, workstreams die individueel op groen staan terwijl het geheel vertraagt, een groeiend aantal lokale uitzonderingen, testing die systematisch opschuift en key users die structureel overbelast zijn.

Wat doe je als je ERP-project vertraagt?
Begin met een diagnose voordat je extra capaciteit, meetings of een nieuwe planning inzet. Breng in kaart waar beslissingen blijven hangen, welke afhankelijkheden blokkeren en of de business klaar is voor de nieuwe werkwijze. Pas dan kun je gericht ingrijpen op de werkelijke bottleneck.