Proces. Ik ben er wel klaar mee.

Tenminste, met het woord. Want het betekent niets. Niets zonder context.

Overal lees je ‘het proces dit, het proces dat’. Maar zonder context is het woord ‘proces’ een nietszeggend woord van 6 letters. Ik snap dan ook heel goed dat mensen generiek procesgeouwehoer een keer zat zijn en komen met uitspraken over ‘het moet over de inhoud gaan, niet over het proces’

Want hebben we het over…

– De dagelijkse uitvoering van een proces?
– Het ontwerp van een proces?
– Dat leuke plaatje van blokjes, pijltjes en wybertjes?
– De afhandeling van bestelling 1258?
– Dat checklistje wat Freek van Financiën gebruikt om facturen te controleren?
– Die microflow in het lowcode application platform?
– De rechtszaak tegen Emiel. K.
– Een systeemproces op de Windows-server?

Bovenstaande punten hebben allemaal wel iets met ‘proces’ te maken, maar betekenen allemaal wat anders.

Je kunt namelijk zoveel met processen doen. In mijn ouwehoersels bedoel ik meestal bedrijfsprocessen; alles wat wordt gedaan en nodig is om een zinvol resultaat op te leveren.

Misschien nog wel wat vaag, dus heb ooit eens geprobeerd het een en ander uit te leggen in mijn youtube-knustelwerkje ‘Wat is Business Process Management?’

Zullen we het dan nu niet meer over ‘het proces’ hebben, maar echt benoemen welk aspect van Business Process Management we bedoelen?

Ar Pie (N)ee?

Regelmatig discussieer ik over de inzet en noodzaak van RPA.  RPA? Wat is dat ook alweer? Ik typte er ooit dit stukje over: https://procesje.nl/wordpress/?p=419

Als Processengek heb ik een haat-liefde verhouding met RPA. Ik zoek liever naar de kernoorzaak van waarom een proces niet presteert, in plaats van de symptomen te bestrijden.

Vandaar dat RPA ook wel eens ‘paving the cowpaths ‘ of ‘ductape automatisering’ wordt genoemd’.

Maar, ik moet ook eerlijk zijn. Door het toepassen RPA verbeter je wel gewoon keihard de prestaties van een proces; het zelfde resultaat kan goedkoper of sneller geleverd worden. Daaruit blijkt weer dat je onderscheid moet maken tussen procesresultaten en doelen die je daar aan stelt: https://procesje.nl/wordpress/?p=340

Een ander prettige bijkomstigheid van RPA (ten opzichte van het daadwerkelijk oplossen van kernoorzaken van een probleem) is het gemak waarmee een business case gemaakt kan worden.

Daarom even terug naar ‘paving the cowpaths’. Stel dat je nu je spulletjes van A naar B vervoert over een zandpad. Dan kun je lang discussiëren over het feit dat dat zandpad niet de slimste weg is van A naar B, maar je kunt het zandpad ook asfalteren. En als je dan, in plaats van 8 keer heen en weer rijden met een tractor, je spulletjes in 1 keer met een vrachtwagen naar B kunt krijgen, dan vermoed ik al snel positieve ROI rapportjes op het bureau van de CEO.

En voordat je concurrent een slimmere asfaltweg van A naar B heeft aangelegd (Lees ; een herontworpen proces met hippe nieuw IT hulpmiddelen heeft geïmplementeerd), dat zal nog wel even duren.

Verder niks te zeuren over RPA dan, Emiel? Tuurlijk wel. Namelijk over die P in RPA. Het komt natuurlijk maar weinig voor dat je een heel proces robotiseert, Meestal delen ervan. Maar ‘Robotic Part of A Process Automation’ ; dat bekt niet echt lekker in een folder of op een Powerpoint slide.

Ik wens u presterende processen!

Waarom wonen in een caravan zo gek nog niet is

Onlangs twitterde ik: ‘#Agile. Da’s toch voor 30.000 € in 4 weken een huis uit de grond stampen en dan nog 6 jaar elke maand voor 20.000 € vertimmeren tot het echt af is?’

Enigszins cynisch en met een knipoog, maar iets wat wel regelmatig een lastig ding is. Lastig om de juiste weg in te vinden in de tijd van ‘Als je niet aan agile doet, besta je over 2 jaar niet meer’.

