Procesafspraken na software-invoering: werkinstructies en eigenaarschap borgen

Nazorg: het moment waarop afspraken wegzakken

In de fasering van een ERP-implementatie is livegang geen eindpunt. Na livegang levert het echte gebruik de restpunten op. Juist in die periode is nazorg vaak niet belegd, terwijl de begeleidende partner afschaalt op het moment dat de eigen mensen de vragen krijgen. Dat patroon staat expliciet in de beschrijving van de fase livegang en nazorg: het oude systeem gaat uit, het nieuwe aan, en de vragen komen dan pas.

Restpunten die na livegang opkomen, zijn deels geen technische fouten maar uitzonderingen die eerder niet boven water kwamen. In de testfase lopen sleutelgebruikers hun eigen werk door in het nieuwe systeem, inclusief de maandafsluiting. In de praktijk wordt echter getest op wat er is gebouwd in plaats van op hoe mensen werken. Wat niet in de testscripts zat, verschijnt in de eerste weken van het dagelijks gebruik.

Zonder afspraak over de nazorg organiseren mensen zichzelf: ze bellen een collega, maken een eigen spreadsheet naast het systeem of vragen de leverancier om een snelle aanpassing. Na een paar maanden zijn die oplossingen de feitelijke werkwijze, terwijl de beschreven werkwijze iets anders zegt. Elke oplossing uit die periode is een bedrijfsbesluit dat je ook had kunnen nemen — maar dan vastgelegd.

Leg daarom vóór livegang vast wie de vragen opvangt in de eerste weken en maanden, met naam en bereikbaarheid per procesgebied. Leg ook vast op welk moment de begeleidende partij haar inzet afbouwt en hoe een restpunt wordt geregistreerd in plaats van mondeling opgelost. Zonder die drie afspraken valt de opvang samen met de periode waarin de externe ondersteuning juist minder wordt.

Afspraken die moeten zijn gemaakt vóór livegang

Elk bedrijfsbesluit krijgt een werkinstructie

Een implementatie is in de kern 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 liggen ook niet bij de leverancier. De softwareleverancier richt de software in en ondersteunt de technische implementatie; de opdrachtgever blijft verantwoordelijk voor de inrichting. Die verantwoordelijkheid verdwijnt niet na de contractondertekening.

De ontwerpfase is het moment waarop wordt besloten wat je aanpast aan de standaard en wat je laat bouwen. Een valkuil is dat elke bestaande uitzondering wordt overgenomen in plaats van bevraagd, waardoor maatwerk groeit nog voordat er een regel code is geschreven.

Een uitzondering die eenmaal is ingebouwd, is later duur om terug te draaien. Elke uitzondering verdient daarom een expliciet besluit — laten vervallen, standaard afhandelen of bewust inbouwen — met de rol die het werk doet en het moment waarop het besluit is genomen.

Een besluit bekijft pas als het per rol is omgezet in een werkinstructie. Werk in de taal en de volgorde van het werk: wat is de aanleiding om te beginnen, welke stappen volgen, welke invoer is verplicht en wat is het resultaat?

Neem ook op wie het resultaat controleert en wat je doet als de situatie afwijkt van de standaard. Een instructie die alleen het scherm of de knop beschrijft, veroudert bij de eerstvolgende update; een instructie die het besluit erachter beschrijft, blijft bruikbaar.

Toets de instructie op het werk zelf en niet alleen op de inrichting. Sleutelgebruikers lopen hun eigen werk door in het nieuwe systeem, inclusief de maandafsluiting; die test laat zien of de beschreven stappen kloppen met wat mensen feitelijk doen.

Besluiten die later moeilijk terug te draaien zijn, leg je vast met datum, beslisser en reden: een vervallen uitzondering, een gewijzigde kring van mensen die cijfers mag zien, de inrichting van de maandafsluiting. Een latere aanpassing is dan een nieuw besluit in plaats van een sluipende wijziging.

Proceseigenaar, data-eigenaar en sleutelgebruiker: drie verschillende petten

