[TOC]

Executive summary

Klassieke procesdocumentatie faalt structureel in moderne organisaties. Onderzoek toont aan dat 80% van de procesdocumentatie binnen 6 maanden na oplevering verouderd is, onvindbaar, of simpelweg genegeerd wordt door de medewerkers die ermee moeten werken. Organisaties investeren gemiddeld 200-500 uur per jaar in het onderhouden van handboeken, Word-documenten en statische PDF’s — vaak zonder meetbaar rendement. De kern van het probleem? Documentatie wordt gezien als een eindproduct, niet als een levend systeem.

De Procesdocumentatie Methode (PDM) introduceert een paradigmaverschuiving: van statische proza naar een dynamisch werknetwerk. PDM benadert procesdocumentatie niet als een schrijfopdracht, maar als een datacenter-architectuur, geïnspireerd op principes uit software engineering (modulariteit, herbruikbaarheid) en data-governance (SSoT, metadata-standaarden).

Waarom PDM werkt

Door inhoud (data) strikt te scheiden van vorm (presentatie) en alle proceskennis vast te leggen in één centrale Single Source of Truth (SSoT), ontstaat een:

• Wendbaar systeem: aanpassingen in de bron propageren automatisch door alle afgeleide documenten.
• Onderhoudbaar systeem: geen dubbel werk, geen inconsistenties.
• Digitaal werknetwerk: proceskennis wordt een actieve laag in de organisatie, niet een stofverzamelaar op een schijf.

Dit whitepaper verdiept:

• Het methodische fundament van PDM (waarom de 4 randvoorwaarden onmisbaar zijn).
• De kernprincipes en architectuur van de PDM-bouwstenen (hoe modelleer je een organisatie als netwerk?).
• Het mechanisme van geautomatiseerde documentprojecties (hoe genereer je doelgroepspecifieke output?).
• Governance via 5 fasen, 5 validatiepoorten en 3 sleutelrollen (hoe borg je kwaliteit?).

De crisis in klassieke documentatie

Waarom traditionele documentatie structureel faalt

PDM identificeert drie fundamentele systeemfouten in klassieke documentatietrajecten. Deze fouten zijn geen kwestie van slechte uitvoering, maar van verkeerde aannames over de aard van proceskennis.

Vorm en inhoud zijn onlosmakelijk vervlochten

Probleem: In een klassiek Word-document of PDF zijn processtappen, organisatierollen, systeemnamen en werkinstructies verweven in lopende tekst. Dit lijkt logisch — totdat iets verandert.

Voorbeeld: Stel, een organisatie vervangt haar CRM-systeem (bv. van Salesforce naar HubSpot). In een traditioneel handboek moet de naam ‘Salesforce’ nu handmatig worden vervangen op:

• Alle pagina’s waar het systeem wordt genoemd.
• In screenshots en voorbeelddocumenten.
• In de index en kruisverwijzingen.

Gevolg:

• Menselijke fouten: niet alle verwijzingen worden aangepast.
• Inconsistenties: sommige documenten verwijzen nog naar het oude systeem.
• Tijdsverlies: uren werk voor een wijziging die in PDM automatisch zou zijn.

Oorzaak: Klassieke documentatie behandelt inhoud (de processtap) en vorm (hoe die stap wordt beschreven) als één onscheidbaar geheel. PDM scheidt deze lagen door:

• Inhoud op te slaan in gestructureerde data (YAML/Markdown).
• Vorm te genereren via templates (voor een PDF, webpagina, of RACI-matrix).

Geen Single Source of Truth (SSoT)

Probleem: Informatie bestaat op meerdere plekken tegelijk, vaak in verschillende formaten:

• Het kwaliteitshandboek (PDF, 1x per jaar geüpdaterd).
• De afdelingswiki (Confluence, onvolledig).
• Trainingssheets (PowerPoint, verouderd).
• Lokale netwerkschijven (VersieFINALFINAL.docx).

Gevolg: Versiechaos: welke versie is nu de waarheid?

• Kennisverlies: medewerkers weten niet waar ze moeten zoeken.
• Compliance-risico’s: audits mislukken omdat documentatie niet up-to-date is.

Oorzaak: Klassieke documentatie ontbreekt een centrale bron. PDM lost dit op door:

• Alle proceskennis te centraliseren in één SSoT (het PDM Canvas).
• Relaties tussen objecten expliciet te modelleren (welke rol voert welke stap uit met welk systeem?).
• Projecties (documenten, diagrammen) automatisch te genereren uit deze bron.

Investeren in projecten, niet in beheer

