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 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.

 

Geregeld.

024

Procesregels. Ik schrijf er niet zo vaak over. Toch komen ze in veel processen voor. Een procesregel bepaalt of een geval (het ding dat door het proces stroomt) links of misschien wel rechts gaat.

Een procesregel zou bijvoorbeeld kunnen zijn dat aanvragen van 50.000 € of meer anders worden afgehandeld dan aanvragen van minder dan 50.000 €.

In een procesmodel zie je zo’n procesregel vaak terug als het oud Hollandse wybertje. Maar, dat is en blijft slechts een plaatje. In de uitvoering van een proces kan zo’n procesregel grote invloed hebben op de prestaties van een proces.

Zeker wanneer de capaciteit (bijvoorbeeld van mensen) over de gevallen met verschillende procesregels moet worden verdeeld. Het zou dan zo kunnen zijn dat het kleine aantal aanvragen van meer dan 50.000 €, de grote hoeveelheid andere aanvragen heel erg ophouden, met grote doorlooptijd voor sommige gevallen als gevolg.

Het is dus verstandig om uw procesregels regelmatig te evalueren en, indien nodig, bij te stellen. Daarom zijn er veel organisaties die een “rules engine” hebben, om de procesregels “buiten het proces” te kunnen wijzigen.

En wanneer een procesregel bepaalde gevallen tot een dusdanige uitzondering maken, is een andere overweging dat deze een eigen proces krijgen, zodat ze de andere gevallen niet meer verstoren.

Er zijn mensen die beweren dat regels leuk zijn. Dat lijkt me wat overdreven, maar wanneer heeft u het laatst naar uw procesregels gekeken?

 

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?

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?

 

Resultaten uit het verleden…

007Deze week was er weer een ellenlange discussie op BPM.com over het in kaart brengen van het bestaande (ook wel bekend als AS-IS of IST) proces. De meesten vinden dat  heeeeel erg belangrijk en een kritische noot op ‘procesmodelstaren’ lijkt meestal niet erg gewaardeerd te worden. Waarschijnlijk omdat dan de verkoop van procesmodelleer klussen in gevaar zou komen.

Maar geef nou eens toe; hoe vaak heeft het in kaart brengen van een bestaand proces bij u nu tot fantastische verbeterinzichten geleid? Misschien best wel vaak. Maar, hoe vaak zijn die verbeterideeën ook tot werkelijke uitvoering gebracht? Minder vaak, vermoed ik.

Aan het vaststellen dat het momenteel echt niet goed is en het bedenken van veranderingen schort het vaak niet. Maar de inrichting van een proces veranderen, zodat het wel beter gaat presteren, is een tweede. Enerzijds komt dat vaak door een beperkt beeld van een proces (blokjes met pijltjes) en anderzijds de bekende verhalen als ‘ze willen niet meewerken’ en ‘weerstand’.

En da’s natuurlijk niet zo gek als verbeteren van processen als iets los van de uitvoering wordt gezien. Een stafhobby, een proces excellence center, procesverbeterteams; dat soort dingen.

Ik heb er zelf ook allemaal aan mee gedaan, maar merk meer en meer dat deze ‘los van de uitvoering’ praktijken leuk zijn voor de mensen die het doen, maar uiteindelijk niet opleveren wat ervan verwacht wordt. Da’s toch zonde?

Er is geen enkele plek waar de ‘voor verbeteringen vatbaarheid’ van processen meer wordt gevoeld dan op de werkvloer. ‘Maar ze mogen toch mee doen met de procesmodelleersessies?’

Ja, maar zijn ze ook verantwoordelijk voor de implementatie? Zien ze het als iets van hen? Vaak niet. Dus verbeterpower onderin het organigram. Op de plek waar het zin heeft, niet in stafprojectjes. Is dat nou nieuw?

Helemaal niet. Maar wel een beetje eng.