Meerwerk bij uw ERP-implementatie: wie beoordeelt of een wijziging echt buiten scope valt?

Neem een donderdagochtend bij een productiebedrijf. Een projectleider leest het zevende wijzigingsvoorstel van dit kwartaal: een aanpassing in de orderafhandeling, met een raming in uren en vier regels toelichting.

Hij moet er iets van vinden. Het enige waarop hij dat kan baseren is de toelichting van de partij die het voorstel heeft geschreven. Om elf uur gaat het stuk door naar zijn financieel directeur, met zijn akkoord eronder, en zij tekent.

Wat hier ontbreekt is een tweede lezing van hetzelfde voorstel, door iemand van buiten het bouwteam. Bij de trajecten waar wij later binnenkomen, ontbreekt die tweede lezing vaak zonder dat iemand haar bewust heeft weggelaten.

Wij schreven eerder over de vraag wie de voortgang van een implementatie beoordeelt, in onafhankelijke ERP-regie. Dit artikel gaat over één beslismoment daarbinnen, dat in de trajecten die wij begeleiden telkens terugkeert: het wijzigingsvoorstel dat op tafel komt en getekend moet worden. Wij komen ze tegen bij programma’s waarin wij de regie voeren en bij trajecten waarin wij de implementatie zelf begeleiden.

Wie het oordeel geeft, bepaalt de rekening

Meerwerk bij een ERP-implementatie is elk werk dat buiten de vastgelegde afspraak valt en apart in rekening wordt gebracht. Wie die grens vaststelt, heeft daarmee invloed op wat uw project uiteindelijk kost.

In de voorstellen die wij lezen, liggen drie oordelen bij elkaar: iemand classificeert (valt dit binnen de afspraak?), iemand raamt (hoeveel werk zit hierin?) en iemand prioriteert (moet dit nu, of kan het na go-live?). In vrijwel elk traject dat wij zien, is dat drie keer dezelfde partij, en dat is de partij die de wijziging vervolgens bouwt en factureert.

Daar zit geen kwade opzet achter. In de trajecten die wij tegenkomen, heeft vaak alleen de implementatiepartner het contract, het functioneel ontwerp en de openstaande backlog samen gelezen, en daarmee is hij vaak de enige aan tafel die de vraag onderbouwd kan beantwoorden.

Wat dan ontbreekt is een vergelijkingsbasis. Voor deze wijziging in dit systeem kan in de praktijk vaak alleen de bouwende partij op korte termijn leveren; een derde partij moet zich eerst inlezen.

Heeft u een eigen ontwikkelteam, een tweede leverancier in hetzelfde landschap of een architect die het ontwerp kent, dan ligt dat anders en is dit knelpunt een stuk kleiner. Waar die tegenkracht ontbreekt, koopt u bij elk voorstel een oordeel: over de omvang van het werk, over de vraag wie het risico van de ontwerpfase draagt, en over urgentie.

Wanneer die drie oordelen structureel van één kant komen, verschuift uw projectbegroting van een plan naar een uitkomst. Dat is een ander soort risico dan een te lage inschatting vooraf, en het vraagt om een andere maatregel: een tegenkracht op het oordeel zelf.

Het organiseren daarvan is een vak apart, ondergebracht bij program governance en assurance. Ligt er nu een voorstel waarover u twijfelt, dan kijken wij daar vrijblijvend met u naar; onze contactgegevens staan onder aan deze pagina.

Waaraan u ziet dat ingrijpen nodig is

Er zijn momenten in een lopend traject waarop het loont om het beoordelingsproces zelf tegen het licht te houden.

Kijk eerst naar uw eigen voortgangsrapportage. Staan alle wijzigingen daar samengevat als één cumulatief bedrag dat uw stuurgroep bij uitzondering bespreekt, dan loopt het aantal getekende voorstellen op zonder dat iemand de optelsom maakt. Zo ontstaat een besluit dat nergens integraal is afgewogen, opgebouwd uit voorstellen die stuk voor stuk klein genoeg leken. Dit is de waarneming die wij in onze praktijk het vaakst tegenkomen.

Eind 2026 valt dat nakijken bovendien samen met de begrotingsronde voor volgend jaar. Wat u dit najaar aan meerwerk tekent, staat straks in de cijfers waarop u 2027 plant.

Stel uw projectleider daarna één vraag: waarom was het vorige voorstel meerwerk? Komt het antwoord neer op een verwijzing naar wat de leverancier heeft toegelicht, dan is de classificatie in de praktijk uitbesteed. Dat zegt vooral iets over de positie waarin uw projectleider zit, alleen tegenover een team dat dit systeem dagelijks bouwt.

Let ten slotte op de toon van het overleg. Zodra gesprekken over wijzigingen ongemakkelijk worden en er woorden vallen over vertrouwen en samenwerking, gaat het naar onze ervaring al niet meer over de scopegrens zelf. Dat wijst er meestal op dat de grens zelf nooit scherp is vastgelegd. Partijen onderhandelen dan over een tekst die twee lezingen toelaat, en ondertussen loopt de bouw door.

