Inleiding

Op twitter heb ik het regelmatig over de dynamiek in de uitvoering van processen en dat je dat niet goed ziet weergegeven in procesmodellen.

Een procesmodel kan handig zijn als werkinstructie of als ontwerp voor een uitvoeringssysteem. Maar, als je ze gebruikt in een procesverbeterproject (en daar wordt het toch best veel voor gebruikt, heb ik gehoord), denk ik dat ze vaak te ver van de werkelijkheid staan om echt te kunnen begrijpen waarom een proces niet presteert.

In dit verhaaltje ga ik proberen uit te leggen wat ik met bovenstaande bedoel. Mijn gedachten hierover werden getriggerd doordat ik de afgelopen maanden diverse gesprekken heb gehad met mensen die zich bezig houden met processen in ziekenhuizen. Daar merk je dat er veel behoefte is aan verbetering, maar op een gegeven moment kwam er een kronkel in m’n hoofd toen ik alle aspecten rondom ziekenhuisprocessen op een rijtje probeerde te krijgen.

Daar heb je namelijk te maken met:

• Het (van te voren soms onduidelijke) proces waar de klant (patiënt) doorheen ‘stroomt’;
• De beschikbaarheid van apparatuur, ruimtes en andere faciliteiten (de logistiek);
• De beschikbaarheid van specialisten;
• De planning die alles qua tijd aan elkaar moet rijgen.

Dit zijn de soort aspecten die ik bedoel als ik het heb over ‘de dynamiek van de uitvoering’.  Hoe je dat precies in procesmodellen moet krijgen, weet ik ook niet. Maar ik ga toch een poging wagen. Het is overigens niet mijn doel om te komen met een nieuw ‘manifest voor procesmodellen’ of  iets dergelijks.

Het is mijn doel  om duidelijk te maken wat ik bedoel met ‘dynamiek van de uitvoering’ en waarom de meeste procesmodellen die ik tegenkom dat niet erg duidelijk weergeven.

Om het enigszins luchtig te houden, zal ik in de voorbeeldjes geen ziekenhuis, maar een pizzeria gebruiken.

Hoe procesmodellen er vaak uit zien

De meeste procesmodellen die organisaties maken, zien er ongeveer als volgt uit.

(Ik weet het; geen formeel BPMN. Klachten naar info@procesje.nl)

Dit is een zeer begrijpelijk procesmodel (hoewel het eigenlijk alleen de werkstroom van een proces is) en kan dus heel goed dienen om aan een medewerker of een klant uit te leggen wat er gebeurt wanneer er een bestelling binnenkomt.

Ook zou dit de basis kunnen zijn voor een toekomstig proces omdat je dit de beste manier vindt om bestellingen af te handelen.

Naar mijn mening zijn procesmodellen zoals bovenstaand enkel geschikt voor:

• Instructie/Uitleg (dit moet je doen als er een bestelling binnenkomt)
• Inrichten van systemen/organisatie met processen “zoals ze zouden moeten lopen” (om het technisch te implementeren is vanzelfsprekend nog wel wat extra nodig).
• Het blij maken van auditors

Maar, wanneer dit een model van het huidige proces zou zijn, heb je er niets aan om te bepalen of dit proces goed presteert. Het vertelt je niet waarom bestellingen te laat komen of pizza’s telkens aanbranden. En al helemaal niet waarom de pizzeria zulke slechte recensies krijgt op Iens.

Om dat te bereiken, moet je het procesmodel opdikken met meer informatie.  Pas dan kun je zinnige uitspraken doen over de prestaties van het proces. En op basis daarvan mogelijke verbeteringen doorvoeren.

Uitbreiding met ‘wie doet het werk?’

Om aan te geven wie het werk doet in een proces, zie je vaak dat er swimlanes worden getekend. In dat geval wordt de werkstroom ‘gematrixt’ met de functies/rollen die de stappen uitvoeren.  Voor het bovenstaande proces ziet dat er mogelijk als volgt uit:

