Categoriearchief: Process Mining

Zijn procesmodellen wel zo handig voor procesverbeteren?

Geplaatst op door
1

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?

Maar weer eens een blogje over procesmodellen

Geplaatst op door
Antwoorden

031

Eens in de zoveel tijd beland ik in een discussie over de zin en onzin van modellen. Hoewel er in bedrijvenland verschillende soorten modellen worden gemaakt, gaat het in mijn geval dan met name om procesmodellen.

Wij en Zij

Aan de ene kant heb je de voorstanders van modelleren. En dan het liefst volgens een bepaalde standaard. En aan de andere kant heb je het meer praktische volk dat van mening is dat je modellen alleen moet gebruiken als ze waarde toevoegen.

Vroeger was ik best wel van de eerste, maar nu veel meer van de laatste stroming. Ik heb namelijk heel wat processen gemodelleerd, maar vroeg me daarna toch regelmatig af wat er uiteindelijk mee bereikt was. “Omdat de klant het wil” is een argument waar ik niet klakkeloos meer ja op zeg 😉

Bij deze nog mijn oprechte excuses aan iedereen die ik er mee lastig heb gevallen.

Doel en Middel

Maar even serieus. Doel en middel is waar het hier om gaat. Een procesmodel is een middel, maar wat is het doel?  Zo door de jaren heen, zijn er daar heel wat van verzonnen.

In essentie gebruik je een procesmodel om het werkelijke proces te kunnen begrijpen en om er over te kunnen communiceren.

Nou zijn echte processen nogal complexe dingen met verschillende belanghebbenden en diverse aspecten (als werkstroom, informatie, mensen, besturing, hulpmiddelen) die het proces maken tot wat het is.

Een eerste vraag die ik zou stellen is; “Wie of Wat wil het proces begrijpen?” en vervolgens “Waarom wil die wie of wat het proces begrijpen”?

Misschien denkt u wat een rare vraag “Wat wil het proces begrijpen?”

De uitvoering

Daarmee kom ik gelijk op het belangrijkste van een proces; de uitvoering.  Om te doen wat u aan klanten belooft, moeten processen uitgevoerd worden. Daarvoor zijn meerdere zaken benodigd, maar veelal gebeurt dat ook met ondersteuning van ICT.

Dat kan specialistische software voor een specifieke taak zijn, maar ook steeds meer zie je een procesgerichte ondersteuning met behulp van een procesmanagement- of zaaksysteem.

Dat soort software is niet geschikt voor alle type processen, maar meestal wel voor processsen waar de werkstroom (wat moet er allemaal gebeuren voor een zaak?) redelijk te bepalen is. En dus te modelleren.

Dan kan er een model gemaakt worden van het proces, wat dan weer als ontwerp dient voor het systeem. Model wordt werkelijkheid. Lijkt me een goed doel van een procesmodel, niet?

In bovenstaande geval moet een procesmodel dus aan de software vertellen hoe het proces uitgevoerd dient te worden. Besef wel dat het dan niet alleen gaat om de werkstroom, maar ook aspecten als data, formulieren, gebruikers en business rules.

En wanneer het proces geschikt is, kunnen dergelijke systemen van grote waarde zijn voor de prestaties van een proces. Over die prestaties gesproken…

Process Mining

Wanneer procesuitvoering wordt ondersteund met software waar een “proces-smaak” aan zit, zoals bijvoorbeeld een procesmanagement- of zaaksysteem, kan de techniek van process mining gebruikt worden om te kijken hoe lekker dat proces gepresteerd heeft.

Process mining gebruikt de gelogde gegevens (wie heeft wat wanneer voor welke zaak gedaan?) om het uitgevoerde proces “te ontdekken”.

Automatisch processen in kaart brengen, zeg maar. Dus niet met een clubje in een hok kruipen om  processen op de muur plakken, maar technologie het proces laten “tekenen”.

Het mooie is dat (als de logbestanden die informatie hebben)  ook inzicht kan worden verkregen in de prestatie informatie van het proces. Dit kan vervolgens weer vergeleken worden met de gestelde doelen en indien niet blij, kan dat een aanleiding tot procesverbetering.

Let wel op dat process mining je enkel de symptomen van slechte procesprestaties laat zien. maar toch geeft het mogelijk een indicatie van waar gezocht moet worden naar oplossing.

Processen verbeteren

Processen verbeteren blijft organisaties bezig houden. Persoonlijk zie ik ook dat weer als een middel, want klanten willen graag betere procesresultaten. Of u daarvoor uw processen moet verbeteren, zal ze niet veel interesseren.

Maar, ok; om processen te verbeteren zie je binnen veel organisaties de behoefte om het bestaande proces te begrijpen. En da’s niet gek, want wellicht ligt in dat proces de oorzaak van de ongewenste procesprestaties.

