Een proces dat niemand leest: zo maak je documentatie die je team wél gebruikt
Door Clen Mourik
33% van nieuwe medewerkers besluit al in de eerste maand te vertrekken. Gemiddelde schade: €20.000 per persoon. De oorzaak? Vaak ontbrekende of onbruikbare documentatie. Dit artikel laat zien hoe je werkinstructies maakt die mensen daadwerkelijk gebruiken.
Hoeveel mapjes op je server staan er vol met processen die niemand ooit opent? Hoe vaak hoor je "vraag het maar aan Karin, die weet hoe het werkt"? En wat kost het je bedrijf als Karin een week ziek is?
In veel MKB-bedrijven bestaat processdocumentatie vooral op papier. Letterlijk. Word-documenten uit 2018, PDF's waar niemand doorheen komt, en werkinstructies die niet kloppen met hoe het werk nu écht gaat. Het gevolg: handmatig overtypen, steeds dezelfde vragen, en nieuwe medewerkers die wekenlang ronddobberen voordat ze snappen hoe het zit.
Ergste nog? Het kost je geld. Onderzoek toont aan dat 33% van nieuwe medewerkers al in de eerste maand besluit te vertrekken. Dat kost gemiddeld €15.000 tot €25.000 per vertrekker aan wervings- en inwerkkosten. En vaak is de oorzaak simpel: ze weten niet hoe ze hun werk moeten doen.

