Procesconcepten in NORA

De NORA (Nederlandse Overheids Referentie Architectuur) definieert een aantal concepten over processen. In dit artikel wil ik ingaan op de definities van:

• Ketenproces
• Bedrijfsproces
• Werkproces (Deelproces)

NORA definieert de concepten correct, maar summier, en ik kom in de praktijk tegen dat hierdoor veel voorkomende fouten gemaakt worden. In dit artikel kom je te weten hoe je ketenprocessen, bedrijfsprocessen en werkprocessen moet modelleren conform NORA, in ArchiMate en BPMN.

Definities

Allereerst is het belangrijk om je te realiseren dat de termen zijn gedefinieerd in NORA 2.0, maar (deels) zijn losgelaten in de latere versie 3 (2014). Daar is een belangrijke reden voor, namelijk dat de definities te rigide waren. Hierover volgt straks uitleg. Binnen allerlei overheidsorganisaties zijn de definities echter omarmd en gebruikt in de procesarchitecturen (zoals in de GEMMA), en is het van belang dat we helder definieren wat we hiermee bedoelen en hoe we hiermee om moeten gaan. In mijn werk bij UWV, Belastingdienst en Defensie kom ik dezelfde worsteling tegen.

We zullen bovenstaand generiek procesmodel gebruiken als kapstok voor de uitleg:

Concept (NORA 2.0)	Definitie
Ketenproces	Een bedrijfsproces onder controle/verantwoordelijkheid van de eigen organisatie, waarin tenminste één activiteit wordt uitgevoerd door een ketenpartner, onder regie van de eigen organisatie
Bedrijfsproces	Een end-to-end (klant tot klant) proces dat een specifieke dienst levert aan een stakeholder.
Werkproces of Deelproces	Een activiteit als onderdeel van een bedrijfsproces dat uitgevoerd wordt door één onderdeel of afdeling van de organisatie
Processtap	Een activiteit als onderdeel van een bedrijfsproces dat uitgevoerd wordt door één rol
Handeling	Een activiteit als onderdeel van een bedrijfsproces dat uitgevoerd wordt door één persoon of systeem

Ketenproces analyse

Diagram 1 laat een generiek voorbeeld zien van een top-level bedrijfsproces. Het feit dat het een ketenproces betreft is in dit diagram direct te zien, omdat één stap in het proces (Werkproces 3b) geheel uitbesteed is aan een ketenpartner (Ketenpartner, de black-box pool waarmee een response/request message flow interactie is te zien).

Dit hoeft niet altijd een activiteit in een top-level diagram te zijn: wanneer een processtap of handeling is uitbesteed is er nog steeds sprake van een ketenproces: een deel van het proces, op welk procesniveau dan ook, wordt onder regie van de eigen organisatie uitbesteed aan een ketenpartner.

Wat is nu het verschil met een “gewone” partner, bijvoorbeeld een betalingsprocesstap die uitbesteed wordt aan een payment provider?

De payment provider zal ook gemodelleerd worden met een black-box pool, maar is geen ketenpartner. In BPMN termen is de payment provider een “gewone” collaboration. Er zullen ook message flow interacties zijn tussen de black-box pool van collaborator en de eigen white-box pool. Alleen heeft de eigen organisatie op geen enkele wijze een afhankelijkheid met de interne opbouw en ontwerp van het proces van de black box pool. De payment provider stelt een service interface ter beschikking van alle gebruikers (waar wij er één van zijn) en wij moeten ons conformeren aan die interface om van de diensten van de payment provider gebruik te kunnen en mogen maken. De message flow interacties vinden plaats vanuit onze “eigen” activiteiten met message send/receive elementen (tasks of events).

