Het Realiseren van een Globaal Procesoverzicht bij Gedecentraliseerde Procesarchitecturen

UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2010 – 2011

Het Realiseren van een Globaal Procesoverzicht bij Gedecentraliseerde Procesarchitecturen

Masterproef voorgedragen tot het bekomen van de graad van Master in de bedrijfseconomie

Thomas Vancaeneghem

onder leiding van Prof. Dr. Geert Poels Maxime Bernaert

UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2010 – 2011


Masterproef voorgedragen tot het bekomen van de graad van Master in de bedrijfseconomie

Thomas Vancaeneghem

onder leiding van Prof. Dr. Geert Poels Maxime Bernaert


Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding.

Thomas Vancaeneghem


Inhoud 1.

Inleiding...........................................................................................................................1

2.

Onderzoeksvragen ..........................................................................................................3

3.

Methodologie...................................................................................................................4

4.

Conceptafbakening .........................................................................................................5

5.

6.

7.

8.

4.1

Bedrijfsproces ..........................................................................................................5

4.2

Business Process Management ...............................................................................6

4.3

Business Process Modelling .....................................................................................7

Voorgaand onderzoek: gedistribueerde systemen ...........................................................8 5.1

Proces - subproces ..................................................................................................8

5.2

Service oriented computing ....................................................................................11

5.3

3 stappen naar decentralisatie................................................................................12

5.3.1

Eerste school: Centrale orchestrator ...................................................................12

5.3.2

Tweede school: Decentralisatie van proceslogica ...............................................15

5.3.3

Derde school: Volledige loskoppeling .................................................................17

Decentralisatie vanuit een globaal procesmodel ............................................................18 6.1

Parallelle gateway ..................................................................................................19

6.2

Toepassing decentralisatie: beperking kader..........................................................20

6.3

XOR gateway .........................................................................................................21

6.4

IOR gateway ..........................................................................................................22

6.5

Besluit decentralisatie ............................................................................................24

Van decentrale architectuur naar globaal procesoverzicht .............................................24 7.1

Verzameling gesplitste processen ..........................................................................25

7.2

Parallelle gateway ..................................................................................................25

7.3

XOR gateway .........................................................................................................27

7.4

IOR gateway ..........................................................................................................29

7.5

Behoud losgekoppelde aspect in BPMN model van de globale flow .......................31

7.6

Reconstructie globale procesflow ...........................................................................32

Conclusie ......................................................................................................................35


9. 10.

Kritische reflectie ...........................................................................................................36 Bibliografie .................................................................................................................38


Lijst figuren

Figuur 1 Procesopdeling.........................................................................................................9 Figuur 2 Cirkel continue verbetering .....................................................................................10 Figuur 3 Services linken business and IT (Feurer, 2007) ......................................................11 Figuur 4 Beperkingen van gecentraliseerde orchestratie (Hens et al., 2010a) ......................14 Figuur 5 Centrale versus decentrale executie .......................................................................16 Figuur 6 Event-based decentraliseren ..................................................................................18 Figuur 7 Voorbeeld hamburgerrestaurant .............................................................................19 Figuur 8 Subproces 'Prepare Hamburger' .............................................................................19 Figuur 9 Split proces 'Arrange Payment' ...............................................................................20 Figuur 10 Split proces 'Add Soda' .........................................................................................21 Figuur 11 Split proces 'AddExtra's' .......................................................................................23 Figuur 12 Gesplitst proces 'Arrange Payment' ......................................................................26 Figuur 13 Reconstructie 'Arrange Payment' ..........................................................................27 Figuur 14 Gesplitste processen met 1 'complete' signaal......................................................27 Figuur 15 Exclusieve events .................................................................................................28 Figuur 16 Reconstructie Add Soda .......................................................................................28 Figuur 17 Gesplitste processen 'Add Extra's' ........................................................................29 Figuur 18 Reconstructie Split proces 'Add Extra's' ................................................................30 Figuur 19 Reconstructie Split proces 'Add Extra's' - tweede stap..........................................31 Figuur 20 Inclusieve events ..................................................................................................31 Figuur 21 Voorlopig gereconstrueerde flow ..........................................................................33 Figuur 22 Gereconstrueerd bestellingproces hamburgerrestaurant ......................................34


1.

Inleiding

Business Process Management, het lijkt wel hét concept te zijn van de laatste 20 jaar. Iedere IT- of business consultant kent de term, iedereen heeft er een eigen invulling voor, met interpretaties van puur (IT-) technisch concept, tot brede managementvisie. Een sterk gerelateerd domein is Business Process Modelling, beide termen worden niet toevallig frequent door elkaar gebruikt. Omdat het specifieke onderscheid tussen beide strekkingen niet de essentie van de scriptie vormt, wordt hier -met sterke zin voor vereenvoudigingvoorgesteld om Business Process Management te zien als een allesomvattende verzameling van initiatieven gericht op het beheren en verbeteren van de processen binnen een organisatie. Om processen te beheren, moet ook duidelijk zijn wat die processen inhouden. Business Process Modelling is dan het in kaart brengen van bestaande en mogelijke toekomstige processen.1 In deze visie is Business Process Modelling het praktisch hulpmiddel om het managen van bedrijfsprocessen te ondersteunen.

Business Process Modelling kent vele gezichten en toepassingen, maar is voor alles toch een middel om overzicht te verwerven over, en inzicht te verwerven in de werking van een bedrijf en haar processen. Wanneer men erin slaagt om een volledig bedrijfsproces van begin tot eind in kaart te brengen, spreekt men van de end-to-end procesflow. Eén van de vele grote uitdagingen die een dergelijke oefening met zich meebrengt, is het samenspel tussen algemeen overzicht en specifieke gedetailleerde informatie. Om beslissingen te nemen en actoren en gebeurtenissen binnen een proces de juiste plaats, functie en verantwoordelijkheid te kunnen toekennen, moet men weten waar die zich binnen het geheel situeren. Hiervoor is het essentieel een goed en duidelijk overzicht te hebben over de volledige end-to-end flow. In vele gevallen is het echter aangewezen om korter op de bal te spelen. (Rosemann, 2006; Silverthorne, 2011) In deze context spreekt men over abstractieniveaus van processen. Zo kan men processen op bedrijfsniveau bekijken, maar ook over de grenzen van een bedrijf heen, op niveau van de supply chain. Ook binnen één bedrijf zijn er verschillende niveaus. Elk abstractieniveau vereist een niveau van detail. (Lin, Yang, & Pai, 2002; Tolsma & de Wit, 2009) Wanneer men op een heel laag niveau processen analyseert, wil men specifiekere informatie terugvinden. In dat geval moet het mogelijk zijn om het proces binnen het proces, het subproces, gedetailleerd in kaart te

1

In sectie 5 wordt dieper ingegaan op hoe men BPM in de bestaande literatuur definieert en

wat hier met deze begrippen bedoeld wordt. 1


brengen. Een subproces is een activiteit die onderdelen bevat die als een procesflow uitgedrukt kunnen worden. Wanneer een activiteit niet meer in onderdelen kan opgedeeld worden, spreekt men van een taak.

Voor complexe processen is het niet altijd evident om deze op te delen in subprocessen. Het kan een noodzaak zijn om alle stappen van het proces op een centrale plaats te beheren en uit te voeren. Dit noemt men centralisatie. Andere processen vormen echter een aaneenschakeling van taken en subprocessen die elk duidelijk afgelijnd hun eigen in- en output hebben. Wanneer deze stappen autonoom uitgevoerd kunnen worden zonder aansturing vanuit een centrale coördinator, is er sprake van decentralisatie. In een ITcontext wordt hier vaak de link gelegd met service oriented architecture (confer infra). Bij de gedecentraliseerde opzet van processen opteert men ervoor om de uitvoering van een of meerdere subprocessen op een aparte plaats uit te voeren en de output van het subproces terug aan te leveren als input voor de volgende stap in de grote end-to-end flow. Wanneer men kiest voor het decentraal uitvoeren van (sub)processen, wil men echter nog steeds het overzicht bewaren op de volledige end-to-end flow. Het is in deze context van algemeen overzicht versus gedecentraliseerde uitvoering dat de essentie van deze scriptie ligt. Wanneer een systeem volledig losgekoppeld wordt opgezet, is er geen duidelijke link meer tussen de verschillende subprocessen en wordt het moeilijk om de globale flow terug op te bouwen. Het realiseren van dit overzicht vormt de centrale doelstelling van deze scriptie. De focus ligt vooral op IT-gestuurde processen, maar de ambitie op lange termijn moet ook zijn om de resultaten te toetsen in een businesscontext los van IT-matige uitvoering. De nood aan een globaal procesoverzicht heeft vele redenen. (Negele, Fricke, Schrepfer, & Härtlein, 1999) Ten eerste leidt een duidelijke en overzichtelijke procesflow tot meer transparantie, het helpt actoren om een overzicht te krijgen en hun plaats te zien in het geheel. Het geeft ook inzicht in welke rol activiteiten spelen in het geheel. Een globaal procesoverzicht bevordert de coördinatie, de actoren spreken allen over hetzelfde. Dankzij die transparantie en verbeterde coördinatie kunnen nieuwe ontwikkelingen beter gepland worden, en kennis van de huidige setting kan als basis dienen voor nieuwe ontwikkelingen. Bovendien is het soms zelfs verplicht om processen te documenteren, in het bijzonder om ISO certificatie te behalen wordt vaak verwacht dat processen gedocumenteerd zijn. Tenslotte is één van de belangrijkste redenen voor een globaal procesoverzicht: "Only if you know what you are doing (which can be described in a process model), you assess how good you are doing it and use it as a basis for improvement." (Negele et al., 1999, p. 2) Het is duidelijk dat wanneer men een gedecentraliseerd en dus gefragmenteerd systeem heeft, het moeilijker wordt om de verbanden tussen de stappen bloot te leggen. Bij volledige loosely coupled systemen is de relatie-informatie moeilijker te vinden door de fragmentatie van proceslogica 2


en de loskoppeling van tijd en plaats. Een moeilijker begrip van de verschillende afhankelijkheden leidt onvermijdelijk tot een beperkter inzicht in het proces zelf, en net dit inzicht in processen is de sleutel tot een goede procesanalyse. (Mendling, Reijers, & van der Aalst, 2010)

2.

Onderzoeksvragen "[...], the global overview of the process flow gets lost. Every process engine works autonomous, without the knowledge of any other part of the process flow. The execution of the process flow thus becomes stateless. Although the overview of the process flow gets lost at runtime, there still exists a process model. Decentralization happens at deployment, where one starts with a global process overview. This overview will thus still be available." (Hens, Snoeck, De Backer, & Poels, 2010a, p.9)

Hens vat de problematiek treffend samen. Waar Hens echter vertrekt van het centrale procesmodel om van daaruit te decentraliseren, wordt hier de omgekeerde weg bewandeld. Het centrale procesmodel is dus niet beschikbaar, het is integendeel net het doel van dit onderzoek om dit procesmodel te genereren. Onderzoeksvraag 1

