De hoge frequentie waarin bedrijfsregels veranderen wordt veroorzaakt door snel veranderende klantenwensen, wet- en regelgeving en beleid. Tegelijkertijd vindt er een beweging plaats waarin meer transparantie over de bedrijfsvoering wordt geëist. Deze beweging dwingt organisaties om aan te kunnen tonen welke bedrijfsregels in welke situaties zijn toegepast. Om de hoge frequentie van verandering bij te kunnen houden en aan de vraag van transparantie te voldoen wordt het beheer van bedrijfsregels steeds belangrijker. Het beheer van bedrijfsregels kan worden onderverdeeld in drie onderdelen: 1) versiebeheer, 2) geldigheidsbeheer en 3) traceerbaarheid. In dit artikel gaan we in op geldigheidsbeheer van bedrijfsregels. Eerst zal het doel van geldigheidsbeheer worden gepresenteerd. Vervolgens wordt uitgelegd wat niet-temporeel geldigheidsbeheer inhoudt inclusief een voorbeeld van een niet-temporeel scenario. Daarna wordt uitgelegd wat temporeel geldigheidsbeheer inhoudt inclusief drie voorbeelden van temporeel geldigheidsbeheer.

Wat is het doel van geldigheidsbeheer?

Het doel van geldigheidsbeheer is om op ieder moment een specifieke versie van een specifiek(e) (set van) artefact(en) ter beschikking te hebben. Door dit te realiseren kan er op elk moment ingezien worden welk(e) specifiek(e) (set van) artefact(en) op dat moment geldig is, was of wordt. Voor het realiseren van geldigheidsbeheer zijn twee verschillende methoden bekend: niet-temporeel en temporeel geldigheidsbeheer. Deze methoden kunnen ook naast elkaar gebruikt worden. Beide methoden worden in de volgende secties toegelicht.

Niet-temporeel geldigheidsbeheer

De eerste methode om geldigheidsbeheer te realiseren is de niet-temporele methode ook wel bekend als “bedrijfsregels over bedrijfsregels”. In deze methode wordt er gebruik gemaakt van (een selectie van) bedrijfsregels om een specifieke context (bedrijfsregelset) mee te selecteren, zie Figuur 1‑1.

Om de methode “bedrijfsregels over bedrijfsregels” te illustreren volgt hieronder een voorbeeld waarin de doorwerkbonus wordt gebruikt als context: “Tussen 2015 en 2017 is een doorwerkbonus van kracht voor 65+’ers. In 2017 komt een nieuwe doorwerkbonus. Mensen van boven de 67 jaar die nog wel werken, ontvangen een hogere doorwerkbonus. Voor mensen met een leeftijd tussen de 65 en 67 jaar, geldt de oude regeling van de doorwerkbonus”.

Figuur 1: Niet-Temporeel Geldigheidsbeheer

Door deze wijziging ontstaat er een context, namelijk context A. Hierin staat de oude regeling van de doorwerkbonus. Tegelijkertijd ontstaat er een andere context, namelijk context B. Hierin staat de nieuwe regeling van de doorwerkbonus. Om te bepalen welke context gebruikt moet worden voor het maken van een beslissing, moeten er (selectie)bedrijfsregels worden opgesteld. De (selectie)bedrijfsregel bij dit voorbeeld luidt als volgt: Is de leeftijd in 2017 van de betreffende persoon hoger dan 67 jaar? Bij ‘ja’ wordt context B gebruikt en bij ‘nee’ wordt context A gebruikt.

De methode “bedrijfsregels over bedrijfsregels” kent zowel voor- als nadelen. Een voordeel is dat wijzigingen snel kunnen worden doorgevoerd, omdat in de meeste gevallen een nieuwe context wordt gemaakt door het kopiëren van een bestaande context. Als deze kopie is gemaakt, wordt een zeer beperkt aantal bedrijfsregels aangepast. Het snel kunnen wijzigen van bedrijfsregels maakt deze methode efficiënt in gebruik. Een nadeel hiervan is dat een aanzienlijke hoeveelheid redundante bedrijfsregels ontstaat. Dit is het resultaat van het feit dat er meerdere contexten, inclusief bijbehorende bedrijfsregels, naast elkaar opgeslagen dienen te worden die nagenoeg hetzelfde zijn.

