PDM Formele Specificatie

Het Werknetwerk

PDM is een formeel model ontworpen voor het vastleggen, beheren en publiceren van proceskennis. In plaats van te vertrouwen op gefragmenteerde tekstbestanden en losse diagrammen, dwingt PDM de constructie van een integraal ‘werknetwerk’ af.

Dit netwerk fungeert als de Single Source of Truth (SSoT): één centrale kennisstructuur waarin elk aspect van de bedrijfsvoering exact één keer wordt vastgelegd. Binnen deze methodiek is documentatie geen vrijblijvend handgeschreven product, maar een model-gedreven weergave (projectie) van de vastgelegde kennis.

Wijzigingen worden uitsluitend in de bron van het model doorgevoerd, waarna alle documentatie en views consistent worden bijgewerkt.

De zeven bouwstenen

Om wildgroei aan informatie te voorkomen en een minimalistische, analyseerbare structuur te borgen, onderscheidt de grammatica van PDM exact zeven fundamentele werkobjecten:

  1. Proces: Definieert een afgebakend werkdomein en fungeert als container voor samenhangende activiteiten.
  2. Processtap: Beschrijft een feitelijke, uitvoerbare, operationele activiteit die door een uitvoerder wordt verricht.
  3. Informatieobject: Beschrijft de specifieke informatie (digitaal of analoog datagedreven) die binnen het netwerk wordt gebruikt of geproduceerd; dit object bepaalt de feitelijke informatieve samenhang in het werk.
  4. Fysiek Object: Beschrijft de materiële/tastbare stromen (grondstoffen, halffabrikaten, eindproducten, fysieke documenten als bedrijfsmiddel) die binnen het netwerk worden getransformeerd of verplaatst; dit object bepaalt de logistieke of materiële samenhang.
  5. Uitvoerder (Actor): Beschrijft de rollen (mensen) of abstracte actoren die de capaciteit leveren om het werk daadwerkelijk uit te voeren.
  6. Hulpmiddel (Middel): Beschrijft de operationele enablers (software, applicaties, machines, gereedschappen, sjablonen) die noodzakelijk zijn om een processtap te kunnen faciliteren, zonder dat het middel zelf wordt geconsumeerd of getransformeerd.
  7. Regel: Beschrijft de beperkingen, verplichtingen, wetgeving of afspraken waaraan de uitvoering van het werk moet voldoen.

Strikte integriteits- en identificatieregels

Een werknetwerk ontleent zijn analytische en audit-waarde aan de rigoureuze identificatie van zijn objecten. Hierbij gelden de volgende dwingende standaarden:

  • Unieke Identificatie: Ieder object beschikt over exact één unieke, permanente identifier (ID) die nooit wijzigt gedurende de levenscyclus van het model.
  • Ontkoppeling van Personen: Uitvoerders worden uitsluitend gedocumenteerd als abstracte rollen (bijv. “Servicedeskmedewerker”), waardoor het model volledig onafhankelijk blijft van personele wisselingen.
  • Naam-onafhankelijkheid: De identiteit van een object is nooit afhankelijk van zijn naam, aangezien terminologie aan verandering onderhevig is.
Specificatie van objectattributen
ObjecttypeVerplichte AttributenOptionele AttributenSpeciale Logica / Voorwaarden
Procesid, naamdoel, scope, eigenaar, status, versie, bovenliggend procesFungeert als organisatorische container.
Processtapid, naamactie, omschrijving, duur, prioriteitActor, duur en prioriteit zijn verplicht bij weergave in de Flow View. Actief taalgebruik is voorgeschreven.
Informatieobjectid, naamdrager, omschrijving, categorie, statusDrager (opslaglocatie, zoals een map of informatiemedium) is verplicht in de Flow View.
Fysiek Objectid, naamomschrijving, eenheid, statusBepaalt de materiële instroom en uitstroom binnen het model.
Uitvoerderid, naam, type UitvoerderstatusType Uitvoerder moet strikt worden gecategoriseerd als Mens (Rol), Machine/Automaat, Extern of Hybride.
Hulpmiddelid, naam, type Middelversie, omschrijving, eigenaar, statusType Middel moet strikt worden gecategoriseerd als Digitaal (Applicatie/Sjabloon) of Materieel (Machine/Gereedschap).
Regelid, naamomschrijving, type regel, bron, statusDient om kaders expliciet te maken zonder de procesvolgorde te breken.

Relationele architectuur en validatie

Relaties vormen de ruggengraat van het netwerk en bepalen de feitelijke flow van het werk, onafhankelijk van een vooraf bepaalde nummering of visuele positionering. De flow ontstaat puur uit de afhankelijkheden tussen processtappen, informatieobjecten en fysieke objecten.