Ik blijf even bij de huis analogie. Stel dat het huis in de eerste ronde wel goed genoeg was; mooi toch? Snel resultaat voor weinig geld.

Maar da’s misschien een illusie. Dus er zullen misschien nog wat verbouwinkjes volgen. En zolang dat niet-structurele dingen zijn als binnenwandje (ver)plaatsen, extra dakraam of misschien zelfs wel keuken op andere plaats, dan is dat nog niet zo schokkend en kostbaar.

En wellicht een goede aanpak, want tijdens het wonen kom je achter dingen die je niet van te voren had kunnen bedenken. Niet kunnen bedenken door er een jaar in theorie en op tekeningen over na te denken in allerlei brainstormgroepjes. Een SBS6 interieurstilist zou zeggen dat je het echt moet ‘voelen’.

Vervelender wordt het als je er tijdens het wonen achter komt dat er fundamenteel foute beslissingen zijn genomen. De tuin moest toch op het zuiden. Het huis moest toch groter. Een aardwarmtepomp was toch beter geweest dan zo’n goedkope aliexpress luchtwarmtepomp. Of nog lastiger; het huis staat op de verkeerde plek.

Tja, dan zijn dat ingrijpende dingen. En wat duurder om te fixen.

Dat is ook waarom ik tijdens procesontwerp (en daarvan afgeleid mogelijk systeemontwerp) liever niet zou willen beginnen zonder helder inzicht in deze fundamenten. Geen gemiep over schermpjes, knopjes, lettertypes, toon van correspondentie, benodigde bureaustoelen, etc.

Nee, liever eerst helderheid krijgen over het waarom? van het proces. o.a. Het resultaat, de na te streven doelen, de benodigde data en de transformatie(s) van deze data.

En ja, dat kost tijd. En dat wordt je misschien weer niet gegund door aandeelhouders die een artikeltje over agile hebben gelezen en snel resultaat willen zien. Maar je vervolgens wel afrekenen op het feit dat ‘de bewoners toch niet zo blij zijn’ en er nog een smak geld en tijd achteraan moet om het echt naar wens af te ronden.

Ik ben niet zo’n zweverig type, maar het Waarom? van een proces is iets wat ik altijd helder wil hebben. Waarom moet dit proces uitgevoerd worden? Zit er echt iemand op te wachten?

Over dat huis gesproken; waarom wil iemand eigenlijk een huis?

Nomaden hebben het wat dat betreft nog niet zo gek bekeken. Het (mobiele) huis is geen doel, maar het middel. Het middel om veilig op een plek te zijn waar ze ook nog eens in hun levensonderhoud kunnen voorzien.. En daar heb je juist helemaal geen fundamenten voor nodig. Maar vooral een agile levenshouding. Nomaden doen niet agile. Die zijn het.

En nee, ik ga nu geen quote van Darwin oplepelen…

Ik wens u wendbare, maar bovenal presterende processen.

Generieke processen. Je bedoelt ‘Iets voor iemand doen’​?

Zo af en toe beland ik in een proces-projectje waar de wens bestaat om ‘generieke processen’ te ontwerpen en, hopelijk, te implementeren.

Als ik deze term hoor, dan wil ik wel eens twitteren dat ik geen idee heb wat dat zou kunnen betekenen. Hoe leuk dan om te zien dat er heftig wordt gereageerd om mij uit te leggen wat generieke processen zijn. Naar mijn mening komt men dan altijd aan met voorbeelden wat ik generieke subprocessen zou noemen. Of generieke stukjes software. Of stukjes werk die in verschillende processen hetzelfde zijn. Of shared services. Of…nou ja, in ieder geval niet iets wat ik als ‘processen’ zou betitelen.

En ik moet toegeven; ik heb er ook wel eens anders over gedacht. Diverse gemeentes heb ik geholpen om een generiek vergunningenproces te ontwerpen. Of beter gezegd; geholpen met het maken van een plaatje met blokjes en pijltjes dat geldt voor alle vergunningen.

En het mooie? Iedereen kon zich er wel in vinden. Maar je had er helemaal niks aan. ‘Aanvraag registreren’, ‘Beoordelen aanvraag’ ‘Informeren klant’; dat zou ook om het bestellen van 86 kuub beton kunnen gaan.