Temporeel geldigheidsbeheer

De tweede methode om geldigheidsbeheer te realiseren is de temporele methode. Deze methode wordt ook vaak aangeduid als tijdreizen. Bij de temporele methode wordt er gebruik gemaakt van tijdstippen om de geldigheid van artefacten te bepalen. Om de geldigheid correct te bepalen, zijn er vier tijdstippen nodig: de valide starttijd, de valide eindtijd, de systeeminvoertijd en de systeemeindtijd.

De valide starttijd is het tijdstip waarop een artefact van kracht wordt. De valide eindtijd is het tijdstip waarop een artefact niet meer van kracht is. De systeeminvoertijd en de systeemeindtijd zijn de automatisch geregistreerde tijdseenheden waarop een artefact is ingevoerd of wordt gewijzigd. Wanneer een artefact wordt ingevoerd, wordt de systeeminvoertijd gelijk gesteld aan het tijdstip waarop de invoer plaatsvindt en wordt de systeemeindtijd automatisch op oneindig gezet. Op het moment dat dit huidige artefact wordt gewijzigd wordt de systeemeindtijd van dit artefact gelijk gesteld aan het tijdstip waarop de wijziging plaatsvindt. Dit tijdstip wordt tegelijkertijd als systeeminvoertijd aan de nieuwe registratie van het artefact toegekend. De vier hiervoor genoemde velden maken het mogelijk om te ‘tijdreizen’. Met ‘tijdreizen’ is het mogelijk om de historische staat of de toekomstige staat van een artefact te kunnen raadplegen. Hieronder wordt aan de hand van drie scenario’s uitgelegd wat geldigheidsbeheer en tijdreizen inhouden. In de drie onderstaande scenario’s (algemeen voorbeeld, kinderkorting, doorwerkbonus) wordt gebruik gemaakt van datums, om het verloop overzichtelijk te houden. Deze datums kunnen ook vervangen worden door tijdseenheden.

Scenario 1: algemeen voorbeeld

De bedrijfsregel met bedrijfsregelnummer 045 (BR_ID 045) wordt op 7 april 2014 ingevoerd (sys_start). Bij het aanmaken van een nieuwe rij in de administratie wordt de sys_eind-datum altijd automatisch ingevuld als oneindig (∞). Echter is deze bedrijfsregel al op 4 april gemaakt en geldig. Dit wordt bij de val_start-datum ingevoerd. De val_eind-datum wordt op oneindig (∞) gezet aangezien de bedrijfsregelanalist niet weet tot wanneer de bedrijfsregel geldig is. In de administratie (Tabel 1‑1) ziet dit er als volgt uit:

Vervolgens wordt de inhoud van bedrijfsregel 045 op 14 april 2014 (sys_start) aangepast van A naar B. Deze wijziging heeft in een temporeel administratiesysteem tot gevolg dat er twee extra rijen worden toegevoegd. Eén rij om aan te geven dat de huidige inhoud van bedrijfsregel 045 ongeldig wordt (zie de donkerblauwe rij) en één rij om de nieuwe inhoud van bedrijfsregel 045 te registeren (zie de lichtoranje rij). De sys_eind-datum van de eerste rij (zie blauwe rij) wordt nu automatisch veranderd naar dezelfde datum als de sys_start-datum van de wijziging namelijk 14 april 2014 (zie de dik omrande cellen). Dit voorbeeld laat duidelijk zien dat de eerste regel niet overschreven wordt, maar dat er gewoon een nieuwe regel bij komt. In de administratie (Tabel 1‑2) ziet dit er als volgt uit:

Op 4 juni 2016 wordt besloten dat de bedrijfsregel 045 niet meer van toepassing is, de bedrijfsregelanalist past direct de val_eind-datum naar 4 juni 2016. De val_start-datum is gelijk gebleven aan de regel daarvoor (zie donkeroranje regel). Daarnaast wordt de sys_eind-datum van de derde rij (zie lichtoranje regel) automatisch veranderd naar dezelfde datum als de sys_start-datum van de wijziging namelijk 4 juni 2016 (zie de dik omrande cellen). De sys_eind-datum van de donkeroranje regel wordt automatisch op oneindig gezet. In de administratie (Tabel 1-3) ziet dit er als volgt uit:

