Processimulatie

Wat is processimulatie?

Bij processimulatie laat je een model van je proces draaien om te zien wat een wijziging zou doen, voor je aan het echte proces raakt. Je geeft het model mee hoe vaak er werk binnenkomt, hoelang elke stap duurt, wie er wanneer beschikbaar is en welke kant de cases uitgaan bij een keuze. Daarna stuur je er een paar duizend cases door en lees je de doorlooptijd, de wachtrijen en de belasting per persoon af.

De vraag heeft altijd dezelfde vorm. Wat als we een tweede goedkeurder toevoegen? Wat als we de controle op ontvangst laten vallen? Wat als het volume in het najaar twintig procent hoger ligt? Wat als de ploeg een uur vroeger start? Daarom heet hetzelfde ding vaak what-if-analyse.

Twee families van tools doen dat werk.

Discrete event simulation is de klassieke van de twee. Het model heeft cases die binnenkomen, activiteiten die tijd kosten, en resources met beperkte capaciteit. Komt een case bij een activiteit terwijl niemand vrij is, dan gaat hij in de wachtrij. De klok springt van gebeurtenis naar gebeurtenis, een aankomst, een start, een einde, in plaats van door lege minuten te tikken. Daardoor draait een jaar werk in enkele seconden. Tools in deze familie, waaronder het oudere Simul8, vragen je om te benoemen wat er door het proces stroomt, welke regels het volgt en om welke resources het moet concurreren, met de willekeur van het echte leven erin.

What-if op een ontdekt procesmodel is de nieuwere weg, en de reden dat simulatie geen specialistenwerk meer is. Een process mining tool haalt het model uit je event log, leest de meeste parameters uit diezelfde log, en laat je een scenario aanpassen en op start duwen. Apromore doet dat op BPMN-modellen: de uitvoer is een gesimuleerde log die je in een dashboard naast de echte legt. SAP Signavio Process Manager heeft hetzelfde idee in zijn modelleertool zitten, met tabbladen voor kosten, duurtijden, hoeveel cases er starten en welke resources er zijn.

Welke van de twee je ook neemt, het werk dat ze voor je doen is hetzelfde: twee ontwerpen vergelijken voor je er een bouwt, een team op maat maken, nakijken of de piek van volgend kwartaal past, en een cijfer plakken op wat één overdracht je kost.

Wat het model nodig heeft voor je het vertrouwt

Vijf soorten input, en bijna elk daarvan is een verdeling of een agenda, geen enkel getal.

• Het aankomstpatroon. Niet vijftig facturen per dag, maar hoe de gaten tussen twee aankomsten gespreid liggen, plus de vorm over de week en over de maand. In Apromore kies je voor de tijd tussen twee aankomsten uit fixed, normaal, exponentieel, uniform, driehoekig, log-normaal of gamma.

• Een duurtijd per activiteit, ook als verdeling. Gemiddeld twee uur met een lange staart gedraagt zich helemaal anders dan een vaste twee uur, en dat verschil komt terecht in de wachtrij erachter.

• Resources en hun agenda. Hoeveel mensen deze stap kunnen doen, wanneer ze effectief werken, en wat hun dag verder vult. De overlevingsgids voor business process simulation van Wil van der Aalst somt vijftien risico's op die een simulatiestudie onderuithalen, en noemt de naïeve modellering van resources als een van de redenen waarom modellen onbetrouwbaar uitvallen. Iemand die twee dagen per week aan dit proces werkt, komt in het model terecht alsof hij erop zit te wachten.

• Kansen per keuzepunt (gateway). Van de facturen die aan de driewegmatch toekomen (factuur, bestelbon en ontvangst), welk aandeel zakt en gaat opnieuw de ronde?

• Kost per activiteit en per uur, als je het antwoord ook in euro's wil en niet enkel in dagen.