En ooit een burger tegengekomen die zich meldt aan de balie met de tekst ‘Goedemiddag, doe mij maar een vergunningkje’. Tuurlijk niet. Generieke processen bestaan niet,

Burgers willen geen generieke vergunning. De aanvragen zijn juist heel specifiek; ‘Ik wil een vergunning om een straatfeest te geven’ of ‘Ik wil een vergunning om een huis te bouwen’ .

Dit benadrukt wederom dat het klanten niet gaat om uw processen. Het gaat hen om wat deze processen voor hun opleveren; concrete producten of diensten die hun problemen oplossen. En da’s niet generiek. Da’s specifiek. Het resultaat maakt het proces.

Maar…euh….in al die vergunningprocessen doen we toch het checken van het ID? Is dat dan geen generiek proces? Nee, da’s een setje werkzaamheden dat voor elke vergunning aanvraag wordt uitgevoerd.

Dat maakt het nog geen proces. Althans, in mijn definitie van een proces. Een proces is naar mijn mening alles wat je doet en nodig hebt om een zinvol resultaat op te leveren. En ‘ID gecheckt’ is volgens mij niet waarom burgers bij gemeentes aankloppen,

Ook in mijn pizzeria had ik de bovenstaande discussie. De kok was van mening dat ‘Bakken pizza’ een generiek proces was. Ik vroeg hem wat het resultaat was van dat werk. ‘Een gebakken pizza’ was zijn antwoord. Nou, is dat waar klanten onze pizzeria voor betalen? Nee, ze willen die pizza thuis bezorgd hebben, netjes en warm verpakt afhalen of dampend op hun bord geserveerd krijgen.

En ja, het klopt dat ‘Bakken pizza’ gebeurt voor verschillende soorten klantwensen en is daarmee onderdeel van de 3 processen ‘Bezorgen pizza’ ‘Afhalen pizza’ of ‘Eten in het restaurant’ . Daarmee is ‘Bakken pizza’ geen proces, maar een subproces of wellicht te betitelen als Shared service. Ook zie je wel projecten waarin software wordt ontwikkeld die in meerdere processen wordt gebruikt. Heel mooi, maar da’s generieke software, geen generiek proces.

Zo, dat ben ik kwijt. En nu weten mijn twitter volgers ook weer waarom ik zo reageer op de term ‘generiek proces’. Ik vind dat dat de naam ‘proces’ niet mag hebben. Maar ja, waar zou ik me druk om maken? Klanten zijn toch niet geïnteresseerd in mijn processen. Die willen gewoon specifieke resultaten om hun problemen op te lossen. Niks generieks aan.

Processen; misschien wat stoffig en niet zo hipster, maar eigenlijk zo gek nog niet

Processen. Daar kleeft toch nog vaak een stoffig AO/IC of kwaliteitsimago aan. Het werk van de mannen in ruitjesbloesen, zeg maar. En als ik eerlijk ben, is dat ook niet zo gek in onze huidige wereld van hippe dingen als Metaverse, AI, digitalisering, robotisering, dronificering, agile en data, data, data.

Ik zit er daarom wel eens over te denken om met al mijn procesgedoe te stoppen en agile-coach, data wetenschapper, robotmanager of avatar te worden. Want, wie zit er anno 2021 nou nog op processen te wachten?

Nou, elke klant van een organisatie! Nou ja, niet persé op die processen, maar wel op de producten of diensten die door deze processen worden opgeleverd. Of nog mooier; de problemen die door de uitvoering van processen worden opgelost.

Niet zo’n gek idee dus om die processen een beetje aandacht te geven. Maar liever veel aandacht!

Want als ik mijn melancholisch ‘ik wil wat anders’ minuutje achter me heb gelaten, vraag ik me retorisch af ‘En wat digitaliseren we? Waar worden die robots gebruikt? Wat moet er agiler worden? Waar wordt al die data voor gebruikt?’

En dan kom ik toch al snel op het onvermijdelijke antwoord ‘In processen (van een organisatie)’.

