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 standaardtaal 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 deel 1 zijn we ingegaan op de basis van The Decision Model and Notation. In deel 2 hebben we de eerste drie stappen doorlopen om een DRD te creëren. Daarna hebben we het DRD verder uitgewerkt in deel 3. In dit vierde deel bespreken we de laatste twee stappen om te komen tot een DRD welke gebruiksklaar is om te beginnen met het specificeren van de bijbehorende bedrijfslogica.

Het resultaat van de vorige besproken zes stappen is versie 0.1 van het DRD, zie figuur 1. De stappen om tot versie 0.1 van het DRD te komen zijn zeer gestructureerd en kunnen door iedereen met een gevoel voor taal, en een basistraining op het gebied van van 1) een scenario-gebaseerd analyseren of 2) een brongebaseerd analyseren worden uitgevoerd. De reden hiervoor is dat deze stap, ongenuanceerd gezegd, wanneer het echt moet nog vanachter een bureau kan worden uitgevoerd.

Figuur 1: De uitwerking van de initiële DRD (versie 0.1)

Om te komen tot versie 0.2 van het DRD dienen nog twee stappen te worden gezet:

1. het controleren van de feittypen (stap 7);
2. het controleren van het DRD op ontbrekende elementen (stap 8);
3. het white-boxen en black-boxen van de beslissingen in het DRD (stap 9).

Voor beide stappen geldt dat er naast analytische kennis ook kennis over de inhoud benodig is. Deze twee typen kennis zijn maar zelden verenigt in één persoon. Daarom is het voor het uitvoeren van deze twee stappen noodzakkelijk om een materiedeskundige te raadplegen. Het raadplegen kan plaatsvinden door een één-op-één sessie of in de vorm van een workshop.

7. Het controleren van de feittypen

In stap vijf “is het feittype een beslissing (afleiding) of een grondterm?” (beschreven in deel 3) is voor elk feittype bepaald of het een grondfeit of een beslissing is. De feittypen die als beslissing zijn geclassificeerd zijn toegevoegd aan het DRD. In het DRD zijn de feittypen die als grondfeiten zijn geclassificeerd nog steeds gekoppeld aan de beslisservice (‘hoofdbeslissing’). Voor elk feittype dient nu te worden bepaald bij welke beslissing deze thuishoort. Dit is een eenvoudige exercitie, voor elk feittype dient de volgende vraag gesteld te worden:

• Is “Feittype X” een conditie voor“Beslissing Y”?

Waarbij de tekst “Feittype X” wordt vervangen door een daadwerkelijk feittype en “Beslissing Y” door een beslissing in het DRD.

Voorbeeld: Het controleren van de feittypen

In het huidige voorbeeld is er maar één feittype overgebleven na stap 5: “is het feittype een beslissing (afleiding) of grondterm?” Dit is het feittype   “voedselinname”. Ter herinnering: het feittype “voedselinname” wordt verkregen door een directe vraag aan de patiënt te stellen, en is daarmee dus een grondfeit. Voor het feittype “voedselinname” wordt de eerder genoemde vraag nu gesteld:

Is “voedselinname” een conditie voor de beslissing “bepaal risico op ondervoeding”?

Het antwoord op deze vraag is “nee”. En daarom dient deze vraag nu voor elke beslissing in DRD te worden gesteld:

Is “voedselinname” een conditie voor de beslissing “bereken risicopunten ondervoeding”? Antwoord: Nee

Is “voedselinname” een conditie voor de beslissing “bepaal risicopunten gewichtsverlies”? Antwoord: Nee

Is “voedselinname” een conditie voor de beslissing “bereken gewichtsverlies”? Antwoord: Nee

Is “voedselinname” een conditie voor de beslissing “bepaal body mass index risk points”? Antwoord: Nee

Is “voedselinname” een conditie voor de beslissing “bereken body mass index”? Antwoord: Nee

Is “voedselinname” een conditie voor de beslissing “bepaal risicopunten voedseliname”? Antwoord: Ja

Het antwoord op de laatste vraag is: ja. Daarom dient in dit geval het feittype “voedselinname” gekoppeld met de beslissing “bepaal risicopunten voedselinname” te worden, zie figuur 2. Omdat er in dit specifieke geval maar één feittype te beoordelen was, hoeft deze exercitie maar één keer plaats te vinden. Wanneer er meerdere feittypen te verdelen zijn dient deze exercitie herhaalt te worden voor elk feittype. In dit voorbeeld zijn de beslissingen in het DRD van boven naar beneden en van links naar rechts gevolgd. Daarom is de de uitslag bij de laatste vraag pas positief, omdat die zelfde volgorde is aangehouden voor stap 7. In een workshop of met een materiedeskundige zal een deel van deze vragen impliciet worden beantwoord omdat de materiedeskundige direct naar de juiste beslissing kan gaan. Nadat elk feittype is behandeld dient het DRD nu gecontroleerd te worden op ontbrekende elementen.

