Aanwijzingen en richtlijnen voor een beslismodel. Van ontwerp tot validatie

Aanwijzingen en richtlijnen voor een beslismodel Van ontwerp tot validatie

Inhoudsopgave 1. Inleiding

p. 3

a. Inhoud

p. 3

b. Bereik van het document

p. 3

2. Leeswijzer

p. 4

3. Algemene richtlijnen ten aanzien van regel intensieve applicaties

p. 5-7

a. Internationale Standaarden

p. 5-7

i. Business Rules Manifest

p. 5-6

ii. De Object Management Group

p. 6-7

iii. Agile Manifesto

p.7

4. Ontwerp Beslismodel

p.8-13

a. De schets van het beslismodel

p. 8

b. Ontwerp en Prototype

p. 9

c. Modelleerrichtlijnen

p. 9-11

d. Overige aspecten die bij het ontwerpen betrokken kunnen worden

p. 12-13

5. Het bouwen van een beslismodel

p. 14-17

a. Inleiding

p. 14

b. Tips bij het bouwen van een beslismodel

p.14-15

c. Analyse van juridische vaagheden en verwijzingen

p. 16-17

6. De Rapportage

p.18-25

a. Inleiding

p. 18

b. Rapportfunctie van de Publisher

p. 18-19

c. Van papier naar digitaal

p. 20-21

d. Informatieschets

p. 20-21

e. Modelleerrichtlijnen

p. 22

f.

p. 22

Extra informatie en lay-out

g. Specifieke opmerkingen in relatie tot de huidige rapportage

p. 23-24

i. Rapport als basis voor ontwerp

p. 23

ii. Inbouwen intelligentie

p. 23-24

iii. Tussenconclusies

p. 24

iv. Gebruik waardelijsten

p. 24

h. Bewijsstukken

p. 24

i.

p. 24-25

Import/Export rekengegevens

7. Acceptatie Beslismodel

p. 26-27

a. Acceptatiecriteria

p. 26

b. Algemene richtlijnen uit de praktijk

p. 26-27

8. Bijlage Berkeley Bridge: Richtlijnen voor een beslismodel www.berkeleybridge.nl

p.28-30 2

1. Inleiding A. Inhoud In dit document worden algemene en specifieke aanwijzingen en (modelleer)richtlijnen beschreven voor het ontwerp en de bouw van een beslismodel. Aangevuld met algemene beschrijvingen worden deze voorgesteld als aanbeveling, tip en/of leidraad voor het ontwerp en de bouw van beslismodellen. Als onderdeel van het beslismodel wordt bovendien een lijst met attentiepunten geboden voor het ontwerpen/bouwen van een rapportage met de resultaten van deze beslisboom.

B. Bereik van het document Het technisch platform voor de beslismodel en rapportage betreft de Berkeley Bridge Publisher. Hoewel het doel van dit document niet is om een functionele beschrijving te geven van het daadwerkelijke modelleren en rapporteren binnen de Publisher, zal bij het uitwerken van de richtlijnen wel zoveel mogelijk rekening worden gehouden met de (on)mogelijkheden van de Publisher en zullen ook concrete tips gegevens worden. Dit document is geen handleiding bij het gebruik van de Publisher, wel bij het maken van beslismodellen.

Berkeley Bridge: Richtlijnen voor een beslismodel www.berkeleybridge.nl

3

2. Leeswijzer De indeling van dit document is als volgt: als eerste worden internationale standaarden voor het ontwerpen en bouwen van regelintensieve systemen beschreven. Deze standaarden geven inzicht hoe om te gaan met kennisintensieve regels (hierna te noemen business rules). Deze standaarden zullen niet altijd onverkort van toepassing zijn, maar geven een interessant beeld hoe nagedacht wordt over gebruik van business rules.

Vervolgens zal nader ingegaan worden op het ontwerpen van een beslismodel. Een rapportage kan niet bestaan zonder een gedegen onderliggend beslismodel en daarom biedt dit document ook aanbevelingen voor het ontwerpen en bouwen van beslismodellen. Ook worden er, onder andere, vragen beantwoord zoals ‘wat is de noodzaak van een ontwerp’ en ‘wat dient het ontwerpt te bevatten.’ Vervolgens wordt aandacht besteed aan de bouw. Wanneer tijdens de ontwerpfase al goed is nagedacht over het beslismodel, kan de bouwfase meestal redelijk snel doorlopen worden. In het daaropvolgende onderdeel wordt nader naar de rapportage gekeken. Waar moet bijvoorbeeld rekening mee gehouden worden bij het ontwerp van de rapportage? Daarna wordt kort stilgestaan bij interfacing, de mogelijkheden op het gebied van communicatie, met andere systemen. Tenslotte wordt aandacht besteed aan het accepteren van het beslismodel.

Figuur 1: fasering van de ontwikkeling van een beslismodel. Testen hoort hier natuurlijk ook bij, maar is in dit document buiten beschouwing gebleven.


4

3. Algemene richtlijnen regelintensieve applicaties

ten

aanzien

van

A. Internationale Standaarden Zowel vanuit wetenschappelijk kader als vanuit het bedrijfsleven is aandacht besteed aan standardisatie en implementatie van het gebruik van business rules. Eensgezindheid in het denken over business rules betekent immers een versnelling en betere beheersing van het voortbrengingsproces. Ook de uitwisselbaarheid van kennis en de onderlinge aansluitbaarheid van systemen is hierbij gebaat. Deze standaarden zijn door hun ofwel algemene karakter of juist gerichtheid op een specifieke tooling of methode niet allemaal onverkort van toepassing, maar bieden wel een leidraad bij het nadenken, ontwerpen en/of bouwen van beslismodellen.