Toegestane verbindingen in het Metamodel
  • Proces $\rightarrow$ bevat $\rightarrow$ Processtap: Elke processtap behoort tot exact één proces ($1..N : 1$ kardinaliteit).
  • Uitvoerder $\rightarrow$ voert uit $\rightarrow$ Processtap: Elke processtap vereist minimaal één uitvoerder die gekoppeld is via de relatie “voert uit”.
  • Processtap $\rightarrow$ produceert $\rightarrow$ Informatieobject: Een stap levert informatie of een status op als resultaat (output).
  • Informatieobject $\rightarrow$ gebruikt door $\rightarrow$ Processtap: Een stap heeft dit specifieke object nodig als input om te kunnen starten.
  • Processtap $\rightarrow$ produceert $\rightarrow$ Fysiek Object: Een stap levert een materieel resultaat op, of transporteert/verplaatst een object naar een nieuwe status (output).
  • Fysiek Object $\rightarrow$ gebruikt door $\rightarrow$ Processtap: Een stap heeft dit specifieke materiële object of deze grondstof nodig als input om te kunnen starten of transformeren.
  • Hulpmiddel $\rightarrow$ faciliteert $\rightarrow$ Processtap: Definieert welk specifiek middel (tool of machine) noodzakelijk is om de processtap uit te kunnen voeren.
  • Regel $\rightarrow$ beïnvloedt $\rightarrow$ Processtap: Bepaalt de randvoorwaarden en operationele kaders waarbinnen de activiteit moet plaatsvinden.

Afgeleide Relatielogica: Hoewel relaties zoals “Proces bevat Uitvoerder” of “Proces gebruikt Hulpmiddel” niet direct handmatig worden gecodeerd, worden deze logisch afgeleid via de actieve koppeling van de uitvoerders en hulpmiddelen aan de onderliggende processtappen binnen dat proces.

Visuele Representatie (Views)

Wanneer het werknetwerk wordt geprojecteerd in diagrammen, is de grafische vormcodering gestandaardiseerd om universele leesbaarheid te garanderen.

Bij gebruik van de Zoom-functionaliteit in de Flow View transformeert een processtap van een enkelvoudige activiteit naar een uitgebreide weergave waarin alle zeven gekoppelde bouwstenen rondom de processtap zichtbaar worden gemaakt.

  • Proces: Wordt afgebeeld als een Hexagon (Zeshoek).
  • Processtap: Wordt afgebeeld als een Rounded Rectangle (Afgeronde rechthoek).
  • Informatieobject: Wordt afgebeeld als een Rectangle (Rechthoek).
  • Fysiek Object: Wordt afgebeeld als een Parallellogram (Schuine rechthoek, symbool voor materiële input/output).
  • Uitvoerder: Wordt afgebeeld als een Stadium (Rechthoek met halfronde zijkanten).
  • Hulpmiddel: Wordt afgebeeld als een Trapezium (Taps toelopende vorm, symbool voor ondersteuning/enabler).
  • Regel: Wordt afgebeeld als een Dashed Rectangle (Gestippelde rechthoek).
Primaire Perspectieven (Views)
  1. Flow View: Toont hoe informatieobjecten en fysieke objecten chronologisch als input en output fungeren tussen processtappen en welke actoren, hulpmiddelen en regels hierbij betrokken zijn. Ondersteunt ‘zoomen’ per processtap voor detailinzage.
  2. Domein View: Geeft een statisch, inhoudelijk overzicht van welke stappen, uitvoerders, hulpmiddelen, objecten en regels gezamenlijk onderdeel zijn van een specifiek werkdomein, zonder een chronologische flow te tonen.
  3. Uitvoerder View (Actor View): Toont het werk strikt vanuit het perspectief van één specifieke rol; het isoleert welke taken worden uitgevoerd, welke hulpmiddelen en objecten hiervoor nodig zijn en welke regels van toepassing zijn.
  4. Relatie View: Toont alle directe en indirecte afhankelijkheden van een specifiek object ten behoeve van impactanalyses (bijv. “welke processtappen kunnen niet doorgaan als dit Hulpmiddel niet beschikbaar is?”) en governance.

De PDM-werkwijze en kwaliteitsfases

De transitie van de dagelijkse praktijk naar een gevalideerd, betrouwbaar model verloopt via vijf gestructureerde fasen, gescheiden door kritische kwaliteitsgates:

graph LR
    F1(Fase 1: Scope) --> G1[Gate 1]
    G1 --> F2(Fase 2: Inventarisatie)
    F2 --> G2[Gate 2]
    G2 --> F3(Fase 3: Analyse)
    F3 --> G3[Gate 3]
    G3 --> F4(Fase 4: Modellering)
    F4 --> G4[Gate 4]
    G4 --> F5(Fase 5: Validatie)
  1. Fase 1 – Opdracht & Scopebepaling: Vaststellen van het te onderzoeken werkdomein. Exit-criterium (Gate 1): Formele acceptatie van de scopebeschrijving en de initiële proceslijst door de opdrachtgever en proceseigenaar.
  2. Fase 2 – Inventarisatie: Verzamelen van feitelijke operationele kennis (IST-situatie) via interviews, workshops en observaties op de werkvloer. Exit-criterium (Gate 2): Oplevering van een ‘ruwe, rijke objectenlijst’ (inclusief gebruikte hulpmiddelen en fysieke materialen) en een eerste voorafgaande consolidatie van synoniemen (genormaliseerde begrippenlijst).
  3. Fase 3 – Analyse & Structurering: Vertalen van de ruwe praktijkkennis naar de formele netwerklogica. Activiteiten omvatten objectanalyse, deduplicatie (het ‘platstaan’ van synoniemen) en relatieanalyse. Exit-criterium (Gate 3): Een goedgekeurd conceptueel werknetwerk zonder ‘zwevende’ objecten of logische weeffouten.
  4. Fase 4 – Modellering & Documentatie: Het formeel vastleggen van de objecten en relaties binnen de modelstructuur en het genereren van de documentatieset (procesbeschrijvingen, werkinstructies, uitvoerderprofielen en overzichten). Exit-criterium (Gate 4): Een succesvolle consistentiecheck; verifiëren dat er geen handmatige aanpassingen buiten de modelbron om zijn gedaan (Single Source of Truth audit).
  5. Fase 5 – Validatie & Oplevering: Finale kwaliteitscontrole waarbij het model via gestructureerde reviewsessies met stakeholders en experts aan de realiteit wordt getoetst. Einddecharge: Formele ondertekening en overdracht naar de lijnorganisatie voor continu beheer. Het model is vanaf dit moment bevroren en mag niet meer handmatig buiten de modelbron om gewijzigd worden.

Harde wetten & validatieregels (kwaliteitsborging)

Om de logische sluitendheid van het werknetwerk te garanderen, moet elk model vóór publicatie (tijdens Gate 4) aan de onderstaande validatieregels voldoen. Indien een regel wordt geschonden, is het model incompleet en is de gegenereerde weergave ongeldig.

Syntactische regels (Modelstructuur)
  • Regel S1 (Geen zwevende objecten): Elk object in het model moet via minimaal één geldige relatie verbonden zijn met het netwerk. Losgekoppelde of ‘zwevende’ objecten zijn niet toegestaan.
  • Regel S2 (Processtap-isolatie): Een processtap mag nooit direct aan een andere processtap gekoppeld worden. De verbinding verloopt altijd via de informatiestroom of materiële stroom (Stap A produceert Object X $\rightarrow$ Object X wordt gebruikt door Stap B).
  • Regel S3 (Kardinaliteitscontrole): Elke processtap bezit exact één voert uit relatie met een Uitvoerder. Een processtap zonder actor is een syntaxfout.
  • Regel S4 (Hulpmiddel-isolatie): Een Hulpmiddel kan nooit rechtstreeks gekoppeld worden aan een Informatieobject of Fysiek Object. De interactie verloopt altijd dwingend via de faciliteert relatie met een Processtap.
Semantische regels (taal en naamgeving)
  • Regel T1 (Actieve schrijfwijze): De naam van een Processtap volgt dwingend de structuur: [Actief Werkwoord] + [Zelfstandig Naamwoord] (bijv. “Controleren Factuur”, niet “Controle” of “De factuur wordt gecontroleerd”).
  • Regel T2 (Passieve informatie): Een Informatieobject of Fysiek Object mag geen werkwoord bevatten. Het beschrijft puur de drager, de dataset of het materiaal (bijv. “Ingevuld urenverantwoording-formulier” of “Houten pallet”, niet “Uren invullen” of “Pallet laden”).
  • Regel T3 (Strikte de-duplicatie): Synoniemen zijn verboden in het model. Als afdelingen verschillende woorden gebruiken voor hetzelfde object of hulpmiddel (bijv. “Klantkaart” en “Cliëntprofiel”, of “ERP” en “Het voorraadsysteem”), dwingt de documentalist in Fase 3 één definitieve term af.
Governance & compliance regels
  • Regel G1 (Eigenaarschap): een Proces kan pas naar de productiestatus (Fase 5) overgaan als het attribuut eigenaar is gevuld met een geldige, bestaande rol binnen de organisatie.
  • Regel G2 (Geen persoonsnamen): het invoeren van persoonsnamen in het attribuut naam of omschrijving bij een Uitvoerder of Hulpmiddel leidt tot een directe afkeuring bij de kwaliteitsgate (bijv. “De Excel-sheet van Jan” is verboden; dit wordt “Sjabloon Productieplanning”).
  • Regel G3 (Kaderbepaling): een Regel mag de processtroom nooit onderbreken of splitsen. Een regel mag uitsluitend via de verbinding beïnvloedt randvoorwaarden opleggen aan een bestaande processtap.