De recente literatuur over decision management en business rules geeft de indruk dat elke business rule uiteindelijk te maken heeft met het maken van een (operationele) beslissing.

Ross stelt dat niet elke business rule in een decision table past.

Betekent dat nu ook dat er business rules zijn, die niet tot een beslissing leiden?

Weergaven: 1081

Berichten in deze discussie

Zoals ik het zie, zijn de regels in een decision table, of een 'rule family' zoals Goldberg en Von Halle het noemen in principe afleidingsregels. Als Ross het heeft over business rules die niet in een decision table passen, heeft hij het volgens mij over business rules die geen afleidingsregels zijn. Dan kun je bijvoorbeeld denken aan (het voorbeeld dat ik altijd geef):

1. "De laatste die het kantoor verlaat, doet het licht uit", of

2. "Bij het vaststellen van de hoogte van de uitkering wordt uitsluitend afgeweken van het advies van het computersysteem met toestemming van de teamleider."

Deze regels zijn geen afleidingsregels. Daarom passen ze niet goed in een decision table. Maar, spelen ze dan geen rol bij een beslissing? Dat denk ik wel, maar daar zit een addertje onder het gras. Een regel als regel 2 kan een rol spelen bij het besluit van een medewerker om toestemming te vragen aan zijn teamleider, maar kan ook een rol spelen bij het besluit van de teamleider om een medewerker op het matje te roepen. De Rossiaanse niet-afleidingsregels kunnen dus in verschillende situaties verschillend toegepast worden. En bij dat toepassen gebeurt iets bijzonders. Een regel als regel 2 wordt dan als het ware omgeschreven (of 'geoperationaliseerd') naar een afleidingsregel. In ons voorbeeld:

2a. "ALS ik (de medewerker) het advies van het computersysteem niet wil overnemen, DAN moet ik toestemming vragen"

2b. "ALS de medewerker mij (de teamleader) niet om toestemming heeft gevraagd om af te wijken van het advies van het computersysteem, DAN moet ik de medewerker daarop aanspreken."

In de visie van Ross is het een voordeel dat er business rules zijn (of kunnen zijn) die niet op die manier concreet zijn gemaakt voor een specifieke situatie, die niet geoperationaliseerd zijn. Immers: ze zijn dan onafhankelijk van de implementatie in processen of technologie en wijzigen naar verwachting daarom minder vaak dan geoperationaliseerde regels.

Het probleem dat Von Halle en Goldberg echter signaleren, is dat het niet-operationaliseren van business rules kan leiden tot wat zij noemen 'a big bag of rules': een grote bak regels, sommige relevant andere niet, met kop noch staart die moeilijk beheersbaar is.

Wat ik bij het toepassen van The Decision Model in de praktijk daarom doe, is top down inzoomen op de beslissingen in een proces, en daar de regels van achterhalen, die daarmee automatisch relevant én geoperationaliseerd zijn. Daarmee kun je een structuur aanbrengen die voor de business relevant is. Zo voorkom je dat je eindigt met een big bag of rules. Immers: je structureert je regels naar beslissingen en processen die voor de business relevant zijn.

Anders gezegd: operationele beslissingen zijn een filter om te kijken naar je business rules. Dankzij dat filter kun je de relevante van de irrelevante business rules onderscheiden en kun je regels beter beheren.

Helpt dit?

(Disclaimer: Ik ben consultant bij RuleManagement Group. RuleManagement Group is partner van KPI voor The Decision Model in de Benelux)

De wijze waarop de vraag is gesteld lijkt te duiden op twee vragen. 

  1. Zijn beslissingstabellen de enige manier om beslislogica vast te leggen?
  2. Kunnen regels die niet in een beslissingstabel passen wel bij een beslissing horen?

De twee vragen staan op zichzelf. Door ze te combineren worden verkeerde conclusies getrokken zoals we terugzien in het antwoord van Bas. Desalniettemin levert het interessant materiaal om een aantal definities duidelijk te maken. We gaan er dus even op in en beginnen met de oorspronkelijke vraag van Alcedo.

Zijn er business rules die niet tot een beslissing leiden? 