Vooreerst wordt de vraag gesteld of er in de bestaande benaderingen rond decentralisatie van processen een rode draad te vinden is. Er bestaan inderdaad al een aantal verschillende visies over hoe men -gegeven een globaal procesmodel- een end-to-end flow kan decentraliseren. Het moet mogelijk zijn één of meerdere stromingen terug te vinden.

1. Zijn er een of meerdere centrale lijnen terug te vinden in bestaande theorieën? Onderzoeksvraag 2

Een

tweede

vraag

die

gesteld

wordt,

is

welke

elementen

de

bestaande

decentralisatiemethodes kunnen aanleveren om een globale procesflow op te bouwen.

2. Welke elementen uit de bestaande methodes voor decentralisatie kunnen bijdragen aan de realisatie van een procesoverzicht?

3


Onderzoeksvraag 3

Als laatste wordt nagegaan of er een methode kan ontwikkeld worden om -gegeven een gedecentraliseerde architectuur- de complete end-to-end flow te genereren, en zo een beter globaal overzicht te realiseren over wat er in de flow gebeurt.

3.

Hoe

kan

het

globale

procesoverzicht

over

een

gedecentraliseerde

procesarchitectuur gerealiseerd worden? Hoe kunnen de verschillende processtappen in een losgekoppelde omgeving gelinkt worden om te komen tot een volledige end-toend flow?

3.

Methodologie

Het onderzoek van dit werk kadert binnen de masterproef van een academische opleiding. Hoewel de stellingen met uitgewerkte voorbeelden geïllustreerd en verdedigd worden, richt dit werk zich toch voornamelijk op de theoretische en conceptuele zijde van de problematiek. Hiervoor wordt een literatuurstudie uitgevoerd: uit de bestaande werken worden een of meerdere lijnen geëxtraheerd, en -indien dat nodig blijkt- wordt daar een uitbreiding of verdieping aan toegevoegd. Als ultieme doel wordt een theorie naar voor gebracht, die hopelijk een aanleiding zal zijn voor verder meer praktijk gericht onderzoek door derden.

Eerst worden enkele sleutelconcepten afgebakend, waarna dieper wordt ingegaan op de bestaande literatuur over het decentraliseren van procesarchitecturen. Daarna wordt door middel van literatuurstudie gezocht welke elementen kunnen bijdragen tot de realisatie van een globaal flowoverzicht bij volledig losgekoppelde systemen. Hierbij worden drie criteria gehanteerd: 

Welke concepten bieden de mogelijkheid om de processtappen van een proces te linken in één groot procesmodel?



Kunnen daarbij ook de relaties uitgebeeld worden zonder de informatie over tijden plaatsonafhankelijkheid op te geven?



Waar bestaande concepten tekort schieten wordt gezocht naar nieuwe elementen om lacunes te overbruggen.

De methodologie van deze scriptie berust dus grotendeels op een literatuurstudie, maar waar bestaande literatuur tekort schiet, worden toch nieuwe elementen aangebracht. 4


4.

Conceptafbakening

In de inleiding werd al een eerste omkadering van het domein van deze scriptie geschetst. Om echter een degelijk onderzoek te kunnen voeren, moeten ook alle aangehaalde concepten duidelijk gedefinieerd en omlijnd worden. In dit vierde hoofdstuk wordt voor alle sleutelconcepten een duidelijke definitie opgesteld.

4.1

Bedrijfsproces

Over wat een bedrijfsproces is, en hoe het gedefinieerd wordt, is al veel geschreven. Lindsay schreef zelfs een volledige paper over de definitie van een bedrijfsproces. (Lindsay, Downs, & Lunn, 2003) In haar werk "Business Processes – Attempts to Find a Definition" wordt al snel duidelijk dat er veel verschillende definities bestaan. Een heel summiere definitie is deze van Jacobson, die een bedrijfsproces beschrijft als "The set of internal activities performed to serve a customer." (Jacobson, 1995) Aguilar-Savèn definieert een bedrijfsproces wat uitgebreider als "A business process is the combination of a set of activities within an enterprise with a structure describing their logical order and dependence whose objective is to produce a desired result." (Aguilar-Savén, 2004,p. 1) Eriksson en Penker voegen daaraan toe dat de nadruk niet mag liggen op wat geproduceerd of geleverd wordt, maar wel hoe dit gerealiseerd wordt. (Eriksson & Penker, 2000) Het wordt al snel duidelijk dat het hier een heel breed domein betreft, met veel verschillende elementen. Melao & Pidd stellen zelfs "... there seem to be almost as many definitions of business process as there are BPR books and BPM." (Melão & Pidd, 2000, p.106) Dit zijn uiteraard slechts enkele van de vele definities, maar twee belangrijke elementen van een bedrijfsproces komen meteen bovendrijven. Er zijn enerzijds gebeurtenissen of acties die plaatsvinden, en anderzijds is er het relatie-element tussen deze gebeurtenissen. Inzicht in deze twee elementen zijn cruciaal om inzicht te verwerven in het proces zelf. Daarom wordt een bedrijfsproces hier omschreven als een combinatie van bedrijfsactiviteiten waarbij de onderlinge relatie tussen de activiteiten is vastgelegd en waarbij het gezamenlijke doel van deze activiteiten is om de in de bedrijfsstrategie vastgelegde bedrijfsdoelstellingen zo effectief en efficiënt mogelijk te realiseren.

5


4.2

Business Process Management

Van der Aalst et al. openen met de stelling: "Business Process Management (BPM) includes methods, techniques, and tools to support the design, enactment, management, and analysis of operational business processes." (van der Aalst, ter Hofstede, & Weske, 2003a, p. 1) Poels omschrijft het als “Business Process Management is een benadering tot bedrijfsbeheer die mogelijk gemaakt wordt door de inzet van een specifieke verzameling van informatietechnologieën volgens een bijhorende methodologie. Met de term BPM kan dus zowel verwezen worden naar een managementconcept als naar de IT die de toepassing van dit management concept mogelijk maakt.” (Poels, 2009, p.242) BPM wordt gezien als de opvolger van Business Process Reengineering (BPR), een concept geïntroduceerd door Davenport en Short dat erop gericht was om bedrijfsprocessen klantgericht te maken en hun middelenverbruik te optimaliseren. (Davenport & Short, 1990) Waar BPR eerder betrekking had op drastische en eenmalige veranderingen binnen bedrijven en hun processen, omvat het BPM concept van de jaren 2000 een meer continue geleidelijke verandering. Rosemann herkent 6 basiselementen in een holistische BPM visie: strategische uitlijning, governance, methodes, information technology, mensen en cultuur. (Rosemann & Brocke, 2010) De auteurs van dit werk erkennen zeker het brede werkgebied van procesmanagement, maar de focus richt zich hier vooral op de IT-zijde van de bedrijfsprocessen. Voortbouwend op de voorgestelde definitie van een bedrijfsproces wordt bedrijfsprocesmanagement een allesomvattende beschrijving voor de verzameling initiatieven die organisaties ondernemen om hun werking te analyseren, te beheren en te optimaliseren. Een belangrijk concept komt hier meteen boven drijven, namelijk het optimaliseren van die processen, ook wel 'business process improvement' genoemd. Wanneer bedrijven hun taken uitvoeren, dan is het de bedoeling om dit zo effectief en efficiënt mogelijk te doen. Privé bedrijven moeten hun investeerders tevreden houden door een goede return te realiseren, publieke entiteiten van hun kant moeten hun bestaan kunnen verdedigen tegenover de politieke entiteiten die hen van de nodige fondsen voorzien. Om een goede return te realiseren of het bestaansrecht van een publieke dienst te verdedigen, heeft men een duidelijk zicht nodig op wat men doet, wie het doet, hoe men het doet en waarom men het doet. Indien men inzicht verwerft in deze vier sleutelaspecten, worden zowel sterke als zwakke elementen in de bedrijfswerking blootgelegd. BPM is een sterk IT gerelateerd domein. Deze scriptie spitst zich vooral toe op die IT kant van het verhaal. De vraag wordt gesteld hoe de terugkoppeling gemaakt kan worden van een IT architectuur naar een voor eindgebruikers (business users) leesbaar en interpreteerbare procesvoorstelling.

6


4.3

Business Process Modelling

Zoals gesteld zijn twee belangrijke bouwstenen in een bedrijfsproces de activiteiten die plaatsvinden en het relatie-element tussen deze activiteiten. Bedrijfsprocesmodellering is erop gericht volledige processen in kaart te brengen, dus is niet alleen een duidelijk inzicht nodig in de activiteiten (subprocessen, taken), maar zeker ook in de onderlinge relaties. Net die relaties blijken bij gedecentraliseerde architecturen moeilijk om duidelijk in kaart te brengen. De relatie tussen Business Process Management en Business Process Modelling is niet altijd even duidelijk. De termen worden vaak door elkaar gebruikt. In de context van dit onderzoek kan men stellen dat Business Process Management eerder een strategische invulling krijgt en Business Process Modelling een meer ondersteunende praktische invulling. Met het modelleren worden zowel de 'as-is' als de 'to-be' situatie in kaart gebracht ter ondersteuning van managementbeslissingen. Gesteund door modellering, staat Business Process Management dus voor de zoektocht naar de procesinvulling die de strategische doelstellingen van het bedrijf zo goed mogelijk realiseert.

Voor het opstellen van procesmodellen worden verschillende modelleertalen en -technieken gebruikt. Het tekenen van modellen zelf gebeurt met software tools, waarvan de ARIS software een van de meest omvattende en erkende is. (Krallmann & Derszteler, 1996; Neiger & Churilov, 2004; Scheer, 2000; Stein, Hawking, & Foster, 2003) De toolset werd ontwikkeld door August-Wilhelm Scheer. Zijn onderneming IDS Scheer heeft verregaande samenwerkingsverdragen met onder andere SAP & Oracle, twee wereldleiders op vlak van bedrijfssoftware. (ORACLE, 2011; Scheer, Kirchmer, & Wolfram, 2002; Software AG, 2011) ARIS omvat de meest courante modelleringstechnieken en -talen (Scheer, 2011). Waar BPEL en WSDL vooral technische talen zijn om Web Services aan te sturen en uit te voeren, zijn EPC en BPMN vooral business gericht (analytisch). Vooral BPMN is de laatste jaren aan een sterke opmars bezig. BPMN heeft de eigenschap om zich op de business users te focussen zonder de mogelijkheid te verliezen om technische informatie in een procesmodel op te nemen. Silver (Silver, 2009) vat de eigenschappen goed samen in vijf punten: 

Elke vorm en symbool heeft een specifieke betekenis, waardoor modellen gelezen kunnen worden zonder dat de auteur erbij moet zijn om deze uit te leggen.