Bij een ketenpartner ziet het er iets anders uit. We modelleren wel een “lokale” placeholder voor de uitbestede activiteit. Omdat wij de regie hebben (wij zijn de proceseigenaar), zijn wij in staat aan die lokale placeholder allerlei eisen te stellen. We kunnen bijvoorbeeld uitspraken doen over hoe de activiteit wordt getriggerd (inkomende sequence flow) en hetzelfde voor de uitgaande sequence flow(s). We kunnen als wij dat willen de interne structuur van het (extern uitgevoerde) proces beschrijven. Wij gedragen ons als eigenaar van de uitbestede activiteit, en de afhankelijkheid is dus veel groter dan bij een “gewone” collaboration. De activiteit Werkproces 3b is dus eigenlijk “onze” activiteit. Omdat er iets bijzonders mee is maak ik gebruik van een grijstint van het blokje maar dit heeft geen betekenis en is een persoonlijke voorkeur (je ziet ook een blauwe black-box pool, hierover meer hieronder).

Samenvattend: om recht te doen aan de strakkere afhankelijkheid van een stap die onder onze eigen regie wordt uitgevoerd door een externe organisatie, stel ik voor gebruik te maken van een lokale placeholder met message flow connecties naar de externe organisatie.

Ik wil het diagram nog wat meer exploreren.

Alleen werkprocessen op top-niveau?

We zien dat alle activiteiten op één na subprocessen zijn (het plusje in de activiteit). Hieronder zal ik de inhoud van die subprocessen laten zien. Er is echter (als voorbeeld) één activiteit opgenomen die geen subproces is maar een gewone (Abstract) Task: Processtap 4. Dit kan een simpele handeling zijn van bijvoorbeeld maar 1 stap. Het komt voor in dit procesniveau, en omdat een handeling in de bovenstaand definities is gekoppeld aan een rol binnen een afdeling/team is die informatie hier ook getoond: de rol Rol 02 binnen Afdeling 2.

Je kunt er ook voor kiezen op het top-niveau alleen werkprocessen te willen laten zien. Dan staat je niet veel anders te doen dan Processtap 4 een subactiviteit te maken van een Werkproces 4 dat je op het top-niveau toont. Beide zijn mogelijk.

Laten we door het proces lopen.

Walk-through

Het proces wordt getriggerd door een Externe trigger (black-box pool, bijvoorbeeld een Klant). Dit is in het merendeel van de bedrijfsprocessen zo. Het inkomende verzoek wordt aangeduid met Bedrijfsobject 1, de message payload van de triggerende message flow. Een voorbeeld van een dergelijk object zou een Order kunnen zijn. We zeggen dan dat het bedrijfsproces in zijn geheel de “Order” representeerd. Bedrijfsprocessen hebben meestal een bedrijfsobject dat het proces representeert.

Vervolgens wordt door Afdeling 1 een proces uitgevoerd die wordt aangeduid met Werkproces 1. We zien dat dit een subproces is, en we zien dat er een uitgaande en inkomende message flow is (resp. request/response) met een externe black-box pool. Deze pool is hier blauw getint, wat een persoonlijke conventie is (geinspireerd door ArchiMate, waarin applicatie objecten blauw zijn). Ik adviseer applicatie koppelingen te modelleren met black-box koppelingen. Waarom?

• Applicaties zijn encapsulated (als het goed is – service componenten die tegenwoordig in plaats van applicaties ontwikkeld worden zijn dat per definitie), dus onafhankelijk van de buitenwereld.
• Applicaties worden gebruikt in een proces via een of andere API. Dit is perfect te mappen op het concept message flow, zeker wanneer er een asynchrone communicatie plaatsvindt (over (a-) synchroon later meer).
• De gebruiker van een applicatie heeft geen enkele dependency met de interne structuur van de applicatie.

We duiken straks dieper in wat er gebeurd binnen Werkproces 1. Ik ben er dus geen voorstander van om de applicatie als een Lane in het proces op te nemen, maar adviseer dit te modelleren als een externe black-box pool.

We zien dat op Werkproces 1 een XOR Gateway volgt. Daaruit kunnen wij afleiden dat het subproces Werkproces 1 twee end states heeft waarvan er één het label Fout heeft (labeling conventie van Gateways). Hieronder gaan we dit procesniveau expliciet beschrijven, voor nu lopen we nog even door het proces op dit top-niveau.