Om temporeel geledigheidsbeheer voldoende te verduidelijken is ervoor gekozen om nog twee voorbeelden te presenteren. Voorbeeld één beschrijft de kinderkorting en voorbeeld twee beschrijft een situatie met betrekking tot de doorwerkbonus.

Scenario 2: Kinderkorting

Op 1 januari 2007 is artikel 8.12 Kinderkorting van kracht. Hieronder in Tabel 1-4 staat de administratie weergegeven waarin één bedrijfsregel staat opgeslagen binnen de context Kinderkorting. Merk hierbij op dat de context Kinderkorting in de werkelijkheid uit meer bedrijfsregels bestaat maar om het voorbeeld overzichtelijk te houden is ervoor gekozen om maar één bedrijfsregel op te nemen, namelijk bedrijfsregel 45 (BR_ID 45).

Op 31 december 2007 vervalt de wet inclusief alle op deze wet gebaseerde bedrijfsregels, dus ook bedrijfsregelnummer 45 (BR_ID 45). Dit is te zien in onderstaande administratie, weergegeven in Tabel 1-5.

Op 1 juli 2008 wordt er besloten dat artikel 8.12 vanaf januari 2009 weer van kracht gaat onder de naam kinderkorting plus. Deze bedrijfsregel wordt op 1 oktober 2008 ingevoerd in het systeem als nieuwe bedrijfsregel met het regelnummer 145, zie Tabel 1-6.

Op 2 juni 2009 wordt een parameterfout ontdekt in bedrijfsregel 145 (de lichtgroene rij) wat betekent dat deze aangepast moet worden. Deze wijziging wordt doorgevoerd op 10 juni 2009. Deze wijziging heeft in een temporeel administratiesysteem tot gevolg dat er twee extra rijen worden toegevoegd. Één rij om aan te geven dat instantie van bedrijfsregel 145 ongeldig wordt (zie de donkergroene rij) en één rij om de nieuwe instantie van bedrijfsregel 145 te registeren (zie de lichtoranje rij). Dit is weergegeven in Tabel 1-7.

Scenario 3: Doorwerkbonus

Harry vraagt op 22 maart 2012 zijn werkbonus aan over 2010. Op basis van bedrijfsregel met het BR_ID 145 wordt de werkbonus berekend. In Tabel 1-8 is te zien dat er meerdere instanties van bedrijfsregel 145 opgeslagen zijn in de administratie. Dankzij de valide_start datum en valide_eind datum kan bepaald worden welke instantie van bedrijfsregel 145 in het jaar 2010 geldig was. In het jaar 2010 was inhoud B van bedrijfsregel 145 geldig, met andere woorden deze instantie van de bedrijfsregel is gebruikt om Harry zijn werkbonus over 2010 te berekenen.

Naast de bovenstaande administratie voor de geldigheid van bedrijfsregels is er ook een administratie om de uitvoering van de bedrijfsregels te registreren. Een belangrijk veld bij het registreren van de aanvragen is de transactietijd. Transactietijd is gedefinieerd als: “een tijdstempel waarop een bedrijfsregel is uitgevoerd.” In het geval van Harry zijn aanvraag (van 22 maart), die op 25 maart 2012 is verwerkt, is de transactietijd gelijk aan 25 maart 2012. De transactietijd kan worden gebruikt om de bedrijfsregel, die is toegepast om Harry zijn aanvraag uit te voeren, terug te vinden. Zo kan er, wanneer Harry bezwaar maakt, worden gekeken welke bedrijfsregel voor die aanvraag is uitgevoerd.

Mede-Auteurs: Eline de Haan en Koen Smit

Copyright Notice

Delen van dit artikel zijn eerder gepubliceerd als onderdeel van het project “Business Rules Management bij uitvoeringsinstanties” onderdeel van het BRM-Living Lab van de Hogeschool Utrecht. Daardoor geldt voor deze publicatie de Creative Commons licentie Naamvermelding-GelijkDelen 4.0 (CC-SA-BY) licentie.