Van GARBAGE-IN naar… GOUD-OUT - deel 1

Ik zou het niet meer doen. Na het beschrijven van 40 processtandaarden voor gemeenten zou ik mijn procesbeschrijvingskunsten (leuk scrabblewoord) aan de wilgen hangen. Je voelt hem hè…  die ‘maar’ die eraan komt.

Nog één keer ben ik gestrikt om ermee aan de slag te gaan. Ik doe het met plezier, met liefde en met hetzelfde enthousiasme als altijd. Zéker als het gaat om kennis overbrengen. Maar het zou niet nodig moeten zijn… Je hebt mij -of wie dan ook- niet nodig om je processen te beschrijven.

Daarom: deze 3-delige blogserie. Om je alle instrumenten mee te geven, zodat jij chocola kan maken van procesbeschrijvingen.

Methode van vastleggen en beschrijven

In 25 jaar heb ik zo'n beetje alle software om procesbeschrijvingen vast te leggen wel voorbij zien komen. Van het klassieke bierviltje tot Protos, Mavim en SqEME aan toe. Ook zag ik de opkomst van allerlei methoden als paddenstoelen uit de grond schieten. Van Scrum tot Agile, van Kanban tot Lean.

Allemaal niks mis mee, begrijp me niet verkeerd. Maar persoonlijk is de liefde voor het bierviltje gebleven. Eerst tekenen met de hand en dan automatiseren in software die meteen breder ingezet kan worden, zoals een risicomanagementsysteem.

"In 25 jaar zag ik alle software voor procesbeschrijvingen wel voorbij komen, maar de liefde voor het klassieke bierviltje is gebleven."

Wat is eigenlijk het probleem?

25 jaar fröbelen met processen hebben mij geleerd: het draait om geen van de bovenstaande zaken. De methode en de beschrijving worden pas belangrijk wanneer er aan twee voorwaarden is voldaan:

1. Weten wat een proces is én

2. Weten -of uitzoeken- wat er in een proces gebeurt.

Waarom makkelijk als het moeilijk kan?

Nee, ik verschrijf me hier niet. Maar zoals Confucius al zei: “Leven is makkelijk, alleen staan wij erop om het moeilijk te maken”. Zelf ben ik altijd blijven roepen: “Houd het Simpel” en gebruik vooral je diploma GBV -Gezond Boeren Verstand.

Maar over een proces bestaan vele misverstanden. Simpel gezegd is een proces niks meer of minder dan het onderstaande plaatje.

- Er gaat “iets” het proces in.

- Dat “iets” wordt verwerkt.

- En er komt “iets” uit.

Spannender wordt het niet.

Waarom is het dan toch zo moeilijk een proces In Control te krijgen? 2 valkuilen

Om de bovenstaande vraag te beantwoorden moeten we het eerst eens worden over wat we eigenlijk willen beschrijven en wat we In Control willen brengen.

Een voorbeeld

Iedereen moet wel eens reizen van A naar B. Dat kan met de auto, fiets, trein, boot, benenwagen of welk vervoermiddel dan ook. Laten we in dit voorbeeld de auto nemen.

Valkuil nummer 1. Wat is het proces

Het proces in dit voorbeeld is de reis van A naar B.

Het vervoermiddel (in ons geval de auto) is het middel.

❗ Hier gaat het vaak gelijk al mis omdat we denken dat de ‘reis met de auto’ het proces is. Maar in dit geval is de ‘reis met de auto’ niet het proces, maar ‘het autorijden’ is de throughput (verwerking) van het proces. De procesuitkomst moet immers zijn: arriveren bij punt B.

Het gevolg van deze denkfout? We gaan beschrijven hoe het proces van het autorijden in elkaar steekt. Iets met: het starten van de auto, gas geven (niet te hard), remmen (vooral op tijd) et cetera. Maar we zijn hier dus het proces ‘autorijden’ aan het beschrijven en niet het proces van de reis van A naar B. En deze valkuil is zo aanlokkelijk om in te stappen omdat het ‘proces van autorijden’ de throughput (verwerking) is van het proces van de reis van A naar B.

Valkuil nummer 2. Valse doelmatigheid

Bovenstaande doen we vaak ook nog vanuit het oogpunt van doelmatigheid, om te bekijken of we wel doelmatig (efficiënt) autorijden. Alleen hebben we daar -in het geval van de procesbeschrijving van de reis van A naar B- helemaal niets aan als we niet eerst weten of we doeltreffend (effectief) zijn.