Dit deel zal dan ook niet extensief alle internationale standaarden bespreken, want dat kan een boekwerk op zichzelf worden en valt daardoor buiten het bestek van het specifieke doel van dit document. Een aantal standaarden is echter wel interessant om toe te lichten. Als eerste wordt het business rules manifest – een aantal leidende principes voor het omgaan met regels in softwaretoepassingen – aangestipt. Daarna wordt ingegaan op de object management group. Dit geeft een beeld van standaarden bij het ontwerpen van systemen en tot slot wordt de Agile-aanpak, gekenmerkt door het ontwikkelen van software in korte, overzichtelijke perioden om de risico’s te verminderen, de directe communicatie, de nadruk op voortgang en het testen hiervan door middel van prototypes. Een voorbeeld van een projectaanpak voor het bouwen van systemen, gebruik makend van de Agile-aanpak, wordt besproken.

i. Business Rules Manifest Het Business rules manifest van de Business Rules Group bevat een aantal algemene regels geformuleerd in een manifest, welke als leidraad dienen voor regelintensieve systemen (en dus voor het omgaan met business rules). Daarnaast is in het kader van BRG de regeltaal SVBR[1] ontwikkeld. Dit is een gestructureerde taal voor het formuleren van regels. De aard van natuurlijke taal (en zeker juridisch taalgebruik) het per definitie onduidelijk en is om die reden niet geschikt voor het formuleren van business rules.[2] De bedrijfsregel (“business rule”) wordt door BRG gezien als een van het proces onafhankelijk deel en vooral als het kennisintensieve hart van systemen. Dat is een zeer belangrijk kenmerk van de business rule. Deze worden ontwikkeld dooren zijn eigendom van de business zelf en zijn daardoor in ontwerp, beheer en onderhoud dus flexibeler en meer aanpasbaar dan ingewikkelde softwarecode in handen van techneuten. Zie de bijlage voor een integraal overzicht van dit manifest. Feitelijk valt het uitschrijven van een regel in een Publisherdiagram ook onder het beheren van de regels door de business zelf (artikel 6.2 van het manifest). Vandaar dat het business rules manifest een algemene leidraad kan bieden bij het ontwikkelen van beslismodellen. Hoewel het hele manifest interessant is, verdienen de


5

artikelen 2.3, 3.3, 4, 5.1, 6.2, 6.3 (de rapportage dus), 8 en 9 extra aandacht bij het ontwerpen van de beslisboom. [1] Semantics of Business Vocabulary and Business Rules [2] Het “oplossen” van vaagheden in (juridische) teksten en deze daarmee geschikt maken voor systeemontwikkeling is een niet te onderschatten activiteit bij het omzetten van (juridische) regels naar business rules. Natuurlijke taal is per definitie vaak meerduidig, terwijl de binaire wereld zwart/wit denkt. Zie ook het voorbeeld verder in dit document.

ii. De Object Management Group De Object Management Group (OMG) is een in 1989 opgericht consortium, dat zich richt op de ontwikkeling van standaarden voor applicatieonafhankelijke,objectgeoriënteerde systemen. Dit bedrijf focust zich tegenwoordig op modelvorming (programma’s, systemen en bedrijfsprocessen) en modelgebaseerde standaarden. Bij de oprichting waren 11 bedrijven betrokken, waaronder Apple, Hewlett-Packard, IBM, en Sun. Ondertussen zijn meer dan 800 bedrijven betrokken en werkt het consortium verder aan het beheer en de ontwikkeling van verschillende internationaal erkende standaarden.[1]

Figuur 2: Een UML Klassediagram


6

Een resultaat van OMG is bijvoorbeeld de ontwerptaal UML (Unified Modeling Language), nu gebruikt als standaard bij het ontwerpen van veel verschillende soorten systemen. UML bestaat uit een aantal grafische elementen die tot diagrammen worden gecombineerd. Omdat het eigenlijk een taal is, bevat UML ook regels voor het combineren van deze elementen. Dit is ruwweg vergelijkbaar met de grafische weergave in de Publisher, waarbij nodes met elkaar worden verbonden door relaties en beperkingen op deze relaties. Hiernaast een voorbeeld van een UML schema.

In dit voorbeeld worden de relatie weergegeven van een persoon met een bedrijf. Dit model beschrijft een statische situatie, waarbij het mogelijk is door het model heen te navigeren. In de Publisher hebben de modellen meer een procedureel karakter, maar de grafische weergave is vergelijkbaar.

[1] Zie http://www.omg.org

iii. Agile Manifesto Het Agile Manifesto (Manifesto for Agile Software Development) is opgesteld tijdens een bijeenkomst van zeventien softwareontwikkelaars begin 2000. Veel ontwikkelaars beroepen zich erop dat hun aanpak agile (behendig/lenig) is. Daarmee is agile softwareontwikkeling een te gebruiken standaard geworden. De meeste agile methoden proberen risico’s te verminderen door software te ontwikkelen in korte overzichtelijke perioden (timeboxes), die ‘iteraties’ genoemd worden. Elke iteratie is als het ware een miniatuurproject op zichzelf, en omvat alle noodzakelijke taken: planning, analyse, ontwerp, testen en documentatie. Een iteratie levert niet altijd genoeg op om het eindproduct vrij te geven. Desondanks is het de bedoeling van een agileproject om na iedere iteratie iets bruikbaars voor de markt op te leveren. Voor software gaat dat vaak op als ze webgebaseerd is.

Agile ontwikkeling levert dus steeds stukjes werkende software op, in plaats van een bigbangoplevering na een lange periode. De in het manifest genoemde samenwerking tussen business en ontwikkelaars is van groot belang voor regelintensieve systemen. Voor beslismodellen is dit dan ook een uitstekende aanpak, omdat niet alleen vrij snel resultaten getoond kunnen worden, maar ook de business zelf de ontwikkeling uitvoert.


7

4. Ontwerp Beslismodel A. De schets van het beslismodel Hoewel de Publisher een zeer laagdrempelige tool is waarmee vrij snel een goed werkend beslismodel mee gemodelleerd kan worden en het beslismodel eigenlijk al het ontwerp is, verdient het aanbeveling om eerst goed na te denken over het uitwerken van een idee in een opzet van het model, vooral om onnodig werk en teleurstelling te voorkomen wanneer het model achteraf toch niet aan de verwachtingen blijkt te voldoen. Een ontwerp maken helpt daarbij.