Probleem: Documentatie wordt vaak opgepakt als een eenmalig project (bv. ‘We gaan ons kwaliteitshandboek eens goed op orde brengen’).

Gevolg:

• Kortstondige verbetering: na oplevering is de documentatie even actueel.
• Geen beheerstructuur: zodra het project afloopt, ontbreekt een geborgde beheercyclus.
• Terugval: binnen maanden ontstaat er weer een wildgroei aan schaduw-IT, informele afspraken en verouderde documenten.

Oorzaak: Klassieke documentatie mist een levenscyclusbenadering. PDM introduceert:

• 5 gefaseerde trajecten met validatiepoorten.
• 3 sleutelrollen met duidelijke verantwoordelijkheden (Proceseigenaar, Model Steward, Operationeel Expert).
• Continue borging via een RFC-proces (Request for Change) en periodieke schouw (Regel B6).

Het PDM fundament: vier harde randvoorwaarden

PDM lost de bovenstaande systeemfouten op door een procesorganisatie op te bouwen aan de hand van vier onwrikbare principes. Deze principes zijn niet optioneel — ze vormen de basis waarop het hele systeem rust.

Datasoevereiniteit & open standaarden

Principe: De organisatie moet volledige controle hebben over haar eigen proceskennis, zonder afhankelijkheid van leveranciers of gesloten systemen.

Hoe PDM dit bereikt:

• Geen vendor-lock-in: PDM gebruikt open standaarden (Markdown, YAML, Git) in plaats van gesloten databases of dure licentiesoftware.
• Platte, gestructureerde bestanden: Alle procesdata wordt opgeslagen in Markdown-bestanden met YAML-metadata. Voorbeeld:

  ---
  id: proc001
  type: proces
  naam: Order-to-Cash
  beschrijving: "Proces voor het afhandelen van klantorders."
  eigenaar: finance@bedrijf.nl
  versiedatum: 2026-07-23
  ---

Voordelen:

• 100% draagbaar: bestanden kunnen overal heen (GitHub, GitLab, lokale server, Synology NAS).

• Doorzoekbaar: volledige tekst doorzoekbaar met standaard tools (bv. grep, ripgrep of VSCodium).

• Toekomstbestendig: geen afhankelijkheid van specifieke softwareversies of gesloten database-indelingen.

Scheiding van bron en projectie

Principe:

Inhoud (data) en vorm (presentatie) moeten strikt gescheiden zijn, zodat wijzigingen in de bron automatisch doorwerken in alle afgeleide documenten.

Hoe PDM dit bereikt:

• Één bron (SSoT): het PDM Canvas (gestructureerde Markdown-bronbestanden) bevat alle proceskennis in raw data-formaat.

• Geautomatiseerde projecties: via scripts (Python, Bash) en templates worden doelgroepspecifieke documenten gegenereerd, zoals:

  • Werkinstructies voor de werkvloer.

  • Procesbeschrijvingen voor het management.

  • RACI-matrices voor compliance.

Voorbeeld:

Stel, het PDM Canvas bevat de volgende data over een processtap:

id: stap001
naam: "Factuur controleren"
rol: "Financieel Medewerker"
hulpmiddel: "SAP"
informatieobject: "Factuur"
basisregel: "AVG"

Uit deze éne bron kunnen automatisch worden gegenereerd:

• Een werkinstructie voor de Financieel Medewerker.

• Een systeemimpactanalyse als SAP wordt vervangen.

• Een compliance-rapport dat laat zien welke stappen onder de AVG vallen.

De ’no manual edits’ regel

Principe:

Handmatige aanpassingen in gegenereerde documenten zijn strikt verboden. Alle wijzigingen moeten uitsluitend in de bron (SSoT) worden doorgevoerd.

Waarom deze regel cruciaal is:

• Voorkomt inconsistenties: als je een PDF of webpagina handmatig aanpast, klopt deze niet meer met de centrale bron.

• Garandeert automatisering: alleen als de bron de enige waarheid is, kunnen wijzigingen geautomatiseerd doorwerken.

• Vermindert fouten: voorkomt dat medewerkers vergeten aanpassingen door te voeren in alle afgeleide bestanden.

Hoe PDM dit afdwingt:

• Technisch: gegenereerde documenten (PDF’s, HTML) zijn read-only exports voor eindgebruikers.

• Procesmatig: wijzigingen lopen via een RFC-proces (Request for Change), dat wordt geautoriseerd door de Proceseigenaar.

• Cultureel: medewerkers worden getraind om altijd in de bron te denken en te werken.

Graph-gebaseerde relatiestructuur

Principe:

