Categoriearchief: Procesinrichting

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

Geplaatst op door
Antwoorden

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.

Bliep

Geplaatst op door
3

039Bewegende stukken metaal; da’s niks nieuws, natuurlijk

Zelfs Bassie en Adriaan hadden er al één; een robot.  Een in elkaar geknutseld stuk blik met een wekkerhoofd dat iets kon vasthouden en een grappig stemmetje had.

En zo kennen de meeste van ons robots (afgezien van het stemmetje en het wekkerhoofd); ronddraaiende machines met mechanische armen die bijvoorbeeld kunnen lassen of dingen oppakken.

En die worden al decennia lang toegepast in industriële processen. En onder de noemer “Industrialisering 4.0” worden deze robots nu ook steeds slimmer. Doordat ze, via sensoren en internetconnectie, data kunnen uitwisselen, beschikken de robots over veel meer informatie om hun gedrag aan te passen of andere “processen” aan te sturen.

Dus naast het fysieke werk wat ze al deden, kunnen robots, doordat ze aangestuurd worden door software steeds beter data begrijpen en verwerken.  Maar dat wist u natuurlijk al, want zelfs die robot van die clown en die acrobaat kon al telefoonboeken lezen en de data met een onwerkelijke snelheid verwerken. 

Dus robots in de industrie worden door deze “connectiviteit ” steeds slimmer en zelflerender.

En, als je de verhalen op Linkedin mag geloven, hebben robots nu zelfs hun intrede gedaan in administratieve processen . Onder de naam “Robotic Process Automation” (RPA) betreden zij de kantoren van de gegevensverwerkende organisaties.

Heeft iedereen straks een lezende wekker op z’n bureau staan? Nee, dat niet. RPA is gewoon software waarmee je data verwerkende transacties kunt automatiseren.

Maar in administratieve processen wordt toch al flink geautomatiseerd? 

Automatisering in gegevensverwerkende processen gebeurt inderdaad al vele jaren. Eerst op taakniveau door het gebruik van specialistische applicaties, later op procesniveau door gebruik te maken van workflowmanagement en BPM achtige tools.

Wat doet Robotic Process Automation dan?

RPA richt zich op data verwerking wat nu nog handmatig gaat

Ondanks dat we in gegevensverwerkende processen al veel ondersteuning zien door software, blijkt dat veel systemen nog niet altijd even goed met elkaar communiceren.

Met name de uitwisseling van data is een gebied waar nog veel te winnen valt. En RPA richt zich met name op gebieden waar het verwerken van data (opzoeken, bewerken en verwerken) nog door mensen wordt gedaan.

Handmatige verwerking, gebeurt dat nog?

Zekers. Met name in processen die een beetje tussen wal en schip zitten en waar, om van (vergeef me de uitdrukking) end-to-end te komen, diverse systemen en databronnen gebruikt moeten worden.

Neem als voorbeeld alles wat er moet gebeuren wanneer een nieuwe medewerker in dienst treedt. Waarschijnlijk zijn er diverse systemen waar de medewerker “opgevoerd” moet worden.  Het personeelsinformatieysteem, salarissysteem, intranet, mail systeem; verzin het maar.

RPA richt zich op organisaties waar dat nog veel met de hand gebeurt. Dus waar mensen al die systemen openen, data opzoeken, bewerken en weer ergens anders invoeren, zodat al deze systemen uiteindelijk over de juiste medewerker-informatie beschikken.

RPA wordt daarom ook wel eens “Draaistoel automatisering” genoemd.

Een robot in RPA speelt dit handmatige riedeltje na

Door het toepassen van RPA tools kunnen deze handmatige acties overgenomen worden door robots. Deze robots voeren dezelfde handelingen uit die eerst door mensen werden gedaan.

Om deze robots te bouwen moeten deze de handmatige taken in een ontwerpomgeving “nagespeeld” worden en “opgenomen”.

Bijvoorbeeld:

  • Open excelbestand <naam medewerker>.xls
  • Ga naar de 2e rij, eerste kolom
  • Kopieer de naam
  • Formateer de naam in [Achternaam],[Voornaam] [tussenvoegsels]
  • Start MIS.exe
  • Klik op “Nieuwe medewerker opvoeren”
  • Selecteer veld “Naam”
  • Plak
  • Ga terug naar Excel
  • Ga naar de 2e rij, 2e kolom
  • etc

En uiteindelijk kan de robot al deze handelingen zelfstandig uitvoeren. Vanzelfsprekend zijn er diverse bewerkingen van data mogelijk, kunnen vele systemen worden “gelezen”en komen de RPA suites met uitgebreide monitoring en logging functionaliteit.

Bestaat dat al niet?

Tuurlijk kunnen er scripts, macro’s, SOA’s, webservices e.d gebouwd worden om al deze data heen-en-weer-stuur acties uit te voeren. Levert wellicht hetzelfde eindresultaat op.

Het idee achter een RPA suite is dat dit allemaal vanuit 1 omgeving gebeurt en makkelijk te bouwen is. Daarnaast zijn robots her te gebruiken, aan elkaar te linken etc. Kortom; een RPA suite is een grote robot bouwdoos.  En de belofte is dat je niet veel programmeerkennis nodig hebt om een robot te bouwen.

RPA suites beloven dus makkelijk bouwen en goed beheer van al deze robots die de handmatige data verwerkingstaken overnemen.

Ben je met RPA eigenlijk niet de “cowpaths aan het paven”?

Vanuit een idealistisch procesverbeter standpunt kun je je afvragen of RPA wel een goed idee is. Iets wat met de hand gebeurde, wordt nu 1 op 1 door robots gedaan.

Dus niet eerst kijken of het ook slimmer kan (waarom hebben we eigenlijk 8 systemen met medewerkerinformatie? Is al die data wel nodig?), maar gewoon automatiseren die hap.

Zoals u weet, wordt dat ook wel “paving the cowpaths” genoemd.

Ik heb een leverancier van RPA gehoord die dat ook helemaal niet ging verdedigen. “RPA is duct tape; niet elegant maar het werkt uitstekend”.

RPA maakt het proces dus niet persé leaner, maar simpelweg goedkoper. En daarmee kom ik op de consequentie van RPA; mensen raken hun baan kwijt.

Waardevoller werk? 

Door leveranciers van RPA wordt altijd benadrukt over het feit dat je heel veel kunt besparen op loonkosten. Dat zorgt meestal voor blije gezichten in de boardroom, maar die loonkosten waren ook iemands salaris.

Ik vind dat er dan altijd net iets te makkelijk wordt gezegd dat die mensen dan werk kunnen gaan doen dat meer waardevol is. En natuurlijk komen de leveranciers dan met mooie voorbeelden daarvan. Ik vraag me af of dat wel altijd het geval zal zijn. Wie doet dan nu dat waardevolle werk? Niemand?  Hoe waardevol is het dan daadwerkelijk?

