Als voormalig BPM personality of the year, krijg ik dagelijks tientallen, zo niet honderden, vragen met betrekking tot (bedrijfs)procesmanagement.

Zo mailde Ard uit Amersfoort  ‘Ik ben business analist bij een woningcorporatie en daar heeft het management tijdens de kerstborrel aangegeven dat ze processen heel erg belangrijk vinden. Daar sta ik helemaal achter. Echter, in hun presentaties gebruiken ze de term ‘keten’ en ‘proces’ te pas en te onpas door elkaar. Ik vind dat verwarrend. Ik vraag me af hoe u, als autoriteit op het gebied van processen, tegen deze termen aankijkt.‘

Afgezien van dat BPM personality ding, onzin en dikdoenerij natuurlijk 😉 Maar de vraag over het verschil tussen proces en keten is niet zo’n vreemde. Ik hoor wel vaker de verwarring die Ard schetst.

Keten en proces; sturen op 2 verschillende doelen

Naar mijn mening zijn een keten en een proces twee heel verschillende dingen.

En dat verschil zit ‘m in het aspect waar op gestuurd wordt.  In een proces wordt gestuurd op het goed afronden van een casus door het leveren van een product of dienst.  In een keten wordt gestuurd op de beschikbaarheid van grondstoffen en/of informatie ten behoeve van andere processen in de keten.

Heuh, wat? Ik zal het proberen uit te leggen. En omdat ik al weer meer dan 5 jaar met veel plezier (mijn baas leest mee, hier) bij een transportverzekeraar werk, hanteer ik een voorbeeld uit die branche.

Aan ‘de voorkant’ verkopen wij verzekeringen (mooier gezegd; dekken wij risico’s af en vragen daar een premie voor)  aan ‘de achterkant’ keren wij uit (of bieden een natura oplossing) in geval van geleden schade door verzekerde en/of tegenpartij.

Dit zijn 2 processen

Naar mijn mening gaat het hier om 2 processen;

1. ‘Afsluiten verzekering’ met als resultaat een polis die de gewenste risico’s afdekt
2. ‘Afhandelen Schadeclaim’ met als gewenst resultaat een vergoede schade

Waarom 2 processen?  Hiervoor zie ik de volgende drie redenen:

Reden 1: Geen 1 op 1 relatie

Het feit dat iemand een polis afsluit wil niet zeggen dat hij ook schades gaat claimen. Er is dus niet een zogenaamde 1:1 relatie tussen het polis- en schade proces.  1 polis kan gevolgd worden door 5 schadeclaims, door 20 of misschien wel 0.

Reden 2: Niet hetzelfde resultaat

Een proces bestaat om een resultaat te leveren. Een resultaat dat waarde heeft voor een klant. In dit geval zijn dat 2 heel verschillende resultaten. In het ene geval wil de klant verzekerd zijn (omdat hij het risico zelf te groot vindt om te dragen of omdat het moet van de wet).

In het andere geval wil de klant dat zijn (veroorzaakte) schade wordt opgelost. 2 verschillende resultaten, dus in mijn visie ook 2 verschillende processen. 2 processen die qua besturing ook verschillend ingericht kunnen zijn.

Reden 3: Frequentie van uitvoeren

Een derde reden om dit als 2 processen te zien is het feit dat beide in een heel andere frequentie plaatsvinden. Het afsluiten va een polis gebeurt eenmalig. Of als je prolongeren mee rekent, één keer per jaar. Het afhandelen van een schadeclaim kent qua frequentie veel meer variëteit.

Processen: Sturen op resultaat

Door uitvoering van een proces stuur je dus op het bereiken van een resultaat; het ‘ding’ waar de klant op zit te wachten. Aan dat resultaat kunnen ook nog doelstellingen gekoppeld worden. Die zijn afhankelijk van je strategie en kunnen doelen zijn op het gebied van tijd, geld of kwaliteit.

Bijvoorbeeld voor het proces ‘Afsluiten verzekering’

• Eerste voorstel polis binnen 2 werkdagen bij klant
• Jaarpremie nooit hoger dan 10% verzekerde som
• Polis pas afgesloten bij geen uitval op sanctielijst
• Polis volledig digitaal

Dit zijn zo maar wat doelen, maar de kern is dat het proces dusdanig wordt ingericht en bestuurd dat het beloofde resultaat en doel geleverd kunnen worden.

2 processen, dus. En ja, deze processen hebben met elkaar te maken. En dat komt omdat ze samenwerken in een keten.

