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

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?

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!