Drie rollen maken na livegang het verschil, en ze zijn niet uitwisselbaar. De proceseigenaar is verantwoordelijk voor hoe het proces loopt en of de werkinstructie nog klopt met de praktijk.

De data-eigenaar is verantwoordelijk voor de kwaliteit, integriteit en toegankelijkheid van een dataset. Die rol houdt toezicht op hoe gegevens worden verzameld, opgeslagen, gebruikt en beveiligd, en zorgt dat ze accuraat, up-to-date en betrouwbaar zijn.

De sleutelgebruiker is de ervaren gebruiker in de eigen afdeling die het werk in het systeem doorloopt, inclusief de maandafsluiting, en die als eerste merkt dat een stap niet meer past.

Zet de bezetting op namen en niet op functietitels. In de voorbereidingsfase staat de bezetting vaak op rollen, en gaandeweg het traject blijkt wie het echt gaat doen.

De valkuil: bij ziekte, verloop of een interne verschuiving verdwijnt de aanspreekbaarheid, terwijl niemand formeel is aangewezen. Wijs per rol een primaire naam en een plaatsvervanger aan, met dezelfde bevoegdheid om knopen door te hakken, en leg vast wie beslist als proceseigenaar en data-eigenaar het oneens zijn.

Maak de grenzen tussen de petten expliciet, anders lopen ze in elkaar over. De proceseigenaar bepaalt niet zelfstandig wie toegang krijgt tot gegevens en wijzigt niet eenzijdig de inrichting. De data-eigenaar houdt toezicht op datatoegang en op de kwaliteit van de dataset, maar beslist niet over proceswijzigingen.

De sleutelgebruiker signaleert knelpunten, wijzigingsbehoeften en uitzonderingen, maar beslist niet en voert niet zelfstandig wijzigingen door. Eén persoon mag meerdere petten dragen, mits per pet duidelijk is welke pet op welk moment geldt.

Datakwaliteit is geen project maar een terugkerende taak

In de fase van bouw en inrichting blijkt de datakwaliteit in de praktijk slechter dan gedacht. Het opschonen is het werk van de organisatie zelf, niet van de implementatiepartner, en dat komt zelden vroeg genoeg op de planning. Wie de overzetting voorbereidt, merkt dan dat verplichte velden leeg zijn, dat dezelfde klant of leverancier onder meerdere codes bestaat en dat historische gegevens niet eenduidig zijn.

Wijs per dataset een eigenaar aan die de gegevens schoon, consistent en bruikbaar houdt en ze regelmatig controleert en bijwerkt. Maak dat concreet per dataset: welke velden zijn verplicht, wie voert ze in, wie controleert ze, met welke frequentie, en wat is de consequentie als een veld fout staat. Een foutieve voorraad of een verkeerd ingevoerde prijs werkt door in de planning en in de rapportage die anderen gebruiken.

Toegang hoort bij dezelfde taak. De data-eigenaar houdt toezicht op wie welke gegevens mag inzien en wijzigen, en dat raakt ook de naleving van privacywetgeving zoals de AVG/GDPR. Bepaal per dataset de kring van mensen die mag lezen en de kleinere kring die mag wijzigen, en leg vast hoe een wijziging wordt gecontroleerd.

Het verschil met een project is de herhaling. Opschonen is eenmalig, maar controleren op juistheid, volledigheid en actualiteit stopt niet bij livegang. Neem de controle op als terugkerende taak in de kwaliteitscyclus, met een vaste frequentie en een vastgelegde eigenaar. Zo verdwijnt de controle niet op het moment dat het implementatietraject wordt afgesloten.

Wie mag wat: toegang, standaardinstellingen en updates

Software en apparatuur worden geleverd met standaardinstellingen en vaak een standaardwachtwoord, en met functies die automatisch 'aan' staan terwijl de organisatie ze niet gebruikt. Wie die instellingen niet vanaf het eerste gebruik aanpast, is onbedoeld kwetsbaar: onnodige functionaliteiten vergroten het aanvalsoppervlak en de toegankelijkheid van het systeem.

Maak er een vaste afspraak van om bij ingebruikname en bij elke nieuwe module of release na te gaan welke functionaliteit niet nodig is en die uit te zetten. Pas standaardinstellingen aan voordat systemen op internet worden aangesloten.