Want:

  • Middels nieuwe technologieën worden (delen van) een proces gedigitaliseerd
  • (Software) robots voeren (delen van) processen uit.
  • Processen moeten zo nu en dan ook eens veranderen om in te kunnen blijven spelen op de vragen van de klant
  • Op verschillende niveaus van het uitvoeren en besturen van processen speelt data een rol

Dus wat mij betreft blijven processen de verbindende factor tussen allerlei aspecten die spelen in een organisatie. Maar dat beeld wordt niet altijd gedeeld. Vandaar dat ik in bovenstaande voorbeelden bewust een aantal keer de term ‘delen van’ heb gebruikt. Want wat me opvalt is dat het hap-snap-fratsgehalte weer lijkt toe te nemen ten koste van ‘echt’ procesmanagement.

Daarbij is een frats is voor mij iets wat op zich zelf best een goed idee lijkt, maar in de context van een proces niet altijd evenveel waarde toevoegt. In feite niets anders dan good old sub-optimalisatie of het niet sleutelen aan bottlenecks vanuit een ToC gedachte.

Beetje als een zuinigere cv ketel kopen, maar niets aan de isolatie van je huis doen; het zal vast winst opleveren, maar een bredere (proces)kijk had misschien geleid tot andere (en beter renderende) verbeterbeslissingen.

En doordat technologische ontwikkelingen ‘zo snel gaan’ en ook steeds makkelijker te implementeren zijn (low code, cloud), zie ik hierin een toename. Elke week is er wel weer iets nieuws wat de schijn wekt een proces te kunnen verbeteren. Maar vanuit een bredere proceskijk misschien niet altijd nodig.

Ik zou bovenstaande heel gewichtig ‘onder architectuur’ kunnen noemen, maar wat mij betreft is het gewoon beseffen dat het processen zijn die resultaten voor klanten opleveren. En dat die processen een ‘verbinding’ zijn tussen allerlei aspecten in en van een organisatie (werkstroom, mensen, data, hulpmiddelen, systemen).

En als een verbetervoorstel dat proces beter (wel eerst even vaststellen wat ‘beter’ is) maakt, prima toch? Dan beloof ik dat ik het geen frats meer noem.

Processen. Misschien wat stoffig en niet zo hipster, maar eigenlijk zo gek dus nog niet.

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?

Komt een proces bij de pedicure…

043Afgelopen vakantie was ik met mijn zoontje lekker zandkastelen aan het bouwen, toen ik op een gegeven moment naar beneden keek. Onderaan mijn spillebeentjes zag ik daar maar liefst twee voeten in maat 46 hun best doen om te verbranden in de zon. Nu heb ik die voeten al jaren, dus aan dat uitzicht was ik wel gewend.

Maar plots werd mijn aandacht getrokken door mijn teennagels. Teennagels die ik al mijn hele leven heb.

Toch heb ik er nooit bewust bij stil gestaan. Gewoon omdat ik er nooit problemen mee heb. En zo kwam ik op dit Procesje.

Want ik heb inderdaad geluk; ik knip af en toe mijn teennagels als ik gedouched heb. En als ik ze sporadisch een keer voel prikken in mijn schoenen, dan werk ik ze een klein beetje bij.

Ik ken echter ook horrorverhalen. Ingegroeide teennagels, kalknagels of zelfs nagels die onverdoofd verwijderd moesten worden. Brrr.  Leuk Emiel, maar wat heeft deze pedicure-praat met processen te maken?

Best veel eigenlijk, want:

  • Processen ontstaan tijdens de geboorte van een product of dienst
  • Processen groeien daarna vaak lekker door. Ongezien.
  • Procesbewustzijn verdwijnt daarom vaak weer
  • Processen krijgen pas weer aandacht als ze “zeer doen”
  • Het kan daarom verstandig zijn om regelmatig de conditie van uw processen te checken

 

De geboorte van een proces

Zoals wij onze nagels krijgen bij onze geboorte, ontstaat een proces bij de lancering van een dienst of product. Een proces is immers het middel om een product of dienst te leveren. Om daarmee hopelijk wel een probleem van een klant op te lossen.

Bij de eerste inrichting van een proces moet veel geregeld worden. Denk aan het beantwoorden van vragen als:

  • Wat moet er allemaal gebeuren (werkstroom)?
  • Wie kan dat doen?
  • Welke grondstoffen zijn daarvoor nodig?
  • Welke informatie is daarvoor nodig?
  • Welke hulpmiddelen moeten we aanschaffen?
  • Aan wat voor eisen van derde partijen moeten we voldoen?