Allereerst is het woord beslissing erg verwarrend omdat het kan staan voor:

  1. het eindresultaat  na de toepassing van een regel (het besluit)
  2. een activiteit waarbij door het volgen van regels tot een besluit wordt gekomen

Natuurlijk zijn er regels die (nog) nooit zijn toegepast en dus ook (nog) nooit tot een beslissing (besluit) hebben geleid maar wel degelijk regels zijn..... ik denk niet dat je op dit antwoord zat te wachten dus we gaan snel verder met de tweede betekenis. Het volgen van een regel heeft altijd een beslissing tot resultaat en in die zin hoort iedere regel potentieel bij een activiteit ‘beslissen’ (voor veel van deze beslissingen is het echter niet de moeite waard om ze expliciet te formuleren en beheren).

Zijn beslissingstabellen de enige manier om beslislogica vast te leggen? Ik zou niet weten waarom! Dat is toch gewoon een representatie keuze? Soms handig, soms niet. 

De tabel (met als bijnaam rule family of decision table) wordt het afgelopen jaar (net als 15 jaar geleden) de hemel ingeprezen. Alsof er niets anders meer kan zijn. Daar is zelfs volgens de grondleggers  (Jan Vanthienen) in dit vakgebied  wel wat nuance op zijn plaats 

Zijn er regels die niet in een beslissingstabel passen? 

Ja, want een beslissingstabel heeft altijd tenminste één conclusie en er zijn allerlei regels die geen conclusie (informatie die wordt afgeleid om de terminologie van Bas te gebruiken) hebben, zoals: 

  • Een aanvrager van .... moet tenminste 18 jaar zijn.
  • Een persoon op een bouwplaats moet een helm dragen.
  • etc.

Deze regels kunnen wel degelijk operationeel uitgevoerd worden en kunnen ook onderdeel zijn van een beslissing.

Zijn er afleidingsregels die niet in een beslissingstabel passen?

Ja,  denk maar aan rekenregels  “A =  B +  C “ Wat wordt hier trouwens afgeleid? Volgens mij kun je hier potentieel 4 beslissingen mee nemen (Wat is A als je B en C weet, Wat is B als je C en A weet, ...  etc.)

Zijn er nog andere afleidingsregels die niet in een beslissingstabel passen?

Zodra je moet redeneren over meerdere instanties kun je geen beslissingstabel gebruiken zonder nieuwe (vaak artificiële) terminologie te introduceren.  Probeer dit maar eens in een beslissingstabel te krijgen zonder nieuwe woorden te introduceren:

Een korting is toegestaan indien de aanvrager in de afgelopen 6 weken minimaal 4 weken 30 Euro heeft uitgegeven.

En dan hebben we hier nog te maken met zeer simpele voorbeelden in vergelijking met wat ik in de praktijk tegenkom ...

Conclusie:

  • Beslissingstabellen zijn een representatie vorm die soms handig is en soms niet.
  • Het toepassen van een regel is onderdeel van een beslisactiviteit (maar niet alle beslissingsactiviteiten zijn interessant genoeg om expliciet te benoemen).

Dan het antwoord van Bas. Niemand zit te wachten op een ‘big bag of rules” natuurlijk (zeker niet als je bedoelt dat die big bag ongesorteerd en ongeorganiseerd is).  Maar om nu te zeggen dat het koppelen van regels aan beslissingen de enige oplossing is gaat velen te ver (de disclaimer verklaart wat dat betreft veel). Het is één van de manieren om naar die lijst regels te kijken. Waarom is het niet dé manier om naar die lijst regels te kijken? Omdat sommige regels voor meerdere beslissingen relevant zijn en Bas geeft een prachtig voorbeeld geeft van hoe je hergebruik van regels om zeep helpt.

Hij vormt zijn voorbeeld regel om naar iets wat:

  • niet hetzelfde is  
  • niet kan worden hergebruikt in een andere beslissing

... want de nieuwe regels (2a en 2b van Bas) vertellen niets over de wijze waarop beoordeeld kan worden of de hoogte van de uitkering conform de regels is bepaald. Er van uitgaande dat Bas in voorbeeld 2. met ‘uitsluitend’ bedoeld dat het om een verplichting gaat (dus: ... mag alleen ...)  moeten we, bij voortzetting van zijn methode dan naast regel 2a en 2b, óók nog de regel toevoegen:

