Je volgende ERP-traject: wat organiseer je deze keer anders?

Bijgewerkt op:

21 August 2026

Een betere ERP-selectie is niet genoeg. Lees wat je vóór, tijdens en na de implementatie anders moet doen om dit keer wel succes te boeken

Je hebt het waarschijnlijk al eens gedaan zoals overal beschreven staat. Er lag een eisenlijst, er waren demo's, en uiteindelijk werd een leverancier gekozen. Op papier klopte het besluit. Toch duurde de implementatie langer dan verwacht, liep het budget op, of leverde het systeem na de livegang minder op dan beloofd.

Grote kans dat de software technisch gezien prima werkte. Maar medewerkers hielden hun spreadsheets aan, rapportages bleven onderwerp van discussie, en voor elke aanpassing was opnieuw een consultant nodig. Het systeem draaide. Je bedrijf werkte alleen niet aantoonbaar beter.

Dan is het verleidelijk om te concluderen dat je deze keer vooral een ander pakket moet kiezen.

Maar de pakketkeuze is maar één besluit binnen een ERP-traject. Onderzoek naar mislukte ERP-implementaties wijst veel vaker op een combinatie van organisatorische factoren: te weinig bestuurlijk eigenaarschap, gebrekkige opleiding, een slechte aansluiting op de strategie, zwakke projectleiding, en gebruikers die het systeem uiteindelijk niet willen gebruiken.

De belangrijkste les van een eerder traject gaat zelden over de software zelf. Vaker gaat het over hoe je het traject organiseert.

Voor wie dit artikel is, en voor wie niet

Kies je voor het eerst een ERP-systeem? Dan hoef je deze lessen gelukkig niet eerst zelf te verdienen. De patronen die voor een ervaren koper herkenbaar zijn, kun jij nog vóór de start doorbreken. Lees dan eerst hoe je het juiste ERP kiest, en gebruik dit artikel als achtergrond voor wat er na de keuze komt.

Dit artikel is wél voor jou als je een eerder traject doorlopen hebt dat niet bracht wat je hoopte, en je dit keer niet alleen een ander pakket wilt, maar vooral een andere uitkomst.

De vorige keer begon het project waarschijnlijk bij de software

Een ERP-traject wordt vaak zichtbaar zodra leveranciers in beeld komen. Vanaf dat moment zijn er concrete producten, demo's, offertes en planningen. Daardoor voelt de selectie als het begin van het project, en de handtekening als de belangrijkste beslissing.

In werkelijkheid begint het traject eerder.

Het begint bij de vraag waarom je bedrijf moet veranderen, welke resultaten je verwacht, en wat daarvoor intern nodig is. Zijn die vragen niet scherp? Dan moet de softwareselectie het gebrek aan richting oplossen. Dan ontstaat een lange lijst met wensen, maar geen gezamenlijk beeld van wat de investering zakelijk moet opleveren.

De implementatiepartner krijgt vervolgens de opdracht om processen uit te vragen en keuzes voor te bereiden. Dat lijkt efficiënt, hij kent het systeem immers het best. Maar kennis van software is iets anders dan verantwoordelijkheid voor jouw strategie. Hebben afdelingen verschillende belangen, dan kan een externe partij niet bepalen welk belang voor je bedrijf zwaarder moet wegen.

De vorige keer begon je mogelijk bij de vraag:

Welk ERP-systeem hebben we nodig?

De volgende keer begin je eerder:

Wat moet er in ons bedrijf veranderen, wie is daarvan eigenaar, en waaraan zien we later dat het is gelukt?

Pas wanneer dat helder is, krijgt de softwarekeuze betekenis. Weet je nog niet zeker of jouw pakketkeuze inhoudelijk verantwoord is? Lees eerst hoe je van het beste naar het juiste ERP komt. Dit artikel gaat over alles wat nodig is om van die keuze ook een goed resultaat te maken.

Een ERP-traject mislukt zelden op één moment

Achteraf zoeken we graag een duidelijk breekpunt. De verkeerde leverancier. Te veel maatwerk. Slechte data. Te weinig training. Weerstand op de werkvloer.