Beleg het beheer van toegangsrechten bij één expliciet aangewezen eigenaar. Die beheert wie welke rol en welke rechten heeft, op basis van functie en taak, en controleert dat op vaste momenten: bij indiensttreding, bij een functiewijziging en bij vertrek.

De data-eigenaar bepaalt wat er met de gegevens mag gebeuren; de beheerder van de toegangsrechten voert dat uit en houdt de rechtenlijst actueel. Zonder die scheiding groeit het aantal mensen met ruime rechten ongemerkt.

Updates en patches horen in een vast proces, niet in de agenda van degene die toevallig tijd heeft. Fabrikanten brengen updates uit om functionaliteiten toe te voegen, maar ook om fouten op te lossen en beveiligingslekken te dichten. Tijdig updaten en patchen verhelpt kwetsbaarheden snel en voorkomt grote schade door bijvoorbeeld gijzelsoftware.

Spreek af met welke cadans updates worden beoordeeld en wie beslist of een update meegaat. Leg ook vast wanneer er wordt getest voordat iets in productie gaat en wie de gebruikers informeert als gedrag in het systeem verandert.

Automatiseer wat zich laat automatiseren, zodat terugkerende updates en controles minder afhankelijk zijn van menselijke opvolging. Herhaal de test stap voor stap in een aparte omgeving voordat de productieomgeving verandert. Neem de bredere beveiligingsmaatregelen in dezelfde afsprakenlijst op: firewall en versleuteling van gegevens horen bij dezelfde verantwoordelijkheid als wachtwoorden en rechten. Zo kent beveiliging één aanspreekpunt en één overzicht.

Wijzigingen beheerst doorvoeren zonder de werkinstructies te breken

Leg één werkwijze vast voor wijzigingen, met een vaste route. Daarin staat wie een wijziging mag aanvragen en welke informatie daarbij hoort: wat, waarom, urgentie, welke rollen en welke gegevens het raakt.

Ook staat erin wie beoordeelt, wie beslist, wie test, wie communiceert en op welk moment de wijziging ingaat. Zonder die route komt een aanpassing binnen via een telefoontje naar de leverancier en is niemand verantwoordelijk voor de doorwerking.

Beoordeel bij elke aanvraag twee gevolgen die vaak worden vergeten: de werkinstructie en de toekenning van rechten. Een nieuw veld, een vervallen stap of een gewijzigde uitzondering betekent dat de instructie voor de betrokken rollen moet worden bijgewerkt, en soms dat een andere groep mensen toegang nodig heeft of juist moet verliezen. Spreek vooraf af dat een wijziging niet in productie gaat zonder bijgewerkte instructie en bijgewerkte rechten, in plaats van dat achteraf te repareren.

Test een wijziging op de werkwijze van de gebruikers en niet op wat er is gebouwd. Dezelfde les als bij de oorspronkelijke testfase geldt bij elke aanpassing: als sleutelgebruikers de gewijzigde stap niet in hun eigen werk doorlopen — inclusief de maandafsluiting — komen de uitzonderingen pas na invoering boven.

Plan daarom ook bij wijzigingen een testmoment, een moment van invoering en een terugvaloptie als het in de praktijk niet werkt. ISO 9001:2026 besteedt meer aandacht aan het plannen en beheerst doorvoeren van veranderingen (management of change), wat aansluit bij deze werkwijze.

Houd één wijzigingsregister bij met datum, aanvrager, beslisser, reden, geraakte processen en rollen, en de status. Dat register is bij een volgende beoordeling de onderbouwing waarom een stap anders is dan een jaar eerder. Het maakt ook zichtbaar welke wijzigingen nog op communicatie of instructie wachten.

Verankeren in de reguliere verbetercyclus: plan, do, check, act

ISO 9001 is de internationale norm voor kwaliteitsmanagementsystemen. Een goed systeem voor kwaliteitsmanagement helpt organisaties de kwaliteit van producten en diensten te borgen en continu te verbeteren. De norm is toepasbaar op iedere organisatie, ongeacht type, omvang, producten of diensten.

