Vergelijkende Analyse van Open Source Business Process Management - Applicaties

Transcriptie

1 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR Vergelijkende Analyse van Open Source Business Process Management - Applicaties Masterproef voorgedragen tot het bekomen van de graad van Master of Science in de Handelswetenschappen Simon Lowagie onder leiding van Prof. M. De Backer

2

3

4

5 VOORWOORD Hiermee wil ik iedereen bedanken die mij geholpen heeft bij het schrijven van deze Masterproef, mijn ouders voor de morele steun en het nalezen, en in het bijzonder Prof. M. De Backer voor zijn begeleiding bij zowel mijn Bachelor- als Masterproef.

6

7 ABSTRACT Dit onderzoek heeft als uiteindelijk doel een duidelijk beeld te vormen van de drie belangrijkste Open Source Business Process Management-applicaties namelijk Activiti, ProcessMaker en Bonitasoft. Eerst wordt een duidelijk beeld opgesteld van de relevante beschikbare onderzoeksliteratuur, waarna de voor handen zijnde analyseframeworks worden vergeleken. Dit onderzoek kiest voor de methode van Koster (2009) waarbij de tools geanalyseerd worden volgens modellering-, design-, interactie-, monitor- en controlecriteria. Uiteindelijk worden de drie applicaties ten opzichte van elkaar besproken aan de hand van behaalde scores gebaseerd op de vooraf gedefinieerde voorwaarden.

8

9 INHOUDSTAFEL Lijst met figuren Inleiding Motivatie Waarom Business Process Management-applicaties? Marktonderzoek Waardecreatie door BPM-applicaties Open Source Objectieven Onderzoeksvraag en methode Business Process Management Definitie BPM De BPM-levenscyclus De PDCA-cyclus De Levenscyclus van Weske De Levenscyclus van Smith & Fingar De Levenscyclus van Petzmann et al De Levenscyclus van Koster BPMS Definitie Sleutelmogelijkheden van BPM-systemen De proceslaag Verhouding van de applicaties t.o.v. het BPMS Evolutie BPM-systemen Architectuur BPMS Build & Run time Standaarden en BPM-systemen... 31

10 Modellerende standaarden Uitvoerende standaarden BPMN Evaluatiemethode Overzicht beschikbare methodes Analyse-Framework van Koster Modellering Design Interactie Monitoren en controle Voorbeeld proces Activiti Inleiding Situering Product Systeemvereisten Bedrijfsmodel Modellering Modelleertalen en hun interoperabiliteit Verschillende views tijdens het modelleren Impliciete bedrijfsregels Expliciete bedrijfsregels Processen in tabelvorm Key Performance Indicators Design Business Process Execution-talen Automatische en manuele vertaling... 60

11 Link uitvoerbaar en grafisch model Programmeertalen Externe applicaties Databanken Online portaal Takenlijst Rollenomschrijving Mogelijkheden op basis van een rol Organisatiestructuren uit externe systemen Manueel of automatisch toekennen van gebruikers Activiteiten toelaten op basis van rollen Interactie Actieve informatie Passieve informatie Monitoren en controle Technische monitoring en controle Actieve monitoring Passieve monitoring Verschillende detailniveaus Procesinstantie-evolutie Veranderende bedrijfsregels Veranderende activiteiten en werklast Samenvatting Activiti Processmaker Inleiding Situering Product... 70

12 Systeemvereisten Bedrijfsmodel Modellering Modelleertalen en hun interoperabiliteit Verschillende perspectieven tijdens het modelleren Impliciete bedrijfsregels Expliciete bedrijfsregels Processen in tabelvorm Key Performance Indicators Design Business Process Execution-Talen Automatische en manuele vertaling Link uitvoerbaar en grafisch model Programmeertalen Externe applicaties Online portaal Databanken Takenlijst Rollenomschrijving Mogelijkheden op basis van een rol Organisatiestructuren uit externe systemen Manueel of automatisch toekennen van gebruikers Activiteiten toelaten op basis van rollen Interactie Actieve informatie Passieve informatie Monitoren en controle... 82

13 Technische monitoring en controle Actieve monitoring Passieve monitoring Verschillende detailniveaus Procesinstantie-evolutie Veranderende bedrijfsregels en activiteiten Veranderende werklast Samenvatting Processmaker Bonitasoft Inleiding Situering Product Systeemvereisten Bedrijfsmodel Modellering Modelleertalen en hun interoperabiliteit Verschillende perspectieven in het proces Impliciete bedrijfsregels Expliciete bedrijfsregels Processen in tabelvorm Key Performance Indicators Design Business Process Execution-Talen Automatische en manuele vertaling Link uitvoerbaar en grafisch model Programmeertalen Externe applicaties... 95

14 Databanken Online portaal Takenlijst Rollenomschrijving Mogelijkheden op basis van een rol Organisatiestructuren uit externe systemen Manueel of automatisch toekennen van gebruikers Activiteiten toelaten op basis van rollen Interactie Actieve informatie Passieve informatie Monitoren en controle Technische monitoring en controle Actieve monitoring Passieve monitoring Verschillende detailniveaus Procesinstantie-evolutie Veranderende bedrijfsregels, activiteiten en werklast Samenvatting Bonitasoft Productvergelijking Modelleercriteria Design Interactiviteit Controle en Monitoring Overzicht Bronnen

15 LIJST MET FIGUREN Figuur 1: Stages van waarde-realisatie bij BPM-investeringen (Janelle B. Hill, 2006) 4 Figuur 2: De PDCA-cyclus van Deming (Moen & Norman, 2009) Figuur 3: Levenscyclus (Weske, 2007) Figuur 4: Levenscyclus (Smith & Fingar, 2003) Figuur 5: Levenscyclus (Petzmann, Puncochar, Kuplich, & Orensanz, 2007) Figuur 6: Levenscyclus (Koster, 2009) Figuur 7: Traditionele architectuur t.o.v. procesarchitectuur (Chang, 2006) Figuur 8: Verhouding applicaties t.o.v. het BPMS (Chang, 2006) Figuur 9: Architectuur BPMS (Hollingsworth, 1995) Figuur 10: Functionele onderdelen van een Business Process Management System (Hollingsworth, 1995) Figuur 11: Relatie tussen BPM-theorie, standaarden en software (Ryan K.L. Ko, 2009) Figuur 12: Standaarden t.o.v. de functionaliteit van BPM-systemen Figuur 13: Impliciete bedrijfsregel Figuur 14: Expliciete bedrijfsregel Figuur 15: Interacties Figuur 16: Voorbeeld proces Figuur 17: Logo Activiti Figuur 18: Overzicht Services Activiti REST ( 57 Figuur 19: Screenshot modelleerkeuze (Activiti) Figuur 20: Screenshot inlogscherm (Activiti) Figuur 21: Screenshot takenlijst (Activiti) Figuur 22: Screenshot rollen (Activiti) Figuur 23: Screenshot actieve monitoring (Activiti) Figuur 24: Screenshot passieve monitoring (Activiti)... 65

16 Figuur 25: Logo ProcessMaker Figuur 26: Screenshot modelleermodule (ProcessMaker) Figuur 27: Screenshot Dynaform (ProcessMaker) Figuur 28: Screenshot impliciete bedrijfsregels (ProcessMaker) Figuur 29: Screenshot online portaal (ProcessMaker) Figuur 30: Screenshot takenlijst (ProcessMaker) Figuur 31: Screenshot rollen (ProcessMaker) Figuur 32: Screenshot mogelijkheden op basis van een rol (ProcessMaker) Figuur 33: Screenshot organisatiestructuur (ProcessMaker) Figuur 34: Screenshot actieve informatie (ProcessMaker) Figuur 35: Screenshot dashboard (ProcessMaker) Figuur 36: Screenshot detailniveaus dashboard (ProcessMaker) Figuur 37: Screenshot keuzemenu procesinstantie-evolutie (ProcessMaker) Figuur 38: Logo Bonitasoft Figuur 39: Screenshot modelleermodule (Bonitasoft) Figuur 40: Screenshot keuzemenu importeren procesmodellen (Bonitasoft) Figuur 41: Screenshot tabel bedrijfsregels (Bonitasoft) Figuur 42: Screenshot online portaal (Bonitasoft) Figuur 43: Screenshot rollen (Bonitasoft) Figuur 44: Kolomgrafiek tussentotalen Figuur 45: Radar grafiek procentuele totalen

17 1. INLEIDING Het inleidende hoofdstuk omvat allereerst de motivatie waarin de relevantie van deze masterproef benadrukt wordt. Hierna volgen de objectieven waarbij het uiteindelijke doel van het gevoerde onderzoek kort uitgelegd wordt. De onderzoeksvraag die de basis vormt om de objectieven te bereiken wordt hierna toegelicht samen met een beknopte omschrijving van de gevolgde methode. 1

18 1.1. MOTIVATIE Veel bedrijven zijn continu op zoek naar vernieuwende manieren om hun productiviteit, productkwaliteit en operationaliteit te verhogen. Business Process Management (BPM) maakt dit mogelijk. (Lee & Dale, 1998) Onderzoek heeft uitgewezen dat er een positieve correlatie bestaat tussen BPM en bedrijfssucces. (Trkman, 2009) WAAROM BUSINESS PROCESS MANAGEMENT-APPLICATIES? Alles wat binnen een bedrijf gebeurt, bestaat uit processen. Zoals de naam reeds suggereert, omvatten die processen de essentie van Business Process Management en worden ze volgens de Workflow Management Coalition gedefinieerd als volgt: een set van één of meer gelinkte procedures of activiteiten die collectief een bedrijfsobjectief of beleidsdoel realiseren, binnen de context van een organisatiestructuur waarin functionele rollen en relaties gedefinieerd zijn. (Workflow Management Coalition, 1999) Business Process Management (BPM) vormt dus de managementdiscipline waarin deze processen niet alleen omschreven en gemanaged worden maar ook continu verbeterd en aldus afgericht op de bedrijfsobjectieven. Alle elementen van een organisatie moeten samengebracht worden om een echte proces-gebaseerde omgeving te bekomen. (Rensburg, 1998) Ten gevolge van globalisering merkt men een stijging van competitiviteit in verschillende markten. Bedrijven die door deze trend niet willen achterblijven, moeten vlot antwoord kunnen bieden op een stijging in de frequentie van bestelde goederen, de nood aan vlotte informatie, snelle en efficiënte beslissingsmechanismen, de nood om zich te kunnen aanpassen aan vraagsveranderingen (Ryan K.L. Ko, 2009) Door het efficiënt managen van alle processen binnen een bedrijf, kan er een competitief voordeel behaald worden en op de hierboven genoemde problematiek een antwoord gegeven worden. Lagere kosten, grotere flexibiliteit, minder verbruikte grondstoffen, grotere kwaliteit zijn maar enkele van de mogelijke voordelen die door middel van BPM behaald kunnen worden. Om echter over te gaan tot efficiënt Business Process Management, moeten bepaalde factoren aanwezig zijn in de organisatie. Eerst en vooral moet men de processen ontwerpen. Er dient te worden vastgelegd wat waar, door wie, wanneer, met welke informatie en onder welke omstandigheden zal gebeuren. Ook de nodige metrieken moeten aanwezig zijn. Processen hebben immers nood aan end-to-end metrieken, afgeleid van de noden van de klanten en van de ondernemingsdoelen. 2

19 Efficiënt BPM vraagt ook om Process Performers die over de juiste vaardigheden moeten beschikken om de processen uit te voeren. Ten vierde zijn er Senior Managers nodig die met autoriteit en verantwoordelijkheid over een proces waken. Deze managementsleden noemt men de Process Owners. De laatste en misschien wel meest cruciale factor tot efficiënt Business Process Management is de IT-infrastructuur binnen de organisatie. Er is nood aan ondersteuning door specifieke systemen met BPM-applicaties. (Hammer, 2008) (Hammer, The Process Audit, 2007) Deze factor speelt een belangrijke en motiverende rol voor dit onderzoek MARKTONDERZOEK De markt voor IT-applicaties die Business Process Management ondersteunen staat niet stil. BPM vindt zijn oorsprong in bestaande domeinen zoals Business Process Re-Engineering, Total Quality Management, Workflow Management, Enterprise Application Integration, Business Activity Monitoring en andere. (Pascal Ravesteyn R. B., 2010) Samen met een dichte relatie tot Service Oriented Architecture, kan men dit beschouwen als een eerste verklaring voor een snel veranderende markt. (Pascal Ravesteyn, 2008) Als men de marktonderzoeken vergelijkt, merkt men duidelijke verschillen over de jaren heen. Gartner Research evalueert jaarlijks de belangrijkste BPM-oplossingen die commercieel beschikbaar zijn (Open Source-oplossingen worden in dit onderzoek niet opgenomen). Door de opkomst van nieuwe technologieën en trends wordt de nadruk elk jaar echter anders gelegd. Vanaf het marktonderzoek van 2012 worden bijvoorbeeld ook de analysemogelijkheden van de BPM-oplossingen beklemtoond (Jim Sinur W. R., 2012). Hieruit kan men een tweede verklaring afleiden voor een continu verschuivende markt waarin er zich over de jaren heen nog geen duidelijke marktleider heeft afgetekend. Ondernemingen beseffen alsmaar meer het belang van BPM en investeren er ook naar. Uit onderzoek van Gartner Research blijkt dat BPM-investeringen steeds een belangrijkere rol spelen binnen de informatietechnologie-uitgaven. Zelfs tijdens de economische crisis in 2009 realiseerde de BPMS-markt een omzet van $1.9 miljard. Dit is een stijging van 15% ten opzichte van 2008 waar er een omzet van $1.6 miljard werd gerealiseerd. (Jim Sinur J. B., 2010) In het onderzoek van Forrester stelt men dat bijna alle BPM-leveranciers een verdubbeling zagen in hun omzetgroei over de eerste drie kwartalen van (Faura, 2009) Men mag deze stijgende trend in de vraag naar BPM ook niet te nauw bekijken. Enterprise Resource Planning (ERP) systemen, Enterprise Application Integration 3

20 (EAI), geavanceerde planningsystemen, softwaresystemen specifiek ontwikkeld voor een bepaalde organisatie, enz. nemen heden ten dage naast BPM-oplossingen nog steeds een prominent deel van de markt in. (Dabaghkashani, Hajiheydari, & Haghighinasab, 2012) WAARDECREATIE DOOR BPM-APPLICATIES Indien men investeert in een BPM-oplossing zal dit binnen de organisatie voor extra waardecreatie zorgen. Dit gebeurt echter niet onmiddellijk maar verloopt geleidelijk over verschillende fases. Het eerste effect manifesteert zich binnen de productiviteit. Er wordt efficiënter gewerkt binnen specifieke locale processen. Deze stijging in productiviteit kan oplopen van 15% tot 150% door het automatiseren van menselijke taken en Document Workflow. In een volgende fase worden de processen meer zichtbaar gemaakt. Door ze eenvoudigweg te modeleren, gaat men hierover verder onderzoek uitvoeren en er zo bepaalde managementvoordelen uithalen. Tenslotte wordt er op creatieve en innoverende wijze, ook breder en out of the box nagedacht hoe BPM-initiatieven tot nut kunnen zijn voor de organisatie. Figuur 1: Stages van waarde-realisatie bij BPM-investeringen (Janelle B. Hill, 2006) Deze fases bouwen zich geleidelijk op over een lange periode (zie figuur 1). De mogelijke waarderealisatie is op het moment van de nodige investeringen niet altijd 4

21 even duidelijk. Zeker in kleinere bedrijven waar men omzichtig moet omspringen met IT-middelen wordt aan BPM-initiatieven vaak een lage prioriteit gegeven OPEN SOURCE De markt voor BPM-oplossingen wordt momenteel gedomineerd door enkele commerciële bedrijven die volwaardige oplossingen aanbieden aan een beperkt aantal grote klanten. Het aangaan van een contract met één van deze aanbieders gaat vaak gepaard met ingrijpende langdurige, complexe en vooral dure herwerkingen van bedrijfs- en IT-systemen. Dit vereist allereerst een grote initiële investering. Ook de nodige bronnen moeten vrijgemaakt worden om eerst de implementatie en nadien het management van het systeem te ondersteunen. (Silver, 2006) Voor 85% van de projecten waarin BPM potentieel bruikbaar is, zijn de enige alternatieve opties (naast de grote commerciële oplossingen) intensief manueel coderen of Open Source BPM. Dit aandeel ligt waarschijnlijk nog hoger aangezien in veel gevallen de nood voor BPM niet herkend wordt. Projecten waarin Open Source BPM aangewezen is, kan men herkennen aan de hieronder opgesomde vereisten. (Faura, 2009) Een nieuwe applicatie met een snelle ontwikkeling is vereist. De applicatie moet op lange termijn onderhoudbaar zijn voor een lage kost. Binnen de organisatie mogen geen bestaande systemen herwerkt worden, de applicatie moet ermee kunnen samenwerken. Wanneer BPM-oplossingen geïmplementeerd worden, verwachten de gebruikers een duidelijke verbetering, automatisering en meting van de processen. Deze belofte kan niet altijd waar gemaakt worden. De voornaamste oorzaken hiervan zijn: de kost van de BPM-software en de implementatie. de rigiditeit van BPM-producten naar de ontwikkeling toe. de innovatie in het aanleveren van BPM-gerelateerde voordelen voor elke persoon binnen de organisatie. Het gebruik van Open Source (OS) kan deze factoren elimineren. In het werk van Faura (2011) wordt dit uitgebreid besproken. Het traditionele gepatenteerde softwaremodel houdt de broncode geheim en vereist dat de klanten betalen voor de gebruikslicentie. Bij OS-software daarentegen wordt de broncode via het internet bekend gemaakt waardoor iedereen die code kan inkijken, bekritiseren, aanpassen 5

22 of ombouwen. Voorbeelden van OS-projecten zijn het GNU-project (een besturingssysteem specifiek gericht op de x86 processor architectuur), de Apache Web Server, de MySql database technologie, Red Hat JBoss, Tomcat, OS-software krijgt soms de onterechte kritiek dat er onvoldoende ondersteuningsinfrastructuur aanwezig is. In de praktijk worden OS-Projecten vaak ondersteund door grote commerciële organisaties of bedrijven. Hiernaast ontstaat er rond OS-applicaties vaak ondersteuning door de gebruikers zelf. Die richten forums en blogs op waar ze oplossingen voor vaak voorkomende en zelfs niche problemen aanbieden. Applicaties met een verborgen broncode kunnen deze vorm van support nooit aanbieden, aangezien de kosten niet opwegen ten opzichte van de verwachte winst. Ook wordt de beveiliging van dergelijke applicaties in vraag gesteld. Er wordt vaak beweerd dat ze te onveilig zijn om binnen een echte bedrijfsorganisatie te implementeren. Echter één van de belangrijkste voordelen van een open broncode, is dat deze door een zeer divers publiek onderzocht wordt. De meeste zwaktes worden snel gedetecteerd en opgelost vooraleer ze een groot probleem vormen. Gevonden problemen kunnen gemakkelijk gedeeld worden met de ontwikkelaar of zelf opgelost worden. Vaak voorziet de ontwikkelaar een platform waarop zelfgemaakte oplossingen gedeeld en besproken kunnen worden. In gepatenteerde programma s kunnen bugs over verschillende versies aanwezig blijven en zijn de gebruikers volledig aangewezen op updates van de ontwikkelaar. Bij gepatenteerde software wordt de geheime broncode door de aanbieder vaak als machtsmiddel gebruikt ten opzichte van zijn klanten. Als de gebruikers van het programma functionaliteiten willen toevoegen of de mogelijkheden uitbreiden, zijn ze volledig afhankelijk van de ontwikkelaar. In de meeste gevallen moeten ze wachten op een update, een andere versie kopen met de gewenste functionaliteiten of betalen om toegang te krijgen tot de Applicatie Programming Interface (API) zodat ze zelf de functies kunnen ontwikkelen. Bij OS-software zijn de gebruikers vrij om de programma s zelf uit te breiden naar hun eigen vereisten met of zonder medewerking van de ontwikkelaar. De Connector-bibliotheek is essentieel voor de functionaliteit van een OSprogramma. Deze connectors worden gebruikt om samen te werken met derde partijsystemen. Gepatenteerde software zorgt hier vaak voor Paywalls of andere obstakels voor het creëren van connectoren naar een derde partij om zo hun winst te maximaliseren. Dit onderdrukt ook de innovaties van ontwikkelaars en beperkt de uiteindelijke mogelijkheden van het softwarepakket. 6

23 OS-programma s zullen zo vaak mogelijk samenwerken met open standaarden. Dit promoot nog meer de transparantie van de applicatie. Gepatenteerde programma s zijn vaak incompatibel met andere formaten. Op deze manier kunnen ze hun klanten rechtstreeks binden aan bepaalde systemen of aanbieders van diensten. Jaarlijks worden door de Infoworld Test Center-redactie en recensenten de Bossies (Best of Open Source Software) uitgereikt. Dit is een prijs specifiek gericht op Open Source-toepassingen. Na grondig onderzoek, worden enkel de meest belovende en kost-effectieve OS-applicaties voor IT-organisaties geselecteerd. Deze applicaties reiken van software-ontwikkelingsondersteuning tot ERP-oplossingen. In de selectie van 2013 ontvingen 3 BPM-applicaties een Bossie, namelijk Activiti, Colosa Processmaker en Bonita BPM. (InfoWorld Bossies (Best of Open Source Software), 2013) Deze award vormt het selectiecriterium van de applicatie voor dit onderzoek. 7

24 1.2. OBJECTIEVEN De nood aan IT-ondersteuning door middel van BPM-applicaties, de steeds veranderende markt, de vertraagde waardecreatie na investering en de voordelen van Open Source-oplossingen maken van OS BPM-applicaties een interessant en actueel onderzoeksgebied dat tot op heden amper bestudeerd werd. Infoworld vermeldt Activiti, ProcessMaker en Bonitasoft als de drie beste OS BPMoplossingen. Dit onderzoek heeft als doel de sterktes en de zwaktes van deze applicaties te evalueren. BPM werkt op basis van een levenscyclus. Elke fase die hierin voorkomt zal door de suite ondersteund moeten worden. Als eindresultaat moet er een duidelijk schema tot stand zijn gekomen waarin de 3 applicaties ten opzichte van elkaar vergeleken worden. 8

25 1.3. ONDERZOEKSVRAAG EN METHODE Dit onderzoek verloopt in verschillende fasen. Een eerste vereiste is een klaar en duidelijk inzicht in Business Process Management zelf. Hiervoor wordt een algemeen literatuuronderzoek uitgevoerd. Eens dit voltooid is, kan men verder ingaan op de volgende onderzoeksvragen: 1) Welke methodes zijn er beschikbaar om BPM-applicaties te evalueren? 2) Welke van de gevonden methodes is het meest geschikt voor een vergelijkende analyse van meerdere BPM-oplossingen? 3) Hoe verhoudt de gekozen methode zich tot de beschikbare literatuur? Daarna kan men overgaan tot een meer hands-on approach waarbij de gekozen applicaties getest worden aan de hand van de methode die uit onderzoeksvraag 2 naar voren werd geschoven. 4) Hoe scoren de applicaties (Activiti, Colosa Processmaker en Bonita BPM) binnen de gekozen methode? 5) Welke conclusies kunnen we trekken uit deze vergelijking? 9