Processen vormen samen een keten

Omdat het ene proces het andere kan opvolgen, hangen deze samen in wat ik een keten noem. Die heb ik hieronder in een eenvoudig plaatje weergegeven.

Dit plaatje is inderdaad wel heel eenvoudig. Te eenvoudig zelfs, omdat je niet goed ziet dat beide processen een andere trigger en resultaat hebben.  Dat heb ik in onderstaand plaatje toegevoegd.

Dit maakt al wat duidelijker dat het hier 2 processen in een keten betreft.  Alleen staan ze nog een beetje los.

En ondanks dat het 2 processen zin, zijn ze wel degelijk verbonden.  Ze zijn verbonden, zoals eerder genoemd,  door grondstoffen of data.

Want om een schadeclaim te kunnen behandelen is er polis informatie nodig. Om te kunnen bepalen of de schade gedekt is, wat het maximaal verzekerde bedrag is, etc. 

Dat betekent dat in het proces ‘Afhandelen schadeclaim’ de output (polisdata) van het proces ‘Afsluiten verzekering’ benodigd is.

In de praktijk zullen bovenstaande processen ondersteund worden met software, waarbij in bovenstaand geval waarschijnlijk een database met polis-informatie gequeried zal worden.

Ketens; processen verbonden door informatie

Processen in een keten zijn dus aan elkaar verbonden doordat ze informatie van elkaar nodig hebben of leveren. De output van het ene proces is de input van een ander proces.  Om de hele keten van processen goed te laten werken moet je dus sturen op de beschikbaarheid van informatie.

En zo kan ik doorgaan met het uitbreiden van de keten. Zo is er namelijk ook het proces ‘prolongeren. In dit proces is, ten behoeve van premiebepaling, informatie nodig over hoe vaak een klant aanspraak heeft moeten maken op zijn verzekering.

Dus stel dat in een jaar het proces ‘Afhandelen schadeclaim’ 5 keer is uitgevoerd voor een bepaalde polis, dan is (naast het resultaat voor de klant) een andere output van dit proces een ‘vastgelegde schade historie’.

En deze data is weer input voor ‘prolongeren’; een ander proces in de verzekeringsketen.

Sturen op informatiebeschikbaarheid

In een keten van processen gaat het er dus om dat processen toegang hebben tot de informatie die door andere processen wordt opgeleverd.  Dat houdt dus in dat je goed moet kijken of de inputs en outputs van de verschillende processen op elkaar aansluiten.  In ‘administratieve’ processen zal dat veelal gaan om de beschikbaarheid data. In fysieke processen om de beschikbaarheid grondstoffen.

Proces en Keten; twee verschillende dingen, toch met elkaar verbonden.

Beste Ard, kun je hier iets mee op de volgende kerstborrel?

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?

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!

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.

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.

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

 

 

 

 

 

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!

 

 

In mijn 2016 jaaroverzicht gaf ik aan in 2016 wat te willen experimenteren met video. Daarvan hier het eerste resultaat.

 

 

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)

 

 

2016. Bijna voorbij. En dan is het wel zo hip dat je even terugblikt.

Ondanks dat Procesje.nl slechts een hobby-projectje is, ben ik verbaasd en bovenal dankbaar dat ik met al m’n onzin toch nog aardig wat leuke dingen heb mogen doen in het afgelopen jaar.

In het laatste blog van dit jaar een (niet chronologische en vast niet complete) opsomming.

Blogger voor Sigma Online

Dit jaar heb ik 6 keer een verhaaltje mogen typen voor het platform van Sigma online. Soms over procesmanagement vs kwaliteit, de andere keer wat meer persoonlijk.

Leuk om te doen en ook volgend jaar ben ik weer van de partij.

Panel op BPM congres in Portugal

Ook werd ik gevraagd om te spreken op een BPM congres in Portugal. Mijn eerste gedachte was “wat heb ik daar nou toe te voegen. Ik deel slechts mijn verwondering en ervaringen in BPM land. Anderen weten veel meer dan ik”.

Uiteindelijk ben ik toch gegaan en heb de paneldiscussie geleid over de zin en onzin van Digitale Transformatie. Die discussie hadden de panelleden ook best zonder mijn inbreng kunnen voeren. Toch was het een leuke ervaring. Met name omdat ik mensen heb ontmoet die ik normaal alleen online spreek. Vanzelfsprekend was het ook gaaf om Lissabon te zien.

Bijwonen Process Model canvas workshop