ALS  de hoogte van de uitkering afwijkt van het advies van het computersysteem EN de teamleider heeft geen toestemming gegeven DAN is de hoogte van de uitkering foutief vastgesteld.

Ergo: we krijgen weer meer regels om te beheren (en iedereen kan gemakkelijk nog een 2d, en 2e verzinnen).

Wat nog beangstigender is, is dat Bas precies doet wat programmeurs ook altijd moeten doen doordat ze (meestal) alleen maar de IF-THEN-ELSE constructie tot hun beschikking hebben.  Gaan we die schone taak nu weghalen bij de programmeur en bij de business leggen? Dat lijkt mij toch wel de wereld op zijn kop!

We zijn toch niet aan het programmeren? Waarom moet die regel dan zonodig omgeschreven worden? Zodat hij automatiseerbaar is? Of zodat hij beter in de beslissingstabel past? Aha!

De redenering van Bas volgend kun je pas zeggen of een regel relevant is als je de regel kan koppelen aan een beslissing of proces. Moet je dan eigenlijk niet eerst alle beslissingen en processen kennen? Ik ben benieuwd welke organisatie al zo ver is... tot die tijd kan je niet over irrelevante business rules spreken, lijkt mij.

Helpt dit?

Bijlagen:

@Bas, @Silvie, dank tot zover voor de uitgebreide antwoorden. 

@Bas, jij formuleert wat preciezer en uitvoeriger wat ik met mijn eerste constatering bedoelde: de operationele beslissing wordt als filter gebruikt om het ons makkelijk te maken. Ik ben het met je eens, en heb in de praktijk ervaren dat dat zaken inderdaad eenvoudiger maakt. Maar dan blijft de hoofdvraag over: waar zijn dan die "andere" rules (die jij als irrelevant kwalificeert) voor bedoeld?

@Silvie, je hebt helemaal gelijk, mijn vraag was niet helemaal eenduidig. Jij legt de vinger op een paar zere plekken, en je voorbeelden zijn, zoals gebruikelijk, sprekend. Het grappige is dat je nog een categorie noemt waar ik nog niet aan gedacht had: dat er ook beslissingsactiviteiten zijn die niet de moeite van het expliciteren waard zijn.

Zitten we nog met de vraag: waar kunnen regels, die niet voor beslissingen bedoeld zijn, dan toe dienen? Ik moet daarbij denken aan CommonKads, framework voor het specificeren van kennistaken. Beslissen is daar slechts één van de kennistaken. Maar er zijn er nog meer, zoals: analyseren, ontwerpen, diagnosticeren, voorspellen. Daar zijn natuurlijk ook regels voor, en die zijn van een ander karakter. 

Het bijzondere vind ik dat dit wijdere perspectief van kennistaken niet is terug te vinden in de recente literatuur over business rules, en volgens mij is dat een gemis. The Decision Model doet je geloven dat eigenlijk alles een beslissing is, en dat is zoals Silvie ook aangeeft, niet het geval. Ook James Taylor geeft hier geen soelaas, want zijn onderwerp is Decision Management.

Ik heb het idee dat we het referentiekader van CommonKads best wel weer eens uit de kast kunnen halen. Het gaat mij dan specifiek om de zogenaamde "task typology". Een andere manier om te regels te classificeren, om met de grote big bag om te kunnen gaan. 

Maar hoe precies? Ideeën?

Afbeelding van de task typology van CommonKads (zie www.commonkads.uva.nl).

Silvie, dank voor je commentaar. Dit kan een interessante discussie worden, maar de toon van je reactie strijkt me tegen de haren in. Je schrijft:

Door [de twee vragen van Alcedo] te combineren worden verkeerde conclusies getrokken zoals we terugzien in het antwoord van Bas. Desalniettemin levert het interessant materiaal om een aantal definities duidelijk te maken. We gaan er dus even op in en beginnen met de oorspronkelijke vraag van Alcedo.