Heb je een event log, dan verzin je niets van dit alles. De gaten tussen aankomsten, de duur van elke activiteit, het aandeel cases per aftakking, en wie wat wanneer deed: het zit allemaal in de timestamps. De parameters uit echte gebeurtenisdata halen in plaats van uit een workshop, is waar van der Aalst al jaren voor pleit. Het is ook de reden dat simulatie opdook als een knop in process mining producten, in plaats van in een aparte tool te blijven zitten.

Waarom een gemiddelde de wachttijd te laag inschat

De klassieke fout is het hele model uit gemiddeldes opbouwen. Vijftig facturen per dag, drie minuten per stuk, dus tweeënhalf uur werk op een dag van acht uur, dus geen wachtrij. Dat antwoord klopt niet, en het slaat altijd dezelfde kant uit: het zegt dat er minder gewacht wordt dan in werkelijkheid.

Wachtrijen ontstaan niet door een tekort aan capaciteit. Ze ontstaan door spreiding. Werk komt niet gelijkmatig binnen en geen enkele stap duurt twee keer even lang. Vallen er zes facturen binnen in dezelfde tien minuten, dan wachten er vijf, en het rustige uur dat volgt geeft die wachttijd niet terug. Een gemiddelde heeft geen geheugen voor dat samenklonteren.

Het vakgebied dat dit bestudeert is de wachtrijtheorie, en het resultaat dat hier telt is de benadering die John Kingman in 1961 publiceerde voor één wachtrij. In gewone woorden: de gemiddelde wachttijd stijgt met drie dingen. Hoe gespreid de aankomsten liggen, hoe gespreid de bewerkingstijden liggen, en hoe dicht de resource tegen voortdurend bezig zit. Dat laatste loopt niet recht. Van tachtig naar negentig procent bezet verdubbelt de wachttijd ongeveer, en van negentig naar vijfennegentig verdubbelt ze nog eens. Een simulatie krijgt dit vanzelf juist, want ze trekt elke aankomst en elke duurtijd uit een verdeling en laat de wachtrij zelf ontstaan.

Simulatie tegenover een berekening in een spreadsheet

Wat de twee scheidt: bestaan wachtrijen en spreiding überhaupt in het model?

Een spreadsheet deelt werk door capaciteit. Ze vertelt je of het totaal in de beschikbare uren past, en dat is een echte vraag, meestal zelfs de eerste die je moet stellen. Wat ze niet kan zeggen, is hoelang één case wacht, want in een spreadsheet bestaan er geen cases en geen wachtrij, alleen totalen per periode. Ze meldt vrolijk dat een manager met tweeënhalf uur factuurwerk per dag ruimte over heeft, terwijl die facturen vier dagen blijven liggen.

Een simulatie duwt de cases één voor één door het proces, langs mensen die bezet kunnen zijn. Je krijgt een spreiding van doorlooptijden in plaats van één getal, dus je kan vragen hoe de traagste case op twintig eruitziet. Net die case levert het telefoontje op. De prijs is opzetwerk en parameters die je moet meten. Onze vuistregel: een spreadsheet als de vraag is of het volume in het jaar past, een simulatie als de vraag is hoelang een case zal wachten.

Rekenvoorbeeld: factuurgoedkeuring in een bedrijf van zestig mensen

Ongeveer duizend leveranciersfacturen per maand, dus zowat vijftig per werkdag. De stappen: registratie, boeken door de boekhouding, een bevestiging van ontvangst die terug naar de besteller gaat, goedkeuring door de afdelingsmanager, en de wekelijkse betaalrun. Gemeten doorlooptijd van binnenkomst tot betaling: elf werkdagen. Effectief werk per factuur: minder dan een half uur.

De event log geeft de wachttijd per stap: één dag bij registratie, vijf dagen bij de overdracht voor de ontvangstbevestiging, vier dagen bij de goedkeuring, één dag tot de volgende betaalrun. Er liggen twee wijzigingen op tafel en de financieel manager wil weten welke eerst moet.

