DMN (Decision Model and Notation)

Wat is DMN?

DMN, voluit Decision Model and Notation, is de standaard om een bedrijfsbeslissing zo op te schrijven dat de persoon die de regel bezit en de software die ze uitvoert hetzelfde lezen. De standaard wordt beheerd door de Object Management Group, dezelfde organisatie achter BPMN, en de twee horen samen: het procesmodel tekent hoe het werk loopt, het beslissingsmodel bevat de beslissingen waar die loop van afhangt.

Je krijgt twee dingen. Een grafische notatie toont welke beslissingen er zijn en waarvan ze afhangen. Een expressietaal, FEEL, schrijft de logica zelf, meestal als een beslissingstabel. Het lemma over de beslissingstabel in dit woordenboek behandelt het raster en de hit policies. DMN is de standaard rond dat raster: hoe een beslissing heet, waar haar inputs vandaan komen, hoe ze als XML tussen tools reist, en hoe een engine ze moet evalueren.

Versie 1.5, aangenomen in augustus 2024, is de meest recente formeel goedgekeurde release. Van 1.6 en 1.7 zijn sindsdien beta's gepubliceerd, en engines lopen voor op die formele goedkeuring: Apache KIE ondersteunt DMN 1.6 sinds april 2026. Voor een eerste beslissingsmodel telt het conformiteitsniveau meer dan het versienummer. Niveau 3 is het niveau waarop een model niet alleen te tekenen maar ook uitvoerbaar is.

Waarom de beslissing uit het procesmodel gehaald wordt

Teken een kortingsregel in BPMN en je krijgt gateways. Klanttype splitst in drie, orderwaarde in vier, en de tekening die moest tonen hoe een bestelling vertrekt bestaat plots vooral uit ruiten. SAP Signavio maakt dat punt met een voorbeeld rond productkorting: zelfs een vrij eenvoudige beslissing levert een procestekening op die moeilijk leesbaar is en snel fouten bevat. De beslissing is niet verdwenen, ze zit uitgesmeerd over de processtappen waar niemand ze in haar geheel ziet.

De tweede reden is tempo. Een proces verandert wanneer het bedrijf zich herorganiseert, misschien een keer per jaar. De regels erin veranderen wanneer een prijslijst opschuift of een leverancierscontract heronderhandeld wordt. Twee dingen die op een ander ritme wijzigen horen niet in een bestand dat een ontwikkelaar opnieuw moet uitrollen telkens de salesmanager een drempel bijstelt. Hergebruik volgt uit dezelfde splitsing: een kredietwaardigheidsbeslissing die in het offerteproces, het orderproces en de aanmaningen gebruikt wordt is een beslissing die je drie keer aanroept, geen drie kopieën die stilaan uit elkaar groeien tot een klant in dezelfde week twee verschillende antwoorden krijgt.

De twee niveaus van een DMN-model

Het bovenste niveau is het decision requirements diagram, kortweg DRD, en dat zegt wat er beslist wordt. Er zitten vier soorten elementen in. Een beslissing is een blok dat een uitkomst oplevert en andere beslissingen kan vereisen, zodat het resultaat van de ene in de volgende terechtkomt. Input data is een gegeven dat van buiten komt, zoals het gewicht van de bestelling of het contract van de klant. Een business knowledge model is logica die je in meer dan een beslissing wil hergebruiken. Een knowledge source benoemt de autoriteit achter een regel: een beleidsdocument, een stuk wetgeving, of iemand met naam en toenaam.

De documentatie van Camunda is duidelijk over die laatste twee: een knowledge source en input data hebben geen uitvoeringssemantiek en worden bij de evaluatie genegeerd. Ze staan er voor de lezer, en dat is geen zwakte. Kunnen wijzen naar een blok en zeggen dat een regel uit het transportbeleid van 2025 komt en dat de transportverantwoordelijke er eigenaar van is, is de halve reden om het diagram te tekenen.

Het onderste niveau is de beslissingslogica, en dat zegt hoe. Elk beslissingsblok krijgt een boxed expression, in de praktijk bijna altijd een beslissingstabel: de inputs bovenaan, een regel per rij, de uitkomst in de laatste kolom.

FEEL, de Friendly Enough Expression Language, vult de cellen. Ze zit in de DMN-specificatie zelf en leest dichter bij een formule in een rekenblad dan bij code. x < 5 and (y > 10 or z > 20) is FEEL, en if (5 < 10) then "low" else "high" ook. Trisotech omschrijft de bedoelde auteur als een doorsnee Excel-poweruser: iemand die met formules overweg kan, maar geen programmeur is. In een beslissingstabel bevatten de meeste cellen één vergelijking of één bereik, dus verder dan dat kom je zelden.

Een leveringstoeslag, uitgewerkt

Een Belgische groothandel bepaalt de leveringstoeslag op vier gegevens: heeft de klant een leveringscontract, welke zone, welk serviceniveau en welk gewicht. Als DMN-beslissingstabel past dat in acht rijen.

Beslissing: Leveringstoeslag
Hit policy: FIRST

 #  Contract  Zone    Levering    Gewicht   Toeslag
 1  ja        BE      standaard   <= 30      0,00
 2  ja        BE      standaard   > 30      12,00
 3  ja        BE      express     -         15,00
 4  ja        NL, LU  -           -         25,00
 5  nee       BE      standaard   <= 30      7,50
 6  nee       BE      standaard   > 30      15,00
 7  nee       BE      express     -         20,00
 8  -         -       -           -         45,00

