Het is niet ongebruikelijk bedrijfsprocessen onder de loep te nemen om te kijken waar het beter kan. Daarbij ligt de focus nogal eens op het onderzoeken van de mogelijkheden tot automatiseren van bepaalde stappen; soms zelfs op het elimineren van de tussenkomst van de menselijke actor, vaak aangeduid als Straight-Through-Processing (STP).
Een slecht idee? Welnee, maar als de scope beperkt blijft tot automatiseren en niet de vraag wordt gesteld “waar doen we het eigenlijk voor”, dan bestaat het risico om de M (management) van BPM te vergeten. Het automatiseren van het proces of ondersteunen van het proces met technologie is immers geen doel op zich, maar een middel om andere doelen te bereiken. In al het technische geweld sneeuwt dit soms onder. Ik focus me hierbij op bedrijfsprocessen die worden ondersteund met automatisering, maar dezelfde principes gelden ook voor handmatige processen.
Volgens de traditionele definitie richt management zich op het plannen van activiteiten, leiding geven aan de uitvoering en toezien op het werk dat plaatsvindt; dit alles met de intentie om bepaalde doelstellingen te bereiken. De M die wordt vergeten, bevindt zich dus aan beide kanten van het automatiseringstraject: vooraf wanneer doelstellingen worden bepaald en bedacht wordt hoe deze op tactisch niveau te realiseren en achteraf wanneer moet worden bepaald of de doelstellingen zijn gehaald of niet en om te leren hoe zaken kunnen worden verbeterd. Het ontbreken van aandacht voor deze twee fases is te herkennen in het automatiseringstraject.
Geen voortraject:
Te herkennen aan het feit dat er tijdens de realisatie van het automatische proces geen requirements m.b.t. procesinformatiebehoeftes zijn die worden gebruikt of waar vragen over ontstaan. De “metertjes” die nodig zijn om de doelstellingen te halen zijn niet gespecificeerd en worden dus ook niet ingebouwd. Er vindt geen verificatie plaats of de informatie aanwezig en correct zal zijn tijdens de uitvoering van het proces, terwijl de proceseigenaar, de belanghebbende van de informatie, hier uitermate in geïnteresseerd zou moeten zijn.
Geen natraject:
Business case gemaakt, analyses opgesteld, proces geprogrammeerd, schermen gebouwd, gedeployed, phew! Eindelijk zijn we er! Of toch niet? Hoe controleren we nu dat we aan de doelstellingen voldoen? Hoe weten we eigenlijk hoe goed het proces het doet? Wat zijn de doorlooptijden? Waar gaat de meeste tijd in zitten? Deze situatie is te herkennen aan het ontbreken van tools in de automatisering om het proces te volgen (live in de vorm van monitoring of achteraf in de vorm van analyse). Vaak zit veel van deze informatie al in het systeem, maar er wordt tijdens de ontwikkeling te weinig rekening gehouden met het ontsluiten van al die waardevolle kennis om de prestaties te toetsen aan de doelstellingen.
Oftewel, automatiseren is niet genoeg. Vooraf moeten de lastige vragen worden beantwoord wat er bereikt moet worden met het proces en welke informatie nodig is om te bepalen of dat lukt. Tijdens het automatiseringstraject moet die informatie in het systeem worden gebouwd op een eenvoudig te raadplegen manier. Tijdens het uitvoeren van het proces moet die informatie worden benut om te leren hoe de prestaties zijn en om het proces te verbeteren.
Zonder de automatisering van het proces te plaatsen binnen een ruimere context van de doelstellingen zal er weinig worden bereikt. Hooguit een (opnieuw) geautomatiseerde versie van wat er altijd al gedaan werd met dit verschil, dat er nu een systeem is dat de schuld kan krijgen als het niet lekker loopt. En zonder de informatie om te leren kan ook dat niet hard worden gemaakt…
Tiese Barrell, BPM Consultant / JAVA Lead Developer / Gecertificeerd Scrum Master bij Salves