Evaluatie Uniforme Normverdeling Beheeruren bij Applicatie Insourcing, toegepast op ASL

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


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


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:


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


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?


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


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.


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


• • • •

• • •

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


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


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


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.


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


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


13


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



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.


15


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



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


17


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


Capacity 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]



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.


19


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



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


21


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



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


23


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



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.


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



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.


27


•

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

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



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.


29


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



Change Management

Incident Management


Design


Capacity Management


Impact Analysis


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


Onderhoud Preventief Capacity Management


Onderhoud Perfectief


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:


31


• • • •

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



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


33


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


STAP 3

STAP 2

STAP 1


Figuur 4.10 Voorbeeld verdeelsleutel voor een contract


35


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 Íncident Management´, Ćonfiguration Management´, Ávailability Management´, Ćontinuity 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 Ćonfiguration 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



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.


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.


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


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.


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


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.


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


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.


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


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


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


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


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


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


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


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


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


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.


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


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


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


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.


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


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.


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


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


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


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.


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-


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.


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.


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


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


Validatie


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.


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


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.


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


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


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


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.


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.


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.


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


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)


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


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


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


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.


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


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.


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


toe dat de de

87

Terminologielijst

Change Request

Wijzigingsverzoek, een verzoek om aan te geven wat de gevolgen van een gewenste wijziging zijn.


(Configuratiebeheer) Het proces rondom het registreren en bijhouden van informatie over het gebruik van de versies van applicatieobjecten.


(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


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.


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


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.


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


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)


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



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


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



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.


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


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


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)


Appendix B - Verdeelsleutels



97


98




99


100




101


102


Evaluatie Uniforme Normverdeling Beheeruren bij Applicatie Insourcing, toegepast op ASL

Recommend Documents