Het van te voren uittekenen van een beslismodel in een workshop met alle benodigde betrokkenen (kenniseigenaar, proceseigenaar, modelleur, etc.) helpt nadenken over de logische opbouw van een beslismodel en kan voorts als hulpmiddel dienen bij de nadere afstemming over het model met de kenniseigenaar. Dit geeft inzicht in de logische opzet van het beslismodel.

Hiervoor zijn talloze meer of minder gedetailleerde, elektronische of papieren mogelijkheden beschikbaar, maar een ruwe schets van de opbouw, loop en verbanden van het programma is wel een minimaal vereiste om een beeld te krijgen van het uiteindelijke beslismodel. Hieronder is een aantal voorbeelden weergegeven:

Figuur 3: Voorbeeld van een ontwerp met eenvoudige middelen (foto van een white board)

Figuur 4: voorbeeld van een uitgebreidere schets van een applicatie, inclusief schermverloop.

Figuur 5: voorbeeld van een al bijna volledig werkend

ontwerp

in

PowerPoint,

werking

eigenlijk als een prototype


8

B. Ontwerp en prototype Naast het maken van schetsen is het ook aan te raden om middels prototyping in de Publisher te proberen of gewenste (delen van) modellen te maken zijn. Dit geeft inzicht in de (on)mogelijkheden van de Publisher. Prototypes kunnen bovendien ook gebruikt worden bij de nadere afstemming tussen de verschillende betrokkenen bij het ontwerp. Een goed prototype kan bovendien bij de bouw ook hergebruikt worden (maar dat is niet het doel op zichzelf).

C. Modelleerrichtlijnen In de ontwerpfase is het bovendien handig om alvast aandacht te besteden aan zaken als modelleerrichtlijnen, naamgevingconventies en metadatering van gegevens. Door de laagdrempelige manier van beslisbomen maken in de Publisher kan men snel een model maken.

Stel: het model werkt en is opgeleverd door persoon x. Na een jaar verandert de wetgeving en moet persoon y het aanpassen. Persoon x werkt inmiddels elders. Het kan uitermate lastig zijn voor persoon y om de gedachtegang van persoon x te doorgronden.

Wanneer het beslismodel echter volgens vastgestelde modelleerrichtlijnen gebouwd is, die door persoon y te raadplegen zijn, dan zal dit al een stuk eenvoudiger zijn voor persoon y. Enkele voorbeelden van richtlijnen in relatie tot het maken van beslismodellen met de Publisher zijn:

Figuur 6: voorbeeld van een onduidelijk model; uit de nodes is niet af te leiden wat de betekenis is. Voor onderhoud zul je dus altijd de bijbehorende schermen moeten raadplegen.


9



Begin met het stellen van de meest discriminatoire vragen (de algemene deler); d.w.z. stel de vraag die voor iedereen van toepassing is aan het begin en niet aan het einde van het model. Plaats vragen die slechts voor een geringe doelgroep van belang zijn zoveel mogelijk achteraan het beslispad.



Stel een eenduidige naamgeving vast voor de name van nodes en graphs (naamgevingconventies). Maak de naam desnoods wat langer als dit de duidelijkheid dient. Geef nodes en graphs een betekenisvolle en declaratieve naam.[1]



Houd de formulering van vragen (question) kort en bondig en voorkom dubbele ontkenningen en/of tangconstructies in de vraagstelling.



Voeg een toelichting bij de vraag toe indien dat ondersteunend aan de vraag is. Vermijd echter algemeenheden in dergelijke toelichtingen (de Publisher biedt een aantal fraaie mogelijkheden voor interactieve toelichtingen).



Maak verschillende soorten kennis als zodanig herkenbaar in de naamgeving (metadatering). Bijvoorbeeld de grondslag minimum loon met een prefix GSL_ gevolgd door het onderwerp (bijvoorbeeld MinLoon). Wanneer deze grondslag wijzigt, dan kunnen deze vrij eenvoudig in het beslismodel aangepast worden. Ook intern beleid en externe wetgeving kan door middel van prefixen uit elkaar gehouden worden. Een andere mogelijkheid is om deze grondslagen in eensubgraph te groeperen.



Neem een bronvermelding op van de betreffende regel. Traceerbaarheid naar een specifieke regel dient niet alleen voor het beter om kunnen gaan met wijzigingen in regelgeving, maar dient ook ter verantwoording van het feit of een bepaalde regel afgedekt is. Dit kan bijvoorbeeld als information bij de node, maar zou ook opgenomen kunnen worden in de naamgeving van de node.



Bedenk patronen in het beslismodel voor veelvoorkomende constructies, zodat deze makkelijk hergebruikt

kunnen

worden.

Een

te

herbruiken

model

wordt

gemodelleerd

in

een

aparte graph (patronen is een dynamisch iets, hoe verder men beslismodellen ontwikkeld, hoe meer patronen men gaat onderkennen). 

Werk details alleen uit indien deze noodzakelijk zijn (granulariteit). Wanneer inkomen bijvoorbeeld een gegeven is dat als geheel ingevoerd kan worden, hoeven niet alle losse inkomenscomponenten uitgevraagd te worden.



Bouw niet alles in één keer, maar verdeel het werk in los op te leveren componenten.



Houd je aan het ontwerp, maar wanneer het ontwerp niet klopt, bespreek dan een aanpassing van het ontwerp.



…[2]

Wanneer iedereen volgens dezelfde richtlijnen werkt aan beslismodellen, dan is het niet meer zo relevant welk specifiek persoon aan een model werkt. Richtlijnen kunnen bovendien in andere projecten eenvoudig hergebruikt worden. Bedenk wel dat het richtlijnen zijn, gegronde afwijking is mogelijk, maar moet wel vastgelegd worden (en leiden tot een aanpassing van de richtlijn).


10

[1] Zie voor een uitleg http://nl.wikipedia.org/wiki/Declaratieve_taal. [2] Deze lijst is niet limitatief en dient als voorbeeld van mogelijke modelleerrichtlijnen. Modelleerrichtlijnen worden in eerste instantie in workshopvorm opgesteld. Input wordt vooral gegeven door aan te geven wat men als lastig ervaart bij het modelleren. In latere projecten zijn deze richtlijnen vanzelfsprekend herbruikbaar.