En dan is het aan de slag. En dat is natuurlijk wel het belangrijkste. Zolang processen niet worden uitgevoerd, staat de klant met lege handen.

 

Processen groeien door

Na een eerste proceslancering lijkt de aandacht daarna vaak een beetje weg te zakken.

Het werk wordt gedaan en wanneer iets niet lekker loopt worden er vast ook wel wat aanpassingen gedaan.  Mensen gaan weg, nieuwe collega’s komen. Misschien worden er wat extra velden in een formulier toegevoegd.

Kortom; in de drive om klanten te helpen, groeien diverse aspecten van een proces vaak ongezien door.

 

Het procesbewustzijn verdwijnt 

Zolang processen doorgroeien en er verder niet veel aan de hand is, merk ik vaak dat het procesbewustzijn in organisaties ook verdwijnt.

Er wordt gewoon gewerkt en mogelijk zijn de mensen die hebben meegewerkt aan de geboorte van het proces niet eens meer betrokken. Zo gaat het in veel organisaties.

Is dat erg? Zolang het goed gaat, tja wie ben ik dan om te zeggen dat je wel procesbewust moet zijn?

 

Maar er kan natuurlijk wel wat misgaan

Plots beginnen klanten te klagen. Plots is de markt meer geïnteresseerd in producten en diensten van concurrenten. Medewerkers melden zich ziek. De inspectie staat op de stoep. De auditor doet plots moeilijk over certificaatverlenging.  Aandeelhouders zijn niet meer zo blij met de resultaten.

Kortom; het begint zeer te doen. Wat nu? Reorganiseren? Mensen ontslaan? Bezuinigingsmaatregelen? Paniek!

Verbazingwekkend zie ik het bovenstaande nog regelmatig gebeuren. Zou het daarom niet verstandiger te zijn uw processen eens regelmatig uit de schoenen te halen en bij te vijlen als het nog niet heel erg zeer doet?

 

Processen zo nu en dan checken

Wellicht preek ik voor eigen parochie; maar ik denk dat regelmatige proces-checks bovenstaande paniekacties kunnen voorkomen.

Zoals ik in mijn youtube serie “Wat is business process management?” heb omschreven kan het checken van processen (en zo nodig aanpassen) op meerdere niveaus plaatsvinden:

  1. Op strategisch niveau, waarbij de zinvolheid van het proces (dus eigenlijk product of dienst) wordt geëvalueerd
  2. Op procesontwerp niveau, waarbij gecheckt wordt of het proces presteert zoals het ooit bedacht is
  3. Op zaakbesturing niveau waarbij de voortgang van alle onderhanden zaken gemonitord wordt
  4. Op zaak niveau, waarbij de voortgang van een individuele zaak bijgehouden wordt

 

Alle niveaus geven rust

Het inrichten van al deze niveaus van “proces-checks” is niet makkelijk en soms zie ik alleen niveau 2 gebeuren.

Dat vind ik jammer, want dan bestaat de kans dat je zinloze processen zit te verbeteren en dat je achter de feiten aanloopt omdat je pas gaat verbeteren als er al veel kwaad geschied is.

Maar, met elkaar vormen al deze niveaus wat ik “managen met processen” zou willen noemen.

In mijn ervaring geeft het rust:

  • De geruststelling voor een klant dat haar/zijn individuele zaak aandacht krijgt
  • De geruststelling dat er genoeg flexibilteit is om in te grijpen in de operationele besturing van alle onderhanden zaken
  • De geruststelling dat er niet onnodig wordt doorgemodderd wanneer het proceontwerp aangepast zou moeten worden
  • De geruststelling dat processen zinvolle producten of diensten leveren

Ik heb zelfs ooit overwogen om mijn aanpak “Rust in Processen” te noemen. Maar met de afkorting werd ik niet echt serieus genomen door mijn Engels sprekende lezers.

Ik wens u presterende processen. En pijnloze teennagels.

 

 

 

 

 

Processen? Daar krijg ik hoofdpijn van.

040