De meerwerktoets: vier knooppunten voordat u tekent

Loop elk voorstel langs de vier knooppunten hieronder. Knooppunt 1 en 2 leiden tot een voorlopige indeling, knooppunt 3 toetst die indeling en gaat bij tegenspraak voor, en knooppunt 4 geldt bij elke uitkomst. Elk voorstel doorloopt dus altijd knooppunt 3 en 4. De toets is bedoeld voor uw eigen team en hoort thuis vóór het gesprek met uw leverancier. Naast dit beslismoment staat ons eerdere artikel over scope creep.

Knooppunt 1: staat dit werk al in de afspraak? Leg het voorstel naast de brondocumenten waarnaar uw contract verwijst: het functioneel ontwerp, de bijlage bij de offerte, het programma van eisen.

Staat het werk daar in herkenbare bewoordingen, dan is uw voorlopige indeling nakoming; ga door naar knooppunt 3. Vindt u niets, of laat de tekst twee lezingen toe, ga dan naar knooppunt 2. Noteer in beide gevallen welk document u heeft geraadpleegd, want die notitie is bij het volgende voorstel uw vertrekpunt.

Knooppunt 2: is uw proces veranderd, of is het beeld ervan veranderd? Een proces dat sinds de contractering werkelijk is gewijzigd, levert als voorlopige indeling meerwerk op. Is het proces onveranderd gebleven en pas nu goed begrepen, dan ligt er een andere vraag: wie droeg het risico van de ontwerpfase?

Die vraag hoort thuis bij de partij die het ontwerp heeft gemaakt en die daarvoor is betaald. Het antwoord kan alsnog zijn dat u betaalt, en dan is dat een keuze die u met open ogen maakt. Ga daarna in beide gevallen door naar knooppunt 3.

Knooppunt 3: wat verdwijnt er als u nee zegt? Dit knooppunt toetst de voorlopige indeling uit knooppunt 1 of 2 en gaat bij tegenspraak voor.

Valt er bij een nee een functie weg die in uw brondocumenten staat beschreven, dan is het nakoming, ook wanneer knooppunt 2 naar een gewijzigd proces wees. Blijft de afspraak overeind en werken uw mensen op dit punt gewoon door zoals ze gewend waren, dan ligt er een wens met een eigen business case. Die business case mag u opvragen in uw eigen termen: hoeveel werk scheelt het, voor hoeveel mensen, hoe vaak per week.

Knooppunt 4: wie draagt dit over een jaar? Ook nakoming levert configuratie of maatwerk op, en daarom hoort dit knooppunt bij elke uitkomst. Iemand onderhoudt dat, test het bij elke release opnieuw en legt het vast voor zijn opvolger.

Heeft niemand uit uw beheerorganisatie het voorstel gezien, dan is het besluit onvolledig, hoe redelijk de raming ook oogt. Dit knooppunt wordt in onze ervaring vaker overgeslagen dan de drie ervoor, en het is als enige nog jaren na go-live zichtbaar op uw beheerbegroting.

Wat u vooraf vastlegt, en welke discussie dat later voorkomt

Het beoordelingsproces zelf regelt u het beste voordat de bouw begint. Zes afspraken maken later het verschil, en ze passen alle zes op één A4.

Afspraak die u vóór de bouwfase maakt	Welke discussie dat later voorkomt
Een definitie van “binnen scope”, met de brondocumenten bij naam genoemd en op volgorde van rangorde	Onderhandelen achteraf over welk document leidend is
Een maximale doorlooptijd voor de beoordeling van een wijzigingsvoorstel	Voorstellen die weken blijven liggen en op de werkvloer met omwegen worden opgevangen
Een afgesproken ramingssystematiek: welke rollen, welk tarief, en hoe een raming wordt onderbouwd	Praten over uren op het moment dat u geen alternatieve leverancier meer heeft
Een bedragdrempel waarboven een voorstel naar de stuurgroep gaat, plus een maandelijkse optelsom van alles eronder	Vijftien kleine goedkeuringen die samen nooit zijn afgewogen
Een tweede lezing van elk voorstel door iemand zonder bouwbelang	Een classificatie die alleen door de bouwende partij is gemaakt
Een verplichte beheerparagraaf bij elk voorstel: wie onderhoudt dit, en wat kost dat per jaar	Maatwerk dat pas na go-live een eigenaar en een testlast blijkt te hebben

Partners die wij hierover spreken, zien deze afspraken zelden als wantrouwen; ze halen de discussie weg bij het moment waarop de druk het hoogst is. Bij trajecten waarin de samenwerking onder spanning kwam te staan, zien wij vooral afspraken die nooit zijn gemaakt. Een traject waarin op tijd is bijgestuurd, beschrijven wij in de case study over Different Doors.

Wanneer een onafhankelijke toets weinig toevoegt

Er zijn situaties waarin deze hele beweging overbodig is, en die horen er eerlijk bij.