Maar zulke problemen staan zelden los van elkaar. Ze vormen meestal een keten.

Is het bedrijfsdoel niet scherp, dan let je tijdens de selectie vooral op functies. Is niet duidelijk welke processen moeten standaardiseren, dan worden afwijkingen tijdens de implementatie één voor één opgelost, en groeit de scope. Moeten interne mensen het project naast hun gewone werk doen, dan worden beslissingen uitgesteld of bij de implementatiepartner neergelegd. Kennis blijft extern, en gebruikers worden pas betrokken als de belangrijkste keuzes al vaststaan. Na de livegang wordt hun weerstand dan als los probleem behandeld.

Wat aan het eind zichtbaar wordt, is vaak maanden eerder veroorzaakt.

Daarom helpt een opsomming van fouten maar beperkt. Wil je juist die veelgemaakte fouten tijdens de implementatie zelf op een rij zien? Lees dan de 7 valkuilen bij een ERP-implementatie. Dit artikel gaat een laag dieper: niet wát er misgaat, maar hóe je als bedrijf voorkomt dat hetzelfde patroon zich herhaalt.

Begin met een diagnose, niet met een nieuwe shortlist

Heb je een eerder ERP-traject achter de rug? Maak dan eerst een reconstructie. Niet om schuldigen aan te wijzen, maar om het patroon te vinden dat je anders opnieuw meeneemt.

Praat met mensen die het traject vanuit verschillende posities hebben meegemaakt: directie, projectteam, proceseigenaren en dagelijkse gebruikers. Hun verklaringen zullen waarschijnlijk verschillen. Juist dat verschil is waardevol.

Onderzoek onder meer:

Welk bedrijfsprobleem moest de investering oplossen?
Wanneer veranderde of vervaagde dat doel?
Welke aannames uit de selectie bleken later niet te kloppen?
Welke beslissingen konden niet op tijd worden genomen, en waarom?
Waar groeide de scope, en wie overzag de gevolgen?
Welke kennis bleef bij consultants of vertrekkende projectleden?
Wanneer werden gebruikers echt betrokken?
Welke beloofde resultaten zijn na livegang gemeten?

Probeer daarna de eerste oorzaak te benoemen, niet alleen het laatste symptoom.

"Gebruikers werkten buiten het systeem om" is nog geen diagnose. Waarom deden ze dat? Was het proces onwerkbaar, vertrouwden ze de data niet, ontbrak kennis, of stuurden leidinggevenden zelf nog op de oude werkwijze?

"Het project werd te duur" is ook niet genoeg. Ontstonden de kosten door verkeerde aannames, nieuwe wensen, slechte data, onduidelijke verantwoordelijkheden, of een strategische keuze die pas tijdens de inrichting werd gemaakt?

Een bruikbare diagnose eindigt met een organisatorisch gevolg:

Dit was het patroon. Daarom reserveren of besluiten we deze keer iets wezenlijk anders.

De directie steunt het project niet alleen, ze blijft eigenaar

In veel trajecten spreekt de directie bij de start haar steun uit, en draagt daarna de uitvoering over aan IT, finance of een projectleider. Botsen afdelingen, of vraagt de dagelijkse operatie aandacht, dan ontbreekt iemand die bedrijfsbrede keuzes kan afdwingen.

Bestuurlijk eigenaarschap is meer dan enthousiasme, budget goedkeuren of aanschuiven bij een stuurgroep. De directie moet gedurende het traject beslissen wanneer legitieme belangen tegenover elkaar staan.

Bijvoorbeeld:

Kiezen we voor één bedrijfsbrede standaard, of behouden we een lokale uitzondering?
Passen we het proces aan, of investeren we in maatwerk?
Accepteren we vertraging om data eerst op orde te brengen?
Welk werk krijgt tijdelijk minder prioriteit, zodat sleutelmedewerkers echt kunnen deelnemen?
Wanneer is een scopewijziging belangrijk genoeg om extra tijd en geld te rechtvaardigen?