26 2. BUSINESS PROCESS MANAGEMENT Bij het uitvoeren van een algemeen verkennend literatuuronderzoek omtrent BPM is het aangewezen om te werken aan de hand van verschillende onderzoeksvragen. Deze omvatten de verschillende aspecten waarvan men duidelijk een beeld wil vormen vooraleer het effectieve onderzoek wordt aangevat. 1. Wat is Business Process Management? 2. Hoe verloopt de BPM-cyclus? 3. Wat is een Business Process Management System? 4. Welke standaarden zijn er beschikbaar? Om antwoord te bieden op de eerste onderzoeksvraag Wat is Business Process Management? wordt er in hoofdstuk 2.1. Definitie BPM een grondige analyse van de beschikbare definities in de literatuur gemaakt. Aan de hand van verschillende interpretaties uit de bestaande literatuur komt vervolgens de tweede onderzoeksvraag Hoe verloopt de BPM-cyclus? uitgebreid aan bod in hoofdstuk 2.2. De BPM-levenscyclus. Hoofdstuk 2.3. Definitie BPMS bouwt verder aan de hand van specifiek onderzoek naar de omschrijving van de systemen, wat bijgevolg een duidelijk antwoord biedt op de derde onderzoeksvraag Wat is een Business Process Management System?. Een overzicht van de beschikbare standaarden en hun verhouding tot de theorie en de BPM-applicaties wordt beschreven in 2.4. Standaarden en BPM-systemen 10

27 2.1. DEFINITIE BPM BPM is het resultaat van een evolutionaire groei vanuit verschillende andere disciplines. Trends en technologische ontwikkelingen hebben hierin een prominente rol gespeeld. Om deze reden biedt de literatuur ook verschillende definities van Business Process Management aan. Op heden bestaat er echter nog geen universeel aanvaarde en éénduidige definitie. (Antonucci & Goeke, 2011) De meest voorkomende definities worden hieronder in chronologische volgorde besproken. Elzinga D.J. (1995) definieert BPM als volgt: Business Process Management is een systematische, gestructureerde benadering om processen te analyseren, verbeteren, controleren en managen met als doel de kwaliteit van de producten en diensten te verbeteren. Men kan stellen dat dit een zeer beperkte en onduidelijke definitie is. De functies van BPM zijn tegenwoordig uitgebreider dan enkel analyse, verbetering, controle en management. Ook modellering, ontwerp, uitvoering vormen op de dag van vandaag een belangrijk onderdeel binnen BPM maar worden niet vermeld in deze definitie. Tevens ontbreekt er enige verwijzing naar IT-infrastructuur of BPMsystemen. Ook de bedrijfsobjectieven waarop de bedrijfsprocessen moeten worden afgericht om hun uiteindelijke doel te bereiken worden hierin niet vermeld. Twee jaar later volgt Zairi (1997) met een nieuwe definitie van BPM: BPM is een gestructureerde benadering tot analyse en continue verbeteringen aan fundamentele activiteiten zoals productie, marketing, communicatie en andere belangrijke elementen van de bedrijfsoperaties. Over deze definitie vallen echter dezelfde opmerkingen te maken als bij de omschrijving van Elzinga (1995). Deze tekortkomingen kan men onder andere toekennen aan het feit dat BPM als onderzoeksgebied toen nog maar net tot stand kwam. M. Weske (2004) stelt volgende definitie voor: Het ondersteunen van bedrijfsprocessen door middel van methodes, technieken en software om operationele processen met betrekking tot mensen, organisaties, applicaties, documenten en andere informatiebronnen te ontwerpen, uit te voeren, te controleren en te analyseren. Drie jaar later wordt deze definitie door dezelfde auteur echter herzien. In zijn boek wordt de volgende omschrijving voorgesteld: Business Process Management omvat concepten, methodes en technieken om het ontwerp, de administratie, configuratie, uitvoering en analyse van bedrijfsprocessen te ondersteunen. (Weske, 2007) 11

28 Deze definities zijn reeds uitgebreider, maar nog niet optimaal. In zijn eerste omschrijving vermeldt M. Weske (2004) software en technieken, maar een verwijzing naar de bedrijfsobjectieven laat hij alsnog achterwege. In de herziening wordt BPM zelfs opnieuw beperkter bekeken. Uit het literatuuronderzoek blijkt dat Koster (2009) de meest volledige definitie hanteert: Business Process Management is een managementdiscipline die een systematische en gestructureerde benadering gebruikt om expliciet Process Management te ondersteunen door middel van methodes, technieken en tools, en met betrekking tot mensen, organisaties, applicaties, documenten en andere informatiebronnen, met als doel het behalen van de bedrijfsobjectieven door het africhten van de bedrijfsprocessen op deze objectieven. Alle aspecten van de voorgaande definities zijn hierin opgenomen of worden zelfs uitgebreid. Voor het eerst wordt BPM voorgesteld en benoemd als een managementdiscipline. Gartner Inc. (2013) voorziet op dit moment de meest recente definitie namelijk: Business Process Management (BPM) is de discipline van het managen van processen (in plaats van taken) met als doel het verbeteren van de bedrijfsperformante uitkomsten en de operationele behendigheid. Processen overspannen organisationele grenzen, leggen linken tussen mensen, informatiestromen, systemen en andere assets met als doel het creëren en leveren van waarde naar klanten en andere belanghebbenden. Deze laatste definitie zorgt uiteindelijk voor weinig toegevoegde waarde op de omschrijving van Koster (2009). Bijgevolg zal in het verder verloop van dit onderzoek steeds de definitie van Koster worden aangewend. 12

29 2.2. DE BPM-LEVENSCYCLUS Koster (2009) spreekt over expliciet Process Management. Logischerwijze staan hiertegenover de impliciete processen, die binnen een organisatie worden uitgevoerd, maar niet specifiek gedefinieerd worden. Men kan dus niet aan BPM doen als er enkel impliciete processen worden gehanteerd. Er moet een procesmodel in een bepaalde modelleertaal (vb. BPMN 2.0) opgesteld worden. (Koster, 2009) De overgang van impliciete naar expliciete processen gebeurt aan de hand van de Business Process Management-levenscyclus. Men spreekt van een cyclisch proces omdat men continu aan de processen sleutelt om een zo n gunstig mogelijk resultaat te behalen. Het belang van een exact gedefinieerde levenscyclus wordt ook aangetroffen bij Business Process Management Systems. Wanneer een bedrijf investeert in een bepaald systeem, wordt er ook verwacht dat deze oplossing ondersteuning biedt voor de gehele cyclus. Bijgevolg is een grondige interpretatie van de levenscyclus van cruciaal belang voor een nauwkeurige analyse. Binnen de literatuur bestaan er net zoals bij de definitie, verschillende interpretaties van deze cyclus. De voornaamste worden hieronder besproken op basis van complexiteit DE PDCA-CYCLUS De grote voorloper van de hedendaagse cyclus vindt men terug in Total Quality Management. Gebaseerd op het werk van Dr. Walter A. Shewart ontwikkelde W. Edwards Deming in 1950 tijdens zijn lezingen in Japan de PDCA-cyclus. (Moen & Norman, 2009) Deze cyclus word gebruikt binnen het kader van TQM en bestaat uit de volgende 4 fasen: Plan: Het product (of de dienst) wordt ontworpen naargelang de vereisten van het management. Do: De vooropgestelde plannen en ontwerpen worden tot uitvoering gebracht. Men gaat over tot productie of dienstverlening. Check: Men controleert of de vooropgestelde objectieven behaald worden. Action: Er wordt overgegaan tot aanpassingen of verbeteringen om eventuele tekortkomingen die naar voren kwamen tijdens de checkfase te corrigeren. Binnen het kader van kwaliteitsmanagement worden hierop later nog varianten opgesteld, bijvoorbeeld de PDSA-cyclus (plan, do, study, action). 13

30 Figuur 2: De PDCA-cyclus van Deming (Moen & Norman, 2009) DE LEVENSCYCLUS VAN WESKE Deze cyclus vormt ook de basis en inspiratie voor de ontwikkeling van de BPMlevenscyclus. Een eerste relatief beperkte kijk op deze levenscyclus vindt men terug in het werk van Van der Aalst. Deze visie wordt in de literatuur algemeen aanvaard en overgenomen. Deze cyclus vormt de basis voor latere ontwikkelde levenscycli. (Weske, 2007) (Ko, Lee, & Lee, 2009) 14 Figuur 3: Levenscyclus (Weske, 2007)

31 Hier wordt een onderverdeling in 4 fasen voorgesteld: Design & Analyse: In deze startfase worden op basis van verzamelde informatie (interviews, data, bestaande kennis ) bedrijfsprocessen geïdentificeerd, beoordeeld, gevalideerd en voorgesteld door modellen (meestal in een grafische vorm). Men past ook simulatietechnieken toe om de validiteit van de processen te ondersteunen. Configuratie: Eens het procesmodel vastligt, kan men overgaan tot implementatie. Eerst en vooral zal een systeem geselecteerd moeten worden. Deze keuze wordt beïnvloed door het voordien gekozen model waarin het proces voorgesteld wordt. Ook kan er extra info binnen het model nodig zijn om te kunnen overgaan tot implementatie in het systeem. Eens de modellen in het systeem ingevoerd zijn, kan men het systeem configureren. Hierbij zal de omgeving (de bestaande IT-infrastructuur, integratie met externe systemen ) van cruciaal belang zijn. Zodra de configuratie afgewerkt is, zal het testen binnen de bedrijfsomgeving beginnen. Uitvoering: In deze fase zal men effectief procesinstanties uitvoeren. Deze worden geïnitieerd om bedrijfsdoelen te kunnen behalen en omvatten dus de eigenlijke werking van de organisatie. Het BPM-systeem zal de instanties opvolgen en aan de hand van bedrijfsregels en de vooropgestelde modellen het geheel de juiste richting uitsturen. Ondertussen zal een monitorcomponent van het systeem de verschillende instanties visualiseren over de processen heen. Dit is een belangrijk mechanisme om accurate informatie te verzamelen over de status van de procesinstanties. Deze informatie wordt opgeslagen in een logbestand. Evaluatie: Alle bruikbare informatie die tijdens de uitvoerende fase werd opgeslagen in de logbestanden, wordt nu beoordeeld. Men past technieken zoals Process-Mining toe om de kwaliteit van de procesmodellen en de adequaatheid van de uitvoeringsomgeving te evalueren. De resultaten hiervan worden dan gebruikt om suggesties voor eventuele verbeteringen tijdens de Design & Analyse- of uitvoeringsfase op te stellen. Deze kunnen vervolgens geïmplementeerd worden als men de volgende keer de BPM-cyclus opnieuw doorloopt DE LEVENSCYCLUS VAN SMITH & FINGAR Deze 4 fasen vormen de basis voor verdere ontwikkelingen binnen het onderzoek naar de levenscyclus van Business Process Management. Smith & Fingar (2003) 15

32 stellen een eerste set van aanpassingen voor. Naast andere benamingen (maar wel met dezelfde inhoud), worden twee nieuwe fasen toegevoegd: Ontdekken: Voorafgaand aan het ontwerpproces en losstaand van de cyclus wordt een eenmalige fase ingevoegd. Deze komt voorafgaand aan het ontwerpproces. In deze fase wordt het proces voor het eerst opgemerkt en toegevoegd aan de bestaande processen binnen de bedrijfsorganisatie. Deze vanzelfsprekende fase wordt in sommige modellen achterwege gelaten. Optimalisatie: Na de analysefase, is het aangewezen om de juiste consequenties te formuleren en hierop volgend ook beslissingen te nemen. In de praktijk zullen er steeds mogelijkheden zijn om de bestaande processen efficiënter te laten werken. Na het opstellen van de verbeteringen kunnen deze in de hierop volgende fase geïmplementeerd worden.. Figuur 4: Levenscyclus (Smith & Fingar, 2003) 16

33 DE LEVENSCYCLUS VAN PETZMANN ET AL. In tegenstelling tot Smith & Fingar (2003) waar de ontdekfase losstaat van de rest van de levenscyclus, keren Petzmann, Puncochar, Kuplich, & Orensanz (2007) terug naar een volledige cyclus. In het hieronder gevisualiseerde opzicht valt direct op dat men een fase heeft opgenomen in verband met de strategie. Niettegenstaande uit de definitie van BPM duidelijk blijkt dat het afstemmen op strategie een erg belangrijke rol speelt, was dit afwezig in de voorgaande modellen van de levenscyclus. Strategie: Vooraleer aan Business Process Management te beginnen, worden de strategische doelen vastgelegd. Concreet betekent dit het abstract definiëren van de kernbedrijfsprocessen en het uitwerken van de procesdoelen en objectieven. Figuur 5: Levenscyclus (Petzmann, Puncochar, Kuplich, & Orensanz, 2007) De strategie bestudeert de langetermijndoelstellingen en geeft duidelijk richting aan wat men wil bereiken. Vanuit het oogpunt van Petzmann, Puncochar, Kuplich, & Orensanz (2007) maakt die strategie echter deel uit van de cyclus zelf. Telkens wanneer men de cyclus doorloopt, zal de strategiefase dus opnieuw worden uitgevoerd. Zodoende worden langetermijndoelstellingen regelmatig herbekeken en gaat het richtinggevend karakter verloren DE LEVENSCYCLUS VAN KOSTER Koster (2009) lost dit probleem op door de strategiefase los te koppelen van de levenscyclus en ze slechts éénmaal uit te voeren. Net als bij Smith & Fingar (2003) wordt nog een ontdekfase toegevoegd vooraleer het cyclisch proces opstart. De eerste twee fasen van de levenscyclus, modelleren en design, klinken zeer gelijkend, maar toch is er een duidelijk verschil. In de modelleringsfase ligt de nadruk 17

34 erop de bedrijfsgerelateerde informatie die in de ontdekfase verzameld werd, te vertalen naar een procesmodel. Tijdens de designfase wordt alle extra info die de implementatie in het systeem mogelijk maakt toegevoegd aan het model. De gebruikte modelleertaal en het gekozen systeem spelen een grote rol in de grootte van deze fase aangezien sommige systemen relatief eenvoudige implementatie mogelijk maken. Figuur 6: Levenscyclus (Koster, 2009) 18