Procesgekken als ik vinden het fantastisch wanneer organisaties het ultieme procesmanagement zouden invoeren waarbij:

  • medewerkers weten wat er van elk proces verwacht wordt,
  • medewerkers inzicht hebben in alle lopende zaken,
  • medewerkers weten wat een presterend proces maakt en kunnen ingrijpen en aanpassen wanneer het niet loopt zoals beloofd.

Vanzelfsprekend is er ook allerlei geavanceerde software op de markt om al deze aspecten van procesmanagement te ondersteunen.

Kortom; mensen de kans geven een zinvolle bijdrage te leveren aan presterende processen. Goed begrijpen wat een proces maakt en oplossingen invoeren die daadwerkelijk bijdragen aan een beter presterend proces.

Om dit beeld een illusie te noemen, gaat wellicht wat ver, maar toch zie je vaker de houding: ‘Procesmanagement? Best leuk allemaal, maar ik heb nu even een nijpend probleem dat opgelost moet worden’.

Net als hoofdpijn.

Komt die hoofdpijn door een kater? Hup aspirine erin en volgende keer een uurtje eerder op de keet aan.

Heeft die hoofdpijn een structurele oorzaak, dan is een aspirine slechts symptoombestrijding. En hoewel het de klachten (even) wegneemt, blijven de oorzaken van het niet presterende proces in stand. Echt zoeken naar de oorzaak (en oplossing!) is dan een betere aanpak.

Maar wel lastiger, tijdrovender en (op korte termijn) duurder.

En in crisistijd is het soms is gewoon noodzakelijk om brandjes te blussen.

Toch zie je organisaties waar geldt ‘voor elke probleem een nieuw systeem’. Met als gevolg 812 tooltjes die allemaal iets doen ter ondersteuning van processen. Niet zelden met dezelfde functionaliteit. 4 systemen voor online betalingen, 5 workflowachtige tools, 3 BI systemen; het komt echt voor.

Een soort van medicijnkast met voor elk kwaaltje een pilletje. Met als mogelijk gevolg dat het ene medicijn weer een ander probleem veroorzaakt.

Even terug naar ingrijpen in een proces.

Zolang alle aanpassingen gebeuren met het laten presteren van het totaalproces voor ogen, tja wie ben ik dan om moeilijk te doen.

Maar als het continu leidt tot klassieke suboptimalisatie, dan kom ik toch even langs met m’n scheikundedoos. Om eerst eens goed te kijken naar de oorzaken van slecht presterende processen en dan het juiste medicijn te ontwikkelen.

Hoewel, medicijn?  Een andere levensstijl is meestal een, om maar even een hipsterterm te gebruiken, duurzamere oplossing.

Gezonde processen gewenst!

 

 

Effectiviteit, Productiviteit en Efficiëntie; een meer met minder discussie?

Je zou het misschien niet verwachten wanneer organisaties al besloten hebben om hun processen te verbeteren, maar soms ontstaat pas dan een discussie over het verschil tussen effectiviteit, efficiëntie en productiviteit.

Ik leg mijn interpretatie van deze termen altijd uit aan de hand van mijn groentetuintje. Misschien wel leuk om dat verhaaltje te delen.

 

Effectiviteit: Het juiste resultaat opleveren

Ik heb dus een groentetuintje. Hierin verbouw ik diverse groentes. Mijn doel is om daarmee  mijn gezinnetje 3 maanden per jaar van verse groente te voorzien.

Dat is dus mijn gewenste procesresultaat en doel: Voldoende groente voor 3 maanden per jaar.

En dat lukt. Mijn werkwijze en inzet van middelen zijn dus effectief; ik bereik het juiste resultaat.

 

Efficiëntie: Hetzelfde resultaat met minder inspanning

Efficiëntie gaat, in mijn beleving, om de hoeveel tijd, geld (of algemener: resources) die je steekt in het behalen van dat juiste proces resultaat.

Voor het gemak van dit verhaal kijk ik alleen even naar geld en tijd (daar zijn overigens de meeste dingen wel naar terug te rekenen).

De meeste tijd zit in het begin en eind bij het planten en oogsten. Maar gemiddeld  besteed ik zo’n 12 minuten per dag aan m’n tuintje.