Vanzelfsprekend komen RPA leveranciers ook met mooie voorbeelden waar de inzet van RPA juist nieuwe banen opleverde. Maar dat kan toch niet waar zijn in alle gevallen?

Maar wie ben ik? 

Maar ja, als je als organisatie alleen maar kunt overleven door kosten te besparen, wie ben ik dan om te zeggen dat dat kort door de bocht is?

Want, als je in een sterk concurrerende markt zit, is de enige manier om te overleven vaak kosten besparen. En dan is het inzetten van robots die niet klagen of moe worden een logische stap.

De maatschappelijke gevolgen zullen breder getrokken moeten worden door bijvoorbeeld discussies over het basisinkomen.

Maar, wie ben ik om me daar mee te bemoeien? Ik typ alleen maar stukjes over procesmanagement.

Bliep.

 

 

 

Als auto’s het kunnen, waarom teams dan niet?

Geplaatst op door
Antwoorden

037

Er  zijn soms van die ‘hypes’ waarvan ik denk; ’Heuh wat is er nieuw aan?’. Zo ook zelfsturing of ontmanageren. Ik ben niet anders gewend en honderdduizenden zzp’ers zullen wel moeten.

Maar inderdaad;  in de grote ’enterprises’, met organigrammen met meer lagen dan de gebouwen waarin ze zijn gehuisvest,  is dat vaak een cultuurschok van jewelste.

Nu wil ik hier niet de verandergoeroe uithangen (voor je het weet moet ik, al sigaren rokend in een grote villa,  mijn huishoudelijke hulp zeggen dat ze niet in beeld moet lopen), dus wat heeft het te maken met procesmanagement?

Alles, denk ik. Want mijn visie is dat procesmanagement geen losse project-frats is, maar dat processen managen hetgene is wat dagelijks gebeurt in organisaties. Dus hoe je de mensen in deze processen aanstuurt, of zich zelf laten sturen, heeft direct invloed daarop.

Nu ben ik niet van het type ‘allemaal aan de zelfsturing want anders ben je morgen failliet’.

Ik zou beginnen met je af te vragen over wat voor processen je het hebt, wat deze processen moeten opleveren en welke manier van inrichting en aansturen daarbij het beste past.

Procesmanagen is een werkwoord, geen functie, dus iedereen kan dat doen. Ik vind het het mooiste om te zien dat processen organisch richting zelfsturing groeien, maar misschien is het eerst verstandig om toch eerst nog een alles overziende procesmanager te hebben.

Of leg je vanaf morgen de procesmanager rol direct bij alle medewerkers?   Maar, zijn ze voldoende opgeleid/gecoached en ontdoost om deze rol te vervullen?  Hebben ze ook de hulpmiddelen (o.a. informatie) om dat te kunnen?

Dus klakkeloos ideeën uit een goedlopend boek invoeren en hopen dat het morgen zo werkt; het is niet zo zwart wit. Dus vraag u af welke van uw processen er bij gebaat zijn en welke inrichtingsveranderingen daarvoor nodig zijn.

Procesresultaten, doelen en dat soort dingen

Geplaatst op door
Antwoorden

“Waarom hebben jullie processen?”

“Om ze in kaart te brengen”

Deze waargebeurde conversatie was voor mij aanleiding om in al m’n opdrachten de nodige tijd en aandacht te besteden aan het helder krijgen van resultaat en doel van processen.

 

Doel, resultaat, proces….heuh?

Procesresultaten en procesdoelen. Ik heb het er vaak over in mijn schrijfsels.

Voor mij zijn dat twee vanzelfsprekend gescheiden aspecten. Omdat die stelling nogal eens tot vragen leidt, vertel ik in dit blog wat ik er mee bedoel.

Misschien ontstaat de verwarring wel doordat er voor dezelfde dingen, verschillende termen worden gebruikt (wat nogal eens voorkomt in processenland). Is dat in dit geval ook zo, dan weten we dat ook weer en is die verwarring in ieder geval opgelost.

 

Processen zijn een middel, geen doel

Elke organisatie heeft processen. Of ze nou goed of minder goed presteren, ze zijn er gewoon. Processen zijn immers het middel om een product of dienst te leveren of om problemen van klanten op te lossen.

En daarmee kom ik direct op wat ik als procesresultaat benoem; het “tastbare” resultaat van een proces.

Een proces heeft vaak meerdere belanghebbenden, maar in de kern is het procesresultaat iets wat waarde moet hebben voor de “echte” klant van het proces.

 

Het procesresultaat

Net zoals in eerdere verhaaltjes, gebruik ik ook nu weer het eenvoudige voorbeeld van een pizzeria en concentreer me daarbij op het proces “Bezorgen pizza”.

Wat is het concrete resultaat van dit proces? Daar kom je achter door bijvoorbeeld de volgende vragen te beantwoorden:

  • Waarom vraagt een klant de pizzeria om dit proces uit te voeren?
  • Waar wil de klant voor betalen?

Inderdaad, “een bezorgde pizza”, in dit geval. Dat is wat ik het concrete procesresultaat noem.

Net zoals het proces “Verstrekken vergunning” een (in de positieve variant) “Verstrekte vergunning” oplevert en het proces “Aannemen nieuwe medewerker” een “Aangenomen medewerker” als procesresultaat heeft.

 

Niet altijd zo concreet voor elk proces

Er bestaan in Processenland verschillende type processen. Er zijn ook processen waarvan het resultaat pas wordt vastgesteld bij aanvang van de zaak.

Bijvoorbeeld als iemand een huis wil laten bouwen, dan zal het “eindresultaat bepalen” waarschijnlijk de eerste stap van het proces zijn.

 

Een goed proces begint aan het eind.

Nu ik er naar kijk, realiseer ik me dat ik in bovenstaand pizza voorbeeld vanuit de verkeerde kant ben gestart. Een proces was immers een middel om het resultaat op te leveren.

Dat gewenste resultaat zou dus het startpunt moeten zijn.

 

Welk probleem lost het procesresultaat op?

Vanuit een meer strategisch perspectief moet je je eerst afvragen waar klanten echt blij van worden. In dat geval moet je voorbij het concrete procesresultaat denken en helder krijgen welke problemen je wilt oplossen voor klanten.

In dit geval zou dat dus iets zijn als “klant moet nog eten, maar wil het huis niet uit en heeft geen zin of mogelijkheid om te koken”

Een “bezorgde pizza” kan dit probleem oplossen. En de pizzeria heeft alle middelen bij elkaar gebracht om een proces uit te voeren wat dat resultaat oplevert.

