ERP-updates testen na go-live: wie accepteert de wijziging die u niet zelf hebt besteld?
Een scenario dat wij in verschillende gedaanten tegenkomen. Op een dinsdagochtend loopt de orderverwerking bij een groothandel achter. Een veld dat vrijdag nog vanzelf werd gevuld, blijft leeg. De teamleider belt de key user, de key user belt beheer, en beheer ontdekt dat de leverancier in het weekend een nieuwe versie heeft doorgezet.
Iedereen doet vervolgens keurig zijn werk. Beheer draait de instelling terug, de teamleider herplant de ochtend, en tegen elven loopt alles weer. De vraag die blijft hangen, is wie die versie vooraf had moeten bekijken. Dat is precies waar ons werk aan testmanagement en kwaliteitsborging begint, en het is een vraag die u vandaag zelf kunt stellen.
Acceptatie is een gewoonte, en gewoontes hebben een eigenaar
Een release accepteren is een besluit over uw bedrijfsvoering, genomen op het moment dat een wijziging naar productie mag. Dat besluit valt elke keer, ook wanneer niemand het bewust neemt. Waar het nergens is belegd, zien wij het in de praktijk terechtkomen bij de partij die de wijziging heeft gemaakt.
In ERP-governance na go-live werkten wij de wijzigingen uit die uw eigen organisatie aanvraagt, en wie daar ja tegen mag zeggen. Dit artikel behandelt de tweede stroom: wijzigingen die van buiten binnenkomen, op een moment dat u zelf niet kiest.
Wie bepaalt wanneer uw ERP verandert
Wij zien bij onze klanten dat het releaseritme bij cloud-ERP aan de kant van de leverancier ligt. Oracle beschrijft datzelfde patroon voor zijn eigen platform: op zijn pagina over cloud-ERP staat dat de aanbieder de software meerdere keren per jaar bijwerkt, bij Oracle tot maandelijks aan toe (geraadpleegd in augustus 2026). Of dat bij uw leverancier ook zo ligt, staat in uw eigen contract. Hoe vaak het bij u gebeurt, hangt af van uw platform, uw contract en uw inrichting.
In de trajecten die wij bij on-premises installaties begeleidden, was een upgrade doorgaans een eigen project, met een datum en een budget eromheen. Bij een cloudplatform verhuist dat naar een ritme dat doorloopt. Voor uw beheerorganisatie betekent dat een taak die permanent is geworden: bij elke release opnieuw vaststellen of uw eigen processen er nog op draaien.
Wat er meeverandert als het scherm verandert
In onze ervaring raakt een release meer dan de functie waar hij over gaat. Een aanpassing in een standaardveld of een strenger geworden validatie werkt door in alles wat daarop is ingericht: uw maatwerk, uw koppelingen en de handelingen die uw medewerkers uit hun hoofd kennen.
Zolang niemand die doorwerking vooraf naloopt, komt zij achteraf boven water, via de mensen die het systeem gebruiken. Uw magazijnmedewerker merkt bijvoorbeeld dat de picklijst opeens anders sorteert, en pas als hij dat meldt, blijkt dat dezelfde wijziging ook een boekingsregel op een andere grootboekrekening laat landen.
Bij de organisaties die wij van binnen zien, is het acceptatieritme na go-live zelden formeel belegd. Er ontstaat dan een gewoonte waarin pas naar een release wordt gekeken zodra iemand een storing meldt.
Wie kan wat verklaren bij een release
Een acceptatietest bij een release controleert of uw eigen kritieke processen na de wijziging nog doen wat uw organisatie ervan verwacht. Vier partijen kunnen daarover elk iets anders zeggen, en samen vormen ze het volledige beeld.
| Partij | Wat die partij kan verklaren |
|---|---|
| Uw leverancier | Dat de release voldoet aan zijn eigen standaard, getoetst in zijn eigen omgeving |
| Uw functioneel beheer | Dat de inrichting, de autorisaties en de maatwerkobjecten na de release nog werken zoals afgesproken |
| Uw proceseigenaren en key users | Dat de dagelijkse gang van zaken in hun proces doorloopt, inclusief de uitzonderingen die zelden in een script staan |
| Een onafhankelijke partij | Dat het acceptatieproces zelf deugt: dat de testset dekt wat kritiek is en dat het oordeel navolgbaar is vastgelegd |
De onderste drie rijen zijn samen de acceptatie. Zodra één rij leeg blijft, verschuift het oordeel over uw processen naar een partij die uw inrichting, uw maatwerk en uw dagelijkse uitzonderingen niet van binnenuit kent. Hoe wij die rijen bij organisaties invullen, staat op onze pagina over testmanagement en kwaliteitsborging.
Het gereedschap voor de middelste twee rijen heet een regressietest: een vaste set doorlopen processen waarmee u controleert of wat gisteren werkte vandaag nog werkt, ook op de plekken die de release niet leek te raken. De waarde van zo’n set zit in de dekking van uw kritieke keten.
De testset veroudert stil
Er is nog een reden waarom acceptatie na verloop van tijd tandeloos wordt. De testset die bij go-live is opgesteld, beschrijft de organisatie zoals die er toen uitzag. Sindsdien zijn er artikelgroepen bijgekomen, is er een vestiging aangehaakt, is een koppeling vervangen en zijn er processen bijgeschaafd.
Wat wij tegenkomen bij organisaties die een paar jaar live zijn, is een testset die is blijven staan waar hij bij go-live stond. Er wordt getest wat erin is opgeschreven, en dat is de organisatie van destijds. De processen die er vandaag toe doen, wachten vaak nog op een plek erin.
Onderhoud van de testset is daarmee beheerwerk, net als het bijhouden van autorisaties of documentatie. Het hoort een eigenaar te hebben en een moment waarop het gebeurt. Wie de gereedheid vóór een eerste livegang wil beoordelen, vindt dat instrument in ERP go-live readiness; daarna begint het onderhoud.
De ERP-update readiness check: vier vragen
Het gaat bij alle vier om het antwoord dat u zonder opzoeken kunt geven, want twijfel is hier zelf al informatie.
- Wanneer verandert uw ERP de eerstvolgende keer? Kunt u de datum noemen, of de periode waarin uw leverancier de volgende release doorzet?
- Wie tekent bij u af dat een release naar productie mag? Kunt u een naam noemen, en weet die persoon zelf dat de rol bij hem of haar ligt?
- Wat dekt uw testset vandaag af? Loopt hij mee met de processen die er nu toe doen, of met de processen van uw implementatie?
- Hoe dicht staat uw acceptatieomgeving bij productie? Komen de inrichting, de data en de koppelingen nog voldoende overeen om iets zinnigs te kunnen concluderen?
Wie alle vier vlot beantwoordt, heeft acceptatie belegd. Wie op één vraag moet zoeken, heeft een taak zonder naam gevonden. Zet die naam erbij en spreek af wanneer het werk gebeurt; dat is de hele stap.
Situaties die voorrang verdienen bij de eerstvolgende release
Soms is de gebruikelijke routine te licht voor de release die eraan komt. Dat geldt wanneer uw leverancier een grote functionele release aankondigt, wanneer er kort daarvoor een koppeling is aangepast of vervangen, en wanneer de release landt in een periode waarin uw kritieke processen zwaar belast zijn, zoals een seizoenspiek of een jaarafsluiting. In die gevallen loont een korte, gerichte toets op de kritieke keten.
De drempel: wanneer volstaat meelopen, en wanneer niet
Hoeveel u toetst, volgt uit een afweging tussen de kans dat een release iets raakt en de schade als dat in productie gebeurt. Wij werken in de trajecten die wij begeleiden met twee houdingen, en de kunst zit in het herkennen van de drempel ertussen.
Meelopen betekent dat u de release accepteert op het oordeel van uw leverancier, met één benoemde persoon die kort na livegang de kritieke processen naloopt. Dat is een verdedigbare keuze bij een standaardinrichting, weinig maatwerk, een korte herstelketen en verstoringen die uw organisatie kan dragen. U accepteert dan bewust dat uw gebruikers de eerste signaalgevers zijn.
Toetsen betekent dat uw eigen organisatie vóór livegang vaststelt dat de kritieke keten nog werkt, op basis van een onderhouden testset en een acceptatieomgeving die op productie lijkt. Dat kost structureel tijd van precies de mensen die het al druk hebben, en dat is de eerlijke prijs.
U zit boven de drempel zodra uw maatwerk en uw koppelingen zo in elkaar grijpen dat u de gevolgen van een wijziging niet meer overziet. Datzelfde geldt op het moment dat een verstoring in uw kernproces duurder uitvalt dan de toetsing zelf. Boven die drempel is meelopen een gok.
Wie boven de drempel zit en de capaciteit intern niet vrij krijgt, kan het toetsen van buitenaf laten inrichten en periodiek laten doorlichten, met overdracht naar het eigen team als einddoel. Hoe zo’n onafhankelijke doorlichting verloopt, laat de PLC-audit die wij voor NLW Groep uitvoerden goed zien.
Wanneer moet u actie ondernemen?
De vier vragen hierboven meten uw acceptatieproces zoals het vandaag staat. Daarnaast zijn er momenten waarop een eerder gemaakte keuze niet meer klopt, omdat uw organisatie inmiddels een andere is dan toen de afspraken werden gemaakt.
Het duidelijkste moment is een wisseling in uw beheerteam. Zodra het krimpt of van samenstelling verandert, verschuift de kennis achter de testset mee, in onze ervaring zonder dat iemand dat op dat moment opmerkt. Hetzelfde geldt bij groei: een nieuwe vestiging, een productlijn of een land erbij betekent dat uw kritieke keten breder is geworden dan de set die hem zou moeten dekken.
Een tweede aanleiding is een verstoring die kort na een release begon. Eén zo’n gebeurtenis in een jaar is genoeg om de vraag te rechtvaardigen of hij vooraf zichtbaar was geweest. En een derde aanleiding komt van buiten: op het moment dat een accountant, een klant of een ketenpartner wil weten hoe u wijzigingen beheerst doorvoert, is uw acceptatieproces ineens iets wat u moet kunnen laten zien.
Wanneer is dit juist niet nodig?
Er zijn situaties waarin een uitgebouwd acceptatieproces overbodig is. Wij zeggen dat liever hardop dan dat wij iedereen dezelfde aanpak aanbevelen.
Draait uw ERP on-premises op een versie die u zelf beheert en op uw eigen moment bijwerkt, dan geldt de aanleiding van dit artikel voor u simpelweg niet. Uw vraag verschuift naar uw eigen upgradeproject, en dat is een ander gesprek.
Heeft u het al op orde, met een naam bij de acceptatie, een testset die met uw processen is meegegroeid en een omgeving die op productie lijkt, dan valt hier weinig te halen. Ons advies zou in dat geval zijn om er vooral niets aan te veranderen.
Zit uw organisatie midden in een implementatie of een grote uitrol, koppel de acceptatievraag dan aan dat traject. Eén afspraak volstaat: leg vast wie kijkt, en waarnaar.
Waarom een geruststelling bij ons pas telt als zij getoetst is
Wij zijn een bedrijf van mensen dat werkt voor bedrijven van mensen, en die zin wordt pas concreet op het moment dat er iets verandert in een systeem waar uw collega’s elke dag in werken. Wat wij daar geloven, is eenvoudig: een wijziging hoort te zijn bekeken voordat iemand hem tegenkomt terwijl hij zijn werk doet. Zo’n toets is de kleinste vorm van respect voor het werk van uw collega’s.
Daar hangt een tweede overtuiging aan. Onze inkomsten staan volledig los van welk platform u draait, welke licenties u afneemt en welke testtool u kiest; wij zijn bij geen enkele leverancier aangesloten. Dat is de reden dat u van ons ook te horen krijgt dat er bij u niets hoeft te veranderen, en dat u dat oordeel kunt vertrouwen.
Onze 265+ specialisten geven ons de capaciteit om de acceptatierol tijdelijk te vullen, functioneel zowel als technisch, zonder dat u daarvoor zelf een testteam hoeft op te bouwen. Welke platformkennis wij voor úw omgeving kunnen leveren, hoort thuis in een intakegesprek.
Twee regels op papier, en dan pas een gesprek
Begin klein. Zoek de datum van uw eerstvolgende release op en zet erbij wie er vandaag feitelijk over gaat. Noteer daarnaast de vijf processen waarvan u zou willen dat ze zeker worden nagelopen. Die twee regels brengen het onderwerp al op de agenda waar het hoort.
Bel of mail ons gerust als u er daarna een uur over wilt sparren. Daar zit geen offerte of vervolgtraject aan vast; wij vinden het simpelweg een gesprek dat te weinig gevoerd wordt. Wilt u een laag dieper, dan kijken wij onafhankelijk mee met uw acceptatieproces: wat uw testset vandaag afdekt en wie namens u het oordeel geeft. Dat werk valt onder onze aanpak voor beheer, support en doorontwikkeling.
Veelgestelde vragen
Hoe vaak moet u uw ERP testen na go-live?
Koppel uw testritme aan het releaseritme van uw leverancier: elke release die uw productieomgeving raakt, verdient een acceptatietest op uw eigen kritieke processen.
De omvang mag verschillen. Bij een kleine correctieve release volstaat een korte controle van de processen die hij raakt. Zodra het om een grote functionele release gaat, hoort de volledige set erdoorheen. Bepaal die omvang vooraf, zodat de afweging niet elke keer ter plekke opnieuw wordt gemaakt.
Wat is een regressietest bij een ERP-systeem?
Een regressietest controleert of processen die al werkten na een wijziging nog steeds werken.
Bij ERP betekent dat: uw orderstroom, uw facturatie, uw voorraadmutaties en uw koppelingen opnieuw doorlopen na een release, ook waar die release niets leek te veranderen. De waarde zit in de dekking. Een testset die alleen de gewijzigde functie raakt, laat precies het risico onbekeken waar het u om gaat.
Wie is verantwoordelijk voor het testen van een ERP-update: u of uw leverancier?
De verantwoordelijkheid is gedeeld: uw leverancier staat in voor zijn eigen standaard en uw organisatie voor het oordeel over de eigen processen, inrichting en koppelingen.
Leg vast wie namens uw organisatie verklaart dat een release naar productie mag, en waarop dat oordeel is gebaseerd. Zonder die rol schuift het oordeel in de praktijk stilzwijgend op naar de partij die de wijziging heeft gemaakt.
Wat schiet u op met het uitstellen van een ERP-update?
Uitstel levert u vooral tijd op om te toetsen, en het verplaatst de datum waarop de wijziging in uw productieomgeving terechtkomt.
Gebruik dat venster daarom gericht en spreek af wanneer de toets klaar is. Uitstel dat ontstaat omdat niemand zich eigenaar voelt, levert een grotere sprong op zodra de release er alsnog doorheen gaat, want dan komen meerdere wijzigingen tegelijk binnen.