35 2.3. BPMS DEFINITIE Eens Business Process Management en de cyclus gedefinieerd zijn, is het ook aangewezen om dieper in te gaan op de Business Process Management Systems (BPMS). In de definitie van Koster (2009) wordt verwezen naar methodes, technieken en tools. Hiertoe behoren de BPMS maar een meer afgetekende definitie is wenselijk om verder onderzoek te vergemakkelijken. Er wordt op dezelfde manier te werk gegaan en de evolutie van de verschillende definities wordt chronologisch besproken. In 1999 wordt een eerste definitie voor dergelijke systemen voorgesteld door de Workflow Management Coalition: Een systeem dat de uitvoering van Workflow definieert, creëert en managet door het gebruik van software, lopend op één of meerdere Engines, die de interpretatie van procesdefinities, interactie met participanten mogelijk maken en indien nodig het gebruik van IT-tools en applicaties kunnen inroepen. Een gelijkaardige omschrijving wordt opgesteld door Smith en Fingar in 2003: Een Business Process Management System moet naast modellering, het ontplooien en het monitoren van bedrijfsprocessen ook de integratie, automatisering en samenwerking van heterogene processen kunnen ondersteunen. (Smith & Fingar, 2003) Hier ligt de nadruk vooral op de functionaliteiten waarin een BPMS moet voorzien (modellering, ontplooien, monitoring ). Ook wordt reeds een duidelijke focus gelegd op het feit dat een BPM-applicatie niet op zichzelf kan werken. De mogelijkheid om samen te werken met andere heterogene processen is dus essentieel. Weske omschrijft BPMS als volgt: Een Business Process Management System is een generiek softwaresysteem dat gedreven wordt door expliciete procesmodellen om gecoördineerd bedrijfsprocessen uit te voeren. (Weske, 2007) Ook deze omschrijving blijft eerder oppervlakkig. Er is sprake van expliciete procesmodellen om gecoördineerde bedrijfsprocessen uit te voeren, maar een BPMS omvat meer dan enkel de beschreven functie. In tegenstelling tot de definitie van Smith en Fingar (2003) wordt hier wel gesproken over een generiek softwaresysteem. In hetzelfde jaar stelt Ravesteyn & Versendaal (2007) ook een definitie op namelijk: Een Business Process Management System is een software-applicatie die modellering, uitvoering, technisch en operationeel monitoring en 19

36 gebruikersvoorstelling van expliciete bedrijfsprocessen en regels mogelijk maakt, gebaseerd op integratie van zowel bestaande als nieuwe informatiesysteemfunctionaliteiten, die georchestreerd en geïntegreerd worden via diensten. (Ravesteyn & Versendaal, 2007) Deze bepaling bevat alle elementen van de voorgaande omschrijvingen en kan dus aangeduid worden als de meest complete definitie van een BPMS. Niet enkel de nauwe samenhang van BPMS met SOA (Service Oriented Architecture) vindt men hier terug, ook wordt voor het eerst een verwijzing naar diensten opgenomen. In het verder verloop van dit onderzoek zal logischerwijze deze laatste definitie dan ook steeds gehanteerd worden bij het bespreken van BPMS. Hammer omschrijft BPMS-software vanuit de functies die ze ondersteunt. Hij stelt een redelijk simplistische opdeling voorop. Principieel kan men de doelen van BPMS onderverdelen in twee categorieën: het opstellen van omschrijvingen van processen (om analyse, simulatie en verder ontwerp te ondersteunen) of om een uitvoerbare code te genereren. (Hammer, 2008) In vergelijking met voorgaande definities kunnen we besluiten dat deze visie op de mogelijkheden van de hedendaagse softwareoplossingen eerder beperkt is. Een BPM-systeem kan bepaalde tools omvatten die men voordien losstaand van het systeem gebruikte. Enkele voorbeelden hiervan zijn een bibliotheek met Best Practice processen, manuele grafische manipulatie van de configuratie, geautomatiseerde verandering van applicatieconfiguraties, links naar bepaalde communicatiesystemen, projectmanagement software Deze tools zijn echter additief en bijgevolg niet essentieel voor een BPMS. (Shaw, Holland, Kawalek, Snowdon, & Warboys, 2007) SLEUTELMOGELIJKHEDEN VAN BPM-SYSTEMEN Deze systemen kan men ook vanuit een ander standpunt bekijken. In plaats van te focussen op het systeem zelf, kan men eveneens de mogelijkheden analyseren die een BPMS beschikbaar maakt voor het bedrijf. Na een succesvolle implementatie van een Business Process Management System zal de relatie tussen de gebruikers, systemen en data verschuiven. Chang (2006) stelt de volgende nieuwe mogelijkheden voorop: Grotere bedrijfsbetrokkenheid in het ontwerpen van IT-gerichte procesoplossingen. De mogelijkheid om mensen en systemen die participeren te integreren in bedrijfsprocessen. 20

37 De kans om bedrijfsprocessen te simuleren zodat het meest optimale proces voor implementatie kan ontworpen worden. De gelegenheid om bedrijfsprocessen in realtime te monitoren, te controleren en te verbeteren. De mogelijkheid om in realtime veranderingen tot stand te kunnen brengen op bestaande bedrijfsprocessen zonder uitvoerige procesconversies uit te voeren DE PROCESLAAG Om een goed functionerend BPM-systeem te kunnen implementeren, zal een verandering binnen de IT-architectuur moeten doorgevoerd worden. In de traditionele architectuur vindt men steeds drie lagen. De data bevinden zich in de onderste laag, die fysisch opgeslagen zit in een databank. Afhankelijk van de organisatie, kunnen hier nog datawarehouses of datamarts op ontwikkeld worden. Deze opgeslagen gegevens werken dan samen met de bovenliggende laag, de applicaties. In deze programma s zitten dan ook de processen ingewerkt. De bedrijfsprocessen zijn echter beperkt per applicatie en vereisen een grondige kennis van de gebruiker over het proces zelf. Veel gerelateerde data, informatie en bepaalde activiteiten moeten door de gebruiker zelf bepaald worden. In de traditionele IT-architectuur bevindt zich boven deze applicatielaag de presentatielaag waarin de resultaten vanuit de applicatielaag aan de eindgebruiker worden voorgesteld. Indien men afstapt van deze traditionele architectuur en meer procesgericht gaat werken, moet er tussen de applicatie- en presentatielaag een vierde laag worden ingevoegd. Deze wordt aangeduid en benoemd als de proceslaag en omvat het volledige BPM-systeem De proceslogica wordt volledig losgekoppeld van de applicaties. Deze proceslaag kan ook verder uitgebreid worden om zo het gebruiksgemak te verhogen. Deze laag bevat ook veel meer informatie waardoor er minder teruggekoppeld wordt naar de kennis van de eindgebruiker. 21

38 Figuur 7: Traditionele architectuur t.o.v. procesarchitectuur (Chang, 2006) VERHOUDING VAN DE APPLICATIES T.O.V. HET BPMS In de traditionele architectuur omvat de applicatielaag ook de procesgerelateerde bedrijfskennis. De verschillende applicaties werken continu samen zonder een duidelijke vooropgestelde structuur. Per applicatie moeten bedrijfsanalisten de nodige vereisten geëist door de eindgebruikers analyseren en in samenwerking met de IT-afdeling vertalen naar elke applicatie. Nadien dient per applicatie elke samenwerking ook duidelijk te worden gedefinieerd. Dit gebrek aan structuur en volgorde veroorzaakt een onnodige complexiteit en onduidelijkheid. Eens de proceslaag met een bijhorend BPM-systeem wordt ingevoerd, zal deze voor een duidelijke link zorgen tussen alle verschillende applicaties. De processen worden volledig gemanaged vanuit deze laag. De duidelijke volgorde van de vereiste applicaties, de gerelateerde data en de nodige deelnemers worden onder andere allemaal vastgelegd binnen de BPMS. Bedrijfsanalisten kunnen vanuit deze laag op eenvoudige wijze invloed uitoefenen op de processen. 22

39 Figuur 8: Verhouding applicaties t.o.v. het BPMS (Chang, 2006) 23

40 EVOLUTIE BPM-SYSTEMEN De evolutie die BPM-systemen tot op heden hebben doorgemaakt kan moeilijk in de tijd worden vastgesteld daar de overgang tussen verschillende bedrijven en regio s niet altijd gelijk verliep. In het werk van Swanson & Shapiro (2008) wordt hiervan een duidelijk overzicht gegeven. Binnen organisaties vinden we tegenwoordig vier verschillende soorten BPM-systemen terug. Sommige bedrijven kiezen er ook uitdrukkelijk voor om één bepaalde soort te implementeren omdat deze het best beantwoordt aan hun bedrijfsvereisten Informatiesystemen met hard gecodeerde Workflow-ondersteuning. Deze allereerste soort BPM-systemen zijn volledig proces- en organisatiespecifiek, alsook uitsluitend ontworpen en geprogrammeerd om te functioneren in één omgeving met een set van vooraf bepaalde processen. Alle interacties tussen verschillende applicaties en tools werden vooraf gecodeerd in het systeem zelf zodat het proces volledig ondersteund wordt. De harde codering zorgt ervoor dat vanuit het management of de IT-afdeling moeilijk invloed kan uitgeoefend worden op het BPMsysteem. Bij noodzakelijke veranderingen kan enkel gespecialiseerd IT-personeel de hard gecodeerde programmatuur wijzigen. Hierbij moet het ganse systeem eerst stil gelegd worden. Dit alles leidt uiteraard tot een tijdrovende en complexe situatie waarbij verschillende departementen moeten betrokken worden Op maat gemaakte informatiesystemen met generieke Workflowondersteuning Sommige bedrijven wijken af van wat commercieel beschikbaar is en ontwikkelen binnenshuis zelf een nieuw systeem. Zo hopen ze de concurrentie voor te zijn en een competitief voordeel te behalen. Het is echter niet makkelijk om dezelfde functionaliteit te bereiken als de commercieel beschikbare oplossingen. Tijdens de ontwikkeling van het systeem ligt de focus immers uitgesproken op de specifieke noden van de organisatie, waardoor bepaalde andere aspecten naar de achtergrond verschuiven. Het bedrijf zal zich dus tevreden stellen met een subset van de totale mogelijkheden. Deze zal echter veel beter en persoonlijker uitgewerkt zijn dan de commerciële systemen Generieke software met ingewerkte procesfunctionaliteit De meeste totaalpakketten voor ondernemingen voorzien de ondersteuning van bedrijfsprocessen. De nadruk zal hier echter niet vaak liggen op deze component. Voorbeelden hiervan vindt men terug in Enterprise Resource Planning (ERP) of Customer Relationship Management (CRM)-systemen. De functionaliteit komt in de buurt van de software-oplossingen die focussen op bedrijfsprocessen maar toch zijn er ontbrekende elementen. 24

41 Generieke software gefocust op procesfunctionaliteit Deze pure BPM-systemen zijn commercieel beschikbaar en bieden ook de meeste ondersteuning. De BPM-oplossingen die we verder in dit onderzoek bespreken worden in deze categorie ondergebracht ARCHITECTUUR BPMS Ook al bestaat er een gevarieerd aanbod aan producten, men herkent steeds dezelfde componenten en architectuur. Om dit te veralgemenen stelt Hollingsworth in 1995 een algemeen model voorop waarin de verschillende componenten en hun relaties besproken worden. Dit document wordt opgesteld in functie van de Workflow Management Coalition. Deze organisatie poogt een zekere uniformiteit binnen het veld van BPM te brengen. De gehanteerde benadering brengt de belangrijkste functionele onderdelen en hun Interfaces in kaart. Dit is echter een theoretisch model. In de praktijk kunnen BPMproducten hiervan afwijken. Soms gebeurt dit zeer bewust om zo een bepaald marktvoordeel te behalen. Figuur 9: Architectuur BPMS (Hollingsworth, 1995) 25

42 In figuur 9 kan men drie verschillende soorten componenten terugvinden: software-componenten voorzien de nodige functionaliteit binnen het BPMsysteem (Definitie Tool, BPM Engine, Worklist Handler, User Interface) verschillende types van systeemdefinities en controledata worden gebruikt als in- en output voor de verschillende software-componenten applicaties en databases die geen onderdeel vormen van het BPM-systeem. Deze staan los van de BPM-tool op zich, maar worden ingeroepen op basis van de procesdefinities Procesdefinitietool Deze tool wordt aangewend om het proces zoals het aanwezig is in de organisatie, te vertalen naar een definitie die leesbaar is door het systeem. De ontwikkelde definities worden vaak opgebouwd in een standaardtaal om de functionaliteit en inzetbaarheid van het model te verhogen. Dit onderdeel wordt soms ook losstaand van het volledige systeem aangeleverd. De definitiemogelijkheid wordt dan opgenomen binnen een Business Process Analysis System van eenzelfde leverancier. De nadruk van dit pakket ligt hier totaal verschillend dan bij BPMsystemen. De gecreëerde modellen zijn dan vlot uitwisselbaar tussen de verschillende paketten Procesdefinitie De procesdefinitie omvat alle nodige informatie om het proces uitvoerbaar te maken door het BPM-systeem. Hieronder vallen bijvoorbeeld start- en eindvoorwaarden, activiteiten, regels om te navigeren tussen deze, taken voor gebruikers, verwijzingen naar applicaties, relevante data... Deze definitie kan (moet niet) verwijzen naar een organisatie/rollenmodel. Dit bestand omvat relevante informatie omtrent de opbouw van de organisatiestructuur en de rollen hierbinnen. Hierdoor kan de procesdefinitie opgebouwd worden in functie van dit model en kunnen rollenfuncties gekoppeld worden aan bepaalde activiteiten of informatie-objecten De BPM-service Centraal in de figuur vindt men de BPM-service terug. Dit onderdeel is verantwoordelijk voor: procesdefinities interpreteren, verschillende procesinstanties controleren, correcte activiteiten opstarten, interactie met data verzorgen, items toevoegen aan de takenlijst en applicaties inroepen waar nodig. Al deze verantwoordelijkheden worden ondersteund door één of meerdere Engines afhankelijk van de capaciteit en belasting van deze. Elke Engine verzorgt het uitvoeren van een serie procesinstanties. 26

43 Op basis van de procesdefinitie en de relevante procesdata, zal de Engine de procesinstanties in een bepaalde richting sturen doorheen verschillende activiteiten. Hierbij kan dan extra informatie worden opgevraagd of afgeleverd, extra procesinstanties worden opgestart die dan parallel of sequentieel worden uitgevoerd, interactie worden uitgevoerd tussen gebruikers en applicaties Procesgerelateerde, controle- en applicatiedata Beslissingen omtrent navigatie in het proces binnen de BPM-service worden gebaseerd op data die gegenereerd of geüpdated worden door BPM-applicaties. Deze data zijn toegankelijk voor de Engine zelf en zijn bijgevolg procesgerelateerd. Een onderdeel van de procesrelevante data, zijn de applicatiedata. Deze data worden gebruikt binnen interacties met de ingeroepen applicaties. Ook al kan de Engine deze data overbrengen, zelf kan hij er geen aanpassingen in aanbrengen. Dit kan enkel gebeuren door gebruikers of applicaties. Deze data kunnen dan door de applicatie weggeschreven worden naar een databank waarin procesgerelateerde data worden opgeslaan. Sommige BPM-systemen doen beroep op controledata om een vlot verloop van hun processen te verzekeren Werklijsten In veel gevallen zijn interacties door gebruikers noodzakelijk binnen procesuitvoering. Om de wisselwerking vlot te laten verlopen doen Engines een beroep op werklijsten, waarop alle uit te voeren activiteiten over het hele systeem heen te vinden zijn. De items, door de Engine op de lijst geplaatst, worden dan gemanaged door een Worklist Handler, die ze op zijn beurt toewijst aan de taaklijsten. De taaklijst verschilt vooral in de toegankelijkheid door de eindgebruiker. In de werklijst zullen alle uit te voeren activiteiten staan terwijl de taaklijst meer gepersonaliseerd is per gebruiker. In sommige gevallen kan de eindgebruiker items selecteren uit de werklijst om deze dan toe te voegen aan zijn persoonlijke taaklijst Worklist Handler en User Interface De Worklist Handler is de softwarecomponent die verantwoordelijk is voor het verloop van de interactie tussen de eindgebruiker en de Engine zelf. Vaak is de functionaliteit uitgebreider dan enkel het doorschuiven van de uit te voeren items van de werklijst naar de taaklijst van de correcte gebruiker. Zo wordt er dikwijls rekening gehouden met de werklast van de gebruikers, die dan tevens de mogelijkheid hebben om taken door te schuiven naar andere personen. De werkitems die worden toegewezen aan de eindgebruiker worden vervolgens voorgesteld in een activiteitenlijst die opgenomen is in de User Interface. Dit wordt in het diagram losgekoppeld van de Worklist Handler aangezien er meer functies voorzien kunnen worden dan enkel een takenlijst. Zo worden er in de User Interface 27

44 eventueel plug-ins ingeschakeld zoals cliënten of relevante Business Intelligence Dashboards. Vanuit de User Interface of Worklist Handler kunnen ook bepaalde applicaties opgeroepen worden die relevant kunnen zijn als de gebruiker beslissingen moet nemen op basis van andere tools. In deze gevallen wordt vaak de keuze tot het oproepen overgelaten aan de eindgebruiker. Dit vormt dan de verschilfactor met het inroepen van een applicatie door de Engine waarbij de invocatie noodzakelijk is voor het succesvol voltooien van het proces. De gebruiker kan daar dus geen invloed op uitoefenen Controle en management Binnen een BPM-systeem is er natuurlijk ook nood aan controle en management. Deze functies worden aan bepaalde gebruikers toegekend die dan rechtstreeks toegang krijgen tot de Engine, dit in tegenstelling tot de gewone eindgebruikers die de werking van de Engine enkel merken via hun taaklijst. De mogelijke functies waarover gebruikers met controle- of managementrechten beschikken zijn bijvoorbeeld het toekennen van werklasten, het identificeren van bepaalde gebruikers en hun taken binnen een proces, gemiste deadlines opsporen, niet uitgevoerde taken detecteren, de geschiedenis opvragen van een bepaalde procesinstantie, statistieken oproepen omtrent bepaalde processen BUILD & RUN TIME In functie van de Workflow Management Coalition introduceert Hollingsworth (1995) een andere manier om BPM-systemen te bestuderen. Waar men voordien de onderdelen afzonderlijk analyseerde wordt nu een opdeling gemaakt naar functionaliteit. Zoals in figuur 10 uit de onderverdeling blijkt, kan men duidelijk onderscheid maken tussen de Build Time en de Run Time. Tussen de twee functionele onderdelen wordt de link gelegd via de procesdefinities. De Build Time omvat het proces ontwerpen en definiëren terwijl de Run Time wordt onderverdeeld in Proces Instantiatie & Controle en Interacties met Gebruikers & Applicaties. 28