Het is dus aan te raden om aan het eind te beginnen om vervolgens vast te stellen dat je daar dus een proces voor nodig hebt.

Op deze manier voorkom je tevens dat je naar zinloze “processen” zit te kijken.

 

Zinloze processen?

Zo klinkt”Pizza gebakken” best wel resultaterig, maar het is niet waar de klant de pizzeria voor betaalt. Het is een tussenproduct in het proces om uiteindelijk te kunnen bezorgen.

Een ander voordeel van over het concrete procesresultaat nadenken, is dat je geen vage processen krijgt, waarvan niemand kan zeggen waarvoor ze exact dienen.

De pizzeria heeft voorraden, maar zou “beheren voorraad” een proces zijn?  Ik weet het niet, want ik kan me niet zo heel veel concreets voorstellen bij een procesresultaat als “een beheerde voorraad”.

Maar, de klant heeft stevige trek, dus snel terug naar het procesresultaat “bezorgde pizza”.

Er zijn miljoenen pizzeria’s die dat zelfde procesresultaat leveren. Wat is dan de reden waarom klanten wel bij de ene en niet bij de andere pizzeria bestellen?

Dat heeft te maken met wat de klant wenst hoe het proces presteert. En dat brengt me op wat ik met het procesdoel bedoel; de beloftes over het procesresultaat.

 

Doel; de beloftes over het procesresultaat

Zoals gezegd is een proces een middel om het procesresultaat op te leveren.

Maar, om een proces in te richten, moet je wel duidelijk hebben wat je over dat resultaat belooft; de procesdoelen.  En dat kunnen er meerdere zijn.

Voor de klant bijvoorbeeld:

  • “Pizza bezorgd” binnen 45 minuten

of nog meer beloftes:

  • “Pizza bezorgd” binnen 45 minuten en warmer dan 70 graden

of heel ambitieus:

  • “Pizza bezorgd” binnen 45 minuten, warmer dan 70 graden, lekker en nooit duurder dan 10 euro

Het procesdoel is dus wat je (qua tijd, kosten, kwaliteit, etc) over het procesresultaat belooft.

Deze combinatie tussen het procesresultaat en de daaraan gekoppelde doelen, is wat je als pizzeria wilt uitstralen.  Snel? Goedkoop?  Engel die op je tong pist?

Dat komt dus neer op de vraag “Wie wil je zijn?”

 

Procesdoel is afhankelijk van “wie je wil zijn”

Wat je over het procesresultaat belooft is afhankelijk van wat je als organisatie “wilt zijn” (ja, dat zal in de boeken wel iets als missie, visie of strategie heten).

In Pizzerialand zie je vanzelfsprekend de verschillen. De grote ketens die gaan voor “snel en gestandaardiseerd”  en de meer traditionele pizzeria’s gaan voor “kwaliteit en smaaksensatie”

 

Invloed op procesinrichting

Dit heeft vanzelfsprekend invloed op wat je belooft over een bezorgde pizza, maar des te meer op de inrichting van het proces.

In geval 1 wordt het pizzamaken tot lopende band werk verheven, waarbij elke uitvoerder in het proces een klein stapje doet met als doel om een pizza te creëren die altijd hetzelfde van vorm en smaak is en ook nog eens in een vooraf voorspelbare tijd gereed is.

In het tweede geval zal een eigenaar-kok mogelijk alle stappen in het proces zelf doen en al zijn ervaring en liefde in de pizza stoppen. Dat dat iets duurder is of langer duurt, dat zal de liefhebber van dat soort pizza’s moeten accepteren.

 

Was het leven maar zo makkelijk

Alles wat ik hierboven heb geschreven over het procesresultaat en doel, gaat er vanuit dat de betalende klant de enige belanghebbende van het proces “Bezorgen pizza” is.

En in Proces-sprookjesland is dat ook zo. En ik ben van mening dat dat wel degelijk de basis moet zijn van elk proces. Maar als je alleen maar dingen doet die “Waarde toevoegen voor de klant”, kan het zomaar zijn dat je met justitie in aanraking komt of failliet gaat.

Want, voegt het waarde voor de klant toe dat u zich aan de wet houdt en dat u rekeningen verstuurt?

De klant is dus niet de enige belanghebbende van een proces.

 

Meerdere belanghebbenden

Zonder de pizza etende klant is het bovenstaande proces helemaal niet nodig. Toch is het in het kader van procesdoelen vaststellen goed om te beseffen dat er meerdere belanghebbenden van een proces kunnen zijn.

Denk bijvoorbeeld aan de aandeelhouders van de pizzeria die willen dat de marge op elke bezorgde pizza meer dan 40% is

Of de voedsel en waren authoriteit die hygiëne eisen stelt aan het maken van pizza’s.

En dan is het “Lean maken” van een proces nog niet zo eenvoudig, want bij de inrichting van het proces zult u rekening moeten houden met al deze verschillende doelen.

Denk in dit geval aan een extra stap om de temperatuur van de pizza te meten of een procesregel dat een brommer niet minder dan 4 pizza’s mag vervoeren omdat anders de marge te laag wordt.

En daar worden processen al snel weer wat “dikker” van.

 

Procesresultaat en doel; is dit nou allemaal zo belangrijk? 

Bovenstaande is geen raket techniek. Gelukkig maar. Is het dan wel belangrijk?

Tja, wat is belangrijk?

Ik vind van wel. Want processen uitvoeren met procesresultaten die voor niemand een probleem oplossen, is jezelf voor de gek houden. Het helpt mij om helder voor ogen te krijgen waarvoor we processen moeten inrichten. En uitvoeren, natuurlijk.

En daarmee ben ik er zeker van dat ik iets doe waarmee ik anderen help met zinvolle procesresultaten.

Daarnaast vind ik een gezamenlijk (proces)doel een minimale vereiste om met meerdere mensen samen te kunnen werken aan zaken in een proces.

Ach, en ben je ZZP’er dan doe je mogelijk het hele proces in je eentje en dan heb je waarschijnlijk heel helder wat het procesresultaat en doel is en stem je dat goed af met je klant.

Maar gaat het om processen waarin verschillende mensen meewerken aan het procesresultaat, dan is het helder maken van procesresultaat en -doel het minste wat je kunt doen voor alle betrokkenen,

 

Maak het helder!

En laat ik daar dan maar de de conclusie van dit verhaal van maken. Processen hebben een resultaat met daaraan gerelateerde doelen.

Of beter andersom; u belooft iets aan uw klanten en wilt uw processen dusdanig inrichten zodat u die belofte waar kunt maken.