Organisaties die al volgens deze norm werken, hebben de verbetercyclus dus al staan. De procesafspraken rond het systeem hoeven daar alleen in te worden opgenomen.

De cyclus is concreet te maken met vier stappen. PLAN: kijk naar de huidige werkzaamheden en ontwerp een plan voor verbetering van die werkzaamheden. DO: voer de geplande verbetering uit.

CHECK: stel vast of het werk feitelijk volgens de werkinstructie loopt — de maandafsluiting op tijd, zonder correcties achteraf en zonder omwegen buiten het systeem. ACT: stel de instructie, de rechten of de inrichting bij en leg vast wat er is gewijzigd.

Neem de werkinstructies en het wijzigingsregister mee in de periodieke beoordeling van het managementsysteem. Zo worden ze bij elke ronde nagelopen in plaats van alleen bij een projectevaluatie.

De herziene norm, ISO 9001:2026, is op 16 september 2026 gepubliceerd en bouwt voort op de eisen uit de versie uit 2015. De veranderingen zitten vooral in verduidelijking, actualisatie en betere aansluiting op de praktijk.

Meer aandacht is er voor de rol van klimaatverandering, voor kwaliteitscultuur en ethisch gedrag en voor een duidelijker onderscheid tussen risico's en kansen. Ook voor het plannen en beheerst doorvoeren van veranderingen en voor betere aansluiting op andere managementsysteemnormen. Organisaties met een bestaand systeem doen er goed aan te beoordelen wat die accenten voor hen betekenen.

Borging vraagt om een vaste cadans en niet om een eenmalig document. Koppel aan de cyclus een terugkerend agendapunt waarin risico's en kansen rond het systeem worden besproken. Besteed daarbij expliciet aandacht aan kwaliteitscultuur en gewenst gedrag: wat doe je als iemand een uitzondering buiten het systeem afhandelt of een stap overslaat omdat het sneller gaat, en wie spreekt daarop aan. Zonder dat gesprek verwatert de instructie alsnog, ongeacht hoe goed het document is.

Toetsen of de afspraken standhouden in de praktijk

Toets periodiek met vier concrete vragen. Loopt de maandafsluiting nog volgens de instructie, met de stappen en de volgorde die zijn beschreven? Komen de beschreven stappen overeen met wat mensen feitelijk in het systeem doen — vergelijk de instructie met de handelingen en de invoer, niet met de bedoeling?

Zijn de eigenaren nog de juiste namen, aanspreekbaar en bevoegd, ook na ziekte of verloop? Komen nieuwe uitzonderingen tijdig boven water en worden ze als wijziging ingediend in plaats van informeel opgelost?

Gebruik sleutelgebruikers en het restpuntenoverzicht uit de nazorgperiode als vaste bron van verbeteringen. Leg restpunten vanaf livegang vast met eigenaar en status en werk de lijst af in vaste besprekingen, in plaats van hem te laten verdwijnen zodra de implementatie wordt afgesloten.

Dezelfde lijst is input voor de plan-do-check-act-cyclus: wat in de nazorg is opgelost, is een verbetering; wat blijft liggen, is een risico dat een besluit vraagt.

Een praktisch signaal dat de afspraken niet meer standhouden: er ontstaan werkwijzen naast het systeem — eigen spreadsheets, informele afspraken, uitzonderingen die buiten de administratie blijven. Dat betekent meestal dat de instructie niet meer klopt met de praktijk, dat de rechten niet passen bij de taak of dat de inrichting een stap onnodig omslachtig maakt. Behandel dat als een besluit en een wijziging, niet als een incident dat telkens opnieuw wordt opgelost.

Herhaal de toets bij elke gebeurtenis die de afspraken raakt: een systeemupdate, een proceswijziging, een nieuwe vestiging of module, en een personeelswissel op een van de drie rollen. Stel elke keer opnieuw vast wie proceseigenaar, data-eigenaar en sleutelgebruiker is en of de werkinstructie nog overeenkomt met het werk. Zo blijven de afspraken levend zonder dat er een nieuw project nodig is.