UNIVERSITEIT GENT FACULTEIT ECONOMIE EN...

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.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


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.


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


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.


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.


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


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.


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.


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.


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:


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


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-


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:


een diensten 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


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.


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).


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


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.


Figuur 2.1: Een autoverhuurproces uitgewerkt met BPMN


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


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).


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)


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


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-


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


(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.


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.


Figuur 2.4: Een autoverhuurproces uitgewerkt met BPMN


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


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:


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-


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


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)


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


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


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


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


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


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-


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


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.


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.


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.


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


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:


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.


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


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


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


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.


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:


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


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



dynamisch ja



modulair redelijk


grote hoeveelheden gegevens verwerken

meegroeien in volume

groei in applicatiemogelijkheden

besparing op trainingskosten

grotere doorstroom

verminderen menselijke interventies

werk creeren

lesmateriaal


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


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.


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.


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):


Figuur 4.4: Intalio|Workflow (Intalio-website, 2010)


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:


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


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).


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.


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).


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).


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.


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:


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.


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


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.


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.


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.


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:


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



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


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.


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-


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:


Tabel 4.3: Functie BPMS


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


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.


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:


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



andere bedrijfssystemen

BPMS

mensen

ruimte

voorbeeldprocessen

externe interacties exporteer proces

importeer proces

toevoegen KPI

aanroepen bedrijfsregels

uitwisselen procesonderdelen



dynamisch ja

modulair in beperkte mate


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


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



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.


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.


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


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.


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


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


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).


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.


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.


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.


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


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


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


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


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


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


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


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:



systeem en de omgeving (koppeling).


buiten het systeem.


ponenten en de omgeving.


de systeemgrens te transporteren.


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).


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


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


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


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


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


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


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


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


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


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


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 /



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-

mail

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



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


ner creeert niet en Intalio|Ser-

ver voert uit

*aan: CPU en kanalen ver-

werken gegevens


ner creeert en Intalio|Server

voert uit

*aan: CPU en kanalen ver-

werken niets


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.

UNIVERSITEIT GENT FACULTEIT ECONOMIE EN...

Documents

Transcript of UNIVERSITEIT GENT FACULTEIT ECONOMIE EN...