En dat is het procesje waar dit blog mee begon; het PROCES begrijpen.  Volgers op twitter weten dat ik me altijd een beetje kan irriteren wannneer mensen “proces” zeggen, maar “procesmodel” bedoelen.

Een procesmodel is het middel om het proces te begrijpen. Of liever; om te begrijpen waarom het proces niet presteert zoals verwacht.

Maar een procesmodel is niet een plaatje van alleen maar blokjes en pijltjes.

Geen blokjes en pijltjes

Als je wilt begrijpen waarom een proces niet presteert, zul je je moeten beseffen dat een proces een samenwerkingsverband is tussen diverse aspecten als:

  • Het werk dat moet gebeuren (de werkstroom)
  • De mensen die dat werk uitvoeren
  • Hulpmiddelen die benodigd zijn
  • Informatievoorziening op uitvoerings- en besturingsniveas
  • De manier waarop het proces bestuurd wordt (bijv. taakgericht of doelgericht)
  • De manier waarop gecommuniceerd wordt met de klant

Laat staan de externe factoren (als wetgeving, eisen vanuit certificerende instanties) waar een proces mee te maken krijgt.

En wanneer je dan enkel een zwembaanplaatje maakt in een procesmodel (wie doet wat?) mis je, mijns inziens, toch enkele van bovengenoemde aspecten.

Processen begrijpen om te analyseren en de oorzaak van slechte prestaties te vinden  is dus nog niet zo eenvoudig. En zeker niet om dat in een model vast te leggen en dan ook nog te kunnen achterhalen welk aspect van het proces de oorzaak is.

Daarnaast is het lastig om in een procesmodel de dynamiek van de uitvoering helder te maken. Terwijl deze wel erg de prestaties van een proces bepalen.  Hierover heb ik eerder een stukje getypt op LinkedIn.

Maar ok, stel dat het u lukt om te ontdekken welke verandering nodig is om het proces beter te maken, dan kunt u die betere werkwijze vanzelfspekend heel mooi vastleggen in een To-Be procesmodel.

To-Be procesmodel 

Maar een To-Be procesmodel is nog steeds een model en nog geen nieuwe werkelijkheid. In veel procesverbeterboeken is het hoofdstuk over implementeren vaak angstvallig dun; want ga er maar aan staan; daar komt een mooi portie verandermanagement bij kijken.

Dat komt met name door, zoals eerder aangegeven, het feit dat een proces een samenwerkingsverband is tussen vele aspecten.

Wat ik me dus afvraag is of op deze “big bang” manier werken aan het verbeteren aan processen wel oplevert wat er van verwacht wordt. Ik zie toch nog regelmatig organisaties waar gedesillusioneerd naar een To-Be model wordt gestaard.

Vergelijk het met het bouwen van een huis

Ik vergelijk het even met het bouwen van een huis. Daarvoor wordt ook een model gemaakt (diverse bouwtekeningen) en dan wordt het huis gebouwd volgens dat model.

Een voordeel van een bouwtekening is dat het een kleine versie van de werkelijkheid is; op basis van het model kun je je een goede voorstelling maken van de werkelijkheid.

Bij een procesmodel is dat lastiger, want dat is niets anders dan een set van afspraken hoe bepaalde procesaspecten worden getekend. Het geeft toch wat minder gevoel voor het echte proces.

Immers; een vierkantje kan “het registreren van een order”, maar ook “het lassen van een frame” zijn.

Nieuw of bestaand?

Een ander verschil tussen een te verbeteren proces en een te bouwen huis is dat het huis nog niet bestond toen het ‘model’ werd gemaakt. Je moet vanaf nul beginnen.

Met een bestaand proces is dat natuurlijk niet zo. Dat wordt al uitgevoerd en bestuurd.

En om dat dan in één knal te veranderen is niet zo makkeliijk . Wellicht daarom dat populaire verbetermethodes als Lean de meer geleidelijke aanpak toepassen van het “continu verbeteren”

Steeds een beetje beter.

Dus niet “Tijdens de verbouwing is de winkel geopend” maar “Tijdens het winkelen verbouwen we”

Maar heb je dan nog steeds procesmodellen nodig?

Continu verbeteren en procesmodellen

Persoonlijk denk ik dat, om continu te kunnen verbeteren, je moet beginnen met het verkrijgen van een continu inzicht in de prestaties van een proces. Of te wel; good old visueel management.

Iedereen moet duidelijk voor ogen hebben wat er in je proces speelt.

Zowel op dagelijks zaakafhandelingsniveau als op procesprestatieniveau. Over deze verschillende niveaus heb ik ook een stukje getypt op LinkedIn.

En op zich is dat “Inzicht in prestaties” ook een model. Het toont modelmatig (bijvoorbeeld in een dashboard) hoe het er voor staat met de werkelijke prestaties.

Een procesmodel zoals we dat veelal zien, mist dat toch een beetje. Live process mining zou mijns inziens het ultieme hulpmiddel hiervoor zijn.