Ik ben er daarom een groot voorstander om deze procesresultaten en doelen kraakhelder te maken. Zodat iedereen weet waar ie aan meewerkt en mee kan denken over een nog betere procesinrichting.

En ja, als je iets helder maakt kan het zijn dat iemand zich daar niet in kan vinden.

Maar wees gerust, voor iedereen is wel een procesresultaat te vinden waar hij zich lekker bij voelt.

Ik wens u zinvolle processen!

 

 

 

 

In de kleedkamer scoren; dat valt nog niet mee

Geplaatst op door
Antwoorden

035

 

Dit Procesje heb ik al een aantal keer tijdens workshops gebruikt en riep daarmee reacties op als ‘Dat hebben wij inderdaad ook gedaan’ , ‘Wat voor mensen heb ik nodig in zo’n project?’ en ‘Een goed idee, dat we daar niet eerder aan hebben gedacht’

Ai. Mijn procesjes bevatten meestal een kwinkslag, dus helaas ontging velen de ironie achter deze tekst.  Processen zijn namelijk gewoon dagelijks werk. Elke organisatie voert elke dag processen uit om producten of diensten te leveren aan haar (proces)klanten.

Alle energie die gestoken wordt in het verbeteren van de procesuitvoering zou dus weggegooid zijn wanneer het geen invloed heeft op de dagelijkse gang van zaken.

Dan wordt het met elkaar in een hok zitten ouwehoeren over ‘hoe mooi het in theorie zou kunnen zijn’.

Ik gebruiken vaak de metafoor van een voetbalwedstrijd om de ideeën achter procesmanagement uit te leggen. Daarbij benadruk ik dat de wedstrijd op het veld gewonnen wordt en dat er zoveel mogelijk verbeterkracht in het veld geregeld moet zijn.

In processen betekent dat; probeer een proces dusdanig in te richten dat tijdens de procesuitvoering ingegrepen kan worden. Los problemen op terwijl de klant nog in het proces is.

Dit is niet makkelijk en stelt eisen aan diverse aspecten van een proces (mensen, informatie, systemen) en heeft mogelijk last van beperkende wetgeving, maar benadrukt wel dat het gaat om het uitvoeren van processen voor klanten.

Dit zal niet lukken voor alle processen, maar altijd nog beter dan in de kleedkamer concluderen dat we helaas weer verloren hebben. Fijne wedstrijd!

 

Processen? Ach, kijk maar wat je er mee doet

Geplaatst op door
Antwoorden

034

 

Deze keer geen dubbelzinnig procesje, maar een enigszins psychiatrische tekst. Procesgericht werken is namelijk niet iets magisch of een trucje van adviseurs en goeroes. Het is een manier van organisatiebesturing waar je bewust voor moet kiezen.

Dat wil niet zeggen dat u geen processen heeft. Elke organisatie voert op dit moment gewoon processen uit om producten of diensten aan haar klanten te leveren.

Echter, in het vakgebied procesmanagement is het het idee dat het een bewuste keuze om deze processen te erkennen (nee, dat is niet hetzelfde als processen beschrijven) en nog belangrijker; deze  processen te gebruiken als stuurmiddel.

Want, processen leveren uw producten of diensten en zijn daarmee de middelen die geld opleveren. Om het proces uit te voeren, moet er vanzelfsprekend ook geld uitgegeven worden. Door u te focussen op het verbeteren van uw organisatie “door processen” heeft u dus goud in handen.

Maar ga niet, met een select clubje,  in een ivoren toren, te lang nadenken over allerlei procesverbeteringen.

Uw processen bestaan immers al en wellicht heeft het meer zin om iedereen te laten beseffen welk resultaat deze processen moeten opleveren en welke factoren in het proces bestaan om de doelstellingen, behorende bij dat resultaat, te beïnvloeden.

Is de werkstroom slim ingericht? Is de juiste (stuur)informatie beschikbaar? Heeft u capabele mensen? Is al die mooie software echt wel ondersteunend? Zo maar een aantal factoren waaraan u kunt denken om uw processen beter te maken.

Durft u te kiezen voor processen als middel om uw resultaten te bereiken?

Man, man, man; wat een ontevreden klanten

Geplaatst op door
1

033Ik kijk graag naar de programma’s (ook in de 8e herhaling) van Gordon Ramsay of Herman den Blijker, waarin ze restaurants er weer bovenop helpen. Hoe doen ze dat?

Door de klant weer centraal te stellen. Door veel aandacht te besteden aan de producten en diensten die geleverd worden. Door medewerkers verantwoordelijk te maken.

Wanneer de missie is geslaagd (en soms lukt dat ook niet), zitten aan het eind van het programma klanten heerlijk te smullen.

Hoe anders is het tenenkrommende programma “De Smaakpolitie” (ik geloof dat het nu anders heet) van Rob Geus. Daar heb ik nog nooit iemand lekker zien eten. Nee, daar gaat het alleen maar om de regeltjes. Is de afzuigkap schoon? Is alles gestickerd? Zijn de rubbertjes heel?

Begrijp me niet verkeerd. Veiligheid is belangrijk, maar straks heb je een hele veilige keuken, maar geen klanten omdat het eten naar schoonmaakmiddel smaakt.

Misschien een beetje, Ramsayig, bot en kort door de bocht. Maar wetgeving en regels zijn vaak frustrerend wanneer u uw processen klantgericht wilt uitvoeren.

Regels, wetgeving; het is bedoeld om alles in goede banen te leiden. Helaas zie ik vaak dat ze de aanleiding is om met processen aan de slag te gaan. Ik vind dat gek en van uit een negatieve optiek gedacht.

Vanzelfsprekend is het de beste aanpak om alle aspecten van een proces bij de kop te pakken wanneer u een proces wilt verbeteren. Werkstroom, informatievoorziening, mensen, hulpmiddelen,  besturing en inderdaad ook de wetgeving die van invloed is op dat proces.

Dat vergt dus vele disciplines in een organisatie om over een proces te praten. En dat is, helaas, soms lastig te organiseren.

Zou het in dat geval niet het beste zijn om eerst eens je processen in te richten om te doen waar uw klanten voor willen betalen? En dan pas kijken of het aan de regels voldoet?  En met een beetje gezond verstand blijkt dat vaak reuze mee te vallen. Klant blij, wetgever, certificeer-meneer en Rob Geus blij.

Maar misschien zie ik het wel verkeerd. Want zo’n smaakpolitie-sticker (heeft u die aflevering van RamBam gezien?) op het raam lokt toch klanten. Ook al is uw biefstukje zo taai als dat schone rubbertje.

 

Zijn procesmodellen wel zo handig voor procesverbeteren?

Geplaatst op door
1

Inleiding

Op twitter heb ik het regelmatig over de dynamiek in de uitvoering van processen en dat je dat niet goed ziet weergegeven in procesmodellen.