Als er een Fout end state is in Werkproces 1, moet nog een kleine handeling verricht wordt door Rol 02 in Processtap 4, waarna het proces eindigt in de state End state fout. Daarmee eindigt het proces (er zijn geen tokens meer in het proces).

Als er geen fout end state is, wordt Werkproces 2 uitgevoerd, waarvan we de binnenkant hieronder nader beschrijven. Na deze stap, komen we bij een splitsing (Parallelle Gateway) die ervoor zorgt dat Werkproces 3a en 3b parallel worden uitgevoerd. Werkproces 3b is de lokale placeholder voor werk dat in werkelijkheid uitgevoerd wordt door Ketenpartner. We gaan hieronder inzoomen op de stappen in dit subproces.

Nadat Werkproces 3b is afgerond volgt er een gateway: we zien hier al dat Werkproces 3b twee end states heeft waarvan er één het label Afgerond heeft. Wordt dit bevestigd (happy flow, de yes-gate wordt getriggerd) dan word gewacht in de merging parallelle gateway totdat Werkproces 3a klaar is. Zodra dat het geval is worden beide tokens gemerged en gaat het proces verder naar End state correct en het proces eindigt. Wanneer Werkproces 3a eerder klaar is dan Werkproces 3b wacht de merging gateway totdat Werkproces 3b klaar is, merged de tokens en gaat dan eveneens naar End state correct.

Wanneer Werkproces 3b echter niet in de end state Afgerond eindigt, wordt een foutmelding gestuurd naar de Externe trigger, en komt het proces in een Terminate end state fout. Dit moet een Terminate zijn (en niet bijvoorbeeld een Message Send End State) omdat er parallelliteit in het proces zit: Werkproces 3a zou nog niet klaar kunnen zijn. De Terminate End Event zorgt ervoor dat Werkproces 3a, mocht die nog bezig zijn, wordt afgebroken, en het gehele proces eindigt in End state fout.

Tot zover het top-level proces. Laten we nu inzoomen op de subprocessen.

Werkproces 1

In dit subproces zien we twee sublanes binnen de lane Afdeling 1, die van Uitvoerder (die Processtap 1.1 uitvoert) en die van Goedkeurder die Processtap 1.2 uitvoert. Ik ga verder niet in op dit subproces, en zoom meteen in op Processtap 1.2.

In dit procesniveau zien we één voorbeeld van de twee manieren waarop applicatiekoppelingen gemodelleerd kunnen worden in procesmodellen, namelijk door een Service Task te gebruiken. Handeling 3 is de stap die uitgevoerd wordt door Applicatie 1. We zien de message flow interacties vanuit die service task. Merk op dat het gebruik van een Service Task impliceert dat de interactie synchroon plaatsvindt, en dat de message flows suggereren dat die asynchroon plaatsvindt. We zien de laatste tijd dat er een conventie ontstaat om asynchrone service interacties toch te modelleren met een service task en message flows, wanneer de request/response cyclus zeer kort (nano/millisecondes) is. Voor een voorbeeld van asynchrone interacties zie hieronder bij Werkproces 3b.

Ten overvloede: in dit subproces staan (nog) niet sublanes die de subrollen/personen binnen de rol Goedkeurder beschrijven (bijvoorbeeld om aan te geven dat Handeling 1 gedaan wordt door Junior Goedkeurder).

Merk ook op dat alle message flow interacties vanaf het laagste niveau (in dit geval Handeling 3) omhoog propageren tot op het top-niveau.

Werkproces 3b

In dit subproces is weliswaar geen sprake van een applicatiekoppeling maar met een externe ketenpartner, maar merk op dat het koppelingspatroon hetzelfde is.

We zien dat wij in dit proces niets doen, alles wordt via asynchrone message flows gedelegeerd naar Ketenpartner. We zien ook een time-out op het proces staan, een standaard onderdeel van elke externe delegatie.

We zien ook een ander pattern: de send is een task, en de receive is een event. Hierdoor kunnen wij bijvoorbeeld een loop zetten op de send, of een boundary.