Hoewel business process management (bpm) nooit zo’n enorm hoge piek in de hype-curve heeft gehad, is het ook daar tijd voor 'het dal der desillusie'. Met andere woorden, het is tijd om realistisch te kijken naar wat er met de inzet van een business process management suite (bpms) mogelijk is, om straks ook met redelijke verwachtingen door te gaan naar een acceptabel productiviteitsniveau. Vraag 1: Hoe zit het met de belofte dat inzet van een bpms leidt tot meer flexibiliteit en wendbaarheid?
Voor de lezers die wat minder bekend zijn met de begrippen bpm en bpms, hier een korte samenvatting wat de analisten en leveranciers in deze markt claimen en sommigen gebruikersorganisaties maar al te graag geloven:
1. De bedrijfsprocessen kunnen worden gemodelleerd door een businessanalist die niets van techniek hoeft te snappen.
2. Doe het in een tekentool, want daarna kun je dat bedrijfsproces met een 'druk op de knop', of, als antwoord op de vraag om deze knop te laten zien, 'met geringe inspanning' omzetten in een werkend systeem waarmee dat proces kan worden ondersteund.
3. Je bent daardoor niet meer afhankelijk van programmeurs…
4. En dus zul je veel sneller kunnen reageren op vragen vanuit de business.
Voor hen die dit geloven wil ik graag kort samenvatten welke misvattingen er aan dit verhaal ten grondslag liggen:
1. Het proces zoals een businessanalist dat kent en modelleert is een versimpeling van de werkelijkheid. In dit model ontbreken uitzonderingen, foutafhandeling, technische koppelingen en heeft iedere betrokken medewerker altijd alle benodigde informatie en neemt deze ook de juiste beslissingen. Dit model is zeker niet voldoende als je het proces wilt implementeren.
Er moeten nog heel veel details toegevoegd worden om dit proces ooit zodanig te implementeren dat het de medewerkers feitelijk ondersteund.
2. Eigenlijk is het best naïef om te denken dat het ondersteunen van een complex proces kan vanuit een procesmodel dat 'met geringe inspanning' is omgezet naar een executeerbaar proces.
De demonstraties waarin men jou dit laat dien door een webservice op een activiteit te slepen en dan na wat snelle muiskliks (data mapping) laat zien dat 'het werkt', zijn in die zin leugenachtig.
Bij elke procesimplementatie, of je dat nu implementeert met een bpms of niet, zul je de volgende aspecten moeten ontwerpen:
– Welke gegevens moeten geregistreerd/vastgelegd worden?
– Welke koppelingen met andere systemen moeten er gelegd worden?
– Vaststellen welke gebruikers/medewerkers een rol spelen.
– De gebruikersinteractie moet ontworpen worden, inclusief de schermen voor elke processtap uitgevoerd door een medewerker.
– Er moet nagedacht worden over dat deel van de processen waar men behoefte heeft aan aanpasbaarheid door een functioneel beheerder en daarom gebruik gemaakt zal worden van extra hulpmiddelen als een business rule engine of iets dergelijks.
– Er moet bepaald worden welke stuurinformatie de procesmanager nodig heeft om de processen waarvoor hij verantwoordelijk is te bewaken en besturen.
Wat hier wordt aangenomen is dat 'het proces' helder is. Als je naar bestaande, niet door een tool ondersteunde processen kijkt, blijkt vaak dat er vele varianten en uitzonderingen zijn waar medewerkers zonder probleem mee om gaan. Tevens is er vaak sprake van inefficiënties. Wellicht het grootste risico is om de huidige processen met al hun varianten en inefficiënties te automatiseren. Maar daarover later meer!
Al met al een significante inspanning, waarbij veel moet gebeuren dat in het verhaal van de analisten en leveranciers nauwelijks aan bod komt.
3. Om al het bovenstaande daarna in het bpms te implementeren vraagt ervaren technische medewerkers en veel inspanning. Wellicht wordt er minder gedaan door 'echte' (Java of .NET) programmeurs, maar er moet toch geprogrammeerd worden, in andere, minder bekende talen (XSL, XPath, XQuery, BPEL, JavaScript, etc.). Om dit configureren te noemen in plaats van programmeren is misschien politiek wel handig, maar daarmee hou je uiteindelijk jezelf en anderen voor het lapje.
Uiteindelijk wil je met de implementatie van bpm meer flexibiliteit. De vraag is in hoeverre dat in de praktijk ook zo is.
Allereerst, uiteraard is het duidelijk krijgen van wat de business nu eigenlijk wil, en bepalen waar dat impact heeft niet triviaal, en zal de nodige tijd kosten. Daarna zullen de gevraagde aanpassingen moeten worden gemaakt, en dat zal tijd kosten, geheel afhankelijk van wat er wordt gevraagd. Maar voor de aanname dat dit met een bpms sneller gaat dan met een willekeurige andere technologie, is geen onderbouwing. Als laatste, ook een procesaanpassing gaat door een kwaliteits- en testcyclus van O naar T naar A naar P. Daarmee is er geen verschil meer tussen een bpm- en een niet-bpm-aanpak.
Ik wil met bovenstaande verhaal niet zeggen het geen zin heeft om te kiezen voor een bpms. Maar als je verhoogde flexibiliteit zoekt, verwacht dan niet dat het bpms je daarmee gaat helpen.
Volgende keer wil ik ingaan op hoe je deze flexibiliteit dan wel kunt bereiken.
Wat in het stuk niet aan bod is gekomen is de historie en waarom Business Process Management Suites zijn ontstaan.
Eén van de redenen daarvoor was de situatie die ontstond na de implementatie van ERP pakketten, waarbij de processen “verstopt” zaten in de applicatie, en dus niet aanpasbaar waren, of alleen tegen zeer hoge kosten aangepast konden worden. Dit was de tijd van Business Process Redesign, waarin bedrijfsprocessen wel werden gemodelleerd, maar uiteindelijk vertaald werden in configuratie van het ERP pakket waar nodig in combinatie met maatwerk.
De behoefte om meer grip te krijgen op de bedrijfsprocessen was een van de triggers voor het ontstaan van Business Process Management Suites, die door het expliciete modeleren van de bedrijfsprocessen en meer direct gebruik van dit procesmodel in de uitvoering van de bedrijfsprocessen aan deze wens tegemoet lijken te zijn gekomen.
Technisch gezien vereist dit nog steeds complexe configuratie en duur maatwerk, nu niet in het ERP pakket, maar in de BPMS tool, en voor de vereiste koppelingen met de aangestuurde pakketten. Ik heb nooit bewijs gezien dat dit geleidt heeft tot meer flexibiliteit.
Mijn conclusie blijft daarom hetzelfde: Verwacht niet dat de inzet van een BPMS je meer flexibiliteit gaat opleveren!
Tsja, als je alles met een oude bril bekijkt, gaat er nooit iets veranderen. Het is duidelijk dat de auteur geen ervaring heeft met de inzet van echte BPMS-tools, want dan had hij geweten dat zijn punten over testen, uitzonderingen modelleren etc etc in de huidige generatie BPMS-tools wel degelijk mogelijk is. Maar ja, dat is dan ook de makke van de huidige generatie “ICT experts”, gebrek aan visie en aan kennis houdt alles bij het oude.
Tom,
Bedankt voor je reactie. Kun je aangeven welke echte BPMS-tools je bedoeld? Kun je toelichten hoe tegemoet komen aan deze aspecten?
Tom,
ik zit zelf al 20 jaar in het vak en heb met heel veel “echte” BPM-tools gewerkt. Theo heeft wel degelijk een punt. Het idee van vele tools is dat door makkelijk modelleren, in flight veranderingen en executeerbare modellen de fase van testen en acceptatie overbodig zijn geworden, is in de praktijk gewoon niet realistisch. Misschien in een kleine omgeving met enkele tientallen gebruikers, maar in complexe heterogene omgevingen komt zoveel meer kijken dat niet zomaar in een procesmodelletje is te vangen. Complexe integraties, decentrale diversificatie, balanceren tussen borging en vrijheid, etc. Zelfs het puur functioneel bepalen van de grenzen en inrichting van processen vereist vaak grondige analyse, afstemming, protoyping en testen. Dat is inherent aan een zorgvuldige bedrijfbrede inrichting van BPM en heeft niets met de tools te maken.
Maar laten we deel 2 afwachten, want daar presenteert Theo ons de oplossing 🙂