Vier inputs met twee, drie, twee en twee mogelijke waarden geven vierentwintig combinaties. Rij één tot zeven dekken er twaalf. De andere twaalf vallen door naar rij acht, de vangnetregel, aan 45 euro.

Lees dat voor aan de salesmanager en er komt meteen iets boven. Een contractklant die naar Luxemburg levert betaalt 25 euro. Diezelfde contractklant die naar Duitsland levert betaalt 45 euro, precies evenveel als een klant zonder contract. Buiten de Benelux levert het contract niets op. Niemand heeft dat beslist, het is wat die acht rijen toevallig doen. Daar zit het argument om een beslissing als tabel te schrijven in plaats van als code: het gat zat er altijd al, en de vorm is wat het zichtbaar maakte in een vergadering en niet in een klachtenmail.

Hoe een DMN-beslissing draait en traceerbaar blijft

Een DMN-engine krijgt het model en de inputwaarden en geeft de uitkomst terug. Ze houdt geen toestand bij, wacht op niemand, en geeft bij dezelfde inputs hetzelfde antwoord. Net door die smalle taak bestaan DMN-engines zowel apart, aanroepbaar via een API, als ingebouwd in procesengines.

In een procesengine gebeurt de aanroep via een business rule task in het BPMN-diagram. Bij Camunda noemt die taak de beslissing bij id en zegt ze in welke procesvariabele het resultaat landt. Ook al gebruik je Camunda nooit, wat daarna komt is het overnemen waard: dezelfde taak legt vast welke versie van de beslissing draait. Je bindt ze aan de laatst uitgerolde versie, aan de versie die samen met het lopende proces werd uitgerold, of aan de laatste versie met een bepaalde version tag.

Daar zit de auditeerbaarheid. Een regelwijziging wordt een nieuwe versie van een artefact met een datum, een auteur en een reden, in plaats van een aangepaste lijn code in een release. Bewaar bij elke uitkomst de versie en het id van de regel die paste. Vraagt een klant in oktober waarom hij in maart 45 euro betaalde, dan haal je de maartversie van de tabel boven, laat je zijn bestelling van toen er nog eens door lopen en toon je hem de rij. Zonder die versie kan je alleen gissen naar wat er destijds in de tabel stond.

DMN tegenover een regel in code of in een BPMN-gateway

De drie opties doen hetzelfde werk. Ze verschillen op een punt dat de rest bepaalt: wie de regel mag wijzigen, en wie achteraf kan reconstrueren wat ze gedaan heeft.

Een regel in applicatiecode. Wijzigen betekent een ticket, een ontwikkelaar, een review en een release. Nakijken betekent een diff lezen in een repository waar de business niet bij kan, en de ingangsdatum is de dag van de uitrol, die weken na de beslissing kan liggen.

Een regel in een BPMN-gateway. Beter, want zichtbaar in een tekening die de business leest. In de praktijk slechter zodra er meer dan een handvol voorwaarden zijn, want de logica ligt verspreid over takken en je ziet niet welke combinaties je vergeten bent. Wijzigen betekent het proces opnieuw uitrollen, en dan komt de vraag terug wat er met de lopende dossiers gebeurt.

Een regel in een DMN-tabel. De eigenaar opent de tabel, ziet alle rijen in één keer, past één cel aan, en die wijziging wordt een nieuwe versie met zijn naam erop. Het procesmodel blijft ongemoeid. Dat is het hele argument voor de standaard: niet dat een tabel er mooier uitziet, wel dat ze de regel legt bij wie er verantwoordelijk voor is en een spoor achterlaat.

De keerzijde is dat je twee artefacten in de pas moet houden, en een beslissing met maar één voorwaarde heeft dit allemaal niet nodig. Een tabel verdient haar plek zodra de combinaties niet meer in je hoofd passen, of zodra de regel vaker wijzigt dan de software eromheen.

DMN naast een LLM

Zodra een bedrijf een model heeft dat een contract kan lezen, komt de verleiding om het ook te laten beslissen: vraag het wat de leveringstoeslag moet zijn, geef het transportbeleid mee en sla de tabel over.

Doe dat niet voor een beslissing die reproduceerbaar moet zijn. Een DMN-tabel geeft bij dezelfde inputs elke keer dezelfde uitkomst, en de rij die paste staat genoteerd. Een model dat je twee keer hetzelfde vraagt kan twee keer iets anders antwoorden, en een prompt is geen artefact met een versie en een eigenaar. Camunda deelt het in zijn eigen richtlijnen op dezelfde manier op: regels passen waar beslissingen deterministisch zijn en waar audit en compliance meespelen, agents passen waar de input rommelig of ongestructureerd is en waar taal begrepen moet worden.

Voor de meeste bedrijven wordt dat een taakverdeling in plaats van een keuze. Laat een model de binnenkomende mail lezen en het gewicht, de zone en het serviceniveau uit een vormvrije aanvraag halen, en geef die vier waarden door aan de tabel. Laat het een nieuwe rij voorstellen en in gewone taal uitleggen wat de bestaande regels doen, wat echt helpt zodra een tabel tot zestig rijen gegroeid is en niemand nog weet waarom rij negentien er staat. De eigenaar van de regel keurt die rij dan goed en de engine voert ze uit. Het model werkt op de inputs en op de uitleg. De beslissing zelf zit in de tabel.

In een agentic proces geldt dezelfde redenering omgekeerd. Elke beslissing die je als tabel kan uitschrijven hoort een tabel te zijn die de agent als tool aanroept, en geen inschatting die je aan het model overlaat. Zo hou je het stuk dat je moet testen klein genoeg om echt te testen.