11

D. Overige aspecten die bij het ontwerp betrokken kunnen worden Naast een schets van de beslisboom en het vastleggen van modelleerrichtlijnen valt nog een aantal andere zaken te noemen, die van belang zijn in de ontwerpfase. De volgende punten helpen vooral de scope en omgeving van het beslismodel te bepalen: 

Wat is de context van het model? Beantwoording van deze vraag bakent descope van de bouw goed af. Het is aan te raden dergelijke afbakening van te voren vast te leggen om de verwachtingen ten aanzien van het eindproduct te managen.



Welk probleem moet opgelost worden? Waarom wordt gekozen voor een beslismodel? Wat zijn de feitelijke knelpunten? Hierbij moet goed nagedacht worden of ook werkelijk alle benodigde input voorhanden is. Ook hier is een ontwerp een uitstekend conversatiehulpmiddel.



Wat moet het product kunnen? Deze vraag wordt beantwoord in het licht van de context en het op te lossen probleem. De verschillende eisen die worden gesteld aan het model kunnen betekenen dat andere processen moeten worden herzien of moeten worden verandert.



Bestaan (herbruikbare) vergelijkbare producten? Waarom het wiel opnieuw uitvinden? Wanneer een ander beslismodel herbruikbare componenten heeft, gebruik deze dan. De Publisher biedt uitgebreide copy/pastefunctionaliteit.



Welke kennis moet ontsloten worden? In het kader van de scope van het beslismodel zal onderzocht moeten worden welke kennis ontsloten moet worden. Is deze kennis voorhanden? Wie is eigenaar van deze kennis? Betreft het wetgeving, beleid of expertkennis?

Inzicht hierin helpt bij de

domeinafbakening en voorkomt dat in de bouwfase teruggegaan moet worden naar de kenniseigenaar met de vraag “wat heb ik nou eigenlijk nodig”? 

Welke veranderingen brengt het product met zich mee? Wil het op te leveren product succesvol zijn, dan moet het gebruikt worden. Wanneer een papieren proces vervangen wordt door een digitaal dan zal dat veranderingen met zich meebrengen. Medewerkers moeten daar op voorbereid zijn en mee om kunnen gaan. Mogelijk zal dit een verschuiving van taken betekenen en wellicht hebben betreffende medewerkers nog aanvullende eisen/wensen voor het beslismodel. Betrek deze dus ook in het ontwerpproces.



Wat zijn de moeilijkheden? Van te voren nadenken over welke moeilijkheden men tegen kan komen, helpt om alvast maatregelen te benoemen mocht dit zich voordoen. Vaak is bijvoorbeeld de geringe capaciteit van de expert een probleem. Dit kan voorkomen worden door van te voren afspraken in te plannen om bevindingen terug te kunnen koppelen.



Houd rekening houden met complexiteit, impact en omvang. Niet alles hoeft op een digitale wijze uitgewerkt te worden. Zeker wanneer de inspanningen hiervan niet in verhouding staan tot het resultaat. Een goede afweging in het beslismodel kan voor een efficiëntere werkwijze zorgen.



Denk ook alvast na over eventuele kwaliteits- en acceptatiecriteria (waar moet het systeem aan getoetst worden, wanneer voldoet het?). In het kader van begrijpelijkheid van de applicatie kun je bijvoorbeeld


12

het criterium benoemen dat namen van nodes overeenkomen met de normen die deze nodes dekken. Aan acceptatie wordt in dit document nog in een apart onderdeel aandacht besteed.

Wanneer deze en eventueel nog andere vragen benoemd en beantwoord zijn (deze opsomming is vanzelfsprekend niet beperkt tot de bovengenoemde punten), dan kan dit ontwerp gelden als een uitgangspunt voor het te bouwen beslismodel. Alle partijen weten nu wat ze kunnen verwachten van het beslismodel. Het modelleren kan nu beginnen. Overigens is het ontwerpen en bouwen een iteratief traject; vanuit de bouw kunnen inzichten ontstaan die een aanpassing van het ontwerp kunnen betekenen.

Figuur 7: Resultaat ontwerpsessie relevante wetgeving voor vastlegging business rules t.a.v. registratie van schepen.


13

5. Het bouwen van een beslismodel A. Inleiding Met het ontwerp als leidraad is bouwen (of eigenlijk modelleren) van de beslisboom een activiteit die met voldoende kennis van de Publisher redelijk snel uitgevoerd kan worden. Onder de activiteit “bouwen” wordt niet alleen het feitelijke beslismodel bouwen verstaan, maar ook het vullen van de content bij het beslismodel (achtergrondinformatie, juridische bronnen en teksten). Naast de bovengenoemde (op te stellen) richtlijnen is er nog een aantal algemene tips die bij het bouwen handig van pas kunnen komen. Deze worden in dit deel behandeld.

B. Tips bij het bouwen van een beslismodel Als het goed is, zijn de algemene loop en de (hoofd)onderdelen van het beslismodel al in het ontwerp opgenomen, is de context en scope bepaald en is nagedacht over richtlijnen bij het modelleren, zodat de bouw kan beginnen en snel kan vorderen. Richt je eerst op de hoofdlijn van het beslismodel en vul bij volgende iteraties de details meer en meer in.

Figuur 8: het kruimel- of sprongpad Bouw binnen deze hoofdlijn de als afzonderlijk te benoemen onderdelen in detail en vermijd om alles tegelijk te willen doen. Voor grotere modellen is het aan te raden om een stappenplan op te stellen van de aanpak van de verschillende onderdelen.[1] Besteed voor deze hoofdlijn aandacht aan het kruimelpad (overzicht van het model), zodat je bij het doorlopen van het beslismodel weet waar je bent. Dit is uitermate handig bij het testen van het beslismodel, een activiteit die de modelleur ook continu moet uitvoeren. Wacht hier niet mee totdat alles klaar is, want dan is het meestal lastig(er) te achterhalen waar de fout zit. Houd bij de bouw in de eerste plaats altijd de beheersbaarheid van het beslismodel in het oog: niet teveel nodes in een scherm, een logische naamgeving van de modelelementen en houd onderwerpen, die bij elkaar horen, bij elkaar. Maak modellen niet te uitgebreid of te complex en stel geen onnodige vragen. [1] Net als de activiteit testen is het hele planningsaspect en projectmanagement buiten beschouwing gelaten.