Kortom; wil je continu verbeteren, dan moet je ook continu weten “hoe het ervoor staat”.

Maar nog veel belangrijker; dit “Meten is Weten” moet ook vertaald kunnen worden naar wijzigingen van het proces.

Die wijzigingen zouden dan weer naar een procesmodel vertaald kunnen worden, maar dat klinkt toch een beetje als verkeerd om.

Wellicht dat een nieuwe werkwijze gecommuniceerd kan worden, met behulp van een procesmodel. Of zelfs kan worden ingezet als werkinstructie.

Procesmodel als werkinstructie

Ik ben het regelmatig tegengekomen; organisaties die procesmodellen als werkinstructie inzetten. Op zich geen probleem, maar “organisaties hebben processen en mensen hebben werk”

Een proces is dus meer dan een werkinstructie. Daarnaast vraag ik me af of procesmodellen echt geschikt zijn als werkinstructie.

Soms is gewoon een stukje tekst of een filmpje veel beter. Of nog beter: Augmented reality waarmee een werkinstructie op de werkelijkheid wordt gelegd.

Bezint eer gemodelleert

Weer een heel verhaal over procesmodellen. Op zich niet veel nieuws, maar ik merk toch vaak dat even nadenken voordat “wij gaan onze processen in kaart brengen” veel frustratie in het vervolg kan voorkomen.

Modelleerze!

‘het nieuwe goud’ en uw processen

Geplaatst op door
1

Data is al heel wat jaartjes hip. Processen worden altijd een beetje als saai gezien.

Toch zijn ze onlosmakelijk met elkaar verbonden. Data is gewoon onderdeel van een proces.

Tenminste, zoals ik er naar kijk. Dus, hoe kijk ik er naar?

Doel is het laten presteren van processen; procesmanagement dus

In een eerdere post kon u al lezen dat ik procesmanagement opdeel in 3 niveaus (met daarboven eigenlijk nog het meer strategische ‘Waarom?’ niveau):

  1. De uitvoering van een proces voor een individuele zaak
  2. Besturing van alle lopende zaken in een bepaald proces
  3. Verbeteren van het procesontwerp voor een bepaald zaaktype

Wanneer ik organisaties help om al deze niveaus van procesmanagement in te richten, is belangrijk om te begrijpen wat je allemaal nodig hebt om een proces te laten presteren.

Zodat je niveau 3 niet zo vaak hoeft te doen.

Dat betekent dat we dan kijken naar diverse samenwerkende proces aspecten als:

  • Wat is het werk dat moet gebeuren (de werkstroom)?
  • Wat voor type mensen met welke capaciteiten zijn daar voor nodig?
  • Welke hulpmiddelen zijn benodigd?
  • Wat is de beste manier om dit proces te besturen (bijv. taakgericht of doelgericht)?

Er zijn meer aspecten, maar degene waar ik in dit verhaaltje op in wil gaan is Data.

Want u heeft waarschijnlijk al diverse artikelen gelezen waarin u las dat data ‘het nieuwe goud ‘ is.  Ook herinnert u zich vast de gloriedagen van ‘Big Data’ of leest u weer een quote dat we nu meer data in een minuut produceren dan onze grootouders in een heel millennium. En laten we dataverslindende AI gadgets niet vergeten.

Super cool, maar wat heeft het te maken met processen inrichten, besturen en verbeteren?

Veel. Want in bijna alle processen speelt data (of zou het beter zijn om het informatie te noemen?) een grote rol. Maar data in het algemeen is ook maar data, dus daarom maak ik altijd onderscheid, net als de cirkeltjes uit een eerder artikel,  in het gebruik van data op verschillende niveaus van procesmanagement:

  1. Data om een proces voor een individuele zaak uit te voeren
  2. Data om alle zaken die momenteel lopen te kunnen besturen
  3. Data om het proces(ontwerp) te kunnen verbeteren
  4. Data als verbinding tussen verschillende processen

Om dit uit te leggen, gebruik ik weer m’n ‘Bezorgen pizza’ proces:

Data die nodig is om het proces uit te voeren

In het proces ‘Bezorgen pizza’, is het gewenste procesresultaat een bezorgde pizza. Maar, het start allemaal met een klant die de wens heeft om een pizza te laten bezorgen. Om alle tussenliggende handelingen uit te kunnen voeren, is informatie benodigd.

Om de pizza te maken is informatie nodig als:

  • Welke pizza wil de klant?
  • Welk formaat?
  • Welke extra toppings zijn er besteld?

Om de pizza te kunnen bezorgen, is informatie nodig als:

  • Bezorgadres
  • Gewenste bezorgtijd
  • Telefoonnummer

Dit maakt ook duidelijk dat stappen die je vaak in het begin van een proces ziet, als ‘Vastleggen bestelling’ alleen maar nodig zijn om bovenstaande data te verkrijgen. Het vastleggen van deze data voegt geen waarde toe aan het maken of bezorgen van de pizza. Het voorziet het proces enkel van informatie. Maar wel nodig natuurlijk.