Bij een korte implementatie met een werkelijk gesloten scope en een vaste prijs, waarbij het aantal wijzigingen op één hand te tellen is, weegt de organisatie van een tweede lezing niet op tegen de opbrengst.

Datzelfde geldt als u zelf een projectleider in dienst heeft die het contract, het ontwerp en de bouwpraktijk goed genoeg kent om een raming te weerspreken, en die daarvoor de ruimte en de rugdekking krijgt. Die rol is dan al belegd.

Ook wanneer uw partner uit zichzelf met een transparante ramingssystematiek werkt, elke wijziging voorziet van een beheerparagraaf en een eigen kwaliteitsrol buiten het bouwteam heeft belegd, voegt een externe toets weinig toe. Een steekproef is dan genoeg: laat twee of drie afgeronde voorstellen achteraf tegenlezen. Dat geeft geen zekerheid over het hele proces, wel een eerste indicatie.

Waarom wij dit oordeel niet bij de bouwer laten liggen

De projectleider die op vrijdagmiddag tegenover drie consultants moet zeggen dat iets erbij hoorde, doet dat in zijn eentje. Hij heeft een vermoeden en niemand die het met hem nakijkt. Mensenwerk betekent voor ons dat wij naast die persoon gaan zitten, met iemand die het dossier net zo goed leest.

Onafhankelijkheid maakt dat mogelijk, en u moet haar kunnen narekenen. Wij verkopen advies, specialistische capaciteit en implementatiebegeleiding. Softwarelicenties zitten daar niet bij, en op geen van de platformen waarmee wij werken (Dynamics 365, S/4HANA, AFAS, Exact, Oracle) hebben wij een partnercertificering te verdedigen die in een oordeel zou meewegen.

Een oordeel over de scopegrens is alleen iets waard wanneer degene die het uitspreekt geen belang heeft bij de uitkomst ervan.

Die tweede lezer moet wel iets kennen dat u zelf niet in huis heeft: de gewoonten van dit ene softwarelandschap, en wat daarin doorgaans binnen de standaardlevering valt. Ons netwerk van specialisten maakt het mogelijk om zo iemand vrij te maken zonder dat u er een vaste rol voor hoeft in te richten.

Wij noemen daar vooraf geen bedrag bij. Wat u eraan heeft is de mogelijkheid om zelf te beslissen, met dezelfde informatie als de partij aan de andere kant van de tafel.

Uw eigen dossier als vertrekpunt

Pak de laatste tien voorstellen uit uw traject erbij en loop ze langs de vier knooppunten. Dat kunt u zelf, en in onze ervaring komen organisaties daar een heel eind mee.

Loopt u vast op een voorstel waarvan twee lezingen mogelijk zijn, dan lezen wij mee. Dat kan met het hele dossier en het kan met dat ene voorstel; u bepaalt wat er op tafel komt. Wat u van ons hoort is per voorstel een indeling met de onderbouwing erbij, en waar wij twijfelen zeggen wij dat ook.

Zit u nog niet zo ver en wilt u alleen toetsen of u het goed ziet, dan is een mailtje genoeg, zonder dossier en zonder verplichting tot een vervolg.

Veelgestelde vragen over meerwerk bij een ERP-implementatie

Wat is meerwerk bij een ERP-implementatie?

Meerwerk bij een ERP-implementatie is elk werk dat buiten de vastgelegde afspraak valt en daarom apart in rekening wordt gebracht, zoals een extra koppeling, een aangepast rapport of een processtap die in het ontwerp ontbrak.

Wij trekken die grens bij de brondocumenten waarnaar uw contract verwijst. Werk dat daarin herkenbaar staat beschreven, lezen wij als nakoming van de afspraak.

Wie bepaalt of een wijziging binnen de scope van een ERP-project valt?

Formeel bepaalt uw contract wie dat doet, en in de trajecten die wij zien beoordeelt de implementatiepartner het, omdat die het contract, het ontwerp en de backlog samen heeft gelezen.

Beleg daarom een tweede lezing bij iemand die de wijziging niet gaat bouwen. Dat kan uw eigen projectleider zijn, mits die de ruimte krijgt om een raming te weerspreken.

Hoe voorkomt u budgetoverschrijding door meerwerk in een ERP-traject?

Spreek vóór de bouwfase af hoe een wijzigingsvoorstel wordt geclassificeerd, geraamd en goedgekeurd, en maak maandelijks de optelsom van alle goedkeuringen onder de stuurgroepdrempel.

In onze ervaring blijven losse voorstellen binnen het mandaat en ontstaat de overschrijding pas in de optelsom van al die goedkeuringen.

Wanneer valt een wijziging onder nakoming van de afspraak?

Wij lezen een wijziging als nakoming zodra het systeem zonder die wijziging niet doet wat in het functioneel ontwerp of de contractbijlage staat beschreven. De leverancier levert dan alsnog wat al was afgesproken.

Twijfelt u, stel dan de omgekeerde vraag: wat gebeurt er als u nee zegt? Valt er een afgesproken functie weg, dan gaat het om nakoming.