Scriptie Saban Karki - Platform Outsourcing Nederland

Evaluatie Uniforme Normverdeling
Beheeruren bij Applicatie Insourcing,
toegepast op ASL
Master Thesis
Saban Karki
september 2007
Amsterdam, Nederland
Evaluatie Uniforme Normverdeling
Beheeruren bij Applicatie Insourcing,
toegepast op ASL
Master Thesis
Saban Karki
[email protected]
<1350625>
september 2007
© Alle rechten voorbehouden. Niets uit deze uitgave mag worden openbaar gemaakt of verveelvoudigd, opgeslagen
in een dataverwerkend systeem of uitgezonden in enige vorm door middel van druk, fotokopie of welke andere wijze
dan ook zonder voorafgaande schriftelijke toestemming van de directeur van Getronics PinkRoccade BAS.
Vrije Universiteit
Faculteit der Exacte Wetenschappen
Afdeling Informatica
De Boelelaan 1081 A
1081 HV Amsterdam
Nederland
Getronics PinkRoccade
Afdeling Research & Development
Staalmeesterslaan 410
Postbus 57005
1040 CG Amsterdam
Nederland
Begeleiders
Dr. A.S. Klusener
Begeleiders
Dhr. S.C. Chang
Ing. J.D. Gerbrandy, MBA
Evaluatie Uniforme Normverdeling Beheeruren bij Applicatie Insourcing, toegepast op ASL
Voorwoord
Deze scriptie schreef ik ter afronding van mijn studie Informatiekunde (Information
Science) aan de Vrije Universiteit in Amsterdam. Het onderzoek is uitgevoerd in opdracht
van Getronics PinkRoccade te Amsterdam. Deze scriptie is ook het resultaat van meer dan
6 maanden onderzoek, ik wil hierbij iedereen bedanken voor alle hulp en steun die ik heb
gekregen tijdens het onderzoek.
Ik wil Getronics PinkRoccade bedanken voor de stage plek die ik heb gekregen. Binnen de
organisatie ben ik op een goede manier behandeld en geholpen. Verder werd er ook een
prima werkplek voor me gecreëerd.
Via deze weg wil ik een aantal mensen in het bijzonder bedanken:
-
Thiel Chang (Getronics PinkRoccade) en Jelle Gerbrandy (Getronics PinkRoccade) voor
het begeleiden van mijn hele onderzoekstraject binnen de organisatie. We hebben
vaak gediscussieerd over het onderzoek, waardoor ik iedere keer na een discussie
gemotiveerd was om verder te gaan met het onderzoek. Deze gesprekken waren
waardevol voor mijn onderzoek, nogmaals bedankt voor jullie inzet en steun.
-
Steven Klusener (Vrije Universiteit) voor het begeleiden van mijn onderzoek vanuit de
VU. De feedback sessies waren ook van groot belang voor het afronden van mijn
onderzoek. Ik wil je ook bedanken voor de bereidheid om ook telkens naar GPR te
komen voor de feedback sessies.
-
Verder hebben gesprekken met mensen binnen Getronics PinkRoccade, Emiel Bos,
Henny Snijder, Martin Bloo en Marcel Oevermans, bijgedragen aan het opzetten van
het onderzoek.
Ik wens u veel plezier bij het lezen,
Saban Karki
Amsterdam, september 2007
© Getronics PinkRoccade 2007
ii
Voorwoord
Inhoudsopgave
VOORWOORD.................................................................................................................................................... II
1
2
3
4
INLEIDING ................................................................................................................................................. 1
1.1 ONDERZOEKSOMGEVING .........................................................................................................1
1.2 AANLEIDING ONDERZOEK .......................................................................................................1
1.3 PROBLEEMSTELLING ................................................................................................................1
1.4 DOELSTELLING .........................................................................................................................2
1.5 ONDERZOEKSVRAAG................................................................................................................3
1.5.1 Conclusie, Advies en Validatie ..............................................................................4
1.6 ONDERZOEKSMETHODE ...........................................................................................................5
1.6.1 Literatuuronderzoek..................................................................................................5
1.6.2 Interviews .....................................................................................................................5
1.7 AFBAKENING ............................................................................................................................6
1.8 OPBOUW VERSLAG ..................................................................................................................7
OUTSOURCING ......................................................................................................................................... 8
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
INLEIDING ................................................................................................................................8
OUTSOURCING DEFINITIE .......................................................................................................8
FASES OUTSOURCING TRAJECT ...............................................................................................9
APPLICATIE OUTSOURCING DEFINITIE .................................................................................10
TRENDS APPLICATIE OUTSOURCING .....................................................................................11
BEST PRACTICES ....................................................................................................................11
APPLICATIE OUTSOURCING BINNEN HET ONDERZOEK ........................................................12
CMMI BINNEN DE ORGANISATIE .........................................................................................12
APPLICATIE BEHEER & ONDERHOUD ....................................................................................... 13
3.1 INLEIDING ..............................................................................................................................13
3.2 DEFINITIE APPLICATIEBEHEER EN ONDERHOUD ..................................................................13
3.3 VERSCHIL TUSSEN BEHEER & ONDERHOUD.........................................................................14
3.4 METRIEK (MEASUREMENT) ...................................................................................................18
3.5 URENADMINISTRATIE ............................................................................................................20
3.6 FACTOREN APPLICATIES ........................................................................................................21
3.6.1 Beïnvloedbare factoren ..........................................................................................21
3.6.2 Bepalende factoren..................................................................................................22
3.6.3 Grootte applicatie.....................................................................................................23
3.6.4 Migratie ........................................................................................................................24
3.6.5 Programmeertaal & Frameworks .......................................................................24
3.7 VERDEELSLEUTEL ...................................................................................................................25
HET STANDAARDISEREN VAN URENPOSTEN........................................................................ 26
4.1 INLEIDING ..............................................................................................................................26
4.2 CRITERIA VOOR OPSTELLEN MODEL .....................................................................................26
4.2.1 V-GQM (1) GOAL STATEMENT ............................................................................26
4.2.2 V-GQM (2) QUESTION DEFINITION..................................................................27
4.2.3 V-GQM (3) METRIC DERIVATION.......................................................................27
4.3 EERSTE OPZET .......................................................................................................................28
4.4 NIEUW MODEL ........................................................................................................................29
4.4.1 Verdeelsleutel ............................................................................................................30
4.5 MINIMALE SET ........................................................................................................................32
4.5.1 Nieuwe Percentuele Verdeling.............................................................................33
4.6 OMZETTING NAAR ASL URENPOSTEN ..................................................................................34
4.6.1 Stappen voor de omzetting naar de basisset................................................34
4.6.2 Statistische benadering van het model ...........................................................37
© Getronics PinkRoccade 2006
iii
Evaluatie Uniforme Normverdeling Beheeruren bij Applicatie Insourcing, toegepast op ASL
5
6
7
CASE STUDY............................................................................................................................................. 38
5.1 INLEIDING ..............................................................................................................................38
5.2 OVERZICHT CONTRACTEN .....................................................................................................41
5.2.1 V-GQM (4) DATA COLLECTION (1/2) ...............................................................41
5.3 STATISTISCHE BENADERING .................................................................................................42
5.3.1 Representatie en Visualisatie ..............................................................................42
5.3.2 Principal Component Analyse ..............................................................................47
5.3.3 Cluster Analyse .........................................................................................................50
5.3.4 Lineaire Regressie....................................................................................................55
5.4 STATISTISCH ONDERZOEK NORMVERDELING .....................................................................61
5.5 AFRONDING EN EVALUATIE CASE STUDY ............................................................................65
VALIDATIE................................................................................................................................................ 67
6.1 INLEIDING ..............................................................................................................................67
6.2 VALIDATIE AFWIJKINGEN EN SPREIDINGEN ........................................................................67
6.2.1 V-GQM (4) DATA COLLETION (2/2)..................................................................67
Cluster 1......................................................................................................................................67
Cluster 2......................................................................................................................................69
Cluster 3......................................................................................................................................70
Cluster 4......................................................................................................................................71
Uitschieters.................................................................................................................................72
6.3 VALIDATIE THEORIE...............................................................................................................73
6.4 CORRECTIEFACTOR ................................................................................................................75
6.5 VALIDATIE MINIMALE SET AAN URENPOSTEN .....................................................................77
6.6 SAMENVATTING......................................................................................................................78
6.6.1 V-GQM (5) METRIC VALIDATION.......................................................................78
6.6.2 V-GQM (6) QUESTION ANALYSIS ......................................................................79
CONCLUSIE .............................................................................................................................................. 80
7.1
7.2
7.3
7.4
DEELVRAGEN ..........................................................................................................................80
HOOFDVRAAG.........................................................................................................................83
V-GQM (7) GOAL REFINEMENT...................................................................................83
TOEGEVOEGDE WAARDE EN VERVOLGONDERZOEK .............................................................84
FIGUREN- EN TABELLENLIJST ............................................................................................................... 86
TERMINOLOGIELIJST.................................................................................................................................. 87
LITERATUURLIJST ........................................................................................................................................ 91
APPENDIX A – INTERVIEW VRAGEN.................................................................................................. 93
APPENDIX B - VERDEELSLEUTELS....................................................................................................... 97
© Getronics PinkRoccade 2007
iv
Inleiding
1 Inleiding
1.1 Onderzoeksomgeving
We hebben onderzoek gedaan naar een algemene norm voor organisaties bij applicatie
insourcing. Deze norm zou uniforme urenposten voor beheer en onderhoud vormen, die
voor organisaties praktisch toepasbaar zouden kunnen zijn. Het onderzoek is uitgevoerd
binnen Getronics PinkRoccade (GPR). GPR heeft in de loop der jaren ICT kennis
opgebouwd en heeft ook veel ervaring op het gebied van architectuur, infrastructuur en
applicatieve dienstverlening [GPR1_2007]. Zo hebben we aan de hand van bestaande
urenregistraties van applicaties de norm gevalideerd. Deze applicaties worden op
verschillende wijze beheerd en onderhouden. Organisaties dienen hun administratie goed
op orde te houden, zodat het betrokken management ook een beter overzicht heeft.
1.2 Aanleiding Onderzoek
GPR heeft momenteel verschillende SLA terminologielijst (Service Level Agreement) contracten
met grote klanten die het beheer en onderhoud van hun applicatie bij GPR hebben. Deze
contracten worden ook met de tijd in aantal steeds groter. Dit komt steeds vaker en bij
meerdere organisaties voor. Binnen GPR is er momenteel een onderzoek gaande naar de
ontwikkeling van een calculatiesheet om beheer en onderhoud van applicaties beter in
kaart te brengen. Een onderdeel hiervan is een percentuele verdeling van de uren van de
beheerprocessen. Deze verdeling geldt als een standaard binnen de organisatie, maar hier
was tot op heden nog geen wetenschappelijk onderzoek naar gedaan. Binnen het
onderzoek willen we aan kunnen tonen of deze manier van werken als een standaard kan
dienen voor organisaties die applicaties insourcen.
1.3 Probleemstelling
De uitdaging van sourcing ligt bij de meeste organisaties in het bijzonder in de nieuwbouw,
onderhoud en beheer van de applicaties. We zullen ons voornamelijk richten op het beheer
en onderhoud bij applicatie insourcing. Voor ons onderzoek is het belangrijk om te kijken
naar het model dat gebruikt wordt voor het beheer en onderhoud uren. Dit model dient als
standaard voor GPR om het beheer en onderhoud processen in te richten.
Op dit moment worden veel beheerprocessen uitgevoerd op basis van ervaringen uit de
praktijk. Het is dan ook belangrijk deze processen hard aantoonbaar te maken. In tabel
1.1 zien we een model dat gebruikt wordt bij aanbiedingen voor klanten. Deze figuur gaan
we overigens trachten te valideren, door te kijken naar bestaande contracten. Deze
validatie stap binnen het onderzoek zal tevens de belangrijkste bijdrage zijn van de
scriptie. Deze bestaande applicaties zouden dan voor een groot deel overeen moeten
komen met de standaard. In de onderstaande tabel zien we een lijst aan urenposten met
de percentuele verdeling ervan. Beheer en onderhoud hebben we gedefinieerd in ASLtermen (ASL staat voor Application Services Library). ASL is een standaard om
applicatiebeheer te professionaliseren. Eén beheeruur is volgens de norm als volgt
opgebouwd:
© Getronics PinkRoccade 2007
1
Inleiding
ASL proces
Incident management (Incidentbeheer)
Configuration management (Configuratiebeheer)
Availability management (Beschibaarheidsbeheer)
Capacity management (Capaciteitsbeheer)
Continuity management (Continuïteitsbeheer)
Change management (Wijzigingenbeheer)
Software Control en distribution (Programmabeheer en distributie)
Onderhoud (correctief, preventief en perfectief)
Tactisch management
Strategisch management
TOTAAL
Tabel 1.1 Normverdeling beheeruren (ASL Processen)
Percentage
12%
5%
15%
3%
5%
2%
5%
40%
10%
3%
100%
In tabel 1.1 zien we de normverdeling van de ASL processen. Deze normverdeling bevat
de ASL processen, waarop uren eventueel in de praktijk op geregistreerd kunnen worden.
Volgens bovenstaande wordt dus 12% van alle beheeruren besteed aan incident
management en 40% van de uren bedoeld voor onderhoud (correctief, preventief en
perfectief). De definities van deze woorden worden besproken in hoofdstuk 3. Deze
normverdeling is gemaakt op pure ervaring en kennis, waar tot op heden nog geen
onderzoek naar gedaan is. Het is dan belangrijk om te onderzoeken of dit een bruikbare
normverdeling is. Aan de hand van de geadministreerde beheeruren van contracten
moeten we kunnen bepalen wat de minimale set is, waarop beheeruren bijgehouden
kunnen worden. Aan het eind van het onderzoek kunnen we uiteindelijk aangeven op
welke urenposten insourcers hun uren voor beheer en onderhoud kunnen registreren.
Verder willen we weten op welke manier we de gegevens kunnen ophalen om tot zo’n
verdeling te komen, om het te kunnen vergelijken met de normverdeling. Hiermee doelen
we op de geadministreerde beheeruren van contracten. Als laatst willen we een hulpmiddel
ontwikkelen waarmee het betrokken management verschillende outsourcing contracten
met elkaar kan vergelijken, indien contracten op verschillende wijze geadministreerd
worden. De percentuele verdeling van de norm kan dan als standaard gebruikt worden, en
contracten waarvan de percentuele verdeling afwijken kunnen dan ook bijgestuurd
worden. Op deze manier krijgen we een opsomming van urenposten met de daarbij
behorende percentuele verdeling ervan. We kunnen dan zien of er een uniforme manier
van uren registeren bestaat voor beheer en onderhoud.
1.4 Doelstelling
Binnen GPR wordt een normverdeling voor beheeruren gebruikt die gevalideerd dient te
worden. Er is behoefte om de normen voor het beheer en onderhoud beter in kaart te
brengen.
Ons doel is om een model te ontwikkelen waarop insourcers van applicaties hun
beheerprocessen kunnen inrichten en hun beheeruren kunnen registreren. Zo gaan we in
de loop van het onderzoek een lijst opstellen met de beheerposten voor insourcers. De
huidige normverdeling van beheeruren gaan we valideren en eventueel verbeteren aan de
hand van bestaande contracten. Zo komen we er ook achter of er een uniforme manier
van urenregistratie bestaat. Hierna zullen we een hulpmiddel ontwikkelen voor het
betrokken management om zelf huidige contracten met elkaar te kunnen vergelijken. Zo
kan het betrokken management per contract een vergelijking maken met de
normverdeling, en indien het contract veel afwijkt van de norm kan het bijgestuurd
worden. Het hulpmiddel is alleen belangrijk indien contracten verschillend worden
bijgehouden, waarbij er dus geen standaard is binnen de organisatie. Het belangrijkste is
dat iedereen op dezelfde manier zijn uren moet registeren, waarop organisaties een
duidelijk overzicht zullen hebben van de contracten.
2
© Getronics PinkRoccade 2007
Inleiding
1.5 Onderzoeksvraag
Aan de hand van de doelstellingen staan de volgende onderzoeksvragen in dit document
centraal:
Hoofdvraag:
In hoeverre werkt de kennis en ervaring van beheer en onderhoud van applicaties door in
het standaardiseren van uniforme urenposten om deze overzichtelijker te maken voor het
betrokken management?
Deelvraag 1:
•
Welke criteria en principes zijn van belang voor een succesvolle inrichting van beheer
en onderhoud van applicaties?
Deelvraag 2:
•
Op
welke
manier
kunnen
gestandaardiseerd worden?
urenregistraties
van
verschillende
applicaties
Deelvraag 3:
•
Is de huidige normverdeling aan urenposten van beheer en onderhoud uniform en
praktisch toepasbaar?
© Getronics PinkRoccade 2007
3
Inleiding
1.5.1 Conclusie, Advies en Validatie
Om meteen een goed beeld te hebben van het onderzoek, gaan we het al in dit onderdeel
hebben over het resultaat en de toegevoegde waarde van het onderzoek. De lezer van het
onderzoek zal tijdens het lezen erachter komen op welke manier men de ASL processen als
urenpost kan gebruiken om zijn uren voor beheer en onderhoud in te richten. Binnen de
organisatie kregen we ook te horen dat bijna elk contract uniek en anders van aard is. Het
kan voorkomen dat er voor een contract meer helpdesk uren nodig zijn. Verder zagen we
dat er binnen de organisatie geen uniforme uren bestonden, waarop de beheer en
onderhoud uren geregistreerd konden worden. Hierdoor hebben we tijdens het onderzoek
ervoor gekozen om uniforme uren te hanteren.
Conclusie
We kwamen er tijdens het onderzoek al snel achter dat de ASL processen binnen de
huidige normverdeling teveel urenposten kennen. Deze worden in de praktijk verschillend
geïnterpreteerd, waardoor het onderling vergelijken van contracten niet mogelijk is. De
ASL onderverdeling wordt in praktijk nauwelijks gebruikt, waardoor we een verdeelsleutel
hebben ontwikkeld om te achterhalen bij welke ASL processen de geregistreerde uren
horen.
Advies
We adviseren organisaties om het aantal urenposten naar 4 te beperken. De huidige
normverdeling (tabel 1.1) bleek voor de praktijk minder geschikt te zijn, doordat er teveel
urenposten waren. Deze urenposten die gebaseerd zijn op ASL zijn niet handig om in
praktijk te gebruiken door de grote hoeveelheid urenposten. Zo hebben wij een minimale
set aan urenposten gecreëerd waarop insourcers de beheer en onderhoud uren op kunnen
registeren. Tevens bevat de minimale set naast de uniforme 4 urenposten ook een
percentuele verdeling. Het betrokken management heeft hierdoor een veel beter overzicht
van de contracten. Indien een van de urenposten bij een contract veel afwijkt van de
percentuele verdeling, kan de contract manager aangesproken worden. Hierna kunnen
afspraken met de klant gestuurd en opnieuw besproken worden.
Validatie
Voor dit onderdeel hebben we aan de hand van 12 contracten bepaald dat deze minimale
set aan urenposten met de bijbehorende percentuele verdeling een bruikbare verdeling is.
Alle urenposten per contract hebben we allereerst gestandaardiseerd naar 4 urenposten.
Voor het standaardiseren van de contracten hebben we gebruik gemaakt van een
verdeelsleutel. Veel contracten kwamen in grote lijn wel overeen met de verdeling, en
afwijkingen konden uit onze verdeelsleutel verklaard worden. Voor het betrokken
management zou dit een prima middel zijn om een totaal overzicht te hebben van alle
contracten.
4
© Getronics PinkRoccade 2007
Inleiding
1.6 Onderzoeksmethode
1.6.1 Literatuuronderzoek
Aan de hand van literatuuronderzoek hebben we kennis verzameld over outsourcing en
applicatiebeheer & onderhoud om basiskennis op te bouwen voor het vervolg onderzoek.
Bronnen zijn als volgt verzameld: Boeken via universiteitsbibliotheken (UVA en VU),
portals waar wetenschappelijke artikelen beschikbaar worden gesteld (ACM en IEEE),
artikelen die via onderzoeksbureaus beschikbaar werden gesteld (Forrester Research en
Gartner), via het Internet en via publicaties.
Voor ons onderzoek gaan we de V-GQM (Validating Goal Question Metric) methode
gebruiken. Het gaat hier om een methode voor het analyseren van een GQM (Goal
Question Metric) studie, nadat data is verzameld met als doel de validatie van de studie
[OLSSON]. Deze methode bestaat uit verschillende stappen, waarbij de stappen over de
hoofdstukken 4, 5 en 6 toegepast worden. Hieronder vinden we de verschillende fases met
de daarbij horende toelichting:
o
o
o
o
o
o
o
Goal Statement: Eisen en doelen vastleggen (Hoofdstuk 4)
Question Definition: Vragen opstellen waarmee je het doel wilt bereiken.
(Hoofdstuk 4)
Metric Derivation: Hierin komt de maatverdeling en de metrieken categorieën
om vervolgens de question-metriek relatie vast te leggen. (Hoofdstuk 4)
Data Collection: Data verzamelen en het resultaat analyseren. (Hoofdstuk 5, 6)
Metric Validation: Testen of elke wijziging voldoet aan de eisen. (Hoofdstuk 6)
Question Analysis: Integratie van het testen (Hoofdstuk 6)
Goal Refinement: Eindresultaat testen (Hoofdstuk 7)
De verschillende fases zullen ons helpen bij het beantwoorden van onze
onderzoeksvragen. De fases zullen aan de hand van onze voorbeelden toegelicht worden in
de daarvoor aangegeven hoofdstukken.
1.6.2 Interviews
We hebben voor het onderzoek interviews afgenomen om de huidige praktijk m.b.t.
urenregistraties in kaart te brengen. Tussentijds vonden er ook feedback gesprekken
plaats met een aantal managers. Hiervoor hebben we gebruik gemaakt van vragenlijsten,
waarbij de feedback gesprekken meehielpen om de vragenlijsten op te stellen. Deze
vragenlijsten waren bestemd voor de service managers om vervolgens informatie te
krijgen over de contracten die zij in hun beheer hadden. Met informatie doelen we op de
gegevens van de applicatie, onder andere de leeftijd van de applicatie en de
urenregistraties met de bijbehorende urenposten. De service managers waren de
eindverantwoordelijke voor een bepaald outsourcingcontract. Zo hebben we iedere
eindverantwoordelijke van een contract een verdeelsleutel laten invullen. Met behulp van
deze verdeelsleutel zouden we de gegevens kunnen standaardiseren naar de huidige
normverdeling van de beheeruren. Hiermee konden we deels bepalen op welke ASL
processen (tabel 1.1) de beheeruren gebaseerd waren.
Aangezien het model dat we onderzoeken voornamelijk gebaseerd is op de praktijk en
ervaring, was het ook moeilijk om wetenschappelijke artikelen hierover te vinden. De
interviews waren dan ook van groot belang bij het onderzoeksproces.
© Getronics PinkRoccade 2007
5
Inleiding
1.7 Afbakening
Bij het onderzoek naar de beheerprocessen bij outsourcing hebben we de volgende
afbakening gemaakt:
•
•
Wanneer we het over outsourcing hebben, doelen we specifiek op applicatie
outsourcing.
GPR is de insourcer (leverancier), die applicaties overneemt van externe organisaties.
Binnen het onderzoek zal het woord ‘contract’ veelvuldig aan bod komen. Met
contracten bedoelen we de outsourcingcontracten.
Applicatie, informatiesysteem, software zijn begrippen waar we hetzelfde mee
bedoelen. Het woord informatiesysteem komt overigens vaak terug in de ASL definities
[ASL_W].
Outsourcing bestaat uit verschillende fases en de fase waar wij ons op richten is de
fase waarin twee partijen al een deal met elkaar hebben afgesloten. Verder hebben we
ons gericht op de partij die een applicatie van een ander bedrijf in zijn beheer heeft
genomen.
Wanneer we het hebben over de ‘normverdeling van de beheeruren’ doelen we op de
huidige verdeling van de beheeruren binnen GPR. In de meeste gevallen zullen we
refereren naar tabel 1.1.
ASL is een hulpmiddel voor het beheren, onderhouden en vernieuwen van applicaties.
De normverdeling van beheeruren is grotendeels op ASL gebaseerd, alleen is de
percentuele verdeling hiervan voortgevloeid uit de praktijk en ervaring.
Voor bepaalde definities refereren we ook naar [ASL_W], het gaar hier om een
woordenlijst die opgesteld is door het ASL Foundation. Zij hebben deze begrippen
overigens voor een groot deel van [POLS] en deels van [DELEN1] en [DELEN2]. Indien
we de definities niet beschreven hebben, duiden we dat aan door achter het woord “Zie
Terminologielijst
” te plaatsen. We verwijzen u dan door naar onze terminologielijst.
Met beheeruren doelen we ook op geregistreerde uren voor onderhoud.
6
© Getronics PinkRoccade 2007
•
•
•
•
•
•
•
Inleiding
1.8 Opbouw Verslag
In het onderstaande figuur zien we hoe onze scriptie is opgebouwd. Tevens vormen de
lijnen de relaties met de hoofdstukken.
HOOFDSTUK 1
INLEIDING
HOOFDSTUK 2
OUTSOURCING
(Basis Kennis)
HOOFDSTUK 3
APPLICATIE BEHEER
& ONDERHOUD
(Basis Kennis)
HOOFDSTUK 4
HET STANDAARDISEREN
URENPOSTEN
(Academ isch Niveau)
HOOFDSTUK 5
CASE STUDY
(Praktische Doelstelling)
HOOFDSTUK 6
VALIDATIE
HOOFDSTUK 7
CONCLUSIE
Figuur 1.2 Opbouw Scriptie
Hoofdstuk 1 dient ter inleiding
onderzoeksvragen aan bod komen.
van
het
onderzoek,
waarin
probleemstelling
en
Hoofdstuk 2 en 3 geven antwoord op de vraag wat outsourcing en applicatiebeheer en
onderhoud inhoud. Deze hoofdstukken fungeren als basis kennis voor het vervolg van het
onderzoek. In figuur 1.2 is dit terug te vinden in de blauwe vakjes.
In Hoofdstuk 4 vinden we een model dat aangeeft op welke manier de beheeruren
bijgehouden dienen te worden conform de ASL processen. Verder vertellen we op welke
manier urenposten gestandaardiseerd kunnen worden. In figuur 1.2 is dit terug te vinden
in het paarse vak, waarmee de academische doelstelling van het onderzoek bereikt wordt.
In Hoofdstuk 5 krijgen we schetsen van de huidige situatie (Cases, interviews, gegevens),
waarna we het model uit het vorige hoofdstuk hier op gaan toepassen. In figuur 1.2 is dit
terug te vinden in het grijze vak, waarmee we overigens de praktische doelstelling van het
onderzoek willen bereiken.
In Hoofdstuk 6 vind er een terugkoppeling naar het model plaats, aan de hand van de
verkregen informatie uit Hoofdstuk 5. Het model zal hierdoor aangepast worden.
In Hoofdstuk 7 geven we kort weer antwoord op de hoofd- en deelvragen en zullen er
aanbevelingen staan voor het management van GPR.
© Getronics PinkRoccade 2007
7
Outsourcing
2 Outsourcing
2.1 Inleiding
In dit hoofdstuk geven we antwoord op de vraag wat outsourcing inhoudt. We geven hierin
de verschillende definities en vormen weer van outsourcing, die we in de literatuur hebben
kunnen vinden. Het hele outsourcing traject en de verschillende trends en best practices
ervan zullen besproken worden. Eveneens zullen we outsourcing binnen het onderzoek
plaatsen en de relatie met het volgende hoofdstuk (Hoofdstuk 3) aanduiden.
2.2 Outsourcing definitie
De laatste jaren zien we dat het woord outsourcing steeds vaker in de belangstelling staat
van organisaties, aangezien het steeds populairder begint te worden. Met het woord
outsourcing wordt in het Nederlands vaak uitbesteding mee bedoeld. Zo is er een aantal
jaren geleden een platform opgezet voor outsourcing in Nederland, genaamd ´Platform
Outsourcing Nederland’ [PON]. Verschillende belanghebbende organisaties willen op deze
manier met elkaar in gesprek raken om outsourcing in Nederland verder te
professionaliseren. Er worden verschillende definities gehanteerd voor het woord
outsourcing, waarbij de definities elkaar ook aanvullen. Hieronder zien we twee recente
definities van het woord outsourcing.
Outsourcing (1)
Outsourcing is: 1) het overdragen van bepaalde bedrijfsprocessen en de daarbij horende
bedrijfsmiddelen en medewerkers aan een externe leverancier en vervolgens 2) het
gedurende een bepaald aantal jaren terugontvangen van diensten van die leverancier op
basis van die processen met een resultaatverplichting [DELEN1].
Outsourcing (2)
IT-uitbesteding is het op basis van een meerjarige contract contractuele relatie met een
substantiële waarde uitvoeren van (delen van) de IT-dienstverlening voor het
uitbestedende bedrijf door een of meer externe leveranciers [BEULEN].
Het woord outsourcing kunnen we gebruiken voor de uitbestedende organisatie en voor de
leverancier wordt het begrip insourcing gebruikt. Zo hanteren we voor beide organisaties,
zowel de uitbestedende organisatie als de leverancier, een aparte definitie.
Insourcing
Insourcing is: 1) het overnemen van bepaalde bedrijfsprocessen en de daarbij horende
bedrijfsmiddelen en medewerkers van een bepaalde organisatie en vervolgens 2) het
verlenen van diensten aan die organisatie gedurende een bepaald aantal jaren op basis
van die processen met een resultaatverplichting [DELEN1]
Een simpel voorbeeld van outsourcing is dat een lokale bakker zijn website door een
extern bedrijf in beheer laat nemen. Outtasking, intasking, greenfield insourcing, followupsourcing en back-sourcing zijn in principe andere vormen van sourcing waar een andere
definitie voor geldt(zie terminologielijst). Binnen onze onderzoek gaan we hier niet verder op in
aangezien wij één fase van outsourcing zullen onderzoeken. We zullen voornamelijk de
kant van de leverancier in kaart brengen.
8
© Getronics PinkRoccade 2007
Outsourcing
2.3 Fases outsourcing traject
Outsourcing wordt meestal in verschillende fases verdeeld, om vervolgens het outsourcing
proces beter beheersbaar te maken. De definities van outsourcing in de vorige paragraaf
geven een grof beeld van het outsourcing traject. In het onderstaande tabel 2.1 [DELEN1]
zien we verfijnde modellen die ontwikkeld zijn door de Groot en Lewis, de Looff, Delen e.a.
en Beulen.
Tabel 2.1 Faseringsmodellen voor sourcing
Zo zijn er naast de in de literatuur beschreven faseringsmodellen ook verschillende
adviesorganisaties binnen het PON die een eigen model hebben opgesteld. Voorbeelden
hiervan zijn: Gartner, Morgan Chambers (het Life Cycle Sourcing Framework TM), Quint
Wellington Redwood (het 7-fasen model TM), TPI en VKA [DELEN2]. Onderstaande figuur
2.2 is het model dat ontwikkeld is door PON.
Figuur 2.2 De sourcing life cycle van het PON
Bij de verschillende fases zullen we een korte toelichting geven, die hieronder beschreven
zullen worden [DELEN2].
© Getronics PinkRoccade 2007
9
Outsourcing
Fase 1 (besluitvorming): Fase waarin besloten wordt welke IT-afdeling van een
organisatie in aanmerking komt voor outsourcing en wat de voor- en nadelen daarvan zijn.
Fase 2 (leverancierselectie): De uitbesteder maakt een selectie uit een aantal
mogelijke dienstenleveranciers. Een methode die ze hierbij gebruiken is ISPL (Information
Services Procurement Library), waarbij de methode gericht is op het verwerven van
projecten en services.
Fase 3 (transitie): In deze fase is het doel dat mensen en middelen overgebracht worden
aan de dienstenleverancier.
Fase 4 (dienstverlening): Hierbij gaat het om een continu proces, waarbij de duur van
de dienstverlening afhangt van de gemaakte afspraken.
Fase 5 (contractbeëindiging): Elk contract duurt een aantal jaren en aan het einde van
een contract kunnen uitbestedende organisaties en leveranciers bepalen of ze het contract
gaan verlengen of beëindigen.
2.4 Applicatie outsourcing definitie
In de vorige paragraaf hebben we de definitie van outsourcing en het outsourcing traject
beschreven. Binnen het onderzoek leggen wij de nadruk op applicatie outsourcing.
Hieronder geven we de definitie van ‘applicatie’ zoals deze beschreven is volgens het ASL
Foundation [ASL_F].
Applicatie
Het
geautomatiseerde
gedeelte
van
een
informatiesysteem,
bestaande
uit
applicatieprogrammatuur, applicatiegebonden gegevens, de (fysieke) opslagstructuren
waarin deze gegevens zijn ingebed en de bijbehorende documentatie [ASL_W].
Applicatie outsourcing vindt meestal plaats, wanneer een organisatie zijn applicatie
uitbesteedt aan een externe partij. Onderstaande definitie is afkomstig van
onderzoeksbureau Gartner.
Applicatie Outsourcing
Application outsourcing is a multiyear or annuity contract/relationship involving the
purchase of ongoing application services for managing, enhancing and maintaining custom
or packaged application software in the server/host or desktop platforms [YOUNG].
Gartner geeft vervolgens ook aan dat applicatie outsourcing een brede portfolio van
diensten bevat. Bij deze diensten kan je denken aan applicatie ontwikkeling, integratie,
deployment en management diensten en ook consulting en raadgevende diensten.
Overigens kunnen deze diensten on-site, remote, onshore of offshore (zie Terminologielijst)
geleverd worden.
10
© Getronics PinkRoccade 2007
Outsourcing
2.5 Trends applicatie outsourcing
Applicatie outsourcing komt tegenwoordig steeds vaker voor. Organisaties laten hun
applicaties door andere bedrijven in beheer en onderhoud nemen, zodat zij zich weer
kunnen concentreren op hun eigen kernactiviteiten. Op dit moment is er veel vraag naar
software gerelateerde diensten. Volgens het Forrester onderzoek zijn er in 2005 in totaal
911 Noord Amerikaanse en Europese software en service organisaties onderzocht voor hun
plannen voor het komende jaar [ROSS]. We zien hieronder een overzicht van de
uitkomsten van het onderzoek:
•
•
•
•
Beheer en maatwerk voor de klant zijn de meest uitbesteedde activiteiten.
Maatwerk voor de klant behoort ook tot de toplijst van projecten.
Nieuwe functionaliteiten bouwen in een applicatie krijgt de voorkeur in vergelijking
tot modernisatie.
Interesse in offshore blijft stabiel.
Verder zien we dat er ook een verschil is tussen applicatie outsourcing in Noord-Amerika
en Europa. We zien dat Noord-Amerika op het gebied van applicatie outsourcing voorloopt
op Europa. In de financiële sector zien we dat Noord Amerikaanse banken meer naar een
end-to-end oplossing op zoek zijn. Zo hebben ze meer de neiging om hun
bedrijfsprocessen volledig te outsourcen. Europese banken doen dit liever stap voor stap
en willen liever de kernactiviteiten van applicaties alsnog binnen de organisatie houden
[HOPPER].
2.6 Best practices
Om applicatie outsourcing zo succesvol mogelijk te laten verlopen, dienen organisaties
goede voorbereidingen te treffen. Op deze manier kunnen valkuilen bij de transitie fase
voorkomen worden. Zo zijn er een aantal best practices die tijdens de transitie in acht
genomen kunnen worden bij de uitbestedende organisatie [MART1]:
•
•
•
•
•
Overeenstemming vinden tussen missie en business goals – Het is belangrijk om
alle vervolg activiteiten mee te nemen in de missie.
De scope dient duidelijk afgebakend te worden – Aangezien de scope tussentijds
kan veranderen is het van belang om van te voren duidelijk aan te geven wat wel
binnen de scope valt en wat niet.
Plan voor behoud van belangrijk personeel – Het is belangrijk om bij de klantzijde
ook personeel te hebben met hoge bedrijfskennis. Bij een outsourcing deal kan de
klant bezuinigen op arbeidskosten, alleen is het nuttig om nog mensen te houden
die enige domein kennis hebben.
Vastleggen van de kosten en kwaliteit baseline – Een exact beeld hebben van de
kosten van beheer van een applicatie kan organisaties afschrikken. Ze moeten
duidelijk de voordelen van outsourcing in kaart brengen, om in te zien dat ze
uiteindelijk geld kunnen besparen.
Breng de requirements in overeenstemming met de leverancierstype – Klanten
moeten bij de keuze van een leverancier duidelijk op de hoogte zijn van de keuzes
die er zijn. Hierna moeten ze bepalen of de leverancier binnen hun scope valt.
© Getronics PinkRoccade 2007
11
Outsourcing
2.7 Applicatie outsourcing binnen het onderzoek
Doelstelling van ons onderzoek is om het betrokken management een hulpmiddel te
bieden die er voor moet zorgen dat ze een overzicht kunnen krijgen van de verschillende
applicatie outsourcing contracten. Applicaties worden in dit geval overgenomen door de
leveranciers. De leverancier zorgt vervolgens voor beheer en onderhoud van de applicatie.
Voor ieder contract worden vervolgens weer verschillende uren geadministreerd, waardoor
het voor het betrokken management moeilijk is om de verschillende uren per contract te
beoordelen.
We doelen voornamelijk op de uren die voor beheer en onderhoud van een applicatie
geregistreerd worden. Beheer en onderhoud zullen in het volgende hoofdstuk toegelicht
worden.
2.8 CMMI binnen de organisatie
In deze paragraaf gaan we in op CMMI (Capability Maturity Model Integration) binnen de
organisatie, waarin we de verschillende niveaus ervan zullen bespreken. CMMI geeft het
software ontwikkelingsniveau van een organisatie weer. Binnen het model maken we
onderscheid tussen 5 CMMI niveaus [CMMI]:
1.
2.
3.
4.
5.
Initial: De processen binnen dit niveau zijn meestal ad hoc en chaotisch.
Organisaties werken dan in een minder stabiele omgeving, waarbij succes van
projecten sterk afhankelijk is van de competenties van de werknemers.
Managed: Hierin wordt basis projectmanagement gebruikt die herhaalbaar is voor
andere projecten om tijd en kosten te meten. Zo wordt er gebruik gemaakt van
kennis dat al is opgedaan in eerdere projecten.
Defined: Binnen dit niveau zijn de belangrijkste processen gestandaardiseerd.
Deze standaard processen worden gebruikt om consistentie binnen de organisatie
te bewerkstelligen. Het grote verschil tussen het 2e niveau is de scope van
standaards, proces beschrijvingen en procedures, waarbij deze zaken allemaal
duidelijk beschreven staan.
Quantitatively Managed: Hierin worden precieze metingen getroffen, waarbij de
kwaliteit van het ontwikkelproces wordt gemeten en eventueel bijgestuurd. Binnen
dit niveau wordt de prestatie van de processen gecontroleerd d.m.v. kwantitatieve
technieken, waarbij de kwantiteit voorspelbaar is.
Optimizing: Niveau 5 concentreert zich op het continu verbeteren van de
prestatie van de processen door zowel waarde verhogende als innovatieve
verbeteringstechnologieën te gebruiken. Optimizing zorgt ervoor dat er continu
fijnafstemming plaatsvindt.
Om als organisatie naar een hoger ontwikkelingsproces te werken, dienen organisaties te
gaan standaardiseren. Niveau 3 is zou dan een belangrijke stap kunnen zijn in dit proces,
wat op zich een serieuze investering met zich zou meebrengen. Deze investering zou je
altijd terug kunnen winnen, omdat dit voorspelbare resultaten zou opleveren. Vanaf niveau
3 ben je als organisatie bezig met het standaardiseren van je processen en hoe hoger het
niveau des te hoger het software ontwikkelingsniveau. Zo streeft de Sourcing en Transition
afdeling binnen GPR ook naar niveau 3, defined. Om dit niveau te bereiken moeten
organisaties een uniforme manier van urenregistraties gebruiken. Indien elk contract de
urenposten anders interpreteren, zullen organisaties niet verder komen dan CMMI niveau
1. We gaan ons dan ook focussen op het standaardiseren van de beheer en onderhoud
processen.
12
© Getronics PinkRoccade 2007
Applicatie Beheer & Onderhoud
3 Applicatie Beheer & Onderhoud
3.1 Inleiding
In dit hoofdstuk geven we antwoord op de vraag wat applicatiebeheer en onderhoud
inhoud. Verder komt de relatie tussen outsourcing en applicatiebeheer en onderhoud
binnen het onderzoek aan bod. ASL (Application Services Library) is een hulpmiddel dat
gebruikt kan worden bij applicatiebeheer en onderhoud, waarbij we tevens ook de kleinste
unit per ASL proces zullen aangeven. We zullen ook kijken naar een aantal factoren, die
mogelijk ook invloed zouden hebben op beheer en onderhoud van applicaties. Hierbij
kunnen we denken aan de invloed van migratie, programmeertalen en frameworks op
beheer en onderhoud weergeven.
3.2 Definitie applicatiebeheer en onderhoud
Indien applicaties worden overgenomen door een leverancier, dan zorgt de leverancier
voor de beheer en onderhoud van de applicatie. Beheer en onderhoud vindt na de
overname plaats, wanneer het SLA contract is getekend. We zitten dan in fase 4 van de
sourcing life cycle (figuur 2.2), “de dienstverlening”.
Voor de definities van Software Maintenance (Software Beheer) kunnen we de definitie van
IEEE raadplegen:
Software Maintenance (Software Beheer)
The modification of a software product after delivery to correct faults, to improve
performance or other attributes or to adapt the product to a modified environment [IEEE].
Hieronder volgen de definities van het ASL Foundation voor beheer, applicatiebeheer en
onderhoud.
Beheer
Geheel van taken, verantwoordelijkheden en activiteiten dat noodzakelijk is om objecten in
zodanige staat te houden, dat deze blijven voldoen aan de vastgestelde eisen en behoeften
van de eigenaren ervan [ASL_W].
Applicatiebeheer
Geheel van taken, verantwoordelijkheden en activiteiten dat er toe dient om applicaties in
zodanige staat te brengen en houden, dat deze voldoen aan de vastgestelde eisen en
behoeften van de eigenaren ervan gedurende de gehele levensduur van de
bedrijfsprocessen die door de applicaties ondersteund worden [ASL_W].
Onderhoud
Het aanbrengen van wijzigingen in een informatie systeem, ten einde fouten te elimineren
of gewenste functionaliteit toe te voegen.
Toelichting: In grote lijnen kan onderhoud worden opgesplitst in:
- Niet planbaar onderhoud: Aanpassingen van een informatiesysteem als reactie op een
niet voorspelde en geplande gebeurtenis.
- Planbaar onderhoud: Aanpassingen van een informatiesysteem op basis van vooraf
overeengekomen afspraken. [ASL_W].
© Getronics PinkRoccade 2007
13
Applicatie Beheer & Onderhoud
De definitie die voor software beheer wordt gegeven bij de IEEE komt meer overeen met
de definitie voor onderhoud van het ASL Foundation. Zo zien we dat er verschillende
definities worden gebruikt, maar binnen ons onderzoek gaan we de definities van het ASL
Foundation toepassen. Voor het onderzoek is het ook van belang dat we de juiste definities
van beheer en onderhoud zullen opnoemen, aangezien er in de praktijk hier nog al
verwarring over bestaat.
3.3 Verschil tussen beheer & onderhoud
In de voorgaande hoofdstukken van het onderzoek hebben we al meerdere malen het
woord ASL gebruikt, waar Application Services Library voor staat.
ASL (Application Services Library)
Een public-domainstandaard voor het professionaliseren van applicatiebeheer, bestaande
uit een framework, best practices en een groeimodel [ASL_W], [POLS].
Het doel van ASL is om uiteindelijk het applicatiebeheer te professionaliseren en
applicatiebeheer heeft de volgende boodschappen [POLS]:
•
Het opereert niet alleen en vormt de schakel tussen functioneel beheer (de
opdrachtgever en eigenaar van het informatiesysteem) en technisch beheer (het
rekencentrum).
•
Aan applicatiebeheer worden eisen gesteld als uniformiteit, stuurbaarheid,
betrouwbaarheid, inzichtelijkheid en een toekomstgerichte blik.
•
ASL geeft aan deze boodschappen invulling door het serviceteam, service levels en
daaraan
gekoppelde
klanteenheden,
de
public-domaingedachte
en
toekomstgerichte
processen
aangaande
de
applicaties
en
de
applicatiebeheerorganisatie.
Binnen ASL is er maar 1 aanspreekpunt, het serviceteam (ST), waarmee zij een
brugfunctie vervullen tussen de gebruikersorganisatie en de automatiseerder. Zo worden
er afspraken gemaakt tussen de organisaties over ontwikkeling, gebruik en exploitatie van
de dienstverlening. De afspraken die gemaakt worden, worden in een SLA (Service Level
Agreement) vastgelegd.
SLA (Service Level Agreement)
Een SLA definieert de verplichtingen en verantwoordelijkheden van aanbieder en afnemer
van de diensten, waarbij het uitgangspunt is dat optimaal invulling wordt gegeven aan de
huidige en toekomstige behoeften van de afnemer, tegen reële kosten [POLS].
Naast een SLA contract wordt er ook een DAP (Dossier Afspraken en Procedures)
vastgelegd. In een DAP document zijn de afspraken en procedures op het grensgebied
tussen klant en ICT-leverancier vastgelegd [ASL_W]. SLA en DAP dienen dan als onderdeel
van het beheer en onderhoud contract.
14
© Getronics PinkRoccade 2007
Applicatie Beheer & Onderhoud
Het model dat we gaan onderzoeken is grotendeels gebaseerd op het ASL Framework
(figuur 3.1) en het verschil tussen beheer en onderhoud kunnen we hiermee verklaren.
Figuur 3.1 ASL Framework
Het ASL framework bestaat uit drie verschillende niveaus, richtinggevend, sturend en
uitvoerend. De richting gevende processen bestaan vervolgens uit ACM (Applications
Cycle Management) en OCM (Organization Cycle Management).
ACM (Applications Cycle Management)
ACM kent als doelstelling het vormgeven van een langetermijnstrategie voor de
verschillende objecten in en het geheel van de informatievoorziening van een organisatie,
in relatie met het langetermijnbeleid van deze organisatie [POLS].
OCM (Organization Cycle Management)
OCM kent als doelstelling het ervoor zorgdragen dat invulling gegeven wordt aan het beleid
en de toekomst van de serviceorganisatie. Hierin wordt de toekomst van de
serviceorganisatie (applicatiebeheerorganisatie) uitgestippeld en vertaald naar een beleid
[POLS].
De sturende processen hebben als doelstelling het bewaken dat de bestaande
activiteiten conform doelstellingen, afspraken en gekozen strategie worden uitgevoerd. Een
aantal van deze taken zijn: PLANNING AND CONTROL, COST MANAGEMENT, QUALITY
MANAGEMENT EN SERVICE LEVEL MANAGEMENT (zie terminologielijst).
De beheer processen zullen we uitgebreid toelichten, aangezien we onze focus daarop
gaan richten. De doelstelling achter de beheerprocessen is om ervoor zorg te dragen dat
de applicaties in gebruik optimaal worden ingezet ter ondersteuning van het bedrijfsproces
met een minimum aan middelen en verstoringen op het uitvoerende niveau [POLS]. Het
verschil tussen en beheer en onderhoud ligt voornamelijk in de activiteiten. In figuur 3.2
zien we wat de activiteiten zijn, die binnen beheer en onderhoud uitgevoerd worden.
© Getronics PinkRoccade 2007
15
Applicatie Beheer & Onderhoud
Change
Management
Incident
Management
Continuity
Management
Design
Availability
Management
Impact
Analysis
Realization
Uitvoerend
Capacity
Management
Configuratio
n
Management
Beheer
Software
Control
and
Distribution
Verbindende
Processen
Implementation
Testing
Onderhoud/
vernieuwing
Figuur 3.2 ASL Framework (Uitvoerend)
Hieronder zullen we de verschillende ASL processen (Incident Management, Configuration
Management, Availability Management, Capacity Management, Continuity Management,
Impact Analysis, Design, Realization, Testing, Implementation, Change Management,
Software Control en Distribution) verder toelichten met de metrieken en de definities
[ASL_W], [POLS] ervan. Hieronder geven we de definities van de ASL processen, die
belangrijk zijn voor het vervolg van het onderzoek.
•
BEHEER
o Incident Management (Incidentbeheer)
Het proces, dat de primaire afhandeling van vragen, wensen en
verstoringen verzorgt, inclusief de communicatie van en naar
gebruikers/functioneel beheer.
o Configuration Management (Configuratiebeheer)
Het proces rondom het registreren en bijhouden van informatie over
het gebruik van de versies van applicatieobjecten(zie terminologielijst).
o Availability Management (Beschikbaarheidsbeheer)
Het proces dat de beschikbaarheid en betrouwbaarheid van diensten
en applicatieobjecten verzorgt, bewaakt en waarborgt.
o Capacity Management (Capaciteitsbeheer)
Het
proces
dat
zorgdraagt
voor
de
optimale inzet
van
(applicatiegerelateerde) middelen, d.w.z. op de juiste plaats, op het
juiste moment, in de juiste hoeveelheden en tegen gerechtvaardigde
kosten.
o Continuity Management (Continuïteitsbeheer)
Het proces waarmee maatregelen getroffen worden om de continuïteit
van de uitvoering en ondersteuning van de informatievoorziening door
middel van informatiesystemen op langere termijn te verzorgen.
•
ONDERHOUD
o Impact Analysis (Impactanalyse)
Het proces waarin in kaart wordt gebracht wat de gevolgen zijn van
voorgestelde wijzigingen, op basis waarvan wordt bepaald wat de
beste globale oplossingsrichting is om de wijzigingen te realiseren.
o Design (Ontwerp)
Het proces waarin de gebruikersspecificaties zodanig worden
uitgewerkt en vastgelegd, in een functioneel ontwerp, dat deze daarna
op een eenduidige wijze kunnen worden gerealiseerd en getest.
o Realization (Realisatie)
Het proces waarin een functioneel ontwerp wordt vertaald in een
technisch ontwerp en vervolgens naar programmatuur die een unittest
(zie terminologielijst)
succesvol doorloopt.
16
© Getronics PinkRoccade 2007
Applicatie Beheer & Onderhoud
o
o
Testing (Testen)
Het proces dat de activiteiten bevat om vast te stellen of datgene wat
ontworpen is, ook inderdaad gerealiseerd is.
Implementation (Implementatie)
Het proces dat alle activiteiten omvat die gedaan moeten worden om
gerealiseerde wijzigingsopdrachten te effectueren voor gebruik.
In tabel 1.1 worden ook een aantal begrippen opgenoemd die vallen onder onderhoud. Het
gaat om de begrippen correctief, preventief, perfectief en adaptief onderhoud. In de
literatuur zijn we verschillende definities tegengekomen hierover. Het is dus van groot
belang dat we deze definities eerst op orde moeten hebben, om onenigheid hierover te
voorkomen. We zullen in de rechter kolom van tabel 1.1 de definities geven die het beste
binnen ons onderzoek passen.
Onderhoud:
Correctief
Definities uit de literatuur
deals with the repair of faults found
[NIESSINK].
Preventief
includes technical upgrades and restructuring of software code [KEMERER]
Perfectief
mainly deals with accommodating new or
changed user requirements. It concerns
functional enhancements to the system
[NIESSINK].
Changes in the software environment
[BENNET].
Adaptief
Definities binnen ons onderzoek
Het herstellen van afwijkingen in
componenten van het informatiesysteem
[ASL_W].
Het corrigeren van componenten van het
informatiesysteem, zonder aanleiding in de
vorm van een probleemrapport. Met als
doel (a) het voorkomen van toekomstige
problemen, of (b) het verhogen van de
onderhoudbaarheid [ASL_W].
Het aanpassen van een component van het
informatiesysteem aan veranderde
kwaliteitseisen van de gebruikers [ASL_W].
Het aanpassen van één of meer delen van
het informatiesysteem als gevolg van
wijzigingen in de omgeving van die delen
[ASL_W].
Tabel 3.3 Definities Onderhoud
•
VERBINDENDE PROCESSEN
o Change Management (Wijzigingsbeheer)
Het proces dat sturing geeft aan het inventariseren, prioriteren,
initiëren, evalueren en bijsturen van de gewenste veranderingen aan
een applicatie.
o Software Control en Distribution (Programmabeheer en distributie)
Het proces dat de activiteiten bevat rond de beheersing en distributie
van de (operationele) applicatieobjecten naar de verschillende
ontwikkel- en testomgevingen en naar productie.
Change Management en Software Control en Distribution zijn overigens de ASL processen,
die zowel onder beheer als onderhoud vallen. Dit is ook de reden dat deze twee
componenten de verbindende processen vormen binnen het ASL Framework.
© Getronics PinkRoccade 2007
17
Applicatie Beheer & Onderhoud
3.4 Metriek (Measurement)
Zoals we al in de inleiding van dit hoofdstuk hadden aangegeven, zouden we de kleinste
unit per ASL proces weergeven. De kleinste unit kunnen we het beste weergeven aan de
hand van metrieken. Metrieken zijn ook wel maatsoorten/meeteenheden en worden ook
wel measurements genoemd in het Engels. Om wat meer grip te krijgen op de ASL
processen zullen we aan de hand van metrieken een aantal voorbeelden opsommen
[BROOK]. We kunnen hierdoor zien welke meeteenheden er toegepast kunnen worden op
de ASL processen.
Measurement is the process by which numbers or symbols are assigned to attributes of
entities in the real world in such a way as to characterize the attributes by clearly defined
rules [FENTON].
Aan de hand van metrieken kunnen we vervolgens afleiden waarop urenregistraties van
werknemers van de organisatie op gedeclareerd kunnen worden. We zullen hieronder een
aantal voorbeelden opnoemen die de kleinste unit vormen per ASL proces. Naast de
metrieken zullen we voor enkele ASL processen de activiteiten [POLS] opnoemen,
aangezien niet alle ASL processen terug te vinden zijn in [BROOK]. De ASL processen zijn
overigens ook gegroepeerd zoals dat te zien was in figuur 3.2.
BEHEER
Incident
Management
Configuration
Management
Availability
Management
Capacity
Management
Continuity
Management
18
•
•
•
•
Percentage van de incidenten die door de 1e lijn opgelost zijn.
Gemiddelde call time zonder escalatie.
Percentage van de incidenten die incorrect toebedeeld zijn.
Percentage van de incidenten die binnen de afgesproken tijd
opgelost (prioriteit van een incident, afhankelijk van de gemaakte
afspraak met de klant)
[BROOK]
•
Aantal niet gebruikte licenties.
•
Aantal ongeoorloofde configuraties.
•
Aantal incidenten van mislukte changes veroorzaakt door verkeerd
gedocumenteerde CIs (Configuration Items).
•
Percentage van de foutieve CIs.
[BROOK]
•
Onbeschikbaarheid van de diensten.
•
Tijd voor het ontdekken van de incident.
•
Tijd voor het antwoorden (response tijd).
•
Herstel tijd van een incident.
[BROOK]
•
Aantal SLA afspraken doorbroken door slechte prestaties van de
dienst.
•
Aantal SLA afspraken doorbroken door slechte componenten.
•
Percentage van de over-capaciteit van IT (Information Technology).
[BROOK]
•
Beveiliging.
•
Backup en herstel (recovery).
[POLS]
© Getronics PinkRoccade 2007
Applicatie Beheer & Onderhoud
ONDERHOUD
Impact Analysis •
In kaart brengen van een wijziging.
•
Inschatten van de verandering.
•
Inschatten van de consequenties.
[POLS]
Design
•
Nadere uitwerking van de vraagstelling.
•
Bepaal de oplossingsrichting(en).
•
Werk oplossingsrichting uit.
[POLS]
Realization
•
Ontwerp technische oplossing.
•
Realisatie van gewenste opzet.
•
Testen van de programma’s.
[POLS]
Testing
•
Technische systeemset.
•
Functionele systeemset.
•
Besturing.
[POLS]
Implementation •
Voorbereiding van de exploitatie.
•
Voorbereiding gebruikersorganisatie.
•
Afronding van de opdracht.
[POLS]
VERBINDENDE PROCESSEN
Change
Management
Software
Control en
Distribution
•
Percentage van mislukte changes.
•
Change backlog.
•
Outages tijdens changes.
[BROOK]
•
Uitgifte van objecten
•
Informatieverstrekking naar onderhoudsproces
•
Overzetten naar productieomgeving
[POLS]
De kleinste units per ASL proces hebben we op deze manier besproken. Omdat deze
begrippen veelvuldig naar voren zullen komen in het vervolg van het onderzoek, vonden
wij het belangrijk dat we naast de begrippen ook de metrieken en activiteiten te
bespreken.
© Getronics PinkRoccade 2007
19
Applicatie Beheer & Onderhoud
3.5 Urenadministratie
Indien het beheer en onderhoud van een applicatie is overgenomen door de insourcer, dan
is het de verantwoordelijkheid van de insourcer om de applicatie te beheren en te
onderhouden. De insourcer zal in de meeste gevallen zijn beheeruren goed kunnen
onderhouden. De activiteiten en metrieken uit paragraaf 3.3 zijn voorbeelden waarop
medewerkers hun beheer- en onderhouduren op kunnen verantwoorden. In eerste
instantie gaan we er vanuit dat de uren van de verschillende contracten op dezelfde
manier geregistreerd worden. In de praktijk kan het voorkomen dat er op verschillende
manieren uren geregistreerd worden.
Er zijn een aantal redenen op te noemen voor de diversiteit aan urenadministratie volgens
GPR:
•
•
•
•
•
Uren worden in de praktijk soms gerelateerd aan de factuur. Zo zijn er vaste
afspraken gemaakt over het werk, waarbij er uren begroot worden voor bepaalde
taken. We willen daarmee zeggen dat medewerkers sneller geneigd zijn om uren te
boeken aan de hand van de begrote uren op de factuur i.p.v. aan het werkelijk
gedane werk.
Soms worden er nauwelijks taken uitgevoerd en komen er dus taken voor waar
geen uren op geboekt worden.
Uren worden niet altijd even nauwkeurig bijgehouden door de medewerkers. Het
kan voorkomen dat medewerkers pas na 2 weken hun uren registreren, waardoor
ze niet meer exact weten welke specifieke taken ze hebben uitgevoerd.
Uren zijn voor een groot deel afhankelijk van het systeem en de eisen van de
klant. Zo kan het voorkomen dat een klant weinig wijzigingen wilt laten
doorvoeren.
Uren die door werknemers geregistreerd worden voor beheer en onderhoud zijn
soms applicatie afhankelijk.
Binnen het onderzoek gaan we alle geregistreerde uren verzamelen en kijken bij welke
ASL processen deze horen. Deze geregistreerde uren zijn opgesteld als gevolg van beheer
en onderhoud van applicaties. Wat we overigens hierboven beschreven hebben is
voornamelijk gebaseerd op de praktijk. In de volgende paragraaf gaan we kijken wat de
literatuur ons te bieden heeft m.b.t. factoren die invloed zouden kunnen hebben op de
beheer en onderhoud uren.
20
© Getronics PinkRoccade 2007
Applicatie Beheer & Onderhoud
3.6 Factoren applicaties
3.6.1 Beïnvloedbare factoren
Bij beheer en onderhoud van applicaties zijn er verschillende factoren die invloed kunnen
hebben op de applicaties. Deze factoren hebben dan weer invloed op de urenregistraties
van de medewerkers. Zo kunnen deze factoren voor eventueel extra werk zorgen, dat op
zijn beurt weer kan leiden tot extra urenregistraties. Het kan ook zo zijn dat bepaalde
factoren zorgen voor minder werk en dan zullen er dus minder uren worden geregistreerd.
Volgens [BHATT] zijn de factoren in drie verschillende gebieden te verdelen, (1)
Demografisch, (2) Objectieve Informatie en (3) Subjectieve Informatie. Deze gebieden zijn
overigens gebruikt voor een onderzoek naar beïnvloedbare factoren in ge-outsourcede
software beheer.
(1) Verzamelde gegevens over de persoon: geslacht, leeftijd, ervaring in de IT, ervaring
met beheer en onderhoud projecten. Met persoon doelen we op een medewerker van de
leverancier.
(2) De volgende objectieve parameters hebben ook invloed op beheer en onderhoud:
o Grootte van het systeem [CHAPIN]
o Leeftijd van het systeem [CHAPIN]
o Aantal eindgebruikers
o Ervaring van het project team
o Technologie (programmeertaal)
o Support uren
o Aantal tickets (incidenten die gemeld zijn)
o Aantal Change Requests (zie terminologielijst) (CRs)
(3) De subjectieve informatie bestaat overigens uit meer dan 60 verschillende factoren, die
in 4 groepen zijn verdeeld. Verder geven we per groep 2 voorbeelden, voor meer
voorbeelden kunnen we u doorverwijzen naar het artikel van [BHATT].
o Systeem baseline (B)
•
Complexiteit van de code
•
Stabiliteit van het systeem
o Customer Attitude (A)
•
Ervaring van de IT team van de klant
•
Stabiliteit van de IT team van de klant
o Maintenance Team (T)
•
Hoe eenvoudig is het om met de klant te communiceren
•
Beschikbaarheid van experts binnen de Beheer- en onderhoudteams
o Organisatorisch klimaat (C)
•
Druk op de werkvloer
•
Training mogelijkheden
Overigens bleek uit het onderzoek dat deze groepen (B, A, T en C) onderling samenhang
hebben, waarbij ze invloed op elkaar en op het Software Beheer Inspanning (E) hebben.
Hiermee bedoelen dat een verhoging van de ene groep kan leiden tot verhoging van de
andere groep. Het resultaat van het onderzoek van [BHATT] hebben we weergegeven in
tabel 3.4. We vertellen hierin alleen dat sommige factoren invloed op elkaar kunnen
hebben.
Relaties
B
A
C
T
B
Y
Y
A
Y
Y
C
Y
Y
Y
T
Y
Y
Y
-
E
Y
Y
Y
Y
Tabel 3.4 Relaties Subjectieve Informatie
© Getronics PinkRoccade 2007
21
Applicatie Beheer & Onderhoud
Deze factoren kunnen overigens gebruikt worden in een vragenlijst, dat bestemd is voor
de service manager. Ze kunnen ook weer van pas komen tijdens de validatie van de
normverdeling beheeruren, om eventuele afwijkingen en spreidingen tussen beheeruren
van contracten te kunnen verklaren. Dit zal overigens in hoofdstuk 6 uitgebreid aan bod
komen.
3.6.2 Bepalende factoren
Sommige factoren binnen applicatie beheer en onderhoud zijn voorspelbaar. Zo beweert
[KEMERER] dat er patronen terug te vinden zijn in het beheer en onderhoudswerk. Er zijn
verschillende karakteristieken van software modules (een applicatie bestaat uit een
collectie software modules), die geassocieerd worden aan deze patronen. [KEMERER] heeft
hier grondig onderzoek naar gedaan en zijn uitkomsten hieronder terug te vinden:
•
Functionaliteit
o Software modules in strategische systemen zullen vaker onderhouden
worden dan software modules in non-strategische systemen.
•
Development practice (Ontwikkeling uitvoering)
o Software modules waarbij de code gegenereerd is, zal minder vaak
gerepareerd worden dan software modules waarbij de code handmatig is
geschreven.
•
Software complexiteit
o Software modules met een hoge beslissingscomplexiteit zullen vaker
gerepareerd
worden
dan
software
modules
met
een
lage
beslissingscomplexiteit.
•
Controle variabele: leeftijd
o Oude software modules zullen vaker onderhouden worden dan nieuwere
software modules. Het kan voorkomen dat er alleen in het eerste jaar over
het algemeen meer wordt onderhouden. Dit zou dan de uitspraak van
[KEMERER] weer tegenspreken.
o Oude software modules zullen vaker gerepareerd worden dan nieuwere
software modules.
o Oude software modules zullen vaker preventief onderhouden worden dan
nieuwere software modules.
De definitie van [KEMERER] over preventief onderhoud luidt:
preventive maintenance includes technical upgrades and restructuring of software code.
•
Controle variabele: grootte
De grootte van een applicatie heeft te maken met het aantal regels code (LOC, zie sub
paragraaf 3.6.3 voor de definitie) in een applicatie. Het gaat niet zozeer om de fysieke
grootte, maar om het aantal regels code.
o Grotere software modules zullen vaker onderhouden worden dan kleinere
software modules.
o Grotere software modules zullen vaker gerepareerd worden dan kleinere
software modules.
o Grotere software modules zullen vaker preventief onderhouden worden
dan kleinere software modules.
Aan de hand van deze bepalende factoren, kunnen we tijdens de validatie van het model
afwijkingen en spreidingen voorspellen. Op deze manier kunnen we zien dat zaken als
functionaliteit, development practice, software complexiteit, controle variabelen: leeftijd en
grootte tot een voorspelling van meer of minder onderhoud kan leiden.
22
© Getronics PinkRoccade 2007
Applicatie Beheer & Onderhoud
3.6.3 Grootte applicatie
In de vorige paragraaf hebben we veelvuldig gesproken over de grootte van een applicatie.
Indien men de grootte van een applicatie weet, kunnen de beheerders en onderhouders
schattingen maken. Deze schattingen kunnen te maken hebben met; - aantal mensen die
er ingezet op moeten worden, - de onderhoudskosten en - de tijd die je nodig hebt voor
het project [MUSTACEVIC]. De grootte van een applicatie kan bepaald worden aan de hand
van metingen en voor het meten zijn er weer verschillende methodieken. We hebben de
volgende definities opgezocht:
•
Lines of Code (LOC)
o Definitie: A line of code is any line of program text that is not a comment
or blank line regardless of the number of statements or fragments of
statements on the line [AGGARWAL].
•
Het gaat hier om de makkelijkste manier van tellen, alleen kan je
niet vaststellen of je fysieke of logische regels moet gebruiken.
Het is niet duidelijk of je commentaar en lege regels ook als LOC
kan beschouwen. Ook op de vraag “Wat voor invloed hebben
programmeertalen op de grootte van een applicatie” heeft de LOC
geen directe antwoord op.
•
Functiepuntenmetriek
o Definitie: function points measure the functionality from the users’ point of
view [ALBRECHT].
•
Het voordeel hierbij is dat de grootte onafhankelijk is van de
techniek die hiervoor gebruikt is. Ze zijn voornamelijk gebaseerd
op de externe beeld die systeem gebruikers hebben van het
systeem [AGGARWAL]. Deze manier van tellen wordt het meest
gebruikt en is gebaseerd op de functies die voor de eindgebruikers
bestemd zijn.
•
Backfiring
o Bij backfiring worden de LOC en het aantal functiepuntenmetriek met
elkaar gekoppeld [JONES_1].
•
Het gaat hier om een simpele manier van schatten, door middel
van een verhoudingsgetal (functiepunten/LOC) kunnen we achter
het aantal functiepunten komen. Het blijkt ook dat deze manier
van tellen niet altijd even nauwkeurig is [MUSTECEVIC]. Het
onderzoek is overigens op kleinere schaal uitgevoerd.
Binnen ons onderzoek kunnen we de bovenstaande gegevens meenemen voor het
toelichten van ons model. De grootte van een applicatie kan op verschillende manieren
geteld worden, maar de meest gebruikte manier is de functiepuntenmetriek. Zo heb je de
twee meest grote organisaties die zich hiermee bezighouden, International Function Point
Users Group (IFPUG) en Nederlandse Software Metrieken Gebruikers Associatie (NESMA).
© Getronics PinkRoccade 2007
23
Applicatie Beheer & Onderhoud
3.6.4 Migratie
In deze paragraaf zullen we de kant van migratie nader bespreken. Het is belangrijk om te
onderzoeken wat voor effect migratie heeft op de beheer & onderhoud van een applicatie.
Het merendeel van de huidige applicaties zijn meer dan 10 jaar oud en sommige
applicaties zijn zelfs ouder dan 25 jaar. Het beheren en onderhouden van legacy systemen
wordt elk jaar moeilijker, doordat upgrades de originele structuur van de applicaties
vervagen [JONES_2].
Legacy syteem
A legacy system is a large system delivering significant business value today from a
substantial pre-investment in hardware and software that may be many years old.
Characteristically, it will have a long maintenance trail. It is therefore, by definition, a
successful system and is likely to be one that is, in its own terms, well engineered. It is
(also) a business-critical system that has an architecture that makes it insufficiently
flexible to meet the challenge of anticipated future change requirements [O’CALLAGHAN].
Legacy systemen kunnen vervolgens zorgen voor meer beheer en onderhoud, wat op zijn
beurt zal leiden tot meer kosten. Migratie van de applicatie zou dan een optie kunnen zijn
om kosten te besparen.
Migratie
Migratie bestaat uit het proces en de gehanteerde technieken en hulpmiddelen om
bestaande software systemen te vervangen door (nieuwe) systemen die voldoen aan
nieuwe wensen en/of makkelijker onderhoudbaar zijn [MAAT].
Volgens [MOSLEY] kunnen we de volgende lessen leren voordat we migreren: Migratie
moet plaatsvinden om een concurrerend voordeel te handhaven, migratie moet
plaatsvinden om veroudering van de applicatie te voorkomen en de kosten voor migratie
zijn zullen hoger uitvallen dan men verwacht, alleen zullen deze kosten terugverdiend
worden door hergebruik van de applicatie.
Uit bovenstaande kunnen we helaas niet concluderen wat de exacte invloed van migratie is
op beheer en onderhoud. Hooguit kunnen we zeggen dat migratie wordt ingezet, wanneer
een applicatie verouderd is en daardoor moeilijker beheerbaar en onderhoudbaar wordt.
3.6.5 Programmeertaal & Frameworks
Een insourcer van applicaties zal meerdere applicaties in zijn beheer hebben, waarbij elk
applicatie in een andere programmeertaal, framework of een combinatie van deze twee
geschreven zal zijn.
Bij een programmeertaal gaat het om (voor)geschreven code die door de computer
begrepen moet worden, om vervolgens de code uit te voeren. Verschillende niveaus van
programmeertalen, worden op basis van statements het aantal LOC’s per functiepunt
bepaald. Hieronder vinden we de verschillende niveaus met een aantal voorbeelden van
programmeertalen per niveau [JONES_2]:
High level language: moderne programmeertaal die minder dan 50 LOC’s nodig heeft om
1 functiepunt te coderen. Voorbeelden: Smalltalk, Eiffel en Objective C.
Low level language: programmeertaal die meer dan 100 LOC’s nodig heeft om 1
functiepunt te coderen. Voorbeelden: C, Fortran en Cobol. Bij assembleer talen heb je zelfs
meer dan 200 tot 300 LOC’s nodig om 1 functiepunt te coderen.
Mid level language: programmeertaal die grofweg 70 LOC’s nodig heeft om 1 functiepunt
te coderen. Voorbeelden: Ada83, PL/I en Pascal.
24
© Getronics PinkRoccade 2007
Applicatie Beheer & Onderhoud
Verder geeft [JONES_2] aan dat het verschil in beheer en onderhoud voornamelijk ligt in
het feit of er (on)ervaren personeel, goed of slecht gestructureerd programmeertaal,
niveau van programmeertaal (High, Low of Mid Level) en of er verschillende
onderhoudshulpmiddelen worden gebruikt voor het bepalen van de functiepunten. We
kunnen vervolgens het aantal mensen voor beheer en onderhoud in de verschillende
niveaus bepalen. Uit de literatuur is het moeilijk te achterhalen of een bepaalde
programmeertaal tot meer of minder beheer en onderhoud zal leiden. Dit geldt ook voor
frameworks, waarbij de framework de geproduceerde code van verschillende
programmeertalen kan integreren om een applicatie mee te vormen [GIAGRANDE]. Deze
.NET technologie van Microsoft bevat een aantal van deze programmeertalen, n.l., Visual
BASIC, C# en C++ [GIAGRANDE]. We zullen niet verder ingaan op de Frameworks en
programmeertalen, aangezien er in de literatuur niet echt een directe link te vinden is met
beheer en onderhoud. Echter zullen we onze resultaten (Hoofdstuk 6) wel eventueel
kunnen relateren aan de gegevens die we wel hebben gevonden en trachten zelf een link
te leggen tussen beheer en onderhoud vs. programmeertalen/frameworks.
3.7 Verdeelsleutel
Om de gegevens van de verschillende contracten met elkaar te kunnen vergelijken,
moeten we deze gegevens vergelijkbaar maken. Op geheel wiskundige wijze zullen we de
gegevens per contract omzetten. Met wiskundig bedoelen we dat we de uren die
geregistreerd zijn per contract, mathematisch zullen omzetten naar de minimale set aan
gegevens. Deze minimale set bevat variabelen waarop uren geregistreerd kunnen worden.
Zo krijgen we data dat we kunnen gebruiken bij de validatie van het model. Het is dan de
bedoeling om per ASL proces aan te geven welke geregistreerde uren hierbij horen. Na het
verdelen kunnen we pas de statistische technieken gebruiken. Het onderdeel
‘Verdeelsleutel’ zal in hoofdstuk 4 uitgebreid aan bod komen.
© Getronics PinkRoccade 2007
25
Het Standaardiseren van Urenposten
4 Het Standaardiseren van Urenposten
4.1 Inleiding
In dit Hoofdstuk vinden we een model dat aangeeft op welke manier de beheeruren
bijgehouden dienen te worden conform de ASL processen. Verder beschrijven we hoe we
tot ons model zijn gekomen. Dit model dient ter ondersteuning aan het betrokken
management die verschillende contracten onder hun beheer hebben. Deze contracten zijn
weer verschillend van aard en de uren voor beheer & onderhoud worden ook verschillend
bijgehouden. Vaak is het moeilijk om te achterhalen wat de oorzaken kunnen zijn van de
afwijkingen van de geadministreerde uren. We zullen hiervoor een model ontwikkelen die
ervoor moet zorgen dat het betrokken management informatie over de contracten kan
verkrijgen. We moeten hiervoor de urenposten standaardiseren naar de ‘minimale set’
(deelvraag 3 van het onderzoek. Deze minimale set zal in paragraaf 4.5 uitgebreid
toegelicht worden. De uitkomsten hiervan zullen weer in het onderzoek gebruikt worden
om te bepalen waar eventuele afwijkingen van contracten aan kunnen liggen. De
toegevoegde waarde van ons onderzoek is dan het ontwikkelen van een model, waarmee
GPR in het vervolg verder mee kan gaan voor vervolg onderzoek.
4.2 Criteria voor opstellen Model
De GQM (Goal Question Metric) benadering is een methode die men kan gebruiken bij het
uitvoeren van empirische studies op software projecten [BASILI]. De V-GQM (Validating
Goal Question Metric) is een methode voor het analyseren van een GQM studie, nadat data
is verzameld met als doel de validatie van de studie [OLSSON]. Bij het opstellen van ons
model zullen we gebruik maken van de V-GQM, aangezien deze toepasselijker is op ons
onderzoek. Overigens hebben we V-GQM al in hoofdstuk 1.6.1 geïntroduceerd en
onderstaande figuur toont alle stappen die hierin terugkomen.
Figuur 4.1 V-GQM methode
4.2.1 V-GQM (1) GOAL STATEMENT
Binnen het onderzoek, volgens [OLSSON]:
Goal statement:
26
Op welke manier kunnen urenregistraties van verschillende
applicaties gestandaardiseerd worden (Deelvraag 2) en of de
huidige normverdeling aan urenposten van beheer en onderhoud
uniform en praktisch toepasbaar (Deelvraag 3)?
© Getronics PinkRoccade 2007
Het Standaardiseren van Urenposten
4.2.2 V-GQM (2) QUESTION DEFINITION
Question Definition:
In onderstaande tabel vinden we 2 verschillende gebieden, n.l.
process definition (onderverdeeld in ‘process conformance’ en
process domain understanding) en quality focus. Process
definition is de definitie van de processen, quality focus legt de
nadruk op de kwaliteit van de vragen, process conformance staat
voor het raakvlak met de processen en process domain
understanding verdiept zich in het domein van de processen.
De question definition hebben we vervolgens op onze eigen situatie toegepast, zie tabel
4.2.
Process Definition
Quality Focus
Process Conformance
Process Domain
Understanding
9. Wat is de kwaliteit in
6. Welke definities voor
1. Welke taken horen bij de
kennis van de
applicatiebeheer en
ASL processen?
normverdeling?
onderhoud worden door de
2. Op welke manier worden
10. Hoeveel tijd wordt er
werknemers gehanteerd?
de uren op dit moment
7. Hoe goed is de kennis van besteed aan de
bijgehouden?
urenverantwoording?
werknemers op het gebied
3. Welke functiepunten
11. Hoe nauwkeurig worden
van ASL?
methodiek wordt er
8. Wat voor ervaring hebben de urenregistraties
gebruikt?
bijgehouden?
de werknemers over de
4. Wat voor invloed hebben
normverdeling?
de volgende zaken op
applicatiebeheer en
onderhoud?
•
Programmeertaal
•
Markt van de applicatie
•
Leeftijd van de applicatie
•
Migratie
•
Grootte van de applicatie
•
Contractduur
•
Geplande uren versus
gerealiseerde uren
Tabel 4.2 Question definition
4.2.3 V-GQM (3) METRIC DERIVATION
Metric Derivation: Hierin komen de scale description (maatverdeling) en de metric
categories (metrieken categorieën) om vervolgens de question/metric relatie vast te
leggen. Hieronder leggen we deze zaken uit, zoals deze beschreven worden door
[OLSSON].
Scale description bestaat uit drie gebieden:
•
Descriptive: Het antwoord is algemeen, waarbij het aantal niet kwantificeerbaar is.
•
Ordinal: De antwoorden kunnen met elkaar vergeleken worden zonder een
absolute waarde.
•
Absolute: Het antwoord is kwantificeerbaar met een absolute betekenis.
Metric categories bestaan uit de volgende categorieën:
•
Process: Het antwoord betreft het ontwikkelingsproces.
•
Resource: Het antwoord is een beschrijving van hoeveel resources er zijn gebruikt.
© Getronics PinkRoccade 2007
27
Het Standaardiseren van Urenposten
•
Product: Het antwoord is een beschrijving van het product of omgeving waarin het
onderzoek heeft plaatsgevonden.
We zullen hierna de question/metric relatie weergeven, om sommige vragen aan de hand
van metrieken te kunnen antwoorden. In Tabel 4.3 geven we deze relatie weer.
Metric
Question
Descriptive, Process
Ordinal, Resource
Ordinal, Product
Absolute, Resource
1, 2, 3, 4
6, 7, 8
9, 11
10
Tabel 4.3 Question-Metric Definitie
4.3 Eerste opzet
In dit onderdeel zullen we de criteria meenemen die we in paragraaf 4.2 omschreven
hebben. Voordat we het model gaan opstellen, zullen we eerst een vragenlijst opstellen om
uiteindelijk de juiste gegevens boven tafel te krijgen om afwijkingen van geregistreerde
uren te verklaren. Dit lijstje dient door de service managers ingevuld te worden, aangezien
zij de hoofdverantwoordelijke van de outsourcing deal zijn.
Voor het verzamelen van gegevens van contracten, hebben we allereerst gebruik gemaakt
van een vragenlijst.
Naam Servicemanager
Naam contract
Programmeertaal
Markt
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
<Voor en achternaam>
<Naam contract>
<Programmeertaal> Over het algemeen bestaan applicaties
uit meerdere programmeertalen. Soms gaat het wel om
enkele tientallen programmeertalen.
De markt waarin de organisatie opereert.
Leeftijd van het systeem en indien van toepassing ook
aangeven of het hier gaat om een legacy system.
Aangeven of er migratie heeft plaatsgevonden en in welk
jaar.
<Aantal functiepunten>. Binnen een organisatie zijn de
functiepunten
niet
altijd
bekend,
aangezien
de
functiepunten dan nog niet geteld zijn. In dit soort gevallen
is een schatting het meest realistische. Bij een schatting of
oude telling moet dat ook aangegeven worden. Deze
functiepunten kunnen eventueel op basis van de NESMA
FPA of IFPUG methodiek geteld zijn.
<Aantal jaren> De duur van het contract.
De verhouding tussen de geplande uren en de gerealiseerde
uren.
Tabel 4.4 Opzet vragenlijst contracten
Ons doel is om een zo compleet mogelijk ingevulde lijst terug te ontvangen van de service
managers. Het kan voorkomen dat niet alle onderdelen van de vragenlijst ingevuld worden
en in dat geval hebben we dus relatief minder informatie om eventuele afwijkingen te
verklaren.
28
© Getronics PinkRoccade 2007
Het Standaardiseren van Urenposten
In de probleemstelling hadden we aangegeven dat er een normverdeling van de
beheeruren bestond, die tijdens de Intake werd gebruikt om het aantal beheeruren van de
over te nemen applicatie te bepalen. Het gaat om het volgende model, tabel 1.1:
ASL proces
Incident management (Incidentbeheer)
Configuration management (Configuratiebeheer)
Availability management (Beschibaarheidsbeheer)
Capacity management (Capaciteitsbeheer)
Continuity management (Continuïteitsbeheer)
Change management (Wijzigingenbeheer)
Software Control en distribution (Programmabeheer en distributie)
Onderhoud (correctief, preventief en perfectief)
Tactisch management
Strategisch management
Percentage
12%
5%
15%
3%
5%
2%
5%
40%
10%
3%
TOTAAL
100%
Tabel 1.1 Normverdeling beheeruren (ASL Processen) (herhaling)
Voor ons onderzoek zouden we op basis van bestaande contracten dit model proberen te
valideren. We gingen er in het begin ook van uit dat we de uren van bestaande contracten
ook op deze manier aangeleverd zouden krijgen. Uitgaande van de huidige normverdeling
beheeruren, zien we dat er in de praktijk niet wordt geadministreerd per ASL proces.
Verder is het in de praktijk niet handig om zoveel urenposten te gebruiken. We zullen het
aantal urenposten zoals deze wordt weergegeven in tabel 1.1 beperken tot 4 urenposten.
Hierna gaan we kijken of contracten met de nieuwe verdeling overeenkomen. We gaan in
de volgende paragraaf hier verder op in,
4.4 Nieuw model
Zoals in hoofdstuk 4.3 is aangegeven, gaan we een nieuw model opstellen. Dit model is
specifiek voor de normverdeling beheeruren, alleen is het als het ware een minimale set
om contracten beter leesbaar te maken voor het betrokken management.
De verdeling van Marcel Oevermans nemen we als uitgangspunt, die ook verantwoordelijk
was voor de normverdeling beheeruren (tabel 1.1) binnen GPR. Zoals we al hebben
aangegeven zijn de urenregistraties per contract verschillend, waardoor het voor het
betrokken management moeilijk is om de relaties en afwijkingen tussen de contracten te
begrijpen. Om deze zaken zo overzichtelijk mogelijk te maken gaan we gebruik maken van
een verdeelsleutel. De verdeelsleutel gebruiken we om op boekhoudkundige wijze de
huidige geregistreerde beheeruren per contract te vertalen naar een standaard. Vervolgens
gaan we het nieuwe model valideren aan de hand van de verkregen output uit de
verdeelsleutel.
© Getronics PinkRoccade 2007
29
Het Standaardiseren van Urenposten
4.4.1 Verdeelsleutel
We gaan per contract trachten om de geregistreerde uren te vertalen naar de ASL
processen, die vervolgens omgezet zullen worden naar een standaard.
Uitgangspunt:
Geregistreerde urenposten:
BEHEER
SERVICE MANAGEMENT
ADAPTIEF ONDERHOUD
(BH)
(SM)
(AO)
Hierboven zien we de geregistreerde uren en de afkorting die erbij horen. Om erachter te
komen bij welke ASL processen de geregistreerde uren horen, was het de bedoeling dat we
Marcel Oevermans dit lieten invullen, zie tabel 4.5.
ASL proces
Incident management
Configuration management
Availability management
Capacity management
Continuity management
Change management
Software Control en distribution
Onderhoud (correctief)
Onderhoud (preventief)
Onderhoud (perfectief)
Tactisch management
Strategisch management
1
Tabel 4.5 Verdeelsleutel
Verdeelsleutel
BH
BH
BH
BH
BH
AO/SM
AO/SM
AO
AO
AO
SM/BH
SM/BH
Toelichting van Marcel Oevermans:
De verdeling is bepaald door ASL, waarbij:
a) Incident-, Configuratie-, Beschikbaarheids-, Capaciteits- en Continuïteitsbeheer
onder de Beheer Processen vallen.
b) Wijzigingenbeheer en Programmabeheer en distributie onder de Verbindende
Processen vallen.
c) De Onderhoudprocessen onder Onderhoud en Vernieuwing vallen.
d) Tactisch en Strategisch management onder de Sturende Processen vallen.
•
•
Alles wat onder Beheer valt hoort bij a) en daar zit een beetje d) bij.
Alles wat onder Adaptief Onderhoud valt hoort bij c) en een beetje b).
Zo willen we voor alle contracten de verdeelsleutel laten invullen, om erachter te komen
achter welke ASL processen de geregistreerde uren horen. Het liefst zouden we willen dat
iedereen op dezelfde manier zijn uren registreert, alleen gaat het in de praktijk er geheel
anders aan toe. De verdeelsleutel zal als aanvulling dienen bij de vragenlijst uit tabel 4.2.
Hierna is het de taak van de service manager om deze zo zorgvuldig mogelijk in te vullen.
30
© Getronics PinkRoccade 2007
Het Standaardiseren van Urenposten
Change
Management
Incident
Management
Continuity
Management
Design
Availability
Management
Capacity
Management
Configuration
Management
Impact
Analysis
Software
Control
and
Distribution
Realization
Implementation
Testing
Omzetting van het ASL Framework (Uitvoerend Niveau)
Naar het ASL Framework van Marcel Oevermans
Tactisch
Management
Strategisch
Management
Change
Management
Incident
Management
Onderhoud
Correctief
Continuity
Management
Availability
Management
Onderhoud
Preventief
Capacity
Management
Configuration
Management
Onderhoud
Perfectief
Software
Control
and
Distribution
ADAPTIEF ONDERHOUD
(AO)
BEHEER
(BH)
SERVICE MANAGEMENT
(SM)
Figuur 4.6 Framework Urenregistratie Marcel Oevermans
In figuur 4.6 zien we waarop Marcel Oevermans zijn uren registreert. Voor de uren wordt
er alleen onderscheid gemaakt tussen Beheer (BH), Adaptief Onderhoud (AO) en Service
Management (SM). In dit figuur zien we dat sommige ASL processen ook samen kunnen
vallen. De ASL processen die onder twee gebieden vallen:
© Getronics PinkRoccade 2007
31
Het Standaardiseren van Urenposten
•
•
•
•
Change Management valt zowel onder AO als SM.
Software Control & Distribution valt zowel onder AO als SM.
Tactisch Management valt zowel onder BH als SM.
Strategisch Management valt zowel onder BH als SM.
In het geval van Marcel Oevermans moeten we bepalen of deze set van geregistreerde
uren voldoende kan zijn om eventuele afwijkingen en spreidingen tussen contracten te
bepalen. Zoals we al eerder vermeld hebben, dient deze set (BH, AO en SM) als basis. Zo
kan het voorkomen dat andere contracten op geheel andere wijze bijgehouden worden, die
vervolgens weer omgezet kunnen worden naar deze standaard.
4.5 Minimale set
De verdeelsleutel uit tabel 4.5 kunnen we weer omzetten in het onderstaande figuur,
waarbij we met behulp van vinkjes kunnen aangeven bij welke ASL processen de
geregistreerde uren horen. Op de verticale as zien we de ASL processen en op de
horizontale as zien we waarop de uren zijn geregistreerd.
Uitgangspunt: Huidig gebruikte minimale set aan urenposten door Marcel Oevermans
SM
AO
BH
Incident management
Configuration management
Availability management
Capacity management
Continuity management
Change management
Software Control en distribution
Onderhoud (correctief)
Onderhoud (preventief)
Onderhoud (perfectief)
Tactisch management
Strategisch management
2
tabel 4.7 Verdeelsleutel
Gesprekken met het management hebben ervoor gezorgd dat we Incident Managent
buiten Beheer kunnen houden. Zo willen we Incident Management kunnen onderscheiden
van Beheer, aangezien dit meer Helpdesk activiteiten zijn. Dit mede ook door het feit dat
er voor de nabije toekomst een centrale Helpdesk gepland is binnen GPR.
We zouden hierdoor onze verdeelsleutel enigszins kunnen aanpassen aan de behoefte van
het management. Dit zou geen extra gevolgen met zich meebrengen voor het onderzoek.
Het is tevens meteen een nieuwe minimale set, zie tabel 4.8.
De enige aanpassing is het feit dat de Helpdesk (HD) erbij is gekomen en onder Helpdesk
valt alleen Incident Management.
32
© Getronics PinkRoccade 2007
Het Standaardiseren van Urenposten
Nieuwe Uitgangspunt:
HD
SM
AO
BH
Incident management
Configuration management
Availability management
Capacity management
Continuity management
Change management
Software Control en distribution
Onderhoud (correctief)
Onderhoud (preventief)
Onderhoud (perfectief)
Tactisch management
Strategisch management
3
Tabel 4.8 Verdeelsleutel
Zoals we al eerder bij de eerste verdeelsleutel (tabel 4.5) hebben aangegeven is het de
taak van de service manager om de eerste verdeelsleutel zo zorgvuldig mogelijk in te
vullen. Zo kunnen wij dit weer omzetten zoals het is weergegeven in tabel 4.8. Voor het
omzetten van de verkregen informatie van de service managers volgen een aantal
tussenstappen. De verdeling van de vinkjes zullen we zelf doen.
4.5.1 Nieuwe Percentuele Verdeling
De nieuwe verdeling leidt vervolgens tot een nieuwe percentuele verdeling. De huidige
normverdeling beheeruren uit tabel 1.1 kunnen we omzetten in de nieuwe verdeling van
onze minimale set (BH, AO, SM en HD). Hierbij is het de bedoeling dat we de basisset
opnieuw percentueel gaan indelen. Dit doen we overigens aan de hand van de huidige
normverdeling, door de percentages horizontaal over de vinkjes (tabel 4.8) te verdelen.
We verdelen vervolgens verticaal alle percentages onder BH, AO, SM en HD op waardoor
we een nieuwe percentuele verdeling krijgen.
Onderhoud (perfectief)
Tactisch management
Strategisch management
TOT 100%
5
1.5
34.5
HD
Onderhoud (preventief)
SM
5
15
3
5
AO
BH
Incident management
Configuration management
Availability management
Capacity management
Continuity management
Change management
Software Control en distribution
Onderhoud (correctief)
12
1
2.5
13 ⅓
13 ⅓
13 ⅓
43.5
1
2.5
5
1.5
10
12
Tabel 4.9 Percentuele verdeling nieuwe basisset
© Getronics PinkRoccade 2007
33
Het Standaardiseren van Urenposten
We krijgen dan als het ware een nulhypothese (nieuwe normering) voor de minimale set
aan urenposten, die er als volgt uitziet (zie ook figuur 4.9):
H0 - BH= 34.5%, AO= 43.5%, SM= 10% en HD= 12%
We hebben op deze manier het nieuwe model van Oevermans genormeerd en een nieuwe
percentuele verdeling van de nieuwe basisset gegenereerd. Bij deze normering kan er nog
eventueel fijnafstemming plaatsvinden. Dat zal in het vervolg van het onderzoek aan bod
komen.
Om een soortgelijke uitvoer per contract te krijgen, moeten we de contracten ook kunnen
omzetten. Deze omzetting wordt in paragraaf 4.6 beschreven d.m.v. een voorbeeld.
4.6 Omzetting naar ASL urenposten
Voor het omzetten van de contracten zouden we idealiter zo weinig mogelijk vertaalslagen
willen maken. We zouden het liefst meteen de minimale set van Marcel Oevermans willen
meten (BH, AO en SM), maar in praktijk wordt er helaas op verschillende manieren
geregistreerd. De stappen die hierbij komen kijken worden op boekhoudkundig wijze
vertaald.
4.6.1 Stappen voor de omzetting naar de basisset
Hieronder geven we een voorbeeld van geregistreerde uren, waarmee we uiteindelijk aan
de hand van drie stappen tot een output komen. Voor elk contract dienen we dezelfde
stappen te volgen.
Input Contract (Voorbeeld van contract EDMS)
Uren zijn als volgt gedefinieerd en geregistreerd:
Xi staat hier voor een bepaalde urenpost en deze kan per contract
verschillen. EDMS is een contract dat door GPR beheerd en onderhouden
wordt.
BH (X1) = 868
SM (X2) = 408
AO (X3) = 40
In figuur 4.10 kunnen we de stroom zien van het omzetten van de gegevens van het
voorbeeld contract. Hierin worden met behulp van gekleurde lijnen aangeven hoe het
omzetten van gegevens verloopt. We willen uiteindelijk BH, SM en AO mappen naar onze
minimale set die bestaat uit 4 urenposten BH (Beheer), AO (Adaptief Onderhoud), SM
(Service Management) en HD (Helpdesk).
34
© Getronics PinkRoccade 2007
STAP 3
STAP 2
STAP 1
Het Standaardiseren van Urenposten
Figuur 4.10 Voorbeeld verdeelsleutel voor een contract
© Getronics PinkRoccade 2007
35
Het Standaardiseren van Urenposten
Stap 1 (Rood)
Voor BH (X1) zijn in totaal 868 uren geregistreerd, die overigens verdeeld (horizontaal)
moeten worden over de vinkjes die onder BH staan. Deze vinkjes zijn vooraf door de
service manager bepaald. In dit geval verdelen we 868 uren over ´Incident Management´,
´Configuration Management´, ´Availability Management´, ´Continuity Management´,
´Tactisch Management´ en ´Strategisch Management’, waarbij ze allemaal 124 krijgen.
Dit doe je vervolgens ook voor de uren SM (X2) en AO (X3) door simpelweg de waardes
horizontaal over de vinkjes te verdelen.
Stap 2 (Groen)
Bij deze stap tellen we het totale aantal uren achter de ASL processen verticaal op,
ongeacht of de uren onder BH, SM of AO staan. Boven elke ASL proces komt er een totaal
bedrag (TOT) te staan. Zo krijg je achter ‘Configuration Management’ een bedrag van 124.
Dit doe je vervolgens voor alle ASL processen, door simpelweg alle waardes achter de
vinkjes verticaal op te tellen.
Stap 3 (Blauw)
1e blauwe lijn (Verticaal naar beneden)
Met de verkregen informatie uit stap 2 kunnen we vervolgens het totale aantal uren achter
de ASL processen opnieuw verdelen over de vinkjes. Deze verdeling is dezelfde verdeling
als in tabel 4.8, alleen in een andere vorm gepresenteerd. Als we naar het voorbeeld
kijken zien we dat het totale aantal uren achter ´Configuration Management’ weer
verticaal verdeeld kan worden over de vinkjes. In dit geval komt het totale aantal uren van
124 onder het enige vinkje wat onder de Beheer (BH) staat. Hetzelfde doe je vervolgens
voor de rest van de TOT bedragen, door deze waardes verticaal naar beneden te verdelen
over de vinkjes.
2e blauwe lijn (horizontaal naar rechts)
Vervolgens kunnen we horizontaal per rij alle waardes bij de vinkjes optellen. Zo krijgen
we het totale aantal uren achter BH, AO, SM en HD.
Met de verkregen output kunnen we een percentuele verdeling maken, zie tabel 4.11:
Basisset
BH
AO
SM
HD
Totaal
Tabel 4.11
Aantal uren
Percentage
722
55 %
134
10 %
336
26 %
124
9%
1316
100 %
Uitvoer Voorbeeld
De drie stappen kunnen bij alle soorten contracten toegepast worden om de gegevens
uiteindelijk beter vergelijkbaar te maken. Deze percentuele verdeling kunnen we voor
ieder contract genereren, om vervolgens de nieuwe percentuele verdeling (tabel 4.9) te
kunnen valideren. De statistische technieken die we zullen gebruiken tijdens de validatie
stap, zullen in de volgende paragraaf beschreven worden.
36
© Getronics PinkRoccade 2007
Het Standaardiseren van Urenposten
4.6.2 Statistische benadering van het model
Zoals we al weten hebben we een nieuwe normering (BH= 34.5%, AO= 43.5%, SM= 10%
en HD= 12%) opgesteld, die ook in tabel 4.9 is terug te vinden. In de vorige subparagraaf
hebben we uiteindelijk een uitvoer voorbeeld van het contract EDMS (tabel 4.11). De
volgende stap na het omzetten is het vergelijken van de verkregen uitvoer met de nieuwe
normering.
Contract EDMS
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Uren
722
134
336
124
1316
%
55%
10%
26%
9%
100%
Normering
34.5%
43.5%
10%
12%
100%
We gaan elk contract omzetten om ze vervolgens allemaal te vergelijken met de
normering. Op deze manier willen we de normering valideren . Tijdens het valideren gaan
we statistische technieken van [EVERITT] gebruiken. In het voorbeeld hierboven zien we
overigens dat er onderling veel verschil is tussen de normering. Dit hoeft niet direct te
betekenen dat de normering niet juist is. In het volgende hoofdstuk gaan we verder met
het toepassen van deze technieken.
© Getronics PinkRoccade 2007
37
Case Study
5 Case Study
5.1 Inleiding
In dit hoofdstuk zullen we een overzicht van de verdeling weergeven die we hebben
omgezet volgens de verdeelsleutel (figuur 4.10). Verder zullen we de huidige situatie
binnen de organisatie schetsen op basis van de verkregen dataset. Deze dataset zal de
percentuele verdeling per contract bevatten om deze vervolgens op te kunnen zetten
tegenover de nieuwe normering (tabel 4.9) uit de vorige hoofdstuk:
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
34.5%
43.5%
10%
12%
Tabel 5.1 Nieuwe Normering
Nadat we alle data verzameld hebben, kunnen we op statistische wijze de huidige situatie
in kaart brengen. Nou is het voor ons belangrijk om de nieuwe normering (uit tabel 5.1
te valideren. Voor de validatie van het model kunnen we verschillende technieken
[EVERITT] gebruiken om correlatie/covariantie tussen verschillende data te visualiseren.
Zo verstaan we onder correlatie het volgende: een verband waarmee twee grootheden
elkaar kunnen beïnvloeden. Covariantie: een maat voor de spreiding van twee gekoppelde
variabelen oftewel de spreidingsmaat. We zullen een aantal technieken opsommen en de
keuze voor die technieken motiveren. Verder gaan we kort in op het feit dat sommige
technieken kunnen leiden tot bepaalde verwachtingen. Deze verwachtingen kunnen soms
verklaard worden uit de methodiek. Hieronder vinden we een overzicht van de
verschillende technieken, onze verwachtingen en bij enkele technieken ook een voorbeeld
uit het dagelijks leven. De voorbeelden zullen gebaseerd zijn op demografische gegevens
van landen, om het even wat begrijpelijker te maken voor de lezer.
Indien we het over variabelen hebben, doelen we specifiek op onze 4 urenposten van de
normering: BH, AO, SM en HD. De variabelen in het voorbeeld zijn demografische
gegevens van landen, zoals populatie, AIDS patiënten, gemiddelde leeftijd, verwachtte
leeftijd of militaire uitgaven.
Representatie en visualisatie technieken
Matrix representatie en visualisatie technieken van multivariate data: Hiermee krijgen
we een globaal beeld over de mogelijke positieve/negatieve correlatie tussen data.
38
•
Scatterplot Matrix: Matrix representatie waarmee we een globaal beeld krijgen
over de mogelijke positieve/negatieve correlatie tussen data.
Positieve correlatie: een vermeerdering van de ene grootheid leidt tot een
vermeerdering van de andere grootheid.
Negatieve correlatie: een vermeerdering van de ene grootheid leidt tot een
vermindering van de andere grootheid.
Verwachting: Sommige variabelen kunnen een mogelijke positieve
correlatie hebben met andere variabelen. Indien variabelen verschillen van
elkaar, dan zou het betekenen dat er negatieve correlatie is. Het gaat hier
om een visuele representatie zonder cijfers.
Voorbeeld: Negatieve correlatie: Tussen verwachtte gemiddelde leeftijd
en het aantal AIDS patiënten in een land. Als het aantal AIDS patiënten
stijgen, dan daalt de gemiddelde leeftijd in een land.
•
Berekening correlatie/covariantie 2 dimensies: Hiermee kunnen we twee
verschillende data onderling met elkaar vergelijken en de onderlinge correlatie en
covariantie bepalen.
Positieve covariantie: data van beide contracten stijgen/dalen gezamenlijk.
Cov(x,y) is hier een positief getal.
© Getronics PinkRoccade 2007
Case Study
Negatieve covariantie: data van beide contracten stijgen/dalen niet
gezamenlijk. Cov(x,y) is hier een negatief getal.
Geen covariantie: Cov()x,y) = 0.
Verwachting: Hiermee kunnen we elk variabele individueel opzetten
tegenover een andere variabele, om de onderlinge correlatie en covariantie
te bepalen. Dit zou een belangrijke stap zijn voor het verklaren van de
somenhang tussen de variabelen.
Voorbeeld: Zelfde voorbeeld als de scatterplot matrix, alleen kunnen we
de negatieve correlatie direct in getallen aflezen.
•
Correlatie tussen alle dimensies: Hiermee krijgen we een totaal beeld van de
correlaties tussen alle data.
Verwachting: Net als bij de scatterplot matrix kunnen we zien of er
positieve of negatieve correlatie bestaat tussen alle data, alleen is het
voordeel dat we dit exact kunnen aflezen uit de uitvoer.
•
Starsplot: Hieruit kunnen we opmaken of bepaalde data met elkaar te vergelijken
zijn. Hierbij worden contracten gevisualiseerd, waarbij ze een bepaalde vorm
aannemen.
Verwachting: Bepaalde contracten kunnen veel op elkaar lijken, door de
data die ze bevatten. We krijgen dan een globaal beeld van contracten die
goed met elkaar te vergelijken zijn. Dit zou betekenen dat sommige
contracten ongeveer dezelfde percentuele verdeling hanteren.
Voorbeeld: We krijgen een visualisatie van alle landen, elk land neemt
dan een bepaalde vorm aan. Landen als Canada en Australië hebben
ongeveer dezelfde vorm, dat betekent dat de demografische gegevens van
de landen veel op elkaar lijken.
Principal Component Analyse technieken
Data met meervoudige dimensies, waarvan we de belangrijkste verbanden
ontdekken en onderlinge samenhang tussen de variabelen na kunnen gaan.
•
Scree Plot: Hiermee kunnen we de variantie van de variabelen visualiseren.
Variantie: kwadraat van de standaardafwijking, een statistische maat voor de
spreiding van een verschijnsel [VAN DALE].
Verwachting: Hiermee krijgen we een gesorteerde beeld van hoge
variantie (y-as) naar lage variantie tussen de variabelen (x-as). Hiermee
kunnen we verklaren of de variantie tussen variabelen hoog genoeg is om
onderscheid te maken tussen de verschillende contracten.
•
Score Plot: De visualisatie van de eerste twee variabelen uit de scree plot,
waarmee we de variantie ervan in alle contracten kunnen visualiseren.
Verwachting: We kunnen hiermee de variantie in de eerste twee
variabelen (ook wel Comp.1 en Comp.2 genoemd) tussen alle contracten
visualiseren. Zo komen we meer te weten over de effect van variabelen op
de uiteindelijke verdeling.
Voorbeeld: Hierin zien we de variantie in de demografische gegevens van
alle landen op de eerste twee demografische gegevens. Landen worden
genummerd en gepositioneerd. Land 1 (Canada) en land 4 (Australië)
liggen bijvoorbeeld dicht bij elkaar.
•
Biplot: Visualiseert de scores op de eerste twee variabelen (Comp.1 en Comp.2) en
de ladingen van de variabelen ervan.
Verwachting: We kunnen hiermee zien welke variabelen veel/weinig
invloed hebben op de verschillende contracten en welke contracten dicht bij
elkaar staan.
Voorbeeld: De variabele AIDS patiënten heeft veel invloed op de positie
van Mozambique en Gambia.
© Getronics PinkRoccade 2007
39
Case Study
Cluster Analyse technieken
Methode om een beeld te krijgen van overeenkomstige patronen (clusters) binnen
een dataset.
•
Multidimensional Scaling: Hiermee kunnen we de Euclidean afstanden zien tussen
de data, met als doel te kijken naar overeenkomstige kenmerken. Accounts die
dan verder veel overeenkomsten met elkaar hebben worden dan gevisualiseerd in
clusters.
Euclidean afstand: de geometrische afstand tussen data in een
multidimensionale ruimte.
Verwachting: Hiermee kunnen we de Euclidean afstanden tussen de
contracten en vervolgens uit opmaken welke contracten overeenkomstige
kenmerken vertonen. Hoe kleiner de Euclidean afstand is, des te meer
verwant tussen de contracten.
Voorbeeld: Landen als Kongo, Sudan en Ethiopië liggen binnen een cluster
en landen als Groot-Brittannië, Duitsland en Frankrijk liggen ook weer in
een aparte cluster.
•
Hiërarchische clustering: onderverdeling van de clusters.
Verwachting (Complete Linkage): Grootste afstand met buren. Hieruit
kunnen we hetzelfde verwachten als bij Multidimensional Scaling.
Verwachting (Average): Gemiddelde afstand met buren.
Verwachting (Single Linkage): Kleinste afstand met buren. Deze
methode zal minder geschikt zijn voor het toewijzen van clusters i.v.m. het
samenvoegen van coördinaten, i.p.v. het toewijzen van een nieuwe cluster.
Voorbeeld: Landen worden ook hier gegroepeerd in clusters, maar dan
wat duidelijker en overzichtelijker.
•
K-means clustering: Hierbij gaat het om een iteratieve manier van clusteren,
waarbij je vooraf bepaald hoeveel clusters je wilt hebben en daarna wordt van elk
datapunt de afstand tot de centra bepaald.
Verwachting: We kunnen hiermee zien welke datapunt aan welke cluster
wordt toegewezen. Dit is een continue proces, die ophoudt totdat er niks
meer verandert. Zo kunnen we zien of er veel of weinig onderscheid is
tussen de waarnemingen.
Lineaire regressie technieken
Voorspellingen doen voor de waarden van een variabele aan de hand van de
waarde van een andere variabele.
40
•
Single linear regression: Om te bepalen of er een zekere verband is tussen
gepaarde waarnemingen.
Verwachting: We kunnen hiermee zien of een variabele voorspelt kan
worden aan de hand van een andere variabele.
Voorbeeld: Kan het aantal AIDS patiënten voorspeld worden aan de hand
van de verwachtte leeftijd? We kunnen hieruit een formule opstellen
waarmee we het aantal AIDS patiënten kunnen voorspellen.
•
Multiple linear regression: Hetzelfde principe als bij single linear, alleen voor
multiple data.
Verwachting: We kunnen hiermee zien of bepaalde variabelen voorspeld
kunnen worden aan de hand van andere variabelen en informatie inwinnen
met betrekking tot de spreiding van de gegevens. Verder zien we een
totale samenvatting van alle data.
•
Linear model: schattingsmodel voor het bepalen van verwachte waardes.
Verwachting: We kunnen hierin per variabele voorspellen welke andere
variabelen invloed hebben op de gegeven variabele.
© Getronics PinkRoccade 2007
Case Study
Voorbeeld: We kunnen exact zien welke demografische gegevens je
nodigt hebt om een bepaalde demografische gegeven te voorspellen. Om
de levensverwachting te voorspellen heb je de gemiddelde leeftijd en het
aantal AIDS patiënten nodig.
De bovenstaande technieken zullen in dit hoofdstuk toegepast worden om de huidige
situatie binnen de organisatie in kaart te brengen. De resultaten van deze technieken
zullen duidelijker worden wanneer we ze toegepast hebben.
Uit de Case Study en Validatie (Hoofdstuk 5 en 6) moet uiteindelijk blijken of de nieuwe
normering met 4 urenposten wel of niet als standaard gebruikt kan worden. Bij het
beantwoorden van deze vraag kunnen we eventuele afwijkingen en spreidingen tussen
data verwachten, aangezien niet alle ASL processen worden geregistreerd. Afwijkingen en
spreidingen kunnen verklaard worden aan de hand van interviews/vragenlijsten/theorie
Hoofdstuk 2 en 3. Spreidingen kunnen ook verklaard worden aan de hand van de spreiding
van de ASL processen, wanneer de gegevens over de normering te weinig zeggen. Ten
slotte zullen we een korte afronding en evaluatie geven over de case study, deze zal
overigens aan het eind van het hoofdstuk aan bod komen. Bij elke techniek hebben we de
bevindingen weergeven, aangezien een figuur niet voor iedereen even duidelijk is.
5.2 Overzicht Contracten
In deze paragraaf hebben we alle contracten omgezet volgens de verdeelsleutel (figuur
4.10). De output die we daaruit gekregen hebben kunnen we weer omzetten naar
percentages. Op deze manier trachten we de nieuwe verdeling te kunnen valideren.
Hieronder vinden we een dataset die is voortgevloeid uit de verdeelsleutel. Deze dataset
bevat alle contracten die we hebben meekregen, inclusief de normering. De contracten
hebben allemaal een nummer gekregen, zodat we uit onze analyse in de volgende
paragraaf kunnen opmaken voor welke contract de nummers staan. We zitten dan alweer
in de eerste data collection fase van het V-GQM model.
5.2.1 V-GQM (4) DATA COLLECTION (1/2)
BH
(1) Normering
34,5
(2) EDMS
55
(3) PUR
19
(4) ODS
38
(5) IMF
35
(6) RESA/FASA
33
(7) EW/BWS
44
(8) GCU
32
(9) Arbototaal
39
(10) GEFIS
54
(11) SBB
28
(12) NEA
37
(13) RING
38
Tabel 5.2 Dataset
AO
43,5
10
58
34
37
38
29
47
33
15
23
29
28
SM
10
26
18
24
26
26
22
17
20
19
17
29
31
HD
12
9
4
4
2
2
6
4
7
12
32
5
3
De uitvoer van de data heeft ervoor gezorgd dat we de normering kunnen opzetten
tegenover de andere contracten om erachter te kunnen komen of deze verdeling tot een
standaard dient te horen. Het zou voor de hand liggen als meer dan de helft van de
contracten een soortgelijke percentuele verdeling hebben, om het als standaard te zien.
We kunnen uit tabel 5.2 zien dat sommige contracten enorm verschillen van de normering.
Alvorens we dit soort uitspraken kunnen maken, moeten we dit eerst bewijzen d.m.v. het
toepassen van de statistische technieken. In de volgende paragraaf zullen we aangeven
welke technieken, welke codes en welk software programma we gebruikt hebben tijdens
het toepassen van de statischtische technieken.
© Getronics PinkRoccade 2007
41
Case Study
5.3 Statistische benadering
Voor het uitvoeren van de statistische technieken hebben we gebruik gemaakt van een
gratis software programma, genaamd R. R is een taal en omgeving voor statische
berekening en visualisering [R-PROJECT]. Het programma is ideaal voor het uitvoeren van
onze analyse.
De technieken die we gaan toepassen doen we met behulp van de code dat bestemd is
voor elk techniek. In de volgende subparagrafen zullen we allereerst de techniek aangeven
die we toegepast hebben, vervolgens de output en als laatst geven we aan wat we kunnen
concluderen uit de output. Voor de verschillende betekenissen van de technieken verwijzen
we u door naar paragraaf 5.1, waar we een overzicht hebben van alle technieken die we
toegepast hebben. De variabelen zijn zoals we al eerder aangegeven hebben de 4
urenposten BH, AO, SM en HD.
5.3.1 Representatie en Visualisatie
data<-matrix(scan("data.txt"),ncol=4,byrow=T)
rownames(data)<-c("Normering", "EDMS", "PUR", "ODS", "IMF", "RESA/FASA", "EW/BWS",
"GCU", "Arbototaal", "GEFIS", "SBB", "NEA", "RING")
colnames(data)<-c("Beheer", "Adaptief Onderhoud", "Service Management", "Helpdesk")
pairs(data, panel=panel.smooth)
Figuur 5.3 Scatterplot Matrix
De Scatterplot matrix geeft ons een beeld van de mogelijke positieve of negatieve
correlatie tussen de verschillende variabelen. Dit zegt overigens nog niks over de
contracten, maar meer over de variabelen van de contracten. Elk blokje geeft de
verhouding tussen twee variabelen. In het vergrote blok uit het bovenstaande figuur zien
we de verhouding tussen Beheer en Helpdesk. We zien een grafiek met de waardes per
punt.
42
© Getronics PinkRoccade 2007
Case Study
Bevinding
Een mogelijke positieve correlatie tussen: BH en SM, alleen kunnen zien we zien
dat een stijging van de ene variabele niet direct kan leiden tot een zelfde soort
stijging van de andere variabele. Aangezien de matrix een mogelijke correlatie zal
geven, weten we dus niet exact of er positieve of negatieve correlatie is tussen de
variabelen.
Een mogelijke negatieve correlatie tussen: BH en AO, wanneer de ene variabele
stijgt dan daalt de andere variabele, alleen ziet het er uit dat deze verschillen
minimaal zijn. We kunnen uit deze visualisatie niet direct opmaken wat de
verschillen zijn. Hetzelfde geldt voor BH en HD.
Berekening correlatie/covariantie: Beheer en Service Management van een
applicatie
dataBeheer <-data[,1]
dataServiceManagement <-data[,3]
X<-cbind(dataBeheer, dataServiceManagement)
X
dataBeheer dataServiceManagement
Normering
34.5
10
EDMS
55.0
26
PUR
19.0
18
ODS
38.0
24
IMF
35.0
26
RESA/FASA
33.0
26
EW/BWS
44.0
22
GCU
32.0
17
Arbototaal
39.0
20
GEFIS
54.0
19
SBB
28.0
17
NEA
37.0
29
RING
38.0
31
cov(X)
dataBeheer
dataServiceManagement
dataBeheer dataServiceManagement
93.49359
14.70192
14.70192
33.74359
cor(X)
dataBeheer
dataServiceManagement
dataBeheer dataServiceManagement
1.0000000
0.2617505
0.2617505
1.0000000
We kunnen van twee variabelen exact zien wat de onderlinge samenhang is m.b.t. de
positieve/negatieve covariantie en de positieve/negatieve correlatie.
Bevinding
Covariantie: De variabelen Beheer en Service Management hebben een positieve
covariantie (14.70192). Dit zou kunnen betekenen dat beide variabelen gezamenlijk
wel zullen stijgen of dalen. Beheer en Service Management zullen veel met elkaar
te maken hebben in de praktijk.
Correlatie: We zien hier voor het eerst een bevestiging van het feit dat er tussen
Beheer en Service Management positieve correlatie (0.2617505) is. Op een schaal
van 0 tot 1 is de positieve correlatie aan de lage kant. Een vermeerdering van
Beheer zal leiden tot een vermeerdering van Service Management.
© Getronics PinkRoccade 2007
43
Case Study
Berekening correlatie/covariantie: Beheer en Adaptief Onderhoud van een
applicatie
dataBeheer <-data[,1]
dataAdaptiefOnderhoud <-data[,2]
X<-cbind(dataBeheer, dataAdaptiefOnderhoud)
X
dataBeheer dataAdaptiefOnderhoud
Normering
34.5
43.5
EDMS
55.0
10.0
PUR
19.0
58.0
ODS
38.0
34.0
IMF
35.0
37.0
RESA/FASA
33.0
38.0
EW/BWS
44.0
29.0
GCU
32.0
47.0
Arbototaal
39.0
33.0
GEFIS
54.0
15.0
SBB
28.0
23.0
NEA
37.0
29.0
RING
38.0
28.0
cov(X)
dataBeheer dataAdaptiefOnderhoud
dataBeheer
93.49359
-102.8622
dataAdaptiefOnderhoud -102.86218
165.1410
cor(X)
dataBeheer dataAdaptiefOnderhoud
dataBeheer
1.0000000
-0.8278227
dataAdaptiefOnderhoud -0.8278227
1.0000000
Bevinding
Covariantie: De variabelen Beheer en Adaptief Onderhoud hebben een negatieve
covariantie (-102.8622). Dit zou kunnen betekenen dat beide variabelen niet
gezamenlijk zullen stijgen of dalen.
Correlatie: We zien hier voor het eerst een bevestiging van het feit dat er tussen
Beheer en Adaptief Onderhoud negatieve correlatie (-0.8278227) is. Op een schaal
van -1 tot 0 is de negatieve correlatie aan de hoge kant. Een vermeerdering van
Beheer zal dus leiden tot een vermindering van Adaptief Onderhoud.
Berekening correlatie/covariantie: Adaptief Onderhoud en Helpdesk van een
applicatie
dataAdaptiefOnderhoud <-data[,2]
dataHelpdesk <-data[,4]
X<-cbind(dataAdaptiefOnderhoud, dataHelpdesk)
X
dataAdaptiefOnderhoud dataHelpdesk
Normering
43.5
12
EDMS
10.0
9
PUR
58.0
4
ODS
34.0
4
IMF
37.0
2
RESA/FASA
38.0
2
EW/BWS
29.0
6
GCU
47.0
4
Arbototaal
33.0
7
GEFIS
15.0
12
SBB
23.0
32
NEA
29.0
5
RING
28.0
3
44
© Getronics PinkRoccade 2007
Case Study
cov(X)
dataAdaptiefOnderhoud
dataHelpdesk
dataAdaptiefOnderhoud dataHelpdesk
165.14103
-38.55769
-38.55769
63.97436
cor(X)
dataAdaptiefOnderhoud
dataHelpdesk
dataAdaptiefOnderhoud dataHelpdesk
1.0000000
-0.3751289
-0.3751289
1.0000000
Bevinding
Covariantie: De variabelen Adaptief Onderhoud en Helpdesk hebben een negatieve
covariantie (-38.55769). Dit zou kunnen betekenen dat beide variabelen niet
gezamenlijk zullen stijgen of dalen.
Correlatie: We zien hier voor het eerst een bevestiging van het feit dat er tussen
Beheer en Adaptief Onderhoud positieve correlatie (-0.3751289) is. Op een schaal
van -1 tot 0 is de negatieve correlatie aan de lage kant. Een vermeerdering van
Beheer zal dus leiden tot een vermindering van Adaptief Onderhoud.
Correlatie tussen alle dimensies
dataBeheer<-data[,1]
dataAdaptiefOnderhoud<-data[,2]
dataServiceManagement<-data[,3]
dataHelpdesk<-data[,4]
all<-cbind(dataBeheer, dataAdaptiefOnderhoud, dataServiceManagement, dataHelpdesk)
cor(all)
dataBeheer dataAdaptiefOnderhoud dataServiceManagement dataHelpdesk
dataBeheer
1.00000000
-0.8278227
0.2617505 -0.03895645
dataAdaptiefOnderhoud -0.82782267
1.0000000
-0.3564982 -0.37512894
dataServiceManagement 0.26175054
-0.3564982
1.0000000 -0.46660608
dataHelpdesk
-0.03895645
-0.3751289
-0.4666061
1.00000000
Bevinding
De correlaties laten zien dat er een positieve correlatie bestaat tussen: Alleen
tussen Beheer en Service Management.
De correlaties laten zien dat er een negatieve correlatie bestaat tussen: Beheer en
Adaptief Onderhoud, Beheer en Helpdesk, Adaptief Onderhoud en Service
Management, Adaptief Onderhoud en Helpdesk, Service Management en Helpdesk.
cov(all)
dataBeheer dataAdaptiefOnderhoud dataServiceManagement dataHelpdesk
dataBeheer
93.493590
-102.86218
14.70192
-3.012821
dataAdaptiefOnderhoud -102.862179
165.14103
-26.61218
-38.557692
dataServiceManagement
14.701923
-26.61218
33.74359
-21.679487
dataHelpdesk
-3.012821
-38.55769
-21.67949
63.974359
Bevinding
De covarianties laten zien dat er een positieve covariantie bestaat tussen: Beheer
en Service Management
De covarianties laten zien dat er een negatieve covariantie bestaat tussen: Beheer
en Adaptief Onderhoud, Beheer en Helpdesk, Adaptief Onderhoud en Service
Management, Adaptief onderhoud en Helpdesk, Service Management en Helpdesk.
© Getronics PinkRoccade 2007
45
Case Study
Stars plot
Stars(data)
Normering
EDMS
PUR
ODS
IMF
RESA/FASA
EW/BWS
GCU
Arbototaal
GEFIS
SBB
NEA
RING
Figuur 5.4 Stars plot
Uit bovenstaande figuur kunnen we zien welke contracten goed met elkaar te vergelijken
zijn, dat zou kunnen betekenen dat deze contracten ongeveer dezelfde percentuele
verdeling hebben.
Bevinding
De volgende applicaties zijn goed met elkaar te vergelijken:
o
o
o
o
o
ODS, EW/BWS, Arbototaal, NEA, RING, IMF en RESA/FASA.
EDMS en GEFIS
GCU en Normering
PUR
SBB
Als we kijken naar onze dataset en EDMS en GEFIS met elkaar vergelijken, zien we
hieronder dat de verdeling tussen beide contracten redelijk met elkaar overeenkomen. Dit
zien we ook terug in figuur 5.4, waarbij de plots redelijk veel op elkaar lijken.
(2) EDMS
(10) GEFIS
46
BH
55
54
AO
10
15
SM
26
19
HD
9
12
© Getronics PinkRoccade 2007
Case Study
5.3.2 Principal Component Analyse
pairs(data, panel=panel.smooth)
pcom<-princomp(data,cor=TRUE)
pcom
Call:
princomp(x = data, cor = TRUE)
Standard deviations:
Comp.1
Comp.2
Comp.3
Comp.4
1.42063758 1.20948712 0.71989186 0.02618212
4
variables and
13 observations.
Herhaling: variantie is de kwadraat van de standaardafwijking, een statistische maat voor de spreiding
van een verschijnsel [VAN DALE] .
Bevinding
De varianties aangeven door de Componenten wijzen aan dat er een kleine knik
(elleboog) ligt bij Comp.3. `Comp.x` staat voor de variabele (BH, AO, SM en HD),
alleen zijn deze bepaald op spreiding. Comp.1 heeft de hoogste variantie (spreiding
van de data) en Comp.4 heeft de laagste variantie.
Screeplot PC
screeplot(pcom,type="lines")
Figuur 5.5 Screeplot PC
Bevinding
Uit de screeplot blijkt dat er een kleine knik bij Comp.3 ligt. De variantie is alleen
niet hoog genoeg bij Comp.2 en Comp.3 om gezamenlijk onderscheid te maken
tussen de verkregen data. Dit heeft vooral te maken met de spreiding van de data
bij elke variabele, de spreiding toont minder verschil onderling met de variabelen.
© Getronics PinkRoccade 2007
47
Case Study
Indien de data meer van elkaar zou verschillen, zouden we een veel duidelijker
knik zien in het figuur hierboven.
loadings(pcom)
Loadings:
Comp.1 Comp.2 Comp.3
Beheer
0.639
0.580
Adaptief Onderhoud -0.669 -0.238 0.154
Service Management 0.376 -0.582 -0.651
Helpdesk
0.777 -0.464
SS loadings
Proportion Var
Cumulative Var
Comp.4
-0.504
-0.687
-0.310
-0.422
Comp.1 Comp.2 Comp.3 Comp.4
1.00
1.00
1.00
1.00
0.25
0.25
0.25
0.25
0.25
0.50
0.75
1.00
Scoreplot PC
plot(pcom$scores, type="n")
text(pcom$scores[,1], pcom$scores[,2],1:13)
2
3
11
10
1
Comp.2
1
2
8
0
9
7
3
4
-1
12
6 5
13
-3
-2
-1
0
1
2
Comp.1
Figuur 5.6 Scoreplot PC
Deze plot laat de variantie zien in de geadministreerde uren van de verschillende
contracten zien over de eerste twee Componenten.
Bevinding
Hier vinden we een spreiding van alle contracten opgesteld op basis van de
variantie van de eerste twee componenten. Contracten die een zelfde soort
variantie hebben, liggen ook dichter bij elkaar. Dus hieruit kunnen we concluderen
dat sommige contracten een zelfde soort percentuele verdeling hebben. GEFIS en
EDMS liggen relatief ook dicht bij elkaar in het figuur, want de nummers stellen de
contracten voor (EDMS is nummer 2 en GEFIS is nummer 10).
48
© Getronics PinkRoccade 2007
Case Study
Biplot
biplot(pcom)
-2
0
2
4
0.6
4
SBB
2
0.4
Helpdesk
Normering
EDMS
Beheer
Arbototaal
EW/BWS
efPUR
Onderhoud
0
GCU
0.0
ODS
NEA
-0.4
IMF
RESA/FASA
RING
-2
-0.2
Comp.2
0.2
GEFIS
-0.6
Service Management
-0.6
-0.4
-0.2
0.0
0.2
0.4
0.6
Comp.1
Figuur 5.7 Biplot
Met bovenstaande figuur kunnen exact opmaken welke variabelen, veel invloed hebben op
de positionering van de contracten. Verder zien we ook welke contracten dicht bij elkaar
liggen. De positionering heeft te maken met de waardes die horen bij elk contract. De
variabelen zijn in het rood aangegeven. EDMS staat bijvoorbeeld dichtbij de variabele
Beheer, dat betekent dat EDMS veel uren gereserveerd heeft voor Beheer. Dat klopt ook
met de werkelijke dataset, want EDMS heeft hier 55% van de totale uren voor
gereserveerd.
Bevinding
Één variabele die invloed heeft op de positie van contracten:
o De variabele BH heeft veel invloed op de positie van EDMS
o De variabele AO heeft veel invloed op de positie van PUR
o De variabele SM heeft veel invloed op de positie van RING
o De variabele HD heeft veel invloed op de positie van SBB
Twee variabelen die invloed hebben op contracten:
o De variabele BH & SM hebben veel invloed op de
o De variabele SM & AO hebben veel invloed op de
RESA/FASA, ODS en NEA
o De variabele AO & HD hebben veel invloed op de
Normering
o De variabele HD & BH hebben veel invloed op de
positie van EW/BWS
positie van IMF,
positie van GCU,
positie van GEFIS
Alle variabelen die invloed hebben op contracten:
o Alle variabeles hebben veel invloed op de positie van Arbototaal
© Getronics PinkRoccade 2007
49
Case Study
5.3.3 Cluster Analyse
Binnen deze paragraaf gaan we contracten clusteren, het samenbrengen in groepen met
gemeenschappelijke eigenschappen of kenmerken [VAN DALE]. Deze gemeenschappelijke
eigenschappen zijn gebaseerd op de variabelen die invloed hebben op de positie van de
contracten in figuur 5.7.
stdata<-data
for(i in 1:4){
pti<-data[,i]
stdata[,i]<-(pti-mean(pti))/
sqrt(var(pti))}
distdata<-dist(stdata)
Multidimensional scaling
3
mds<-cmdscale(distdata)
plot(mds,type="n",xlab="",ylab="",axes=TRUE)
applicaties<-c("Normering", "EDMS", "PUR", "ODS", "IMF", "RESA/FASA", "EW/BWS", "GCU",
"Arbototaal", "GEFIS", "SBB", "NEA", "RING")
text(mds,applicaties)
2
SBB
Normering
1
GEFIS
EDMS
GCU
0
Arbototaal
EW/BWS
PUR
ODS
-1
NEA
IMF
RESA/FASA
RING
-3
-2
-1
0
1
2
Figuur 5.8 MDS
Bevinding
Deze plot laat de ‘Euclidean’ afstanden (geometrische afstanden) zien tussen de
contracten. Wij kunnen 4 clusters hieruit opmaken: (Normering en GCU), (GEFIS
en EDMS), (Arbototaal en EW/BWS) en (RESA/FASA, IMF, ODS, NEA en RING)
opmaken en twee uitschieters PUR en SBB.
50
© Getronics PinkRoccade 2007
Case Study
Hiërarchische clustering
clustobj<-hclust(distdata,method="complete")
plot(clustobj)
5
Cluster Dendrogram
PUR
2
4 Clusters
RESA/FASA
IMF
ODS
RING
NEA
Arbototaal
EW/BWS
GEFIS
EDMS
GCU
0
Normering
1
Height
3
SBB
4
3 Clusters
distdata
hclust (*, "complete")
Figuur 5.9 Complete Linkage
clustobj<-hclust(distdata,method=”average”)
plot(clustobj)
3
SBB
4
Cluster Dendrogram
2 Clusters
3 Clusters
Figuur 5.10 Average
RESA/FASA
IMF
ODS
RING
NEA
Arbototaal
EW/BWS
GEFIS
EDMS
GCU
Normering
0
1
Height
PUR
2
4 Clusters
distdata
hclust (*, "average")
© Getronics PinkRoccade 2007
51
Case Study
clustobj<-hclust(distdata,method="single")
plot(clustobj)
SBB
1 Cluster
2 Clusters
PUR
Figuur 5.11 Single Linkage
GCU
Normering
Arbototaal
EW/BWS
RESA/FASA
IMF
ODS
RING
NEA
GEFIS
EDMS
1.0
0.0
0.5
Height
1.5
2.0
2.5
3.0
Cluster Dendrogram
distdata
hclust (*, "single")
Binnen hiërarchisch clustering vinden we de onderverdeling van de clusters.
Bevinding
Figuur 5.9 Complete Linkage – Heeft 3 tot 4 clusters en is gebaseerd op de
grootste afstand tussen buren, tevens geeft deze figuur het beste de verschillen
weer tussen de clusters. Deze indeling komt overeen met multidimensional scaling
uit figuur 5.8 en de clusters die we daar gemaakt hebben komen redelijk overeen
met de bevindingen in figuur 5.9.
Figuur 5.10 Average – Heeft 2 tot 4 clusters en is gebaseerd op de gemiddelde
afstand tussen buren.
Figuur 5.11 Single Linkage – Heeft 1 tot 2 clusters en is gebaseerd op de kleinste
afstand met buren. Dit is de minst geschikte methode voor het toewijzen van
clusters, wat overigens ook terug te zien is in het figuur.
52
© Getronics PinkRoccade 2007
Case Study
K-means clustering
datamat<-as.matrix(data[,1:4])
pairs(datamat)
30
40
50
5 10
20
30
40
50
10 20
40
50
20
30
Beheer
25
30
10
20 30
Adaptief Onderhoud
20
30
10
15
20
Service Management
5 10
Helpdesk
20
30
40
50
10
15
20
25
30
Figuur 5.12 K-means clustering
km<kmeans(datamat,centers=3,iter.max=500)
plot(datamat[,c(1,2)], type="n",xlab="Beheer", ylab="Adaptief Onderhoud")
text(datamat[,1], datamat[,2],km$cluster)
50
1
1
40
3
3
3
30
Adaptief Onderhoud
1
3
3
3
3
20
2
10
2
2
20
25
30
35
40
45
50
55
Beheer
Figuur 5.13 K-means BH en AO
© Getronics PinkRoccade 2007
53
Case Study
plot(datamat[,c(1,3)], type="n",xlab="Beheer", ylab="Service Management")
text(datamat[,1], datamat[,3],km$cluster)
30
3
3
3
2
3
20
3
3
2
1
2
15
Service Management
25
3
10
1
1
20
25
30
35
40
45
50
55
Beheer
Figuur 5.14 K-means BH en SM
plot(datamat[,c(2,4)], type="n",xlab="Adaptief Onderhoud", ylab="Helpdesk")
text(datamat[,2], datamat[,4],km$cluster)
Helpdesk
15
20
25
30
2
1
10
2
2
5
3
3
3
1
3
3
1
33
10
20
30
40
50
Adaptief Onderhoud
Figuur 5.15 K-means AO en HD
Bevinding
Bij K-means clustering met 3 gekozen centers, hebben we geconstateerd dat er
relatief veel onderscheid is tussen de waarnemingen. Uit figuren 5.13 tot en met
5.15 zien we dat bij verschillende variabelen er constant 3 contracten tot cluster 1
behoren, 3 contracten tot cluster 2 en 7 contracten tot cluster 3. Wanneer we meer
clusters nemen zou dit niet veranderen aangezien dit een iteratief proces is. Het
zijn in principe 3 clusters, waar de contracten bij horen. Deze techniek zegt iets
over de clusters wanneer we steeds 2 variabelen analyseren. Deze zijn terug te
zien in figuren 5.13 t/m 5.15 en de verschillen tussen de variabelen blijven groot,
aangezien ze tot 3 verschillende clusters toegewezen worden. We hebben
uiteindelijk ook 4 urenposten, die al veel verschillen van elkaar. Ook met twee
variabelen kunnen we uiteindelijk 3 clusters opmaken.
54
© Getronics PinkRoccade 2007
Case Study
5.3.4 Lineaire Regressie
Kan het aantal Beheer (BH) uren voorspeld worden aan de hand van Service Management
(SM)? Uit voorgaande bevindingen zagen we dat de twee variabelen BH en SM zowel
positieve covariantie hadden als positieve correlatie. Dit is ook de reden voor de keuze van
deze twee variabelen, aangezien enig verband tussen variabelen noodzakelijk is voor een
eventuele voorspelling.
Single linear regression
20
10
15
Service Management
25
30
plot(data[,1],data[,3],xlab="Beheer", ylab="Service Management")
20
25
30
35
40
45
50
55
Beheer
Figuur 5.16 Single Lineair
Bevinding
We zien dat de data enorm verspreid is waardoor er geen duidelijke lijn in ligt. We
willen uiteindelijk kunnen bepalen of een variabele voorspelt kan worden. Op basis
van de weergave uit bovenstaande figuur, kunnen we deels concluderen dat een
formule voor het spellen van een andere variabele niet geschikt zal zijn.
dfdata<-data.frame(data)
data.lm<-lm(Beheer~Service.Management, data=dfdata)
coefficients(data.lm)
(Intercept) Service.Management
27.8712956
0.4356953
plot(dfdata$Beheer,dfdata$Service.Management,xlab="Beheer", ylab="Service Management",
abline(coefficients(data.lm)))
summary(data.lm)
Call:
lm(formula = Beheer ~ Service.Management, data = dfdata)
Residuals:
Min
1Q
-16.714 -4.199
Median
-3.278
3Q
2.415
Max
17.850
Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept)
27.8713
10.9578
2.544
0.0273 *
Service.Management
0.4357
0.4844
0.899
0.3877
--Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
Residual standard error: 9.747 on 11 degrees of freedom
Multiple R-Squared: 0.06851,
Adjusted R-squared: -0.01617
© Getronics PinkRoccade 2007
55
Case Study
F-statistic: 0.8091 on 1 and 11 DF,
qqnorm(residuals(data.lm))
p-value: 0.3877
5
0
-5
-15
-10
Sample Quantiles
10
15
Normal Q-Q Plot
-1.5
-1.0
-0.5
0.0
0.5
1.0
1.5
Theoretical Quantiles
Figuur 5.17 Q-Q Plot
Bevinding
Het figuur hierboven toont aan hoe de data eruit zou zien, wanneer de verdeling
perfect normaal verdeeld zou zijn. Hoe dichter bij de lijn, des te meer normaal
verdeeld de data zou zijn. De Q-Q plot laat overigens grofweg zien hoe de data
gezamenlijk verdeeld zou zijn.
Voorspelling functie: Beheer = 27,8713 + 0,4357 (x Service.Management) +10
Bij Service Management van 25 % zou Beheer (48,7638≈) 49 % zijn op basis van
onze data. Alleen weten we dat de data alsnog verschillen van elkaar en zou deze
formule alleen als richtlijn kan gelden. Op deze manier zou je eventueel Beheer
kunnen voorspellen, voor de overige data is zouden we ook eventueel een formule
kunnen maken. Alleen weten we al dat de data in het algemeen weinig correlatie
met elkaar hebben.
56
© Getronics PinkRoccade 2007
Case Study
Multiple lineaire regressie
pairs(data)
30
40
50
5 10
20
30
40
50
10 20
40
50
20
30
Beheer
25
30
10
20 30
Adaptief Onderhoud
20
30
10
15
20
Service Management
5 10
Helpdesk
20
30
40
50
10
15
20
25
30
Figuur 5.18 Multiple Lineair
summary(data)
Beheer
Min.
:19.00
1st Qu.:33.00
Median :37.00
Mean
:37.42
3rd Qu.:39.00
Max.
:55.00
Adaptief Onderhoud
Min.
:10.00
1st Qu.:28.00
Median :33.00
Mean
:32.65
3rd Qu.:38.00
Max.
:58.00
Service Management
Min.
:10.00
1st Qu.:18.00
Median :22.00
Mean
:21.92
3rd Qu.:26.00
Max.
:31.00
Helpdesk
Min.
: 2.000
1st Qu.: 4.000
Median : 5.000
Mean
: 7.846
3rd Qu.: 9.000
Max.
:32.000
round(cor(data),2)
Beheer
Adaptief Onderhoud
Service Management
Helpdesk
Beheer Adaptief Onderhoud Service Management Helpdesk
1.00
-0.83
0.26
-0.04
-0.83
1.00
-0.36
-0.38
0.26
-0.36
1.00
-0.47
-0.04
-0.38
-0.47
1.00
Bevinding
Zoals we al eerder aangaven zien we ook hierin terug dat Beheer en Service
Management positieve correlatie met elkaar ondervinden. Verder zagen we dat de
positieve correlatie niet aan de hoge kant lag, waardoor onze voor voorspelling
minder waarde zal hebben.
Uit de summary zien we de verdeling van alle data en het opvallende is dat we als
het ware een nieuwe percentuele verdeling kunnen maken op basis van de
gegevens die we hebben gekregen. We nemen vervolgens de gemiddelden per
© Getronics PinkRoccade 2007
57
Case Study
variabele, waardoor we de volgende verdeling krijgen, de percentuele verdeling
volgens de data die we hebben gekregen:
Normering
Normering op basis van data
BH AO SM HD
34.5 43.5 10
12
37.4 32.7 21.9 7.8
Tabel 5.19 normering op basis van data
Uit bovenstaande tabel kunnen we concluderen dat er verschillen zitten tussen de
contracten en de normering die we hebben gehanteerd. Waar zouden deze
afwijkingen en spreidingen aan kunnen liggen? Dit gaan we in hoofdstuk 6 bij de
validatie trachten te verklaren.
Linear model (Beheer)
dfdata<-data.frame(data)
data.lm<-lm(formula = Beheer~Adaptief.Onderhoud + Service.Management +
Helpdesk,data=dfdata)
coefficients(data.lm)
(Intercept) Adaptief.Onderhoud Service.Management
Helpdesk
101.061010
-1.022541
-1.018755
-1.008619
summary(data.lm)
Call:
lm(formula = Beheer ~ Adaptief.Onderhoud + Service.Management +
Helpdesk, data = dfdata)
Residuals:
Min
1Q
-0.8817 -0.2704
Median
0.1774
3Q
0.2105
Max
1.0570
Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept)
101.06101
1.60344
63.03 3.21e-13 ***
Adaptief.Onderhoud -1.02254
0.01844 -55.46 1.01e-12 ***
Service.Management -1.01876
0.04275 -23.83 1.93e-09 ***
Helpdesk
-1.00862
0.03129 -32.23 1.31e-10 ***
--Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
Residual standard error: 0.5793 on 9 degrees of freedom
Multiple R-Squared: 0.9973,
Adjusted R-squared: 0.9964
F-statistic: 1112 on 3 and 9 DF, p-value: 7.037e-12
Bevinding
R2 = 0.9973. De waarde van R ligt dicht in de buurt van 1. Dit zou betekenen dat
we meer dan 99 % van de variantie kunnen verklaren met het model. We kunnen
bijna met zekerheid de spreiding van de waardes van Beheer verklaren. Om een
eventuele voorspelling te doen heb je alle variabelen nodig.
58
© Getronics PinkRoccade 2007
Case Study
rg<-residuals(data.lm)
pg<-predict(data.lm)
plot(pg,rg,type="n",xlab="predicted Beheer",ylab="residuals")
text(pg,rg,1:13)
7
1.0
0.5
8
res
idu
als
5
1 1213
4
11
0.0
10 2
0.5
3
6
9
20
25
30
35
40
45
50
55
predicted Beheer
Figuur 5.20 Residual Beheer
qqnorm(rg)
0.0
-1.0
-0.5
Sample Quantiles
0.5
1.0
Normal Q-Q Plot
-1.5
-1.0
-0.5
0.0
0.5
1.0
1.5
Theoretical Quantiles
Figuur 5.21 Q-Q plot Beheer
Bevinding
Residuals zijn observeerbare schattingen van een niet observeerbare foutmelding,
oftewel de standaardafwijking van het gemiddelde. In figuur 5.20 zien we aan de
hand van de residuals, het aantal voorspelde beheeruren per contract. Op de x-as
zien we de beheeruren en op de y-as zien we de residuals. Ook hier zullen
contracten die dicht bij elkaar staan ongeveer dezelfde verdeling hebben.
© Getronics PinkRoccade 2007
59
Case Study
De Q-Q plot (figuur 5.21) laat zien dat de residuals normaal verdeeld zijn,
overigens wordt er weergegeven dat de residuals dezelfde variantie hebben
(homoscedasticity).
Linear model (Adaptief Onderhoud)
data.lm<-lm(formula =
Adaptief.Onderhoud~Beheer+Service.Management+Helpdesk, data=dfdata)
summary(data.lm)
R-Squared(R^2): 0.9985
stepdata<-step(data.lm,direction="both")
Start: AIC= -11.59
Adaptief.Onderhoud ~ Beheer + Service.Management + Helpdesk
Df Sum of Sq
<none>
- Service.Management
- Helpdesk
- Beheer
1
1
1
RSS
AIC
2.88 -11.59
291.40 294.28 46.55
579.19 582.07 55.42
984.23 987.11 62.29
Bevinding
R2 = 0.9985. De waarde R2 ligt dicht in de buurt van 1. Dit betekent dat we meer
dan 99% van de variantie kunnen verklaren met het model.
Om Adaptief.Onderhoud te bepalen/voorspellen zijn de variabelen; Beheer,
Service.Management en Helpdesk nodig. We hebben hier alle beschikbare
variabelen voor nodig, aangezien er niet direct samenhang is tussen variabelen.
Linear model (Service Management)
data.lm<-lm(formula =
Service.Management~Beheer+Adaptief.Onderhoud+Helpdesk, data=dfdata)
summary(data.lm)
R-Squared(R^2):0.9929
stepdata<-step(data.lm,direction="both")
Start: AIC= -11.66
Service.Management ~ Beheer + Adaptief.Onderhoud + Helpdesk
Df Sum of Sq
<none>
- Beheer
- Adaptief.Onderhoud
- Helpdesk
1
1
1
RSS
AIC
2.86 -11.66
180.76 183.62 40.42
289.84 292.70 46.48
349.16 352.03 48.88
Bevinding
R2 = 0.9929. De waarde R2 ligt dicht in de buurt van 1. Dit betekent dat men meer
dan 99% van de variantie kunnen verklaren met het model.
Om Service.Management te bepalen/voorspellen zijn de variabelen; Beheer,
Adaptief.Onderhoud en Helpdesk nodig. Ook hier hebben we alle variabelen nodig.
60
© Getronics PinkRoccade 2007
Case Study
Linear model (Helpdesk)
data.lm<-lm(formula =
Helpdesk ~Beheer+Adaptief.Onderhoud+Service.Management, data=dfdata)
summary(data.lm)
R-Squared(R^2): 0.9962
stepdata<-step(data.lm,direction="both")
Start: AIC= -11.31
Helpdesk ~ Beheer + Adaptief.Onderhoud + Service.Management
Df Sum of Sq
<none>
- Beheer
- Service.Management
- Adaptief.Onderhoud
1
1
1
RSS
AIC
2.94 -11.31
339.75 342.70 48.53
358.75 361.70 49.24
591.90 594.85 55.70
Bevinding
R2 = 0.9962. De waarde R2 ligt dicht in de buurt van 1. Dit betekent dat men meer dan
99% van de variantie kunnen verklaren met het model.
Om Helpdesk te bepalen/voorspellen zijn de variabelen; Beheer, Adaptief.Onderhoud en
Service.Management nodig. Ook hier hebben we alle variabelen nodig.
De lineaire modellen per variabele zijn geschikt voor het verklaren van voorspellingen, die
gedaan kunnen worden. Achteraf bleek dat deze methode niet geschikt is voor onze
dataset. Zo heb je voor elke variabele, alle resterende variabelen nodig. Dit komt doordat
er lage positieve en lage negatieve correlatie is tussen de data.
5.4 Statistisch Onderzoek Normverdeling
We kunnen net als in de vorige paragraaf m.b.v. de voorbeeld verdeelsleutel voor een
contract uit figuur 4.10 een dataset creëren die alle uren per ASL proces zal bevatten. Het
gaat in dit geval om alle urenposten van de normverdeling beheeruren. We zullen hierbij
alleen de stappen 1 en 2 volgen. Bij elk contract krijgen we dan de volgende 12
variabelen, IncidentM, ConfigurationM, AvailabilityM, CapacityM, ContinuityM, ChangeM,
SoftwareControl, CorretiefO, PreventiefO, PerfectiefO, TactischM, StrategischM. We zullen
hier een aantal technieken op gaan toepassen, om erachter te komen of er ook enig
samenhang in de variabelen zal zijn. Verder willen we weten of de clusters overeenkomen
met de clusters uit de voorgaande paragraaf, waar we een dataset hadden gecreëerd op
basis van de minimale set aan urenposten met 4 variabelen.
Dataset
(zonder decimalen)
(horizontaal alle ASL processen)
(verticaal alle contracten)
(eerste rij bevat de Normverdeling Beheeruren zoals deze verdeeld is in tabel 1.1)
12
124
101
483
377
524
92
272
2625
309
2598
126
51
5
124
101
1852
2209
4086
59
950
10800
283
557
126
51
15
124
101
483
377
524
59
272
1000
472
567
126
51
3
124
101
483
377
524
466
272
1000
188
195
126
51
© Getronics PinkRoccade 2007
5
124
101
483
377
524
59
272
750
305
557
126
51
2
110
378
1370
1832
3562
112
769
1625
202
726
274
105
5
110
378
1370
1832
3562
466
678
11550
485
1284
274
105
13
8
378
483
377
524
59
769
1800
16
299
87
250
13
8
378
1370
1832
3562
59
769
1800
16
299
207
50
13
8
378
1370
1832
3562
59
769
1800
16
299
207
50
10
226
101
1852
2209
4086
112
322
625
167
428
487
406
3
226
101
1852
2209
4086
0
322
625
167
428
487
406
61
Case Study
Correlatie tussen alle dimensies
dataIncidentM<-data[,1]
dataConfigurationM<-data[,2]
dataAvailabilityM<-data[,3]
dataCapacityM<-data[,4]
dataContinuityM<-data[,5]
dataChangeM<-data[,6]
dataSoftwareControl<-data[,7]
dataCorretiefO<-data[,8]
dataPreventiefO<-data[,9]
dataPerfectiefO<-data[,10]
dataTactischM<-data[,11]
dataStrategischM<-data[,12]
all<-cbind(dataIncidentM, dataConfigurationM, dataAvailabilityM, dataCapacityM,
dataContinuityM, dataChangeM, dataSoftwareControl, dataCorretiefO, dataPreventiefO,
dataPerfectiefO, dataTactischM, dataStrategischM)
cor(all)
Bevinding
We kunnen uit het bovenstaande concluderen dat alle variabelen onderling
positieve correlatie hebben. Dit zal hoogstwaarschijnlijk komen door het feit dat we
tijdens stap 1 van de voorbeeld verdeelsleutel voor een contract, handmatig en
gelijk de uren over de vinkjes hebben verdeeld. Zo krijgen we waardes achter de
ASL processen, waarbij sommige ASL processen dezelfde waardes hebben. Dit zou
grotendeels de positieve correlatie verklaren, tevens tonen we hiermee ook aan dat
de nieuwe dataset minder geschikt is voor het verklaren van samenhang tussen
variabelen.
62
© Getronics PinkRoccade 2007
Case Study
Multidimensional scaling
4
mds<-cmdscale(distdata)
plot(mds,type="n",xlab="",ylab="",axes=TRUE)
applicaties<-c("Normering", "EDMS", "PUR", "ODS", "IMF", "RESA/FASA", "EW/BWS", "GCU",
"Arbototaal", "GEFIS", "SBB", "NEA", "RING")
text(mds,applicaties)
2
Arbotota
0
SBB
GEFIS
GCU
EW/BWS
PUR
EDMS
ormering
RING
NEA
ODS
-2
IMF
RESA/FASA
-2
0
2
4
6
Figuur 5.22 MDS ASL processen
Bevinding
In tegenstelling tot figuur 5.8 zien we in figuur 5.22 andere clusters. We zien 3
clusters: (EW/BWS, Normering, PUR, RING, EDMS en NEA), (GEFIS en GCU),
(ODS en IMF) en drie uitschieters SBB, Arbototaal en RESA/FASA. Opmerkelijk is
dat meerdere contracten overeenkomen met de normverdeling van beheeruren.
We zagen al dat de nieuwe dataset minder geschikt was om correlatie te meten.
De variabelen tonen onderling ook veel samenhang, aangezien we tijdens onze
verdeelsleutel (4.10) de uren gelijkmatig hebben verdeeld over de vinkjes.
Wat we hieruit kunnen concluderen is: Hoe meer urenposten we nemen, des te
minder onderscheid er tussen de variabelen zijn en des te meer contracten met de
normverdeling overeenkomen.
© Getronics PinkRoccade 2007
63
Case Study
Hiërarchische clustering
clustobj<-hclust(distdata,method="complete")
plot(clustobj)
Arbototaal
SBB
4
3 Clusters
IMF
3 Clusters
ODS
GEFIS
GCU
NEA
EDMS
RING
PUR
Normering
EW/BWS
0
2
Height
6
RESA/FASA
8
10
Cluster Dendrogram
distdata
hclust (*, "complete")
Figuur 5.23 Complete Linkage ASL
Bevinding
Net als in figuur 5.22 zien we dezelfde drie clusters.
De overige technieken zijn naar onze mening niet geschikt voor onze dataset. De
normering vormt overigens meer correlatie met andere contracten, waardoor er als het
ware een nieuwe grote cluster (EW/BWS, Normering, PUR, RING, EDMS en NEA) uit
voortvloeit.
64
© Getronics PinkRoccade 2007
Case Study
5.5 Afronding en evaluatie Case Study
We hebben in paragraaf 5.3 en 5.4 de huidige situatie van contracten binnen de
organisatie statistisch geanalyseerd en in kaart gebracht. Hiermee wilden we weten in
hoeverre de contracten afwijkingen vertoonden t.o.v. van de nieuwe normering (tabel 5.1)
met de 4 urenposten. We hebben hierdoor ook de nieuwe normering meegenomen in onze
dataset. We zullen hieronder de uitkomsten van de verschillende technieken nog een keer
samenvatten.
Representatie en visualisatie technieken
Allereerst hebben we gekeken naar de correlatie tussen de variabelen. Hieruit konden we
opmaken dat alleen de variabelen BH en SM positieve correlatie en positieve covariantie
hebben. Volgens onze dataset zou dus een stijging van BH uren kunnen leiden tot een
stijging van de SM uren. Het opvallende was wel dat de positieve correlatie aan de lage
kant zou liggen. Verder is er sprake van positieve covariantie, waarbij beide variabelen
gezamenlijk zullen stijgen of dalen. De overige variabelen hadden allemaal een negatieve
correlatie onderling. Uit figuur 5.3 konden we opmaken welke variabelen goed met elkaar
te vergelijken waren. De stars plot gaf ons een visuele weergave van alle contracten,
waarbij elk contract een speciale vorm had gekregen. De figuren die het meest op elkaar
leken, zouden goed met elkaar te vergelijken zijn. De contracten (ODS, EW/BWS,
Arbototaal, NEA, RING, IMF en RESA/FASA) leken veel op elkaar. De contracten (EDMS en
GEFIS) leken ook veel op elkaar, net als (GCU en Normering). De contracten PUR en SBB
zagen er totaal verschillend uit en behoorden niet tot een bepaalde groepering.
Principal component analyse technieken
Bij de variantie oftewel de spreiding van de variabelen zien we weinig verschil in de
variabelen. Dit betekent dat er relatief weinig onderscheid is tussen de gegevens die horen
bij de variabelen in de screeplot (figuur 5.5). We zagen ook dat contracten die een zelfde
soort variantie hadden, dichter bij elkaar stonden in de scoreplot (figuur 5.6). Een
conclusie die we hieruit konden trekken is het feit dat contracten die dichter bij elkaar
staan, een soortgelijke percentuele verdeling hebben. Met de biplot (figuur 5.7) hebben we
voor een deel kunnen verklaren welke variabelen veel invloed hebben op bepaalde
contracten. Zo hebben we de uitslag hiervan in drie categorieën verdeeld: (1) één
variabele die invloed heeft op de positie van contracten, (2) twee variabelen die invloed
hebben op contracten en (3) alle variabeles die invloed hebben op contracten. Een
overzicht hiervan zou ons kunnen helpen bij de validatie in het volgende hoofdstuk, om
deze invloeden eventueel te kunnen verklaren.
Zo krijgen we bij (1) BH heeft invloed op EDMS, AO heeft invloed op PUR, SM heeft
invloed op RING en HD heeft invloed op SBB.
(2) BH & SM hebben invloed op EW/BWS, SM & AO hebben invloed IMF en RESA/FASA,
ODS en NEA, AO & HD hebben invloed GCU en Normering en HD & BH hebben invloed
GEFIS.
(3) BH, AO, SM en HD hebben invloed op Arbototaal.
Cluster analyse technieken
De cluster analyse technieken zijn belangrijk geweest in het visualiseren van clusters voor
contracten. Op deze manier konden we voor een groot deel zien welke contracten
ongeveer dezelfde verdeling gebruiken. De clusters die we hieruit konden opmaken zijn
nogmaals: (Normering en GCU), (GEFIS en EDMS), (Arbototaal en EW/BWS) en
(RESA/FASA, IMF, ODS, NEA en RING) en twee uitschieters PUR en SBB vormden geen
cluster. Deze uitkomst leek veel op de stars plot, alleen konden we hier alle
onderverdelingen in terugvinden. Zo zagen we dat Arbototaal en EW/BWS ook samen een
cluster vormen.
© Getronics PinkRoccade 2007
65
Case Study
Lineaire regressie technieken
Voor het voorspellen van variabelen hebben we twee variabelen nodig die een verband
met elkaar hebben. We hebben gekozen voor de variabelen Beheer en Service
Management. Uit figuur 5.16 zagen we dat er met de beschikbare gegevens geen goede
voorspelling gedaan kon worden vanwege de grote afwijkingen in de contracten. Echter
hebben we wel een voorspellingsfunctie kunnen aanmaken, alleen is deze formule geschikt
voor gebruik als we te maken hadden met een perfect normale verdeling (figuur 5.17).
De grote verschillen in de contracten t.o.v. de normering is terug te vinden in tabel 5.19.
Met de gegevens die we verzameld hebben, kunnen we een nieuwe normering hanteren.
Deze normering op basis van de data ziet er als volgt uit: BH=37.4, AO=32.7, SM=21.9 en
HD= 7.8.
Verder hebben we per variabele gekeken welke variabelen er nog nodig zijn om de
variantie te verklaren. Het opvallende hierbij was dat we alle variabelen nodig hadden om
de variantie per variabele te kunnen verklaren. Hiermee doelen we op het feit dat we alle
variabelen nodig hebben, om de breedte van de verdeling te kunnen verklaren.
Statistisch onderzoek normverdeling
De stappen 1 en 2 van de verdeelsleutel leveren een nieuwe basisset op, waarbij er achter
elke ASL proces een aantal beheeruren staan. Met dit onderzoek hebben we geprobeerd te
kijken of er ook correlatie was tussen de ASL processen. We hebben hier alle 12
urenposten van de normverdeling gebruikt. We zijn er snel achter gekomen dat alle
variabelen positief met elkaar gecorreleerd zijn. Dit kwam door het feit dat we alle uren
handmatig verdeeld hebben, waardoor sommige variabelen ook dezelfde uren hadden. De
nieuwe dataset is minder geschikt voor het verklaren van correlatie tussen variabelen,
waardoor het voor ons onderzoek weinig heeft opgeleverd. Naast de correlatie wilden we
ook de clusters gaan onderzoeken, om te kijken welke contracten vergelijkbaar zijn. We
kregen de volgende clusters: (EW/BWS, Normering, PUR, RING, EDMS en NEA), (GEFIS
en GCU), (ODS en IMF) en drie uitschieters SBB, Arbototaal en RESA/FASA. Het positieve
uit deze uitkomst is het feit dat meer contracten overeenkomen met de normering, de
normering bij de nieuwe dataset is de normverdeling van beheeruren uit tabel 1.1. We
krijgen hier geen bevestiging van de eerdere clusters die we hebben gekregen. Het gaat in
paragraaf 5.4 om totaal andere clusters dan in paragraaf 5.3. Dit heeft grotendeels te
maken met de verkregen nieuwe dataset en de verdeelsleutel (figuur 4.10), die tevens ook
meerdere variabelen bevatte. Het goede nieuws is dat er meer contracten overeenkomen
met de normering, indien we meerdere (12) urenposten hebben.
66
© Getronics PinkRoccade 2007
Validatie
6 Validatie
6.1 Inleiding
In hoofdstuk 2 en 3 hebben we de basis kennis vastgesteld, alvorens de doelstellingen te
bereiken. Vervolgens hebben we in hoofdstuk 4 het standaardisatieproces van de
urenposten beschreven. Hierna hebben we in hoofdstuk 5 een toepassing van de theorie
beschreven aan de hand van een case study. We hebben daarmee de huidige situatie
binnen de organisatie op papier gezet. In hoofdstuk 6 vind er terugkoppeling naar het
model plaats, aan de hand van de verkregen informatie uit hoofdstuk 5. Aan de hand van
deze terugkoppeling zullen we afwijkingen en spreidingen van contracten t.o.v. de
normering met 4 urenposten proberen te verklaren. Voor de validatie van het model zullen
we gebruik maken van de beschreven theorie uit hoofdstuk 2, 3 en de verkregen
informatie van de interviews. De spreidingen kunnen verklaard worden aan de hand van de
verkregen dataset.
6.2 Validatie Afwijkingen en Spreidingen
Binnen deze paragraaf zullen we afwijkingen van contracten t.o.v. de normering proberen
te verklaren. We zullen per cluster verklaren in hoeverre de percentuele verdeling afwijkt
van de normering. De clusters geven aan dat de contracten al gemeenschappelijke
kenmerken hebben, die uit onze Case Study naar voren zijn gekomen. Het gaat in dit
geval om de gemeenschappelijke variabele(n) die invloed hebben op contracten.
Daarnaast hadden we aan de hand van de vragenlijsten een tabel opgesteld met de
gegevens van contracten die onder een cluster vallen. De volledige vragenlijsten van de
interviews zijn terug te vinden in Appendix A. Verder zullen we de spreidingen verklaren
aan de hand van de informatie van de contracten, die we verkregen hebben met behulp
van de resultaten van de verdeelsleutel. Deze resultaten van de verdeelsleutel zijn terug te
vinden in Appendix B.
6.2.1 V-GQM (4) DATA COLLETION (2/2)
Binnen de V-GQM zijn we dan belandt in het tweede deel van de Data Collection stap. In
dit deel hebben we de gegevens uit de interviews verzameld per cluster.
Cluster 1
Invloed
Variabele
ODS
AO/SM
Leeftijd
(jaar)
Prog.taal/
2
.Net/Oracle
Markt
framework
Migratie
(Ja/nee)
Ministerie VWS*
nee
Functiepunten Beheerder
(jaar)
1.142
Vergoossen
(2005)
NEA
AO/SM
2
.Net
Semi Overheid
RING
AO
2
.Net
Gezondheidszorg
RESA/F
AO/SM
20
Cobol
Sociale
Verzekering
nee
Sociale
Verzekering
nee
IMF
AO/SM
16
Cobol
nee
-
Dekker
-
Dekker
4.500
Vergoossen
(1992)
1.810
Vergoossen
(2007)
*Volksgezondheid, Welzijn en Sport
Tabel 6.1 Cluster 1
© Getronics PinkRoccade 2007
67
Validatie
De bovenstaande 5 contracten hebben over het algemeen veel invloed van de variabele
AO. Dit zou betekenen dat er hiervoor in de verdeling per contract relatief meer uren
besteed worden aan AO en er in de percentuele verdeling een hogere percentage wordt
gereserveerd. Dit geldt ook voor de SM uren, waarbij deze uren ook aan de hoge kant
zullen liggen.
Hieronder vinden we per contract het totaal aantal manuren per variabele van de minimale
set en de percentuele verdeling van de normering met 4 urenposten. We zullen per
contract de afwijkingen en spreidingen verklaren t.o.v. de normering.
Afwijkingen en Spreidingen Cluster 1
Contract ODS
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Uren
5151,93
4591,64
3221,94
482,5
13448,01
%
38%
34%
24%
4%
100%
Normering
34.5%
43.5%
10%
12%
100%
Uren
9744
11210
7648
524
29126
%
33%
38%
26%
2%
100%
Normering
34.5%
43.5%
10%
12%
100%
Uren
5550,02
5874,14
4041,78
377,06
15843
%
35%
37%
26%
2%
100%
Normering
34.5%
43.5%
10%
12%
100%
Contract Resa/Fasa
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Contract IMF
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Bevinding: De SM uren liggen aan de hoge kant t.o.v. de normering. Verder zien we dat
de HD uren een stuk lager zijn. De overige variabelen wijken niet zo veel af van de
normering. Overigens wordt er binnen ODS, RESA/FASA en IMF op twee variabelen uren
geregistreerd. Verder gebruiken deze contracten dezelfde verdeelsleutel tijdens Stap 1,
aangezien deze contracten onder beheer en onderhoud staan van dezelfde persoon.
Contract NEA
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Uren
989,39
774,18
760,72
125,71
2650
%
37%
29%
29%
5%
100%
Normering
34.5%
43.5%
10%
12%
100%
%
38%
28%
31%
3%
100%
Normering
34.5%
43.5%
10%
12%
100%
Contract Ring Amsterdam
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Uren
612,14
455
511,43
51,43
1630
Bevinding: Bij NEA en RING zien we dat er op 4 variabelen uren worden geregistreerd en
ook hier zien we dat er een hoge SM percentage en een lage HD percentage is. Overigens
staan deze contracten door dezelfde persoon in beheer en onderhoud.
Afwijkingen Cluster 1: We zien bij alle contracten binnen deze cluster dat de SM uren
aan de hoge kant liggen en de HD uren aan de lage kant liggen.
Spreidingen Cluster 1: De hoge percentage aan SM en de lage percentage aan HD
kunnen we deels verklaren uit de verdeelsleutel. Hierbij hebben we de uren tijdens Stap 1
68
© Getronics PinkRoccade 2007
Validatie
(figuur 4.10) van de verdeelsleutel gelijkmatig over de vinkjes verdeeld. Zo zouden we
tijdens Stap 1 een correctiefactor kunnen gebruiken, aangezien de SM uren in praktijk veel
lager moeten uitvallen. Deze correctiefactor moet ervoor zorgen dat er nauwkeuriger uren
verdeeld kunnen worden. Een service manager geeft tijdens Stap 1 aan tot welke ASL
processen zijn uren behoren. We zouden dan minder uren kunnen toekennen aan de SM
uren tijdens deze stap. Tijdens stap 3 en volgens de verdeling van Oevermans (tabel 4.8)
zien we dat de SM uren bestaan uit de volgende ASL processen; Change Management,
Software Control en Distribution, Tactisch Management en Strategisch Management.
De lage percentage van HD kunnen we ook uit de verdeelsleutel verklaren, aangezien we
hier tijdens stap 1 gelijkmatig de uren verdelen onder de verschillende vinkjes. De vinkjes
boven Incident Management, zorgen voor het totaal aantal uren voor HD. Ook hier zouden
we een correctiefactor kunnen toepassen door tijdens stap 1 relatief meer uren te
reserveren voor de vinkjes boven Incident Management. Voor de correctiefactoren van SM
en HD verwijzen we u door naar paragraaf 6.4.
Cluster 2
Invloed
Variabele
Arbototaal
EW/BWS
BH/SM
BH/SM
Leeftijd
(jaar)
Prog.taal/
4
Oracle
Markt
Migratie
framework
(Ja/nee)
2001Verzuimmanagement Ja,
2002
(o.a. Arbo-diensten)
(4 jaar)
6, (officieel Oracle
37)
Zorg (huursubsidies)
Ja,
2001
2001-
Functiepunten Beheerder
(jaar)
10.000
Bellmon/
Jacobs
10.000
Rook
(6 jaar)
Tabel 6.2 Cluster 2
De bovenstaande 2 contracten hebben over het algemeen veel invloed van de variabele
BH. Dit zou betekenen dat er hiervoor in de verdeling per contract relatief meer uren
besteed worden aan BH. De SM uren zijn bij deze contracten ook relatief hoger dan bij de
normering.
Contract Arbototaal
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Uren
14175
11987,50
7212,50
2625
36000
%
39%
33%
20%
7%
100%
Normering
34.5%
43.5%
10%
12%
100%
Bevinding: Arbototaal was het enige contract waarbij er meer dan 4 variabelen werden
geregistreerd. Het ging totaal om 8 variabelen waar uren op geregistreerd waren. Ook hier
werden uren niet volgens de ASL processen geregistreerd, waardoor we ook een
verdeelsleutel nodig hadden van de service manager.
Contract EW/BWS
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Uren
699
466
345
92
1602
%
44%
29%
22%
6%
100%
Normering
34.5%
43.5%
10%
12%
100%
Bevinding: Opvallend genoeg worden de uren van EW/BWS onder dezelfde variabelen
geregistreerd als de minimale set, alleen krijgen deze uren na stap 3 andere waardes.
© Getronics PinkRoccade 2007
69
Validatie
Afwijkingen Cluster 2: We zien bij alle contracten binnen deze cluster dat de BH en SM
uren aan de hoge kant liggen.
Spreidingen Cluster 2: Net als bij cluster 1 kunnen we de hoge percentage aan SM uren
verklaren aan het feit dat we de uren gelijkmatig hebben verdeeld, tijdens Stap 1. We
zouden ook hier een correctiefactor kunnen toepassen, zodat de SM uren lager zullen
uitvallen. Dit geldt ook voor de lage aantal uren aan HD, net als bij cluster 1 kunnen we
ook hier een correctiefactor toepassen. Het hoge aantal aan BH uren kunnen we verklaren
uit het feit dat het hier om grotere applicaties gaat, waarbij beide applicaties uit ongeveer
10.000 functiepunten bestaan. Een andere factor die invloed zou kunnen hebben, is dat
beide applicaties een migratie hebben ondergaan. We zouden deze bewering overigens niet
kunnen onderbouwen, aangezien onze dataset hier te klein voor is. Verder heeft deze
cluster meer gelijkenis met de Normering in vergelijking met cluster 1.
Cluster 3
Invloed
Variabele
Leeftijd
(jaar)
Prog.taal/
VB
Markt
Migratie
framework
(Ja/nee)
Overheid
(uitkering)
GCU
AO/HD
3
Normering
AO/HD
GCU komt het meest overeen met de Normering
nee
Functiepunten Beheerder
(jaar)
750
Nordemann
Tabel 6.3 Cluster 3
GCU is het enige contract binnen onze dataset die veel gelijkenis heeft met de normering.
De variabelen AO en HD zijn de variabelen die zorgen voor de spreiding van de verdeling.
Contract GCU
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Uren
2086,17
2748,52
762,40
271,50
5868,59
%
32%
47%
17%
5%
100%
Normering
34.5%
43.5%
10%
12%
100%
Afwijkingen Cluster 3: De SM uren liggen iets aan de hoge kant en de HD uren liggen
iets aan de lage kant. Binnen GCU worden de uren voor beheer en onderhoud bijgehouden
volgens 4 variabelen.
Spreidingen Cluster 3: Overigens kunnen we hier de correctiefactoren voor SM en HD
toepassen, waardoor de verdeling nog meer zal lijken op die van de Normering.
70
© Getronics PinkRoccade 2007
Validatie
Cluster 4
Invloed
Variabele
Leeftijd
(jaar)
Prog.taal/
Markt
framework
Migratie
(Ja/nee)
GEFIS
BH/HD
15
Cobol
Overheid
nee
EDMS
BH
9
Informix
Ministerie SZW** nee
en VWS
Functiepunten
(jaar)
Beheerder
10.000
Hagen
-
Oevermans
** Sociale Zaken en Werkgelegenheid
Tabel 6.4 Cluster 4
Binnen cluster 4 kunnen we zien dat de variabele BH zeer hoog ligt in verhouding met de
normering. We zien hier overigens wat oudere applicaties, waarbij er nog geen migratie
heeft plaatsgevonden bij de applicaties. Verder kunnen we alleen van GEFIS zeggen dat
het hier gaat om een grote applicatie van ongeveer 10.000 functiepunten.
Contract GEFIS
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Uren
1414,5
389,9
509,6
309
2623
%
54%
15%
19%
12%
100%
Normering
34.5%
43.5%
10%
12%
100%
Bevinding: Één variabele is onderverdeeld over de ASL processen door de service
manager. Hierdoor hebben we enigszins tijdens stap 1 de uren categorie BH verschillende
waardes meegekregen. Dit moeten we niet in verwarring brengen met onze BH variabele
van de minimale set.
Verder gaf de service manager aan dat het om een relatief oud systeem gaat waarop
nauwelijks onderhoud (correctief en adaptief) wordt uitgevoerd. Dit zien we overigens ook
terug in onze percentuele verdeling. Dit is onze verklaring voor de lage percentage aan AO
uren. Verder zien we ook hier een hoge percentage aan SM uren.
Contract EDMS
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Uren
722
134
336
124
1316
%
55%
10%
26%
9%
100%
Normering
34.5%
43.5%
10%
12%
100%
Bevinding: Bij EDMS worden de uren geregistreerd op 3 variabelen. Ook hier zien we een
hoge percentage aan BH uren. Aangezien het hier om een wat oudere applicatie gaat zien
we ook hier dat de AO uren aan de lage kant liggen en de SM uren die liggen netals bij alle
voorgaande contracten aan de hoge kant. Verder gaf de service manager van EDMS aan
dat deze applicatie over 2 jaar niet meer bestaat.
Afwijkingen Cluster 4: We zien over het algemeen een hoge percentage aan BH uren,
een te lage percentage aan AO uren. Verder zijn de SM uren aan de hoge kant.
Spreidingen Cluster 4: De spreidingen voor de uren BH en AO kunnen we verklaren uit
het feit dat het hier om wat oudere applicaties gaat, waarbij er nauwelijks aan AO gedaan
wordt. Voor de hoge percentage aan SM uren kunnen we ook hier een correctiefactor
toepassen.
© Getronics PinkRoccade 2007
71
Validatie
Uitschieters
Invloed
Variabele
Leeftijd
(jaar)
Prog.taal/
Markt
Migratie
framework
(Ja/nee)
SBB
HD
15
Cobol
overheid
nee
PUR
AO
10-15
Oracle
Zelfstandig orgaan nee
(Ministerie VWS)
Functiepunten
(jaar)
Beheerder
9.000
Hagen
-
Oevermans
Tabel 6.5 Uitschieters
Contract SBB
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Uren
2304,16
1901,37
1432,47
2598
8236
%
28%
23%
17%
32%
100%
Normering
34.5%
43.5%
10%
12%
100%
Bevinding, Afwijking en Spreiding: De service manager van SBB gaf aan dat het ook
hier om een oud systeem gaat, waarbij er nauwelijks AO uren zijn. Verder geldt er voor
SBB dat er in 2006 contractonderhandelingen zijn geweest waardoor het aantal uren voor
strategisch en tactisch management veel hoger is. Wat overigens ook frappant is, is het
feit dat er veel uren zijn gereserveerd voor HD. De uren voor HD bestaan zoals we weten
uit Incident Management uren, de uren voor HD zijn zelf door de service manager
ingevuld. Deze uren hebben dus nauwelijks invloed gehad van de verdeelsleutel, alleen
hebben wij niet direct een verklaring voor deze hoge percentage. Voor de hoge SM uren
kunnen we ook hiervoor een correctiefactor op toepassen.
Contract PUR
Variabele
BH (Beheer)
AO (Adaptief Onderhoud)
SM (Service Management)
HD (Helpdesk)
Totaal
Uren
504,25
1513,6
479,25
100,85
2597,95
%
19%
58%
18%
4%
100%
Normering
34.5%
43.5%
10%
12%
100%
Bevinding, Afwijking en Spreiding: Bij PUR zien we dat de AO uren hoger zijn
uitgevallen als de andere variabelen. Het gaat hier om een wat oudere applicatie, alleen
bleek uit de uitspraken van de service managers dat er voor oudere applicaties minder AO
wordt gedaan. Bij PUR is dit niet het geval en het gaat hier om een uitschieter. Overigens
heeft deze uitschieter wel een aantal overeenkomstige zaken met cluster 1, 2 en 3. Zo zien
we ook hier een hoge percentage aan SM uren en een te lage percentage aan HD uren. We
kunnen ook hier de correctiefactoren op toepassen die we in paragraaf 6.4 verder zullen
toelichten.
72
© Getronics PinkRoccade 2007
Validatie
6.3 Validatie theorie
Per cluster zullen we ook een kleine checklist doornemen, die opgesteld is uit de theorie uit
hoofdstuk 3. Hierin vinden we enkele factoren die invloed hebben op beheer en onderhoud,
zoals deze beschreven is in de literatuur. Op basis van de verkregen resultaten zullen we
een aantal van deze factoren per cluster toelichten. Het gaat in dit geval niet om een
validatie van deze theorie, aangezien we niet over voldoende contracten en informatie
beschikken om tot een validatie te komen. Het gaat voornamelijk om onze bevindingen uit
de verkregen dataset van de urenregistraties en de interviewvragen. We zullen per cluster
de verhouding tussen BH en AO weergeven om deze checklist door te nemen.
Checklist
•
Oude applicaties zullen vaker onderhouden/gerepareerd/preventief onderhouden
worden, dan nieuwere applicaties. (subparagraaf 3.6.2)
o Cluster 1: Binnen deze cluster zien we dat er bij de nieuwere applicaties
ODS (2 jaar), NEA (2 jaar) en RING (2 jaar) relatief minder uren worden
besteedt aan AO in vergelijking met BH. De oudere applicaties RESA/FASA
(20 jaar) en IMF (16 jaar) besteden relatief meer tijd aan AO en relatief
minder tijd aan BH.
Uitspraak wordt bevestigd: Ja
o Cluster 2: Als we kijken naar de huidige leeftijd van deze twee applicaties
na migratie, zien we dat Arbototaal (4 jaar, officieel niet bekend) en EW/BWS (6
jaar, officieel 37 jaar) relatief minder uren besteden aan AO en relatief meer
uren aan BH.
Uitspraak wordt bevestigd: Ja, uitspraak wordt deels bevestigd.
o Cluster 3: GCU (3 jaar) besteedt relatief meer uren aan AO dan aan BH.
Uitspraak wordt bevestigd: Nee
o Cluster 4: GEFIS (15 jaar) en EDMS (9 jaar) zijn relatief oudere applicaties,
alleen zagen we dat de BH uren veel hoger uitvallen dan de AO uren.
Uitspraak wordt bevestigd: Nee
Conclusie: We kunnen hooguit zeggen dat iedere applicatie uniek en anders van aard
is. We kunnen helaas geen uitspraak doen over de bovenstaande stelling.
•
Grotere applicaties zullen vaker onderhouden/gerepareerd/preventief onderhouden
worden, dan kleinere applicaties. (subparagraaf 3.6.2 en 3.6.3)
o Cluster 1: RESA/FASA (4.500 functiepunten) besteedt relatief meer uren uit aan
AO dan aan BH. IMF (1.810 functiepunten) besteedt ook relatief meer uren uit
aan AO dan aan BH, alleen gaat het hier om een kleinere applicatie. ODS
(1.142 functiepunten) besteedt relatief minder uren uit aan AO dan aan BH.
We kunnen niet exact opmaken wat we verstaan onder een grotere
applicatie en een kleinere applicatie. Hierdoor kunnen we bij deze cluster
nauwelijks een uitspraak over doen. De functiepunten van NEA en RING
waren niet beschikbaar.
o Cluster 2: Arbototaal (10.000 functiepunten) en EW/BWS (10.000 functiepunten)
kunnen we zien als grotere applicaties. Alleen kunnen we hier ook niet echt
een uitspraak over doen, aangezien er migratie heeft plaatsgevonden. We
zien wel dat bij beide applicaties de BH uren hoger uitvallen dan de AO
uren. Dit zou in principe de uitspraak tegenspreken, alleen kunnen we
zeggen dat andere factoren ook invloed hebben.
o Cluster 3: GCU (750 functiepunten) is een wat kleinere applicatie, alleen vallen
de AO uren hoger uit als de BH uren. Dit zou in principe de uitspraak
tegenspreken.
o Cluster 4: We hebben alleen van GEFIS (10.000 functiepunten) de gegevens en
van EDMS ontbreken de gegevens. GEFIS is een wat grotere applicatie,
alleen zien we relatief veel uren bij BH dan bij AO. Dit zou de uitspraak
tegenspreken, maar we kunnen zelf de link niet leggen.
© Getronics PinkRoccade 2007
73
Validatie
•
Migratie wordt gebruikt om veroudering van een applicatie te voorkomen.
(subparagraaf 3.6.4)
o Cluster 2: Alleen de contracten Arbototaal en EW/BWS hebben een
migratie ondergaan. Wat wij uit ons dataset kunnen opmaken is dat de
uren door migratie voor AO lager zijn uitgevallen. Of dit ook een direct
gevolg is van migratie is moeilijk te zeggen, door onze kleine dataset.
•
Wat zijn opmerkelijke resultaten van het onderzoek m.b.t. programmeertalen en
frameworks. (subparagraaf 3.6.5)
o Cluster 1: Binnen cluster 1 valt het ons op dat er bij de Cobol (RESA/FASA en
IMF) applicaties relatief meer uren besteedt worden aan AO dan aan BH.
Verder zien we dat bij de .Net applicaties de uren voor BH hoger uitvallen
dan bij AO. Op basis van deze 5 applicaties kunnen we zien, dat er binnen
onze onderzoek voor Cobol (ODS, NEA en RING) applicaties de uren voor AO
relatief hoger uitvallen dan bij .Net applicaties binnen cluster 1.
o Cluster 2: Binnen cluster 2 hebben we te maken met 2 Oracle (Arbototaal en
EW/BWS) applicaties, waarbij de uren voor BH hoger zijn uitgevallen dan de
uren voor AO. Op basis van onze gegevens zouden we graag willen
suggereren dat er relatief meer uren nodig zijn voor BH dan voor AO bij
Oracle applicaties. Ook hier kunnen we deze uitspraak moeilijk bewijzen,
aangezien we een kleine dataset hebben.
o Cluster 3: Hier zien we dat de uren voor Visual Basic (GCU) applicatie voor
AO hoger zijn als de uren voor BH. Dit was tevens het contract die het
meest overeenkwam met de normering.
o Cluster 4: We zien binnen cluster 4 twee verschillende applicaties, waarbij
een Cobol (GEFIS) applicatie en een Informix (EDMS) applicatie. In
tegenstelling tot de resultaten uit cluster 1, zijn de uren bij Cobol voor BH
veel hoger uitgevallen dan de uren voor AO en hetzelfde geldt voor de
Informix applicatie.
•
Markt – We kunnen over de markt van de applicaties relatief weinig zeggen,
aangezien de meeste applicaties die GPR in zijn beheer en onderhoud heeft vallen
onder overheidsinstellingen. Ook binnen de clusters zien we dat er niet echt
onderscheid is te maken op basis van de markt.
Conclusie
Dit zijn in grote lijnen de uitkomsten van ons onderzoek m.b.t. de programmeertalen en
frameworks. We kunnen helaas geen duidelijke uitspraken hierover maken, aangezien
onze dataset hier te klein voor is. We hebben overigens ook geen overeenkomstige
patronen kunnen ontdekken. Tijdens het onderzoek hadden we bij de interviews
meegekregen dat .Net applicaties in vergelijking tot Cobol applicaties meer onderhoud
vereisen. Deze uitspraak hebben we niet kunnen terugvinden binnen onze resultaten.
Zoals we al in paragraaf 3.6.1 hebben beschreven, zijn er verschillende factoren die
invloed hebben op de beheer en onderhoud en daarmee ook op de urenregistraties. Deze
factoren hebben ook weer relaties met andere factoren. De reden dat wij moeilijk tot
uitspraken zijn gekomen, heeft grotendeels te maken met de verschillende factoren per
applicatie. Zo hebben leeftijd, programmeertalen/frameworks, de markt, migratie,
functiepunten wel degelijk invloed op beheer en onderhoud, alleen kunnen we uit onze
resultaten niet zeggen wat de exacte invloed is. Dit komt doordat deze factoren ook op
elkaar invloed kunnen uitoefenen (zie ook tabel 3.4), waar uiteindelijk onze onderzoek te
klein voor is.
74
© Getronics PinkRoccade 2007
Validatie
6.4 Correctiefactor
In paragraaf 6.2 hebben we getracht de afwijkingen en spreidingen te verklaren. We zagen
over het algemeen dat de SM uren hoger uitvielen en de HD uren wat lager (zie tabel
5.19). Dit had grotendeels te maken met onze verdeelsleutel. Tijdens stap 1 van de
verdeelsleutel worden uren gelijkmatig over de vinkjes verdeeld, waardoor we aan elke
ASL proces evenveel uren moesten toekennen. Het gelijkmatig verdelen van de uren wordt
tevens ook gedaan tijdens stap 3. We zouden onze verdeelsleutel enigszins kunnen
aanpassen, om uiteindelijk meer contracten overeen te laten komen met de normering. In
paragraaf 6.2 hebben we per cluster en uitschieter aangegeven of we een correctiefactor
konden toepassen, zodat er meer overeenkomst was met de normering. In het tabel
hieronder zien we een overzicht van de clusters en uitschieters waarvan we bepaald
hebben of er een correctiefactor (CF) voor SM en HD toegepast kan te worden.
Cluster 1
Cluster 2
CF SM
CF HD
Tabel 6.6 Correctiefactor
Cluster 3
Cluster 4
SBB
x
x
PUR
Uit tabel 6.6 blijkt dat er voor elk contract een correctiefactor voor SM toegepast dient te
worden en een correctiefactor voor HD is ook in de meeste gevallen nodig. Alleen voor
cluster 4 en SBB lijkt het toepassen van een correctiefactor overbodig, aangezien de HD
uren al aan de hoge kant liggen. Met behulp van onderstaande figuur zullen we hier meer
informatie over geven.
Figuur 6.7 Verdeelsleutel Correctiefactor
In figuur 6.7 zien we hoe we invloed kunnen uitoefenen op de SM uren en de HD uren. We
zullen stap voor stap laten zien hoe we uiteindelijk kunnen zorgen voor een vermeerdering
van de HD uren en een vermindering van de SM uren.
Correctiefactor HD
De uren voor HD bestaat uit de ASL proces “Incident Management”. Voor ons is het
belangrijk om te kijken hoeveel uren we moeten toekennen aan de vinkjes. Als we kijken
naar de vinkjes verticaal boven Incident Management zien we dat de uren bestaan uit X4
en X6. X4 heeft zijn vinkje alleen onder Incident Management staan, waarbij we de uren
niet hoeven te delen onder de andere vinkjes en volledig kunnen toekennen aan dat ene
© Getronics PinkRoccade 2007
75
Validatie
vinkje (100%). Bij X6 zien we vervolgens dat de vinkjes boven Incident Management en
Change Management staan. Als voorbeeld hebben we een verhouding gekozen van 75%
van de waarde bij X6 toe te kennen aan Incident Management en de overige 25% weer toe
te kennen aan Change Management. Zo zorgen we ervoor dat de HD uren hoger zullen
uitvallen en onze verhouding van 75%-25% hebben we alleen als voorbeeld gebruikt.
Verder zou iedere organisatie zijn eigen verhouding kunnen maken aan de hand van hun
ervaringen.
Correctiefactor SM
De belangrijkste reden voor deze correctiefactor, kunnen we verklaren uit de informatie die
we gekregen hebben van Marcel Oevermans. In subparagraaf 4.4.1 zien we dat
Oevermans een toelichting heeft gegeven voor het model. Hij gaf hierin aan dat sommige
ASL processen samen konden vallen. Hierbij gaf hij aan dat de aandeel van sommige ASL
processen wat kleiner waren.
De correctiefactor voor SM bestaat vervolgens uit meerdere ASL processen, die weer
weergegeven zijn in stap 3 van de verdeelsleutel. We kunnen in figuur 6.7 zien dat het om
de uren Change Management, Software Control en Distribution, Tactisch Management en
Strategisch Management gaat, waarbij ze allemaal tijdens stap 2 een totale waarde
hebben meegekregen gekregen.
We zijn nu belandt in stap 3 van de verdeelsleutel, waarbij we de totale aantal uren voor
Change Management moeten verdelen over AO en SM. In plaats van het gelijkmatig
verdelen van de uren, gaan we minder uren toekennen aan SM, zoals dat in subparagraaf
4.4.1 ook werd aangegeven. Ook hier hebben we als voorbeeld gekozen voor een 75%25% verhouding. Dit doen we ook voor de overige ASL processen die invloed hebben de
SM uren (zie tabel 6.8). Op deze manier zorgen we ervoor dat de uren voor SM lager
zullen uitvallen.
75%
75%
HD
75%
75%
SM
AO
BH
Change management
Software Control en distribution
Tactisch management
Strategisch management
Tabel 6.8 Correctiefactor SM
25%
25%
25%
25%
Overigens zullen organisaties zelf de afweging moeten maken hoeveel uren ze toekennen
aan SM, dit kan simpel door een percentuele verhouding als in tabel 6.8.
76
© Getronics PinkRoccade 2007
Validatie
6.5 Validatie Minimale Set aan Urenposten
We zijn nu gekomen bij de validatie van de minimale set om uren op te registreren, deze
minimale set bestond vervolgens uit 4 variabelen. De 4 variabelen zijn BH (Beheer), AO
(Adaptief Onderhoud), SM (Service Management) en HD (Helpdesk), die op hun beurt een
standaard hanteren. Zoals we al weten gaat het om onze normering, de verdeling die is
voortgevloeid uit tabel 1.1, de Normverdeling beheeruren (ASL processen). In hoofdstuk 5
hadden we gebruik gemaakt van statistische technieken om te kijken wat de afwijkingen
en spreidingen waren van de huidige contracten t.o.v. de normering. In tabel 5.19 zagen
we exact waar de grote verschillen in lagen en hieronder zien we nogmaals deze
percentuele verdelingen.
BH
AO
SM
Normering
34.5 43.5 10
Normering op basis van data
37.4 32.7 21.9
Tabel 5.19 normering op basis van data (herhaling)
HD
12
7.8
We kunnen uit bovenstaande tabel exact opmaken wat het gemiddelde percentage per
variabele is. Zo zien we één op één de verschillen van de totale dataset t.o.v. de
normering. De verschillen zitten met name in SM en HD, alleen konden we dit verschil
verklaren uit onze verdeelsleutel. In onze verdeelsleutel hadden we namelijk alle uren
gelijkmatig verdeeld over de aanwezige vinkjes, hierdoor kregen we bij bijna alle
contracten een groot verschil t.o.v. de normering. Zo leek het voor ons voor de hand
liggend om correctiefactoren toe te passen bij de verdeelsleutel (figuur 6.7). We krijgen
hier als het ware een verlaging van de SM uren en een verhoging van de HD uren. Op deze
manier komen de waardes van de verdeling nog dichter bij normering. We kunnen dan aan
de hand van onze dataset, dat in totaal bestond uit 12 contracten inclusief de normering,
verklaren dat de normering een bruikbare verdeling is.
In het begin van ons onderzoek gingen we ervan uit dat we de normverdeling van de
beheeruren zouden onderzoeken en valideren. Dit bleek achteraf niet handig aangezien er
in de praktijk niet werd geregistreerd op ASL processen. Zo besloten we een minimale set
op te zetten, waarna we in subparagraaf 4.5.1 hadden aangeven hoe we tot de minimale
set waren gekomen. In paragraaf 5.4 hebben we alsnog een 2e dataset gecreëerd op basis
van de normverdeling beheeruren (tabel 1.1) en daarvan de correlaties en clusters tussen
de variabelen en contracten onderzocht. We wilden hiermee een bevestiging van ons
eerdere onderzoek. In dat onderzoek kwam sterk naar voren dat de variabelen allemaal
positief gecorreleerd waren en dat er meerdere contracten overeenkwamen met de
normverdeling beheeruren (ASL processen).
Validatie resultaten 2e dataset met 12 variabelen, normverdeling beheeruren:
•
Bij de resultaten van deze dataset met meerdere variabelen, zien we dat er
meerdere variabelen overeenkomen met de normverdeling beheeruren. Dit komt
door de aanwezige variabelen die meer zijn als in de 1e dataset. Dit zorgt ervoor
dat de afwijkingen relatief lager zijn als bij de normering van de minimale set met
4 urenposten. Dit is als het ware een verklaring voor het feit dat er relatief minder
afwijkingen waren.
•
Het feit dat we voor de validatie van de normering een correctiefactor toepassen
heeft naar onze mening veelal te maken met de afwijkingen. Zo hebben we voor
de 2e dataset geen correctiefactor nodig, terwijl dat bij de 1e dataset wel nodig is.
De resultaten van de 2e dataset bevestigen hiermee nogmaals dat de minimale set een
bruikbare normverdeling is.
© Getronics PinkRoccade 2007
77
Validatie
6.6 Samenvatting
Zo hebben we in dit hoofdstuk de afwijkingen en spreidingen verklaard aan de hand van
onze dataset. Zoals we al weten waren het aantal contracten dat we gekregen hebben wat
aan de lage kant. In eerste instantie zagen we ook verschillen tussen de contracten en de
normering. Deze verschillen hebben we aan de hand van onze dataset kunnen verklaren
en bleek dat de verschillen die we in eerste instantie zagen, achteraf niet eens zo groot
waren. Dit had natuurlijk grotendeels te maken met het lage aantal contracten en
correctiefactoren die toegepast moesten worden. Dit was de eerste bevestiging van het feit
dat de minimale set een bruikbare verdeling zou zijn. Ter bevestiging hadden we de 2e
dataset geraadpleegd en daar kwam als het ware een 2e bevestiging uit. We hadden met
de 2e dataset meerdere variabelen, waardoor de afwijkingen en spreidingen per contract
lager uitvielen. Dit had als gevolg dat er meerdere variabelen overeenkwamen met de
normverdeling beheeruren volgens de ASL processen. De minimale set zou volgens ons
onderzoek een prima middel zijn waarop de uren van beheer en onderhoud op
geregistreerd kunnen worden. Het is dan de bedoeling dat iedereen zijn uren volgens deze
standaard dient bij te houden. De definities en taken van de ASL processen dienen wel
bekend te zijn bij de service manager en zijn team. We vinden dit belangrijk aangezien ons
hele model voor een groot deel is opgesteld uit het ASL Framework. Het betrokken
management heeft tevens een hulpmiddel waarmee ze makkelijker een overzicht kunnen
maken van de gewenste contracten. Afwijkingen en spreidingen kunnen voor een deel uit
de verdeling per contract gemaakt worden. Hier kunnen ze de eindverantwoordelijke
(service manager) voor aanspreken, die dan het een en ander nog kan toelichten.
Organisaties zouden dus op een uniforme manier de uren moeten bijhouden, waardoor je
als het ware ook geen verdeelsleutel nodig zou hebben.
Nadat we alle data verzameld en geanalyseerd hebben, kunnen we de metrieken valideren
volgens het V-GQM model. We zullen in de volgende subparagraaf de vragen valideren en
niet de metrieken.
6.6.1 V-GQM (5) METRIC VALIDATION
Bij metric validation testen we of elke wijziging voldoet aan de eisen. Hierbij maken we
onderscheid tussen drie categorieën. De vragen hadden we al opgesteld in subparagraaf
4.2.2 tijdens de question definition stap van het V-GQM model.
Unavailable: De metriek is voor de een of andere reden onbeschikbaar.
Question (vraag)
4
6, 8, 9, 10, 11
Reden
Uit ons onderzoek hebben we niet direct de gevolgen van programmeertalen,
markt, leeftijd, migratie, grootte, contractduur en geplande versus
gerealiseerde uren op beheer en onderhoud kunnen opmaken. Wel hebben we
onze eigen situatie per cluster geanalyseerd.
We kwamen er niet meteen achter welke definities er voor applicatiebeheer
door werknemers werden gehanteerd. Elke service team hanteerde zijn eigen
urenadministratie, waarvan niet duidelijk was op welke manier zij hun uren
registreerden. Dit was ook de reden dat we voor elke applicatie een
verdeelsleutel nodig hadden om tot een verdeling te komen van de
geadministreerde uren. Over de ervaring van de werknemers t.o.v. de
normverdeling/normering kunnen we ook vrij weinig over zeggen.
Extended: Er is meer data verzameld dan in de GQM plan.
Question (vraag)
2
78
Uitleg
Op deze vraag hebben we geen duidelijk antwoord. Uren worden meestal per
applicatie verschillend bijgehouden. We zien dat er voor elke applicatie een
service manager met zijn beheer- en onderhoudsteam verantwoordelijk voor
is. Wat we overigens wel gezien hebben is dat applicaties die onder één service
manager vallen, op dezelfde manier zijn uren bijhouden.
© Getronics PinkRoccade 2007
Validatie
Generisable: De verzamelde data kan gegeneraliseerd worden.
Question (vraag)
3
Reden
We weten van alle applicaties dat de functiepunten volgens het FPA NESMA
methodiek geteld zijn. Deze functiepunten waren of lange tijd geleden geteld of
bij sommige applicaties niet beschikbaar.
6.6.2 V-GQM (6) QUESTION ANALYSIS
Binnen question analysis gaat het om de integratie van het testen door ook de categorieën
van de metric validation te gebruiken.
Unavailable questions
We hebben in totaal 7 vragen van het V-GQM waar we niet direct een antwoord op hebben
gekregen, de vragen 4, 8, 9, 10 en 11. Doordat we over relatief weinig contracten
beschikten, konden we niet direct conclusies trekken op vraag 4. Het enige wat we uit de
literatuur konden opmaken was het feit dat al deze zaken invloed op elkaar uitoefenden.
Om de vragen te beantwoorden hadden we niet voldoende informatie om uitspraken over
te doen. Het enige wat we wel wisten was het feit dat werknemers binnen GPR een ASL
certificaat konden halen.
Extended questions
Op vraag 2 hadden we enorm veel uitkomsten met betrekking tot het registreren van uren.
Zo had iedere service manager een andere manier van uren registreren. Om ons model te
valideren moesten we exact weten tot welke ASL processen de geregistreerde uren
behoorden. Dit deden we vervolgens door een verdeelsleutel te gebruiken. Applicaties die
onder één service manager vielen, hanteerden wel dezelfde verdeelsleutel. Hierdoor
hadden we een duidelijk overzicht van de geregistreerde uren en konden we afwijkingen
en spreidingen per applicatie deels hieruit verklaren.
Generalisable questions
We kregen van GPR te horen dat de functiepunten van alle applicaties volgens het NESMA
methodiek geteld waren, vraag 3. Verder zagen we dat sommige tellingen zelfs lang
geleden geteld waren. Ondertussen zou er heel veel veranderd kunnen zijn aan een
applicatie, waardoor deze tellingen ook niet meer zouden kloppen. Dus mochten we
informatie over de functiepunten van een applicatie krijgen dan weten we alleen zeker dat
deze telling volgens het NESMA methodiek geteld is.
© Getronics PinkRoccade 2007
79
Conclusie
7 Conclusie
In hoofdstuk 6 hebben we op onze manier het model gevalideerd. Het model is als het
ware een minimale set aan urenposten waarop insourcers hun uren kunnen registreren,
waarbij het model tevens een percentuele verdeling bevat. In dit Hoofdstuk geven we kort
weer antwoord op de hoofd- en deelvragen die we in de voorgaande hoofdstukken
beantwoord hebben. Hierna zullen we de laatste stap van het V-GQM model bespreken en
tenslotte sluiten we af met een conclusie en vervolgonderzoek.
7.1 Deelvragen
Deelvraag 1: Welke criteria en principes zijn van belang voor een succesvolle inrichting
van beheer en onderhoud van applicaties?
Antwoord op deze deelvraag is terug te vinden in hoofdstuk 3 en hoofdstuk 4:
Allereerst hebben we de juiste definities volgens ASL gegeven voor beheer en onderhoud
met de daarbij behorende metrieken en activiteiten (paragraaf 3.4)van de ASL urenposten.
We hebben hierin voornamelijk gebruik gemaakt van de definities van het ASL Foundation
(ASL_F). Voor beheer en onderhoud van applicaties zitten we op het uitvoerende niveau
binnen het ASL Framework (figuur 3.2) en dit was tevens ons uitgangssituatie. Uit ons
onderzoek bleek dat de urenposten bij elke applicatie anders werden bijgehouden en
meestal ook niet volgens ASL. Zo kozen we voor een set aan urenposten, die onderdeel
vormden van het ASL Framework (figuur 3.1). Deze set aan urenposten waren opgesteld
door Marcel Oevermans van GPR die op basis van de praktijk een percentuele verdeling
hiervan heeft gemaakt. Zo hebben we als het ware een nieuwe framework opgesteld
(figuur 4.6) volgens de verdeling van Marcel Oevermans. In tabel 1.1 zien we nogmaals de
urenposten die gebruikt kunnen worden bij beheer en onderhoud van applicaties.
ASL proces
Incident management (Incidentbeheer)
Configuration management (Configuratiebeheer)
Availability management (Beschibaarheidsbeheer)
Capacity management (Capaciteitsbeheer)
Continuity management (Continuïteitsbeheer)
Change management (Wijzigingenbeheer)
Software Control en distribution (Programmabeheer en distributie)
Onderhoud (correctief, preventief en perfectief)
Tactisch management
Strategisch management
Percentage
12%
5%
15%
3%
5%
2%
5%
40%
10%
3%
TOTAAL
Tabel 1.1 Normverdeling beheeruren (ASL Processen) (herhaling)
100%
Voor een succesvolle inrichting van beheer en onderhoud zouden dus de bovenstaande
urenposten door de werknemers geregistreerd kunnen worden. Uit praktijk blijkt dat dit
veel tijd en moeite zal kosten, waardoor we voor een minimale set aan urenposten hebben
gekozen. We hebben vervolgens een minimale set aan urenposten opgesteld, waarvan we
exact weten bij welke ASL processen deze horen. Op deze manier kunnen uren die
geregistreerd worden op 4 urenposten gedeclareerd worden, i.p.v. 12 urenposten, tevens
wordt onderhoud ook in drieën verdeeld (correctief, preventief en perfectief). Dit hebben
we overigens in hoofdstuk 4 beschreven, waarbij de minimale set aan urenposten met de
percentuele verdeling ervan zijn weergegeven in tabel 4.9.
80
© Getronics PinkRoccade 2007
Conclusie
HD
SM
AO
BH
Incident management
12
Configuration management
5
Availability management
15
Capacity management
3
Continuity management
5
Change management
1
1
Software Control en distribution
2.5
2.5
Onderhoud (correctief)
13 ⅓
Onderhoud (preventief)
13 ⅓
Onderhoud (perfectief)
13 ⅓
Tactisch management
5
5
Strategisch management
1.5
1.5
TOT 100%
34.5
43.5
10
12
Tabel 4.9 Percentuele verdeling nieuwe basisset (herhaling)
We kunnen in het bovenstaande tabel exact aflezen welke ASL processen vallen onder BH
(Beheer), AO (Adaptief Onderhoud), SM (Service Management) en HD (Helpdesk). Dit zou
volgens ons de manier zijn om je uren voor beheer en onderhoud bij te houden. Binnen
een organisatie zouden alle applicaties op dezelfde manier bijgehouden te worden.
Deelvraag 2: Op welke manier kunnen urenregistraties van verschillende applicaties
gestandaardiseerd worden?
Antwoord op deze deelvraag is terug te vinden in hoofdstuk 4:
Aangezien applicaties op verschillende wijze worden bijgehouden in de praktijk, is het voor
het betrokken management moeilijk zichtbaar in hoeverre beheer en onderhoud van
applicaties afwijken ten opzichte van andere applicaties. Zo moesten we de geregistreerde
uren per applicatie omgooien naar onze minimale set aan urenposten. We hebben hiervoor
een verdeelsleutel ontwikkeld die ervoor zorgt dat we de uren konden omzetten m.b.v.
vertaalslagen.
Figuur 4.10 Voorbeeld verdeelsleutel voor een contract (herhaling)
© Getronics PinkRoccade 2007
81
Conclusie
Aan de hand van drie stappen kunnen we zoals weergegeven in figuur 4.10 geregistreerde
uren omzetten naar onze minimale set aan urenposten. De service manager geeft tijdens
stap 1 aan tot welke ASL urenposten zijn geregistreerde uren behoren. Zo kunnen we aan
de hand van deze gegevens de verdere verdeling invullen. Stap 2 is een kwestie van het
optellen van de uren en stap 3 is de verdeling volgens die van Marcel Oevermans. Voor
iedere applicatie kunnen we vervolgens een basisset aan urenposten construeren en
vergelijken met de percentuele verdeling van de minimale set aan beheeruren. Om de
omzetting van contracten nog eens uitvoerig te lezen verwijzen we u door naar paragraaf
4.6. Hierin geven we aan de hand van een voorbeeld aan op welke manier geregistreerde
uren omgezet kunnen worden naar onze minimale set aan urenposten. Zo maakt het ook
niet uit hoeveel variabelen de urenposten bestaan. Indien elk contract op een uniforme
manier bijgehouden wordt, dan is de verdeelsleutel overbodig.
Deelvraag 3: Is de huidige normverdeling aan urenposten van beheer en onderhoud
uniform en praktisch toepasbaar?
Antwoord op deze deelvraag is terug te vinden in hoofdstuk 5 en hoofdstuk 6:
De percentuele verdeling van de minimale set aan urenposten hebben we in hoofdstuk 5
per applicatie in kaart gebracht (case study). Aan de hand van onze dataset, dat bestond
uit 12 applicaties, hebben we een tabel geconstrueerd om de verschillen te weergeven
t.o.v. de normering met 4 urenposten. Uit onze case study bleek dat er wat verschillen
zitten t.o.v. de normering, zie tabel 5.19.
Normering
Normering op basis van data
BH AO SM HD
34.5 43.5 10
12
37.4 32.7 21.9 7.8
Tabel 5.19 normering op basis van data (herhaling)
In dit tabel kunnen we de verschillen van de gehele dataset per urenpost zien. De
verschillen hebben we overigens in hoofdstuk 6 verklaard. Hierin hebben we het model
gevalideerd en de afwijkingen en spreidingen per cluster of per applicatie verklaard. Over
de gehele dataset viel het ons op dat de urenpost SM hoger uitviel en de HD urenpost te
laag uitviel. Dit was uit onze verdeelsleutel uit figuur 4.10 en de uitleg van Marcel
Oevermans te verklaren. Zo zijn we erachter gekomen dat organisaties uitzonderingen
kunnen maken tijdens stap 1 om meer uren toe te kennen aan HD, waardoor er in het
algemeen de uren voor HD hoger zullen uitvallen. Verder konden we ervoor zorgen dat de
uren voor SM lager uitvielen, door gebruik te maken van correctiefactoren. In figuur 6.7
zien we aan de hand van een voorbeeld hoe correctiefactoren toegepast kunnen worden.
Tevens kunnen we met behulp van correctiefactoren verklaren dat de percentuele
verdeling van de minimale set aan urenposten praktisch toepasbaar zijn. Deze uitspraak
doen we op basis van onze dataset en daarmee hebben we ook onze verdeelsleutel
enigszins aangepast met correctiefactoren.
82
© Getronics PinkRoccade 2007
Conclusie
7.2 Hoofdvraag
In de vorige paragraaf hebben we kort antwoord gegeven op al onze deelvragen. Tevens
hebben we door het beantwoorden van deze vragen ook antwoord gegeven op de
hoofdvraag. Hieronder zien we wederom onze hoofdvraag die we opgesteld hadden in
paragraaf 1.5:
Hoofdvraag: In hoeverre werkt de kennis en ervaring van beheer en onderhoud van
applicaties door in het standaardiseren van uniforme urenposten om deze overzichtelijker
te maken voor het betrokken management?
Onze hoofdvraag hadden we in drie deelvragen (zie paragraaf 7.1) opgesplitst, waardoor
we bij elke beantwoording van een deelvraag ook een deel van de hoofdvraag hebben
beantwoord. Onze hoofdvraag is toegespitst op alle organisaties die m.b.v. ASL hun uren
voor beheer en onderhoud gestandaardiseerd willen hebben. Nou zijn wij uitgegaan op
basis van de situatie binnen GPR, maar elke organisatie die applicaties in beheer en
onderhoud heeft kan leren van deze situatie. Zo hebben we deelvraag 1 beantwoord in
hoofdstuk 3 en 4, deelvraag 2 beantwoord in hoofdstuk 4 (hiermee hebben we het
academisch niveau van het onderzoek bereikt) en deelvraag 3 hebben we beantwoord in
hoofdstuk 5 en 6 (hiermee hebben we de praktische doelstelling van het onderzoek
bereikt).
7.3 V-GQM (7) GOAL REFINEMENT
We zijn nu aangekomen bij de zevende en laatste stap van het V-GQM model, Goal
Refinement. Binnen deze stap zullen we twee factoren naar voren halen die ons niet alleen
zullen helpen voor het succesvol afronden van ons onderzoek, maar ook een bijdrage
zullen leveren aan de bruikbaarheid voor organisaties in het algemeen. Ons onderzoek is
gebaseerd op de huidige situatie binnen GPR. De 4 urenposten kunnen op iedere situatie
toegepast worden, waarbij organisaties streven naar standaardisatie van hun processen
voor beheer en onderhoud van applicaties, toegepast op ASL. Hieronder zullen we de twee
factoren bespreken.
External factors
Binnen de externe factoren zullen we de doelen van de organisatie en veranderingen in de
setting bespreken. Deze doelen hadden we tijdens de goal statement fase van het V-GQM
besproken die tevens bestonden uit de eerste en tweede deelvraag van het onderzoek.
Deze doelen hebben we in paragraaf 7.1 besproken en beantwoord. De setting van het
onderzoek is wel veranderd tijdens ons onderzoek. Zo hadden zouden we in eerste
instantie een lijst met 12 ASL processen met de bijbehorende percentuele verdeling
onderzoeken. Daarmee wilden we weten of bestaande applicaties overeenkwamen met het
model van Marcel Oevermans. In praktijk bleek dat de urenregistraties niet direct werden
bijgehouden volgens de ASL processen, waardoor we genoodzaakt waren om een minimale
set aan beheerposten te construeren waarop de beheer en onderhoud uren bijgehouden
konden worden.
Input data collection
Binnen de input data collection zullen we de beperkingen van de gegevensverzameling en
de lessons learned bespreken. We hadden het liefst meerdere contracten van applicaties
willen hebben voor het onderzoek, alleen konden we maar over 12 contracten
bemachtigen. Tijdens het afronden van het onderzoek waren we tot de conclusie gekomen
dat de minimale set met 4 urenposten een bruikbare verdeling zou zijn. Indien we over
meerdere contracten zouden beschikken, zouden we wat sterker in ons schoenen staan bij
deze bewering. Verder kwamen we er snel achter dat de interviewvragen niet volledig
werden ingevuld door de service managers. Dit kwam doordat sommige gegevens niet
beschikbaar waren, zoals de functiepunten die niet bij alle applicaties geteld waren. Verder
hadden we ook data verzameld waar we achteraf niet zo veel aan gehad hebben, zoals de
© Getronics PinkRoccade 2007
83
Conclusie
geplande uren versus de gerealiseerde uren en de contractduur. In paragraaf 6.3 hebben
we getracht de theorie die we beschreven hadden te valideren. We konden niet een directe
conclusie trekken over de invloed van bepaalde variabelen op beheer en onderhoud. Wel
hebben we uitkomsten proberen toe te lichten, alleen kwamen we er snel achter dat onze
dataset hier te klein voor was.
7.4 Toegevoegde waarde en Vervolgonderzoek
In deze paragraaf zullen we de toegevoegde waarde van ons onderzoek voor organisaties
bespreken.
Standaardisatie urenposten bij de contracten
Op het moment dat we alle contracten binnen hadden gekregen, zagen we dat er op
verschillende urenposten uren voor beheer en onderhoud werden geregistreerd. Het was
voor ons niet duidelijk bij welke ASL processen deze hoorden. Binnen de organisatie werd
ons verteld dat ieder contract uniek en anders van aard is. Ook de persoonlijke ideeën van
de service managers hadden invloed op de contracten. Binnen de organisatie waren er
geen uniforme urenposten, waarop de beheer en onderhoud uren geregistreerd konden
worden. Hierdoor moesten we elk contract standaardiseren naar onze minimale set met 4
urenposten.
Toegevoegde waarde
Na standaardisatie van de 12 contracten hebben we deze tegenover de minimale set aan
urenposten gezet. De verdeling hebben we aan de hand van deze contracten gevalideerd.
Wij raden organisaties om op 4 urenposten (Beheer 34.5%, Adaptief Onderhoud 43.5%,
Service Management 10% en Helpdesk 12%) hun urenregistraties bij te houden. De
minimale set met de 4 urenposten zijn naar onze mening een bruikbaar standaard dat
toegepast is op ASL. ASL is een standaard binnen applicatiebeheer en volgens ons een
prima middel voor een succesvolle inrichting van beheer en onderhoud van applicaties.
Als alle applicaties op een uniforme manier bijgehouden worden is het voor het betrokken
management makkelijker om een overzicht te maken van de uren. Afwijkingen en
spreidingen van applicaties kunnen verhaald worden bij de verantwoordelijke service
manager. Als de Helpdesk uren aan de hoge kant liggen, kan er zelf gesproken worden
met de klant om de afspraken te herzien. Het contract kan dan eventueel veranderd
worden.
Met het standaardiseren van de processen kunnen organisaties tevens ook naar een hoger
level van het CMMI model streven. Het CMMI model hadden we in hoofdstuk 2 beschreven
en verteld dat GPR naar niveau 3 van het CMMI model streeft. Het is dan van belang dat
organisaties zoveel mogelijk hun beheer en onderhoud processen standaardiseren. Indien
ze niet standaardiseren, zullen ze helaas niet verder komen dan niveau 1 van het CMMI
model. Organisaties die streven naar niveau 3 streven, moeten uniforme urenposten
hebben.
Vervolgonderzoek
Allereerst willen we dat de uitkomsten van het onderzoek zo betrouwbaar mogelijk zijn. Dit
doen we door het vergaren van meerdere contracten en volledig ingevulde vragenlijsten.
Organisaties kunnen hierna hun eigen situatie in kaart brengen en kijken in hoeverre de
uitkomsten overeenkomen met de minimale set. Verder zouden ze aan de hand van de
vragenlijst enig verband kunnen ontdekken over factoren die invloed hebben op beheer en
onderhoud van applicaties. Wij hebben in dit onderzoek niet echt de directe gevolgen van
de factoren kunnen ontdekken. Aangezien applicaties uniek zijn, kunnen ze eventueel
nieuwe percentuele verdelingen maken. Contracten die gelijkenis hebben zouden dan in
84
© Getronics PinkRoccade 2007
Conclusie
clusters gegroepeerd kunnen worden. Het idee is dan om niet 1 minimale set aan
urenposten te gebruiken als standaard, maar meerdere standaarden. Deze standaarden
kunnen eventueel gegroepeerd worden onder grote/kleine, nieuwe/oude of gemigreerde
applicaties. De organisatie moet over een groot aantal applicaties beschikken, om
vervolgens het gemiddelde per cluster te nemen als standaard. Het is dan belangrijk dat
de clusters gemeenschappelijke kenmerken hebben, zoals grote/kleine, nieuwe/oude of
gemigreerde applicaties. Iedere organisatie moet zelf bepalen hoeveel standaarden ze dan
gaan gebruiken. Voorbeeld: Minimale Set aan urenposten bij een grote applicatie met
10.000 en meer functiepunten, inclusief de bijbehorende percentuele verdeling.
Verder hadden we in paragraaf 6.4 aangegeven dat er correctiefactoren toegepast kunnen
worden tijdens de standaardisatie van bestaande urenposten. Wij hadden in ons voorbeeld
een 75-25 % gehanteerd. Het is belangrijk voor een organisatie om te weten wat de
exacte verhouding is tussen de ASL processen (zie figuur 6.7). Zo moeten organisaties dit
proces nog verder afstemmen op hun eigen situatie. Dit zou volgens ons een prima
motivatie voor vervolgonderzoek kunnen zijn.
© Getronics PinkRoccade 2007
85
Figuren- en tabellenlijst
Figuren- en tabellenlijst
Tabel 1.1
Figuur 1.2
Normverdeling beheeruren (ASL Processen)
Opbouw Scriptie
Tabel 2.1
Figuur 2.2
Faseringsmodellen voor sourcing
De sourcing life cycle van het PON
Figuur 3.1
Figuur 3.2
Tabel 3.3
Tabel 3.4
ASL Framework
ASL Framework (Uitvoerend)
Definities Onderhoud
Relaties Subjectieve Informatie
Figuur 4.1
Tabel 4.2
Tabel 4.3
Tabel 4.4
Tabel 4.5
Figuur 4.6
Tabel 4.7
Tabel 4.8
Tabel 4.9
Figuur 4.10
Tabel 4.11
V-GQM methode
Question definition
Question-Metric Definitie
Opzet vragenlijst
Verdeelsleutel1
Framework Urenregistratie Marcel Oevermans
Verdeelsleutel2
Verdeelsleutel3
Percentuele verdeling nieuwe basisset
Voorbeeld verdeelsleutel voor een contract
Uitvoer Voorbeeld
Tabel 5.1
Tabel 5.2
Figuur 5.3
Figuur 5.4
Figuur 5.5
Figuur 5.6
Figuur 5.7
Figuur 5.8
Figuur 5.9
Figuur 5.10
Figuur 5.11
Figuur 5.12
Figuur 5.13
Figuur 5.14
Figuur 5.15
Figuur 5.16
Figuur 5.17
Figuur 5.18
Tabel 5.19
Figuur 5.20
Figuur 5.21
Figuur 5.22
Figuur 5.23
Nieuwe Normering
Dataset
Scatterplot Matrix
Stars Plot
Screeplot PC
Scoreplot PC
Biplot
MDS
Complete Linkage
Average
Single Linkage
K-means clustering
K-means BH en AO
K-means BH en SM
K-means AO en HD
Single Lineair
Q-Q plot
Multiple lineair
Normering op basis van data
Residual Beheer
Q-Q plot Beheer
MDS ASL processen
Complete Linkage ASL
Tabel 6.1
Tabel 6.2
Tabel 6.3
Tabel 6.4
Tabel 6.5
Tabel 6.6
Figuur 6.7
Tabel 6.8
Cluster 1
Cluster 2
Cluster 3
Cluster 4
Uitschieters
Correctiefactor
Verdeelsleutel Correctiefactor
Correctiefactor SM
86
© Getronics PinkRoccade 2007
Terminologielijst
Terminologielijst
BEGRIP
BESCHRIJVING
ACM
(Applications Cycle Management) ACM kent als doelstelling het
vormgeven van een langetermijnstrategie voor de verschillende
objecten in en het geheel van de informatievoorziening van een
organisatie, in relatie met het langetermijnbeleid van deze
organisatie.
Applicatie
Het geautomatiseerde gedeelte van een informatiesysteem,
bestaande
uit
applicatieprogrammatuur,
applicatiegebonden
gegevens, de (fysieke) opslagstructuren waarin deze gegevens zijn
ingebed en de bijbehorende documentatie.
Applicatie Outsourcing
Application
outsourcing
is
a
multiyear
or
annuity
contract/relationship involving the purchase of ongoing application
services for managing, enhancing and maintaining custom or
packaged application software in the server/host or desktop
platforms.
Applicatiebeheer
Geheel van taken, verantwoordelijkheden en activiteiten dat er
dient om applicaties in zodanige staat te brengen en houden,
deze voldoen aan de vastgestelde eisen en behoeften van
eigenaren ervan gedurende de gehele levensduur van
bedrijfsprocessen die door de applicaties ondersteund worden.
Applicatieobject
Onderdeel dat direct gerelateerd is of onderdeel uitmaakt van een
applicatie, zoals programma’s, sources, gegevensbestanden,
documentatie, datadefinities, testbestanden/scripts etc.
ASL
Een public-domainstandaard voor het professionaliseren van
applicatiebeheer, bestaande uit een framework, best practices en
een groeimodel.
Availability Management
(Beschikbaarheidsbeheer) Het proces dat de beschikbaarheid en
betrouwbaarheid van diensten en applicatieobjecten verzorgt,
bewaakt en waarborgt.
Backfiring
Bij backfiring worden de LOC en het aantal functiepuntenmetriek
met elkaar gekoppeld.
Back-sourcing
1) het verwerven van de bedrijfsmiddelen die nodig zijn om
bepaalde bedrijfsprocessen uit te voeren die tot dan toe als dienst
door een externe partij waren verleend, en 2) die bedrijfsprocessen
vanuit de eigen organisatie als diensten leveren aan de eigen
organisatie.
Beheer
Geheel van taken, verantwoordelijkheden en activiteiten dat
noodzakelijk is om objecten in zodanige staat te houden, dat deze
blijven voldoen aan de vastgestelde eisen en behoeften van de
eigenaren ervan.
Capacity Management
(Capaciteitsbeheer) Het proces dat zorgdraagt voor de optimale
inzet van (applicatiegerelateerde) middelen, d.w.z. op de juiste
plaats, op het juiste moment, in de juiste hoeveelheden en tegen
gerechtvaardigde kosten.
Change Management
(Wijzigingsbeheer) Het proces dat sturing geeft aan het
inventariseren, prioriteren, initiëren, evalueren en bijsturen van de
gewenste veranderingen aan een applicatie.
© Getronics PinkRoccade 2007
toe
dat
de
de
87
Terminologielijst
Change Request
Wijzigingsverzoek, een verzoek om aan te geven wat de gevolgen
van een gewenste wijziging zijn.
Configuration Management
(Configuratiebeheer) Het proces rondom het registreren en
bijhouden van informatie over het gebruik van de versies van
applicatieobjecten.
Continuity Management
(Continuïteitsbeheer) Het proces waarmee maatregelen getroffen
worden om de continuïteit van de uitvoering en ondersteuning van
de informatievoorziening door middel van informatiesystemen op
langere termijn te verzorgen.
Cost Management
Het proces rond het beheersen en doorbelasten van de kosten van
de IT-dienstverlening.
Design (Ontwerp)
Het proces waarin de gebruikersspecificaties zodanig worden
uitgewerkt en vastgelegd, in een functioneel ontwerp, dat deze
daarna op een eenduidige wijze kunnen worden gerealiseerd en
getest.
Follow-upsourcing
1) het overdragen van een bepaalde dienstverlening van een
leverancier aan een ander leverancier en vervolgens 2) het
voortzetten van de dienstverlening door die andere leverancier
voor een bepaalde periode aan de oorspronkelijke uitbesteder op
basis van een resultaatverplichting.
Functiepuntenmetriek
Function points measure the functionality from the users’ point of
view.
GQM
(Goal Question Metric)
Is een methode die men kan gebruiken
bij het uitvoeren van empirische studies op software projecten.
Greenfield Insourcing
1) het opzetten van bepaalde bedrijfsprocessen met de daarbij
behorende bedrijfsmiddelen en medewerkers voor een bepaalde
organisatie en vervolgens 2) het verlenen van diensten aan die
organisatie gedurende een bepaald aantal jaren op basis van die
processen met een resultaatverplichting.
Impact Analysis
(Impactanalyse) Het proces waarin in kaart wordt gebracht wat de
gevolgen zijn van voorgestelde wijzigingen, op basis waarvan
wordt bepaald wat de beste globale oplossingsrichting is om de
wijzigingen te realiseren.
Implementation
(Implementatie) Het proces dat alle activiteiten omvat die gedaan
moeten worden om gerealiseerde wijzigingsopdrachten te
effectueren voor gebruik.
Incident Management
(Incidentbeheer) Het proces, dat de primaire afhandeling van
vragen,
wensen
en
verstoringen
verzorgt,
inclusief
de
communicatie van en naar gebruikers/functioneel beheer.
Informatiesysteem
Het geheel van applicatieve functies (zoals invoer, uitvoer en
bewerkingen), gegevensverzamelingen, technische voorzieningen
en handmatige procedures dat bedrijfsprocessen ondersteunt.
Insourcing
1) het overnemen van bepaalde bedrijfsprocessen en de daarbij
horende bedrijfsmiddelen en medewerkers van een bepaalde
organisatie en vervolgens 2) het verlenen van diensten aan die
organisatie gedurende een bepaald aantal jaren op basis van die
processen met een resultaatverplichting.
88
© Getronics PinkRoccade 2007
Terminologielijst
Intasking
1) het overnemen van bepaalde bedrijfsprocessen en de daarbij
behorende bedrijfsmiddelen en medewerkers van een externe
organisatie en vervolgens 2) het verlenen van diensten aan die
organisatie gedurende een bepaald aantal jaren op basis van die
processen met een resultaatverplichting.
Lines of Code
(LOC) A line of code is any line of program text that is not a
comment or blank line regardless of the number of statements or
fragments of statements on the line.
Metriek
(Measurement) is the process by which numbers or symbols are
assigned to attributes of entities in the real world in such a way as
to characterize the attributes by clearly defined rules
OCM
(Organization Cycle Management) OCM kent als doelstelling het
ervoor zorgdragen dat invulling gegeven wordt aan het beleid en
de toekomst van de serviceorganisatie. Hierin wordt de toekomst
van
de
serviceorganisatie
(applicatiebeheerorganisatie)
uitgestippeld en vertaald naar een beleid.
Off-shore
Waarbij de operations in een andere regio plaatsvinden dan waar
de uitbesteder is gevestiogd.
Onderhoud
Het aanbrengen van wijzigingen in een informatie systeem, ten
einde fouten te elimineren of gewenste functionaliteit toe te
voegen.
Onderhoud Adaptief
Het aanpassen van één of meer delen van het informatiesysteem
als gevolg van wijzigingen in de omgeving van die delen.
Onderhoud Correctief
Het herstellen van
informatiesysteem.
Onderhoud Perfectief
Het aanpassen van een component van het informatiesysteem aan
veranderde kwaliteitseisen van de gebruikers.
Onderhoud Preventief
Het corrigeren van componenten van het informatiesysteem,
zonder aanleiding in de vorm van een probleemrapport. Met als
doel (a) het voorkomen van toekomstige problemen, of (b) het
verhogen van de onderhoudbaarheid.
On-shore
Waarbij de operations nog in hetzelfde land plaatsvinden als waar
de uitbesteder is gevestigd.
On-site
Operations wanneer de dienstverlening nog vanaf de locatie van de
uitbesteder wordt verleend.
Outsourcing
1) het overdragen van bepaalde bedrijfsprocessen en de daarbij
horende bedrijfsmiddelen en medewerkers aan een externe
leverancier en vervolgens 2) het gedurende een bepaald aantal
jaren terugontvangen van diensten van die leverancier op basis
van die processen met een resultaatverplichting.
Outtasking
1) het overdragen van bepaalde bedrijfsprocessen aan een externe
leverancier
zonder
de
bijbehorende
bedrijfsmiddelen
en
medewerkers en ver vervolgens 2) het gedurende een bepaald
aantal jaren terugontvangen van diensten van die leverancier op
basis van die processen met een resultaatverplichting
Planning and Control
Het proces dat ervoor zorgt dat de afgesproken dienstverlening
tijdig en met de juiste menscapaciteit gerealiseerd wordt.
Quality Management
Het proces dat zorgdraagt voor de handhaving van de (interne)
kwaliteit van proces en product door deze te definiëren en te
bewaken.
© Getronics PinkRoccade 2007
afwijkingen
in
componenten
van
het
89
Terminologielijst
Realization
(Realisatie) Het proces waarin een functioneel ontwerp wordt
vertaald in een technisch ontwerp en vervolgens naar
programmatuur die een unittest succesvol doorloopt.
Remote Operations
Groot deel van de dienstverlening vindt plaats vanaf de locatie van
de inbesteder.
Service Level Management
Het proces dat de dienstverlening in lijn brengt en houdt met de
wensen en verwachtingen van de klant.
SLA
Een SLA definieert de verplichtingen en verantwoordelijkheden van
aanbieder en afnemer van de diensten, waarbij het uitgangspunt is
dat optimaal invulling wordt gegeven aan de huidige en
toekomstige behoeften van de afnemer, tegen reële kosten
Software Control en
Distribution
(Programmabeheer en distributie) Het proces dat de
activiteiten bevat rond de beheersing en distributie van de
(operationele) applicatieobjecten naar de verschillende ontwikkelen testomgevingen en naar productie.
Software Maintenance
(Software Beheer) The modification of a software product after
delivery to correct faults, to improve performance or other
attributes or to adapt the product to a modified environment.
Testing
(Testen) Het proces dat de activiteiten bevat om vast te stellen of
datgene wat ontworpen is, ook inderdaad gerealiseerd is.
Unittest
Hierin wordt getest of de gerealiseerde of gewijzigde programma’s
voldoen aan de daaraan gestelde eisen.
V-GQM
(Validating Goal Question Metric) Is een methode voor het
analyseren van een GQM studie, nadat data is verzameld met als
doel de validatie van de studie.
90
© Getronics PinkRoccade 2007
Literatuurlijst
Literatuurlijst
[AGGARWAL]
Aggarwal, K.K., Singh, Y., Chandra, P., Puri, M., An expert committee model to
estimate lines of code (September 2005), ACM SIGSOFT Software Engineering
Notes, Vol. 30, Issue 5, pp. 1-4.
[ALBRECHT]
Albrecht, A., Jaffeney, J.E., Software Function Source Lines of Code and
Development Effort Prediction :A Software Science Validation (1983), IEEE Trans.
Software Engineering, SE-9, pp. 639-648.
[ASL_F]
http://www.aslfoundation.org/
[ASL_W]
http://www.aslfoundation.org/fileadmin/Documents/ASL_Woordenlijst_2.0.1.pdf
[BASILI]
Basili, V. R., Caldiera, G., Rombach, H.D., Goal Question Metric paradigm (1994),
Encyclopedia of Software Engineering, Vol. 1, pp. 528-532, John Wiley & Sons.
[BEULEN]
Beulen, E.P., Uitbesteden van IT dienstverlening (2002), ten Hagen & Stam, Den
Haag.
[BHATT]
Bhatt, P., Williams, K., Shroff, G., Influencing factors in outsourced software
maintenance (May 2006), ACM SIGSOFT Software Engineering Notes; Vol. 31, Issue
3, ACM Press.
[BROOK]
Brooks, P., Metrics for IT Service Management (April 2006), van Haren publishing,
Zaltbommel.
[CHAPIN]
Chapin, N., Software maintenance: a different view (1985), in AFIPS Conference
Proceedings, Vol. 54, pp. 328-331, NCC, AFIPS Press, Reston, VA.
[CMMI]
Capability Maturity Model Integration (CMMI SM) (Maart 2002), Version 1.1,
Carnegie Mellon - Software Engineering Institute.
[DELEN1]
Delen, G.P.A.J., Decision- en controlfactoren voor sourcingvan IT (2005), van Haren
publishing, Zaltbommel.
[DELEN2]
Delen, G.P.A.J., Outsourcing van IT – a management guide (2006), van Haren
publishing, Zaltbommel.
[EVERITT]
Everitt, B.S., Dunn, G., Applied Multivariate Data Analysis 2nd Edition (2001), A
Hodder Arnold Publication, ISBN 0340741228.
[FENTON]
Fenton, Norman E. & Whitty, Robin. "Introduction," 1-19. SoftwareQuality Assurance
and Measurement, A Worldwide Perspective (1995),Norman Fenton, Robin Whitty,
and Yoshinori Iizuka, ed. London:International Thomson Computer Press.
[GIAGRANDE]
Giagrande Jr., E., CS1 programming language options (January 2007), Vol. 22,
Issue 3, pp. 153-160, Journal of Computing Sciences in Colleges.
[GPR1_2007]
Getronics PinkRoccade Site, zie:
http://www.getronicspinkroccade.nl/_nieuws/en_denken_en_doen/en_denken_en_d
oen.htm
[HOPPER]
Hopperman, J., Matzke, P., From ASP To Selective Application Outsourcing
(September 13, 2005), Forrester Reasearch.
[IEEE]
IEEE Std. 1219: Standard for Software Maintenance, IEEE Computer Society Press,
1993.
[JONES_1]
Jones, C., How Software Estimation Tools Work (February 2005) Version 5, Software
Productivity Research, Inc.
[JONES_2]
Jones, C., The Economics Of Software Maintenance In The Twenty First Century
(February 2006) Version 3, Software Productivity Research, Inc.
© Getronics PinkRoccade 2007
91
[KEMERER]
Kemerer, C.F., Slaughter, S.A., Determinants of Software Maintenance Profiles: An
Empirical Investigation (1997), Vol. 9, pp. 235-251, John Wiley & Sons, Inc., New
York.
[MAAT]
Maat, M., Vogt, H., Migratie — Het legacy probleem aangepakt, SERC whitepaper
(November 1998).
[MART1]
Martorelli, W., Ross, C.F., Key Preparatory Steps For Applications Outsourcing
(September 30, 2005), Forrester Research.
[MOSLEY]
Mosley, D., When to migrate legacy embedded applications (December 2006),
Volume XXVI, Issue 3, pp. 77-80, DDC-I, Inc., Phoenix.
[MUSTACEVIC]
Mustacevic, M., Automatisering van het tellen van functiepunten (Oktober 2000),
Master’s Thesis, University of Amsterdam, Supervised Master’s Theses.
[NESMA]
http://www.nesma.nl/hbfpa.htm
[NIESSINK]
Niessink, F., Vliet, H., van, Software maintenance from a service perspective (2000),
Journal of Software Maintenance: Research and Practice, Vol. 12, pp. 103-120, John
Wiley & Sons, Inc., New York.
[O’CALLAGHAN]
O’Callaghan, A., Object Technology Migration is not just Reverse Engineering (1997)
, Object Expert 2, nr. 1, pp. 16-19.
[OLSSON]
Olsson, T., Runeson, P., V-GQM: A Feed-back Approach to Validation of a GQM
Study (April 2001), International Software Metrics Symposium, pp. 236-245.
[POLS]
Pols, R., van der, ASL: een framework voor applicatiebeheer (2001), tenHagenStam
Uitgevers, Apeldoorn.
[PON]
Platform Outsourcing Nederland (http://www.platformoutsourcing.nl/)
[ROSS]
Ross, C.F., Firms’ Software Outsourcing Plans For 2006 (January 3, 2006), Forrester
Reasearch.
[R-PROJECT]
Software programma (http://www.r-project.org/)
[VAN DALE]
Online woordenboek (www.vandale.nl)
[YOUNG]
Young, A., Scardino, L., Karamouzis, F., Marriot, I., Iyengar, P., User Guide for
making application outsourcing provider choices (Augustus 2005), Gartner.
92
© Getronics PinkRoccade 2007
Appendix A – Interview vragen
Appendix A – Interview vragen
Naam Servicemanager
Naam contract
Marcel Oevermans
EDMS
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
Informix
Ministerie van SZW en VWS
Naam Servicemanager
Naam contract
Marcel Oevermans
9 jaar (geen legacy)
Nvt
Onbekend
1 jaar met optie voor verlenging
Beheer 1691 uur gepland, 1276 gemaakt
PUR (Pensioen en Uitkeringsraad)
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
Oracle
De PUR is een zelfstandig orgaan vallend onder het Ministerie van
VWS
10-15 jaar
Nvt
Onbekend
1 jaar met optie voor verlenging
Naam Servicemanager
Naam contract
Marc Vergoossen
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
© Getronics PinkRoccade 2007
Beheer 604 uur gepland, 706 uur gemaakt
ODS
.NET/Oracle
De ODS is een zelfstandig orgaan vallend onder het Ministerie van
VWS
2 jaar (2005)
geen
1.142
Jaar van telling: Oktober 2005
-
93
Appendix A – Interview vragen
Naam Servicemanager
Naam contract
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
Naam Servicemanager
Naam contract
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
Naam Servicemanager
Naam contract
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
Naam Servicemanager
Naam contract
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
94
Marc Vergoossen
IMF
Cobol Dek Classic
Sociale verzekeringsmarkt
16 jaar (1991)
geen
1.810
Actuele telling
Marc Vergoossen
Resa/Fasa
Cobol Dek Classic
Sociale verzekeringsmarkt
20 jaar (1987)
geen
4.500
Jaar van telling: 1992
-
Marius Rook
EW/BWS
Oracle
Zorg (huursubsidies)
Cobol op mainframe eind jaren ’70 (legacy)
2000-2001 gemigreerd naar Oracle
6jaar (2000-2001)
10.000, Echter wordt er een beperkte (onbekende) hoeveelheid
functionaliteit gebruikt voor EW/BWS.
-
Richard Nordemann
GCU
(23750 – UW GCU-techn-onderh-2007)
Microsoft VB 6.0, VBA en VB .Net
UWV is overheidsinstantie die wettelijke uitkeringen verzorgt.
3 jaar (Applicatie is in 2004 in productie genomen, geen legacy)
Nvt
Aantal functiepunten is geschat op 750.
Applicatie heeft echter zo’n 15000 ontwikkeluren gekost.
Bij UWV wordt gewerkt met Beheer & Onderhoudcontracten van
maximaal 1 jaar.
Gepland: 6744 uur per jaar
Gerealiseerd: 6435 uur in 2006
© Getronics PinkRoccade 2007
Appendix A – Interview vragen
Naam Servicemanager
Gert Jacobs (overall servicemanager) vanuit Productgroep
ArboTotaal A&SM.
Anje Belmon servicemanager voor deel dat in de Oracle
Maintenancestraat van A&SM is belegd (m.n. realisatie van
onderhoudsopdrachten)
Naam contract
Naam solution: ArboTotaal.
Dit is een product t.b.v. Verzuimmanagement. Er zijn vele
contracten (het product is momenteel bij 15 klanten in gebruik,
met totaal zo’n 1.000 gebruikers).
Oracle Designer 6i
ArboTotaal wordt gebruikt door organisaties die zich bezig houden
met Verzuimmanagement (o.a. Arbodiensten)
4 jaar (Eind 2003 is het vernieuwde product voor de eerste klant
in productie gegaan. Het is geen legacy systeem)
In 2001 en 2002 heeft herbouw plaatsgevonden (zowel op
technisch als functioneel gebied).
10.000
n.v.t.
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
Naam Servicemanager
Naam contract
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
Extra info
Naam Servicemanager
Naam contract
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
© Getronics PinkRoccade 2007
Er zijn van te voren geen uren per ASL activiteit begroot. Wel is er
een overall solutionplan hoe het met de kosten staat en waar we
naar toe willen, willen we voldoende marge draaien. Dit plan
voorziet in een afname van Onderhoud & Beheer kosten waarbij in
een periode van 5 jaar de uren die aan onderhoud en beheer
worden besteed met 50% worden gereduceerd, terwijl het aantal
users sterk toeneemt / verdubbeld.
Harold Hagen
GEFIS
Cobol (gegenereerd vanuit Visual Age Generator) voor zowel
online als batch
overheid
± 15 jaar
nvt
± 10.000
December 2007
± 3000 gepland, 2623 gerealiseerd
Voor GEFIS geldt dat het een relatief oud systeem betreft waarop
nauwelijks onderhoud (correctief en adaptief) wordt uitgevoerd.
Harold Hagen
Financieel portaal SBB
Centrale omgeving:
Cobol (gegenereerd vanuit Visual Age Generator) voor online
Cobol (batch)
Decentrale omgeving:
Bestaat uit meerdere servers (± 15) waarop ondersteunende
applicaties draaien. Beheer wordt door GPR uitgevoerd.
Onderhoud ligt voor een deel bij een onderaannemer.
overheid
± 15 jaar
nvt
± 9.000
Augustus 2009
8397 gepland, 8236 gerealiseerd
95
Appendix A – Interview vragen
Gerealiseerde uren
Extra info
Naam Servicemanager
Naam contract
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
Naam Servicemanager
Naam contract
Soort Programmeertaal
In welke markt opereert de
organisatie?
Leeftijd van het systeem
Migratie
Aantal functiepunten
Contractduur
(voor outsourcing)
Geplande uren versus
Gerealiseerde uren
96
Voor SBB geldt dit ook voor het centrale (mainframe) deel. Verder
geldt voor SBB dat er in 2006 contractonderhandelingen zijn
geweest waardoor het aantal uren voor strategisch en tactisch
management veel hoger is.
Ronald Dekker
NEa
.Net
Semi Overheid
2 jaar, geen legacy
NVT
Niet te bepalen
2 jaar
Gepland 2600 per jaar
Gerealiseerd 2900 (inclusief 1-malig inwerken)
Ronald Dekker
Ring Amsterdam
.Net
Gezondheidszorg
2 jaar
NVT
Niet te bepalen
Per jaar verlenging
Gepland 600 per jaar
Gerealiseerd 2000 (inclusief 1-malig inwerken)
© Getronics PinkRoccade 2007
Appendix B - Verdeelsleutels
Appendix B - Verdeelsleutels
© Getronics PinkRoccade 2007
97
Appendix B - Verdeelsleutels
98
© Getronics PinkRoccade 2007
Appendix B - Verdeelsleutels
© Getronics PinkRoccade 2007
99
Appendix B - Verdeelsleutels
100
© Getronics PinkRoccade 2007
Appendix B - Verdeelsleutels
© Getronics PinkRoccade 2007
101
Appendix B - Verdeelsleutels
102
© Getronics PinkRoccade 2007