Process Mining (deel 2): werking van het algoritme

In dit deel gaan we in op de werking van het Process Mining (PM) algoritme wat als voornaamste doel heeft om het procesmodel te visualiseren.

In de literatuur zijn er heel veel algoritmen te vinden die trachten te doen wat we in deel één hebben gedefinieerd als het doel van PM; een proces visualiseren en analyseren op basis van event data.

We gaan uiteraard niet in op al deze algoritmen, maar we zullen ons uitsluitend focussen op de meest relevante en gemeenschappelijke componenten. We beginnen bij de vereisten en format van de dataset en zullen aan de hand van een voorbeeld uit de HR-praktijk (specifiek het proces van Werving & Selectie) de werking van het algoritme toelichten.

Dataset

Zoals gezegd bestaat de data uit registraties van ‘events’; gebeurtenissen die middels een logtrail in een proces zijn vastgelegd. Applicaties die in een workflow handelingen van diverse mensen en applicaties vastleggen in een proces zijn bij uitstek hiervoor geschikt. De bron hoeft niet per sé een logtrail te zijn, maar kan ook worden gereconstrueerd uit tabellen in een datawarehouse.

De kerningrediënten die i.i.g. aanwezig dienen te zijn binnen de dataset zijn:

  • Case ID 
  • Activiteit
  • Timestamp

Bij een Case ID kan je denken aan een uniek kenmerk wat in het proces het object volgt. Heb je bijv. te maken met het proces van Werving en Selectie, dan wil je mogelijk een sollicitant of de voortgang van een vacature volgen. Dan wil je per sollicitant een unieke Sollicitant_ID of per vacature een unieke Vacature_ID. Heb je met een facturatiemodule te maken, dan zou een Factuur_ID vereist zijn, etc.

Activiteit
Dit veld beschrijft alle handelingen die de Case ID doorloopt. In het geval van een sollicitant die door het proces van Werving en Selectie loopt, kun je bijv. te maken krijgen met de volgende activiteiten: Opsturen_sollicitatie, Ontvangst_sollicitatie, Uitnodiging, 1e Interview, 2e Interview, Aanstelling (of Afwijzing), etc. Dit voorbeeld beschrijft zeer gesimplificeerd enkele stappen.

Bij een factuurproces kan je te maken krijgen met: ontvangst factuur, boeking, autorisatie, goedkeuring c.q. afkeuring, betaling c.q. creditering, etc.

Hoe fijnmaziger de activiteiten zijn geregistreerd, des te gedetailleerder men na afloop kan analyseren.

Timestamp
Iedere activiteitstap die wordt geregistreerd dient een aanduiding van datum + tijd te krijgen. Hiermee kan het algoritme bepalen hoe het visuele model opgebouwd kan worden. Uiteraard kunnen we hiermee ook analyses uitvoeren over doorlooptijden.

 

Dataformat

De format van de dataset dient er als volgt uit te zien:

 

 

We zien hier dus twee sollicitanten diverse stappen in een proces doorlopen met bijbehorende datums. Dit is de ‘bare minimum’, dit moet aanwezig zijn wil je iets kunnen voeden aan het algoritme. In de praktijk gaan we uiteraard meerdere eigenschappen inlezen zodat we daarop kunnen analyseren in een latere fase. Denk hierbij aan het geslacht van de sollicitant of eigenschappen als leeftijd, de functie waarop wordt gesolliciteerd etc.

Algoritme

Hoe bouwt het algoritme op basis van bovenstaande dataset het model op?

Hieronder wordt dit gedemonstreerd aan de hand van een gesimplificeerd voorbeeld. We beginnen met de volgende dataset:

 

 

Voor het gemak gaan we ervan uit dat de activiteiten chronologisch zijn voorgekomen in de volgorde van het alfabet.

We gaan nu stap voor stap een procesmodel bouwen per sollicitant en deze integreren in een totaalmodel. Om te beginnen kunnen we per sollicitant een pad uit de ruwe data destilleren die er als volgt uitziet:

 

 

Als we het model bouwen o.b.v. het pad van de eerste sollicitant, ziet dit er als volgt uit:

 

 

Het is natuurlijk niet zo gek dat het verkregen model (in het rood) één op één overeenkomt met het pad van sollicitant één. Het wordt pas interessant als we hier meerdere paden aan toevoegen:

 

 

Wat valt op? Omdat gemiddeld gezien B en C tegelijk optreden (zie het verschil tussen pad 1 en 2 wat betreft activiteiten B en C), worden ze in het uiteindelijke model op gelijke hoogte weergegeven.

Verder zien we een dubbele pijl tussen B en C en een pijl vanuit beide activiteiten naar D. Dit strookt volledig met de paden A en B.

Als we hier het laatste pad aan toevoegen, dan krijgen we:

 

 

Het derde pad bevat een herhaling van activiteit D, zodoende zien we een loep ontstaan bij activiteit D. Herhalingen worden dus d.m.v. een loop visueel weergegeven.

Dilemma

We zouden door deze logica te volgen het model steeds verder kunnen uitbreiden o.b.v. nieuwe paden. Indien we te maken hebben met een complex proces of één met zeer veel unieke cases (honderden duizenden of miljoenen gevallen zijn eerder een regel dan uitzondering bij complexe processen), dan kan het model onleesbaar complex worden:

 

 

We stuiten op het volgende dilemma: Hoe kunnen we een balans treffen tussen de leesbaarheid vs de bruikbaarheid van het model?

Om een model leesbaar te houden, moet het simpel zijn. Dat betekent echter dat we informatie moeten verwijderen. Echter, een volledig platgeslagen model is onbruikbaar omdat het onvoldoende (nuttige) eigenschappen van de werkelijkheid ondervangt en visualiseert.

Een mogelijke oplossing zou kunnen zijn; bouw het model op basis van de meest voorkomende paden. Paden die het vaakst voorkomen vertegenwoordigen een zekere mate van relevantie. Tegelijkertijd leveren ze (doorgaans) het meest simpele model op. Immers, de minst voorkomende paden zijn doorgaans de afwijkingen die zich minder vaak voordoen. Bovendien zit het meest simpele model ook het dichtst tegen het oorspronkelijk ontworpen model (op papier) aan omdat men het procesmodel ontwerpt op de regel en niet op de afwijking.

Dit zal gedemonstreerd worden met het volgende schema aan doorlopen paden:

 

 

Kiezen we er echter voor om het model op basis van de twee meest voorkomende paden te bouwen, dan ontstaat het volgende model:

 

 

Het tweede model is simpeler waardoor het beter te interpreteren is. Tegelijkertijd behoudt het een hoge mate van relevantie omdat het ruim 80% (5/6e deel) van alle paden ondervangt.

In deel drie maken we kennis met enkele PM applicaties. We zullen zien dat applicaties tevens de mogelijkheid bieden om juist naar de uitzonderingen te kijken (bijv. toon mij de 10% minst voorkomende paden).

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Fill out this field
Fill out this field
Geef een geldig e-mailadres op.
Je moet de voorwaarden accepteren voordat je het bericht kunt verzenden.

Menu