45 Figuur 10: Functionele onderdelen van een Business Process Management System (Hollingsworth, 1995) Build Time Hier worden de procesdefinities opgesteld. Bedrijfsanalisten leggen deze omschrijvingen vast aan de hand van onderzoek binnen de organisatie (bv. door het afnemen van interviews, groepssessies, het analyseren van bestaande data door middel van Proces Mining ). in een bepaalde modelleertaal, tekstueel of grafisch. Het resultaat hiervan moet echter gewoon een waarheidsgetrouwe weergave zijn van wat er effectief in het bedrijf gebeurt. Ook de data die nodig zijn voor de uitvoering van de processen worden in de Run Time vast gelegd. Na een grondige analyse van deze omschrijvingen worden door het gebruik van bepaalde tools inconsistenties, onnodige herhalingen en fouten uit de bestaande processen gehaald om deze efficiënter en effectiever te maken. Na deze aanpassing kunnen ze vlot uitgevoerd worden in het Run Time-gedeelte van het BPMS Run Time De dienst Workflow Enactment Service, onderdeel van Proces Instantiatie & Controle wordt ondersteund door de Business Process Engine. Die zal de vooropgestelde procesdefinities, vastgelegd in de Build Time, interpreteren en 29

46 uitvoeren. Zo wordt een duidelijke link gelegd tussen het werk van de bedrijfsanalisten die de processen vorm gaven in de Build Time en de manier waarop de eindgebruikers van het systeem de processen dagelijks ervaren. Aan de hand van de voorziene gegevens, zal de Engine procesinstanties genereren en controleren. Weske (2007) definieert een procesinstantie als volgt: Een voorstelling van een concrete case in de operaties van een bedrijf, bestaande uit activiteitinstanties. Bij deze instanties wordt dus een status bijgehouden. Ook de relevante data zullen naargelang de manier waarop ze vooraf zijn vastgelegd, transformeren volgens de verschillende stappen in het proces. In het gedeelte Interacties met Gebruikers & Applicaties wordt het effectieve werk van een proces niet uitgevoerd in het BPM-systeem, maar door de gebruikers en applicaties die ingeroepen worden door de Engine. Volgens de plaats van de procesinstantie zal de Engine ofwel manuele taken toewijzen aan de gebruiker of geautomatiseerde taken laten uitvoeren door applicaties, tools of webservices. Hiernaast kan er ook interactie bestaan met andere BPM-systemen. Het ene proces kan een ander doen opstarten of laten eindigen. Binnen een bedrijf kan de samenwerking zich zo spreiden over verschillende departementen. Zelfs meerdere organisaties waartussen een samenwerkingsverband is vastgelegd, kunnen betrokken worden. 30

47 2.4. STANDAARDEN EN BPM-SYSTEMEN Business Process Management wordt gekenmerkt door de aanwezigheid van veel standaarden, die elk gebaseerd zijn op de theorie. Dit kan voor de nodige verwarring zorgen wanneer men BPM wil implementeren. Het is aangewezen om de relatie van de standaarden ten opzichte van de theorie en de applicaties kort uit te diepen. Er wordt een onderscheid gemaakt tussen grafische en uitvoerende standaarden. Deze verschillende soorten vinden echter allemaal hun oorsprong terug in de theorie. BPM-applicaties implementeren dan weer de standaarden en specificaties. Men kan spreken van een geneste relatie tussen deze drie. (Ryan K.L. Ko, 2009) Figuur 11: Relatie tussen BPM-theorie, standaarden en software (Ryan K.L. Ko, 2009) MODELLERENDE STANDAARDEN Wanneer een organisatie haar processen wil modelleren, zal er een keuze gemaakt moeten worden voor een bepaalde modelleertaal. Op de dag van vandaag is er een uitgebreid aanbod aan verschillende Business Process Modelling Languages (BPMLs). Een eerste manier waarop processen gemodelleerd worden is UML 2.0 Activity Diagrams. Deze methode, bedoeld om processen en stromen van data in softwaresystemen te modelleren, vindt logischerwijze haar oorsprong terug in de software-ontwikkeling. (Bell, 2003) 31

48 Event Driven Process Chains is ook een beschikbare methode voor modellering. Deze notatie heeft als doel bedrijfsmensen zelf processen te laten modelleren en de modellen te begrijpen. De syntax of de semantiek is echter niet in een standaard vastgelegd waardoor dubbelzinnige modellen ontstaan. De consistentie en compleetheid van het model valt moeilijk te controleren. (Aalst, 1999) Om bedrijfsprocessen en sequenties rechtstreeks in systemen te modelleren kan men de Integrated DEFinition Method 3 (IDEF3) gebruiken. Deze methode is gebaseerd op twee perspectieven: de proces- en de objectsemantiek. (Badica & Fox, 2008) Soms wordt voor de modellering van bedrijfsprocessen ook Role Activity Diagrams (RAD) gebruikt. De oorsprong van deze methode vindt men terug in het modelleren van coördinatie. Dit is een high-level visuele taal waarbij de nadruk vooral ligt op rollen, activiteiten en interactie in samenspel met externe events. (Badica & Badica, 2010) UITVOERENDE STANDAARDEN Uit noodzaak om grafische bedrijfsprocesmodellen uitvoerbaar te maken en ook te integreren over de grenzen van organisaties heen, zijn een reeks modelleertalen ontstaan. Voorbeelden hiervan zijn BPEL4WS (Business Process Execution Language for Web Services), WSFL (Web Service Flow Language), XLANG (Web Service for Business Process Design), WSCI (Web Service Choreograpgy Interface), BPML (Business Process Modelling Language) Deze talen staan bekend als Web Service Flow-talen, Web Service Executie-talen, Web Service Orchestratie-talen en Web Workflow-talen. Zoals de omschrijving al doet vermoeden werken al deze talen samen met het internet. Om volledige uitvoerbaarheid door BPM-systemen te verwezelijken worden deze modellen opgesteld in XML-formaat. Echter op de dag van vandaag worden ze minder gebruikt en is de ondersteuning van sommige van talen stopgezet. De grootste oorzaak van het mingebruik van deze modelleermethoden is de ontwikkeling van BPMN 2.0 (Aalst, 2003) Bovendien heeft men ook Petri Nets ter beschikking. Deze notatie werd ontworpen voor analyse en simulatie van dynamische systemen. In vergelijking met andere methodes zien we hier een meer wiskundige benadering van procesmodellering waardoor er geen ambiguïteit kan ontstaan tussen de modellen en rechtstreekse uitvoering mogelijk wordt. (International organization for standardization, 2000) BPMN 2.0 Op de dag van vandaag kan men stellen dat de meest populaire en dus de meest gebruikte standaard beschikbaar BPMN 2.0 (Business Process Modeling Notation) is. Deze wordt onafhankelijk uitgegeven door de Object Management Group. BPMN 32

49 2.0 is een grafische diagrammodelleertaal voor bedrijfsprocessen die wijdverspreid overgenomen is door zowel bedrijfs- als technische modelleurs en softwareleveranciers. De sterkte van deze notatie bestaat erin dat die naast een vlot te interpreteren grafische standaard ook de onderliggende XML- code voorziet. Hierdoor worden diagrammen met de nodige specificaties direct uitvoerbaar binnen de omgeving voorzien door de BPM-applicaties. Bedrijfsanalisten kunnen dus zelf een grafisch uitvoerbaar model opstellen zonder dat er technische specialisten aan te pas komen. Deze modellen zijn vlot te interpreteren voor de meeste gebruikers. Een grondige kennis van de taal is niet vereist om de werking ervan te verstaan. (Object Management Group, 2011) (Silver, 2011) (Völzer, 2010) Door het voorzien van een volledig uitvoerbaar XML-model bij de grafische notatie slaagt deze notatie erin om de brug te vormen tussen de grafische en uitvoerbare standaarden. De kracht hiervan kan men vlot illustreren aan de hand van de functionaliteit opgesteld door Hollingsworth (1995). In de Build Time vindt men de puur grafische talen terug, in de Run Time de uitvoerbare talen. Voor het ontstaan van BPMN 2.0 stonden beide volledig los van elkaar, waardoor er steeds een vertaling van het ene soort model naar het andere vereist was. BPMN 2.0 heeft als modelleertaal volledig voet aan de grond in zowel Run- als Build Time waardoor binnen BPM-systemen maar één notatie nodig is. Figuur 12: Standaarden t.o.v. de functionaliteit van BPM-systemen 33

50 3. EVALUATIEMETHODE Na dit duidelijk overzicht omtrent de theorie en definities van Business Process Management wordt een analyse gemaakt van de voorhanden zijnde evaluatiemethodes voor BPM-applicaties. Dit biedt dan ook antwoord op de 1 e onderzoeksvraag: Welke methodes zijn er beschikbaar om BPM-applicaties te evalueren? 3.1. OVERZICHT BESCHIKBARE METHODES Het reeds gevoerde beschikbare onderzoek naar de evaluatie van BPM-applicaties is redelijk beperkt. Een eerste methode ontwikkeld voor analyse vindt men terug in het werk van Helkiö, Seppälä, & Syd (2006). Hun onderzoek is een losstaande analyse van de Intalio BPM Tool waarbij specifiek de nadruk wordt gelegd op het modelleringsaspect. De gebruikte evaluatiemethode in dit onderzoek is een bespreking volgens een aantal criteria, gebaseerd op de ISO/IEC 9126 softwarekwaliteit-karakteristieken, aangevuld met specifieke BPM-maatstaven afgeleid uit marktonderzoeken van Gartner (functionaliteit, betrouwbaarheid, bruikbaarheid, efficiëntie, onderhoudbaarheid, draagbaarheid, integreerbaarheid, domeinspecifieke behoeften). Hierna wordt het overzicht van deze normen getoetst aan de beschikbare literatuur die op het moment van hun onderzoek eerder beperkt in omvang is. Niet alle vooropgestelde criteria kunnen getest worden met de tool, dus construeert men een ingekorte versie, waarna overgegaan wordt tot het controleren van de maatstaven ten opzichte van de Intalio BPM Tool. De bespreking van elke norm beperkt zich dan tot een kwalitatieve samenvatting zonder kwantitatieve metrieken. Voor verder onderzoek wordt wel de nood aan het creëren van een kwantitatieve checklist gesuggereerd. De gebruikte methode in het onderzoek van in Helkiö, Seppälä & Sud leent zich niet tot overname in dit onderzoek. Eerst en vooral is er sinds 2006 relatief veel veranderd op het vlak van BPM-tools en hun mogelijkheden. De vooropgestelde criteria zijn dus niet up-to-date. Men kan ook niet overgaan tot een vergelijkende analyse via een kwalitatieve bespreking. Als men duidelijk drie Open Source BPMtools ten opzichte van elkaar wil vergelijken, zal een kwantificering van de criteria een essentieel aspect vormen van het onderzoek. Een andere methode wordt toegepast in het onderzoek van Nie, Seppälä, & Hafrén (2009). Hier wordt een vergelijkende analyse gemaakt van twee OS BPMoplossingen, JBoss BPM en Intalio BPMS. In tegenstelling tot het voorgaande onderzoek waar de nadruk lag op de modelleringsfunctie, wordt hier gefocust op de 34

51 bedrijfswereld, meer specifiek de banksector. BPM-experts ontwikkelen de evaluatiecriteria. Aan de hand van 3 interviews tijdens de loop van hun onderzoek wordt het iteratief uitgewerkt. Het evaluatieframework dat op deze manier tot stand komt, wordt ook getoetst aan de bestaande literatuur en bestaat uit volgende onderdelen: procesmodellering, werkruimte, regel-engine, connectiviteit, orchestratie-omgeving, procesadministratie, bedrijfsactiviteitmonitoring, procesdatabank, resourcemanagement. Hierna wordt op basis van de afgenomen interviews een case opgesteld gerelateerd aan de banksector, die vervolgens getest wordt in JBoss BPM en Intalio BPMS. Voor elk onderdeel van het gevonden framework maakt men nadien een bespreking aan de hand van de ervaren prestaties van de geteste tools. Als conclusie worden in tegenstelling tot het vorige onderzoek kwantitatieve evaluaties gegenereerd. De gebruikte waarden variëren tussen 1 (komt niet overeen met verwachtingen) en 3 (overstijgt verwachtingen). Dit biedt de mogelijkheid tot een vergelijkende analyse. Deze analysemethode kan niet overgenomen worden in dit onderzoek. De gevonden criteria zijn voldoende uitgebreid om testen uit te voeren voor actuele BPM-tools. Voor elk onderdeel wordt echter hetzelfde gewicht gebruikt binnen de testen. Sommige aspecten van een tool zijn belangrijker dan andere en moeten dus in de evaluatie zwaarder doorwegen. Dit is dus duidelijk niet het geval. Ook zijn de gebruikte waarden die bij de beoordeling worden toegepast, redelijk beperkt. Er is geen mogelijkheid om de nodige diepgang te bieden die vereist is bij een grondige vergelijkende analyse. Een andere analysemethode wordt ontwikkeld en toegepast in het werk van Koster (2009). Uitgaande van een grondige literatuurstudie en zijn BPM-levenscyclus (zie De levenscyclus van Koster) wordt een framework opgesteld waarin verschillende aspecten van de levenscyclus geëvalueerd worden. Elke fase krijgt een aantal concrete criteria toegekend die elk ook een eigen belang en relevantie krijgen toegewezen. Hierdoor wegen bepaalde criteria zwaarder door in de totaalscore van de BPMS. Deze methode blijkt ideaal te zijn voor dit onderzoek aangezien het een grondige evaluatie van elke tool voorziet waarbij verschillende aspecten besproken worden. Het scoresysteem verschaft tevens de mogelijkheid tot een vergelijkende analyse waarbij voor elke BPM-applicatie de sterke en zwakke punten duidelijk zullen worden. Hierdoor leent deze methode zich het best voor dit onderzoek. Als antwoord op de 2 e onderzoeksvraag Welke van de gevonden methodes is het meest geschikt voor een vergelijkende analyse van meerdere BPM-oplossingen? kan men duidelijk stellen dat de methode aangehaald door Koster (2009) meest aangewezen is. 35

52 3.2. ANALYSE-FRAMEWORK VAN KOSTER Gebaseerd op zijn gevoerde literatuurstudie en zijn levenscyclus komt Koster tot een aantal bevindingen die leiden tot het opstellen van een framework. Relevantie en efficiëntie waren bepalend tijdens het ontwerpen van deze evaluatiemethode. Om antwoord te bieden op de 3 e onderzoeksvraag Hoe verhoudt de gekozen methode zich tot de beschikbare literatuur? wordt hieronder de analysemethode van Koster (2009) besproken. Het resulterende framework om tot beoordeling over te gaan bestaat uit 4 hoofdonderdelen met elk hun eigen onderverdeling: Modellering o Procesmodellering Grafische modelleertalen Interoperabiliteit Verschillende perspectieven Impliciete bedrijfsregels Expliciete bedrijfsregels Bedrijfsregels in tabelvorm o Indicatoren Key Performance Indicatoren Design o Uitvoerbare procesmodellen Uitvoerbare modelleertalen Vertaling procesmodellen Linken uitvoerbare en grafische modellen o Implementatie programmeertalen o User Interfaces Externe applicaties data-invoer Online portaal Activiteitenlijst o User Management Rollen 36

53 Mogelijkheden op basis van een rol Organisatiestructuren uit externe systemen Manueel gebruikers toekennen aan een rol Automatisch gebruikers toekennen aan een rol Activiteiten gebaseerd op rollen Interactie o Informeren van de gebruiker Actieve informatie Passieve informatie Monitoren en Controle o Technische monitoring en controle o Bedrijfsmonitoring Actieve monitoring Passieve monitoring Verschillende detailniveaus o Bedrijfscontrole Procesinstantie-evolutie Veranderende bedrijfsregels Veranderende activiteiten Veranderende werklast MODELLERING De eerste stap in het evaluatieproces omvat dadelijk al één van de belangrijkste componenten binnen Business Process Management. Het bedrijfsproces wordt allereerst in een BPM-taal gegoten om zo een éénduidig model te bekomen. Deze fase noemt dan ook logischerwijs Business Process-modellering. Het aldus verkregen ontwerp, geschreven in formele BPM-taal volgens de vooropgestelde syntax, omvat alle relevante informatie. Hierdoor vermijdt men elke mogelijkheid tot alternatieve interpretaties of verwarring. Een model dat eenzijdig kan geïnterpreteerd worden biedt ook de kans tot een diepgaande analyse van andere keuzemogelijkheden binnen het ontwerpproces. 37

54 Echter kan eenzelfde model dat duidelijk een éénduidige betekenis heeft vanuit verschillende perspectieven en met een verschillende graad van detail bekeken worden. Binnen een modelleertaal kan dit tot afwijkende grafische voorstellingen zorgen terwijl deze duidelijk hetzelfde betekenen. Het nut hiervan kan men terugvinden in het voorzien van modellen voor verschillende stakeholders met diverse verwachtingen. Er kunnen vijf verschillende perspectieven onderscheiden worden. (List & Korherr, 2006) Als eerste wordt het functionele perspectief naar voren geschoven waarbij de nadruk ligt op de uitvoering van het proces zelf en alle relevante informatie die erbij opgenomen wordt. Als tweede kan men het organisationele perspectief aanhalen. De klemtoon zal hier vooral liggen op door wie en waar de processen uitgevoerd zullen worden. Ook welke grondstoffen en middelen er nodig kunnen zijn bij het uitvoeren van de processen wordt in rekening gebracht. Ten derde is er het gedragsperspectief. Het gedrag van het proces zelf zoals het gebruik van loops, iteratie, complexe beslissingen, begin- en eindcriteria, enz. staat centraal. Een vierde invalshoek is het informatieperspectief. Hierbij wordt het accent gelegd op de productie en manipulatie van de informatie door het proces. De creatie van entiteiten zoals data, artefacten, producten en entiteiten speelt hier een belangrijke rol. Een vijfde benadering is het bedrijfsproces-contextperspectief. Dit is de meest brede benadering van het procesmodel. Het voorziet een overzichtelijk beeld van het proces en omschrijft de belangrijkste karakteristieken zoals de prestaties, relatie ten opzichte van KPI s (Key Performance Indicators), procestype Deze vijf verschillende invalshoeken voor procesmodellering zijn echter puur theoretisch en zullen in de praktijk nauwelijks zo duidelijk toegepast worden of onderscheidbaar zijn. Wel worden er verschillende accenten gelegd in de modellering van eenzelfde proces, waardoor er afwijkende grafische voorstellingen kunnen ontstaan. Men zal echter moeten opletten dat er geen verwarring kan ontstaan tussen de uiteindelijke betekenis van de verschillende resultaten. Een verder vergelijkend onderzoek naar deze modelleertalen en in welke gevallen welke taal het best te gebruiken is, valt echter buiten de reikwijdte van dit onderzoek. 38