En daarom moet er, zeker in de huidige ‘multi-channel-tijd’, tijdens procesontwerp nagedacht worden over hoe de data in het proces belandt.

  • Telefoon
  • E-mail
  • Bestelwebsite
  • Bestel app

Omdat de Customer Journey ook een hip ding is, is het belangrijk dat het de klant niet heel erg moeilijk wordt gemaakt om u van deze data te voorzien.

Bovenstaande is dus data voor een individuele case. Hopelijk krijgt deze pizzeria meer dan 1 bestelling per dag. En daarmee kom ik op het volgende niveau van data.

Data om alle zaken in een proces te managen

Veronderstel dat op een bepaald moment in de avond zich 8 bestellingen in het proces bevinden. Medewerkers werken aan de individuele bestellingen, maar tenminste één iemand zal de rol van procesmanager moeten spelen om ‘alle zaken in de gaten te houden’.  Dat betekent dat er informatie nodig is over hoe de zaken er voor staan.

Voor mij zou dat betekenen dat je de status van alle zaken in het proces weet en dat duidelijk is of ‘de belofte wordt waargemaakt’

En die belofte kan, vanzelfsprekend, van proces tot proces verschillen. In een vorige post hield ik het simpel door alleen de bezorgtijd (binnen 50 minuten) in ogenschouw te nemen. Omdat waar te kunnen maken is dus voor elke bestelling inzicht in deze belofte nodig:

Dit is traditioneel proces monitoring, maar voor mij nog steeds essentieel in ‘doen wat je belooft’.  Dit is wat ik ‘op het veld’ noem. Want op dit moment kan nog ingegrepen worden in zaken waar de belofte mogelijk niet waar gemaakt kan worden.

Wanneer u nadenkt over de inrichting van zaakmonitoring, kunt u ook nadenken over in hoeverre u deze gegevens beschikbaar wilt stellen aan een klant. Het schijnt ‘the age of the customer’ te zijn, dus wilt u hem/haar informeren over de voortgang van de zaak?

Dit monitoring niveau van procesdata gaat om ‘doen wat je belooft voor de individuele klant’. In dit geval pizza’s op tijd bezorgen.

Nadat je meerdere individuele klanten hebt geholpen, wordt waarschijnlijk ook duidelijk hoe goed het proces in het algemeen is ingericht.

Tenminste, als u daar de juiste data voor verzamelt. En daarmee zijn we op niveau 3 van data in procesmanagement beland.

Data om processen te verbeteren

Dit derde niveau van data gaat over traditioneel procesverbeteren.  Presteert het proces zoals we het ooit hebben bedacht, of heeft het een opknapbeurt nodig? Het is de klassieke Village People hit ‘PDCA’.

Maar om te weten of het ‘beter’ moet, zul je eerst ‘goed’ moeten definiëren.

In mijn simpele pizza voorbeeld is dat ‘Bezorgd binnen 50 minuten’. Maar in het echt gelden vast meer doelen als:

  • Lekker (hoewel smaken verschillen)
  • Warm (> 78 graden)

Of interne doelen als:

  • Winstmarge op pizza > 34%

En dan hebben we het nog niet eens gehad over doelen opgelegd door andere belanghebbenden als wetgever of controlerende instanties als de NVWA.

Om te kunnen bepalen hoe goed het proces het doet (of eigenlijk ‘heeft gedaan’), is data over procesprestaties benodigd. Dat kan natuurlijk verzameld worden door te meten, spreadsheets bij te houden of misschien zelfs met mooie management informatie dashboards in een BPM tool.

En dat maakt mij verder ook niet uit, zolang de data je maar iets zinvols vertelt over de prestaties van je proces. Sinds een aantal jaar zou ook Process Mining hierbij een toepasbaar hulpmiddel kunnen zijn.

Process Mining is technologie dat data gebruikt van de systemen die worden toegepast om processen uit te voeren. Vervolgens wordt deze data (die over de verschillende afgehandelde zaken gaat) omgezet naar een ‘procesgeoriënteerde kijk’, om op die manier iets over het proces te weten te komen.

De meeste process mining tools hebben diverse mogelijkheden om deze data te representeren. Een basisplaatje is vaak een figuur van de werkstroom met daaraan gekoppeld de gemiddelde bewerkingstijd van activiteiten en de gemiddelde wachttijd tussen de activiteiten (weergegeven op verbindingen).

Na een beetje rekenen (wat de process mining tool vanzelfsprekend ook voor u kan doen) is de conclusie dat de gemiddelde doorlooptijd 50 minuten en 33 seconden bedraagt.

Maar, wat heb je nou aan gemiddeldes? Ik heb op school niet zo heel goed opgelet bij statistiek, maar niet zo heel veel, geloof ik.  Daarom hebben de meeste process mining tools ook de mogelijkheid om doorlooptijden, wachttijden etc. anders te tonen.