14

Figuur 9: gebruik van graphs: elke deelonderwerp is opgenomen in een aparte graph. Knip complexe modellen op wanneer deze als zelfstandig onderwerp zijn te beschouwen. Maak voor deze afgebakende onderwerpen gebruik van graphs. Dit dient bovendien de herbruikbaarheid, want deze kunnen vanuit meerdere kanten aangeroepen worden.

Bedenk bij het modelleren (en in het bijzonder bij complexe modellen) waarom je voor een bepaalde constructie kiest, wanneer dat niet logischerwijze uit het model blijkt (modelleerbeslissing). Leg deze modelleerbeslissingen vast (bij voorkeur in het model zelf in de yellow note, maar eventueel ook in een apart document, met verwijzing(en) naar de node(s) waar deze bijhoren) , zodat de tester en degene die het beslismodel moet valideren en/of goedkeuren deze gedachtegang kan achterhalen. Ook degene die – soms jaren later – het model moet aanpassen/onderhouden kan deze modelleerbeslissingen goed gebruiken.

Hergebruik delen van het model (of van andere beslismodellen), indien dat mogelijk is. Bijvoorbeeld persoonsgegevens, deze zijn vaak voor de verschillende personen hetzelfde. Bouw deze één keer goed voor één type persoon en kopieer deze dan. Stel eenduidige ja/nee vragen in plaats van complexe samengestelde vragen, splits vragen desnoods op. Geef deelmodellen altijd een kop (start) en een staart (einde). In veel gevallen is het doorlopen van een (deel van) het model niet meer nodig (zie hierboven bij de richtlijnen), na het stellen van een aantal vragen. Dit geeft in de modelweergave bovendien een goed overzicht in de loop van het beslismodel (vooral in combinatie met een goed doordachte naamgeving van modelelementen).

Maak gebruik van datatypes voor het stellen van vragen met een waardelijst. Zo kunnen deze vragen eenvoudig hergebruikt worden. Richt daarnaast templates in voor de lay-out van de vraagschermen, zodat dit niet bij elke afzonderlijke vraag ingesteld hoeft te worden. Figuur 10: voorbeeld van een model met een start/einde: vanuit verschillende vragen (de grijsgeteinte) wordt naar het einde van het model gesprongen.


15

C. Analyse van juridische vaagheden en verwijzingen Een onderwerp wat speciale aandacht verdiend bij het bouwen van juridische beslismodellen is het oplossen van vaagheden in de regelgeving en het in acht nemen van verwijzingen.

Volgens de jurist is de wet helder, maar wanneer wetgeving uitgevoerd moet worden in een it-toepassing dan zul je de kennis van deze expert nodig hebben om de juiste afleidingen te kunnen maken. De expert maakt normaliter deze afwegingen in het hoofd (weet hoe de vaagheid te interpreteren of wat de verwijzing inhoudt), maar dat is een activiteit die het beslismodel niet kan uitvoeren. Een voorbeeld uit de vreemdelingenwetgeving:

Ogenschijnlijk zijn dit correcte teksten. Maar bij een nadere lezing zullen de rood gearceerde vaagheden nader ingevuld moeten worden, wil je dit in een beslismodel kunnen verwerken. Het woord “kan” betekent dat iets kan, maar moethet of mag het? Tussen moeten en mogen zit de nodige ruimte. Wanneer is ietsredelijk of billijk? En is onmiddellijk binnen 24 uur of binnen een week? Wetgeving bestaat daarnaast voor een groot deel uit verwijzingen naar andere delen van wetgeving. Soms volstaat het om de verwijzing te laten voor wat deze is. Vooral wanneer de achterliggende regels niet relevant zijn, maar veelal moet via deze verwijzing de betreffende regel binnen het bereik van het model gehaald worden. Verwijzingen zijn vaak expliciet (“zoals bedoeld in artikel x”) maar soms ook erg impliciet, zoals in het voorbeeld hierboven (“de aanwijzingen”).

Figuur 11: “onduidelijkheden” in wetgeving


16

Kortom, terminologie kan voor meerdere uitleg vatbaar zijn en verwijzingen zijn niet altijd duidelijk. Maak deze vaagheden en verwijzingen in regelgeving dan ook zoveel mogelijk samen met de expert expliciet of benoem deze als bewuste vaagheid en besteed hier aandacht aan in de toelichting. Voeg in dat geval bijvoorbeeld jurisprudentie of een beleidsregel toe die uitleg geeft (bijvoorbeeld: in het Petorska-arrest[1] heeft de Hoge Raad “onmiddellijk” uitgelegd als binnen 24 uur).

[1] Fictief


17

6. De Rapportage A. Inleiding In dit deel wordt in detail naar de rapportage gekeken en een aantal algemene opmerkingen over rapportages afgeleid.

B. Rapportfunctie van de Publisher In de Publisher is de rapportage, zoals ook al in de inleiding van dit document is opgemerkt, eigenlijk een resultante van het doorlopen van het beslismodel. Met de “Add document” functie in de Publisher kan op elk moment in het programma een rapport aangemaakt worden. Is het rapport daarmee klaar? Nee. Omdat de rapportage voor vele modellen het belangrijksteoutputproduct van het beslismodel is, is het ook voor de rapportage van belang om, allereerst een aantal afwegingen te maken, omdat dit van invloed kan zijn op de loop van het beslismodel. Bepaalde keuzes beïnvloeden de opzet van het beslismodel in grote mate en het is daarom verstandig om hier van te voren naar te kijken.