55 Hoe wordt er omgegaan met bedrijfsregels? (Business Rules) is een modelleringsaspect dat zeker bijkomende aandacht verdient. Er worden drie manieren besproken waarop deze in een procesmodel kunnen voorkomen. Een eerste methode wordt omschreven als het gebruik van impliciete bedrijfsregels. Alle regels worden geïmplementeerd in het procesmodel zelf. In de vorm van een beslissingspunt kan de Business Rule in het model verwerkt worden. Hieronder volgt een uitgewerkt voorbeeld van impliciete bedrijfsregelmodellering waarbij de leeftijd invloed heeft op de interest die aangerekend wordt op een bepaalde lening. Figuur 13: Impliciete bedrijfsregel Een andere methode waarin bedrijfsregels gemodelleerd worden is de expliciete manier. Enkel een verwijzing naar de regel die in een externe opslagplaats zit, wordt in het model opgenomen, niet de expliciete Business Rule zelf. Doordat de bedrijfsregels losstaan van de modellen, geeft dit natuurlijk als voordeel dat deze dus apart gemanaged kunnen worden, waardoor eventuele wijzigingen aan de bedrijfsregels efficiënt doorgevoerd kunnen worden. De derde methode omvat het modelleren van het volledige bedrijfsproces op basis van de bedrijfsregels. In dit geval doet men geen beroep op een grafische notatie maar giet men het model in een tabel bestaande uit expliciete Business Rules. 39

56 Figuur 14: Expliciete bedrijfsregel Tenslotte kunnen er aan een procesmodel de nodige Key Performance Indicators (KPI) worden toegevoegd. Deze waarde omvat de performantie van het proces. Aan de hand van een doelwaarde en de uitvoeringsdata in de logs bekijkt men of de waarde behaald is. KPI s functioneren als een hulpmiddel om de organisatie naar de vooropgestelde doelen te laten werken. Deze KPI s moeten SMART (specifiek, meetbaar, haalbaar, relevant en tijdsgebonden) zijn. Binnen de levenscyclus kunnen in elke fase relevante indicatoren opgesteld worden. Zijn de KPI s direct gerelateerd aan de performantie van de processen, dan spreekt men van Process Performance Indicators (PPI). In methodologiëen en frameworks zoals COBIT, ITIL of het EFQM Excellence Model vindt men tegenwoordig steeds meer het belang terug van het insluiten van de PPI s in de procesmodellen. (del-rio-ortega, Resinas, & Ruiz- Cortés, 2010) (del-rio-ortega & Resinas, 2009) Uitgaande van deze aspecten kunnen bepaalde criteria die ondersteund moeten worden door BPM-systemen naar voren gehaald worden. In de onderzoeksmethodologie van Koster (2009) worden deze als volgt omschreven (zie onderstaande tabel). Ook wordt voor elk criterium een bepaald gewicht toegekend. 40

57 Modelleercriteria Methode puntentoekenning 1. Ondersteuning voor procesmodellering 1.1. Ondersteuning voor verschillende grafische modelleertalen 1.2. Ondersteuning voor interoperabiliteit tussen modelleertalen Ondersteuning voor verschillende perspectieven van een proces 1.4. Ondersteuning voor het modelleren met impliciete bedrijfsregels Ondersteuning voor het modelleren met expliciete bedrijfsregels Ondersteuning voor het volledig modelleren van processen met expliciete bedrijfsregels in tabelvorm. Ondersteuning voor enkel 1 modelleertaal resulteert in 6 punten. (8 indien deze de standaardtaal BPMN is.) Elke extra taal die ondersteund wordt, zal resulteren in een extra punt (tot een maximum van 10 punten) als de interoperabiliteit tussen de verschillende talen gegarandeerd wordt. Elk verschillend perspectief resulteert in 1 punt (4 extra als het perspectief volledig bruikbaar is) met een maximum van 10 punten. Ondersteuning resulteert in 10 punten. Geen ondersteuning leidt tot 0 punten. Ondersteuning resulteert in 10 punten. Geen ondersteuning leidt tot 0 punten. Ondersteuning resulteert in 10 punten. Geen ondersteuning leidt tot 0 punten. 2. Ondersteuning voor indicatoren 2.1. Ondersteuning voor KPI s. KPI s definieren met (bijna) volledig natuurlijke taal geeft 10 punten. Als er via een grafische notatie gewerkt wordt, resulteert dit in 5 punten. Als de KPI gecodeerd moet worden, geeft dit 3 punten. 41

58 DESIGN In deze fase gaat men over tot het implementeren van het vooropgestelde model in een systeem met IT-ondersteuning. Afhankelijk van de gebruikte modelleertaal, zal de organisatie de nodige stappen moeten ondernemen om het procesmodel uitvoerbaar te maken. De grafische notatie wordt omgezet in een uitvoerbare modelleertaal. Bepaalde talen (Bv. BPMN 2.0) ondersteunen automatische vertaling naar een uitvoerbaar model, de meeste vallen echter terug op een manuele vertaling van het opgestelde grafische model naar een uitvoerbaar resultaat. Om deze stap te vermijden, wordt er soms rechtstreeks gemodelleerd in codetaal die onmiddellijk door het systeem kan gelezen worden. Hierdoor wordt het moeilijker om de link te leggen tussen het Business- en het procesmodel. Het visuele aspect van een notatie, wat onontbeerlijk is voor een vlotte communicatie, gaat immers verloren. Ook al kan men in sommige gevallen een automatische vertaling uitvoeren, toch is een omgeving die een manuele vertaling ondersteunt een essentiële component. Niet alle opgestelde grafische modellen zijn echter 100% correct en dus zullen de fouten mee vertaald worden. Na een automatische vertaling kunnen via manuele aanpassingen nog correcties aangebracht worden. Het spreekt vanzelf dat er geen inhoudelijke verschillen mogen ontstaan tussen het grafische en het uitvoerbare model. Na het vertalen moeten beide aan elkaar gelinkt worden. Zo kunnen wijzigingen doorgevoerd worden van het ene model naar het andere, en worden inconsistenties volledig vermeden. Eens het uitvoerbare proces volledig gecreëerd is, kan het Service Level Agreement (SLA) opgesteld worden. Ook kunnen de nodige KPI s die in de voorgaande fase werden opgesteld, gelinkt worden aan het proces. Tijdens de uitvoering van een proces zullen er zich ook steeds uitzonderingen voordoen, waarop het systeem moet anticiperen. Deze afwijkingen leiden tot het negatief beëindigen van een activiteit en daarmee ook vaak het proces. De rol die de activiteit speelt binnen het proces zal van belang zijn om de reactie van het systeem te configureren. Door het implementeren van Exception Handlers kan het systeem hiermee omgaan. Als reactie kan men overgaan tot het opnieuw uitvoeren van de activiteit en de gebruiker dus laten reageren op de uitzondering. Een andere mogelijkheid is het terugrollen van het proces tot wanneer een consistente status tot stand komt. Om dit succesvol te laten verlopen, moet een Failure and Cancellation - mechanisme geïmplementeerd zijn. Dit werkt op basis van het ACID-principe (atomair, consistent, geïsoleerd, duurzaam) en werd oorspronkelijk ontwikkeld als databasetechnologie. De toepassing binnen Process Management is op logische wijze tot stand gekomen. Processen bestaan immers uit activiteiten die toegang delen tot persistente databronnen en dus ook ondersteund worden door een transactiesemantiek. De bestaande technologie maakt het echter niet mogelijk om alle processen terug te draaien. Sommige activiteiten zijn definitief en kunnen niet gecompenseerd worden door een bepaald systeem. 42

59 Binnen de designfase wordt ook de interactie met externe systemen vastgelegd. Een BPMS werkt immers niet alleen en deze samenwerking is van cruciaal belang voor het efficiënt implementeren van het systeem in zijn omgeving. Er moet beroep kunnen gedaan worden op applicaties zoals databanken, CRM-toepassingen, Office -onderdelen zowel binnen als buiten de organisatieomgeving. Interne systemen worden op elkaar afgestemd door middel van de eerder traditionele methode "Enterprise Applicatie Integratie" (EAI). Voor externe oplossingen gebruikt men dan Business to Business Integration (B2Bi). (Smith & Fingar, 2003) Databanken zijn een van de belangrijkste systemen waarmee een vlotte communicatie vereist is. Een BPMS moet de gegenereerde data van de processen kunnen wegschrijven naar databases zodat deze ook te gebruiken zijn voor andere doeleinden zoals diepgaande statistische analyse of export naar andere producten. Hoe meer verschillende technologieën(mysql, Oracle, DB2...) waarmee een BPMS kan communiceren, hoe beter... "Enterprise Application Integration" benadrukt ook hoe belangrijk het is om data vlot te kunnen delen binnen organisaties. (Linthicum, 1999) (Chang, 2006) Deze integratie wordt gestimuleerd door de opkomst van interessante trends zoals Service Oriented Architecture in Informatie wordt steeds meer en meer locatieonafhankelijk dankzij het internet en de mogelijkheid om belangrijke, efficiënte netwerken op te zetten. Bedrijfssystemen reageren hierop door af te stappen van grote ondernemingssystemen die lokaal onderhouden worden en te bewegen naar een omgeving waarin informatie en applicaties als diensten worden aangeboden. Deze diensten bevinden zich op één locatie en de eindgebruiker kan deze via het netwerk inroepen. Om dergelijke systemen mogelijk te maken binnen Business Process Management is een vlotte integratie noodzakelijk. (Swanson & Shapiro, 2008) Om integratie te bekomen doet een BPMS beroep op onderliggende Middleware die verschillende soorten technologie, gaande van berichtmakelaars, transactiewachtrijmanagers, publiceer/abonneer Middleware tot zelfs een Enterprise Service Bus omvat. Deze methodes bevatten dan de participerende applicaties, detecteren Events gerelateerd aan het proces en garanderen een vlotte regeling van de Events en berichten tussen de verschillende applicaties. (Dayal, Hsu, & Ladin, 2001) Orchestratie kan op twee mogelijke manieren geregeld worden. Indien men uitgaat van een orchestratiebenadering zullen verschillende partijen samenwerken vanuit één enkel perspectief. De volledige interactie wordt gecontroleerd vanuit dit standpunt. Hier tegenover staat een choreografische kijk op interactie. Elke betrokken partij van het proces omschrijft zelf zijn rol die hij speelt in de interactie en geen enkele entiteit controleert het volledige proces. (Leymann & Reisig, 2006) Tijdens het integreren van een bedrijfsproces, kan men tekorten binnen de bedrijfsomgeving detecteren. Niet alle nodige applicaties om het proces tot een goed 43

60 einde te brengen, kunnen aanwezig zijn. Sommige BPM-applicaties ondersteunen een omgeving om daarin extra applicaties en diensten te modelleren. Ook dit zal een punt van evaluatie vormen. Als de eindgebruikers het proces uitvoeren, zal de manier van interactie tussen hen en de applicatie van cruciaal belang zijn voor een goed verloop. De gebruikers verzenden hun informatie in de vorm van formulieren, waarvoor beroep gedaan kan worden op externe applicaties.dit kan ook binnen de BPM-applicatie zelf geregeld worden. Via een Web Portaal kunnen deze User Interfaces(UI) op handige wijze ondersteund worden. Voor de eindgebruiker vergemakkelijkt dit de toegang door de bedrijfsomgeving heen. Deze UI s kunnen gecreëerd worden in de BPM-applicaties zelf. Soms wordt zelfs een volledig automatische generatie voorzien waarbij de nodige customisatie- en personalisatieopties komen kijken.typisch bij een User Interface is bijvoorbeeld een takenlijst waarop de nog af te werken opdrachten worden weergegeven. Vanuit deze lijst kunnen de gebruikers dan per activiteit de nodige applicaties of diensten inroepen. (Leymann, Web Services: Distributed Applications without Limits, 2003) User Management zal geïmplementeerd moeten worden om de verschillende gebruikers de juiste informatie te tonen. Door rollen te definiëren moeten BPMproducten duidelijk kunnen onderscheiden welke gebruikers tot welke data toegang krijgen. Deze rollen kunnen overgenomen worden uit externe systemen, servers of zelfs uit de gebruikte authentificatie binnen het besturingssysteem. Men moet ze de nodige mogelijkheden toekennen. Ze kunnen ook manueel gedefinieerd worden in de BPMS. Net als voor de modelleringscriteria, wordt door Koster (2009) aan elk criterium een puntenwaarde toegekend. Designcriteria Methode puntentoekenning 1. Ondersteuning voor uitvoerbare procesmodellen Ondersteuning voor Business Process Execution-talen. Ondersteuning voor een enkele taal resulteert in 6 punten. Per extra taal waarbij de interoperabiliteit wordt gegarandeerd, wordt een extra punt toegekend. (tot een maximum van 10) 44

61 1.2. Ondersteuning van manuele en automatische vertaling tussen Business Process modelleertalen en Business Process Execution-talen Ondersteuning voor het linken van het uitvoerbare model aan het grafische model. 2. Ondersteuning voor programmeertalen voor het implementeren van diensten en applicaties. Voor elke combinatie van ondersteunde modelleer- en uitvoeringstalen, wordt er per automatische vertaling 10 punten toegekend en per manuele 0 punten. Al deze punten worden uiteindelijk opgeteld en gedeeld door het aantal mogelijke combinaties. Als alle synchronisatie manueel gebeurt, krijgt het BPM-systeem 0 punten. Als de verandering van een grafisch naar een uitvoerbaar model automatisch gebeurt, verdient het systeem 5 punten. Dit stijgt naar 8 punten indien aanpassingen langs beide kanten automatisch in beide modellen wijzigingen teweeg brengen. Als het grafische model rechtstreeks uitvoerbaar wordt (zonder dat er specifiek naar een uitvoerbaar model moet worden overgegaan), verdient de tool 10 punten. Eén of meerdere ondersteunde programmeertalen uit de top 15 van de TIOBE Programming Community Index verdient 10 punten. Indien er geen ondersteuning is voor programmeertalen, verdient de tool 0 punten. 3. Ondersteuning voor het ontwerpen van User Interfaces Ondersteuning voor externe applicaties voor data-invoer Ondersteuning voor databanken Ondersteuning resulteert in 10 punten. Geen ondersteuning leidt tot 0 punten. Ondersteuning voor 1 databanktechnologie resulteert in 5 punten. Per extra technologie wordt 1 punt toegevoegd (tot een maximum van 10 punten) 3.3. Ondersteuning voor Ondersteuning resulteert in 10 punten. Geen 45

62 online portaaltechnologie Ondersteuning voor een activiteitenlijst. ondersteuning leidt tot 0 punten. Ondersteuning voor de activiteitenlijst binnen een online portaal resulteert in 7 punten. Hierbij worden 3 extra punten toegekend, als de lijst hergebruikt kan worden in een aparte applicatie of een extern portaal. 4. Ondersteuning voor User Management 4.1. Manieren voor omschrijving van rollen 4.2. Ondersteuning voor het bepalen van de mogelijkheden op basis van een organisatierol Ondersteuning voor het importeren van organisatiestructuren uit externe systemen Ondersteuning voor het manueel toekennen van een gebruiker aan een rol Ondersteuning voor het automatisch toekennen van een gebruiker aan een rol, gebaseerd op zijn mogelijkheden Ondersteuning voor toelating van activiteiten gebaseerd op rollen. Indien de omschrijving van rollen enkel bij naam of bij mogelijkheden wordt ondersteund, verdient de tool 5 punten. 10 punten worden toegekend als de beide manieren worden ondersteund. Ondersteuning resulteert in 7 punten. Hieraan worden 3 extra punten toegevoegd als er rollen gedefinieerd door de gebruiker aan toegevoegd kunnen worden. Ondersteuning resulteert in 10 punten. Geen ondersteuning leidt tot 0 punten. Automatische toekenning resulteert in 10 punten. Manueel zorgt voor 7 punten. Geen ondersteuning leidt tot 0 punten. Ondersteuning resulteert in 10 punten. Geen ondersteuning leidt tot 0 punten. 46

63 INTERACTIE Dit is een belangrijk en bepalend aspect voor de eindgebruiker en zijn gebruikservaring van de tool. Het proces stelt een opeenvolging van verschillende activiteiten voor, waarbij sommige geautomatiseerd worden en sommige door mensen moeten worden uitgevoerd. Hiervoor wordt een sub-fase binnen het proces opgestart. Deze interactieprocessen zijn meestal beperkt in hun complexiteit in vergelijking met andere procesmodellen. Eerst wordt de gebruiker geïnformeerd over de noodzakelijke interactie. Deze bestaat uit twee soorten. Enerzijds worden er data aangeleverd waarop de gebruiker moet reageren. Dit kan aan de hand van andere programma s die ingeroepen worden, via een Webportaal, een pop-up met meerkeuzevragen De mogelijkheden kunnen redelijk uitgebreid zijn naargelang het proces en de soort data. Anderzijds moet de gebruiker ook reageren op uitzonderingen. Processen kunnen tijdens het uitvoeren immers altijd op onverwachte afwijkingen stoten. Hierop kan geen geautomatiseerd antwoord ingebouwd worden, dus zal een gebruiker moeten tussenkomen om hiervoor een oplossing te bedenken. Figuur 15: Interacties Er bestaan twee mogelijke manieren om de aandacht van de gebruiker te vestigen op de nood van zijn tussenkomst. Een BPM-tool kan hem op een passieve manier op de hoogte brengen met als gevolg dat de activiteit gewoon aan de lijst wordt toegevoegd. In veel gevallen wordt dit echter over het hoofd gezien of zelfs vergeten. Er kan echter ook op een actievere manier aan de gebruiker worden verduidelijkt dat interactie noodzakelijk is, bijv. door naast het toevoegen van de activiteit op de lijst, ook een mail te verzenden. Ook voor deze criteria kent Koster (2009) een bepaalde puntenwaarde toe, zodat deze ook in de evaluatie opgenomen kunnen worden. 47