Wat heb je hier aan als het gaat om verbeteren van dit proces? Niet zo heel veel. Je ziet wie verantwoordelijk is voor de uitvoering van een stap, maar wat je bijvoorbeeld niet ziet is:

• Hoeveel koks zijn er op welk moment beschikbaar?
• Hoe lang zijn de uitvoerenden bezig met deze stappen?
• Zorgen overdrachten voor bottlenecks?

Wil je iets over de prestaties van dit proces zeggen, dan moet dat ook zichtbaar zijn in het model.  Dat ga ik straks proberen, maar een ander belangrijk aspect voor het zien of een proces goed verloopt , is het aantal gevallen dat het proces moet afhandelen.  1 pizza bestelling per week is heel wat anders dan 100 per dag, dus dat dynamische aspect moet duidelijk worden.

Process mining/Simulatietechnieken

Met behulp van processmining/simulatie hulpmiddelen kun je duidelijk maken hoeveel en hoe gevallen door het proces stromen.  De “bolletjes” (als weergave van onderhanden bestellingen) maken dit namelijk duidelijk.

Dit soort technieken geven al een indicatie van bottlenecks in een proces.  Maar bottlenecks zijn slechts symptomen, dus moet je veel dieper in het proces duiken om te achterhalen wat deze bottlenecks veroorzaakt.

In bovenstaand plaatje zie je dat er 3 bestellingen genoteerd worden, maar slechts 1 belegd, waardoor een wachtrij ontstaat. Hoe kan dat? Wanneer we naar de ziekenhuiswereld kijken, heeft dat vaak te maken met beperkte resources.

Een chirurg kan maar 1 operatie tegelijk doen. En wanneer zij aan het opereren is, kan ze geen consulten doen. Dus de doorstroom van patiënten wordt dan beperkt door het aantal medewerkers. Dat zie je niet terug in de meeste procesmodellen. Dus op één of andere manier, zou je de modellen moeten kunnen ‘opdikken’ met resource beschikbaarheid.

Resource-beschikbaarheid in een procesmodel

Wanneer je denkt aan het toevoegen van de beschikbaarheid van resources aan een procesmodel maak je eigenlijk een soort matrix van zwembaan x aantal resources  x stap.

Stel dat er 3 serveersters, 1 kok en 2 bezorgers zijn in het bezorgen pizza proces. Dan wordt het model (het is maar een zelfgeknutselde weergave, hoor) als volgt:

 

Combinatie met bolletjes

Wanneer je het bovenstaande model dan weer combineert met bolletjes (bestellingen), wordt een beetje duidelijker waarom sommige bestellingen niet doorstromen:

 

Zo zie je bijvoorbeeld dat er geen nieuwe bestellingen worden aangenomen omdat de 3 beschikbare serveersters allemaal bezig zijn met een bestelling.

Daarnaast zie je nog iets wat slecht is af te beelden in een model ; er is maar 1 kok, die 3 opéénvolgende stappen voor een bestelling moet uitvoeren. Als hij een pizza aan het verpakken is, kan hij ondertussen niets anders doen.  Hoe zou je deze afhankelijkheid kunnen afbeelden?

Misschien met kleurtjes?

Op deze manier kun je misschien duidelijk maken dat ze onderverdeeld zijn in drieën.

Een andere manier zou kunnen zijn door te zeggen dat het kokswerk een soort van blok is waar zich slechts 1 bestelling tegelijkertijd in kan bevinden:

Het is een lastig aspect van een proces om af te beelden. Maar wel een hele belangrijke om te bepalen waarom een proces niet presteert.  Het is in principe een soort van aan/uit switch tussen activiteiten; als de ene wordt uitgevoerd, ligt de ander stil.

Mensen niet de enige schaarse resource

