Upload
others
View
27
Download
0
Embed Size (px)
Citation preview
UNIVERSITEIT GENT
FACULTEIT ECONOMIE EN BEDRIJFSKUNDEACADEMIEJAAR 2009-2010
Evolutie van programmeren gaande van mainframestot BPMS gedreven application development: een
literatuurstudie
Masterproef voorgedragen tot het bekomen van de graad van
Master in de Toegepaste Economische Wetenschappen: Handelsingenieur
Elien Dequidt
onder leiding van
Prof. dr. G. Poels en K. Decreus
PERMISSION
Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of
gereproduceerd worden, mits bronvermelding.
Elien Dequidt
Woord vooraf
Deze thesis heb ik niet kunnen verwezenlijken zonder de steun van enkele mensen rondom mij.
Een woord van dank is hier dan ook op zijn plaats.
In de eerste plaats wens ik mijn co-promotor Ken Decreus te bedanken voor de begeleiding en
feedback die hij mij gegeven heeft tijdens het schrijven van deze thesis.
Verder wil ik Eddy Barbry, Eddy Breemersch en Koen Dequidt bedanken voor de tijd die zij
hebben vrijgemaakt om een kritische blik te werpen op mijn thesis.
Natuurlijk richt ik ook een woordje van dank aan mijn ouders en mijn vriend zonder wiens
morele en financiele steun ik deze studies niet tot een goed einde kon brengen.
i
Inhoudsopgave
Woord vooraf i
Inhoudsopgave ii
Gebruikte afkortingen vi
Lijst van figuren vii
Lijst van tabellen ix
Inleiding 1
1 Algemene systeemtheorie 5
1.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Oorsprong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Verschillende opvattingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Opvatting Ludwig von Bertalanffy . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Opvatting Boulding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 Opvatting Churchman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.4 Opvatting Hall en Fagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.5 Opvatting Wieringa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.6 Vergelijking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Uitwerking opvatting Wieringa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.2 Structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.3 Grens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.4 Functie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.5 Gedrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4.6 Waarom, wat en hoe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
ii
Inhoudsopgave iii
1.4.7 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2 Bedrijfsproces 22
2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Bedrijfsproces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 Definitie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Procesgeorienteerde organisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1 Evolutie naar procesgeorienteerde organisatie . . . . . . . . . . . . . . . . 27
2.4 Relaties tussen bedrijfsproces en systeem . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.1 Relatie tussen procesorientatie en systeemtheorie . . . . . . . . . . . . . . 31
2.4.2 Relatie tussen bedrijfsproces en systeem . . . . . . . . . . . . . . . . . . . 32
2.4.3 Toepassing van de systeemtheorie op een bedrijfsproces: voorbeeld . . . . 33
2.5 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3 Mainframes 39
3.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Definitie mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Mainframe system/360 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.1 Subelementen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.2 Relatie en interne interacties . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.3 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5 Grens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.1 Omgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.2 Externe interacties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.3 Dynamisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5.4 Modulair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5.5 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.6 Functie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6.1 Functies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6.2 Gebruikers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.6.3 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.7 Gedrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Inhoudsopgave iv
3.7.1 Toestand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.7.2 Acties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.7.3 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.8 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4 Business Process Management Systems 60
4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Definitie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3 Structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.1 Subelementen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.2 Relatie en interne interacties . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.3 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4 Grens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.1 Omgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.2 Externe Interacties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4.3 Dynamisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.4.4 Modulair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.4.5 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.5 Functie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.5.1 Functies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.5.2 Gebruikers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.5.3 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.6 Gedrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.6.1 Toestand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.6.2 Acties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.6.3 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.7 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5 Vergelijking mainframe en BPMS 83
5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2 Werkwijze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.2.1 Voorbeeld en assumpties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.3 Structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.3.1 Subelementen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.2 Relatie en interne interacties . . . . . . . . . . . . . . . . . . . . . . . . . 91
Inhoudsopgave v
5.4 Grens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.4.1 Omgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.4.2 Externe interacties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4.3 Dynamisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.4 Modulair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.5 Functie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.5.1 Functies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.5.2 Gebruikers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.6 Gedrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.6.1 Toestand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.6.2 Acties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.7 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Besluit 115
Bibliografie xi
Gebruikte afkortingen
ALU = Arithmetic and Logical Unit
BAM = Business Activity Monitoring
BOS = Basic Operating System
BPEL = Business Process Execution Language
BPM = Business Process Management
BPMN = Business Process Modeling Notation
BPMS = Business Process Management Systems
BPR = Business Process Reengineering
BPS = Basic Programming Support
CPU = Central Processing Unit
CRM = Customer Relationship Management
DMAIC = Define, Measure, Analyze, Improve, Control
DOS = Disk Operating System
EAI = Enterprise Application Integration
IBM = International Business Machines Corporation
i/o = input/output
KPI = Key Performance Indicator
OS/360 = Operating System/360
TOS = Tape Operating System
TQM = Total Quality Management
WSDL = Web Service Definition Language
vi
Lijst van figuren
1 De implementatiehierarchie doorheen de thesis . . . . . . . . . . . . . . . . . . . 1
1.1 De link tussen systeemstructuur, systeemfunctie en systeemgedrag (Wieringa,
1996-2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 Een autoverhuurproces uitgewerkt met BPMN . . . . . . . . . . . . . . . . . . . 25
2.2 De value chain van Porter (Harmon, 2007) . . . . . . . . . . . . . . . . . . . . . 28
2.3 De decompositie van de value chain (Harmon, 2007) . . . . . . . . . . . . . . . . 33
2.4 Een autoverhuurproces uitgewerkt met BPMN . . . . . . . . . . . . . . . . . . . 34
3.1 Mainframe system/360 (IBM-website, 2010) . . . . . . . . . . . . . . . . . . . . . 41
3.2 Mainframe system/360 met subelementen (IBM-DPD, 1964) . . . . . . . . . . . . 42
4.1 Het BPMS van Intalio met de twee subelementen . . . . . . . . . . . . . . . . . . 61
4.2 Intalio|Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3 Intalio|Console (Intalio-website, 2010) . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4 Intalio|Workflow (Intalio-website, 2010) . . . . . . . . . . . . . . . . . . . . . . . 65
4.5 Een voorbeeld van een dashboard in een BAM systeem (Intalio-website, 2010) . . 67
4.6 Een voorbeeld van een beslissingstabel in het systeem dat de bedrijfsregels bevat
(Intalio-website, 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.7 Een KPI toevoegen vanuit het BAM systeem naar de Intalio|Designer (Intalio-
website, 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.8 Een voorbeeld van een externe interactie waarbij een beslissingstabel wordt op-
geroepen (Intalio-website, 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.9 Een BPMS ondersteunt de hele levenscyclus van een proces (Vollmer & Peyret,
2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.10 Intalio|Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.1 De implementatiehierarchie doorheen de thesis . . . . . . . . . . . . . . . . . . . 84
vii
Lijst van figuren viii
5.2 Een autoverhuurproces als voorbeeld om de vergelijking tussen een mainframe en
een BPMS te duiden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Lijst van tabellen
1.1 Implementatiehierarchie vanuit het standpunt van een software-ingenieur (Wie-
ringa, 1996-2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Samenvattende tabel voor het structuuraspect . . . . . . . . . . . . . . . . . . . . 13
1.3 Samenvattende tabel voor het grensaspect . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Samenvattende tabel voor het functieaspect . . . . . . . . . . . . . . . . . . . . . 16
1.5 Samenvattende tabel voor het gedragsaspect . . . . . . . . . . . . . . . . . . . . . 17
1.6 Link waarom, wat en hoe met de implementatiehierarchie van Wieringa (1996-2006) 19
1.7 Een overzicht van de belangrijkste elementen uit de opvatting van Wieringa . . . 20
2.1 De kenmerken van het proces denken ten opzichte van de kenmerken van het
functionele denken (McCormack, 2001) . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2 Procesverbetering versus procesinnovatie (Davenport, 1993) . . . . . . . . . . . . 29
2.3 Toepassing van de opvatting van Wieringa (1996-2006) op een bedrijfsproces . . 37
3.1 Structuuraspect mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Grensaspect mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3 Functie mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.4 Gedrag mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.5 Toepassing van de opvatting van Wieringa (1996-2006) op het mainframe sys-
tem/360 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1 Structuuraspect BPMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2 Grensaspect BPMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.3 Functie BPMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.4 Gedrag BPMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.5 Toepassing van de opvatting van Wieringa (1996-2006) op het BPMS van Intalio 80
5.1 Vergelijking van het mainframe system/360 met het BPMS voor het structuuraspect 88
ix
Lijst van tabellen x
5.2 Vergelijking van het mainframe system/360 met het BPMS voor het grensaspect 93
5.3 Vergelijking van het mainframe system/360 met het BPMS voor het functieaspect 102
5.4 Vergelijking van het mainframe system/360 met het BPMS voor het gedragsaspect107
5.5 Vergelijking van het mainframe system/360 met het BPMS van Intalio aan de
hand van de tabel vanuit de opvatting van Wieringa (1996-2006) . . . . . . . . . 112
Inleiding
Context
De context van deze thesis wordt op figuur 1 als volgt weergegeven:
Figuur 1: De implementatiehierarchie doorheen de thesis
Reeds enkele decennia geleden merkte men op dat in onderzoek en wetenschap de specialisatie
enorm doorgedreven was en daardoor ging de algemene focus verloren. Dit leidde tot de ontwik-
keling van de systeemtheorie waar principes worden geıdentificeerd die toepasbaar zijn op een
systeem in het algemeen, onafhankelijk van een specifieke vakdiscipline (Bertalanffy, 1968). Een
dergelijk systeem kan gedefinieerd worden als “een georganiseerde collectie van interagerende
1
Inleiding 2
subelementen” (Wieringa, 1996-2006, p.13).
Wanneer we meer in detail treden en dit systeemdenken toepassen op het bedrijfsleven, merken
we ook daar specialisatie. Vaak zijn bedrijven namelijk georganiseerd volgens functies met de
klassieke organogrammen om dit weer te geven (Harmon, 2003). Deze toestand ontstond onder
invloed van onder andere Adam Smith die stelde dat, wanneer iedere werknemer zijn eigen klein
stukje werk heeft, er een grotere efficientie kan worden bereikt (Hammer & Champy, 2003).
Hierbij is de organisatie eerder intern georienteerd waarbij het gemeenschappelijke doel, namelijk
de klant, op de achtergrond verdwijnt. Gezien de klant belangrijker werd in het bedrijfsleven,
ontstond er een geleidelijke overschakeling van de functionele orientatie naar de procesorientatie.
Een dergelijke organisatie denkt in functie van processen en is klantengeorienteerd (McCormack,
2001). Smith & Fingar (2007) definieren zo een bedrijfsproces als “de complete en dynamisch
gecoordineerde verzameling van samenwerkende en transactionele activiteiten die waarde creeren
voor de klant” (Smith & Fingar, 2007, p.47).
Een dergelijk bedrijfsproces bestaat dan weer uit informatiesystemen en niet-informatiesystemen.
Informatiesystemen zorgen voor het verzamelen van gegevens die verwerkt worden om dan weer
op een gestructureerde manier te worden verdeeld. Vaak zijn het de niet-informatiesystemen,
zoals mensen, die deze informatie gebruiken.
In deze thesis wordt, zoals de titel duidt, dieper ingegaan op twee soorten informatiesystemen
namelijk een mainframe en een BPMS. De eerste mainframes dateren van 1944 en waren in die
tijd grote machines die bijgevolg veel plaats innamen (IBM-website, 2010). Het BPMS is in
tegenstelling tot de mainframes een recenter informatiesysteem. Dit ondersteunt de Business
Proces Management (BPM) theorie, die vooral focust op het creeren van een beweeglijke orga-
nisatie zodat deze zich snel kan aanpassen aan de steeds veranderende omgeving van vandaag
de dag (Smith & Fingar, 2007).
Onderzoeksvraag
Een BPMS en de bijhorende BPM theorie kunnen bedrijven voor een stuk helpen in tijden van
economische crisis. Het lijkt ons interessant om deze nieuwe systemen met de reeds bestaande
mainframes te vergelijken, aangezien we vandaag de dag nog steeds te kampen hebben met
economische onzekerheid en het BPMS hierbij een eerste stap is voor bedrijven om hiermee om
te gaan.
Dit leidt tot de onderzoeksvraag van deze thesis namelijk: Wat zijn de gelijkenissen en verschillen
Inleiding 3
tussen een mainframe en een BPMS vanuit het standpunt van de systeemtheorie?
Methodologie
Om een antwoord te formuleren op de onderzoeksvraag worden in deze thesis drie stappen
doorlopen.
Vooreerst wordt een raamwerk uitgewerkt vanuit de systeemtheorie om een tabel van elementen
te creeren, dat kan worden gebruikt om een mainframesysteem een een BPMS te vergelijken.
Na het analyseren van enkele opvattingen in de systeemtheorie werd de opvatting van Wieringa
(1996-2006) gekozen als referentiekader voor deze vergelijking.
Hierna wordt een specifiek mainframesysteem, namelijk het mainframe system/360, en een spe-
cifiek BPMS, namelijk het BPMS van Intalio, besproken om inzicht te verwerven in elk van de
systemen.
Aan de hand van de opgestelde tabel vanuit de opvatting van Wieringa (1996-2006), worden in
een volgende stap de twee specifieke systemen vergeleken. Hierbij wordt ook gebruik gemaakt
van een voorbeeld om de vergelijking beter te duiden en toe te passen in de praktijk.
Bijdrage en beperkingen
Gezien er nog geen bruikbare literatuur aanwezig is die deze twee systemen expliciet met elkaar
vergelijkt, geeft deze thesis een eerste inzicht in dit onderwerp. Hierbij worden gelijkenissen en
verschillen van de twee systemen weergegeven op basis van vier aspecten, namelijk: structuur-
aspect, grensaspect, functieaspect en gedragsaspect.
De voornaamste beperking voor het schrijven van de thesis was het gebrek aan algemeen aan-
vaarde literatuur. Voor mainframes wordt er vaak heel specifiek over een bepaald onderdeel
geschreven, waarbij deze literatuur vaak technisch is opgesteld. Voor BPMSs, zijn er nog weinig
papers beschikbaar gezien het een recent begrip is en de BPM theorie nog steeds in ontwikkeling
is.
De voornaamste beperking van de thesis zelf is het gebruik van een specifiek mainframesysteem
en een specifiek BPMS. Bovendien worden deze ook slechts op een manier vergeleken, namelijk
via de opvatting van Wieringa (1996-2006).
Structuur van de thesis
In wat volgt wordt de volgende structuur aangenomen:
Inleiding 4
In hoofdstuk 1 over systeemtheorie wordt aangevangen met een korte uitleg over de oorsprong
van deze theorie. Hierna worden enkele opvattingen binnen deze theorie besproken waarna de
opvatting van Wieringa (1996-2006) in detail wordt uitgewerkt.
In hoofdstuk 2 wordt meer in detail getreden en wordt het onderwerp bedrijfsproces besproken.
Het vangt aan met enkele definities waarna het begrip procesorientatie en de evolutie hierrond
wordt uitgewerkt. Het hoofdstuk eindigt met de relatie tussen een bedrijfsproces en een systeem.
In hoofdstuk 3 en 4 worden respectievelijk het mainframesysteem en het BPMS besproken. Voor
elk van deze wordt een specifiek systeem uitgewerkt aan de hand van de tabel opgesteld vanuit
de opvatting van Wieringa (1996-2006) in hoofdstuk 1. Voor een mainframesysteem is dit het
mainframe system/360 gezien dit een grote mijlpaal was in de computergeschiedenis (Eddolls,
2009). Voor het BPMS wordt het Intalio BPMS uitgewerkt omdat dit een van de enige volledig
uitgewerkte open source BPMSs is (Hill et al., 2009).
In het laatste hoofdstuk worden deze twee systemen met elkaar vergeleken, wat ook het uitein-
delijke doel is van deze thesis.
Hoofdstuk 1
Algemene systeemtheorie
1.1 Inleiding
In dit eerste hoofdstuk wordt de basis gelegd voor de volgende hoofdstukken in deze thesis.
Vooreerst wordt de oorsprong van het onderwerp systeemtheorie kort verklaard. Vervolgens
worden enkele opvattingen vermeld waarbij in een volgend deel dieper wordt ingegaan op de
opvatting van Wieringa (1996-2006). De begrippen die Wieringa gebruikt, worden uitgelegd en
vormen een tabel die voor het vervolg van deze thesis gebruikt wordt.
1.2 Oorsprong
Reeds enkele decennia geleden merkte men op dat in onderzoek en wetenschap de specialisatie
enorm doorgedreven was (Bertalanffy, 1968). Vandaag de dag is dit nog steeds zo. Denk maar
aan de verschillende vakdisciplines waarin men kan specialiseren, zoals fysica, biologie, filosofie,
informatica en economie die nog maar een fractie voorstellen van alle specialisaties die er bestaan.
Deze wirwar aan specialisaties roept de vraag op of deze evolutie van specialisaties niet te ver
is doorgedreven.
Bertalanffy (1968), die wordt gezien als de grondlegger van de systeemtheorie, geeft hierop een
antwoord. Hij toont aan dat de specialisatie noodzakelijk was door de enorme hoeveelheid
gegevens en de alsmaar complexere technologieen die ontstonden. Deze specialisaties hebben
er echter voor gezorgd dat de algemene focus werd verloren. Elke specialist zit in zijn eigen
vakgebied met zijn eigen kennis, waardoor de communicatie tussen de verschillende specialisaties
nagenoeg onbestaand is.
Het resultaat van deze evolutie is dat onafhankelijk van elkaar, gelijkaardige denkwijzen en the-
orieen ontwikkeld worden in de verschillende specialisaties (Bertalanffy, 1968). Daarom stelt
5
Hoofdstuk 1. Algemene systeemtheorie 6
bijvoorbeeld Bertalanffy (1968) de algemene systeemtheorie voor. Deze heeft als doel de princi-
pes te identificeren die toepasbaar zijn op een systeem in het algemeen, onafhankelijk van een
specifieke vakdiscipline. Er wordt dus als het ware een nieuwe wetenschap gecreeerd die alle ver-
schillende specialisaties integreert zonder hiervoor de huidige vakdisciplines te laten verdwijnen.
Dit lange-termijn doel wordt onder andere verwezenlijkt door The Society for the Advance-
ment of General System Theory opgericht in 1954 (Keuning, 1973). Het grote gevolg van deze
eenmaking der wetenschappen is dat duplicatie wordt vermeden en communicatie tussen de
vakdisciplines wordt bevorderd (Keuning, 1973; Bertalanffy, 1968).
1.3 Verschillende opvattingen
Alhoewel het streven naar een eenmaking der wetenschappen het doel is van de algemene sys-
teemtheorie, heersen er onder auteurs verschillende opvattingen over wat de algemene systeem-
theorie inhoudt. Volgens Keuning (1973) zijn de twee voornaamste opvattingen de algemene
systeemtheorie in de enge zin en de algemene systeemtheorie in de ruime zin. In de enge zin
ligt de focus op de algemene principes toepasbaar op alle systemen zoals beschreven in punt
1.2. De ruime zin breidt de enge zin uit met enkele speciale theorieen waarvan de voornaams-
te cybernetica, informatietheorie en speltheorie zijn. De grondleggers van deze theorieen zijn
respectievelijk Wiener, Shannon en Weaver, en Neumann en Morgenstern (Bertalanffy, 1968).
Zoals uit punt 1.2 blijkt, staat binnen de algemene systeemtheorie het begrip systeem centraal.
Ook hier zijn er echter verschillende opvattingen over de definitie en kenmerken van deze centrale
term.
1.3.1 Opvatting Ludwig von Bertalanffy
Bertalanffy (1968) definieert een systeem als “een verzameling van elementen die in interrelatie
staan” (Bertalanffy, 1968, p.37). Volgens Bertalanffy is het niet voldoende de elementen van
een systeem te identificeren, maar zijn ook de relaties tussen deze elementen belangrijk. Hij
duidt hiermee op het principe ‘het geheel is meer dan de som van de onderdelen’. Wanneer
de onderdelen en de relaties tussen deze onderdelen gekend zijn, dan kan het gedrag van het
systeem hieruit afgeleid worden.
Een concept dat volgens Bertalanffy niet mag ontbreken, is een hierarchische volgorde van sys-
temen waarbij elk niveau de vorige niveaus omvat. Deze hierarchische volgorde omvat negen
niveaus die een vaste opsomming vormen. Hiermee wordt bedoeld dat de negen niveaus die
Bertalanffy weergeeft telkens dezelfde zijn en bijgevolg een vaste structuur vormen.
Hoofdstuk 1. Algemene systeemtheorie 7
1.3.2 Opvatting Boulding
De orginele Engelse definitie die Boulding in het boek van Mesarovic (1964) geeft voor het begrip
systeem zegt: “A system is a big black box of which we can’t unlock the locks, and all we can
find out about is what goes in and what comes out. Perceiving input-output pairs, related by
parameters, permits us, sometimes, to relate an input, output, and a state. If this relation’s
good and stable then to predict we may be able, but if this fails us-heaven forbid! We’ll be
compelled to force the lid!” (Mesarovic, 1964, p.39).
Boulding (2003) is vooral bekend door zijn hierarchie van systemen die hij opstelt. De volgorde
die hij opstelt, is een vaste opsomming van negen niveaus die gaan van systemen die weinig
complex zijn, naar systemen die uitermate complex zijn. Hierbij bestaat elk individueel systeem
van een bepaald niveau uit een verzameling van elementen van een lager gelegen niveau van de
hierarchie.
Boulding (2003) vermelt ook kort dat zo een individueel systeem interageert met een omgeving
die bestaat uit andere individuele systemen waar dit systeem mee in contact komt. Deze indivi-
duele systemen vertonen een gedrag dat gerelateerd is aan de omgeving waar het mee interageert
en verklaard wordt door de structuur en samenhang van de elementen waaruit het bestaat.
1.3.3 Opvatting Churchman
Churchman (1968) defineert een systeem als volgt: “Een systeem bestaat uit een verzameling
van componenten die samenwerken voor het doel van het geheel” (Churchman, 1968, p.11).
Naast de componenten van het systeem zijn er volgens Churchman nog vier andere elementen
die moeten worden vermeld wanneer men over een systeem spreekt, namelijk: de omgeving, de
doelen, de hulpmiddelen en het management van het systeem.
De omgeving is moeilijk te achterhalen en wordt volgens Churchman gedefinieerd als hetgeen
het systeem niet kan beınvloeden en dus als het ware gegeven is. Om te helpen bepalen of iets in
de omgeving ligt of niet, zijn er twee vragen die moeten worden beantwoord: ‘Kan ik er iets aan
doen?’ en ‘Is het belangrijk gezien mijn doelen?’. Is het antwoord op de eerste vraag ja en op de
tweede vraag nee, dan ligt het element in de omgeving. De doelen van een systeem zijn ook niet
gemakkelijk te achterhalen aangezien de opgegeven doelen vaak niet de echte zijn. Zo kan het
opgegeven doel van een onderneming zijn ‘de beste kwaliteit te leveren aan de klanten’ terwijl
het echte, reele doel is ‘een zo groot mogelijke winstmarge te creeren’. De hulpmiddelen zitten
in het systeem, dit in tegenstelling tot de omgeving die buiten het systeem ligt. Voorbeelden
Hoofdstuk 1. Algemene systeemtheorie 8
van hulpmiddelen zijn: geld en werkuren. Deze hulpmiddelen worden door de componenten van
het systeem gebruikt om acties uit te voeren. Om zeker te zijn dat een component goed werkt,
worden richtlijnen opgesteld voor elk component. Dit alles wordt geregeld door het management
dat de doelen bepaalt, de hulpmiddelen toewijst en de richtlijnen controleert.
1.3.4 Opvatting Hall en Fagen
Volgens Hall & Fagen (2003) wordt een systeem gedefinieerd als “een verzameling van objecten
met relaties tussen deze objecten en tussen hun attributen” (Hall & Fagen, 2003, p.63). De
attributen stellen kenmerken voor van de objecten. Zo heeft het object fietsband bijvoorbeeld
een bandenspanning en een kleur als attribuut.
Hall en Fagen voegen aan hun definitie de term omgeving toe. Volgens hen is de omgeving van
een systeem “de verzameling van alle objecten waarvan een verandering in hun attributen het
systeem beınvloedt en ook de objecten waarvan de attributen worden beınvloed door het gedrag
van het systeem” (Hall & Fagen, 2003, p.66). Hier kan de omgeving het systeem beınvloeden en
omgekeerd.
1.3.5 Opvatting Wieringa
Wieringa (1996-2006) gebruikt in zijn boek verscheidene definities voor het begrip systeem.
Een eerste definitie stelt: “Een systeem is gedefinieerd als elk werkelijk of mogelijk deel van
de realiteit dat, als het bestaat, kan worden geobserveerd” (Wieringa, 1996-2006, p.10). Deze
definitie resulteert uit het feit dat Wieringa zich beperkt tot het beschrijven van observeerbare
systemen. Hierbij betekent de term observatie een interactie van het systeem met zijn omgeving.
Een andere definitie die Wieringa gebruikt, zegt dat “een systeem een georganiseerde collectie
van interagerende subelementen is” (Wieringa, 1996-2006, p.13).
Het is ook interessant te bemerken dat Wieringa een hierarchie van systemen definieert. Volgens
Wieringa zijn er verschillende niveaus waaruit de wereld is opgebouwd, waarbij een systeem op
een bepaald niveau bestaat uit systemen van een lager niveau. Wieringa gebruikt dan ook het
woord implementatiehierarchie in plaats van een hierarchie van systemen. Hij geeft geen vaste
opsomming van niveaus en bijgevolg is er dan ook geen vaste implementatiehierarchie mogelijk.
Je kunt verschillende hierarchieen maken, afhankelijk van het standpunt dat je inneemt. Bo-
vendien is elke hierarchie die je maakt een vereenvoudiging. Een voorbeeld van een hierarchie
die Wieringa gebruikt voor zijn boek is een hierarchie vanuit het standpunt van een software-
ingenieur. Deze hierarchie wordt weergegeven in tabel 1.1.
Hoofdstuk 1. Algemene systeemtheorie 9
Tabel 1.1: Implementatiehierarchie vanuit het standpunt van een software-ingenieur (Wieringa, 1996-
2006)
NIVEAU VOORBEELDEN
Sociaal systeem Een organisatie
Computersysteem Een vliegsimulator
Softwaresysteem Een databasesysteem
Softwaresubsysteem Een planner
Een software-ingenieur houdt zich, zoals het woord zelf zegt, onder andere bezig met het ont-
wikkelen van software. De meeste systemen die een software-ingenieur bouwt, zijn bedoeld voor
mensen. Het eerste niveau in het voorbeeld dat Wieringa geeft, is een sociaal systeem. Een vol-
gend niveau, namelijk de producten waaruit het sociaal systeem bestaat, die relevant zijn voor
de software-ingenieur, zijn onder andere computersystemen. In een volgend niveau kunnen deze
computersystemen onderverdeeld worden in softwaresystemen. Een laatste niveau dat Wieringa
hier definieert, is het softwaresubsysteem. Dit voorbeeld van een hierarchie is slechts een van
de vele mogelijke voorbeelden, aangezien elke hierarchie een vereenvoudiging is waarbij enkel
de systemen waarvoor we op dit moment geınteresseerd zijn, worden weergegeven. Wieringa
definieert nergens dat een implementatiehierarchie alle mogelijke niveaus moet beschrijven. Bij-
gevolg zijn er voor dit voorbeeld ook lagere en hogere niveaus mogelijk dan de reeds beschreven
niveaus.
Als extra elementen om een systeem verder te duiden, gebruikt Wieringa onder andere de termen
omgeving, gedrag en functie. Om te beginnen wordt de omgeving gedefinieerd als het deel van
de wereld waar het systeem mee interageert waarbij deze interactie zowel door de omgeving
als door het systeem zelf kan worden gestart. Als gevolg hiervan kun je volgens Wieringa de
omgeving ook zien als de waarnemer van het systeem, die via interactie met het systeem deze
laatste waarneemt. Vervolgens kan het gedrag van een systeem gezien worden als “de manier
waarop het systeem interageert met de omgeving in de tijd” (Wieringa, 1996-2006, p. 19). Een
eigenschap van het systeem zelf wordt gezien als een aspect van het gedrag. Het stelt eigenlijk
de inhoud van het gedrag voor en wordt ook nog wel attribuut genoemd in softwareomgevingen.
Als laatste wordt de functie of het doel van het systeem besproken. Dit is een element dat
volgens Wieringa niet elk systeem bezit en wordt gedefinieerd als “een dienst die het systeem
aanbiedt aan zijn omgeving” (Wieringa, 1996-2006, p.22). Deze functie van het systeem is niet
voor elke gebruiker dezelfde.
Hoofdstuk 1. Algemene systeemtheorie 10
1.3.6 Vergelijking
Zoals uit het vorige blijkt, hanteren diverse auteurs verschillende definities voor het begrip
systeem. Sommige auteurs voegen extra begrippen toe, andere niet. Keuning (1973) spreekt
dan ook terecht over de ‘systeem jungle’. Bijgevolg worden hier de verschillende, besproken
opvattingen vergeleken om de belangrijkste verschillen en gelijkenissen te duiden. De vergelijking
gebeurt op basis van vijf termen, namelijk: definitie, hierarchie van systemen, omgeving, gedrag
en doelen.
Vooreerst worden de verschillende auteurs vergeleken op basis van het begrip definitie. Alle
auteurs geven een definitie voor het begrip systeem. De inhoud van deze definitie is echter niet
overal gelijk. De twee voornaamste verschillen zijn: het gebruik van verschillende termen voor
elementen van dezelfde aard en het gebruik van termen die niet in andere definities voorkomen.
Vooreerst wordt iets dieper ingegaan op een eerste verschil, namelijk het gebruik van verschillen-
de termen voor elementen van dezelfde aard. Hier kunnen twee voorbeelden worden aangehaald.
Ten eerste wordt door Bertalanffy (1968) en Wieringa (1996-2006) de term elementen gebruikt
waar Churchman (1968) de term componenten gebruikt en Hall & Fagen (2003) de term objec-
ten gebruiken. Ten tweede kan ook een verschil worden gemerkt wat betreft de term relatie.
Zowel Bertalanffy (1968), Hall & Fagen (2003) als Wieringa (1996-2006) gebruiken letterlijk
de term relatie in tegenstelling tot Churchman (1968) die dit vervangt door de samenwerking
tussen de componenten. Het tweede verschil, namelijk het gebruik van elementen die niet in
andere definities voorkomen, kan via drie voorbeelden worden geduid. Ten eerste kunnen uit de
definitie van Boulding in het boek van Mesarovic (1964) de termen input, output, parameters
en toestand gehaald worden, die helemaal niet voorkomen in de andere definities. Ten tweede
gebruiken ook Hall & Fagen (2003) een term die geen enkele andere definitie bevat, namelijk het
begrip attribuut. Er moet worden opgemerkt dat Wieringa (1996-2006) ook de term attribuut
gebruikt, maar niet uitdrukkelijk in zijn definitie. Deze auteurs geven echter wel dezelfde be-
tekenis aan de term, namelijk een kenmerk of eigenschap zoals kleur, grootte, vorm en sterkte
(Wieringa, 1996-2006; Hall & Fagen, 2003). Een laatste voorbeeld komt uit de definitie van
Wieringa (1996-2006) die de enige auteur is die spreekt over observeerbare systemen.
Een volgend element op basis waarvan de verschillende auteurs kunnen worden vergeleken is de
hierarchie van systemen. Enkel drie van de vijf auteurs vermelden een hierarchie van systemen.
Deze zijn: Bertalanffy (1968), Boulding (2003) en Wieringa (1996-2006). De onderverdeling van
Bertalanffy (1968) vertoont sterke gelijkenissen met de onderverdeling die Boulding (2003) heeft
gemaakt. Hieruit kan worden geconcludeerd dat Bertalanffy (1968) zich gebaseerd heeft op de
Hoofdstuk 1. Algemene systeemtheorie 11
hierarchie van Boulding (2003), aangezien deze laatste zijn hierarchie publiceerde in 1956 en
Bertalanffy (1968) pas in 1968 (Bertalanffy, 1968; Boulding, 2003). Het voornaamste verschil
tussen de hierarchie die Wieringa (1996-2006) opstelt en deze die Bertalanffy (1968) en Boulding
(2003) opstellen, is dat de eerste auteur geen vaste opsomming van niveaus geeft en de twee
andere wel. Je kunt dus volgens Wieringa (1996-2006) verschillende hierarchieen maken al
naargelang het standpunt dat je inneemt.
Een derde element op basis waarvan de auteurs kunnen worden vergeleken is de term omgeving.
Wat betreft deze term zijn er vijf auteurs die deze term gebruiken, namelijk: Boulding (2003),
Churchman (1968), Hall & Fagen (2003) en Wieringa (1996-2006). Alle definities duiden aan dat
er een interactie bestaat tussen het systeem en de omgeving, maar enkel Hall & Fagen (2003)
en Wieringa (1996-2006) duiden aan dat deze interactie in beide richtingen gebeurt.
In verband met een vierde term namelijk het gedrag, kan uit de analyse van de besproken op-
vattingen worden geconcludeerd dat enkel Boulding (2003), Hall & Fagen (2003) en Wieringa
(1996-2006) hierover spreken. Deze auteurs vermelden dat het gedrag van een systeem gerela-
teerd is aan de omgeving van het systeem. De andere opvattingen vermelden deze term niet op
een uitdrukkelijke manier.
De laatste term die wordt gebruikt om de verschillende auteurs te vergelijken omvat de doelen van
een systeem. Deze worden slechts door twee auteurs uitdrukkelijk vermeld, namelijk: Churchman
(1968) en Wieringa (1996-2006). Churchman (1968) is de enige die ook nog hulpmiddelen en
management definieert als extra elementen.
Algemeen kan uit deze vergelijking worden geconcludeerd dat de opvatting van Wieringa (1996-
2006) de meeste gelijkenissen vertoont met de andere opvattingen. De enige termen die niet
voorkomen in de opvatting van Wieringa zijn hulpmiddelen en management. Deze komen ook
echter alleen voor in de opvatting van Churchman (1968). De opvatting van Wieringa (1996-
2006) lijkt dus de meest volledige theorie te zijn. Ook is het zo dat de opvatting van Wieringa
consistent is. De verschillende elementen en definities die hij geeft, zijn allemaal mooi gelinkt
met elkaar en vormen een geheel. Bovendien beperkt Wieringa zich tot het beschrijven van
observeerbare systemen. Hierbij betekent de term observatie een interactie van het systeem met
zijn omgeving, waarbij deze interactie zowel door het systeem als door de omgeving zelf kan
worden gestart. Dit is in de context van deze thesis een relevante beperking.
Hoofdstuk 1. Algemene systeemtheorie 12
1.4 Uitwerking opvatting Wieringa
1.4.1 Inleiding
Wieringa (1996-2006) beperkt zijn opvatting tot het definieren van observeerbare systemen,
waarbij deze observatie gebeurt door de omgeving in de vorm van een interactie tussen de
omgeving en het systeem. Om dit begrip observeerbaar systeem verder te duiden, wordt het
bekeken vanuit verschillende perspectieven, namelijk: systeemstructuur (1.4.2), systeemgrens
(1.4.3), systeemfunctie (1.4.4) en systeemgedrag (1.4.5). Tenslotte wordt in punt 1.4.6 het
onderscheid en de relatie tussen de systeemstructuur, de systeemfunctie en het systeemgedrag
samengevat.
1.4.2 Structuur
Vanuit het perspectief systeemstructuur wordt een systeem gedefinieerd als een collectie van
gerelateerde elementen. Deze elementen worden ook wel subelementen genoemd. Deze definitie
toont aan dat elementen en relatie twee belangrijke termen zijn om een systeem te definieren.
Om te beginnen wordt iets dieper ingegaan op de eerste belangrijke term, namelijk de elementen
van het systeem. Elementen zijn de onderdelen van een systeem. Zo bestaat het observeerbaar
systeem fiets uit de elementen zadel, twee wielen, een remsysteem, een frame en een bel. Deze
subelementen kunnen zelf ook systemen zijn die wederom uit componenten bestaan. Hier kan
als voorbeeld het subelement wiel worden genomen, dat zelf een systeem is. Dit wiel heeft als
onderdelen een naaf, spaken, een ventiel, een velg en een band. Deze opdeling kan alsmaar
verder worden toegepast totdat men tot een elementair element komt dat niet meer kan worden
opgedeeld. De grens tussen de verschillende subelementen moet zodanig gekozen worden dat elk
subelement als een onafhankelijke eenheid kan gezien worden.
Vervolgens wordt de term relatie uitgediept. De relatie tussen de elementen is een ander be-
langrijk aspect aangezien er zonder deze relatie geen systeem zou bestaan. Het gedrag van een
systeem wordt namelijk niet alleen bepaald door het gedrag van de onderdelen maar ook door
de interacties van de onderdelen met elkaar. Een verzameling van onderdelen op zich is geen
systeem zolang er geen interactie is tussen deze onderdelen. Neem bijvoorbeeld een zadel, twee
wielen, een remsysteem, een frame en een bel als aparte systemen dan is dit geen fiets. Enkel
wanneer deze aparte systemen op een bepaalde manier met elkaar in relatie worden gezet, krijg
je een fiets. De fiets wordt dus eigenlijk ‘gemaakt’ door zijn onderdelen en de relatie tussen deze
onderdelen.
Hoofdstuk 1. Algemene systeemtheorie 13
De interacties tussen de subelementen worden interne interacties genoemd aangezien deze zich
afspelen in het systeem zelf. Laten we hier als voorbeeld een koffieautomaat nemen om een in-
terne interactie te definieren. Veronderstel dat een waterreservoir en een koffiefilter met gemalen
koffiebonen twee subelementen van een koffieautomaat zijn, dan kan geef water hiertussen een
interne interactie zijn. Deze interactie zorgt ervoor dat het waterreservoir water uitwisselt met
de koffiefilter zodanig dat er koffie kan worden gezet.
De belangrijkste termen onder het structuuraspect kunnen in tabel 1.2 worden samengevat:
Tabel 1.2: Samenvattende tabel voor het structuuraspect
structuur subelementen
relatie
interne interactie
1.4.3 Grens
Om de term observeerbare systemen iets meer te duiden, vergelijkt Wieringa de omgeving met
een waarnemer die het systeem waarneemt door ermee te interageren. Deze systemen kunnen,
naar de definitie van een systeem volgens Wieringa, zowel fysische als ongrijpbare objecten zijn,
zolang deze interageren met andere systemen. Zo zijn bijvoorbeeld de ongrijpbare objecten
databasemanagementsysteem en informatiesysteem observeerbaar, aangezien deze objecten in-
terageren met andere systemen en Wieringa stelt dat vanuit het standpunt van de omgeving een
interactie gelijk is aan een observatie.
Volgens Wieringa heeft zijn definitie drie gevolgen. Vooreerst bestaat een systeem wanneer het
interageert met andere systemen. Aangezien een systeem interageert met andere systemen en
aangezien deze interacties gebeuren in de tijd, is een systeem volgens zijn definitie dynamisch.
Ook moet een systeem altijd een omgeving hebben aangezien het zonder omgeving niet kan
worden geobserveerd en bijgevolg ook niet zou bestaan.
Deze omgeving wordt volgens Wieringa gedefinieerd als het deel van de wereld waarmee het
systeem interageert. De verzameling van interacties tussen deze omgeving en het systeem wordt
de interface of grens genoemd. Aangezien deze interacties niet in het systeem zelf plaatsvinden,
maar tussen het systeem en een extern systeem worden deze interacties ook nog wel externe
interacties genoemd. Een voorbeeld van een externe interactie tussen een koffieautomaat en een
menselijke gebruiker is: geef koffie.
Hoofdstuk 1. Algemene systeemtheorie 14
Wieringa vermelt ook een richtlijn om de grens tussen het systeem en de omgeving te bepalen,
namelijk: “de systeemgrens moet worden bepaald zodat het systeem modulair is” (Wieringa,
1996-2006, p. 12). Deze modulariteit betekent dat het systeem zich min of meer als een onaf-
hankelijke eenheid moet gedragen. Wieringa geeft enkele criteria weer die als richtlijn dienen
om modulariteit te bepalen. De belangrijkste voor deze thesis zijn:
• Interactie tussen de componenten van het systeem (cohesie) is groter dan de interactie
tussen het systeem en de omgeving (koppeling). Bij een koffieautomaat is er bijvoorbeeld
een grotere interactie tussen zijn subelementen dan tussen het systeem zelf en de kamer
waarin de koffieautomaat staat.
• Veranderingen binnen een systeem zouden minimale veranderingen moeten veroorzaken
buiten het systeem. Indien bijvoorbeeld een verandering wordt gemaakt aan de waterko-
ker van het koffieautomaat, dan wordt hierdoor niets veranderd aan de kamer waarin de
koffieautomaat staat.
• Er zijn meer relaties onder de systeemcomponenten onderling dan tussen de systeemcom-
ponenten en de omgeving. Als voorbeeld kan hier opnieuw de koffieautomaat worden
gebruikt. Het aantal mogelijke relaties tussen de componenten van de koffieautomaat zijn
talrijker dan de relatie tussen de koffieautomaat en de menselijke gebruiker, namelijk het
voorzien van koffie.
• Er is meer energie nodig om iets over de systeemgrens te transporteren dan om iets binnenin
de systeemgrens te transporteren. Om bijvoorbeeld water te brengen van het waterreser-
voir naar de koffiefilter is maar een interactie nodig. Om de koffie te zetten en deze aan
de menselijke gebruiker te leveren moeten echter alle interne interacties worden doorlopen
wat een groter energieverbruik tot gevolg heeft.
• De systeemgrens zou zo moeten worden gekozen dat het systeemgedrag eenvoudiger is dan
bij enige andere keuze van systeemgrens. Daarom wordt bijvoorbeeld bij een koffieauto-
maat de knop waarop gedrukt wordt om koffie te verkrijgen, verondersteld een deel te zijn
van het systeem en niet van de omgeving. Indien deze knop deel van de omgeving zou
zijn, dan kan de koffieautomaat zelf in principe geen koffie zetten, aangezien de knop en
dus het startsignaal in de omgeving zit. Het gedrag van de koffieautomaat, namelijk koffie
zetten, is dan niet te verklaren, dit in tegenstelling tot wanneer men de knop wel als een
deel van het systeem beschouwd.
In tabel 1.3 worden de voornaamste elementen van het grensaspect weergegeven:
Hoofdstuk 1. Algemene systeemtheorie 15
Tabel 1.3: Samenvattende tabel voor het grensaspect
grens omgeving
externe interacties
dynamisch
modulair
1.4.4 Functie
Tot nu toe hebben we een systeem dat een interne structuur heeft en interageert met zijn
omgeving. Er is echter nog een derde element dat weliswaar niet in elk systeem aanwezig is
namelijk een functie. “Een functie is een dienst die het systeem aanbiedt aan zijn omgeving”
(Wieringa, 1996-2006, p.22). Zo is de functie van een koffieautomaat, koffie zetten en de functie
van een auto iemand van plaats a naar plaats b vervoeren.
Deze functie van het systeem is eigenlijk een oplossing voor de behoefte van de omgeving. Het
is door te interageren met het systeem dat de omgeving zijn behoefte kan vervullen. Bijgevolg
wordt de omgeving dan ook vaak vervangen door het woord systeemgebruiker. Je kunt bijvoor-
beeld de behoefte hebben om te kunnen slapen omdat je moe bent. De functie van een matras is
om een zachte plaats te bieden om op te liggen. Bijgevolg kun je dus een nieuwe matras kopen
zodat je beter slaapt en minder moe bent. Hierdoor wordt je behoefte om te kunnen slapen
vervuld.
Een belangrijke bemerking die Wieringa maakt, is dat de functie van een systeem niet voor
elke gebruiker dezelfde is. De kans is groot dat elke gebruiker een andere functie ziet in het
systeem aangezien deze gebruikers andere behoeftes hebben. Bijgevolg heeft een systeem vaak
verscheidene functies. Zo is een van de functies van een auto: iemand van plaats a naar plaats
b vervoeren, zoals eerder vermeld. Voor iemand anders kan de auto echter een andere functie
hebben, bijvoorbeeld een plaats om je kleren te leggen. Deze gebruiker kan dan iemand zijn die
veel onderweg is en de behoefte heeft om op alle weersomstandigheden voorbereid te zijn.
Aangezien functie een element is dat niet noodzakelijk in elk systeem aanwezig is, zijn er ook
systemen die geen functie hebben voor hun omgeving. Wieringa geeft hier het voorbeeld van de
planeet Jupiter. De planeet Jupiter is er, interageert met andere elementen in de ruimte en is
bijgevolg volgens de definitie een systeem. Echter, er is geen functie die de planeet Jupiter heeft,
die een behoefte van zijn omgeving vervult. Ook systemen die wel behoeftes van hun gebruikers
Hoofdstuk 1. Algemene systeemtheorie 16
vervullen, hebben geen functie meer van zodra alle gebruikers worden weggenomen.
De voornaamste elementen die horen bij het functieaspect worden in tabel 1.4 samengevat:
Tabel 1.4: Samenvattende tabel voor het functieaspect
functie functie
gebruiker
1.4.5 Gedrag
“Het gedrag van een systeem is de manier waarop het systeem interageert met de omgeving in
de tijd” (Wieringa, 1996-2006, p. 19). Zoals reeds vermeld, bestaat het gedrag van een systeem
uit het gedrag van de onderdelen en ook uit de interacties van de onderdelen met elkaar (supra,
p.12). Een eigenschap van het systeem zelf wordt gezien als een aspect van het gedrag. Het is
eigenlijk de inhoud van het gedrag en ditwordt in softwareomgevingen ook nog wel attribuut
genoemd. (Voorbeelden van attributen zijn grootte en kleur.)
Het gedrag van een systeem zal afhangen van het geheugen van het systeem. Elk systeem heeft
een geheugen van acties in het verleden, ook wel systeemtoestand genoemd. Dit betekent dat,
als je als buitenstaander voor een lange periode naar een systeem kijkt en alle mogelijk acties
noteert die het systeem onderneemt, je een overzicht hebt gemaakt van de mogelijke toestanden
van het systeem. Zo heeft een koffieautomaat bijvoorbeeld als toestand: aan, uit en koffie
zetten. Een toestand hangt af van de waarnemer en van het niveau waarop je jezelf bevindt in
de implemetatiehierarchie. Dit heeft tot gevolg dat een toestand van een systeem gelijk is aan
de som van de toestanden van elk van zijn subelementen. Als bijvoorbeeld een onderdeel van
de koffieautomaat defect is en bijgevolg als toestand uit heeft, dan kan de koffieautomaat ook
enkel uit als toestand hebben. Een systeem is namelijk de som van zijn componenten en hun
interacties. Dus als een onderdeel defect is, is het systeem bijgevolg ook defect.
Om van de ene toestand naar de andere te gaan moet er een interactie gebeuren. De toestand
aan het begin van de interactie wordt ook wel begintoestand genoemd en de toestand op het
einde van de interactie de eindtoestand. Deze interactie kan zowel intern als extern zijn. Een
koffieautomaat gaat van uit naar aan door een externe interactie, namelijk iemand die op de
aan-knop drukt. Een toestand tussen deze begintoestand en eindtoestand wordt tussentoestand
genoemd.
Aangezien het gedrag van een systeem ook mede bepaald wordt door het gedrag van de onderde-
Hoofdstuk 1. Algemene systeemtheorie 17
len is het interessant ook hiervoor een term te introduceren. Wieringa definieert hiervoor echter
geen specifieke term. Bijgevolg wordt hier zelf een term geıntroduceerd, namelijk de term actie.
Deze term stelt dus de acties voor die zich in de onderdelen zelf afspelen. Aangezien een systeem
bestaat uit de som van zijn componenten zijn de acties van het systeem, de som van de acties
van de onderdelen. Kortom, deze bespreking vervolledigt de termen interne interacties, die de
acties tussen de onderdelen weergeven, en externe interacties, die de acties tussen het systeem
en de omgeving weergeven.
Voor het gedragsaspect kan tabel 1.5 worden opgesteld, waarin de voornaamste elementen wor-
den weergegeven:
Tabel 1.5: Samenvattende tabel voor het gedragsaspect
gedrag toestand
actie
1.4.6 Waarom, wat en hoe?
Wieringa stelt dat er een belangrijke relatie aanwezig is tussen systeemstructuur, systeemfunctie
en systeemgedrag. Visueel kunnen deze drie perspectieven van een systeem samengevat worden
aan de hand van figuur 1.1.
Figuur 1.1: De link tussen systeemstructuur, systeemfunctie en systeemgedrag (Wieringa, 1996-2006)
Deze drie perspectieven worden verbonden met elkaar via het begrip nut. Dit begrip stelt een
relatie voor tussen iets dat kan gebruikt worden en iets dat er voordeel bij doet om dat element
te gebruiken. Zo heeft een voordeel bij het gebruiken van de koffieautomaat, aangezien hij bij
de koffieautomaat gewoon op een knop moet drukken om koffie te verkrijgen en bijgevolg zelf
geen tijd verliest bij het zetten van koffie. Figuur 1.1 bevat twee zulke nutsrelaties, namelijk:
Hoofdstuk 1. Algemene systeemtheorie 18
een dienst- en een correctheidsrelatie.
Als eerste heb je de relatie dienst die zich afspeelt tussen het systeem en de gebruiker. Bij deze
nutsrelatie is het systeem hetgeen wordt gebruikt door de gebruiker die er voordeel bij doet
dit systeem te gebruiken. Een systeem levert namelijk een dienst aan een gebruiker waardoor
de behoefte van deze laatste wordt vervuld. Zo levert de koffieautomaat koffie als dienst aan
een menselijke gebruiker die zin heeft in koffie. Hierdoor wordt de behoefte aan koffie vervuld.
Het systeem doet dus iets wanneer het deze dienst levert en dit kan gelijk gesteld worden
met het gedrag van het systeem. Dit is wat het systeem precies doet. De gebruiker van dit
systeem kan dan weer gelijkgesteld worden met de functie van het systeem, aangezien het systeem
geen functie heeft als het geen gebruikers heeft. Bovendien verklaart deze functie waarom een
systeem een bepaald gedrag vertoont, namelijk om de behoefte van de gebruiker te vervullen.
Wanneer systeemgedrag (wat) en systeemfunctie (waarom) bijgevolg ook op figuur 1.1 worden
vermeld, kan de nutsrelatie dienst ook gezien worden als een link tussen het systeemgedrag en
de systeemfunctie.
Een tweede nutsrelatie is de correctheidsrelatie die zich afspeelt tussen het systeem en de sys-
teemdecompositie. Hierbij is correctheid de graad waarmee de systeemdecompositie het gedrag
van het systeem effectief verwezenlijkt. Bijgevolg is hier de systeemdecompositie hetgeen ge-
bruikt wordt door het systeem dat er voordeel bij doet deze systeemdecompositie te gebruiken.
Het is namelijk zo dat een correcte implementatie of systeemdecompositie ervoor zorgt dat het
systeem zijn gedrag correct kan uitvoeren. Zo kan een koffieautomaat slechts op een correcte
manier koffie leveren als de koffiefilter en het waterreservoir correct werken. Deze systeemde-
compositie is eigenlijk niets meer dan de verzameling van de subelementen. Bijgevolg kan de
systeemdecompositie gelijk gesteld worden aan de systeemstructuur. Hieruit kan worden be-
sloten dat de systeemstructuur beschrijft hoe het systeem een bepaald gedrag uitvoert. Ook
hier kan bijgevolg het systeemgedrag (wat) en de systeemstructuur (hoe) op figuur 1.1 worden
vermeld. De nutsrelatie correctheid kan bijgevolg ook gezien worden als een link tussen het
systeemgedrag en de systeemstructuur.
Wieringa merkt hierbij op dat een product enkel bruikbaar is wanneer zowel de nutsrelatie
dienst als de nutsrelatie correctheid kunnen worden aangetoond. Het is namelijk belangrijk dat
er respectievelijk kan worden aangetoond dat het gedrag nuttig is voor de gebruikers maar ook
dat dit gedrag correct is geımplementeerd.
Uit bovenstaande bespreking kan worden gesteld dat systeemfunctie, systeemgedrag en sys-
teemstructuur respectievelijk kunnen worden gelijkgesteld aan waarom een systeem een bepaald
Hoofdstuk 1. Algemene systeemtheorie 19
gedrag vertoont, wat dat gedrag precies is en hoe het systeem dat gedrag uitvoert. Toegepast
op het voorbeeld van de koffieautomaat geeft dit tabel 1.6.
Tabel 1.6: Link waarom, wat en hoe met de implementatiehierarchie van Wieringa (1996-2006)
functie WAAROM organisatie/mensen
gedrag WAT koffieautomaat
structuur HOE koffiefilter en waterreservoir
De rechter kolom van tabel 1.6 kan worden gezien als een hierarchie van systemen volgens
Wieringa. Bijgevolg kan het wat-, waarom- en hoe-perspectief worden gelinkt aan de imple-
mentatiehierarchie. Vooreerst het wat-perspectief. Als we starten op een bepaald niveau dan
kunnen we vragen wat het product doet. Dit geeft het gedrag van het systeem weer. Zo kunnen
we starten op het niveau van de koffieautomaat en kijken wat het doet, namelijk koffie zetten.
Vervolgens kijken we een niveau hoger. Hier wordt de vraag gesteld waarom een product dit
gedrag vertoont. Voor het voorbeeld van de koffieautomaat zitten we op het niveau van de
organisatie wanneer we de waarom-vraag stellen. Waarom de koffieautomaat koffie zet, kan als
reden hebben dat de mensen in de organisatie liever koffie drinken dan thee en de organisa-
tie bijgevolg een koffieautomaat heeft gekocht. Indien de werknemers liever thee drinken, zet
deze automaat waarschijnlijk thee en wordt het een ‘theeautomaat’ genoemd. Tenslotte kan
vanuit het startniveau, de koffieautomaat, ook een niveau lager worden gekeken, namelijk naar
het niveau van de structuur. Hierbij wordt de vraag gesteld hoe het systeem een bepaald ge-
drag uitvoert. Bijvoorbeeld wat een koffieautomaat doet, is koffie zetten. Hoe deze automaat
dat doet, wordt duidelijk door een niveau te dalen en te kijken wat de subelementen van de-
ze koffieautomaat zijn en hoe deze in relatie staan met elkaar om het proces koffie zetten te
verwezenlijken. Samenvattend kan worden gesteld dat bij het kijken naar een hoger niveau het
bestaan van een systeem zichtbaar wordt, terwijl de implementatie van een systeem zichtbaar
wordt wanneer een lager gelegen niveau wordt aangesproken. Dit heeft tot gevolg dat wanneer
we kijken waarom een koffieautomaat koffie zet het niet zichtbaar is hoe deze koffieautomaat
koffie zet en omgekeerd. Wieringa merkt hierbij echter op dat, als iets niet zichtbaar is, dit niet
wil zeggen dat het daarom niet bestaat. Het is er wel, maar het is tijdelijk niet zichtbaar omdat
je alles van op een ander niveau bekijkt.
Hoofdstuk 1. Algemene systeemtheorie 20
1.4.7 Samenvatting
Tabel 1.7 geeft een overzicht van de belangrijkste elementen uit de onderdelen systeemstructuur,
systeemgrens, systeemfunctie en systeemgedrag. Het vat de tabellen 1.2, 1.3, 1.4 en 1.5 samen.
Tabel 1.7: Een overzicht van de belangrijkste elementen uit de opvatting van Wieringa
structuur subelementen
relatie
interne interactie
grens omgeving
externe interacties
dynamisch
modulair
functie functie
gebruiker
gedrag toestand
actie
Dit is de tabel die zal worden gebruikt in de hoofdstukken 3 en 4 om de observeerbare systemen
mainframe en BPMS met elkaar te vergelijken in hoofdstuk 5.
1.5 Conclusie
Het hoofdstuk ving aan met een korte uitleg over de oorsprong van de systeemtheorie waarin
de belangrijkheid van deze theorie duidelijk werd. Zoals bij sommige andere theorieen of we-
tenschappen die populair worden, drijven termen uiteen en worden verschillende definities en
invullingen gegeven aan gelijkaardige objecten. Dit fenomeen werd duidelijk aan de hand van
enkele belangrijke opvattingen, namelijk: de opvatting van Bertalanffy (1968), de opvatting van
Boulding (2003), de opvatting van Churchman (1968), de opvatting van Hall & Fagen (2003) en
de opvatting van Wieringa (1996-2006).
Voor het vervolg van de thesis werd gekozen voor de opvatting van Wieringa met zijn vier basis-
elementen: systeemstructuur, systeemgrens, systeemfunctie en systeemgedrag. Hierbij kunnen
de systeemstructuur, de systeemfunctie en het systeemgedrag ook gezien worden als respectie-
velijk hoe een systeem zijn gedrag uitvoert, waarom een systeem dat bepaald gedrag vertoont
en wat een systeem precies doet (Wieringa, 1996-2006).
Hoofdstuk 1. Algemene systeemtheorie 21
Er werd gekozen voor deze theorie omdat deze de meest volledige was van alle besproken opvat-
tingen en de meeste gelijkenissen vertoonde met de termen van de andere opvattingen. Bovendien
is het een consistente theorie en werkt Wieringa (1996-2006) met observeerbare systemen. Deze
opvatting is bijgevolg de beste keuze om het doel van deze thesis te helpen uitwerken. Hieruit
blijkt dat dit eerste hoofdstuk een belangrijke basis legt voor de volgende hoofdstukken.
Hoofdstuk 2
Bedrijfsproces
2.1 Inleiding
Na het bespreken van de systeemtheorie en de term systeem gaan we nu meer in detail met het
bespreken van bedrijfsprocessen. Het doel van dit hoofdstuk is een vergelijking te maken tussen
een bedrijfsproces en een systeem. Vooraleer deze vergelijking wordt gemaakt, wordt eerst het
concept bedrijfsproces in punt 2.2 wat dieper in detail beschreven aan de hand van een definitie
en een uitgewerkt voorbeeld. Om enkele elementen van de vergelijking in punt 2.4 te begrijpen,
wordt in punt 2.3 de term procesgeorienteerde organisatie uitgewerkt en de evolutie naar deze
orientatie beschreven.
2.2 Bedrijfsproces
2.2.1 Definitie
Het aantal definities van een proces zijn niet meer op een hand te tellen. Er zijn echter drie
definities waar in veel literatuur naar wordt verwezen, namelijk deze van Davenport (1993),
Smith & Fingar (2007) en Hammer & Champy (2003).
Om te beginnen definieert Davenport (1993) een proces als volgt: “Een proces is een gestructu-
reerde, gemeten verzameling van activiteiten ontworpen om een specifieke output te produceren
voor een specifieke klant of markt. Het legt een sterke nadruk op ‘hoe’ werk wordt uitgevoerd in
een organisatie in tegenstelling tot een productfocus die meer de nadruk legt op het ‘wat’. Een
proces is dus een specifieke ordening van werkactiviteiten over tijd en plaats, met een begin, een
einde en duidelijk gedefinieerde inputs en outputs: een structuur voor actie” (Davenport, 1993,
p.5). Ten tweede, geven Smith & Fingar (2007) de volgende definitie voor een bedrijfsproces:
“Een bedrijfsproces is de complete en dynamisch gecoordineerde verzameling van samenwerken-
22
Hoofdstuk 2. Bedrijfsproces 23
de en transactionele activiteiten die waarde creeren voor de klant” (Smith & Fingar, 2007, p.47).
Ten derde, gebruiken Hammer & Champy (2003) de volgende, eenvoudigere definitie: “Een be-
drijfsproces is een collectie van activiteiten, die een of meer soorten van input nodig heeft en
een output creeert die een waarde heeft voor de klant” (Hammer & Champy, 2003, p.38).
Deze definities vertonen veel gelijkenissen. Elke auteur stelt dat een bedrijfsproces een collectie
is van activiteiten en dat deze bedrijfsprocessen waarde creeren voor de klant. Smith & Fingar
(2007) zijn de enige die in hun definitie niet de termen input en output gebruiken. Er moet
echter worden vermeld dat Smith & Fingar (2007) in hun boek verwijzen naar de definitie
van Davenport (1993) en hun definitie zien als een aanvulling op deze van Davenport (1993).
Onrechtstreeks vermelden ze dus wel de termen input en output. De reden waarom Smith &
Fingar (2007) hun definitie als een aanvulling zien, is dat zij de term coordinatie in hun definitie
integreren en Davenport (1993) deze, volgens Smith & Fingar (2007) belangrijke term, niet in
zijn definitie opneemt. Er moet worden opgemerkt dat ook Hammer & Champy (2003) deze
term niet gebruiken in hun definitie. Kortom, de definitie van Smith & Fingar (2007) kan als
de meest volledige definitie van de drie gezien worden.
2.2.2 Voorbeeld
Om het begrip bedrijfsproces verder te duiden zullen we een voorbeeld van een bedrijfsproces
uitwerken. Om het voorbeeld weer te geven in een figuur wordt gebruikt gemaakt van de Business
Process Modelling Notation (BPMN) omdat dit een recente notatie is met niet al te complexe
symbolen (Smith & Fingar, 2007; Vergidis et al., 2008).
Als voorbeeld wordt in figuur 2.1 het proces weergegeven van een huurbedrijf voor wagens wan-
neer iemand een auto terugbrengt. Een BPMN pool dient als een omhulsel voor de activiteiten
van een proces waarbij de naam van het proces links in de pool wordt geschreven (Group, 2010;
Harmon, 2007). In het voorbeeld is er een pool aanwezig, namelijk: autoverhuur terugbrengen
auto.
Deze pool bestaat uit drie lanen, namelijk: accounting, claimregeling en lokale dienst. Deze lanen
dienen om een onderscheid te maken tussen de mogelijke deelnemers. Deze lanen kunnen vier
soorten elementen bevatten, namelijk activiteiten, volgorde-pijlen, poorten en gebeurtenissen
Om te beginnen stelt een activiteit werk voor dat wordt uitgevoerd in een onderneming (Group,
2010; Harmon, 2007). Enkele activiteiten die in het voorbeeld voorkomen zijn: ontvang auto,
maak rekening en geef informatie in. De activiteit ontvang auto, is de activiteit waarmee het
Hoofdstuk 2. Bedrijfsproces 24
proces start. Bij deze activiteit brengt een persoon een gehuurde auto terug naar de lokale
dienst.
Ten tweede: de volgorde-pijlen dienen om de volgorde aan te tonen waarin de activiteiten
zich afspelen (Group, 2010; Harmon, 2007). Zo kan in het voorbeeld een auto enkel worden
geınspecteerd van zodra de autogegevens zijn opgevraagd.
Ten derde dienen de poorten om stromen te divergeren of te convergeren. Dit betekent respec-
tievelijk dat een stroom kan worden opgesplitst in twee of meer stromen, of dat twee of meer
stromen kunnen worden samengevoegd tot een stroom (Group, 2010; Harmon, 2007). In dit
voorbeeld zijn twee soorten poorten aanwezig, namelijk: en-poorten en exclusieve of-poorten.
Bij een en-poort zal de stroom enkel verder lopen indien bij een divergatie alle uitgaande stromen
juist zijn, of bij een convergatie alle inkomende stromen juist zijn. Bij een exclusieve of-poort zal
de stroom verder lopen indien bij een divergatie slechts een van de uitgaande stromen juist is,
of als bij een convergatie slechts een van de inkomende stromen juist is (Group, 2010; Harmon,
2007). De en-poort die als eerste in het voorbeeldproces voorkomt, toont aan dat er zowel een
rekening wordt gemaakt als wordt gekeken of er claims moeten worden gemaakt. De tweede
en-poort maakt duidelijk dat na het ingeven van de noodzakelijke informatie omtrent de claim
zowel de auto gerepareerd wordt als een document gemaakt wordt omtrent het geval. Dit voor-
beeld heeft maar een exclusieve of-poort die aantoont dat er ofwel een claim is ofwel geen claim
is, maar dat beide nooit samen voorkomen.
Als laatste soort element in een laan is er een gebeurtenis, iets dat gebeurt tijdens een proces op
een bepaald moment. Het kan iets starten, onderbreken of stoppen (Group, 2010; Harmon, 2007).
Dit voorbeeld heeft vier gebeurtenissen die iets doen stoppen. Zo is er in de laan accounting na
de activiteit maak rekening een stop-gebeurtenis gesitueerd. Deze toont aan dat na het maken
van de rekening de inbreng van de accountingdeelnemer niet meer nodig is.
Hoofdstuk 2. Bedrijfsproces 25
Figuur 2.1: Een autoverhuurproces uitgewerkt met BPMN
Hoofdstuk 2. Bedrijfsproces 26
2.3 Procesgeorienteerde organisatie
Nu duidelijk is wat een proces precies inhoudt en hoe dit via BPMN kan voorgesteld worden,
kan het begrip procesgeorienteerde organisatie geıntroduceerd worden.
In de jaren ’70 en ’80 werden de meeste ondernemingen georganiseerd volgens functies en de-
partementen met de klassieke boomstructuren om dit weer te geven. Vanaf de jaren ’90 echter
kwam een orientering volgens processen op de voorgrond (Harmon, 2003). Het werd toen dui-
delijk dat werknemers enkel kleine delen van de onderneming zien en zich settelen in hun eigen
specialisatie zonder enig idee te hebben van wat zich afspeelt in andere delen van het bedrijf
(Hammer & Champy, 2003). Dit houdt echter een risico van suboptimalisatie in (Davenport,
1993). De verschillende afdelingen hebben geen gemeenschappelijk doel voor ogen en concen-
treren zich enkel op hun eigen doelen (McCormack, 2001). Dit kan leiden tot verbeteringen in
een afdeling, die tegelijk zware nadelen veroorzaken voor een andere afdeling. Bovendien heeft
deze opsplitsing in kleine taken tot gevolg dat een overzicht op het volledige proces nagenoeg
onhaalbaar is zonder een toename in middle management. Deze toename leidt op zich dan tot
een vergroting van de afstand tussen management en klant (Hammer & Champy, 2003). Die-
gene die dus het meeste lijdt onder een functionele orientatie is de klant (McCormack, 2001).
Aangezien de klant tegenwoordig heel belangrijk is in het bedrijfsleven, is de overschakeling van
het functionele denken naar het proces denken een verklaarbare evolutie geweest.
De verschillen tussen het proces denken en het functionele denken worden in tabel 2.1 weerge-
geven:
Tabel 2.1: De kenmerken van het proces denken ten opzichte van de kenmerken van het functionele
denken (McCormack, 2001)
Proces denken Functionele denken
‘hoe’ wordt werk gedaan welke producten of diensten worden er geleverd
functionele orientatie en teamwerk ongecoordineerde functies waarbij werk
‘over de muur wordt gegooid’
systeem-denken: het proces als entiteit het proces is opgedeeld in stukken
klantenorientatie interne orientatie
We kunnen dus stellen dat een procesgeorienteerde onderneming een onderneming is die niet meer
denkt in functie van departementen, diensten en producten, maar in functie van processen door
de onderneming heen (McCormack, 2001). Deze processen overschrijden departementsgrenzen
Hoofdstuk 2. Bedrijfsproces 27
waardoor werk niet meer ‘over de muur wordt gegooid’. Bijgevolg wordt zo de functionele
suboptimalisatie uitgeschakeld en orienteert de organisatie zich meer naar de klant toe. Dit
kan enkel worden gerealiseerd indien ook bijvoorbeeld de compensatie van de werknemer gelinkt
wordt aan dit proces denken. (Hammer & Champy, 2003; McCormack, 2001)
2.3.1 Evolutie naar procesgeorienteerde organisatie
De overschakeling van functionele orientatie naar procesorientatie is een radicale stap (Daven-
port, 1993) die vaak verwarring en conflicten met zich meebrengt (McCormack, 2001). Veel
ondernemingen bevinden zich dan ook in de transitiezone tussen functionele orientatie en pro-
cesorientatie (Harmon, 2003). Waar deze radicale ommekeer in denken vandaan kwam, wordt
hieronder beschreven. De evolutie begint bij de organisatie die functioneel georienteerd is (func-
tionele organisatie), waarna enkele keerpunten worden beschreven die deze procesorientatie in
de hand werken en verder doen evolueren.
Functionele organisatie
Al sinds het ontstaan van de mensheid streeft de mens ernaar processen te verbeteren (Harmon,
2007). Denk maar aan de uitvinding van het wiel.
De industriele revolutie heeft deze verbeteringsdrang overgebracht naar de bedrijfswereld (Har-
mon, 2007). Adam Smith was in die tijd een van de eersten om hierop in te spelen. Hij stelde
dat het verdelen van werk in kleinere taken bijdraagt tot een grotere efficientie van het pro-
ductieproces (Hammer & Champy, 2003). In 1910 paste Henry Ford deze filosofie toe op de
productie van auto’s en werd zo tot op vandaag de dag beroemd (Hammer & Champy, 2003;
Harmon, 2007). Deze manier van werken bleef gedurende een tweehonderdtal jaar in gebruik en
heeft geleid tot de hedendaagse functionele organisatie waar iedereen zich gespecialiseerd heeft
en werkt in zijn eigen afdeling (Hammer & Champy, 2003; McCormack, 2001).
De jaren ’80
Harmon (2007) veronderstelt dat de systeemtheorie en de value chain van Porter de twee grote
theorieen zijn die zorgden voor een volledige verandering in dit denken. De systeemtheorie
maakte het immers duidelijk dat specialisaties ervoor zorgen dat het zicht op het geheel verdwijnt
(Bertalanffy, 1968) en dat elke specialist onderdeel is van een groter geheel (Harmon, 2007). Wat
dit geheel precies is, werd duidelijk door de value chain van Porter weergegeven in figuur 2.2
(Harmon, 2007).
Hoofdstuk 2. Bedrijfsproces 28
Figuur 2.2: De value chain van Porter (Harmon, 2007)
De value chain is een verzameling van alle activiteiten die een onderneming kan uitvoeren (Mc-
Cormack, 2001). Het geeft het produceren van een product of dienst weer, dat start bij een
bestelling van een klant en eindigt bij de levering van het product bij de tevreden klant. De
value chain is het grootst mogelijke proces waarover kan worden gesproken. Het kan ook gezien
worden als een proces waarbij verscheidene ondernemingen betrokken zijn (Harmon, 2007). De
eerste stap naar procesorientatie was gezet (Harmon, 2007) en het verbeteren van processen
was de nieuwe manier om een competitief voordeel te behalen op je concurrenten (McCormack,
2001).
Gebaseerd op deze nieuwe inzichten ontstonden vooral kwaliteitsgerichte theorieen. Deze zijn
onder andere Total Quality Management (TQM) en Six Sigma (Harmon, 2007). TQM concen-
treert zich voornamelijk op het tevreden stellen van de klant via continue verbeteringen in de
kwaliteit (Pereira & Aspinwall, 1997). Het heeft dus als doel om alle defecten en verspillingen
uit de processen weg te werken en dit voor de hele organisatie (Moghaddam & Moballeghi,
2008). Six Sigma is het vervolg van onder andere TQM en is vooral gekend door zijn minimaal
toegelaten foutenpercentage. Six Sigma projecten hebben dus als voornaamste doel producten
te vermijden die niet worden aanvaard door de klant. De werkwijze tijdens zo een project door-
loopt de stappen van de DMAIC cyclus (Define, Measure, Analyze, Improve en Control) en is
vooral gebaseerd op statistische methodes. Ook deze theorie richt zich voornamelijk op continue
verbetering in plaats van een eenmalige actie aangezien Six Sigma projecten vaak projecten zijn
van korte duur en er verscheidene Six Sigma projecten worden uitgevoerd in een bedrijf in de
loop van de tijd. (Harmon, 2007)
Hoofdstuk 2. Bedrijfsproces 29
De jaren ’90
Tegen het einde van de jaren ’80 vonden er enkele nieuwe ontwikkelingen plaats, waardoor
de interesse in procesverbetering alsmaar groter werd. Globalisering zorgde bijvoorbeeld voor
grotere competitie wat op zich dan weer leidde tot fusies en overnames tussen bedrijven (Hammer
& Champy, 2003). Davenport (1993) is echter een van de velen die toen in die tijd ervan overtuigd
was dat de kwaliteitsinitiatieven niet voldoende waren om aan deze nieuwe druk te voldoen. Zij
brengen slechts vijf tot tien procent verbetering in alle bedrijfsprocessen. Maar om beter op deze
nieuwe trends in te spelen is, volgens Davenport, een verbetering nodig van vijftig tot honderd
procent in een selecte groep van bedrijfsprocessen.
Uit deze nieuwe ideeen ontstonden er enkele theorieen die zich richtten op een andere manier
van procesverbetering, namelijk radicale procesverbetering in plaats van de continue procesver-
betering bij Six Sigma en TQM. Bij radicale verbetering worden processen niet incrementeel
veranderd maar eerder radicaal om te kunnen voldoen aan de vijftig tot honderd procent verbe-
tering (Davenport, 1993). Davenport (1993) noemt dit Business Process Reengineering (BPR).
Ook Hammer & Champy (2003) hebben dezelfde denkwijze als Davenport (1993) en zij geven
de volgende definitie aan de term BPR: “Business reengineering is het fundamenteel herover-
wegen en radicaal herontwerpen van organisatorische processen om drastische verbetering van
de bestaande prestatie te bereiken wat betreft kosten, dienstverlening en snelheid” (Hammer &
Champy, 2003, p.35).
De verschillen tussen de continue verbetering en de radicale verbetering worden in tabel 2.2
weergegeven. Davenport (1993) noemt deze termen respectievelijk verbetering en innovatie.
Tabel 2.2: Procesverbetering versus procesinnovatie (Davenport, 1993)
EIGENSCHAPPEN VERBETERING INNOVATIE
Niveau van verandering incrementeel radicaal
Startpunt bestaande processen starten van een ‘schone lei’
of een ‘wit blad’
Frequentie van verandering eenmalig of continu continu
Benodigde tijd kort lang
Deelname bottom-up top-down
Typische breedte van project klein project groot project
Risico matig hoog
Hoofdstuk 2. Bedrijfsproces 30
Uit tabel 2.2 blijkt dat een verbetering eerder een kort project is waarvan het risico matig is. Dit
kan worden verklaard door het feit dat de verbetering slechts incrementeel is en men vertrekt
van reeds bestaande processen. In tegenstelling hiermee is een innovatie eerder een groot project
waarvan het risico hoog is. Dit volgt uit het feit dat een innovatie radicaal is en niet start van
bestaande processen maar helemaal opnieuw begint (Davenport, 1993).
Er zijn nog enkele andere belangrijke theorieen die zich situeren in deze tijd en die een bij-
drage hebben geleverd tot procesorientatie, namelijk: Workflow Management en Enterprise
Application Integration (EAI) (Harmon, 2007). Workflow Management houdt zich bezig met
documentverwerking en de stroom van gegevens door het bedrijf (Cummings, 2008) en dient
volgens Harmon (2007) voornamelijk om manuele activiteiten tussen gebruikers te automatise-
ren. Dit creeerde een verzameling van geautomatiseerde applicaties. Op zich zijn al deze aparte
applicaties niet zo efficient en worden ze beter gebundeld. Dit is waar EAI tussenkomt aangezien
deze het mogelijk maakt om gegevens op een gecoordineerde manier van de ene applicatie naar
de andere door te geven (Harmon, 2007; Cummings, 2008).
De jaren 2000 tot nu
Tegen het einde van de jaren ’90 echter is de bubbel rond de grote hype, BPR, uiteengespat
(Harmon, 2007). Het bleek te moeilijk te zijn om processen op een radicale manier te wijzigen
en slechts dertig procent van de aangegane BPR projecten slaagde (Hammer & Champy, 2003).
Bovendien hadden de Chief Executive officers in de tijd van de eeuwwisseling veel meer oog voor
de aankomende problemen met de millennium bug (Harmon, 2007).
De opkomst van het internet bracht hierin verandering: voor klanten maakte internet het moge-
lijk om prijzen over de hele wereld te vergelijken, terwijl dit voor de producenten betekende dat
er weer meer competitie was (Harmon, 2007). Ook is de klant nu koning en heeft deze de macht
en controle verkregen in de markt. Bijgevolg krijgt het personaliseren van producten hier veel
aandacht (Smith & Fingar, 2007). Hier moet ook nog worden toegevoegd dat de economische
onzekerheid steeg in die tijd (Harmon, 2007) en het is er vandaag de dag zeker niet beter op
geworden met de economische crisis.
Dit alles wakkerde de interesse voor procesorientatie weer aan. Men realiseerde zich dat het
mogelijk was om alle vorige theorieen te integreren in een nieuwe en betere theorie, name-
lijk Business Process Management (BPM) (Harmon, 2007), die zich opnieuw concentreerde op
continue verbetering (Hill et al., 2009). Deze theorie focust vooral op het beweeglijk zijn als
organisatie, zodat er snel kan worden aangepast aan de steeds sneller veranderende omstan-
Hoofdstuk 2. Bedrijfsproces 31
digheden. Aangezien de klant steeds belangrijker wordt en in deze tijd verandering de enige
zekerheid is (Smith & Fingar, 2007), is deze beweeglijkheid zeker een must om te overleven als
organisatie. De definitie van Smith & Fingar (2007) toont aan wat BPM kan verwezenlijken:
“Bedrijven die een BPM competentie bezitten, zullen hun klanten sneller en beter kunnen bedie-
nen. Ze zullen betere kwaliteit kunnen aanbieden tegen een lagere kost met grotere schaaleco-
nomieen, wat hun winstgevendheid zal verhogen. Ze zullen sneller kunnen reageren op nieuwe
opportuniteiten die zich voordoen in de markt via het bundelen of ontbundelen van bedrijfsre-
laties, zowel in hun vraag- als aanbodkanalen” (Smith & Fingar, 2007, p.141).
Het voordeel dat BPM heeft ten opzichte van de vorige theorieen is dat BPM een ondersteunende
technologie heeft, namelijk het Business Process Management System (BPMS) (Cummings,
2008).
Vandaag de dag is deze BPM-theorie en de bijhorende technologie nog verder in ontwikkeling en
dit is dan ook waar we ons momenteel bevinden. Aangezien we vandaag nog steeds te kampen
hebben met economische onzekerheid en BPM daar een oplossing blijkt voor te bieden, is het
zeker interessant om deze nieuwe theorie te vergelijken met de reeds bestaande mainframes in
hoofdstuk 5.
2.4 Relaties tussen bedrijfsproces en systeem
2.4.1 Relatie tussen procesorientatie en systeemtheorie
Uit bovenstaande evolutie kan er een link gelegd worden tussen het ontstaan van de proces-
orientatie en de systeemtheorie. Het is namelijk de systeemtheorie die gedeeltelijk heeft bijgedra-
gen tot het ontstaan van de procesorientatie (Harmon, 2007). Het was onder andere Bertalanffy
(1968) die aantoonde dat iedere specialist in zijn eigen cocon zat en nooit verder keek dan zijn
deelgebied. Dit had tot gevolg dat er veel dubbel werk werd verricht onder de verschillende dis-
ciplines. Onderlinge uitwisseling van ideeen zou veel positieve resultaten met zich meebrengen
en zo ontstond de algemene systeemtheorie (Bertalanffy, 1968) met de bijhorende Society for the
Advancement of General System Theory (Keuning, 1973). Er werd een overzicht gegeven van
het geheel in plaats van zich te concentreren op de aparte delen.
Dit is net wat er gebeurt bij de procesgeorienteerde organisatie. De invoering van Adam Smith
zijn theorie, die stelt dat wanneer iedere werknemer zijn eigen klein stukje werk heeft, er een
grotere efficientie kan worden bereikt, heeft geleid tot specialisatie (Hammer & Champy, 2003).
Dit leidt tot suboptimalisatie (Davenport, 1993) aangezien elke werknemer zijn eigen doel heeft
Hoofdstuk 2. Bedrijfsproces 32
(Smith & Fingar, 2007). Via het systeemperspectief werd duidelijk dat ook hier cocons ontston-
den en de links en relaties verdwenen waren. Werknemers moeten gezien worden als deel van
een groter geheel, waarbij de resultaten worden bereikt door samen te werken. Aangezien alles
gelinkt is met elkaar is het interessant om bedrijfsprocessen te zien als een stroom in plaats van
als aparte delen die samenwerken (Harmon, 2007).
Samenvattend kunnen we stellen dat de systeemtheorie een grote rol heeft gespeeld in het ont-
staan van de procesgeorienteerde organisatie.
2.4.2 Relatie tussen bedrijfsproces en systeem
Naast de bovenstaande relatie is er ook een link tussen een bedrijfsproces en een systeem.
Volgens Churchman (1968) wordt een systeem als volgt gedefinieerd: “Een systeem bestaat uit
een verzameling van componenten die samenwerken voor het doel van het geheel” (Church-
man, 1968, p.11). Als definitie voor een bedrijfsproces nemen Smith & Fingar (2007): “Een
bedrijfsproces is de complete en dynamische, gecoordineerde verzameling van samenwerkende
en transactionele activiteiten die waarde creeren voor de klant” (Smith & Fingar, 2007, p.47).
De verzameling van elementen bij de systeemdefinitie kan worden gelinkt met de verzameling
van activiteiten bij de definitie voor een bedrijfsproces. Een systeem heeft een doel en bij een
bedrijfsproces is dit waarde creeren voor de klant. Deze twee definities vertonen dus een duide-
lijke relatie waaruit kan worden geconcludeerd dat een bedrijfsproces een voorbeeld is van een
systeem.
De hierarchie zoals Bertalanffy (1968) en Boulding (2003) deze definieren, namelijk als niveaus
waarbij elk niveau de vorige niveaus omvat (supra, p.6 en 7), of de implementatiehierarchie van
Wieringa (1996-2006) (supra, p.8) komt ook bij bedrijfsprocessen terug, aangezien een bedrijfs-
proces een voorbeeld is van een systeem. Wieringa (1996-2006) stelt dat elk systeem kan worden
opgedeeld in zijn subelementen en deze op zich ook opnieuw kunnen worden opgedeeld in hun
subelementen tot je aan een element komt dat niet meer deelbaar is. Harmon (2007) past dit
toe op bedrijfsprocessen door te beginnen bij het grootst mogelijk proces, de value chain, en
dit verder op te delen in zijn subelementen. Figuur 2.3 toont aan hoe deze onderverdeling eruit
ziet.
Hoofdstuk 2. Bedrijfsproces 33
Figuur 2.3: De decompositie van de value chain (Harmon, 2007)
2.4.3 Toepassing van de systeemtheorie op een bedrijfsproces: voorbeeld
Nu er geıllustreerd is dat een bedrijfsproces een systeem is en aangezien de theorie van Wieringa
(1996-2006) en de hiervan afgeleide tabel (supra, p.20) kunnen worden gebruikt om een systeem
te analyseren, kunnen we deze tabel ook kort toepassen op bedrijfsprocessen. Als systeem wordt
het proces genomen dat besproken werd als voorbeeld in punt 2.2.2. Dit voorbeeld wordt in
figuur 2.4 weergegeven. Het wordt vooreerst geanalyseerd aan de hand van het structuuraspect,
vervolgens het grensaspect, daarna het functieaspect en als laatste het gedragsaspect.
Hoofdstuk 2. Bedrijfsproces 34
Figuur 2.4: Een autoverhuurproces uitgewerkt met BPMN
Hoofdstuk 2. Bedrijfsproces 35
Als eerste aspect wordt de structuur van het proces geanalyseerd. Een proces bestaat volgens de
definities in punt 2.2.1 uit activiteiten (supra, p.22). Figuur 2.3 van Harmon (2007) die de de-
compositie van de value chain weergeeft, bevestigt dit. De activiteiten uit het voorbeeld worden
weergegeven door het symbool voor activiteiten in de BPMN namelijk de rechthoek. Voorbeel-
den van activiteiten zijn: ontvang auto, maak rekening en herstel auto. De relaties tussen de
verschillende subelementen worden weergegeven door de pijlen. Zo bestaat er bijvoorbeeld een
relatie tussen het ontvangen van de auto en het vragen naar de autogegevens. De interacties
tussen de activiteiten in dit voorbeeld zullen voornamelijk gebaseerd zijn op het uitwisselen van
gegevens. Zo kan er tussen de activiteit inspecteer auto en noteer claims en de activiteit maak
een claimrapport, gegevens uitgewisseld worden omtrent de aard van de claim.
Ook het aspect grens kan op een proces worden toegepast. Deze bevat vier elementen, namelijk:
omgeving, externe interacties, dynamisch en modulair. Vooreerst de omgeving die bestaat uit
de deelnemers van een proces, namelijk: mensen, computersystemen, andere organisaties en
andere processen (Smith & Fingar, 2007). Voor het ‘auto-verhuur terugbrengen’ systeem zijn
bijvoorbeeld de klant en de accountant, mensen die in de omgeving van het proces zitten. Een
ander proces dat een mogelijke connectie heeft met dit proces en bijgevolg in zijn omgeving zit
is het verhuren van een auto. Zo heeft bijvoorbeeld de vrijgeven auto activiteit op het einde van
het proces tot gevolg dat de auto wordt vrijgegeven en weer klaar is voor verhuur. Hier kan een
link gemaakt worden met het verhuurproces dat de vrijgekomen auto opnieuw verhuurt. Voor
het tweede element namelijk externe interactie kan als voorbeeld de uitwisseling van een auto
genomen worden. Dit speelt zich bijvoorbeeld af tussen het gegeven proces en het verhuurproces.
Ten derde, kan een bedrijfsproces ook wel een dynamisch systeem genoemd worden, aangezien
het bedrijfsproces interageert met andere systemen. Smith & Fingar (2007) vermelden zelf ook
letterlijk dat “bedrijfsprocessen dynamische systemen zijn” (Smith & Fingar, 2007, p.164). Ook
in het voorbeeld interageert het proces met mensen en andere processen, die ook systemen zijn.
Dit maakt het voorbeeldproces dynamisch. Ten vierde is de modulariteit van dit proces moeilijk
te bewijzen aangezien er geen informatie aanwezig is over het bedrijf. Het is mogelijk dat de
integratie van een bepaalde activiteit in het proces, dit proces logischer maakt maar aangezien
het proces begrijpbaar is zoals het weergegeven is in figuur 2.4, is de kans hiertoe klein.
Een volgend element dat kan worden besproken voor processen is de functie. Volgens de definities
gegeven in punt 2.2.1 blijkt dat de functie van een proces is: waarde te creeren voor de klant
(Smith & Fingar, 2007; Hammer & Champy, 2003; Davenport, 1993). De waardecreatie in het
proces in het voorbeeld kan bijvoorbeeld het efficient of snel afhandelen zijn van de teruggave
Hoofdstuk 2. Bedrijfsproces 36
van de huurauto. Dit hoeft niet noodzakelijk de enige functie van het proces te zijn, aangezien
volgens Wieringa (1996-2006) een systeem meerdere functies kan bezitten, afhankelijk van het
standpunt dat wordt ingenomen. Gebruikers van een proces zijn, zoals reeds vermeld: mensen,
computersystemen, andere processen en andere organisaties (Smith & Fingar, 2007).
Als laatste element wordt het gedrag besproken. Het voorbeeldproces kan als toestand in de
wachtfunctie staan. Dit is bijvoorbeeld het geval wanneer het departement verzekeringen op
dat moment niet werkt en het proces niet verder kan worden doorlopen. Ook kan het proces
volledig worden doorlopen zonder enig probleem. Dit betekent dat het proces werkzaam is.
Andere toestanden zoals defect of uit (indien de organisatie gesloten is), zijn ook mogelijk.
Binnen elke activiteit vinden acties plaats, wat ons brengt bij de term acties. Zo heeft de
activiteit contacteer verzekering hoogstwaarschijnlijk een actie telefoneer naar Dhr. Barbry van
het departement verzekeringen. Bij de activiteit maak rekening kan er als actie print de rekening
voorkomen.
De bovenstaande bespreking kan worden samengevat in tabel 2.3:
Hoofdstuk 2. Bedrijfsproces 37
Tabel 2.3: Toepassing van de opvatting van Wieringa (1996-2006) op een bedrijfsproces
structuur subelement activiteiten
relatie tussen ontvang auto en vraag autogegevens
interacties gegevens uitwisselen
grens omgeving mensen
computersystemen
organisaties
andere processen
externe interacties uitwisseling auto
dynamisch ja
modulair /
functie functie waarde creeren voor de klant
gebruikers mensen
computersystemen
organisaties
andere processen
gedrag toestand wachtfunctie
werkzaam
defect
uit
actie telefoneer naar
print de rekening
2.5 Conclusie
Na het bespreken van het begrip systeem werd in dit hoofdstuk meer in detail getreden door
een element van een soort systeem te bespreken, namelijk een bedrijfsproces. Dit hoofstuk ving
aan met enkele definities van bedrijfsprocessen die met elkaar werden vergeleken. Aan de hand
van BPMN werd daarna een voorbeeld uitgewerkt van een bedrijfsproces om de definities beter
te duiden.
In een volgend punt werd het begrip procesgeorienteerde organisatie uitgewerkt. Deze evo-
lutie maakte duidelijk hoe belangrijk processen vandaag de dag zijn (Smith & Fingar, 2007;
McCormack, 2001) en wat de verschillende keerpunten waren in de evolutie naar de procesge-
Hoofdstuk 2. Bedrijfsproces 38
orienteerde organisatie. Deze bespreking maakte het mogelijk in punt 2.4 een link te leggen
tussen de systeemtheorie en de procesorientatie en hoe deze laatste beınvloed werd door de
systeemtheorie.
In punt 2.4 werd verder ook de belangrijke link tussen een systeem en een bedrijfsproces uitge-
diept waarna de tabel opgesteld vanuit de opvatting van Wieringa (1996-2006) werd toegepast
op een voorbeeld.
Hoofdstuk 3
Mainframes
3.1 Inleiding
Informatiesystemen zijn een onderdeel van bedrijfsprocessen besproken in hoofdstuk 2. In dit
hoofdstuk wordt het mainframe besproken, dat een onderdeel is van een informatiesysteem
van een bedrijfsproces. De theorie van Wieringa (1996-2006) wordt toegepast op een typisch
mainframe systeem via de opgestelde tabel.
3.2 Definitie mainframe
Een mainframe kan worden gedefinieerd als een grote computer waar vooral grote bedrijven
mee werken. De eerste soort van mainframes dateren van 1944 (IBM-website, 2010), maar ook
vandaag worden er nog mainframes gebruikt. Voornamelijk grotere bedrijven en overheidsorga-
nisaties horen nog tot de gebruikers van mainframes (Peterson, 2006).
De drie voornaamste redenen waarom mainframes ook vandaag de dag nog worden gebruikt zijn
omdat het voornamelijk de meest kritische processen bevat, het betrouwbaar is en een beter eco-
logisch aspect heeft (Perkins, 2009; Bradbury, 2008). Eerst iets meer over de kritische processen
dat het mainframesysteem bevat. Er wordt gezegd dat er vandaag de dag nog ongeveer zeventig
procent van de belangrijkste gegevens die aanwezig zijn in de wereld, op de mainframe servers
staan (Peterson, 2006). Dit kan worden gelinkt aan de tweede reden namelijk dat mainframes
betrouwbaar zijn. Mainframesystemen zijn namelijk zo gebouwd dat wanneer een component
verouderd is en stopt met werken, er een andere component aanwezig is die zijn taken kan over-
nemen (Bradbury, 2008). Deze twee redenen hebben ervoor gezorgd dat mensen het liever niet
riskeren om de processen die aanwezig zijn op het mainframesysteem over te zetten op een ander
systeem dat misschien goedkoper is (Perkins, 2009). De meeste vrezen dat er bij de omzetting
39
Hoofdstuk 3. Mainframes 40
fouten zullen optreden, die ervoor zorgen dat de belangrijke informatie verloren gaat die momen-
teel op deze mainframes beschikbaar is. Een derde reden is het ecologische aspect. Mainframes
zijn efficienter dan andere systemen die dezelfde functie uitoefenen. Om de capaciteit van de
mainframes te bereiken, verbruiken de andere systemen meer energie dan het maiframesysteem
nodig heeft (Bradbury, 2008).
Tegenover deze voordelen staat echter de grotere initiele kost van een mainframesysteem. Dit
kan worden genuanceerd door de totale kosten van een computersysteem te berekenen waarbij
bijgevolg ook onderhoudskosten en ecologische kosten zitten. Bij deze berekening komt een
mainframesysteem goedkoper uit dan andere systemen. Zo is bijvoorbeeld het onderhoud van
een mainframe gecentraliseerd waarbij er slechts een machine aanwezig is. Bij andere systemen
is er vaak een netwerk van computers aanwezig waarbij het onderhoud niet op een plaats kan
gebeuren. Dit verhoogt bijgevolg de onderhoudskosten.
3.3 Mainframe system/360
Binnen de groep van mainframes door de jaren heen heeft volgens Bresnahan & Greenstein
(1999) het mainframe system/360 een centrale rol gespeeld wat betreft de structuur van het
mainframesegment en was het bovendien veel beter dan de vorige mainframe systemen. Om
deze centrale rol meer te duiden, stellen Gifford & Spector (1987) dat het mainframe system/360
(en de volgende versie die gebaseerd is op het mainframe system/360) meer dan drieentwintig
jaar na zijn introductie in 1964, nog steeds een belangrijk instrument is dat wordt gebruikt
door de mens. Ook Eddolls (2009) stelt dat het mainframe system/360 een grote invloed heeft
uitgeoefend op de computergeschiedenis. Hieruit kan worden geconcludeerd dat het mainframe
system/360 een grote mijlpaal was in de computergeschiedenis die bovendien enkele belangrijke
karakteristieken heeft geıntroduceerd die in de volgende generaties verder werden verbeterd.
Het mainframe system/360 kan dus gezien worden als de basis van alle volgende generaties
en bijgevolg is het representatief dit mainframe systeem als voorbeeld te nemen in de verdere
bespreking.
Vooraleer de theorie van Wieringa (1996-2006) toe te passen op het mainframe system/360,
wordt dieper ingegaan op enkele vernieuwende eigenschappen van het mainframe system/360.
Dit zorgt ervoor dat het mainframe system/360 en de bespreking ervan beter kan geplaatst en
begrepen worden.
Het mainframe system/360 was een nieuwe generatie mainframes (IBM-website, 2010) dat enkele
problemen van de vorige edities oploste (IBM, 1964). Vooreerst, was het mainframe system/360
Hoofdstuk 3. Mainframes 41
het eerste dat opwaarts en neerwaarts compatibel was, wat het mogelijk maakte om over te
schakelen naar een groter model, zonder dat er hierbij problemen ontstonden (IBM, 1964; IBM-
DPD, 1964). Ten tweede waren vorige edities van mainframes specifiek voor wetenschappelijke
of commerciele applicaties gemaakt. Het mainframe system/360 heeft in tegenstelling tot de
vorige edities een algemener design waardoor het zowel voor wetenschappelijke als commerciele
applicaties kan worden gebruikt. Bijgevolg hoeft er nu geen keuze meer gemaakt te worden
(IBM-DPD, 1964). Ten derde kunnen deze mainframes met een groot aantal terminals commu-
niceren die zich op grote afstand van het mainframe kunnen bevinden (IBM, 1967). Ten vierde
werd bij de productie van deze mainframe voor de eerte keer gebruik gemaakt van de solid logic
technologie waarbij microminiaturisatie gebruikt wordt voor de componenten en circuits. Een
laatste belangrijke eigenschap van het mainframe system/360 is het feit dat dit een besturings-
systeem heeft. Dit zorgt ervoor dat er minder menselijke interventies nodig zijn, zodat enkele
belangrijke fouten werden vermeden (IBM, 1964).
3.4 Structuur
Nu duidelijk is met welk systeem we werken, kan de tabel opgesteld vanuit de opvatting van
Wieringa (1996-2006) worden toegepast, beginnend bij het aspect structuur. Hier wordt via
een figuur vooreerst duidelijk gemaakt wat deel is van het systeem en wat niet, en worden de
interacties tussen de subelementen uitgewerkt.
3.4.1 Subelementen
Figuur 3.1: Mainframe system/360 (IBM-website, 2010)
Hoofdstuk 3. Mainframes 42
Bovenstaande figuur 3.1 geeft in de ovaal weer wat hier als deel van het mainframe system/360
wordt gerekend. Hetgeen zich buiten deze ovaal bevindt, is deel van de omgeving.
Wanneer meer in detail gekeken wordt naar figuur 3.1 verkrijgen we de elementen in de rechthoek
op figuur 3.2.
Figuur 3.2: Mainframe system/360 met subelementen (IBM-DPD, 1964)
Een mainframe kan onderverdeeld worden in een hardware- en een softwaregedeelte, waarbij het
softwaregedeelte niet zichtbaar is op de tekening. De voornaamste hardware-elementen zijn de
central processing unit (CPU), de kanalen en het systeemcontrolepaneel, terwijl het voornaamste
software-element het besturingssysteem is. Deze elementen (CPU, kanalen, systeemcontrolepa-
neel en besturingssysteem) zijn bijgevolg de subelementen van een mainframe.
De CPU bestaat uit een hoofdopslageenheid, zestien algemene registers, vier floating-point re-
gisters (Opler, 1966) en een arithmetic and logical unit (ALU). Deze hoofdopslageenheid kan ook
niet geıntegreerd zijn in de CPU en bijgevolg een alleenstaande eenheid zijn in het mainframe.
De hoofdopslageenheid heeft als doel, zoals het woord zelf zegt: het opslaan van gegevens die
komen van de CPU en het geven van gegevens die gevraagd worden door de CPU. Deze gegevens
worden uitgewisseld in eenheden van acht bits of een veelvoud van acht bits (IBM-DPD, 1964).
De ALU verwerkt gegevens en gebruikt hierbij de registers om onder andere resultaten in op
te slaan. In vorige edities waren slechts een klein aantal registers aanwezig, wat een kleinere
flexibiliteit en snelheid tot gevolg had (Thomas, 1971). Aangezien dit gezien werd als een van de
tekorten van deze vorige edities, werd dit in het mainframe system/360 opgelost (IBM, 1964).
Het tweede hardware element zijn de kanalen. De kanalen zorgen voor een communicatielijn
tussen de hoofdopslageenheid en de input/output (i/o) apparatuur (IBM-DPD, 1964). Hierdoor
Hoofdstuk 3. Mainframes 43
wordt de CPU ontlast van deze taak en kan het verwerken van gegevens tezelfdertijd gebeuren als
i/o operaties (IBM, 1964). De kanalen nemen dus een taak van de CPU over en kanalen werken
bovendien onafhankelijk van elkaar (IBM-DPD, 1964). De kanalen kunnen gezien worden als
een onafhankelijke computer met een eigen register (IBM, 1967). Er zijn twee soorten kanalen:
multiplexor kanalen en selector kanalen. Het feit dat er twee soorten kanalen zijn, is om het
uitvoeren van meer dan een i/o operatie tegelijk mogelijk te maken (Germain, 1967). Ten eerste
het multiplexor kanaal: dat wordt gebruikt om trage-snelheids i/o apparaten, zoals een printer,
aan vast te koppelen (IBM, 1967, 1964). Dit kanaal heeft twee werkingsstanden, namelijk: de
burst mode en de multiplexor mode. In de multiplexor mode worden de faciliteiten van het
multiplexor kanaal gedeeld door verscheidene i/o apparaten, waarbij elk i/o apparaat gedurende
een bepaald interval info verkrijgt (IBM-DPD, 1964). De burst mode is net het tegenovergestelde
en hier neemt slechts een i/o apparaat het volledige multiplexor kanaal in voor de volledige
tijdsperiode (IBM, 1964). Een mainframe kan slechts een multiplexor kanaal bevatten. Ten
tweede is er het selector kanaal: dat wordt gebruikt om hoge-snelheid i/o apparatuur, zoals
een magnetische tape, aan vast te koppelen (IBM, 1967). Deze heeft een enkele werkingsstand
namelijk de burst mode (Germain, 1967). De betekenis van deze burst mode is dezelfde als bij het
multiplexor kanaal. De meeste mainframe system/360 modellen kunnen tot zes selector kanalen
bezitten (IBM, 1967).
Het besturingssysteem wordt geladen in de hoofdopslageenheid in de CPU. Deze zorgt ervoor
dat het mainframe programma’s blijft uitvoeren zonder dat er menselijke interactie nodig is
(Thomas, 1971). Aangezien er nogal wat modellen bestaan in de mainframe system/360 serie,
zijn er ook een groot aantal besturingssystemen. De voornaamste zijn: Operating System/360
(OS/360), Disk Operating System (DOS), Tape Operating System (TOS), Basic Operating
system (BOS) en Basic Programming Support (BPS) (Germain, 1967). De eerste drie, namelijk
OS/360, BOS en BPS, waren geıntroduceerd in 1964 (Thomas, 1971) waarbij BPS eigenlijk een
tapeversie is van BOS (Germain, 1967). BOS is het kleinste besturingssysteem qua plaatsinname
in de opslageenheid en OS/360 het grootste. Omdat het grootteverschil tussen beide systemen
nogal groot was, heeft IBM nog twee andere besturingssystemen op de markt gebracht, namelijk:
de TOS en de DOS. De twee besturingssystemen die meest gebruikt werden, waren de DOS en
de OS/360 (Thomas, 1971). In de eerste computers was er geen besturingssysteem aanwezig
en werd alles via de gebruikers gedaan. Er was dus veel menselijke interactie en naarmate het
aantal gebruikers steeg en de programma’s complexer werden, werd het onhandig om alles via de
gebruiker te laten verlopen (Thomas, 1971). Bovendien maakten de gebruikers veel fouten tijdens
het uitvoeren van programma’s (IBM-DPD, 1964). Het introduceren van het besturingssysteem
Hoofdstuk 3. Mainframes 44
vermeed deze fouten (IBM-DPD, 1964) door de interventies van de gebruiker te minimaliseren
en verbeterde bovendien de doorstroom van het systeem (Thomas, 1971).
Aangezien het toch nog steeds nodig is dat de gebruiker enige controle heeft op het systeem (om
bijvoorbeeld het systeem te resetten), bestaat er een systeemcontrolepaneel (IBM-DPD, 1964).
Op figuur 3.2 is dit systeemcontrolepaneel niet zichtbaar, maar op figuur 3.1 wel. Het systeem-
controlepaneel bestaat uit alle knoppen en hendeltjes die je aan de buitenkant ziet (IBM-DPD,
1964). Het bestaat uit een operator controle, een operator interventie en een klanten enginee-
ring onderhoud (IBM, 1964). Dit systeemcontrolepaneel kan onder andere de CPU resetten,
informatie opslaan en weergeven in de opslageenheid en kan indien nodig initiele programma
informatie laden (IBM-DPD, 1964). Om te zorgen dat de acties ook effectief worden uitgevoerd
als een gebruiker op een knop drukt, is het systeemcontrolepaneel verbonden met de CPU (IBM,
1964).
3.4.2 Relatie en interne interacties
Volgens Wieringa (1996-2006) bestaan de subelementen van een systeem ook uit subelementen
die verder kunnen worden opgedeeld. Deze opdeling gaat verder tot aan een bepaald niveau
waar geen verdere onderverdeling meer mogelijk is. Wanneer dit wordt gecombineerd met het
feit dat interne interacties, interacties zijn tussen subelementen, dan kan er heel uitgebreid over
deze interne interacties worden geschreven. Om dit te beperken wordt hier enkel gesproken over
de relaties tussen de eerste onderverdeling van subelementen. Het gaat hier dus over de relaties
en interacties onder de CPU, de kanalen, het systeemcontrolepaneel en de hoofdopslageenheid
wanneer deze niet is geıntegreerd in de CPU.
Figuur 3.2 geeft enkele relaties tussen de CPU, hoofdopslageenheid en de twee soorten kanalen
weer. Zo is er bijvoorbeeld een relatie tussen de CPU en het multiplexor kanaal en een relatie
tussen de CPU en het selector kanaal. Een relatie die niet op deze tekening is weergegeven, is
de relatie tussen de CPU en het systeemcontrolepaneel.
Tussen de hoofdopslageenheid en de CPU zijn de twee belangrijkste interacties: het opslaan van
gegevens en het vragen van gegevens (IBM-DPD, 1964). De eerste interactie gebeurt vanuit de
CPU richting de hoofdopslageenheid en de andere interactie gebeurt in de omgekeerde richting.
De kanalen hebben dezelfde link met de hoofdopslageenheid als de CPU. Er wordt ook infor-
matie geladen en opgevraagd (IBM-DPD, 1964). Bovendien zit het programma van de kanalen
in de hoofdopslageenheid en moet dit programma dus worden geladen om te kunnen worden
uitgevoerd. Dit vormt een vraag vanuit de kanalen naar de hoofdopslageenheid. Bijgevolg is dit
Hoofdstuk 3. Mainframes 45
een andere interactie tussen het kanaal de hoofdopslageenheid. Om dit te kunnen uitvoeren is
ook een start i/o instructie nodig, wat een interactie weergeeft tussen de kanalen en de CPU.
Andere interacties of instructies tussen deze twee subelementen zijn test i/o, stop i/o en test
kanaal (IBM, 1967). De instructies zijn interacties vanuit de CPU naar de kanalen toe. Een
andere interactie vanuit de kanalen maar dan richting de CPU is de i/o onderbreking. Deze
laat de CPU weten dat de kanalen weer vrij zijn voor een nieuwe operatie (IBM-DPD, 1964).
Aangezien de CPU verbonden is met het systeemcontrolepaneel bestaan er tussen deze twee
ook interacties. Zo zal de interactie waarbij initiele programma-informatie wordt doorgegeven,
bepaalde gegevenselementen transporteren.
3.4.3 Samenvatting
Wanneer de subelementen en interne interacties van het mainframe system/360 worden weer-
gegeven in de tabel opgesteld vanuit de opvatting van Wieringa (1996-2006), geeft dit tabel
3.1:
Tabel 3.1: Structuuraspect mainframe
structuur subelementen CPU + hoofdopslageenheid
kanalen
systeemcontrolepaneel
besturingssysteem
relatie tussen CPU en multiplexor kanaal
tussen CPU en selector kanaal
tussen CPU en systeemcontrolepaneel
interne interacties opslaan van gegevens
vragen van gegevens
programma laden
start i/o
test i/o
stop i/o
test kanaal
i/o onderbreking
transporteer gegevenselementen
Hoofdstuk 3. Mainframes 46
3.5 Grens
Nu gedefinieerd is wat het systeem bevat, kan gekeken worden wat er in de omgeving zit en
welke interacties plaatsvinden tussen dit systeem en de omgeving. Op basis daarvan kan daarna
gekeken worden in welke mate het systeem dynamisch en modulair is.
3.5.1 Omgeving
Uit figuren 3.1 en 3.2 kan worden besloten dat de i/o apparaten en de controle-eenheden deel
zijn van de omgeving.
I/o apparaten dienen om externe opslagcapaciteit te voorzien en vormen ook een communica-
tiemiddel dat het systeem met de externe wereld verbindt (IBM-DPD, 1964). Met input wordt
bedoeld dat informatie van buiten uit het systeem, in het systeem wordt gebracht terwijl output
net het omgekeerde doet en informatie vanuit het systeem naar de buitenwereld brengt. De
apparaten die dit doen, zijn dus de i/o apparaten en deze vertalen zowel de input gegevens naar
de code van het mainframe system/360 als de code van het mainframe system/360 naar de taal
nodig om de output weer te geven (Germain, 1967). De soorten i/o apparaten zijn: harde schijf
en drum opslageenheden, magnetische tape-eenheden, printers, kaartlezers, kaartprikkers en dis-
play units of in combintie met een toetsenbord ook wel terminals genoemd worden (IBM, 1965;
Germain, 1967; IBM, 1964). Deze terminals konden zich verder van het mainframe system/360
bevinden dan de andere i/o apparaten (IBM, 1964).
Deze i/o apparaten worden via de controle-eenheid verbonden met de kanalen. Zoals reeds
gezegd, worden de trage snelheid apparaten verbonden met het multiplexor kanaal en de hoge
snelheid apparaten met het selector kanaal (IBM, 1967). De controle-eenheid maakt het mogelijk
voor de kanalen om de i/o apparaten te laten werken en te controleren aangezien deze controle-
eenheid de karakteristieken van elk i/o apparaat aanpast aan wat de kanalen kunnen verwerken.
De link tussen deze controle-eenheid en de kanalen wordt ook wel i/o interface genoemd (IBM-
DPD, 1964). Er bestaan verschillende soorten controle-eenheden waarbij de naam dezelfde is
als die van het i/o apparaat waarmee de eenheid gelinkt is, maar waaraan het woord controle
wordt toegevoegd. Display units wordt dus display units control (IBM, 1965). Elke controle-
eenheid kan dan ook maar worden verbonden met het i/o apparaat waarvoor het gemaakt is.
De kant waarmee het met de kanalen wordt verbonden is wel standaard en hier wordt dus
geen onderscheid gemaakt qua verbinding (IBM-DPD, 1964). De controle-eenheden kunnen dus
gezien worden als een soort tussenstuk om de verschillende soorten i/o apparaten te verbinden
met de kanalen. Het is mogelijk verscheidene i/o apparaten van dezelfde soort aan te schakelen
Hoofdstuk 3. Mainframes 47
aan een controle-eenheid en een kanaal kan met een of meer controle-eenheden verbonden worden.
Er moet wel opgemerkt worden dat de functies van de controle-eenheid vaak voor de gebruiker
niet te onderscheiden zijn van de functies van de i/o apparaten. Bovendien gebeurt het vaak
dat de controle-eenheid geıntegreerd is met het i/o apparaat en er dus op het zicht geen twee
verschillende onderdelen te zien zijn (IBM, 1967).
Wat zeker ook interessant is om te vermelden, is dat ook andere mainframe systems/360 in de
omgeving van het mainframe system/360 kunnen zitten. Dit creeert zo een multisysteem confi-
guratie en dit gebeurt via drie soorten communicatieniveaus tussen de CPU’s van de systemen.
Een eerste mogelijkheid is dat een i/o apparaat wordt gedeeld. Er kan ook een directe connectie
bestaan tussen de kanalen of voor sommige modellen van het mainframe system/360 kan de
opslageenheid worden gedeeld (IBM-DPD, 1964).
Verder zitten ook de mensen die het mainframe gebruiken en de ruimte waarin het systeem zich
bevindt in de omgeving van het systeem.
3.5.2 Externe interacties
Aangezien Wieringa (1996-2006) stelt dat de omgeving interageert met het systeem worden hier
de externe interacties van de omgeving met het systeem weergegeven.
De kanalen vertalen bevelen die ze via orders doorgeven aan de i/o apparaten en de controle-
eenheden. Er zijn zes mogelijke bevelen, namelijk: voel, verplaats in kanaal, lees omgekeerd,
schrijf, lees en controleer (IBM, 1967). Het lees bevel zorgt ervoor dat iets gelezen wordt van
het geselecteerde i/o apparaat terwijl het schrijf bevel iets schrijft naar een i/o apparaat. Het
lees omgekeerd bevel doet net hetzelfde als het lees bevel waarbij het externe document in een
omgekeerde richting wordt gelezen. Via het controleer bevel wordt informatie verkregen over
een bepaald i/o apparaat. De voel en verplaats in kanaal bevelen worden niet verder uitgelegd
aangezien deze te specifiek zijn. Deze interacties verlopen meestal in twee richtingen. Als een
kanaal bijvoorbeeld een controleer bevel geeft aan een i/o apparaat, verloopt de interactie van
kanaal naar i/o apparaat maar hierop komt sowieso een reactie van het i/o apparaat waarbij dit
de gevraagde informatie doorgeeft aan het kanaal (IBM-DPD, 1964). Deze interactie verloopt
dan logischerwijze van het i/o apparaat naar het kanaal.
Wat ook als externe interactie wordt gedefinieerd, is iets wat het directe controlekenmerk wordt
genoemd. Hierbij zijn de twee interacties lees direct en schrijf direct waarbij rechtstreeks in-
formatie geschreven of gelezen wordt tussen een externe opslageenheid en de interne hoofd-
Hoofdstuk 3. Mainframes 48
opslageenheid. Normaal gezien wordt zo informatie uitgewisseld via de controle-eenheden en
kanalen maar, niettegenstaande deze route wordt geprefereerd, wordt er toch soms rechtstreeks
geschreven en gelezen (IBM-DPD, 1964).
In punt 3.5.1 werd ook gesteld dat een ander mainframe system/360 deel kan zijn van de omge-
ving van een mainframe system/360. Bijgevolg bestaan tussen deze twee systemen ook externe
interacties. Wanneer de opslageenheden verbonden zijn, kan er informatie worden uitgewisseld
aan de snelheid die de opslageenheden hebben. Ook kan er een signaal worden uitgewisseld
waarbij de ene CPU de andere CPU onderbreekt of waarbij statusinformatie wordt uitgewisseld
(IBM-DPD, 1964).
Zoals reeds gezegd zitten er ook mensen in de omgeving van het systeem. De interacties met het
systeem verlopen echter voornamelijk via de andere elementen in de omgeving van het systeem,
namelijk de i/o apparaten. Enkel via het systeemcontrolepaneel komt de menselijke gebruiker
rechtstreeks in contact met het systeem. De meeste externe interacties zijn dus nagenoeg dezelfde
als de net besproken interacties.
De ruimte waarin het systeem zich bevindt, maakt ook deel uit van de omgeving. Als interactie
kan bijvoorbeeld het geluid dat het systeem maakt, genomen worden (Hall & Fagen, 2003).
Dit geluid wordt afgeleverd aan de omgeving en kan bijgevolg als een externe interactie gezien
worden.
3.5.3 Dynamisch
Volgens Wieringa (1996-2006) is een systeem dynamisch als het interageert met zijn omgeving
aangezien deze interacties plaatsvinden in de tijd. Het is duidelijk uit punt 3.5.2 dat het sys-
teem interageert met zijn omgeving die ook bestaat uit systemen en dat deze interacties niet
allemaal op hetzelfde tijdstip plaatsvinden. Een mainframe system/360 is dus een dynamisch,
observeerbaar systeem.
3.5.4 Modulair
Modulariteit betekent dat het systeem onafhankelijk handelt, volgens Wieringa (1996-2006). In
hoofdstuk 1 werden enkele richtlijnen weergegeven die konden worden gebruikt om te onderzoe-
ken of een systeem modulair is of niet. Deze waren:
• Interactie tussen de systeemcomponenten (cohesie) is groter dan de interactie tussen het
systeem en de omgeving (koppeling). Voor dit eerste punt is moeilijk een voorbeeld te
Hoofdstuk 3. Mainframes 49
vinden om deze veronderstelling te illustreren voor het mainframe system/360. Het is
namelijk zo dat een mainframe system/360 de i/o apparaten nodig heeft om te commu-
niceren met de buitenwereld en hetgeen het verwerkt naar buiten te brengen (IBM-DPD,
1964). Bovendien blijkt uit de bespreking van de interne en externe interacties dat er voor
beide een groot aantal interacties te beschrijven valt. Aan de andere kant is het wel zo dat
niet noodzakelijk alle i/o apparaten aan een systeem moeten gekoppeld worden. Sommige
apparaten kunnen gewoon off-line zijn (IBM-DPD, 1964). Dit is een element dat erop kan
wijzen dat er een grotere interactie bestaat tussen de subelementen dan tussen het systeem
en de omgeving, maar de eerstgenoemde elementen maken dat dit eerste punt niet volledig
toepasbaar is op het mainframe system/360.
• Veranderingen binnen een systeem zouden minimale veranderingen moeten veroorzaken
buiten het systeem. Dit tweede element is wel toepasbaar op het mainframe system/360.
Doordat er een interface bestaat tussen de kanalen en de omgeving (IBM-DPD, 1964) zal
een verandering in het systeem nagenoeg geen invloed hebben op de omgeving. Bovendien
heeft een verandering in het systeem helemaal geen invloed op de gebruikers die het systeem
gebruiken.
• Er zijn meer relaties onder de systeemcomponenten onderling dan tussen de systeemcom-
ponenten en de omgeving. Voor dit derde element kunnen dezelfde bewijzen en tegenbe-
wijzen worden aangehaald als bij het eerste item. Ook hier kan dus niet volledig worden
geıllustreerd dat deze richtlijn toepasbaar is voor het mainframe system/360.
• Er is meer energie nodig om iets over de systeemgrens te transporteren dan om iets binnenin
de systeemgrens te transporteren. Om informatie in de externe wereld te krijgen zijn zowel
enkele interne interacties nodig die bijvoorbeeld het kanaal in werking doen treden als ook
enkele externe interacties die de opdrachten doorgeven aan de i/o apparaten (IBM, 1967;
IBM-DPD, 1964; IBM, 1964). Bijgevolg kan worden gesteld dat er meer energie nodig is
om iets over de systeemgrens te transporteren dan om iets binnenin de systeemgrens te
transporteren.
• De systeemgrens zou zo moeten worden gekozen dat het systeemgedrag eenvoudiger is
dan bij enige andere keuze van systeemgrens. Het laatste element toont aan waarom het
systeemcontrolepaneel met zijn knoppen en hendels (IBM-DPD, 1964) ook binnenin het
systeem wordt verondersteld. Indien dit niet zo zou zijn, zouden bepaalde gedragingen van
het systeem (zoals het resetten van het systeem) niet kunnen worden verklaard. Dit is net
zoals in het voorbeeld van de koffieautomaat (supra, p.14) waar de knop waarop gedrukt
Hoofdstuk 3. Mainframes 50
wordt om koffie te verkrijgen, wordt verondersteld deel uit te maken van de koffieautomaat
en niet van de omgeving. Indien dit niet zo zou zijn, kan het gedrag van de koffieauto-
maat, namelijk koffie zetten, niet volledig worden verklaard. Maar de toepasbaarheid van
deze laatste richtlijn, wordt in twijfel getrokken wanneer gekeken wordt naar de interne
interacties. De meeste interne interacties zijn te verklaren zonder dat hiervoor de externe
systemen nodig zijn. De interacties start i/o, test i/o en halt i/o (IBM-DPD, 1964) zijn
echter moeilijk te verklaren als de i/o apparaten buiten het systeem worden beschouwd.
Wieringa (1996-2006) stelt dat de systeemgrens moet gekozen worden zodat het systeem mo-
dulair is. Uit de vorige analyse is het duidelijk dat de hier gemaakte keuze geen modulair
systeem creeert. Indien de i/o apparaten als deel van het systeem zouden worden beschouwd,
zou bij toepassing van bovenstaande richtlijnen het systeem wel modulair zijn. Toch kan niet
worden verondersteld dat de hier gemaakte keuze omtrent de systeemgrens helemaal verkeerd
is. Vooreerst vormen de gekozen subelementen samen een fysiek apart element zoals op figuur
3.1 zichtbaar is. De tweede en grootste reden waarom de schrijver toch bewust de i/o apparaten
en de controle-eenheden als deel van de omgeving heeft verondersteld, is omdat een mainfra-
me system/360 niet alle i/o apparaten en bijhorende controle-eenheden hoeft aangekoppeld te
hebben. Indien de i/o apparaten als onderdelen van het systeem zouden worden verondersteld,
zitten er bijgevolg soms delen in het systeem die het systeem in de realiteit helemaal niet bevat.
De huidig veronderstelde subelementen zijn in tegenstelling tot sommige i/o apparaten altijd
een deel van het systeem. Vandaar de keuze van de schrijver om de i/o apparaten niet als
onderdeel in het systeem op te nemen. Deze keuze vormt ook geen probleem bij het beschrijven
van de andere elementen van de tabel opgesteld vanuit de opvatting van Wieringa (1996-2006),
namelijk: systeemstructuur, systeemfunctie en systeemgedrag.
3.5.5 Samenvatting
De elementen van het grensaspect toegepast op het mainframe system/360 kunnen in tabel 3.2
worden samengevat:
Hoofdstuk 3. Mainframes 51
Tabel 3.2: Grensaspect mainframe
grens omgeving harde schijf en drum opslageenheden
magnetische tape-eenheden
printers
kaartlezers
kaartprikkers
display units
controle-eenheden
mainframe system/360
mensen
ruimte
externe interacties voel
verplaats in kanaal
lees omgekeerd
schrijf
lees
controleer
lees direct
schrijf direct
informatie uitwisselen
signaal uitwisselen
statusinformatie uitwisselen
interacties met mensen
interacties met ruimte
dynamisch ja
modulair redelijk
3.6 Functie
3.6.1 Functies
Volgens Wieringa (1996-2006) is een functie “een dienst die het systeem aanbiedt aan zijn om-
geving” (Wieringa, 1996-2006, p.22). Het biedt een oplossing voor de behoefte die een gebruiker
heeft.
Hoofdstuk 3. Mainframes 52
De externe interacties tussen het systeem, de i/o apparaten en de controle-eenheden in punt
3.5.2 tonen aan dat er gegevens worden uitgewisseld tussen het systeem en de apparaten in
de omgeving. De functie die het systeem heeft voor i/o apparaten en controle-eenheden, is
bijgevolg het voorzien en uitwisselen van gegevens. Zo verkrijgt bijvoorbeeld het i/o apparaat
printer, gegevens van het mainframe system/360 die kunnen worden geprint. De functie van het
mainframe system/360 in dit geval is de printer te voorzien van de nodige gegevens.
Voor de menselijke omgeving kunnen de functies in drie groepen worden onderverdeeld, name-
lijk: de voornaamste functie, functies als antwoord op bepaalde specifieke behoeftes en enkele
aanvullende funties.
Ten eerste, is de voornaamste functie van het mainframe system/360, grote hoeveelheden ge-
gevens verwerken (Benson, 1983). Bijgevolg werd het mainframe system/360 vooral voor com-
merciele, communicatieve, wetenschappelijke en controle-gerichte toepassingen gebruikt (IBM,
1964). Een voorbeeld hiervan is de banksector (anoniem, 2010). Vandaag de dag wordt vaak
het reservatiesysteem voor tickets van een luchtvaartmaatschappij via een mainframe verwerkt
(Churbuck & Samuels, 1996).
Ten tweede heeft het mainframe system/360 ook nog enkele andere functies die voortkomen
uit een onderzoek van het SPREAD comite. Dit laatste toonde aan dat de gebruikers van
mainframes specifieke behoeftes hadden die door de toen beschikbare mainframes niet werden
vervuld (Gifford & Spector, 1987; IBM, 1964). Deze behoeftes werden bijgevolg omgezet in
functies die het nieuwe mainframe system/360 moest bezitten (Gifford & Spector, 1987). Hier
worden vier zulke behoeftes met bijhorende functie(s) besproken.
Vooreerst hadden menselijke gebruikers behoefte aan een systeem dat kon meegroeien wanneer
nodig (IBM, 1967). Wanneer een bedrijf groeide en meer gegevens moesten worden verwerkt,
betekende dit dat er een nieuw systeem moest worden aangekocht aangezien er geen opwaartse
of neerwaartse compatibiliteit bestond (IBM-DPD, 1964). Aangezien het mainframe system/360
verschillende modellen had die verschilden in verwerkingscapaciteit (IBM, 1967) en die bovendien
neerwaarts en opwaarts compatibel waren, werd deze behoefte vervuld (IBM-DPD, 1964). Ook
de mogelijkheid om extra opslagcapaciteit toe te voegen, droeg bij tot de vervulling van de
behoefte om een systeem te hebben dat kan meegroeien in volume (IBM, 1964).
Ten tweede was er naast de groei in verwerkingscapaciteit ook behoefte aan groei in applicatie-
mogelijkheden (IBM, 1967). Als een bedrijf zowel wetenschappelijke als commerciele gegevens
wilde verwerken, was het genoodzaakt twee verschillende mainframes aan te kopen of men moest
Hoofdstuk 3. Mainframes 53
een keuze maken. Een wetenschappelijke mainframe heeft een grote opslagcapaciteit terwijl een
commerciele mainframe andere eigenschappen heeft. Het mainframe system/360 zorgde voor
een integratie tussen deze systemen en zorgde ervoor dat een keuze maken niet meer nodig was
(IBM, 1964). Het mainframe system/360 is bijgevolg een algemeen systeem dat voor verschil-
lende applicatiemogelijkheden kan worden gebruikt (IBM, 1967; Opler, 1966).
Een extra functie die volgt uit deze twee vorige elementen, is dat er kan bespaard worden
op trainingskosten. Eenmaal een menselijke gebruiker een van de modellen kent, kan hij met
alle modellen werken, aangezien de verschillende modellen compatibel zijn en er een algemeen
systeem is voor verschillende applicatiemogelijkheden (IBM, 1964).
Een derde belangrijkere behoefte vanuit het standpunt van de menselijke gebruiker is dat er
een grote doorstroom kan worden gerealiseerd met het mainframe system/360. De CPU moet
namelijk vaak wachten tot bepaalde i/o operaties afgewerkt zijn om zelf te kunnen verderwerken.
Ook omgekeerd is het zo dat een i/o apparaat vaak niets te doen heeft terwijl de CPU gegevens
verwerkt. Dit zorgt voor een verspilling aan capaciteit (IBM, 1967). Indien de CPU gegevens kan
verwerken terwijl er i/o operaties worden uitgevoerd voor een volgende stap in de CPU en indien
bovendien verscheidene i/o operaties tegelijk kunnen worden uitgevoerd, wordt de verspilling
uitgeschakeld. Daarom hebben de ontwikkelaars van het mainframe system/360 het subelement
kanalen geıntroduceerd aangezien deze de CPU verlichten van werk. Dit zorgt ervoor dat er
zowel gegevens kunnen worden verwerkt in de CPU als operaties kunnen worden uitgevoerd
door een i/o apparaat. Om ervoor te zorgen dat er verscheidene i/o operaties mogelijk zijn,
bestaan er twee soorten kanalen: een multiplexor kanaal voor de trage snelheid apparaten en
een selector kanaal voor de hoge snelheid apparaten (Germain, 1967).
Een laatste belangrijke behoefte is het verminderen van het aantal interventies van de menselijke
gebruiker. Aangezien er alsmaar meer menselijke gebruikers waren en ook de programma’s
complexer werden (Thomas, 1971), werden er vaak grote fouten gemaakt (IBM, 1964). Bijgevolg
werd er een besturingsprogramma ontwikkeld waarbij het mainframe system/360 zichzelf kon
beheren (IBM, 1964). De menselijke gebruikers hebben nog steeds toegang tot de gegevens van
het systeem via het systeemcontrolepaneel dat deel is van het systeem (IBM-DPD, 1964) of via
de terminals die vanop grote afstand verbonden zijn met het systeem (IBM, 1967).
De derde groep functies die het mainframe system/360 vervult, zijn de aanvullende functies.
Zo moest er software worden ontwikkeld voor het mainframe system/360 wat door IT-gerichte
personen werd gedaan. Hier heeft het mainframe system/360 als functie werk creeren. Ook waren
Hoofdstuk 3. Mainframes 54
lessen nodig om mensen op te leiden die konden werken met mainframes en meer specifiek in
ons geval met het mainframe system/360. Bijgevolg had het mainframe system/360 in dit geval
de functie van lesmateriaal.
3.6.2 Gebruikers
De gebruikers van het mainframe system/360 zijn de systemen in de omgeving van het mainframe
system/360 die hun behoefte vervullen door interactie met het mainframe system/360 (Wieringa,
1996-2006). Bijgevolg zijn niet alle elementen die deel zijn van de omgeving ook gebruikers van
het systeem.
De bespreking van de functies toonde aan dat de i/o apparaten en de controle-eenheden gebrui-
kers zijn van het systeem. Ook de mensen in de omgeving van het systeem zijn gebruikers van
het systeem. Deze menselijke omgeving kan worden onderverdeeld in drie subgroepen: bedrijfs-
gebruikers, IT-gebruikers, en lesgevers en studenten.
In de jaren ’60 toen het mainframe system/360 werd ontwikkeld, was er helemaal geen sprake
van een computer in een huisgezin. Ook de arbeiders op de werkvloer of de bedienden in
de kantoren hadden vaak nog geen persoonlijke computer bij zich, zoals nu het geval is. De
bedrijfsgebruikers bestonden dan ook voornamelijk uit mensen van het management team, die
dit systeem gebruikten om gegevens te verkrijgen voor bepaalde beslissingen (Benson, 1983),
en personen die zo een systeem nodig hadden voor hun werk, bijvoorbeeld wetenschappers.
De functie van het mainframe system/360 om grote hoeveelheden gegevens te verwerken en
de behoeftes te vervullen die de vorige generaties mainframes niet vervulden, hebben vooral
betrekking op deze groep van menselijke gebruikers.
Diegenen die ook vaak in contact kwamen met de mainframes waren de IT-gebruikers. Deze
ontwikkelden software voor het mainframe system/360 en zorgden voor het onderhoud van het
mainframe (Churbuck & Samuels, 1996).
De groep lesgevers en studenten gebruikten het mainframe system/360 om mensen op te leiden
zodat deze konden werken met het mainframe. Deze personen zijn ook gebruikers van het main-
frame system/360, maar dan voor een heel andere functie dan de andere menselijke gebruikers.
Het feit dat Wieringa (1996-2006) zegt dat een element van de omgeving pas een gebruiker is
als dit het systeem gebruikt om zijn behoefte te vervullen, maakt duidelijk waarom volgens deze
definitie de ruimte waarin het systeem zich bevindt, geen gebruiker is. De ruimte zit wel in de
omgeving van het systeem maar aangezien het geen behoefte vervult door te interageren met
Hoofdstuk 3. Mainframes 55
het systeem, kan het niet als een gebruiker worden beschouwd.
3.6.3 Samenvatting
Tabel 3.3 geeft een samenvatting weer van de elementen functies en gebruikers voor het main-
frame system/360:
Tabel 3.3: Functie mainframe
functie functies uitwisselen van gegevens
grote hoeveelheden gegevens verwerken
meegroeien in volume
groei in applicatiemogelijkheden
besparing op trainingskosten
grotere doorstroom
verminderen menselijke interventies
werk creeren
lesmateriaal
gebruikers niet-menselijke systemen in de omgeving
bedrijfsgebruikers
IT-gebruikers
lesgevers en studenten
3.7 Gedrag
3.7.1 Toestand
Een mainframe system/360 heeft een aan- en uitknop (IBM-DPD, 1964). Wanneer het mainfra-
me aanstaat, zijn verschillende situaties mogelijk wat betreft de werking van de subelementen,
de hoofdopslageenheid buiten beschouwing gelaten. Bij een eerste mogelijk scenario is de CPU
gegevens aan het verwerken, maar verwerken de kanalen niets. In een ander scenario is net het
omgekeerde het geval en verwerkt de CPU niets, terwijl de kanalen wel in actie zijn. Het is ook
mogelijk dat beide in actie zijn of omgekeerd dat beide niets verwerken. Het systeem is bij dit
laatste wel aan, maar er gebeurt niets. Dit zijn alle mogelijke toestanden die het systeem kan
aannemen indien voor een lange periode naar het systeem wordt gekeken.
Hoofdstuk 3. Mainframes 56
3.7.2 Acties
In dit punt wordt dieper ingegaan op de acties in twee van de subelementen: CPU en kanalen.
De acties in het besturingssysteem en het systeemcontrolepaneel zijn niet relevant voor deze
thesis. Indien de hoofdopslageenheid zich in de CPU bevindt dan zijn de twee interne interacties:
opslaan van gegevens en vragen van gegevens beschreven in punt 3.4.2 acties. Aangezien het
programma dat in de CPU aanwezig is ook moet worden uitgevoerd, zijn er ook acties als
interpreteer opdracht (Thomas, 1971) en verwerk informatie (IBM-DPD, 1964). Het eerste
wordt uitgevoerd door het besturingssysteem in de CPU terwijl de tweede actie wordt uitgevoerd
door de ALU. De verwerking van deze informatie in de ALU wordt uitgevoerd door de operaties
optelling, aftrekking, vermenigvuldiging en deling (Thomas, 1971).
Ook de kanalen hebben als actie het uitvoeren van een programma. Het vertaalt ook de op-
drachten die het krijgt van de CPU en doorgeeft aan de i/o apparaten (IBM, 1967). Bovendien
controleert het ook de informatie die het verkrijgt van de i/o apparaten op validiteit. Enkele
andere acties die de kanalen nog uitvoeren, zijn: tellen van het aantal bytes die worden verwerkt
en het onderhouden van zijn status informatie. Dit laatste geeft weer of het kanaal vrij is of als
het in actie is en geen nieuwe opdracht kan verwerken.
3.7.3 Samenvatting
Als samenvatting voor de termen toestand en acties kan tabel 3.4 worden weergegeven:
Hoofdstuk 3. Mainframes 57
Tabel 3.4: Gedrag mainframe
gedrag toestand aan: CPU verwerkt gegevens, kanalen verwerken niets
aan: CPU verwerkt niets, kanalen verwerken gegevens
aan: CPU en kanalen verwerken gegevens
aan: CPU en kanalen verwerken niets
uit
acties opslaan van gegevens
vragen van gegevens
interpreteer opdracht
verwerk informatie
uitvoeren programma
vertaal opdrachten
controleer validiteit
tel aantal bytes
onderhoud status informatie
3.8 Conclusie
In dit hoofdstuk werd de opvatting van Wieringa (1996-2006) toegepast op het mainframe sys-
tem/360. Het mainframe system/360 heeft een grote invloed uitgeoefend op de computergeschie-
denis, wat de keuze voor deze mainframe ondersteunde. Bij de toepassing van de tabel opgesteld
vanuit de opvatting van Wieringa (1996-2006) werd eerst de structuur besproken en daarna het
grensaspect. Dit werd gevolgd door de bespreking van de functie en daarna het gedrag van het
mainframe system/360. De resultaten van deze bespreking kunnen worden samengevat in tabel
3.5. Deze vat de tabellen 3.1, 3.2, 3.3 en 3.4 samen.
Tabel 3.5: Toepassing van de opvatting van Wieringa (1996-2006) op het mainframe system/360
structuur subelementen CPU + hoofdopslageenheid
kanalen
systeemcontrolepaneel
besturingssysteem
relatie tussen CPU en multiplexor kanaal
tussen CPU en selector kanaal
Deze tabel gaat verder op de volgende bladzijde
Hoofdstuk 3. Mainframes 58
tussen CPU en systeemcontrolepaneel
interne interacties opslaan van gegevens
vragen van gegevens
programma laden
start i/o
test i/o
stop i/o
test kanaal
i/o onderbreking
transporteer gegevenselementen
grens omgeving harde schijf en drum opslageenheden
magnetische tape-eenheden
printers
kaartlezers
kaartprikkers
display units
controle-eenheden
mainframe system/360
mensen
ruimte
externe interacties voel
verplaats in kanaal
lees omgekeerd
schrijf
lees
controleer
lees direct
schrijf direct
informatie uitwisselen
signaal uitwisselen
statusinformatie uitwisselen
interacties met mensen
interacties met ruimte
dynamisch ja
Deze tabel gaat verder op de volgende bladzijde
Hoofdstuk 3. Mainframes 59
modulair redelijk
functie functies uitwisselen van gegevens
grote hoeveelheden gegevens verwerken
meegroeien in volume
groei in applicatiemogelijkheden
besparing op trainingskosten
grotere doorstroom
verminderen menselijke interventies
werk creeren
lesmateriaal
gebruikers niet-menselijke systemen in de omgeving
bedrijfsgebruikers
IT-gebruikers
lesgevers en studenten
gedrag toestand aan: CPU verwerkt gegevens, kanalen verwerken niets
aan: CPU verwerkt niets, kanalen verwerken gegevens
aan: CPU en kanalen verwerken gegevens
aan: CPU en kanalen verwerken niets
uit
acties opslaan van gegevens
vragen van gegevens
interpreteer opdracht
verwerk informatie
uitvoeren programma
vertaal opdrachten
controleer validiteit
tel aantal bytes
onderhoud status informatie
Hoofdstuk 4
Business Process Management
Systems
4.1 Inleiding
Een tweede soort van informatiesystemen zijn Business Process Management Systems (BPMSs).
Ook hierop wordt de theorie van Wieringa (1996-2006) toegepast via de opgestelde tabel. Als
voorbeeldsysteem wordt het BPMS van Intalio gebruikt. De keuze voor het Intalio BPMS wordt
verantwoord door het feit dat dit een van de enige volledig uitgewerkte open source BPMSs is,
en deze vorm vandaag veel aandacht krijgt door de toegenomen economische onzekerheid (Hill
et al., 2009). Hiervan wordt vooreerst de structuur besproken, daarna het grensaspect, gevolgd
door het functieaspect en het gedragsaspect.
4.2 Definitie
Om een BPMS duidelijk te definieren worden een aantal definities weergegeven namelijk deze
van Smith & Fingar (2007), Frankel (2003), Shaw et al. (2007) en Hill et al. (2009).
Smith & Fingar (2007) geven de volgende definitie: “Een Business Process Management System
laat de onderneming toe om missiekritische bedrijfsprocessen, die verscheidene bedrijfsapplica-
ties, departementen en bedrijfspartners overspannen, te modelleren, uit te voeren en te beheren
- achter de firewall en over het internet” (Smith & Fingar, 2007, p.233).
Frankel (2003) stelt dat “een BPMS - dat een software tool is - processen beheert in een ‘pro-
cesbasis’ die extern is ten opzichte van individuele applicaties” (Frankel, 2003, p.1).
60
Hoofdstuk 4. Business Process Management Systems 61
Shaw et al. (2007) vergelijken een BPMS met een bedrijfsproces om een BPMS te definieren.
“Een bedrijfsproces is een socio-technisch systeem uitgevoerd door mensen en machines en een
BPMS is een puur technisch systeem” (Shaw et al., 2007, p.92).
Als laatste wordt de definitie van Hill et al. (2009) vermeld. Zij definieren een BPMS als
“een geıntegreerde collectie van softwaretechnologieen die de controle en het beheer van een
bedrijfsproces mogelijk maakt” (Hill et al., 2009, p.8).
De definitie van Smith & Fingar (2007) bevat de meeste elementen, maar de definitie van Hill
et al. (2009) leunt sterk bij deze aan. Samenvattend kan worden gesteld dat een BPMS een
software tool is dat toelaat bedrijfsprocessen binnenin een onderneming en over verschillende
ondernemingen heen te beheren en te controleren en deze op te slaan in een ‘proces basis’ (Smith
& Fingar, 2007; Frankel, 2003; Shaw et al., 2007; Hill et al., 2009).
4.3 Structuur
In dit eerste element van de tabel opgesteld vanuit de opvatting van Wieringa (1996-2006) wordt
de structuur van het BPMS van Intalio geanalyseerd. Er wordt gekeken wat de subelementen
en de hieronder bestaande interacties zijn.
4.3.1 Subelementen
Het Intalio BPMS bestaat uit twee aparte delen, namelijk: de Intalio|Designer en de Intalio|Ser-
ver. Dit zijn de twee subelementen van het BPMS zoals op figuur 4.1 wordt weergegeven.
Figuur 4.1: Het BPMS van Intalio met de twee subelementen
Hoofdstuk 4. Business Process Management Systems 62
Deze twee elementen stellen de softwarecomponenten voor van het BPMS. Het hardwarecom-
ponent van het BPMS is een computer. Zonder een computer om het BPMS op te installeren,
kan het BPMS niet worden opgestart. Bijgevolg wordt de computer als onderdeel gezien van
het systeem als hardwarecomponent. Via deze computer krijgt een menselijke gebruiker toe-
gang tot het BPMS. Dit is nodig aangezien de twee onderdelen van het BPMS de gebruiker
nodig hebben om te werken. Zo wordt in Intalio|Designer gewerkt door de gebruikers en ook de
Intalio|Server heeft de mens nodig, namelijk om deze op te starten. Deze computer bevat ook
een besturingssysteem dat nodig is om programma’s zoals het BPMS te kunnen laten draaien.
Figuur 4.2: Intalio|Designer
In wat volgt, wordt dieper ingegaan op de twee softwarecomponenten van het Intalio BPMS
weergegeven in figuur 4.1.
Vooreerst, de Intalio|Designer, die in figuur 4.2 wordt weergegeven. De Intalio|Designer is een
procesmodellering programma dat zowel door bedrijfsanalisten als door software-ingenieurs ge-
bruikt wordt om processen te modelleren. Hierin kunnen naast het zelf modelleren van be-
drijfsprocessen ook reeds bestaande bedrijfsprocessen worden geımporteerd (Finkelstein, 2005).
Figuur 4.2 geeft in het midden het bedrijfsproces weer dat in hoofdstuk 2 (supra, 23) werd ge-
bruikt. De voornaamste subelementen van de Intalio|Designer zijn, zoals op figuur 4.1 zichtbaar
is: het BPMN pallet, de Data Mapper, de Data Editor en de Web Service Definition Language
(WSDL) Visual Connector. Het BPMN pallet is een verzameling van BPMN elementen die
kunnen worden geselecteerd en gebruikt om het proces dat iemand wil weergeven te creeren.
Hoofdstuk 4. Business Process Management Systems 63
Voor het proces in figuur 4.2 wordt dit rechts weergegeven. De Intalio|Designer doet echter
meer dan gewoon processen modelleren. De Data Mapper en de Data Editor zorgen er samen
voor dat de gegevens die zich ontwikkelen gedurende de werking van een proces goed beheerd
worden. De Data Mapper doet dit nog steeds op een grafische wijze waarbij bijvoorbeeld kan
worden gedefinieerd welke gegevens er naar het proces worden gezonden. De Data Editor werkt
al met BPEL concepten waardoor er een overzicht wordt gegeven van het uitvoerbare model.
Het is interessant te vermelden dat de Data Mapper en de Data Editor rechtstreeks met elkaar
zijn verbonden waardoor veranderingen in de ene meteen worden doorgevoerd bij de andere.
Een laatste element namelijk de WSDL Visual Connector zorgt ervoor dat ook diensten kunnen
worden ingevoerd en bewerkt. De Intalio|Designer wordt ondersteund door de software Eclipse
(Intalio, 2007).
De Intalio|Server is het tweede subelement van het softwaregedeelte. Deze voert het proces
uit (Finkelstein, 2005), genereert gebeurtenissen om aan te tonen waar het proces zich bevindt
en stuurt opdrachten door naar de menselijke gebruiker. Het wordt gestart via een startop-
dracht. Eenmaal deze opdracht gegeven, worden de nodige elementen geladen om de twee
subelementen van de Intalio|Server te kunnen openen via het internet of intranet. Zoals op
figuur 4.1 is aangeduid, zijn deze twee subelementen van de Intalio|Server de Intalio|Console en
de Intalio|Workflow. De Intalio|Console is meer een administratieve console. Ze geeft een over-
zicht van de beschikbare processen, waarbij deze processen kunnen worden aangeklikt en worden
gestart. Het is ook mogelijk om een zicht te krijgen waar het proces zich op dit moment bevindt.
De voornaamste knoppen om deze acties te ondernemen zijn start, deploy en lijst van processen
(Intalio-website, 2010). Een deel van de Intalio|Console wordt in figuur 4.3 weergegeven.
Hoofdstuk 4. Business Process Management Systems 64
Figuur 4.3: Intalio|Console (Intalio-website, 2010)
Een tweede subelement van de Intalio|Server is de Intalio|Workflow. Deze wordt ook toegankelijk
via intranet of internet en is een gebruikersinterface voor diegenen die de taken moeten uitvoe-
ren die de Intalio|Server rondstuurt. Via een gebruikersnaam en paswoord krijgt de gebruiker
toegang tot het Intalio|Workflow systeem waar hij zijn persoonlijke taken kan zien die hij moet
uitvoeren om het proces verder te laten lopen (Intalio-website, 2010). Zo een Intalio|Workflow
en de bijhorende taken zien er als volgt uit (figuur 4.4):
Hoofdstuk 4. Business Process Management Systems 65
Figuur 4.4: Intalio|Workflow (Intalio-website, 2010)
4.3.2 Relatie en interne interacties
Figuur 4.1 geeft de relatie weer tussen de subelementen van het Intalio BPMS. Aangezien er maar
twee subelementen zijn, is er maar een relatie mogelijk, namelijk deze tussen de Intalio|Designer
en de Intalio|Server. De interne interacties zijn niet zo uitgebreid, voornamelijk omdat er
maar twee subelementen zijn. De voornaamste interactie die tussen de Intalio|Designer en de
Intalio|Server kan worden geıdentificeerd is de interactie deploy. Aangezien het model in de
Intalio|Designer naar de Intalio|Server moet worden gebracht om te kunnen worden uitgevoerd,
bestaat hiertussen de interactie die in het Engels deploy wordt genoemd. Dit mag niet worden
geınterpreteerd als zijnde uitvoeren maar eerder als het omzetten naar. Deze stap zorgt ervoor
dat het model dat nog steeds in BPMN staat, kan worden uitgevoerd door de Intalio|Server die
met BPEL code werkt.
4.3.3 Samenvatting
De toepassing van het structuuraspect op het BPMS van Intalio kan in tabel 4.1 worden samen-
gevat:
Hoofdstuk 4. Business Process Management Systems 66
Tabel 4.1: Structuuraspect BPMS
structuur subelementen computer met besturingssysteem
Intalio|Designer
Intalio|Server
relatie tussen de Intalio|Designer en de Intalio|Server
interne interacties deploy
4.4 Grens
In dit onderdeel wordt de omgeving van het systeem geanalyseerd en de bijhorende externe
interacties tussen het systeem en de omgeving. Op basis van deze informatie wordt gekeken in
hoeverre het systeem dynamisch en modulair is.
4.4.1 Omgeving
De omgeving van het BPMS bestaat uit verschillende systemen, waarvan er hier negen worden
besproken.
Een eerste element is een BPM opslageenheid of zoals Frankel (2003) het ook nog noemt een
procesbasis. Dit bevat een verzameling van processen, waarvan het volledige proces of delen
ervan kunnen hergebruikt worden via deze opslageenheid. Bovendien kan deze verzameling aan
processen gebruikt worden om deze te onderzoeken en beter te begrijpen hoe deze werken. Deze
verzameling van processen maakt het mogelijk om een ‘kennisbasis’ aan te leggen die informatie
bevat die voordien enkel voor individuele mensen beschikbaar was. Dit samenbrengen van
processen maakt het mogelijk om deze kennis te delen met een grote groep mensen. (Stineman,
2007)
Een tweede element in de omgeving dat bovendien ook een link met de BPM opslageenheid bevat,
is het Business Activity Monitoring (BAM) systeem. Hierin worden Key Performance Indicators
(KPI) en processen geanalyseerd (Stineman, 2007). De Intalio|Server creeert gebeurtenissen die
aantonen waar een proces zit en deze worden doorgegeven aan het BAM systeem dat deze
gegevens omzet in KPI’s. Deze KPI’s worden zorgvuldig bijgehouden en wanneer een proces
afwijkt van zijn normale werking, wordt hiervoor een signaal gegenereerd (Silver, 2006). Deze
waarschuwingen worden aan de bedrijfsmensen doorgegeven via dashboards of e-mail. Deze
dashboards laten ook toe om de bedrijfsmensen inzicht te geven in het verloop van het proces
Hoofdstuk 4. Business Process Management Systems 67
en eveneens waar het proces zich bevindt qua verwerkingsfase (Stineman, 2007). Om deze
processen te kunnen analyseren heeft het BAM systeem waarschijnlijk toegang tot de BPM
opslageenheid. Figuur 4.5 geeft een voorbeeld van zo een dashboard waar enkele gegevens op
worden weergegeven.
Figuur 4.5: Een voorbeeld van een dashboard in een BAM systeem (Intalio-website, 2010)
Een derde element in de omgeving van het BPMS is een systeem dat bedrijfsregels bevat. Dit
zorgt ervoor dat bepaalde beslissingen automatisch gebeuren (Silver, 2006; Stineman, 2007).
Deze bedrijfsregels kunnen door het gemodelleerde proces in de Intalio|Designer worden opge-
roepen. De combinatie van deze regels met de Intalio|Designer maakt het gemakkelijker om
bepaalde processen te modelleren in de Intalio|Designer. Een voorbeeld van een bedrijfsregel
die in een beslissingstabel wordt weergegeven, wordt in figuur 4.6 weergegeven (Intalio-website,
2010).
Hoofdstuk 4. Business Process Management Systems 68
Figuur 4.6: Een voorbeeld van een beslissingstabel in het systeem dat de bedrijfsregels bevat (Intalio-
website, 2010)
Ten vierde zitten er ook printers in de omgeving van het Intalio BPMS. Op figuur 4.2 wordt
namelijk links bovenaan een printknop weergegeven. Deze toont aan dat het Intalio|Designer
subelement verbonden moet zijn met een externe printer die het gemodelleerde proces kan
afdrukken. Bovendien heeft elke werknemer die opdrachten krijgt op zijn computer van de
Intalio|Workflow vaak ook een printer verbonden aan deze computer. Hiermee kunnen docu-
menten worden afgedrukt wanneer dit nodig is voor de opdracht die via de Intalio|Workflow
wordt gegeven. Ook is het mogelijk de dashboards die informatie bevatten over het verloop van
het proces, af te drukken.
Ten vijfde zitten er ook andere bedrijfssystemen in de omgeving van het BPMS, zoals een
Customer Relationship Management (CRM) systeem en legacy systemen. Deze maken gebruik
van het BPMS om processen te beheren (Smith & Fingar, 2007).
Een zesde element in de omgeving van het Intalio BPMS zijn andere BPMSs. Vandaag de
dag moeten bedrijven hun relatie met bedrijfspartners beter beheren en moeten ze meer belang
hechten aan een volledige value chain die meerdere bedrijven bevat (Smith & Fingar, 2007).
Om dit te verwezenlijken zitten ook andere ondernemingen in de omgeving van het BPMS of
meer specifiek ook ander BPMSs.
Ten zevende zijn er ook heel wat mensen die interageren met het systeem en bijgevolg ook in de
omgeving zitten.
Hoofdstuk 4. Business Process Management Systems 69
Achtste element: de ruimte waarin de computer die het BPMS bevat, zich bevindt, kan ook als
onderdeel van de omgeving worden gezien.
Tenslotte, kunnen ook voorbeeldprocessen als onderdeel van de omgeving worden gezien. Het
zijn modelvormen van processen zoals het verwerken van facturen (Stineman, 2007). Deze
standaarden kunnen worden geıntegreerd in de Intalio|Designer en worden aangepast indien
nodig. De aanwezigheid van zulke modelvormen vermindert en verlicht het werk aanzienlijk.
4.4.2 Externe Interacties
Aangezien bovenstaande elementen in de omgeving van het BPMS systeem zitten, interageren
ze volgens Wieringa (1996-2006) ook met het systeem. Bijgevolg worden hier enkele externe
interacties vermeld tussen deze elementen in de omgeving en het systeem.
Een eerste en belangrijke interactie bestaat tussen het BPMS en de BPM opslageenheid. Tussen
deze twee systemen worden voornamelijk processen uitgewisseld. Een interactie kan dus zijn
exporteer proces waarbij een proces gecreeerd in bijvoorbeeld Intalio|Designer wordt bewaard
in de BPM opslageenheid. De omgekeerde interactie namelijk importeer proces bestaat ook,
aangezien een volledig proces of delen ervan kunnen worden hergebruikt (Frankel, 2003).
Ook tussen het BPMS en het BAM systeem kan een voorbeeld van een interactie worden gegeven.
De KPI’s die in het BAM systeem zijn gecreeerd, kunnen toegevoegd worden aan het procesmodel
in de Intalio|Designer. Figuur 4.7 toont aan hoe deze toevoeging eruit ziet in de Intalio|Designer
(Intalio-website, 2010).
Hoofdstuk 4. Business Process Management Systems 70
Figuur 4.7: Een KPI toevoegen vanuit het BAM systeem naar de Intalio|Designer (Intalio-website,
2010)
Tussen het BPMS en het systeem dat de bedrijfsregels bevat, kan de interactie plaatsvinden
waarbij de Intalio|Designer de gecreeerde regels aanroept om deze te kunnen uitvoeren. Figuur
4.8 toont aan dat via de pool BRE een beslissingstabel over leeftijden van studenten wordt
opgeroepen om het bedrijfsproces uit te voeren (Intalio-website, 2010).
Hoofdstuk 4. Business Process Management Systems 71
Figuur 4.8: Een voorbeeld van een externe interactie waarbij een beslissingstabel wordt opgeroepen
(Intalio-website, 2010)
Door het toegenomen belang van samenwerking met bedrijfspartners (Smith & Fingar, 2007)
wordt het ook belangrijker de link tussen BPMSs van verschillende organisaties te identifice-
ren. Hoogstwaarschijnlijk worden hier onderdelen van de interne processen van de verschillende
organisaties uitgewisseld.
Wanneer de Intalio|Server in actie is, geeft hij ook opdrachten door aan menselijke deelnemers
van het proces dat wordt uitgevoerd (Silver, 2006). Deze uitwisseling van taken is een externe
interactie tussen de Intalio|Server of beter het subelement Intalio|Workflow en de menselijke
gebruiker. Er zijn ook vele interacties tussen de menselijke gebruiker en het systeem, die on-
rechtstreeks verlopen met name via de andere systemen in de omgeving van het BPMS.
De ruimte waarin de computer waar het BPMS op is geınstalleerd, zich bevindt, maakt ook deel
uit van omgeving. Hier kan het geluid dat de computer maakt, gezien worden als een interactie
tussen het systeem en de ruimte.
Hoofdstuk 4. Business Process Management Systems 72
4.4.3 Dynamisch
Volgens Wieringa (1996-2006) is een systeem dynamisch als het interageert met zijn omgeving
aangezien deze interacties plaatsvinden in de tijd. Uit de externe interacties in punt 4.4.2 kan
worden geconcludeerd dat het BPMS interageert met systemen in zijn omgeving en dat deze
interacties niet allemaal op hetzelfde ogenblik in de tijd plaatsvinden. Bijgevolg is een BPMS
een dynamisch, observeerbaar systeem.
4.4.4 Modulair
Volgens Wieringa (1996-2006) is een systeem dat onafhankelijk handelt een modulair systeem.
Om deze modulariteit te onderzoeken gaf hij onderstaande richtlijnen:
• Interactie tussen de systeemcomponenten (cohesie) is groter dan de interactie tussen het
systeem en de omgeving (koppeling). Er vindt maar een interactie plaats tussen de twee
subelementen van het BPMS. Bovendien heeft het BPMS de elementen in de omgeving
nodig om het proces dat gemodelleerd werd uit te voeren. Zo kan het proces bijvoorbeeld
zonder de menselijke gebruikers niet werken aangezien de opdrachten die worden doorge-
stuurd niet worden uitgevoerd. Ook stellen Vollmer & Peyret (2006) dat een BPMS de
hele levenscyclus van een proces ondersteunt zoals op figuur 4.9 te zien is:
Figuur 4.9: Een BPMS ondersteunt de hele levenscyclus van een proces (Vollmer & Peyret, 2006)
Om dit mogelijk te maken is, zoals op figuur 4.9 zichtbaar is, meer nodig dan enkel de
elementen van het Intalio BPMS. Ook de elementen uit de omgeving zijn nodig om dit
te verwezenlijken. Bijgevolg kan hier niet worden besloten dat de interactie tussen de
systeemcomponenten groter is dan de interactie tussen het systeem en de omgeving.
• Veranderingen binnen een systeem zouden minimale veranderingen moeten veroorzaken
buiten het systeem. Ook voor dit tweede item kan niet beslist worden dat deze veronder-
stelling klopt voor het BPMS. Het is namelijk zo dat de veranderingen die in het systeem
Hoofdstuk 4. Business Process Management Systems 73
kunnen plaatsvinden, veranderingen zijn aan de onderliggende code om de Intalio|Designer
en de Intalio|Server te creeren. Indien deze code op een incorrecte manier wordt gewijzigd,
kan het gebeuren dat de connecties met de elementen uit de omgeving niet meer werken.
• Er zijn meer relaties onder de systeemcomponenten onderling dan tussen de systeemcom-
ponenten en de omgeving. Uit de bespreking van de interne en externe interacties kan hier
worden besloten dat deze veronderstelling niet opgaat. Er is namelijk maar een interactie
onder de subelementen terwijl er veel meer interacties mogelijk zijn tussen het systeem en
de omgeving.
• Er is meer energie nodig om iets over de systeemgrens te transporteren dan om iets binnenin
de systeemgrens te transporteren. Indien er verscheidene interne interacties nodig zouden
zijn voor er een externe interactie kan plaatsvinden, zou deze veronderstelling kunnen
kloppen. Hier is er echter maar een interne interactie. Bovendien verlopen de externe
interacties voornamelijk automatisch en hoofdzakelijk via het aanwezige netwerk in de
organisatie. De energie die hierbij te pas komt, is te verwaarlozen.
• De systeemgrens zou zo moeten worden gekozen dat het systeemgedrag eenvoudiger is dan
bij enige andere keuze van systeemgrens. Dit laatste item kan in tegenstelling tot de andere
items wel worden toegepast op het BPMS. Zo is de computer als hardware component,
deel van het systeem om het gedrag beter te kunnen verklaren aangezien zonder computer
het systeem niet zou kunnen worden gebruikt. Het grote aantal elementen in de omgeving
is wel nodig om het proces uit te voeren dat in het BPMS wordt gemaakt. Deze elementen
opnemen in het systeem zou echter een ingewikkeld systeem creeren waarvan het gedrag
een ingewikkeld kluwen van interacties wordt. De hier gemaakte keuze maakt het gedrag
bijgevolg eenvoudiger te verklaren.
Ondanks dit laatste positieve element kan niet worden gesteld dat het systeem modulair is. Ver-
scheidene elementen spreken het modulair zijn van het systeem tegen. Het systeem is bovendien
niet tastbaar wat het moeilijker maakt om het als modulair te definieren.
4.4.5 Samenvatting
Wanneer de termen omgeving, externe interacties, dynamisch en modulair worden weergegeven
voor het BPMS van Intalio geeft dit tabel 4.2:
Hoofdstuk 4. Business Process Management Systems 74
Tabel 4.2: Grensaspect BPMS
grens omgeving BPM opslageenheid
BAM systeem
systeem met bedrijfsregels
printer
andere bedrijfssystemen
BPMS
mensen
ruimte
voorbeeldprocessen
externe interacties exporteer proces
importeer proces
toevoegen KPI
aanroepen bedrijfsregels
uitwisselen procesonderdelen
interacties met mensen
interacties met ruimte
dynamisch ja
modulair in beperkte mate
4.5 Functie
4.5.1 Functies
Volgens Wieringa (1996-2006) biedt een functie een oplossing voor een behoefte van een gebrui-
ker. Een eerste functie die een BPMS bezit, is dat het met andere niet-menselijke systemen
in zijn omgeving gegevens uitwisselt die deze systemen nodig hebben. Zo is de functie van het
BPMS voor de BPM-opslageenheid deze te voorzien van processen om die te kunnen onderzoe-
ken.
Voor de menselijke systemen is een BPMS een technologie die de BPM theorie ondersteunt (Hill
et al., 2009). Deze theorie is ontstaan uit de druk die ondernemingen ondervinden door de
verhoogde macht van de klant en door de globalisering die de competitie verhoogde. Dit zorgt
ervoor dat je als onderneming niet alleen beter, sneller en goedkoper moet zijn, maar ook je
Hoofdstuk 4. Business Process Management Systems 75
klant op een speciale manier moet weten te behagen (Smith & Fingar, 2007). Smith & Fingar
(2007) stellen dat er zich vandaag de dag zeven belangrijke trends voordoen waar BPM een
oplossing voor is, namelijk:
• De klant is de nieuwe dictator
• Massaproductie moet plaats maken voor mass customization
• Klanten vragen totale oplossingen
• De industriegrenzen vervagen
• Value chains worden de nieuwe eenheid van competitie
• Collaboratie en coopetition vervangen de traditionele vormen van competitie
• Verandering is de enige zekerheid
Onderstaande definitie toont wat BPM volgens Smith & Fingar (2007) kan verwezenlijken,
rekening houdend met de vorige zeven trends: “Bedrijven die een BPM competentie bezitten,
zullen hun klanten sneller en beter kunnen bedienen. Ze zullen betere kwaliteit kunnen aanbieden
tegen een lagere kost met grotere schaaleconomieen, wat hun winstgevendheid zal verhogen.
Ze zullen sneller kunnen reageren op nieuwe opportuniteiten die zich voordoen in de markt
via het bundelen of ontbundelen van bedrijfsrelaties, zowel in hun vraag- als aanbodkanalen”
(Smith & Fingar, 2007, p.141). BPM heeft een ondersteunende technologie om dit allemaal te
verwezenlijken, namelijk het BPMS (Cummings, 2008). Zonder deze technologie is er wel een
BPM theorie, maar is er geen methode om deze theorie om te zetten in de praktijk. Bijgevolg is
deze ondersteunende functie zeker een eerste functie die BPMS vervult en die voor menselijke
gebruikers geldt.
Een BPMS voert deze ondersteunende functie uit aan de hand van enkele andere functies die
het bezit. Zo laat een BPMS vooreerst toe dat bedrijfslogica wordt losgekoppeld van de in-
frastructuur waardoor applicaties sneller kunnen worden ontwikkeld (Silver, 2006). Dit laat de
onderneming toe om sneller in te spelen op veranderingen die volgens Smith & Fingar (2007) de
enige zekerheid zijn.
Een tweede functie die een BPMS ook bezit is dat het bedrijfsprocessen kan modelleren en
analyseren (Hill et al., 2009). Deze modellering en analyse zorgt voor kennis in verband met de
bedrijfsprocessen, wat het gemakkelijker toelaat om producten aan te passen aan de klant.
Hoofdstuk 4. Business Process Management Systems 76
Het heeft ten derde ook de mogelijkheid om interacties te coordineren tussen gebruikers, taken
en informatiebronnen ongeacht waar deze zich bevinden (Hill et al., 2009). Dit zorgt ervoor dat
samenwerking mogelijk is en helpt om de vervaging van de industriegrenzen te verwerken.
Ten vierde wordt ook groepssamenwerking binnen de onderneming tussen IT-mensen en bedrijfs-
mensen ondersteund (Hill et al., 2009). Een voorbeeld hiervan is de invoering van de BPMN, die
de communicatie tussen de technisch ingestelde IT-mensen, die beter met code kunnen omgaan,
en de niet-technisch ingestelde bedrijfmensen, die minder met code kunnen omgaan, bevordert.
Het is namelijk zo dat de procesmodellen die door de bedrijfsmensen worden opgesteld moeilijk
te coderen zijn door de IT-mensen aangezien deze de procesmodellen niet volledig begrijpen. Dit
zorgt voor een groot aantal foute vertalingen tijdens de codering. Door de nauwe relatie tussen
de BPMN, waarmee de processen gemodelleerd worden, en de BPEL, waarmee de processen ge-
codeerd worden, wordt de communicatie tussen IT-mensen en bedrijfsmensen verbeterd (Smith
& Fingar, 2007). Deze verbeterde communicatie verhoogt de reactiesnelheid van de onderneming
en laat toe om sneller op de veranderende omgeving in te spelen.
Tenslotte ondersteunt een BPMS processimulatie en optimalisatie (Hill et al., 2009) wat ervoor
kan zorgen dat fouten worden opgemerkt en een beter product wordt geleverd aan de klant.
4.5.2 Gebruikers
De systemen in de omgeving van het BPMS die ook een behoefte vervullen door te interageren
met het systeem, zijn de gebruikers van het BPMS (Wieringa, 1996-2006).
Bovenstaande bespreking van de functies toont aan dat de niet-menselijke systemen in de om-
geving van het BPMS, ook gebruikers zijn. Andere gebruikers van het BPMS zijn de mensen
die kunnen worden onderverdeeld in drie groepen, namelijk: bedrijfsgebruikers, IT-gebruikers
en de educatieve gebruikers.
Bij de bedrijfsgebruikers zijn de voornaamste: de managers, de analisten en de eindgebruikers.
Aangezien bedrijven vandaag onder grote druk staan door de toegenomen globalisatie en toe-
genomen druk van de consument, wordt het vandaag moeilijker om bedrijven te beheren. Als
bedrijf moet je jezelf gemakkelijk kunnen aanpassen om te overleven en BPMSs zijn hier een
hulpmiddel (Smith & Fingar, 2007). Aangezien managers verantwoordelijk zijn voor de over-
leving van het bedrijf, zijn zij zeker gebruikers van het BPMS. Bedrijfsanalisten gebruiken ook
het BPMS, namelijk om bedrijfsprocessen te modeleren. Hiervoor gebruiken ze rechtstreeks het
modelleringinstrument van een BPMS (Smith & Fingar, 2007) zoals Intalio|Designer. Bedrijfs-
Hoofdstuk 4. Business Process Management Systems 77
analisten analyseren ook bedrijfsprocessen en gebruiken hiervoor vaak het BAM instrument via
dashboards en e-mail (Stineman, 2007) en dus onrechtstreeks ook het BPMS aangezien het BAM
instrument zijn informatie voor een deel uit het BPMS haalt. Eindgebruikers zijn ook gebruikers
van het BPMS. Zij krijgen de opdrachten toegestuurd die nodig zijn om het proces dat wordt
uitgevoerd door de Intalio|Server te verwezenlijken. Deze opdrachten worden voornamelijk via
een computer aan de eindgebruiker geleverd. Bijvoorbeeld via intranet of mail.
Door de procesorientatie waar het belangrijk is te kijken naar processen (McCormack, 2001) en
de trend dat value chains alsmaar belangrijker worden, wordt het voor de IT-gebruikers alsmaar
moeilijker om processen te programmeren (Smith & Fingar, 2007). Vooral omdat value chains
de ondernemingsgrenzen overschrijden wordt het voor de IT-gebruikers moeilijk om deze evolutie
bij te houden. De nieuwe programmeertaal BPEL helpt de IT-gebruikers hiermee om te gaan,
aangezien die kan gebruikt worden wanneer complexe gevallen moeten worden geprogrammeerd
zoals een situatie waar verscheidene ondernemingen deelnemen aan een proces. Bovendien heeft
de BPEL een nauwe relatie met de BPMN (Smith & Fingar, 2007). Hierdoor is al een deel van
het werk verricht wanneer bedrijfsmensen het proces modelleren in bijvoorbeeld Intalio|Designer
in BPMN dat via de Intalio|Server in BPEL wordt omgezet.
De educatieve gebruikers zijn de mensen die lessen aanbieden in verband met een BPMS en ook
de mensen die deze lessen volgen. Deze lessen over een BPMS hebben verschillende onderwerpen.
Enkele hiervan zijn het bespreken van het BPMS van een bepaalde producent en dieper ingaan
op de BPMN.
De functie dat een BPMS de BPM theorie ondersteunt, is bijgevolg een functie die de behoefte
van gebruikers vervult.
Er is echter een element dat in de omgeving zit, maar niet als gebruiker kan worden gedefinieerd,
namelijk de ruimte. Deze ruimte vervult geen behoefte door te interageren met het systeem en
aangezien dit een vereiste is om als gebruiker te worden gedefinieerd (Wieringa, 1996-2006), is
de ruimte geen gebruiker.
4.5.3 Samenvatting
Als samenvatting kan de tabel 4.3 worden opgesteld die de elementen functies en gebruikers
voor het BPMS van Intalio weergeeft:
Hoofdstuk 4. Business Process Management Systems 78
Tabel 4.3: Functie BPMS
functie functies uitwisselen van gegevens
ondersteunen van de BPM theorie
bedrijfslogica loskoppelen van de infrastructuur
bedrijfsprocessen analyseren en modelleren
interacties coordineren
samenwerking tussen IT-mensen en bedrijfsmensen verbeteren
processimulatie en optimalisatie
gebruikers niet-menselijke systemen in de omgeving
bedrijfsgebruikers
IT-gebruikers
educatieve gebruikers
4.6 Gedrag
4.6.1 Toestand
Het BPMS van Intalio moet worden geınstalleerd. Bijgevolg is het BPMS ofwel geınstalleerd
ofwel niet geınstalleerd. Deze twee toestanden kunnen worden vergeleken met een aan- en
een uit-toestand. Wanneer het BPMS geınstalleerd is, kunnen er zich verschillende situaties
voordoen wat betreft de subelementen. De Intalio|Designer kan ofwel in de situatie zijn waar
een proces wordt gecreeerd ofwel in de positie waar er geen proces wordt gecreeerd. Voor de
Intalio|Server zijn er ook twee situaties mogelijk, namelijk een eerste situatie waarbij een proces
wordt uitgevoerd en een tweede waarbij er geen proces wordt uitgevoerd.
Onder de aan-toestand van het BPMS zijn er dus vier subtoestanden mogelijk. Een eerste is de
situatie waarbij er een proces wordt gecreeerd in de Intalio|Designer en geen proces wordt uit-
gevoerd in de Intalio|Server. Het is ook mogelijk dat er in de Intalio|Designer geen proces wordt
gecreeerd terwijl de Intalio|Server wel een proces verwerkt of uitvoert. Een derde situatie is deze
waarbij de Intalio|Designer een proces creeert en de Intalio|Server ook een proces verwerkt. Dit
proces dat wordt verwerkt, kan zowel een proces zijn dat door de Intalio|Designer werd gecreeerd
in een vorige stap of een proces dat werd gecreeerd door een ander modelleringinstrument. Een
laatste mogelijke toestand is deze waarbij beide instrumenten niet werken en er dus geen proces
wordt gecreeerd in de Intalio|Designer en geen proces wordt uitgevoerd in de Intalio|Server.
Hoofdstuk 4. Business Process Management Systems 79
4.6.2 Acties
Hier worden de acties besproken die zich afspelen in twee van de subelementen: Intalio|Designer
en Intalio|Server. De acties die zich afspelen in de computer en het bijhorende besturingssysteem
zijn niet relevant voor deze thesis.
De Intalio|Designer bestaat uit verscheidene tabbladen en verscheidene elementen zoals op fi-
guur 4.10 zichtbaar is. Bijgevolg zijn er vele acties mogelijk binnen deze Intalio|Designer. Er
kan bijvoorbeeld een nieuw proces worden aangemaakt waarna enkele acties kunnen worden uit-
gevoerd waarbij een element van het BPMN pallet aan de linkerzijde naar het middengedeelte
wordt versleept. Als actie kan er ook een link gecreeerd worden via een volgorde-pijl tussen twee
elementen van het proces, dat wordt afgebeeld in het middengedeelte.
Figuur 4.10: Intalio|Designer
Bij de Intalio|Server worden de meeste acties uitgevoerd via de Intalio|Workflow en de Inta-
lio|Console. Een voorbeeld van een actie is de startactie in de Intalio|Console. Hiermee wordt
het geselecteerde proces gestart en worden de nodige taken uitgestuurd. Bij het Intalio|Workflow
systeem kan als actie geklikt worden op het tabblad taken, wat een overzicht geeft van alle uit
te voeren taken (Intalio-website, 2010).
4.6.3 Samenvatting
De toestanden en acties van het BPMS van Intalio worden in tabel 4.4 weergegeven:
Hoofdstuk 4. Business Process Management Systems 80
Tabel 4.4: Gedrag BPMS
gedrag toestand geınstalleerd: Intalio|Designer creeert en Intalio|Server voert niets uit
geınstalleerd: Intalio|Designer creeert niet en Intalio|Server voert uit
geınstalleerd: Intalio|Designer creeert en Intalio|Server voert uit
geınstalleerd: Intalio|Designer creeert niet en Intalio|Server voert niets
uit
niet geınstalleerd
acties maak nieuw proces aan
versleep BPMN element
creeer volgorde-pijl
start proces
klik op tabblad taken
4.7 Conclusie
In dit hoofdstuk werd het BPMS van Intalio geanalyseerd aan de hand van de tabel opgesteld
vanuit de opvatting van Wieringa (1996-2006). De keuze voor het Intalio BPMS wordt verant-
woord door het feit dat dit een van de enige volledig uitgewerkte open source BPMSs is, en
deze vorm vandaag veel aandacht krijgt door de toegenomen economische onzekerheid. Voor-
eerst werd hier het structuuraspect op toegepast, gevolgd door het grensaspect. Tenslotte werd
gekeken naar de functie en het gedrag van het Intalio BPMS. De resultaten uit deze analyses
die in tabellen 4.1, 4.2, 4.3 en 4.4 werden weergegeven, kunnen in tabel 4.5 worden samengevat:
Tabel 4.5: Toepassing van de opvatting van Wieringa (1996-2006) op het BPMS van Intalio
structuur subelementen computer met besturingssysteem
Intalio|Designer
Intalio|Server
relatie tussen de Intalio|Designer en de Intalio|Server
interne interacties deploy
grens omgeving BPM-opslageenheid
BAM systeem
systeem met bedrijfsregels
printer
Deze tabel gaat verder op de volgende bladzijde
Hoofdstuk 4. Business Process Management Systems 81
andere bedrijfssystemen
BPMS
mensen
ruimte
voorbeeldprocessen
externe interacties exporteer proces
importeer proces
toevoegen KPI
aanroepen bedrijfsregels
uitwisselen procesonderdelen
interacties met mensen
interacties met ruimte
dynamisch ja
modulair in beperkte mate
functie functies uitwisselen van gegevens
ondersteunen van de BPM theorie
bedrijfslogica loskoppelen van de infrastructuur
bedrijfsprocessen analyseren en modelleren
interacties coordineren
samenwerking tussen IT-mensen en bedrijfsmensen verbete-
ren
processimulatie en optimalisatie
gebruikers niet-menselijke systemen in de omgeving
bedrijfsgebruikers
IT-gebruikers
educatieve gebruikers
gedrag toestand geınstalleerd: Intalio|Designer creeert en Intalio|Server voert
niets uit
geınstalleerd: Intalio|Designer creeert niet en Intalio|Server
voert uit
geınstalleerd: Intalio|Designer creeert en Intalio|Server voert
uit
Deze tabel gaat verder op de volgende bladzijde
Hoofdstuk 4. Business Process Management Systems 82
geınstalleerd: Intalio|Designer creeert niet en Intalio|Server
voert niets uit
niet geınstalleerd
acties maak nieuw proces aan
versleep BPMN element
creeer volgorde-pijl
start proces
klik op tabblad taken
Hoofdstuk 5
Vergelijking mainframe en BPMS
5.1 Inleiding
Na het bespreken van het begrip systeem in hoofdstuk 1 werd in hoofdstuk 2 iets meer in detail
getreden door een soort systeem te bespreken namelijk, een bedrijfsproces. Bovendien bestaat
dit bedrijfsproces uit informatiesystemen waar mainframes, besproken in hoofdstuk 3, en een
BPMS, besproken in hoofdstuk 4, twee voorbeelden van zijn.
In deze thesis wordt de implementatiehierarchie van Wieringa (1996-2006)(supra, p.8) toegepast
waarbij begonnen wordt met het begrip systeem. Daarna wordt er telkens een lager gelegen
niveau aangesproken, waarbij het hoger gelegen niveau bestaat uit de systemen uit het lager
gelegen niveau. Figuur 5.1 geeft dit weer voor de begrippen systeem, bedrijfsproces, mainframes
en BPMS, besproken in deze thesis:
83
Hoofdstuk 5. Vergelijking mainframe en BPMS 84
Figuur 5.1: De implementatiehierarchie doorheen de thesis
Als laatste stap van deze thesis worden in dit hoofdstuk de twee informatiesystemen, mainframes
en BPMS, met elkaar vergeleken aan de hand van de opgestelde tabel vanuit de opvatting van
Wieringa (1996-2006). Vooreerst wordt de structuur van een mainframe vergeleken met de struc-
tuur van een BPMS. Daarna wordt het grensaspect vergeleken, gevolgd door het functieaspect
en het gedragsaspect.
5.2 Werkwijze
Om de vergelijking tussen een mainframe en een BPMS beter te plaatsen, wordt gebruik gemaakt
van een voorbeeldproces. Tijdens de vergelijking van de elementen van de twee systemen wordt
eerst een theoretische vergelijking gemaakt waarna in een volgend deel verwezen wordt naar het
voorbeeldproces om de gelijkenis toe te passen in de praktijk. Het voorbeeldproces is het proces
waarbij een gehuurde auto wordt teruggebracht. Het verloop van dit voorbeeldproces wordt
in figuur 5.2 weergegeven samen met enkele andere elementen die worden gebruikt tijdens de
vergelijking in de praktijk. Het voorbeeldproces is ongeveer hetzelfde proces dat werd gebruikt
in hoofdstuk 2 en hoofdstuk 4.
Hoofdstuk 5. Vergelijking mainframe en BPMS 85
5.2.1 Voorbeeld en assumpties
Figuur 5.2: Een autoverhuurproces als voorbeeld om de vergelijking tussen een mainframe en een BPMS
te duiden
Het voorbeeld stelt in het midden het proces voor dat zich afspeelt wanneer iemand een gehuurde
auto terugbrengt naar het bedrijf dat onder andere auto’s verhuurt. Het is vanuit het standpunt
van dit proces dat het voorbeeld in figuur 5.2 wordt gebruikt voor het vervolg van dit hoofdstuk.
Wanneer bijgevolg gesproken wordt over het proces, het accounting departement, de lokale dienst
of de claimregeling dan heeft dit betrekking op het proces waarbij een gehuurde auto wordt
teruggebracht, tenzij anders vermeld.
Hoofdstuk 5. Vergelijking mainframe en BPMS 86
Het bedrijf in figuur 5.2 heeft zowel een mainframesysteem als een BPMS ter beschikking. Het
mainframe systeem staat samen met de meeste van zijn i/o apparaten in de kelder van het
bedrijfsgebouw. Het BPMS is geınstalleerd op een computer die door de modelleerder van pro-
cessen gebruikt wordt om processen te modelleren in de Intalio|Designer. Deze is beschikbaar
in een lokaal van het bedrijf. Alle andere werknemers die gebruik maken van het BPMS voor
het uitvoeren van taken, hebben een persoonlijke computer ter beschikking waarop ze hun taken
kunnen openen en uitvoeren. Om de overzichtelijkheid op figuur 5.2 te bewaren, worden het
mainframesysteem, het BPMS en de persoonlijke computers niet getekend. Voor het verdere
gebruik van het voorbeeld kunnen zes belangrijke spelers worden vermeld, namelijk: het ac-
counting departement, de lokale dienst, de claimregeling, de manager, andere processen in het
bedrijf en andere bedrijven.
Vooreerst het accounting departement dat werkt met een BPMS. Hun taak in dit proces is
gelimiteerd aangezien dit departement enkel verantwoordelijk is voor het maken van de rekening.
Gezien ze werken met een BPMS is het de Intalio|Server die de opdracht geeft om de rekening
te maken.
Ook de lokale dienst werkt met een BPMS. De rij van taken voor de mensen in dit departement
wordt gestart aan de balie waar een persoon de auto die wordt teruggebracht, ontvangt. Wanneer
deze persoon aan de computer meldt dat er een auto is teruggebracht, krijgt hij de opdracht van
de Intalio|Server om de autogegevens op te vragen via een database. Vervolgens wordt de auto
manueel geınspecteerd en krijgt de inspecteur de opdracht van de Intalio|Server om eventuele
claims te noteren. Indien er geen claims worden genoteerd, wordt de auto vrijgegeven voor verder
verhuur. Indien er wel claims worden genoteerd, worden deze via de Intalio|Server automatisch
ter beschikking gesteld aan een andere werknemer van de lokale dienst die de opdracht krijgt
om hiervan een rapport te genereren. De werknemer kan, om dit rapport te genereren, een
programma gebruiken dat ook op zijn persoonlijke computer is geınstalleerd. De Intalio|Server
wordt op de hoogte gebracht wanneer de taak is uitgevoerd. In de lokale dienst wordt ook,
indien nodig, de auto gerepareerd.
Een derde speler is de claimregeling die werkt met een mainframesysteem. Wanneer de claim-
regeling wordt gecontacteerd met de melding dat er claims zijn genoteerd, zal een werknemer
eerst de gegevens van de klant opvragen via de terminal die hij ter beschikking heeft. Deze
terminal kan contact leggen met het mainframe systeem dat toegang heeft tot de klantengege-
vens die reeds werden opgeslagen bij het verhuren van de auto. Verder worden alle gegevens
die nodig zijn om het verzekeringsdocument op te stellen, ingegeven via een inputapparaat. De
Hoofdstuk 5. Vergelijking mainframe en BPMS 87
persoon die verantwoordelijk is voor het ingeven van deze gegevens, informeert de persoon die
verantwoordelijk is voor het documenteren van het geval, dat de nodige gegevens beschikbaar
zijn. Deze laatste geeft het mainframesysteem de opdracht deze gegevens met behulp van een
programma te verwerken om het verzekeringsdocument te creeren. Dit programma wordt door
de CPU of het kanaal geladen.
Een vierde speler is de manager die zowel toegang heeft tot het BPMS als tot het mainframe-
systeem. Het BPMS brengt hem via bijvoorbeeld KPI’s op de hoogte van het verloop van de
processen. Hiermee kan hij zien of de processen volgens wens verlopen. Dit is nodig aangezien
de manager instaat voor de leiding van het bedrijf en hiervoor vaak snel informatie nodig heeft.
Ook vanuit het mainframesysteem kan de manager informatie halen die hij kan gebruiken als
ondersteunend materiaal bij bepaalde beslissingen.
Ten vijfde zijn er ook andere processen in het bedrijf. Elementen van zulke processen kunnen
gebruik maken van het BPMS of het mainframesysteem. Deze kunnen bovendien ook gelinkt
zijn met het proces waarbij gehuurde auto’s worden teruggebracht. Zo zal het bedrijfsproces
dat ervoor zorgt dat wagens worden verhuurd, in contact staan met het gegeven proces. De
auto’s die worden vrijgegeven op het einde van het proces waarbij een gehuurde auto wordt
teruggebracht, kunnen namelijk opnieuw worden verhuurd. Er zijn echter ook processen in het
bedrijf die niet hoeven in contact te staan met het gegeven proces. Dit kan bijvoorbeeld het
proces zijn waarbij motorfietsen worden verhuurd in plaats van auto’s. Dit proces heeft hetzelfde
verloop als het proces in figuur 5.2 maar dan voor motorfietsen.
Als laatste belangrijke speler zijn er de andere ondernemingen waarmee het bedrijf contact heeft.
Nemen we hier als voorbeeld de onderneming waar het bedrijf dat auto’s verhuurt, zijn auto’s
aankoopt. Deze onderneming bezit ook een mainframesysteem en een BPMS om zijn processen
te beheren.
5.3 Structuur
Zowel bij het mainframesysteem in hoofdstuk 3 als bij het BPMS in hoofdstuk 4 werd het
begrip structuur besproken aan de hand van enkele elementen, namelijk: subelementen, relatie en
interne interacties. Ook hier worden beide systemen vergeleken aan de hand van deze elementen.
Tabel 5.1 geeft alvast een overzicht van de vergelijking.
Hoofdstuk 5. Vergelijking mainframe en BPMS 88
Tabel 5.1: Vergelijking van het mainframe system/360 met het BPMS voor het structuuraspect
MAINFRAME BPMS
structuur subelementen systeemcontrolepaneel computer
besturingssysteem besturingssysteem
CPU /
kanalen /
/ Intalio|Server
/ Intalio|Designer
relatie / /
interne interacties / /
acties = interne interacties vertaal opdrachten deploy
5.3.1 Subelementen
Hier worden vooreerst de subelementen besproken die kunnen worden vergeleken. Ook de sub-
elementen waarvoor geen gelijkenis bestaat komen aan bod aangezien deze een belangrijke rol
spelen in het proces op figuur 5.2.
Systeemcontrolepaneel - de computer waarop het BPMS is geınstalleerd
Theorie
Het systeemcontrolepaneel bij een mainframe system/360 zorgt voor de toegang van de gebruiker
tot het systeem. Het bestaat uit knoppen en hendels die verbonden zijn met de CPU zodat, als
de gebruiker op een knop drukt, de gevraagde taak ook effectief wordt uitgevoerd (IBM-DPD,
1964; IBM, 1964). Ook bij een BPMS heeft de menselijke gebruiker toegang tot het BPMS
via de computer waarop dit laatste is geınstalleerd. De modelleerder kan dan bijvoorbeeld
op deze computer aan de slag in de Intalio|Designer. Deze computer bevat ook knoppen (het
toestenbord) om mee te werken in het systeem.
Hierbij moet worden opgemerkt dat het gebruik van de computer voor menselijke interactie met
het BPMS, vaker wordt gebruikt dan het systeemcontrolepaneel bij een mainframe system/360.
Voor het mainframe system/360 was het namelijk zo dat interacties van menselijke gebruikers
werden geminimaliseerd (Thomas, 1971). Dit in tegenstelling tot het BPMS waar menselijke
interactie nodig is om met de Intalio|Designer te werken, aangezien dit systeem niet op zichzelf
werkt. Ook de Intalio|Server heeft menselijke interactie nodig om te worden gestart en ook om
Hoofdstuk 5. Vergelijking mainframe en BPMS 89
opdrachten te vervolledigen tijdens het uitvoeren van het proces.
Voorbeeld
Stel dat er iets misloopt bij de verwerking van het verzekeringsdocument, dan kan een werknemer
deze verwerking stopzetten via het systeemcontrolepaneel. Zo kan er ook iets mislopen bij de
verwerking van het claimrapport. Hiervoor kan een werknemer via de computer waarop het
BPMS is geınstalleerd naar de Intalio|Console in het BPMS gaan om het proces stop te zetten.
Besturingssysteem - besturingssysteem
Theorie
Een mainframe system/360 en een computer waar het BPMS op draait, hebben beiden een
besturingssysteem (Thomas, 1971). De besturingssystemen die voor het BPMS worden gebruikt
zijn niet meer dezelfde als deze die voor het mainframe system/360 werden gebruikt. Toch
hebben beide hetzelfde nut, namelijk dat het mainframe of de computer blijft programma’s
uitvoeren zonder menselijke interactie (Thomas, 1971). Voor een mainframe zijn de programma’s
deze die de CPU en de kanalen uitvoeren voor het BPMS is dit het BPMS zelf.
Voorbeeld
Zo zorgt het besturingssysteem in het mainframe system/360 ervoor dat het programma dat
nodig is om het verzekeringsdocument te maken enkel moet worden gestart door een werknemer.
De werknemer hoeft het mainframe system/360 niet te sturen tijdens het uitvoeren van het
programma. Ook bij het BPMS zorgt het besturingssysteem ervoor dat het BPMS van de lokale
dienst blijft werken. Eenmaal het proces van de lokale dienst door een werknemer wordt gestart
in de Intalio|Console, worden de opdrachten rondgestuurd en is het niet nodig dat de werknemer
dit nog verder stuurt.
CPU - /
Theorie
De CPU in een mainframesysteem zorgt ervoor dat opdrachten worden uitgevoerd op gegevens.
Hierbij kunnen bepaalde gegevens worden opgeslagen in de hoofdopslageenheid (IBM-DPD,
1964).
Voorbeeld
Hoofdstuk 5. Vergelijking mainframe en BPMS 90
Voor het opstellen van het verzekeringsdocument kunnen bijvoorbeeld berekeningen nodig zijn.
Deze berekeningen worden uitgevoerd in de CPU of meer specifiek in de ALU van het mainfra-
mesysteem.
Kanalen - /
Theorie
De kanalen zijn een communicatielijn tussen de hoofdopslageenheid en de i/o apparaten waardoor
de CPU ontlast wordt van deze taak (IBM-DPD, 1964). De kanalen zorgen ervoor dat gegevens
vanuit de i/o apparaten in het systeem worden gebracht en omgekeerd (Germain, 1967).
Voorbeeld
Stel dat de claimregeling het verzekeringsdocument dat werd opgesteld, wil afdrukken. De
gegevens hiervan zitten nog in het systeem waar het document werd gecreeerd. Het kanaal zet
deze gegevens om zodat ze begrijpbaar zijn voor de printer en geeft vervolgens de opdracht
schrijf aan de printer, waardoor die vervolgens het document afdrukt.
/ - Intalio|Server
Theorie
De Intalio|Server voert het proces uit (Finkelstein, 2005), genereert gebeurtenissen om aan te
tonen waar het proces zich bevindt en stuurt opdrachten door naar de menselijke gebruiker
(Intalio-website, 2010).
Voorbeeld
Zo geeft de Intalio|Server aan een werknemer van de lokale dienst de opdracht om een claimrap-
port op te stellen in geval er claims zijn genoteerd.
/ - Intalio|Designer
Theorie
De Intalio|Designer is een procesmodelleringsprogramma waarin nieuwe processen kunnen wor-
den gemodelleerd maar ook eerder gecreeerde processen kunnen worden geladen en aangepast
(Finkelstein, 2005).
Hoofdstuk 5. Vergelijking mainframe en BPMS 91
Voorbeeld
Het proces in figuur 5.2 dat weergeeft wat er allemaal gebeurt wanneer een gehuurde auto wordt
teruggebracht, werd gemodelleerd met de Intalio|Designer door een werknemer van het bedrijf.
5.3.2 Relatie en interne interacties
Hier worden de volgende onderdelen besproken:
Relatie - relatie
Het is niet relevant de relaties van beide systemen te vergelijken aangezien relaties tussen speci-
fieke subelementen van systemen worden gedefinieerd (Wieringa, 1996-2006) en de subelementen
bij het mainframesysteem en het BPMS verschillend zijn. Bijgevolg wordt hier geen theoretische
vergelijking gemaakt waardoor ook het voorbeeld hierbij niet kan worden betrokken.
Interne interactie - interne interactie
Theorie
Voor het BPMS werd tussen de Intalio|Designer en de Intalio|Server maar een interactie weerge-
geven, namelijk deploy. Deze zet een BPMN model gemaakt in de Intalio|Designer om naar de
Intalio|Server. Binnen de opgesomde interacties van het mainframe system/360 is er geen enkele
die vergelijkbaar is met de interactie tussen de Intalio|Designer en de Intalio|Server waarbij code
wordt omgezet.
Voorbeeld
Aangezien er geen vergelijking mogelijk is, kan het voorbeeld van de auto hierop niet worden
toegepast.
Actie: vertaal opdrachten - interne interactie: deploy
Theorie
Niettegenstaande er geen interne interactie van het mainframe system/360 vergelijkbaar is met
de interne interactie deploy van het BPMS, is er wel een actie van een subelement van het
mainframe system/360 hiermee vergelijkbaar. Hierbij moet echter worden opgemerkt dat er
geen een-op-een vergelijking mogelijk is, maar dat de interactie wel gelijkaardig is aan de actie.
Hoofdstuk 5. Vergelijking mainframe en BPMS 92
Zoals reeds vermeld wordt tijdens de interactie deploy een BPMN model omgezet naar de
Intalio|Server. Hierbij wordt het model dat weergegeven is in de BPMN, omgezet naar BPEL
code die door de Intalio|Server kan worden geınterpreteerd. Een gelijkaardige vertaling gebeurt
binnenin het kanaal dat de opdrachten die het verkrijgt van de CPU, vertaalt en doorgeeft aan
de i/o apparaten (IBM, 1967). Hierbij wordt dus net zoals bij de interactie deploy bepaalde
code omgezet naar andere code.
Voorbeeld
Om de informatie die een werknemer van de claimregeling bezit in te geven wordt door de CPU
aan het kanaal een start i/o opdracht gegeven. Omdat het kanaal dat is wat communiceert met
de i/o apparaten, vertaalt het deze start i/o opdracht zodat het voor het benodigde i/o apparaat
duidelijk is wat het moet doen.
Zo kan ook het BPMN model in de Intalio|Designer, waarvan figuur 5.2 een voorbeeld is, niet
door de Intalio|Server worden begrepen. Hiervoor zal dit model tijdens de deploy interactie
worden omgezet naar BPEL, wat kan worden vergeleken met programmeercode. Hierdoor zal
de Intalio|Server het model begrijpen en de nodige opdrachten kunnen uitsturen om ervoor te
zorgen dat bijvoorbeeld het claimrapport kan worden opgesteld.
5.4 Grens
Na het vergelijken van de structuur van beide systemen, kan de vergelijking van het grensaspect
worden uitgediept. Vooreerst wordt de omgeving van beide systemen vergeleken waarna de
externe interacties worden besproken. Hierop volgt een vergelijking op basis van de elementen
dynamisch en modulair. Hieruit zal blijken of beide systemen even dynamisch en modulair zijn
of dat het ene systeem dynamischer of meer modulair is dan het andere. Een overzicht van de
vergelijking wordt in tabel 5.2 weergegeven.
Hoofdstuk 5. Vergelijking mainframe en BPMS 93
Tabel 5.2: Vergelijking van het mainframe system/360 met het BPMS voor het grensaspect
MAINFRAME BPMS
grens omgeving magnetische tape-eenheden procesbasis
en harde schijf en
drum opslageenheden
printer printer
terminal computer: dashboards en e-mail
gelijksoortige systemen gelijksoortige systemen
mensen mensen
ruimte ruimte
kaartlezer /
kaartprikker /
controle-eenheid /
/ systeem met bedrijfsregels
/ andere bedrijfssystemen
/ voorbeeldprocessen
externe interacties lees en schrijf exporteer en importeer proces
informatie uitwisselen informatie uitwisselen
interacties met mensen interacties met mensen
interacties met ruimte interacties met ruimte
dynamisch ja ja
modulair redelijk in beperkte mate
5.4.1 Omgeving
De elementen in de omgeving van beide systemen vertonen enkele gelijkenissen. Deze worden
hieronder besproken. Er zijn echter ook enkele elementen die niet kunnen worden vergeleken
met een element van het andere systeem. Deze worden vernoemd in tabel 5.2, maar worden hier
niet verder uitgewerkt aangezien de meeste van deze reeds besproken zijn in hun respectievelijk
hoofdstuk.
Magnetische tape-eenheden en harde schijf en drum opslageenheden - pro-
cesbasis
Theorie
Hoofdstuk 5. Vergelijking mainframe en BPMS 94
De magnetische tape-eenheden en harde schijf en drum opslageenheden van het mainframe sys-
tem/360 dienen als externe opslagcapaciteit en slaan bijgevolg gegevens op die vanuit het systeem
worden doorgegeven. De gegevens op deze systemen kunnen zowel output zijn van het systeem
of als input dienen in het systeem (IBM, 1964). Iets gelijkaardigs gebeurt in de procesbasis van
het BPMS. Deze slaat procesmodellen op die in het BPMS worden gecreeerd. Bovendien kunnen
deze procesmodellen ook weer als input worden gegeven in het systeem wanneer delen van het
opgeslagen proces worden hergebruikt (Stineman, 2007).
Hier moet worden opgemerkt dat de aard van hetgene dat als input of output dient, anders
is voor het mainframesysteem en het BPMS. De twee elementen die worden vergeleken zijn
bijgevolg niet helemaal gelijk maar eerder gelijkaardig.
Voorbeeld
Het verzekeringsdocument dat wordt gecreeerd door de claimregeling wordt misschien bij voor-
keur bijgehouden. Hiervoor wordt bijvoorbeeld de magnetische tape-eenheid gebruikt die het
document opslaat. Wanneer nodig kan het document ook weer worden opgevraagd. Voor de
procesbasis kan het procesmodel in het midden van figuur 5.2 hierin worden opgeslagen. Indien
nodig kan dit proces of delen ervan ook weer uit de procesbasis worden gehaald. Dit is bijvoor-
beeld het geval wanneer het bedrijf in het voorbeeld ook motorfietsen verhuurt en er bijgevolg
een proces ontstaat waarbij verhuurde motorfietsen worden teruggebracht. Het proces dat zich
afspeelt wanneer de motorfietsen worden teruggebracht zal net hetzelfde zijn als dat waarbij
verhuurde auto’s worden teruggebracht, maar dan voor motorfietsen. Bijgevolg moet dit proces
niet opnieuw worden gemodelleerd maar kan het procesmodel in figuur 5.2 uit de procesbasis
worden gehaald en naar wens worden aangepast.
Printer - printer
Theorie
In beide systemen kan in de omgeving een printer worden waargenomen (IBM, 1964). Een
printer is een outputsysteem dat dient om gegevens naar de buitenwereld te brengen via een
geprinte output die door de menselijke gebruiker kan worden geınterpreteerd. Bij het BPMS
kan er zowel een printer verbonden zijn met de computer waarop het BPMS is geınstalleerd als
met de computers waar de menselijke gebruikers hun opdrachten op ontvangen.
Voorbeeld
Hoofdstuk 5. Vergelijking mainframe en BPMS 95
Stel dat in het voorbeeld van figuur 5.2 het claimrapport en het verzekeringsdocument moeten
worden afgedrukt om deze te kunnen opsturen per brief. Voor het claimrapport zal de gebruiker
die dit opstelt ook de taak krijgen om het af te drukken, wat hij kan uitvoeren via de printer die
met zijn computer is verbonden. Voor het verzekeringsdocument zal iemand van de claimregeling
de opdracht geven aan het mainframe system/360 om dit document af te drukken via de printer
verbonden met het systeem.
Terminal - computer: dashboards en e-mail
Theorie
Een mainframe system/360 gebruikt naast de printers ook terminals om output via het scherm
aan de menselijke gebruiker weer te geven (IBM, 1964). Bij het BPMS gebruikt men hiervoor
de computer of meer bepaald de dashboards en e-mails. Deze dashboards geven bepaalde KPI’s
van het proces weer, terwijl een waarschuwing in verband met het verloop van het proces via
e-mail kan worden doorgegeven (Stineman, 2007).
Voorbeeld
De claimregeling vraagt bijvoorbeeld de klantengegevens op nadat ze gecontacteerd werden met
de melding dat er claims werden genoteerd. Om deze klantengegevens op te vragen, gebruiken
ze de terminal om contact te leggen met het mainframe system/360 dat toegang heeft tot de
gegevens. Nadat deze gegevens zijn aangevraagd, worden ze op het scherm van de terminal
weergegeven zodat de gebruiker deze kan lezen. Bij een BPMS kan er, wanneer er een fout op-
treedt in de verwerking van het claimrapport, een signaal worden gestuurd naar een werknemer.
Dit signaal komt toe via mail op de computer van de werknemer.
Gelijksoortige systemen - gelijksoortige systemen
Theorie
Bij het mainframe system/360 werd in hoofdstuk 3 opgemerkt dat ook andere mainframe sys-
tems/360 in de omgeving kunnen worden waargenomen. Deze kunnen op drie verschillende
manieren met elkaar worden verbonden, namelijk: via het delen van een i/o apparaat, het be-
staan van een connectie tussen de kanalen, of via het delen van de opslageenheid (IBM-DPD,
1964). Uit deze verbindingsmogelijkheden kan worden geconcludeerd dat de mainframesystemen
niet ver uit elkaar kunnen staan en bijgevolg slechts tot een onderneming kunnen behoren. Ook
Hoofdstuk 5. Vergelijking mainframe en BPMS 96
bij het BPMS zitten andere BPMSs in de omgeving, omdat organisaties vandaag de dag hun
relaties met hun bedrijfspartners beter moeten beheren en dit kan bijvoorbeeld via het BPMS
(Smith & Fingar, 2007). Hier is het wel mogelijk dat de BPMSs tot verschillende ondernemingen
behoren.
Voorbeeld
Zoals vermeld bij de bespreking van het voorbeeld (supra, p.85) zit er een andere onderneming in
de omgeving van het bedrijf. Deze onderneming heeft ook een mainframesysteem en een BPMS.
De mainframesystemen van deze beide ondernemingen kunnen niet worden verbonden gezien
deze te ver uit elkaar staan. Indien het bedrijf zelf een tweede mainframe ter beschikking zou
hebben voor bijvoorbeeld de claimregeling van het proces waar motorfietsen worden verhuurd,
dan kunnen deze twee wel contact leggen. Hier kan dan bijvoorbeeld de printer als i/o apparaat
waarmee voor beide processen documenten worden afgedrukt, worden gedeeld.
Het BPMS van het bedrijf kan echter wel worden verbonden met het BPMS van de andere
onderneming. Zo kan het verkoopproces van auto’s in het BPMS van de andere onderneming
verbonden worden met het aankoopproces van auto’s in het BPMS van het bedrijf dat auto’s
verhuurt. Dit zorgt ervoor dat beide processen op elkaar worden afgestemd, wat zorgt voor een
betere relatie tussen beide ondernemingen.
Mensen - mensen
Theorie
Zowel in hoodstuk 3 als hoofdstuk 4 werd vermeld dat respectievelijk het mainframe system/360
als het BPMS van Intalio mensen in de omgeving hebben die het systeem gebruiken.
Voorbeeld
In de claimregeling die werkt met het mainframesysteem, zitten werknemers die bijvoorbeeld de
klantengegevens opvragen en bijgevolg kunnen gezien worden als mensen in de omgeving van
het systeem. Dit is hetzelfde voor het BPMS in de lokale dienst waar werknemers bijvoorbeeld
autogegevens opvragen en bij deze eveneens in de omgeving van het systeem zitten.
Ruimte - ruimte
Theorie
Hoofdstuk 5. Vergelijking mainframe en BPMS 97
Zowel voor het mainframe system/360 als voor het BPMS van Intalio werd respectievelijk in
hoodstuk 3 en hoofdstuk 4 vermeld dat de ruimte waarin het systeem zich bevindt, deel is van
de omgeving gezien deze ook interageert met het systeem via het uitwisselen van geluid.
Voorbeeld
Het mainframe system/360 staat, zoals verondersteld in punt 5.2.1 in de kelder samen met de
i/o apparaten. Bijgevolg is de kelder hier de ruimte waar het systeem zich bevindt. Zo is ook
het lokaal waar de computer staat waarop het BPMS is geınstalleerd de ruimte voor het BPMS.
5.4.2 Externe interacties
Voor de systemen in de omgeving die niet kunnen worden vergeleken, kan er ook geen vergelijking
gemaakt worden wat betreft hun interacties met het systeem. Bijgevolg worden deze hier niet
besproken aangezien deze reeds werden besproken in hun respectievelijke hoofdstukken. Voor
de andere externe interacties kunnen de volgende gelijkenissen worden vermeld:
Lees en schrijf - exporteer en importeer proces
Theorie
Bij een mainframe system/360 zijn er onder andere de externe interacties lees en schrijf tussen
de kanalen en de externe opslageenheden. Deze zorgen er respectievelijk voor dat er gegevens
worden gelezen of geschreven. Het lezen zorgt ervoor dat gegevens worden geımporteerd in het
systeem, terwijl het schrijven ervoor zorgt dat gegevens vanuit het systeem worden geexporteerd
(IBM-DPD, 1964). Bij het BPMS is een gelijkaardige externe interactie waarneembaar tussen
het systeem en de BPM opslageenheid. Een proces wordt namelijk geımporteerd vanuit de pro-
cesbasis naar de Intalio|Designer of geexporteerd vanuit de Intalio|Designer naar de procesbasis.
Bij het importeren wordt het proces of delen ervan hergebruikt terwijl bij het exporteren het
proces wordt opgeslagen in de procesbasis (Stineman, 2007). De andere interacties die tussen de
kanalen en de i/o apparaten plaatsvinden, kunnen niet worden vergeleken met interacties tussen
het BPMS en zijn omgeving.
Hier moet worden opgemerkt dat de aard van war wordt geımporteerd of geexporteerd, anders is
voor de het mainframesysteem en het BPMS. De twee externe interacties die worden vergeleken
zijn bijgevolg niet helemaal gelijk maar eerder gelijkaardig.
Voorbeeld
Hoofdstuk 5. Vergelijking mainframe en BPMS 98
Stellen we voor het mainframe system/360 dat het verzekeringsdocument dat wordt gecreeerd
in de claimregeling moet worden opgeslagen op een magnetische tape-eenheid zodat dit later
opnieuw kan worden geopend. Hiervoor is de externe interactie schrijf nodig om de gegevens
op de magenetische tape-eenheid te kunnen zetten.
Voor het BPMS wordt het BPMN model in het midden van figuur 5.2 gemaakt in de Intalio|De-
signer. Hierna wordt het geexporteerd naar de procesbasis. Hierdoor kan dit model opnieuw
worden gebruikt voor andere processen die delen van dit proces kunnen hergebruiken zoals het
proces waarbij gehuurde motorfietsen worden teruggebracht.
Informatie uitwisselen - informatie uitwisselen
Theorie
Informatie uitwisselen is een externe interactie die zich afspeelt tussen het systeem en een systeem
van dezelfde aard. Het is namelijk zo dat het mainframe system/360 informatie kan uitwisselen
met een ander mainframe system/360 wanneer deze verbonden zijn via hun opslageenheden
(IBM-DPD, 1964). Ook de BPMSs die verbonden zijn met elkaar, wisselen informatie uit omdat
dit de relatie tussen de verschillende bedrijven kan verbeteren (Smith & Fingar, 2007). Hierbij
kan bijvoorbeeld informatie uitgewisseld worden over bepaalde procesonderdelen zodat deze
beter op elkaar kunnen worden afgestemd.
Voorbeeld
Zowel bij de claimregeling waarbij de verhuurde auto’s worden teruggebracht als bij de claim-
regeling waarbij de verhuurde motorfietsen worden teruggebracht, worden klantengegevens op-
gevraagd. Het is mogelijk dat een klant ooit zowel een auto als een motorfiets heeft gehuurd,
waardoor deze klantengegevens in beide mainframesystemen aanwezig zijn. Indien de klant de
laatste keer een motorfiets heeft gehuurd en de klantengegevens die toen waren ingegeven recenter
zijn, kan iemand ervoor zorgen dat deze recentere informatie via de verbonden opslageenheden
wordt doorgegeven. Hierdoor worden de meest recente gegevens weergegeven wanneer er een
volgende keer klantengegevens worden opgevraagd bij het proces waar gehuurde auto’s worden
teruggebracht.
Het BPMS van de lokale dienst waarbij auto’s worden teruggebracht, kan ook informatie uitwis-
selen met het BPMS van de onderneming waarvan auto’s worden aangekocht. Zo kan de link
tussen beide BPMSs ervoor zorgen dat de autogegevens aanwezig in het bedrijf overeenstemmen
Hoofdstuk 5. Vergelijking mainframe en BPMS 99
met de autogegevens vanuit de onderneming waarvan de auto’s worden aangekocht. Hierdoor
zijn de autogegevens die worden opgevraagd door de lokale dienst altijd correct.
Interacties met mensen - interacties met mensen
Theorie
Beide systemen hebben mensen in de omgeving waarmee ze interageren. Bij het mainframe
system/360 wordt enkel via het systeemcontrolepaneel rechtstreeks geınterageerd met de mensen.
Zij kunnen hiermee bijvoorbeeld de CPU resetten (IBM-DPD, 1964). De meeste interacties
verlopen echter onrechtstreeks via de andere elementen in de omgeving. Bij het BPMS zijn er
wel veel rechtstreekse interacties tussen het BPMS en de mensen, aangezien de mensen in contact
komen met de Intalio|Workflow tijdens het uitvoeren van opdrachten. Ook de modelleerder van
procesmodellen komt rechtstreeks in contact met het systeem via de Intalio|Designer. Maar er
zijn ook veel interacties mogelijk tussen het systeem en de mensen die niet rechtstreeks verlopen
maar via de andere systemen in de omgeving.
Voorbeeld
Vooreerst voor elk systeem een voorbeeld van de rechtstreekse externe interacties. Stel dat er
iets misloopt bij de verwerking van het verzekeringsdocument, dan kan de gebruiker via een knop
op het systeemcontrolepaneel eerst de verwerking stopzetten en vervolgens de CPU resetten. Zo
kan er ook iets mislopen bij de verwerking van het claimrapport. Een persoon krijgt hiervan
een melding en zal via de computer waar het BPMS op geınstalleerd is, naar de Intalio|Console
gaan om het proces stop te zetten.
Ten tweede voor elk systeem een voorbeeld van een onrechtstreekse externe interactie. De
gebruiker van de claimregeling gebruikt een terminal om de klantengegevens op te vragen. Via
deze terminal die verbonden is met het mainframesysteem komt hij onrechtstreeks in contact
met het mainframe om de nodige klantengegevens te verkrijgen. Voor het BPMS is de melding
die de persoon krijgt wanneer de verwerking van het claimrapport misloopt, een onrechtstreekse
externe interactie met het BPMS. Deze melding wordt bijvoorbeeld via e-mail doorgestuurd
vanuit het BPMS waarbij de gebruiker van de lokale dienst deze ontvangt op zijn computer.
Interacties met ruimte - interacties met ruimte
Theorie
Hoofdstuk 5. Vergelijking mainframe en BPMS 100
Beide systemen hebben de ruimte waarin het systeem zich bevindt, als deel van de omgeving.
Volgens Wieringa (1996-2006) moeten beide systemen bijgevolg interageren met deze ruimte.
Voorbeeld
Het mainframe system/360 maakt geluid als het in werking is. Bijgevolg is er een externe inter-
actie tussen het systeem en de kelder waarin het systeem staat, waarbij geluid wordt afgeleverd
aan de kelder. Dit is hetzelfde voor het BPMS van het bedrijf, waarbij het geluid echter wordt
afgeleverd in het lokaal waar de computer staat, waar het BPMS op is geınstalleerd.
5.4.3 Dynamisch
Theorie
Wieringa (1996-2006) stelt dat een systeem dynamisch is als het interageert met zijn omgeving,
aangezien deze interacties plaatsvinden in de tijd. Zowel een mainframe als een BPMS heeft
externe interacties met de systemen in hun omgeving, die bovendien niet allemaal op hetzelf-
de ogenblik plaatsvinden. Dit resulteert in de bevinding dat beide systemen als dynamische,
observeerbare systemen kunnen worden gezien.
Voorbeeld
Het mainframe system/360 van het bedrijf zal voor het afdrukken van het verzekeringsdocument
interageren met de printer in zijn omgeving. Bovendien heeft dit afprinten tijd nodig en staat
het systeem dus voor geruime tijd in contact met de printer. Het mainframe system/360 dat
aanwezig is in het bedrijf, is bijgevolg een dynamisch systeem. Ook het BPMS dat aanwezig is
in het bedrijf, is een dynamisch systeem. Wanneer het de opdracht verstuurt naar de werknemer
om een claimrapport op te stellen, interageert het via de Intalio|Workflow met de werknemer
die ook een systeem is en deze interactie neemt bovendien enige tijd in beslag aangezien de
werknemer de opdracht moet lezen.
5.4.4 Modulair
Theorie
Modulariteit bij een systeem betekent dat het systeem als een onafhankelijke eenheid kan worden
gezien (Wieringa, 1996-2006). Voor beide systemen werd de modulariteit onderzocht via enkele
richtlijnen die Wieringa (1996-2006) heeft opgesteld, namelijk:
Hoofdstuk 5. Vergelijking mainframe en BPMS 101
• Interactie tussen de systeemcomponenten (cohesie) is groter dan de interactie tussen het
systeem en de omgeving (koppeling).
• Veranderingen binnen een systeem zouden minimale veranderingen moeten veroorzaken
buiten het systeem.
• Er zijn meer relaties onder de systeemcomponenten onderling dan tussen de systeemcom-
ponenten en de omgeving.
• Er is meer energie nodig om iets over de systeemgrens te transporteren dan om iets binnenin
de systeemgrens te transporteren.
• De systeemgrens zou zo moeten worden gekozen dat het systeemgedrag eenvoudiger is dan
bij enige andere keuze van systeemgrens.
Voor het BPMS van Intalio was slechts een van de vijf elementen toepasbaar, terwijl dat voor
het mainframe system/360 twee elementen waren. Bovendien konden voor het mainframe sys-
tem/360 twee andere elementen niet helemaal worden weerlegd. Hieruit kan worden geconclu-
deerd dat het mainframe system/360 meer modulair is dan het BPMS van Intalio.
Dit kan verder worden geduid aan de hand van twee elementen. Vooreerst is het mainframe
system/360 een zichtbare eenheid die fysiek als een onafhankelijk deel kan worden gezien. In
tegenstelling hiermee kan een BPMS niet vastgenomen worden of fysiek waargenomen worden.
Hier bovenop heeft dit altijd een computer nodig om te opereren. Deze elementen maken het
moeilijk een BPMS als een onafhankelijke eenheid te zien.
Als tweede element kan, voortbouwend op het vorige element, gesteld worden dat het BPMS
meer gedistribueerd is terwijl het mainframesysteem eerder gecentraliseerd is. Met dit laatste
wordt bedoeld dat het mainframe system/360 en zijn i/o apparaten vaak samen te vinden zijn en
het mainframe system/360 opereert vanuit een plaats, namelijk de ruimte waarin dit aanwezig
is. Enkel terminals staan op een verdere afstand van het mainframesysteem. Dat het BPMS
gedistribueerd is, wil zeggen dat het systeem in principe taken kan rondsturen over verscheidene
computersystemen heen en dat deze computersystemen met elkaar in verbinding staan. Dit
zorgt er bijvoorbeeld voor dat, wanneer iemand een taak uitvoert, de gevormde informatie via
het gecreeerde netwerk rechtstreeks kan worden doorgegeven aan een volgende persoon in het
proces. Bovendien is het BPMS ook voor een deel aanwezig op de computers van de mensen die
de taken uitvoeren, aangezien deze via een gebruikersnaam en paswoord toegang hebben tot de
Intalio|Workflow (Intalio-website, 2010).
Hoofdstuk 5. Vergelijking mainframe en BPMS 102
Voorbeeld
Hier wordt voor elk element van verder duidt waarom een BPMS minder modulair is dan het
mainframe system/360 een voorbeeld gegeven.
Vooreerst kan het mainframe system/360 door de werknemers fysiek worden waargenomen in de
kelder bijvoorbeeld wanneer ze naar de kelder gaan om via de printer het verzekeringsdocument
af te drukken. In tegenstelling hiermee kan het BPMS niet worden vastgenomen door de werk-
nemers van de lokale dienst. Het is geen losstaand element, maar wordt door de werknemers
waargenomen wanneer ze bijvoorbeeld de taak ontvangen om de claims te noteren. Bovendien
heeft de werknemer zijn computer nodig om deze taak te ontvangen.
In verband met het tweede element opereert het mainframe system/360 vanuit een centraal punt:
de kelder. Enkel de terminals die ter beschikking staan van de werknemers van de claimregeling,
zijn niet in de kelder aanwezig. In tegenstelling hiermee is het BPMS bijna overal aanwezig
in de lokale dienst. Het stuurt taken door zodat de autogegevens worden opgezocht, claims
worden genoteerd en een claimrapport wordt gemaakt. Zo staat ook bijvoorbeeld de computer
van diegene die de claims noteert via het BPMS, in contact met de computer van diegene die
het claimrapport moet opstellen. Wanneer de claims zijn genoteerd, worden deze gegevens
automatisch doorgestuurd naar diegene die ze nodig heeft om het claimrapport op te stellen.
5.5 Functie
In dit derde deel worden de systemen met elkaar vergeleken op basis van het functieaspect. Een
overzicht van de vergelijking is zichbaar in tabel 5.3.
Tabel 5.3: Vergelijking van het mainframe system/360 met het BPMS voor het functieaspect
MAINFRAME BPMS
functie functie uitwisselen van gegevens uitwisselen van gegevens
grote afstand grote afstand
verminderen van fouten verminderen van fouten
gebruikers niet-menselijke systemen niet-menselijke systemen
bedrijfsgebruikers bedrijfsgebruikers
IT-gebruikers IT-gebruikers
lesgevers en studenten educatieve gebruikers
Hoofdstuk 5. Vergelijking mainframe en BPMS 103
5.5.1 Functies
Volgens Wieringa (1996-2006) is een functie “een dienst die het systeem aanbiedt aan zijn om-
geving” (Wieringa, 1996-2006, p.22). Het biedt een oplossing voor de behoefte die een gebruiker
heeft. Aangezien elk systeem andere elementen in zijn omgeving heeft, zullen bepaalde func-
ties niet kunnen worden vergeleken. Bijgevolg worden deze hier niet vermeld, aangezien deze
reeds werden besproken in hun respectievelijke hoofdstukken. De volgende functies kunnen wel
worden vergeleken:
Uitwisselen van gegevens - uitwisselen van gegevens
Theorie
Uit hoofdstuk 3 en hoofdstuk 4 blijkt dat een mainframe system/360 en het BPMS van Intalio
beide externe interacties hebben met hun omgeving. Deze interacties bestaan voornamelijk uit
het uitwisselen van gegevens. Een eerste functie die beide systemen bijgevolg gemeenschappelijk
hebben, is dat ze beide dienen als systeem voor uitwisseling van gegevens.
Voorbeeld
In het voorbeeld worden de verzekeringsgegevens verwerkt in het mainframesysteem en in een
volgende stap uitgewisseld met de omgeving of meer bepaald met de printer die de gegevens
afdrukt. Ook indien de modelleerder het procesmodel van het proces van de lokale dienst afdrukt
vanuit de Intalio|Designer, worden de gegevens van het model uitgewisseld met de printer in de
omgeving.
Grote afstand - grote afstand
Theorie
Het BPMS kan de interacties coordineren onder gebruikers, taken en informatiebronnen, on-
geacht waar deze zich bevinden (Hill et al., 2009). Bijgevolg heeft het BPMS als functie dat
het andere systemen kan contacteren vanop grote afstand. Ook een mainframe system/360 kan
systemen contacteren vanop grote afstand. Dit is mogelijk via terminals en bijgevolg ook via
gebruikers van deze terminals (IBM, 1964).
Voorbeeld
Aangezien het mainframesysteem in de kelder staat, is het voor de werknemers van de claim-
regeling niet handig als ze, telkens ze klantengegevens nodig hebben, hiervoor naar de kelder
Hoofdstuk 5. Vergelijking mainframe en BPMS 104
moeten. Bijgevolg hebben deze een terminal ter beschikking die vanuit hun bureau in contact
staat met het mainframe system/360 in de kelder. Zo is het ook mogelijk dat het lokaal waar
BPMS zich bevindt, niet dichtbij de werkplaats van de lokale dienst is gesitueerd. Desondanks
ontvangen de werknemers van de lokale dienst de taken die ze moeten uitvoeren.
Verminderen van fouten - verminderen van fouten
Theorie
Het mainframe system/360 zorgde ervoor dat er minder menselijke interventies nodig waren, wat
als gevolg had dat er minder menselijke fouten werden gemaakt (Thomas, 1971; IBM, 1964).
Ook het BPMS helpt het aantal fouten te verminderen. Dit gebeurt echter meer specifiek,
namelijk door het verminderen van fouten bij het omzetten van een procesmodel naar uitvoerbare
code. De slechte communicatie tussen bedrijfsmensen en IT-mensen was er oorzaak van dat er
bij het omzetten veel fouten gebeurden. Bij een BPMS wordt het aantal fouten verminderd
aangezien het BPMN en BPEL introduceert en deze een nauwe relatie vertonen met elkaar. De
bedrijfsmensen werken namelijk met BPMN in Intalio|Designer om een model te creeren terwijl
IT-mensen werken met BPEL om een proces te coderen. Door de nauwe relatie tussen BPMN
en BPEL begrijpen de bedrijfsmensen beter wat de IT-mensen coderen en omgekeerd (Smith &
Fingar, 2007). Deze betere communicatie resulteert in een vermindering van het aantal fouten.
Voorbeeld
Wanneer het verzekeringsdocument wordt gecreeerd, hoeven de werknemers van de claimregeling
geen orders meer te geven aangezien de CPU samen met het besturingssysteem zorgt voor het
verdere verloop van het programma. Zo kan de gebruiker alvast geen foute orders meer geven.
Voor het BPMS kan de IT-gebruiker, via het model van het proces van de lokale dienst, weten
wat de modelleerder wil dat de IT-gebruiker codeert. De IT-gebruiker weet bijvoorbeeld dat het
plusteken in de ruit betekent dat beide stromen moeten worden uitgevoerd. Bijgevolg zal hij
dit invoeren in zijn code, zodat bij de uitvoering hiervan de Intalio|Server zowel een opdracht
om een rekening te maken stuurt naar het accounting departement als checkt of er claims zijn
gemeld.
5.5.2 Gebruikers
Beide systemen hebben andere systemen in de omgeving die een behoefte vervullen door te
interageren met het systeem. De gelijkenissen onder deze gebruikers van beide systemen zijn de
Hoofdstuk 5. Vergelijking mainframe en BPMS 105
volgende:
Niet-menselijke systemen - niet-menselijke systemen
Theorie
Beide systemen hebben niet-menselijke systemen in hun omgeving. Deze bestaan uit de niet-
menselijke elementen van de omgeving, uitgezonderd het systeem de ruimte.
Voorbeeld
Het mainframesysteem heeft bijvoorbeeld de printer als niet-menselijk systeem in zijn omgeving.
Hiermee wordt het verzekeringsdocument afgedrukt. Het BPMS van het bedrijf heeft bijvoor-
beeld een procesbasis in de omgeving. Daarin wordt het BPMN model van het proces van de
lokale dienst opgeslagen zodat het later eventueel kan worden hergebruikt voor het modelleren
van een gelijkaardig proces.
Bedrijfsgebruikers - bedrijfsgebruikers
Theorie
Bij het mainframe system/360 kunnen de bedrijfsgebruikers worden onderverdeeld in twee groe-
pen, namelijk: het managementteam en de personen die zo een systeem nodig hebben voor hun
werk, zoals wetenschappers. Bij BPMS worden bedrijfsgebruikers ingedeeld in drie groepen,
namelijk: managers, analisten en eindgebruikers. Enkel de managers van beide systemen kun-
nen worden vergeleken. Beide systemen bezorgen de manager informatie die ervoor zorgt dat
de manager het bedrijf op een degelijke manier kan leiden. De andere groepen hebben elk een
andere functie in een bedrijf en kunnen bijgevolg niet worden vergeleken.
Voorbeeld
Indien de manager wenst te beslissen met welke verzekeringsmaatschappijen hij verder wil sa-
menwerken kan hij hiervoor bepaalde verzekeringsdocumenten halen uit het mainframesysteem.
Deze verzekeringsdocumenten zijn opgesteld door de claimregeling. Hieruit kan de manager
de kosten van bepaalde verzekeringen analyseren om daarna zijn beslissing op deze analyse te
baseren.
Een manager kan ook via het BPMS zien in welke stap het proces van de lokale dienst zich
bevindt. Ook wordt de manager via e-mail op de hoogte gebracht wanneer er een fout optreedt
Hoofdstuk 5. Vergelijking mainframe en BPMS 106
bij het noteren van de claims. Na het ontvangen van deze e-mail kan hij een gepaste oplossing
zoeken.
IT-gebruikers - IT-gebruikers
Theorie
Beide systemen hebben IT-gebruikers in de omgeving. De functie van deze gebruikers is echter
bij beide systemen verschillend. Bij een mainframe system/360 is de functie van IT-gebruikers
voornamelijk geconcentreerd op het ontwikkelen van software en het onderhoud van het mainfra-
mesysteem (Churbuck & Samuels, 1996). In tegenstelling hiermee is de voornaamste functie van
de IT-gebruikers in het BPMS de processen weergegeven in BPMN om te zetten naar uitvoerbare
code.
Voorbeeld
Wanneer een kanaal van het mainframesysteem in het bedrijf verouderd is en niet meer werkt,
kan een werknemer van het IT-team ervoor zorgen dat dit wordt opgelost. Het IT-team dat
verantwoordelijk is voor het BPMS, zal voornamelijk procesmodellen zoals dat van de lokale
dienst omzetten in BPEL zodat de Intalio|Server het procesmodel begrijpt en de nodige taken
kan rondsturen.
Lesgevers en studenten - educatieve gebruikers
Theorie
Een laatste groep die kan worden vergeleken is de groep lesgevers en studenten bij het mainframe
system/360 en de educatieve gebruikers bij het BPMS. Aangezien het mainframe system/360
een nieuw apparaat was, was het nodig mensen op te leiden om hiermee te kunnen werken.
Eenmaal opgeleid konden ze met alle modellen van dit systeem werken, wat een voordeel was.
Voor een BPMS worden mensen vooral opgeleid om de BPMN te leren. Hierbij wordt vaak ook
de theorie van BPM betrokken, waarvan de principes worden uitgelegd. Bijgevolg kan ook hier
worden geconcludeerd dat de groepen wel gelijkaardige personen kunnen bevatten, maar hun
gebruik van het systeem verschillend is.
Voorbeeld
De werknemers van de lokale dienst moeten kunnen werken met het mainframesysteem en zijn
i/o apparaten om hun taken uit te voeren. Zo moeten ze bijvoorbeeld het verzekeringsdocument
Hoofdstuk 5. Vergelijking mainframe en BPMS 107
kunnen overzetten op een magnetische tape-eenheid. Het bedrijf heeft bijgevolg voor de claimre-
geling enkel werknemers aangeworven die al een opleiding hebben gekregen over het mainframe
system/360. Anders konden deze personen hun taken niet behoorlijk uitvoeren.
Aangezien de modelleerder van het bedrijf moet werken met de BPMN om processen te model-
leren in de Intalio|Designer, heeft het bedrijf een werknemer aangeworven die deze kennis reeds
bezat.
5.6 Gedrag
Tenslotte wordt het mainframe system/360 vergeleken met het BPMS van Intalio op basis van
het gedragsaspect. De gelijkenissen worden in tabel 5.4 voorgesteld.
Tabel 5.4: Vergelijking van het mainframe system/360 met het BPMS voor het gedragsaspect
MAINFRAME BPMS
gedrag toestand *aan: CPU verwerkt gegevens, *geınstalleerd: Intalio|Designer creeert
kanalen verwerken niets en Intalio|Server voert niets uit
*aan: CPU verwerkt niets, *geınstalleerd: Intalio|Designer creeert
kanalen verwerken gegevens niet en Intalio|Server voert uit
*aan: CPU en kanalen *geınstalleerd: Intalio|Designer creeert
verwerken gegevens en Intalio|Server voert uit
*aan: CPU en kanalen *geınstalleerd: Intalio|Designer creeert
verwerken niets niet en Intalio|Server voert niets uit
*uit *niet geınstalleerd
acties uitvoeren van een programma uitvoeren van processen
5.6.1 Toestand
Indien voor een langere periode naar een systeem wordt gekeken, kunnen de toestanden voor
het systeem worden geobserveerd (Wieringa, 1996-2006). Voor een mainframe system/360 zijn
de twee toestanden aan en uit. Ook een BPMS heeft een aan- en een uit-toestand die respec-
tievelijk de betekenis geınstalleerd en niet geınstalleerd hebben. Bovendien hebben zowel een
mainframe system/360 als een BPMS vier scenario’s onder deze aan-toestand. Voor een main-
frame system/360 worden deze scenario’s opgebouwd uit een combinatie van de toestanden van
de CPU en de kanalen. Bij een BPMS worden de scenario’s opgebouwd uit een combinatie van
Hoofdstuk 5. Vergelijking mainframe en BPMS 108
de toestanden van de Intalio|Designer en de Intalio|Server.
Er moet echter worden opgemerkt dat de Intalio|Designer, de Intalio|Server, de CPU en de
kanalen niet met elkaar kunnen worden vergeleken, zoals uit punt 5.3.1 bleek. Bijgevolg zijn de
scenario’s bij beide systemen niet gelijk maar wel gelijkaardig. De volgende scenario’s worden
besproken:
Aan: CPU verwerkt gegevens, kanalen verwerken niets - geınstalleerd: In-
talio|Designer creeert en Intalio|Server voert niets uit
Theorie
De gelijkenis die aanwezig is tussen de twee systemen is dat een van hun subelementen werkzaam
is en het andere niet.
Voorbeeld
Stel dat we in het voorbeeld enkel kijken naar de taak waarbij het verzekeringsdocument wordt
gecreeerd. Terwijl de CPU berekeningen maakt om het verzekeringsdocument op te stellen, is
het mogelijk dat de kanalen niets verwerken omdat de gegevens die nodig zijn reeds aanwezig
zijn in de hoofdopslageenheid.
Voor het BPMS is het mogelijk dat bijvoorbeeld de werknemers van de lokale dienst vrijaf hebben
en er geen opdrachten worden rondgestuurd door de Intalio|Server binnen deze lokale dienst.
Hierbij kan de werknemer die verantwoordelijk is voor het modelleren van processen ondertussen
het proces dat zich afspeelt in de lokale dienst, hermodelleren in de Intalio|Designer. Hierbij kan
hij bijvoorbeeld een extra taak invoegen waarbij de auto wordt gewassen nadat deze is hersteld.
Aan: CPU verwerkt niets, kanalen verwerken gegevens - geınstalleerd: In-
talio|Designer creeert niet en Intalio|Server voert uit
Theorie
De gelijkenis die hier aanwezig is, is net dezelfde als in de vorige situatie. Een van de subele-
menten is werkzaam en het andere niet.
Voorbeeld
Nemen we in het voorbeeld de taak waarbij klantengegevens worden opgevraagd en waarbij de
CPU al de opdracht heeft gegeven aan het kanaal om het i/o apparaat te starten. Hierbij is
Hoofdstuk 5. Vergelijking mainframe en BPMS 109
het mogelijk dat, terwijl het kanaal het order geeft aan een i/o apparaat om klantengegevens te
lezen, de CPU wacht op de gegevens en ondertussen niets verwerkt.
In het geval dat de werknemers van de lokale dienst aanwezig zijn en werken, krijgen zij op-
drachten van de Intalio|Server. Hierbij is het mogelijk dat diegene die processen modelleert niet
aanwezig is in het bedrijf en bijgevolg niets wordt gecreeerd in de Intalio|Designer.
Aan: CPU en kanalen verwerken gegevens - geınstalleerd: Intalio|Designer
creeert en Intalio|Server voert uit
Theorie
De gelijkenis die hier aanwezig is, is dat voor zowel het mainframe system/360 als voor het
BPMS beide subelementen werkzaam zijn.
Voorbeeld
Laten we aannemen dat de claimregeling kort na elkaar twee meldingen heeft gekregen van geno-
teerde claims. Voor de eerste melding die is binnengekomen, wordt op dit moment het verzeke-
ringsdocument gemaakt terwijl voor de tweede melding de klantengegevens worden opgevraagd.
Bijgevolg werkt hier de CPU aangezien die berekeningen maakt voor het verzekeringsdocument
van de eerste melding. Ook de kanalen zijn werkzaam aangezien deze orders uitwisselen met i/o
apparaten om de nodige klantengegevens te verkrijgen.
Voor het BPMS is het mogelijk dat de Intalio|Server taken rondstuurt naar de werknemers van
de lokale dienst terwijl de modelleerder het accountingproces aanpast in de Intalio|Designer.
Bijgevolg zijn hier beide apparaten werkzaam.
Aan: CPU en kanalen verwerken niets - geınstalleerd: Intalio|Designer
creeert niet en Intalio|Server voert niets uit
Theorie
In dit geval zijn voor zowel het mainframe system/360 als voor het BPMS beide subelementen
niet werkzaam.
Voorbeeld
Wanneer de claimregeling nog geen melding heeft gekregen dat er claims zijn genoteerd, wor-
den er geen klantengegevens opgevraagd, wordt er geen informatie ingegeven en wordt er geen
Hoofdstuk 5. Vergelijking mainframe en BPMS 110
verzekeringsdocument opgesteld. In dit geval zijn bijgevolg de CPU en de kanalen beide niet
werkzaam.
Wanneer we enkel het proces van de lokale dienst bekijken, is het mogelijk dat er nog geen auto
is teruggebracht en er bijgevolg geen taken moeten worden uitgevoerd. Wanneer bovendien ook
de modelleerder afwezig is, worden er geen processen gecreeerd in de Intalio|Designer.
Uit - niet geınstalleerd
Theorie
In dit geval is het mainframesysteem zelf niet werkzaam gezien het op uit staat. Ook het BPMS
is niet werkzaam gezien het niet is geınstalleerd.
Voorbeeld
Indien het bedrijf bijvoorbeeld beslist om voor lange tijd te sluiten, kan iemand van de claimre-
geling naar de kelder gaan om het mainframesysteem uit te schakelen, zodat er geen onnodige
energiekosten worden gemaakt.
Indien het bedrijf nergens een BPMS gebruikt en enkel werkt met het mainframesysteem, dan is
het BPMS niet geınstalleerd en bijgevolg niet aanwezig. Zo zal de lokale dienst dan ook werken
met een mainframesysteem in plaats van met het BPMS.
5.6.2 Acties
Hier kan weer worden opgemerkt dat uit de analyse in punt 5.3.2 bleek dat er een relatie
lijkt te bestaan tussen een actie van het ene systeem en een interne interactie van het andere
systeem. Het vertalen van opdrachten door de kanalen wordt namelijk gelijkgesteld met de
interne interactie deploy waarbij het procesmodel in BPMN wordt omgezet naar BPEL.
Vele acties die zich afspelen binnen de subelementen, zijn specifiek voor die bepaalde subele-
menten. Deze kunnen bijgevolg niet worden vergeleken en worden hier ook niet weergegeven
aangezien deze reeds zijn beschreven in hun respectievelijke hoofdstukken. Hierdoor kan er
slechts een actie worden gelijkgesteld tussen beide systemen. Deze wordt hieronder beschreven.
Programma’s uitvoeren - processen uitvoeren
Theorie
Hoofdstuk 5. Vergelijking mainframe en BPMS 111
De CPU en de kanalen zorgen ervoor dat programma’s die gegevens verwerken, worden uitge-
voerd. De kanalen nemen hierbij bepaalde taken van de CPU over om deze te ontlasten. De
nodige gegevens om dit programma uit te voeren, komen vanuit de hoofdopslageenheid of vanuit
een i/o apparaat (IBM, 1967, 1964). Dit kan worden vergeleken met de Intalio|Server die ook,
net zoals de CPU en de kanalen, iets uitvoert. Wat het uitvoert, is echter geen programma maar
een proces. Bijgevolg zorgen beide ervoor dat taken in het proces worden afgewerkt, zodat het
proces kan verder lopen.
Voorbeeld
Toegepast op het voorbeeld zorgen de CPU en de kanalen er bijvoorbeeld voor dat het program-
ma dat het document van de verzekering creeert, wordt uitgevoerd. Het programma om zo een
document uit te voeren geeft namelijk bepaalde instructies die de CPU of de kanalen uitvoeren.
Hier kan er bijvoorbeeld een berekening nodig zijn om het bedrag van de schade te bepalen.
Die kan door de CPU worden uitgevoerd. De Intalio|Server zorgt ook voor de uitvoering van
een document, namelijk het claimrapport. De Intalio|Server stuurt een opdracht uit naar een
persoon die er zelf dan voor zorgt dat dit claimrapport wordt opgesteld. Deze persoon kan
hiervoor ook een programma gebruiken en laat de Intalio|Server weten wanneer de opdracht is
uitgevoerd. Bijgevolg zorgen zowel de Intalio|Server als de CPU met de kanalen ervoor dat een
bepaald deel van het proces wordt afgewerkt zodanig dat de volgende stap in het proces kan
worden uitgevoerd.
5.7 Conclusie
In dit hoofdstuk werd de laatste stap uitgewerkt om een antwoord te vinden op de onderzoeks-
vraag: Wat zijn de gelijkenissen en verschillen tussen een mainframe en een BPMS vanuit het
standpunt van de systeemtheorie? Hiervoor werd gebruikt gemaakt van de vier aspecten uit
de tabel opgesteld vanuit de opvatting van Wieringa (1996-2006) namalijke: structuuraspect,
grensaspect, functieaspect en gedragsaspect.
Vooreerst kan uit de vergelijking op basis van het structuurapsect worden besloten dat er weinig
gelijkenissen bestaan tussen de subelementen van elk systeem wat betreft hun structuur. Enkel
het systeemcontrolepaneel en het besturingssysteem van het mainframe system/360 kunnen
respectievelijk worden vergeleken met de computer waarop het BPMS is geınstalleerd en het
bijhorende besturingssysteem. Bijgevolg kunnen ook weinig gelijkaardige interne interacties
worden gevonden. Er is echter wel een opmerkelijke vaststelling dat een actie van het ene
Hoofdstuk 5. Vergelijking mainframe en BPMS 112
systeem een relatie vertoont met een interne interactie van het andere systeem. Het vertalen
van opdrachten door de kanalen wordt namelijk gelijkgesteld met de interne interactie deploy
waarbij het procesmodel in BPMN wordt omgezet naar BPEL.
Ten tweede kan uit het grensaspect worden besloten dat er in tegenstelling tot de geringe ver-
gelijkingsmogelijkheden tussen de subelementen, wel meerdere gelijkenissen bestaan tussen de
elementen in de omgeving van beide systemen. Het is echter niet omdat er meerdere elementen
in de omgeving kunnen worden vergeleken, dat er bijgevolg ook meerdere externe interacties
gelijk zijn. Beide systemen zijn wel vergelijkbaar wat betreft het dynamsisch zijn. Aangezien
beide systemen interageren met elementen in hun omgeving zijn beide systemen dynamisch. Het
mainframe system/360 is echter meer modulair dan het BPMS van Intalio. Bijgevolg kan het
mainframe system/360 beter als een onafhankelijke eenheid worden gezien.
Ten derde blijkt uit de bespreking van het functieaspect dat de gebruikers van de systemen
verschillende behoeftes hebben wat leidt tot verschillende functies die niet allemaal kunnen
worden vergeleken. De gebruikers zelf kunnen voor beide systemen wel onderverdeeld worden
in gelijke groepen maar gezien hun verschillende behoeftes gebruiken deze gebruikers elk van de
systemen op een andere wijze.
Ten laatste kan er uit het grensaspect worden besloten dat de toestanden gelijkaardig zijn maar
dat er slechts een actie van het mainframe system/360 kan worden vergeleken met een actie van
het BPMS van Intalio. De CPU en de kanalen zorgen er namelijk voor dat programma’s worden
uitgevoerd terwijl de Intalio|Server processen uitvoert. Hier kan ook terug dezelfde opmerking
worden gemaakt als bij het structuurapsect namelijk dat er een relatie lijkt te bestaan tussen
een actie van het mainframe system/360 en een interne interactie van het BPMS van Intalio.
De besproken vergelijking van het structuuraspect, grensaspect, functieaspect en gedragsaspect
werd telkens respectievelijk in tabel 5.1, 5.2, 5.3 en 5.4 weergegeven. Deze tabellen worden
samengevat in tabel 5.5 die hieronder wordt weergegeven.
Tabel 5.5: Vergelijking van het mainframe system/360 met het BPMS van Intalio aan de hand van de
tabel vanuit de opvatting van Wieringa (1996-2006)
MAINFRAME BPMS
structuur subelementen systeemcontrolepaneel computer
besturingssysteem besturingssysteem
CPU /
Deze tabel gaat verder op de volgende bladzijde
Hoofdstuk 5. Vergelijking mainframe en BPMS 113
kanalen /
/ Intalio|Server
/ Intalio|Designer
relatie / /
interne inter-
acties
/ /
acties = in-
terne interac-
ties
vertaal opdrachten deploy
grens omgeving magnetische tape-eenheden procesbasis
en harde schijf en
drum opslageenheden
printer printer
terminal computer: dashboards en e-
gelijksoortige systemen gelijksoortige systemen
mensen mensen
ruimte ruimte
kaartlezer /
kaartprikker /
controle-eenheid /
/ systeem met bedrijfsregels
/ andere bedrijfssystemen
/ voorbeeldprocessen
externe inter-
acties
lees en schrijf exporteer en importeer proces
informatie uitwisselen informatie uitwisselen
interacties met mensen interacties met mensen
interacties met ruimte interacties met ruimte
dynamisch ja ja
modulair redelijk in beperkte mate
functie functie uitwisselen van gegevens uitwisselen van gegevens
grote afstand grote afstand
Deze tabel gaat verder op de volgende bladzijde
Hoofdstuk 5. Vergelijking mainframe en BPMS 114
verminderen van fouten verminderen van fouten
gebruikers niet-menselijke systemen niet-menselijke systemen
bedrijfsgebruikers bedrijfsgebruikers
IT-gebruikers IT-gebruikers
lesgevers en studenten educatieve gebruikers
gedrag toestand *aan: CPU verwerkt gege-
vens, kanalen verwerken niets
*geınstalleerd: Intalio|Desig-
ner creeert en Intalio|Server
voert niets uit
*aan: CPU verwerkt niets, ka-
nalen verwerken gegevens
*geınstalleerd: Intalio|Desig-
ner creeert niet en Intalio|Ser-
ver voert uit
*aan: CPU en kanalen ver-
werken gegevens
*geınstalleerd: Intalio|Desig-
ner creeert en Intalio|Server
voert uit
*aan: CPU en kanalen ver-
werken niets
*geınstalleerd: Intalio|Desig-
ner creeert niet en Intalio|Ser-
ver voert niets uit
*uit *niet geınstalleerd
acties uitvoeren van een programma uitvoeren van processen
Besluit
Conclusies
Zowel een mainframesystemen als een BPMS kunnen in een bedrijf aanwezig zijn en kunnen
bovendien een bijdrage leveren aan de werking van het bedrijf. Bijgevolg werd in deze thesis het
mainframe system/360 vergeleken met het BPMS van Intalio met als doel de gelijkenissen en
verschillen hiertussen te bepalen vanuit het standpunt van de systeemtheorie. De belangrijkste
conclusies uit de vergelijking kunnen in vier delen worden onderverdeeld namelijk: de structuur
van beide systemen, de omgeving van beide systemen, de functie van beide systemen en het
gedrag van beide systemen.
Wat de structuur betreft zijn de onderdelen van elk systeem moeilijk vergelijkbaar aangezien
deze anders zijn opgebouwd. Bij het mainframesysteem ligt de nadruk meer op de hardware-
componenten terwijl bij het BPMS de nadruk ligt op de softwarecomponenten. Ook de manier
waarop deze onderdelen onderling interageren verschilt bij beide systemen.
In tegenstelling hiermee zijn er onder de elementen in de omgeving meerdere vergelijkingen mo-
gelijk. Vele omgevingselementen van beide systemen hebben een gelijkaardige manier van werken
en sommige hebben zelfs een vergelijkbare structuur. Er kan echter ook worden geconcludeerd
dat de manier waarop deze omgevingselementen interageren met het systeem vaak verschillend
is. Ook kan een mainframe system/360 beter als een onafhankelijke eenheid worden gezien dan
het BPMS aangezien het mainframesysteem fysiek kan worden waargenomen en vanuit een cen-
trale plaats opereert. Het BPMS brengt echter meerdere computers met elkaar in verbinding en
creeert zo een netwerk van computersystemen.
Hierdoor lopen ook de functies van beide systemen niet altijd gelijk. De mensen die gebruik
maken van deze functies kunnen wel in gelijkaardige groepen worden onderverdeeld maar deze
gebruiken de systemen elk op een andere wijze.
Wat het gedrag betreft, kunnen beide systemen zich in gelijkaardige situaties bevinden.
115
Besluit 116
Algemeen toonde de vergelijking aan dat alhoewel deze systemen op bepaalde vlakken gelijkenis-
sen vertonen er toch een groot verschil is qua aanwezigheid in de onderneming. Een mainframe
systeem is meer gecentraliseerd waarbij dit bovendien een zichtbare, fysische eenheid vormt die
kan worden onderscheiden van zijn omgeving. In tegenstelling hiermee is een BPMS meer gedis-
tribueerd. Het zorgt ervoor dat de werknemers met elkaar in verbinding staan via hun computer.
Bovendien komen deze werknemers vaak rechtstreeks in contact met het systeem. Een BPMS
kan echter fysiek niet waargenomen worden, wat het moeilijk maakt een lijn te trekken tussen
het systeem en zijn omgeving.
Beperkingen
Deze thesis vormt een eerste insteek in de vergelijking tussen een mainframe en een BPMS.
Andere literatuur die dit onderwerp aankaart is voorlopig niet beschikbaar. Bovendien bevat
deze thesis ook enkele beperkingen.
Een hinderpaal voor het schrijven van deze thesis was het gebrek aan algemeen aanvaarde
literatuur. Vooreerst is er weinig literatuur over het mainframe system/360. Veel literatuur over
dit systeem is bovendien technisch ingesteld. Een tweede beperking is het gebrek aan literatuur
over een BPMS. Er is reeds onderzoek verricht maar veel literatuur beperkt zich tot de BPM
theorie en deze is nog steeds in ontwikkeling. De voornaamste beperking van de thesis zelf is het
gebruik van een specifiek mainframesysteem en een specifiek BPMS. Aangezien er ook andere
mainframesystemen en BPMSs bestaan, maakt dit de veralgemeenbaarheid van de conclusies
moeilijk. Bovendien werden deze twee specifieke systemen op slechts een manier met elkaar
vergeleken namelijk vanuit het standpunt van de systeemtheorie.
Aanbevelingen
Deze beperkingen leiden meteen tot enkele voorstellen voor verder onderzoek. Vooreerst kunnen
de begrippen waarmee de twee systemen werden vergeleken, worden uitgebreid met andere
nuttige begrippen. Een tweede voorstel tot verder onderzoek bestaat erin andere specifieke
systemen met elkaar te vergelijken. Voorlopig werd de vergelijking enkel uitgevoerd voor een
maiframe system/360 en een BPMS van Intalio, maar andere systemen zijn mogelijk. Een
derde mogelijkheid tot verder onderzoek is om de meer technische kant van deze systemen na te
gaan om zo tot een vergelijking te komen. Hierbij kunnen de onderliggende technologieen van
beide systemen worden bestudeerd om dieper in te gaan op de evolutie van een gecentraliseerd
mainframesysteem tot een gedistribueerd BPMS.
Bibliografie
anoniem (2010). Back in fashion. Economist, 394(8665):64–66.
D. H. Benson (1983). A field study of end user computing: Findings and issues. MIS quarterly,
7(4):35–45.
L. v. Bertalanffy (1968). General System Theory. Penguin Books, Harmondsworth.
K. E. Boulding (2003). General systems theory - the skeleton of science. In Systems Thinking
Volume 1: General Systems Theory, Cybernetics and Complexity, pp. 52–62. SAGE Publica-
tions, Londen.
D. Bradbury (2008). The ’big iron’ is back. Engineering and Technology, 3(12):60–63.
T. Bresnahan & S. Greenstein (1999). Technological competition and the structure of the
computer industry. The Journal of Industrial Economics, 47(1):1–40.
D. Churbuck & G. Samuels (1996). Can ibm keep it up. Forbes, 157(11):142–144.
C. W. Churchman (1968). The Systems Approach. Dell Publishing, New York.
J. Cummings (2008). The new brood of best-of-breed. Business finance, pp. 16–26.
T. H. Davenport (1993). Process Innovation: Reengineering Work through Information Techno-
logy. Harvard Business School Press, Boston.
T. Eddolls (2009). Life begins at 45. Engineering and Technology, 4(20):58–59.
C. Finkelstein (2005). Business process managment software vendors part 4: Intalio|n3. DM
Review, 15(12):78–80.
D. S. Frankel (2003). Bpm and mda: The rise of model-driven enterprise systems. Business
Process Trends, pp. 1–15.
C. B. Germain (1967). Programming the IBM 360. Prentice-Hall, Englewood Cliffs.
xi
Bibliografie xii
D. Gifford & A. Spector (1987). Case study: Ibm’s system 360-370 architecture. Communications
of the ACM, 30(4):291–307.
O. M. Group (2010). <http://www.bpmn.org/index.htm>(20/02/2010).
A. Hall & R. Fagen (2003). Definition of system. In Systems Thinking Volume 1: General
Systems Theory, Cybernetics and Complexity, pp. 63–82. SAGE Publications, Londen.
M. Hammer & J. Champy (2003). Reengineering the Corporation: A Manifesto for Business
Revolution. HarperCollins, New York.
P. Harmon (2003). Business process architecture and the process-centric company. Business
Process Trends, 1(3):1–11.
P. Harmon (2007). Business Process Change: A Guide for Business Managers and BPM and
Six Sigma Professionals. Elsevier/Morgan Kaufmann Publishers, Amsterdam; Boston.
J. B. Hill, M. Cantara, M. Kerremans & D. C. Plummer (2009). Magic quadrant for business
process management suites. Technical report, Gartner.
IBM (1964). Ibm system/360 system summary. Technical report, IBM.
IBM (1965). Ibm system/360: Input/output configurator. Technical report, IBM.
IBM (1967). Student text: Introduction to ibm system/360 architecture. Technical report, IBM.
IBM-DPD (1964). IBM System/360 Principles of Operation. IBM.
IBM-website (2010). <http://www-03.ibm.com/ibm/history/>(10/03/2010).
Intalio (2007). Intalio|bpms designer: an overview. Technical report, Intalio.
Intalio-website (2010). <http://community.intalio.com/>(05/03/2010).
D. Keuning (1973). Algemene systeemtheorie, systeembenadering en organisatietheorie. Stenfert
Kroese, Leiden.
K. P. McCormack (2001). Business Process Orientation: Gaining the E-Business Competitive
Advantage. St. Lucie Press, Boca Raton.
M. D. Mesarovic (1964). Views on General Systems Theory. Wiley, New York.
G. G. Moghaddam & M. Moballeghi (2008). Total quality management in library and informa-
tion sectors. The Electronic Library, 26(6).
Bibliografie xiii
A. Opler (1966). Programming the IBM System/360. John Wiley and Sons, New York.
Z. L. Pereira & L. Aspinwall (1997). Total quality management versus business pocess re-
engineering. Total Quality Management, 8(1):33–39.
A. Perkins (2009). Mainframe sweet mainframe. IBM Systems Magazine, pp. 1–6.
D. M. Peterson (2006). Ensuring security on ibm mainframes. Business Communications Review,
pp. 56–61.
D. R. Shaw, C. P. Holland, P. Kawalek, B. Snowdon & B. Warboys (2007). Elements of a
business process management system: theory and practice. Business Process Management,
13(1):91–107.
B. Silver (2006). Sketching out bpm. Infoworld, 28(8):26–35.
H. Smith & P. Fingar (2007). Business Process Management: the third wave. Meghan-Kiffer
Press, Tampa.
B. Stineman (2007). Bpm: Suite value. AIIM E-DOC, 21(2):42–43.
A. Thomas (1971). System 360 Programming. Rinehart Press, San Francisco.
K. Vergidis, A. Tiwari & B. Majeed (2008). Business process analysis and optimization: Beyond
reengineering. IEEE Transactions on Systems, Man and Cybernetics - Part C: Applications
and Reviews, 38(1):69–82.
K. Vollmer & H. Peyret (2006). The forrester wave: Integration-centric business process mana-
gement suites, q4 2006. Technical report, Forrester.
R. J. Wieringa (1996-2006). Requirements Engineering: Frameworks for Understanding. Faculty
of Mathematics and Computer Science, Vrije Universiteit Amsterdam.