Figuur 2: DRD met voedseliname verplaatst

8. Controleren ontbrekende beslissingen, feittype, bronnen en regelsets?

In stap 8 “controleren ontbrekende beslissingen, feittype, bronnen en regelsets?”, wordt het DRD gecontroleerd op ontbrekende elementen. De elementen die gecontroleerd worden zijn: beslissingen, feittype, bronnen en bedrijfslogica.

Controle op ontbrekende beslissingen

Bij het controleren op ontbrekende beslissingen worden er drie specifieke punten gecontroleerd. Ten eerste wordt er gecontroleerd of de beslisservice (‘hoofdbeslissing’) ook daadwerkelijk de beslisservice (‘hoofdbeslissing’) is. Deze controle heeft al eerder plaatsgevonden aan het einde van stap 2“initiele analyse van de/het touchpoints”, maar wordt hier voor de zekerheid nogmaals herhaald.

Ten tweede wordt er gecontroleerd of de ‘onderste’ beslissingen ook echt de ‘onderste' beslissingen zijn. Hierbij wordt een eerdere waarschuwing herhaald:

Let op, bij het beantwoorden van de voorgaande vragen gaat het om deze specifieke situatie en de bijbehorende DRD!

Ondanks de waarschuwing kan het soms voorkomen dat er toch specifieke beslissingen niet zijn meegenomen terwijl ze wel relevant zijn. Deze dienen dan alsnog te worden toegevoegd.

Ten derde wordt er gefocust op zogenaamde ‘vliegende beslissingen’, zie figuur 3. Een ‘vliegende beslissing’ is een beslissing, welke is opgenomen in het DRD maar niet is verbonden met één van de andere beslissingen in hetzelfde DRD, zie figuur 3 (links). In deze specifieke gevallen zijn er twee situaties. Ten eerste (en dit is de meest voorkomende situatie) dat er nog een beslissing ontbreekt in het DRD, zie figuur 3 (links). De reden hiervoor kan zijn dat de beslissing impliciet is gelaten en daarom niet is opgenomen in het touchpoint. Het kan ook zijn dat tijdens de initiële analyse niet alle relevante touchpoints zijn meegenomen. Wanneer dit laatste het geval is dient dit touchpoint alsnog opgenomen te worden en volledig geanalyseerd te worden (vanaf stap 2: initiële analyse van de/het touchpoints). Deze beslissing dient dan wel te worden toegevoegd aan het DRD, zie figuur 3 (rechts). De tweede situatie is dat de beslissing niet thuishoort in dit betreffende DRD, maar in een andere. In dat geval dient de beslissing te worden verwijderd uit het DRD.

In de huidige DRD zijn er geen ontbrekende beslissingen en kan de analyse verder gaan met het controleren van de ontbrekende feittypen.

Figuur 3: DRD met ‘vliegende beslissingen’

Controle op ontbrekende feittype

Als basisuitgangspunt kan worden gesteld dat elke beslissing minimaal één gekoppeld feittype dient te hebben. Dit feittype fungeert als conclusie om de daadwerkelijke beslissing te kunnen maken. Er zijn twee manieren waarop een feittype gekoppeld kan worden aan een beslissing: 1) als grondfeit en/of 2) als onderliggende beslissing (zie figuur 4). Dit betekend dat bij deze controle voor elke beslissing in het DRD de volgende vragen gesteld dienen te worden:

• Welke feittypen zijn benodigd om deze beslissing te nemen?

En voor elk feittype:

• Is dit een grondfeit? Of
• Wordt dit feittype als conclusie van een onderliggende beslissing aangeleverd?

Als het antwoord op de eerste vraag “ja” en de op de tweede vraag “nee” is dan dient het feittype als grondfeittype te worden toegevoegd. Als het antwoord op de eerste vraag “nee” is en op de tweede vraag “ja” is, dan dient er gecontroleerd te worden of er een relatie met de beslissing die dit feittype levert bestaat. Als dit niet het geval is dient deze alsnog gemaakt te worden. Als deze beslissing niet voorkomt in het DRD dient de vraag gesteld te worden of in deze specifieke context het feittype als grondfeit of als afgeleid feittype (beslissing) dient te worden meegenomen. Is dit eerste het geval dient het feittype als grondfeit te worden opgenomen. Is dit tweede het geval dat dient er een extra beslissing te worden opgenomen, en kan er eventueel een nieuwe touchpoint analyse benodigd zijn. Specifiek dient er bij deze analyse gelet te worden op de ‘onderste’ beslissingen. Deze kunnen niet worden afgeleidt en dienen daarom te worden voorzien van grondfeit. Als deze ontbreken, dienen deze te worden toegevoegd.

Figuur 4: Voorbeeld afgeleide conditiefeittype

Voorbeeld: Het controleren op ontbrekende feittypen

In het huidige voorbeeld zijn er zes beslissingen zonder grondfeittype:

