Zoekt en gij zult niet vinden

Over de zin en onzin van processen in kaart brengen heb ik al genoeg geschreven. Het blijft toch vaak de wereld van ProcesPsychologen, LeanLuitjes, RisicoRakkers en VerbeterVentjes.

Meestal niet de wereld van de werkende helden. Toch wordt vaak gedacht dat door al deze procesinformatie op een intranet te knallen, deze medewerkers wel geholpen worden. Maar, geholpen waarmee?

Eén van mijn gewaagde uitspraken tijdens een presentatie onlangs was ‘Als je medewerkers procesmodellen moet geven om het werk uit te voeren, heb je het proces niet goed geïmplementeerd. En ik zou ook eens een gesprekje houden met je HR mensen over het inwerkbeleid’. Stilte. ‘Emiel bedankt, leuk dat je er was’

Maar ja, wie ben ik, dus ik stap maar even af van de discussie of procesmodellen wel of niet een hulpmiddel zijn ter ondersteuning van het werk van medewerkers.

Als je gelooft dat dat echt zo is, zorg dan in ieder geval dat de zoekfunctie bovenop al deze procesinformatie een beetje fatsoenlijk werkt. Het is namelijk een illusie dat medewerkers vanuit een soort van procesoverzichtsplaat beginnen te klikken naar lagere niveaus en hun vraag wel beantwoord krijgen.

De zoekfunctie zou dan hulp moeten bieden. Maar die laat, mijns inziens, nogal eens te wensen over in menig intranet-proceshandboek.

Zoeken op een term levert vaak een grote hoeveelheid resultaten op, die kunnen verwijzen naar plaatjes, beschrijvingen, werkinstructies, documenten, etc.

Wat mij betreft zouden er tenminste 2 zoekopties feilloos moeten werken:

– Ik wil….

– De klant wil….

De eerste zoekoptie moet direct leiden naar een werkinstructie/hulpmiddel om de taak uit te voeren waar de medewerker naar zocht.

De tweede zoekoptie denkt meer vanuit de klant en zou moeten leiden tot de informatie om de klant te kunnen vertellen wat er allemaal moet gebeuren om haar/zijn wens in te vullen. Dit dwingt ook om meer te denken vanuit zaken/zaaktypes in plaats van algemene procesmodellen. Een goede zaak vind ik.

Maar gelukkig heb ik meer verstand van processen dan van zoeken. Anders had ik wel bij Google gewerkt.

In hoeverre helpen procesmodellen uw werkende helden?

Zijn procesmodellen wel zo handig voor procesverbeteren?

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

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.

 

Wat voeren wij hier uit, jongeman?

025

Processen in kaart brengen. Inmiddels weet u wel dat dat bij mij regelmatig allergische reacties oproept. Niet omdat ik per definitie tegen procesmodellen ben, maar meestal omdat het middel niet zelden tot doel wordt verheven.

Ik ben van mening dat het het doel niet moet zijn om processen in kaart te brengen. Het zou moeten gaan om het inrichten en uitvoeren van een proces, zodat het doet wat u belooft.  Een proces zelf is dus eigenlijk ook maar een middel. Een middel om een resultaat te leveren. Dus het is aan u de taak om te bepalen wat de karakteristieken van het proces moeten zijn om dat resultaat te kunnen leveren.

Vanuit dat eindpunt kun je nadenken over de inrichting van de verschillende procesaspecten.

Hoe wilt u bijvoorbeeld de werkstroom inrichten (procedureel of meer flexibel op basis van de zaak)?  Welk type medewerkers heeft u nodig omdat zo uit te voeren (gestuurden of zelfsturenden)?  Wat vergt dit proces van uw informatievoorziening? Welke hulpmiddelen hebben uw medewerkers nodig?  Welke procesregels zijn van belang?  Hoe wilt u de besturing inrichten (strak er bovenop of resultaat gericht)?

Kortom, vele aspecten die een proces doen presteren. En deze aspecten kunnen van proces tot proces verschillen. Dat ligt bijvoorbeeld ook aan de uitvoeringsfrequentie van het proces en, zoals gezegd, wat belanghebbenden verwachten aan het eind van het proces.

En een procesmodel? Tja, daar kunt u alle bovenstaande aspecten heel goed in vast leggen. Maar uiteindelijk inrichten en uitvoeren is waar het om gaat. Net een wegenkaart. Niet zinloos als je het gebruikt om een reis ’in te richten’.  Maar uiteindelijk is het de reis die je bij de gewenste bestemming brengt.

Niet de kaart.

Als de beschrijvingen maar up to date zijn, toch?

020U zou haast denken dat ik alleen maar bezig ben met het verzinnen van quasi lollige procesjes en het twitteren van cynische teksten, maar toch kome ik ook regelmatig bij organisaties die ‘iets met processen’ doen. En ja, dan blijkt het vastleggen van processen toch vaak op een griepje waar je niet vanaf komt.