Een proces is geen lineair verhaal, maar een netwerk van onderling verbonden objecten. Wijzigingen in één object moeten automatisch de impact op het hele netwerk tonen.

Hoe PDM dit modelleert:

PDM gebruikt een netwerkbenadering (graph-structuur), waarbij objecten relationeel aan elkaar gekoppeld zijn.

Een processtap is relationeel gekoppeld aan:

• Een Rol (wie voert de stap uit?).

• Een Informatieobject (wat is de input/output?).

• Een Hulpmiddel (welk systeem of tool wordt gebruikt?).

• Een Basisregel (welke wet, norm of kader is van toepassing?).

Voorbeeld:

Stel, het hulpmiddel SAP wordt vervangen door Odoo. In PDM:

1. Pas je in de bron het Hulpmiddel-object aan (van SAP naar Odoo).

2. Het systeem berekent automatisch welke:

   • Processtappen gebruikmaken van SAP.

   • Rollen deze stappen uitvoeren.

   • Informatieobjecten hierbij betrokken zijn.

3. Je genereert direct een systeemimpactanalyse die exact laat zien:

   • Welke workflows geraakt worden.

   • Welke medewerkers getraind moeten worden.

   • Welke werkinstructies vernieuwd worden.

De PDM-bouwstenen: anatomie van het werknetwerk

PDM gebruikt een vaste set bouwstenen om de werkelijkheid van een organisatie foutloos te modelleren. Elk object beschikt over:

• Een uniek ID (bv. proc001, stap012).

• Een vastgesteld type (bv. Proces, Processtap, Rol, Basisregel).

• Gestructureerde metadata (bv. naam, beschrijving, eigenaar).

• Expliciete relaties met andere objecten.

Overzicht van kernobjecten

graph LR
    PR[Proces]
    P[Processtap]
    A[Rol]
    R[Basisregel]
    I[Informatieobject]
    T[Hulpmiddel]
    K[KPI]
    O[Fysiek Object]

    P -->|is onderdeel van| PR
    A -->|voert uit| P
    R -->|conditioneert| P
    I <-->|input/output| P
    T -->|enabler/IT| P
    K -->|meet| P
    O -->|input/output| P

De koppelregels van PDM

PDM hanteert strikte koppelregels om de integriteit van het werknetwerk te waarborgen:

1. Geen directe koppeling tussen processtappen:

   • Regel: Twee processtappen mogen nooit rechtstreeks aan elkaar gekoppeld worden.

   • Oorzaak: Dit zou leiden tot een star, lineair model, terwijl processen in de praktijk netwerken zijn.

   • Oplossing: Er bevindt zich altijd een Informatieobject of Fysiek Object als drager tussen.

   • Voorbeeld:

     Stap A –> Stap B (ongeldig)

     Stap A –> Factuur [Informatieobject] –> Stap B (valide)

2. Rollen zijn gekoppeld aan het functiehuis:

   • Regel: Rollen worden nooit gekoppeld aan individuele persoonsnamen.

   • Oorzaak: Personen wisselen van functie of verlieten de organisatie; functies en rollen blijven bestaan.

   • Voorbeeld:

     Rol: Jan Janssen (ongeldig)

     Rol: Financieel Medewerker (valide)

3. Hulpmiddelen zijn geclassificeerd:

   • Regel: Hulpmiddelen worden gecategoriseerd (bv. ERP, CRM, Office, Schaduw-IT).

   • Oorzaak: Dit maakt gerichte systeemimpactanalyses mogelijk.

4. Basisregels zijn geconditioneerd aan processtappen:

   • Regel: Elke Basisregel moet gekoppeld zijn aan minstens één specifieke Processtap.

   • Oorzaak: Losse regels zonder koppelpunt op de werkvloer zijn onmeetbaar en verhogen compliance-risico’s.

Documentatie als dynamische projectie

In PDM is documentatie geen statisch eindproduct, maar een dynamische weergave (Projectie) van het onderliggende werknetwerk. Doordat alle data in de SSoT relationeel vastligt, kunnen via geautomatiseerde filters, scripts en static site generators (zoals Hugo met het Relearn-thema) verschillende doelgroepspecifieke projecties uit dezelfde bron worden gegenereerd.

Hoe projecties werken

graph LR
    PDM-Canvas["PDM Canvas (SSoT)"]

    subgraph Documentatie[Documentatie]
        direction TB
        DOC[Procesbeschrijving<br>Werkinstructies<br>Rollenmatrix]
    end

    subgraph Projecties[Projecties]
        direction TB
        PR[Processtroom<br>RACI-Matrix<br/>Risico-Matrix<br>Rollenmatrix View<br>Ketenimpact<br>Systeemimpact<br>Kaderoverzicht]
    end

    PDM-Canvas -->|Generatie| Documentatie
    PDM-Canvas -->|Generatie| Projecties

