Sinds september 2015 is de ‘business rule management wereld’ / ‘decision management wereld’ weer een standaard rijker: The Decision Model and Notation (DMN). De Object Management Group (OMG) heeft deze nieuwe standaard uitgebracht met als doel een standaard taal te creëren om 1) requirements voor beslissingen en 2) de beslissingen zelf te modelleren. De adoptie van DMN heeft een wat lange aanloop gehad, maar begint nu serieuze vormen aan te nemen. Om deze reden brengen wij een vierdelige serie over DMN en het gebruik van DMN uit. In deze introductie, deel 1, gaan we in op de basis van The Decision Model and Notation.
The Decision Model and Notation
The Decision Model and Notation is uitgebracht met als doel een standaard taal te creëren om 1) requirements voor beslissingen en 2) beslissingen van de tweede categorie (zwart-wit bedrijfsregels), zie ook Classificatieschema voor BRMS: Deel 2, te modelleren. Voor het modeleren van derde en vierde categorie bedrijfsregels is DMN niet geschikt. Deze twee doelen staan ook gelijk aan de twee abstractieniveau’s die de standaard onderscheid: 1) het decision requirements diagram en 2) de decision logic. Het decision requirements diagram wordt gebruikt om beslissingen, de benodigde bedrijfslogica om de beslissing te maken, de bron waar op de bedrijfslogica is gebaseerd en de benodigde feiten om de beslissing te maken in kaart te brengen. Het tweede niveau, de decision logic, is een verdiepingsslag en beschrijft de daadwerkelijke bedrijfslogica om de beslissing te kunnen nemen. Dit kunnen bedrijfsregels, predictive modellen, beslistabellen, zoals eerder geformuleerd ondersteund DMN standaard alleen bedrijfsregels en beslistabellen.
Het decision requirements diagram
Een Decision Requirements Diagram (DRD) onderkent vier concepten en bijbehorende visualisaties, zie tabel 1. Om het DRD en de onderliggende concepten helder te maken gebruiken we een voorbeeld beslissing, de beslissing (decision): “bereken risicopunten voedselinname.”
Tabel 1. DRD concepten en visualisaties
Een voorbeeld DRD – Bereken risicopunten voedselinname
De beslissing “bereken risicopunten voedselinname” wordt weergegeven in een rechthoek, zie Figuur 1. Om de beslissing te kunnen maken moet de bedrijfslogica (business knowledge) gespecificeerd worden. Het specificeren van de daadwerkelijk benodigde bedrijfslogica zelf wordt niet in het DRD maar in het decision logic model gedaan. In het DRD wordt alleen de verwijzing naar de bedrijfslogica opgenomen, in het voorbeeld “bereken risicopunten voedselinname”, namelijk de “bereken risicopunten voedselinname beslistabel.”
Figuur 1. Voorbeeld DRD – bereken risicopunten voedselinname
Het concept bedrijfslogica, op het niveau van de DRD, is te vergelijken met een container. De container bevat de bedrijfslogica om de beslissing te kunnen nemen. Op het niveau van DRD zijn we alleen niet geïnteresseerd in de inhoud van container, maar willen we hem alleen kunnen identificeren. Over het algemeen kunnen we stellen dat mensen het lastig vinden om een representatieve naam te geven aan de container die de bedrijfslogica representeerd. Er zijn industrieën, en op kleinere schaal organisaties, waar bepaalde sets van bedrijfslogica een specifieke naam hebben, maar vaak is dit niet het geval. Indien er geen gemeenschappelijke naam binnen de organisatie of afdeling wordt gebruikt is het aan te raden om de naam van de bedrijfslogica zo generiek mogelijk te maken in het DRD. De meest generieke vorm is de het woord “bedrijfsregelset” of “bedrijfslogica” en de naam van de beslissing zonder het werkwoord, in ons voorbeeld: “bedrijfslogica bereken risicopunten voedselinname”. We komen ook nog wel eens voorbeelden tegen waar één van de volgende namen wordt gebruikt:“beslistabel bereken risicopunten voedselinname” en “beslisboom bereken risicopunten voedselinname.” Deze namen zijn niet inccorect, maar specificeren behalve de inhoud van de container ook de notatievorm waarin deze inhoud is gespecificeerd, namelijk een beslistabel of een beslisboom. Wanneer de notatievorm waarin de bedrijfslogica is gespecicificeerd veranderd zou daarmee ook de naam van de bedrijfslogica in het model veranderen, bijvoorbeeld van “beslistabel bereken risicopunten voedselinname” naar “regelset bereken risicopunten voedselinname.” Dit is natuurlijk mogelijk, maar met het oog op het minimaliseren van het aantal wijzigingen moet er geprobeerd worden dit te voorkomen.
De bedrijfslogica waarmee een beslissing wordt genomen is vaak / meestal gebaseerd op een bron. De bron kan extern of intern van aard zijn, bijvoorbeeld wet- en regelgeving, intern beleid en/of een specifieke rol. In het voorbeeld “bereken risicopunten voedselinname.” worden deze criteria beschreven door het document Malnutrition Universal Screening Tool (MUST), en deze is daarom opgenomen in het model. Een vraag die veel gesteld wordt bij het specificeren van de bron: op welk abstractieniveau dient de bron gespecificeerd te worden? In plaats van MUST kan er bijvoorbeeld ook gekozen worden voor BAPEN. BAPEN is de Britse organisatie die is toegewijd aan het herkennen van ondervoeding en het bieden van oplossingen om ondervoeding tegen te gaan. Een andere optie is om voor een lager abstactieniveau te kiezen, bijvoorbeeld: “pagina 1, paragraaf 2, van MUST versie 1.2.” Er zijn wel een aantal specifieke regels, gebaseerd op specifieke situaties, voor het vastleggen van bronnen. Over het algemeen kan gesteld worden: specifieker is beter.
Naast het vastleggen van de bedrijfslogica en de bronnen waarop deze bedrijfslogica is gebaseerd kun je in het DRD ook aangeven welke feiten er nodig zijn om de beslissing te kunnen maken. In het voorbeeld “bereken risicopunten voedselinname” zijn dit: 1) vaste inname patiënt, 2) vloeibare inname patiënt, 3) leeftijd patient. Een vraag die ook bij het vastleggen van de feiten veel gesteld wordt is op welk abstractieniveau de feiten gespecificeerd dienen te worden. Modelleer je elk feit apart of geef je een verzameling van feiten een naam? Wanneer er in de organisatie standaard namen bestaan voor gegevens van feiten dan geniet het de voorkeur om deze namen te gebruiken. Wanneer deze niet bestaan dan geldt, net zoals bij het modelleren van bronnen, specifieker is beter.
Het creëren van een DRD – een stappenplan
Het creëren van een DRD kan op meerdere manieren. De één start bij het specificeren van de input data elementen, de ander start bij het specificeren van bronnen, maar men kan ook starten met het specificeren van de beslissingen. Onze ervaring is dat het creëren van een DRD het eenvoudigdst mogelijk is volgens een specifiek stappenplan. Twee type stappenplannen zijn; 1) een scenario-gebaseerd stappenplan en 2) een brongebaseerd stappenplan.
In het volgende artikel gaan we in op het scenario-gebaseerde stappenplan.
Mede-Auteur: Koen Smit