Vanzelfsprekend belanden we dan snel in discussies over hoe deze beschrijvingen actueel gehouden kunnen worden. Gemene vraag die ik dan stel; denkt u dat uw klanten op actuele procesbeschrijvingen zitten te wachten? Nee, lijkt me niet.

Die (proces)klanten willen gewoon dat u uw processen dusdanig ingericht heeft zodat deze processen u helpen om te doen wat u belooft. Grip op de uitvoering van processen (wel zinvolle graag!) is uiteindelijk het enige wat telt. En in de uitvoering kan dat betekenen dat processen inderdaad vaak veranderen, omdat u voor een bepaalde klant net even iets anders doet.

Daarmee wordt ook weer benadrukt dat een proces niet hetzelfde is als ‘standaardisatie’. Processen zijn gewoon processen (de ‘dingen’ die producten en diensten leveren) en standaardisatie is slechts een oplossing om meer grip te krijgen op een proces. En voor processen waar ‘adaptation’ belangrijk is, is standaardisatie waarschijnlijk geen goede oplossing.

Het is dus grappig om te zien dat, afhankelijk van iemand’s standpunt, heel makkelijk doel en middel door elkaar worden gehaald.

Ooit een organisatie gezien die als doel had om up to date procesbeschrijvingen te hebben?

Wat kijkt iedereen hier betrokken

019In elke organisatie die ‘iets met processen’ wil doen, ontstaat uiteindelijk wel de discussie over hoe je medewerkers kunt betrekken bij processen. Nu is dat sowieso al een vage vraag. Wat wordt er bedoeld met  ‘processen’?  Mooie modellen maken, processen verbeteren of ze gewoon uitvoeren?

Ik hoop altijd dat laatste, maar vaak wordt toch bedoeld het verbeteren van processen.

Verplicht mee moeten doen met allerlei verbeterprojecten, uitmondend in het gedetailleerd vastleggen van processen; hoe betrokken is dat?  Dan weet je zeker dat medewerkers gemotiveerd raken; gemotiveerd om nooit meer mee te doen.

En het is vaak wel zielig voor al die procesgekken die met allerlei middelen proberen om iedereen te verleiden met procesverbeterdingen mee te doen. Met zoveel enthousiasme werken ze eraan en niemand vindt het interessant.

Heel vaak zit ‘m dat toch op (ja, ik weet dat het tocht door de open deur); communicatie.  Stel dat je er voor kiest om procesverbeterprojecten uit te voeren, neem dan in ieder geval de moeite om te vertellen over welke processen het gaat, wat er van die processen verwacht wordt en waarom ze niet goed lopen.

Maar  toch, ik blijf het gek vinden om verbeteren als iets los te zien. We gaan even verbeteren en dan weer aan het werk. Waarom niet andersom?

Ga aan het werk en geef medewerkers de mogelijkheden en middelen om te verbeteren. Zij voelen de pijn, zitten dicht bij de klant. Dat is de plek waar verbeteringen tot leven komen.

En als u ze dan ook nog een klein beetje opleidt over procesmanagement; wow  (….pinkt een traantje weg…)

Ziet u uw processen wel?

014

De meeste mensen die een huis bouwen, beginnen met een impressietekening en wanneer ze daadwerkelijk willen bouwen, worden de tekeningen steeds gedetailleerder; constructieberekeningen, leidingschema’s etc.

Heel gek is het daarom dat het vaak andersom gebeurt wanneer organisaties procesgericht willen gaan werken (bouwen van een proces?).

Met veel enthousiasme, energie en tijdsbesteding worden allerlei processen gedetailleerd in kaart gebracht. Tot het moment dat niemand het meer snapt. Dan wordt er voor gekozen om het allemaal weer wat simpeler te maken, met als gevolg dat het te simpel is geworden om een goede diagnose te stellen waarom het proces niet presteert of om het daadwerkelijk in te richten.

Sowieso zie je dat hier verschillende doelen van processen modelleren door elkaar lopen (van instructie-achtige zaken tot processen verbeteren).
Wanneer verbeteren uw doel is, is het aan te raden om het andersom aan te pakken.

Maak je niet te druk om details van een proces het als u het toch niet wilt verbeteren. Begin dus eerst met het opstellen van een zogenaamd proceslandschap. Simpel gezegd een lijst van processen in uw organisatie.

Selecteer in deze lijst de slecht presterende processen (het resultaat voldoet niet aan de doelstellingen). Om inzicht te krijgen in de oorzaken, kunt u dit proces in detail proberen te doorgronden. Mogelijk met behulp van een procesmodel.

Waarom een leidingschema maken voor een huis dat u toch niet wilt bouwen?

 

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?