Business process management (bpm) bestaat al heel wat jaren en vrijwel iedere organisatie doet ook wel iets op het gebied van bpm. Ze huren bijvoorbeeld een Lean-consultant in, maar op de werkvloer is het begrip nog niet breed doorgedrongen.
Ja, veel werknemers hebben wel een beeld hierbij, want in veel bedrijfstakken is dat hot. Of ze daarmee ook een beeld hebben van procesmanagement is de vraag, want veel Lean-projecten beperken zich tot het wegsnijden van stappen. Of het proces daarmee ook effectiever en klantvriendelijker wordt, is een vraag die lang niet iedereen zich stelt. Terwijl de combinatie van efficiency en effectiviteit juist de kern is van bpm.
Het hele idee van procesmanagement is dat de keten van handelingen efficiënt én effectief wordt gemaakt, zodat je met dezelfde mankracht een hoger volume kunt produceren met minimaal dezelfde en eigenlijk een hogere kwaliteit. En is dat niet wat iedere organisatie graag wil?
Ander proces
De uitvoering gebeurt helaas niet door alle organisaties even goed. Sommige managers horen alleen de woorden ‘efficiënt’ en ‘hoger volume’. Ze managen op het verlagen van kosten, zonder stil te staan bij de gevolgen daarvan. Neem de vele organisaties die hebben bedacht dat klantvragen tegenwoordig via het web moeten worden afgehandeld. Of klanten daar ook gelukkig van worden, is een vraag die ze zich te weinig stellen. En of het effectief is, evenmin. Want als klanten er zelf niet uit komen en op de gok een product bestellen terwijl ze eigenlijk liever eerst met een specialist hadden willen overleggen, is de kans groot dat ze eigenlijk een ander product nodig hadden. Wie ook kijkt naar de effectiviteit van processen zou juist aandacht besteden aan hoe de organisatie haar klanten het best kan helpen. De kans is groot dat er dan een heel ander proces wordt ingericht.
Er zijn ook organisaties die processen beschouwen als een lopende band: na stap A volgt stap B. De uitkomst van stap B kan ja of nee zijn. Bij ja volgt tussenstap C, en bij nee kun je direct door naar stap D. Waren processen maar zo simpel! In de huidige kennisintensieve organisaties kennen processen vaak veel verschillende afslagen die uiteindelijk leiden tot een veelheid van productcombinaties. Standaardiseer je zo’n proces op de lopende band-manier, dan maak je ze weliswaar efficiënt, maar niet effectief.
Optimale combinatie
Bpm kan juist bij dergelijke kennisintensieve processen veel toegevoegde waarde geven. Bpm leert een organisatie bijvoorbeeld denken in termen van een klantorder-ontkoppelpunt. Tot waar kun je producten en processen standaardiseren en waar moet je medewerkers juist de vrijheid geven om naar eigen inzicht aan de klantenwensen te voldoen? Tot welk punt heeft efficiency de overhand en vanaf welk moment moet je juist kijken naar de effectiviteit? Immers, bpm richt op het vinden van de optimale combinatie van efficiency én effectiviteit. Het combineert ‘the best of both worlds’.
Een proces ontwikkelen dat zowel efficiënt als effectief is, is één ding, het vervolgens implementeren is een tweede. De daadwerkelijke transformatie is misschien wel het moeilijkste onderdeel van het hele bpm-traject. Immers, verander je te snel, dan begrijpen medewerkers de essentie van de verandering niet en gaan toch weer op de oude manier werken, eventueel via workarounds. Maar laat je in eerste instantie alles bij het oude en voeg je hooguit wat automatisering aan je proces toe, dan bereik je niet de gewenste efficiency- en effectiviteitsdoelstellingen. Met andere woorden: in goed verandermanagement schuilt vaak het succes. Besteed hier voldoende aandacht aan.
Laat ik beginnen met de stelling dat processen de basis vormen van elke vorm van samenwerking, een zekere mate van voorspelbaarheid vinden we prettig omdat maar weinig de chaos beheersen. Vraag is echter of BPM het doel behaald dat ze beloven als we kijken naar de knelpunten hierin aangaande de schaalbaarheid binnen de enterprise, een begin of het eind disucssie in het hele vraagstuk van ketenbeheer binnen het loketdenken van BPM zullen we maar zeggen.
Ik breng dit naar voren omdat ik dus steeds vaker wat rafelige eindjes zie in het hele procesdenken waarbij de empathie tot een simpele meerkeuze vraag van ja of nee is teruggebracht. Het komt dus allemaal neer op de optimale combinatie, waar gaat menselijke gevoel buiten het proces en in hoeverre wordt dit geaccepteerd binnen het verwachtingsmanagement van voorspelbare uitkomsten?
Oja, de ‘olifantenpaadjes’ in de vorm van work-arounds worden in 99,99% van de gevallen ingegeven door een slecht luisterend oor als we kijken naar de top-down benaderingen van BPM welke nog vaak leidt tot een fenomeen van micromangement. Wil niet rot doen maar als je medewerkers vraagt om hun uren in kwartieren te verantwoorden dan ben je als management misschien een beetje teveel los van de praktijk geraakt, systeembevrediging is gewoon een vorm van verlies.
@Ewout Die olifantenpaadjes en het informele circuit zijn niet te onderschatten en vaak de smeerolie van een organisatie. Als ik lees efficient en effectief dan lees ik eigenlijk, managen op kosten. En dan is het juist zo gek dat micromanagement de uitkomst is, onder het mom van meten is weten. Dus gaat je werk voor een te groot deel bestaan uit het boekhouden van het eigen werk en is rol van procesbegeleiders met bijbehorende methodes zo groot geworden. Dan denk ik, dan wordt het middel erger dan de kwaal en het zal denk ik niet bijdragen aan de productiviteit laat staan aan de kostenbeheerding. Ik zie wel, het is DE trend in deze maatschappy. De ene helft van de medewerkers controleert, monitort, procesbegeleid de andere helft. Maar ik ben ook voor vertrouwen en niet voor controle en als je dat laatste wil kan dat ook op een grof niveau zonder micromanagement. Ik zou het wel weten als er dan zonodig op kosten gemanaged moet worden, schrap dit soort niet productieve rollen en procedures.
Ben wel blij dat je het woord ‘effectief’ gebruikt. Een proces is slechts een middel om te doen wat je belooft en dan is effectiviteit (iets doen waar iemand op zit te wachten) het uitgangspunt.
Efficiëntie is slechts een middel omdat plotseling het procesresultaat sneller/goedkoper geleverd moet worden (bijvoorbeeld omdat ‘de concurrent het ook doet’ of ‘aandeelhoudersdruk’).
Maar efficiënt zijn in dingen waar niemand op zit te wachten is helemaal zinloos naar mijn mening.
Een goed proces begint dus altijd aan het eind. Wat moeten we opleveren (product, dienst, opgelost probleem) en wat beloven we daarover (tijd, kosten, kwaliteit).
Pas als je dat helder hebt, kun je iets zinvols zeggen over de procesinrichting. En dan moet je je wel beseffen dat een proces niet ‘een aantal blokjes met pijltjes is’. Da’s slechts (een plaatje van) de werkstroom. Maar om een proces te laten presteren is, naast een setje handelingen dat moet geberuen, veel meer nodig zoals mensen, informatie, hulpmiddelen en ook een manier van besturen.
En juist dat laatste zie ik vaak mis gaan. Met ‘procesmanagement’ denkt men vaak aan alles in gebaande banen proppen en er strak bovenop zitten. Maar je kunt een proces ook resultaatgericht sturen, waarbij medewerkers voor de desbetreffende zaak de beste manier toepassen. En allerlei besturingsvormen er tussen in.
Een zooitje met een succes is ook een proces.
Kortom; begin aan het eind: welke resultaten moet u opleveren en welke procesinrichting past daar het beste bij?
Maar u heeft gelijk, makkelijker gezegd dan gedaan.
@Hans, gaat het niet om de ‘Winst’ die het BPM project oplevert?
Met ’the best of both worlds’ verwijs je naar efficiënt als effectief, maar daar zit volgens mij een groter doel achter. Welke change je ook voorbereid, je bent als organisatie op zoek naar ‘meer wint’.
Dat winstbeginsel kan puur financieel zijn, maar dat is vandaag de dag te smal om bestaansrecht en continuïteit te bieden aan je klanten, medewerkers, aandeelhouders, keten-partners, etc.
Uit vraaggesprekken met directieleden van zowel commerciële bedrijven als not-for-profit organisaties en overhead hebben we een nieuwe definitie voor winst ontwikkeld:
Winst = het gerealiseerd voordeel voor een of meer stakeholders, zonder de andere stakeholders te benadelen of onacceptabele risico’s te introduceren, met bijdrage aan het bestaansrecht, de continuïteit en ontwikkeling van de onderneming/organisatie.
De winnende BPM Business Case richt zich op ‘winst’ zoals hierboven gedefinieerd en bouwt vroegtijdig een band op met alle stakeholders.
Onze ervaring leert dat zij, bewust van hun belang, actief gaan meewerken aan het beoogde succes.
@Louis,
in het kader van micromanage-compliancy kan ik je wellicht h2h holostic approach based coachen om jouw business-enabling capability competence een exponential employee engagement boost te geven, zodat je je weer met een glass-full mentality lean & mean op je core comptentencies kunt focussen.
Lol Felix, zullen we een keer meeten om wat te levelen zodat we ons waarde proposities kunnen enabelen om zodoende een unicorn start-up te funden?
Ah sweet BPM. Iedere organisatie heeft processen, maar hoe weet een ieder welke taken hij uit moet voeren? Waar de uitzonderingen zitten, hoe de happy flow gaat. Hoe weet een nieuwe medewerker wat hij moet doen? En welke parate kennis moet een medewerker hebben om (standaard) processen uit te voeren?
BPM is enerzijds een vorm van kennis management aan de andere kant moet de automatisering medewerkers helpen de juiste stappen uit te voeren. Hoe strakker het proces hoe goedkoper de medewerker die je in kunt zetten.
Hoe je dit organiseert hangt af van de situatie en de gehele waarde propositie (buzz) naar de klant. In een markt met veel competitie moet je kiezen voor premium (aandacht / maatwerk) of het goedkoopst goed kunnen produceren. In nieuwe markten mag je nog een beetje aanrommelen.
Ha Felix, ik ben wel geinteresseerd maar je bent toch wel een certified professional? En niet te duur? Ik moet eerlijk zeggen goede coaching is nooit weg zodat er voor deze oudere ict-er misschien ook nog kansen zijn. Je moet mee met de tijd.
@Henri Is goedkoper de enige maatstaf? Is kwaliteit niet net zo belangrijk?
Louis, goedkoper is een “driver” voor de business, kwaliteit ook, maar wordt op een ander niveau “gestuurd”. Je BPM borgt de kwaliteit in zichzelf al, de menselijk factor staat hier in de basis namelijk los van. Juist door het proces te formaliseren met BPM kun je het verbeteren, kwaliteit regel je over hele andere “metrics” en moet je in dit geval eruit halen.
Maar goed, hier dieper op in gaan leidt tot een epistel.
Uiteindelijk draait het inderdaad om het resultaat als geheel – dus hetgeen afgeleverd wordt bij de ontvangende partij. Onderscheid maken tussen effectiviteit, efficiency en kwaliteit lijkt me geen goede.
Als de output (het eindproduct) matched met de verwachting (is effectief), de juiste prijs heeft (is efficiënt) maar na een week stuk is (kwaliteit is toch niet goed), dan is het proces misschien wel effectief en efficiënt; inclusief de kwaliteitsaspecten. Maar hoe zit het met de beleving van de ontvangende partij? Denkt die daar ook zo over?
Waar ik het vaak mis zie gaan is dat de data die gebruikt wordt om de effectiviteit, efficiency en kwaliteit van het eindproduct van een proces te bepalen afkomstig is uit het proces zelf – een situatie die je het best kan vergelijken met een bakker die zijn brood moet beoordelen op basis van zijn inspanning rondom het klaarmaken van het deeg en het bakken van het brood.
Met andere worden, data die afkomstig uit het proces zelf is eigenlijk niet geschikt om iets te zeggen over de effectiviteit, efficiency en kwaliteit van het geleverde eindproduct – hooguit zegt het iets over een mogelijke verspilling binnen dat proces.
De enige die hier iets zinvols over kan zeggen is de ontvangende partij. Even vanuit de keten denkend: die doet dat op basis van de volgende “stap/bewerking” van het aangeleverde product (i.e. de input voor het volgende proces).
Misschien wat vaag – daarom een voorbeeld op basis van een IT dienst:
Een veelgebruikte prestatie indicator van het incident management proces is de oplostijd van storingen. De data is afkomstig uit het ticket systeem en is gekoppeld aan de CI’s (de hard- en software) van de technische infrastructuur.
Bij elkaar ziet een veelgebruikte werkwijze er alsvolgt uit:
Als een klant belt met de melding dat iets niet werkt, dan wordt er, na registratie, gestart met een eerste onderzoek naar wat er aan de hand is. Vervolgens komt men tot de conclusie dat (bijvoorbeeld) een stuk hardware het niet goed doet. Vervolgens wordt die hardware vervangen en het incident gesloten.
De oplostijd is dan de tijd die ligt tussen het moment waarop vastgesteld is welk stuk hardware de oorzaak is en het moment waarop dat stuk hardware weer operationeel is.
Bij veel organisaties is degene die belt geen onderdeel van de vergelijking. Terwijl degene die belt zowel het startpunt als de ontvangende partij is van de output van het incidenten proces.
Wat maakt dat hij of zij feitelijk de enige is die kan bepalen of het incident inderdaad gesloten kan worden. Immers, dat ene stuk hardware wat niet goed werkte, dat kan zijn feitelijke oorzaak ergens anders hebben in die infrastructuur keten. Alleen is daar verder nog geen onderzoek naar gedaan.
Afhankelijk van de inrichting van je monitoring systeem kan je daar ook alleen maar achter komen door degene die het gemeld heeft terug te bellen met de vraag of alles weer naar behoren werkt. Pas als deze vraag bevestigend beantwoord wordt kan het incident gesloten worden – althans – zo zou het moeten.
Nu zul je misschien denken “lekker belangrijk”.
Eigenlijk wel – ja. Want dit nuance verschil rondom oorzaak en gevolg heeft een behoorlijke impact op het moment dat de prestaties van een IT organisatie even in het geding is.
Sla je de controle met de meldende partij over, dan kan het gebeuren dat diezelfde partij meerdere keren gaat bellen voor een status update omdat e.e.a. nog steeds niet werkt. Terwijl vanuit het proces gezien het incident alweer gesloten is. Met als gevolg dat, even heel extreem, er bij elk belletje voor een status update een nieuw incident aangemaakt wordt.
Het eindresultaat is dat het incident proces beoordeeld wordt als zeer efficiënt en effectief omdat alle storingen ruim binnen SLA opgelost worden. Maar dat de prestaties van de IT organisatie als geheel negatief beoordeeld wordt omdat de opgeleverde infrastructuur blijkbaar te kampen heeft met heel veel incidenten.
Dag Will,
Uiteraard is alle data belangrijk maar je doet de data van het proces wel heel erg te kort!
Laat ik een paar voorbeelden geven.
Ooit heb ik wel eens een workflow management systeem gebouwd voor een keukenbladen fabrikant. Een van de onderdelen was het behandelen van klachten. Na verloop van tijd hebben we een analyse gedaan op het behandelen van klachten over granieten werkbladen. Wat bleek? Als er bepaalde klachten binnen kwamen over het blad was het direct opnieuw produceren en leveren goedkoper dan een expert langs sturen en alles wat erna komt zoals nieuwe bladdelen leveren. Totaal tegen de intuïtie, maar zelfs de klanttevredenheid ging omhoog (een lang oplostraject mond praktisch altijd uit in een ontevreden klant).
Maar wat je nog meer uit proces data kan halen:
– Performance van medewerkers. Zien waar een medewerker wellicht extra training op nodig heeft
– Effect van proceswijzigingen op doorlooptijd en kwaliteit
– Effect van beslissingen.
Op een gegeven moment zijn we begonnen met het bevestigen van klachten door een “incident” nummer per post en fax te versturen. Kleine moeite, zeer groot plezier. De klacht kon veel sneller worden teruggevonden waardoor het proces veel efficiënter verliep en er minder fouten werden gemaakt.
Uiteraard was vaak de laatste stap om de klant te bellen en vragen of het probleem volledig was opgelost zodat het dossier gesloten kon worden.
Maar zoals je ziet er zit nog een hele wereld achter en alles is belangrijk. Ik ben zelf groot voorstander om processen onder te brengen in een BPM al zitten daar ook nadelen aan zoals omslachtig proces, minder flexibel en dat medewerkers zich vaak lopende band medewerkers voelen. Door slimme dingen toe te passen kun je hier wel wat aan doen, maar BPM heeft ook zijn nadelen.