Sinds BPMN versie 2.0 is BPMN ook de toplaag van een complete XML taal voor procesdefiniëring, dit zorgt ervoor dat een BPMN model ook uitvoerbaar is in een 'process engine'.

7




BPMN ondersteunt 'event-triggered behaviour', en gaat dus niet enkel uit van het ideale scenario maar houdt ook rekening met onverwachte onderbrekingen, vb. door een handeling van een gebruiker.



BPMN was er vanaf het begin op gericht om 'business-friendly' te zijn.



BPMN heeft de ingebouwde mogelijkheid om technische specificaties toe te voegen, zodat een BPMN model ook daadwerkelijk kan gebruikt worden om een workflow te realiseren.

Die eigenschappen hebben ertoe geleid dat BPMN software giganten als SAP, Oracle en IBM de taal opnemen in hun nieuwe BPM tools. (Hevner, March, Park, & Ram, 2004; ORACLE, 2011) Omdat een taal op zichzelf geen garantie biedt op een consequent gebruik ervan, ontwikkelde Silver een methode om ze te gebruiken: "By method I mean a cookbook approach starting from a blank sheet of paper and leading to a complete BPMN model. OMG boasts that BPMN has no methodology, since how it is used depends on what you are trying to do...That should not imply, however, a single method across the board. The details of the method necessarily depend on the modeler's objective." (Avison & Pries-Heje, 2005; OMG; Silver, 2009, p.xi) Een bijkomend voordeel aan BPMN is dat het geen eigendom is van een commerciële softwareontwikkelaar en is dus gratis voor gebruik, wat de ontwikkeling ten goede kan komen. Als het lukt om een goede methode te vinden om vertrekkend van een gedecentraliseerde architectuur, een end-to-end procesflow te genereren, is het -met de blik op de toekomst- interessant om die gegenereerde flow in de BPMN notatie te proberen te zetten.

5.

Voorgaand onderzoek: gedistribueerde systemen

5.1

Proces - subproces

Een belangrijk doel van bedrijfsprocesmodellering is het in kaart brengen, beheren en/of verbeteren van processen. Om deze processen in kaart te brengen, worden zij opgedeeld in kleinere stukken zodat zichtbaar wordt wat juist de bouwstenen van het proces zijn, en ultiem ook welke bouwstenen kunnen verbeterd, vervangen of zelfs verwijderd worden. Verwijderen kan bijvoorbeeld wanneer blijkt dat een bepaalde activiteit geen toegevoegde waarde (meer) heeft in het geheel. Zoals aangegeven, kunnen sommige processen onderverdeeld worden in subprocessen. De definitie van een subproces luidt: "A subprocess is simultaneously an 8


activity, a step in a process that performs work, and a process, a flow of activities from a start event to one or more end events." (Silver, 2009, p.12) Als de start en het einde van dit subproces duidelijk geïdentificeerd kunnen worden, kan het subproces als het ware uit het globale proces gelift worden om het afzonderlijk te analyseren en uit te voeren.

Figuur 1 Procesopdeling

In Figuur 1 wordt schematisch voorgesteld hoe zoiets gerealiseerd wordt. Vertrekkend van de globale end-to-end procesflow, gaat men op zoek naar duidelijk af te bakenen subprocessen in de flow. Men vertrekt van een basisproces, bijvoorbeeld 'Klantenopvolging' (proces 1 op de tekening). Dit proces bevindt zich op het niveau van de eindgebruiker. Vervolgens gaat een business analist deze eindgebruiker vragen stellen met het doel uit die algemeen omschreven taak van de binnendienst medewerker te weten te komen uit wat die taak dan allemaal bestaat. Het hoe, wat en het waarom van deze onderdelen en taken wordt onderzocht. Waarom doet de eindgebruiker wat hij/zij doet, en welke toegevoegde waarde heeft het in het gehele proces? Wat is met andere woorden het doel van de activiteit? Zo komt de business analist in dit voorbeeld te weten dat in het proces 'klantenopvolging' een stuk orderinput zit, een stuk orderbevestiging naar de klant, een stuk klachtenopvolging... (processen 2a, 2b en 2c op de tekening) Zo deelt men het volledige proces op in kleine delen tot op het laagste relevante niveau, met als doel kleine stukken te hebben die onderling vervangbaar, of anders uitvoerbaar zijn. (processtappen 3a tem 3f op de tekening)

Silver (Silver, 2009) maakt bij gebruik van BPMN een onderscheid tussen de descriptieve, de analytische en de uitvoerbare modelleerlaag. Waar de descriptieve laag een pure business benadering is van de procesbeschrijving, krijgt de analyselaag een iets meer gedetailleerde invulling. De uitvoerbare laag bevat de informatie nodig om het proces in de praktijk effectief 9


tot stand te brengen. Dit onderscheid hoeft zich echter niet te beperken tot BPMN. Hier wordt het doorgetrokken tot procesmodelleren zelf. Alles wat betrekking heeft op het beschrijven en analyseren van processen en gegevens wordt uitgevoerd door de business analist. Dit noemen de auteurs de analyselaag. Op het laagste niveau komt men echter in de uitvoeringslaag van het proces (execute). Dit is de laag waar (stukken van) processen geautomatiseerd of gestandaardiseerd kunnen worden. Het is bijgevolg ook op dit niveau dat men spreekt over centrale of decentrale coördinatie in een informatiesysteem. Op het laagste niveau kunnen vele taken overgelaten worden aan een computersysteem dat deze taken uitvoert voor de medewerker. Het is ook op dit niveau dat de keuze ontstaat tussen een centrale 'orchestrator' enerzijds, of meerdere lokale, onafhankelijke systemen die met elkaar communiceren. Deze twee 'lagen' in een systeem zijn uiteraard niet onafhankelijk van elkaar, er zijn in beide richtingen mechanismen die beide verbinden. De weg tussen de analyse (modelleren) en de 'execution' laag is development. Oplossingen die naar voor komen uit een analyse moeten ontwikkeld worden voor zij kunnen uitgevoerd worden. Zoals aangehaald is het de ambitie om BPMN niet te beperken tot analyse, maar ook uitvoerbare procescode te integreren, waardoor deze twee stappen sterker verweven worden. Eens een systeem draait, moet er ook een feedback systeem zijn om continue aanpassing en verbetering mogelijk te maken, dit is monitoring. Samengevat bekomt men dus een systeem met daarin een cyclus zoals afgebeeld in Figuur 2.

Figuur 2 Cirkel continue verbetering

Systemen die vooral gericht zijn op het gedetailleerd monitoren en controleren van een systeem worden vaak beschreven met de term (Business) Process Intelligence of Process Mining. Op basis van event logs wordt zoveel mogelijk informatie en kennis verzameld over lopende processen. (Dumas, van der Aalst, & ter Hofstede, 2005; Stoesser, 2011; van der Aalst, 2011) Op basis van die logs worden een aantal analyses gedaan om technische pijnpunten te ontdekken. Process Mining heeft zich ontwikkeld tot een apart vakgebied. 10


(Dumas et al., 2005; Process Mining Group, 2009) De gedetailleerde uitwerking van een ontwikkelingsproces is hier minder relevant, maar komt impliciet wel meer aan bod vanaf sectie 5.3 waarin verschillende methodes voor decentralisatie besproken worden.

5.2

Service oriented computing

Met de opkomst van de zogenaamde service-oriented computing ontstonden nieuwe mogelijkheden om verschillende procesdelen te automatiseren. In de services visie worden de verschillende kleine onderdelen van een proces elk afzonderlijk geanalyseerd en opgezet. Zo bekomt men concreet afgelijnde bouwstenen die ook voor niet-IT'ers een stuk begrijpelijker zijn. Deze bouwstenen zijn een stuk flexibeler voor de opzet van een volledige flow. Sven Feurer van SAP AG vat dit concept mooi samen: "Today, the concept of services primarily intends to interlink the world of IT and business. Hereby, services illustrate common building blocks that span the bridge between the functional approach of business departments and the object-oriented approach of IT divisions. Services [...] have the potential to actually facilitate the consolidation of business and IT. Services exchange data in the form of standardized messages. This feature makes services that powerful and independent unlike any other implementation technologies in the past. Figure [...] shows the bridge between business and IT and its paving realized by services." (Feurer, 2007, pg.4) (confer Figuur 3)

Figuur 3 Services linken business and IT (Feurer, 2007)

Het concept van services moet dus de link leggen tussen de businesszijde van een bedrijf en de eerder technische zijde van het verhaal. Services zijn zowel in de academische als professionele wereld aan een sterke opmars bezig. (Alonso, 2008; Alonso, Casati, Kuno, & Machiraju, 2004; Benatallah, Dumas, & Sheng, 2005; Catts & St.Clair, 2009; Dijkman & Dumas, 2004; Yildiz & Godart, 2008) Ook de auteurs treden bij in het geloof dat deze 11


services het potentieel hebben om de consolidatie van business en IT te verbeteren. Feurer heeft het over gestandaardiseerde berichten, Rosemann (Rosemann, 2010) beschrijft deze eigenschap van services met de term 'abstractie'. Abstractie betekent dat services kunnen beschreven en gebruikt worden zonder diepgaande kennis over de werking van de services zelf. "It should not matter what modeling technique or tool is used. A service-oriented view on process management stresses exactly this abstraction from BPM methodologies and related terminologies that are often confusing for the process-agnostic business world." (Rosemann, 2010, p.1) De opkomst van deze service-oriented computing heeft het loskoppelen van proceselementen verder versterkt, en daarmee ook het belang van procesmodellering. Ook in de literatuur wordt deze stelling vaak bijgetreden. (Alonso et al., 2004; Curbera et al., 2002; Curbera, Khalaf, Mukhi, Tai, & Weerawarana, 2003; Hens et al., 2010a) De concepten "proces" en "service" worden vaak door elkaar gebruikt om een gelijkaardig begrip aan te duiden. In navolging van Rosemann (Rosemann, 2010) worden deze gezien als verschillende visies op eenzelfde organisatorisch aspect. Een procesinterpretatie belicht de operationele kant van dat element, waar de servicevisie het element eerder als een 'black box' bekijkt. In de service visie ligt de focus volledig op de functionaliteit van de (web)service en wordt abstractie gemaakt van de technische aspecten die de eigenlijke uitvoering mogelijk maken. De opkomst van services zorgt er niet enkel voor dat de afstand tussen business en IT wordt verkleind. De coördinatie van een proces wordt ook een stuk complexer. Aanvankelijk werd de coördinatie van al die verschillende services toevertrouwd aan één centrale coördinator, een zogenaamde 'middleware'.

5.3

3 stappen naar decentralisatie 5.3.1

Eerste school: Centrale orchestrator