Inhoudsopgave
- Belangrijkste punten
- Waarom niemand je documentatie leest
- Wat wél werkt: documentatie die mensen gebruiken
- Voorbeelden uit de praktijk
- De techniek: documentatie ná een systeemkoppeling
- Veelgemaakte fouten (en hoe je ze voorkomt)
- Welke tools kun je gebruiken?
- Zo begin je vandaag
- Veelgestelde vragen
Belangrijkste punten
| Punt | Details |
|---|---|
| Betrek je team | Medewerkers die meedenken over hun eigen proces volgen het ook daadwerkelijk op |
| Houd het kort | Eén A4 met beslisboom werkt beter dan een handboek van 40 pagina's |
| Plaats op het moment van gebruik | Niet in een map op de server, maar in het systeem waar je het nodig hebt |
| Onderhoud het actief | Verouderde documentatie is erger dan geen documentatie |
| Leg het 'waarom' uit | Mensen volgen procedures beter als ze snappen waarom het belangrijk is |
Waarom niemand je documentatie leest
Laten we eerlijk zijn. De meeste procesdocumentatie wordt geschreven door iemand die het werk zelf niet doet. Een manager tikt op een woensdagmiddag een proceshandleiding in Word, slaat hem op in een map genaamd "Procedures 2024", en mailt de link naar het team.
Drie maanden later vraagt diezelfde manager waarom niemand de procedure volgt. Het antwoord is simpel: niemand herkent zijn eigen werk erin.
Wat ik steeds zie in het MKB: de beste proceshandleidingen worden niet geschreven, maar getekend op een whiteboard door de mensen die het werk doen.
Volgens Commant is gefragmenteerde documentatie een van de grootste oorzaken van operationele chaos. Richtlijnen, processen en werkinstructies zijn verspreid over meerdere systemen, met inhoudelijke tegenstellingen en onduidelijke terminologie. Het resultaat: inconsistentie, herhalende fouten, ondermaatse kwaliteit.
Het Word-document-kerkhof
Herkenbaar? Je hebt een gedeelde schijf met mappen als "Werkinstructies", "Procedures nieuw", "Procedures DEFINITIEF" en "Procedures 2023 backup". In elke map zitten tien tot twintig documenten waarvan niemand meer weet welke versie actueel is.
Gevolg: medewerkers vragen het aan een collega. Die collega doet het op zijn manier. Een andere collega doet het anders. En jij hebt vijf verschillende workflows voor hetzelfde proces.
Te veel detail op het verkeerde moment
Een ander probleem: managers denken op tactisch niveau, medewerkers werken op operationeel niveau. Zoals too-doo beschrijft, maken veel bedrijven de fout om processen alleen operationeel te documenteren (flowcharts, SOP's), terwijl het management juist een tactisch overzicht nodig heeft.
Het omgekeerde is ook een probleem. Een magazijnmedewerker die dozen moet inpakken heeft geen behoefte aan drie pagina's strategische context over waarom het retourproces belangrijk is voor de klanttevredenheid. Die wil weten: welke stappen, in welke volgorde, en wat doe ik als het misgaat.

Wat wél werkt: documentatie die mensen gebruiken
De beste processdocumentatie heeft drie kenmerken: het is kort, het staat op de juiste plek, en het is geschreven door de mensen die het werk doen.
1. Kort en concreet
Één A4 met een beslisboom werkt beter dan een handboek van 40 pagina's. Waarom? Omdat mensen op het moment dat ze een probleem hebben geen tijd hebben om door een document te scrollen.
Neem een retourproces in een groothandel. In plaats van een lange beschrijving van het beleid, maak je een simpele checklist:
- Is de retour binnen 14 dagen? → Ja: volledige terugbetaling. Nee: check met teamleider.
- Is de verpakking nog intact? → Ja: retour naar voorraad. Nee: afkeuren.
- Heeft klant een retourbon? → Nee: mail sturen met retourlink.
Drie stappen. Duidelijk. En het past op een half A4-tje dat je naast je werkplek kunt ophangen.
2. Op de juiste plek
Documentatie die ergens in een map staat wordt niet gebruikt. Waar moet het dan wel staan? Daar waar je het nodig hebt.
Voorbeelden:
- Een productiebedrijf met een MES-systeem: werkinstructie direct in het systeem, niet in een PDF.
- Een webshop met een WMS: foutwaarschuwing bij foutieve orderverwerking linkt naar de juiste werkinstructie.
- Een installatiebedrijf met mobiele monteurs: QR-code op de servicebus die linkt naar een video-walkthrough voor zeldzame storingen.
De regel: documentatie moet beschikbaar zijn op het moment dat iemand het nodig heeft, niet drie klikken verder in een mappenstructuur.
3. Geschreven door de uitvoerder
Hier zit de crux. Als je wilt dat mensen een procedure volgen, laat ze dan zelf de procedure schrijven. Boom Management legt uit: medewerkers die betrokken zijn bij het ontwerp van een proces krijgen een gevoel van eigendom. Ze zetten zich in, zijn bezorgd over het verloop, en werken gedisciplineerd.
Ik merk in de praktijk: als een medewerker zegt 'dit klopt niet met hoe wij het doen', dan heeft hij meestal gelijk. En als hij dan mag meeschrijven, heb je meteen draagvlak.
Dat betekent niet dat je als manager geen rol hebt. Jij zorgt voor de structuur, de consistentie tussen afdelingen, en het vastleggen van de beslissingen. Maar de inhoud komt van de vloer.
Voorbeelden uit de praktijk
Voorbeeld 1: Groothandel met AFAS en WMS-koppeling
Een groothandel met 20 medewerkers gebruikte AFAS voor hun administratie en een WMS voor voorraad. Ze hadden een koppeling gebouwd zodat orders automatisch werden doorgezet. Scheelde hen dagelijks uren handmatig werk.
Maar niemand had vastgelegd wat er moest gebeuren als de koppeling een fout gaf. Het magazijn had vijf verschillende workarounds voor hetzelfde probleem.
Oplossing: een korte werkinstructie per fouttype. Maximaal één A4 met een beslisboom. Opgeslagen in het WMS zelf, niet in een map op de server. Resultaat: minder escalaties naar de leidinggevende en consistente afhandeling.
Voorbeeld 2: Productiebedrijf met kennismonopolie
Een productiebedrijf met 35 medewerkers had een ervaren planner die de hele productieplanning in zijn hoofd had. Geen instructies, geen vastgelegde werkwijze. Toen hij twee weken op vakantie ging, stond de productie bijna stil.
Samen met hem een SOP (Standard Operating Procedure) opgesteld. Niet hoe de manager dacht dat het ging, maar hoe hij het daadwerkelijk deed. In zijn eigen woorden. Inclusief de 'trucs' die hij gebruikte.
Daarna konden andere medewerkers de planning overnemen. En de planner zelf merkte dat hij minder fouten maakte omdat hij zijn eigen proces nu expliciet had gemaakt.
Voorbeeld 3: E-commerce met seizoenspieken
Een webshop met 8 vaste medewerkers en 5-10 uitzendkrachten in piekmomenten. Ze gebruikten Exact Online voor boekhouding en Shopify als platform. Orderverwerking liep door elkaar omdat iedere uitzendkracht het op zijn eigen manier deed.
Oplossing: korte video-walkthroughs (schermopnames) per ordertype, gecombineerd met een checklist. Toegankelijk via een QR-code op de werkplek. Nieuwe medewerkers konden meteen aan de slag, zonder dat iemand naast ze hoefde te staan.
Bijkomend voordeel: onderzoek van Copilot laat zien dat 40% van bedrijven nieuwe medewerkers onvoldoende ondersteunt. Bij 1 op de 3 bedrijven verlopen de eerste weken rommelig. Dit bedrijf loste dat op met goede documentatie op het juiste moment.

De techniek: documentatie ná een systeemkoppeling
Vaak wordt de behoefte aan documentatie pas echt urgent ná een systeemimplementatie of -koppeling. Je hebt net een koppeling gebouwd tussen je ERP en je boekhouding, en opeens verandert de workflow. Handmatige stappen vervallen. Nieuwe stappen komen erbij. En niemand heeft opgeschreven hoe het nu moet.
AFAS en Exact Online: de twee grote spelers
In het Nederlandse MKB zijn AFAS en Exact Online de meest gebruikte pakketten. Volgens Ondernemen en Internet:
- Exact Online is modulair opgebouwd. Je kunt beginnen met boekhouding en facturatie, en uitbreiden met modules voor handel, productie of projecten. Het heeft veel koppelingen via de Exact App Store.
- AFAS biedt één geïntegreerd systeem, sterk in HRM, salaris en administratieve workflows. Ideaal voor organisaties met veel interne processen.
Beide systemen hebben krachtige API's waarmee je koppelingen kunt bouwen. Maar een technisch werkende koppeling is niet genoeg. Je moet ook documenteren:
- Wat doet de koppeling precies?
- Welke stappen vervallen?
- Wat moet een medewerker doen als er een fout optreedt?
- Waar is de 'bron van waarheid' (welk systeem is leidend)?
Error handling: het ontbrekende stuk
Bij SyncIT bouwen we koppelingen met error handling en logging. Als er iets misgaat, is dat detecteerbaar voordat de gebruiker het merkt. Maar je moet ook documenteren wat een gebruiker moet doen als hij een foutmelding ziet.
Voorbeeld: een order wordt niet doorgezet van het WMS naar AFAS. De medewerker ziet een rode waarschuwing. Wat nu?
- Check of de klantgegevens compleet zijn (telefoonnummer en e-mail verplicht).
- Controleer of de voorraad correct is bijgewerkt in het WMS.
- Kijk in het logboek (link naar logboek-scherm in AFAS).
- Lukt het nog niet? Escaleer naar IT met foutnummer.
Vier simpele stappen. Geen lange uitleg over waarom de koppeling soms faalt. Gewoon: dit doe je, in deze volgorde.
Veelgemaakte fouten (en hoe je ze voorkomt)
Fout 1: Documentatie schrijven zonder de uitvoerder erbij te betrekken
Dit is de grootste fout. Een manager schrijft achter zijn bureau een proces op,baseert het op hoe hij denkt dat het werkt, en deelt het met het team. Het team herkent hun eigen werk er niet in.
Oplossing: ga met de medewerker mee een dag lang. Kijk hoe hij het werk doet. Schrijf op wat hij doet, niet wat je denkt dat hij zou moeten doen. En laat hem het eindresultaat reviewen.
Fout 2: Te veel detail
Een veelgemaakte fout is dat managers een volledige strategische context meegeven bij een operationele instructie. Een monteur die een installatie moet doen heeft geen behoefte aan een halve pagina over waarom klanttevredenheid belangrijk is. Die wil weten: welke kabels waar, in welke volgorde.
Oplossing: splits je documentatie in niveaus. Management krijgt strategische overzichten. Teamleiders krijgen tactische processen. Uitvoerders krijgen korte werkinstructies.
Fout 3: Documentatie niet onderhouden
Verouderde documentatie is erger dan geen documentatie. Als een medewerker een instructie volgt en merkt dat het niet klopt, verliest hij vertrouwen in alle documentatie. De volgende keer vraagt hij het aan een collega in plaats van het op te zoeken.
Oplossing: wijs per document een eigenaar aan. Die persoon is verantwoordelijk voor updates. Zet een review-datum in de documentatie (bijvoorbeeld: "Laatste check: januari 2025"). En maak het makkelijk om feedback te geven ("Klopt dit niet? Mail naar [eigenaar]").
Fout 4: Documentatie op de verkeerde plek
Een PDF in een map op de server wordt niet gebruikt. Mensen hebben geen tijd om te zoeken. Ze vragen het liever aan een collega.
Oplossing: plaats documentatie daar waar het nodig is. In het systeem zelf, via een QR-code op de werkplek, of als pop-up bij een foutmelding.
Fout 5: Het 'waarom' ontbreekt
Zoals Diks Process Support uitlegt: medewerkers die het 'waarom' van een procedure snappen, zijn eerder geneigd om die procedure te volgen.
Voorbeeld: in plaats van "Vul altijd het telefoonnummer in", schrijf je "Vul altijd het telefoonnummer in, zodat de koerier contact kan opnemen bij leveringsproblemen".
Dat ene zinnetje extra maakt het verschil tussen een regel die wordt gevolgd en een regel die wordt genegeerd.
Welke tools kun je gebruiken?
Er zijn grofweg vier aanpakken voor processdocumentatie. Geen enkele is 'de beste'. Het hangt af van hoe je team werkt, hoeveel medewerkers je hebt, en hoeveel processen je moet vastleggen.
| Aanpak | Voordelen | Nadelen | Geschikt voor |
|---|---|---|---|
| Gedeelde schijf (Word/PDF) | Lage drempel, geen extra kosten | Geen versiebeheer, slecht vindbaar | Kleine teams (<10), weinig processen |
| Wiki (Confluence, Notion) | Flexibel, goed doorzoekbaar | Vereist discipline, geen afdwinging | Teams die al samenwerken in wiki |
| SOP-tools (Trainual, Waybook) | Ingebouwde tracking, onboarding-focus | Hogere kosten, engere focus | Groeiende bedrijven met onboarding-vraag |
| Video-tools (Scribe, Loom) | Snel te maken, laagdrempelig | Moeilijk te updaten, niet doorzoekbaar | Visuele processen, software-instructies |
Confluence: voor teams die al in Atlassian zitten
Als je al Jira gebruikt voor projectbeheer, is Confluence een logische keuze. Je kunt pagina's direct linken aan tickets en sprints. Maar let op: Confluence heeft een steile leercurve voor niet-technische gebruikers.
Notion: flexibel maar vraagt discipline
Notion is populair omdat het zo flexibel is. Je kunt een proceswiki, een onboarding hub en een bibliotheek van sjablonen in één werkruimte bouwen. Maar die flexibiliteit is ook een valkuil: zonder structuur wordt het een rommelige verzameling pagina's.
Trainual en Waybook: all-in-one voor onboarding
Tools als Trainual en Waybook zijn specifiek gebouwd voor processdocumentatie en onboarding. Ze hebben ingebouwde tracking (wie heeft wat gelezen), verificatie (quiz na een proces), en herinneringen voor updates.
Voordeel: je kunt zien of nieuwe medewerkers de onboarding daadwerkelijk doorlopen. Nadeel: hogere kosten dan een wiki, en de focus ligt op onboarding (minder geschikt voor operationele troubleshooting).
Video-walkthroughs: snel maar lastig te onderhouden
Voor software-instructies werken video's goed. Tools als Scribe en Loom maken het makkelijk om een schermopname te maken met automatische annotaties.
Nadeel: als je software een update krijgt, moet je de video opnieuw opnemen. En video's zijn niet doorzoekbaar (tenzij je een transcript toevoegt).
Zo begin je vandaag
Je hoeft niet in één keer je hele bedrijf te documenteren. Begin klein. Kies één proces dat vaak fout gaat of veel vragen oplevert. Documenteer dat. Kijk of het werkt. En breid dan uit.
Stap 1: Kies je eerste proces
Vraag jezelf af: waar loop je het vaakst tegenaan? Vaak zijn dat processen die:
- Regelmatig fout gaan (retouren, creditnota's, klachten)
- Afhankelijk zijn van één persoon ("vraag het maar aan Karin")
- Nieuw zijn (na een systeemkoppeling of software-update)
- Veel vragen opleveren van nieuwe medewerkers
Begin daar.
Stap 2: Betrek de uitvoerder
Ga niet zelf achter je laptop zitten. Ga met de persoon mee die het werk doet. Vraag: "Kun je me laten zien hoe je dit doet?" en schrijf mee. Let niet alleen op de stappen, maar ook op de beslismomenten ("als dit gebeurt, dan doe ik dat").
Stap 3: Houd het kort
Eén A4. Maximaal. Gebruik een beslisboom of checklist in plaats van lange zinnen. En voeg screenshots toe als het om software gaat.
Stap 4: Test het
Laat iemand anders (idealiter een nieuwe medewerker) het proces volgen aan de hand van je documentatie. Kijk waar hij vastloopt. Verbeter die stukken.
Stap 5: Plaats het op de juiste plek
Niet in een map op de server. Hang het op bij de werkplek, zet het in het systeem, of maak een QR-code die linkt naar de instructie.
Stap 6: Wijs een eigenaar aan
Iemand moet verantwoordelijk zijn voor updates. Zet zijn naam en de review-datum in de documentatie. En maak het makkelijk om feedback te geven.
Veelgestelde vragen
Wat zijn de beste tools voor processdocumentatie in het MKB?
Dat hangt af van je team. Voor kleine teams (<10) volstaat vaak een gedeelde schijf met Word-documenten. Voor grotere teams die al samenwerken in een wiki werkt Confluence of Notion goed. Voor bedrijven die veel nieuwe medewerkers onboarden zijn dedicated tools als Trainual of Waybook geschikt. En voor visuele software-instructies zijn video-tools als Scribe handig.
Hoeveel kost het om processdocumentatie te laten maken door een extern bureau?
Dat verschilt sterk. Een simpel SOP-traject (5-10 processen) kost vaak tussen €2.000 en €5.000. Een volledig managementsysteem met ISO-certificering kan oplopen tot €15.000-€30.000. Bij SyncIT richten we ons vooral op documentatie ná systeemkoppelingen, waarbij we werkinstructies meenemen als onderdeel van de implementatie.
Waarom wordt processdocumentatie niet gelezen door mijn team?
Meestal om een van deze redenen: (1) het klopt niet met de werkelijkheid, (2) het is te lang en complex, (3) het staat op de verkeerde plek (niet vindbaar op het moment van gebruik), of (4) medewerkers zijn niet betrokken geweest bij het maken ervan. Los één van die vier op en je zult zien dat gebruik toeneemt.
Hoe schrijf je effectieve werkinstructies die medewerkers daadwerkelijk gebruiken?
Houd het kort (één A4), betrek de uitvoerder bij het schrijven, plaats het op de juiste plek (waar het nodig is), leg uit waarom het belangrijk is, en wijs een eigenaar aan die updates doet. Test de instructie met een nieuwe medewerker om te zien waar hij vastloopt.
Wat is het verschil tussen een proces, procedure en werkinstructie?
Een proces is het grote geheel ("orderverwerking"), een procedure beschrijft de stappen en verantwoordelijkheden, en een werkinstructie is de concrete handleiding voor een specifieke taak ("hoe verwerk je een retour"). Voor de werkvloer zijn werkinstructies het belangrijkst.
Hoe houd je processdocumentatie actueel na een systeemkoppeling?
Wijs per document een eigenaar aan, zet een review-datum in de documentatie, en maak het makkelijk om feedback te geven. Bij grote wijzigingen (software-update, nieuwe koppeling) plan je een herziening in. En belangrijk: betrek de mensen die het proces uitvoeren bij updates, zodat de documentatie blijft kloppen met de praktijk.
Welke documentatie heb je nodig bij een AFAS of Exact Online koppeling?
Minimaal drie dingen: (1) wat doet de koppeling (welke data wordt gesynchroniseerd), (2) wat moet een medewerker doen bij een foutmelding, en (3) welk systeem is de 'bron van waarheid' (leidend). Daarnaast helpt het om de oude workflow (voor de koppeling) en de nieuwe workflow (na de koppeling) naast elkaar te zetten, zodat medewerkers het verschil zien.
Wil je weten hoe processdocumentatie past bij jouw systeemkoppeling? Of heb je moeite met processen die niet worden gevolgd? Plan een adviesgesprek en we kijken samen hoe je documentatie kunt maken die je team daadwerkelijk gebruikt. Geen verplichtingen, gewoon een eerlijk gesprek over wat werkt in jouw situatie.