Dat vind ik nogal arrogant geformuleerd, om het zwak uit te drukken. Misschien kun je trouwens zelf ook je commerciële relatie met Ron Ross wat toelichten in plaats van op de man te spelen n.a.v. mijn disclaimer?

Dat gezegd hebbende, denk ik dat het goed is om een aantal punten te verduidelijken.

In de literatuur over Decision Management waar Alcedo in zijn oorspronkelijke bericht naar verwijst, speelt de term 'decision' (beslissing) vanzelfsprekend een centrale rol. Binnen Decision Management is een beslissing een scharnierpunt tussen een procesbeschrijving waaruit blijkt dat beslissing genomen wordt, en de bedrijfsregels waar de beslissing op gebaseerd wordt (zie bijvoorbeeld het stuk van James Taylor, [1]).

Het inzicht van decision management is, dat het zinnig is om een duidelijk onderscheid te maken tussen beslissingen en regels: beslissingen zijn stappen (taken) in een procesbeschrijving en regels ondersteunen een beslissing (een soort taak). Daaruit volgt, dat je naar de procesbeschrijving moet kijken om te zien of het volgen van een regel tot een beslissing leidt (in de terminologie van Decision Management). 

Om een voorbeeld te geven, het volgen van een individuele regel als:

  1. Als de aanvraag is ingediend in 2009, geldt een subsidieplafond van 26.000.000 euro.

... leidt pas tot iets dat we een 'beslissing' moeten noemen als bepalen-wat-het-subsidieplafond-is een stap is een procesbeschrijving. Dat zou kunnen, maar het is vaak niet zo. Een procesbeschrijving wordt in het algemeen op een hoger abstractieniveau opgesteld. Gelukkig hoeven we regel 1 niet weg te gooien. Regel 1 kan bijvoorbeeld prima een rol spelen bij een andere beslissing, bijvoorbeeld bij de beslissing bepalen-wat-de-hoogte-is-van-het-subsidiebedrag. Ten minste, aangenomen dat bepalen-wat-de-hoogte-is-van-het-subsidiebedrag wel een beslissing is in een procesbeschrijving.

Daarmee zeg ik natuurlijk niet, dat een bedrijfsregel altijd maar voor *één* beslissing relevant is en niet kan worden hergebruikt. En ik zeg ook niet, dat je alle bedrijfsregels in beslistabellen, decision tables of rule families kunt of moet stoppen. En ook niet, dat je bedrijfsregels alleen maar kunt ordenen via beslissingen. En waarom dit is 'wat programmeurs moeten doen' met 'IF-THEN-ELSE constructies' ontgaat mij volledig.

Beslissingen zijn juist business dingen bij uitstek, precies omdat ze zich op het niveau van de bedrijfsprocessen bevinden en niet, zoals regels, net daaronder. Hierdoor zijn beslissingen breder herkenbaar in de business dan regels. De beslissingen-bril van Decision Management is dan ook een verrijking: als je weet wat de beslissing(en) zijn die door een regel gestuurd worden, dan helpt dat enorm bij het begrijpen en beoordelen van die regel.

Op al deze punten heeft Silvie mij, bewust of onbewust, verkeerd geïnterpreteerd. Verrassend genoeg geeft zij als afsluiting wel een prima samenvatting van de kijk van Decision Management op business rules:

"De redenering van Bas volgend kun je pas zeggen of een regel relevant is als je de regel kan koppelen aan een beslissing of proces."

Dat is zo. De relatie met een beslissing (en dus een proces) bepaalt de relevantie van een regel. Maar die stelling kun je natuurlijk niet omdraaien door te zeggen dat je 'dus' eerst alle beslissingen en processen in de organisatie moet kennen voor je kunt beginnen met Decision Modelling. De aanpak van The Decision Model is juist heel praktisch: eerst bepaal je welke operationele beslissingen cruciaal zijn voor de organisatie, en vervolgens bepaal je welke regels nodig zijn om die beslissing te nemen. Zo kun je beoordelen welke regels je als eerste moet expliciteren en welke (nog) niet. Zo blijf je gefocust en hou je grip op je regels tijdens het opstellen ervan. Niet alleen als het er tien zijn, niet alleen als het er honderd zijn, maar ook als het om duizenden regels gaat. Dat Silvie denkt, dat je niet kunt spreken over 'irrelevante regels', geeft voor mij aan dat zij het probleem van de beheersing van regels absoluut onderschat.

