BPMN-stijlgids

Het probleem

Grote organisaties tekenen hun processen als diagrammen: wie doet wat, in welke volgorde, en waar de beslissingen zitten. BPMN 2.0 is daarvoor de standaardnotatie. Die vertelt je welke vormen bestaan, niet hoe een bepaald bedrijf ze gebruikt. Dus schrijft elke organisatie er een stijlgids bovenop: benoem taken als "werkwoord + object", formuleer gateways als vragen, gebruik nooit complexe gateways, splits een proces zodra het een bepaalde omvang passeert.

De twee tools waarin mensen daadwerkelijk tekenen, Enterprise Architect en Draw.io, gebruiken volstrekt verschillende XML-formaten, dus een model uit de een is niet over te zetten naar de ander.

Wat het doet

Drie ingangen: een geschreven procedure, een vergadertranscript, of een bestaand model dat je gecorrigeerd wilt hebben. Eén uitgang: een BPMN-diagram dat je stijlgids volgt, te downloaden als standaardconforme .bpmn voor Enterprise Architect en als mxGraph-XML voor Draw.io.

De stijlgids zelf is het kernobject. Upload je bestaande gids als document en Claude haalt de regels eruit als gestructureerde JSON, die je daarna bewerkt in een formulier voor naamgevingspatronen, toegestane elementtypen, structurele grenzen, uitlijnrichting, plus eigen regels in vrije tekst. Gidsen worden bewaard en hergebruikt over generaties heen.

Gegenereerde diagrammen openen in een bewerkbaar canvas. Een linter toetst de XML aan de opgeslagen gids en prikt overtredingsmarkeringen op de vormen die de fout maken: elementen zonder label, losgekoppelde knopen, gateways die niet als vraag geformuleerd zijn, taaktypen die de gids verbiedt. Pas je het diagram aan, dan lint hij al doende opnieuw.

Het lastige deel

Een diagram tekenen uit een rommelige beschrijving is niet het moeilijke deel. Er een maken dat geldige notatie is, dat de afspraken van één specifieke organisatie volgt, en dat correct opent in allebei de tools waarin mensen echt tekenen, dat is het moeilijke deel.

De verleidelijke sluiproute is een model de regels laten lezen, het diagram laten lezen, en laten zeggen of het voldeed. Dat gaat precies zo mis als je zou verwachten. Het is meegaand, het spreekt zichzelf tegen tussen runs, en een analist kan niet in discussie met een oordeel dat geen onderbouwing aan een vorm hangt. Naleving moest mechanisch getoetst worden, zodat een overtreding altijd dezelfde overtreding is en altijd wijst naar het element dat haar veroorzaakte.

Een tweede tekentool ondersteunen moest bovendien een toevoeging zijn en geen herschrijving, en die randvoorwaarde heeft alles bepaald wat eraan voorafgaat. Het blijft een prototype, en het draait op Claude.

Waar het nu staat

De extractor, de linter en de serialisers landden binnen één dag, en de repo is stil sinds begin mei 2026.

Een werkend prototype, geen afgerond product. Het draait vandaag van begin tot eind: geef het een geschreven procedure, een vergadertranscript of een bestaand model, en je krijgt een diagram terug dat je stijlgids volgt, exporteerbaar naar allebei de tools waarin analisten echt tekenen. Overtredingen worden mechanisch benoemd en vastgeprikt op de vorm die ze veroorzaakte. De wijzigingsrapporten en het aannamelogboek worden wel gegenereerd maar nog niet getoond. De volgende echte mijlpaal is het voorleggen aan een analist die het niet gebouwd heeft.