Statische documentatie

Gestructueerde hoofddocumenten, geautomatiseerd gegenereerd uit de SSoT.

Dynamische projecties

Interactieve of visuele weergaven die real-time inzicht bieden in het werknetwerk.

Hoe wordt een projectie gegenereerd?

PDM gebruikt een pijplijnbenadering voor het genereren van projecties:

1. Bronbestand (SSoT): bevat alle procesdata in gestructureerd Markdown/YAML (bv. procesorder-to-cash.md).
2. Filteren: selecteer de relevante data voor de doelgroep (voor een Werkinstructie filter je alleen de processtappen van één specifieke Rol).
3. Pas een Macro (Hugo shortcode) toe om de data om te zetten in de gewenste structuur.
4. Exporteren: genereer het eindproduct in het gewenste formaat (HTML, PDF, CSV) via geautomatiseerde scripts.
5. Publiceren: plaats de gegenereerde bestanden in de online Kennishub (Hugo Relearn).

Governance: fasen, validatiepoorten en rollen

Kwaliteitsborging binnen PDM is een gefaseerd proces waarin borging aan de poort centraal staat. Een traject stroomt pas door naar een volgende fase wanneer de bijbehorende Validatiepoort formeel de status APPROVED heeft gekregen.

Waarom governance cruciaal is

Zonder een strikt governance-proces:

• Wordt kwaliteit niet geborgd: fouten sluipen in de SSoT en propageren door alle afgeleide projecties.

• Ontbreekt eigenaarschap: niemand voelt zich formeel verantwoordelijk voor de onderhoudbaarheid van de documentatie.

• Ontbreekt continue verbetering: wijzigingen worden niet verwerkt en het werknetwerk veroudert alsnog.

PDM introduceert drie lagen van governance:

1. Fasen: heldere trajectstructuur.

2. Validaties: kwaliteitscontroles aan het einde van elke fase.

3. Rollen: duidelijke scheiding van taken, bevoegdheden en verantwoordelijkheden.

De 5 PDM fasen en validatiepoorten

graph LR
    subgraph Fase1["Fase 1: Initiatie"]
        A1["Scopebepaling & Doelen<hr>Validatie 1: Scopeakkoord"]
    end

    subgraph Fase2["Fase 2: Inventarisatie"]
        A2["Interviews & Praktijkdata<hr>Validatie 2: Inventarisatiecheck"]
    end

    subgraph Fase3["Fase 3: Analyse & Structurering"]
        A3["Normaliseren & Koppelen<hr>Validatie 3: Canvas-freeze"]
    end

    subgraph Fase4["Fase 4: Documentatie & Generatie"]
        A4["Genereren Projecties & Audit<hr>Validatie 4: Oplevervalidatie"]
    end

    subgraph Fase5["Fase 5: Continue Borging"]
        A5["Livegang & RFC-Cyclus<hr>Validatie 5: Beheeroverdracht"]
    end

    Fase1 --> Fase2
    Fase2 --> Fase3
	Fase3 --> Fase4
    Fase4 --> Fase5

De validatiepoorten uitgediept

Validatie 1: scopeakkoord

• Doel: garanderen dat alle partijen eenduidig weten wat de reikwijdte en doelstellingen van het traject zijn.

• Betrokkenen: Proceseigenaar, Model Steward, Operationeel Expert.

• Criteria: Scope is SMART geformuleerd, randvoorwaarden en interviewplanning zijn akkoord.

Validatie 2: inventarisatiecheck

• Doel: garanderen dat alle feitelijke praktijkdata (inclusief uitzonderingen en schaduw-IT) compleet is verzameld.

• Betrokkenen: Model Steward, Operationeel Expert.

• Criteria: geen hiaten in de processtappen, schaduw-IT volledig in kaart gebracht.

Validatie 3: canvas-freeze

• Doel: het PDM Canvas als Single Source of Truth formeel bevriezen en vastleggen.

• Betrokkenen: Proceseigenaar, Model Steward.

• Criteria: alle objecten uniek geïdentificeerd, koppelregels getoetst, geen zwevende objecten.

Validatie 4: oplevervalidatie

• Doel: valideren dat gegenereerde projecties en werkinstructies foutloos en praktisch bruikbaar zijn.

• Betrokkenen: Proceseigenaar, Model Steward, Operationeel Expert.

