U kent vast wel deze beroemde uitspraak van Abraham Lincoln: ‘Als ik zes uur had om een boom te kappen, zou ik de eerste vier uur besteden aan het slijpen van mijn bijl’.
De essentie is het efficiënt inzetten van hulpmiddelen. Niet zes uur als een dolle met een botte bijl op die boom staan rossen, maar door een scherpe bijl, met minder inspanning (ervan uitgaande dat een bijl slijpen minder energie kost dan hakken) die boom omkrijgen.
Efficiënt werken; ik hoor het regelmatig als doel. En als reactie op bovenstaande quote hoor ik dan vaak stoere verbetertaal als: ‘Wat als de bijl na een uur al scherp is, dan ben ik in totaal maar drie uur bezig’, of: ‘Een bijl? Ik heb een kettingzaag!’
Wauw, wat een efficiëntie. Maar efficiëntie is geen doel. Efficiëntie een middel. Een middel om je procesresultaat sneller/goedkoper te bereiken. Dus de vraag die zulke quotes bij mij oproepen is: ‘Waarom moet die boom eigenlijk om?’
Te snel, te diep
Zoals u weet, doe ik iets met processen, dus als ik bovenstaande vraag vertaal naar processentaal, komt dat neer op vragen (of eigenlijk de antwoorden) die ik dikwijls mis in ‘procesprojecten’:
- Hebben we het over zinvolle processen?
- Waarom heeft dit proces aandacht nodig ?
Want ik zie nog best vaak dat in een organisatie het idee is opgevat dat het ‘beter moet’ en vol energie stort men zich op de inhoud. Verbeterclubjes die processen in kaart brengen, hele afdelingen die op Lean training gaan. Leveranciers die worden uitgenodigd om hun aanbod voor procesautomatisering te laten zien. Een enkeling waagt zich zelfs aan process mining. U begrijpt het al: het walhalla voor een procesnerd als ik.
Bovenstaande zaken zijn wellicht zinvol, maar gaan soms te vroeg te diep. Hierdoor ontstaat het gevaar dat, met goede bedoelingen, deze projecten uiteindelijk niet over processen gaan (het niveau waarop je zou willen sturen), maar over stukjes proces of over te veel processen ineens.
Procesknutsel magnetisme
En toch is dat ook niet zo gek. Veel mensen willen gewoon lekker aan de slag met wat ze leuk vinden. Voor de één is dat processen in kaart brengen, voor de ander is dat automatiseren met behulp van een BPMS, en voor weer een ander is dat lekker allerlei data analyseren.
Ach en zo’n ramp is dat nou ook weer niet als het direct bijdraagt aan het enige wat telt voor een proces: de uitvoering. Helaas blijken het toch vaak zaken ‘rondom’ het proces te zijn.
Het lijkt vaak wel een soort van natuurlijk magnetisme om heel snel de ‘oplossingen’ in te willen duiken zonder een helder beeld van wat het op te lossen probleem is. In dit geval dus: welk proces heeft welk probleem?
Dus als ik in een project de simpele vraag stel: ‘Jullie hebben toch wel een helder beeld van jullie processen?’, is vaak het antwoord: ‘Doe niet zo gek Emiel, tuurlijk hebben wij dat!’.
Dat zou mooi zijn, maar wanneer ik dan de individuele antwoorden op de vraag ‘over welk(e) proces(sen) hebben we het’ op een muur plak, blijkt dat vaak toch niet helemaal waar te zijn.
Ik merk dus vaak dat achter de stap ‘procesidentificatie’ al snel een vinkje wordt gezet.
Een goed proces begint aan het eind
Is dat erg, geen helder beeld van een proces, voordat er aan gesleuteld wordt?
Dat mag iedereen zelf weten, maar ik vind het altijd zonde als er met veel enthousiasme aan good old suboptimalisatie wordt gewerkt.
In mijn trainingen gebruik ik vaak pizzeria voorbeelden.
Zo was er eens een keuken die een budget had om te verbeteren. Ze hadden gehoord van ‘doelen stellen’, dus ze wilden van ‘10 pizza’s per uur bakken’ naar ‘30 pizza’s per uur bakken’.
Na lang brainstormen werd een nieuwe ‘Internet of Things Turbo Oven’ aangeschaft, die inderdaad bovenstaand doel wist te bewerkstelligen. Super!! Bier en Pizza!
Wel jammer dat ze het bezorgteam niet hadden betrokken. Zij hadden nog steeds maar twee brommers en wisten zich geen raad met de stapel pizza’s die al koud waren voordat ze werden bezorgd.
Simpel voorbeeld natuurlijk,maar altijd goed bruikbaar om duidelijk te maken dat een klant niet op een ‘gebakken pizza die op de balie ligt’ zit te wachten.
In dit voorbeeld is het gewenste procesresultaat een bezorgde pizza. Hier kun je vervolgens doelen aan koppelen wat betreft tijd, smaak of prijs. Ik maak dus onderscheid tussen procesresultaat en procesdoel. Iets voor een volgend blog.
Kortom: maak het procesultaat kraakhelder voordat u met het proces zelf aan de slag gaat. Dat hoeft niet een Sinekkig ‘why’ te zijn, maar moet wel een helder beeld geven van ‘waar we het over hebben en waarom we er aan werken’. Het voorkomt veel verwarring en teleurstelllng wanneer er dieper in de processen wordt gedoken.
Want efficiënt worden in zinloze dingen – dat kan ik zelfs.
Emiel Kelly is officieel trainer/coach Business Process Management, maar deelt z’n belevenissen en mening al enkele jaren als Procesje. Twitter: @Procesje
