• startpagina
• diensten
• samenwerking
• publicaties
• The Xpragmatic View
• archief
• Snippets of an Incomplete Mind
• auteursrecht
• wettelijke vermeldingen
• nieuws
• over xpragma
• contactinfo

BPM: laat ons de hype vermijden

The Xpragmatic View #52
19 februari 2003
door Marc Buyens (@mbuyens), Xpragma
marc.buyens@xpragma.be
url: http://www.xpragma.be/view52.php
Downloaden als een PDF-file

Sinds enige tijd kan BPM (Business Process Management) zich duidelijk verheugen in een toenemende belangstelling. Een aantal belangrijke analisten, om Gartner niet bij naam te vernoemen, prediken in toenemende mate het belang van BPM als zijnde een sleutelaanpak en -technologie voor de komende jaren. De reactie van de mogelijke leveranciers laat dan ook niet op zich wachten.

Het is het voorbije halfjaar relatief kalm geweest wat betreft de introductie van nieuwe IT-oplossingen en functionaliteit. Toch kunnen we actueel vaststellen dat een resem van (bestaande) oplossingen plots op magische wijze de grote enablers geworden zijn voor BPM. Het aantal publicaties en seminaries dat sinds de jaarwissel opdook rond dit thema is al niet lang meer te tellen. Ondertussen heeft zowat iedereen ook de mogelijke link ontdekt tussen BPM en Web Services, dus de hype kan volop beginnen.

Ik kan natuurlijk enkel maar toejuichen dat het belang van BPM meer en meer onderkend wordt. Maar ik vrees dat hier en daar de complexiteit van de opdracht toch grondig onderschat wordt. Ik denk daarbij in de eerste plaats aan de "traditionele" EAI-leveranciers. Zowal allen prediken ze ondertussen de kwaliteit van hun aanbod als dé technologie om aan procesbeheer te doen, zonder zich daarbij al te zeer af te vragen of hun aanpak en de gebruikte architectuur eigenlijk wel een gepaste oplossing bieden voor de fundamentele uitdagingen van BPM.

Natuurlijk zijn er heel wat punten waar een EAI-infrastructuur een wezenlijke bijdrage kan en zal leveren voor het oplossen van deze problematiek, maar we moeten toch vaststellen dat de meeste leveranciers vrij oppervlakkig zijn bij het kritisch analyseren van het eigen aanbod.

Toen ik in 1999 mijn eerste EAI Status Report publiceerde, gebruikte ik daarin reeds het volgende eenvoudige architectuurplaatje:

 

 

Op dat ogenblik was het integratieaanbod in essentie beperkt tot de onderste twee lagen. Sindsdien is dit aanbod wel fundamenteel geëvolueerd en kunnen we spreken van een zekere mate van invulling van de hogere lagen. Zo zullen de meeste producten een of andere vorm van ondersteuning van web services geven (wat men in theorie zou kunnen zien als een invulling van de component laag). De realiteit is echter dat deze invulling vaak niet veel verder gaat dan een soort veredelde adaptertechnologie die dus eerder twee lagen lager zit.

De business process laag wordt door een aantal leveranciers ook zwaar gepromoot in hun marketing literatuur, maar ook daar is de invulling vaak beperkt tot de design en de aansturing van de procesgedeelten die een rol spelen in de eigenlijke integratieopdracht. Met andere woorden, het blijft vaak beperkt tot het aanleveren van een gebruiksvriendelijke interface voor het configureren van de adapters in de onderliggende lagen.

Ook denk ik dat we zeer kritisch moeten kijken naar de architectuur van deze producten. De meeste broker suites zijn gebaseerd op concepten die wel degelijk pasten bij de toenmalige integratieopdracht (het vermijden van de n-to-n integratiespaghetti, het gebruiken van centrale functies zoals transformatie, e.d. ), maar is dit de juiste aanpak voor BPM? Denken we bv. maar aan de complexiteit van het beheren van langlopende transacties. Denken we aan de uitdagingen die gesteld worden door de steeds verder reikende gedistribueerde omgevingen. Denken we aan de noodzaak voor decentrale controle en beheer.

Daarnaast is er dan de grote groep van workflow- en native BPM-leveranciers. Vaak zijn zij gespecialiseerd in een specifiek domein of een type problematiek of hebben ook zij een "geëvolueerd" aanbod waarvan de roots ergens anders liggen (bv. documentbeheer).

Allen geven zij een gedeeltelijke invulling van de globale problematiek van BPM, maar vooralsnog is er geen zicht op een aanpak die echt in staat is de enterprise-wide BPM problematiek op te lossen. Voorlopig blijft het dus behelpen met een combinatie van diverse benaderingen en oplossingen.

Zo zou de ARIS ^[1] oplossing van IDS Scheer misschien wel eens een goede aanvulling kunnen zijn voor de ondersteuning van je BPM behoeften op het vlak van procesinfrastructuur. Maar voor de ondersteuning van procesgericht denken op strategisch vlak zou dan weer een tool zoals ProVision ^[4] een beter hulpmiddel kunnen zijn. Als je behoeften dan weer eerder liggen op het vlak van echte process discovery, dan moet je misschien eerder kijken naar een oplossing zoals ProActivity ^[3].

Je ziet het, de "beste" keuze maken is niet zo maar een voor de hand liggende opdracht. Bedrijven staan steeds huiverig t.o.v. de idee van meerdere "gelijksoortige" producten te gebruiken. Maar eigenlijk is er geen alternatief. Er zijn immers nauwelijks echt gelijksoortige producten. Allen hebben ze wel ergens een écht sterk punt dat hen onderscheidt van de concurrerende producten. Jammer genoeg zit deze core competence vaak verborgen temidden van andere, eerder middelmatige of oppervlakkige functionaliteit die het product laten opgaan in de groep van "algemene" BPM oplossingen. Wellicht een poging tot verruiming van de doelmarkt, maar leveranciers zouden er m.i. beter aan doen een duidelijke focus in hun productaanpak te behouden en dergelijke focus ook duidelijk zichtbaar te maken in hun marketing aanpak.

Een combinatie van meerdere technologieën en oplossingen dringt zich dus op. Groot struikelblok blijft daarbij echter het ontbreken van reële standaarden, zeker wanneer we het hebben over extra-company BPM.

Natuurlijk is er geen gebrek aan standaarden of benaderingen, alleen is er actueel nog niet zoiets als een de-facto BPM-standaard à la XML. BPMI.org ^[2] kan hier misschien een belangrijke rol spelen, maar we moeten ons weer de vraag stellen of we hiermee het probleem hebben opgelost. Gaan we hier niet te zeer in de richting van procesbenaderingen zoals SCOR ^[5] die wel een basis leggen voor een beter procesbegrip, een gemeenschappelijke taal en een basis voor interoperabiliteit, maar gaat men hierbij ook niet al te veel in de richting van uniformiteit, gelijkvormigheid en afwezigheid van competitief onderscheid? We bereiken hiermee misschien wel een omgeving die ons toelaat onze (ook reeds uniforme) ERP-infrastructuur op een meer dynamische manier te benaderen, maar geeft dit ons business agility? Of blijft het beperkt tot de vlotte herconfiguratie van een ERP-pakket?

Ook moeten we beseffen dat al deze BPM-benaderingen nog steeds in belangrijke mate zich beperken tot het beheer van de eigenlijke uitvoering van bedrijfstaken en het beheersen van de gegevensstroom die hiermee gepaard gaat. Maar dit is slechts een subset van wat we onder de noemer "bedrijfsprocessen" moeten verstaan. Waar past in dit alles het beheersen van de échte klanteninteractie? Hoe gaan we hierbij om met strategische verandering en innovatie? Hoe ver mogen we gaan met het beheersen van processen om niet te vervallen in het verstarren van processen?

Veel vragen dus waarvoor ook ik niet altijd het antwoord beschikbaar heb. Daarom vrees ik dat we nog een tijdje met heel wat "pseudo-BPM" zullen te maken hebben in afwachting van een meer fundamentele doorbraak. Die zou kunnen geïnitieerd worden door het samengaan van een aantal complementaire spelers. Het huidige economische klimaat is echter in niet-geringe mate een rem op dergelijke ontwikkelingen en op de introductie van radicaal nieuwe ideeën en concepten. Toch blijf ik er van overtuigd dat we vroeg of laat verplicht zullen zijn de actuele benaderingen grondig in vraag te stellen om op een veel fundamentelere manier de belofte van BPM aan te pakken en hopelijk te realiseren. We zien wel...

Tags: business process management (BPM)

 

comments powered by Disqus