Slides of presentation by Jaap Braaksma about Business process flows, business rules, queues & status reason.

1. Business
process
flows,
business
rules,
queues
en status
reason

2. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Voorstellen - Jaap Braaksma
- Sinds 1996 bezig met Microsoft producten
- Eerst 10 jaar bij de Caesar Groep in allerlei rollen
- Daarna gespecialiseerd in Microsoft CRM bij AtosOrigin
- Daarna 7 jaar gewerkt bij AkzoNobel als Global application manager CRM en als
Enterprise Architect
- Sinds twee en een half jaar bij ShareValue:
- Eerst een ruim een jaar bij Fugro gezeten (met Wouter van Rij)
- Momenteel ingehuurd door ICTU voor een project bij de Raad voor Rechtsbijstand,
weer samen met Wouter.
Agenda

3. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Voorstellen
Requirements
Architectuur
Demo
Uitdagingen
Vragen
Agenda

4. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Proces • Raad voor Rechtsbijstand is uitvoerder van de Wet op de
Schuldsanering Natuurlijke Personen (Wsnp)
• Die wet bepaald dat een persoon door de rechter een
bewindvoerder toegewezen kan krijgen voor een bepaalde
periode, waarna hij een zogenaamde ‘schone lei’ heeft
• De door de rechter benoemde bewindvoerder kan hiervoor
subsidie Aanvragen bij de Raad voor Rechtsbijstand
• Ik wil dieper ingaan op de registratie en de afhandeling van
zo’n subsidie aanvraag.
Fasering
Uitvoering
Statussen

5. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Proces
• De Raad wil zogenaamd ‘dienstgericht’ gaan werken
• Diensten worden uitgevoerd volgens standaard stappen:
1. Registreren van het verzoek
2. Bepalen of het verzoek geaccepteerd kan worden
3. Beoordelen van het verzoek
4. Aanmaken van het besluit
5. Het leveren van wat er besloten is
• Deze fasering geldt ook voor de afhandeling van
subsidieverzoeken.
Fasering
Uitvoering
Statussen
Registreren Accepteren Beoordelen Besluiten Leveren

6. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Proces • In veel gevallen kan de uitvoering van zo’n verzoek in een
moeite gedaan worden door een medewerker
• Er zijn minstens twee omstandigheden waarin dat niet kan:
1. Niet alle benodigde stukken zijn aangeleverd (OZP). De
aanvrager wordt per mail verzocht de ontbrekende stukken
aan te leveren. Tot zolang moet het verzoek worden
geparkeerd
2. Als de beoordeling uitwijst dat het toegekende bedrag
afwijkt van het aangevraagde bedrag, dient de beoordeling
geverifieerd te worden door een andere medewerker
• De Raad wil in de toekomst de mogelijkheid hebben om de
verschillende stappen ook door verschillende ‘experts’ uit te
laten voeren. Een afdeling registratie, een afdeling Beoordeling
etc…
Fasering
Uitvoering
Statussen

7. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Proces
• De volgende statussen zijn gedefinieerd die horen bij de fasering van het
‘dienstgericht’ werken.Fasering
Uitvoering
Statussen

8. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Er zijn veel meer verzoeken gedefinieerd die ook op dergelijke
wijze afgehandeld moeten worden.
Om herhaalbaar te kunnen zijn moet de architectuur:
• Transparant zijn wat betreft technische oplossing
• Robuust zijn, om verschillende smaken te kunnen
ondersteunen
• Intuitief zijn voor de gebruikers.
BPF
Status process
Queues
Business rules
Kaders

9. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Business process flow om de gebruiker
• Te ondersteunen in de uitvoering van het proces
(wat moet ik doen in deze fase?)
• In een oogopslag te tonen in welke fase het verzoek is
• De controle te geven over de fase veranderingen
Uitgangspunten zijn daarom:
• De gebruiker bepaalt de fase overgang, en dat doet hij
middels de BPF
• Status reason, queues, business rules: ze moeten dus allemaal
de BPF volgen
• Speciale acties die bij een fase horen, ontvangstbevestiging,
besluit, betalingensopdracht, woden door workflows gedaan
die door een fase ingang of uitgang wordt getriggerd.
BPF
Status process
Queues
Business rules
Kaders

10. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Vanuit de BPF wordt de status workflow aangeroepen
• Deze zet het verzoek in de juiste statusreason
• De gebruiker kan altijd de status reason aanpassen
• De fase kan betreden worden vanuit een hogere of lagere fase!!
BPF
Status process
Queues
Business rules
•Status is altijd
“Aanvraag ingediend”
Registreren
•Bij binnenkomst altijd
“Acceptatie gestart”
Accepteren •Vanaf Accepteren:
“Acceptatie afgerond”
•Vanaf Besluiten:
“Beoordeling gestart”
Beoordelen
•Vanaf Beoordelen
“Beoordeling afgerond”
•Vanaf Leveren niet mogelijk
Besluiten •Altijd “Besluit
afgerond”
Leveren
Kaders

11. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Het wijzigen van de statusreason triggert de workflow “Wachtrijen”
• Als het veld “wachtrij item” op het verzoek leeg is maakt het process een
workflow item aan voor het verzoek in de “subsidieverzoeken” wachtrij
• Als het gaat om een OZP status roept hij de action AddToQueue aan om
de wachtrij op het wachtrij item, bij te werken
• Als het gaat om een tweede beoordeling dan plaatst hij hem in de wachtrij
“Tweede beoordeling”
BPF
Status process
Queues
Business rules
Kaders

12. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Als een bepaalde fase voorbij is kunnen die gegevens niet meer aangepast
worden.
Het zou bv. raar zijn om tijdens de beoordeling de registratie aan te passen:
• In elke fase worden meer velden read-only gemaakt
• De trigger is de status reason
• Het gebeurt met (heel uitgebreide) business rules.
BPF
Status process
Queues
Business rules
Kaders

13. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
Gebruiker veranderd fase
Status workflow
Update status reason
Business rules voor forms
Velden vergrendelen
Queue management workflow
Zet de aanvraag in de queue

14. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?

15. Inleiding Requirements Architectuur Demo Uitdagingen Vragen?
• Als een fase voorbij is kunnen de gegevens van die fase niet meer
aangepast worden.
De eenvoudigste en eenvoudigst te onderhouden methode zou zijn om
een business rule per veld te maken. Dit is echter vanuit het oogpunt van
performance niet wenselijk, dus we hebben een business rule per fase
(meerdere status reason waardes), met daarin alle betrokken velden
• De fase kan binnengekomen worden vanuit een willekeurige andere fase.
Een hogere of lagere, maar evt zelfs via “Instellen fase”. Hier moet de
logica rekening mee houden.
• BPF in de deployment pipeline: het is mogelijk wijzigingen te doen die de
BPF inconsistent maken en dan blokkeert de pipeline.

16. Conditionele branches moeten gebaseerd zijn op een veld in de voorgaande
fase van de BPF.
• Dit is (voor de gebruiker) vaak niet logisch. In ons geval is een tweede
beoordeling nodig als twee bedragen verschillen of als het per post of
mail binnen is gekomen. Dat vul je niet in de beoordelingsfase in.
Oplossing is tonen en read only maken.
• Velden in de BPF kun je niet officieel read only maken, wel via jscript
Je kunt het verhogen van de fase blokkeren door een bit veld.
• Default staat een bit op false. Deze kun je in de Create leeg maken.
• Echter is altijd de waarde nee de blokkade. Dat is best lastig want
[IsCompleet] ja/nee kan natuurlijk heel goed, maar [IsGeblokkeerd] ja/nee
kan dus niet. Het moet dan zijn [AlleBlokkadesWeg] ja/nee.
Inleiding Requirements Architectuur Demo Uitdagingen Vragen?

17. Inleiding Requirements Architectuur Demo Uitdagingen Conclusie
Vanuit gebruikers perspectief
• Zijn enthousiast over de BPF
• Zijn zonder veel uitleg aan de slag gegaan
• Enige verzoek was het in en uitklappen van tabbladen
Vanuit technisch perspectief
• Groot aantal workflows
• Nauwelijks code!
• Robuuste werking
• The devil is in the details: toch nog best complex.