64 Interactiecriteria Methode puntentoekenning 1. Ondersteuning voor informeren van de gebruiker 1.1. Ondersteuning voor actieve informatie 1.2. Ondersteuning voor passieve informatie Als de gebruiker geïnformeerd kan worden via , krijgt de tool 8 punten. Hierbij wordt er voor elke extra methode die ondersteund wordt 1 punt bijgeteld. Ondersteuning resulteert in 10 punten. 0 punten worden toegekend als er geen ondersteuning voorzien wordt MONITOREN EN CONTROLE Eens het proces uitgevoerd wordt, is controle en monitoring cruciaal. Het management moet continu op de hoogte zijn hoe het met de uitgevoerde processen gesteld is. Monitoring kan men vanuit twee verschillende invalshoeken benaderen, namelijk een technisch en een bedrijfsperspectief. Het technisch opvolgen van de processen is van groot belang voor een efficiënt systeem. Het identificeren en oplossen van mogelijke technische problemen of abnormaliteiten is onmogelijk zonder enige vorm van controle. Mogelijke problemen die zich kunnen voordoen tijdens het uitvoeren van een proces zijn: het stoppen van de werking van nodige servers, problemen met netwerkverbindingen, het ontoegankelijk worden van data Om dit te vermijden, moeten parameters zoals responstijden en systeembelasting nauwkeurig opgevolgd worden. In principe is het technisch opvolgen van een BPM-tool niet verschillend van het monitoren van complexe applicatiesystemen door technische specialisten. Omdat een technische analyse buiten de scope van dit onderzoek ligt, wordt hier ook niet verder op ingegaan. Het bedrijfsperspectief is de andere invalshoek. Eens een proces wordt opgestart in een BPM-tool wordt hiervoor een procesinstantie aangemaakt, als voorstelling van een lopend proces. Het monitoren van deze instanties kan op een actieve manier gebeuren via Push-technologie of passief via Pull-technologie. (Muehlen & Rosemann, 2000). Actief monitoren gebeurt aan de hand van Business Activity Monitoring. Hierin zal de eindgebruiker (met de juiste permissies binnen het systeem) het proces en de daarbij horende procesinstanties in realtime opvolgen. De verzamelde gegevens kunnen in 48

65 de vorm van grafieken in rapporten worden gegoten. (Golfarelli, Rizzi, & Cella, 2004) Er wordt uitgegaan van de logbestanden die de BPM-tool genereert. Als aanvullende waarden worden hierbij vaak metrieken zoals procestijd of eventuele voor het proces relevante KPI s berekend. Deze KPI s worden in sommige BPM-tools geanalyseerd aan de hand van statistische berekeningen. Er kunnen manueel minimum- of maximumwaarden worden ingevoerd. In sommige tools kunnen deze berekend worden op basis van historische waarden. (Gillot, 2008) Mocht het proces tijdens de uitvoering een van deze grenzen overschrijden, dan wordt de gebruiker op de hoogte gebracht. Dit is een veel gebruikte techniek bij Management-by-Exception. Hierbij komt het management enkel tussen in het geval van een uitzondering. Zo analyseert men historische gegevens die verzameld worden in de logs van de tool voor voorspellingen, waardoor onwenselijke situaties in de toekomst vermeden worden. (Casati, Dayal, Sayal, & Shan, 2004) (Whiting, 2006) Het passief monitoren van de processen omvat enkel het opvragen van de informatie over de lopende procesinstanties zodat hierop gereageerd kan worden indien nodig. Dit is een functie die normalerwijze in elke tool wordt voorzien. (Koster, 2009) De verschillende gebruikers die de processen monitoren, hebben ieder hun eigen vereisten in de manier hoe ze hun procesinstanties willen bekijken. De interesse van het topmanagement in de processen zal op een ander niveau gebeuren dan een gebruiker die verantwoordelijk is voor één proces. Hiervoor moet de tool de mogelijkheid voorzien om op verschillende detailniveaus te kunnen analyseren. (Leymann & Roller, 2002) Ook zorgen deze meerdere manieren voor de mogelijkheid om de eventuele complexiteit van de logs te verbergen. (Muehlen & Rosemann, 2000) De informatie voor het monitoren wordt op typische wijze weergegeven in een dashboard. Uitgaande van de verkregen informatie door het monitoren, ontstaat de wens tot wijzigingen aan de processen. Dit omvat dan het aspect van bedrijfscontrole in plaats van enkel monitoring. Deze gewenste aanpassingen kunnen gelden voor één of meerdere procesinstanties. Indien het om één procesinstantie gaat, kan men dit beschouwen als het omgaan met een uitzondering. Als het om permanente wijzigingen gaat, gaat men het proces herontwerpen. Er bestaan verschillende methodes om mogelijke veranderingen te hanteren: (Dickson K.W. Chiu & Karlapalem, 1999) 1) Procesinstantie-evolutie: a. Veranderende rol of bron vereist voor een activiteit b. Veranderende mogelijkheden van rollen of gebruikers 49

66 c. Veranderingen binnen de organistiestructuur d. Veranderende voorwaarden door het toevoegen een extra check e. Verwijderen van problematische paden binnen het proces f. Toevoegen of verwijderen van activiteiten 2) Toevoegen van expliciete Exception Handlers die automatische uitzonderingen gaan behandelen: a. Exception Handlers voor een bepaalde activiteit b. Het heruitvoeren van een bepaald stuk van het proces c. Het compenseren van eerder uitgevoerde activiteiten 3) Veranderingen van de bedrijfsregels 4) Veranderingen van de structuur van de activiteiten 5) Veranderingen binnen de werklast van verschillende gebruikers Ook deze literatuurstudie wordt samengevat binnen bepaalde criteria volgens Koster (2009). Aan elke criterium worden er ook kwantificeerbare waarden toegekend, zodat deze eveneens binnen het onderzoek kunnen opgenomen worden. Monitor- en controlecriteria 1. Ondersteuning voor technische monitoring en controle Methode puntentoekenning Ondersteuning voor technische controle en monitoring in de BPM tool leveren 10 punten op. 5 punten worden toegekend indien deze functies worden uitgevoerd door tools die losstaan van de BPMsuite, maar toch door dezelfde ontwikkelaar worden voorzien. 0 punten worden toegekend indien er geen ondersteuning wordt voorzien. 2. Ondersteuning voor bedrijfsmonitoring 50

67 2.1. Ondersteuning voor actieve monitoring 2.2. Ondersteuning voor passieve monitoring 2.3. Ondersteuning voor verschillende niveaus van detail 8 punten worden toegekend indien er een volledig geïntegreerde Business Activity Monitoring (BAM)-component wordt voorzien. Hierbij wordt telkens 1 punt toegekend per extra methode om de gebruiker op de hoogte te brengen (tot een maximum van 10 punten) 6 punten worden toegekend als het mogelijk is om rechtstreeks de status van een procesinstantie op te vragen. 4 extra punten worden hierbij toegekend als dit gedaan wordt aan de hand van een door de gebruiker gedefinieerde variabele (vb. naam van een klant.) Ondersteuning resulteert in 10 punten. 0 punten worden toegekend als er geen ondersteuning voorzien wordt. 3. Ondersteuning voor bedrijfscontrole Als een lopende procesinstantie niet kan gewijzigd worden, maar de wijziging geldt enkel voor een nieuwe instantie, worden 4 punten toegekend Ondersteuning voor procesinstantie-evolutie Als de wijziging toegepast wordt op alle lopende procesinstanties, worden 4 punten toegekend. 2 extra punten worden toegekend, indien de gebruiker de keuze heeft tussen de beide. 51

68 3.2. Ondersteuning voor veranderende bedrijfsregels 3.3. Ondersteuning voor veranderende activiteiten Ondersteuning voor veranderende bedrijfsregels tijdens het lopen van het proces krijgen 7 punten. Hierbij worden 3 extra punten toegevoegd, als er een optie wordt voorzien om de lopende procesinstanties te herevalueren. Als de lopende procesinstanties niet veranderd kunnen worden, maar de wijzigingen wel gelden voor nieuwe procesinstanties, worden 4 punten toegekend. Als de wijzigingen tellen voor alle lopende instanties, worden 4 punten toegekend. Hierbij worden 2 punten gerekend indien de gebruiker tussen beide kan kiezen Ondersteuning voor het veranderen van de werklast tussen gebruikers. 10 punten worden toegekend als de werklast kan gewijzigd worden zonder het procesmodel aan te passen. Enkel 4 punten worden toegekend als er wijzigingen moeten doorgevoerd worden binnen het procesmodel. 0 punten indien er geen wijzigingen mogelijk zijn. 52

69 3.3. VOORBEELD PROCES Om over te gaan tot het testen van deze criteria in de geselecteerde BPM-tools, wordt een proces geïmplementeerd. In dit onderzoek stellen we een algemene case voor over de aanvraag van een mobiel telefonie-abonnement. "Via een applicatieformulier schrijft een klant zich in op een mobiel telefonieabonnement. Op ieder formulier noteert hij zijn naam (voor- en familienaam), adres (straat, nummer, stad en postcode), geboortedatum (dag, maand en jaar) alsook het type abonnement dat hij zich wil aanschaffen (prijs per maand en duur van het abonnement). Gebaseerd op de informatie die de klant verstrekt in zijn applicatieformulier, berekent een gespecialiseerde dienst automatisch het risico en classificeert de aanvraag als laag of hoog risico. Bij laag risico volgt automatisch de goedkeuring van de aanvraag. Bij hoog risico kijkt men eerst na of er schulden openstaan. Op basis van het resultaat van deze check beslist een manager om de aanvraag al dan niet goed te keuren. Goedgekeurde applicaties worden nadien nog geverifieerd door een werknemer, want ook de data van het aanvraagformulier moeten correct zijn. Via informeert men de klant van het aanvaarden of weigeren van de aanvraag. Bij eventuele weigering wordt de reden hiervoor duidelijk gecommuniceerd in de mail." (Koster, 2009) 53

70 54 Figuur 16: Voorbeeld proces

71 4. ACTIVITI 4.1. INLEIDING SITUERING Het Activiti project is gestart in 2010 door Tom Baeyens en Joram Barrez. Als voormalig oprichter en hoofdontwikkelaar van jbpm (JBoss BPM) heeft Joram al de nodige ervaring met BPM-aplicaties. Activiti heeft als doel het ontwikkelen van een solide Open Source BPMN 2.0 Engine. Alfresco (bekend van het Open Source Document Management-systeem onder dezelfde naam) dient zich aan als investeerder, maar toch blijft Activiti bestaan als een onafhankelijk Open Sourceproject. Alfresco gebruikt de procesmanagementfunctionaliteit van Activiti om functies zoals het nakijken en goedkeuren van documenten te verwezenlijken. Figuur 17: Logo Activiti In december 2010 wordt de eerste stabiele versie van Activiti online aangeboden. Sindsdien wordt er continu aan voortgewerkt door een team van 18 ontwikkelaars. Tevens ontstaat er rond de applicatie een grote gemeenschap die gesteund wordt door verschillende bedrijven waaronder SpringSource, Next Level Integrations, MuleSoft, Fuse Source, Edorasware, Anchor, Atos en Salves PRODUCT Activiti kan men best omschrijven als een BPMN 2.0 Proces-Engine Framework. De tool is volledig ontworpen rond deze modelleertaal. Om vlot om te kunnen gaan met processen in dit modelformaat, kan men Activiti best beschouwen als een State Machine. Elke procesinstantie die opgestart wordt, krijgt een bepaalde status toebedeeld. Afhankelijk van het ontwerp van het proces zal deze status veranderen en extra informatie toegekend krijgen. Het doel is om de communicatie te verbeteren tussen degene die een software-oplossing nodig hebben en de ontwikkelaars die procesdiagrammen opstellen. 55

72 Om deze functionaliteit te realiseren, beschikt Activiti over de volgende componenten: Actviti Engine o Dit is het centrale onderdeel van de tool verantwoordelijk voor de BPMfunctionaliteit. Hieronder vallen bijvoorbeeld het aanmaken van de procesinstanties en het toekennen van de uit te voeren taken. Activiti Modeler o Deze component levert een modelleeromgeving in de browser. Hiermee kunnen volwaardige BPMN 2.0 procesmodellen ontworpen worden. Dit onderdeel wordt aangeboden door Signavio, ook wel bekend van de commercieel beschikbare modelleertool Signavio Process Editor. Activiti Designer o Dit onderdeel bestaat uit een Eclipse plugin-modelleertool om BPMN 2.0 procesmodellen te ontwerpen. Ook de toevoeging van Activiti Extensies, zoals Java Service-taken en executielijsten kunnen hierin ontwikkeld worden. In dit onderdeel worden ook processen geïmporteerd, geëxporteerd en getest. Hiermee creëert men ook Deployment-artefacten. De functionaliteit van deze component is uitgebreider dan de Activiti Modeler. Hierdoor is dit Designer onderdeel meer gericht op een technische ontwikkelaar, terwijl de Modeler meer focust op de bedrijfsgebruikers. Activiti Explorer o Dit onderdeel omvat het webportaal van de Activiti Engine. De eindgebruiker kan hier toegang krijgen tot zijn processen en takenlijst. Men kan ook procesmanagement, zoals het opstarten van nieuwe procesinstanties en taken hierin uitvoeren. Activiti REST o Deze component geeft rechtstreeks toegang tot de Process Engine. REST staat voor Representational State Transfer en ondersteunt de State Machine functionaliteit van Activiti. Dit is een krachtig onderdeel aangezien het de automatisering van veel functies mogelijk maakt. (Pautasso, 2011) Dit maakt het mogelijk om rechtstreeks opdrachten te sturen naar het portaal zonder terug te vallen op het online portaal. Er worden verschillende services voorzien die ingeroepen kunnen worden. 56

