Valkuilen bij het modelleren van bedrijfsprocessen

Bedrijfsprocessen vormen het hart van elke organisatie. Foutieve of inefficiënte processen kunnen desastreuze gevolgen hebben. Met procesmodellering is dit te ondervangen, mits gestoeld op twee eisen: ‘expliciete modellering van toestanden’ en ‘goede analysetechnieken’. Hoewel een goede standaard nog ontbreekt, vormt een techniek op basis van Petri-netten een uitstekend uitgangspunt, stellen twee experts van de TU Eindhoven en van Consultdata.

Tot voor kort werden informatiesystemen vooral gebruikt ter ondersteuning van individuele taken. Het komt echter steeds vaker voor dat een informatiesysteem het bedrijfsproces zelf moet ondersteunen. Het gaat hierbij vooral om de logistieke besturing van het proces: het informatiesysteem bepaalt welke taken er uitgevoerd moeten worden, in welke volgorde en door wie. De grote belangstelling voor ‘business process reengineering’ (bpr), ‘workflow management’ (wfm) en ‘continuous process improvement’ (cpi), illustreert het feit dat steeds meer organisaties het bedrijfsproces zelf centraal stellen. Tot voor kort waren er echter weinig generieke gereedschappen voor het ondersteunen van de logistieke besturing van bedrijfsprocessen. Hierdoor zijn er veel informatiesystemen gebouwd waarin het proces verborgen is in de code van de diverse applicaties. Indien bijvoorbeeld twee taken na elkaar uitgevoerd moeten worden, stuurt de applicatie ter ondersteuning van de ene taak een signaal naar de applicatie ter ondersteuning van de andere taak. De ene applicatie moet dus op de hoogte zijn van het bestaan van de andere. Dit is niet gewenst, omdat het niet mogelijk is het onderliggende bedrijfsproces aan te passen zonder ook de applicaties aan te passen.
Er zijn meer nadelen verbonden aan het ‘verstoppen’ van het bedrijfsproces in de applicaties. Zo is het niet mogelijk om op een generieke manier managementinformatie te verzamelen en het proces bij te sturen. Ook worden stukjes functionaliteit op meerdere plaatsen gerealiseerd en wordt hergebruik onvoldoende ondersteund.

Procesgeoriënteerd

De afgelopen vijf jaar is er gelukkig een aantal gereedschappen op de markt gekomen ter ondersteuning van bedrijfsprocessen. Voor de administratieve organisatie zijn er workflowmanagement-systemen ontwikkeld. Een wfm-systeem is een pakket ter ondersteuning van het ontwerp, de analyse, de besturing, de registratie en de uitvoering van werkstromen. Banken, verzekeringsmaatschappijen en overheidsinstellingen zijn de organisaties waar dergelijke systemen op dit moment worden toegepast. Ook voor de meer industriële omgevingen zijn gereedschappen ontwikkeld ter ondersteuning van de logistieke besturing van bedrijfsprocessen. In deze omgevingen worden vaak systemen voor enterprise resource planning (erp) gebruikt, zoals SAP en Baan. Ook deze erp-systemen leggen steeds meer de nadruk op het ondersteunen van werkstromen. Het is geen toeval dat juist nu het aanbod van procesgeoriënteerde gereedschappen groot is: bedrijfsprocessen worden steeds complexer en nemen in aantal toe. Ook de snelheid waarmee de processen veranderen is enorm gestegen.
Kijkend naar de huidige generatie wfm- en erp-systemen zien we dat een grote variëteit aan procesmodelleringstechnieken gebruikt wordt. De meeste systemen hanteren een eigen, productspecifieke techniek om de processen in kaart te brengen. Dit brengt veel gevaren met zich mee. In de eerste plaats is het voor de gebruiker moeilijk om de systemen met elkaar te vergelijken en om van het ene systeem naar het andere systeem over te stappen. In de tweede plaats is de uitdrukkingskracht van de gebruikte technieken vaak beperkt. Hierdoor is het niet mogelijk om bepaalde constructies te gebruiken. Ook hangt het voortbestaan van de procesmodelleringstechniek af van het productbeleid van de leverancier. Tenslotte is de grote variëteit rampzalig voor het uitwisselen van informatie tussen de diverse systemen. Een procesontwerp dat is gemaakt met het ene systeem kan niet gebruikt worden in het andere. De systemen kunnen ook niet samenwerken binnen één bedrijfsproces. Ondanks de inspanningen van organisaties zoals de Workflow Management Coalition (WfMC) ontbreekt op dit moment een standaard voor het modelleren van bedrijfsprocessen. De in ontwikkeling zijnde standaarden richten zich vooral op de technische aspecten (syntaxis) en niet op de concepten die aanwezig moeten zijn en de betekenis van deze concepten (semantiek).
Dit artikel concentreert zich op twee belangrijke eisen waaraan een procesmodelleringstechniek moet voldoen. Enerzijds moeten toestanden expliciet gemodelleerd worden. Verder zijn goede analysetechnieken essentieel. Beide aspecten worden in de huidige generatie systemen ter ondersteuning van bedrijfsprocessen vaak onderbelicht. De hier gedane constateringen zijn niet alleen geldig voor wfm-systemen, maar ook voor andere systemen ter ondersteuning van bedrijfsprocessen, zoals erp-systemen.

Het belang van ’toestanden’

In een bedrijfsproces moeten er voor elke casus, zoals een bestelling of een verzekeringsclaim, taken worden uitgevoerd, bijvoorbeeld ‘controleer polisgegevens’. Met behulp van een procesmodelleringstechniek is aan te geven welke taken er uitgevoerd moeten worden en in welke volgorde. We spreken in dit verband ook wel over routering. De WfMC onderkent de volgende routeringsvormen: sequentiële, parallelle, conditionele en iteratieve routering. De meeste wfm-systemen ondersteunen deze vier routeringsvormen. Figuur 1 toont twee vormen van routering: parallelle en conditionele routering. In het eerste geval worden na de uitvoering van taak A zowel de taken B als C uitgevoerd. Deze mogen in willekeurige volgorde plaats hebben, met daarna taak D.

Figuur 1. Twee routeringsvormen.

Taak A wordt ook wel een ‘and-split’ genoemd omdat er twee parallelle stromen gestart worden. Taak D is een ‘and-join’ en zorgt voor de synchronisatie van beide stromen. Bij de conditionele routering wordt gebruik gemaakt van een ‘or-split’ (taak A) en een ‘or-join’ (taak D). In dit geval wordt óf taak B óf taak C uitgevoerd. De meeste wfm-systemen maken gebruik van een techniek die overeenkomsten vertoont met de processchema’s uit figuur 1. Nauwkeurige beschouwing van de figuur leert dat de toestanden van de casus tussen de uitvoering van de diverse taken niet expliciet gemodelleerd worden. Het schema richt zich uitsluitend op de ordening van taken en abstraheert, net zoals de meeste wfm-systemen, tussentoestanden. Voor het modelleren van bedrijfsprocessen is het expliciet onderkennen van toestanden echter van het grootste belang. Er is een aantal goede redenen voor het expliciet modelleren van toestanden. In de eerste plaats hebben toestanden meestal een duidelijke betekenis die helder en zinvol is voor de personen die participeren in het proces. Een bestelling kan bijvoorbeeld in de toestand ‘geaccepteerd’ zijn; bepaalde taken mogen alleen uitgevoerd worden indien de bestelling in deze toestand is. Met name in omgevingen waar men te maken heeft met stringente regelgeving is het onderkennen van toestanden zinvol. Binnen veel overheidsinstellingen heeft men bijvoorbeeld te maken met wettelijke toestanden. Ook vanuit een logistiek standpunt is het onderkennen van toestanden van belang. De doorlooptijd van een casus is vaak vele malen groter dan de tijd die feitelijk besteed wordt aan de casus. Het afhandelen van een belastingaangifte kost bijvoorbeeld weken terwijl de feitelijke bedieningsduur misschien maar enige minuten is. Dit betekent dat een casus meestal in rusttoestand is. Het is dus merkwaardig om juist dit aspect niet expliciet te modelleren. Ook zijn bepaalde routeringsvormen niet of moeilijk te modelleren indien men abstraheert van toestanden. Twee voorbeelden lichten dit toe.

Triggering

In figuur 2 zijn de toestanden expliciet weergeven door middel van cirkels. Zowel situatie (a) als situatie (b) modelleren een keuze tussen de taak ‘behandel_aangifte’ en de ’taak stuur_herinnering’.

Figuur 2. Twee verschillende vormen van conditionele routering.

In situatie (a) wordt direct na de uitvoering van de taak ‘stuur_aangifte’ beslist of de taak ‘behandel_aangifte’ of de taak ‘stuur_herinnering’ uitgevoerd moet worden. Is de casus na uitvoering van ‘stuur_aangifte’ in toestand ‘wacht_op_aangifte’, dan wordt ‘behandel_aangifte’ uitgevoerd, anders ‘stuur_herinnering’ . We zeggen ook wel dat ‘wacht_op_aangifte’ een preconditie is voor ‘behandel_aangifte’ en dat ‘wacht_op_einde_termijn’ de preconditie voor ‘stuur_herinnering’ is. In situatie (b) wordt de keuze later gemaakt. Na uitvoering van de taak ‘stuur_aangifte’ is de casus in toestand ‘wacht’ waarna zowel de taak ‘behandel_aangifte’ als de taak ‘stuur_herinnering’ nog tot de mogelijkheden behoren. Het verschil tussen de expliciete ‘or-split’ in (a) en de impliciete ‘or-split’ in (b) lijkt heel subtiel, maar is van wezenlijk belang. Zoals in figuur 2 schematisch is weergegeven, wordt de taak ‘behandel_aangifte’ getriggerd door een extern bericht. De taak ‘stuur_herinnering’ wordt getriggerd op een bepaald tijdstip. Doordat de omgeving invloed kan uitoefenen op de keuze tussen twee taken, is het moment van keuze van belang. In situatie (a) wordt meteen na het versturen van de aangifte reeds bepaald of men gaat wachten totdat de aangifte wordt geretourneerd of dat men na verloop van tijd een herinnering stuurt. In situatie (a) wordt de keuze tussen ‘behandel_aangifte’ en ‘stuur_herinnering’ te vroeg gemaakt. Men kan immers niet van te voren met zekerheid bepalen of de persoon in kwestie op tijd zijn aangifte retourneert. In situatie (b) wordt door het onderkennen van een neutrale tussentoestand ‘wacht’ de keuze pas gemaakt op het moment dat de aangifte arriveert of dat de tijd verstreken is. Dit voorbeeld laat zien dat alleen door het onderkennen van toestanden het onderscheid tussen impliciete en expliciete keuzes te maken is. In figuur 1b, waar geabstraheerd wordt van toestanden, is dat niet mogelijk. Wfm-systemen die abstraheren van tussentoestanden kunnen dan ook veelvuldig voorkomende constructies zoals afgebeeld in figuur 2b alleen via een omweg of alleen in speciale gevallen ondersteunen.

Figuur 3. Een proces voor het afhandelen van klachten.

Figuur 3 laat een ander proces zien dat moeilijk te modelleren is zonder de toestanden expliciet te maken. Het fictieve proces modelleert het afhandelen van klachten. Na het uitvoeren van de taak ‘registreer’ wordt er parallel gewerkt aan het versturen en verwerken van een klachtenformulier en het evalueren en verwerken van de klacht. Indien de indiener van de klacht niet op tijd het formulier terugstuurt, wordt de taak ’time-out’ uitgevoerd. Ook hier is weer sprake van een impliciete keuze tussen twee taken die moeilijk te modelleren zijn zonder het onderkennen van de toestand c3. Voor het verwerken van de klacht ’taak verwerk_klacht’ moet er voldaan zijn aan twee voorwaarden: a) de casus is in toestand c5 (de afhandeling van het formulier is afgerond) en b) de casus is in toestand c4 (de klacht moet daadwerkelijk verwerkt worden). In dit geval fungeert c5 als een soort van mijlpaal. Ook het modelleren van mijlpalen is niet mogelijk zonder het expliciet opnemen van toestanden in het procesmodel.
Het expliciet onderkennen van toestanden is ook van belang zodra wfm-systemen gaan samenwerken. Voor het overhevelen van een casus van het ene naar het andere systeem is het immers noodzakelijk dat de toestand op een eenduidige wijze geëxporteerd kan worden.

Analyse van werkstromen

Bedrijfsprocessen vormen het hart van elke organisatie. Daarom is het van groot belang dat deze processen zorgvuldig ontworpen worden. Een foutief of inefficiënt proces heeft desastreuze gevolgen voor het succes van de organisatie. WFM-systemen maken het mogelijk om in korte tijd bedrijfsprocessen te veranderen en in te voeren. Om dit op een verantwoorde manier te doen moeten processen voor invoering grondig geanalyseerd worden. We maken hierbij onderscheid tussen drie soorten analyses: (1) validatie, (2) verificatie en (3) prestatie-analyse. Een bedrijfsproces wordt gevalideerd door proefondervindelijk vast te stellen of het proces correct gemodelleerd is. Bij validatie worden een aantal typische cases doorlopen. Dit kan met pen en papier of met een proefopstelling waarin een wfm-systeem gebruikt wordt. Validatie wordt vooral gebruikt om vast te stellen of de werking van het proces overeenkomt met het verwachtingspatroon van de gebruikers. Dit neemt niet weg dat er nog fouten in het ontwerp kunnen zitten. Het kan bijvoorbeeld zo zijn dat er in uitzonderlijke gevallen ‘deadlocks’ of impasses kunnen optreden (waardoor het hele proces stil komt te liggen) of dat bepaalde taken nooit uitgevoerd kunnen worden. Daarom is een verificatie van het procesmodel nodig. Het model is succesvol geverifieerd als het volledig gecontroleerd is op logische fouten. Een proces zonder logische fouten kan nog steeds inefficiënt zijn. Daarom is een prestatie-analyse nodig om te onderzoeken of er knelpunten in het procesontwerp zitten die leiden tot lange doorlooptijden of een ineffectieve inzet van capaciteit. De huidige generatie wfm-systemen biedt slechts beperkte mogelijkheden voor verificatie en prestatie-analyse. Vaak worden er, behoudens enkele triviale consistentiecontroles, nauwelijks mogelijkheden tot verificatie geboden. Bij prestatie-analyse wordt meestal volstaan met een ruwe simulatiemogelijkheid. Vanwege deze beperkingen in het kort iets over de eisen ten aanzien van verificatie en prestatie-analyse.
Elk bedrijfsproces moet voldoen aan een aantal basisvoorwaarden. Zo heeft elk proces waarin een casus afgehandeld wordt een begin- en eindpunt. Elke casus die start in het beginpunt moet na verloop van tijd terechtkomen in het eindpunt. Op het moment dat het eindpunt bereikt is, moet de casus volledig afgehandeld zijn. Ook mogen er geen ‘dode’ taken zijn, dat wil zeggen taken die nooit uitgevoerd kunnen worden. Voor verificatie is het nodig dat bewezen kan worden dat het proces deze essentiële eigenschappen bezit.
De prestatie-analyse van een proces richt zich op een aantal prestatie-indicatoren zoals gemiddelde doorlooptijd, gemiddelde wachttijd, gemiddelde bewerkingstijd, gemiddelde bezettingsgraad, en het percentage dat binnen een bepaalde tijd kan worden afgehandeld (serviceniveau). Met behulp van simulatie of meer geavanceerde technieken uit de Operations Research (OR) kunnen deze prestatie-indicatoren bepaald worden. Merk op dat het voor deze vorm van analyse noodzakelijk is om ook het gedrag van de omgeving (bijvoorbeeld de klantvraag) te modelleren.

Petri-net is actief en passief

Zoals aangegeven schieten de meeste wfm-systemen tekort als het gaat om het modelleren van toestanden en het analyseren van bedrijfsprocessen. Deze tekortkomingen zijn voor een belangrijk deel terug te voeren op de gebruikte procesmodelleringstechnieken. In de meeste wfm-systemen is gekozen voor een zelf ontwikkelde tekentechniek, die proefondervindelijk is vastgesteld en vaak de sporen van het verleden draagt. Daarom zijn deze tekentechnieken meestal beperkt toepasbaar en bieden zij constructies waarvan de betekenis onder bepaalde omstandigheden onduidelijk is. Gelukkig bestaat er een procesmodelleringstechniek die wel tegemoet komt aan de eerder genoemde bezwaren. Het betreft een techniek op basis van Petri-netten. De processchema’s afgebeeld in de figuren 2 en 3 zijn voorbeelden van Petri-netten.
Een Petri-net bestaat uit actieve en uit passieve componenten. De actieve componenten worden meestal transities genoemd en de passieve componenten meestal plaatsen. In de context van workflowmanagement is het echter beter om over taken en condities te spreken. Elke taak wordt voorgesteld door een vierkant en een conditie door een cirkel. Door een Petri-net stromen tokens. Een token wordt voorgesteld door een zwarte stip. Indien een conditie een token bevat, dan betekent dit dat er aan de conditie is voldaan. In figuur 3 geeft het token in conditie start aan dat een nieuwe klacht binnengekomen is. Omdat start de enige input-conditie van de taak ‘registreer’ is, kan deze taak plaatsvinden. Nadat de taak registreer heeft plaatsgevonden ligt er zowel een token in conditie c1 als in conditie c2. In ‘parallel’ kunnen nu de taken stuur_formulier en evalueer uitgevoerd worden. Nadat het formulier verstuurd is ligt er een token in c3 en wordt na verloop van tijd één van de taken verwerk_formulier en time-out uitgevoerd. Indien na evaluatie blijkt dat de klacht verwerkt moet worden ligt er een token in conditie c4. De taak verwerk_klacht wordt pas uitgevoerd nadat er zowel in c4 als c5 een token ligt. Na het verwerken van de klacht wordt het token in c5 teruggelegd en wordt via conditie c6 de taak controleer_verwerking aangestuurd. Indien de klacht goed verwerkt is, komt er een token in conditie te liggen. Indien de verwerking nog te wensen overlaat wordt via conditie c4 een additionele verwerkingsstap geïnitieerd. Taak archiveer kan pas uitgevoerd worden op het moment dat er een token in c5 en c7 ligt. Uiteindelijk komt er een token in conditie einde te liggen en is de klacht volledig afgehandeld.
Met een Petri-net kunnen alle gangbare routeringsvormen worden beschreven. In figuur 3 zijn bijvoorbeeld sequentiële, parallelle, conditionele en iteratieve routering aanwezig. Ook is het mogelijk toestanden te onderkennen en kan het verschil tussen de impliciete en expliciete OR-split duidelijk aangegeven worden.
Petri-netten vormen een beproefde techniek. Sinds de zestiger jaren worden Petri-netten toegepast voor het modelleren van processen en is er erg veel onderzoek gedaan naar de fundamenten van deze procesmodelleringstechniek. Het Petri-net combineert een grafische en intuïtieve beschrijvingswijze met een stevige wiskundige fundering. In tegenstelling tot veel andere technieken worden toestanden expliciet gemodelleerd. Ook zijn er vele analysetechnieken en gereedschappen beschikbaar. Deze analysetechnieken maken het bijvoorbeeld mogelijk om bedrijfsprocessen te verifiëren op basis van vele correctheidseisen. Indien in figuur 2 bijvoorbeeld de condities c5 en c7 samengevoegd worden, kan op basis van de structuur van het Petri-net de gemaakte fout geconstateerd worden. Indien de taak ’time-out’ verbonden wordt met de taak verwerk_klacht via een additionele conditie, dan kan met behulp van standaard analyse-gereedschappen voor Petri-netten aangetoond worden dat het workflow-proces een potentiële ‘deadlock’ bevat. Deze impasse treedt op indien de klacht inhoudelijk verwerkt moet worden en het formulier op tijd is geretourneerd. De klacht komt dan vast te zitten in de toestand waarbij er een token in zowel c4 als c5 zit.

Geïntegreerde gereedschappen

De toepassing van Petri-netten in de context van wfm is uitvoerig beschreven in het boek van W.M.P. van der Aalst and K.M. van Hee [1]. De daarin beschreven aanpak is reeds meerdere malen in de praktijk met succes toegepast (bijvoorbeeld de Belastingdienst, ABN-Amro en de Postbank). Sinds kort wordt de aanpak ook ondersteund door een geïntegreerde verzameling gereedschappen.
Protos (Pallas Athena) is een bpr-gereedschap waarmee bedrijfsprocessen op een eenvoudige wijze gemodelleerd kunnen worden in termen van Petri-netten. Daarnaast is mogelijk om gemodelleerde bedrijfsprocessen te exporteren naar Cosa, Exspect en Woflan.
Het gereedschap van Cosa Solutions/Software Ley is een volledig wfm-systeem met de mogelijkheid om bedrijfsprocessen te ontwerpen, te besturen, te volgen en te ondersteunen in de uitvoering. Het wordt op diverse plaatsen in Nederland toegepast en kenmerkt zich door sterke procesmodelleringsfaciliteiten.
Exspect (Bakkenist Management Consultants) is een geavanceerd simulatiegereedschap met animatiemogelijkheden. Bedrijfsprocessen gemodelleerd met Protos of Cosa kunnen direct met Exspect gesimuleerd worden.
Woflan (Technische Universiteit Eindhoven) is een gereedschap voor het verifiëren van workflow-processen gemodelleerd met Protos of Cosa. Het gereedschap maakt gebruik van ‘state-of-the-art’ resultaten op het gebied van Petri-net-analyse.
De vier genoemde gereedschappen ondersteunen het volledige traject van modellering en herontwerp (Protos), analyse (Woflan/Exspect) en realisatie (Cosa). Doordat elk van de gereedschappen gebaseerd is op Petri-netten, is het mogelijk om procesbeschrijvingen uit te wisselen. In figuur 4 is de relatie tussen de vier gereedschappen weergegeven.

Inhoudelijke afstemming

Op twee belangrijke punten schieten de meeste wfm-systemen tekort: het niet onderkennen van toestanden en het ontbreken van goede analysemogelijkheden. Deze tekortkomingen illustreren het feit dat op dit moment een goede conceptuele standaard voor het modelleren van bedrijfsprocessen ontbreekt. De standaarden die voorgesteld worden door instanties zoals de Workflow Management Coalition proberen teveel een compromis te sluiten tussen de diverse producten en zijn vooral gericht op de technische problemen met betrekking tot interoperabiliteit. Het uitwisselen van informatie tussen wfm-systemen is echter meer dan het uitwisselen van berichten; ook de inhoudelijke afstemming is van wezenlijk belang. Een goede standaard moet daarom gebaseerd zijn op heldere en eenduidige concepten, moet toestanden expliciet onderkennen, en moet aanknopingspunten bieden voor geavanceerde analysetechnieken. Petri-netten vormen een uitstekend uitgangspunt voor zo’n standaard.
 
W.M.P. van der Aalst is verbonden aan de Technische Universiteit Eindhoven.
J.H.M. Rigter werkt bij Consultdata te Amsterdam.

Literatuur

W.M.P. van der Aalst and K.M. van Hee. Workflow Management: Modellen, Methoden en Systemen. Academic Service, Schoonhoven, 1997.
W.M.P. van der Aalst, K.M. van Hee, and G.J. Houben. Modelleren en Analyseren van Workflow: een Aanpak op Basis van Petri-netten. Informatie, 37(11):590-599, 1995.
W.M.P. van der Aalst. Putting Petri nets to work in industry. Computers in Industry, 25(1):45-54, 1994.
Lawrence, editor. Workflow Handbook 1997, Workflow Management Coalition. John Wiley and Sons, New York, 1997.