Bijvoorbeeld de minimale en maximale waarde. Dit geeft al een kleine indicatie van de variantie.

Het volgende plaatje laat de minimum en maximum bewerkingstijd van activiteiten en de minimum en maximum wachttijd op verbindingen zien.

Even de TI 30 stat er bij pakken en u ziet dat de snelste bestelling in 38 minuten werd bezorgd en dat de langzaamste er 1 uur en 25 minuten over deed. Is dat erg? Waarschijnlijk niet zo leuk voor de klant die 35 minuten langer dan beloofd moest wachten. Maar maakt dat het direct noodzakelijk om te sleutelen aan het procesontwerp?

Meer inzicht daarin verkrijg je door alle doorlooptijden in een grafiek te laten zien (ook standaard functionaliteit van een fatsoenlijke process mining tool).

Nu is zichtbaar dat 7 van de 23 bestellingen een langere doorlooptijd dan het doel van 50 minuten hadden. Of dat goed of slecht is, mag elke organisatie zelf bepalen. Maar voor de 7 klanten die de pizza te laat kregen, is er niks meer aan te doen. We kijken immers naar gegevens uit het verleden. Vandaar dat ik traditioneel procesverbeteren ook wel ‘kleedkamerpraat’ noem.

Een ander ding om te beseffen, is dat al deze proces prestatie informatie slechts symptomen laten zien. Om het proces te verbeteren, zul je echter op zoek moeten naar de oorzaken.

Toch kan process mining al wel wat indicaties geven over waar te zoeken naar de oorzaken van bijvoorbeeld een lange doorlooptijd.  Zo was te zien dat bestellingen een behoorlijke tijd spenderen aan wachten. Bijvoorbeeld tussen de stappen ‘Verpakken pizza’ en ‘Bezorgen pizza’.

Nog steeds een symptoom, maar dit zou kunnen leiden tot een onderzoek waarin duidelijk wordt waarom bestellingen gemiddeld 8 minuten wachten voordat ze worden opgepakt voor bezorging.

Om nog meer inzicht te krijgen in verstoringen van ‘de flow’, bieden process mining tools ook de mogelijkheid om de stroom van gevallen in een soort van filmpje te tonen. Wat er in feite gebeurt is dat het logbestand op een procesgeoriënteerde manier wordt nagespeeld. Hierdoor worden bottlenecks nog visueler (dit is overigens een statisch plaatje) weergegeven.

En dan ‘nog even’ een oplossing bedenken en implementeren 😉

En dat was niveau 3 van data; procesverbetering. Niveau 2 ging over de dagelijkse procesgang van zaken (in dit geval pizzabestellingen) en op niveau 1 zagen we de data benodigd voor een individuele bestelling.

Wanneer ik organisaties help met het knutselen aan processen, benoem ik ook altijd nog een ander type data; data die stroomt tussen processen.

Data die stroomt tussen processen

De meeste organisaties hebben meer dan één proces. We weten al dat de pizzeria een proces heeft voor ‘Bezorgen pizza’, maar er zullen ook processen zijn voor ‘Afhalen pizza’  en misschien ook wel voor ‘Eten in het restaurant’.  Daarnaast verwacht ik processen om de voorraad (van deeg, tomaten, saus, dozen, etc) op het gewenste niveau te houden.

En tussen al deze processen bestaan ook datastromen. Want als je 50 pizza’s per dag verkoopt, heeft dat gevolgen voor de voorraad. Dus het proces ‘Bezorgen pizza’ genereert data (50 pizza’s gemaakt), wat weer gevolgen heeft voor data in andere processen (de huidige voorraad van goederen).

‘Bezorgen pizza’  en ‘ Voorraad op gewenste niveau houden’ zijn dus processen met een relatie. Die relatie is niet de stroom van een zaak, maar gebaseerd op de data die in die processen gegenereerd wordt:

Processen sturen dus data naar ‘databases’ met informatie en ander processen maken weer gebruik van die data. Hier zijn vele voorbeelden van te bedenken. Bijvoorbeeld klantinformatie die in het ene proces wordt geactualiseerd en in het andere proces weer nodig is.

Dit maakt weer mooi duidelijk dat ‘de processelarij’  heel veel andere vakgebieden raakt zoals informatiemanagement en data-security.

En dat komt omdat dit niveau 4 van data zich meer op een organisatie- of procesarchitectuurniveau bevindt. Hiermee wordt ook duidelijk dat de prestatie van het ene proces invloed kan hebben op een ander proces.

Heel wat data, dus. Een belangrijk aspect van presterende processen, denk ik.  Maar niet het enige. Vandaar ook dat ik processen altijd een goed uitgangspunt vind om naar organisaties te  kijken.