Een procesmodel kan handig zijn als werkinstructie of als ontwerp voor een uitvoeringssysteem. Maar, als je ze gebruikt in een procesverbeterproject (en daar wordt het toch best veel voor gebruikt, heb ik gehoord), denk ik dat ze vaak te ver van de werkelijkheid staan om echt te kunnen begrijpen waarom een proces niet presteert.

In dit verhaaltje ga ik proberen uit te leggen wat ik met bovenstaande bedoel. Mijn gedachten hierover werden getriggerd doordat ik de afgelopen maanden diverse gesprekken heb gehad met mensen die zich bezig houden met processen in ziekenhuizen. Daar merk je dat er veel behoefte is aan verbetering, maar op een gegeven moment kwam er een kronkel in m’n hoofd toen ik alle aspecten rondom ziekenhuisprocessen op een rijtje probeerde te krijgen.

Daar heb je namelijk te maken met:

  • Het (van te voren soms onduidelijke) proces waar de klant (patiënt) doorheen ‘stroomt’;
  • De beschikbaarheid van apparatuur, ruimtes en andere faciliteiten (de logistiek);
  • De beschikbaarheid van specialisten;
  • De planning die alles qua tijd aan elkaar moet rijgen.

Dit zijn de soort aspecten die ik bedoel als ik het heb over ‘de dynamiek van de uitvoering’.  Hoe je dat precies in procesmodellen moet krijgen, weet ik ook niet. Maar ik ga toch een poging wagen. Het is overigens niet mijn doel om te komen met een nieuw ‘manifest voor procesmodellen’ of  iets dergelijks.

Het is mijn doel  om duidelijk te maken wat ik bedoel met ‘dynamiek van de uitvoering’ en waarom de meeste procesmodellen die ik tegenkom dat niet erg duidelijk weergeven.

Om het enigszins luchtig te houden, zal ik in de voorbeeldjes geen ziekenhuis, maar een pizzeria gebruiken.

Hoe procesmodellen er vaak uit zien

De meeste procesmodellen die organisaties maken, zien er ongeveer als volgt uit.

(Ik weet het; geen formeel BPMN. Klachten naar info@procesje.nl)

Dit is een zeer begrijpelijk procesmodel (hoewel het eigenlijk alleen de werkstroom van een proces is) en kan dus heel goed dienen om aan een medewerker of een klant uit te leggen wat er gebeurt wanneer er een bestelling binnenkomt.

Ook zou dit de basis kunnen zijn voor een toekomstig proces omdat je dit de beste manier vindt om bestellingen af te handelen.

Naar mijn mening zijn procesmodellen zoals bovenstaand enkel geschikt voor:

  • Instructie/Uitleg (dit moet je doen als er een bestelling binnenkomt)
  • Inrichten van systemen/organisatie met processen “zoals ze zouden moeten lopen” (om het technisch te implementeren is vanzelfsprekend nog wel wat extra nodig).
  • Het blij maken van auditors

Maar, wanneer dit een model van het huidige proces zou zijn, heb je er niets aan om te bepalen of dit proces goed presteert. Het vertelt je niet waarom bestellingen te laat komen of pizza’s telkens aanbranden. En al helemaal niet waarom de pizzeria zulke slechte recensies krijgt op Iens.

Om dat te bereiken, moet je het procesmodel opdikken met meer informatie.  Pas dan kun je zinnige uitspraken doen over de prestaties van het proces. En op basis daarvan mogelijke verbeteringen doorvoeren.

Uitbreiding met ‘wie doet het werk?’

Om aan te geven wie het werk doet in een proces, zie je vaak dat er swimlanes worden getekend. In dat geval wordt de werkstroom ‘gematrixt’ met de functies/rollen die de stappen uitvoeren.  Voor het bovenstaande proces ziet dat er mogelijk als volgt uit:

Wat heb je hier aan als het gaat om verbeteren van dit proces? Niet zo heel veel. Je ziet wie verantwoordelijk is voor de uitvoering van een stap, maar wat je bijvoorbeeld niet ziet is:

  • Hoeveel koks zijn er op welk moment beschikbaar?
  • Hoe lang zijn de uitvoerenden bezig met deze stappen?
  • Zorgen overdrachten voor bottlenecks?

Wil je iets over de prestaties van dit proces zeggen, dan moet dat ook zichtbaar zijn in het model.  Dat ga ik straks proberen, maar een ander belangrijk aspect voor het zien of een proces goed verloopt , is het aantal gevallen dat het proces moet afhandelen.  1 pizza bestelling per week is heel wat anders dan 100 per dag, dus dat dynamische aspect moet duidelijk worden.

Process mining/Simulatietechnieken

Met behulp van processmining/simulatie hulpmiddelen kun je duidelijk maken hoeveel en hoe gevallen door het proces stromen.  De “bolletjes” (als weergave van onderhanden bestellingen) maken dit namelijk duidelijk.

Dit soort technieken geven al een indicatie van bottlenecks in een proces.  Maar bottlenecks zijn slechts symptomen, dus moet je veel dieper in het proces duiken om te achterhalen wat deze bottlenecks veroorzaakt.

In bovenstaand plaatje zie je dat er 3 bestellingen genoteerd worden, maar slechts 1 belegd, waardoor een wachtrij ontstaat. Hoe kan dat? Wanneer we naar de ziekenhuiswereld kijken, heeft dat vaak te maken met beperkte resources.

Een chirurg kan maar 1 operatie tegelijk doen. En wanneer zij aan het opereren is, kan ze geen consulten doen. Dus de doorstroom van patiënten wordt dan beperkt door het aantal medewerkers. Dat zie je niet terug in de meeste procesmodellen. Dus op één of andere manier, zou je de modellen moeten kunnen ‘opdikken’ met resource beschikbaarheid.

Resource-beschikbaarheid in een procesmodel

Wanneer je denkt aan het toevoegen van de beschikbaarheid van resources aan een procesmodel maak je eigenlijk een soort matrix van zwembaan x aantal resources  x stap.

Stel dat er 3 serveersters, 1 kok en 2 bezorgers zijn in het bezorgen pizza proces. Dan wordt het model (het is maar een zelfgeknutselde weergave, hoor) als volgt:

 

Combinatie met bolletjes

Wanneer je het bovenstaande model dan weer combineert met bolletjes (bestellingen), wordt een beetje duidelijker waarom sommige bestellingen niet doorstromen:

 

Zo zie je bijvoorbeeld dat er geen nieuwe bestellingen worden aangenomen omdat de 3 beschikbare serveersters allemaal bezig zijn met een bestelling.

