ERP-implementatie
Een ERP-implementatie is het traject waarin een gekozen systeem wordt ingericht, gekoppeld, gevuld met uw gegevens en in gebruik genomen. De techniek is zelden waar het misgaat.
Uit welke fasen het bestaat
Wie waarover beslist
Waar het onomkeerbaar wordt
Wat is een ERP-implementatie?
Een ERP-implementatie is het traject waarin een gekozen systeem wordt ingericht op uw processen, gekoppeld aan uw andere software, gevuld met uw gegevens en in gebruik genomen door uw mensen. Het begint na de keuze en het eindigt niet bij livegang.
Het onderscheid met de selectie is scherp: bij een selectie kiest u wat u koopt, bij een implementatie bepaalt u wat u ermee doet. De tweede vraag kost meer tijd, meer geld en meer aandacht van uw eigen mensen dan de eerste.
Dat het zelden op techniek misgaat, is te zien in de cijfers. In het ERP-onderzoek van Panorama Consulting uit 2026 meldt bijna een kwart van de organisaties een overschrijding van de planning, en de meest genoemde oorzaak waren organisatorische zaken: besluitvorming, weerstand tegen verandering en procesherinrichting.
Een implementatie is geen ICT-project met een bedrijfskundig randje.
Het is een reeks bedrijfsbesluiten die toevallig in software worden vastgelegd. Welk proces verandert, welke uitzondering vervalt, wie de nieuwe cijfers mag zien: dat zijn geen technische vragen, en ze zijn ook niet aan uw leverancier.
Uit welke fasen bestaat een ERP-implementatie?
Vijf fasen, in deze volgorde. De namen verschillen per leverancier, de inhoud niet. Bij elke fase staat waar het in de praktijk misgaat, want dat is bruikbaarder dan een opsomming van activiteiten.
Per fase, en waar het misgaat
| Fase | Wat er gebeurt | Waar het misgaat |
|---|---|---|
| Voorbereiding | Scope, planning en bezetting worden vastgelegd. De stuurgroep komt voor het eerst bij elkaar. | De bezetting staat op rollen en niet op namen. Wie het echt gaat doen, blijkt pas als het traject loopt. |
| Ontwerp | Uw processen worden naast de standaard van het systeem gelegd. Hier valt het besluit wat u aanpast en wat u laat bouwen. | Elke uitzondering wordt overgenomen in plaats van bevraagd. Zo groeit maatwerk voordat er een regel code is geschreven. |
| Bouw en inrichting | Het systeem wordt ingericht, koppelingen worden gelegd en gegevens worden voorbereid op de overzetting. | Datakwaliteit blijkt slechter dan gedacht. Opschonen is uw werk, niet dat van de partner, en dat komt zelden vroeg genoeg op de planning. |
| Testen | Sleutelgebruikers lopen hun eigen werk door in het nieuwe systeem, inclusief de maandafsluiting. | Er wordt getest op wat gebouwd is in plaats van op hoe uw mensen werken. Uitzonderingen komen dan pas na livegang boven. |
| Livegang en nazorg | Het oude systeem gaat uit, het nieuwe aan. Daarna volgt de periode waarin het echte gebruik de restpunten oplevert. | De nazorg is niet belegd. De partner schaalt af terwijl uw mensen de vragen juist dan krijgen. |
De fasen lopen in de praktijk door elkaar heen, zeker bij een uitrol per vestiging of per onderdeel. De volgorde van de besluiten blijft wel staan: ontwerpen gaat voor bouwen, en testen gaat voor livegang.
Wie beslist waarover?
De rolverdeling staat zelden op papier, en juist daar ontstaan de conflicten. Vijf rollen, met per rol het besluit dat er hoort en de valkuil die erbij hoort.
Rollen en besluiten
| Rol | Beslist over | De valkuil |
|---|---|---|
| Opdrachtgever | Doel, budget en de vraag of het traject doorgaat bij tegenslag. | Alleen aanschuiven bij de stuurgroep. Dan wordt de scope in de projectgroep bepaald, buiten het zicht van wie hem betaalt. |
| Projectleider aan uw kant | Voortgang, escalatie en de dagelijkse afweging tussen tijd, scope en kwaliteit. | Iemand met een volle eigen baan erbij. De rol vraagt aandacht op de dagen dat het knelt, niet op de dagen dat het schikt. |
| Proceseigenaar | Welk proces verandert en welke uitzondering vervalt. | Niet benoemd, waardoor niemand nee mag zeggen tegen een uitzondering. Elke afwijking wordt dan maatwerk. |
| Sleutelgebruiker | Of het gebouwde werkt zoals er echt gewerkt wordt. | Wordt pas bij het testen betrokken. Dan is het ontwerp al vast en is elk bezwaar een wijziging. |
| Implementatiepartner | Hoe het systeem wordt ingericht binnen wat u besluit. | Krijgt besluiten in de schoot geworpen die van u zijn. Wie dat laat gebeuren, kiest bij elke twijfel meerwerk. |
Op welke momenten wordt een besluit onomkeerbaar?
Vier momenten waarop iets vastligt dat u later alleen met kosten terugdraait. Bij elk moment staat de vraag die u dan hardop moet stellen.
Bij de scope, voor de start
Wat er wel en niet in dit traject zit, en welke vestiging of welk onderdeel later volgt. Dit bepaalt de planning meer dan de techniek.
Wat gebeurt er met dit traject als het volgende onderdeel over een jaar aansluit?
Bij elke afwijking van de standaard
Elke keer dat u een uitzondering laat bouwen in plaats van hem af te schaffen, koopt u die uitzondering opnieuw bij elke grote bijwerking.
Wat kost het ons als we dit proces aanpassen aan het systeem in plaats van andersom?
Bij de gegevensoverzetting
Welke historie meegaat en in welke vorm. Vervuilde gegevens blijven vervuild na migratie, en opschonen achteraf is duurder dan vooraf.
Wie is eigenaar van deze gegevens, en wie zegt of ze goed genoeg zijn?
Bij het besluit om live te gaan
Livegang met bekende restpunten kan verstandig zijn, maar alleen als vastligt wie ze oplost en wanneer. Anders verdwijnen ze in de waan van de dag.
Welke restpunten accepteren we, en op welke datum zijn ze weg?
Waar lopen implementaties vast?
Vijf patronen die terugkeren, ongeacht sector of systeem. Ze zijn geen van alle technisch, en ze zijn alle vijf vroeg te zien.
De bezetting staat op rollen, niet op namen
Een plan met rollen leest prettig en zegt niets. Pas als er namen staan, met een aantal dagen per week erbij, blijkt of het traject bemand is.
Vraag namen voor de handtekening, niet erna.
Uitzonderingen worden overgenomen in plaats van bevraagd
Elke afdeling heeft een reden waarom het bij hen anders moet. Wie die redenen niet toetst, bouwt het oude proces na in nieuwe software.
Een uitzondering die niemand kan uitleggen, is een gewoonte.
Datakwaliteit komt te laat op de planning
Opschonen is uw werk en het kost meer tijd dan iedereen denkt. Het staat vaak pas op de planning als de bouw al loopt.
Begin met opschonen voordat u weet welk systeem het wordt.
Er wordt getest op het gebouwde, niet op het werk
Een test die de specificatie volgt, bevestigt de specificatie. Alleen uw eigen orders en uw eigen maandafsluiting laten zien wat er ontbreekt.
Test op uw lastigste week, niet op een schoon voorbeeld.
Het slechte nieuws komt te laat boven
Wie de voortgang rapporteert is meestal ook de partij die de vertraging veroorzaakt. Dat is geen kwade wil, het is een rolconflict.
Laat de voortgang beoordelen door iemand die niet meebouwt.
Verdieping per onderwerp
Twee besluiten liggen voor de implementatie en bepalen hoe die verloopt. Ze hebben allebei een eigen pagina.
De implementatiepartner
Welke soorten partijen er zijn, waar hun belang ligt, wat van u blijft en hoe u een kandidaat toetst voordat u tekent.
Lees over de partnerkeuzeHet systeem zelf
Welke soorten ERP-systemen er zijn, wat u per sector tegenkomt, en waarin ze werkelijk van elkaar verschillen.
Lees over de systeemkeuzeVeelgestelde vragen
- Wat is een ERP-implementatie?
Een ERP-implementatie is het traject waarin een gekozen systeem wordt ingericht op uw processen, gekoppeld aan uw andere software, gevuld met uw gegevens en in gebruik genomen door uw mensen.
Het begint na de keuze en het eindigt niet bij livegang. De periode erna levert de restpunten op die het echte gebruik zichtbaar maakt.
- Hoe lang duurt een ERP-implementatie?
Dat hangt af van uw omvang, het aantal vestigingen en hoeveel er buiten de standaard valt. In het ERP-onderzoek van Panorama Consulting uit 2026 was de mediane doorlooptijd negen maanden.
Die mediaan komt uit een internationaal onderzoek onder relatief grote organisaties, dus het is een ordegrootte en geen norm. De spreiding eromheen is groot.
- Wat is het verschil tussen een ERP-selectie en een ERP-implementatie?
Bij een selectie kiest u wat u koopt. Bij een implementatie bepaalt u wat u ermee doet: welk proces verandert, welke uitzondering vervalt en wie waarover beslist.
De tweede vraag kost meer tijd en meer aandacht van uw eigen mensen dan de eerste, terwijl de meeste voorbereiding in de eerste gaat zitten.
- Wie is verantwoordelijk voor een ERP-implementatie?
De opdrachtgever blijft verantwoordelijk voor doel, budget en de besluiten over processen. De partner is verantwoordelijk voor de inrichting binnen die besluiten.
Die grens staat zelden in de offerte, en juist daar ontstaan de conflicten. Spreek hem uit voordat u tekent.
- Waarom lopen ERP-implementaties vast?
Zelden op techniek. De terugkerende oorzaken zijn een bezetting die alleen op papier bestaat, uitzonderingen die niemand bevraagt, datakwaliteit die te laat op de planning komt en voortgang die wordt beoordeeld door de partij die bouwt.
Alle vier zijn ze vroeg te zien, mits iemand de vraag stelt. Dat is precies de reden om de beoordeling los te trekken van de uitvoering.
Verder lezen
Deze pagina beschrijft de fasen, de rollen en de beslismomenten. De artikelen hieronder gaan dieper in op de uitvoering.
- Stappenplan van kickoff tot livegang
- Uitbesteden of zelf doen?
- Uw gegevens klaarmaken voor de overzetting
- Medewerkers meekrijgen voor de livegang
- Klaar om live te gaan, of nog niet
- Waarom de partij die bouwt niet ook de voortgang beoordeelt
Deze pagina is voor het laatst nagelopen op 3 september 2026.
Een implementatie laten bewaken
Wij zitten aan uw kant van de tafel: wij bouwen niet mee en hebben geen binding met leveranciers. Daardoor kunnen wij de voortgang beoordelen zonder belang bij de uitkomst.
Waarmee wij helpen
- De rolverdeling uitspreken voordat u tekent
- Meelezen op ontwerpkeuzes die maatwerk veroorzaken
- De voortgang beoordelen los van de partij die bouwt