Een implementatiepartner kan de gevolgen uitleggen. Een projectleider kan het besluit voorbereiden. Maar alleen jouw bedrijf zelf kan bepalen welke afweging zakelijk verantwoord is.

De tweede keer regel je daarom meer dan een opdrachtgever op papier: een eigenaar met mandaat, beschikbare tijd, en de bereidheid om te blijven leiden als de keuzes onaangenaam worden.

Interne tijd is onderdeel van de investering

Software, licenties en externe consultants staan zichtbaar in de begroting. De tijd van je eigen mensen vaak niet. Zij moeten workshops bijwonen, data controleren, processen ontwerpen, oplossingen testen en collega's begeleiden, naast hun gewone werk.

Dat leidt tot een voorspelbaar conflict. De operatie vraagt vandaag aandacht, het ERP-project moet morgen resultaat opleveren. Zonder duidelijke prioriteit wint het dagelijkse werk bijna altijd.

De gevolgen verschijnen later: trage besluitvorming, oppervlakkige tests, slecht opgeschoonde data, of een inrichting die vooral door externen is bepaald. Wat eruitziet als een probleem met de implementatiepartner, is in werkelijkheid vaak een tekort aan interne capaciteit.

Reserveer daarom vóór de start niet alleen extern budget, maar ook interne capaciteit. Maak per sleutelrol zichtbaar:

Welke bijdrage tijdens het traject nodig is.
Welke beslissingen deze persoon moet kunnen nemen.
Welk regulier werk tijdelijk wordt overgedragen of uitgesteld.
Wie vervangt bij uitval of vertrek.
Welke kennis na het project intern moet blijven.

Een goed voornemen zonder uren, vervanging of mandaat is geen projectorganisatie.

Laat de implementatiepartner niet als enige jouw belang bewaken

Een professionele implementatiepartner kan onmisbaar zijn. Hij kent de software, heeft vergelijkbare trajecten gezien, en weet welke keuzes later problemen kunnen veroorzaken.

Maar hij blijft ook opdrachtnemer. Extra analyse, maatwerk en langere inzet kunnen nodig zijn, en leveren hem tegelijk omzet op. Dat maakt de partner niet onbetrouwbaar. Het betekent wel dat hij niet de enige bewaker van scope, budget, planning en kwaliteit kan zijn.

Zorg dat iemand vanuit jouw belang het geheel blijft overzien. Dat kan een sterke interne projectleider zijn, of een onafhankelijke externe begeleider. Deze regie verbindt losse besluiten steeds opnieuw aan het bedrijfsdoel waarmee je begon.

Voor elke belangrijke wijziging moet duidelijk zijn:

Welk probleem ze oplost.
Waarom dit probleem niet binnen de afgesproken werkwijze kan worden opgelost.
Wat de wijziging betekent voor kosten, planning, beheer en toekomstige updates.
Welk ander onderdeel eventueel vervalt of wordt uitgesteld.
Wie het resterende risico accepteert.

Zo voorkom je niet elke scopewijziging. Dat hoeft ook niet. Je voorkomt vooral dat tientallen los verdedigbare besluiten samen een project opleveren dat niemand bewust heeft gekozen.

Lees meer over onafhankelijke regie tijdens een ERP-implementatie.

Kennisoverdracht begint vóór de training

Bij kennisoverdracht denken bedrijven vaak aan eindgebruikerstraining vlak voor de livegang. Medewerkers leren in welke schermen ze moeten werken, en hoe ze hun dagelijkse taken uitvoeren.

Dat is nodig, maar te laat en te beperkt.

Tijdens de analyse en inrichting wordt voortdurend kennis uitgewisseld. Medewerkers leggen uit hoe het bedrijf werkelijk werkt, inclusief uitzonderingen die nergens zijn beschreven. Consultants vertalen die werkelijkheid naar systeemkeuzes. Blijft die uitwisseling eenrichtingsverkeer, dan begrijpt de consultant je bedrijf uiteindelijk beter dan je bedrijf zijn eigen ERP-inrichting begrijpt.