Na wat discussies online, heb ik dit jaar ook een workshop Process Model Canvas van Marco Bijl mogen bijwonen. Hiervan heb ik een verslag geschreven.

Reaguurder op BPM.com 

Al enkele jaren discussieer ik mee op het forum van BPM.com. Soms erger ik me wel eens aan het “alles automatiseren” sfeertje dat daar heerst. Ik vraag me dan af of ik met mijn stijl van reageren wel moet doorgaan.  Maar voor het eerst sinds jaren merkte ik dit jaar dat ook anderen er wat luchtiger instonden. Niemand zal immers tijdens zijn uitvaart herinnerd worden als “Hij was zo goed in processen automatiseren”.

1 April 

Ik vind procesmanagement zo leuk omdat het alle aspecten van organiseren raakt. Hoewel sommigen dat wel denken, is het niet alleen de technologie. Maar ook o.a data, besturing en het menselijke aspect.

Met name menselijk gedrag en de invloed op processen is waar ik me steeds meer in ben gaan interesseren. Vandaar dat mijn 1 april grap van dit jaar dan ook dit “softe” aspect betrof.

Interviews met BPMtips.com

BPMtips.com van Zbigniew Misiak is een nog erger uit de hand gelopen hobbby dan Procesje.nl. Daarom werk ik daar graag aan mee. Dat heb ik dit jaar 2 keer gedaan. De eerste keer met een interview zonder beeld, en de 2e keer met beeld als onderdeel van de BPM Value Summit.

Bezoek jaarcongres procesmanagement

Op 17 oktober heb ik het jaarcongres procesmanagement bezocht. In principe om Marco Bijl te helpen met zijn Process Model Canvas Workshop. Maar natuurlijk heb ik ook alle kansen aangegrepen om nieuwe dingen te leren.

Podcast met Kissflow

Kissflow is een leverancier van Workflow software, maar de manier waarop ze dingen brengen vind ik wel grappig. Hun marketing meneer vroeg of ik een soort jaar-afsluit-podcast willde opnemen, samen met Sandy Kemsley. Ook hier dacht ik weer “Waarom ik? Ik typ alleen maar quasi lollige stukjes over processen”.  Desondanks toch gedaan. Altijd leuk; een beetje ouwehoeren over processen.

Het normale werk; bloggen en twitteren

Procesje.nl is natuurlijk ooit begonnen als blogje met een knipoog. Om mijn verwondering en ervaringen over mijn werk in Processenland te delen. Dit jaar heb ik toch ook wel wat verhaaltjes geschreven die verder gingen dan het traditionele 4 post-its procesje. Deze staan op mijn blog of Linkedin.

Daarnaast blijf ik twitter een leuk medium vinden. De interactie, de grapjes en de snelheid; daar houd ik van. Niet te serieus nemen dus,die tweets 😉

Niet alles ging goed

Waar gehakt wordt vallen spaanders. Dus niet alles lukt. Of soms moet je je ongelijk toegeven. Gelukkig word ik daar steeds beter in. Eigenlijk vind ik het juist wel prettig. Daardoor leer je nieuwe dingen en andere inzichten. En kom je er soms achter dat je het ook niet altijd met elkaar eens hoeft te zijn, maar toch normaal kunt doen.

Zo werd ik dit jaar door een organisatie gevraagd om gastblogger te worden. Prima. Maar tijdens het schrijven van het eerste blog, bleek de match toch minder dan verwacht. Onze stijlen liepen te veel uiteen. En een compromis zou er heel knullig uit gaan zien. In goed overleg dus besloten hier niet mee verder te gaan.

En 2017? 

Ik ben er nog niet over uit. Blijf ik actief in BPM land? Zo ja, dan wil ik met Procesje.nl wat gaan experimenteren met video. Dus niet meer alleen maar tekst, maar ook bewegende plaatjes.

Oh ja. Ik ga ook meeschrijven (lees: beetje commentaar geven) aan het nieuwe boek van Roger Tregear.

En misschien ga ik toch echt eens wat anders doen. Zoals die leraren opleiding. Of toch die gastouderopvang ombouwen tot kinderdagverblijf. Of toch dat klussenbedrijf. Of toch…

Ach, ik zie wel. Ik leef vandaag. (nog) niet morgen.

In ieder geval bedank ik jullie heel erg hartelijk voor het volgen van Procesje en wens ik jullie hele fijne feestdagen. En ik hoop dat 2017 wordt wat je er van verwacht!

De mazzel,

Emiel