Beslisregels horen niet verstopt in code
Krijgt deze klant korting? Valt deze aanvraag in een hoge risicoklasse? Mag dit verzoek automatisch door, of moet er een medewerker naar kijken? Elke organisatie neemt dagelijks duizenden van zulke kleine beslissingen. Achter elk ervan zit een regel. De vraag is alleen: waar staat die regel, en wie kan hem lezen?
Waar de regels nu meestal zitten
In de praktijk kom ik beslisregels op drie plekken tegen.
- In de code. Ergens in een applicatie staat een rij
if-statements. Die doet precies wat hij moet doen, maar alleen een ontwikkelaar kan hem lezen. Wil de business een grens aanpassen, dan wordt het een wijzigingsverzoek, een release en een paar weken wachten. - In een spreadsheet of document. Goed leesbaar, maar het is een beschrijving van de regel, niet de regel zelf. Na een paar jaar zijn het document en de applicatie het stilletjes niet meer met elkaar eens.
- In iemands hoofd. “Dat weet Ans wel.” Tot Ans met pensioen gaat.
Alle drie hebben hetzelfde probleem: de regel die de business bedoelt en de regel die het systeem uitvoert, zijn twee verschillende dingen. Met DMN worden ze één ding.
Wat DMN is
DMN staat voor Decision Model and Notation. Het is een open standaard van de Object Management Group, dezelfde organisatie achter BPMN voor procesmodellen. Waar BPMN beschrijft wat er gebeurt en in welke volgorde, beschrijft DMN hoe een beslissing tot stand komt.
Het hart van DMN is de beslistabel. Links staan de voorwaarden, rechts de uitkomst, en elke rij is één regel. Een vereenvoudigd voorbeeld:
| Regel | Klanttype | Orderbedrag | Korting |
|---|---|---|---|
| 1 | partner | – | 15% |
| 2 | zakelijk | ≥ 5000 | 12% |
| 3 | zakelijk | 1000 tot 5000 | 8% |
| 4 | – | – | 0% |
Een streepje betekent: maakt niet uit. Iedereen die het bedrijf kent, kan deze tabel lezen en zeggen of hij klopt. En een beslisengine kan precies deze tabel uitvoeren, zonder dat iemand hem eerst naar code vertaalt.
Wie wil zien hoe dat werkt, kan het zelf uitproberen in de demo: vul een bestelling in en zie welke regel de doorslag geeft.
Wie wint als meerdere regels passen?
Kijk nog eens naar de tabel. Een partner met een order van € 6.000 past bij regel 1 én bij regel 4. Welke geldt?
DMN dwingt u die vraag expliciet te beantwoorden met een hit policy. De meest gebruikte zijn:
- Unique: er mag altijd maar één regel passen. Passen er twee, dan is de tabel fout. Streng, maar daardoor vindt u gaten en overlap meteen.
- First: de regels worden van boven naar beneden gelezen en de eerste die past, wint. Handig voor een tabel met uitzonderingen bovenaan en een vangnet onderaan, zoals hierboven.
- Collect: alle passende regels tellen mee, bijvoorbeeld om alle redenen voor een handmatige controle te verzamelen.
Dat klinkt als een detail, maar juist hier zitten in code vaak de fouten. De volgorde
van if-statements bepaalt stilzwijgend de uitkomst, en niemand heeft die volgorde
ooit bewust gekozen. In DMN staat de keuze bovenaan de tabel.
Waarom het loont
Eén bron van waarheid. De tabel die de business goedkeurt, is de tabel die wordt uitgevoerd. Er is geen vertaalslag meer waarin iets verloren kan gaan.
Toetsbaar. Per regel kunt u een testgeval maken: deze invoer, deze uitkomst. Zo toetst u een wijziging voordat hij live gaat, en ziet u ook welke regels nooit worden geraakt.
Uitlegbaar. Bij elke beslissing kunt u laten zien welke regel de doorslag gaf. Bij beslissingen over mensen is dat geen luxe. Als een klant vraagt waarom zijn aanvraag is afgewezen, wilt u een beter antwoord dan “dat zegt het systeem”.
Wendbaar. Een grens verschuiven van € 5.000 naar € 4.000 is het aanpassen van één cel, niet een ontwikkeltraject.
Waar u op moet letten
DMN is geen wondermiddel. Een paar valkuilen die ik vaak zie:
- Te grote tabellen. Een tabel met tachtig regels en twaalf kolommen is net zo onleesbaar als de code die hij vervangt. Splits de beslissing op in kleinere deelbeslissingen. DMN heeft daar een eigen diagram voor, het Decision Requirements Diagram, dat laat zien welke beslissing op welke andere beslissing steunt.
- Proces en beslissing door elkaar. “Eerst controleren we het adres, dan vragen we een uittreksel op” is een proces en hoort in BPMN. DMN gaat over het oordeel, niet over de stappen.
- Alleen IT aan tafel. Het grootste voordeel van DMN is dat de business meeleest. Wordt de tabel alleen door ontwikkelaars gemaakt en beheerd, dan hebt u vooral een nieuwe programmeertaal ingevoerd.
Hoe ik ermee werk
In mijn werk als Pega business architect zie ik hetzelfde principe terug: beslissingen horen niet verspreid door de schermen en processen, maar op één plek, in een vorm die de business kan lezen. Pega heeft daarvoor eigen beslistabellen; DMN is de open standaard die met verschillende beslisengines werkt, zoals Operaton.
Mijn advies om te beginnen: kies één beslissing die vaak voorkomt en waar regelmatig discussie over is. Schrijf de regels samen met de mensen die ze kennen in een tabel, kies bewust een hit policy en maak bij elke regel een testgeval. Vaak blijkt al tijdens dat gesprek dat twee afdelingen dezelfde regel anders toepassen. Dat inzicht alleen is de moeite al waard.
Wilt u weten of DMN past bij een beslissing in uw organisatie? Neem gerust contact op.