73 Figuur 18: Overzicht Services Activiti REST ( SYSTEEMVEREISTEN De systeemvereisten van Activiti kunnen geen problemen vormen. De architectuur en het ontwerp van het programma zijn erop gericht om zo efficiënt mogelijk met bronnen om te gaan, zonder verlies te lijden op het vlak van performantie. Na uitvoerig testen door de ontwikkelaars, is vastgesteld dat Activiti gemiddeld 12 mb RAM nodig heeft om vlot te werken. (Barrez, 2013) BEDRIJFSMODEL Activiti is volledig gratis beschikbaar als Open Source-download. Hierbij krijg je volledige toegang tot de broncode van alle verschillende componenten. Hiernaast kunnen organisaties ook kiezen voor een betalend alternatief namelijk Alfresco Activiti Enterprise Offering. Dit pakket omvat hetzelfde programma als de Open Source-versie maar komt samen met volledige ondersteuning door Alfresco en een uitgebreidere administratie-applicatie. (Rademakers, 2014) 57

74 4.2. MODELLERING Elke score die toegekend wordt in de evaluatie van een tool, is gebaseerd op de voorwaarden die in hoofdstuk Modellering zijn vastgelegd MODELLEERTALEN EN HUN INTEROPERABILITEIT Activiti is volledig gericht en ontworpen rond BPMN 2.0. Dit is dan ook de enigste modelleertaal die ondersteund wordt. De Activiti Modeler maakt het aanmaken van dergelijke modellen in een webomgeving zeer toegankelijk. Score = VERSCHILLENDE VIEWS TIJDENS HET MODELLEREN Ook al worden subprocessen zeer vlot geïmplementeerd, toch kan er geen onderscheid gemaakt worden tussen de verschillende views zoals deze in de literatuur (List & Korherr, 2006) gedefinieerd zijn. Score = IMPLICIETE BEDRIJFSREGELS BPMN 2.0 heeft als eigenschap dat binnen Activiti de bedrijfsregels rechtstreeks in het model kunnen worden opgenomen. In de vorm van een Business Rule Task kan de nodige logica binnen het model gecodeerd worden. Deze taak werkt op basis van een vooraf gedefinieerde input, waarmee dan verder gewerkt wordt om het gewenste resultaat te bekomen. Score = EXPLICIETE BEDRIJFSREGELS Activiti biedt ook de mogelijkheid om via Drools bedrijfsregels te managen losstaand van een procesmodel. Drools is een door Apache gelicencieerd Jboss project dat volledige bedrijfsregelfunctionaliteit ondersteunt. Het bestaat uit verschillende subprojecten. In deze context is enkel Drools Expert relevant. Dit subproject omvat de eigenlijke regel-engine en komt samen met een eclipse gebaseerde managementomgeving. Score = PROCESSEN IN TABELVORM Bij het opstellen van procesmodellen, kunnen deze ook volledig in tabelvorm ontwikkeld worden. Deze vorm van modelleren is op een logische manier opgebouwd en daarom erg toegankelijk. In plaats van volledige diagrammen uit te werken, kan de ontwikkelaar de naam, uitvoerder, groep, omschrijving, de voorwaarden voor uitvoering en de nodige acties per activiteit in tabelvorm invoeren. Het eindelijke resultaat wordt dan door de Activiti Modeler vertaald naar een BPMN 2.0 grafiek. 58

75 Figuur 19: Screenshot modelleerkeuze (Activiti) Score = KEY PERFORMANCE INDICATORS KPI s definiëren via volledige natuurlijke taal of een grafische notatie is niet mogelijk. Coderen kan wel aangezien het een Open Source-applicatie is. Score = 3 59

76 4.3. DESIGN Elke score die toegekend wordt in de evaluatie van een tool, is gebaseerd op de voorwaarden die in hoofdstuk Design zijn vastgelegd BUSINESS PROCESS EXECUTION-TALEN De enigste ondersteunde taal is BPMN 2.0. Activiti is ontworpen in functie van deze taal waardoor er geen mogelijkheid is voor ondersteuning van extra talen. Score = AUTOMATISCHE EN MANUELE VERTALING De automatische vertaling wordt voorzien binnen BPMN 2.0 Score = LINK UITVOERBAAR EN GRAFISCH MODEL Het grafisch model wordt rechtstreeks uitvoerbaar gemaakt via BPMN 2.0. Score = PROGRAMMEERTALEN De API geleverd bij Activiti is ontwikkeld in Java, waardoor alle verdere ontwikkelingen in dezelfde taal kunnen gebeuren. In de Tiobe Programming Index voor maart 2014 staat Java op nr. 2 genoteerd. (TIOBE, 2014) Er kan ook nog beroep gedaan worden op andere programmeertalen om bepaalde aspecten van Activiti aan te roepen. Het ondersteunen van programmeertalen is eigen aan het Open Source-karakter van de tool. Score = EXTERNE APPLICATIES Activiti voorziet verschillende mogelijkheden om te connecteren naar externe applicaties. Met de Java-gebaseerde API kan een applicatie ingeroepen worden. Om met verschillende technologieën samen te werken wordt dit echter snel zeer complex. De nood om EAI vlot te verwezenlijken wordt opgelost door de samenwerking binnen Activiti met Mule ESB en Apache Camel. Beide programma s verzorgen de integratie met externe applicaties. Apache Camel is een Open Source-Java integratie framework gebaseerd op drie basiselementen: eindpunten, processoren en componenten. Mule ESB is een veel gebruikte en populaire Open Source Enterprise Service Bus. Het voorziet een uitgebreid aanbod aan connectors, ondersteuning voor Enterprise-integratiepatronen en een gemakkelijk te leren Flow-taal. (Ibsen & Anstey, 2011) (Dossot & D'Emic, 2010) Score = 10 60

77 DATABANKEN Mule ESB voorziet ook de integratie met een zeer uitgebreid aanbod databanken. Voorbeelden zijn DB2, JDBC, Hadooip HDFS, Microsoft SQL Server, MongoDB, MySQL, Oracle DB,... Score = ONLINE PORTAAL Activiti werkt vanuit een online portaal. Score = 10 Figuur 20: Screenshot inlogscherm (Activiti) TAKENLIJST Eens aangemeld op het online portaal, komt men rechtstreeks op een takenlijst terecht. Figuur 21: Screenshot takenlijst (Activiti) 61

78 Score = ROLLENOMSCHRIJVING Men kan rollen omschrijven op basis van een groepensysteem, waarbij elke groep dan een rol omvat. Dit lukt echter enkel bij naam. De mogelijkheden kunnen pas vastgelegd worden bij de ontwikkeling van het proces. Score = 5 Figuur 22: Screenshot rollen (Activiti) MOGELIJKHEDEN OP BASIS VAN EEN ROL Elke groep wordt geassocieerd met een aantal processen. De gebruiker kan hier geen invloed op uitoefenen. Score = ORGANISATIESTRUCTUREN UIT EXTERNE SYSTEMEN Activiti kan geen organisatiestructuren importeren. Score = MANUEEL OF AUTOMATISCH TOEKENNEN VAN GEBRUIKERS Als men via het portaal gebruikers wil toekennen aan een rol zal dit manueel moeten gebeuren. Hiernaast kan Activiti REST dit automatiseren via de Identity Service. Score = ACTIVITEITEN TOELATEN OP BASIS VAN ROLLEN Op basis van een rol moet aan elke activiteit een rol toegekend worden Score = 10 62

79 4.4. INTERACTIE Elke score die toegekend wordt in de evaluatie van een tool, is gebaseerd op de voorwaarden die in hoofdstuk Interactie zijn vastgelegd ACTIEVE INFORMATIE Het informeren van de gebruikers kan enkel via het portaal gebeuren en niet op een actieve manier. Score = PASSIEVE INFORMATIE Informatie via het portaal valt onder passieve informatie. Score = 10 63

80 4.5. MONITOREN EN CONTROLE Elke score die toegekend wordt in de evaluatie van een tool, is gebaseerd op de voorwaarden die in hoofdstuk Monitoren en controle zijn vastgelegd TECHNISCHE MONITORING EN CONTROLE Technische rapportering is niet mogelijk binnen Activiti. Score = ACTIEVE MONITORING Data met betrekking tot het verloop kunnen in het online portaal opgevraagd worden in de vorm van verschillende rapporten. Deze kunnen aangepast worden zodat enkel de data die relevant zijn voor de gebruiker, getoond worden. Deze data worden gevisualiseerd in bepaalde grafieken. Dit is echter de enige mogelijkheid om de gebruikers op de hoogte te brengen. Score = 8 Figuur 23: Screenshot actieve monitoring (Activiti) 64

81 PASSIEVE MONITORING Van elke procesinstantie kan de status opgevraagd worden. Aan de hand van een procesdiagram kan deze status dan samen met alle relevante data weergegeven worden. Score = 6 Figuur 24: Screenshot passieve monitoring (Activiti) VERSCHILLENDE DETAILNIVEAUS Verschillende detailniveaus zijn niet mogelijk binnen Activiti. Score = PROCESINSTANTIE-EVOLUTIE Activiti hanteert het volgende principe om met procesveranderingen om te gaan: Wanneer een nieuwe procesdefinitie is gedeployed, worden alle nieuwe proces instanties op deze procesdefinitie gestart. Alle overige procesinstanties die nog lopen op het moment van deployment, zullen blijven lopen tegen de oude procesdefinitie. (Rademakers, 2012) De Engine kan hierop een uitzondering maken. Nieuwe procesinstanties kunnen nog uitgevoerd worden volgens oude procesdefinities. De oude procesinstanties kunnen wel niet overgezet worden naar de nieuwe procesdefinities. 65

82 Score = VERANDERENDE BEDRIJFSREGELS Indien een procesinstantie reeds aan het lopen is, maar de bedrijfsregel nog niet voorgekomen is tijdens het procesverloop, dan kan deze regel alsnog gewijzigd worden, op voorwaarde dat ze expliciet werd toegevoegd. Er wordt dan echter geen wijziging van het procesdiagram doorgevoerd, aangezien er enkel een verwijzing naar de bedrijfsregel opgenomen is. Lopende instanties die reeds geëvalueerd werden door de bedrijfsregel kan men niet opnieuw laten evalueren. Score = VERANDERENDE ACTIVITEITEN EN WERKLAST De werklast en activiteiten worden telkens vastgelegd binnen het procesmodel. Als deze gewijzigd worden, zal de aanpassing pas gelden voor de nieuwe opgestarte procesinstanties. Beide criteria krijgen dus dezelfde score. Score = 4 66

83 4.6. Samenvatting Activiti Modelleercriteria 1. Procesmodellering 1.1. Ondersteuning voor verschillende grafische modelleertalen Ondersteuning voor interoperabiliteit tussen modelleertalen Ondersteuning voor verschillende perspectieven van een proces Ondersteuning voor het modelleren met impliciete bedrijfsregels Ondersteuning voor het modelleren met expliciete bedrijfsregels Ondersteuning voor het volledig modelleren van processen met expliciete bedrijfsregels in tabelvorm Indicatoren 2.1. Ondersteuning voor KPI s. 3 Tussentotaal: Modelleercriteria 41 Designcriteria 3. Uitvoerbare procesmodellen Ondersteuning voor Business Process Execution-talen Ondersteuning van manuele en automatische vertaling tussen Business Process modelleertalen en Business Process Executiontalen Ondersteuning voor het linken van het uitvoerbare model aan het grafische model Programmeertalen voor het implementeren van diensten en applicaties 4.1. Ondersteuning voor verschilllende programmeertalen User Interfaces Ondersteuning van externe applicaties voor data-invoer Ondersteuning voor databanken

84 5.3. Ondersteuning voor online portaaltechnologie Ondersteuning voor een activiteitenlijst User Management 6.1. Manieren voor omschrijving van rollen Ondersteuning van het bepalen van de mogelijkheden op basis van een organisatierol Ondersteuning voor het importeren van organisatiestructuren uit externe systemen Ondersteuning voor het manueel toekennen van een gebruiker aan een rol Ondersteuning voor het automatisch toekennen van een gebruiker aan een rol, gebaseerd op zijn mogelijkheden Ondersteuning voor activiteiten toelatingen gebaseerd op rollen. 10 Tussentotaal: Designcriteria 105 Interactiecriteria 7. Informeren van de gebruiker 7.1. Ondersteuning voor actieve informatie Ondersteuning voor passieve informatie. 10 Tussentotaal: Interactiecriteria 10 Monitor- en controlecriteria 8. Technische monitoring en controle 8.1. Ondersteuning technische monitoring en controle Ondersteuning voor bedrijfsmonitoring 9.1. Ondersteuning voor actieve monitoring Ondersteuning voor passieve monitoring Ondersteuning voor verschillende niveaus van detail. 0 68

85 10. Ondersteuning voor bedrijfscontrole Ondersteuning voor procesinstantie-evolutie Ondersteuning voor veranderende bedrijfsregels Ondersteuning voor veranderende activiteiten Ondersteuning voor het veranderen van de werklast tussen gebruikers. 4 Tussentotaal: Monitor- en controlecriteria 33 Totaal

86 5. PROCESSMAKER 5.1. INLEIDING SITUERING Processmaker is de Open Source BPM-oplossing ontwikkeld door Colosa. De eerste versie van dit project zag het levenlicht in ProcessMaker heeft als doel het ontwikkelen van een eenvoudig, vlot te gebruiken tool. De slogan Workflow Simplified omvat deze gedachte volledig. Dit pakket benadert de BPM-markt op een andere manier dan de meeste beschikbare OS oplossingen. De broncode is vrij beschikbaar, maar enkel als een cloud-oplossing. Er is geen downloadbare versie beschikbaar van Processmaker. Men spreekt van Open Source as a Service (OSAAS) Figuur 25: Logo ProcessMaker De laatste jaren heeft ProcessMaker een aanzienlijk marktaandeel verworven door onder andere een samenwerking met SugarCRM, een Customer Relationship Management-applicatie die zowel commercieel als in een Open Source-versie beschikbaar is. Een duidelijke vraag van de gebruikers naar een grotere BPMfunctionaliteit, een krachtiger visueel procesmodel, designcomponent en Engine binnen CRM applicaties waren voor Colosa reden genoeg om deze samenwerking aan te gaan. (Destination CRM, 2012) PRODUCT ProcessMaker is een volledige cloud-oplossing en bestaat uit een online portaal waarop de gebruiker zich aanmeldt. Tijdens dit onderzoek wordt gebruik gemaakt van een proefversie van dit portaal met volledige functionaliteit. Hierin kan men vier verschillende onderdelen in onderscheiden: Home o Dit is het startscherm waarop de gebruiker terecht komt als hij zich aanmeldt. Hierop kan hij processen opstarten, zoeken door de lopende processen, filteren op status... Ook worden andere functionaliteiten aangeboden, zoals een client en een Interface waarin bestanden gedeeld kunnen worden. Deze s en bestanden kunnen rechtstreeks gelinkt worden aan de processen. 70

87 Designer o In het Designer-tabblad wordt een overzicht gegeven van de verschillende processen binnen het portaal. Indien de juiste rechten zijn toegekend aan de gebruiker kan die van hieruit de processen managen en er dus voor zorgen dat elk proces in de browser kan worden aangemaakt, aangepast, verwijderd, geïmporteerd of geëxporteerd. Dashboards Admin o De dashboard-module geeft een overzicht van bepaalde grafieken met procesgerelateerde data. Dit dashboard kan gepersonaliseerd worden per gebruiker. o Deze component omvat de verschillende configuratie Interfaces. Hierin wordt nog een onderverdeling gemaakt naar settings, Users, logs en plugins SYSTEEMVEREISTEN De laatst beschikbare en dus de gebruikte versie is ProcessMaker 2.5. Hardware o Server Type Minimum Aangeraden Processor 3.O GHz Pentium IV of beter 2 CPU Cores (indien meer dan 10 gebruikers) Geheugen Ram 1GB RAM MB RAM per extra gebruiker Vrij geheugen op de harde schijf 30 GB 30 GB o Client-stations Type Processor Geheugen Ram Minimum Pentium IV 256 MB RAM (Windows XP of Linux), 512 MB RAM (Windows Vista/7) 71

88 Connectie Breedband of lokale netwerkconnectie 72 Software o Besturingssystemen GNU/Linux UNIX Windows (XP, Vista, 7, Server 2003, Server 2008) o Web Server Apache of hoger met de volgende functies: o Databanken o Talen Deflate Expires Rewrite Vhost_alias Voor ProcessMaker 1.6 of hoger: MySQL of hoger Voor ProcessMaker 1.8 of hoger: MySQL of hoger Voor ProcessMaker 2.5 of hoger: MySQL of hoger PHP of hoger (maar geen PHP 5.3.X als ProcessMaker 1.8 of lager gebruikt wordt) BEDRIJFSMODEL ProcessMaker wordt uitgegeven onder een dubbele licentie. Beide zijn ontworpen om aan de vereisten van verschillende gebruikers en hun noden te voldoen. Er wordt een broncode vrijgegeven maar afhankelijk van de manier waarop je deze wenst te gebruiken wordt de keuze van je licentie bepaald. De twee beschikbare licenties zijn de GNU Affero General Public Licentie (AGPLv3) en een commerciële licentie. Kies je voor de Open Source-licentie of de AGPL, ben je vrij ProcessMaker te gebruiken onder de voorwaarden vastgelegd in de GNU AGPL-licentie, versie 3. Deze vorm van vergunning is een uitgebreidere versie van de GPL-licentie. Dit houdt in dat als je gebruikt maakt van een broncode die hierdoor beschermd wordt binnen

89 een applicatie, je ook je eigen broncode van die applicatie moet bekend maken. De AGPL-licentie gaat hierin nog een stap verder. Indien je een beschermde broncode gebruikt op een server die connecteert naar het netwerk als een Software-as-a- Service (Saas) of een Applicatie Service Provider (ASP), dan moet je ook je broncode van je applicatie bekend maken. Indien je geen gebruik wil maken van de AGPL-licentie, kan je ook beroep doen op de commerciële licentie, namelijk een overeenkomst met Colosa, Inc. (het bedrijf dat ProcessMaker ontwikkelt en alle rechten beheert). Deze vorm van licentie kan men in verschillende vormen met verschillende prijzen afhankelijk van het soort contract aankopen namelijk: ProcessMaker Cloud Edition ProcessMaker On-Premise Enterprise Editions ProcessMaker SugarCRM Edition 73

90 5.2. MODELLERING Elke score die toegekend wordt in de evaluatie van een tool, is gebaseerd op de voorwaarden die in hoofdstuk Modellering zijn vastgelegd MODELLEERTALEN EN HUN INTEROPERABILITEIT Binnen ProcessMaker is slechts één modelleertaal beschikbaar. Die is ontwikkeld voor de tool zelf en is niet gebaseerd op een beschikbare standaard. De modelleertaal werkt zeer intuïtief en is beperkt in functionaliteit. Figuur 26: Screenshot modelleermodule (ProcessMaker) De ontwerpfunctionaliteit gaat uit van Dynaforms. Dit zijn formulieren waarin je kan bepalen welke data de gebruikers kunnen invoeren of zien. Het proces wordt dan volledig opgebouwd uit aan elkaar gelinkte Dynaforms. Score = 6 74

91 Figuur 27: Screenshot Dynaform (ProcessMaker) VERSCHILLENDE PERSPECTIEVEN TIJDENS HET MODELLEREN Tijdens het modelleren kan men niet verwisselen tussen verschillende perspectieven. Score = IMPLICIETE BEDRIJFSREGELS Bedrijfsregels kunnen rechtstreeks opgenomen worden in de modellen. 75

92 Figuur 28: Screenshot impliciete bedrijfsregels (ProcessMaker) Score = EXPLICIETE BEDRIJFSREGELS Expliciete bedrijfsregels kunnen niet opgenomen worden. De regels zitten altijd ingewerkt in het procesmodel. Score = PROCESSEN IN TABELVORM Processen kunnen niet opgesteld worden in tabelvorm binnen ProcessMaker. Score = KEY PERFORMANCE INDICATORS Key Performance Indicators worden niet ondersteund binnen ProcessMaker. Deze functionaliteit kan wel bereikt worden via een samenwerking met Pentaho BI. Score = 0 76

93 5.3. DESIGN Elke score die toegekend wordt in de evaluatie van een tool, is gebaseerd op de voorwaarden die in hoofdstuk Design zijn vastgelegd BUSINESS PROCESS EXECUTION-TALEN In ProcessMaker worden de ontworpen processen rechtstreeks uitgevoerd zonder onderscheid te maken tussen een grafische en uitvoerende modelleertaal. Dit zorgt voor een eenvoudige benadering, maar veroorzaakt een grote beperking in het aanpassen van de modellen. Zo moet men om gegevens in verband met de uitvoering aan te passen telkens in de grafische modelleeromgeving werken. Dit valt niet te vergelijken met BPMN 2.0 waarbij grafische processen ook rechtstreeks uitvoerbaar zijn. Het grote verschil zit in de generatie van een achterliggende Business Process Execution-taal, wat hier niet aanwezig is. Score = AUTOMATISCHE EN MANUELE VERTALING Aangezien er geen toegankelijk uitvoerbaar model is, is dit criterium niet van toepassing. Score = LINK UITVOERBAAR EN GRAFISCH MODEL Aangezien er geen toegankelijk uitvoerbaar model is, is dit criterium niet van toepassing. Score = PROGRAMMEERTALEN ProcessMaker ondersteunt PHP en Javascript als programmeertalen. Beide staan in de top 15 van de TIOBE programming Index. (TIOBE, 2014) Score = EXTERNE APPLICATIES ProcessMaker ondersteunt verschillende Third Party Triggers, zoals Sharepoint DWS Triggers, SugarCRM, Alfresco en Zimbra. D Score = ONLINE PORTAAL ProcessMaker werkt volledig in de cloud en biedt bijgevolg een online portaal aan. 77

94 Figuur 29: Screenshot online portaal (ProcessMaker) Score = DATABANKEN ProcessMaker werkt automatisch samen met 3 MySQL databanken om de normale werking te ondersteunen. Er worden drie databanken voorzien: voor de informatie nodig om de Proces Engine te laten draaien, voor de rollen en User Management en om de connectiviteit met externe applicaties te managen. Hiernaast maakt ProcessMaker gebruik van Propel. Dit is een Open Source Mapping-tool voor objectrelaties ontwikkeld in PHP. Deze component maakt de connectie met MySQL, Microsoft SQL Server, PostgreSQL en Oracle databanken mogelijk. Score = TAKENLIJST Een takenlijst wordt voorzien in het online portaal. Deze kan echter niet in een andere omgeving overgenomen worden. 78

95 Figuur 30: Screenshot takenlijst (ProcessMaker) Score = ROLLENOMSCHRIJVING Rollen kunnen volledig gedefinieerd worden volgens naam en mogelijkheden. Score = 10 Figuur 31: Screenshot rollen (ProcessMaker) MOGELIJKHEDEN OP BASIS VAN EEN ROL In ProcessMaker kunnen de mogelijkheden aan elke rol worden toegekend. De gebruiker zelf kan hier geen invloed op uit oefenen. Figuur 32: Screenshot mogelijkheden op basis van een rol (ProcessMaker) Score = 7 79

96 ORGANISATIESTRUCTUREN UIT EXTERNE SYSTEMEN Volledige organisatiestructuren kunnen ontwikkeld worden in ProcessMaker. Er kan een opdeling gemaakt worden volgens departementen en groepen. Het importeren uit externe systemen is echter niet mogelijk. Score = 0 Figuur 33: Screenshot organisatiestructuur (ProcessMaker) MANUEEL OF AUTOMATISCH TOEKENNEN VAN GEBRUIKERS Alle gebruikers moeten manueel toegekend worden aan een rol. Automatisch toekennen is niet mogelijk. Score = ACTIVITEITEN TOELATEN OP BASIS VAN ROLLEN Elke activiteit binnen een proces moet een rol toegekend krijgen om deze uitvoerbaar te maken. Score = 10 80

97 5.4. INTERACTIE Elke score die toegekend wordt in de evaluatie van een tool, is gebaseerd op de voorwaarden die in hoofdstuk Interactie zijn vastgelegd ACTIEVE INFORMATIE Gebruikers kunnen via ervan op de hoogte gebracht worden dat hun input nodig is voor bepaalde activiteiten of beslissingen. Score = 8 Figuur 34: Screenshot actieve informatie (ProcessMaker) PASSIEVE INFORMATIE Gebruikers kunnen via het portaal alle relevante informatie opvragen. Score = 10 81

98 5.5. MONITOREN EN CONTROLE Elke score die toegekend wordt in de evaluatie van een tool, is gebaseerd op de voorwaarden die in hoofdstuk Monitoren en controle zijn vastgelegd TECHNISCHE MONITORING EN CONTROLE Technische monitoring binnen ProcessMaker is niet mogelijk. Score = ACTIEVE MONITORING Binnen ProcessMaker kunnen dashboards ontwikkeld worden bestaande uit grafieken en andere visualisaties van alle data omtrent de uitgevoerde processen. Deze kunnen volledig gepersonaliseerd worden door de gebruiker. Score = 8 Figuur 35: Screenshot dashboard (ProcessMaker) PASSIEVE MONITORING Van de processen waarvoor de gebruiker de juiste permissies heeft toegewezen gekregen, kan men de procesinstanties bekijken. De data worden overzichtelijk in een tabel weergegeven waarbij elke rij een procesinstantie voorstelt. De enigste manier om deze data op te vragen is per proces. Er is geen uitgebreidere zoekfunctionaliteit. Score = VERSCHILLENDE DETAILNIVEAUS 82

99 De grafieken binnen de dashboards zijn uitgerust met een bepaalde interactiviteit om verschillende detailniveaus te bekijken. Men spreekt van een Drill-Down door de data. Bijvoorbeeld kunnen eerst de gegevens per departement bekeken worden, vervolgens wordt het Finance Departement per werknemer geanalyseerd, om uiteindelijk op het laagste niveau de verschillende procesinstanties die uitgevoerd werden door een werknemer te bekijken. Score = 10 Figuur 36: Screenshot detailniveaus dashboard (ProcessMaker) 83

100 PROCESINSTANTIE-EVOLUTIE Als een nieuwe versie van een proces wordt ingevoerd, biedt ProcessMaker volgende keuzes aan. Alle lopende procesinstanties worden opnieuw geëvalueerd als de optie Update the current process wordt gekozen. Indien de tweede optie Disable the current process gekozen wordt, wordt de nieuwe procesdefinitie enkel toegepast op de nieuw opgestarte procesinstanties. Als de laatste optie wordt gekozen, wordt een volledig nieuw proces aangemaakt, naast het huidige. Score = 10 Figuur 37: Screenshot keuzemenu procesinstantie-evolutie (ProcessMaker) VERANDERENDE BEDRIJFSREGELS EN ACTIVITEITEN Hier geldt dezelfde regeling als bij de procesinstanties. De verandering moet in de procesdefinitie worden doorgevoerd, aangezien expliciete bedrijfsregels niet mogelijk zijn. Deze aanpassing zal dezelfde vraag genereren zoals in figuur 37. Voor de criteria in verband met de ondersteuning voor veranderende bedrijfsregels en activiteiten levert dat voor beide dezelfde score op. Score = VERANDERENDE WERKLAST De werklast kan niet losstaand van het procesmodel gewijzigd worden. Score = 4 84

101 5.6. Samenvatting Processmaker Modelleercriteria 1. Procesmodellering 1.1. Ondersteuning voor verschillende grafische modelleertalen Ondersteuning voor interoperabiliteit tussen modelleertalen Ondersteuning voor verschillende perspectieven van een proces Ondersteuning voor het modelleren met impliciete bedrijfsregels Ondersteuning voor het modelleren met expliciete bedrijfsregels Ondersteuning voor het volledig modelleren van processen met expliciete bedrijfsregels in tabelvorm Indicatoren 2.1. Ondersteuning voor KPI s. 0 Tussentotaal: Modelleercriteria 16 Designcriteria 3. Uitvoerbare procesmodellen Ondersteuning voor Business Process Execution-talen Ondersteuning van manuele en automatische vertaling tussen Business Process modelleertalen en Business Process Executiontalen Ondersteuning voor het linken van het uitvoerbare aan het grafische model Programmeertalen voor het implementeren van diensten en applicaties Ondersteuning voor verschilllende programmeertalen User Interfaces Ondersteuning van externe applicaties voor data-invoer Ondersteuning voor online portaaltechnologie

102 5.3. Ondersteuning voor databanken Ondersteuning voor een activiteitenlijst User Management 6.1. Manieren voor omschrijving van rollen Ondersteuning van het bepalen van de mogelijkheden op basis van een organisatierol Ondersteuning voor het importeren van organisatiestructuren uit externe systemen Ondersteuning voor het manueel toekennen van een gebruiker aan een rol Ondersteuning voor het automatisch toekennen van een gebruiker aan een rol, gebaseerd op zijn mogelijkheden Ondersteuning voor activiteiten toelatingen gebaseerd op rollen. 10 Tussentotaal: Designcriteria 79 Interactiecriteria 7. Informeren van de gebruiker 7.1. Ondersteuning van actieve informatie Ondersteuning voor passieve informatie. 10 Tussentotaal: Interactiecriteria 18 Monitor- en controlecriteria 8. Technische monitoring en controle 8.1. Ondersteuning technische monitoring en controle Ondersteuning voor bedrijfsmonitoring 9.1. Ondersteuning voor actieve monitoring Ondersteuning voor passieve monitoring Ondersteuning voor verschillende niveaus van detail

103 10. Ondersteuning voor bedrijfscontrole Ondersteuning voor procesinstantie-evolutie Ondersteuning voor veranderende bedrijfsregels Ondersteuning voor veranderende activiteiten Ondersteuning voor het veranderen van de werklast tussen gebruikers. 4 Tussentotaal: Monitor- en controlecriteria 58 Totaal

104 6. BONITASOFT 6.1. INLEIDING SITUERING Het Bonitaproject komt tot stand in 2001 wanneer Miguel Valdes-Faura, computerscience-ingenieur aan het Frans Nationaal Instituut voor onderzoek in computerscience en controle, beseft dat Business Process Management een integraal deel gaat uitmaken van de IT-strategie van veel bedrijven. Het Bonita Open Source-project heeft als doel OS alternatieven voor de bestaande BPM-oplossingen te ontwerpen en te ontwikkelen. In 2009 wordt uit dit project BonitaSoft opgericht met als doel het Open Source-project te commercialiseren en de verdere ontwikkelingen hieruit te managen. Figuur 38: Logo Bonitasoft Momenteel is Bonitasoft gevestigd in Grenoble, Frankrijk met kantoren in Parijs, San Francisco, Boston en Beijing. De oorspronkelijke investeerders, Ventech en Auriga Partners worden echter gevolgd door enkele extra series waarin kapitaal opgehaald wordt. Zo bedraagt het totaal geïnvesteerd kapitaal rond de 12.5 miljoen. Bonitasoft stelt ongeveer 100 mensen te werk, komende van 17 in midden Financiële resultaten worden niet meegedeeld, maar onderzoek van Lehmann (2012) duidt erop dat het bedrijf zich in een investeer-stage bedrijfscyclus bevindt, net onder of op break-even draait en geïnvesteerd kapitaal gebruikt om zijn groei te financieren PRODUCT Op het moment van dit onderzoek, is BonitaBPMCommunity de recentste beschikbare versie. In het vervolg van dit onderzoek wordt dan ook deze editie gebruikt. Na analyse van het programma kan men duidelijk drie verschillende componenten onderscheiden: 88 Bonita BPM Studio:

105 o Een grafische Interface waarin processen kunnen ontworpen worden, automatisering wordt toegevoegd aan de nodige componenten en alles gemanaged kan worden. Dit menu is vlot toegankelijk voor zowel bedrijfs- als technische gebruikers. Bonita BPM Engine: o De omgeving die alle processen draait, meerdere processen parallel ondersteunt en de werking in de cloud mogelijk maakt. Deze Engine verzorgt de procesuitvoering, transactiemanagement, taakmanagement voor de gebruikers, eventmanagement en de Java-gebaseerde API s waarin custom-applicaties kunnen ontworpen en ingewerkt worden. Bonita User Experience: o Dit is een rollengebaseerd portaal in een online omgeving. Process Stake Holders kunnen inloggen om procestaken uit te voeren, te antwoorden op meldingen en samen te werken als deel van een gestructureerde procesactiviteit of dynamisch in samenwerking met het sociale netwerk SYSTEEMVEREISTEN Bij Bonitasoft wordt een onderscheid gemaakt in systeemvereisten tussen enerzijds Bonita BPM Studio (enkel een modelleermodule en testomgeving) en anderzijds het volledige platform Bonita BPM Studio Hardware Type Minimum Aangeraden Processors 2 CPU Cores 2 CPU Cores Geheugen (RAM) 4 GB 6 GB Vrij geheugen op de harde schijf 10 GB 30 GB (afhankelijk van gebruik) Software o Een besturingssysteem dat compatibel is met een ondersteunde Java Virtual Machine o Een Java Virtual Machine (JVM) te kiezen uit: 89

106 Oracle Java SE JRE 6 Oracle Java SE JRE 7 OpenJDK Bonita BPM platform Hardware Type Minimum Aangeraden Processors 4 CPU Cores 4 CPU Cores of meer Geheugen (RAM) 4 GB 8 GB Vrij geheugen 10 GB Afhankelijk van gebruik Software o Een besturingssysteem dat compatibel is met een ondersteunde Java Virtual Machine o Een Java Virtual Machine (JVM) te kiezen uit: Oracle Java SE JRE 6 Oracle Java SE JRE 7 OpenJDK 7 o Een database te kiezen uit: MySQL PostgreSQL Microsoft SQL Server 2008 Oracle Database BEDRIJFSMODEL Bonitasoft s bedrijfsmodel kan men best omschrijven als een Open-Source-s-a- Service (OSaaS). De broncode is gratis beschikbaar voor de klanten. Zij kunnen echter inschrijven op een Subscription Pack (SP) tegen een jaarlijkse betaling. 90

107 Het SP biedt nog een extra uitbreiding van de mogelijkheden op de beschikbare versie en een volledige ondersteuning door het Bonitasoft team. Deze uitbreidingen zijn gericht op een grootschalige implementatie en voor kleinere bedrijven dus niet relevant. De expansie van het programma omvat een verbeterd datamanagement, contentmanagement, integratie, verbeterde documentmanagement mogelijkheden, templates voor Finance, Human Resources, IT en kwaliteitsmanagement, en een verbeterde resource-, proces- en foutmonitoring. De meeste verbeteringen hierop hebben betrekking op de schaalbaarheid van de tool. Bonitasoft benadert haar klanten via een kleinschalig project in een groep of departement. De prijzen zijn gebaseerd op servergebruik en stijgen in 4 delen. Een vierdelig jaarlijks abonnement varieert tussen en $. De gemiddelde klant betaalt rond de $ per project. Voor de meeste klanten verzorgt Bonitasoft verschillende projecten. Bijvoorbeeld de top 25 klanten leveren elk gemiddeld $ per jaar op. Over de jaren heen heeft Bonitasoft ook een aanzienlijk aantal partnerrelaties uitgebouwd, met meer dan 60 samenwerkingsverbanden gesitueerd in 30 landen. Er is onder andere een nauwe samenwerking met JasperSoft, gespecialiseerd in Open Source BI-software, met SugarCRM, aanbieder van Open Source CRM-software, en met Talend die Open Source Integratie-software verstrekt. Deze partners gebruiken de technologie van Bonitasoft om BPM-mogelijkheden toe te voegen aan hun tools. 91

108 6.2. MODELLERING Elke score die toegekend wordt in de evaluatie van een tool, is gebaseerd op de voorwaarden die in hoofdstuk Modellering zijn vastgelegd MODELLEERTALEN EN HUN INTEROPERABILITEIT Bonitasoft voorziet in BPM Studio een volledige omgeving waarin er aan de hand van BPMN 2.0 modellen kunnen opgesteld worden. Figuur 39: Screenshot modelleermodule (Bonitasoft) Wel kunnen er bepaalde formaten van procesmodellen geïmporteerd worden. 92

109 Figuur 40: Screenshot keuzemenu importeren procesmodellen (Bonitasoft) Score = VERSCHILLENDE PERSPECTIEVEN IN HET PROCES Tijdens de modelleerfase maakt Bonitasoft geen onderscheid tussen verschillende perspectieven. Op dit criterium worden er dus geen punten behaald. Er kan echter wel vlot gewerkt worden met subprocessen. Score = IMPLICIETE BEDRIJFSREGELS Bonitasoft kan impliciete bedrijfsregels opnemen in haar modellen. Op elk formulier kan op basis van ingevoerde data een vooraf gedefinieerde beslissing gemaakt worden. Score = EXPLICIETE BEDRIJFSREGELS Bedrijfsregels die opgenomen worden in modellen ontworpen in Bonitasoft, kunnen ook in de vorm van Groovy Scripts ingevoegd worden. Groovy is een programmeertaal ontwikkeld voor een Java-platform, gebaseerd op een syntax gelijkend op Java en werkend volgens programmeerprincipes zoals methodes en 93

110 klassen. Alle regels die ontwikkeld worden in Groovy, worden in een aparte Interface binnen Bonitasoft gemanaged en staan dus onafhankelijk van de processen. Men kan dan in de processen verwijzen naar deze scripts. Score = PROCESSEN IN TABELVORM Bedrijfsregels kunnen ingevoegd worden in tabelvorm. Ze blijven echter beperkt tot een bepaalde Gateway. Zo wordt eenvoudigweg wel een overzichtelijke manier voorzien om de verschillende impliciete bedrijfsregels te modelleren. Een volledig overzicht van het totale proces zoals in de literatuur wordt aangehaald, is niet mogelijk. Score = 0 Figuur 41: Screenshot tabel bedrijfsregels (Bonitasoft) KEY PERFORMANCE INDICATORS KPI s worden binnen Bonitasoft niet expliciet ondersteund. Men kan echter werken met de hierboven beschreven Groovy Scripts. Hiermee kan de functionaliteit van KPI s nagebouwd worden. Dit vereist echter de nodige codeerkennis. Score = 3 94

111 6.3. DESIGN Elke score die toegekend wordt in de evaluatie van een tool, is gebaseerd op de voorwaarden die in hoofdstuk Design zijn vastgelegd BUSINESS PROCESS EXECUTION-TALEN Aangezien Bonitasoft werkt met BPMN 2.0, is dit ook de enige ondersteunde uitvoerende taal. Score = AUTOMATISCHE EN MANUELE VERTALING De automatische vertaling wordt voorzien binnen BPMN 2.0. Score = LINK UITVOERBAAR EN GRAFISCH MODEL Het grafische model wordt rechtstreeks uitvoerbaar aangezien BPMN 2.0 gebruikt wordt. Score = PROGRAMMEERTALEN Bonitasoft wordt ondersteund door een volledige API ontwikkeld in Java. In de Tiobe Programming Index voor maart 2014 staat Java op nr. 2 genoteerd. (TIOBE, 2014) Score = EXTERNE APPLICATIES Er wordt connectiviteit voorzien voor een aantal applicaties voor externe data-invoer namelijk: Alfresco CMIS Google Calender Jasper 5 LDAP Messaging Salesforce SAP Jco 2 SAP Jco 3 95

112 96 Script Sugar CRM Talend Job launcher Talend TIS job launcher Twitter Web service De gebruikers zelf kunnen deze lijst verder uitbreiden. Via de API kunnen ontwikkelaars eigen connecties aanmaken. Score = DATABANKEN Er wordt connectiviteit voorzien voor een aantal databanken namelijk: Ingres 10.1 MySQL 5.5 Teradata 14 Informix 11 DB2 9.7 HSQL 2.2 Microsoft SQL Server 2008 of 2012 PostgreSQL 8.4 of 9.2 H2 1.3 Oracle 10G of 11G JDBC 4 AS 400 Sybase ASE 15 Datasource db query Ook deze lijst kan verder aangevuld worden door de gebruiker zelf. De API voorziet ook de noodzakelijke functies om de nodige connectoren vlot in een Java-omgeving

113 te ontwikkelen. Voor bepaalde andere technologieën kunnen online reeds connectoren gevonden worden. Score = ONLINE PORTAAL Bonitasoft voorziet een intuïtief portaal waarin de nodige informatie door de gebruikers kan opgezocht worden. De belangrijkste functie van het portaal binnen Bonitasoft is het voorzien van de takenlijst. Dit portaal wordt opgedeeld in 3 verschillende delen namelijk: Links: Een overzicht van de mogelijke filters. Deze worden gebruikt om het zoekproces naar bepaalde processen te vergemakkelijken. Men kan bijvoorbeeld de mislukte processen bekijken. Midden: Hierin worden de mogelijke acties weergegeven, meestal een activiteit die binnen het proces de aandacht van de gebruiker vereist. Rechts: Afhankelijk van de geselecteerde filters en acties, worden hier de details getoond. Deze omvatten alle relevante info voor de gebruiker over de geselecteerde actie. De functionaliteit voorzien binnen het portaal wordt bepaald door het soort account waarmee men zich aanmeldt. Is dit een account met administratorrechten, dan worden een paar extra mogelijkheden toegevoegd. Zo kan men als Admin de organisatie managen, analysedata bekijken en verder instellingen configureren. Figuur 42: Screenshot online portaal (Bonitasoft) 97

114 Score = TAKENLIJST De takenlijst is opgenomen binnen het online portaal. Score = ROLLENOMSCHRIJVING Binnen Bonitasoft kunnen rollen omschreven worden. Deze worden samengebracht in groepen die dan deel uitmaken van een bepaalde organisatie. Hierdoor kan men complexe structuren op overzichtelijke wijze managen. Score = 5 Figuur 43: Screenshot rollen (Bonitasoft) MOGELIJKHEDEN OP BASIS VAN EEN ROL Aan elk onderdeel binnen het proces kan een bepaalde rol worden toegekend. Hierdoor worden de mogelijkheden per rol bepaald. Score = ORGANISATIESTRUCTUREN UIT EXTERNE SYSTEMEN Organisatiestructuren die in Bonitasoft zelf zijn ontwikkeld en opgeslagen in een.xml formaat kunnen geïmporteerd worden. Score = 10 98