• Criteria: geautomatiseerde generatie succesvol verlopen, positieve doelgroeptoets op de werkvloer.

Validatie 5: beheeroverdracht

• Doel: overdracht van het project naar de staande organisatie voor permanent beheer.

• Betrokkenen: Proceseigenaar, Model Steward, Beheerorganisatie.

• Criteria: RFC-procedure geactiveerd, Regel B6 (de periodieke schouw) geborgd in de organisatie-agenda.

De 3 PDM kernrollen

PDM verdeelt de verantwoordelijkheden strikt over drie sleutelrollen:

Samenwerking tussen de 3 rollen

De drie rollen vormen een gesloten kwaliteitscirkel binnen het PDM-beheermodel:

graph TD
    PO[Proceseigenaar\nStrategisch & Besluitvormend]
    MS[Model Steward\nTechnisch & Syntactisch]
    OE[Operationeel Expert\nInhoudelijk & Praktijk]

    PO -->|1. Verleent scope & goedkeuring| MS
    MS -->|2. Modelleert & genereert projecties| OE
    OE -->|3. Toetst praktijk & dient RFC in| PO
    PO -->|4. Autoriseert RFC| MS
    MS -->|5. Werkt SSoT bij| PO

1. Proceseigenaar (Strategisch & Besluitvormend):

   Focus op wat er gedocumenteerd moet worden en waarom. Hij/zij stuurt op kaders, autoriseert de validatiepoorten en beslist over inhoudelijke wijzigingen (RFC’s).

2. Model Steward (Technisch & Syntactisch):

   Focus op hoe het werknetwerk gemodelleerd wordt. Hij/zij bewaakt de PDM-standaarden, beheert de Markdown-bronbestanden in Git en zorgt dat alle projecties foutloos worden gegeneerd.

3. Operationeel Expert (Inhoudelijk & Praktijk):

   Focus op de feitelijke uitvoering. Hij/zij levert de input van de werkvloer, toetst de bruikbaarheid van de gegenereerde werkinstructies en geeft via het RFC-proces aan wanneer de praktijk verandert.

Door deze strikte rolverdeling wordt voorkomen dat een procesanalist op de stoel van de proceseigenaar gaat zitten, of dat de werkvloer geconfronteerd wordt met onuitvoerbare theoretische modellen.

Conclusie en resultaat

Door de PDM Standaard te implementeren, stapt een organisatie definitief uit de spiraal van verouderde handboeken, versiechaos en ad-hoc hersteloperaties.

Het resultaat in de praktijk

• 100% Datasoevereiniteit: volledige controle over eigen proceskennis opgeslagen in open standaarden (Markdown/Git).

• Minimale Beheerlast: één wijziging op de bron (SSoT) past geautomatiseerd alle afgeleide documenten, diagrammen en matrices aan (No Manual Edits).

• Maximale Wendbaarheid: bij IT-migraties of reorganisaties is met één druk op de knop inzichtelijk welke rollen, processtappen en informatie-elementen worden geraakt.

• Permanente Audit-Readiness: aantoonbare borging van kaders, wetgeving (AVG, ISO) en risico’s tot op het niveau van de individuele werkinstructie.

Copyright & Licentie

© 2026 Martin van Pelt / De Procesdocumentalist.

Dit werk is gelicentieerd onder de Creative Commons Naamsvermelding-NietCommercieel-GeenAfgeleideWerken 4.0 Internationaal-licentie (CC BY-NC-ND 4.0).

Het staat u vrij om dit document te delen, te kopiëren en te verspreiden via elk medium of formaat, onder de volgende voorwaarden:

• Naamsvermelding: U dient de auteur (Martin van Pelt / De Procesdocumentalist) te vermelden en een link naar de licentie op te nemen.
• Niet-commercieel: U mag dit werk niet gebruiken voor commerciële doeleinden.
• Geen afgeleide werken: U mag het materiaal niet remixen, veranderen of erop voortbouwen om het vervolgens te verspreiden.

Voor uitzonderingen of commercieel gebruik van de PDM-methodiek kunt u contact opnemen via procesdocumentalist.nl.

Over de auteur

Martin van Pelt is een onafhankelijk Procesdocumentalist en Procesanalist met ruim 35 jaar ervaring in de IT- en telecomsector. Als grondlegger van de Procesdocumentatie Methode (PDM) helpt hij organisaties bij het transformeren van complexe, ongestructureerde documentatie naar een strak, beheersbaar en toekomstbestendig werknetwerk.

Meer weten of de PDM Standaard toepassen binnen uw organisatie? Kijk op procesdocumentalist.nl.