Daarnaast zie je nog iets wat slecht is af te beelden in een model ; er is maar 1 kok, die 3 opéénvolgende stappen voor een bestelling moet uitvoeren. Als hij een pizza aan het verpakken is, kan hij ondertussen niets anders doen.  Hoe zou je deze afhankelijkheid kunnen afbeelden?

Misschien met kleurtjes?

Op deze manier kun je misschien duidelijk maken dat ze onderverdeeld zijn in drieën.

Een andere manier zou kunnen zijn door te zeggen dat het kokswerk een soort van blok is waar zich slechts 1 bestelling tegelijkertijd in kan bevinden:

Het is een lastig aspect van een proces om af te beelden. Maar wel een hele belangrijke om te bepalen waarom een proces niet presteert.  Het is in principe een soort van aan/uit switch tussen activiteiten; als de ene wordt uitgevoerd, ligt de ander stil.

Mensen niet de enige schaarse resource

Een grote uitdaging in een ziekenhuis is niet enkel de inzet van schaarse specialisten, maar ook de beperkte beschikbaarheid van apparatuur/operatiekamers etc.  Je kunt misschien 10 chirurgen hebben, maar als je maar 1 operatiekamer hebt, is dat de beperkende factor.

In administratieve processen kun je dan misschien denken aan systemen (of misschien beter licenties) waarvan er slechts een paar zijn.  Ook dat zou eigenlijk uit het model duidelijk moeten worden. Voor de pizzeria is dat misschien de situatie dat er maar 1 brommer is om te bezorgen. In onderstaand model is deze beperking opgenomen.

 

Om dit te begrijpen heb je eigenlijk wel weer de dynamische bolletjes nodig. Zo zie je dat een bestelling (daarom 2 halfjes) een bezorger en een brommer nodig heeft. Nu zie je dus ook dat er eigenlijk een bezorger te veel is. Of een brommer te weinig.  Kans voor bezuiniging of meer throughput.

Dit lijkt overigens wel een beetje op petrinetten zoals sommigen van jullie wellicht kennen.

En wanneer er in de pizzeria een oven heeft, waarin 3 pizza’s tegelijkertijd gebakken kunnen worden, ziet dat deel van het proces er als volgt uit:

 

Ook hier zie je weer het probleem van 1 kok. Hij kan niet tegelijkertijd een pizza in de oven stoppen en er eentje uithalen (hoewel, ik heb koks gezien…).  Daarom ontstaat het gevaar dat er allemaal pizza’s liggen aan te branden omdat de kok geen tijd heeft om pizza’s uit de oven te halen.

En daarmee kom je op een ander aspect van processen; planning en tijd

Planning en tijd

In het plaatje hierboven wordt dus het belangrijke aspect van tijd duidelijk; wanneer een pizza te lang in de oven ligt, brandt hij aan. Dit heeft dus ook weer met planning te maken.  Dat zit meer in de daadwerkelijke uitvoering van een proces, maar is wel heel belangrijk om een proces goed uit te voeren.

Daarbij zul je bijvoorbeeld ook rekening moeten houden met de beschikbaarheid van medewerkers. Op zaterdag heeft de pizzeria misschien 3 bezorgers en door de week maar 1. Dus het proces (en zijn prestaties) verschilt ook nog weer per dag.  Dit dynamische aspect zul je echt niet ontdekken d.m.v. een traditioneel procesmodel.

In het ziekenhuis heb je daar ook mee te maken. Stel dat er 2 chirurgen zijn, maar slechts 1 operatiekamer. Terwijl de ene chirurg aan het opereren is, kan de ander consulten doen. Hoe maak je dit soort planningsachtige aspecten, die belangrijk zijn voor de patiënt nu duidelijk? Even proberen…

 

Conclusie tot nu toe

Procesmodellen zoals we ze vaak zien hebben hun toepassingen, maar helpen niet altijd om inzicht te krijgen in de oorzaken van slechte procesprestaties.

Daarvoor moet je o.a. ook weten:

  • Aantal gevallen (de bolletjes)
  • Resources
  • Afhankelijkheid resources
  • Planningachtige zaken (beschikbaarheid)

Heel veel aspecten dus, maar noodzakelijk naar mijn mening. Als je dit allemaal wilt afbeelden in een model heb je een aantal dimensies (als tijd, casussen en resources) nodig.

In dit blog heb ik geprobeerd dit duidelijk te maken en in modelletjes weer te geven. En dat valt niet  altijd mee, zoals u heeft kunnen zien.

Dus is het wel de moeite waard om proberen processen te verbeteren aan de hand van procesmodellen zoals ze vaak worden gemaakt?

Of is het wellicht beter om vanuit de uitvoering het proces steeds een klein beetje beter te maken.  Want de dynamiek van de uitvoering komt toch het meeste naar voren in……….. de uitvoering.

Elk voordeel zal z’n nadeel wel hebben, dus hoe denkt u over dit soort zaken?

‘het nieuwe goud’ en uw processen

Geplaatst op door
1

Data is al heel wat jaartjes hip. Processen worden altijd een beetje als saai gezien.

Toch zijn ze onlosmakelijk met elkaar verbonden. Data is gewoon onderdeel van een proces.

Tenminste, zoals ik er naar kijk. Dus, hoe kijk ik er naar?

Doel is het laten presteren van processen; procesmanagement dus

In een eerdere post kon u al lezen dat ik procesmanagement opdeel in 3 niveaus (met daarboven eigenlijk nog het meer strategische ‘Waarom?’ niveau):

  1. De uitvoering van een proces voor een individuele zaak
  2. Besturing van alle lopende zaken in een bepaald proces
  3. Verbeteren van het procesontwerp voor een bepaald zaaktype

Wanneer ik organisaties help om al deze niveaus van procesmanagement in te richten, is belangrijk om te begrijpen wat je allemaal nodig hebt om een proces te laten presteren.

Zodat je niveau 3 niet zo vaak hoeft te doen.

Dat betekent dat we dan kijken naar diverse samenwerkende proces aspecten als:

  • Wat is het werk dat moet gebeuren (de werkstroom)?
  • Wat voor type mensen met welke capaciteiten zijn daar voor nodig?
  • Welke hulpmiddelen zijn benodigd?
  • Wat is de beste manier om dit proces te besturen (bijv. taakgericht of doelgericht)?

Er zijn meer aspecten, maar degene waar ik in dit verhaaltje op in wil gaan is Data.

Want u heeft waarschijnlijk al diverse artikelen gelezen waarin u las dat data ‘het nieuwe goud ‘ is.  Ook herinnert u zich vast de gloriedagen van ‘Big Data’ of leest u weer een quote dat we nu meer data in een minuut produceren dan onze grootouders in een heel millennium. En laten we dataverslindende AI gadgets niet vergeten.