Dan ontstaat na de livegang afhankelijkheid. Bij een afwijking, nieuwe rapportage of proceswijziging moet steeds dezelfde externe partij terugkomen. Meestal ligt dat niet aan de complexiteit van het systeem, maar aan de kennis die nooit intern is geland.

Organiseer leren daarom gedurende het hele traject:

Laat proceseigenaren meebeslissen over de inrichting, en de afwegingen daarachter begrijpen.
Leg belangrijke keuzes en uitzonderingen vast in taal die gebruikers herkennen.
Laat interne beheerders al tijdens de bouw meekijken en oefenen.
Gebruik tests niet alleen om fouten te vinden, maar ook om kennis op te bouwen.
Bepaal welke vragen je bedrijf na livegang zelfstandig moet kunnen beantwoorden.

Een goede implementatie levert meer op dan werkende software. Ze maakt je bedrijf bekwamer dan het was vóór het project.

Behandel gebruikersweerstand als informatie

Willen medewerkers niet met het nieuwe systeem werken, dan wordt al snel gesproken over weerstand tegen verandering. Soms speelt onbekendheid inderdaad een rol. Maar weerstand kan ook informatie bevatten over eerdere keuzes.

Misschien vraagt de nieuwe werkwijze meer handelingen zonder zichtbaar voordeel. Misschien verdwijnt informatie die iemand nodig heeft om verantwoordelijkheid te nemen. Misschien zijn uitzonderingen uit de dagelijkse praktijk tijdens het ontwerp genegeerd. Of leidinggevenden vragen om nieuw gedrag, terwijl ze zelf op de oude rapportages blijven sturen.

Gebruikers leveren zo meer dan draagvlak: ze leveren kennis die het systeem beter maakt.

Dat betekent niet dat elke wens wordt overgenomen, of dat elke medewerker over het pakket beslist. Wel dat representatieve gebruikers:

praktijkscenario's helpen opstellen;
de voorgestelde werkwijze daadwerkelijk uitvoeren;
laten zien waar de praktijk afwijkt van het procesmodel;
tijd krijgen om te leren en feedback te verwerken;
begrijpen welk probleem de verandering voor het bedrijf oplost.

Adoptie is dan geen eindfase, maar een maatstaf die vanaf het begin meeloopt met elke beslissing.

Livegang is niet hetzelfde als succes

De livegang is zichtbaar, spannend en makkelijk te plannen. Daardoor wordt ze vaak het natuurlijke eindpunt van het project. Lopen transacties eenmaal door het nieuwe systeem, dan wordt het team afgebouwd, en verschuift de aandacht terug naar de operatie.

Maar technisch gebruik bewijst nog niet dat de investering haar doel bereikt.

Definieer succes daarom vooraf op drie niveaus:

Projectresultaat: de afgesproken oplossing is binnen bewust geaccepteerde kaders opgeleverd.
Gebruik: medewerkers kunnen en willen de nieuwe processen zelfstandig uitvoeren.
Bedrijfsresultaat: de oorspronkelijke verbetering in bijvoorbeeld leverbetrouwbaarheid, voorraad, doorlooptijd of informatiekwaliteit wordt zichtbaar.

Het derde niveau vraagt om metingen na de livegang. Niet alleen in de eerste weken, wanneer kinderziektes centraal staan, maar ook na drie, zes en twaalf maanden.

Welke noodoplossingen bestaan nog? Welke functionaliteit wordt niet gebruikt? Zijn doorlooptijden echt korter? Worden beslissingen op betere informatie genomen? Is de afhankelijkheid van externe ondersteuning afgenomen?

Blijft niemand verantwoordelijk voor die vragen, dan wordt "het systeem draait" vanzelf de definitie van succes. Daarmee verdwijnt precies de belofte waarmee het traject ooit begon.

Wat organiseer je deze keer anders?

Een goed voornemen om zorgvuldiger te werken is daarvoor niet genoeg. Een volgend ERP-traject wordt beter wanneer lessen worden vertaald naar tijd, mandaat, verantwoordelijkheden en meetbare afspraken.