C. Van papier naar digitaal Beslismodellen worden vaak gemaakt om een papieren stroom te vervangen met een digitale. Om deze transitie succesvol uit te voeren, moet eerst worden vastgelegd wat de karakteristieke verschillen zijn tussen het bestaande papieren product en het gewenste digitale. Verwijzingen op papier worden bijvoorbeeld intelligente vragen/beslissingen die door het beslismodel uitgevoerd worden in de digitale oplossing. Een ander aspect wat alleen op papier terugkomt, is de ondertekening. Hoe moet daarmee omgegaan worden? Volstaat het om een rapport te printen en deze alsnog handmatig te ondertekenen? In een volledig digitale omgeving (lees: zonder printen, uitsluitend elektronische verzending) zal dat niet altijd gaan (e.g. het is niet handig om een document met de online rapportfunctie van de Publisher uit te printen) en moet voor een andere oplossing gekozen worden (in de Publisher dus voor een printbaar rapport). Verzending is overigens een punt op zichzelf: wordt het rapport ook elektronisch verzonden of alleen geprint en per post verzonden?

Een ander aspect is (pagina)nummering: waar in een papieren rapport men eenvoudig doorverwezen kan worden naar een onderwerp dat op pagina x staat, is dit digitaal lastig omdat het voor de intelligentie van de beslisboom niet helemaal vanzelfsprekend is dat dat ook op de verwezen pagina staat. Daar heb je echter specifieke functies voor zoals de jumplist om terug te gaan. Maar als ten volle gebruik gemaakt wordt van intelligentie in een beslismodel, wat is dan nog het nut van heen- en weer navigeren behoudens controle wat ingevuld

is

(en

zelfs

dat

is

niet

altijd

nodig,

tussensamenvattingen/conclusies in het beslismodel).

bijvoorbeeld

door

de

mogelijkheid

van

Ditzelfde geldt voor vraagnummering; door de

intelligentie in het beslismodel worden alleen de voor de casus relevante vragen gesteld. Daardoor kunnen vragen overgeslagen worden, die niet relevant zijn. Vraagnummering heeft dan geen zin, omdat dan gaten in de nummering ontstaan.


18

Bedenk van te voren dan ook hoe om te gaan met de specifieke papieren elementen van het rapport. Wat is het nut van het papieren element en is deze nog wel nodig na digitalisering? Maak een analyse van de papieren eigenschappen van het bestaande rapport en bedenk hoe deze in de digitale omgeving te verwerken.

In relatie tot het ontwerp van het beslismodel kan ook afgevraagd worden hoeveel intelligentie in het model gestopt moet worden. Moet het de bedoeling zijn dat alle informatie in het rapport middels slimme vraagbomen achterhaald wordt, of kan ook op bepaalde plaatsen volstaan worden met memovelden waarin extra uitleg opgenomen wordt? Soms is dit erg handig om bepaalde keuzes, of hele specifieke omstandigheden nader toe te lichten. Voor intelligent hergebruik van informatie zijn memovelden echter niet bruikbaar.


19

D. Informatieschets Net als voor de beslisboom, is het handig om voor de rapportage van te voren een schets te maken, de informatieschets. Stel hierbij de vragen: wat heb ik nodig om, wat moet ik weten om, hoe kom ik aan: iedere vraag is te vertalen naar een element in het beslismodel waarin uit-gemodelleerd kan worden hoe de op te leveren informatie te achterhalen valt. Het opstellen van een informatieschets heeft als doel het ondersteunen van de communicatie met de gebruiker over de structuur en de inhoud van de benodigde informatie. Deze schets toont alle relevante onderdelen eventueel in de vorm van concrete voorbeelden, of juist betekenisloze teksten (“lorum ipsum”) als het alleen om lay-out gaat. Ook de structuur wordt getoond in de schets aan de rechterkant.

Bij het uitwerken van de informatieschets wordt top-down gewerkt. Het ontwerp van de rapportage wordt steeds verder opgedeeld in groeperingen die ieder op zich nog betekenisvol zijn.

Figuur 12: voorbeeld van een vrij algemene schets van een formulier voor aanvraag van een vergunning. In de marges is aangegeven wat de herkomst is van de formulierdelen. Bijvoorbeeld: de Schadesamenvatting wordt onderverdeeld in de onderdelen Zonder ongeval, Na ongeval en Berekeningsgegevens. Binnen deze groepen valt weer een verdere verdeling te maken naar loongegevens, pensioengegevens, belastinggegevens. Ook deze onderdelen zijn weer onder te verdelen. Voor elke te onderscheiden groep wordt onderzocht onder welke condities de informatie in het rapport verschijnt. Daarnaast wordt ook het aantal iteraties van de groep(en) bepaald (hoeveel verschillende dienstverbanden kan iemand hebben?). Deze condities en iteraties worden verwerkt in het beslismodel. De


20

informatieschets zal doorgaans redelijk 1-op-1 het ontwerp van het beslismodel volgen. Maar mogelijk is het niet wenselijk om alle gestelde vragen van de beslisboom op te nemen in de rapportage (denk bijvoorbeeld aan stuurvragen). De informatieschets is dan ook onlosmakelijk verbonden met het ontwerp van het beslismodel, aangezien het beslismodel eigenlijk bepaalt wat in het rapport kankomen, maar vanuit het rapport bekeken moet worden wat in het beslismodel uitgevraagd moet worden. Zo nodig moet het beslismodel dan aangepast worden om de gewenste gegevens in het rapport te krijgen. Ook kan overwogen worden om het rapport anders in te richten, wanneer een dergelijke aanpassing tot ongewenste resultaten in het beslismodel zal leiden.

Figuur 13: voorbeeld waarin in de schets al rekening is gehouden met feitelijke teksten en opmaak.


21

E. Modelleerrichtlijnen Ook voor het opstellen van de rapportage gelden modelleerrichtlijnen, aangezien rekening gehouden moet worden met de eventuele beperkingen en (on)mogelijkheden van de weer te geven kennis vanuit de beslisboom. Een greep hieruit:[1] 