Een proces is een verzameling van allerlei samenwerkende factoren. Niet alleen blokjes en pijltjes (en als u van BPMN houdt, ook wat cirkeltjes). Daarom blijf ik procesmanagement zo interessant vinden.

Gebruik uw data slim en happy processing!

Procesmanagement en uw wandeling naar dat mooie kasteeltje

Geplaatst op door
Antwoorden

castle

Ik zeg vaak dat procesmanagement dagelijks werk is. Toch besef ik me wel degelijk dat het door velen toch als iets nieuws of bijzonders kan worden gezien.

Wanneer u voor het eerst Processenland binnenwandelt, hoort of leest u mogelijk verhalen over BPM, Workflow, Adaptive Case Management, Zaakgericht werken en Process Mining en denkt u mogelijk  ‘Wat heeft dat allemaal met mijn dagelijkse werk te maken?’

Het kan allemaal te maken hebben met het besturen van uw organisatie op een procesmatige manier. Dat is overigens slechts één manier om uw organisatie te besturen. Maar omdat processen ‘de dingen’ zijn om de problemen van uw klanten op te lossen, is meer grip (of beter; het juiste niveau van grip) op ze krijgen niet zo’n gek idee.

Begin aan het eind

Wanneer organisaties ‘iets met processen’ willen doen is mijn advies altijd om te beginnen aan het eind.  Met duidelijk maken welke resultaten (producten/diensten/opgeloste problemen) het waard zijn om te bereiken en te besturen als een proces.