Effectief is in dit geval het bereiken van punt B. Bereiken we punt B namelijk niet, dan kunnen we nog zo doelmatig autorijden, de procesoutput blijft ongewenst (we komen namelijk nooit bij B aan).

❓ Is dat dan zo essentieel om eerst te weten of je doeltreffend bent, voordat je doelmatigheid kan onderzoeken? Het antwoord is simpelweg JA.

Stel, we bereiken keer op keer punt B niet. Door de focus op de throughput (verwerking) blijven we onze autorijkunsten aanscherpen. Maar wat nu als blijkt dat het niet bereiken van punt B simpelweg komt omdat je daar met de auto niet kan komen?

Dan kan je de doelmatigheid van het autorijden blijven onderzoeken, de doeltreffendheid van het proces ‘reis van A naar B’, blijft nul komma nul, noppes, niente, nada, niks. Oorzaak: Een verkeerde input. De auto had bijvoorbeeld een fiets moeten zijn.

Stop met tijd, energie & geld uitgeven aan procesbeschrijvingen. Start met het proceshandboek. 
40 processen. 1 handboek. Eindelijk alles beschreven. LEES ER HIER ALLES OVER

Valkuilen vermijden met GBV

Een proces is niets minder dan een aantal processtappen die elk een input, throughput, output hebben. En de hele schakel noemen we: het proces.

Focus je dus per processtap op de input (dat “iets” dat erin gaat) en de output (dat “iets” wat eruit moet komen) en laat die hele throughput voorlopig met rust. Dat is immers niets meer dan een werkinstructie. Een werkinstructie over “hoe je moet autorijden” of “hoe je moet fietsen” of “hoe je moet varen”. Je snapt mijn punt.

"Een proces is niets minder dan een aantal processtappen die elk een input, throughput, output hebben. En de hele schakel noemen we: het proces."

En nu hoor ik je nu denken, “Ja, maar er zijn meer factoren! Zo is bijvoorbeeld de route óók belangrijk”.

En daar heb je helemaal gelijk in. Maar het plannen van de route is een processtap van het proces ‘reis van A naar B’. Met als input “hoe kom ik van A naar B”. Als throughput “het plannen van de reis”. En als output “een geplande route”. Wederom is ‘hoe’ je de reis plant hier niet belangrijk.

Mocht je nu willen roepen, “ja maar als ik goed plan, had ik geweten dat ik niet met de auto moet gaan”, dat klopt. Maar daarom is ook de output van het proces ‘plannen van de reis’, een reisplanning. En die reisplanning is input voor het proces ‘keuze vervoersmiddel’.

Super omslachtig

Het lijkt super omslachtig om een proces op deze manier te bekijken. Immers, dit voorbeeld is zo simpel dat we heel veel processtappen als het ware in elkaar kunnen schuiven. We hoeven dan ook niet het proces ‘plannen van de reis’ en ‘keuze vervoersmiddel’ uit elkaar te trekken en al helemaal niet apart te beschrijven. Toch?

Als een meer dan ervaren procesbeschrijver ben ik dat roerend met je eens. Je hoeft het proces zo niet te beschrijven in de eindvorm, maar je moet het wel zo bekijken tijdens je analyse.

Want door het ogenschijnlijk makkelijk maken van het proces door stappen in elkaar te schuiven, wordt de valkuil om werkinstructies in plaats van het proces te beschrijven alleen maar groter. Met als gevolg: een onjuiste -of veel te ingewikkelde- procesbeschrijving.

Wanneer je deze logica snapt, is het tijd voor GBV tip nummer 1.

GBV tip nummer 1

Beschrijf van een proces eerst alle processtappen en focus je per processtap op:

1. Wat gaat er in.
2. Wat moet er uit komen.
3. Laat de throughput (verwerking) voorlopig met rust -want dat is een werkinstructie.

Benieuwd naar deel 2? In deel 2 neem ik je mee in hoe je het makkelijkste alle noodzakelijke procesinformatie in kaart brengt, zonder dat je gehinderd wordt door alle informatie die bij de werkinstructies hoort.

Mocht je nu alvast een vraag hebben over procesbeschrijvingen, neem gerust contact op.