1. de beslissing “bepaal risico op ondervoeding”;
2. de beslissing “bereken risicopunten ondervoeding”;
3. de beslissing “bepaal risicopunten gewichtsverlies”;
4. de beslissing “bereken gewichtsverlies”;
5. de beslissing “bepaal body mass index risk points”;
6. de beslissing “bereken body mass index”.

En één beslissing met één grondfeittype:

7. de beslissing “bepaal risicopunten voedseliname”.

Als eerst worden de onderste beslissingen geanalyseerd, dit zijn: D) de beslissing “bereken gewichtsverlies”, F) de beslissing “bereken body mass index” en G) “bepaal risicopunten voedselinname”. Voor beslissing D “bereken gewichtsverlies”, dienen er twee feittype te worden toegevoegd:

1. “het huidige gewicht van de patiënt” en;
2. “het gemiddelde gewicht van de patiënt”.

Voor beslissing F “bereken body mass index”, dienen er twee feittype te worden toegevoegd:

1. “lengte van de patiënt” en;
2. “het gemiddelde gewicht van de patiënt”.

Voor de beslissing G “bepaal risicopunten voedseliname”, geldt dat er al een grondfeittype benoemd staat, maar dat er inderdaad ook één ontbreekt die nog dient te worden toegevoegd, zie figuur 5:

1. “leeftijd van de patiënt”.

De hierboven genoemde omissies in het model komen voort uit het feit dat een aantal feittypen inderdaad impliciet worden gelaten en door de arts ‘automatisch’ worden meegenomen. Voor een aantal feittypen geldt ook dat ze op andere touchpoint staan benoemd. Zoals eerder vermeldt is de analyse van de overige touchpoints in deze specifieke voorbeelden buiten beschouwing gelaten.

Figuur 5: Beslissing met ontbrekende feittype

Na de analyse van de ‘onderste’ beslisingen dienen de overige beslissingen geanalyseerd te worden:

1. “bepaal risico op ondervoeding”;
2. “bereken risicopunten ondervoeding”;
3. “bepaal risicopunten gewichtsverlies;
4. “bepaal body mass index risk points”.

Voor elk van deze beslissingen geldt in dit geval dat er geen grondfeittype worden toegepast om de beslissing te maken. Elk benodigd feittype is de conclusie van een onderliggende beslissingen. Er hoeven dus geen extra grondfeittypen te worden toegevoegd.

Ontbrekende bronnen en bedrijfslogica

Het controleren van ontbrekende bronnen en bedrijfslogica is meer straight-forward dan het controleren van ontbrekende beslissingen en feittype. Bij elke beslissing dient gecontroleerd te worden of er een element voor een bron en bedrijfslogica is toegevoegd. In het DRD dat wordt toegepast in het voorbeeld zijn alle bronnen en bedrijfslogica (regelsets) elementen bekend en toegevoegd. Wanneer een bron of de bedrijfslogica onbekend zijn en daarom niet toegevoegd zijn worden beide alsnog in deze stap toegevoegd. In beide gevallen wordt er dan een “?” als naam voor beide elementen gekozen, zie figuur 6. Deze vraagtekens wordt in een later stadium van het proces elicitatie en analyse van beslissingen en bedrijfsregels opgelost.

Figuur 6: Beslissing onduidelijke bedrijfslogica en bron

In onze specifieke cases leidt dit in zijn geheel nu tot het DRD zoals gepresenteerd in figuur 7.

Figuur 7: De uitwerking van de DRD logica (DRD versie 0.2)

Vervolg-stappen

Met dit artikel eindigt onze vierdelige serie over het ontwerpen van een DRD. Toch is het ontwerpen van het DRD pas het begin van het ontwerpen, structureren, specificeren en uitvoeren van de bijbehorende beslissingen. Een aantal vervolg stappen die nu dienen te gebeuren zijn:

• Het white- en black-boxen van elke beslissing in DRD;
• Het vaststellen van de bijbehorende governance structuur (per beslissing);
• Het vaststellen van de variabiliteit van de bedrijfslogica bij elke beslissing;
• Op basis van de resultaten het bepalen van de onderliggende methode en technologie voor het specificeren, verifiëren, valideren en uitrollen, uitvoeren en beheren van de beslissingen en bijbehorende bedrijfslogica;
• Het monitoren en evalueren van de beslissingen en bijbehorende bedrijfslogica.

Over een aantal van de hierboven besproken stappen hebben wij in een eerder stadium kortere en langere artikelen geschreven. Deze zijn te vinden door te klikken op de opsomming. In een later stadium zullen wij nog terugkomen op de andere.

Mede-Auteur: Koen Smit

Mocht u al vragen of interesse hebben, neem dan contact op via:  info@martijnzoet.com of bekijk de cursus: “Elicitatie en Ontwerp van beslissingen en bedrijfsregels”, waarin elk van deze onderdelen wordt behandeld:

Cursus: Elicitatie en Ontwerp van beslissingen en bedrijfsregels