Super cool, maar wat heeft het te maken met processen inrichten, besturen en verbeteren?

Veel. Want in bijna alle processen speelt data (of zou het beter zijn om het informatie te noemen?) een grote rol. Maar data in het algemeen is ook maar data, dus daarom maak ik altijd onderscheid, net als de cirkeltjes uit een eerder artikel,  in het gebruik van data op verschillende niveaus van procesmanagement:

  1. Data om een proces voor een individuele zaak uit te voeren
  2. Data om alle zaken die momenteel lopen te kunnen besturen
  3. Data om het proces(ontwerp) te kunnen verbeteren
  4. Data als verbinding tussen verschillende processen

Om dit uit te leggen, gebruik ik weer m’n ‘Bezorgen pizza’ proces:

Data die nodig is om het proces uit te voeren

In het proces ‘Bezorgen pizza’, is het gewenste procesresultaat een bezorgde pizza. Maar, het start allemaal met een klant die de wens heeft om een pizza te laten bezorgen. Om alle tussenliggende handelingen uit te kunnen voeren, is informatie benodigd.

Om de pizza te maken is informatie nodig als:

  • Welke pizza wil de klant?
  • Welk formaat?
  • Welke extra toppings zijn er besteld?

Om de pizza te kunnen bezorgen, is informatie nodig als:

  • Bezorgadres
  • Gewenste bezorgtijd
  • Telefoonnummer

Dit maakt ook duidelijk dat stappen die je vaak in het begin van een proces ziet, als ‘Vastleggen bestelling’ alleen maar nodig zijn om bovenstaande data te verkrijgen. Het vastleggen van deze data voegt geen waarde toe aan het maken of bezorgen van de pizza. Het voorziet het proces enkel van informatie. Maar wel nodig natuurlijk.

En daarom moet er, zeker in de huidige ‘multi-channel-tijd’, tijdens procesontwerp nagedacht worden over hoe de data in het proces belandt.

  • Telefoon
  • E-mail
  • Bestelwebsite
  • Bestel app

Omdat de Customer Journey ook een hip ding is, is het belangrijk dat het de klant niet heel erg moeilijk wordt gemaakt om u van deze data te voorzien.

Bovenstaande is dus data voor een individuele case. Hopelijk krijgt deze pizzeria meer dan 1 bestelling per dag. En daarmee kom ik op het volgende niveau van data.

Data om alle zaken in een proces te managen

Veronderstel dat op een bepaald moment in de avond zich 8 bestellingen in het proces bevinden. Medewerkers werken aan de individuele bestellingen, maar tenminste één iemand zal de rol van procesmanager moeten spelen om ‘alle zaken in de gaten te houden’.  Dat betekent dat er informatie nodig is over hoe de zaken er voor staan.

Voor mij zou dat betekenen dat je de status van alle zaken in het proces weet en dat duidelijk is of ‘de belofte wordt waargemaakt’

En die belofte kan, vanzelfsprekend, van proces tot proces verschillen. In een vorige post hield ik het simpel door alleen de bezorgtijd (binnen 50 minuten) in ogenschouw te nemen. Omdat waar te kunnen maken is dus voor elke bestelling inzicht in deze belofte nodig:

Dit is traditioneel proces monitoring, maar voor mij nog steeds essentieel in ‘doen wat je belooft’.  Dit is wat ik ‘op het veld’ noem. Want op dit moment kan nog ingegrepen worden in zaken waar de belofte mogelijk niet waar gemaakt kan worden.

Wanneer u nadenkt over de inrichting van zaakmonitoring, kunt u ook nadenken over in hoeverre u deze gegevens beschikbaar wilt stellen aan een klant. Het schijnt ‘the age of the customer’ te zijn, dus wilt u hem/haar informeren over de voortgang van de zaak?

Dit monitoring niveau van procesdata gaat om ‘doen wat je belooft voor de individuele klant’. In dit geval pizza’s op tijd bezorgen.

Nadat je meerdere individuele klanten hebt geholpen, wordt waarschijnlijk ook duidelijk hoe goed het proces in het algemeen is ingericht.

Tenminste, als u daar de juiste data voor verzamelt. En daarmee zijn we op niveau 3 van data in procesmanagement beland.

Data om processen te verbeteren

Dit derde niveau van data gaat over traditioneel procesverbeteren.  Presteert het proces zoals we het ooit hebben bedacht, of heeft het een opknapbeurt nodig? Het is de klassieke Village People hit ‘PDCA’.

Maar om te weten of het ‘beter’ moet, zul je eerst ‘goed’ moeten definiëren.

In mijn simpele pizza voorbeeld is dat ‘Bezorgd binnen 50 minuten’. Maar in het echt gelden vast meer doelen als:

  • Lekker (hoewel smaken verschillen)
  • Warm (> 78 graden)

Of interne doelen als:

  • Winstmarge op pizza > 34%

En dan hebben we het nog niet eens gehad over doelen opgelegd door andere belanghebbenden als wetgever of controlerende instanties als de NVWA.

Om te kunnen bepalen hoe goed het proces het doet (of eigenlijk ‘heeft gedaan’), is data over procesprestaties benodigd. Dat kan natuurlijk verzameld worden door te meten, spreadsheets bij te houden of misschien zelfs met mooie management informatie dashboards in een BPM tool.

En dat maakt mij verder ook niet uit, zolang de data je maar iets zinvols vertelt over de prestaties van je proces. Sinds een aantal jaar zou ook Process Mining hierbij een toepasbaar hulpmiddel kunnen zijn.

Process Mining is technologie dat data gebruikt van de systemen die worden toegepast om processen uit te voeren. Vervolgens wordt deze data (die over de verschillende afgehandelde zaken gaat) omgezet naar een ‘procesgeoriënteerde kijk’, om op die manier iets over het proces te weten te komen.

De meeste process mining tools hebben diverse mogelijkheden om deze data te representeren. Een basisplaatje is vaak een figuur van de werkstroom met daaraan gekoppeld de gemiddelde bewerkingstijd van activiteiten en de gemiddelde wachttijd tussen de activiteiten (weergegeven op verbindingen).

Na een beetje rekenen (wat de process mining tool vanzelfsprekend ook voor u kan doen) is de conclusie dat de gemiddelde doorlooptijd 50 minuten en 33 seconden bedraagt.

Maar, wat heb je nou aan gemiddeldes? Ik heb op school niet zo heel goed opgelet bij statistiek, maar niet zo heel veel, geloof ik.  Daarom hebben de meeste process mining tools ook de mogelijkheid om doorlooptijden, wachttijden etc. anders te tonen.

Bijvoorbeeld de minimale en maximale waarde. Dit geeft al een kleine indicatie van de variantie.