Een eerste stap in het gebruik van services werd gezet door het inschakelen van deze services voor kleine stukjes functionaliteit. Enkel het pure uitvoeren van het werk wordt hierbij gedecentraliseerd, de proceslogica blijft nog steeds op één plaats bewaard. Er bestond lang een consensus dat de coördinatie van al deze services best op één centrale plaats gecentraliseerd bleef, in een zogenaamde "middleware". (Alonso et al., 2004) Elke IT infrastructuur heeft dan een centrale middleware waarlangs alle processen passeren, vb. Microsoft Biztalk of SAP Netweaver PI. (Microsoft Corporation, 2010; SAP AG, 2011) Zoals Mühl et al. aangeven, is de middleware een extra laag die tussen systemen gelegd wordt. Deze centrale middleware heeft als grote voordeel dat alle processen op één en dezelfde plaats te bekijken en te beheren zijn. "As such, it is widely used and has proved to be a 12


successful abstraction that helps with the design and implementation of complex distributed systems." (Mühl, Fiege, & Pietzuch, 2006, p.2) Architecturen met een centrale middleware zijn

dus

-ondanks de decentrale

uitvoering

van de

services zelf- nog

steeds

gecentraliseerde IT infrastructuren. Een gecentraliseerde structuur gaat impliciet uit van een heel statische omgeving: "Traditionally, middleware has viewed data and services as being stationary in a collection of objects or databases, with inquiries directed at them in a request/reply mode of interaction. This concept has led to client/server middleware architectures that emphasize explicit delegation of functionality, where system components access remote functionality to accomplish their own goals." (Mühl et al., 2006, p.2) Belangrijk hierbij is dat de eigenlijke uitvoering van de services niet op de middleware gebeurt, maar decentraal. Er wordt dus functionaliteit gedistribueerd, maar de proceslogica zelf blijft gecentraliseerd. De centrale orchestrator geeft de impuls om een decentrale (web)service op te starten. Barros (Barros, Dumas, & Oaks, 2006) spreekt in dit kader over een 'orchestration model' waarin alle communicaties en relaties vastgelegd zijn. Deze werkwijze brengt met zich mee dat een enorme druk op deze centrale orchestrator wordt gelegd. De orchestrator kan een vertragende factor worden voor de volledige bedrijfswerking (confer de bottleneck van Eli Goldratt). Deze centrale coördinator krijgt de aanvraag van een client om een activiteit op te starten, en stuurt als reactie een impuls uit om deze te starten. Wanneer die activiteit beëindigd is, wordt de centrale coördinator hier opnieuw over verwittigd, zodat die kan overgaan tot het starten van de volgende stap in het proces. Dit kunnen verschillende acties zijn, zoals een event triggeren, een nieuwe workflow starten, het proces beëindigen, ... In een dergelijk opzet zit alle proceslogica op één centrale plaats en is het de centrale middleware die het werk coördineert. Om dit werk aan te kunnen, moeten orchestrators heel krachtige machines zijn.

De voordelen van een gecentraliseerd systeem met een centrale coördinator zijn vrij duidelijk. 

Vooreerst zit alle logica van de end-to-end flow gecentraliseerd op één plaats waardoor het heel eenvoudig is om het overzicht te bewaren.



Bovendien is er één controleplaats, de zogenaamde centrale 'locus of control'.

Er zijn echter ook veel nadelen verbonden aan een centrale coördinator. 

Een eerste heel manifest nadeel is de keerzijde van de centrale 'locus of control'. Centralisatie is heel positief in termen van analyse en overzicht, maar wordt meteen ook de zwakke plek op performantievlak. Als de centrale coördinator uitvalt, ligt het volledige systeem meteen plat. Dit wordt vaak een 'single point of failure' genoemd. Dit wordt uitgebeeld in Figuur 4a (Hens et al., 2010a) 13




Een ander groot nadeel van een centrale coördinator is de grote hoeveelheid netwerk communicatie die ermee gepaard gaat (Figuur 4b), en de druk die dit met zich meebrengt op de performantie van de coördinator - en bijgevolg ook het hele systeem. (Figuur 4c) (Benatallah et al., 2005; Muth, Wodtke, Weissenfels, Dittrich, & Weikum, 1998)



Bovendien ontstaat er in deze tijden van supply chain optimalisatie en groeiende samenwerking

tussen

bedrijven

(e-business,

B2B)

een

nood

aan

grensoverschrijdende coördinatie en communicatie. Chen introduceert in dit verband de term collaborative business process: "A collaborative process involves multiple parties. The process definition is based on a commonly agreed operational protocol, such as the protocol for online purchase or auction" (Chen, 2001, p.2) Ondernemingen zijn vaak van elkaar gescheiden door firewalls en zijn om redenen als veiligheid en privacy ook niet altijd geneigd alle bedrijfsgegevens te delen met hun partners.

Sommige

informatie,

zoals

financiële

gegevens,

kunnen

het

onderhandelingsproces met een leverancier of klant sterk beïnvloeden. (Chen, 2001) In deze zin moet het mogelijk zijn om slechts kleine delen informatie beschikbaar te stellen voor de externe partners, in plaats van deze partners toegang te geven tot de centrale coördinator waar alle informatie bereikbaar is. 

Centrale coördinatoren zijn ook zelden flexibel genoeg om aan de steeds sneller veranderende omgeving aangepast te worden. Hoe meer activiteiten geconcentreerd wordt op de centrale middleware, hoe complexer het geheel wordt, en hoe moeilijker het wordt om een aanpassing door te voeren. Dit zorgt ervoor dat er impliciete grenzen worden gesteld aan de zogenaamde scalability (Hens et al., 2010a) terwijl net die scalability toch één van de belangrijkste vereisten voor een systeem is (Yu, 2009b)

Figuur 4 Beperkingen van gecentraliseerde orchestratie (Hens et al., 2010a) (a) 'single point of failure', (b) onnodige netwerk communicatie, (c) een bottleneck voor performantie

14


5.3.2

Tweede school: Decentralisatie van proceslogica

Om aan deze nadelen een antwoord te bieden, ontstond het idee om meer dan enkel de uitvoering van de services te decentraliseren. (Chafle, Chandra, Mann, & Nanda, 2004; Hens et al., 2010a; Muth et al., 1998; Nanda, Chandra, & Sarkar, 2004) Ook de procesflow en de coördinatie van het geheel worden opgedeeld in kleinere stukken. In Figuur 5 wordt het principe van decentralisatie uitgebeeld. In (A) is nog sprake van een centrale coördinator, deze bevat alle proceslogica en staat ook in voor het uitvoeren van alle processtappen. In dit voorbeeld wordt met activiteit 1 (A1) een service (S1) opgeroepen, en nadat die service is uitgevoerd beslist de centrale coördinator op basis van de feedback van de service dat de volgende activiteit kan worden uitgevoerd (A2). Bij decentrale coördinatie (B) wordt elk subproces echter als een aparte entiteit met eigen coördinatielogica opgezet. Wanneer activiteit 1 (service 1) uitgevoerd is, triggert process engine A1 een signaal. Dit signaal vormt het startschot voor een andere process engine A2, die service S2 lanceert. Met deze manier van werken zit de proceslogica telkens in de process engines zelf. Bij centrale coördinatie is dat niet het geval. Wanneer de centrale coördinator faalt, falen alle onderdelen van het proces. Met deze decentrale werkwijze wordt de process engine opgesplitst in een aantal kleinere process engines en wordt de workload verdeeld. De introductie van meerdere kleine process engines heeft een positieve impact op de performantie. Omdat niet alle communicatie moet terugkeren via één centrale plaats, wordt deze bottleneck vermeden. (Chafle et al., 2004) Bovendien wordt het op deze manier ook eenvoudiger om webservices te gebruiken in een business to business omgeving. Men kan er zo immers voor zorgen dat (gevoelige) data slechts in één richting kan verlopen.

De vele voordelen van deze visie hebben ertoe geleid dat aan deze conceptuele visie veel aandacht werd besteed door onderzoekers. Er werden vele verschillende invullingen aan gegeven. Nanda et. al (Nanda et al., 2004) maken gebruik van 'program dependency grafieken' om een procesflow op te splitsen. Hiermee kunnen ze een BPEL proces opsplitsen in een aantal kleinere processen. Hun belangrijkste doel hierbij is om de netwerktrafiek te verminderen. Andere proberen hetzelfde te bereiken met 'dependency tables' (Fdhila, Yildiz, & Godart, 2009) of 'state and activity charts' (Muth et al., 1998). Chen et al proberen hetzelfde doel te bereiken met 'business policies'. Al deze methoden hebben voornamelijk tot doel de netwerktrafiek te verminderen en de proceslogica te verplaatsten naar meerdere lokale process engines. Belangrijk hier is dat die verschillende process engines sterk aan elkaar gelinkt zijn. De uitvoering van een service is afhankelijk van het signaal dat de service krijgt van zijn voorganger in de procesflow. Process engine A1 geeft een signaal naar process engine A2 dat zijn werk beëindigd is en dat de inputvoorwaarden voor service S2 15


vervuld zijn. Op zijn beurt doet process engine A2 hetzelfde wanneer service S2 klaar is, zodat de startvoorwaarden voor service S3 vervuld zijn en deze van engine A3 ook het signaal kan krijgen om gestart te worden. (Figuur 5)

Figuur 5 Centrale versus decentrale executie

Deze gedecentraliseerde manier van werken zorgt ervoor dat het 'single point of failure' is weggewerkt. Bovendien, omdat data communicatie niet meer via één centrale coördinator verloopt, wordt ook de netwerk communicatie sterk verminderd. Waar dataverkeer vroeger telkens eerst naar de centrale coördinator verstuurd werd, zelfs wanneer deze geen relevantie had voor de centrale coördinator, wordt de data nu rechtstreeks verstuurd van de ene naar de andere engine. De communicatie zit dus ook niet meer gecentraliseerd op één punt, wat een gunstige invloed heeft op de performantie. Elke process engine apart heeft minder te verwerken dan wanneer al het werk op één process engine verzameld zit. Omdat het uitwisselen van (in bepaalde gevallen gevoelige) gegevens verdeeld wordt in aparte engine-to-engine communicatie, is er ook meer controle over welke data naar waar verstuurd wordt. Waar het bij centrale coördinatie moeilijk is om een onderscheid te maken tussen welke informatie op die ene coördinator wel of niet beschikbaar mag zijn voor externe partners, kan nu duidelijk afgelijnd worden welke informatie wordt doorgestuurd naar een externe partner. Externe partners kunnen 'ingeschreven' worden op de output van specifieke services opgeroepen op specifieke process engines zonder dat zij kennis hebben van informatie verstuurd door en tussen andere process engines in de ketting. Dankzij dit gemakkelijker afschermen van vertrouwelijke informatie, wordt het eenvoudiger om collaboratieve processen op te zetten met externe partners.

Decentralisatie van de proceslogica en de procesuitvoering kon bijgevolg een antwoord bieden aan de meeste van de nadelen die een centrale coördinator met zich meebracht: 16




Het 'single point of failure' is weggewerkt.



De netwerkcommunicatie wordt sterk gereduceerd, wat een gunstige invloed heeft op de performantie van de volledige architectuur.