In het heel leesbare artikel "Three Reasons to Upgrade from Business Rules to Decision Models" [2] gaan Barbara von Halle en Larry Goldstein dieper in op deze aanpak.

[1] Taylor, James, "How to Get Smarter with Decision Management", http://www.brcommunity.com/taylor.php

[2] Goldstein, Larry, en Von Halle, Barbara, "Three Reasons to Upgrade from Business Rules to Decision Models". http://www.modernanalyst.com/Resources/Articles/tabid/115/articleTy...

(Disclaimer: Ik ben consultant bij RuleManagement Group. RuleManagement Group is partner van KPI voor The Decision Model in de Benelux.)

Alcedo, de CommonKads typologie en de relatie met decisions en business rules is inderdaad erg interessant. Ik kom daar graag later op terug.

Overigens bedoel ik, als ik het heb over relevante en irrelevante business rules, hun relevantie voor een specifiek proces van een specifieke organisatie. Ik denk niet dat er hele categorieën business rules zijn die in totaliteit irrelevant zijn.

Bas, goed dat je dat even rechtzet.


Bas Leerintveld zei:

Alcedo, de CommonKads typologie en de relatie met decisions en business rules is inderdaad erg interessant. Ik kom daar graag later op terug.

Overigens bedoel ik, als ik het heb over relevante en irrelevante business rules, hun relevantie voor een specifiek proces van een specifieke organisatie. Ik denk niet dat er hele categorieën business rules zijn die in totaliteit irrelevant zijn.

Het idee om de CommonKads Task typology te gebruiken om regels te classificeren is door  wijlen Leo Hermans al voorgesteld. Hij heeft dit tijdens de 2de European Business Rules Conference in Zurich gepresenteerd. Het CommonKads framework is altijd een enorme inspiratiebron en hulp voor mij geweest maar ik vind het niet handig om regels op basis daarvan te classificeren. Een regel kan in meer dan één taak ingezet worden dus wat kies je dan?

Een voorbeeldje:

  • Een werknemer mag niet meer dan 4 uur achtereen ingezet worden voor taak Y.

Bij deze regel denk je natuurlijk direct aan scheduling: je hebt een groep werknemers en die  moet je toekennen aan taken. Maar waarom niet ook aan monitoring? We moeten monitoren of mensen niet te lang aan dezelfde taak werken? Of beoordeling: zijn er medewerkers die de regels hebben overtreden?

De CommonKads taak typologie is handig omdat iedere taak een bepaald soort resultaat, invoer en redenering met zich meebrengt. De classificatie is daarbij één van de tien soorten (en het meest gebruikt). Op basis van deze kennis kan je vaak wel zeggen naar wat voor soort regels je op zoek moet gaan (andersom dus). Zie mijn column voor BRCommunity die geïnspireerd is op deze redenering:

Silvie Spreeuwenberg, "Use the Right Tool for your Job," Business Rules Journal, Vol. 12, No. 11 (Nov. 2011), URL:  http://www.BRCommunity.com/a2011/b624.html 

Meer over de problematiek betreffende hergebruik van regels kun je lezen in de column van Rik Gerrits voor BRCommunity: 

Rik Gerrits, "Business Rules, Can They Be Re-used?" Business Rules Journal, Vol. 5, No. 9 (Sep. 2004), URL:  http://www.BRCommunity.com/a2004/b203.html  

Alhoewel taken helpen bij het opstellen van regels omdat ze je naar een resultaat toe laten werken is het gevaar dat de regels ook met een specifieke richting opgeschreven worden. Rik laat zien dat ze dan niet meer door andere taken kunnen worden hergebruikt. Het blijft dus opletten! Nothing is ever easy.

Silvie Spreeuwenberg samen met Rik Gerrits.

RSS

Sponsoren

Advertenties

© 2020   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden