In dit hoofdstuk wordt vanuit een topdown benadering het concept Workflow Management toegelicht. Allereerst worden de historische ontwikkelingen die tot Workflow Management hebben geleid kort geschetst in 3.1. Dit geeft het op een abstract niveau aan waar Workflow Management historisch gepositioneerd is. In het hoofstuk 3.2 wordt vervolgens dieper ingegaan op de verschillende typen van computer ondersteuning met in het bijzonder Workflow Management. In het volgende hoofdstuk wordt het belang van Workflow aangeduid. Vervolgens wordt in het hoofdstuk 3.4 in meer detail gekeken naar de concepten die verbonden zijn met workflow en de achterliggende aannames.

De modellen die deze concepten vormgegeven worden toegelicht in 3.5. Tenslotte wordt een concreet model voor Workflow Management Systemen geïntroduceerd.

3.1 Historische context

Al sinds de beginjaren van de computer wordt deze toegepast binnen kantooromgevingen. In de jaren zeventig stond dit bekend onder de naam ‘office automation’ oftewel kantoorautomatisering. In deze periode lag de nadruk sterk op verwerken van gegevens: het opslaan en vinden van gegevens. Toch werd reeds in 1968 het idee van procesautomatisering geopperd door Fritz Nordsieck:

"Think about [a] modern data processing [system]. [It] represents a perceptible process, that is [..] connected with the business process and accompanies - or even controls - this process during various segments." [21]

Midden jaren zeventig begonnen enkele onderzoekers systemen te ontwikkelen die al gestuurd werden door procesmodellen. Ellis, Holt en Zisman werkten ieder aan systemen op basis van Petri-netten om betere informatiesystemen te ontwikkelen voor kantooromgevingen.

In de jaren tachtig ontstonden de eerste Document Management systemen en Computer Supported Cooperative Work systemen. Deze systemen werden mogelijk gemaakt door de snelle ontwikkeling van computernetwerken en de trend naar samenwerken. Toch zijn veel systemen uit deze periode mislukt, wat deels te wijten is aan technische en deels aan fundamentele problemen. De netwerken waren te langzaam en er bestonden nog weinig grafische interfaces en ontwikkeltools. Bovendien ontbrak het aan een uniforme manier om processen te modelleren en de ontwikkelde systemen waren vaak te rigide voor de mensen in de praktijk.

Onderzoek van Porter, Hammer, Champy en vele anderen leidde tot groeiende interesse in het structureren van organisaties volgens processen. Ondanks deze interesse bleek het moeilijk voor bedrijven om procesgeoriënteerde structuren te implementeren. Dit valt deels te wijten aan het feit dat de technische infrastructuur ontwikkeld is voor een functionele indeling. De salarisadministratie gebruikte een bepaald software pakket, dat niet berekend was op samenwerking met andere pakketten.

In de jaren negentig werden de eerste Workflow Management Systemen (WFMS) ontwikkeld die het mogelijk maken om bedrijfsprocessen uit te voeren door de coördinatie van activiteiten.

Business Process Management kan gezien worden als de laatste ontwikkeling op dit gebied. Het bouwt verder op WFM, waarbij naast het uitvoeren van processen, ook de onderdelen proces ontwerp en diagnose een belangrijkere rol spelen. Groupware is het omvattende begrip van systemen die gebruikt worden ter ondersteuning van menselijke activiteiten.

Een andere belangrijke ontwikkeling is Enterprise Applicatie Integratie (EAI) geweest. Hierbij werd gepoogd om los gekoppelde systemen naadloos te integreren door processen, programmatuur, standaarden en apparatuur zodanig op elkaar af te stemmen dat de systemen als één geheel opereren. EAI is niet zo’n groot succes gebleken en met de komst van Web Services is het overbodig geworden.

Al deze ontwikkelingen zijn samengebracht in figuur 3.1, waarbij de onderlinge relaties duidelijker naar voren komen.

Figuur 3.1 - Ontwikkeling Workflow

3.2 Computer Supported Cooperative Work

De meeste computersystemen ondersteunen slechts de werkzaamheden van individuele gebruikers. Het merendeel van het kantoorwerk bestaat echter uit interactie met andere personen: informatie-uitwisseling, ideeën ontwikkelen, rapporten opstellen, afspraken maken enz. Samenwerken in groepsverband is dus een zeer belangrijk deel van de werkzaamheden. Computer Supported Cooperative Work (CSCW) heeft tot doel juist op dit vlak ondersteuning te bieden.

3.2.1 Definitie van CSCW en Groupware

De term Computer Supported Cooperative Work (CSCW) duikt voor het eerst op in 1984 en wordt gebruikt door Greif en Cashman om na te denken over hoe computer effectiever ingezet kunnen worden voor mensen in hun werk. Vaak wordt CSCW gezien als een combinatie van Informatica en Sociale Wetenschappen. Over de een gedetailleerde definitie bestaat echter veel onenigheid.

Zo bestaat er een technologische invalshoek en werk-invalshoek. Volgens deze eerste groep zijn de termen Computer Supported Cooperative Work (CSCW) en Groupware synoniemen. Ellis (1993) geeft de volgende definitie voor CSCW:

“computer-gebaseerde systemen die ondersteuning bieden aan groepen mensen die werken aan een gezamelijke taak (of doel) en die een interface bieden tot een gedeelte omgeving”

De tweede groep is echter van mening van CSCW en Groupware twee verschillende zaken zijn. Groupware verwijst volgens hen naar computer-gebaseerde systemen zoals videosharing, e-mail, cvs systemen enz. CSCW is volgens hen de studie naar tools en technieken om groupware mogelijk te maken, maar daarnaast ook de psychologische, sociale en organisatorische effecten. Dit verschil is terug te vinden in de definitie die Suchman (1989) geeft:

“het ontwerp van computer-gebaseerde technologieën met het uitdrukkelijke zorg voor sociaal georganiseerde praktijk van de bedoelde gebruikers”

3.2.2 Drie categorieën groupware systemen

Ondanks deze verschillen is het mogelijk om drie verschillende categorieën groupware systemen te onderscheiden [16]:

Samenwerking ondersteunend

Effectieve samenwerking vereist dat betrokkenen informatie kunnen delen. Voorbeelden van groupware systemen waarin ondersteuning wordt geboden voor samenwerking zijn bijvoorbeeld Document Management Systemen. Mensen kunnen in teams samen werken doordat toegangscontrole en versiebeheer wordt verschaft.

Communicatie ondersteunend

Voorbeelden van systemen in deze categorie zijn video conferencing en chat-programma’s. Dergelijke systemen refereren aan het belang van communicatie die traditioneel wordt vormgegeven door vergaderingen of telefoongesprekken. Door gebruik te maken van groupware systemen kan bespaard worden op reistijd, hierbij is echter wel van belang dat verschillende media zoals audio en beeld geintegreerd worden.

Coordinatie ondersteunend

Effectief samenwerken is pas echt mogelijk wanneer de activeiten van de medewerkers op elkaar worden afgestemd. De functie van coördinerende systemen is dan ook om te voorkomen dat taken dubbel worden uitgevoerd en dat er onduidelijkheid ontstaat over wie wat doet. Workflow Systemen vallen in deze categorie, ze modelleren taken en bijbehorende rollen. Nadat een taak is uitgevoerd stuurt het Workflow systeem de taak automatisch naar de volgende verantwoordelijke.

Wanneer deze drie systemen in één figuur worden gezet, wordt het toepassingsgebied duidelijker:

Figuur 3.2 – Categoriën groupware systemen

3.2.3 Verschillende typen Workflow Systemen

Wanneer in wat meer detail wordt gekeken naar Workflow systemen dan kunnen de Workflow systemen opgedeeld worden in meerdere categorieën. Een mogelijke indeling is naar gelang het type werk dat ondersteund moet worden.

De efficiëntie en effectiviteit van workflowsystemen hangt af van het type werk dat wordt geautomatiseerd. Van der Meer [18] maakt onderscheid tussen twee typen werk (tabel 3.1):

Tabel 3.1, Type I- en II-werk

Het werk dat met type I wordt aangeduid, is zeer goed met workflow systemen te automatiseren. Deze systemen worden ook wel gestructureerde workflowsystemen genoemd, omdat de processen goed gestructureerd zijn. Type II werk is veel minder goed structureerbaar. Hierbij gaat het vaak om uitzonderingssituaties die niet een vast pad volgen.

Door McCready [17] werd het onderscheid gemaakt tussen adhoc, administratief en productie workflow. Deze onderverdeling komt nog vaak in de literatuur voor, maar is door de vele ontwikkelingen inmiddels enigszins achterhaald. Deze is te vinden in Bijlage 3.

Een andere verdeling wordt gegeven door Reijers et al [22]. Hierbij wordt een splitsing gemaakt naar oriëntatie (proces, data of beide) en gestructureerdheid.

Figuur 3.3 – Onderscheid workflow systemen volgens Van der Aalst

Groupware systemen zijn traditioneel gebaseerd op data en ondersteunen alleen ongestructureerde processen. Productie workflows omvatten herhalende, voorspelbare processen die tijdens het ontwerpen volledig worden vastgelegd.

Ad hoc systemen staan toe dat tijdens het uitvoeren workflows gemaakt en gewijzigd worden. Om dit te bereiken heeft elke casus de beschikking over zijn eigen procesdefinitie. De flexibiliteit die deze systemen bieden vereist echter meer kennis van modelleertechnieken van de gebruikers. Een ad hoc workflow systeem wacht dus op de gebruiker om te bepalen wat vervolgens moet gebeuren.

Naast de tot nu toe behandelde typen workflow, is er nog een nieuw type bijgekomen genaamd Case Handling Systemen (CHS). In tegenstelling tot ad-hoc systemen wordt niet van gebruikers verwacht dat ze zelf de modellen aanmaken of wijzigen. Voor een uitgebreide beschrijving van CHS wordt verwezen naar Bijlage 2.

Figuur 3.4 – Afwegingen verschillende Workflow Systemen

Deze verschillende systemen hebben ieder hun sterke en zwakke punten en het hangt van de te ondersteunen processen af, welk soort workflow systeem gekozen moet worden.

3.3 Workflow Management: beloften en gevaren

3.3.1 Beloften van Workflow Management

Workflow management werd door sommigen aangeduid als een magische oplossing voor alle problemen die optreden bij bedrijfsprocessen door de volgende beloften:

1. Minder coördinatie, het WFMS bevrijdt werknemers van routine werk dat ze moeten uitvoeren ter coördinatie.
2. Hogere kwaliteit, WFMS biedt ten minste het werk dat nodig is om aan een bepaalde kwaliteit te voldoen
3. Hogere efficiëntie, WFMS biedt maximaal de hoeveelheid werk die is vereist voor een acceptabel resultaat.
4. Beter onderhoudbaar, door de scheiding van workflow en traditionele applicaties, kan eenvoudiger de uitvoer worden aangepast.

Het gebruik van een WFMS vereist dat de organisatie de processen opnieuw kritisch bekijkt. Dit is daarom een goed moment om deze processen opnieuw in te richten. Kobielus geeft aan dat een proces geoptimaliseerd dient te worden op één van de volgende drie punten:

1. procestijd minimaliseren. Dit kan door het aantal deelnemers terug te dringen, door de maximale duur te verlagen, tijd tussen taken verlagen, maximale wachttijd verlagen (prioriteit geven aan acties die al langer staan te wachten), meer taken parallel uitvoeren.
2. toegevoegde waarde van het proces maximaliseren door de kwaliteit te verhogen of de kosten te verlagen. Dit kan door standaard procedures te volgen, deelnemers toegang te verschaffen tot online status informatie, kosten van papier te elimineren.
3. flexibiliteit in het contact met de klant maximaliseren. De klant hoeft maar één keer gegevens in te voeren, ondersteuning voor transacties, aanbieden meerdere mogelijkheden.

WFMS bieden verbeterde toegang tot informatie. Voor elke taak wordt door het WFMS de geschiedenis bijgehouden en ten alle tijden kan de actuele status van een proces worden ingezien. Daarnaast biedt een WFMS verbeterde beveiliging en betrouwbaarheid. Op basis van authorisatie, wordt toegang verleend tot bepaalde onderdelen. Niet iedereen kan bijvoorbeeld een salarisverhoging goedkeuren.

3.3.2  Gevaren van Workflow Management

Ondanks deze beloften blijkt de inzet van Workflow Systemen nog beperkt. Het is belangrijk te weten waardoor de inzet beperkt is gebleven, zodat de problemen in het vervolg vermeden kunnen worden.

Dit heeft te maken met de volgende gevaren van WFMS:

1. te veel detail: processen kunnen gedefinieerd worden op elk willekeurig niveau. Wanneer te veel door het systeem wordt voorgeschreven, werkt dit contraproductief. Bovendien blijkt dat voor complexe processen worden de modellen dermate complex, dat de beheersbaarheid zeer lastig wordt. Om procesmodellen toch beheersbaar te houden wordt dan gekozen voor het vereenvoudigen van het model. Hierdoor ontstaat een geïdealiseerde versie van het werkelijke proces. Uitzonderingsgevallen worden bijvoorbeeld niet gemodelleerd en wanneer deze optreden, zal de gebruiker buiten het WFMS om moeten gaan.
2. menselijke weerstand. Een aantal medewerkers kan de invoering van een WFMS zien als een devaluatie van hun werk, of ze zien het als controle-middel op hun werk door hun baas. Anderen kunnen de interactie met collega’s missen, die nu overbodig is geworden.
3. minder flexibel. Niet alle processen zijn geschikt voor workflow systemen. Wanneer de medewerker bijvoorbeeld eigen inzicht moet gebruiken, kan een workflow te star zijn.
4. kosten technische implementatie. WFMS zijn vaak complexe systemen die ontwikkeld en onderhouden dienen te worden. De aanschaf van software, hardware en de implementatie in de organisatie kunnen flinke kostenposten zijn.
5. kosten procesdefinitie. Het (her)ontwerpen van processen kan een een lastig karwij zijn dat veel tijd kost. Bovendien is een zeer gedetailleerde kennis noodzakelijk van de onderliggende processen.

3.4 Workflow definitie en concepten

Het moge duidelijk zijn dat Workflow management gaat om het ondersteunen van processen. Wat processen zijn en welke processen ondersteund worden is vaak onduidelijk.

3.4.1 Verschillende soorten processen

Er bestaan veel verschillende definities over wat een proces is, ieder ingegeven door een net iets andere invalshoek. In dit rapport wordt een een proces gezien als een formele beschrijving van een bedrijfsproces, gerepresenteerd als een gecoördineerde verzameling proces activiteiten die verbonden zijn om een gezamenlijk doel te bereiken. De activiteiten hebben op hun beurt weer relevante gegevens. Door Dubray [11] wordt onderscheid gemaakt tussen vier typen processen die hij indeelt op vier niveaus.

Op het eerste niveau bevinden zich bedrijfsprocessen, die een globaal overzicht geven op de activiteiten die worden uitgevoerd om een bepaald doel te bereiken. Vaak beslaat dit type processen meerdere bedrijven. Op het tweede niveau bevinden zich de uitvoerbare processen die de acties van medewerkers coördineren en de bedrijfstransacties die door externe partijen zijn geïnitieerd. Dit is dus beperkt tot de grenzen van het bedrijf. Uitvoerbare bedrijfsprocessen kunnen door één bedrijfsproces management systeem worden uitgevoerd. Het derde niveau correspondeert met samenwerkingsverbanden die de interactie tussen uitvoerbare processen modelleert. Op het laagste niveau bevinden zich de taken. Dit niveau ontkoppelt het bedrijfsproces van de gebruiker of het systeem. Dit niveau wordt vaak aangeduid met workflow.

3.4.2 Workflow definitie

Het vierde niveau van Dubray’s indeling komt overeen met de definitie van workflow door de WfMC:

 “De automatisering van een bedrijfsproces, geheel of gedeeltelijk, waarbij documenten, informatie of taken van de ene betrokkene naar de andere(n) worden doorgegeven, volgens een set van procedurele regels”

De definitie van een Workflow Management Systeem is volgens de WfMC:

“Een systeem dat de uitvoer van workflows definieert, creëert en beheert door middel van software, lopend op een of meerdere workflow engines, die in staat is een procesdefinitie te interpreteren, interactie te plegen met workflow deelnemers en, waar nodig, externe IT tools en applicaties kan aanroepen.”

Activiteiten representeren werkeenheden die door een medewerker of systeem worden uitgevoerd. Activiteiten hebben een bepaalde invoer en uitvoer en pre- en postcondities. Een bedrijfsproces wordt slechts gezien als een opeenvolging van activiteiten volgens een bepaalde volgorde. Wanneer een activiteit is afgerond bepaalt de control flow welke activiteit vervolgens wordt uitgevoerd.

3.4.3 Dimensies workflow processen

Workflows zijn processen waarbij de taken worden uitgevoerd binnen een bepaalde casus. Van der Aalst [1],[2] onderscheidt drie dimensies waarin deze processen bezien kunnen worden (figuur 3.5). De ordening van de taken, oftewel het proces, kan gezien worden als de control-flow dimensie. Hierin wordt bepaald welke taken uitgevoerd moeten worden. Hierbij wordt gebruik gemaakt van welbekende routing structuren zoals conditionele, sequentiële, parallelle en iteratieve. Een overzicht van verschillende workflow en communicatie patronen volgt in hoofdstuk 4.1.

Taken worden uitgevoerd door hulpbronnen. Dit kunnen zowel medewerkers als apparaten zijn. Samen vormen zij de bron-dimensie waarin ze worden ingedeeld in rollen en organisationele groepen. Deze twee dimensies hebben niets te maken met individuele casussen. Pas wanneer een bepaalde casus wordt uitgevoerd ontstaat de derde dimensie die een combinatie is van de eerste twee.

Figuur 3.5 – Verschillende dimensies casus-gedreven processen

De primaire taak van WFM systemen is om bedrijfsprocessen uit te voeren. Zoals uit de definitie van de WfMC blijkt, spelen daar meerdere aspecten bij een rol.

Allereerst moeten workflow proces definities worden opgesteld waarin wordt aangegeven welke taken in welke volgorde uitgevoerd moeten worden. Deze taken worden gezien als ondeelbare werkeenheden; ze worden dus wel of niet geheel uitgevoerd.

Daarnaast moet de organisatiestructuur en de invulling daarvan worden vastgelegd. De organisatiestructuur bepaalt verantwoordelijkheden, authorisatie, toegankelijkheid enz. Vervolgens kan een workflow worden uitgevoerd. Hierbij zijn twee typen data betrokken: controle en productie data. Controle gegevens worden door het WFMS gebruikt om te beslissen over routing. Productie data bestaat uit informatieobjecten die zinvol zijn voor medewerkers zoals formulieren.

De onderliggende gedachte van veel WfMS’en is dat een proces bestaat uit een stel taken die uitgevoerd moeten worden door bepaalde hulpbronnen zoals mensen en applicaties volgens een bepaald schema. Dit wordt ook wel het ‘manufacturing paradigma’genoemd naar analogie van productie werk.

3.4.4 Eigenschappen manufacturing paradigma

Er zijn diverse overeenkomsten tussen lopende-band en administratief werk. Beide processen leggen de nadruk op het routeren van werk en het inschakelen van hulpbronnen voor dat werk. Ondanks de overeenkomsten zijn er ook verschillen tussen beide processen [3]:

-         goedkoop om een kopie te maken. In tegenstelling tot het maken van een kopie van een auto, is het maken van een kopie van een softwareprogramma eenvoudig.

-         limieten aan opslagcapaciteit zijn minder aan de orde. Auto’s moeten opgeslagen worden in loodsen, en daaraan zij veel kosten verbonden. Dit fenomeen wordt bestreden met just-in-time concepten, maar bij software ontwikkeling is dit veel minder belangrijk. Opslag is erg goedkoop en geen belangrijke factor.

-         minder eisen aan de volgorde van uitvoer. In tegenstelling tot technische beperkingen bij het assembleren van producten, zijn mensen flexibeler.

-         kwaliteit is moeilijk te meten. Voor mechanische systemen is objectief vast te stellen of aan een bepaalde standaard wordt voldaan.

-         kwaliteit van eindproducten kan variëren. Soms kan het aantrekkelijk zijn om bepaalde acties over te slaan om de werkdruk te verlichten.

-         transport van elektronische data is erg snel in tegenstelling tot het transport van fysieke objecten.

-         productie voor voorraad zelden mogelijk. Elk product is uniek, het is niet mogelijk om te beginnen met de verwerking van formulieren voordat het formulier binnen is.

-         iteraties of opnieuw beginnen komen vaak voor. Productieprocessen zijn vaak sequentieel, terwijl bij administratieve processen vaak herhalingen voorkomen.

-         tijdens proces te beïnvloeden door klant. Bij productieprocessen wordt vooraf besloten wat het product zal zijn, bij administratieve processen is beïnvloeding nog mogelijk tijdens de verwerking.

Deze verschillen wijzen erop dat de concepten van productieprocessen niet zomaar op administratieve processen van toepassing zijn. Bovendien heeft de focus op het proces ertoe geleid dat er minder aandacht voor het product is.

Toch blijkt volgens onderzoek dat ondanks de verschillen, het manufacturing paradigma wel toepasbaar is voor administratieve processen.

3.5 Workflow Modelleren

De basis van WFMS bestaat uit een workflow. Hiervoor is het van vitaal belang dat de workflows goed gemodelleerd en geanalyseerd kunnen worden. Twee belangrijke technieken bestaan hiervoor: Petri-netten en WF-netten. Het gebruik van een formele basis biedt als voordeel dat dubbelzinnigheden, onduidelijkheden en tegenstrijdigheden worden voorkomen. Bovendien maakt het de analyse van de workflow eenvoudiger.

3.5.1 Petri-netten

Petri-netten werden in 1962 door Carl Petri geïntroduceerd om processen te modelleren en analyseren. Ze worden als basis voor diverse WFM Systemen gebruikt.

Het zijn in feite gerichte bipartiete grafen met twee typen nodes: plaatsen en transities. Plaatsen worden voorgesteld met cirkels, transities worden voorgesteld met rechthoeken.

Plaatsen en transacties worden met elkaar verbonden door middel van gerichte verbindingen, voorgesteld door pijltjes (figuur 3.6). Aangezien verbindingen alleen tussen plaatsen en transacties (en omgekeerd) mogen bestaan, zijn er slechts twee soorten verbindingen.

Petri definieert bij een transactie twee soorten plaatsen. Een plaats p is de invoerplaats van een transactie t als er een gerichte verbinding van p naar t loopt en een uitvoerplaats van een transactie t is een gerichte verbinding naar p.

Figuur 3.6 - Plaats A is hier de invoerplaats van transitie B; plaats C is de uitvoerplaats van transitie B.

Een Petri-net bevindt zich in een bepaalde toestand. Deze toestand wordt bepaald door de positie van tokens, die worden voorgesteld door zwarte stippen. Deze tokens symboliseren vaak objecten. Tokens kunnen alleen in plaatsen voorkomen en wanneer een transitie vuurt, dan verwijdert het een token bij alle invoerplaatsen en produceert het een token bij alle uitvoerplaatsen. In bovenstaand voorbeeld zal door het vuren van B een token uit A verwijderd worden en in C geproduceerd worden. Dit vuren is echter alleen mogelijk wanneer op elk van de invoerplaatsen (in dit geval A) minimaal één token aanwezig is.

De transities vormen het actieve deel van Petri-netten. De structuur van het Petri-net verandert niet.

Petri-netten blijken voor praktijksituaties ondanks hun sterke wiskundige achtergrond vaak tekort te schieten. Dit komt doordat een Petri-net vaak te groot en daarmee onoverzichtelijk wordt. Om deze reden zijn Petri-netten uitgebreid. De drie belangrijkste uitbreidingen zijn:

1. kleur. In klassieke Petri-netten is het niet mogelijk tokens te onderscheiden. Het kan echter wenselijk zijn om de eigenschappen van een object aan een token te koppelen. Hiertoe worden tokens voorzien van een waarde. Het vuren van een transitie kan nu afhankelijk zijn van de waarde van het token. Bovendien is het aantal geproduceerde tokens afhankelijk van de waarde. Dit betekent dat transities precondities kunnen bevatten.
2. tijd. Vaak is het interessant om naar de prestaties van een Petri-net te kijken. Hiervoor is het noodzakelijk om Petri-netten uit te breiden met tijd. Naast een waarde krijgt een token nu ook een tijdstempel dat aangeeft vanaf welk tijdstip het token beschikbaar is. Wanneer een transisite vuurt, ondervindt een token een bepaalde vertraging die afhankelijk kan zijn van het token maar ook bijvoorbeeld een constante vertraging kan zijn.
3. hiërarchie. De twee voorgaande uitbreidingen maken een Petri-netten nog complexer om te lezen. Door hiërarchie aan te brengen is het mogelijk weer structuur aan te brengen in het model.

Voor een uitgebreidere toelichting wordt verwezen naar [4].

3.5.2 WF-netten

Een Workflow net is een Petri-net met enkele beperkingen. Het bevat één invoerplaats ‘begin’ en één uitvoerplaats ‘einde’. Elke transitie (in de context van Workflow ook wel taak) en plaats (conditie) ligt op het gerichte pad van begin naar einde. Dit betekent dat er geen taken of condities zijn die niet vanuit de beginplaats bereikbaar zijn.

3.5.3 Analyse: verificatie, validatie, prestatieanalyse

Een foutieve workflow leidt ertoe dat werknemers zich niet aan de workflow zullen houden, omdat dit negatieve gevolgen zou hebben voor een organisatie: boze klanten, schadeclaims, hoge kosten enz. Daarom is het zeer belangrijk dat een workflow proces definitie goed geanalyseerd wordt voordat het in gebruik wordt genomen.

Wanneer formele methoden zoals Petri-netten gebruikt worden om te modelleren, kan gebruik gemaakt worden van enkele krachtige analyse technieken. Analyse valt onder te verdelen in

-         Validatie. Gedraagt het model zich zoals verwacht?

-         Verificatie. Is de Workflow correct?

-         Prestatieanalyse. Zijn de prestaties van het proces hoog genoeg?

Validatie is het eenvoudigst, dit kan worden bevestigd door het model een aantal malen te doorlopen met enkele test casussen. Verificatie en prestatie-analyse vereisen geavanceerdere technieken uit de wiskunde. Voor verificatie kunnen technieken uit de lineaire algebra ingezet worden om diverse eigenschappen te testen. Daarnaast zijn diverse technieken voor graaf-analyse nuttig. Voor prestatieanalyse wordt gebruik gemaakt van Markov-analyse, wachtrij-theorie of simulatie. Op deze analyse-technieken zal niet verder ingegaan worden.

3.6 Architectuur

De grote verscheidenheid aan workflow systemen betekent dat er niet één standaard kan gelden dat geschikt is in elke situatie. Om toch uitspraken te kunnen doen over de architectuur, is door de WfMC (Workflow Management Coalition) een referentie-model [27] ontwikkeld dat de eigenschappen van alle WFMS (Workflow Management Systeem) op een hoog niveau weergeeft (figuur 3.7). De WfMC is een organisatie voor de ontwikkeling en promotie van workflow standaarden waaraan veel bedrijven deelnemen.

Figuur 3.7 – WfMC Workflow Referentie Model

Interface 1: Workflow Definition Interchange

De uitwisseling tussen het modelleer-gereedschap en de Workflow Engine is mogelijk via Interface1. Voorbeelden zijn bijvoorbeeld het gebruik van Protos [Pallas Athena] om procesbeschrijvingen te maken en deze te gebruiken in een workflow pakket van een andere leverancier. De informatie die uitgewisseld wordt, omvat de volgende onderdelen: proces structuur, de activiteiten, rollen, triggers, voorwaarden, aangeroepen applicaties, resources etc.

Interface 2: Workflow Client Application Interface

Deze Interface scheidt de Workflow Engine van de applicaties voor de gebruikers. Hierbij wordt gebruik gemaakt van een gestandaardiseerd API en uitwisselformaat. Onderwerpen die hierbij van belang zijn beslaan: connectie/disconnectie, proces en activiteit beheersfuncties, proces status functies en het manipuleren van de lijst met werkeenheden. Interface 2 heeft een duidelijk pull karakter; medewerkers selecteren actief taken uit een lijst om te verwerken.

Interface 3: Invoked Application Interface

Bij de uitvoer van een proces kan het nodig zijn dat externe programma’s worden aangeroepen. Om ervoor te zorgen dat niet voor elke applicatie de Workflow Engine herschreven hoeft te worden, is een aparte module toegevoegd genaamd Application Agent. Deze Application Agent heeft vervolgens applicatie-specifieke interfaces tot de daadwerkelijk aangeroepen applicaties. Daarnaast kunnen applicaties die kunnen omgaan met Workflow systemen direct via gestandaardiseerde APIs gebruikt worden door de Workflow Engine. In tegenstelling tot Interface 2, is hier veel meer sprake van een push model. De applicaties worden door de workflow engine gestart en geven de controle weer terug nadat de verwerking klaar is.

Interface 4: WAPI Interoperability Functions

Om uitwisseling tussen verschillende workflow systemen mogelijk te maken, is het noodzakelijk dat ook deze koppeling gestandaardiseerd wordt. Interface 4 beschrijft hoe workflow engines activiteiten of subprocessen kunnen starten, processen en activiteiten kunnen beheersen en de status opvragen, applicatie/workflow-relevante data kunnen versturen, synchroniseren en proces definities kunnen uitwisselen met andere workflow engines.

Interface 5: Systeem Administratie Interface

Om management applicaties gebruik te kunnen laten maken van diverse workflow engines, is ook hier een Interface aangebracht. Gespecificeerd worden het management van gebruikers, rollen, audit-informatie, beheersing van bronnen, overzicht op processen enz.

De architectuur van een WFMS kan ook als volgt worden weergegeven met iets meer detail, waarbij de samenhang tussen de verschillende componenten in meer detail wordt uitgewerkt:

Figuur 3.8 – WfMC Architectuur WFMS

Voor deze verschillende Interfaces bestaat een grote verscheidenheid aan standaarden. Veel standaarden overlappen elkaar geheel of gedeeltelijk. In hoofdstuk 4 wordt dieper ingegaan op deze standaarden.

3.7 Conclusie

In dit hoofdstuk is Worklow Management geïntroduceerd als een specifieke vorm van computerondersteuning. In de jaren 70 werden gegevens beheerd door afzonderlijke applicaties. Met de introductie van RDBMS werd de data ontsloten voor andere applicaties. Een zelfde proces is nu zichtbaar voor bedrijfslogica. Niet langer worden bedrijfsregels vastgelegd in applicatiecode, maar wordt een nieuwe laag geïntroduceerd die een abstractie voor de bedrijfslogica biedt. Workflow is de automatisering van een speciaal type proces, namelijk binnen bedrijven. Deze processen kunnen gemodelleerd worden op basis van Petri-netten of Workflow-netten. Door te kiezen voor een wiskundig goed onderbouwd model, wordt de validatie, verificatie en analyse vereenvoudigd.

Er bestaan verschillende typen workflowsystemen voor verschillende toepassingen, deze toepassingen zijn echter vooral gericht op toepassingen binnen een bedrijf.

De introductie van Internet en bijbehorende technologieën heeft er mede toe geleid dat steeds vaker over de grenzen van het eigen bedrijf wordt gekeken. Bedrijfsprocessen die meerdere bedrijven overspannen worden aan elkaar geknoopt tot alles omvattende procesmodellen. Workflow management is geëvolueerd tot Business Process Management, wat veel meer omvat dat alleen de coördinatie van taken tussen verschillende personen. Het omvat alle processen waaraan een bedrijf deelneemt, van het kleinste niveau waarbij medewerkers zijn betrokken tot op bedrijfsproces niveau waarbij andere bedrijven zijn betrokken.

In het volgende hoofdstuk worden de verschillende standaarden toegelicht die zijn ontwikkeld met het doel om bedrijfsprocessen op alle niveaus te ondersteunen.