Collaboratieve bedrijfsprocessen worden een stuk makkelijker afgelijnd.

5.3.3

Derde school: Volledige loskoppeling

Hoewel door toepassing van de tweede benaderding (confer 5.3.2) de flexibiliteit van systemen al sterk verbeterd is, worden soms nog hogere eisen gesteld. Tegenwoordig is het niet altijd meer voldoende om flexibele applicaties te hebben. Ook aan de gehele architectuur worden meer en meer eisen voor flexibiliteit gesteld. (Marín, 2005; Muthusamy & Jacobsen, 2010; Nurcan, 2008; Papazoglou, 2005a; Reijers & Mendling, 2008) Men verwacht van systemen dat zij zich heel snel kunnen aanpassen aan een dynamische business. Scalability is hier het sleutelwoord, en een losse koppeling van de process engines moet hiervoor zorgen. Men spreekt in deze context van 'loose coupling'. (Papazoglou, 2005a) Inderdaad, de eerder aangehaalde methodes voor decentralisatie van de procesflow dragen nog steeds een heel sterke koppeling met zich mee. Wanneer process engine A3 geen signaal krijgt van process engine A2, dan valt de procesketting stil en worden volgende stappen niet meer uitgevoerd. Vaak wordt voor een volledige loskoppeling teruggegrepen naar 'event-based' systemen of 'event-driven architecture'. Bij centrale coördinatoren werd soms al gebruik gemaakt van events, maar enkel om services vanuit de coördinator op te roepen (de gestreepte pijlen in Figuur 6). Hens et al (Hens et al., 2010a; Hens , Snoeck, De Backer, & Poels, 2010b) gaan een stap verder en vervangen de 'calls' tussen de process engines door een publish/subscribe mechanisme. Het betreft de zwarte pijlen in Figuur 6. Deze pijlen komen overeen met de control flow beschreven in de globale flow, en beschrijven de notifications die gepubliceerd worden en waarop ingeschreven wordt door de process engines. De process engines zijn allen kleine coördinatoren die interpreteren welk werk er moet gerealiseerd worden, en de juiste service lanceren om dit werk te realiseren. Zij werken autonoom en schrijven zich in op messages om de nodige input te verzamelen via de event architectuur om de voorwaarden voor het lanceren van de services vervuld te krijgen.

17


Figuur 6 Event-based decentraliseren

Er is een duidelijke scheiding van proceslogica en functionaliteit. Elke process engine publiceert een notificatie dat zijn event heeft plaats gevonden ("job x is gebeurd"), maar heeft geen invloed op de verdere stappen. Hiermee leggen Hens et al de beslissingslogica volledig bij de volgende stap zelf, die beslist wanneer die 'inschrijft' op de notificatie om te starten. De voordelen zijn legio: er wordt een de facto loskoppeling gerealiseerd van tijd en plaats. Er is echter ook een groot nadeel verbonden aan deze manier van werken: de loskoppeling gaat ten koste van het globaal procesoverzicht. Dat procesoverzicht is zoals eerder aangehaald een heel belangrijke factor in procesmodellering, zoniet zelfs deel van de essentie van procesmodellering. Hens pareert dit nadeel door aan te geven dat het globaal procesmodel voor handen is, omdat vanuit dit model vertrokken is om de decentralisatie te verwezenlijken. Voor architecturen waar het globaal procesmodel niet (meer) voor handen is, wordt echter geen oplossing aangeboden. De oplossing voor dit vraagstuk wordt hier behandeld.

6. Decentralisatie vanuit een globaal procesmodel Om het principe van decentralisatie concreet uit te beelden, wordt hier eerst een voorbeeld van een globale procesflow gedecentraliseerd. Wanneer de flow volledig gedecentraliseerd is, kan worden nagegaan of het mogelijk is om de volledige flow te herconstrueren. In Figuur 7 wordt een voorbeeld van een globale procesflow gegeven.

18


Figuur 7 Voorbeeld hamburgerrestaurant In het voorbeeld worden process engines gebruikt om de procesflow uit te voeren. Er wordt tevens een 'task manager' gebruikt om berichten te sturen naar de inbox van de personen die de taken uitvoeren. In dit geval worden de gerechten door de kassier verzameld op een plateau. Het klaarmaken van de hamburger is een apart proces dat uitgevoerd wordt door de mensen in de keuken, het is een subproces van het vorige proces (zie Figuur 8). Om de tekening niet te zwaar te maken zijn hier zowel het subproces als de lanes van de gebruikers achterwege

gelaten

en

wordt

hier

gefocust

op

wat

aan

de

kassa

van

het

hamburgerrestaurant gebeurt wanneer de klant toekomt.

Figuur 8 Subproces 'Prepare Hamburger'

6.1

Parallelle gateway

Om het globale proces uit Figuur 7 nu te decentraliseren met een Event Architectuur zoals Hens et al. die voorstelden in (Hens

et al., 2010b), wordt het proces hier in stukken 19


getrokken zodat duidelijker afgebakend kan worden welk stuk hier wordt behandeld. Een eerste onderdeel in de flow is de parallelle gateway bij de taak 'Arrange Payment' . Deze werd aangeduid met een kader met stippellijn en nummer 1. Wanneer deze parallelle gateway opgesplitst wordt, bekomt men een deelproces zoals in Figuur 9 is afgebeeld:

Figuur 9 Split proces 'Arrange Payment'

Er moeten drie inputsignalen verzameld worden voor de process engine de service 'Arrange Payment' kan lanceren. Moeilijker wordt het echter wanneer in de conditionele flow keuzes moeten gemaakt worden, zoals bij exclusieve OR en inclusieve OR gateways. In het voorbeeld in Figuur 7 zit een voorbeeld voor beide gateways.

6.2

Toepassing decentralisatie: beperking kader

Om ook keuzes te kunnen bewaren in een gedecentraliseerd geheel van gesplitste processen, wordt hier voorgesteld om een volledige losse koppeling slechts in een beperkt aantal situaties te gebruiken. Vooreerst moet de vraag gesteld worden of centralisatie en decentralisatie mekaars exclusieve moeten zijn. Naar Kants voorbeeld kan het antwoord hier in de synthese liggen. (Kant, 1781) Niet elk proces en/of subproces stelt even hoge eisen naar flexibiliteit. Een complementaire aanpak moet mogelijk zijn. In dit verband is het onderscheid van Rosemann (Rosemann, 2010) interessant. Hij onderscheidt twee verschillende types services. Enerzijds zijn er transactionele services, deze kenmerken zich vooral in het feit dat ze heel repetitief en voorspelbaar zijn. De uitvoering van deze services verandert de structuur of de processen van een organisatie niet. Voorbeelden die hij aanhaalt zijn payroll, aankoop van standaard componenten of accounts receivable. Anderzijds hebben transformele services wel impact op de organisatiestructuur en processen. Rosemanns onderscheid wordt hier toegepast op de uitvoering van procestaken. Gekoppeld aan het decentralisatievraagstuk wordt hier voorgesteld om enkel transactionele services loosely coupled op te zetten. Door het gestandaardiseerde en repetitieve karakter van transactionele services worden zij uitgevoerd in een herkenbaar kader en dankzij dat 20


beperkt kader is het mogelijk alle mogelijke keuzes op te lijsten in input tabellen (confer 6.3). Wanneer de lijst van opties afgelijnd is, kunnen ook keuzes doorgegeven worden aan de process engines. Het wordt mogelijk om keuzes te maken in een flow (XOR en IOR). De keuze wordt eigenlijk gemaakt via de informatie die vervat zit in de notificatie. Wanneer het referentiekader niet beperkt is, wordt het heel moeilijk (zoniet onmogelijk) om keuzes te maken. De keuzeopties zijn in dat geval immers onbeperkt, en er kan niet afgelijnd worden met welke signalen wel en niet rekening moet gehouden worden.

6.3

XOR gateway

Wanneer volledig losgekoppelde decentralisatie enkel gebruikt wordt in herkenbare situaties, is het mogelijk om een exhaustieve lijst van combinaties te maken bij het opsplitsen van het proces. Deze extensieve lijst zal ervoor zorgen dat ook keuzes kunnen gemaakt worden in de process engines van die gesplitste processen. Teruggrijpend naar het voorbeeld van het hamburgerrestaurant, worden alle keuzemogelijkheden voor de klant in kaart gebracht. In het voorbeeld is de keuze voor een gratis frisdrank bij de hamburger beperkt tot Cola of Fanta. (Figuur 7, kader stippellijn nummer 2) Omdat er maar één drankje mag gekozen worden, betreft het hier een exclusieve OR-relatie. In een exclusieve OR relatie wordt er altijd maar één van de verschillende paden bewandeld, er wordt dus altijd maar één input geconsumeerd en één service getriggerd. Er wordt dus een keuze gemaakt.

Figuur 10 Split proces 'Add Soda'

Vanuit de globale flow is geweten dat er maar twee input signalen mogelijk zijn: ofwel 'Add Cola' ofwel 'Add Fanta'. (zie Figuur 10A ) Er zijn bijgevolg ook maar twee verschillende outputs mogelijk: 'Signal-AddColaComplete' of 'Signal-AddFantaComplete'. Doordat de

21


scope van het globale proces beperkt werd tot de vertrouwde processen zijn alle mogelijke inputs gekend. De twee enige opties in dit voorbeeld zijn:

Input tabel 'Add Soda' Signal-AddCola Signal-AddFanta

Door het beperkte, gekende kader is het ook mogelijk om de keuze volledig af te lijnen en de XOR om te vormen tot een gecombineerde input van statussen waarbij telkens één voorwaarde wel is vervuld (status 'Complete') en alle andere statussen niet vervuld zijn (status 'Denied'). Zodra een input gevonden wordt kan de service opgestart worden door de locale engine, want de statusinformatie die gelezen wordt heeft zowel een antwoord op welk pad in deze flow gekozen wordt, als een antwoord op de vraag welk pad hier uitgesloten wordt. Noteer dat deze manier van werken het nadeel heeft dat meer data moet worden meegegeven tussen de verschillende process engines (in de event notifications). Wanneer het aantal opties binnen de keuze oploopt, moeten deze allemaal opgenomen worden in de extensieve lijst die meegegeven wordt. Bij exclusieve OR keuzes blijft dit aantal beperkt tot het aantal alternatieven dat er zijn. Bij inclusieve OR's zijn meer combinaties mogelijk en kan de hoeveelheid meegegeven data sterk oplopen. Merk op dat er nog een tweede XOR relatie in het voorbeeld verwerkt zit. Daar beperkt de keuze zich tot het wel of niet bijbestellen van iets extra.

6.4

IOR gateway

