September 2010
Het creëren en onderhouden van functionaliteit die voldoet aan de behoeftes van de gebruiker tegen acceptabele kosten, is een voortdurende uitdaging. De hierbij steeds vaker toegepaste tools voor Business Process Modelling (BPM) zijn bedoeld om de prestaties bij het leveren van functionaliteit te optimaliseren. Is dat alleen rozengeur en maneschijn of zijn er ook nadelen aan verbonden? SIG heeft verscheidene BPM-implementaties beoordeeld en gemonitord.

 
Dit is wat we daarvan hebben geleerd.

Ten eerste iets over BPM - wat is dat eigenlijk? Tools voor Business Process Modelling bieden de gebruikers de mogelijkheid om hun zakelijke processen te modelleren, om die proces modellen toe te passen en uit te voeren, en om de modellen te verfijnen aan de hand van gegevens over de executie van de modellen. Hierdoor bieden Business Process Modelling-tools transparantie over de organisatieprocessen en is het bovendien mogelijk om de zakelijke processen binnen een grote organisatie te centraliseren en er kwantificaties ten aanzien van de uitvoering aan te koppelen.

Hierbij is de veronderstelling, ofwel de belofte aan de markt, dat de zakelijke processen kunnen worden ondersteund door fit-for-purpose softwaresystemen, zonder dat hierbij de software hoeft te worden aangepast (codering is dus niet nodig).

In werkelijkheid is het echter zo dat de verwachtingen van de gebruikers vaak de mogelijkheden van BPM overstijgen. Denk bijvoorbeeld maar aan een algoritme of een berekening die wordt gebruikt binnen bepaalde klantenprocessen.

Zo’n berekening wil je niet modelleren, maar dient te worden geschreven of te worden geprogrammeerd (gecodeerd). Alle moderne BPM tools ondersteunen die optie, en dus is er nog steeds behoefte aan broncode. Ook binnen BPM architecturen. En dan zijn we dus weer op het punt dat alle gebruikelijke software engineering best practises weer van toepassing zijn.

Bovendien kunnen de modellen die een weergave zijn van de zakelijke processen, zelf ook onnodig ingewikkeld zijn - en daardoor moeilijk te onderhouden. Daar is een logische verklaring voor: de BPM-implementaties beginnen eenvoudig, zolang de processen niet ingewikkeld of uitgebreid zijn. Zo’n eerste succes leidt tot meer vraag en de processen die door BPM worden gedekt nemen vervolgens ook toe in complexiteit. Gedurende dit proces bestaat er het risico dat men zakelijke functionaliteiten gaat opnemen in de BPM-laag, terwijl er misschien beter gekozen kan worden om ze in de onderliggende transactiesystemen onder te brengen.

SIG heeft zich laten inspireren door de “Seven Process Modeling Guidelines” die worden aangeraden door onderzoekers van de Queensland University of Technology en door de TU Eindhoven.

1. Gebruik zo min mogelijk elementen in het model
   De grootte van een model heeft nadelige effecten op de inzichtelijkheid van het model en op de kans op fouten
2. Minimaliseer het aantal routing paths per element
   Hoe hoger de graad van een element in het procesmodel, hoe moeilijker het is om het model te begrijpen
3. Gebruik één start en één end event
   Het aantal start en end events hangt samen met een verhoogde kans op fouten
4. Modelleer zo gestructureerd mogelijk
   Een procesmodel is goed gestructureerd wanneer elke split connector overeenkomt met een respectievelijke join van hetzelfde type
5. Vermijd OR routing elementen
   Modellen die alleen maar AND en XOR connectors hebben, zijn minder gevoelig voor fouten
6. Gebruik verb-object activity labels
   De verb-object stijl, zoals “Inform complainant”, is het minst verwarrend en het informatiefst
7. Splits het model op wanneer het uit 50 of meer elementen bestaat

Wij gebruiken deze richtlijnen als maatstaf om BPM-implementaties te toetsen. Verder hebben we een paar eigen metrieken toegevoegd. Hierdoor krijg je een kwaliteitsmodel dat vergelijkbaar is met de set van software metrics die we gebruiken bij technologieën zoals J2EE, .Net, of ABAP.

We hebben ontdekt dat BPM-implementaties zeer krachtig en nuttig kunnen zijn. Net als voor elke andere technologie geldt dat het het beste is wanneer BPM wordt gebruikt voor het doel waarvoor het is ontworpen. Let er wel op dat u het op de juiste manier toepast! Wanneer uw BPM-implementatie zeer veel scripting bevat, zeer ingewikkeld is of zeer uitvoerige processen bevat, dan lopen de onderhoudbaarheid en de betrouwbaarheid gevaar - dan wordt uw bedrijfsvoering dus niet ondersteund, maar juist verstoord.

Jan Willem Klerkx
Joost Visser

Voor meer informatie kunt u contact opnemen met Joost Visser,