17-1-2021
Afstudeer scriptie
Auteur:
Jansen, Matthijs, M
Achternaam, Voornaam & -Letter
435700
Student nummer
Begeleider:
Weijman, Floor, F.
Achternaam, Voornaam & -Letter Bedrijfsbegeleider:
Sijbesma, John, J
Achternaam, Voornaam & -Letter
Strategisch Adviseur IT en Informatiebeveiliging
Functie
Plaats & Datum:
I.
Voorwoord
Voor u ligt het scriptieverslag van mijn afstudeerperiode bij de gemeente Wierden. De scriptie is geschreven als onderdeel van de module “Afstuderen” van de opleiding HBO-ICT aan Hogeschool Saxion te Enschede. Gedurende 5 maanden ben ik werkzaam geweest bij de afdeling
“Bedrijfsvoering”. Tijdens deze periode ben ik begeleid door John Sijbesma
Het schrijven van deze scriptie was mooie uitdaging en een leerzaam proces. Een belangrijk onderdeel van deze scriptie is ITIL. ITIL is meerdere malen tijdens de collegelessen van het Saxion voorbijgekomen maar dit heb ik persoonlijk nog nooit hoeven implementeren. Om deze kennis dan ook daadwerkelijk toe te kunnen passen was een leerzaam proces. Tijdens het schrijven van deze scriptie zijn er ook een aantal uitdagingen geweest. Een hiervan, en ik denk ook de belangrijkste, is Corona. Toen ik een paar weken bezig was met het schrijven van deze scriptie werd er opgeroepen om zoveel mogelijk thuis te gaan werken. Dit gelde ook voor mij. Hier door heb ik de rest van mijn afstudeerperiode thuis moeten door brengen. Met als gevolg hiervan dat alle vergaderingen en gesprekken online moesten worden gehouden. Dit is natuurlijk een goed alternatief maar werkt lang niet zo makkelijk als wanneer je even snel naar iemand toe kan lopen om wat te vragen of overleggen.
Bij deze wil ik graag mijn bedrijfsbegeleider, John Sijbesma, bedanken voor de begeleiding tijdens deze periode. Ook wil ik van de gemeente Wierden, Bart ter Linde en Laurentz Freriksen bedanken voor hun hulp en feedback tijdens het schrijven van deze scriptie. John, Bart en Laurentz gaven mij veel ruimte en vrijheid in deze periode en ik kon altijd zonder problemen bij hun terecht voor vragen of dergelijke. Tot slot wil ik Floor Weijman bedanken voor de begeleiding vanuit het Saxion en voor alle feedback.
Matthijs Jansen
II.
Samenvatting
Dit document beschrijft de scriptie voor het afstudeerproject van de opleiding HBO-ICT. Deze scriptie bestaat uit alle eindproducten die aan de opdrachtgever worden geleverd. De opdrachtgever (de gemeente Wierden), is een gemeente in de regio Twente en telt ongeveer 200 medewerkers binnen verschillende afdelingen. In de huidige situatie van de gemeente Wierden is er weinig structuur op het gebied van het registreren en bijhouden van IT gerelateerde incidenten/ problemen en het ontbreken van een supportsysteem. De gemeente Wierden zou graag een aantal nieuwe processen willen ontwerpen en inrichten zodat er meer structuur ontstaat voor het registreren en bijhouden van incidenten/ problemen samen met een supportsysteem dat deze processen ondersteund. Om deze vraag te beantwoorden is er gebruik gemaakt van de methode “Ontwerponderzoek”. Deze methode bestaat uit een probleemanalyse, behoefteanalyse, contextanalyse, (inspirerend voorbeeld, welke te vinden is in hoofdstuk 4 van het vooronderzoek), een literatuuronderzoek en tot slot een ontwerp van het prototype.
Om de probleemanalyse uit te voeren, zijn een aantal methodieken gebruikt. De methodieken die gebruikt zijn, zijn als volgt: een vragenlijst (Face2face en schriftelijk) en een gesprek (persoonlijk gesprek en groepsgesprek). Uit de probleemanalyse is gekomen dat de gemeente Wierden weinig tot geen structuur heeft op het gebied van incidenten bijhouden, het ontbreken van een knowledge base waardoor incidenten steeds weer “opnieuw” uitgezocht moeten worden en het ad hoc reageren op gebeurtenissen omdat er geen vaste manier van werken is. Uit de conclusie van de probleemanalyse zijn de onderzoeksvragen gekomen die in het literatuuronderzoek behandeld worden.
Om de behoefteanalyse uit te voeren is er gebruik gemaakt van triangulatie. Triangulatie houdt in dat er vanuit verschillende perspectieven (oogpunten) wordt gekeken naar de behoeftes van meerdere stakeholders. Dit wordt gedaan middels een stakeholder analyse. Uit de behoefteanalyse zijn een aantal requirements gekomen. Enkele belangrijke requirements zijn onder andere dat de gemeente Wierden met behulp van het supportsysteem een vaste manier van melden wil creëren. Een ander belangrijke requirement is dat de gebruikers met het supportsysteem kunnen werken.
Bij het uitvoeren van de contextanalyse is er gebruik gemaakt van een groepsgesprek, deskresearch en Micro-Meso-Macro. Met Micro-Meso-Macro wordt er op 3 verschillende aggregatieniveaus gekeken naar de invloeden van verschillende factoren. In deze analyse is de huidige situatie geïnventariseerd en aan de hand daarvan zijn er randvoorwaarden gemaakt.
Vervolgens is er een literatuuronderzoek gedaan op de deelvragen, die uit de probleemanalyse zijn gekomen. Hieruit is gekomen dat er voor ITIL gekozen is met onder andere de volgende ITIL processen: Incident management, Problem management, Change management, Service Asset and Configuration management en Knowledge management
De keuze voor het supportsysteem is gevallen op TOPdesk met de volgende modules: Selfserviceportal, meldingen beheer, middelen beheer en wijzigings beheer. Uit het
literatuuronderzoek zijn ontwerpprincipes gekomen die gebruikt worden in het functioneel en technisch ontwerp.
In het functioneel ontwerp worden de ontworpen processen beschreven en worden er middels screenshots afbeeldingen getoond van het prototype. Op deze manier krijgt de opdrachtgever een beeld van hoe de toekomstige situatie er uit komt te zien. In het technisch ontwerp wordt er duidelijk beschreven hoe het prototype is ingericht.
Om de controleren of alle gestelde requirements verwerkt zijn in het prototype is er een testrapport gemaakt.
Tot slot is er een veranderstrategie, communicatieplan en uitrolplan gemaakt. Hierin staat beschreven hoe de gebruikers van de gemeente Wierden worden meegenomen/ betrokken in deze verandering en hoe de gemeente Wierden deze verandering kan gaan communiceren binnen de organisatie.
III.
Leeswijzer
Deze scriptie is een samenvatting van een aantal documenten, namelijk: het vooronderzoek, het ontwerp, de evaluatie, het communicatieplan en de bijlagen. Gedurende het lezen van deze scriptie wordt er een aantal keren verwezen naar deze documentatie omdat bepaalde informatie daar in meer detail beschreven staat. Dit komt omdat deze scriptie een “beknopte” versie is van al deze
documenten. De belangrijkste onderdelen van al deze documenten (het vooronderzoek, ontwerp, evaluatie en communicatieplan) zijn te lezen in deze scriptie.
De opbouw van deze scriptie is zoals in de samenvatting verteld, opgedeeld in een aantal onderdelen. Het eerste onderdeel is het vooronderzoek, bestaande uit vier hoofdstukken, met als eerste hoofdstuk de probleemanalyse. In dit hoofdstuk wordt de probleemstelling uitgelegd, wat de aanleiding is en worden de onderzoeksvragen bekend gemaakt.
Het tweede hoofdstuk is de behoefteanalyse. In dit hoofdstuk wordt ingegaan op de behoeften van de gemeente Wierden. Dit wordt geformuleerd door middel van requirements.
Het derde hoofdstuk is de contextanalyse. In dit hoofdstuk wordt de context van het afstudeerproject toegelicht. De uitkomst van dit hoofdstuk zijn de randvoorwaarden.
Het laatste hoofdstuk van het vooronderzoek is het literatuuronderzoek. In het literatuuronderzoek worden de onderzoeksvragen uit de probleemanalyse onderzocht en beantwoord. De uitkomst van dit literatuuronderzoek zijn verschillende ontwerpprincipes die weer terugkomen in het ontwerp van het prototype.
Het tweede onderdeel van deze scriptie is het ontwerp. Het ontwerp is gebaseerd op een prototype van het supportsysteem en bestaat uit twee hoofdstukken, namelijk: het functioneel en technisch ontwerp. In het functioneel ontwerp worden de ontworpen processen getoond samen met enkele functies van het toekomstige supportsysteem. In het technisch ontwerp wordt er dieper ingegaan op de manier hoe dit prototype is ingericht en hoe de requirements van de gemeente Wierden in het prototype verwerkt zijn.
Hierna volgt de evaluatie welke bestaat uit een ontwerpevaluatie en een eindevaluatie. In de
ontwerpevaluatie wordt er gekeken of de conclusies (ontwerpprincipes) aansluiten bij het ontwerp van het prototype. Bij de eindevaluatie wordt er gekeken of het ontwerp antwoord geeft op de hoofdvraag van dit onderzoek.
Vervolgens wordt het communicatieplan besproken. Dit plan is bedoeld voor de inrichting van de “echte” omgeving van TOPdesk. Ook zullen in dit plan enkele mogelijkheden genoemd worden om TOPdesk bekend te maken in de organisatie samen met een veranderstrategie.
Als laatste onderdeel van deze scriptie zijn er de bijlagen. In de bijlagen staat extra informatie waar gedurende het lezen van deze scriptie naar wordt verwezen.
INHOUDSOPGAVE
I. VOORWOORD ... 1
II. SAMENVATTING ... 2
III. LEESWIJZER ... 3
IV. TABELLEN EN FIGUREN ... 5
V. BEGRIPPENLIJST ... 6
1 PROBLEEMANALYSE ... 7
1.1 AANLEIDING ... 7
1.2 DOELSTELLING VAN HET ONDERZOEK ... 7
1.3 METHODIEK ... 7
1.4 RESULTATEN ... 8
1.5 ONDERZOEKSVRAGEN ... 9
2 BEHOEFTEN GEMEENTE WIERDEN ... 10
2.1 STAKEHOLDERS ... 10 2.2 BEHOEFTEN STAKEHOLDERS ... 10 2.3 REQUIREMENTS ... 11 3 CONTEXT ... 13 3.1 METHODIEK ... 13 3.2 RESULTATEN ... 13 3.3 CONCLUSIE ... 18 4 LITERATUURONDERZOEK ... 19 4.1 METHODIEK ... 19 4.2 DEELVRAAG 1&2 ... 19
4.3 DEELVRAAG 3:WELKE METHODES ZIJN ER OM DE PROCESSEN IN TE RICHTEN? ... 19
4.4 DEELVRAAG 4:WAT ZIJN DE BENODIGDE PROCESSEN EN HOE WORDEN DEZE INGERICHT? ... 25
4.5 DEELVRAAG 5:WELKE SYSTEMEN ZIJN ER BENODIGD OM DEZE (ONDERSTEUNENDE) PROCESSEN TE IMPLEMENTEREN? ... 29
4.6 ONTWERPPRINCIPES ... 32
5 ONTWERP ... 34
5.1 KOPPELING ONTWERPPRINCIPES AAN REQUIREMENTS ... 34
5.2 FUNCTIONEEL ONTWERP ... 34
5.3 TECHNISCH ONTWERP ... 50
6 COMMUNICATIE & UITROLPLAN ... 67
6.1 VERANDERSTRATEGIE: ... 67
6.2 COMMUNICATIEPLAN ... 68
6.3 UITROLPLAN ... 69
7 ONTWERPEVALUATIE & EINDEVALUATIE ... 70
7.1 ONTWERPEVALUATIE ... 70 7.2 CONCLUSIE ... 71 7.3 EINDEVALUATIE ... 72 7.4 CONCLUSIE ... 75 8 BIBLIOGRAFIE ... 75 9 BIJLAGEN ... 77
9.1 BIJLAGE I:INTERVIEW GEMEENTE WIERDEN ... 77
9.2 BIJLAGE IIKOPPELING ONTWERPPRINCIPES AAN REQUIREMENTS ... 78
9.3 BIJLAGE IIITESTRAPPORT ... 84
IV.
Tabellen en figuren
TABEL 1BUSINESS REQUIREMENTS ... 9
TABEL 2BUSINESS REQUIREMENTS ... 11
TABEL 3USER REQUIREMENTS ... 12
TABEL 4SYSTEM REQUIREMENTS ... 12
TABEL 5MICRO-OMGEVING RANDVOORWAARDEN ... 18
TABEL 6MESO-OMGEVING RANDVOORWAARDEN ... 18
TABEL 7MACRO-OMGEVING RANDVOORWAARDEN ... 18
TABEL 8ZOEKBOOM ... 19
TABEL 9BENODIGDE ITIL PROCESSEN ... 26
TABEL 10INDELING RECHTEN + GROEPEN ... 53
FIGUUR 1MATURITY MODEL, BRON:(VIETNAM,2020) ... 14
FIGUUR 2ISM PROCES MODEL, BRON:(ISM,2005) ... 20
FIGUUR 3ITIL LEVENSCYCLUSFASEN, BRON:(MANN,2011) ... 22
FIGUUR 4MOF PROCESMODEL, BRON:(BERG,2013) ... 23
FIGUUR 5 INCIDENT MANAGEMENT PROCES ... 35
FIGUUR 6PROBLEM MANAGEMENT ... 36
FIGUUR 7CHANGE MANAGEMENT ... 37
FIGUUR 8KNOWLEDGE MANAGEMENT ... 38
FIGUUR 9INLOG PAGINA SELFSERVICEPORTAL ... 39
FIGUUR 10STARTPAGINA SELFSERVICEPORTAL ... 39
FIGUUR 11INCIDENT MELDEN FORMULIER ... 40
FIGUUR 12FORMULIER VERZOEK OM WIJZIGING ... 40
FIGUUR 13OVERZICHT MELDINGENBEHEER ... 41
FIGUUR 14OPENSTAANDE MELDING ... 42
FIGUUR 15AFHANDELING MELDING ... 42
FIGUUR 16HUIDIGE STATUS MELDING ... 42
FIGUUR 17MAJOR INCIDENT ... 43
FIGUUR 18MELDING MET AUTOMATISCHE SUGGESTIES ... 44
FIGUUR 19ITEM IN CMDB ... 45
FIGUUR 20ONDERLINGE RELATIE CONFIGURATIES ... 45
FIGUUR 21ONDERLINGE RELATIES LAPTOP... 45
FIGUUR 22OVERZICHT WIJZIGINGSAANVRAGEN ... 46
FIGUUR 23HUIDIGE STATUS AANVRAAG INZIEN ... 47
FIGUUR 24SSP LEIDINGGEVENDE VOOR AUTORISATIE ... 48
FIGUUR 25AUTORISATIE AANVRAAG GOED OF AFKEUREN ... 48
FIGUUR 26TAKEN OVERZICHT WIJZIGINGSAANVRAAG ... 49
FIGUUR 27HUIDIGE STATUS MELDING ... 49
FIGUUR 28OVERZICHT TAKEN ... 49
FIGUUR 29WIJZIGING GOEDKEUREN ... 49
FIGUUR 30HUIDIGE IT-INFRASTRUCTUUR ... 50
FIGUUR 31TOEKOMSTIGE IT-INFRASTRUCTUUR... 51
FIGUUR 32MODULES TOPDESK ... 52
FIGUUR 33RECHTEN MODULES ... 53
FIGUUR 34SSP INLOGPAGINA ... 54
FIGUUR 35SSP-DESIGNER ... 54
FIGUUR 36DIENSTEN SSP-DESIGNER ... 55
FIGUUR 37FUNCTIONALITEITEN MELDINGEN (EERSTELIJNS) ... 56
FIGUUR 38FUNCTIONALITEITEN MELDINGEN (TWEEDELIJNS) ... 56
FIGUUR 39AFHANDELING MELDINGEN ... 56
FIGUUR 40PRIORITEITENMATRIX MELDINGENBEHEER ... 57
FIGUUR 41SJABLOONSOORT ... 58
FIGUUR 43BEHANDELAAR WIJZIGINGSSJABLOON ... 59
FIGUUR 44ACTIVITEITEN WIJZIGINGSAANVRAAG (ICT) ... 59
FIGUUR 45ACTIVITEIT WIJZIGING ... 60
FIGUUR 46PLANNER WIJZIGINGSAANVRAGEN ... 60
FIGUUR 47FORMULIER WIJZIGINGSAANVRAAG ... 61
FIGUUR 48REGISTRATIE NIEUWE HARDWARE ... 62
FIGUUR 49PLAATSKOPPELING HARDWARE... 62
FIGUUR 50AANMAKEN NIEUWE LICENTIE ... 63
FIGUUR 51OVERZICHT AANTAL GEBRUIKTE LICENTIES ... 63
FIGUUR 52OVERZICHT VEEL GESTELDE VRAGEN ... 64
FIGUUR 53AANMAKEN NIEUW KENNISITEM ... 65
FIGUUR 54LDAP/SAML OVERZICHT TOPDESK ... 65
FIGUUR 55MAILACTIE MAIL NAAR GEBRUIKER ... 66
FIGUUR 56GEBEURTENIS MAIL NAAR GEBRUIKER ... 66
FIGUUR 57OVERZICHT MAIL NAAR GEBRUIKER ... 67
FIGUUR 58WWK-MODEL, BRON:(VAVIA,2018) ... 68
FIGUUR 59UITROLPLANNING ... 69
V.
Begrippenlijst
Begrip Definitie/ verklaring
ASL Application Services Library
BiSL Business Information Services Library
CI’s Configuration item(s)
CMDB Configuration management database
ECAB Emergency Change Advisory Board
FAQ Frequently Asked Questions
ISM Integrated Service Management
ITIL Information Technology Infrastructure Library
MOF Microsoft Operations Framework
N.B. Nota bene
RCA Root cause analysis
SaaS Software as a Service
SSO Single sign-on
1
Probleemanalyse
Dit hoofdstuk beschrijft de aanleiding, probleemstelling (hoofdvraag inclusief deelvragen) en de doelstelling van dit onderzoek (Probleemanalyse, hoofdstuk 1 van het vooronderzoek).
1.1
Aanleiding
De gemeente Wierden is een gemeente die onderdeel uit maakt van de regio Twente. De gemeente Wierden telt ongeveer 200 werknemers die werkzaam zijn binnen de verschillende afdelingen. Het aantal aanwezige werknemers verschilt per dag omdat niet iedereen fulltime werkt en er dus op sommige dagen ook parttimers aanwezig zijn. De ICT-afdeling van de gemeente Wierden telt 6 werknemers namelijk: • 1 afdelingshoofd, • 2 (senior)netwerkbeheerders, • 1 programmeur, • 1 i-adviseur, • 1 strateeg.
Al de medewerkers van de gemeente Wierden zijn van de ICT-afdeling afhankelijk als het gaat om ICT gerelateerde incidenten/problemen. De huidige situatie is zo dat wanneer er zich op enig moment een incident voordoet hier ad hoc op wordt gereageerd. Er is voor de afhandeling nog geen structuur (vaste manier van werken) of richtlijnen. Er zijn geen processen aanwezig die beschrijven hoe bepaalde incidenten opgelost dienen te worden, en wie wat doet. Er worden geen incidenten bijgehouden of gerapporteerd etc. Om deze reden wil de gemeente Wierden dat:
1. Dit deel van hun ICT-dienstverlening beter wordt ingericht met behulp van nieuwe processen, 2. Er een nieuw supportsysteem voor het registreren en bijhouden van meldingen komt.
Het uitgangspunt van dit afstudeerproject is dat er een advies komt met een (deels)werkend prototype, inclusief de hierbij behorende (ondersteunende) processen.
1.2
Doelstelling van het onderzoek
Omdat de gemeente Wierden heeft besloten om meer structuur aan te willen brengen in de ICT-dienstverlening, dient er een nieuw supportsysteem te komen met de hierbij behorende
(ondersteunende) processen. Het is de bedoeling dat dit nieuwe systeem zo gebruikersvriendelijk mogelijk wordt ingericht, zodat medewerkers van de gemeente hier gemakkelijk mee kunnen werken. Om dit te kunnen realiseren dient er onderzoek gedaan te worden naar de huidige situatie, de problemen en wat de eisen en wensen zijn ten behoeve van de toekomstige situatie. Hierbij dient er ook een overzicht van alle kosten te komen, zoals de aanschaf van software en eventuele licenties etc.. Zo zal er gekeken worden naar wat de meest efficiënte manier is voor het inrichten van de (ondersteunende) processen, wie is waar verantwoordelijk voor, etc. Ook zal er onderzocht worden welke methode het meest geschikt is voor de gemeente Wierden. Aan de hand daarvan zal er een supportsysteem gekozen worden en zal van de toekomstige situatie een prototype gerealiseerd worden.
1.3
Methodiek
Methodieken die gebruikt zijn voor het verzamelen van data, zijn gedaan middels het gebruik van perspectieven en interviewmethodes. De data die benodigd is voor dit onderzoek kan verkregen worden middels gesprekken met de betrokken personen binnen de gemeente Wierden. Verder benodigde data voor het toekomstige supportsysteem kan verkregen worden van de leverancier van het supportsysteem. Tevens zal er gebruik worden gemaakt van observatieonderzoek.
Onder “interviewmethodes” worden in dit project de volgende methodes bedoeld: • Vragenlijst o Face2face o Schriftelijk • Gesprek o Persoonlijk gesprek o Groepsgesprek
Met observatieonderzoek wordt bedoeld het observeren van de problemen die gesignaleerd worden. Dus het ad hoc reageren, het binnenkomen lopen van medewerkers bij de ICT-afdeling etc. en hoe vaak dit per dag gebeurt.
1.4
Resultaten
In dit hoofdstuk worden de resultaten van de probleemanalyse beschreven.
Binnen dit project zijn er een aantal stakeholders die een groot belang hebben bij dit project. De initiële stakeholders zijn hieronder beschreven met hun eigen perspectieven en belangen voor dit project. In de behoefteanalyse (Hfst. 2) zal er een definitieve selectie gemaakt worden, welke stakeholders betrokken zijn bij dit project.
Initiële stakeholders
• ICT-afdeling Gemeente Wierden, de ICT-afdeling van de gemeente Wierden wil graag onderzocht hebben hoe op een verantwoorde manier een geheel nieuw supportsysteem kan worden opgezet dat voldoet aan de door hun gestelde eisen.
• De applicatiebeheerders, de applicatiebeheerders van de gemeente Wierden lossen een groot aantal problemen op en hebben het contact met de leveranciers van een aantal
softwarepakketten.
• De medewerkers van de gemeente Wierden, de medewerkers van de gemeente Wierden moeten zonder problemen en gemakkelijk met het toekomstige supportsysteem kunnen werken.
• Management gemeente Wierden, hier kan er gedacht worden aan leidinggevende, portefeuillehouder college, IT-strateeg etc. Het management wil bijvoorbeeld rapportages krijgen met hierin vermeld alle incidenten en hoe vaak deze zich voor doen.
• Externen met problemen.
o Inwoners van Wierden (deze zijn indirect betrokken met dit project).
o Externen, zoals bedrijven of andere gemeentes, die een probleem hebben met de systemen van Wierden.
• De afstudeerder, met de kennis opgedaan in de afgelopen vier jaar bij de studie HBO-ICT aan het Saxion zal de afstudeerder een advies uit brengen aan de gemeente Wierden om tot een succesvol afstudeerproject te komen.
1.4.1
Perspectieven
• Literatuur
o Aan de hand van literatuur kan er informatie worden verzameld en inspiratie worden opgedaan over de verschillende supportsystemen. De keuze voor het definitieve supportsysteem zal in dit onderzoek als advies worden meegegeven en worden onderbouwd in hoofdstuk 4.5.4. De perspectieven (triangulatie) die in deze analyse gebruikt zijn, zijn:
• Perspectief van de ICT-afdeling
• Perspectief van de applicatie beheerders • Perspectief van het management
• Perspectief van de gebruikers
1.4.2
Literatuuronderzoek
Bij het uitvoeren van de probleemanalyse is er een klein literatuuronderzoek gedaan, wat tijdens het beantwoorden van de deelvragen gebruikt kan worden. Dit korte literatuuronderzoek is te vinden in het vooronderzoek, hoofdstuk 1.5.2. Een uitgebreidere uitleg over dit onderzoek is te vinden in het
Literatuuronderzoek (Hfst. 5).
1.4.3
Interview
Naar aanleiding van het eerste gesprek met John Sijbesma (Strategisch Adviseur IT en
Informatiebeveiliging), Bart ter Linde (netwerkbeheerder) en Laurentz Freriksen (netwerkbeheerder) van de gemeente Wierden zijn er een aantal resultaten naar voren gekomen die helpen om een goed
beeld te krijgen van de huidige problemen. Dit interview is te vinden in de bijlages, als bijlage I. Hieronder is een opsomming gemaakt van de problemen.
• Er gebeuren (te)veel dingen ad hoc.
• Er wordt niets gerapporteerd hoe incidenten opgelost zijn.
• Het is te druk waardoor andere werkzaamheden blijven liggen bij de ICT-afdeling. • Er is geen structuur in de manier van werken.
• Er zijn geen processen die beschrijven wie waar verantwoordelijk voor is. Een voorbeeld hiervan is dat applicatiebeheerders niet meer weten of ze verantwoordelijk zijn voor vragen van hun pakketten. Het kan namelijk zijn dat sommige mensen deze werkzaamheden erbij doen zonder dat dit mogelijk in hun contract/functie beschreven staat.
• Geen knowledge base aanwezig voor FAQ.
Aan de hand van de opsommingen hierboven blijkt dat het probleem vooral ligt bij het niet bij houden van incidenten en het ontbreken van een duidelijke structuur met de hierbij horende (ondersteunende) processen. Hierdoor mist een stuk inzicht over de problemen, welke problemen spelen er veel of komen vaker voor in de organisatie, en is de gemeente Wierden minder proactief ingesteld.Deze opsomming dient dan ook de hoofdvraag te brengen die met bovenstaande problemen
overeenkomen.
De hoofdvraag die bij dit onderzoek gesteld wordt moet in elk geval de volgende onderdelen bevatten: • Methodes om processen in te richten zodat beschreven wordt wie waar verantwoordelijk voor
is, om zo meer structuur aan te brengen.
• Een supportsysteem waar incidenten in geregistreerd en bijgehouden kunnen worden.
1.5
Onderzoeksvragen
De conclusie die getrokken kan worden, uit de aanleiding, de gesprekken en de doelstelling van het probleem is dat de gemeente Wierden te weinig structuur heeft door het ontbreken van
(ondersteunende) processen met incidenten en het bijhouden hiervan. Ook gebeuren er (te)veel dingen ad hoc waardoor andere werkzaamheden blijven liggen. De gemeente Wierden wenst dat er een nieuw supportsysteem komt waarin incidenten kunnen worden geregistreerd en bijgehouden met de hierbij horende (ondersteunende) processen. Uit deze conclusie is een hoofdvraag gekomen met deelvragen die helpen antwoord te geven op deze hoofdvraag.
• “Hoe kan de gemeente Wierden een geheel nieuw supportsysteem, met de bijbehorende ondersteunende processen, implementeren en inrichten?”
Bovenstaande hoofdvraag is uitgewerkt in een aantal deelvragen, deze zijn hieronder te lezen:
1. Wat is de huidige situatie?
2. Welke requirements zijn er voor de toekomstige situatie? 3. Welke methodes zijn er om de processen in te richten?
4. Wat zijn de benodigde processen en hoe worden deze ingericht?
5. Welke systemen zijn er benodigd om deze (ondersteunende) processen te implementeren?
Deze vragen kunnen worden vertaald naar business requirements die, samen met de user en system requirements, helpen bij het behalen van de eisen en wensen van dit afstudeerproject.
Business requirements ID Requirement:
BR01 De gemeente Wierden wil met de nieuwe processen meer structuur aanbrengen binnen de
ICT-afdeling.
BR02 Medewerkers moeten weten voor welke taken hij/zij verantwoordelijk zijn.
BR03 De gemeente Wierden wil met behulp van het supportsysteem een vaste manier van
melden creëren.
BR04 Er moet meer tijd vrij komen voor de “echte” werkzaamheden die horen bij elke functie. BR05 De gemeente Wierden wil inzicht hebben in het aantal meldingen per x aantal
weken/maanden.
BR06 Met het supportsysteem moet de AVG gewaarborgd kunnen worden. Tabel 1 Business requirements
2
Behoeften gemeente Wierden
Dit hoofdstuk beschrijft de behoeften van de gemeente Wierden samen met de betrokken stakeholders (Behoefteanalyse, hoofdstuk 2 van het vooronderzoek).
2.1
Stakeholders
Om de behoeften van de gemeente Wierden en de betrokken stakeholders vast te stellen is er een stakeholder analyse uitgevoerd. Uit deze analyse zijn de volgende stakeholders voort gekomen:
• ICT-afdeling gemeente Wierden
o De ICT-afdeling vraagt advies over het verantwoord opzetten van een supportdesk met de bijbehorende processen en de daarbij horende requirements.
• De applicatiebeheerders
o De applicatiebeheerders van de gemeente Wierden lossen een groot aantal problemen van de medewerkers op en onderhouden ook het contact met de leveranciers van de softwarepakketten.
• Management gemeente Wierden
o Hier kan er gedacht worden aan leidinggevenden, portefeuillehouders, college, IT-strateeg etc. Deze willen graag inzicht in tijdsbesteding, rapportages en andere stuurinformatie.
• Medewerkers van de gemeente Wierden
o De ± 200 medewerkers van de gemeente Wierden die gemakkelijk moeten kunnen werken met het nieuwe supportsysteem.
• Leveranciers van diensten en/of services aan de gemeente Wierden
o Hiermee wordt vooral gedoeld op de leverancier van het supportsysteem. • Externen met problemen
o Inwoners van Wierden (deze zijn indirect betrokken bij dit project).
o Externen, zoals bedrijven of andere gemeentes, die een probleem hebben met de systemen van de gemeente Wierden
Voor een uitwerking van de stakeholder analyse verwijs ik u door naar de behoefteanalyse, hoofdstuk 2 van het vooronderzoek.
2.2
Behoeften stakeholders
Vanuit het eerste interview (Bijlage I) kunnen enkele behoeften vastgesteld worden welke uitgebreid worden beschreven in hoofdstuk 2.3.2 van het vooronderzoek. Daarnaast zijn deze behoeften
gecategoriseerd volgens de MoSCoW-methode en een Functionele of Niet-functionele aard. Dit is een manier om de urgentie te kunnen bepalen. Elk van deze behoeften heeft daarnaast (meestal) een koppeling met een User-en een System-requirement.
De MoSCoW methode staat voor: • Must haves
Minimale eisen waar het systeem aan moet voldoen. • Should haves
Eisen waaraan het informatiesysteem aan moet voldoen, maar het ook kan functioneren zonder deze eis en evt. later worden toegevoegd.
• Could haves
Hiermee wordt bedoeld dat er bepaalde onderdelen kunnen worden gerealiseerd mits hier tijd voor is. Deze onderdelen zijn vaak niet noodzakelijk om te realiseren.
• Won’t haves
Ideeën van de groep of opdrachtgever die bij voorbaat al niet in het systeem zullen komen. Het is in de toekomst wel mogelijk om deze uit te voeren, alleen niet voor dit project.
Functioneel en niet functionele requirements
Volgens (Swart, 2011) geeft een functionele requirement het gewenste gedrag van het systeem weer, terwijl niet-functionele requirements een kwaliteitseis is waaraan het systeem moet voldoen.
2.3
Requirements
Uit de resultaten van de behoefteanalyse (hoofdstuk 2 van het vooronderzoek) is er een beter beeld ontstaan waaraan de toekomstige situatie zou moeten voldoen. Daarnaast kan men aan de hand van de opgestelde requirements in deze en voorgaande hoofdstukken van het vooronderzoek, bepalen in welke mate het eindproduct aan de eisen en wensen zal voldoen.
De deelvragen uit de probleemanalyse kunnen worden vertaald naar business requirements, welke samen met de user en de system requirements helpen bij het beoordelen van het prototype van dit project. Hieronder staat een overzicht van alle requirements.
Business requirements
BR-ID: SR-ID: Requirement: (Niet)
Functioneel:
Prioriteit (MoSCoW):
BR01 SR07 De gemeente Wierden wil met de nieuwe processen meer structuur aanbrengen binnen de ICT-afdeling.
NF M
BR02 N.V.T. Medewerkers moeten weten voor welke taken hij/zij verantwoordelijk zijn.
NF M
BR03 N.V.T. De gemeente Wierden wil met behulp van het supportsysteem een vaste manier van melden creëren.
F M
BR04 N.V.T. Er moet meer tijd vrij komen voor de “echte” werkzaamheden die horen bij elke functie.
NF M
BR05 SR01 De gemeente Wierden wil inzicht hebben in het aantal meldingen per x aantal weken/maanden.
F M
BR06 N.V.T. Met het supportsysteem moet de AVG gewaarborgd kunnen worden.
NF M
BR07 N.V.T. De gemeente Wierden wil in de toekomst kunnen uitbreiden met meer processen en deze kunnen inrichten en implementeren met behulp van de nog te kiezen methode.
NF M
Tabel 2 Business requirements
User requirements
US-ID: SR-ID: Requirement: (Niet)
Functioneel: Prioriteit (MoSCoW): US01 SR06 & SR10 & SR11
De helpdesk dient simpel in gebruik te zijn voor de gebruikers.
F M
US02 SR02 Gebruikers moeten weten wat ze moeten doen bij het willen melden van incidenten (welke volgorde).
NF M
US03 SR01 & SR02 & SR05 & SR12
Gebruikers dienen zelf een melding te kunnen aanmaken in de helpdesk middels een webpage.
F M
US04 SR02 Het moet voor de gebruiker duidelijk zijn op welke verschillende manieren en in welke volgorde, meldingen gedaan kunnen worden.
NF M
US05 SR03 De gebruiker moet de door hem/haar ingediende melding terug kunnen vinden.
US06 SR03 Het moet mogelijk zijn om een
overzicht te krijgen van alle incidenten en onder welke categorieën deze vallen.
F M
US07 N.V.T. De werkzaamheden van de
supportmedewerker dienen duidelijk beschreven te zijn
NF M
US08 N.V.T. Het bestaan van de helpdesk dient bekend te worden binnen de organisatie.
NF M
Tabel 3 User requirements
System requirements:
BR/US-ID:
SR-ID: Requirement: (Niet)
Functioneel:
Prioriteit (MoSCoW):
BR05 & US03
SR01 Er dienen incidenten te kunnen worden geregistreerd en bijgehouden.
F M
US03 & US04
SR02 De helpdesk moet voor elke
medewerker beschikbaar zijn, op elk moment van de dag.
NF M
US05 & US06
SR03 Er moet een mogelijkheid zijn om eerder gebeurde incidenten terug te kunnen vinden.
F M
N.V.T. SR04 Het moet mogelijk zijn om meldingen die geregistreerd zijn binnen de helpdesk te koppelen aan personen.
F M
US03 SR05 Gebruikers die een melding hebben aangemaakt moeten een notificatie krijgen wanneer er een update is over hun melding.
F S
US01 SR06 De helpdesk dient zo ingericht te zijn dat elke medewerker (met en zonder enige IT-kennis) hier mee kan werken.
F M
BR01 SR07 De helpdesk dient de nieuwe processen te ondersteunen.
F M
N.V.T. SR08 Het dient mogelijk te zijn om de helpdesk te koppelen aan de huidige IT-infrastructuur middels een LDAP-verbinding.
F M
N.V.T. SR09 Er dient een Knowledge base aanwezig te zijn.
F M
US01 SR10 Persoonsgegevens worden automatisch ingevuld door de helpdesk.
F S
US01 SR11 De webpage waar een melding gedaan wordt, moet met 1 klik bereikbaar zijn.
F M
N.V.T. SR12 Het moet mogelijk zijn een CMDB op te zetten.
F M
3
Context
Dit hoofdstuk beschrijft de context analyse voor het afstudeerproject voor de gemeente Wierden. Hierin wordt de omgeving van het afstudeerproject toegelicht. Verder zullen hier de projectgrenzen en de randvoorwaarden worden onderzocht en toegelicht.
3.1
Methodiek
In de context analyse zijn de volgende methodieken gebruikt:
• Groepsgesprek, er zijn diverse gesprekken geweest met de betrokken personen van de
gemeente Wierden. Omdat er bij deze gesprekken altijd meerdere mensen aanwezig zijn geweest praten we hier over de methode “groepsgesprekken”.
• Deskresearch, bij de onderzoeksmethode deskresearch wordt er zowel literatuur als
bestaande gegevens/informatie gebruikt. De bestaande gegevens/informatie zijn voortgekomen uit de groepsgesprekken die eerder hebben plaatsgevonden. In deze analyse is er vooral gebruik gemaakt van de uitkomsten van de eerder gevoerde gesprekken om zo de context van meerdere perspectieven duidelijk te krijgen.
• Mirco-Meso-Macro, bij deze methode wordt er op drie verschillende aggregatieniveaus
gekeken naar de invloeden van verschillende factoren. Hier worden (toekomstige) mogelijkheden genoemd die van buitenaf afkomstig zijn en die van invloed zouden kunnen zijn op de uitkomst van dit afstudeerproject. Voor het Micro niveau wordt het 7S model gebruikt, voor het Meso niveau zal de krachtenveld analyse gebruikt worden en voor het Macro niveau zal er gebruik worden gemaakt van de DESTEP methode
o 7S model (Het Micro niveau): In 1981 maakt (McKinsey, 1981) het 7S model. Dit
model bestaat uit 7 factoren, elke van deze factoren wordt beïnvloed door de andere 6 en moet deze daarom ook ondersteunen. Op deze manier worden alle factoren, en daarmee de gehele organisatie, versterkt. Belangrijk is dus dat er samenhang is tussen alle factoren.
o Krachtenveld analyse (het Meso niveau): Volgens (CROW, 2008) geeft een
krachtenveldanalyse inzicht in de positie van partijen en hun belang bij bepaalde uitkomsten. Een krachtenveldanalyse begint bij het inventariseren van de relevante spelers. Vervolgens vindt een positiebepaling plaats op basis van de invloed die bepaalde spelers hebben en wat hun belangen zijn.
o DESTEP methode (het Macro niveau): (Marketingscriptie, sd) beschrijft de DESTEP
als afkorting van zes factoren. (Demografische factoren, Economische factoren, Sociale-culturele factoren, Technologische factoren, Ecologische factoren en Politiek-juridische factoren) Deze factoren bieden een kans om de omgeving te bekijken uit diverse invalshoeken op macroniveau.
3.2
Resultaten
Hieronder wordt de huidige en de gewenste situatie beschreven met daarbij de randvoorwaarden die hierbij horen.
3.2.1
Micro niveau
Tijdens dit afstudeerproject wordt er op Micro niveau gekeken naar de gemeente Wierden. Hierbij wordt er gebruik gemaakt van het 7S-model. Dit model is ontworpen om aan de hand van zeven vaste factoren de prestaties van een onderneming te kunnen analyseren. Deze factoren zijn:
• Strategy: Onder strategy wordt geanalyseerd welke doelen het bedrijf heeft gesteld en hoe deze bereikt moeten worden.
• Systems: Bij systems worden alle denkbare systemen omschreven.
• Structure: Bij structure wordt gekeken naar de wijze waarop het bedrijf ingericht is. • Shared Values: Het gaat hier over een (al dan niet) gezamenlijke bedrijfsopvatting. • Style: Onder style wordt geanalyseerd in welk vorm het management omgaat met de
medewerkers.
• Staff: Bij staff wordt er gekeken naar het personeel en het management.
3.2.1.1
Structuur gemeente Wierden (Strategy, Structure, Shared
Values, Staff, Skills)
De gemeente Wierden is een gemeente die onderdeel uit maakt van de regio Twente en ongeveer 24.000 inwoners telt. De gemeente is verantwoordelijk voor verschillende burgerzaken waarbij kan worden gedacht aan zaken als:
• Economische zaken; denk hierbij aan de bereikbaarheid van bedrijventerreinen of een mooi uitziende winkelstraat.
• Sociale zaken en werkgelegenheid; een gemeente zal proberen om zoveel mogelijk mensen aan het werk te krijgen. Voor de mensen die niet kunnen werken zal er een uitkering van de gemeente beschikbaar zijn.
• Verkeer en vervoer; hierbij kan er gedacht worden aan de straten, wegen, voetpaden en parkeerterreinen. De gemeente is verantwoordelijk voor de aanleg en het onderhoud hiervan. • Milieubeheer; het gescheiden inzamelen van huisvuil maar ook het uitgeven van
milieuvergunningen aan bedrijven.
De gemeente Wierden telt ongeveer 200 werknemers die werkzaam zijn binnen de verschillende afdelingen welke allen eigen werkzaamheden hebben. Het aantal aanwezige werknemers verschilt per dag omdat niet iedereen fulltime werkt en er dus op sommige dagen ook parttimers aanwezig zijn.
Zoals eerder verteld, heeft elke afdeling zijn eigen werkzaamheden of diensten die ze aanbieden aan de inwoners van Wierden. Dit project zal uitsluitend bestemd zijn voor de ± 200 medewerkers van de gemeente Wierden en dus niet voor de bewoners.
3.2.1.2
Huidige situatie (Systems, Style)
Zoals hierboven al is vermeld werken er bij de gemeente Wierden ongeveer 200 medewerkers verspreid over verschillende afdelingen. Al deze medewerkers zijn van de ICT-afdeling afhankelijk als het gaat om ICT gerelateerde incidenten/problemen. Wanneer er zich op dit moment een incident of probleem voordoet wordt hier ad hoc en zonder enige structuur (vaste manier van werken) of richtlijnen op gereageerd. Er zijn geen processen aanwezig die beschrijven hoe bepaalde incidenten of problemen opgelost dienen te worden of wie wat doet. Er worden geen incidenten bijgehouden of gerapporteerd etc. Hierdoor wordt het ook moeilijk eerder voorgekomen incidenten terug te vinden, en om deze incidenten of problemen sneller op te kunnen lossen.
Maturity model
Figuur 1 Maturity model, bron: (Vietnam, 2020)
Het Capability Maturity Model (figuur 1) is een model dat aangeeft op welk niveau de ontwikkeling van een organisatie zit.
Het model onderscheidt vijf levels (niveaus):
• Initial: initial is het eerste level van het model. Elk bedrijf/ organisatie of individu kan dit niveau bereiken. Op dit niveau zijn geen processen aanwezig of worden ze te snel en onvoldoende uitgewerkt. Hierdoor kunnen werkzaamheden chaotisch en ad hoc zijn.
Problemen worden pas opgelost als ze zich voordoen. Dit is het niveau waar de gemeente Wierden zich op dit moment bevindt.
• Managed: managed is het 2e level van het model. In dit level zijn processen beschreven,
worden projecten ingepland en gecontroleerd. In dit level is een stuk projectmanagement ontwikkeld door de organisatie. Om level 2 te behalen moeten alle eisen die gesteld worden aan projecten worden behaald. De projecten moeten worden gepland, geïmplementeerd en gecontroleerd. Met deze uitvoeringsmethode zullen projecten altijd worden uitgevoerd volgens vooraf gedocumenteerde stappen.
• Defined: defined is het 3e level van het model. In dit niveau zijn processen duidelijk
beschreven en zijn de belangrijkste processen gestandaardiseerd. In dit level wordt er meer proactief gewerkt dan reactief. Om dit level te behalen moeten processen tot in detail worden beschreven, de processen moeten makkelijk te begrijpen zijn en het moet duidelijk zijn welke tools er gebruikt gaan worden om dit te kunnen realiseren.
• Quantitatively managed: Quantitatively managed is het 4e level van het model. In dit level
zijn de processen geïmplementeerd en worden deze aan de hand van data zoals rapporten gecontroleerd en indien nodig verbeterd. Om dit level te behalen moeten de processen worden gecontroleerd aan de hand van statische of kwantitatieve tools zoals bijvoorbeeld een rapport. Hierbij moeten alle mensen die betrokken zijn bij de processen, worden
meegenomen. Dus de eindgebruikers en het personeel welke het proces uitvoeren. • Optimizing: optimizing is het 5e en hoogste level van het model. In dit level zijn alle
processen en de benodigde tools geïmplementeerd en gebruikt. Op dit level zijn er geen grote problemen met de processen. Mensen begrijpen het en gebruiken het. Om dit level te behalen moeten alle doelen in de voorgaande levels behaald zijn en is er alleen nog sprake van verfijning van de processen en tools (de puntjes op de i zetten).
3.2.2
Meso niveau
Tijdens dit afstudeerproject wordt er op Meso niveau gekeken naar de ICT-afdeling van de gemeente Wierden. Hierbij wordt er gebruik gemaakt van de krachtenveldanalyse. Een krachtenveldanalyse geeft inzicht in de positie van partijen en hun belang bij bepaalde uitkomsten. Een
krachtenveldanalyse begint bij het inventariseren van de relevante spelers. Vervolgens vindt een positiebepaling plaats met de belangen van de betrokken partijen. Ten slotte wordt een
benaderingsstrategie geformuleerd hoe de betrokken partijen worden meegenomen in dit project.
3.2.2.1
De betrokken partijen
Bij dit project zijn een aantal verschillende partijen betrokken Deze betrokken partijen zijn: • De ICT-afdeling van de gemeente Wierden.
• De medewerkers van de verschillende afdelingen van de gemeente Wierden. • Het management van de gemeente Wierden.
• De (nog onbekende) leverancier van het supportsysteem.
3.2.2.2
IT-infrastructuur
Voor een overzicht van de huidige IT-infrastructuur verwijs ik u door naar hoofdstuk 5.3.1.
In deze afbeelding is de huidige IT-infrastructuur van de gemeente Wierden te zien. De gemeente Wierden heeft de meeste servers on-premises staan en heeft deze zelf in beheer. Een aantal applicaties wordt gehost door de leverancier. Het nieuwe supportsysteem dient een koppeling te maken met deze infrastructuur en dan met name een koppeling met de directory server. Dit komt omdat in deze directory server alle gegevens staan die TOPdesk nodig heeft. Omdat het
supportsysteem voor elke medewerker op elk moment van de dag beschikbaar moet zijn, zal dit naar alle waarschijnlijkheid een webbased/Cloud oplossing worden. Een randvoorwaarde die de gemeente Wierden hier stelt is dat het systeem te koppelen moet zijn met de huidige IT-infrastructuur (directory server). Hiermee kunnen alle aanwezige IT-componenten worden gekoppeld aan het supportsysteem om zo een CMDB te creëren waardoor niet alles handmatig moet worden toegevoegd. Op deze manier is het niet nodig om alle IT gerelateerde hardware handmatig toe te voegen.
3.2.2.3
Gewenste situatie
Zoals eerder vermeld staat wil de gemeente Wierden een gedeelte van de ICT-dienstverlening
verbeteren met behulp van nieuwe processen en een supportsysteem (helpdesk). Wanneer dit op een correcte manier wordt ingericht met de juiste methode en bijbehorende (ondersteunende) processen, zal dit veel meer structuur en orde geven aan de ICT-afdeling en de manier van werken, zoals wie waar verantwoordelijk voor is. Een betere structuur zorgt er voor de medewerkers van de gemeente Wierden ook voor dat zij bijvoorbeeld sneller en gerichter geholpen worden met hun
incidenten/problemen, wat weer kan resulteren in een hogere tevredenheid. Echter moet hier wel een kanttekening gemaakt worden. Sommige medewerkers zijn op dit moment gewend dat zij gelijk geholpen worden. Dit zal in de toekomstige situatie niet altijd meer het geval zijn. Voor deze mensen kan het daardoor omslachtiger, logger en bureaucratischer aanvoelen. Deze nieuwe processen vergen dan ook de tijd en de nodige aanpassingen zodat de gebruikers binnen de gemeente Wierden hier mee om kunnen gaan en er ook de voordelen van gaan inzien. In de toekomstige situatie met processen hoeft er mogelijk ook niet meer ad hoc gereageerd te worden. Met behulp van een supportsysteem wordt het mogelijk om incidenten bij te houden en hier later rapportages van te maken. De wens van de gemeente Wierden hierbij is om een volledig nieuw supportsysteem
(helpdesk) in te richten en te implementeren met de bijbehorende (ondersteunende) processen. Voor deze processen is de wens om hiervoor een methode als bijvoorbeeld ITIL (Information Technology Infrastructure Library) of MOF (Microsoft Operations Framework) te gebruiken. Voor het
supportsysteem is de wens dat er een prototype komt die aansluit bij de requirements.
3.2.2.4
Het supportsysteem
Het supportsysteem, ook wel helpdesk genoemd, moet natuurlijk voldoen aan een aantal eisen van de gemeente Wierden. Zo moet de helpdesk verschillende mogelijkheden/functionaliteiten bieden, zoals:
• Het registreren en bijhouden van incidenten. • Het maken van rapportages over de incidenten.
• Incidenten koppelen aan medewerkers en eventuele leveranciers. • Afgeronde incidenten terug kunnen vinden.
• Het categoriseren van veel voorkomende incidenten (rapportages). • Een knowledge base voor een pagina met een FAQ en actuele storingen.
• Het moet mogelijk zijn om de helpdesk te koppelen aan de bestaande IT-infrastructuur. De punten hierboven zijn enkele mogelijkheden/ functionaliteiten van een helpdesk. De echte mogelijkheden/ functionaliteiten zullen tijdens het literatuuronderzoek besproken worden.
3.2.2.5
Betrokken partijen
Zoals in de voorgaande hoofdstukken al is benoemd zijn er verschillende partijen betrokken bij dit project. Het is dan ook belangrijk om al deze partijen te betrekken bij dit project.
• ICT-afdeling gemeente Wierden: De ICT-afdeling is voornamelijk bij dit project betrokken voor het maken van beslissingen, het informeren over de voortgang van de werkzaamheden en het vragen om input/advies.
• De medewerkers/ verschillende afdelingen van de gemeente Wierden: De medewerkers van de gemeente Wierden zullen alleen betrokken worden bij de inrichting van het
supportsysteem. De reden waarom ze hierbij betrokken worden is omdat zij de groep medewerkers zijn die met het supportsysteem moeten gaan werken. Door deze groep mensen te betrekken bij de inrichting kunnen zij zelf aangeven of iets wel of juist niet goed werkt voor hen.
• Het management van de gemeente Wierden: Het management is in mindere mate betrokken bij de uitvoering van dit project maar is wel betrokken bij de uitkomst hiervan. Het management heeft namelijk belang bij de uitkomst. Het belang van het management is dat zij inzicht kunnen krijgen in de lopende ICT incidenten/problemen van de gemeente Wierden aan de hand van bijvoorbeeld rapportages per aantal weken.
• De (nog onbekende) leverancier van het supportsysteem: De leverancier van het supportsysteem is verantwoordelijk voor de levering en het onderhouden ervan. Deze partij geeft geen groot belang bij dit onderzoek maar heeft wel een groot belang bij de uitkomst. Zo weet de leverancier namelijk wat deze moet leveren en tegen welke prijs.
3.2.3
Macro niveau
Tijdens dit afstudeerproject wordt er op Macro niveau gekeken naar de externe factoren van buitenaf die van invloed kunnen zijn op dit project middels de DESTEP methode. Deze methode biedt een aantal factoren, echter zullen niet al deze factoren van toepassing zijn op dit project. De factoren die wel van toepassing zijn op dit project zijn:
• Economische factoren
• Sociaal-maatschappelijke factoren • Technologische factoren
• Politiek-juridische factoren
3.2.3.1
De AVG-wetgeving (politiek-juridisch)
Vanaf 25 mei 2018 is de GDPR (General Data Protection Regulation) vervangen door de AVG (Algemene verordening gegevensbescherming). Bij deze nieuwe wet gelden weer andere regels en eisen aan (persoon)gegevens. Enkele voorbeelden hiervan zijn:
• Werkgevers mogen niet meer gegevens in het personeelsdossier vastleggen dan nodig is, en de gegevens moeten ter zake doen.
• Werkgevers moeten de persoonsgegevens passend beveiligen, zodat ze niet verloren raken of in verkeerde handen terechtkomen.
• Werkgevers mogen de persoonsgegevens niet langer bewaren dan noodzakelijk is.
Aangezien in het supportsysteem ook (persoon)gegevens dienen te worden vastgelegd zoals wie de melder is, het telefoonnummer etc. moet hier in een bepaalde mate ook voldaan worden aan de AVG-wetgeving. De onderdelen waarmee rekening gehouden dient te worden zijn:
• Het vastleggen van gegevens. De AVG verplicht bedrijven/organisaties om zorgvuldig om te gaan met persoonsinformatie. Daarom is het van belang alleen gegevens te registreren die echt van belang zijn voor de dienstverlening.
• Het opruimen van oude gegevens. De AVG geeft geen concrete bewaartermijn voor persoonsgegevens. De regels voor de bewaartermijn vallen onder de Wet bescherming persoonsgegevens (Wbp). Zo staat hierin dat gegevens van personeel niet langer dan 2 jaar bewaard mag blijven. De AVG noemt wel een opslagbeperking voor persoonsgegevens. Dit houdt in dat persoonsgegevens bewaard mogen worden als dit nodig is voor een doel waarvoor de gegevens zijn vastgelegd. Echter dienen deze gegevens dan wel
geanonimiseerd te zijn.
3.2.3.2
COVID-19 (sociaal-maatschappelijk)
Sinds begin van het jaar 2020 is het COVID-19 virus oftewel Corona virus wereldwijd bekend geworden en heeft ook bijna elk land ter wereld hier last van (gehad). Ook heeft dit virus zijn impact gehad op dit afstudeerproject en kan het nog steeds een impact hebben op de uitkomst hiervan. De impact die het op het moment van schrijven heeft gehad zijn onder andere:
• Het niet tijdig kunnen starten met dit afstudeerproject.
• Dat het niet mogelijk is om (deels) te werken in het gemeentehuis zelf, maar grotendeels vanuit huis.
Enkele risico’s die COVID-19 nog met zich mee kan brengen zijn:
• Het wegens ziekte het niet (op tijd) kunnen afronden van het project.
• Medewerkers van de gemeente Wierden worden ziek en zijn niet bereikbaar. • Betrokken partijen zijn niet bereikbaar vanwege een (gedeeltelijke) lock down.
3.2.3.3
Cloud (technologisch)
Op dit moment werkt de gemeente Wierden nog niet (geheel) in de Cloud. De kans bestaat dat dit in het komende paar jaar gaat veranderen aangezien steeds meer bedrijven/organisaties hun IT-infrastructuur verplaatsen naar de Cloud. Mocht dit in de nabije toekomst gebeuren dan kan dat van invloed zijn op de uitkomst van dit project. Het supportsysteem dient namelijk gekoppeld te worden met de infrastructuur. Deze koppeling moet nog steeds mogelijk zijn ook al bevindt de IT-infrastructuur van de gemeente Wierden zich in de Cloud.
3.2.3.4
Groeien of krimpen gemeente Wierden (economisch)
Een andere externe factor die in de toekomst van invloed kan zijn op dit project is het groeien of krimpen van de gemeente Wierden. Zo is het bijvoorbeeld mogelijk dat de gemeente Wierden als gevolg van de oplopende zorgkosten m.b.t. het COVID-19 virus, genoodzaakt is te bezuinigen of te krimpen. Hierdoor kan het gevolg ontstaan dat er minder medewerkers benodigd zijn of dat het budget van de ICT-afdeling omlaag moet en er keuzes moeten worden gemaakt in het wel of niet behouden van bepaalde software pakketten.
3.3
Conclusie
Omdat de medewerkers van de gemeente Wierden afhankelijk zijn van de ICT-afdeling voor een goede dienstverlening naar de inwoners toe, is het van belang dat ICT-gerelateerde incidenten goed worden opgepakt en opgelost. Tijdens de eerder gevoerde gesprekken zijn al requirements voor dit project naar voren gekomen. Deze gesprekken zijn ook van toegevoegde waarde geweest op de contextanalyse. In de tabellen hieronder (tabellen 5, 6 en 7) zijn de randvoorwaarden op 3
verschillende niveaus ingedeeld op mogelijke invloeden van buitenaf. Die mogelijke invloeden van buitenaf kunnen invloed hebben op de uitkomst van dit afstudeerproject. Deze in invloeden zijn afkomstig uit de resultaten van de contextanalyse (Hfst. 3.2).
Micro-omgeving: krachten in de organisatie die van invloed zijn op het resultaat. Meso-omgeving: directe omgeving van het bedrijf/organisatie.
Macro-omgeving: bredere maatschappelijke krachten die de markt beïnvloeden. Micro (De gemeente Wierden)
ID Mogelijke invloeden
1. Het commitment van de betrokken afdelingen en het management.
2. Het nieuwe supportsysteem dient bekend te zijn binnen de afdelingen en de organisatie. Tabel 5 Micro-omgeving randvoorwaarden
Meso (de ICT-afdeling)
ID Mogelijke invloeden
1. Het supportsysteem moet gekoppeld kunnen worden aan de huidige IT-infrastructuur om
het zo mogelijk te maken een CMDB op te zetten.
2. De beschikbaarheid van testpersonen en voldoende tijd om te testen.
3. Het management moet met behulp van het supportsysteem inzicht krijgen door middel
van rapportages.
Tabel 6 Meso-omgeving randvoorwaarden
Macro (De overheid)
ID Mogelijke invloeden
1. Er dient duidelijk te zijn welke gegevens er wel, en niet geregistreerd moeten worden. 2. Er moet gedacht worden aan het archiveren en anonimiseren van persoonsgegevens in
meldingen.
3. Om mogelijke ziekte (Covid-19) te voorkomen of het niet kunnen voltooien van het
afstudeerproject dient er zoveel mogelijk thuis gewerkt te worden.
4. Wanneer de gemeente Wierden over gaat naar een beheerde Cloud omgeving, dient het
mogelijk te zijn om het supportsysteem te koppelen aan de betreffende Cloud omgeving.
5. Het belang van het supportsysteem dient binnen de organisatie bekend en erkend te zijn. 6. De voordelen van het supportsysteem rechtvaardigen de hierbij horende kosten.
4
Literatuuronderzoek
Dit hoofdstuk beschrijft het literatuuronderzoek voor het afstudeerproject en zullen de deelvragen beantwoord worden. Ook zullen in dit hoofdstuk de ontwerpprincipes worden uitgewerkt. Voor een uitgebreidere toelichting op het onderzoek verwijs ik u door naar hoofdstuk 5 van het vooronderzoek.
4.1
Methodiek
De volgende methodieken zijn toegepast om het onderzoek effectief uit te kunnen voeren.
Zoekboom
De zoekboom beschrijft elke gebruikte zoekterm die gebruikt is in het onderzoek en of dit resultaten heeft opgeleverd. Zo ja, dan wordt er ook beschreven welke artikel(en) dit heeft opgeleverd. Ook de zoekmachine/databank die gebruikt is wordt meegenomen in de zoekboom. De tabel van de zoekboom ziet er als volgt uit.
Zoekterm Databank Bronartikel Gevonden documenten/artikelen Samenvatting Tabel 8 Zoekboom
Sneeuwbalmethode
De sneeuwbalmethode kan zorgen voor meer accurate zoekresultaten. Wanneer er een artikel is gevonden, kunnen er uit dat artikel nieuwe zoektermen bedacht worden. Uit die artikelen kunnen weer nieuwe zoektermen bedacht worden enzovoort.
Deskresearch
Bij de onderzoeksmethode deskresearch wordt er zowel literatuur als bestaande gegevens/informatie gebruikt. De bestaande gegevens/informatie zijn voortgekomen uit de groepsgesprekken die eerder hebben plaats gevonden. In deze analyse is er vooral gebruik gemaakt van de uitkomsten van de gesprekken om zo de context van meerdere perspectieven duidelijk te krijgen.
4.2
Deelvraag 1 & 2
Deelvraag 1 & 2 zijn reeds al beantwoord. Voor het antwoord op deze vragen verwijs ik u naar de volgende hoofdstukken van het vooronderzoek: Probleemanalyse (Hfst. 1), Behoefteanalyse(Hfst. 2) en de Contextanalyse (Hfst. 3)
4.3
Deelvraag 3: Welke methodes zijn er om de processen
in te richten?
Om meer structuur aan te brengen binnen de ICT-afdeling dienen er nieuwe processen te komen. Voordat deze processen gekozen kunnen worden moet er eerst onderzocht worden welke methode hiervoor gebruikt kan worden. Uit de literatuur blijkt dat er verschillende methodes zijn om processen in te richten. Hierbij is er zo breed mogelijk gekeken naar de methodes, bijvoorbeeld of methodes platform afhankelijk/ gericht zijn en of methodes goed aansluiten bij de eisen en wensen van de gemeente Wierden. Hieronder worden een aantal mogelijke methodes genoemd en wat hiervan de mogelijkheden zijn. De methodes die in deze deelvraag besproken worden zijn:
• ISM (Integrated Service Management)
• ITIL (Information Technology Infrastructure Library) • MOF (Microsoft Operations Framework)
4.3.1
ISM (Integrated Service Management)
ISM (ISM, 2005) wordt beschreven als een methode om de IT-dienstverlening te organiseren, te borgen en continu te verbeteren. Het is een compacte maar complete set van processen, rollen, procedures, tools en werkinstructies om alle IT-diensten te ontwerpen, leveren, beheren én continu te verbeteren. ISM zorgt ervoor dat alle middelen die de IT-afdeling inzet in samenhang worden ingericht én gemanaged. De IT- beheerders gaan beter samenwerken door managementaansturing, het standaardiseren van processen en het afstemmen van toolinrichting. De ISM-methode dient niet gezien te worden als een complete vervanging van het ITIL-gedachtegoed. ISM heeft de verschillende methoden en werkwijzen gecombineerd in een integrale aanpak. ISM is dus te vergelijken met een bundeling van standaardisering methoden zoals ITIL, DevOps, BiSL, MOF etc.
ISM bestaat uit een procesmodel; een integratie met een set van tools, een serie templates, een organisatiebeschrijving, een standaard definitiestelsel, en een implementatie-aanpak. In deze deelvraag is alleen het procesmodel van belang en niet de overige onderdelen. Mocht ISM gekozen worden als de te gebruiken methode, dan zullen de overige onderdelen ook behandeld worden.
Het procesmodel van ISM beschrijft in zes elementaire processen de werkzaamheden op tactisch en operationeel niveau, in een volledig geïntegreerd model. Deze zes processen, die op
activiteitenniveau zijn uitgewerkt, sluiten aan op de bekende ITIL-processen. ISM richt zich met name op het verbeteren van de onderlinge samenwerking en het procesmodel is dan ook vooral een samenhangende set samenwerkingsafspraken. De onderstaande afbeelding toont het ISM-procesmodel.
Figuur 2 ISM proces model, bron: (ISM, 2005)
Volgens (Both, 2012) bestaat het ISM-procesmodel (figuur 2) uit de volgende zes processen: • Afspreken – Service Level Management (SLM), Er dienen tussen de klant en de
IT-beheerorganisatie afspraken gemaakt te worden over de dienstverlening.
• Voorkomen – Quality Management (QM), Dit houdt in het beperken van risico's die een bedreiging kunnen vormen voor het leveren van de IT-dienstverlening.
• Wijzigen – Change Management (CHM), Wanneer het gewenst is (vanuit de klantwens) of nodig is (om de dienstverlening te blijven garanderen) dienen er werkzaamheden uitgevoerd te worden waardoor IT-middelen kunnen wijzigen.
• Herstellen – Incident Management (INC), Als de functionaliteit in het geding komt door falen van ICT-middelen, dan dient de dienstverlening hersteld te worden.
• Informeren – Configuration Management (COM), Het beschikbaar stellen van informatie zodat andere processen daarover kunnen beschikken en daardoor (beter) functioneren. • Leveren – Operations Management (OPS), Er moeten operationele werkzaamheden
verricht worden door de IT-dienstverlener om de levering van IT-diensten mogelijk te maken en blijvend te realiseren.
4.3.2
ITIL (Information Technology Infrastructure Library)
Uit de literatuur van (Latour, 2017) en (Freshdesk, 2020) is gebleken dat ITIL de meest toegepaste beheermethodiek is en nog steeds dé standaard is voor het inrichten van beheerprocessen binnen een IT-organisatie. Uit literatuur is gebleken dat er naast ITIL nog 2 andere methodes zijn. Dit zijn ASL (Application Services Library) en BISL (Business Information Services Library). De reden dat er niet voor ASL of BISL is gekozen is dat ASL wordt gebruikt voor het inrichten van applicatiebeheer en applicatiemanagement, en BISL zich voornamelijk richt op het informatie en functioneel beheer (de gebruikerskant). Omdat het in dit afstudeerproject niet alleen gaat over applicatiebeheer, applicatie management of de gebruikerskant is er gekozen voor ITIL. Volgens (GoodSense) richt ITIL zich op de technische kant, (de infrastructuur) maar richt zich ook een stuk op de applicaties en informatie/ functioneel beheer (de gebruikerskant). Ook al spelen zowel de applicatiebeheerder(s) en de gebruikers een rol tijdens dit afstudeerproject, dan nog blijft de focus bij dit project liggen op het beheer van de technische kant (de infrastructuur). Op het moment van schrijven is ITIL V4 de meest recente versie. Tijdens dit onderzoek zal echter ITIL V3 gebruikt worden. De keuze hiervoor is omdat bij V3 de focus ligt op het creëren van processen en bij V4 de focus ligt op het creëren van waarde. Aangezien bij de gemeente Wierden op dit moment geen enkel proces aanwezig is voor bijvoorbeeld het afhandelen van een incident, ligt het meer voor de hand om te gaan voor de versie waarbij de focus ligt op het creëren van processen. In een later stadium kan er eventueel worden gekeken naar ITIL V4 voor het vergroten van de waarde. ITIL V3 dekt zowel applicatie- als infrastructuurbeheer af. Indien gewenst kan ITIL worden uitgebreid met de bijbehorende ITIL rollen. Het basisprincipe van ITIL is dat de IT-organisatie diensten verleent aan de afnemer (de gebruikersorganisatie) in een standaard pakket. ITIL V3 is opgedeeld in vijf levenscyclusfasen. Elke fase is opgedeeld in meerdere processen op basis van dienstprincipes, processen, rollen en prestatie-indicatoren.De vijf levenscyclusfasen zijn:
• Service strategy: gericht op het definiëren van de strategie van je organisatie voor het
bedienen van klanten, en hoe je die strategie onderhoudt en implementeert. Het doel van deze levenscyclusfase is je organisatie aanmoedigen om strategisch te denken en te handelen.
• Service Design: gericht op het vertalen van de service strategy naar de praktijk door het
ontwerpen en ontwikkelen van nieuw aanbod of door het bestaande aanbod aan diensten van je organisatie te verbeteren.
• Service Transition: gericht op het samenbrengen van alle middelen binnen een dienst en
zorgen dat deze geïntegreerd en getest worden. Service transition kijkt ook naar de kwaliteit van een nieuwe of gewijzigde dienst voor deze operationeel wordt.
• Service Operation: zorgt dat er robuuste best practices zijn die bijdragen aan
responsieve dienstverlening (vraag en antwoord). Incident Management en de servicedesk van je organisatie behoren bijvoorbeeld tot deze fase.
• Continual Service Improvement: gericht op het verbeteren van de effectiviteit en
efficiëntie van de IT-processen en -diensten van jouw organisatie. Deze levenscyclusfase verbetert continu de andere vier fasen.
Zoals hierboven beschreven staat, bestaat elke fase weer uit meerdere processen. Hieronder is een lijst te zien van deze processen afkomstig uit de samenvatting van (GoodSense).
Service Strategy
• Strategy Management for IT Services, • Service Portfolio Management
• Demand Management • Financial Management
• Business Relationship Management
Service Design
• Design Coördination • Service Level Management • Service Cataloque Management • Capacity Management
• Availibility Management
• IT Service Continuity Management • Information Security Management • Supplier Management
Service Transition
• Change Management • Change Evaluation • Project Management • Application Development
• Service Asset and Configuration Management • Release and Deployment Management
• Knowledge Management Service Operation • Incident Management • Event Management • Request Fulfilment • Problem Management • Access Management • IT Operations Control* • Application Management* • Technical Management*
Continual Service Improvement
• Seven-step improvement process
* dit zijn geen processen binnen ITILV3 maar functies
Voor uitleg van deze processen verwijs ik u door naar het vooronderzoek, hoofdstuk 5.2.2.2 ITIL.
De volgende afbeelding (figuur 3) toont de vijf levenscyclusfasen van ITIL V3
Zoals hierboven te lezen is, biedt ITIL een heel scala aan processen aan, die ingericht kunnen worden. Belangrijk om te onthouden is dat niet elk proces ingericht hoeft te worden om het doel te bereiken. Echter is het wel belangrijk om van tevoren goed helder te hebben welke processen ingericht moeten worden en welke niet.
4.3.3
MOF (Microsoft Operations Framework)
(Berg, 2013) beschrijft het Microsoft Operations Framework (MOF) als richtlijnen waarmee organisaties bedrijf kritische systeembetrouwbaarheid, beschikbaarheid, ondersteunbaarheid en beheerbaarheid van Microsoft-producten en -technologieën kunnen bereiken en beheren. MOF bestaat deels uit een aantal componenten van ITIL en is verrijkt met een aantal specifieke
componenten van Microsoft voor de inrichting van de beheerprocessen. Microsoft bouwt bewust voort op ITIL en stelt dat het ITIL zowel adopteert als adapteert. MOF is ontworpen om breed te kunnen worden ingezet en zou dus ook geschikt zijn voor andere omgevingen dan die van Microsoft. Echter werkt MOF prettiger in een omgeving die is gebaseerd op Microsoft omdat deze omgevingen goed op elkaar aansluiten. Op het moment van schrijven is MOF 4.0 de nieuwste versie. Echter is de nieuwe versie gebouwd om meer de waarde van IT in te zien en het verbeteren van de organisatorische capaciteit. MOF 4.0 is dus niet specifiek gericht op het inrichten of implementeren van nieuwe
processen. Om deze reden wordt er dus gebruik gemaakt van MOF en niet van MOF 4.0. Zoals net al vermeld was is MOF een alternatief voor de Information Technology Infrastructure Library ( ITIL ). Net als ITIL bevat MOF richtlijnen voor de hele levenscyclus van een IT-service: van concept tot einde of vervanging. Deze worden bij MOF quadrants genoemd. MOF kent 4 quadrants, binnen deze quadrant bevinden zich de service management functions (SMFs). Volgens (Microsoft, High Availability and the Microsoft Operations Framework, 2017) zijn SMF's de best practices op basisniveau en
voorschrijvende richtlijnen voor het beheren en onderhouden van een IT-omgeving. Het volgende figuur toont de MOF procesmodel (figuur 4).
Figuur 4 MOF procesmodel, bron: (Berg, 2013)
Changing quadrant
Het changing quadrant omvat de SMFs die nodig zijn om veranderingen te identificeren, te
beoordelen, goed te keuren en op te nemen in een beheerde IT-omgeving. Het gaat hier vooral om wijzigingen in software, hardware, documentatie, rollen en verantwoordelijkheden. De volgende processen horen bij dit quadrant:
• Change management • Configuration management • Release management
Operating quadrant
Het operating quadrant omvat de SMF's die nodig zijn om serviceoplossingen dagelijks te bewaken, controleren, en beheren om serviceniveaus te bereiken en te behouden binnen vooraf bepaalde parameters. De volgende processen horen bij dit quadrant:
• Service monitoring and control • System administration
• Network administration
• Directory services and administration • Security administration
• Storage management • Job scheduling
Supporting quadrant:
Supporting quadrant omvat de SMF's die nodig zijn om incidenten, problemen en verzoeken te identificeren, toe te wijzen, te diagnosticeren, op te sporen en op te lossen binnen de goedgekeurde vereisten die zijn opgenomen in de Service Level Agreements.
• Servicedesk
• Incident management • Problem management
Optimizing quadrant:
Het optimizing quadrant omvat de SMF's die bijdragen aan het handhaven van de afstemming van het bedrijf en de IT door te focussen op het verlagen van de IT-kosten terwijl het serviceniveau
gehandhaafd of verbeterd wordt. Dit omvat beoordeling van uitval en incidenten, onderzoek van kostenstructuren, beoordelingen van personeel, analyse van beschikbaarheid en prestaties en capaciteitsvoorspellingen.
• Service Level Management • Capacity management • Availability management • Security management • Infrastructure engineering • Financial management • Workforce management
• Service Continuity Management
Voor uitleg van deze SMF’s verwijs ik u door naar het vooronderzoek, hoofdstuk 5.2.2.3 MOF.
4.3.4
Discussie, aanbeveling en conclusie
Discussie
Uit de literatuur en het onderzoek is gebleken dat veel beheermethodes allemaal een eigen
(afgeslankte) versie van ITIL zijn. In de kern bieden ze allen dezelfde processen aan, alleen onder de naam van een andere methode. Echter is het gevaar bij ITIL dat er veel processen zijn om uit te kiezen, dat hier verkeerde keuzes in gemaakt worden, en dat het te groot of complex wordt waardoor het een papieren drama wordt. Maar omdat ITIL een referentiemodel is kan iedere organisatie zelf bepalen en een afweging maken hoe ze dit willen gebruiken of inrichten.
Het framework dat Microsoft aanbiedt genaamd “MOF” is ietwat verouderd. Ook biedt de nieuwste versie MOF 4.0 niet de functionaliteiten die voor dit afstudeerproject gevraagd zijn. Ook is gebleken dat deze methode het beste werkt bij een IT-infrastructuur die gericht is op Microsoft software. Aangezien bij de gemeente Wierden weinig tot niks gedaan wordt op het gebied van beheer met Microsoft heeft het niet veel toegevoegde waarde om deze methode te gebruiken voor dit project. Mocht het ooit voorkomen dat hier verandering in komt, dan kan dit onderdeel weer naar voren komen ter discussie.
De methode ISM is, zoals hierboven beschreven, een simpelere versie van ITIL maar biedt wel een aantal van dezelfde kernprocessen aan.
Aangezien MOF afvalt als methode blijven er dus ITIL en ISM over. Tussen deze 2 methoden moet dan de afweging gemaakt worden welke beter aansluit bij de requirements van de gemeente Wierden.
Aanbeveling
Na onderzoek van de deelvraag: “Welke methodes zijn er om de processen in te richten?” is er de keuze tussen ITIL en ISM. Wanneer er hierbij ook wordt gekeken naar de requirements die zijn opgesteld, voldoet ISM net niet aan de gestelde requirements. Het gaat met name om de requirement BR07 uit de behoefteanalyse. Deze requirement houdt namelijk in dat de gemeente Wierden in de toekomst graag meer processen wil inrichten en implementeren met dezelfde methode. Dit is met ISM niet mogelijk. De reden hiervoor is dat ISM maar 6 processen aanbiedt en er dus geen mogelijkheid is om in de toekomst meer processen met deze methode in te richten. ITIL aan de andere kant, biedt een heel scala aan processen aan. Hoewel in eerste instantie niet al deze processen worden
ingericht, zijn er nog genoeg ITIL processen die in de toekomst wel verder kunnen worden uitgewerkt en ingericht. Omdat ISM dus geen uitbreide mogelijkheden heeft kan ISM niet voldoen aan alle requirements. Om deze reden is er voor deze opdracht gekozen voor ITIL.