Leg vóór de start op één pagina vast:

Welk bedrijfsresultaat het traject moet opleveren.
Welk patroon uit een eerder traject zich niet mag herhalen.
Wie bestuurlijk eigenaar is van bedrijfsbrede keuzes.
Welke interne capaciteit daadwerkelijk wordt vrijgemaakt.
Wie onafhankelijk scope, budget en planning bewaakt.
Welke kennis na afloop aantoonbaar intern aanwezig moet zijn.
Hoe gebruikers tijdens ontwerp en tests invloed krijgen.
Wat na drie, zes en twaalf maanden wordt gemeten.

Dat is geen implementatiechecklist. Het is de organisatorische afspraak waarop directie, projectteam en partners elkaar gedurende het traject kunnen aanspreken.

Zoals André Maes, Finance Manager bij PlastChem, het verwoordde:

"Ons vorige ERP-traject hebben we destijds te snel doorlopen, en dat hebben we jarenlang in het dagelijks gebruik gevoeld. Dit keer nemen we bewust de tijd: eerst grondig selecteren, dan pas implementeren. En we kijken minstens zo kritisch naar de partij die het gaat bouwen als naar het pakket zelf."

De tweede keer kies je misschien andere software. Maar dat is niet de belangrijkste verandering.

De belangrijkste verandering is dat je het ERP-project niet langer behandelt als iets wat een leverancier voor je implementeert. Het is een verandering van je eigen bedrijf, waarvan je zelf eigenaar blijft, vóór de selectie, tijdens de inrichting, en lang nadat het systeem live is gegaan.

Wil je eerst onafhankelijk vaststellen waar jouw grootste risico zit?

Ik denk met je mee, zonder belang bij welk pakket of welke partner je kiest. Ik ontvang geen commissie van softwareleveranciers of implementatiepartners. Soms leidt dat tot een andere keuze. Soms tot een andere projectaanpak. En soms is het beste advies om nog niet te beginnen.

Plan onafhankelijk advies — 30 minuten, gratis, direct met Dennis.

Wil je eerst zelf checken of je bedrijf er klaar voor is? Doe de Software Gereedheidscheck.

Veelgestelde vragen

Waar kan ik dat onderzoek vinden over de oorzaak van gefaalde ERP trajecten?

Dit is de bron:Rajapakse, D.P.P.K. & Thushara, S.C. (2023). Critical Failure Factors in ERP Implementation: A Systematic Literature Review. Journal of Business and Technology, 7(1), 65–90. https://doi.org/10.4038/jbt.v7i1.109

Moeten we dit keer per se een ander pakket kiezen?

Niet per se. Uit de diagnose van je vorige traject blijkt vaak dat de organisatie eromheen meer bepalend was dan de software zelf. Soms is hetzelfde type pakket met een andere aanpak en een andere partner de betere keuze.

Wat als de directie het vorige traject niet als mislukt beschouwt?

Dat overkomt je vaker dan je denkt, vooral als het systeem technisch wel draait. Leg dan niet de nadruk op "mislukt", maar op concrete signalen: functionaliteit die niemand gebruikt, rapportages die nog steeds los in Excel worden gebouwd, of terugkerende afhankelijkheid van een externe partij. Die signalen overtuigen sneller dan een oordeel.

Hoeveel tijd moeten we reserveren voor de diagnose van het vorige traject?

Reken op enkele gesprekken van een uur met mensen uit verschillende posities: directie, projectteam, proceseigenaren, gebruikers. Een paar weken is meestal genoeg om het patroon boven tafel te krijgen, mits je er niet mee wacht tot de volgende selectie al loopt.

Is interne regie voldoende, of hebben we ook externe onafhankelijke ondersteuning nodig?

Dat hangt af van of er intern iemand is met zowel mandaat als tijd, én zonder belang bij een specifieke uitkomst. Ontbreekt een van die twee, dan is externe, onafhankelijke regie vaak goedkoper dan de kosten van een tweede misser.