UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2009 – 2010
Conceptuele gegevensmodellering bij procesbewuste informatiesystemen
Masterproef voorgedragen tot het bekomen van de graad van Master in de Toegepaste Economische Wetenschappen: Handelsingenieur
Jasper Delbaere onder leiding van Prof. dr. Geert Poels
Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Jasper Delbaere
Woord vooraf Het schrijven van deze masterproef was voor mij een boeiende en leerrijke ervaring. Graag wil ik van deze gelegenheid gebruik maken een dankwoord te richten aan iedereen die heeft bijgedragen bij het tot stand komen van mijn thesis.
Vooreerst wil ik mijn promotor Prof. dr. Geert Poels bedanken voor het nuttig advies en de verstrekte hulp bij het schrijven van deze masterproef. Ook wil ik de universiteit Gent danken voor het ter beschikking stellen van hun infrastructuur, de nodige literatuur en andere ondersteunende materialen die mij geholpen hebben in mijn onderzoek. Daarnaast wil ik iedereen bedanken voor het nalezen van deze masterproef.
Inhoudsopgave
1. Inleiding
1
2. Case
3
3. Informatiesystemen
6
3.1. Datagerichte informatiesystemen
8
3.2. Procesbewuste informatiesystemen
9
3.2.1. Enterprise resource planning systemen
12
3.2.2. Voor- en nadelen van procesbewuste informatiesystemen
13
4. Conceptuele modellen 4.1. Conceptuele gegevensmodellen
15 16
4.1.1. Entity-Relationship modellen
16
4.1.2. Object-Role modellen
17
4.2. Conceptuele procesmodellen
20
5. Procesmodellen
21
5.1. Waarom ook data in een procesmodel betrekken?
22
5.2. Workflow datapatronen
23
5.3. Data flow ondersteuning bij procesmodellen
25
5.4. High level petri nets
26
5.4.1. Colored petri nets
28
5.4.2. Conclusie
31
5.5. Business Process Modeling Notation
31
5.5.1. BPMN
32
5.5.2. Datapatronen ondersteund door BPMN
34
5.5.3. BPMN 2.0
35
5.5.4. Conclusie
37
5.6. Event-driven process chains
37
5.6.1. EPCs binnen het ARIS framework
38
5.6.2. De basiselementen van een EPC
38
5.6.3. Dataobjecten
39
5.6.4. Information carrier object
41
5.6.5. Knowledge object
43
5.6.6. Conclusie
44
5.7. UML Activiteitsdiagram
45
5.7.1. Elementen van een UML activiteitsdiagram
45
5.7.2. Data flow van een UML activiteitsdiagram
46
5.7.3. Uitgewerkt voorbeeld van een UML activiteitsdiagram
51
5.7.4. Datapatronen ondersteund door UML 2.0 activiteitsdiagrammen
54
5.7.5. Conclusie
55
5.8. Yet Another Workflow Language
55
5.8.1. newYAWL
55
5.8.2. Data-elementen ondersteuning
57
5.8.3. Data-interactie ondersteuning
57
5.8.4. Linkcondities
59
5.8.5. Pre- en postcondities
59
5.8.6. Locks
60
5.8.7. Datapatronen ondersteund door YAWL en newYAWL
60
5.8.8. Conclusie
60
6. Gegevensmodellering bij procesgericht informatiesystemen 6.1. Product Based Workflow Design
62 62
6.1.1. Product Data Model
63
6.1.2. Product Based Workflow Design
66
6.1.3. Product Based Workflow Support
69
6.1.4. Conclusie
71
6.2. Case handling systemen
71
6.2.1. Case handling
73
6.2.2. Case handling en Product Based Workflow Design
75
6.2.3. Conclusie
76
6.3. Information-centric procesmodellering 6.3.1. Artifact-centric procesmodellering
76 78
6.3.2. Omvormen van een activity-centric model naar een information-centric model
82
6.3.3. Document-driven workflow systemen
86
6.3.4. Conclusie
87
6.4. Data-Driven Process Structures
88
6.4.1. COREPRO Modeling Framework
88
6.4.2. Conclusie
92
6.5. Document-process association model
92
6.6. Data Acces Plug-ins en XML based data acces
95
6.7. Overzicht van bijkomende methoden en concepten
97
6.7.1. Data-Driven Process Control en Exception Handling
97
6.7.2. Data flow en validatie
98
6.7.3. AHEAD
100
6.7.4. ADAPTflex
100
6.7.5. SEAM
100
7. Algemene conclusie
101
8. Lijst met geraadpleegde werken
105
Gebruikte afkortingen AD = Activiteitsdiagrammen ARIS = Architecture of Integrated Information System BOM = Bill Of Material BPD = Business Process Diagram BPEL = Business Process Execution Language BPM = Business Process Management BPMI = Business Process Management Initiative BPMN = Business Process Modeling Notation BPMN 2.0 = Business Process Modeling Notation 2.0 BPMS = Business Process Management Systeem BPR = Business Process Reengineering CPN = Colored Petri Nets DBMS = Database Management Systeem DSM = Documentstructuur model DTD = Document Type Definition eEPC = extended Event-Driven Process Chains EPC = Event-Driven Process Chains ER = Entity-Relationship ERM = Entity-Relationship Model ERP = Enterprise Resource Planning FIFO = First In, First Out GDAP = Generic Data Access Plug-in ID = Identificatiecode of – sleutel IS = Informatiesysteem LCM = Life Cycle Coordination Model LCS = Life Cycle Coordination Structure LIFO = Last In, First Out newYAWL = new Yet Another Workflow Language OLC = Object Life Cycle
OMG = Object Management Group OODBMS= Object Oriented Database Management Systeem ORM = Object-Role Model PAIS = Process-Aware Information System PBWD = Product Based Workflow Design PBWS = Product Based Workflow Support PDM = Product Data Model PK = Primary Key PMS = Proces Management Systeem PSM = Processtructuur model RDBMS = Relational Database Management Systeem UML = Unified Modeling Language WfM = Workflow Management WfMS = Workflow Management Systeem YAWL = Yet Another Workflow Language
Lijst van tabellen I.
Multipliciteiten bij een ER Model
II.
Overzicht van de datapatronen die worden ondersteund door workflow systemen (+ ondersteund door het WfMS, - niet ondersteund door het WfMS)(Russell et al. 2006a)
III.
Overzicht van de datapatronen die worden ondersteund door BPMN (+ ondersteund door BPMN, - niet ondersteund door BPMN) (Wohed et al. 2006)
IV.
Overzicht van de datapatronen die worden ondersteund door UML 2.0 activiteitsdiagrammen (+ ondersteund door AD, - niet ondersteund door AD) (Russell et al., 2006b)
V.
Data patronen die worden ondersteund door YAWL en newYAWL (+ ondersteund door YAWL/newYAWL, - niet ondersteund door YAWL/newYAWL) (Russell et al., 2007)
VI.
Verschillen tussen workflow management en case handling (van der Aalst et al., 2004)
Lijst van figuren I.
Schematische voorstelling van de basiscase (Loos & Thomas, 1998; Dumas et al. 2005)
II.
Trends in informatiesystemen (van der Aalst et al. 2003)
III.
Verband tussen processen en informatiesystemen (Davenport en Short, 1990)
IV.
Voorbeeld van een Entity-Relationship datamodel
V.
Symbolen van een Object-Role model
VI.
Voorbeeld van een Object-Role model
VII.
Onderdelen van een informatiesysteem (van der Aalst, 1998)
VIII.
Voorbeeld van een low level petri net
IX.
Basiselementen van petri nets
X.
Voorbeeld van colored petri nets (Chu-Carroll, 2007)
XI.
Voorbeeld van token consumptie (links) en productie (rechts)
XII.
BPMN constructen
XIII.
Voorbeeld van een Business Process Diagram
XIV.
Data-elementen van BPMN 2.0 (OMG, 2009)
XV.
Basiselementen van een EPC
XVI.
Dataobjecten van een EPC (Davis & Brabänder, 2007)
XVII.
Vergelijking technical term objecten (links) met formele dataobjecten (rects) (Davis & Brabänder, 2007)
XVIII.
Transformatie van data (Davis & Brabänder, 2007)
XIX.
Information carrier object
XX.
Alternatieve weergaven van een information carrier object (Davis & Brabänder, 2007)
XXI.
Voorbeeld van een event-driven process chain
XXII.
Knowlegde objecten van een EPC
XXIII.
Voorbeeld van een token flow bij UML 2.0 activiteitsdiagrammen (Dumas et al., 2005)
XXIV.
De vier mogelijke object nodes uit UML 2.0 AD (Bock, 2003)
XXV.
A) Input en output pins B) Stand alone notatie (Engels et al., 2005)
XXVI.
Voorbeeld van een activiteit met activity parameter nodes (Bock, 2003)
XXVII.
Voorbeeld van een upper bound en een selectie (Engels et al., 2005)
XXVIII.
Voorbeeld van een pre- en postconditie van een actie (Bell, 2003)
XXIX.
Uitgewerkt voorbeeld van een activiteitsdiagram (Engels et al., 2005)
XXX.
Basisconstructen van newYAWL
XXXI.
Een voorbeeld van een newYAWL model
XXXII.
Voorbeeld van een evaluatie van een input parameter (Russell et al., 2007a)
XXXIII.
Voorbeeld van een bill of material voor productieprocessen
XXXIV.
Voorbeeld van een A) AND en een B) XOR conditie uit een product data model
XXXV.
Voorbeeld van een product data model
XXXVI.
Deel van PDM uit figuur XXXV
XXXVII.
Petri net model gemaakt op basis van een product data model
XXXVIII.
Schematisch overzicht van PBWD (Vanderfeesten et al., 2008c)
XXXIX.
Uitvoeren van een product data model pad 1
XL.
Uitvoeren van een product data model pad 2
XLI.
Levenscyclusmodel van het artefact ‘Bestelling’
XLII.
Artefactgerichte versie van een workflow model (Bhattacharya et al., 2007)
XLIII.
Constructen van een Artifact-centric Operational model
XLIV.
Een voorbeeld van een Artifact-centric Operational model (Gerede et al., 2007)
XLV.
Voorbeeld van een activity-centric procesmodel (Kumaran, et al., 2008)
XLVI.
Referentiële en inclusieve dominanties (Kumaran, et al., 2008)
XLVII.
Voorbeeld van een datamodel (Kumaran, et al., 2008)
XLVIII.
Voorbeeld van een information-centric procesmodel (Kumaran, et al., 2008)
XLIX.
Algemeen concept van de COREPRO Model benadering (Müller et al., 2010)
L.
Constructen van van een object life cycle (Müller et al., 2008)
LI.
Voorbeeld van het OLC voor het object ‘Bestelling’
LII.
Voorbeeld van interne, externe en directe toestandstransities
LIII.
Voorbeeld van een workunit model (Bae & Kim, 2002)
LIV.
Voorbeeld van een proces waarbij verloren data kunnen optreden (Sadiq et al., 2004)
1. Inleiding Vroeger lag bij het ontwikkelen van informatiesystemen de nadruk op de opslag van gegevens en het verwerken van deze gegevens tot nuttige informatie. In de jaren negentig verschoof de aandacht naar processen en het dataperspectief werd naar de achtergrond geschoven. Recent is er echter steeds meer aandacht voor het dataperspectief bij procesbewuste informatiesystemen.
Het doel van deze masterproef is na te gaan of en hoe conceptuele gegevensmodellen toegepast worden bij procesbewuste informatiesystemen en derhalve ook wat de voordelen zijn van het gebruik van gegevensmodellen bij het ontwikkelen van procesbewuste informatiesystemen.
Procesbewuste
informatiesystemen
worden
ontwikkeld
op
basis
van
procesmodellen. De meeste modelleertalen om procesmodellen te ontwikkelen zijn echter vooral gericht op het rangschikken van activiteiten en het coördineren van die activiteiten. Het dataperspectief komt veel minder uitgebreid aan bod of wordt soms zelf gewoon genegeerd. In deze masterproef wordt vooral nagegaan hoe en in welke mate de traditionele procesmodellen zoals BPMN, YAWL, Petri Nets, EPC en UML 2.0 activiteitsdiagrammen de data flow ondersteunen en op die manier toelaten om data in een procesmodel te integreren.
Verder bestaan er ook andere modellen, concepten en methoden die bijzondere aandacht vestigen op het gebruik van datamodellen bij het ontwikkelen van procesbewuste informatiesystemen. Zo zijn er modellen zoals bijvoorbeeld artifactcentric modellen waarbij informatie-entiteiten de basis vormen in plaats van activiteiten. Andere technieken zoals bijvoorbeeld product based workflow design vertrekken van een datastructuur om procesmodellen te ontwikkelen.
Ter illustratie zal doorheen de thesis steeds met dezelfde case worden gewerkt. Deze case heeft voornamelijk als doel bepaalde modellen, concepten en methoden te verduidelijken en de vergelijking ertussen te vergemakkelijken.
1
In het eerste deel van deze masterproef wordt de case uitvoerig besproken. Daarna volgt een uiteenzetting over informatiesystemen en wordt het onderscheid tussen data- en procesgerichte informatiesystemen en hun respectievelijke modellen besproken. Vervolgens wordt een overzicht gegeven van de verschillende procesmodellen waarbij nadrukkelijk wordt ingegaan op het dataperspectief bij procesmodellen. Het laatste deel geeft een overzicht van concepten en methoden die eveneens de nadruk leggen op het dataperspectief bij het ontwikkelen van procesbewuste informatiesystemen.
2
2. Case Doorheen deze thesis zal steeds op dezelfde case of op specifieke onderdelen van de case worden terugkomen om bepaalde modellen en technieken te illustreren. Hier is bewust voor gekozen om het vergelijken van bepaalde modellen, technieken en concepten te vergemakkelijken.
De case is gebaseerd op het model uit Loos en Thomas (1998) en op het order fulfillment voorbeeld uit Dumas, van der Aalst en ter Hofstede (2005). Het betreft dus een order-to-fulfill proces dat is geïllustreerd aan de hand van een eenvoudig basismodel (Figuur I). De bedoeling van een order-to-fulfill proces is het produceren van een product gebaseerd op een bestelling van een klant. Alles begint dan ook met het aanmaken van dergelijke bestelling. Dit kan in de eerste plaats door de klant zelf gebeuren door het order online aan te maken. De klant kan de bestelling ook opsturen via een fax of een verkoper kan de bestelling aanmaken na zelf te hebben onderhandeld met de klant. Vervolgens wordt het order geplaatst en opgeslagen in de database „Klanten bestellingen‟. Na het plaatsen wordt de bestelling verwerkt door het bedrijf. Eens de bestelling verwerkt is, gaat men een factuur aanmaken. Deze factuur wordt daarna opgestuurd naar de klant. Gelijktijdig wordt er een productieorder
aangemaakt.
Het
productieorder
bevat
informatie
over
de
verschillende producten die moeten worden geproduceerd zoals bijvoorbeeld informatie over de status en de leveringsdatum. Aan de hand van de BOM (Bill Of Material) kan men nagaan welke materialen en onderdelen er allemaal nodig zijn om het order te produceren. Vervolgens wordt er gecontroleerd of deze materialen en onderdelen voorradig zijn. Indien dit het geval is worden ze gereserveerd, zoniet worden ze besteld bij een leverancier. Eens de materialen en onderdelen aanwezig zijn doordat ze voorradig zijn of geleverd werden en het productieorder is gemaakt, kan men overgaan tot het plannen en het maken van een productieplan. Het plannen is dus gebaseerd op het productieorder, de BOM en het tijdstip waarop de materialen en de orderdelen beschikbaar zijn.
3
Figuur I: Schematische voorstelling van de basiscase (Loos & Thomas, 1998; Dumas et al. 2005)
4
Op het geplande tijdstip worden de onderdelen opgehaald uit de voorraad en kan men aan de productie en de assemblage beginnen. Na de assemblage kan eventueel een extra controle volgen. Vervolgens kan de klant kiezen tussen enerzijds het order zelf ophalen of anderzijds het laten transporteren. In het laatste geval worden de producten nog eens extra verpakt vóór het transport. Na de verpakking kan er eveneens een extra controle volgen. Het transport kan ofwel goedkoop maar trager gebeuren ofwel gebeurt het sneller maar dan is het duurder. Indien het product niet goed geassembleerd of verpakt is, kan het nodig zijn dat de producten opnieuw moeten geassembleerd of verpakt worden. Eens de factuur betaald is en de bestelling getransporteerd of opgehaald is, kan de bestelling als afgerond worden beschouwd. Bestellingen die teruggezonden worden of problemen tijdens het transport worden hier buiten beschouwing gelaten.
Het model in figuur I toont de verschillende processtappen en de belangrijkste gegevens die in de database worden bijgehouden. De verbanden tussen de data onderling en de attributen van deze data worden niet in dit basismodel weergegeven. Het model dient dan ook louter ter illustratie en werd zo eenvoudig mogelijk gehouden. Dit basismodel is verre van een formeel model en bevat dan ook niet dezelfde uitdrukkingskracht die andere procesmodelleertalen die later aan bod komen, wel hebben. Zo werd hier bijvoorbeeld geen onderscheid gemaakt tussen het opsplitsen van paden waarbij alle parallelle paden moeten worden uitgevoerd (AND) of waarbij slechts één pad van alle parallelle paden mag worden gevolgd (XOR). Het eerste is het geval bij „Factuur maken‟, „Productieorder maken‟ en „Controleren benodigdheden‟ en het tweede komt voor bij „Materiaal reserveren‟ of „Materiaal bestellen‟.
5
3. Informatiesystemen Data en informatie zijn in steeds grotere hoeveelheden aanwezig in een bedrijf en zijn steeds gemakkelijker te vinden. In wezen is er echter een groot verschil tussen data en informatie. Data betreft de pure feiten en gegevens. Denk maar aan productgegevens, verkoopgegevens, klantengegevens. Volgens Curtis en Cobham (2008) is informatie data die op een nuttige manier verwerkt is. Een voorbeeld hiervan is het vergelijken van verkoopsgegevens om er bepaalde conclusies uit te trekken. Data zijn derhalve de feiten en gegevens die bijgehouden en opgeslagen worden, terwijl informatie de interpretatie is van die gegevens en gebruikt wordt om beslissingen te nemen. Omdat data en informatie zo ruimschoot aanwezig zijn in een bedrijf komen alle werknemers binnen een bedrijf er dan ook wel op een of andere manier mee in contact. Dit maakt het belangrijk dat de juiste informatie steeds beschikbaar
is,
gemakkelijk
kan
worden
teruggevonden
en
opgevraagd.
Informatiesystemen die instaan voor de opslag van data en de transformatie van die data naar informatie zijn derhalve niet meer uit het bedrijfsleven weg te denken (Curtis & Cobham, 2008). Alter (1999) beschrijft een informatiesysteem (IS) als volgt: “Een informatiesysteem is een systeem dat informatie verwerkt door een combinatie van de volgende processen: het vastleggen, doorgeven, opslaan, opvragen, manipuleren en weergeven
van
informatie”.
Sinds
de
intrede
van
de
computer
werden
informatiesystemen alleen maar belangrijker. Ook de intrede van internet en andere nieuwe technologieën hebben ertoe geleid dat informatiesystemen aan belang gewonnen hebben. Dit alles heeft ertoe bijgedragen dat er een groot aanbod is aan verschillende soorten informatiesystemen en aan verschillende applicaties die worden gebruikt in informatiesystemen (Curtis & Cobham, 2008). Ook de vraag naar informatiesystemen werd groter. Volgens Ives en Learnmonth (1984) kunnen de informatiesystemen voor een competitief voordeel zorgen en er zo toe bijdragen dat bedrijven gemakkelijker kunnen overleven in hoge concurrentiële omgevingen en in snel veranderende markten. Zo kunnen ze bijvoorbeeld de kosten doen dalen of helpen om nieuwe producten sneller op de markt te brengen. Op die manier kunnen informatiesystemen een bedrijf winstgevender maken. Informatiesystemen moeten de belangrijkste bedrijfsprocessen en bedrijfsfuncties ondersteunen en dragen er toe 6
bij dat de effectiviteit en efficiëntie van de organisatie verbeteren (Hevner et al. 2004).
Volgens Van Der Meer (2002) bestaan informatiesystemen uit apparatuur, programmatuur, gegevens, mensen en procedures. Computersystemen bestaan eerder uit apparatuur, en eventueel ook gegevens. Informatiesystemen zijn dus meer dan gewoon computersystemen. Het menselijk aspect is ook van belang en mensen die van het informatiesysteem gebruik maken, maken er ook deel van uit.
Figuur II toont de trends die bij informatiesystemen werden vastgesteld. Volgens van der Aalst et al. (2003) bestaan de informatiesystemen uit verschillende lagen. Het centrum bevat de software die de hardware moet doen werken, namelijk het besturingssysteem. De tweede laag bestaat uit de meest algemene applicaties die in verschillende ondernemingen kunnen worden gebruikt. Deze applicaties zijn niet bedrijfsgebonden en worden in veel verschillende bedrijven gebruikt. De derde laag omvat de applicaties die ontwikkeld zijn voor specifieke ondernemingen. De buitenste laag betreft de op maat gemaakte applicaties. In de jaren zestig werden de informatiesystemen vooral gebouwd rond kleinere besturingssystemen met beperkte functionaliteiten. Deze informatiesystemen bestonden vooral uit de zogenaamde op maat gemaakte applicaties. Daarna zijn de tweede en derde laag er bijgekomen en zijn deze lagen in grootte toegenomen. Door het toenemend aantal applicaties bieden de informatiesystemen steeds meer functionaliteiten aan. Dit zorgde voor een trend waarbij de bouw van informatiesystemen niet zozeer meer gaat over het programmeren van de verschillende applicaties maar vooral over het integreren en assembleren van verschillende stukken software uit de vier lagen. Een andere belangrijke
trend
bij
informatiesystemen
is
de
shift
van
datagedreven
informatiesystemen naar procesgedreven informatiesystemen. Op deze trend wordt later nog uitvoerig teruggekomen. De laatste trend volgens van der Aalst et al. (2003) is het dynamischer worden van software. Minder informatiesystemen worden nog vanaf nul opgebouwd. In de plaats daarvan gaat men steeds meer nieuwe applicaties integreren in de bestaande informatiesystemen.
7
Figuur II: Trends in informatiesystemen (van der Aalst et al. 2003)
Het ontwikkelen van een informatiesysteem verloopt in verschillende fasen gaande van systeemonderzoek tot systeemimplementatie (Poels, 2007). In de analysefase wordt een conceptueel model ontwikkeld dat in kaart brengt wat van belang is voor het informatiesysteem en de werkelijkheid zo goed mogelijk weergeeft. Zo zal men bijvoorbeeld van een datamodel vertrekken dat alle noodzakelijke data en de relaties in kaart brengt indien men een datagericht informatiesysteem wil opbouwen. Data - en/of procesmodellen zijn dus de kern bij het ontwikkelen van een informatiesysteem. Modelleren helpt ontdekken wat relevant is en wat niet en zorgt er op die manier voor dat de informatiesystemen niet onnodig complex worden (Giaglis, 2001).
3.1.
Datagerichte informatiesystemen
In de jaren zestig bestonden alle informatiesystemen uit verschillende applicaties. Elk van deze applicaties hadden hun eigen datastructuren en manieren om data op te slaan en op te vragen. In de jaren zeventig werden de data geweerd uit de verschillende applicaties en werden ze apart beheerd (van der Aalst, 1998). Alle gegevens werden in een gemeenschappelijke database opgeslagen en gemanaged. Op deze manier werden inconsistenties en duplicaties tot een minimum herleid. Deze soort informatiesystemen zijn ook veel beter bestand tegen veranderingen van gegevens en zijn een stuk flexibeler.
8
Het managen van de data en de databases vormt derhalve niet langer een onderdeel van de applicaties omdat dit in een afzonderlijk deel van het informatiesysteem gebeurt. Dit deel noemt men het database management systeem (DBMS) (van der Aalst, 1998).
In de jaren zeventig waren de meeste computersystemen bijna uitsluitend verantwoordelijk voor het opslaan en opvragen van data. Deze informatiesystemen waren dan in feite beperkt tot een database management systeem (Levene & Loizou, 1999). Tot de jaren negentig lag de focus van informatiesystemen vooral op het opslaan en opvragen van gegevens en de transformatie van die gegevens tot informatie via allerlei soorten algoritmen en transformatieprocessen. De ontwikkeling van
informatiesystemen
begon
bij
het
maken
van
datamodellen
en
informatiesystemen werden opgebouwd rond de databases (van der Aalst, ter Hofstede & Weske, 2003; Dumas et al. 2005; Curtis & Cobham, 2008). Datagerichte informatiesystemen kunnen worden ingedeeld naargelang het model dat gebruikt wordt en dus het soort databasesysteem dat ontwikkeld wordt. Zo kan een relationeel database management systeem (RDBMS) ontwikkeld worden op basis van een relationeel datamodel of een object oriented database management systeem (OODBMS) op basis van een objectgericht datamodel. Vroeger werden informatiesystemen ontwikkeld aan de hand van relationele datamodellen of andere traditionele datamodellen zoals de hiërarchische datamodellen of de netwerk datamodellen. Tegenwoordig worden OODBMS steeds meer gebruikt omdat de data en de entiteiten steeds complexer werden en de traditionele datamodellen hier toch enigszins te beperkt voor zijn (Dittrich, 1986).
3.2.
Procesbewuste informatiesystemen
Procesbewuste informatiesystemen zijn informatiesystemen waar de focus in de eerste plaats ligt op de bedrijfsprocessen, de activiteiten en hun relaties. Bedrijfsprocessen vormen de basis voor procesbewuste informatieprocessen en worden in de meeste gevallen omschreven als “samenhangende activiteiten die van waarde zijn voor de klanten” (Melão & Pidd, 2000). Een betere en meer omvattende definitie is de volgende: “The specific ordering of work activities across time and
9
place, with a beginning, an end, and a clearly identified input and output” (Davenport, 1993).
Omdat de nadruk in de jaren zeventig en tachtig meer op data lag, werd het softwarematig implementeren van processen in informatiesystemen verspreid over verschillende applicaties. Er was dan geen samenhang tussen de verschillende applicaties en de taken die deze applicaties ondersteunden hadden geen weet van elkaars bestaan. De meeste applicaties die in informatiesystemen gebruikt werden waren dan ook niet procesbewust maar ondersteunden een bepaalde taak. Dumas et al. (2005) geven een text editor als voorbeeld. Deze ondersteunt een bepaalde taak in het proces, maar is zich niet bewust van zijn plaats en functie in dat proces. Een text editor heeft dus in de meeste gevallen geen connectie met de stappen die ervóór of erna komen (van der Aalst W. M., 1999; van der Aalst et al. 2003). Omdat de processen verspreid waren over de verschillende applicaties was dit nefast voor het monitoren en coördineren van het werk over de verschillende stappen en bijgevolg ook voor de controle van de zogenaamde workflow. Ook als de onderliggende
processen
veranderden,
zorgde
dit
voor
de
nodige
aanpassingproblemen (van der Aalst, 1998). Processen werden soms zelf aangepast om te kunnen voldoen aan restricties en beperkingen van de informatiesystemen (Dumas et al. 2005).
In de jaren negentig moesten bedrijven steeds meer producten en diensten aanbieden. Daarnaast is de levensduur van deze producten en diensten aanzienlijk verminderd. Dit heeft ertoe geleid dat er steeds meer processen zijn binnen de bedrijven die niet alleen veel complexer zijn geworden maar daarnaast ook nog eens frequent veranderen (van der Aalst, 1997). De aandacht van informatiesystemen verschoof derhalve van data naar processen. Informatiesystemen werden nu opgebouwd aan de hand van procesmodellen en het beheren van de processen werd meer geïsoleerd in aparte applicaties die zich in de tweede laag van een informatiesysteem bevinden (supra, p.7). Voorbeelden hiervan zijn de zogenaamde workflow management systemen (WfMS), business proces management systemen (BPMS) (van der Aalst et al. 2003; Russell, 2007) en case handling systemen (Weber, Rinderle & Reichert, 2007). Een workflow management systeem moet de flow van werk doorheen de organisatie ondersteunen en toelaten het te managen. 10
Een WfMS ondersteunt met andere woorden niet alleen de individuele taken maar ondersteunt volledige bedrijfsprocessen. Daarnaast behoren ook het controleren, het monitoren en het optimaliseren van die bedrijfsprocessen tot de mogelijkheden van een WfMS (van der Aalst, 1998). Business proces management (BPM) kwam er na de jaren negentig en werd door veel mensen beschouwd als de volgende stap na de opmars van workflow management (WfM). Omdat de fundamenten voor BPM in de jaren ervoor al werden gelegd was het niet echt vernieuwend. Toch is BPM door het samennemen van de fundamenten uit andere methodieken uitgebreider dan workflow management. Zo is er bij BPM meer aandacht voor de diagnose fase. In deze fase worden bedrijfsprocessen geanalyseerd om zo problemen te ontdekken en om zaken te vinden die kunnen verbeteren. Verder is er ook meer ondersteuning voor de simulatie, validate en verificatie van procesontwerpen en betere ondersteuning voor de omgang met real-time data. BPM is gericht op het continu verbeteren van processen (van der Aalst et al. 2003; Verduin, 2006). Case handling systemen maken in tegenstelling tot workflow management systemen en business proces
management
systemen
geen
gebruik
van
voorgedefinieerde
procescontrolestructuren maar zijn gebaseerd op de data als product van de kennisintensieve bedrijfsprocessen (van der Aalst, Mathias & Dolf, 2004). Op case handling systemen wordt later nog uitgebreid teruggekomen (infra p.71).
Processen werden dus net zoals data in de jaren zeventig onttrokken uit de op maat gemaakte applicaties en kunnen zo apart worden gemanaged en geïntegreerd in de informatiesystemen aan de hand van procesmodellen. Op die manier worden het herontwerpen en het uitbreiden van het informatiesysteem, door veranderingen aan de processen, beter ondersteund.
Deze IS worden process-aware information
systems (PAIS) genoemd (Dumas, van der Aalst & ter Hofstede, 2005). Bij een PAIS wordt de opeenvolging van applicaties die het proces voorstellen niet meer geopend of geactiveerd door de voorgaande applicatie maar door het WfMS. Het WfMS ondersteunt met andere woorden de bedrijfsprocessen (van der Aalst, 1999).
Reeds in de jaren zeventig werden de eerste inspanningen geleverd om procesgerichte informatiesystemen te ontwikkelen. De eerste PAIS waren de office information systems op basis van procesmodellen (Zisman, 1977; Ellis, 1979; Holt, 1985). Het doel was om de bureaufuncties te automatiseren en er werden 11
verschillende prototypesystemen ontwikkeld (Russell, 2007). In die tijd was de technologie echter ontoereikend en de netwerken werkten nog te traag. Tevens was er geen uniforme manier om de processen te modelleren en veranderingen te implementeren. Bedrijven waren toen vooral gericht op het optimaliseren van individuele taken in plaats van hele processen. Veel vooruitgang werd er dan ook niet geboekt en de meeste applicaties faalden. Zoals eerder gezegd was het pas in de jaren negentig dat PAIS opnieuw onder de aandacht kwamen en het eerste belangrijke concept in die periode was business process reengineering (BPR) (Hammer, 1990; Hammer & Champy, 1993; Davenport, 1993). Bij BPR gaat men informatiesystemen gebruiken om de processen te herontwikkelen om op die manier verbeteringen aan te brengen op vlak van productiviteit, kwaliteit, kosten en cycle times (Hammer, Champy & Brealey, 2007). Ook de manier waarop bedrijven te werk gingen veranderde op een radicale manier (Revenaugh, 1994). De focus ligt niet langer op de individuele taken maar meer op de connectie en coördinatie tussen de verschillende taken en het beheren van het werk dat doorheen de organisatie stroomt (van der Aalst, 1998). Dit heeft ertoe geleid dat de PAIS veel aan belang hebben gewonnen (van der Aalst & van Hee, 2002; van der Aalst et al. 2003; Dumas et al., 2005).
3.2.1. Enterprise resource planning systemen Een complex soort informatiesystemen zijn de enterprise resource planning (ERP) systemen. Een ERP systeem bevat alle functies en alle departementen van een bedrijf en geeft de onderneming op een eengemaakte manier weer. Alle transacties kunnen worden ingevoerd, opgeslagen, verwerkt, gecontroleerd en gerapporteerd in een ERP systeem (Umble, Haft & Umble, 2003). Een ERP systeem is net als een workflow management systeem een type informatiesysteem dat bedoeld is om de informatie en de processen te integreren in alle gebieden van de organisatie en beiden kunnen worden gebruikt om de processen beter te beheren.
ERP systemen maken onderdeel uit van de process-aware informatiesystemen. Ondank het feit dat de ERP en WfM systemen focussen op de business processen en dezelfde problemen aanpakken, doen ze dit beide op een andere manier. WfM systemen worden gebouwd op basis van een workflow model, terwijl ERP systemen veel meer ontwikkeld worden aan de hand van voorgefabriceerde applicaties waarin 12
het workflow model al ingebed is. Ontwikkelaars hebben echter vaak problemen met het begrijpen van deze ingebedde procesmodellen. Als oplossing hiervoor worden WfM systemen vaak geïntegreerd in de ERP systemen. In tegenstelling tot WfMS die meer procesgericht zijn, zijn ERP systemen datagericht en voorzien ze een gemeenschappelijke data infrastructuur voor de hele organisatie (Cardoso, Bostrom, & Sheth, 2004; Dumas et al. 2005; Russell, 2007).
3.2.2. Voor- en nadelen van procesbewuste informatiesystemen Waar processen vroeger uitsluitend door mensen werden uitgevoerd kunnen ze sinds de intrede van informatiesystemen steeds meer worden geautomatiseerd. (Georgakopoulos, Hornick & Sheth, 1995). Ook vandaag nog zijn er veel processen die alleen door mensen kunnen worden uitgevoerd. Informatiesystemen dienen alsnog vooral om het werk te vergemakkelijken, te ondersteunen en op die manier de werklast te verlichten. Spijtig genoeg ontbreekt het nog steeds aan een standaard om processen te modelleren. Een ander minpunt is dat ondanks het feit dat er al veel workflow management systemen en tools om processen te modelleren in omloop zijn, de meeste applicaties nog steeds gericht zijn op specifieke industrieën zoals
verzekeringen
en
banken.
Desondanks
zorgen
PAIS
voor
nieuwe
opportuniteiten voor de bedrijfsprocessen. Davenport & Short (1990) spreken dan ook van een patroon dat zichzelf herhaalt. Processen en de manier van werken beïnvloeden het ontwerpen van een informatiesysteem en dit biedt op zijn beurt de informatiesystemen die voor nieuwe opportuniteiten voor het bedrijf (Figuur III).
PAIS kunnen van nul worden opgebouwd. Voor de meeste bedrijven is dit echter te duur en wordt er vertrokken van een algemeen proces support systeem zoals een WfMS (Dumas et al. 2005).
13
Figuur III: Verband tussen processen en informatiesystemen (Davenport en Short, 1990)
14
4. Conceptuele modellen Een model is een vereenvoudigde weergave van de complexe realiteit. Modellen zorgen er onder andere voor dat men kan nagaan of het informatiesysteem wel de manier van werken ondersteunt, voldoende flexibel zal zijn, de juiste informatie zal voorzien en een strategisch voordeel zal bieden. Ze laten ook toe te focussen op bepaalde zaken en andere irrelevante details achterwege te laten (Eriksson & Penker, 2000). Conceptuele modellen trachten de werkelijkheid zo goed mogelijk weer te geven in een model. Deze modellen zijn van belang bij het ontwikkelen van informatiesystemen
omdat
ze
de
correctheid,
duidelijkheid,
flexibiliteit
en
productiviteit verzekeren (Halpin, 1998). Het was in de jaren zestig dat werd ingezien dat het bouwen van kwalitatieve conceptuele modellen bij de ontwikkeling van informatiesystemen ervoor zorgt dat fouten vroeger worden gedetecteerd of met andere woorden eerder kunnen worden gecorrigeerd (Wand & Weber, 2002). Het maken van conceptuele modellen draagt er dus toe bij dat informatiesystemen van een betere kwaliteit kunnen worden ontwikkeld (Van Der Meer, 2002). Conceptuele modellen zijn ook gemakkelijk te begrijpen voor mensen zonder kennis van zaken (Halpin, 1998). Mensen die nauw betrokken zijn bij de ontwikkeling van een systeem maar zonder een softwareachtergrond kunnen zich dan ook zonder al te veel problemen mengen in het modelleerdebat. Er kan een onderscheid worden gemaakt tussen datamodellen en procesmodellen. Data– of gegevensmodellen zijn meer gericht op statische fenomenen en beschrijven eerder bepaalde zaken en hun kenmerken. Procesmodellen zijn dynamischer en geven eerder de stroom van werk doorheen het proces, of de manipulatie van bepaalde objecten doorheen het proces weer (Wand & Weber, 2002). Toch is het niet altijd evident om een onderscheid te maken tussen een datamodel en een procesmodel. Het is dan ook niet eenvoudig om de samenhang tussen beiden te formaliseren. Er wordt beweerd dat het onmiddellijk starten met het modelleren van een proces een compleet ander beeld geeft van procesmodellering dan wanneer bij procesmodellering vertrokken wordt vanuit een datamodel (Olle, 1996).
15
4.1.
Conceptuele gegevensmodellen
Conceptuele gegevensmodellen brengen in kaart welke gegevens van belang zijn voor een informatiesysteem en zijn een realistische omschrijving van de structuur van de gegevens die binnen een bepaalde toepassing moeten worden beheerd (Calvanese, Lenzerini & Nardi, 1998). Ze bevatten alle relevante objecten waarover men gegevens wenst te verzamelen en geven een overzicht van de gegevens die men uiteindelijk wil opslaan in een database. Normaal vertrekt men dan ook door na te denken welke data het informatiesysteem moet ondersteunen, welke data de gebruikers en het systeem zullen nodig hebben en bestudeert men de gegevenselementen en hun onderlinge verbanden (Olle, 1996). Centraal bij de ontwikkeling van deze modellen staan dus de gegevens en hun structurele- en gedragskenmerken (Worboys, Hearnshaw & Maguire, 1990). Een datamodel moet de mogelijkheid bieden om de vereisten die een database moet hebben in een model te kunnen gieten en om een structuur aan te brengen die het mogelijk maakt om een DBMS te ontwikkelen (Worboys et al. 1990).
Er zijn talrijke soorten datamodellen beschikbaar zoals bijvoorbeeld EntityRelationship modellen (ERM) (Chen, 1976; Worboys et al. 1990) of Object-Role modellen (ORM) (Blum, 1995; Halpin, 1998). Deze modellen komen hierna ter illustratie kort aan bod.
4.1.1. Entity-Relationship modellen Entity-Relationship (ER) modellen bevatten entiteitstypes zoals bijvoorbeeld ‘Klant’. Dit entiteitstype stelt alle klanten (of verschillende entiteiten) voor en geeft hun attributen of hun eigenschappen weer. In ER modellen worden dus niet de entiteiten getoond maar enkel de entiteitstypes. Daarnaast worden ook de relaties tussen de entiteitstypes weergegeven alsook hun multipliciteiten (Tabel I).
16
Tabel I: Multipliciteiten bij een ER Model
Multipliciteiten
Weergave in ER Model
0 1 0…n 1…n
Deze multipliciteiten geven aan hoeveel connecties er mogelijk zijn tussen de verschillende entiteiten. Zo heeft elke klant één verkoper, maar kan een verkoper geen of meerdere klanten hebben. Figuur IV toont een voorbeeld van een ER data model. De attributen waarbij {PK} (Primary key of primaire sleutel) vermeld staat, dienen om de entiteiten uniek te maken.
Figuur IV: Voorbeeld van een Entity-Relationship datamodel
4.1.2. Object-Role modellen Een tweede datamodel dat hier aan bod komt is een Object-Role model. Als conceptueel model geniet het Object-Role model de voorkeur bij het ontwikkelen van DBMS omdat ER modelleren bepaalde problemen met zich meebrengt. Zo moeten bij de attributen complexe keuzes gemaakt worden, is er weinig 17
ondersteuning bij formele transformaties, staat ERM verder van de natuurlijke taal dan bij Object-Role modelleren, kunnen feiteninstanties niet worden opgenomen, zijn constraints moeilijker uit te drukken en wordt bepaalde informatie over het semantisch domein verborgen gehouden (Halpin, 1998). Object-Role modelleren vermijdt het grootste deel van deze problemen. Bijgevolg is dit type modellen voor de complexe en snel veranderende bedrijven meer aangewezen dan ER modellen.
Bij Object-Role modellering werkt men met objecten en rollen in plaats van entiteiten en relaties (Worboys et al. 1990). Bijgevolg bestaat het model uit objecten. Dit kan enerzijds een entiteitsobject zijn zoals de „Verkoper‟ of anderzijds een value object zoals de naam van de verkoper. Entiteitsobjecten bij Object-Role modellen zijn vergelijkbaar met entiteiten bij Entity-Relationship modellen (Halpin, Business Rules and Object Role Modeling, 1996). De entiteitsobjecten worden op een unieke manier geïdentificeerd door een primary key. De verschillende verkopers uit het object „Verkoper‟ worden bijvoorbeeld geïdentificeerd door hun werknemernummer. In tegenstelling tot ER modellering worden er geen attributen toegevoegd aan het object. Eigenschappen zoals bijvoorbeeld een naam worden aan het object gelinkt via een relatie en worden value objecten genoemd. Dit wordt gedaan omdat de attributen in vele gevallen niet stabiel zijn. Als het attribuut dan bij meerdere entiteiten is opgenomen, komt dit de flexibiliteit niet ten goede. Daarnaast moet men, in tegenstelling tot ER modellen, niet de moeilijke keuze maken of men het attribuut in de entiteit zal opnemen of in een relatie zal weergeven (Halpin, 1996). Figuur V geeft een overzicht van de verschillende symbolen die bij Object-Role modellering worden gebruikt. Objecten in verschillende relaties spelen als het ware een bepaalde rol. Zo kan in figuur VI een klant met een bepaald klantnummer de rol spelen van het plaatsen van een bepaalde bestelling, of de rol van het ontvangen van een levering (Blum, 1995; Halpin, 1998).
Figuur V: Symbolen van een Object-Role model
18
Object-Role modellering wordt soms ook Fact-Based modellering genoemd omdat de belangrijkste data worden geformuleerd als feiten. De kleinste elementen zijn feiten die niet verder kunnen worden opgesplitst zonder informatie te verliezen. Deze feiten en regels worden in een te begrijpen taal gegoten zodat ook niettechnische gebruikers ze gemakkelijk kunnen begrijpen (Halpin, 1996; Halpin, 2009).
Figuur VI: Voorbeeld van een Object-Role model
19
4.2.
Conceptuele procesmodellen
Conceptuele procesmodellen zijn modellen die de bedrijfsprocessen in kaart brengen en zijn vooral gericht op het rangschikken van activiteiten en het coördineren van die activiteiten (Sun et al. 2006). Dergelijke procesmodellen vormen een belangrijk luik in dit werk en worden uitvoerig besproken in het volgende hoofdstuk.
20
5. Procesmodellen Dumas et al. (2005) beschrijven PAIS als volgt: “A software system that manages and executes operational processes involving people, applications, and/or information sources on the basis of process models.” Procesmodellen vormen dus de basis van een PAIS en worden voornamelijk gebruikt bij het ontwikkelen van procesgerichte informatiesystemen. Deze modellen zijn reeds in grote mate beschikbaar (Dumas et al. 2005).
Bedrijven zijn meer geïnteresseerd in wat ze juist doen en hoe ze dat efficiënter kunnen doen. De zoektocht naar meer efficiëntie en automatisatie leidt dan ook naar meer interesse in procesmodellering en bedrijfsprocessen worden steeds meer als corporate assets gezien (Russell, ter Hofstede & van der Aalst, 2007b; Russell & ter Hofstede, 2009;).
Het deel van het informatiesysteem dat instaat voor het managen van de processen wordt het workflow management systeem genoemd, gelijkaardig aan het database management systeem voor data (Figuur VII) (van der Aalst, 1998; Dumas et al. 2005).
Figuur VII: Onderdelen van een informatiesysteem (van der Aalst, 1998)
Workflow modellen die worden gebruikt bij de ontwikkeling van een WfMS, geven alle aspecten van een workflow weer die relevant zijn voor het uitvoeren van die workflow. Een workflow model bevat dus op zijn minst informatie over de taken die moeten worden uitgevoerd, hun relaties, condities die aanzet geven tot die taken, de resources en resource management regels. Workflow modellering begint dan ook 21
vaak met het modelleren van de onderliggende bedrijfsprocessen. Workflow kan bekeken worden vanuit verschillende perspectieven. Dit is nuttig omdat workflow modellering vrij complex is (Oberweis, 2005). Enkele van deze perspectieven zijn het control flow perspectief, het dataperspectief, het resource perspectief, het organisatieperspectief en het business rules perspectief (Russell et al. 2007b). Het control flow perspectief of het procesperspectief beschrijft de taken en activiteiten alsook hun volgorde. Het dataperspectief of objectperspectief beschrijft de businessen procesdata, business documenten en eventueel andere objecten die van activiteit naar activiteit vloeien. Het resource perspectief geeft weer welke middelen de activiteiten nodig hebben. Het organisatieperspectief geeft de organisatiestructuur weer of met andere woorden de individuen en de taken die ze uitvoeren en waarvoor ze verantwoordelijk zijn. Het business rules perspectief geeft het beleid of de regels weer die moeten worden gevolgd in een organisatie onafhankelijk van bepaalde processen (van der Aalst & ter Hofstede, 2005; Oberweis, 2005). Zoals in de inleiding ook al wordt aangegeven (supra, p.1), gaat de meeste aandacht echter nog steeds uit naar het control flow perspectief. Het dataperspectief komt bijgevolg vaak minder aan bod of wordt soms zelf gewoon genegeerd (Sun et al. 2006).
5.1.
Waarom ook data in een procesmodel betrekken?
Door alleen naar het control flow perspectief te kijken en het data- of informatief perspectief te negeren wordt niet naar het volledig plaatje gekeken. Dit kan ertoe leiden dat business actoren meer gaan kijken naar wat moet gedaan worden in plaats van wat kan gedaan worden. Dit belemmert natuurlijk een innovatie van de operaties (van der Aalst et al. 2004). Bijgevolg is de gegevensstroom en dus ook het dataperspectief van belang bij workflow management. Als de gegevensstroom onvoldoende gedefinieerd is, kunnen er later nog onverwachte problemen opduiken. Deze problemen worden veroorzaakt doordat beslissingen die bepalen welke activiteiten moeten worden uitgevoerd, vooral gebaseerd zijn op data (Trcka, van der Aalst & Sidorova, 2008). Hoe eerder problemen en fouten ontdekt worden, hoe meer de kosten om de fouten te herstellen, gereduceerd worden (Moody, 1998). De huidige simulaties die gebruikt worden om gegevensstroomfouten te ontdekken,
22
ontdekken deze fouten pas in een latere fase en zijn dan ook verre van ideaal. Meer aandacht voor het data flow perspectief is derhalve noodzakelijk.
5.2.
Workflow datapatronen
Bij de hiernavolgende bespreking van procesmodellen (infra p.25) zal de nadruk dan ook op het dataperspectief van deze modellen liggen. Russel et al. (2006a) hebben een taalonafhankelijk onderzoek gedaan naar alle mogelijke concepten betreffende de voorstelling en het gebruik van data in workflow systemen. Hierbij werd ook rekening gehouden met de interactie tussen data en andere workflow- en omgevingselementen. Het resultaat was een overzicht van veertig verschillende datapatronen die werden geïdentificeerd en geeft de omvang van workflow data weer. Dit overzicht kan nu worden gebruikt als basis voor vergelijkingen van verschillende workflow management systemen en/of procesmodellen. Deze datapatronen kunnen worden opgedeeld in vier groepen:
-
Data
visibility:
De
manier
waarop
data-elementen
worden
gezien,
gedefinieerd en worden gebruikt door de verschillende componenten in het workflow proces. Een data-element kan bijvoorbeeld worden gebruikt door een bepaalde taak in het proces. -
Data interaction: De manier waarop data word gecommuniceerd door de verschillende componenten in het workflow proces. Er wordt een onderscheid gemaakt tussen een interactie van componenten van hetzelfde workflow systeem (interne interactie) of van een interactie van een component met de externe omgeving (externe interactie). Zo kan een data-element worden doorgegeven van taak tot taak of kan een taak data opvragen uit of doorgeven aan een externe bron.
-
Data transfer: De manier waarop de daadwerkelijke overdracht van data door de verschillende workflow componenten gebeurt. Data kan bijvoorbeeld als een waarde worden doorgegeven aan een component of data kan worden doorgegeven door te verwijzen naar de locatie waar het data-element is opgeslagen.
-
Data-based routing: De manier waarop data elementen de werking van andere workflow componenten beïnvloeden. Zo kan data als pre- of 23
postconditie van een bepaalde taak worden gebruikt, afgaand op de waarde of de aanwezigheid van bijvoorbeeld die data. Tabel II geeft een overzicht van alle datapatronen onderverdeeld per groep. Daarnaast wordt er ook weergegeven welke datapatronen ondersteund worden door een aantal workflow systemen zoals Staffware, Wehshare, FLOWer, COSA, XPDL en BEL4WS. Voor een meer gedetailleerde uiteenzetting van deze patronen kan Russel et al. (2006a) of Russel (2007) worden geraadpleegd.
COSA
XPDL
BPEL4WS
9 10 11 12 13 14
Data Visibilty Task Data Block Data Scope Data Multiple Instance Data Case Data Folder Data Workflow Data Environment Data Data Interaction (intern) between Tasks Block Task to Sub process Sub process to Block Task to Multiple Instance Task from Multiple Instance Task Case to Case
FLOWer
1 2 3 4 5 6 7 8
Patroon
Websphere
Nr
Staffware
Tabel II: Overzicht van de datapatronen die worden ondersteund door workflow systemen (+ ondersteund door het WfMS, - niet ondersteund door het WfMS) (Russell et al. 2006a)
+ +/+/+ +
+/+ + + + +/-
+/+ +/+ + +
+ + + + + +/+
+ + + +/-
+/+ + +
+ + + +/-
+ + + +/-
+ +/+/+ + +/-
+ +/+/+
+ + + +/-
+ +/-
24
5.3.
XPDL
BPEL4WS
34 35 36 37 38 39 40
COSA
27 28 29 30 31 32 33
FLOWer
15 16 17 18 19 20 21 22 23 24 25 26
Patroon Data Interaction (extern) Task to Environment – Push-Oriented Environment to Task – Pull-Oriented Environment to Task – Push-Oriented Task to Environment – Pull-Oriented Case to Environment – Push-Oriented Environment to Case – Pull-Oriented Environment to Case – Push-Oriented Case to Environment – Pull-Oriented Workflow to Environment – Push-Oriented Environment to Workflow – Pull-Oriented Environment to Workflow – Push-Oriented Workflow to Environment – Pull-Oriented Data Transfer by Value – Incoming by Value – Outgoing Copy In/Copy Out by Reference – Unlocked by Reference Locked Data Transformation – Inp. Data Transformation – Outp. Data-Based Routing Task Preconditon – Data Existence Task Precondition – Data Value Task Postcondition – Data Existence Task Postcondition – Data Value Event-based Task Trigger Data-based Task Trigger Data-based Routing
Websphere
Nr
Staffware
Tabel II: Overzicht van de datapatronen die worden ondersteund door workflow systemen (+ ondersteund door het WfMS, - niet ondersteund door het WfMS) (Russell et al. 2006a)
+ + +/+/+/+/+
+/+/+/+/+/+/+/+
+ + +/+/+ + + + -
+ + + + + + +
+ + -
+ + +/+/-
+ +/+/-
+ + -
+/+ +/+/+/-
+/+/+ -
+/+/+/+ -
+ + + +/-
+ + +/+/+ +/-
+ + +/+
+ + + + + + +/-
+ + + + +
+ +
+/+ + +/+
Data flow ondersteuning bij procesmodellen
In wat volgt zal worden nagegaan in hoeverre bepaalde procesmodelleertalen toelaten om de data flow te integreren in het procesmodel. Waar mogelijk zal aangegeven worden welke datapatronen uit tabel II ondersteund worden door de
25
desbetreffende procesmodelleertaal. De modellen die hier aan bod zullen komen zijn de volgende:
1. High level petri nets 2. Business Process Modeling Notation 3. Event-driven Process Chains 4. UML Activiteitsdiagrammen 5. Yet Another Workflow Language
5.4.
High level petri nets
Petri nets werden in de jaren zestig ontwikkeld door Carl Adam (1962). Daarna zijn er enkele uitbreidingen gekomen en werden ze gebruikt om allerlei processen te modelleren. Petri nets zijn een populaire techniek om de control flow te modelleren en oppervlakkig lijken ze zeer sterk op de activiteitsdiagrammen en op event-driven process chains (Eshuis & Wieringa, 2003). Deze laatste zijn erop gebaseerd en komen later nog aan bod. Petri nets hebben naast een instinctieve grafische notatie ook een degelijke mathematische basis (Desel, 2005). Ze zijn geschikt om PAIS te modelleren (Mulyar & van der Aalst, 2005b). Figuur VIII toont een voorbeeld van een klassiek low level petri net model gebaseerd op de basiscase. De petri nets ontwikkeld in de jaren zestig worden ook low level petri nets genoemd en lieten niet toe om bijvoorbeeld data te integreren in het model. Daarom werden deze petri nets uitgebreid met onder andere data, tijd en hiërarchie en werd aan deze uitbreiding de naam high level petri nets gegeven (van der Aalst W. M., 1998). Hierna wordt dieper ingegaan op de uitbreiding met data. De twee andere uitbreidingen liggen buiten het bereik van deze masterproef.
26
Figuur VIII: Voorbeeld van een low level petri net
27
5.4.1. Colored petri nets Het uitbreiden van petri nets met data wordt de uitbreiding met kleur of de colored petri nets (CPN) genoemd. CPN zijn bijzonder geschikt voor het modelleren van grote complexe systemen. De drie basiselementen van petri nets zijn plaatsen, transities en arcs en worden voorgesteld in figuur IX. De nodes in een model zijn ofwel een plaats ofwel een transitie en worden voorgesteld door respectievelijk een cirkel en een rechthoek. Die nodes worden met elkaar verbonden met een arc, welke wordt voorgesteld door een pijl. In het model kunnen twee dezelfde nodes nooit na elkaar komen. Ofwel wordt er van een plaats p naar een transitie t gegaan ofwel van een transitie naar een plaats. In het eerste geval is de plaats een inputplaats van de transitie en spreekt men van een preconditie. Analoog is de plaats in het laatste geval een outputplaats van de transitie en is er sprake van een postconditie.
Figuur IX: Basiselementen van petri nets
Een plaats kan één of meerdere tokens, voorgesteld door een zwarte stip, bevatten (Figuur IX). De waarde van tokens die doorheen het proces vloeien, wordt bepaald door de transities. Die waarde is gebaseerd op de waarde van het token vóór de transitie. Een verandering van toestand of met andere woorden een verandering van plaats van een token gebeurt volgens de firing rule. Een transitie is pas enabled of ingeschakeld als zijn inputplaats tenminste één token bevat. De transitie kan dan een token van die inputplaats consumeren en vervolgens produceert hij een token in elk van zijn outputplaatsen. Dit proces wordt firing genoemd. De tokens uit de low level petri pets zijn in veel gevallen objecten waaraan men eveneens attributen wil toevoegen. Dit lukt echter niet in een low level petri nets model en daarom is men het model gaan uitbreiden met colored tokens. Om een attribuut te kunnen toevoegen bevatten al deze tokens een bepaalde waarde (van der Aalst, 1998; Eshuis & Wieringa, 2003). De naam colored petri nets klopt in feite niet helemaal. Oorspronkelijk was het de bedoeling om een kleur toe te kennen aan de tokens, 28
maar uiteindelijk is men een stap verder gegaan en heeft men data toegekend aan de tokens. Tokens in de high level petri nets modellen bevatten dan ook complexe informatie in tegenstelling tot low level petri nets waarbij slechts één soort teken kan voorkomen dat beschreven is door een integer. Deze tokens kunnen dan ook niet worden onderscheiden van elkaar (Jensen, 1992).
De werking van colored petri nets wordt voorgesteld in figuur X. CPN heeft iedere plaats een bepaald datatype. Dit type kan rechts onderaan worden weergegeven in cursief of zoals in de figuur tussen de volgende spekhaakjes: <…>. Deze plaatsen kunnen dan alleen tokens van dergelijk datatype bevatten. Zo kan de plaats links bovenaan in de figuur alleen maar tokens bevatten met een string en een integer. Het token op die plaats bevat inderdaad een string namelijk „Bestelling1‟ en een integer namelijk „5‟ wat het aantal producten die besteld werden, voorstelt. De plaats aan de rechterkant kan alleen tokens ontvangen met een integer. In dit voorbeeld bevat het token een integer die de prijs van een product voorstelt. Bij high level petri nets kan een plaats dus wel verschillende soorten tokens bevatten waartussen er weldegelijk een onderscheid kan worden gemaakt. Een plaats kan in feite gezien worden als een tijdelijke opslagplaats voor tokens.
Figuur X: Voorbeeld van colored petri nets (Chu-Carroll, 2007)
29
De transitie, in dit geval „Prijs berekenen‟, bevat een aantal condities. De condities aan de ingang bepalen waaraan de tokens moeten voldoen. Er moet dan aan alle condities worden voldaan om een transitie in te schakelen of te enablen. In het geval van het voorbeeld is er voor de transitie „Prijs berekenen‟ een token nodig die bestaat uit een bestellingsnaam b en een aantal onderdelen a. Daarnaast is er eveneens een token nodig die bestaat uit een prijs p. Als dit het geval is, is er aan de condities voldaan en zegt men dat de transitie ingeschakeld of enabled is. Bij het verlaten van een transitie is er een expressie aanwezig om de waarde van een nieuwe token of tokens te berekenen. Een transitie bepaalt dus de waarde van het token die hij produceert. Deze waarde is gebaseerd op de waarde van het token die de transitie consumeert en zo is er derhalve een relatie tussen de geconsumeerde en geproduceerde tokens (Figuur XI). In het voorbeeld bepaalt de expressie dat het nieuw geproduceerde token bestaat uit de naam van de bestelling b en de vermenigvuldiging van het aantal onderdelen a en de prijs p (van der Aalst W, 1998; Mulyar & van der Aalst, 2005a; Chu-Carroll, 2007).
Figuur XI: Voorbeeld van token consumptie (links) en productie (rechts)
De plaats van alle tokens in het model wordt de marking genoemd en stelt de toestand voor van het volledige CPN. Men kan ook spreken over de marking van een plaats en dit zijn dan de tokens die zich op die plaats bevinden. Zo wordt de toestand van een plaats bij low level petri nets bepaald door het aantal tokens op die plaats. Bij high level petri nets is naast het aantal ook het soort token van belang voor het bepalen van de toestand. De initial marking is de initiële staat van het CPN. De transities zorgen ervoor dat de tokens van plaats veranderen en wijzigen bijgevolg de toestand of de marking van het model (Kristensen, Christensen & Jensen, 1998; Desel, 2005).
30
5.4.2. Conclusie De oorspronkelijk low level petri nets schoten te kort op het vlak van data-integratie in het model. De uitbreiding van petri nets, namelijk colored petri nets loste dit probleem op en maakte het mogelijk om datastructuren op te nemen. De tokens die doorheen het petri net vloeien bieden de mogelijkheid om data die doorheen het proces vloeien weer te geven. Petri nets vormen de basis voor enkele van de procesmodellen die hierna aan bod zullen komen en waar ook meer uitgebreid zal worden ingegaan op de datapatronen die ze ondersteunen.
5.5.
Business Process Modeling Notation
Business Process Modeling Notation (BPMN) is tot stand gekomen in 2004. De notatie is speciaal ontwikkeld door het Business Process Management Initiative (BPMI) zodat een model gebaseerd op BPMN gemakkelijk leesbaar en bruikbaar zou zijn voor iedereen die ermee moet werken. De bedoeling was om een gestandaardiseerde notatie te ontwikkelen om processen te modelleren en de beste ideeën uit andere notaties werden dan ook overgenomen (White, 2004; BPMI, 2004). BPMN dient vooral voor de analisten en bedrijfsmensen die het gewoon zijn om om te gaan met bedrijfsprocessen in een flow-chart formaat. De bedrijfsmensen die de processen managen en monitoren kunnen op een robuuste manier hun processen modelleren. De analist zorgt voor een procesmodel waar de belangrijkste zaken in staan. Dit kan worden aangevuld met de technische aspecten door een technisch ontwerper (BPMI, 2004; Verduin, 2006; OMG, 2008; Miers, 2010). BPMN geeft aanzet tot Business Process Management waarbij de nadruk vooral ligt op het verbeteren en optimaliseren van bedrijfsprocessen (Owen & Raj, 2003). In 2006 werd de notatie als standaard aangenomen door de OMG (Object Management Group) (White, 2006). BPMN voorziet een mechanisme om uitvoerbare processen te genereren en de onderliggende semantiek van BPMN helpt bij het omvormen van de bedrijfsprocesmodellen naar uitvoerbare modellen die door workflow engines kunnen worden begrepen (Miers, 2010). Zo kan een BPMN model worden omgevormd tot de Business Process Execution Language (BPEL). Op basis van deze scriptaal kan een workflow engine het procesmodel uitvoeren. BPMN wordt derhalve ook gebruikt door ontwikkelaars van applicaties om BPMN om te vormen naar BPEL en op die manier
31
de technologie die de processen zal uitvoeren, te kunnen implementeren. Op die manier tracht BPMN de kloof tussen proces design en procesimplementatie te dichten (Wohed et al. 2006; Verduin, 2006). 5.5.1. BPMN Op basis van BPMN wordt er een Business Process Diagram (BPD) gemaakt. Het BPMN model bevat 4 categorieën van constructen, namelijk flow objecten, connectieobjecten, swimlanes en artefacten. Flow objecten kunnen events, activiteiten of gateways zijn. Connectieobjecten zorgen voor de connectie tussen verschillende objecten. Swimlanes groeperen activiteiten. Daarnaast heb je ook artefacten zoals data objecten, group en annotation. Figuur XII geeft een overzicht van enkele symbolen gebruikt bij BPMN.
Figuur XII: BPMN constructen
Procesmodellen zijn ontwikkeld om bedrijfsprocessen in kaart te brengen. Zoals eerder
vermeld,
zijn
de
meeste
modellen
echter
vooral
gericht
op
de
goederenstroom en het integreren van de gegevensstroom bleek vaak een probleem te zijn. BPMN slaagt hier beter in en geeft aldus voldoende aandacht voor de gegevensstroom (Verduin, 2006). Zo geven de messages flows of information flows de boodschappen weer tussen de verschillende deelnemers van het proces. Dit ontbrak in de meeste traditionele procesmodellen (Lonjon, 2004). Daarnaast kunnen met een association (één van de connectieobjecten) ook dataobjecten gaan gelinkt 32
worden aan een activiteit. Deze dataobjecten tonen aan welke data de processen nodig hebben, of welke data ze produceren (White, 2004). Aan deze dataobjecten kan de toestand van het dataobject worden toegevoegd. Dit gebeurt door de toestand tussen vierkante haakjes onder de naam weer te geven. Naast de toestand kunnen er optioneel ook eigenschappen worden toegevoegd aan een dataobject (OMG, 2008).
Figuur XIII toont een voorbeeld van een BPD. Dit is gebaseerd op het linkerpad van het basismodel maar werd aangepast met een kleine uitbreiding. Een klant stuurt een bestelling door naar een bedrijf. Na het ontvangen en het verwerken van de bestelling kan er een factuur worden opgemaakt en opgestuurd. Bij het verwerken van de bestelling kan er eventueel een nieuwe klant worden toegevoegd. Het doorsturen van de bestelling en van de factuur wordt weergegeven met een message flow. Daarnaast wordt er aan de hand van de dataobjecten ‘Bestelling’, ‘Klant’ en ‘Factuur’ en associaties aangetoond welke gegevens er nodig zijn bij welke activiteiten. De richting van de associaties duidt aan of het een input of een output betreft.
Figuur XIII: Voorbeeld van een Business Process Diagram
33
In tegenstelling tot het basismodel wordt hier wel gebruik gemaakt van een formele modelleertaal. Uit dit procesmodel kan dan ook veel meer worden afgeleid dan uit het basismodel. Aan de hand van bijvoorbeeld connectieobjecten, kan bij BPMN onderscheid worden gemaakt tussen connecties naar verschillende constructen. Daarnaast zijn er ook dataobjecten opgenomen in het BPD en kan er een onderscheidt gemaakt worden tussen AND splitsingen en XOR splitsingen. In dit BPD wordt er in tegenstelling tot het basismodel ook onderscheid gemaakt tussen de verschillende deelnemers van het proces.
BPMN is geen
data
flow
language
en
is
niet
geschikt om
data- en
informatiemodellen te maken. Toch biedt BPMN biedt de mogelijkheid om data en gegevensstromen weer te geven in een procesmodel (BPMI, 2004). Het simuleren, het monitoren of het ontwikkelen van bedrijfsprocessen wordt een stuk vergemakkelijkt door het kunnen maken van gedetailleerde en complexe procesmodellen (zur Muehlen & Recker, 2008; OMG, 2009). Het toevoegen van dataobjecten is optioneel. Ze voegen extra informatie toe aan het model. De dataobjecten komen overeen met entiteitstypes uit de relationele datamodellen of met klassen uit object oriented datamodellen (Owen & Raj, 2003).
5.5.2. Datapatronen ondersteund door BPMN Wohed et al. (2006) hebben onderzocht welke datapatronen ondersteund worden door BPMN en concludeerden dat dit het geval was voor ongeveer de helft van de datapatronen. Voorbeelden van datapatronen die niet worden ondersteund zijn workflow en environment datapatronen en data-interacties van en naar een taak met multiple instances. Tabel II geeft een compleet overzicht van de datapatronen die ondersteund worden door BPMN.
34
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Patroon Data Visibilty Task Data Block Data Scope Data Multiple Instance Data Case Data Folder Data Workflow Data Environment Data Data Interaction (intern) between Tasks Block Task to Sub process Sub process to Block Task to Multiple Instance Task from Multiple Instance Task Case to Case Data Interaction (extern) Task to Env. – Push-Oriented Env. to Task – Pull-Oriented Env. to Task – Push-Oriented Task to Env. – Pull-Oriented Case to Env. – Push-Oriented Env. to Case – Pull-Oriented
+ + +/+ + + + + + + + -
Nr 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Patroon Data Interaction (vervolg) Env. to Case – Push-Oriented Case to Env. – Pull-Oriented Workflow to Env. – Push-Oriented Env. to Workflow – Pull-Oriented Env. to Workflow – Push-Oriented Workflow to Env. – Pull-Oriented Data Transfer by Value – Incoming by Value – Outgoing Copy In/Copy Out by Reference – Unlocked by Reference Locked Data Transformation – Inp. Data Transformation – Outp. Data-Based Routing Task Precond. – Data Existence Task Precond. – Data Value Task Postcond. – Data Existence Task Postcond. – Data Value Event-based Task Trigger Data-based Task Trigger Data-based Routing
BPMN
Nr
BPMN
Table II: Overzicht van de datapatronen die worden ondersteund door BPMN (+ ondersteund door BPMN, - niet ondersteund door BPMN) (Wohed et al., 2006)
+ + +/+ +/+/+ + + + +
Er kan geconcludeerd worden dat bij BPMN data veel minder aandacht krijgen dan processen. Zo wordt de data-interactie maar beperkt ondersteund. Het feit dat dataobjecten een onderdeel zijn van de artefacten die slechts een uitbreiding zijn van de belangrijkste set van constructen gebruikt bij BPMN is volgens Magnani en Montesi (2007) een aanwijzing dat data niet genoeg aandacht krijgt.
5.5.3. BPMN 2.0 Sommige problemen of tekortkomingen waar BPMN nog mee te kampen had, worden momenteel aangepakt en men is nu volop bezig met het ontwikkelen van Business Process Modeling Notation 2.0 (BPMN 2.0). BPMN 2.0 is een stuk uitgebreider dan BPMN en heeft dan ook meer aandacht voor de data flow. Toch 35
biedt deze nieuwe versie van BPMN nog steeds geen model aan om de structuur van de data weer te geven. Desondanks zijn er mogelijkheden om extern gedefinieerde datastructuren en andere talen te integreren in een model. Het is ook mogelijk om verschillende talen en datastructuren naast elkaar te gebruiken in BPMN 2.0 (OMG, 2009; Jørgensen, 2010).
In BPMN 2.0 zijn er vijf soorten data-elementen: dataobjecten, data input, data output, data stores en properties (Figuur XIV).
Figuur XIV: Data-elementen van BPMN 2.0 (OMG, 2009)
Dataobjecten vormen eigenlijk de basis bij het modelleren van gegevens. Een dataobject kan ofwel één datavoorkomen aanduiden, of het kan een collectie of een groep van data weergeven. Omdat dataobjecten door processen gemanipuleerd en gewijzigd worden, doorlopen ze een levenscyclus. Deze cyclus hangt bijgevolg af van de processen of subprocessen waarmee de dataobjecten verbonden zijn. Ook hier kan de toestand van het dataobject worden weergegeven onder de naam van het dataobject. Soms zijn data noodzakelijk opdat activiteiten en processen zouden kunnen werken. In andere gevallen produceren ze data als gevolg van hun functioneren. Dit wordt weergegeven in het model door respectievelijk data inputs en data outputs. Enerzijds kunnen processen en hun activiteiten data opvragen die buiten het bereik van dat proces liggen door de data op te vragen uit een data store. Anderzijds kunnen processen ook data opslaan in een data store. Properties zijn gelijkaardig aan dataobjecten maar ze hangen eerder vast aan elementen zoals processen, activiteiten en events dan dat ze als een apart element getoond worden in het Business Process Diagram. De levenscyclus van een property hangt af van het element waarmee hij verbonden is. Een property kan dus alleen maar bestaan
36
als het element waarmee hij verbonden is, tot leven is geroepen. Een property is ook enkel toegankelijk via het element waarmee hij verbonden is.
De link tussen enerzijds data, input en output objecten en anderzijds processen en activiteiten wordt weergeven door data-associaties. Deze associaties hebben een richting en hebben als gevolg daarvan bronnen en doelen. Als de associatie wordt uitgevoerd, dan worden de data van de bron naar het doel gekopieerd. Vaak gaat dit gepaard met een transformatie van de data. Als er geen transformatie is tijdens het kopiëren dan is er meestal maar één bron en wordt de data van deze bron zuiver gekopieerd naar het doel. Via associaties kunnen dataobjecten gelinkt worden aan processen als input of output. Daarnaast kunnen deze dataobjecten ook gelinkt worden aan een sequence flow waarbij de richting van deze associaties wordt weergegeven door middel van deze sequence flow.
5.5.4. Conclusie BPMN kan niet gebruikt worden om een datamodel te beschrijven. Toch biedt BPMN de mogelijkheid om de data flow in een model te integreren. Maar de mogelijkheden om informatie op de nemen in het model zijn veel beperkter dan de mogelijkheden om processen te modelleren. Zo zijn bij BPMN vooral de ondersteuning van BPMN voor data visibility en data-interactie beperkt. De vernieuwde versie van BPMN, namelijk BPMN 2.0 biedt op vlak van data-integratie in het procesmodel meer mogelijkheden. Zo zijn er nu verschillende soorten dataobjecten en kan nu een data store worden toegevoegd aan het model.
5.6.
Event-driven process chains
De event-driven process chain (EPC) werden in 1992 ontwikkeld. De EPCs die hier aan bod zullen komen zijn de uitgebreide versie of de zogenaamde extended eventdriven process chain (eEPC). De EPCs werden uitgebreid om ook data, resources, tijd en waarschijnlijkheden te ondersteunen (van Hee, Oanea & Sidorova, 2005). Omdat deze versie ook de basisversie bevat, wordt in wat volgt geen onderscheid gemaakt tussen de uitgebreide en de klassieke versie. Als vanaf nu over EPC gesproken wordt, wordt hiermee de uitgebreide versie bedoeld. EPC is gebaseerd
37
op petri nets (supra p26) en is ook zeer gelijkaardig aan UML activiteitsdiagrammen die hierna aan bod komen (infra p.45) (Korherr & List, 2006).
5.6.1. EPCs binnen het ARIS framework EPC is ontwikkeld binnen het framework van de Architecture of Integrated Information System (=ARIS) en is bedoeld om gemakkelijk te zijn in gebruik en om gemakkelijk te begrijpen. Het ARIS concept verdeelt complexe processen onder in verschillende perspectieven die zowel onderling als in verband kunnen gebruikt worden (Korherr & List, 2006). Zo heeft men de keuze tussen een organisatie- , een controle -, een functioneel- , een output- of een informatieperspectief om een model te maken. Het modelleren van verschillende perspectieven heeft wel bepaalde voordelen maar om het volledige bedrijfsproces te gaan modelleren moeten de verschillende perspectieven gecombineerd worden. Daartoe moet er echter één perspectief als basis worden gekozen. Omdat het functioneel perspectief het dichtst in de buurt komt van het bedrijfsproces wordt dit meestal als basisperspectief gekozen (Scheer, Thomas & Adam, 2005).
5.6.2. De basiselementen van een EPC De basiselementen van een EPC zijn de functies, de events, en de logical operators. Figuur XV toont de bijhorende symbolen van de basiselementen.
Figuur XV: Basiselementen van een EPC
De functies van een EPC geven de activiteiten weer in een proces. Een event beschrijft een bepaalde toestand in een proces. De events worden ook meestal naar een object genoemd aangezien objecten worden verwerkt door processen. Onrechtstreeks geven ze dus vaak een toestand van een object terug, zoals bijvoorbeeld een dataobject. 38
Naast de hierboven omschreven basiselementen heeft EPC nog een categorie elementen beschikbaar, namelijk de objecten. Ze zijn zeer uitgebreid. Er zijn immers tot 150 objecten beschikbaar. Ze kunnen onder andere gebruikt worden om de data flow in een proces te modelleren. De categorieën objecten die meest interessant zijn voor de data flow zijn de data, de information carriers en de knowlegde objecten. EPC biedt via deze objecten de mogelijkheid om de data flow te integreren in het model. 5.6.3. Dataobjecten Data kunnen op twee manieren worden gemodelleerd. De eerste manier is het modelleren vanuit het bedrijfsperspectief. Het is een minder formele manier en hiervoor worden technical term objecten gebruikt. Daarnaast is er ook een formele manier. Hierbij gebruikt men clusters, entiteitstypes en attribuut objecten. De laatste manier voldoet meer aan de data modelleer standaarden. Figuur XVI stelt de dataobjecten van een EPC model voor.
Figuur XVI: Dataobjecten van een EPC (Davis & Brabänder, 2007)
Naargelang de modelleerwijze kan er dus gebruik gemaakt worden van verschillende dataobjecten. Een technical term is een stuk bedrijfsinformatie. Een entiteitstype is hetzelfde zoals bij een ER model, zoals bijvoorbeeld een klant of een bestelling. Een entiteitstype kan attributen zoals bijvoorbeeld een klantnaam of een bestelnummer bevatten. De entiteitstypes en de attributen komen dus overeen met entiteiten en attributen in een ER Model (Korherr & List, 2006). Een cluster is een verzameling van entiteitstypes die in verband staan met elkaar. Tussen clusters en entiteitstypes is er in het model derhalve geen directe link.
Het formeel modelleren van data in EPC is gelijkaardig aan ER modelleren. Daarom is het goed om formeel te gaan modelleren als men reeds data heeft gemodelleerd in een datamodel. Naast een ER model kan ook een class diagram gebruikt worden 39
om de data op een objectgerichte manier te modelleren. Als er op voorhand nog geen datamodel is gemaakt, kunnen de technical term objecten gebruikt worden. Bij het formeel modelleren worden er verschillende objecten gebruikt om de entiteiten, clusters en attributen voor te stellen. Technical term objecten zijn veel minder strikt en gebruiken voor entiteiten, clusters en attributen hetzelfde object. In figuur XVII wordt rechts met formele objecten de entiteit „Klant‟ voorgesteld met zijn attributen „Klantnummer‟ en „Naam‟. Links worden hetzelfde voorgesteld maar met technical term objecten.
Figuur XVII: Vergelijking tussen technical term objecten (links) en formele dataobjecten (rechts) (Davis & Brabänder, 2007)
In een eerste fase kunnen de databenodigdheden als technical term objecten in het model opgenomen worden en pas in een latere fase vervangen worden door formele dataobjecten. Vaak worden technical term objecten en formele dataobjecten samen gebruikt in een model. De input van een functie kan dan bijvoorbeeld de minder formele technical term objecten zijn en de output de striktere formele dataobjecten. Hierbij wordt nog eens extra benadrukt dat de processen of in dit geval de functies de data transformeren en ze dus waardevoller gaat maken. De transformatie van data wordt voorgesteld in figuur XVIII.
Figuur XVIII: Transformatie van data (Davis & Brabänder, 2007)
De connectie tussen een dataobject en een functie is een input connectie. Hierbij wordt het dataobject gelezen. Omgekeerd spreekt men over een output connectie en 40
kan het dataobject worden gecreëerd, geüpdate of gedelete door middel van een functie. Informatieobjecten duiden aan welke data de functies als input of als output hebben.
Zolang er consistentie is in het model, kan men vrij kiezen welk niveau van detail er gebruikt wordt. Ofwel kunnen enkel entiteitstypes worden getoond in het model ofwel kunnen eveneens de attributen worden getoond om duidelijk te maken welke attributen een functie transformeren. Het model kan dus op een meer gedetailleerde manier worden weergegeven, met het verband tussen functies en attributen, of meer algemeen, met het verband tussen functies en data clusters (Loos & Thomas, 1998; Davis & Brabänder, 2007).
5.6.4. Information carrier object Data worden altijd ergens opgeslagen. Gegevens kunnen elektronisch worden opgeslagen, maar dit kan evengoed op een niet-elektronische manier gebeuren (uitprinten, brief). Er is slechts één object dat deze opslag voorstelt en dat is een information carrier object (Figuur XIX). Daar waar dataobjecten de gegevens zelf voorstellen, stellen de information carrier objecten de plaats voor waar deze gegevens worden opgeslagen.
Figuur XIX: Information carrier object
Toch bestaan er vele varianten van dit object (Figuur XX). Deze varianten stellen de verschillende soorten opslagmedia voor. Voorbeelden hiervan zijn een fax, een brief of een telefoon.
41
Figuur XX: Alternatieve weergaven van een information carrier object (Davis & Brabänder, 2007)
In hun relatie met de functie kunnen de information carrier objecten een input voorzien of een output creëren. De relaties tussen een dataobject en een information carrier object is een “ligt op” relatie. Bepaalde data voorgesteld door dataobjecten worden opgeslagen of liggen op een bepaalde plaats voorgesteld door een information
carrier
object.
Een
bestelling
ligt
bijvoorbeeld
op
een
bestellingsdatabase.
Bepaalde information carrier objecten zoals een telefoon zorgen meestal niet voor gestructureerde data. Normaal wordt hier dan ook enkel het information carrier object weergegeven als input object voor een functie in plaats van samen met het dataobject. Dit is het geval in figuur XXI bij de functie „Bestelling maken, plaatsen en verwerken‟ en het information carrier object „Telefoon‟.
Figuur XXI geeft de EPC versie weer van een deel van de basiscase. In vergelijking met het basismodel kunnen hier ook de attributen worden weergegeven van de dataelementen en wordt er onderscheid gemaakt tussen de data en hun opslagplaats. Daarnaast is het in dit model ook mogelijk om een onderscheid te maken tussen gestructureerde en ongestructureerde data. Bovendien zijn de connecties tussen de dataconstructen en de functies talrijker aanwezig omdat er hier zowel de output als
42
input relaties zijn weergegeven. Derhalve is de data flow in het EPC model veel beter weergegeven dan in het basismodel.
Figuur XXI: Voorbeeld van een event-driven process chain
5.6.5. Knowlegde object Met knowlegde objecten kan alle kennis die iemand moet hebben om een bepaalde taak uit te voeren, in het model worden opgenomen. Uiteraard is het opnemen van alle kennis niet aan te raden omdat het model zeer onduidelijk zou worden. Daarom is het beter om alleen de zeer specifieke kennis nodig om een bepaalde taak uit te
43
voeren, in het model op te nemen. Hiervoor gebruikt men het knowledge category object (Figuur XXII).
Figuur XXII: Knowlegde objecten van een EPC model
Naast een knowledge category object kan men ook gebruik maken van een documented knowlegde object. Dit is geschreven kennis die noodzakelijk is om het kunnen uitvoeren van een bepaalde taak. Een documented knowlegde object is in feite vergelijkbaar met data die worden opgeslagen in een information carrier. Het verschil is dat men een documented knowlegde object meer gaat gebruiken als de structuur van het document niet echt van belang is en als de informatie niet wordt getransformeerd door een functie. Eigenlijk moet men zich afvragen of de gegevens zullen worden opgeslagen in een database. Is dit het geval, dan is het beter om het te gaan modelleren als data die in een information carrier worden opgeslagen in plaats van als een documented knowlegde object (Davis & Brabänder, 2007).
5.6.6. Conclusie Bij event driven process chains zijn er verschillende objecten voorhanden om data in een procesmodel te modelleren. Samengevat zijn er drie soorten “data” die in een model kunnen opgenomen worden aan de hand van verschillende objecten. Zo zijn er de data zelf (entiteiten en attributen), welke gestructureerd is en getransformeerd wordt door een functie. Daarnaast is er ook informatie (technical term object) die ongestructureerd is en eveneens wordt getransformeerd door een functie. Ten slotte is er de knowlegde (knowlegde objecten) die niet gestructureerd is en die ook niet wordt getransformeerd door een functie (Davis & Brabänder, 2007). Door deze objecten met een verschillende structuur is het mogelijk om de structuur van de data weer te geven in het model. Verder kunnen ook de attributen van de data-elementen worden toegevoegd in het model en de opslagplaats van data. Ook de relaties tussen deze data-elementen, hun opslagplaats en de functies kunnen in een EPC model worden weergegeven. 44
5.7.
UML Activiteitsdiagram
Activiteitsdiagrammen (AD) zijn een onderdeel van de Unified Modeling Language (UML). UML is een modelleertaal die helpt om modellen voor informatiesystemen te omschrijven,
te
visualiseren
en
te
documenteren
(OMG,
2005).
Activiteitsdiagrammen worden gebruikt om een proces te modelleren. De versie van UML die hier zal worden besproken is UML 2.0. Daar waar de 1.4 versie nog gebaseerd was op state charts is de 2.0 versie gebaseerd op petri nets. Activiteitsdiagrammen zijn vooral gericht op het control flow perspectief (Eshuis & Wieringa, 2003).
5.7.1. Elementen van een UML activiteitsdiagram Activiteiten vormen de basis van een activiteitsdiagram en duiden op het gecoördineerd uitvoeren van acties. Acties worden in het model voorgesteld als rechthoeken met afgeronde hoeken en worden actie nodes genoemd (Figuur XXIII). Ze wijzen op de taken die tijdens het proces worden uitgevoerd. Acties zijn in staat data te manipuleren, te testen en te transformeren. Ze worden gecoördineerd door control flow edges of object flow edges die in het model worden voorgesteld als een pijl. Het verschil tussen de twee edges ligt hem in het gebruik ervan. Control flow edges worden gebruikt om twee acties met elkaar te verbinden en object flow edges worden gebruikt om de input en output van die acties met elkaar te verbinden. De edges duiden op de verbanden tussen en de volgorde van de verschillende acties. Het geheel van acties en edges stelt een flow voor. Control waarden en datawaarden vloeien langs die edges en worden door de nodes getransformeerd, worden aan een bepaalde route meegegeven of worden tijdelijk opgeslagen. Deze control waarden en datawaarden worden voorgesteld door de tokens. Tokens kunnen dus control tokens zijn en stellen een control waarde voor, maar ze kunnen ook data waarden voorstellen. In het laatste geval worden ze object tokens of data tokens genoemd. Tokens vloeien langs de edges doorheen het proces (Figuur XXIII). Een bepaalde actie kan maar worden uitgevoerd als alle voorgaande acties een token bevatten (Bell, 2003; Engels et al. 2005).
45
Figuur XXIII: Voorbeeld van een token flow bij UML 2.0 activiteitsdiagrammen (Dumas et al., 2005)
5.7.2. Data flow van een UML activiteitsdiagram
Activiteitsdiagrammen bieden de mogelijkheid om de object flow en derhalve ook data in het model op te nemen. Object nodes en flows kunnen in het model geïntegreerd worden in combinatie met de acties. Object nodes worden gebruikt om objecten op een specifieke plaats in het proces weer te geven. Een object node wordt in het model voorgesteld door een rechthoek. De naam van het object wordt onderlijnd. Indien nodig kan ook de toestand van het object worden toegevoegd. Deze toestand wordt tussen vierkante haakjes onder de naam geplaatst en toegevoegd aan een object omdat deze vaak een transformatie ondergaat doorheen het proces. Het toevoegen van objecten is optioneel en is in de eerste plaats informatief. Er zijn vier soorten object nodes namelijk pins, central buffer nodes, data store nodes en activity parameter nodes (Figuur XXIV) (Bell, 2003; Engels et al., 2005).
46
Figuur XXIV: De vier mogelijke object nodes uit UML 2.0 AD (Bock, 2003)
Pins vormen de eerste soort object nodes. De input of output van een actie worden weergegeven door respectievelijk input en output pins (Figuur XXV.A). Dergelijke pins worden weergegeven als vierkanten en worden aan een actie gelinkt. Hun type wordt boven of onder het vierkant geschreven. De twee pins in figuur XXV.A zijn verbonden met een object flow edge. Figuur XXV.B toont de schematische voorstelling van een stand alone notatie van de pins. Deze notatie kan worden gebruikt als de output en input pins die verbonden zijn, hetzelfde type hebben (Bell, 2003; Engels, et al. 2005).
Figuur XXV: A) Input en output pins B) Stand alone notatie (Engels et al., 2005)
Een tweede object node, de central buffer node, vormt een buffer voor de verschillende input en output flows. Een central buffer node wordt altijd verbonden met object nodes maar nooit met acties of activiteiten. Object tokens kunnen zo in een central buffer node nog eens extra worden gequeued en de input en output flow wordt derhalve gemanaged door deze central buffer nodes (Bell, 2003; Engels et al., 2005).
47
Data store nodes zijn een speciaal soort central buffer nodes. In tegenstelling tot deze central buffer nodes worden de tokens die binnenkomen in een data store node, daar gehouden en kunnen niet worden verwijderd. De tokens worden enkel verwijderd als de activiteit beëindigd is. Als een token een object bevat die al aanwezig is in de data store dan wordt het oude token vervangen (Bell, 2003; OMG, 2004; Engels et al., 2005).
Activiteiten bestaan uit verschillende acties. Een activiteit wordt geïnitieerd door het inroepen van een actie. Figuur XXVI geeft de voorstelling van een activiteit weer. Activity parameter nodes vormen de laatste soort object nodes en dienen om data in en uit de activiteit te voeren. Er zijn twee soorten activity parameters, namelijk input en output parameters. Deze parameters zijn ook object nodes maar zijn niet hetzelfde als pins. Ze worden wel verbonden via een object flow edge naar die pins en worden weergegeven op de rand van de activiteiten. Als de activiteit in figuur XXVI wordt geactiveerd, wordt er een token op de initiële node (zwarte stip) geplaatst. Daarnaast wordt er ook een data token geplaatst op de twee input parameter nodes. Het token op de initiële node wordt gekopieerd en gaat naar actie 1 en actie 2. Op hetzelfde moment gaan ook de data tokens naar actie 1 en 2. Vervolgens gaat een token van actie 2 naar actie 3 waarna een data token naar de output parameter vloeit. De andere tokens gaan ondertussen naar de finale node en uiteindelijk stopt de activiteit (Bell, 2003; Engels et al., 2005).
48
Figuur XXVI: Voorbeeld van een activiteit met activity parameter nodes (Bock, 2003)
Object tokens worden zoals eerder vermeld gebruikt om de object flow weer te geven in het model. De object tokens gaan via de object flow edges van de ene object node naar de andere en verwijzen naar een bepaald object. Soms hebben die edges waarlangs de tokens vloeien een bepaald type. In dit geval kan deze object node alleen maar object tokens accepteren van hetzelfde type. Als een token binnenkomt via een ingaande edge wordt het onmiddellijk doorgegeven via een uitgaande edge. Als een node echter meer dan één uitgaande edge heeft, zullen de nodes die erna komen concurreren voor het token aangezien dit token in deze situatie slechts één pad mag volgen. Dit kan gebeuren aan de hand van een bepaalde conditie, zoniet wordt op een non-deterministische manier bepaald welke edge het token zal volgen. Als de object tokens naar meer dan één node moet worden doorgegeven of als met andere woorden het token moet worden gedupliceerd, kan men gebruik maken van een fork node zoals het voorbeeld in figuur XXVI. Een fork node duidt immers aan dat alle parallelle paden simultaan moeten worden gevolgd. Indien er geen gebruik wordt gemaakt van een fork node mag slechts één pad worden gevolgd (Bell, 2003; Engels et al., 2005).
Object tokens kunnen ook tijdelijk worden bijgehouden als geen van de nodes die erna komt klaar is om de tokens te ontvangen. Deze tokens worden daarna in 49
dezelfde volgorde terug doorgegeven. Verder is het ook mogelijk om naast de standaard FIFO (First In, First Out) een andere queue order te gebruiken zoals bijvoorbeeld LIFO (Last In, First Out). Dit wordt een selectie genoemd en kan worden toegevoegd aan een object node of aan een edge. Het aantal tokens dat kan worden opgeslagen, kan worden beperkt door een upper bound toe te voegen aan een object node. Dergelijke upper bound laat een maximaal aantal tokens toe. Figuur XXVII stelt zowel een selectie als een upper bound voor. Daarnaast is het mogelijk om multipliciteiten toe te voegen aan object nodes (Bell, 2003; Engels et al., 2005).
Figuur XXVII: Voorbeeld van een upper bound en een selectie (Engels et al., 2005)
Tenslotte kunnen ook pre- of postcondities toegevoegd worden aan een actie (Figuur XXVIII). Bij de start van een actie moet een preconditie eerst worden goedgekeurd vooraleer de actie kan worden uitgevoerd. Bij het einde van een actie moet aan de postconditie voldaan zijn vooraleer een activiteit kan worden afgerond. Toch wordt er bij UML nauwelijks bepaald wat er moet gebeuren indien niet aan de condities voldaan is (Bell, 2003; Engels et al., 2005).
Figuur XXVIII: Voorbeeld van een pre- en postconditie van een actie (Bell, 2003)
50
5.7.3. Uitgewerkt voorbeeld van een UML activiteitsdiagram In wat volgt wordt de data flow in het UML 2.0 activiteitsdiagram uitgelegd aan de hand van een voorbeeld, dat een uitwerking is van de basiscase. De uitleg is gebaseerd op het werk van Engels et al. (2005). Figuur XXIX geeft het voorbeeld van het UML activiteitsdiagram schematisch weer. Bij de start van het proces wordt de bestelling eerst aangemaakt, daarna geplaatst en tenslotte verwerkt. Al deze acties hebben gemeenschappelijke inputs en outputs. Dit betekent dat de stand alone versie van de output en input pins, zoals in figuur XXV.B gebruikt kan worden. Bij de start van het proces komt er een token binnen dat naar de eerste activiteit wordt geleid en zal zo verder vloeien doorheen het proces. Wanneer er bij het verwerken van de bestelling problemen opduiken zullen de bestellingen worden verworpen. Dit is echter een exception of uitzondering, en wordt aangeduid door middel van een driehoekje. Na het verwerken van de bestelling, is het bestellingsobject nodig in alle vier de parallelle paden die leiden naar de vier objecten „Factuur aanmaken‟, „Productieorder aanmaken‟, „Bestelling opslaan‟ en „Benodigdheden controleren‟. Hier kan dus een fork node gebruikt worden die het object token zal kopiëren en via de vier paden naar de corresponderende objecten zal leiden. In vergelijking met de basiscase is hier een extra pad toegevoegd om de bestellingen op te slaan. Hiervoor wordt een data store node gebruikt. Bij het ophalen van de onderdelen wordt een speciaal soort pin gebruikt, namelijk een streaming pin (zwart gekleurd vierkant). De reden hiervoor is dat bij het ophalen van een eerste onderdeel de output pin zou worden gevuld met een „Onderdeel‟ token. In normale omstandigheden zou de actie hier stoppen. Omdat er echter meerdere onderdelen nodig zijn maakt men hier gebruik van een streaming pin en gaat de actie verder tot er voor alle “onderdeel” objecten die moeten worden opgehaald een „Onderdeel‟ token is voorzien. Andere soorten pins die kunnen voorkomen zijn parameter sets die een groep van parameters weergeven en value pins die een bepaalde constante waarde moeten verschaffen aan een actie. Bij het testen van de onderdelen worden er geen streaming pins gebruikt omdat er onderdeel per onderdeel wordt getest en elk onderdeel afzonderlijk voor de test moet slagen. Omdat er een verschil is tussen de tests van de onderdelen type X of Y wordt er gebruikt gemaakt van een decision node. Na de tests komen de onderdelen samen en in het model wordt dit weergegeven door een central buffer node. Om ervoor te 51
zorgen dat de assemblage pas kan beginnen als alle onderdelen beschikbaar zijn wordt er een weight expressie gebruikt. Deze bepaalt hoeveel tokens er op hetzelfde moment de egde moeten passeren. In dit geval zorgt de weight expressie ervoor dat de actie assemblage niet kan beginnen vooraleer alle onderdeel tokens beschikbaar zijn in het central buffer.
Ook dit UML 2.0 activiteitsdiagram heeft meer uitdrukkingskracht dan het basismodel. Door al dan niet gebruik te maken van een control node kan er bijvoorbeeld onderscheid gemaakt worden tussen XOR en AND splitsingen. Daarnaast wordt door gebruik te maken van de object nodes, de data flow meer uitgebreid weergegeven.
Figuur XXIX. Uitgewerkt voorbeeld van een activiteitsdiagram (Engels et al., 2005)
52
Figuur XXIX: Uitgewerkt voorbeeld van een activiteitsdiagram (Engels et al., 2005)
53
5.7.4. Datapatronen ondersteund door UML 2.0 activiteitsdiagrammen Tabel IV toont een overzicht van alle datapatronen die worden ondersteund door UML 2.0 activiteitsdiagrammen. Voor een meer uitgebreide uitleg kan worden verwezen naar het werk van Russel et al. (2006b).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Patroon Data Visibilty Task Data Block Data Scope Data Multiple Instance Data Case Data Folder Data Workflow Data Environment Data Data Interaction (intern) between Tasks Block Task to Sub process Sub process to Block Task to Multiple Instance Task from Multiple Instance Task Case to Case Data Interaction (extern) Task to Env. – Push-Oriented Env. to Task – Pull-Oriented Env. to Task – Push-Oriented Task to Env. – Pull-Oriented Case to Env. – Push-Oriented Env. to Case – Pull-Oriented
+/+ + + + + + + + -
Nr 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Patroon Data Interaction (vervolg) Env. to Case – Push-Oriented Case to Env. – Pull-Oriented Workflow to Env. – Push-Oriented Env. to Workflow – Pull-Oriented Env. to Workflow – Push-Oriented Workflow to Env. – Pull-Oriented Data Transfer by Value – Incoming by Value – Outgoing Copy In/Copy Out by Reference – Unlocked by Reference Locked Data Transformation – Inp. Data Transformation – Outp. Data-Based Routing Task Precond. – Data Existence Task Precond. – Data Value Task Postcond. – Data Existence Task Postcond. – Data Value Event-based Task Trigger Data-based Task Trigger Data-based Routing
UML AD
Nr
UML AD
Tabel IV. Overzicht van de datapatronen die worden ondersteund door UML 2.0 activiteitsdiagrammen (+ ondersteund door AD, - niet ondersteund door AD) (Russell et al., 2006b)
+ + + + + + + + +
Algemeen kan worden gesteld dat de datapatronen vrij goed worden ondersteund. Russel et al. (2006b) hebben wel een aantal opmerkingen. Door zoals bij petri nets gebruik te maken van tokens voor data en control flow zijn er kleine verschillen met andere workflow modellen. Zo worden de tokens echt geconsumeerd en maakt dit het soms moeilijk om gegevens uit te wisselen met concurrerende activiteiten. Door gebruik te maken van deze tokens wordt de interne data-interactie zeer goed 54
ondersteund. Bijna alle patronen van de interne data-interactie worden dan ook ondersteund. Activiteitsdiagrammen hebben echter geen aandacht voor externe data-interacties. Dit kan eventueel worden opgelost door een combinatie met andere UML modellen, maar hier is toch enige voorzichtigheid geboden.
5.7.5. Conclusie UML 2.0 activiteitsdiagrammen zijn geschikt om de data die doorheen het proces vloeien, weer te geven. Zo zijn er vier verschillende object nodes die in combinatie met object tokens de data flow doorheen het proces kunnen weergeven. Toch zijn ook hier nog enkele gebreken op vlak van de ondersteuning van de workflow datapatronen. Zo wordt de interne data-interactie wel goed ondersteund, aandacht voor externe data-interacties is er evenwel niet. Scope, case en folder data worden niet ondersteund door UML 2.0 activiteitsdiagrammen evenals het transfereren van data tussen proceselementen als waarden.
5.8.
Yet Another Workflow Language
Yet Another Workflow Language (YAWL) bouwt verder op petri nets, maar ondersteunt meer workflow processen (van der Aalst & ter Hofstede, 2005). Het was aanvankelijk vooral gericht op de control flow (Ouyang, 2005) en YAWL ondersteunt het dataperspectief dan ook totaal niet. Alleen bij de implementatie van YAWL wordt het dataperspectief in beperkte mate ondersteund, maar dit is ontoereikend. 5.8.1. newYAWL Opdat YAWL ook de data flow zou ondersteunen was een uitbreiding nodig. De nieuwe uitgebreide versie van YAWL heet newYAWL en ondersteunt naast het dataperspectief ook het resource perspectief en meer workflow patronen. newYAWL wordt gezien als een referentietaal voor PAIS (Russell et al., 2007a). Figuur XXX geeft een overzicht van enkele constructen gebruikt in het newYAWL model zoals een conditie, een taak en enkele varianten daarop.
55
Figuur XXX: Basisconstructen van newYAWL
De taken zijn gelijkaardig als de transities in petri nets. Toch kunnen de taken hier direct met elkaar verbonden worden in tegenstelling tot petri nets. Figuur XXXI toont een voorbeeld van een newYAWL model gebaseerd op een deel van de basiscase. Door de mogelijkheid om van taken AND, XOR of OR split taken of AND, XOR of OR join
taken
te
maken,
heeft
dit
op
zich
eenvoudig
procesmodel
meer
uitdrukkingskracht dan het basismodel.
Figuur XXXI: Een voorbeeld van een newYAWL model
De data zijn opgenomen in het model maar worden niet weergegeven. Om data te integreren in het control flow perspectief maakt newYAWL gebruik van dataelementen of variabelen. Door formele parameters te gebruiken worden de dataelementen uitgewisseld door de verschillende procescomponenten. newYAWL laat ook toe om specifieke logische condities toe te voegen die aangeven of een proces mag beginnen of eindigen (pre - en postcondities) of linkcondities die bepalen welke takken geactiveerd moeten worden bij OR of XOR splits (Russell, 2007; Russell et al., 2007a; Russell et al., 2007b). 56
5.8.2. Data-elementen ondersteuning newYAWL biedt verschillende mogelijkheden aan om data te integreren. Er wordt onderscheid gemaakt tussen acht verschillende doelen die met data-elementen kunnen worden verbonden. Op die manier kan het gebruik en de zichtbaarheid van de data-elementen worden beperkt. De verschillende doelen zijn de volgende (Russell, 2007; Russell et al., 2007a; Russell et al., 2007b).
-
Externe variabelen: Variabelen die gedefinieerd zijn binnen de operationele omgeving maar die buiten de omgeving vallen
-
Folder variabelen: Variabelen die beschikbaar zijn voor één of meer processen
-
Global variabelen: Variabelen die beschikbaar zijn voor alle elementen van alle procesvoorkomens
-
Case variabelen: Variabelen die beschikbaar zijn voor alle elementen van één procesvoorkomen
-
Block variabelen: Variabelen die beschikbaar zijn voor alle elementen van een proces of subproces
-
Scope variabelen: Variabelen die beschikbaar zijn voor een subset van de elementen in een specifieke top-level proces of subproces definitie voor een bepaald procesvoorkomen
-
Task variabelen: Variabelen die gebonden zijn aan een specifieke taak
-
Multiple Instance variabelen: Variabelen die gebonden zijn aan een specifiek voorkomen of aan een meervoudig taakvoorkomen
5.8.3. Data-interactie ondersteuning Voor
het
transfereren
van
data-elementen
tussen
de
verschillende
procescomponenten worden formele parameters gebruikt. De parameters worden gecodeerd en in een parameter mapping geplaatst. Een voorbeeld van dergelijke parameter is de volgende:
parameter input-vars mapping-function output-vars direction participation
57
Dergelijke parameters kunnen worden geassocieerd met een taak, een blok of een proces. De direction of richting van een parameter bepaalt of het om een input of een output parameter gaat. Een input parameter dient om data in te geven in een element waaraan de parameter gebonden is. Een output parameter dient om data uit een element te doen vloeien. Parameters worden altijd geëvalueerd. Bij de evaluatie van een input parameter gaat men als volgt te werk. De bepaalde mapping functie wordt opgeroepen met de waarden van de input variabele en het resultaat wordt gekopieerd naar de output variabele. Figuur XXXII toont een voorbeeld van een evaluatie van een input parameter. De input variabele die via de misplit functie wordt opgeroepen is in dit geval de klantgegevens. De waarden van die klantgegevens worden gekopieerd naar de output variabele. Bij een output parameter gaat men omgekeerd te werk en worden de waarden gekopieerd naar de input variabele. Bij een multiple instance taak wordt het resultaat in tabelvorm geleverd omdat men hier te maken heeft met meerdere variabelen en meerdere taak instanties.
Figuur XXXII: Voorbeeld van een evaluatie van een input parameter (Russell et al., 2007a)
58
Participation van de parameter bepaalt of die parameter optioneel is of verplicht. Bij een verplichte parameter moet de evaluatie van de parameter een bepaald resultaat hebben. Bij een onbepaald resultaat zal het construct waarmee de input of de output parameter verbonden is, worden tegengehouden om respectievelijk te beginnen of te voltooien (Russell, 2007; Russell et al., 2007a; Russell et al., 2007b).
5.8.4. Linkcondities Linkcondities bepalen welke branches of takken er moeten worden geactiveerd bij OR of XOR splits. Een voorbeeld van dergelijke linkconditie wordt hieronder gegeven:
link condition link-function input-variables
De waarden van de input variabelen worden geëvalueerd door de linkfunctie waaraan deze waarden werden doorgegeven. Op deze manier wordt bepaald via welke link de control flow verder gaat. Bij een OR split worden alle linkcondities van elke tak geëvalueerd en bij iedere link met een positieve evaluatie wordt de bijhorende tak geactiveerd. Als er geen enkele conditie “true” is dan maakt men gebruik van een default link die op voorhand werd bepaald. Bij een XOR split gaat men bij de eerste positieve linkconditie de bijhorende tak activeren. Er wordt dan ook een volgorde bepaald voor het evalueren van de link condities. Indien er geen enkele positief is, dan maakt men ook hier gebruik van een default link (Russell, 2007; Russell et al., 2007a; Russell et al., 2007b).
5.8.5. Pre- en postcondities Pre – en postcondities hebben dezelfde vorm als linkcondities. De condities worden geëvalueerd bij de start of het einde van een taak of processen en alleen als de evaluatie “true” is, kan de taak of het proces waarmee de conditie geassocieerd is, beginnen of eindigen (Russell, 2007; Russell et al., 2007a; Russell et al., 2007b).
59
5.8.6. Locks newYAWL laat ook toe om data-elementen te specificeren die een taak exclusief nodig heeft om te beginnen. Als de taak wordt uitgevoerd dan kan ze exclusief gebruik maken van dit data-element. Dit wordt een lock genoemd. Als de taak voltooid is wordt de lock terug opgegeven en kunnen andere taken terug gebruik maken van dit data-element. De locks zijn geregistreerd in de lock register plaats (Russell, 2007; Russell et al., 2007a; Russell et al., 2007b).
5.8.7. Datapatronen ondersteund door YAWL en newYAWL Tabel V toont een overzicht van de datapatronen die worden ondersteund door YAWL en newYAWL. De dataondersteuning in YAWL is gebaseerd op variabelen die aan de hand van XQuery statements worden doorgegeven van en naar taken. Hierbij wordt vooral de externe data-interactie en de data-based routing niet ondersteund door YAWL. newYAWL daarentegen ondersteunt bijna alle workflow datapatronen. Enkel de datatransfers door referentie worden maar deels ondersteund. newYAWL biedt wel de mogelijkheid om data te locken. Dit komt echter niet voor onder dezelfde vorm als gedefinieerd bij de workflow datapatronen. Bijgevolg wordt dit patroon maar deels ondersteund (Russell et al., 2007a).
1.1.1. Conclusie newYAWL is een enorme verbetering ten opzichte van YAWL op het gebied van datapatroonondersteuning. newYAWL ondersteunt dan ook bijna alle workflow datapatronen met uitzondering van data transfer by reference. newYAWL ondersteunt derhalve ook complexe datastructuren. newYAWL maakt gebruik van formele parameters om de data-elementen door verschillende procescomponenten uit te wisselen. Daarnaast kunnen er ook pre - en postcondities worden toegevoegd aan de taken of linkcondities die bepalen welke takken er geactiveerd moeten worden. Data-elementen kunnen ook exclusief worden gebruikt door een taak door middel van een lock.
60
+ + -
+ + + + + + + +
+ + + + + -
+ + + + + +
-
+ + + + + +
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Patroon Data Interaction (vervolg) Env. to Case – Push-Oriented Case to Env. – Pull-Oriented Workflow to Env. – Push-Oriented Env. to Workflow – Pull-Oriented Env. to Workflow – Push-Oriented Workflow to Env. – Pull-Oriented Data Transfer by Value – Incoming by Value – Outgoing Copy In/Copy Out by Reference – Unlocked by Reference Locked Data Transformation – Inp. Data Transformation – Outp. Data-Based Routing Task Precond. – Data Existence Task Precond. – Data Value Task Postcond. – Data Existence Task Postcond. – Data Value Event-based Task Trigger Data-based Task Trigger Data-based Routing
newYAWL
Data Visibilty Task Data Block Data Scope Data Multiple Instance Data Case Data Folder Data Workflow Data Environment Data Data Interaction (intern) between Tasks Block Task to Sub process Sub process to Block Task to Multiple Instance Task from Multiple Instance Task Case to Case Data Interaction (extern) Task to Env. – Push-Oriented Env. to Task – Pull-Oriented Env. to Task – Push-Oriented Task to Env. – Pull-Oriented Case to Env. – Push-Oriented Env. to Case – Pull-Oriented
Nr
YAWL
Patroon
newYAWL
YAWL
Tabel V: Data patronen die worden ondersteund door YAWL en newYAWL (+ ondersteund door YAWL/newYAWL, - niet ondersteund door YAWL/newYAWL) (Russell et al., 2007a)
-
+ + + + + +
+ + + +
+ + + +/+ +
+
+ + + + + + +
61
2. Gegevensmodellering informatiesystemen
bij
procesbewuste
Hoewel het beheer en het behandelen van data in principe een belangrijk aspect is van procesmodellen, wordt hier toch lang niet voldoende aandacht aan besteed en werd het managen van data vooral overgelaten aan onderliggende systemen (van der Aalst et al., 2003). De meeste procesmodelleertalen waren in het begin dan ook vooral control flow gericht. Toch hebben activiteiten data nodig als input of ze produceren data als output. Ook worden er data gebruikt bij het nemen van automatische control flow beslissingen. Het is dan ook eigenaardig dat het dataperspectief slechts beperkte aandacht kreeg bij WfMS. Recent is er daar echter verandering in gekomen met onder meer het onderzoek naar workflow datapatronen en de interesse in de datamanagement aspecten bij workflow systemen is toegenomen (Eder & Lehmann, 2007). Naast het opnemen van de data flow in de procesmodellen bestaan er talrijke andere concepten en technieken om data te integreren in workflow systemen. De concepten en methoden die in deze masterproef aan bod komen zijn:
-
Product Based Workflow Design en Support
-
Case Handling
-
Information centric business process modeling
-
Data-Driven Process Structures
-
Document-Process Association Model
-
Data Acces Plug-ins en XML based data acces
2.1.
Product Based Workflow Design
Product Based Workflow Design (PBWD) is een techniek om procesmodellen te ontwikkelen op basis van een productstructuur zoals bijvoorbeeld een Bill Of Material (BOM). Het model van een productstructuur wordt in PBWD een product data model (PDM) genoemd. Dit model kan handmatig of op een automatische manier worden omgevormd naar een procesmodel (Vanderfeesten et al. 2008b). PBWD wordt vooral toegepast om processen te herdefiniëren en te verbeteren. Dit gebeurt door
62
terug van nul te beginnen en naar de workflow te kijken vanuit een ander standpunt (Vanderfeesten, van der Aalst, & Reijers, 2005; Vanderfeesten et al., 2008c).
2.1.1. Product Data Model Een workflow
management systeem
wordt
geacht
om
de processen
te
ondersteunen. Maar in principe zijn het niet de processen die het belangrijkste zijn maar de output of het product van deze processen. Een productgebaseerde benadering die vooral op de output gericht is, is dus beter. De output of het product kan worden gedefinieerd aan de hand van de Bill Of Material of met andere woorden door de componenten van het product. Deze BOM geeft weer welke materialen er nodig zijn om een bepaald product te produceren. Figuur XXXIII illustreert een voorbeeld van een BOM. De BOM heeft een boomstructuur en geeft van onder naar boven de verschillende materialen die nodig zijn om een product te maken alsook het eigenlijke product.
Figuur XXXIII: Voorbeeld van een bill of material voor productieprocessen
PBWD is vooral ontwikkeld voor administratieve of informatie-intensieve processen terwijl een BOM eerder gebruikt wordt voor productieprocessen. Bijgevolg moeten er een aantal aanpassingen worden gemaakt om een model te ontwikkelen dat de productstructuur weergeeft voor informatie-intensieve processen. Zo kan informatie
63
zeer gemakkelijk worden gekopieerd en kan eenzelfde stukje informatie voor verschillende soorten andere informatie zorgen. In tegenstelling tot de BOM bij productieprocessen moeten er geen fysische objecten worden geassembleerd, maar gaat het hier om data-elementen die moeten worden verwerkt om zo nieuwe data te creëren. Informatie-intensieve processen hebben meestal verschillende manieren om tot hetzelfde eindproduct te komen. Bij productieprocessen is dit veel minder het geval door bepaalde fysische beperkingen. Zo kan informatie bijvoorbeeld gemakkelijk worden gekopieerd. Een boomachtige structuur is in dit geval dus niet noodzakelijk (Vanderfeesten et al., 2008c).
Het analyseren van de producten en materialen leidt tot het identificeren van de data-elementen en hun relaties. Een beschrijving van een productstructuur bij een informatiegericht proces net zoals een BOM bij een productieproces wordt een product data model genoemd. Het geproduceerd product van een product data model is dus informatie (Reijers, Liman, & van der Aalst, 2003; Vanderfeesten, et al., 2008b).
Het gebruik van een product data model heeft als voordeel dat alle data-elementen en productieregels kunnen worden verantwoord tegenover dit product. Dit heeft als gevolg dat er geen overbodige stappen meer zijn in het proces, dat informatie maar éénmalig zal worden geregistreerd en dat er kan worden nagegaan welke datamanipulatie in het proces kan worden geautomatiseerd. Een ander voordeel is dat het ordenen van de taken is gebaseerd op prestatiegerichte doelstellingen en op de strategie van een bedrijf. De processen voeren op die manier uit wat vandaag van belang is voor de organisatie in tegenstelling tot het uitvoeren van willekeurige updates zoals in het verleden gebeurde (Vanderfeesten et al., 2008c).
Een product data model beschrijft de meest elementaire deeltjes in een workflow proces en geeft weer welke data en informatie er moet worden geproduceerd. De stukken data in een PDM worden data-elementen of informatie-elementen genoemd. Voorbeelden zijn de naam van een klant, het recht op korting en een BTW-nummer. Deze data-elementen worden als cirkels weergegeven in het PDM. Op deze elementen gaat men operaties uitvoeren welke worden voorgesteld door middel van pijlen. Ze vormen de basis en geven de verbanden weer tussen de data-elementen. 64
Een activiteit kan bestaan uit meerdere operaties. Operaties kunnen dus geen halfafgewerkte producten produceren, terwijl activiteiten dit wel kunnen. Soms kunnen er alternatieve paden worden gevolgd om tot een product te komen. Dit is een zogenaamde eXclusive OR-constructie (XOR). In andere gevallen zijn alle paden noodzakelijk en zijn alle inputs noodzakelijk. Dit is een AND–construction. Figuur XXXIV.A toont een voorbeeld weer van een AND constructie en figuur XXXIV.B van een XOR constructie (Reijers & Vanderfeesten, 2004; Vanderfeesten et al., 2005).
Figuur XXXIV: Voorbeeld van een A) AND en een B) XOR conditie uit een product data model
Figuur XXXV geeft een voorbeeld van een PDM. Hier is het de bedoeling om de totale prijs te berekenen van een bepaalde bestelling. Daarvoor heeft men de normale prijzen nodig van de bestelde producten en moet nagegaan worden of de klant recht heeft op een korting. De korting kan worden berekend op de basis van verkoopsgegevens van het jaar voordien alsook op basis van de relatie met de klant. Als de klant in hetzelfde jaar al eens een bestelling heeft gedaan, dan is het kortingspercentage waarop hij dit jaar recht heeft, al berekend en hoeft dit niet opnieuw te gebeuren.
65
Figuur XXXV: Voorbeeld van een product data model
2.1.2. Product Based Workflow Design In de industrie zijn de product data modellen over het algemeen een stuk groter dan het voorbeeld dat hierboven wordt beschreven. Ze kunnen zelfs tot honderden dataelementen bevatten. Van deze product datamodellen kunnen nu procesmodellen ontwikkeld worden. Dit gebeurt door de data-elementen en de operaties te groeperen in activiteiten. Dit groeperen moet op een slimme manier gebeuren, rekening houdend met bepaalde beperkingen en vereisten (Vanderfeesten, Reijers & van der Aalst, 2008a).
Hierna volgt een voorbeeld van een procesmodel gebouwd op basis van een product data model. Dit voorbeeld is gebaseerd op het model beschreven door van der Aalst (1997). Het procesmodel is een petri net model (supra p.26). Ter illustratie zal slechts een deel van figuur XXXV worden omgebouwd (Figuur XXXVI).
66
Figuur XXXVI: Deel van PDM uit figuur XXXV
Om een korting te berekenen zijn de volgende zaken vereist: de gegevens omtrent het volume dat vorig jaar werd besteld, de totale verkopen van een klant van het jaar ervoor en de relatie met de klant. Het berekenen van de korting kan evenwel overbodig zijn als een klant eerder dit jaar reeds een bestelling heeft geplaatst. In dit geval kan hetzelfde kortingspercentage van die eerdere bestelling gebruikt worden. Als men de korting wil berekenen, begint alles met het voorbereiden van het berekenen van de korting. „Voorbereiden korting‟ is derhalve de eerste transitie in het petri net model in figuur XXXVII. Deze transitie zorgt ervoor dat de korting zal berekend worden en de nodige activiteiten geactiveerd zullen worden. De korting wordt berekend via informatie over de verkopen, het volume en de relatie. Dit wordt in het petri net model weergegeven door de transitie „Volume, verkopen, relatie‟. De korting kan eveneens worden overgenomen van eerdere bestellingen dat jaar waarbij de korting al eens berekend was. Hierbij is de informatie omtrent de verkopen, het volume en de relaties met de klant overbodig. Dit wordt in het petri net model weergegeven door de transitie „Overslaan volume, verkopen, relatie‟.
67
Figuur XXXVII: petri net model gemaakt op basis van een product data model
In figuur XXXVI is er buiten „Korting‟ geen andere component aanwezig met inkomende pijlen. Indien dit wel het geval zou zijn, kan er voor die component ook een petri net model worden gemaakt. Op die manier kan een volledig petri net model worden gecreëerd. Men begint dus bovenaan bij de top van het product data model en gaat zo verder tot er van alle componenten een petri net model is gemaakt (van der Aalst, 1997).
Figuur XXXVIII geeft een schematisch overzicht van de manier waarop PBWD werkt. In de analysefase wordt het product geanalyseerd en op die manier kunnen de verschillende data-elementen en hun relaties worden onderscheiden. Daarna worden deze data-elementen en de operaties in een PDM gebracht. Het ordenen van activiteiten komt hier nog niet aan bod. Van dit PDM wordt dan een procesmodel ontwikkeld rekening houdend met de gekozen strategie en performance goals. Op basis van dit procesmodel kan er een WfMS worden ontwikkeld die de bedrijfsprocessen ondersteunt (van der Aalst W. M., 1999; Reijers et al., 2003; Vanderfeesten et al., 2008c).
68
Figuur XXXVIII: Schematisch overzicht van PBWD (Vanderfeesten et al., 2008c)
2.1.3. Product Based Workflow Support Bij PBWD wordt een product data model ontwikkeld. Hier wordt dan handmatig of automatisch een procesmodel uit gegenereerd. Vooral de handmatige manier is nogal tijdsconsumerend. Daarnaast is het niet gemakkelijk om een procesmodel te ontwikkelen op basis van een product data model en gaat er tijdens dit proces veel flexibiliteit verloren. Daarom kwam het idee om processen automatisch te ondersteunen op basis van de productstructuur. Hierbij wordt dus niet eerst een procesmodel ontwikkeld. Dit concept heet Product Based Workflow Support (PBWS) (Vanderfeesten et al., 2008c). Het is een methode om de PDM direct uit te voeren en op die een manier dynamische en flexibele ondersteuning te kunnen voorzien voor processen.
Bij PBWS worden voor elke processtap alle data-elementen verzameld. Tijdens het uitvoeren van de processen gaat men op basis van alle verzamelde informatie het product en de strategie van wat de beste volgende stap is bepalen. De volgende activiteit die moet worden uitgevoerd wordt dus niet bepaald aan de hand van het vooropgesteld procesmodel. Het uitvoeren van een PDM hangt ook af van de gekozen strategie of van de performance goals. Als die strategie verandert, zal het model moeten worden herzien. Hierbij kan de workflow solution eventueel veranderen, maar het product data model zelf blijft hetzelfde bij een nieuwe strategie (Vanderfeesten et al., 2008c).
De werkwijze om een product data model uit te voeren, wordt hierna beschreven. De uitleg is gebaseerd op het werk van Vanderfeesten et al. (2008c). Als in figuur 69
XXXIX alle elementen in het blauw aanwezig zijn, zal de korting berekend worden aan de hand van de productie, het volume en de relatie met de klant. Indien zoals in figuur XL ook informatie aanwezig is omtrent een vorige bestelling, dan zal de korting op een andere manier berekend worden.
Figuur XXXIX: Uitvoeren van een product data model pad 1
Figuur XL: Uitvoeren van een product data model pad 2
In een PDM zijn er meestal verschillende paden beschikbaar om tot hetzelfde eindproduct te komen. Toch zal er altijd maar één pad de voorkeur krijgen. Welk pad uiteindelijk wordt gekozen, hangt af van de performance goals voor dat proces. Het is duidelijk dat in het voorbeeld hierboven voor snelheid wordt gekozen. Indien alle 70
informatie beschikbaar is dan zal worden gekozen voor het snelste pad namelijk het pad via eerdere bestellingen dit jaar. Naast het snelste pad kan bijvoorbeeld ook het pad met de minste kosten of het kwalitatief meest hoogstaande pad de voorkeur genieten (Vanderfeesten et al., 2008b; Vanderfeesten et al., 2008c).
2.1.4. Conclusie Product Based Workflow Design legt de focus op het product en ontwikkelt procesmodellen op basis van een productstructuur. Het wordt vooral gebruikt om bedrijfsprocessen te herontwikkelen en te verbeteren. Voordelen van PBWD zijn het kunnen verantwoorden van data-elementen en productieregels tegenover het product. Daarnaast worden de taken gerangschikt volgens een bepaalde strategie en perfomance goals of met andere woorden wat vandaag van belang is voor het bedrijf. Omdat het tijdrovend is om een procesmodel te ontwikkelen op basis van een PDM en er veel flexibiliteit verloren gaat, kwam het idee om processen automatisch te ondersteunen op basis van de productstructuur. Dit concept heet Product Based Workflow Support en zorgt voor een dynamische en flexibele ondersteuning van de bedrijfsprocessen.
2.2.
Case Handling systemen
Omdat traditionele workflow systemen vooral activiteitsgericht zijn, zijn ze niet zo flexibel. Als eventuele oplossing hiervoor werd er een nieuw systeem ontwikkeld, namelijk het Case Handling Systeem. Een voorbeeld van een dergelijk case handling systeem is FLOWer.
Case handling is veel beter in het omgaan met flexibele en/of informatie-intensieve processen. Het is dan ook veel meer data gericht dan traditionele workflow systemen. Case handling probeert de volgende problemen die bij normale workflow systemen voorkomen op te lossen: -
In een workflow systeem worden activiteiten eigenlijk beschouwd als de kleinste onderdelen. Maar in realiteit kunnen de activiteiten nog verder worden opgesplitst.
-
Enkel het werk waarvoor een bepaalde gebruiker geautoriseerd is, is zichtbaar voor deze gebruiker. Bovendien kunnen ze ook enkel dit werk 71
uitvoeren waarvoor ze geautoriseerd zijn. De autorisatie en distributie van werk vallen dus samen bij traditionele workflow systemen. -
Omdat bij traditionele workflow systemen de nadruk teveel op de control flow ligt en de data daardoor wat verdrongen worden, krijgt men alleen maar informatie te zien die nodig is om een bepaalde taak uit te voeren in plaats van alle informatie die met de case te maken heeft.
-
Bij traditionele workflow systemen ligt de focus op wat moet gedaan worden in plaats van wat kan gedaan worden.
Deze problemen leiden ertoe dat workflow management systemen inefficiënt en onvoldoende flexibel zijn en dat er zelfs fouten kunnen optreden. Omdat men ook steeds met een deel van het proces te maken heeft en er bijgevolg geen overzicht omtrent alle voorhanden informatie ter beschikking is, is het moeilijk om beslissingen te nemen.
Case handling biedt een antwoord op al deze problemen. Dit gebeurt op de volgende manier: -
Het voorzien van alle informatie die beschikbaar is
-
De volgende activiteit gaan bepalen op basis van de informatie die beschikbaar is in plaats van op basis van voorgaande activiteiten
-
Het splitsen van de distributie en de autorisatie van het werk
-
Het mogelijk maken om informatie aan te passen vóór en na een activiteit
Van der Aalst et al. (2004) zijn van oordeel dat case handling een goede balans biedt tussen de datagerichte systemen uit de jaren tachtig en de procesgerichte systemen uit de jaren negentig. Data en processen worden dan ook beiden als even belangrijk beschouwd.
Case handling bepaald volgende stap in het proces aan de hand van alle beschikbare informatie, in tegenstelling tot traditionele WfMS waar de volgende activiteit bepaald wordt aan de hand van de activiteiten die ervoor kwamen. Hieruit blijkt ook nog eens dat de data en de processen beide zeer belangrijk zijn bij case handling (Limburg et al., 2002; van der Aalst et al., 2004).
72
2.2.1. Case handling In tegenstelling tot andere workflow systemen zijn het niet de activiteiten die centraal staan bij case handling maar de cases. Een case is in feite een product dat wordt geproduceerd en is gebaseerd op data. Activiteiten die worden uitgevoerd dienen louter om de case te behandelen. Een case handling systeem gaat dan ook veel meer assisteren in plaats van in een bepaalde richting te sturen. Een ander verschil is dat een activiteit bij case handling gewoon een stuk werk is dat kan verricht worden. Dit is minder strikt dan bij andere workflow systemen waar een activiteit ondeelbaar is en ofwel niet ofwel volledig moet worden uitgevoerd. De cases doorlopen wel nog steeds een proces, maar een vaste routing van een case wordt zoveel mogelijk beperkt. De precedence relations die de voorrang en volgorde van de activiteiten bepalen worden bij case handling tot een minimum herleid. Op die manier is er meer vrijheid voor de gebruikers van het systeem. Daarom is het belangrijk dat de gebruikers zicht hebben op de volledige case en dat alle relevante informatie beschikbaar is.
Een case wordt gezien als een product met een structuur en een toestand. Deze worden weergegeven door middel van een collectie van dataobjecten. Een dataobject kan al dan niet aanwezig zijn, maar als het aanwezig is, dan moet het een bepaalde waarde hebben. De toestand van een case wordt dus niet bepaald door de control flow maar door de aanwezigheid van dataobjecten. Dit is het grootste verschil met andere workflow systemen en wordt ook nog eens geïllustreerd aan de hand van de volgende uitspraak (van der Aalst et al., 2004): “Case handling is also driven by data flow instead of exclusively by control flow.”
Dataobjecten worden in een form weergegeven. Deze forms zijn louter een manier om dataobjecten voor te stellen. Activiteiten kunnen worden gelinkt aan dergelijke forms om op die manier de meest relevante data te kunnen weergeven. Dataobjecten zijn dus verbonden met een proces. Dataobjecten kunnen mandatory en/of restricted zijn voor een bepaalde activiteit. Als een dataobject mandatory of verplicht is moet dit dataobject in de activiteit worden opgenomen om de activiteit te kunnen voltooien. Als een dataobject restricted of beperkt is, kan het alleen worden opgenomen door die activiteit. Verder zijn er ook free dataobjecten of vrije 73
dataobjecten. Deze dataobjecten kunnen in tegenstelling tot andere dataobjecten worden gewijzigd wanneer de case wordt behandeld. Verplichte dataobjecten vormen een soort postconditie. Om ook precondities te hebben, kan er gebruik gemaakt worden van dummy activiteiten of activiteiten waarbij er niks gebeurt en enkel moet voldaan zijn aan de conditie.
Actoren of gebruikers van het systeem worden gegroepeerd in rollen. Een actor kan verschillende rollen hebben. Bij case handling zijn er drie soorten rollen die voor elke activiteit en elk proces kunnen worden gespecificeerd: -
Execute rol: om de activiteit uit te voeren
-
Redo rol: om de activiteit ongedaan te maken, daarna kan ze opnieuw worden uitgevoerd
-
Skip rol: om een activiteit over te slaan
Daarnaast bestaat er ook een „no-one’ rol, die eigenlijk boven alle andere rollen staat. Dit is bijzonder handig om een point of no return te modelleren omdat niemand gemachtigd is om iets van de „no-one’ rol ongedaan te maken. Tenslotte kan ook een everyone rol in het model worden opgenomen. Iedereen die een rol heeft in het proces kan dit dan uitvoeren. Andere zelf gedefinieerde rollen behoren ook tot de mogelijkheden.
Bij klassieke workflow systemen werkt men met een in-tray systeem om het werk aan iemand toe te kennen. Werkitems die moeten worden uitgevoerd worden aan een tray toegevoegd en op die manier aan werkers met een bepaalde rol toegewezen. Meerdere werkers kunnen een werkitem toegewezen krijgen, maar slechts één iemand zal het uitvoeren. Als een werkitem wordt geselecteerd dan zal het WfMS de bijhorende activiteit opstarten. Bijgevolg vallen bij een WfMS de autorisatie en de distributie van het werk samen. Case handling daarentegen maakt gebruik van een flexibel query mechanisme in plaats van een in-tray systeem. Dit mechanisme laat de werkers toe om alle actieve en voltooide cases op te vragen. Er kunnen verschillende queries worden geformuleerd, waarvan hierna enkele voorbeelden worden vermeld (van der Aalst et al.2004): -
“Selecteer alle cases waarvoor een activiteit is geactiveerd met een execution rol R” 74
-
“Selecteer alle cases waaraan werker W gewerkt heeft in de laatste twee maanden”
De eerste query zorgt voor dezelfde resultaten die men bij een in-tray systeem te zien krijgt. Opdat er ook andere queries kunnen gebruikt worden, biedt het mechanisme aan werkers de mogelijkheid om de cases die aandacht vereisen, op te vragen en te behandelen. Op deze manier wordt de distributie en de autorisatie van het werk bij case handling opgesplitst (van der Aalst et al., 2004).
Tabel VI geeft een samenvatting van de verschillen tussen de traditionele workflow management systemen en case handling systemen.
Tabel VI: Verschillen tussen workflow management en case handling (van der Aalst et al., 2004)
Workflow management Focus Primaire driver Splitsing van case data en proces controle Splitsing van autorisatie en distributie Roltypes
Case handling
Werkitem
Volledige case
Control flow
Case data
Ja
Nee
Nee
Ja
Execute
Execute, Skip, Redo
2.2.2. Case handling en Product Based Workflow Design In tegenstelling tot de traditionele workflow systemen is case handling veel meer datagericht. In dat opzicht bieden case handling systemen een veel betere ondersteuning voor Product Based Workflow Design (PBWD). Hier ligt de nadruk immers ook veel meer op het product of de case in plaats van op de activiteiten (Vanderfeesten, et al., 2008a). Vanderfeesten et al. (2008a) oordelen dat een systeem dat PBWD moet ondersteunen aan de volgende eigenschappen moet voldoen:
-
Het beschikken over een manier om een productstructuur te definiëren en te bezichtigen 75
-
De mogelijkheid bieden om activiteiten te kunnen bekijken en definiëren
-
Ondersteuning bieden om een procesmodel te ontwerpen op basis van een product data model
Dezelfde auteurs hebben eveneens onderzocht in hoeverre case handling systemen zoals
“FLOWer”
en
“Activity
Manager”
product
based
workflow
design
ondersteunen. Hun conclusie was dat case handling systemen en in het algemeen WfMS nog niet helemaal klaar zijn voor PBWD. Vooral de mogelijkheid om het product data model als een hiërarchische structuur weer te geven ontbrak bij de onderzochte case handling systemen.
2.2.3. Conclusie Case handling is veel datagerichter dan traditionele workflow systemen. Bij case handling zijn het dan ook niet de activiteiten die centraal staan maar een case of het product dat moet worden geproduceerd. Case handling systemen zijn beter in de omgang met flexibele en informatie-intensieve processen. Case handling focust ook meer op wat kan gedaan worden in plaats van wat moet gedaan worden en staat dus meer open voor innovatie.
2.3.
Information-centric procesmodellering
De focus van information-centric procesmodellering, ook wel artifact-centric procesmodellering genoemd, ligt niet op de activiteiten maar op het bewegen van data doorheen het proces. Vele proces- en workflow modellen zijn vooral op de processen en activiteiten gericht en nemen de data onvoldoende in rekening, of ze zijn vooral op datagericht en hechten minder belang aan de processen. Informationcentric procesmodellering daarentegen beschouwt zowel data als processen als elementaire blokjes om een model mee te bouwen. De information-centric methode gebruikt informatie-entiteiten of business artefacten welke in feite de belangrijkste bedrijfsdata voorstellen en gaat op basis van deze entiteiten bedrijfsprocessen ontwerpen. Het verschil met andere technieken is dat de focus verschoven wordt van de activiteiten die moeten worden uitgevoerd, naar de entiteiten waarop deze acties worden uitgevoerd (Bhattacharya et al., 2007). In tegenstelling tot de activitycentric methode waarbij de acties worden beschreven om een bepaalde doelstelling 76
te bereiken, gaat men hier eerst de artefacten waarop acties worden uitgevoerd, beschrijven. Men gaat dus de operaties beschrijven door eerst te identificeren wat belangrijk is voor het bedrijf. Daarna wordt beschreven hoe die artefacten kunnen bewerkt worden om een bepaalde doelstelling te bereiken (Liu, Bhattacharya & Wu, 2007).
Door de wisselwerking tussen data en processen biedt artifact-centric business procesmodellering nieuwe mogelijkheden. Zo is het mogelijk om te onderzoeken hoe een bepaalde categorie van gegevens gaat evolueren als functie van de tijd (Cohn & Hull, 2009). Met de artifact-centric methode kan ook de verantwoordelijkheid van het werk grondiger worden nagegaan. Al het werk dat wordt uitgevoerd, zou dan ook traceerbaar moeten zijn door het als een stukje informatie op te nemen in één of meer business artefacten (Liu et al., 2007). Deze methode zet ook aan tot meer communicatie tussen de verschillende stakeholders wat betreft de processen en operaties (Cohn & Hull, 2009).
Information-centric procesmodellering slaagt er in om het gedrag van complexe processen in een vlakke structuur weer te geven door te focussen op enkele business entiteiten. Traditionele benaderingen daarentegen moeten grote en complexe bedrijfsprocessen hiërarchisch weergeven en dit bevordert diepgaande analyses niet. Information-centric procesmodellering laat in tegenstelling tot traditionele procesmodellen ook toe om de nadruk te leggen op wat kan er gedaan worden in plaats van wat moet gedaan worden. Dit komt omdat traditionele modellen alleen maar de informatie voorzien die nodig is om een bepaalde activiteit uit te voeren en information-centric procesmodellering ook contextuele informatie voorziet (Kumaran, Liu, & Wu, 2008).
Informatie-entiteiten bij information-centric modellering hebben doorheen de geschiedenis verschillende benamingen gekregen. Tegenwoordig worden ze vooral business artefacten (Liu et al., 2007) of business entiteiten (Kumaran et al., 2008) genoemd. In wat volgt wordt eerst een voorbeeld gegeven van information-centric procesmodellering. Daarna volgt de beschrijving van een methode om activitycentric procesmodellen om te vormen naar information-centric procesmodellen.
77
2.3.1. Artifact-centric procesmodellering Artifact-centric procesmodellering is gebaseerd op business artefacten die zowel data- als procesaspecten in een holistische eenheid kunnen opnemen. Een business artefact wordt door Gerede, Bhattacharya en Jianwen (2007) als volgt omschreven: “A business artifact is an identifiable, self-describing unit of information through which business stakeholders add value to the business.” Dergelijke informatieeenheden vormen de elementaire bouwstenen van een model. In een eerste fase gaat men dan ook alle mogelijke artefacten zoeken en analyseren. Een artefact bevat informatie, heeft een unieke identificatiecode of – sleutel (ID) en begint meestal met een paar gedefinieerde attributen. Doorheen het proces vullen de activiteiten de overige attributen in of wijzigen ze reeds gedefinieerde attributen (Deutsch et al., 2009). De artefacten evolueren dus terwijl ze doorheen een proces passeren en doorlopen een levenscyclus. Business artefacten kunnen ook worden aangemaakt en opgeslagen. Ze kunnen evenwel niet worden opgesplitst (Cohn & Hull, 2009).
In een informatiemodel kunnen gegevens over business artefacten tijdens hun levenscyclus worden weergegeven. Daarnaast kan er ook een levenscyclusmodel worden gemaakt dat de mogelijke tijdstippen en manieren beschrijft waarop taken kunnen worden ingeroepen op deze objecten. Cohn en Hull (2009) geven een air courier pakket als typisch voorbeeld. Zo zal het informatiemodel zaken bevatten als ID, zender, ontvanger en leveringsdatum, terwijl het levenscyclusmodel eerder de manieren van transport en betaalmiddelen zal bevatten. Deze techniek zorgt zo voor een middel om data en processen te gaan combineren op een manier die nog steeds handelbaar is (Cohn & Hull, 2009). Figuur XLI toont een voorbeeld van een artefact „Bestelling‟. Het levenscyclusmodel toont de meest relevante toestanden waarin een artefact zich kan bevinden tijdens het proces. De volle pijlen duiden op de normale gang van zaken. De pijlen in stippellijn duiden op alternatieve toestanden die het artefact kan hebben. De pijlen boven de toestand „Verwerkt‟ wijzen op enkele lussen die het artefact doorloopt.
78
Figuur XLI: Levenscyclusmodel van het artefact ‘Bestelling’
Volgens Cohn en Hull (2009) zijn er enkele gelijkenissen tussen de artefactmethode en entity relationship modellering (supra p.16). Zo is het business artefact framework net als een ER diagram actiegericht omdat beiden kunnen gebruikt worden om een uitvoerbaar
systeem
te
ontwikkelen.
Daarnaast
zijn
beiden
semantische
benaderingen die gebruik maken van een kleine set natuurlijke en intuïtieve constructen. In tegenstelling tot ER modellering gaat de artefactmethode data veel meer gaan clusteren op basis van de toestanden in de levenscyclus van de eenheden. De ER techniek gaat de data eerder opsplitsen in kleine onderdelen. Zo worden data in een ER diagram opgesplitst in entiteitstypes en hun relaties. Met een artefact zoals bijvoorbeeld „Bestelling‟ kan men nagaan in hoeverre het bedrijf op goede weg is om hun bedrijfsdoelen te bereiken. In Figuur XLII wordt de artefactgerichte versie van een workflow model voorgesteld en meer precies van het artefact „Bestelling‟. Dit artefact houdt verschillende zaken bij zoals het ID, de leveringsdatum en de prijs. Daarnaast heeft de bestelling ook verschillende stadia die het doorloopt zoals „Aangemaakt‟, „Verwerkt‟ en „Voltooid‟. Naast het artefact „Bestelling‟ kunnen de services terug gevonden worden zoals bijvoorbeeld „Bestelling aanmaken‟ of
„Bestelling verwerken‟. Deze services kunnen een artefact
instantiëren, updaten of de toestand veranderen. Een service moet op zijn minst één artefact updaten of de toestand veranderen van tenminste één artefact. Artefacten kunnen ook gerelateerd zijn aan elkaar (Bhattacharya et al., 2007). Zo gaat het artefact „Bestelling‟ verwijzen naar de andere artefacten en zijn de identificatiecodes van de artefacten „Factuur‟ (FactuurNr) en „Productieorder‟ (PdorderNr) opgenomen
79
als attributen van het artefact „Bestelling‟. Er zijn ook modellen die deze relaties tussen de artefacten weergeven maar die worden hier buiten beschouwing gelaten.
Figuur XLII: Artefactgerichte versie van een workflow model (Bhattacharya et al., 2007)
Als startpunt bij de ontwikkeling van een informatiesysteem wordt een business artifact-centric operational model ontwikkeld. Dergelijke modellen beschrijven de werking van een bedrijf en geven het verwerken van de artefacten weer waarbij de attributen worden ingevuld. Het model toont met andere woorden hoe een bepaalde doelstelling wordt bereikt door het verwerken van artefacten. Een artifact-centric operational model bestaat uit drie belangrijke constructen: artefacten, taken en opslagplaatsen (Figuur XLIII).
80
Figuur XLIII: Constructen van een Artifact-centric Operational model
Business artefacten werden reeds uitgelegd. Business taken zijn de operaties die op een business artefact worden uitgevoerd. Zoals reeds aangehaald moet een taak op zijn minst één business artefact updaten of van toestand veranderen. Een taak voegt met andere woorden waarde toe aan een artefact. Een opslagplaats of repository duidt op een buffer of een plaats waar artefacten wachten. Een taak kan een artefact in een dergelijke opslagplaats plaatsen of eruit halen. In het volgend voorbeeld dat is gebaseerd op een deel van het basismodel zijn er drie artefacten: „Bestelling‟, „Factuur‟ en „Productieorder‟ (Figuur XLIV) (Gerede et al., 2007).
Figuur XLIV: Voorbeeld van een business Artifact-centric Operational model (Gerede, et al., 2007)
81
2.3.2. Omvormen van een activity-centric model naar een information-centric model Kumaran et al. (2008) beschrijven een manier om een activity-centric model om te vormen naar een information-centric model. Ze spreken over informatie-entiteiten in plaats van business artefacten. De informatie-elementen vormen volgens hen een informatie-domein. Dit is in feite alle informatie die door de bedrijfsfuncties wordt gebruikt. Figuur XLV toont een voorbeeld van een activity-centric procesmodel. Links in de figuur zijn de activiteiten en hun volgorde weergegeven. Rechts staat de informatie die de activiteiten gebruiken of produceren tijdens het proces.
Figuur XLV: Voorbeeld van een activity-centric procesmodel (Kumaran et al., 2008)
Het verschil tussen activity-centric en information-centric is dat bij het activity-centric perspectief de activiteiten de informatie-entiteiten gebruiken, aanpassen of produceren om zo een bepaalde output te produceren. Bij het information-centric perspectief hangt het uitvoeren van een bepaalde activiteit af van de aanwezigheid 82
van de correcte informatie in de juiste toestand. De informatie-entiteiten beïnvloeden dus de activiteiten. Het informatie-entiteit „Bestelling‟ beïnvloedt bijvoorbeeld bijna alle activiteiten in het proces, terwijl de entiteiten „Productieplan‟ en „Factuur‟ slechts één activiteit beïnvloeden die op hun beurt ook door „Bestelling‟ worden beïnvloed. Er is dus duidelijk een verschil in graad van invloed op de activiteiten. Hier kan men zeggen dat de entiteit „Bestelling‟ de informatie-entiteiten „Factuur‟ en „Productieplan‟ domineert. Algemeen kan worden gesteld dat een informatie-entiteit (e1) een andere entiteit (e2) domineert als (Kumaran, Liu, & Wu, 2008): -
Iedere activiteit die e2 als input heeft, ook e1 als input heeft
-
Iedere activiteit die e2 als output heeft, ook e1 als output heeft
-
e1 door tenminste één activiteit meer wordt gebruikt dan e2
Figuur XLVI stelt referentiële en inclusieve dominanties voor. Een dominante entiteit is een entiteit die door geen enkele andere entiteit wordt gedomineerd. Een gedomineerde entiteit daarentegen wordt wel door een andere entiteit gedomineerd. Als de gedomineerde entiteit alleen maar als input wordt gebruikt voor activiteiten wordt dit een referentiële dominantie genoemd. Als een gedomineerde entiteit tenminste éénmaal als output is gebruikt, spreekt men van inclusieve dominantie. Zo wordt de entiteit „Klant‟ referentieel gedomineerd door „Bestelling‟ omdat „Klant‟ enkel als input dient bij het maken van een bestelling. „Productieorder‟ en „Factuur‟ worden inclusief gedomineerd door de entiteit „Bestelling‟. Andere entiteiten zoals bijvoorbeeld „BOM‟ kunnen niet domineren of gedomineerd worden. Een grafiek zoals voorgesteld in figuur XLV. wordt een entiteit dominantie grafiek genoemd.
Figuur XLVI: Referentiële en inclusieve dominanties (Kumaran et al., 2008)
83
Van de entiteit dominantie grafiek kan een datamodel worden gemaakt door gebruik te maken van containment data modellering. In dit model wordt een dominantie entiteit een container, een referentiële gedomineerde entiteit een referentie lid en een inclusieve gedomineerde entiteit een container member. Figuur XLVII geeft een voorbeeld weer van een dergelijk datamodel. Dit datamodel geeft de samenhang van de informatie-entiteiten weer.
Figuur XLVII: Voorbeeld van een datamodel (Kumaran et al., 2008)
Naast het datamodel kan er eveneens een gedragsmodel gemaakt worden om het gedrag van de entiteiten weer te geven. Een dergelijk gedragsmodel geeft de verschillende toestanden weer in een model, alsook de activiteiten die deze toestanden veroorzaken. Een gedragsmodel zou de volledige functionaliteit van bedrijfsprocessen moeten bevatten. Het information-centric procesmodel vormt de combinatie van alle gedragsmodellen van de verschillende entiteiten. In zo‟n procesmodel worden met andere woorden de levenscyclussen van alle entiteiten weergegeven. Daarnaast worden ook de synchronisatiepatronen weergegeven. Dit geeft het uitwisselen van informatie tussen twee entiteiten weer. Zo wisselen in figuur XLVIII de entiteiten „Productieorder‟ en „Productieplan‟ gegevens uit via de activiteit „maken van productieplan‟.
84
Figuur XLVIII: Voorbeeld van een information-centric procesmodel (Kumaran et al., 2008)
Een activity-centric procesmodel kan worden omgevormd naar een informationcentric procesmodel via de volgende vier stappen (Kumaran et al., 2008): -
Zoeken naar de informatie-entiteiten en het maken van een dominantie grafiek
-
Zoeken naar input en outputentiteiten van de activiteiten
-
Een outputtoestand creëren voor elke outputentiteit van een activiteit
-
De
activiteiten
verbinden
met
die
output-entiteitstoestand
en
de
outputtoestand verbinden met de volgende activiteit
85
2.3.3. Document-driven workflow systemen Document-driven workflow systemen zijn gerelateerd aan information-centric modellering.
Deze
workflow
systemen
zijn
ontworpen
op
basis
van
de
afhankelijkheden tussen gegevens. Expliciete control flow is bij document driven workflow systemen niet nodig (Kumaran et al., 2008).
Het werk van Wang en Kumar (2005) bouwt verder op het WIDE project waarbij het gebruik van triggers bij workflow systemen wordt besproken. Hierbij wordt meer aandacht besteed aan datamanagement en aan de processen die de data creëren en manipuleren. Door datamanagement als basis te gebruiken voor workflow management en door bedrijfsdata gemakkelijk beschikbaar te stellen, worden de data en de processen op een geïntegreerde manier gemanaged (Grefen, Pernici & Sanchez, 1999). Bij document-driven workflow systemen gaat men een stap verder en vertrekt men van het idee om een compleet workflow systeem in een database te implementeren. De workflow systemen moeten immers kunnen reageren op events. Op die manier wordt de workflow geleid door triggers die events waarnemen en is een workflow engine overbodig (Wang & Kumar, 2005).
Bij een workflow waarbij de document flow geïntegreerd is kan er onderscheid gemaakt worden tussen hard en soft constraints. Een hard constraint duidt op een data dependency constraint en dit is bij alle bedrijven hetzelfde. Men moet bijvoorbeeld eerst een bestelling krijgen vooraleer een factuur kan aangemaakt worden. Een soft constraint kan verschillen van bedrijf tot bedrijf en duidt op een business policy constraint. Zo kan het voor bepaalde bedrijven de gewoonte zijn om pas te factureren nadat de bestellingen zijn opgestuurd. Voor andere bedrijven kan die volgorde dan weer omgekeerd zijn. Bij traditionele workflow systemen is dit onderscheid niet mogelijk omdat dit niet blijkt uit een procesmodel waar de document flow die de hard constraints aangeeft niet is in opgenomen. Dit komt de flexibiliteit niet ten goede (Wang & Kumar, 2005).
Document-driven workflow systemen die een WfMS bouwen in een database maken, geen gebruik van een vooraf gedefinieerde control flow omdat taken worden 86
uitgevoerd op basis van de aanwezigheid van de noodzakelijke inputdocumenten en resources. Op deze manier wordt er voor meer flexibiliteit gezorgd. Deze methode werkt echter minder goed voor grote processen met veel taken, onder meer omdat het moeilijk is om het proces te visualiseren door het ontbreken van de control flow (Wang & Kumar, 2005).
2.3.4. Conclusie De information-centric methode legt de nadruk op de informatie-entiteiten of de artefacten waarop acties moeten worden uitgevoerd in plaats van op de acties zelf. Deze methode zorgt voor een framework dat zowel data als processen op een beheerbare manier combineert. Met de information-centric methode kan ook worden nagegaan hoe een bepaalde categorie gegevens evolueert als functie van de tijd en kan het werk dat wordt uitgevoerd, gemakkelijk traceerbaar worden gemaakt. Daarnaast laten de artefacten ook toe om te evalueren in welke mate bedrijfsdoelen worden bereikt. Door te focussen op enkele business artefacten kunnen grote en complexe processen nog steeds worden weergegeven als vlakke structuren in plaats van een hiërarchische structuur zoals dit bij traditionele procesmodellen het geval is. Omdat de information-centric methode ook contextuele informatie voorziet in plaats van alleen informatie die nodig is voor het uitvoeren van een activiteit, kan er gekeken worden naar wat kan gedaan worden in plaats van wat moet gedaan worden. Activity-centric procesmodellen kunnen worden omgevormd tot informationcentric procesmodellen. Een andere methode die hiermee gerelateerd is, namelijk de document-driven workflow systemen, ontwerpt workflow systemen op basis van de afhankelijkheden tussen de gegevens. Deze methode waarbij expliciete control flow niet vereist is, is een stuk flexibeler, al is deze methode niet geschikt voor grote processen.
2.4. Data-driven
Data-Driven Process Structures processen
zijn
processen
met
over
het
algemeen
grote
processtructuren. Een processtructuur bestaat uit een proces met zijn subprocessen. Deze processen hebben een sterke relatie met de assemblage van een product. Muller, Reichert en Herbst (2008) geven de productie van een auto als voorbeeld. Er 87
gebeuren continue wijzigingen aan deze processen en dus moet er voor voldoende flexibiliteit worden gezorgd. Door de grote hoeveelheid processen is dit niet vanzelfsprekend aangezien het modelleren van de processtructuur op zich al zeer complex is.
Omdat er bij data-driven processen een sterke link is tussen het product of de datastructuur en de processtructuren, kunnen de processtructuren gemodelleerd, bepaald en aangepast worden op basis van de datastructuren. Op enkele uitzonderingen
na
is
het
ontwerpen
van
processen
nog
voornamelijk
activiteitsgedreven. Hierbij moet de connectie tussen het product en de datastructuren manueel worden gedefinieerd. Het spreekt voor zich dat dit inefficiënt is. Bij het ontwikkelen van data-driven processtructuren worden
data– en
procesmodellen dan ook geïntegreerd (Müller, Reichert & Herbst, 2006). In COREPRO,
een
framework
voor
het
data-driven
modelleren
van
grote
processtructuren, worden veranderingen in de datastructuur dan ook automatisch omgezet in veranderingen in de processtructuur (Müller et al., 2008; Müller, Reichert & Herbst, 2010).
2.4.1. COREPRO Modeling Framework Met het COREPRO Modeling Framework kunnen de data-driven processtructuren gemodelleerd worden. Figuur XLIX toont de verschillende stappen van de COREPRO model benadering.
Boven
de
stippellijn
worden
de
modellen
weergegeven en onder de stippellijn de structuren. Helemaal onderaan de figuur worden de gebruikte symbolen verklaard. Een eerste stap is het definiëren van een datamodel (Figuur XLIX.1a). Een datamodel in COREPRO is opgebouwd uit objecttypes en relatietypes. Een objecttype is een abstractie van een bepaald onderdeel van het product. Een relatietype geeft het verband tussen twee objecttypes weer. Een datamodel toont dus het verband tussen de verschillende objecttypen. Op basis van dit datamodel kan een datastructuur worden gecreëerd. (Figuur XLIX.1b). Dit is een uitgewerkt voorbeeld van het datamodel. De datastructuren bestaan uit objecten en hun relaties welke voorbeelden zijn van objecttypes en relatietypes. Zo is in figuur XLIX.1b het type systeem één keer geïnstantieerd en het type subsysteem drie keer. 88
Figuur XLIX: Algemeen concept van de COREPRO Model benadering (Müller et al. 2010)
Vervolgens moet de datastructuur gelinkt worden aan de processtructuur. Hiertoe moeten de objecttypes worden weergegeven in een object life cycle (OLC) (Figuur XLIX.2a). Een object life cycle bestaat uit object states of objecttoestanden en internal state transitions of interne toestandstransities. Objecttoestanden worden getransformeerd door subprocessen. Hierbij verandert de toestand van een object. Dit wordt in het model weergegeven door interne toestandstransities en bijhorende processen die de objecten manipuleren en zo hun toestand veranderen. Dit wordt verduidelijkt aan de hand van Figuur L en LI. Figuur L stelt de constructen voor van een object life cycle en figuur LI toont een voorbeeld van een object life cycle. In een object life cycle kan er ook altijd maar één interne toestandstransitie worden geactiveerd. Zo wordt het object „Bestelling‟ in figuur LI ofwel verwerkt ofwel verworpen. Een OLC toont bijgevolg niet alleen de ideale situatie maar toont ook de uitzonderingen.
89
Figuur L: Constructen van een object life cycle (Müller et al., 2008)
Figuur LI: Voorbeeld van het OLC voor het object ‘Bestelling’
Bij COREPRO model benadering bestaat stap twee dus uit het maken van een OLC voor alle objecten. Dit is echter nog onvoldoende. Er moet ook rekening worden gehouden met de relatietypes tussen de verschillende objecttypes en dus moeten er ook relaties worden gedefinieerd tussen de verschillende objecten. Dit wordt gedaan door object depedencies die de OLCs van gerelateerde objecten synchroniseren. Object
depedencies
bestaan
uit
external
state
transities
of
externe
toestandstransities die objecttoestanden uit het gerelateerd OLC met elkaar verbinden. Zo moet het object „Klant‟ worden aangemaakt alvorens het object „Bestelling‟ kan worden verwerkt. Dit wordt in het model opgenomen als een externe toestandstransitie tussen toestanden van verschillende objecten (zoals rechts voorgesteld in figuur XLIX.2a). Alle OLCs en hun object depedencies worden in het COREPRO Modeling Framework het Life Cycle Coordination Model (LCM) genoemd. Het verschil tussen interne - en externe toestandstransities is dat subprocessen bij een interne toestandstransitie voor een deactivatie zorgen bij de brontoestand (toestand vóór het subproces) en voor een activatie zorgen van de doeltoestand (toestand na het subproces). Met andere woorden zorgen de interne toestandstransities
voor
een
toestandsverandering
in
een
OLC.
Externe
toestandstransities veranderen geen toestand in de OLC van de brontoestand. Een doeltoestand wordt dan ook pas geactiveerd als één interne toestandstransitie en alle externe toestandstransities uitgevoerd zijn. Daarnaast bestaan er ook nog 90
directe toestandstransities. Deze zorgen eveneens voor een deactivatie van de brontoestand en een activatie van de doeltoestand en worden bijvoorbeeld gebruikt bij de unieke starttoestand (Figuur LII) om op die manier alle startstaten van de OLC te activeren. Figuur LII stelt alle mogelijke transities voor.
Figuur LII: Voorbeeld van interne, externe en directe toestandstransities
Samengevat combineert het LCM het datamodel met de subprocessen. Op basis hiervan kan op een automatische manier een data-driven processtructuur worden ontwikkeld. Dit wordt een life cycle coordination structure (LCS) genoemd (Figuur XLIX.2b). In een LCM geeft men de objecttypes weer terwijl in een LCS de echte objecten of de voorbeelden van objecttypes weergegeven worden. Een LCS bestaat uit een begin– en eindtoestand, een OLC voor elk geïnstantieerd object en alle externe toestandstransities tussen deze objecten. Met de volgende drie stappen kan een LCS worden ontwikkeld op basis van de datastructuur en het LCM (Müller et al., 2010): -
Voor elk object uit de datastructuur wordt een OLC geïnstantieerd, geassocieerd met het overeenkomend objecttype.
-
Voor elke relatie in de datastructuur worden de OLC depedencies geassocieerd met de overeenkomende relatietypes, ingevoerd om de toestand van de verbonden OLCs te verbinden.
91
-
Om de LCS begintoestanden te verbinden met de OLC toestand en de OLC eindtoestanden te verbinden met de LCS eindstaat worden directe toestandstransities ingevoerd.
Het resultaat hiervan is een data-driven processtructuur. Deze processtructuur bepaalt de volgorde van uitvoeren van de processen. LCS kan gemakkelijk worden omgevormd naar een activity-centered procesmodelleertaal zoals BPMN.
In tegenstelling tot de traditionele activiteitsgerichte procesmodellen waarbij veranderingen aan de datastructuur en de processtructuur handmatig moet worden aangepast, worden deze veranderingen met COREPRO automatisch doorgevoerd. Op die manier kan er veel tijd worden bespaard en is het ook niet nodig om diepgaande kennis te bezitten over de processen om de veranderingen te kunnen uitvoeren (Müller et al., 2006; Müller et al., 2008; Müller et al., 2010);
2.4.2. Conclusie Data-driven processen bevatten over het algemeen grote processtructuren en hebben een sterke relatie met een product. Door de continue wijzigingen moeten ze voldoende flexibel zijn. Door de sterke link tussen de processtructuren en het product kunnen via COREPRO veranderingen in de datastructuur automatisch worden omgezet in veranderingen in de processtructuur. Via deze methode kunnen er bijgevolg op een efficiënte manier flexibele datagedreven processtructuren van complexe processen worden ontwikkeld.
2.5.
Document-Process Association Model
De meeste workflow management systemen voorzien wel bepaalde functies om documenten aan te maken en op te slaan, maar de stroom van deze documenten doorheen het proces wordt niet in rekening gebracht. Ook de controle van de document flow wordt over het algemeen niet in acht genomen. WfM systemen houden ook alleen maar de laatste versie van een bepaald document bij. Als er doorheen het proces een fout werd gemaakt, is het onmogelijk te achterhalen wie er nu juist verantwoordelijk is (Bae et al., 2004). Daar waar traditionele WfM systemen vooral bezig zijn met het leveren van documenten gaat de methode die hier 92
beschreven wordt veel meer over een WfMS dat de document flow kan managen. Belangrijk hierbij is rekening te houden met het verband tussen de documenten en onderliggende processen en de evolutie van de documenten doorheen het proces.
Een traditioneel WfMS ziet een document ook meestal als een geheel, terwijl een document eigenlijk uit verschillende velden bestaat en een bepaalde structuur heeft. Dit wordt de vorm van een document genoemd. Activiteiten die een document invullen of veranderen, moeten meestal maar bepaalde velden invullen of wijzigen. Dit veroorzaakt dus problemen. Een ander probleem is dat er meestal geen uniform formaat bestaat tussen de documenten. Deze problemen kunnen worden opgelost door gebruik te maken van XML. Er werd geopteerd voor XML en niet voor HTML of SGML. HTML is immers te beperkt omdat het niet toelaat om de inhoud van een document te manipuleren. SGML is dan weer te complex om te gebruiken bij deze methode.
Bij een document-process association model wordt een document ingedeeld in segmenten. Een segment is een werkeenheid die door bepaalde activiteiten kan worden uitgevoerd doorheen het proces. Er wordt dan ook een model ontwikkeld dat deze werkeenheden linkt aan de procesactiviteiten. De componenten van een document komen op die manier overeen met de componenten van het onderliggend procesmodel. Zo wordt het verleden van een document gelinkt aan de progressie van een proces. De toestand van een document kan dan onmiddellijk worden gecontroleerd bij een bepaalde stap in het proces en de inhoud van een document vóór en na een wijziging kan dan worden vergeleken.
Het WfMS dat ontwikkeld wordt bij document-process association modellering is web based en XML documenten zijn hier uitermate geschikt voor. Om XML voor webapplicaties te kunnen gebruiken moet een Document Type Definition (DTD) en een stylesheet worden gedefinieerd. Het DTD bepaalt de structuur van het document en maakt gebruikt van tags en attributen. Een stylesheet bepaalt hoe een document wordt getoond op een webbrowser. Het onderscheid tussen een DTD en een stylesheet leidt ertoe dat de data-inhoud kan worden gemanaged onafhankelijk van de presentatie ervan. Het indelen van een document in segmenten gebeurt aan de
93
hand van XML tags. De documenten worden op die manier gemodulariseerd. (Bae & Kim, 2002).
De link tussen de work units of de werkeenheden van de gemodulariseerde documenten en het bedrijfsproces wordt weergegeven in een workunit model. Dit workunit model bestaat uit een deel waar documenten, bestaande uit werkeenheden en velden, worden weergegeven. Dit wordt het documentstructuur model (DSM) genoemd. Daarnaast is er ook een deel waar de procesactiviteiten worden weergegeven dat het processtructuur model (PSM) wordt genoemd. Figuur LIII geeft een voorbeeld van een workunit model weer waarbij er een associatie wordt gemaakt tussen het DSM dat links wordt weergegeven en het PSM dat rechts wordt weergegeven. In een folder worden verschillende documenten opgeslagen. Verder bestaat een document uit verschillende werkeenheden. Deze werkeenheden worden op hun beurt gelinkt aan de procesactiviteiten. Elke werkeenheid moet aan tenminste één activiteit worden gekoppeld. Daarnaast bestaat een werkeenheid ook nog eens uit verschillende velden die door de activiteiten worden ingevuld of gewijzigd.
Figuur LIII: Voorbeeld van een workunit model (Bae & Kim, 2002)
94
Figuur LIII: Voorbeeld van een workunit model (Bae & Kim, 2002)
Het document-process association model maakt enkele documentgerelateerde functies mogelijk in een WfMS. Voorbeelden hiervan zijn het automatisch identificeren van relevante documenten voor een activiteit en het kunnen omgaan met de inhoud van dit document of het monitoren van de documenten (Bae & Kim, 2002).
2.6.
Data access plug-ins en XML based data access
He toepassen van data access plug-ins en XML based data access werd ontwikkeld om te kunnen omgaan met alle verschillende soorten data in workflow management systemen. De bedoeling is om een uniforme manier te ontwikkelen om toegang te krijgen tot alle gegevens. Eder en Lehmann (2007) pleiten voor meer aandacht voor data management en data handling bij WfMS en stellen daarmee een abstractie mechanisme voor om op een uniforme en flexibele manier data te kunnen managen.
95
Data die noodzakelijk zijn voor een WfMS kunnen van verschillende bronnen en eventueel externe systemen afkomstig zijn. Data uit het systeem kunnen zelfs van een verschillend type of formaat zijn. Om ervoor te zorgen dat een WfMS al deze data kan gebruiken introduceert men data access plug-ins. Deze omhullen externe databases en zijn herbruikbaar en uitwisselbaar. De plug-ins leggen de inhoud van de database voor aan het WfMS en managen op die manier de toegang tot de data. De plug-ins regelen dus in feite de werking van die databases. Daarnaast pleiten Eder en Lehmann (2007) ook voor het gebruik van XML als dataformaat. De data access plug-ins voorzien de data van externe databases als XML documenten aan het WfMS. De data access plug-ins en de XML schema‟s worden geregistreerd door het WfMS en kunnen daarna zo vaak gebruikt worden als nodig door het WfMS. Een voorbeeld van dergelijk XML schema wordt hieronder gegeven: 1: <process name="verwerkBestelling" version="1.0"> 2: <documents> 3: <document name="Bestelling" type="Bestellingtype" accessPlugin="bestellingDbPlugin"/> 4:
Aangezien de meeste data in relationele databases worden opgeslagen, werden de generic data access plug-ins (=GDAP) geïntroduceerd. Die GDAP bieden basisoperaties aan die gemakkelijk kunnen worden uitgebreid. GDAP zorgen ervoor dat de hiërarchische XML documenten die gebruikt worden door de activiteiten en processen worden gemapt of in kaart gebracht worden als een relationeel datamodel. Dit wordt dan op zijn beurt gebruikt door de externe databases.
De interface van een taak wordt weergegeven als een XForm. XForms maken een onderscheid tussen de data-inhoud en de manier waarop de data wordt weergegeven. Deze XForms zijn bedoeld om met XML te kunnen werken. Op deze manier kan een XForm de nodige XML documenten voor het uitvoeren van een taak aannemen als input en als een XForm aan de gebruiker weergeven. Na het uitvoeren van de taak worden de resultaten als een XML document geproduceerd als output.
Nu kan er ook een procesmodel worden ontwikkeld, rekening houdend met de data access plug-ins en de XML based data access. De uitleg van dit model is gebaseerd
96
op het metamodel van Eder en Lehmann (2007). In dit model lieten zij het organisatieperspectief buiten beschouwing. Uit hun metamodel kan afgeleid worden dat een workflow activiteiten gebruikt. Een activiteit is ofwel een (sub-) workflow, een taak of een complexe activiteit (Eder & Lehmann, 2007). Documenten kunnen als parameters worden doorgegeven aan de activiteiten of worden gebruikt als variabelen vermeld in een workflow definitie. Als dergelijk XML document is beschreven in een workflow definitie is het toegankelijk voor een data access plugin. Elk document heeft een XML schematype met een unieke naam. Enkel als dit XML schematype wordt ondersteund door een data access plug-in kan deze plug-in omgaan met het XML document. Verder bestaat een document uit verschillende voorkomens. Deze voorkomens zijn eveneens toegankelijk voor een data access plug-in. Tenslotte kan een taak een XForm hebben. Dergelijke XForm bestaat uit een unieke naam en een set parameters. De parameters van de taak worden ingepast in de parameters van de XForm.
Samengevat ondersteunt het workflow management systeem het gebruikt van XML documenten en via de data access plug-ins zijn data afkomstig van verschillende bronnen toegankelijk voor het WfMS. Data management gebeurt hier dan ook op een flexibele en uniforme manier. Door het gebruik van XForms bij taken wordt ook de user interface flexibeler en meer modulair (Eder & Lehmann, 2007). 2.7.
Overzicht van bijkomende methoden en concepten
2.7.1. Data-Driven Process Control en Exception Handling Proces management systemen zijn over het algemeen niet goed in de omgang met real-world exception. Data-driven processtructuren zijn hiervoor beter geschikt. Rinderle en Reichers (2006) wijzen erop dat er een kloof is tussen de gecomputeriseerde processen en de real-world processen. Een reden hiervoor is dat het met de huidige Proces Management Systemen (PMS) niet mogelijk is om realworld data te integreren over lopende processen. Deze data zijn echter noodzakelijk om te kunnen omgaan met real-world uitzonderingen. Bij het optreden van een dergelijke uitzondering moet er dan ook vaak om het PMS heen worden gewerkt.
97
Rinderle en Reichert (2006) stellen een framework voor dat hiervoor een oplossing zou moeten bieden. Door gebruik te maken van datagedreven uitbreidingen en wijzigingen aan te brengen aan de datastructuur is het mogelijk te kunnen omgaan met deze uitzonderingen zonder echt veranderingen te maken aan de processen. Dit is een gebruiksvriendelijke manier om overweg te kunnen met real-world exceptions (Rinderle & Reichert, 2006).
2.7.2. Data flow en validatie Een belangrijk onderdeel van de procesvalidatie, waarbij men naar het resultaat van het proces gaat kijken en wat men ervan verwacht, zijn de databenodigdheden en de data flow. De validatie dient om fouten en conflicten te kunnen opsporen en zo meer vertrouwen in het model te kunnen hebben.
Om data in een workflow model te kunnen valideren stellen Sadiq et al. (2004) een activity-based datamodel voor. Dit model wordt gebruikt omdat het niet mogelijk is om in een workflow model alle informatie van de onderliggende databases te integreren en omdat het zeer moeilijk is om de data flow weer te geven in grote en complexe
processen.
Dergelijk
activity-based
datamodel
geeft
de
databenodigdheden weer van de individuele activiteiten. Dit model moet de data die activiteiten nodig hebben of produceren weergeven. Het model moet met andere woorden de input en output data kunnen weergeven. Daarnaast moet het ook de uitwisseling van data tussen activiteiten of met andere woorden de data flow kunnen weergeven.
De verschillende types data die in het model kunnen worden weergegeven zijn referentie-, operationele, beslissings- en contextuele data. Referentiedata duiden op data die gebruikt worden om een voorkomen te identificeren. Operationele data zijn de data die worden gebruikt door de activiteiten. Beslissingsdata zijn data die nodig zijn om een control flow beslissing te nemen. Beslissingsdata is een onderdeel of een deelverzameling van de operationele data. Contextuele data zijn meestal data met een complexe structuur die als input of output worden gebruikt door de activiteiten. In het model wordt ook de bron van de data opgenomen. Dit kan ofwel een interne bron of een externe bron zijn. Externe data zijn data die in tegenstelling 98
tot interne data niet uit de proces datastore komen. De structuur van data kan gaan van een ongestructureerde tot een complexe datastructuur. Voor de datavalidatie is er bijgevolg nood aan een model dat met de datastructuur, de databron en het datatype kan omgaan.
Problemen die bij datavalidatie kunnen optreden zijn de volgende (Sadiq et al. ,2004): -
Overtollige data: Data die worden gegeven als output van een activiteit maar voor geen enkele activiteit nodig zijn als input.
-
Verloren data: Als twee parallelle activiteiten hetzelfde data-item genereren en niet bepaald is van welke activiteit de activiteit na de join de data moet ontvangen (Figuur LIV)
-
Vermiste data: Data die als input van een activiteit worden gegeven, maar waarvan de bron niet bekend is.
-
Mismatch data: De structuur van de data die nodig zijn, is niet dezelfde als de structuur van de data in de bron
-
Inconsistente data: Data die tijdelijk worden opgeslagen om later terug te worden gebruikt in het proces, kunnen extern worden geüpdate.
-
Verkeerd geleide data: Als de data flow botst met de control flow van het proces
-
Ontoereikende data: Data die onvoldoende zijn om een activiteit uit te voeren
Figuur LIV. Voorbeeld van een proces waarbij verloren data kunnen optreden (Sadiq et al., 2004)
99
2.7.3. AHEAD Een andere methode om control en data flow te integreren is voorzien door AHEAD. Het is een systeem om processen te modelleren en te ontwikkelen. Producten, activiteiten en middelen (resources) worden dan ook op een geïntegreerde manier gemanaged. De data flow en de control flow worden geïntegreerd omdat activiteiten worden gerelateerd met objecten uit het datamodel (Jäger, Schleicher, & Westfechtel, 2000; Müller et al., 2010). 2.7.4. ADEPTflex ADEPTflex vormt een basis voor het ondersteunen van dynamische en structurele veranderingen aan workflow voorkomens tijdens de uitvoering. Hiervoor is een ADEPTflex model ontwikkeld. ADEPTflex is gebaseerd op het workflow model ADEPT. Het ADEPTflex model bevat naast de control flow ook een data flow. Het ontwikkelde workflow schema wordt geassocieerd met een set van data-elementen. De data flow wordt dan weergegeven door de parameters van de taken te verbinden met de dataelementen (Reichert & Dadam, 1998).
2.7.5. SEAM SEAM staat voor state-entity-activity model. SEAM is een conceptueel workflow model dat zowel data als processen weergeeft en dat daarnaast ook nog eens het element tijd incorporeert. Het betrekken van data in SEAM is gebaseerd op ER modellen en maakt onder meer gebruik van entiteitstypes, toestandstypes en hun attributen. Data en processen worden bij SEAM uitdrukkelijk aan elkaar gelinkt. Van de SEAM schema‟s kunnen er eveneens abstracties worden gemaakt die worden ondersteund door relationele database management systemen (Bajaj & Ram, 2002).
100
3. Algemene conclusie Het doel van deze masterproef was na te gaan in welke mate conceptuele gegevensmodellen toegepast worden bij procesbewuste informatiesystemen.
Omdat procesmodellen de basis vormen van procesbewuste informatiesystemen, werd in een eerste deel nagegaan hoe het dataperspectief geïntegreerd kan worden in procesgerichte modellen. De meeste procesmodelleertalen waren in eerste instantie vooral op de control flow gericht. Nochtans vormen zowel data als processen belangrijke aspecten van de workflow en is het dus belangrijk dat beiden in een model kunnen worden opgenomen. Om de data flow en andere perspectieven beter te ondersteunen volgden bij de meeste modelleertalen uitbreidingen of kwam een nieuwe versie uit.
Colored petri nets (CPN) zijn een uitbreiding van de low level petri nets en laten toe de data flow in het model te integreren aan de hand van tokens die doorheen het model vloeien. Aan deze tokens kunnen data worden toegevoegd. Petri nets vormen de basis voor de andere procesmodellen zoals EPC, UML 2.0 activiteitsdiagrammen en YAWL.
Business process modeling notation (BPMN) laat ook toe om data te integreren in het procesmodel, maar doet dit aan de hand van dataobjecten. Deze dataobjecten worden via associaties aan de activiteiten gelinkt. Daarnaast kunnen er met de information flows ook boodschappen weergegeven worden tussen de verschillende deelnemers van het proces. BPMN is beperkt op het vlak van zichtbaarheid, het definiëren
en
het
gebruik
van
data-elementen
door
de
verschillende
procescomponenten. Verder is BPMN vooral beperkt op het vlak van data-interactie van de verschillende procescomponenten, en dan vooral de data-interactie met de externe omgeving.
Event-driven process chains (EPCs) maken eveneens gebruik van objecten om data weer te geven in het procesmodel. Hierbij heeft men de keuze tussen entiteitstypes, technical term objecten en knowlegde objecten. Door dit onderscheid kan in het model worden weergegeven of de data al dan niet gestructureerd zijn. Daarnaast 101
kunnen ook de opslagplaats en de attributen van data aan het model worden toegevoegd.
UML 2.0 activiteitsdiagrammen (UML 2.0 AD) combineren object tokens en object nodes in het model. De object tokens stellen datawaarden voor die doorheen het proces vloeien en de object nodes vormen in feite tijdelijke opslagplaatsen voor de object tokens. UML 2.0 AD heeft enkele gebreken op vlak van de ondersteuning van de workflow datapatronen. Zo worden net als bij BPMN externe data-interacties niet ondersteund en is er geen aandacht voor scope, case en folder data en het transfereren van data als een waarde tussen verschillende proceselementen.
newYAWL is een modelleertaal die de workflow datapatronen veruit het best ondersteunt. Alleen de uitwisseling van data door te verwijzen naar de locatie van die data wordt maar beperkt ondersteund. newYAWL maakt gebruik van formele parameters om de data-elementen door verschillende procescomponenten uit te wisselen. Daarnaast kunnen er ook pre- en postcondities worden toegevoegd aan de taken of linkcondities die bepalen welke takken er geactiveerd moeten worden. Dataelementen kunnen ook exclusief worden gebruikt door een taak door middel van een lock.
In het tweede deel van deze masterproef worden andere modellen, methoden en concepten beschreven waarbij naast het opnemen van data flow in procesmodellen ook het dataperspectief een belangrijk onderdeel vormt van de ontwikkeling van procesbewuste informatiesystemen.
Concepten zoals product based workflow design (PBWD) en data-driven processtructuren ontwikkelen procesmodellen op basis van een product of een datastructuur. PBWD dient vooral om processen te herontwikkelen en te verbeteren. Voordelen van PBWD zijn het kunnen verantwoorden van data-elementen en productieregels tegenover het product. Daarnaast worden de taken gerangschikt volgens een bepaalde strategie en perfomance goals. Processen kunnen ook rechtstreeks ondersteund worden door een productstructuur zonder eerst een procesmodel te ontwikkelen. Dit concept heet product based workflow support (PBWS) en zorgt voor een meer flexibele en dynamische ondersteuning van de 102
processen dan bij PBWD het geval is. Ook de datagedreven processtructuren zorgen voor meer flexibiliteit dan traditionele WfMS omdat veranderingen aan datastructuren automatisch kunnen worden omgezet in veranderingen aan de processtructuren. Het idee om activiteiten te coördineren op basis van data als product van de kennisintensieve bedrijfsprocessen is ook terug te vinden bij case handling. Case handling systemen gaan beter om met flexibele en informatieintensieve processen in tegenstelling tot traditionele workflow systemen. Bovendien laat case handling toe om meer nadruk te leggen op wat kan gedaan worden in plaats van wat moet gedaan worden. Information-centric modellering, ook wel artifact-centric modellering genoemd, is gelijkaardig aan case handling, PBWD en datagedreven processtructuren. Ook bij deze methode ligt de nadruk niet op de acties maar op de informatie-entiteiten of business artefacten waarop deze acties worden uitgevoerd. Door de nadruk te leggen op entiteiten en artefacten kunnen grote en complexe processen nog steeds als een vlakke structuur worden weergegeven in plaats van een hiërarchische structuur. Dit bevordert de analyse van het systeemgedrag. Daarnaast kan ook hier worden gefocust op wat kan gedaan worden omdat information-centric modellering niet alleen de informatie weergeeft die nodig is om een activiteit uit te voeren maar ook contextuele informatie weergeeft. Andere gerelateerde systemen zijn de document-driven workflow systemen. Bij deze methode worden workflow systemen ontwikkeld op basis van de afhankelijkheden tussen de gegevens. Deze systemen waarbij expliciete control flow niet nodig is, zijn een stuk flexibeler dan gewone WfMS.
Modellen zoals document-process association modellen maken gebruik van XML documenten die ingedeeld zijn in segmenten. Deze segmenten worden dan aan de activiteiten van het proces gelinkt en op die manier wordt de document flow van een WfMS beheerd. Een andere methode maakt dan weer gebruik van XML om meer flexibele workflow systemen te ontwikkelen en om data op een uniforme en flexibele manier te managen. Dit wordt ondermeer gedaan door gebruik te maken van data access plug-ins en XML based data access.
103
Samengevat
kan
worden
gesteld
dat
het
gebruik
van
conceptuele
gegevensmodellen bij de ontwikkeling van procesbewuste informatiesystemen recent onder de aandacht is gekomen. Door ook de data flow te integreren in procesmodellen wordt er een meer correcte weergave verkregen van de werking van de processen waardoor er achteraf minder problemen opduiken.
Andere
datagerichte methoden zoals bijvoorbeeld PBWS en datagerichte processtructuren zorgen dan weer voor de ontwikkeling van meer flexibele procesbewuste informatiesystemen en bieden tevens tal van andere voordelen.
104
4. Lijst met geraadpleegde werken
Adam, C. (1962). Kommunikation mit Automaten. PhD thesis, Institut fur instrumentelle Mathematik. Alter, S. (1999). Information Systems: A Management Perspective. Addison-Wesley, Reading, MA . Bae, H. & Kim, Y. (2002). A document-process association model for workflow managament. Computers in Industry, Vol. 47, Nr. 2, 139-154. Bae, H., Hu, W., Yoo, W. S., Byeong, K. K., Kim, Y. & Park, Y.-T. (2004). Document configuration control processes captured in a workflow. Computers in Industry, Vol. 53, Nr. 2, 117-131. Bajaj, A. & Ram, S. (2002). SEAM: A State-Entity-Activity-Model for a Well-Defined Workflow Development Methodology. IEEE Transactions on Knowlegde and Data Engineering, Vol. 14, Nr. 2, 415-431. Bell, D. (2003). UML basics Part II: The activity diagram. Rational Software. Bhattacharya, K., Gerede, C., Hull, R., Liu, R. & Su, J. (2007). Towards Formal Analysis
of
Artifact-Centric
Business
Process
Models.
Business
Process
Management, Vol. 4714, 288-304. Blum, S. D. (1995). A Primer on Object Role Modeling. Bock, C. (2003). UML 2 Activity and Action Models. Journal of Object Technology; Vol. 2, Nr. 4 . BPMI. (2004, mei 3). Business Process Modeling Notation (BPMN). URL:
. (18/04/2009). Calvanese, D., Lenzerini, M. & Nardi, D. (1998). Description logics for conceptual data modeling. Logics for Databases and Information Systems .
105
Cardoso, J., Bostrom, R. P. & Sheth, A. (2004). Workflow Management Systems vs. ERP
Systems:
Differences,
Commonalities,
and
Applications.
Information
Technology and Management, Vol. 5, Nr. 3-4, 319-338. Chen, P. P.-S. (1976). The Entity-Relationship Model – Toward a Unified View of Data. Chu-Carroll, M. C. (2007, Oktober 10). Colored Petri Nets. URL: . (5/03/2010). Cohn, D. & Hull, R. (2009). Business Artifacts: A Data-centric Approach to Modeling Business Operations and Processes. Data Engineering. Curtis, G. & Cobham, D. (2008). Business Information System: Analysis, Design and Practice, 6th edition. Harlow, UK: Pearson Education. Davenport, T. H. (1993). Process Innovation: Reengineering Work through Information Technology. Boston: Harvard Business School Press. Davenport, T. H. & Short, J. E. (1990). The New Industrial Engineering: Information Technology and Business Process Redesign. Sloan Management Review, Vol. 31, Nr. 4 (Summer), 11-27. Davis, R. & Brabänder, E. (2007). ARIS Design Platform: Getting Started with BPM. Springer: London. Desel, J. (2005). Process Modeling Using Petri Nets. In M. Dumas, W. M. van der Aalst & A.H. ter Hofstede, PROCESS-AWARE INFORMATION SYSTEMS Bridging People and Software Through Process Technology (p.147-178). New Jersey: John Wiley & Sons. Deutsch, A., Hull, R., Patrizi, F. & Vianu, V. (2009). Automatic Verification of DataCentric Business Processes. ACM International Conference Proceeding Series; Vol. 361, Proceedings of the 12th International Conference on Database Theory , 252267.
106
Dittrich, K. R. (1986). Object-oriented database systems (extended abstract): the notions and the issues. International Workshop on Object-Oriented Database Systems, Proceedings on the 1986 international workshop on Object-oriented database systems, 2-4. Dumas, M., van der Aalst, W. M. & ter Hofstede, A. H. (2005). Introduction. In PROCESS-AWARE INFORMATION SYSTEMS Bridging People and Software through Process Technology (p.3-19). New Jersey: John Wiley & Sons, Inc. Eder, J. & Lehmann, M. (2007). Uniform and Flexible Data Management in Workflow Management Systems. Conceptual Modelling in Information Systems Engineering, 91-106. Ellis, C. A. (1979). Information Control Nets: A Mathematical Model of Office Information Flow. In Proceedings of the Conference on Simulation, Measurement and Modeling of Computer Systems, Boulder, Colorado, ACM Press, 225–240. Engels, G., Förster, A., Heckel, R. & Thöne, S. (2005). Process Modeling Using UML. In M. Dumas, W. M. van der Aalst & A. H. ter Hofstede, PROCESS-AWARE INFORMATION SYSTEMS Bridging People and Software Through Process Technology (p.85-118). New Jersey: John Wiley & Sons. Eriksson, H.-E. & Penker, M. (2000). Business Modeling with UML. Eshuis, R. & Wieringa, R. (2003). Comparing Petri Net and Activity Diagram Variants for Workflow Modelling – A Quest for Reactive Petri Nets. Petri Net Technology for Communication-Based Systems, 321-351. Georgakopoulos, D., Hornick, M. & Sheth, A. (1995). An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases, Vol. 3, 119-153. Gerede, C. E., Bhattacharya, K. & Jianwen, S. (2007). Static Analysis of Business Artifact-centric Operational Models. Business Process Management, Vol. 4714, 288304.
107
Giaglis, G. M. (2001). A Taxonomy of Business Process Modeling and Information Systems Modeling Techniques. International Journal of Flexible Manufacturing Systems, Vol. 13, Nr.2 , 209-228. Grefen, P., Pernici, B. & Sanchez, G. (1999). Database Support for Workflow Management: The WIDE Project. USA: Kluwer Academic Publishers. Halpin, T. (1996). Business Rules and Object Role Modeling. Database Programming & Design. Halpin, T. (1998). Obejct-Role Modeling: an overview. Halpin, T. (2009). Object-Role Modeling. Encyclopedia of Database Systems, . Hammer, M. (1990). Reengineering Work: Don‟t Automate, Obliterate. Harvard Business Review, 104-112. Hammer, M. & Champy, J. (1993). Reengineering the Corporation. Harper Collins Books, New York. Hammer, M., Champy, J. & Brealey, N. (2007). Business process re-engineering. Special Edition, Vol. 15, Nr. 5. Hevner, A. R., March, S. T., Park, J. & Ram, S. (2004). Design Science in Information Systems Research. MIS Quarterly. Holt, A. W. (1985). Coordination Technology and Petri Nets. Advances in Petri Nets, volume 222 of Lecture Notes in Computer Science, 278-296. Ives, B. & Learmonth, G. P. (1984). Information System as a Competitive Weapon. Comunication of the ACM (27), 1193-1201. Jäger, D., Schleicher, A., & Westfechtel, B. (2000). AHEAD: A Graph-Based System for Modeling and Managing Development Processes. Applications of Graph Transformations with Industrial Relevance, 91-94.
108
Jensen, K. (1992). Coloured Petri Nets. Basic concepts, analysis methods and practical use. EATCS monographs on Theoretical Computer Science, SpringerVerlag. Jørgensen, H. (2010, Maart 23). Simplifying BPMN 2.0. URL: . (25/03/2010). Korherr, B. & List, B. (2006). A UML 2 Profile for Event Driven Process Chains. Research and Practical Issues of Enterprise Information Systems, 161-172. Kristensen, L. M., Christensen, S. & Jensen, K. (1998). The practitioner's guide to coloured Petri nets. International Journal on Software Tools for Technology Transfer, 98-132. Kumaran, S., Liu, R. & Wu, F. Y. (2008). On the Duality of Information-Centric and Activity-Centric Models of Business Processes. Advanced Information Systems Engineering, 32-47. Levene, M. & Loizou, G. (1999). A Guided Tour Of Relational Databases And Beyond. London: Springer. Limburg, D., Sikkel, K., Ramaekers, M. & Eertink, P. (2002). Case handling of gewoon workflow? Situatiefactoren geven de doorslag. Informatie. Liu, R., Bhattacharya, K. & Wu, F. Y. (2007). Modeling Business Contexture and Behavior Using Business Artifacts. Advanced Information Systems Engineering, Vol. 4495 , 324-339. Lonjon, A. (2004). Business Process Modeling and Standardization. BPTrends . Loos, P. & Thomas, A. (1998). An approach for integration UML and Event-Driven Process Chains (EPC). URL: <wi.bwl.uni.mainz.de/publikatione/iwih144.pdf>. (3/04/2009). Magnani, M. & Montesi, D. (2007). BPM + DM = BPDM. Technical Report .
109
Melão, N. & Pidd, M. (2000). A Conceptual Framework For Understanding Business Processes And Business Process Modelling. Info System 10 , 105-110. Miers, D. (2010). Understanding BPMN: A Primer. URL: . (2/05/2010) Moody, D. L. (1998). Metric for evaluating the quality of entity relationship models. Proceedings 17th International Conference Conceptual Modeling. Müller, D., Reichert, M. & Herbst, J. (2008). A New Paradigm for the Enactment and Dynamic Adaptation of Data-Driven Process Structures. Advanced Information Systems Engineering, 48-63. Müller, D., Reichert, M. & Herbst, J. (2006). Flexibility of Data-driven Process Structures. Business Process Management Workshops, 181-192. Müller, D., Reichert, M. & Herbst, J. (2010). Data-driven Modeling and Coordination of Large Process Structures. On the Move to Meaningful Internet Systems 2007: CoopIS, DOA, ODBASE, GADA, and IS, 131-149. Mulyar, N. A. & van der Aalst, W. M. (2005a). Towards a Pattern Language for Colored Petri Nets. Mulyar, N. A. & van der Aalst, W. M. (2005b). Patterns in Colored Petri Nets. BETA Working Paper Series, WP 139. Oberweis, A. (2005). Person-to-Application Processes: Workflow Management. In M. Dumas, v. d. Wil & A. H. ter Hofstede, PROCESS-AWARE INFORMATION SYSTEMS Bridging People and Software Through Process Technology (p.21-36). New Jersey: John Wiley & Sons. Olle, T. W. (1996). Fundamentals of Data and Process Modeling. Workshop in Seattle, 9-12. OMG. (2009, augustus). Business Process Model and Notation (BPMN), FTF Beta URL: (15/04/ 2010). 110
OMG. (2004, April 30). UML 2.0 Superstructure Specification. URL: (3/05/2010) OMG. (2005, Juli). Introduction to OMG's Unified Modeling Language™ (UML®). URL: . (2/05/2010). OMG. (2008). Business Process Modeling Notation, V1.1. OMG Available Specification . Ouyang, C. (2005). How to Manipulate Data in YAWL. YAWL Engine Beta 6 and YAWL Editor 1.3 . Owen, M. & Raj, J. (2003). BPMN and Business Process Management: Introduction to the New Business Process Modeling Standard. Popkin Software, 27. Poels, G. (2007). Beleidsinformatica. Reichert, M. & Dadam, P. (1998). ADEPTflex – Supporting Dynamic Changes of Workflows Without Loosing Control. Journal of Intelligent Information Systems, Vol. 10, Nr. 2, 93-129. Reijers, H. A. & Vanderfeesten, I. T. (2004). Cohesion and Coupling Metrics for Workflow Process Design. Lecture Notes in Computer Science, 290-305. Reijers, H. A., Liman, S. & van der Aalst, W. M. (2003). Product-Based Workflow Design. Journal of Management Information Systems, Vol. 20, Nr. 1, 229 - 262. Revenaugh, L. D. (1994). Business Process Re-engineering: The Unavoidable Challenge. Management Decision, Vol. 32, Nr. 7, 16-27. Rinderle, S., & Reichert, M. (2006). Data-Driven Process Control and Exception Handling in Process Management Systems. Advanced Information Systems Engineering , 273-287. Russell, N. C. (2007). Foundations of process-aware information systems. Faculty of Infomation Technology, Queensland, University of Technology Brisbane, Australia . 111
Russell, N. & ter Hofstede, A. H. (2009). newYAWL: Towards Workflow 2.0. Transactions on Petri Nets and Other Models of Concurrency II, 79-97.
Russell, N., ter Hofstede, A. H. & van der Aalst, W. M. (2007b). newYAWL: Specifying a Workflow Reference Language using Coloured Petri Nets. Eighth Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools, 107-126. Russell, N., ter Hofstede, A. H., Edmond, D. & van der Aalst, W. M. (2006). Workflow Data Patterns (Revised Version). Russell, N., ter Hofstede, A. H. van der Aalst, W. M. & Edmond, D. (2007a). newYAWL: Achieving Comprehensive Patterns Support in Workflow for the ControlFlow, Data and Resource Perspectives. Russell, N., van der Aalst, W. M., ter Hofstede, A. H. & Wohed, P. (2006). On the Suitability of UML 2.0 Activity Diagrams for Business Process Modelling. Conferences in Research and Practice in Information Technology Series; Vol. 166. Sadiq, S., Orlowska, M., Sadiq, W. & Foulger, C. (2004). Data Flow and Validation in Workflow Modelling. ACM International Conference Proceeding Series; Vol. 52; Proceedings of the 15th Australasian database conference; Vol. 27, 207 - 214. Scheer, A.W., Thomas, O. & Adam, O. (2005). Process Modeling Using EventDriven Process Chains. In M. Dumas, W. M. van der Aalst & A. H. ter Hofstede, PROCESS-AWARE INFORMATION SYSTEMS Bridging People and Software Through Process Technology (p.119-146). New Jersey: John Wiley & Sons. Sun, S. X., Zhao, J. L., Nunamaker, J. F. & Liu Sheng, O. R. (2006). Formulation the Data-Flow Perspective for Business Process Management. Information System Reseach, Vol. 17, Nr. 4, 374-391. Trcka, N., van der Aalst, W. M. & Sidorova, N. (2008). Analyzing Control-Flow and Data-Flow in Workflow Processes in a Unified Way. Technical Report CS 08/31.
112
Umble, E. J., Haft, R. R. & Umble, M. M. (2003). Enterprise resource planning: Implementation procedures and critical success factors. European Journal of Operational Research 146, 241–257. van der Aalst, W. M. (1997). Designing workflows based on product structures. van der Aalst, W. M. (1998). The Application of Petri Nets to Workflow Management. The Journal of Circuits, Systems and Computers, 8(1), 21-66. van der Aalst, W. M. (1999). On the automatic generation of workflow processes based on product structures. Computers in Industry; Vol. 39, Nr. 2, 97-111. van der Aalst, W. M. & ter Hofstede, A. H. (2005). YAWL: yet another workflow language. Information Systems 30, 245–275. van der Aalst, W. M. & van Hee, K. (2002). Workflow Management: Models, Methods, and Systems. Cambrigde: MIT Press. van der Aalst, W. M., Mathias, W. & Dolf, G. (2004). Case handling: a new paradigm for business process support. Data & Knowlegde Engereering, Vol. 53, Nr. 2, 129162. van der Aalst, W. M., ter Hofstede, A. H. & Weske, M. (2003). Business Process Management: A Survey. Lecture Notes in Computer Schience, Business Process Management, Vol. 2678 . Van Der Meer, K. (2002). Documentaire Informatiesystemen. Den Haag: Biblion Uitgeverij. van Hee, K., Oanea, O. & Sidorova, N. (2005). Colored Petri Nets to Verify Extended Event-Driven Process Chains. On the Move to Meaningful Internet Systems 2005: CoopIS, DOA, and ODBASE, 183-201. Vanderfeesten, I., Reijers, H. A. & van der Aalst, W. M. (2008a). An evaluation of case handling systems for product based workflow design. Enterprise Information Systems .
113
Vanderfeesten, I., Reijers, H. A. & van der Aalst, W. M. (2008b). Product Based Workflow Support: Dynamic Workflow Execution. Advanced Information Systems Engineering , 571-574. Vanderfeesten, I., Reijers, H. A. & van der Aalst, W. M. (2008c). Product Based Worlkflow Support: A Recommendation Service for Dynamic Workflow Execution. Advanced Information Systems Engineering Vol. 5074, 571-574. Vanderfeesten, I., van der Aalst, W. M. & Reijers, H. A. (2005). Modelling a product based workflow system in CPN tools. Sixth Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools , 99-118. Verduin,
R.
(2006).
Business
Process
Modeling
het
modelleren
van
bedrijfsprocessen. Software Release Magazine 8, Java Magazine 4, 31-34. Wand, Y., & Weber, R. (2002). Research commentary: Information Systems and Conceptual Modeling - A Research Agenda. Information Systems Research, Vol.13, Nr.4, 363. Wang, J., & Kumar, A. (2005). A Framework for Document-Driven Workflow Systems. Business Process Management, 285-301. Weber, B., Rinderle, S., & Reichert, M. (2007). Change Patterrns and Change Support Features in Process-Aware Information Systems. Advanced Information Sustems Engineering, Vol. 4495, 574-588. White, S. A. (2004). Introduction to BPMN. Bptrends . White, S. A. (2006). OMG BPMN Tutorial. URL: . (3/04/2009). Wohed, P., van der Aalst, W. M., Dumas, M., ter Hofstede, A. H., & Russell, N. (2006). On the Suitability of BPMN for Business Process Modelling. Proceedings 4th International Conference on Business Process Management, 161-176.
114
Worboys, M. F., Hearnshaw, H. M., & Maguire, D. J. (1990). Object-Oriented Data Modelling for Spatial Databases. International Journal of Geographical Information Systems, Vol. 4, Nr. 4, 369-383. Zisman, M. D. (1977). Representation, specification and automation of office procedures. University of Pennsylvania, Warton School of Business, 218-224. zur Muehlen, M., & Recker, J. (2008). How Much Language is Enough? Theoretical and Practical Use of the Business Process Modeling Notation. In Proceedings 20th International Conference on Advanced Information Systems Engineering, 465-479.
115