Het volgende plaatje laat de minimum en maximum bewerkingstijd van activiteiten en de minimum en maximum wachttijd op verbindingen zien.

Even de TI 30 stat er bij pakken en u ziet dat de snelste bestelling in 38 minuten werd bezorgd en dat de langzaamste er 1 uur en 25 minuten over deed. Is dat erg? Waarschijnlijk niet zo leuk voor de klant die 35 minuten langer dan beloofd moest wachten. Maar maakt dat het direct noodzakelijk om te sleutelen aan het procesontwerp?

Meer inzicht daarin verkrijg je door alle doorlooptijden in een grafiek te laten zien (ook standaard functionaliteit van een fatsoenlijke process mining tool).

Nu is zichtbaar dat 7 van de 23 bestellingen een langere doorlooptijd dan het doel van 50 minuten hadden. Of dat goed of slecht is, mag elke organisatie zelf bepalen. Maar voor de 7 klanten die de pizza te laat kregen, is er niks meer aan te doen. We kijken immers naar gegevens uit het verleden. Vandaar dat ik traditioneel procesverbeteren ook wel ‘kleedkamerpraat’ noem.

Een ander ding om te beseffen, is dat al deze proces prestatie informatie slechts symptomen laten zien. Om het proces te verbeteren, zul je echter op zoek moeten naar de oorzaken.

Toch kan process mining al wel wat indicaties geven over waar te zoeken naar de oorzaken van bijvoorbeeld een lange doorlooptijd.  Zo was te zien dat bestellingen een behoorlijke tijd spenderen aan wachten. Bijvoorbeeld tussen de stappen ‘Verpakken pizza’ en ‘Bezorgen pizza’.

Nog steeds een symptoom, maar dit zou kunnen leiden tot een onderzoek waarin duidelijk wordt waarom bestellingen gemiddeld 8 minuten wachten voordat ze worden opgepakt voor bezorging.

Om nog meer inzicht te krijgen in verstoringen van ‘de flow’, bieden process mining tools ook de mogelijkheid om de stroom van gevallen in een soort van filmpje te tonen. Wat er in feite gebeurt is dat het logbestand op een procesgeoriënteerde manier wordt nagespeeld. Hierdoor worden bottlenecks nog visueler (dit is overigens een statisch plaatje) weergegeven.

En dan ‘nog even’ een oplossing bedenken en implementeren 😉

En dat was niveau 3 van data; procesverbetering. Niveau 2 ging over de dagelijkse procesgang van zaken (in dit geval pizzabestellingen) en op niveau 1 zagen we de data benodigd voor een individuele bestelling.

Wanneer ik organisaties help met het knutselen aan processen, benoem ik ook altijd nog een ander type data; data die stroomt tussen processen.

Data die stroomt tussen processen

De meeste organisaties hebben meer dan één proces. We weten al dat de pizzeria een proces heeft voor ‘Bezorgen pizza’, maar er zullen ook processen zijn voor ‘Afhalen pizza’  en misschien ook wel voor ‘Eten in het restaurant’.  Daarnaast verwacht ik processen om de voorraad (van deeg, tomaten, saus, dozen, etc) op het gewenste niveau te houden.

En tussen al deze processen bestaan ook datastromen. Want als je 50 pizza’s per dag verkoopt, heeft dat gevolgen voor de voorraad. Dus het proces ‘Bezorgen pizza’ genereert data (50 pizza’s gemaakt), wat weer gevolgen heeft voor data in andere processen (de huidige voorraad van goederen).

‘Bezorgen pizza’  en ‘ Voorraad op gewenste niveau houden’ zijn dus processen met een relatie. Die relatie is niet de stroom van een zaak, maar gebaseerd op de data die in die processen gegenereerd wordt:

Processen sturen dus data naar ‘databases’ met informatie en ander processen maken weer gebruik van die data. Hier zijn vele voorbeelden van te bedenken. Bijvoorbeeld klantinformatie die in het ene proces wordt geactualiseerd en in het andere proces weer nodig is.

Dit maakt weer mooi duidelijk dat ‘de processelarij’  heel veel andere vakgebieden raakt zoals informatiemanagement en data-security.

En dat komt omdat dit niveau 4 van data zich meer op een organisatie- of procesarchitectuurniveau bevindt. Hiermee wordt ook duidelijk dat de prestatie van het ene proces invloed kan hebben op een ander proces.

Heel wat data, dus. Een belangrijk aspect van presterende processen, denk ik.  Maar niet het enige. Vandaar ook dat ik processen altijd een goed uitgangspunt vind om naar organisaties te  kijken.

Een proces is een verzameling van allerlei samenwerkende factoren. Niet alleen blokjes en pijltjes (en als u van BPMN houdt, ook wat cirkeltjes). Daarom blijf ik procesmanagement zo interessant vinden.

Gebruik uw data slim en happy processing!

Een documentstroom is geen proces, toch?

Geplaatst op door
Antwoorden

030

 

Degene die mij kennen, weten vast wel (bijvoorbeeld via facebook voor mensen met een stropdas) dat ik ooit werkte voor een grote Amerikaanse printerreus die via allerlei acquisities ook een Enterprise software leverancier is geworden. Inmiddels is dat door allerlei overnames allemaal al weer anders, maar ergens wordt die Software nog wel geleverd.

Veel van die software probeert oplossingen te bieden voor problemen die zich in het informatiewereldje bevinden.

Dan lijkt procesmanagement soms slechts een speldenknop te zijn binnen het geweld van documenten die gescand, geprint, rond-geworkflowed, gezocht en opgeslagen moeten worden.

En omdat veel organisaties worstelen met grip krijgen op een grote verzameling documenten vergeet men al snel dat er maar één plaats is waar die documenten nodig zijn; in processen!

Wanneer u bijvoorbeeld een lening aanvraagt bij een bank, worden er in dat proces heel wat documenten gebruikt om u, de bank en andere belanghebbenden te voorzien van de benodigde informatie voor procesuitvoering. En daarmee hebben we gelijk de 2 punten om die documentgekken om de oren te slaan.

Ze betitelen vaak de stroom van een document als een proces. Da’s een zeer beperkte kijk. Het gaat om het verstrekken van een lening, niet om het rondsturen van het aanvraagformulier. Het is de aanvraag die stroomt, niet het document.

En daarmee kom je op het punt dat een document slechts een gegevensdrager is. De aanvrager wil zijn aflossingsbedrag weten en dat hoeft niet persé op een document te staan. Het gaat om de informatie. Dat heeft een proces, naast andere enablers, nodig om te presteren. Niet de documenten.

Maar, als u dan toch documenten maakt en print, dan wel op een ******* printer (ik heb nog steeds aandelen)!