Deze methode kan nu op gelijkaardige manier toegepast worden om procesdelen met inclusieve OR beslissingen op te splitsen. Bijkomende moeilijkheid bij IOR gateways is dat de keuze die gemaakt wordt niet exclusief is. Er zijn bijgevolg combinaties mogelijk van de te volgen flows. In het voorbeeld van het hamburgerrestaurant hebben de klanten de keuze om een extra salade bij te bestellen of extra frieten. (Figuur 7 - kader stippellijn nummer 3) Het verschil met de frisdrankbeslissing is dat klanten hier ook de keuze hebben om beide bij te bestellen of helemaal niets. Er zijn dus meer mogelijkheden. Deze keuze tussen wel of niet extra's bijvoegen is een XOR beslissing, die dus met de in sectie 6.3 voorgestelde methode kan gedecentraliseerd worden. Ze wordt hier expliciet bij de IOR vermeld omdat in het IORpad ook het signaal 'Signal-NoExtrasDenied' telkens in de input notificaties zit. Met de voorgestelde methode om processen op te splitsen met gebruik van input tabellen mag het decentraliseren van de IOR-beslissing geen struikelblok vormen. Wel zal er meer informatie 22


in het gesplitste proces moeten worden meegenomen. Waar het hier 'maar' twee services betreft die kunnen aangesproken worden, zijn er wel vier mogelijke scenario's, die allemaal in het gesplitste proces moeten vervat zitten. De engine moet immers weten welke service(s) gestart moet(en) worden.

Input tabel 'Add Extra's' Signal-NoExtra's Signal-AddSalad Signal-AddFries

Hier zullen er in de praktijk vier aparte processen zijn, één voor elke mogelijkheid. In Figuur 11 wordt uitgebeeld welke vier gesplitste processen hier mogelijk zijn. Opvallend is dat bij het eerste scenario geen enkele service gestart wordt door de engine, en bij het vierde scenario twee verschillende services opgestart worden.

Figuur 11 Split proces 'AddExtra's' 23


6.5

Besluit decentralisatie

Op basis van de door Hens voorgestelde methode tot decentralisatie kon een voorbeeldflow gedecentraliseerd worden. Mits enkele aanpassingen kon deze methode ook toegepast worden waar keuzes moesten gemaakt worden (XOR en IOR gateways). Om deze mogelijk te maken, werd het werkkader van decentralisatie beperkt tot een kader waarin alle opties binnen de flow gekend zijn. Daardoor wordt een opsomming van de keuzemogelijkheden in de flow mogelijk. Wanneer alle keuzemogelijkheden bekend zijn, wordt het ook mogelijk om in gesplitste procesdelen, mits toevoeging van de nodige informatie, keuzepaden in de flow te definiëren. Uiteindelijk werden vanuit de globale flow een reeks gesplitste processen opgezet, die nu vanuit aparte process engines gestuurd kunnen worden. Het is interessant om vanuit deze gesplitste processen te vertrekken om op zoek te gaan naar een globaal procesoverzicht.

7. Van decentrale architectuur naar globaal procesoverzicht "Ideally, each subprocess will have one entrance and one exit. However, the most critical consideration is that the process be understood by the people carrying out the work. If this is not the case, the result can be a difficult to manage process." (van der Aalst & van Hee, 2002, p.93)

Wanneer een volledig 'loosely coupled' architectuur opgezet wordt, ontstaat onvermijdelijk een nieuw probleem: hoe kan men de end-to-end flow herkennen in het geheel van losse engines en services? Op het moment dat een proces in stukken geknipt wordt, verliest men alle overzicht. Het kan niet de bedoeling zijn dat de volledige end-to-end flow een groep losse elementen zonder herkenbare structuur of procesflow wordt. Wanneer de links tussen de verschillende process engines niet duidelijk is, wordt aan transparantie ingeboet en wordt coördinatie moeilijker. Ook documentatie wordt complexer (confer Inleiding). Zoals van der Aalst et al. in bovenstaande quote terecht opmerken, is het ook heel belangrijk dat de mensen die het werk uitvoeren, begrijpen wat moet gebeuren. Als dit niet het geval is, wordt het voordeel van de flexibiliteit teniet gedaan door het verlies aan draagvlak bij de actoren zelf. Hier wordt een methode voorgesteld om de globale flow vanuit een gedecentraliseerde architectuur opnieuw op te bouwen. In een eerste stap worden alle gesplitste processen verzameld. In een tweede stap wordt de statusinformatie voor in- en output geanalyseerd om 24


de processen aan elkaar te kunnen linken. In laatste instantie wordt de verzamelde informatie aangewend om de globale procesflow te herconstrueren.

7.1

Verzameling gesplitste processen

Een eerste stap in het mogelijk maken van een reconstructie van een globale procesflow werd al gezet tijdens het decentraliseren zelf. Door een volledig losse koppeling enkel te gebruiken binnen duidelijk afgelijnde en gekende werkdomeinen kon sluitende informatie vervat worden in de gesplitste processen zelf. Met deze informatie kan nu een poging ondernomen worden om de globale flow te reconstrueren. Een tweede stap tot het realiseren van een overzicht wordt het vinden en analyseren van verbanden tussen de processtappen. Elk gesplitst proces moet nu terug uitgebeeld worden in een BPMN flow. Wanneer een processtap volledig geautomatiseerd is, noemt BPMN dit een 'service taak'. In de procescode zit de informatie verwerkt die nodig is om de link te leggen naar een voorgaande of volgende stap in het proces. Is deze informatie niet gekend, dan kan een service niet gestart worden en is er bijgevolg geen sprake van een processtap. In Figuur 9, Figuur 10 en Figuur 11 zijn enkele gesplitste processtappen van het voorbeeld uitgebeeld. Bij elke stap is aangegeven welke input vereist is om de service te starten. Er is ook aangegeven welke eindstatus bekomen wordt na uitvoering van de service. Deze in- en output informatie zit in de procescode van deze engines vervat. Op BPMN-niveau wordt het meegeven van in- en output statussen gesupporteerd via parameters, in het bijzonder via de Input- and OutputPorpertyMaps attributen. (Wohed, van der Aalst, Dumas, ter Hofstede, & Russell, 2006). Kan er nu mits lichte aanpassingen aan de uitbeelding van de gesplitste processen een link gelegd worden tussen de procesdelen zonder de informatie over het losgekoppelde aspect op te geven?

7.2

Parallelle gateway

Net zoals de parallelle gateway de minst complexe was om te decentraliseren, zal ook blijken dat een parallelle gateway relatief snel te reconstrueren is uit een gesplitst proces.

25


Figuur 12 Gesplitst proces 'Arrange Payment'

Startend van het proces 'Arrange Payment' uit Figuur 12 kan men vaststellen dat deze taak enkel start wanneer alle drie de startvoorwaarden vervuld zijn. Het parallel karakter zit eigenlijk al in het start event verwerkt. De startvoorwaarden voor deze taak kunnen aangewend worden om op zoek te gaan naar voorgaande stappen in de te reconstrueren flow. Is er een gepubliceerde notificatie terug te vinden die output 'Signal-AddSodaComplete' bevat? Indien zo'n notificatie kan teruggevonden worden, kan hieruit ook afgeleid worden welke service gelanceerd werd, en door welke process engine. Dit is mogelijk omdat de informatie over de (voorgaande) proceslogica tijdens het decentraliseren meegegeven werd via de input tabellen. Om dit opzoeken automatisch te laten verlopen, wordt veel verwacht van de opkomende techniek van process mining. Op basis van event logs wordt zoveel mogelijk informatie en kennis verzameld over lopende processen. (Dumas et al., 2005; Stoesser, 2011; van der Aalst, 2011) Op basis van die logs worden een aantal analyses gedaan om technische pijnpunten te ontdekken. Process mining heeft zich recent ontwikkeld tot een apart vakgebied. (Dumas et al., 2005; Process Mining Group, 2009) Process mining moet zich in deze context niet beperken tot het zichtbaar maken van veel voorkomende relaties, het kan ook een waardevol instrument zijn om deadlocks of bottlenecks te traceren. In het voorbeeld kan via de input tabellen een link gelegd worden naar de vorige stap in de procesflow en kan een stap richting globale flow gezet worden. Toegepast op het voorbeeld moeten drie signalen getraceerd worden in de gepubliceerde notificaties, want 'Arrange Payment' consumeert drie inputsignalen.

26


Figuur 13 Reconstructie 'Arrange Payment'

In wat volgt worden 'Add Soda' en 'Add Extra's' van dichtbij bekeken, respectievelijk in 7.3 en 7.4.

7.3

XOR gateway

Om XOR gateways te herkennen in gedecentraliseerde processen moet men op zoek gaan naar process engines die één 'Complete' signaal en één of meerdere 'Denied' signalen als input hebben. Er moeten ook evenveel taken teruggevonden worden als er statussen zijn in de inputsignalen. In het voorbeeld van het hamburgerrestaurant zijn er twee processen terug te vinden die aan deze voorwaarden voldoen, het 'Add Cola' proces en 'Add Fanta'.

Figuur 14 Gesplitste processen met 1 'complete' signaal

Omdat er telkens maar één van de processen kan opgestart worden door de process engine, kan hier een exclusieve OR-keuze onderscheiden worden. De beginstatussen kunnen

27


herleid worden tot 'Signal-AddCola' en 'Signal-AddFanta'. Om duidelijk aan te geven dat het een keuze betreft wordt hier een conditional start event gebruikt. In de toekomst zou het mits een kleine uitbreiding mogelijk moeten zijn expliciet uit te beelden dat het een input tabel betreft met input statussen die elkaar uitsluiten. Een duidelijk symbool in deze context zou een event met een X zijn, naar analogie met de exclusieve gateways. (zie Figuur 15)

Figuur 15 Exclusieve events Zowel start, intermediate als end event worden hier op deze nieuwe manier afgebeeld.

Figuur 16 Reconstructie Add Soda

Afhankelijk van welke input er gevonden worden in de event architectuur, wordt één van beide flows doorlopen (C1 of C2) en dus één van beide als Complete uitgestuurd. In de reconstructie van de globale procesflow was inderdaad al een input aanwezig die overeenkomt met wat hier gepubliceerd wordt. Deze stap kan dus toegevoegd worden aan het model (confer infra). Er is nog een tweede XOR relatie aanwezig in het voorbeeld van het hamburgerrestaurant. Het triggeren van 'Signal-AddExtra'sComplete' wordt vooraf gegaan door de exclusieve keuze tussen wel of geen extra's.

28


7.4

IOR gateway

De gesplitste processen in dit geval worden terug afgebeeld in Figuur 17.

Figuur 17 Gesplitste processen 'Add Extra's'

Mits toevoeging van wat kleine elementen kan dit iets duidelijker worden afgebeeld. Ten eerste blijkt dat hier een XOR relatie kan afgezonderd worden : Signal-NoExtra's is in slechts één van alle gevallen vervuld. In alle andere gevallen wordt het 'denied'. Dit komt overeen met één en slechts één pad. Wanneer deze XOR beslissing geïsoleerd wordt van de rest, is er een tweede patroon dat kan herkend worden. De gesplitste processen gebruiken allen dezelfde inputs, en dus dezelfde input tabel voor hun statussen. Alle drie de processen werken dus binnen hetzelfde kader:

Input tabel Extra's Signal-AddSalad 29


Signal-AddFries

Ook hun output hebben alle processen gemeen: 'Signal-AddExtra's'. Het wordt hier dus snel duidelijk dat deze drie processen een connectie hebben. Om dit aspect uit te beelden kan hier gebruik gemaakt worden van een abstracte taak 'Add Extra's' (confer 7.3), die het keuzemoment in de process engine uitbeeldt. Het is een abstracte taak, die eigenlijk meer dient als een hulpmiddel om de flow op te bouwen. 'Add Extra's' zal afhankelijk van het scenario dat wordt doorlopen de service 'Add Extra Salad', 'Add Extra Fries' of beide voorstellen. Gezien het drie aparte scenario's betreft, wordt hier een exclusieve gateway toegevoegd om aan te duiden dat het hier drie aparte scenario's betreft.

Figuur 18 Reconstructie Split proces 'Add Extra's'

Op het eerste zicht lijkt het alsof hier ook een XOR gateway kan gereconstrueerd worden. In de Input tabel is echter duidelijk aangegeven dat een simultaan voorkomen van 'Add Salad' en 'Add Fries' mogelijk is. Het is dus geen exclusieve keuze (XOR) maar een inclusieve

30


(IOR). De flow kan dus vereenvoudigd worden tot een flow waarin slechts twee taken uitgevoerd kunnen worden. Het resultaat is een IOR met twee verschillende paden.

Figuur 19 Reconstructie Split proces 'Add Extra's' - tweede stap

Analoog met de exclusieve input is er ook hier een nood om het niet-exclusieve karakter van de input aan te duiden. Om duidelijk aan te geven dat het een niet-exclusieve keuze betreft met een input tabel met input statussen die elkaar niet uitsluiten, wordt hier -opnieuw naar analogie met bestaande inclusieve gateways- geopteerd voor een cirkel (zie Figuur 15). Merk op dat de cirkel steeds wit gekleurd is om het onderscheid te maken met de cirkel die al gebruikt wordt om een intermediate event aan te duiden. Zowel start, intermediate als end event worden hier op deze nieuwe manier afgebeeld.

Figuur 20 Inclusieve events

7.5

Behoud losgekoppelde aspect in BPMN model van de globale

flow Een belangrijk aspect bij de reconstructie van de flow in een loosely coupled architectuur is de vraag hoe men kan vermijden dat het losgekoppelde aspect van de flow verloren gaat in het globale BPMN 2.0 procesmodel. Door in de reconstructie steeds de events in de tekening te houden (zie Figuur 22) kan duidelijk gemaakt worden dat het hier elkaar opvolgende processen betreft waartussen met events gecommuniceerd wordt. Dit is echter nog niet opgenomen in de BPMN 2.0 standaarden. Mits een opname van dit principe kan ook het losgekoppelde aspect van een architectuur opgenomen worden in het model. Het is niet ondenkbaar dat hier in de toekomst nog meer eisen worden gesteld aan dit principe om 31


bijvoorbeeld tijd en/of plaatsonafhankelijkheid specifiek aan te duiden. Het toevoegen van een lettercode aan de event symbolen die de flows met elkaar verbinden, kan dit aanduiden.

7.6

Reconstructie globale procesflow

Om keuzes op te zoeken tussen verschillende losgekoppelde deelprocessen en engines is een analyse nodig van de beschikbare input tabellen in drie stappen:

1) Werden alle gesplitste processen teruggevonden die op basis van de input tabel mogelijk zijn? 2) Bevat de input tabel 'no options' of 'all options' inputs? Indien ja, is er sprake van een IOR. Indien nee, is er sprake van een XOR. In dit tweede geval moeten er ook exact evenveel gesplitste processen mogelijk zijn, als er in- en output statussen zijn in de tabel. Toch zal er bij elke instance slechts één doorlopen worden. 3) Voor Parallelle gateways moeten voor alle entries in de input tabel een signaal teruggevonden worden.

Op voorwaarde dat de flow gedecentraliseerd werd volgens de in sectie 6 voorgestelde (uitgebreide) decentralisatiemethode, kan een globale procesflow aan de hand van bovenstaande regels terug opgebouwd worden, startend van de gesplitste processen. De oorspronkelijke globale flow hoeft hiervoor niet beschikbaar te zijn. Door toepassing van bovenstaande regels kan onderstaande globale flow opgebouwd worden voor het voorbeeld van het hamburgerrestaurant (Figuur 21). Om de tekening niet te overladen met informatie worden de in- en output statussen niet meer afgebeeld, dit wil niet zeggen dat zij niet meer in het model vervat zitten.

32


Figuur 21 Voorlopig gereconstrueerde flow

Merk op dat het globale proces hier vertrekt vanuit drie notifications (event messages) die gelezen worden. Wanneer een process instance ID wordt meegegeven in de event messages moet het mogelijk zijn om deze drie events aan elkaar te linken. Meer zelfs, als meerdere start events dezelfde process ID hebben, is hier sprake van een parallelle gateway en kan deze globale flow nog een stuk vervolledigd worden:

33


Figuur 22 Gereconstrueerd bestellingproces hamburgerrestaurant

Wanneer alle informatie verzameld en aan elkaar gelinkt is, bekomt men het uiteindelijke globale proces zoals weergegeven in Figuur 22. Indien geen beginstatussen meer gevonden worden om te linken aan eindstatussen, zit men op een eindpunt. De verschillende links zijn zichtbaar en de informatie rond al dan niet losse koppeling van procesdelen is in het model opgenomen. Na heropbouw van de flow wordt analyse van de processen terug completer. Wanneer bijvoorbeeld door process mining naar boven komt dat een bepaalde process engine in ons proces vaak faalt, is het nu duidelijker waar die 'zwakke' process engine zich in het globale proces bevindt. Dankzij dit overzicht zal een beslissing tot eventuele aanpassing steviger onderbouwd zijn.

34


8.

Conclusie

Vertrekkend van bestaande literatuur over decentralisatie van informatiesystemen werd gekomen tot een antwoord op de eerste onderzoeksvraag. Er kunnen drie grote 'scholen' herkend worden in bestaand onderzoek rond decentralisatie. De rode draad vertrekt bij een volledig centraal systeem en wordt door de verschillende "scholen" stap voor stap gedecentraliseerd. Een eerste school ging enkel de uitvoering van specifieke services decentraliseren. Een tweede school probeerde ook de proceslogica te decentraliseren door deze in de process engines zelf in te passen. Een derde school ging het verst en koppelde ook de process engines volledig van elkaar los. Dan spreekt met over 'loosely coupled' systemen.

Als antwoord op de tweede onderzoeksvraag naar elementen die kunnen bijdragen tot realisatie van een globale procesflow werden de bestaande systemen voor decentralisatie aangevuld met input tabellen. Deze werden toegevoegd in notificaties die gepubliceerd worden in de event architectuur, om ook keuzes in een losgekoppelde architectuur mogelijk te maken. De informatie nodig voor de control flow wordt dus volledig opgenomen in de notifications die tussen de process engines worden uitgewisseld via de event architectuur. De vraag werd gesteld om het of-of denken te verlaten en een gecombineerd gebruik van de verschillende decentralisatiemethodes te gebruiken. Door volledige loskoppeling enkel op te zetten binnen de grenzen van bekende processen, kunnen ook keuzes opgenomen worden in een losgekoppelde setup. De laatste onderzoeksvraag was om een methode te ontwikkelen om een overzicht bij gedecentraliseerde architecturen te realiseren. Het voorgesteld model spoort aan tot gecombineerd gebruik van de verschillende methodes (centraal, gekoppeld decentraal en losgekoppeld decentraal), om zo een 'best of both worlds' te bereiken. Om de reconstructie van keuzes (gateways) mogelijk te maken, werd een oplossing voorgesteld waar de informatie over de proceslogica wordt meegegeven in de notifications. Reconstructie van een procesoverzicht wordt mogelijk gemaakt op basis van een combinatie van verschillende gegevensbronnen: 

Beperking referentiekader: omdat losgekoppelde engines en services beperkt worden tot de transactionele laag, worden ze beperkt tot de vertrouwde delen van het bedrijfsproces. Dit reduceert het aantal potentiële engines om te linken en

35


services om te lanceren en maakt het gebruik van input- en output tabellen mogelijk. 

Opvangen van proceslogica in de input- en outputinformatie in de notifications die verstuurd en aangeschreven worden door de gedecentraliseerde process engines. Deze informatie maakt het via de tabellen mogelijk om ook keuzegateways in losgekoppelde systemen op te nemen.



Het expliciet aanduiden van alle link-events in het globale procesmodel om het losgekoppelde karakter van de architectuur in het model te bewaren.

Van een losse verzameling processen werd een geheel gereconstrueerd in een globale BPMN flow door combinatie van bestaande en nieuwe elementen. Ook de relaties konden worden uitgebeeld zonder de informatie over de losse koppeling van de stappen te verliezen.

9.

Kritische reflectie

De beloftes van een volledig flexibel en losgekoppeld systeem klinken veelbelovend, maar men moet de vraag durven stellen of de toegevoegde waarde van een 100% losgekoppelde end-to-end flow wel significant is. Men moet veel opgeven (globaal overzicht) om die complete flexibiliteit te bereiken. Bovendien zijn transparantie en overzicht net hoekstenen van procesmodellering. Het opgeven van een overzicht ondermijnt eigenlijk de drijfveer van BPM projecten. Hier werd een oplossing voorgesteld ter verbetering van het globaal procesoverzicht bij gedecentraliseerde processen en procesarchitecturen. Daarvoor werd de decentralisatie zelf uitgebreid met 'input tabel'-concept. Dit moet het mogelijk maken om keuzes ook op te nemen in een losgekoppeld decentrale architectuur. Meteen worden ook een aantal nieuwe vragen opgeroepen: 

Heel interessant voor verder onderzoek is de vraag of deze methode ook kan omgezet worden in praktisch werkbare procescode.



Als een dergelijke werkbare code kan geschreven worden, ontstaat meteen een nieuwe vraag: wat is de invloed van het meesturen van al die extra informatie op de performantie en werkbaarheid van de gedecentraliseerde, gesplitste processen? Het is niet ondenkbaar dat die extra informatie een invloed zal hebben op de werking van de event architectuur. Dit is meteen ook één van de grootste nadelen verbonden aan deze methode. Hoe sterk deze invloed doorweegt, en wat dit betekent ten opzichte

36


van het voordeel van volledige flexibiliteit, is zeker een heel interessant punt voor verder onderzoek door derden. 

Een derde heel interessante vraag is wat de rol van process mining kan zijn in dit verhaal. Process mining is aan een sterke opmars bezig, en zal ongetwijfeld deuren openen om heel snel te reageren op probleemsituaties, ook in decentrale omgevingen. Process mining en de hier voorgestelde methode tot verbetering van het globaal procesoverzicht moeten elkaar kunnen aanvullen. Waar het procesoverzicht vooral de functionele zijde van de proceswerking moet ondersteunen, kan process mining helpen om de technische zwakke punten in het proces aan te duiden.