Wat zijn de vaste tekstblokken (d.w.z. welke worden niet intelligent bepaald in het beslismodel? Welke van deze teksten wil je wel/niet in het beslismodel zien?



Houdt rekening met een logische volgorde (van algemeen naar specifiek) in de indeling van het rapport.



Lijn (financiële) gegevens uit ten behoeve van de leesrust.



Formuleren van rubrieksomschrijvingen zoveel mogelijk even lang definiëren, om te voorkomen dat het rapport een rommelig aanzien krijgt. De afstand tussen omschrijving en rubriek wordt kleiner en daarmee de lay-out duidelijker.



Is het nodig dat het product geprint moet worden (in dat geval is formaat staand meer geschikt dan liggend (voor brede tabellen is liggend weer meer geschikt).



Etcetera…

[1] Ook deze richtlijnen worden in een ontwerpsessie opgesteld. Beantwoord vooraleerst de vraag “hoe wil ik dat het rapport eruit ziet?”. Op basis daarvan kunnen vervolgens nadere richtlijnen geformuleerd worden.

F. Extra informatie en lay-out Meestal zal je wel het hele beslismodel doorlopen willen hebben om een rapport op te kunnen stellen; gegevens die na het maken van het rapport nog uitgevraagd worden, kunnen immers niet in het rapport komen. Naast de inhoud van het beslismodel is bij het configureren van de output het verder nog mogelijk om extra tekst toe te voegen (dit is niet aan te raden omdat deze tekst niet uit het beslismodel zelf komt) of de lay-out nader vorm te geven (bijvoorbeeld om te voldoen aan de huisstijl). Ook voor het onderhoud is het handiger om deze extra informatie in het beslismodel zelf op te nemen. Zo houd je bovendien die informatie ook bij het deel van het model waar het bij hoort.


22

G. Specifieke opmerkingen in relatie tot de huidige rapportage i. Rapport als basis voor ontwerp Het verdient aanbeveling om het rapport als basis voor het ontwerp van het beslismodel te nemen, maar neem wel de verschillen tussen papier en digitaal in ogenschouw. Let ook op dat het rapport de weergave van een casus is en dus waarschijnlijk niet alle mogelijke informatie zal bevatten. Voor het ontwerp van het beslismodel zijn alle mogelijke routes in de beslisboom nodig. Het rapport is nu vooral verhalend van opzet. Daar is een beslismodel niet helemaal geschikt voor, tenzij alle secties via memovelden ingevoerd worden. In dat geval is er niet echt meer sprake van een beslismodel, maar meer van een invoermodule. Probeer hier dan ook zoveel mogelijk vragen voor op te stellen en vanzelf ook zoveel mogelijk onderlinge samenhang (intelligentie) daartussen. Het rapport met vrije tekst wordt daarmee een product met gestructureerde informatie. Het voordeel van gestructureerde informatie is bovendien deze informatie dan altijd op dezelfde plaats staat. Het rapport kan op die manier dan ook sneller en gerichter gelezen worden.

ii. Inbouwen intelligentie Het opzetten van een tekst naar een logisch beslismodel kan lastig zijn, de logische verbanden zijn niet altijd eenvoudig te herkennen. Probeer in de ontwerpfase deze verbanden eerst uit te tekenen. Een paar voorbeelden op basis van signaalwoorden (deel tussen “”) wordt gegeven: 

Een zinsdeel waar “zoals … blijkt” in voorkomt, suggereert dat informatie valt af te leiden. Modelleer deze informatie uit en gebruik deze informatie om dergelijke afleidingen te doen.



Een zin met “vanaf …” duidt erop dat vanaf deze datum een verandering plaats heeft gevonden / zal vinden. In het kader van beslismodellen worden dit tijdsversies of tijdreizen genoemd. Dit is in het juridisch domein een veel voorkomende situatie. De Publisher biedt verscheidene mogelijkheden om hiermee om te gaan: 

Zo kan er per norm voor elke periode een afzonderlijke berekening gemaakt worden, waarin als voorwaarde de periode wordt gebruikt. In de ‘source’ kan deze methode eventueel nog met een ‘if then begin / end’ worden vereenvoudigd, zodat de periodevoorwaarde maar eenmaal gebruikt hoeft te worden in plaats van bij elke berekening opnieuw.



Je kan de normen ook extern opslaan, bijvoorbeeld in een database. Bij het inlezen uit die database bepaald je dan aan de hand van de periode welke rij ingelezen moet worden.



Er kan een kopie van de gehele ‘graph’ gemaakt worden met daarin zowel het beslismodel als de van toepassing zijnde normen. Afhankelijk van de periode doorloop je dan de juiste graph.



Je kan ook verschillende versies van het model maken. Denk aan de aangifteprogramma’s van de Belastingdienst. Dat ‘matcht’ vaak ook met de praktijk, namelijk het verstrekken van een licentie per versie/jaar.


23

Bepaal van te voren dus goed welke gegevens uitgevraagd moeten worden, welke gegevens af te leiden zijn, wat precies de grondslagen zijn en hoe de informatie getoond moet worden. Kortom, maak een ontwerp/informatieschets.

iii. Tussenconclusies Het is een optie om voor de deelonderwerpen in het beslismodel gebruik te maken van tussenconclusies voor een overzicht van afgeleide elementen. Dit is enerzijds voor de gebruiker van het systeem handig, zodat bekend is met welke informatie de afleidingen gedaan worden, maar ook voor het maken van de rapportage. Deze afleidingen kunnen in het rapport hergebruikt worden en overzichtelijk getoond worden. Maak hierin vooral ook duidelijk met welke informatie de afleidingen zijn gemaakt, zodat dit altijd valt te valideren. Bovendien blijft het beslismodel zo ook overzichtelijk, omdat het voor de gebruiker duidelijk is waar hij is in het programma en wat met de gegevens gedaan wordt.

iv. Gebruik waardelijsten Maak vooral gebruik van waardelijsten bij de invoer in het beslismodel (de Publisher biedt hier tal van mogelijkheden voor, variërend van “ja/nee-drop down menus” tot volledig te configureren radiobuttons). De specifieke waarde van een dergelijke lijst kan in een ander deel van de beslisboom weer hergebruikt worden (zoals hierboven al eerder aangestipt, is hergebruik van de inhoud van memovelden een stuk lastiger). Een ander voordeel is dat er geen waarde ingevoerd kan worden, die niet bestaat of die net even anders geformuleerd is, maar hetzelfde betekent; de Publisher toont alleen de mogelijke verwijzingen. Ook bedragen en percentages worden als numerieke gegevens ingevoerd om mee te kunnen rekenen. Daar waar het echt nodig is om situaties nader toe te lichten kunnen vanzelfsprekend memovelden toegevoegd worden.

H. Bewijsstukken Rapportages kunnen worden aangevuld met een aantal bewijsstukken, zoals bijvoorbeeld een loonstrook etc. Probeer in de (tussen)conclusies ook af te leiden welke documenten als bewijsstukken toegevoegd moeten worden. Het beslismodel levert dan dus een checklist op voor relevante documenten.

I. Import/Export rekengegevens Het kan voorkomen dat het rapport uit verschillende delen bestaat waarin veel verschillende informatie moet worden ingevuld. Het complete rapport kan dan erg onoverzichtlijk voorkomen. Met het beslismodel zijn hier verschillende oplossingen voor.

De eenvoudigste is om simpelweg een aparte rapportage te maken, waarin alleen een bepaald deel van de invoer wordt weergegeven. In datatypiste kan dan met de verscheidene deelrapporten gemakkelijk aan de slag. De beslisboom heeft immers de afleiding gedaan van alle relevante invoergegevens.


24

Een meer geautomatiseerde oplossing is om een interface te bouwen welke bepaalde gegevens van een webserver haalt. Handmatige invoer van deze gegevens is dan niet meer nodig.

Andersom is deze opmerking ook te maken. Een aantal gegevens komt uit gestructureerde overzichten, zoals loonstroken, pensioenoverzichten of salarisadministraties. Om invoer in het beslismodel te versnellen zou deze gestructureerde informatie uit andere systemen ingelezen kunnen worden. Met deze informatie wordt dan in het beslismodel rekening gehouden. Ook hier geldt, net zoals hierboven, dat dit een punt van nader onderzoek is. Ook al zijn vele standaarden geformuleerd in de wereld van de automatisering, helaas kunnen nog niet alle systemen eenvoudig met elkaar communiceren.


25

7. Acceptatie Beslismodel A. Acceptatiecriteria Na een rondgang langs ontwerp, bouw, het maken van een rapportage en waarschijnlijk een aantal keren terug naar het ontwerp en (her)bouw is het beslismodel klaar. Maar wanneer is een beslismodel echt klaar en hoe kan dat gemeten worden? De vraag die nu dan nog gesteld moet worden is of de uitkomst van het model ook de verwachte uitkomst is?

Verwachte uitkomst heeft al in zich dat degene die accepteert bepaalde verwachtingen heeft. Het is verstandig om deze verwachtingen al voor de bouw in kaart te hebben, zodat de modelleur hier al van te voren rekening mee kan houden. Deze verwachtingen bestaan vaak voor een deel uit de verwachte functionaliteit, de persoonlijke verwachtingen, zoals het ontwerp, maar ook of de rekenuitkomsten voldoen en andere nietfunctionele eisen zoals de lay-out en privacy-eisen. Dit bij elkaar worden de acceptatiecriteria genoemd. Deze helpen de eindbeslisser bij het geven van zijn/haar acceptatie op het opgeleverde model.

B. Algemene richtlijnen uit de praktijk Ook ten aanzien van acceptatiecriteria zijn standaarden ontwikkeld, zodat niet voor elk systeem opnieuw de volledige set bedacht hoeft te worden. Hieronder een aantal aandachtspunten bij de acceptatie van een beslismodel, voor een deel gebaseerd op de norm ISO/IEC 9126: 

Een beslismodel is begrijpelijk: dit wordt verstaan in het licht van de doelgroep. Voor een groep van expertgebruikers kan de terminologie ingewikkelder zijn dan wanneer niet inhoudelijk deskundigen het beslismodel gebruiken. De overheid hanteert bijvoorbeeld taalniveau ‘eenvoudig Nederlands’ als richtlijn voor haar formulieren.



Een beslismodel moet toepasbaar zijn. Het moet de werkelijkheid zodanig weergeven dat het voldoende basis biedt voor de gewenste acties. Voor een geldig rijbewijs geldt bijvoorbeeld dat deze een pasfoto moet bevatten. Maar niet elke pasfoto is geschikt op een rijbewijs. Je gezicht moet in een bepaalde hoek zichtbaar zijn, je mag geen hoofddeksel dragen. De vraag of een pasfoto aanwezig is dus niet voldoende en is dus geen gewenste actie, aangezien nadere eisen te benoemen zijn aan de foto.



Een beslismodel is waarheidsgetrouw als het een correcte afspiegeling van de beschreven situatie vormt. Voor het toetsen van de waarheidsgetrouwheid is de traceerbaarheid van de kennis in beslismodellen erg belangrijk. Dit betreft de bron van de kennis (bijvoorbeeld weten regelgeving), maar ook de historie van deze kennis (is het beslismodel veranderd en zo ja wanneer en door wie (versiebeheer)). Als de kennis in een beslismodel niet traceerbaar is, kan de waarheidsgetrouwheid van dit kennismodel nooit voldoende worden bevonden.



Een beslismodel is onderhoudbaar. Beslismodellen moeten gemakkelijk en snel aan te passen zijn naar aanleiding van veranderingen in wetgeving of beleid.


26

Een beslismodel is volledig en bevat dan ook alle informatie voor het betreffende doel. Hierbij moet aan één kant gekeken worden of informatie ontbreekt in de beslismodellen en aan de andere kant of er niet te veel irrelevantie informatie is.


27

8. Bijlage


28


29


30

Aanwijzingen en richtlijnen voor een beslismodel. Van ontwerp tot validatie

Recommend Documents