• Een tweede goedkeurder toevoegen. De afdelingsmanager krijgt een collega met dezelfde tekenbevoegdheid. De simulatie brengt de goedkeuringswachtrij van vier dagen naar één, en de doorlooptijd van elf dagen naar acht.

• De overdracht weghalen. De ontvangstbevestiging wordt vastgelegd op het moment van levering, in het scherm dat het magazijn toch al gebruikt, zodat de factuur niet meer buiten moet en terug. Die vijf dagen wachten vallen weg. Alleen laat de simulatie ook zien dat de goedkeuringswachtrij van vier naar vijf dagen groeit, want de facturen bereiken de manager nu sneller en dichter op elkaar. Netto doorlooptijd: zeven dagen.

De overdracht levert dus een dag meer op dan de extra goedkeurder, en ze kost niemand loon. Doe je allebei, dan land je op vijf dagen en niet op de vier die je krijgt door de twee besparingen op te tellen, want de tweede goedkeurder vangt het samenklonteren maar deels op dat je veroorzaakt door de overdracht weg te halen. Dat samenspel is waar een simulatie voor dient. Hoelang je ook naar de event log staart, dit haal je er niet uit.

Het model aftoetsen aan het verleden

Een simulatie die niemand nagekeken heeft, is een tekening met cijfers erop. De test kost weinig: voed het model met de parameters van vorig jaar, laat het draaien, en leg de doorlooptijd die eruit komt naast die je effectief had. Vergelijk de vorm en niet enkel het midden. Had het echte proces een mediaan van elf dagen met een staart van cases die over de dertig gaan, en geeft je model elf dagen met bijna niets voorbij vijftien, dan klopt het volume maar de spreiding niet, en dan valt elk antwoord over wachtrijen te optimistisch uit. De gewone oorzaak: een duurtijd ingevuld als een vast gemiddelde, of iemand gemodelleerd als de hele dag beschikbaar.

Zit je op ongeveer een dag juist, zowel op het midden als op de staart, dan is dat goed genoeg om twee ontwerpen tegen elkaar af te wegen. Het is niet goed genoeg om een klant een datum te beloven.

Waar moet je op letten bij processimulatie

Het is geen voorspelling. Een simulatie zegt wat er met dit proces gebeurt onder deze aannames, niet wat de markt volgend kwartaal doet. Zet je het aankomsttempo hoger, dan krijg je het gevolg van dat tempo te zien, en dat is iets anders dan het tempo voorspellen.

Het is geen bewijs voor een beslissing die al genomen is. De parameters komen uit echte data of ze komen uit een mening, en met één duurtijd en één kans wat bij te stellen haalt iedereen het gewenste antwoord eruit. Krijg je nog geen event log bij elkaar, meet dan eerst een maand lang drie timestamps met de hand voor je iets modelleert. Schrijf elke parameter op met de bron erbij voor je iets laat draaien, en laat een collega er één veranderen om te zien hoe ver het antwoord meebeweegt.

Kleine verschillen zijn toeval. Elke run trekt willekeurige getallen, dus twee runs van hetzelfde scenario lopen uiteen. Laat elk scenario vaak genoeg draaien tot het verschil tussen de scenario's groter is dan het verschil tussen de runs, en lees een halve dag niet meer als een resultaat.

Het langetermijngemiddelde is jouw dinsdag niet. De meeste resultaten beschrijven hoe het proces zich gedraagt nadat het model uitgetrild is. Gaat de vraag over de komende twee weken, start het model dan vanuit de achterstand van vandaag en niet vanuit leeg.

Simuleer de agent voor je hem koopt. Een AI-agent die je voor een stap overweegt, is ook gewoon een resource, met een eigen snelheid, een eigen beschikbaarheid en een eigen foutenpercentage, plus het herstelwerk dat die fouten opleveren. Zet die cijfers in het model en je ziet wat hij met de wachtrij doet. Dat is meestal een kleiner verschil dan de demo laat uitschijnen, want het wachten zat nooit in die stap.