Maar weer eens een blogje over procesmodellen

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!

Visio-therapie? Dat zit toch in het aanvullend pakket?

028

Afgelopen tijd ben ik weer veel bedrijven geweest waar (nog steeds) het in kaart brengen van processen als heilige graal wordt gezien. Laten we mooie procesmodellen maken, deze op een intranet zetten en dan met z’n allen hopen dat iedereen er elke dag naar kijkt en dat de processen dan vanzelf beter gaan verlopen. Bij u gebeurt dat niet? Da’s mooi, dan heeft u geen Visio-therapeuten (elke andere modelleer tool mag ook, maar dit is nou eenmaal leuk voor het woordgrapje) in dienst.

Het wordt wel minder, maar nog steeds hoor ik verhalen waarin het in kaart brengen van processen  wordt verkocht als procesmanagement.

Maar dat is toch geen procesmanagement?  In procesmanagement gaat het er om dat u processen gebruikt als middel om uw organisatie te besturen. Een statisch procesmodel kan u helpen om ‘inzicht’ te krijgen in het proces, maar om een proces uit te voeren, te managen en misschien wel te verbeteren is veel meer nodig.

Dus in plaats van uw intranet vol te zetten met “hoe de processen uitgevoerd moeten worden” is het misschien verstandig om medewerkers in te wijden in de zin en onzin van procesmanagement. En heb niet de illusie dat iedereen dat interessant vindt, maar onze ervaring is dat het meer oplevert dan iedereen te wijzen op die processchema’s op het intranet.

Als een medewerker weet wat een proces moet opleveren, weet wat er nodig is om een proces te laten presteren en het lef heeft om te verbeteren wordt procesmanagement echt dynamisch.

Da’s meer waard dan elke Visio-therapeut.

 

Subprocessen

003

In mijn dagelijkse praktijk kom ik, per week, toch gemiddeld zo’n 3.457 Mb aan procesmodellen tegen. Ik ga het er nu een keer niet over hebben dat alle processen zomaar in kaart brengen zinloos is. Nee, ik wil het eens hebben over wat ik ook vaak zie; verschillende niveaus in procesmodellen.

Omwille van “behapbaarheid” wordt een procesmodel vaak opgedeeld in grote brokken; subprocessen. Daarmee ontstaan er verschillend lagen; hoofdproces, werkproces, activiteit, handeling en wat al niet meer. Hartstikke gestructureerd, makkelijk te rapporteren, maar een strak uitziend procesmodel kan toch geen doel zijn?

Wanneer u er voor kiest om een proces in kaart te brengen, is globaal (het liefst door het vaststellen van een proceslandschap) beginnen niet verkeerd.
Maar wilt u processen verbeteren en echt begrijpen waarom een proces niet presteert, dan heb je aan dat globale plaatje bij lange na niet genoeg. Voor verbeter-doeleinden gebruik ik dan ook nooit niveaus, maar modelleer alles op activiteitniveau.

Dat kan er rommelig uitzien. Da’s mooi, want dan zal het proces ook wel complex zijn ingericht. Daarnaast zijn al deze activiteiten (de werkstroom) niet het enige wat nodig is om een proces te laten presteren.

Mensen, informatie, ondersteunende systemen, stuurinformatie, procesregels. Zomaar wat factoren die allemaal nodig zijn voor een goed werkend proces. Blindstaren op subprocessen met daarin activiteiten is dus niet genoeg.

Denkt u ook in hokjes of durft u naar het gehele proces te kijken?