Aan zaadjes/stekjes ben ik zo’n 20 euro per seizoen kwijt. Water haal ik uit de vijver aan de overkant, dus dat kost me niets. Aan mest besteed ik 25 euro.

Voor mij is efficiëntie “Hetzelfde resultaat behalen met minder resources”.  Uitgangspunt blijft dus dat ik die 3 maanden groente oplever.

Maar wanneer ik daar bijvoorbeeld maar 11 minuten per dag aan hoef te besteden, dan is mijn efficiëntie verhoogd.

Of stel dat ik mest goedkoper kan krijgen. Dan kan ik met minder geld hetzelfde resultaat bereiken. Efficiëntie verhoogd.

Efficiëntie: Dezelfde hoeveelheid groente met minder tijd of geld.

 

Productiviteit: Meer resultaat met dezelfde inspanning

Productiviteit betekent voor mij meer van het juiste uit dezelfde resources halen. 

Dat betekent in dit geval dat ik nog steeds 12 minuten per dag besteed. En nog steeds 45 euro besteed aan zaadjes en mest.

Maar stel dat het betere mest is, of dat ik een ander ras zaadjes heb gekocht. Of misschien dat ik mijn techniek van water geven heb verbeterd.

(of dat ik gewoon geluk heb met het weer)

Dan kan het zo maar zijn dat ik plots voor 3 maand en 1 week groente kan opleveren., Met dezelfde tijdsbesteding en kosten heb ik dan een beter resultaat bereikt. Hierbij ga ik er wel vanuit dat die ene week extra groente een zinvol resultaat is.

Productiviteit; meer groente voor hetzelfde geld en tijd.

 

Meer met minder?

Meer met minder. Die term hoor je vaak. Dat zou dus betekenen dat ik zowel efficiënter en productiever wordt. Zou dat kunnen?  Vast wel.

Ik verzin maar wat:

  • Door een verbeterde spittechniek houdt de grond meer water vast, groeien de wortels beter en wordt de opbrengst groter
  • Het lukt me om zaadjes te oogsten die ik het volgend seizoen weer kan planten
  • Mest heb ik goedkoper kunnen krijgen

En zo heb ik uiteindelijk meer groente, tegen lagere kosten. Hoe zou je dat noemen Produciënter?

Daarnaast heeft het weer natuurlijk ook een grote invloed. Je kunt geluk, maar ook pech hebben. Misschien ga ik wel investeren in een kas. Over investeren gesproken:

 

Weinig dingen komen voor niets; return on investment

Soms heb ik geluk en krijg ik een gratis verbetering van efficiëntie of productiviteit. Bijvoorbeeld als de mest in de aanbieding is of als het weer gunstig is.

Maar niet zelden moet je ook investeren voor verbetering.

Wanneer ik minder tijd wil besteden, zal dat soms kunnen door slimmer te werken. Maar meestal gaat dat gepaard met investeren in zaken als machines of andere hulpmiddelen.

Dan is het verstandig om te kijken naar de Return on Investment.

Zo loop ik dus voor water naar de vijver aan de overkant. Ik gebruik de grootst mogelijke emmers, maar ik kwam erachter dat dat best veel tijd kost. Gemiddeld zo’n 6 minuten per dag (op regenachtige dagen loop ik niet en op droge dagen vaker). Maar die 6 minuten is wel de helft van de totale bewerkingstijd! Zou ik daar iets aan kunnen doen?

Zo zag ik op marktplaats een goede kwaliteit dompelpomp met voldoende lengte aan slang. Ik kon deze voor 80 euro overnemen. Ik heb even geoefend met het uitrollen en opruimen. Gemiddeld kan ik daar zo’n 2 minuten per dag mee besparen.

In principe is mijn vrije tijd gratis, maar stel dat ik als zzp’er netto 30 euro per uur kan pakken, dan bespaar ik dus 1 Euro per dag.

Dat betekent dat ik de dompelpomp er in 80 dagen uit heb. Dat is iets minder dan de 3 maanden die ik elk seizoen aan ‘n tuintje besteed. Binnen 1 seizoen heb ik deze investering dus terug verdiend.

En ik ga ervan uit dat de pomp wel wat meer seizoenen mee gaat. Wat zou u doen?

(getallen in dit verhaaltje zijn fictief. Om makkelijk te rekenen)