Last but not least wordt hier meegegeven dat men nooit uit het oog mag verliezen dat niet enkel technische haalbaarheid een bepalende factor mag zijn voor het al dan niet decentraliseren van een architectuur. Het is niet omdat iets kan, dat het ook moet gebruikt worden. Voor elk systeem moet een gerichte analyse uitgevoerd worden over pro's en contra's in de gegeven omgeving. Steeds moet er nagegaan worden of de grotere flexibiliteit gerealiseerd door de volledige loskoppeling, opweegt tegen het verlies aan overzicht. In procesanalyse en procesbeheer moet steeds de nodige ruimte blijven voor analyse, analyse die moeilijker is zonder een globale flow. Weegt het voordeel van de extra flexibiliteit op tegen het extra werk nodig om het overzicht te bewaren?

37


10.

Bibliografie

Aguilar-Savén, R. S. 2004. Business process modelling: Review and framework. International Journal of Production Economics, 90(2): 129-149. Alonso, G. 2008. Myths around Web Services, Bulletin of the Technical Committee on Data Engineering, December 2002 ed.: 3-9. Alonso, G., Casati, F., Kuno, H., & Machiraju, V. 2004. Web services: Concepts, architectures and applications. Heidelberg: Springer. Avison, D., & Pries-Heje, J. 2005. Research in Information Systems: A Handbook for research supervisors and their students: Elsevier Ltd. Barros, A., Dumas, M., & Oaks, P. 2006. Standards for Web Service Choreography and Orchestration: Status and Perspectives. In C. Bussler, & A. Haller (Eds.), Business Process Management Workshops, Vol. 3812: 61-74: Springer Berlin / Heidelberg. Benatallah, B., Dumas, M., & Sheng, Q. Z. 2005. Facilitating the Rapid Development and Scalable Orchestration of Composite Web Services. Distributed and Parallel Databases, 17(1): 5-37. Catts, A., & St.Clair, J. 2009. Business Process Management Enabled by SOA. Chafle, G. B., Chandra, S., Mann, V., & Nanda, M. G. 2004. Decentralized orchestration of composite web services, Proceedings of the 13th international World Wide Web conference on Alternate track papers & posters: 134-143. New York, NY, USA: ACM. Chen, Q. 2001. Inter-Enterprise Collaborative Business Process Management, International Conference on Data Engineering: HP Labs - Hewlett Packard Co. . Curbera, F., Duftler, M., Khalaf, R., Nagy, W., Mukhi, N., & Weerawarana, S. 2002. Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI. IEEE Internet Computing, 6(2): 86-93. Curbera, F., Khalaf, R., Mukhi, N., Tai, S., & Weerawarana, S. 2003. The next step in Web services. Commun. ACM, 46(10): 29-34. Davenport, T., & Short, J. 1990. The new industrial engineering: information technology and business process redesign. Sloan Management Review, 31(4): 11-27. Dijkman, R., & Dumas, M. 2004. Service-oriented Design: A Multi-viewpoint Approach. Dumas, M., van der Aalst, W. M. P., & ter Hofstede, A. 2005. Process-Aware Information Systems: John Wiley & Sons, Inc. Eriksson, H.-E., & Penker, M. 2000. Business Modeling with UML: Addison-Wesley. Fdhila, W., Yildiz, U., & Godart, C. 2009. A Flexible Approach for Automatic Process Decentralization Using Dependency Tables. Paper presented at the Web Services, 2009. ICWS 2009. IEEE International Conference on. Feurer, S. 2007. Enterprise Architecture – IT meets Business: 16: BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com. Hens, P., Snoeck, M., De Backer, M., & Poels, G. 2010a. Decentralized Event-Based Orchestration International Workshop on Event-Driven Business Process Management (edBPM'10) (Hoboken, NJ (US)): 9. Hens , P., Snoeck, M., De Backer, M., & Poels, G. 2010b. Transforming Standard Process Models to Decentralized Autonomous Entities, Conference on Enterprise Information Systems. Eindhoven, The Netherlands. Hevner, A. R., March, S. T., Park, J., & Ram, S. 2004. Design Science in Information Systems Research. MIS Quarterly, 28(1): 75-105. Jacobson, I. 1995. The Object Advantage: Business Process Reengineering With Object Technology Addison-Wesley Pub Co. Kant, I. 1781. Kritik der reinen Vernunft.

38


Krallmann, G., & Derszteler, H. 1996. Workflow Management Cycle: An Integrated Approach to the Modelling, Execution and Monitoring of Workflow-Based Processes. In B. Scholz-Reiter, & E. Stickel (Eds.), Business Process Modelling. Berling: Springer Verlag. Lin, F.-R., Yang, M.-C., & Pai, Y.-H. 2002. A generic structure for business process modeling. Business Process Management Journal, 8(1): 19 - 41. Lindsay, A., Downs, D., & Lunn, K. 2003. Business processes--attempts to find a definition. Information and Software Technology, 45(15): 1015-1019. Marín, C. 2005. Multiagent Architecture for Decentralized Workflow Process Execution: Center for Intelligent Systems Tecnol´ogico de Monterrey Monterrey, Mexico. Melão, N., & Pidd, M. 2000. A conceptual framework for understanding business processes and business process modelling. Information Systems Journal, 10(2): 105-129. Mendling, J., Reijers, H. A., & van der Aalst, W. M. P. 2010. Seven process modeling guidelines (7PMG). Information and Software Technology, 52(2): 127-136. Microsoft Corporation. 2010. Microsoft BizTalk Server 2010, Vol. 2011. Mühl, G., Fiege, L., & Pietzuch, P. 2006. Distributed Event-Based Systems: Springer-Verlag New York, Inc. Muth, P., Wodtke, D., Weissenfels, J., Dittrich, A. K., & Weikum, G. 1998. From Centralized Workflow Specification to Distributed Workflow Execution. Journal of Intelligent Information Systems, 10(2): 159-184. Muthusamy, V., & Jacobsen, H.-A. 2010. BPM in Cloud Architectures: Business Process Management with SLAs and Events. In R. Hull, J. Mendling, & S. Tai (Eds.), Business Process Management, Vol. 6336: 5-10: Springer Berlin / Heidelberg. Nanda, M. G., Chandra, S., & Sarkar, V. 2004. Decentralizing execution of composite web services, Proceedings of the 19th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications: 170-187. Vancouver, BC, Canada: ACM. Negele, H., Fricke, E., Schrepfer, L., & Härtlein, N. 1999. Modeling of integrated product development processes. Paper presented at the 9 th Annual Int. Symposium of INCOSE Systems Engineering: Sharing the Future. Neiger, D., & Churilov, L. 2004. Goal-Oriented Business Process Modeling with EPCs and ValueFocused Thinking. In J. Desel, B. Pernici, & M. Weske (Eds.), Business Process Management, Vol. 3080: 98-115: Springer Berlin / Heidelberg. Nurcan, S. 2008. A Survey on the Flexibility Requirements Related to Business Processes and Modeling Artifacts. Paper presented at the 41st Annual Hawaii International Conference on System Sciences, Hawaii. OMG. Object Managment Group website. ORACLE. 2011. Oracle Business Process Analysis Suite. Papazoglou, M. 2005a. Extending the service-oriented architecture. Business Integration Journal: 1821. Poels, G. 2009. Hoofdstuk 5 : Business Process Management. Cursus Beleidsinformatica: 242-310. Process Mining Group, M. C. d., Eindhoven University of Technology. 2009. Process mining. Reijers, H., & Mendling, J. 2008. Modularity in Process Models: Review and Effects. In M. Dumas, M. Reichert, & M.-C. Shan (Eds.), Business Process Management, Vol. 5240: 20-35: Springer Berlin / Heidelberg. Rosemann, M. 2006. Potential pitfalls of process modeling: part B. Business Process Management Journal, 12(3): 377-384. Rosemann, M. 2010. Process Management as a Service: 4. Rosemann, M., & Brocke, J. 2010. The Six Core Elements of Business Process Management. In J. v. Brocke, & M. Rosemann (Eds.), Handbook on Business Process Management 1: 107-122: Springer Berlin Heidelberg. SAP AG. 2011. SAP Process Integration 7.1. Scheer, A.-W. 2000. ARIS - Business Process Modeling: Springer-Verlag, Berlin Heidelberg. Scheer, A.-W. 2011. ARIS Modeling Standards. 39


Scheer, A.-W., Kirchmer, M., & Wolfram, J. (Eds.). 2002. Business Process Excellence: Aris in Practice. New York: Springer-Verlag New York, Inc. Secaucus, NJ, USA. Silver, B. 2009. BPMN Method and Style: A levels-based methodology for BPM process modeling and improvement using BPMN 2.0: Cody-Cassidy Press. Silverthorne, S. 2011. Zoom In, Zoom Out Decision Making, The View from Harvard Business, Vol. 2011. Software AG. 2011. AWARDS & INDUSTRY RECOGNITION. Stein, A., Hawking, P., & Foster, S. 2003. ERP Post Implementation: A new journey. Paper presented at the ACIS 2003. Stoesser, T. 2011. EBPM 101 - A primer on Enterprise Business Process Management. Tolsma, J., & de Wit, D. 2009. Effectief procesmanagement: Eburon Uitgeverij. van der Aalst, W., ter Hofstede, A., & Weske, M. 2003a. Business Process Management: A Survey. In M. Weske (Ed.), Business Process Management, Vol. 2678: 1019-1019: Springer Berlin / Heidelberg. van der Aalst, W., & van Hee, K. 2002. Workflow Management: Models, Methods, and Systems (Cooperative Information Systems): The MIT Press. van der Aalst, W. M. P. 2011. Process Mining: Discovery, Conformance and Enhancement of Business Processes: Springer-Verlag Berlin Heidelberg 2011. Wohed, P., van der Aalst, W., Dumas, M., ter Hofstede, A., & Russell, N. 2006. On the Suitability of BPMN for Business Process Modelling. In S. Dustdar, J. Fiadeiro, & A. Sheth (Eds.), Business Process Management, Vol. 4102: 161-176: Springer Berlin / Heidelberg. Yildiz, U., & Godart, C. 2008. Designing Decentralized Service Compositions: Challenges and Solutions. In J. Filipe, & J. Cordeiro (Eds.), Web Information Systems and Technologies, Vol. 8: 60-71: Springer Berlin Heidelberg. Yu, W. 2009b. Consistent and decentralized orchestration of BPEL processes, Proceedings of the 2009 ACM symposium on Applied Computing: 1583-1584. Honolulu, Hawaii: ACM.

40

Het Realiseren van een Globaal Procesoverzicht bij Gedecentraliseerde Procesarchitecturen

Recommend Documents