Een grote uitdaging in een ziekenhuis is niet enkel de inzet van schaarse specialisten, maar ook de beperkte beschikbaarheid van apparatuur/operatiekamers etc.  Je kunt misschien 10 chirurgen hebben, maar als je maar 1 operatiekamer hebt, is dat de beperkende factor.

In administratieve processen kun je dan misschien denken aan systemen (of misschien beter licenties) waarvan er slechts een paar zijn.  Ook dat zou eigenlijk uit het model duidelijk moeten worden. Voor de pizzeria is dat misschien de situatie dat er maar 1 brommer is om te bezorgen. In onderstaand model is deze beperking opgenomen.

 

Om dit te begrijpen heb je eigenlijk wel weer de dynamische bolletjes nodig. Zo zie je dat een bestelling (daarom 2 halfjes) een bezorger en een brommer nodig heeft. Nu zie je dus ook dat er eigenlijk een bezorger te veel is. Of een brommer te weinig.  Kans voor bezuiniging of meer throughput.

Dit lijkt overigens wel een beetje op petrinetten zoals sommigen van jullie wellicht kennen.

En wanneer er in de pizzeria een oven heeft, waarin 3 pizza’s tegelijkertijd gebakken kunnen worden, ziet dat deel van het proces er als volgt uit:

 

Ook hier zie je weer het probleem van 1 kok. Hij kan niet tegelijkertijd een pizza in de oven stoppen en er eentje uithalen (hoewel, ik heb koks gezien…).  Daarom ontstaat het gevaar dat er allemaal pizza’s liggen aan te branden omdat de kok geen tijd heeft om pizza’s uit de oven te halen.

En daarmee kom je op een ander aspect van processen; planning en tijd

Planning en tijd

In het plaatje hierboven wordt dus het belangrijke aspect van tijd duidelijk; wanneer een pizza te lang in de oven ligt, brandt hij aan. Dit heeft dus ook weer met planning te maken.  Dat zit meer in de daadwerkelijke uitvoering van een proces, maar is wel heel belangrijk om een proces goed uit te voeren.

Daarbij zul je bijvoorbeeld ook rekening moeten houden met de beschikbaarheid van medewerkers. Op zaterdag heeft de pizzeria misschien 3 bezorgers en door de week maar 1. Dus het proces (en zijn prestaties) verschilt ook nog weer per dag.  Dit dynamische aspect zul je echt niet ontdekken d.m.v. een traditioneel procesmodel.

In het ziekenhuis heb je daar ook mee te maken. Stel dat er 2 chirurgen zijn, maar slechts 1 operatiekamer. Terwijl de ene chirurg aan het opereren is, kan de ander consulten doen. Hoe maak je dit soort planningsachtige aspecten, die belangrijk zijn voor de patiënt nu duidelijk? Even proberen…

 

Conclusie tot nu toe

Procesmodellen zoals we ze vaak zien hebben hun toepassingen, maar helpen niet altijd om inzicht te krijgen in de oorzaken van slechte procesprestaties.

Daarvoor moet je o.a. ook weten:

• Aantal gevallen (de bolletjes)
• Resources
• Afhankelijkheid resources
• Planningachtige zaken (beschikbaarheid)

Heel veel aspecten dus, maar noodzakelijk naar mijn mening. Als je dit allemaal wilt afbeelden in een model heb je een aantal dimensies (als tijd, casussen en resources) nodig.

In dit blog heb ik geprobeerd dit duidelijk te maken en in modelletjes weer te geven. En dat valt niet  altijd mee, zoals u heeft kunnen zien.

Dus is het wel de moeite waard om proberen processen te verbeteren aan de hand van procesmodellen zoals ze vaak worden gemaakt?

Of is het wellicht beter om vanuit de uitvoering het proces steeds een klein beetje beter te maken.  Want de dynamiek van de uitvoering komt toch het meeste naar voren in……….. de uitvoering.

Elk voordeel zal z’n nadeel wel hebben, dus hoe denkt u over dit soort zaken?