Je kunt het zien als het maken van een reis. Voordat je  op reis gaat (tenminste, in een bedrijfsmatige context, misschien wel niet privé 😉 moet je weten waar je naar toe wilt.

Wat heb je nodig om de bestemming te bereiken?

Vervolgens moeten er veel dingen worden besloten; de route, de beste transportmanier, beste tijd om te reizen, etc. Een proces heeft vele aspecten (ook wel ‘enablers’ genoemd) nodig om te presteren. Denk hierbij o.a. aan goede mensen, goede informatie, ondersteunende tools, passende manier van besturen en een slimme route.

Echter, alleen focussen op de route (ook wel de werkstroom genoemd) is veelal te weinig om te begrijpen wat echt nodig is om een proces te laten presteren. Toch is deze werkstroom wel een handig ‘skelet’ om over het proces te kunnen praten.

Dus een proces; op z’n minst zal er een route gevolgd worden naar de bestemming. Maar, deze route is mogelijk niet altijd van te voren bekend en misschien zijn er wel effectievere routes. Dus, pak uw tas in en…

…stelt u zich eens voor dat u, ergens in Europa, op een bergtop bent beland. Tot uw schrik realiseert u zich dat u een beetje bent verdwaald. Maar dan, wanneer de mist optrekt, ziet u een prachtig kasteel op een andere berg, een paar kilometer verderop.

Het reisdoel

U stelt vast dat uw gewenste resultaat ‘zijn in het kasteel op de andere berg’ is en besluit een wandeling (de werkstroom) te gaan maken om die bestemming te bereiken.

Een klein probleempje; tussen u en het kasteel bevindt zich een groot, donker (velen zouden het als griezelig betitelen) woud. Maar, zoals wel vaker, heeft u weer eens geluk; net voordat u uw wandeling wilt starten, komt er een man uit het bos. Hij vertelt u dat hij uit het kasteel komt en ook wel ‘Meneertje Gestructureertje’ wordt genoemd.

Daarom heeft hij al zijn stappen bijgehouden om van het kasteel naar de berg, waar u nu op staat, te komen. Ondanks dat de man wat vreemd gekleed is in zijn lange jas, vertrouwt u hem en volgt zijn aanwijzingen in omgekeerde volgorde.

Linksaf bij de grote steen, een kilometer over het smalle pad tussen de beukebomen, de rivier over bij de houten brug en ja hoor, na een stevige wandeling van enkele uren bereikt u inderdaad het kasteel.

Workflowmanagement-stijl

Dit was een reis die in procestermen ‘workflowmanagement-stijl’ genoemd zou kunnen worden. Alle stappen zijn netjes uitgevoerd, het procesresultaat is bereikt, maar als procesuitvoerder heeft u mogelijk geen idee wat u doet en waarom. Dit is klassiek ‘Taylorisme’  en kan nog steeds geschikt zijn voor bepaalde type processen.  En daarnaast zijn er in de huidige wereld van ‘Social’, ‘Digitalisatie’ , ‘Uberizering’ en ‘Co-creatie’ nog genoeg mensen die ‘gewoon hun werk willen doen’ en niet geïnteresseerd zijn in processen.

Worfklowmanagementsystemen zijn in de basis dus systemen die zaken langs uitvoerders routeren, die vervolgens handelingen voor deze zaken uitvoeren. Vergelijkbaar, met een lopende band dus. Daarom heb ik het ook altijd gek gevonden dat het ‘workflow’ wordt genoemd. De zaken stromen en het werk staat juist stil 😉

Terug naar de bergtop. Wat als u de man met instructies niet had ontmoet en zonder stappenplan aan uw reis had moeten beginnen?

“We zien wel”

Dan was u gewoon met lopen begonnen om tijdens de reis op diverse obstakels te stuiten waar u op dat moment een oplossing voor moet zoeken. Dus u loopt mogelijk uren langs een woeste rivier om een brug te vinden, verstopt zich 45 minuten achter een steen voor een boze beer en ontwijkt die bosjes met gevaarlijke doornen.

Maar uw gewenste resultaat blijft het kasteel, dus zo nu en dan klimt u in een boom om te kijken waar het kasteel zich bevindt. En na het overwinnen van de nodige obstakels en uitdagingen, bereikt u uiteindelijk het kasteel.

Adaptive Case Management 

In procestermen wordt deze manier van reizen ‘Adaptive Case Management’ of ‘Dynamisch Case Management’ genoemd.

Er is een gewenst resultaat, maar er is geen vooraf gedefinieerde route. Dus tijdens de reis bekijkt u continue wat de beste volgende stap is. Dit zie je bijvoorbeeld veel in processen waar, sorry voor de term, kenniswerkers problemen moeten oplossen voor verschillende zaken, maar waar elke zaak zijn eigen unieke problemen en karakteristieken heeft.

Informatie en vertrouwen  belangrijker dan uitgestippeld pad

Workflowmanagementsystemen, zoals hierboven genoemd, kunnen dit type proces niet zo goed ondersteunen omdat het te volgen pad niet van te voren bedacht kan worden. In dit soort processen is het veel belangrijker om medewerkers te voorzien van alle zaakinformatie om hun beslissingen op te baseren.

Over meerdere zaken gesproken; stel dat er nog meer mensen zijn die hetzelfde kasteel willen bereiken zonder kaart. Zij baseren hun beslissingen dan op hun eigen ervaring en passen hun individuele kennis en vaardigheden toe tijdens de reis.

Sommigen kunnen misschien goed zwemmen en zoeken niet naar een brug. Anderen beschikken over een bijl en hakken wat bomen om om een pad te maken, etc. Afhankelijk van de situatie (de zaakinformatie), neemt iedereen andere beslissingen en creëert zo zijn eigen route.

Deze dynamische manier van procesmanagement kan twijfels oproepen omdat het ongestructureerd lijkt (iedereen doet maar wat hem het beste lijkt).

Maar dat is nou eenmaal hoe sommige processen werken. Het vereist vertrouwen in uw vaardige medewerkers in plaats van ze te willen micro-managemen en het proces tot een ‘verplichte volgorde van stappen’ te laten worden. Goede informatievoorziening over zaken, maar ook tussen medewerkers, helpen om deze processen te ondersteunen.

Maar, misschien is er in uw processen toch meer structuur nodig of mogelijk. Dus terug naar het donkere bos.

Wat als al deze ‘kennisreizigers’ GPS trackers in hun rugtas hadden verstopt, gecombineerd met een go-pro op hun hoofd? Dan wordt er uiteindelijk heel veel informatie over de gevolgde routes verzameld. Deze informatie kan vervolgens gebruikt worden om te bekijken welke route en beslissingen het beste resultaat opleverden.

Process Mining 

Deze manier van ‘het ontdekken van de gevolgde routes’ is wat Process Mining voor u kan betekenen. Process Mining is een technologie waarbij ‘verborgen’ werkstromen worden ontdekt uit grote hoeveelheden data die zich bevinden in de systemen waarmee u dagelijks uw processen uitvoert.

Deze informatie kan gebruikt worden om verschillende routes te analyseren en zo te bepalen welke route in welk geval geschikt is. Wellicht dat sommige routes ook tot standaard gepromoveerd kunnen worden. De meeste processen worden immers meerdere keren per week/dag/maand uitgevoerd en dan merk je dat er vaak behoefte is aan een ‘bekende weg’.  Je zou dit ‘normaal procesmanagement’ kunnen noemen.

Dus als 20 mensen elke dag dezelfde reis naar het kasteel moeten maken, kan het nuttig zijn om hen de beste route op dat moment te overhandigen. De uitvoering van het proces zou ondersteund kunnen worden met een ‘Procesmanagement systeem’, wat je in reistermen als een soort van navigatiesysteem kunt zien.

Het mooie is dat op die manier steeds data en ervaringen worden verzameld. Op deze manier kan continu geleerd worden of de route nog past bij het gewenste resultaat.

Procesnavigatie

Over dat navigatiesysteem getypt; daarin geeft u het gewenste procesresultaat (het kasteel) aan. Dan moet u, naar mijn mening, zich ervan bewust zijn dat er wel een verschil is tussen het procesresultaat en doelen die u daarover afspreekt.

U kunt ervoor kiezen om het kasteel snel, via de kortste weg, of de mooiste route te bereiken. In uw organisatie is dat afhankelijk van uw strategie. Wilt u de snelste, de goedkoopste of degene met de hoogste kwaliteit zijn?

Dit navigatiesysteem is daarmee een soort van zaaksysteem geworden.

Dit systeem zal dan opereren als een soort van gids tijdens de uitvoering van het proces voor een zaak. Het zal u ook informeren of u het gewenste doel zult halen (verwachte aankomsttijd is 10:25) en kan mogelijk waarschuwen wanneer u niet aan regels voldoet (knipperend verkeersbordje wanneer u de snelheidslimiet overschrijdt)

De meer flexible navigatiesystemen kunnen u zelfs helpen met het vinden van alternatieve routes wanneer onverwachte dingen gebeuren (een omgewaaide boom op de weg).

Kortom biedt een procesmanagement- of zaaksysteem u op elk moment inzicht in de status van alle zaken die u op dat moment in behandeling heeft.  En afhankelijk van uw wens kunt u de vrijheidsgraden van besturing bepalen. U zou zelfs de route weer helemaal dicht kunnen timmeren waardoor eigenlijk weer een traditioneel workflowmanagmentsysteem is gecreëerd.

Het resultaat bepaalt de reis

Conclusie: Net zoals je een reis op verschillende manieren kunt maken, kunnen processen op verschillende manieren ingericht en bestuurd worden. Afhankelijk van het gewenste resultaat en daaraan gekoppelde doelen. Het bepalen van deze mate van flexibiliteit vind ik een belangrijke stap in het ontwerpen van een proces.

Even terug naar het begin van dit verhaal; ik denk dat alle discussies over ‘Normaal BPM’ vs ‘Workflow’ vs ‘Adaptive Case Management’ vs ‘Zaakgericht werken’ niet zo zinvol zijn en dat we beter kunnen kijken welke manier van besturen processen het beste laat presteren.

Ik wil u wel graag bedanken voor de reis de we samen hebben gemaakt. Maar, vergeet niet de echte boodschap van dit verhaal.

Hoewel het vaak een natuurlijke aantrekkingskracht heeft, zou het discussiëren over een proces niet met de route moeten beginnen. Ik denk dat het beter is om de discussie te starten met de vraag of het resultaat waarover u het heeft wel een proces waard is.

Herinnert u zich dat mooie kasteel? Dat kasteel staat in het stadje Bran in Roemenië. En dan weet u misschien dat ‘zijn in het kasteel’ helemaal niet zo’n gewenst resultaat is. De meesten die de reis hebben gemaakt wensen dat ze het nooit hadden gedaan want ze eindigden allemaal met twee kleine gaatjes in hun nek…

Meten is weten. Nou en?

Geplaatst op door
Antwoorden

013

Regelmatig lees ik artikeltjes op Linkedin over wat belangrijker is in BPM; het proces of data?

Gekke vraag, want data is onderdeel van een proces. Net als mensen, werkstroom, hulpmiddelen, procesregels, etc. Al deze aspecten met elkaar zorgen ze ervoor dat een proces (goed of slecht) presteert. Nu vind ik de informatievoorziening wel één van de belangrijkste aspecten voor het presteren van een proces. En ook niet te vergeten; informatie bevindt zich op meerdere niveaus van procesmanagement.

In de uitvoering van een zaak (bijvoorbeeld een bestelling voor een product of dienst) is informatie over die bestelling benodigd. Altijd handig als dat snel en foutloos is te vinden.

Ook in procesverbetering-initiatieven is informatie nodig. Als er bijvoorbeeld gegevens zijn verzameld over alle 2000 zaken die u het afgelopen jaar heeft afgehandeld, zou u, bijvoorbeeld met behulp van Process Mining technieken, iets kunnen zeggen over mogelijke procesverbeteringen voor de toekomst.

Maar als het op procesmanagement aankomt, ligt de meest waardevolle informatie hier, naar mijn mening, tussenin. Informatie die iets zegt over de procesuitvoerining op dit moment. Hoeveel zaken lopen er? In welke status zijn ze? Zijn ze nog ‘on track’? Gewoon monitoring eigenlijk. Veel organisaties doen dat. Meten vaak allerlei gegevens. Maar zeggen ze ook iets over de voortgang van een zaak? Helpt het u om te bepalen of u moet ingrijpen?

En daarmee kom ik op de boodschap achter dit procesje. Meten is Weten. Leuk, maar als je niet kunt ingrijpen, erg frustrerend. Help, we gaan niet op tijd leveren!

Dus wanneer u mooie dashboards gaat ontwikkelen, vergeet dan niet dat u ook mogelijkheden bedenkt om bij te kunnen sturen, wanneer deze dashboards gaan ‘piepen’.

Want, als ik toch niet kan remmen of gasgeven hoef ik ook niet weten hoe snel ik ga.