Leones. IT Service Assessment & Improvement

Leones

IT Service Assessment & Improvement

05-03-2009

1.


Versie 2.0

Inleiding

Dit rapport is geschreven in opdracht van Leones door Jurjen Bloo, student aan de Hogeschool van Amsterdam en is onderdeel van de afstudeeropdracht.

Binnen dit rapport worden de volgende onderdelen behandeld: –

De organisatie van Leones;

–

IT dienstverlening met de daarbij horende bedrijfsprocessen;

–

Nul-meting van de IT-Servicedesk;

–

Advies met betrekking tot de IT dienstverlening.

De organisatie Leones wordt in de eerste paar hoofdstukken uitgediept. Naarmate het document vordert zullen de problemen aan het licht komen. Om de analyse op een juiste manier te doorlopen heb ik gekozen om de stappen van lemniscate model te volgen.

2

Auteur: Jurjen Bloo

05-03-2009


Versie 2.0

Inhoudsopgave 1.

INLEIDING ................................................................................................................................................. 2

2.

DE ORGANISATIE ...................................................................................................................................... 4 2.1 LEONES ....................................................................................................................................................... 4 2.2 PRODUCTEN EN DIENSTEN ............................................................................................................................... 4 2.3 ORGANOGRAM ............................................................................................................................................. 5 2.4 PROCESSEN .................................................................................................................................................. 5 2.4.1 Primaire processen ........................................................................................................................... 5 2.4.2 Secundaire processen ....................................................................................................................... 6 2.4.3 Porter waardeketen ......................................................................................................................... 6 2.5 IT-SERVICE .................................................................................................................................................. 7 2.6 C/U MATRIX ................................................................................................................................................ 8

3.

NUL-METING VAN DE IT-SERVICE ORGANISATIE ....................................................................................... 9 3.1 DOELSTELLINGEN .......................................................................................................................................... 9 3.2 FUNCTIES..................................................................................................................................................... 9 3.3 TAKEN....................................................................................................................................................... 10 3.4 PROCESSEN ................................................................................................................................................ 14 3.4.1 Change Management ..................................................................................................................... 15 3.4.2 Incident Management Infrastructure ............................................................................................. 16 3.4.3 Incident Management Software Solutions ..................................................................................... 17 3.5 CULTUUR BINNEN IT-SERVICE ORGANISATIE...................................................................................................... 18 3.6 PROBLEMEN BINNEN DE IT-SERVICE ORGANISATIE ............................................................................................. 18 3.7 CONCLUSIE ................................................................................................................................................ 19 3.8 HUIDIGE EN GEWENSTE SERVICE ..................................................................................................................... 19 3.8.1 Huidige service ............................................................................................................................... 19 3.8.2 Gewenste service ............................................................................................................................ 19

4.

METHODOLOGIE ..................................................................................................................................... 20 4.1 INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY (ITIL)............................................................................. 20 4.1.1 ITIL process assessment .................................................................................................................. 21 4.2 CAPABILITY MATURITY MODEL INTEGRATED(CMMI) ........................................................................................ 22

5.

ADVIES ..................................................................................................................................................... 1 5.1 5.2

KORTE TERMIJN DOELSTELLINGEN ..................................................................................................................... 1 LANGER TERMIJN DOELSTELLINGEN ................................................................................................................... 4

6.

BIJLAGE I: INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY VRAGENLIJST.................................. 5

7.

BIJLAGE II: CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ........................................................ 17

®

3

Auteur: Jurjen Bloo

05-03-2009


2.

De organisatie

2.1

Leones

Versie 2.0

Leones is een ICT dienstverlener die zich richt op de zorgsector. Binnen de zorgsector neemt ICT een steeds belangrijker plaats in. Was het vroeger ter ondersteuning van het administratieve proces, tegenwoordig wordt ICT een helper, zowel voor de interne processen als onderscheidend vermogen ten opzichte van andere instellingen. Daardoor hebben zorginstellingen behoefte aan een goed geïnformeerde en betrouwbare gesprekspartner. Leones heeft ruime ervaring in het geven van advies op maat en indien gewenst, voegen de daad graag bij het woord en realiseren een passende ICT voorziening.

2.2

Producten en diensten

Leones biedt een groot aantal ICT producten en diensten aan. De dienstverlening varieert van beleidsadvies, complete inrichting van computernetwerken en het ontwikkelen van maatwerk (web)applicaties tot hard- en software producten. Tot het dienstenpakket behoren ook interim management na een fusie, de inrichting van een nieuw rekencentrum of de installatie van een beveiligde netwerk infrastructuur. Een beknopte opsomming van de producten en diensten vindt u hieronder: Op project- of regiebasis Installatie en inrichting ICT netwerken Maatwerk software Beleidsadvisering Interim management Projectmanagement Infrastructuur engineering Informatie analyse Ontwerp van ICT-architecturen Training Website en intranet ontwikkeling

4

Op contractbasis ICT Servicedesk Systeembeheer Werkplek service Datacenterbeheer Technisch applicatiebeheer ASP diensten en hosting Beheerde netwerkinfrastructuren Calamiteiten service

Auteur: Jurjen Bloo

05-03-2009


2.3

Versie 2.0

Organogram Directie

Secretariaat

Programma Management

Operations

Finance

Marketing

Consultant

2.4

Project Management

Sales

Service

Processen

De processen binnen Leones zijn op te splitsen in primaire en secundaire processen. Hieronder zijn de Primaire processen en de Secundaire processen kort beschreven. Ook is er een Porter waardeketen gemaakt van de processen.

2.4.1

Primaire processen

Het primaire proces van Leones is het verkopen van IT oplossingen aan diverse klanten. De processen die hiervoor nodig zijn worden in vier verschillende soorten onderverdeeld: –

Marketing

–

Operations

–

Finance

–

Sales

Marketing Om de producten van Leones aan de man te krijgen zal er goede marketing moeten zijn. De afdeling marketing is hier verantwoordelijk voor. Ze houden zich bezig met het kijken naar de vraag van de markt en de naamsbekendheid.

Operations Operations is het hart van de organisatie. Binnen deze afdeling worden de ICT-oplossingen gecreëerd, consultancy geleverd en service verleend aan de verschillende klanten van Leones.

Finance Fincance houdt zich bezig met de betalingen van Leones.

5

Auteur: Jurjen Bloo

05-03-2009


Versie 2.0

Sales Om ervoor te zorgen dat de ICT-oplossingen verkocht is er de afdeling Sales. Deze is verantwoordelijk voor het werven van klanten en de juiste contracten af te sluiten.

2.4.2

Secundaire processen

Secretariaat Het secretariaat houdt zich bezig met het plannen van afspraken voor de directie en het opstellen van contracten voor de medewerkers.

Programma Management Programma Management houdt zich bezig met het onderzoeken naar mogelijke nieuwe ICToplossingen.

Porter waardeketen

Programma Management

Sales

Service

Finance

Operations

Secretariaat

Marketing

2.4.3

6

Auteur: Jurjen Bloo

05-03-2009

2.5


Versie 2.0

IT-Service

Leones maakt gebruik van software die speciaal ontwikkeld is om hun bedrijfsprocessen te ondersteunen. Het systeem, Webs, verwerkt o.a. de volgende gegevens contactgegevens, offertes, contracten, salariëring, projecten en servicedesk meldingen worden hierin verwerkt. Er bestaat de mogelijkheid voor de klanten van Leones om zelf in te loggen op het softwarepakket. De klanten kunnen binnen Webs hun contactgegevens te wijzigen en incidenten aanmelden. De voortgang van de incidenten kan ook bekeken worden binnen het systeem. Naast de applicatie Webs wordt er nog een tal van andere applicaties gebruikt. Hieronder ziet u een opsomming van veel gebruikte applicaties binnen Leones: – Microsoft Office 2003; – Microsoft Office 2007; – Microsoft SQL Server 2003; – Microsoft SQL Server 2007; – Visual Studio 2008; – Microsoft Exchange 2003; – Microsoft Windows Server 2000; – Microsoft Windows Server 2003; – Microsoft Windows XP; – Microsoft Windows Vista; – Adobe Photoshop CS2; – Citrix Neighborhood.

7

Auteur: Jurjen Bloo

05-03-2009

2.6


Versie 2.0

C/U Matrix

8

Auteur: Jurjen Bloo

05-03-2009

3.


Versie 2.0

Nul-Meting van de IT-Service organisatie

Om een duidelijk beeld te krijgen van de IT-Service organisatie heeft een nul-meting plaats gevonden. Hierdoor zal er een duidelijk beeld van de organisatie komen waarop vervolgens een advies geschreven wordt.

3.1

Doelstellingen

De IT-Service organisatie, Servicedesk, heeft een aantal primaire doelstellingen: De klant voorzien van een zo hoog mogelijk service; Systeem en Netwerkbeheer binnen de organisatie;

3.2

Functies

De IT-Service organisatie bestaat uit een aantal medewerkers. Hieronder is weergegeven om welke functie het gaat met daarbij het aantal medewerkers. Functie(s) Servicedesk e 2 lijn(Systeembeheer) e 3 lijn(Systeembeheer) Netwerk Consultant e 2 lijn(Applicatiebeheer) e 3 lijn(Junior programmeur) Specialist(Senior programmeur) Software Consultant Change Manager Project Management IT Manager

Aantal FTE’S 2 2,5 5,5 2 1 2 2 1 1 3 1

De medewerkers hebben ieder hun eigen verantwoordelijkheid. Hieronder is een organogram zichtbaar van de IT-Service organisatie. In de volgende paragraaf zal ingegaan worden op de taken van de verschillende functies.

9

Auteur: Jurjen Bloo

05-03-2009


Versie 2.0

Operations Manager

Consultant

Netwerk Consultant

Project Management

Service Manager

Change Manager

Software Consultant

3e lijn (Systeembeheer)

3e lijn (Junior programmeur)


2e lijn (Applicatiebeheer)

1e lijn (Servicedesk)

3.3

Taken

Binnen de IT-Service organisatie zijn een aantal verschillende taken te definiëren. In de onderstaande matrix staan de taken zoals deze door het Nederlands Genootschap voor Informatici (NGI) worden omschreven. Daarnaast staan de functies en wordt aan gegeven welke taak wordt vervult door welke functie.

10

Auteur: Jurjen Bloo

05-03-2009


11

Versie 2.0

Auteur: Jurjen Bloo

05-03-2009


12

Versie 2.0

Auteur: Jurjen Bloo

05-03-2009


13

Versie 2.0

Auteur: Jurjen Bloo

05-03-2009

3.4


Versie 2.0

Processen

In deze paragraaf zullen de processen besproken worden die momenteel toegepast worden. In het onderstaande overzicht zal met uitleg de huidige werkwijze uitgelegd worden. Vervolgens zijn de processen uitgetekend. Zodra een melding binnenkort op de Servicedesk zal er gekeken worden of de melding bestemd is voor software bestemd of voor infrastructure. Als de melding met software te maken heeft wordt deze e doorgestuurd naar de 2 lijns van applicatiebeheer. Is het een melding voor infrastructure zal er eerst gekeken worden of het gaat om een Change of dat het om een storing gaat. De verschillende processen zijn hieronder uitgetekend.

Klant 1

Klant 2

Klant 3 Incident Management

Telefoon

Mail

Webs

Change Management

Servicedesk (Eerste-lijnsondersteuning)

Change Management

Infrastructure

Software Solutions

Change Manager



Technisch Consultant


3e lijn (Junior programmeur)

Netwerk consultant

Software consultant

Verkoop

14

Auteur: Jurjen Bloo

05-03-2009

3.4.1


Versie 2.0

Change Management

Change Management Registratie (Servicedesk)

Incident Management

Incident

Intake en bewaking (Change Manager)

Aanname

Aanvulling info van beheer en klant

Proceskeuze

Advies?

Change

Nee

Registratie in Webs (aanvraag)

Engineering?

Ja

Ja

Engineering (Tech. Consultants)

Offerte (Verkoop binnendienst)

Advies

Offerte in Webs

Engineering

Offerte

Nee Registratie Aanvraagformulier Offerte?

Akkoord?

Nee

Ja

Inplannen

Project in Webs

Uitvoering

Terugkoppeling klant

Change afgesloten

15

Nee

Auteur: Jurjen Bloo

05-03-2009

3.4.2


Versie 2.0

Incident Management Infrastructure

Incident management Infrastructure Registratie & bewaken (Servicedesk)


1

1

Diagnose

Diagnose

Aanname

Change Management

Change


Proceskeuze

Incident

Registratie Nee

Nee

Nee

Oplossen

Oplossen

Opgelost?

Opgelost?

Matching

Opgelost?

Ja

1

Niet opgelost

Controle klant

Ja

Ja

Opgelost

Afsluiten

16

Auteur: Jurjen Bloo

05-03-2009

3.4.3


Versie 2.0

Incident Management Software Solutions

Incident management Software Solutions Registratie & bewaken (Servicedesk)


3e lijn (Junior Programmeur)

1

1

Diagnose

Diagnose

Aanname

Proceskeuze

Incident

Registratie Nee

Nee

Nee

Oplossen

Oplossen

Opgelost?

Opgelost?

Matching

Opgelost?

Ja

1

Niet opgelost

Controle klant

Ja

Ja

Opgelost

Afsluiten

17

Auteur: Jurjen Bloo

05-03-2009

3.5


Versie 2.0

Cultuur binnen IT-Service organisatie

Binnen de IT-Service organisatie hangt een klant georiënteerde cultuur. Dit wil zeggen dat de meeste incidenten snel worden verwerkt tot een goed werkend resultaat of dat er eerst een work-around wordt aangeboden om vervolgens het incident blijvend te verhelpen. De IT-Service organisatie is echter wel reactief. Er wordt weinig gepoogd om de incidenten te beperken. Men is meer bezig met het genezen in plaats van te voorkomen van incidenten.

3.6

Problemen binnen de IT-Service organisatie

Er zijn een aantal problemen naar boven gekomen, deze kunnen we verdelen in verschillende categorieën. In de onderstaande paragrafen staan de problemen omschreven onder de juiste categorie.

Servicedesk Kort geleden is men begonnen met het procesmatig werken binnen de IT-Service organisatie. Tijdens het uitvoeren van deze processen komt naar voren dat sommige processen nog vrij stroef lopen. Ook is er op dit moment weinig controle op de incidenten die voor Software Solutions bestemd zijn. Deze incidenten worden doorgestuurd en verdwijnen dan uit zicht van de IT-Service organisatie. Dit komt mede doordat er een slechte communicatie is tussen deze afdelingen. De slechte communicatie wordt door een aantal zaken gecreëerd.

Communicatie e

e

Momenteel valt de servicedesk onder infrastructure net als de Change Management, 2 en 3 lijns e e systeembeheer. De 2 lijns applicatiebeheer en de 3 lijns junior programmeur vallen onder Software Solutions. De afdelingen Infrastructure en Software Solutions leggen beide aan een andere manager verantwoording. Prioriteiten binnen de afdelingen worden ook anders gesteld. Wat de communicatie verder verslechterd is dat beide afdelingen aan de andere kant van het gebouw zitten. Hierdoor is snel overleg tussen de afdelingen lastiger.

Servicedesk Medewerkers De medewerkers van de Servicedesk zijn momenteel reactief ingesteld. Hierdoor is men altijd bezig met genezen in plaats van voorkomen. Het voorkomen van incidenten zou een grotere klanttevredenheid opwekken bij de klanten van Leones. Het geeft ook een goed signaal af naar eventueel nieuwe klanten. De medewerkers verzuimen om documenten up-to-date te houden. Dit zorgt ervoor dat er soms meer tijd nodig is om gegevens te achterhalen. Ook zijn er nauwelijks procedures uitgewerkt. Hierdoor is het voor nieuwe werknemers lastig om te beginnen met zijn/haar werkzaamheden. Bij ziekte levert dit ook problemen op. Taken over nemen van een collega is lastig als de werkzaamheden niet beschreven staan. Doordat werknemers niet goed bijhouden wat hun huidige werkzaamheden zijn. Levert dit het probleem dat bij ziekte niet bekend is waar diegene gebleven is met zijn werkzaamheden. Hierdoor worden taken misschien dubbel uitgevoerd. Dit levert onnodige vertraging op. Bij ziekte wordt ook zichtbaar dat er gebrek is aan personeel. Binnen de IT-Service organisatie is er niet genoeg mankracht om de taken van een zieke werknemer volledig over te nemen. Hierdoor zullen werkzaamheden vertraging oplopen. Dit wordt ook zichtbaar als het gaat om het beheer van de IT binnen Leones zelf. IT problemen binnen Leones worden vrijwel niet in behandeling genomen omdat hier te weinig tijd voor is. De klanten van Leones gaan nou eenmaal voor.

18

Auteur: Jurjen Bloo

05-03-2009

3.7


Versie 2.0

Conclusie

Aan de hand van de nul meting kunnen we opmaken dat er nog een hoop moet gebeuren binnen de IT-Service organisatie. Hieronder staat een opsomming van punten die verbeterd kunnen en moeten worden. Optimaliseren huidige processen; Procedures opstellen van de werkzaamheden; Vanuit de servicedesk betere controle op de incidenten van Software Solutions; Communicatie tussen Infrastructuur en Software Solutions verbeteren; Documenten up-to-date houden; Uitbreiding IT-Service organisatie.

3.8

Huidige en gewenste service

3.8.1

Huidige service

Momenteel loopt de IT-Service organisatie vrij stroef. Er wordt vrij reactief en ad hoc gewerkt. Er bestaan procedures maar deze staan nauwelijks op papier. Iedere medewerk weet wat zijn of haar taken zijn maar bij ziekte levert dit het probleem op dat andere de werkzaamheden van de desbetreffende medewerker niet over kan nemen. Voor nieuwe medewerkers is dit ook lastig om ingewerkt te worden. Ze hebben geen hou vast aan een overzicht met werkzaamheden die hij/zij uit moet voeren. Dit zal hem/haar de eerste weken afhankelijk maken van de andere medewerkers en zal het langer duren voordat iemand ingewerkt is. Voor mensen die een storing hebben is het vrij makkelijk om de servicedesk te bereiken. Dit verloopt goed. Probleem is nog wel dat als er storingen binnen Leones zelf zijn dat deze vrijwel niet verholpen worden. Dit veroorzaakt wildgroei op het netwerk. Mensen gaan hun eigen weg zoeken om hun probleem op te lossen. De communicatie tussen Infrastructure en Software Solutions loopt alles behalve soepel. Doordat er weinig communicatie is tussen de afdelingen is het voor de servicedesk niet mogelijk om controle te houden op de incidenten van Software Solutions. Doordat de documentatie niet altijd up-to-date is, is het soms onbekend wat de wachtwoorden zijn voor de verschillende systemen. Dit voorkomt vertraging op bij het verhelpen van incidenten. Tijd dat onnodig verloren gaat.

3.8.2

Gewenste service

Leones geeft aan dat het de IT-Service organisatie wil veranderen. Dat wordt ook zichtbaar doordat Leones bezig is met het reorganiseren. Er zijn momenteel een aantal processen uitgeschreven maar dit is niet voldoende. De wens is om een proactieve IT-Service organisatie neer te zetten. Die gaat werken volgens de ITIL processen. Men hoopt hierdoor de kwaliteit van de IT-Service organisatie te verhogen. In de IT-Service organisatie moeten de afdelingen Infrastructure en Software Solutions samen komen. Dit zal ervoor zorgen dat er op de juiste manier met elkaar gecommuniceerd word. Ook wordt het mogelijk voor de servicedesk om de incidenten beter te beheren. Hierdoor zal het niet meer mogelijk zijn om incidenten voor een lange tijd open te laten staan. Dit zal ook de kwaliteit van de servicedesk verhogen. Leones wenst ook dat Infrastructure en Software Solutions op dezelfde manier de incidenten af gaat handelen. Zo wil men een standaard creëren voor de manier van werken.

19

Auteur: Jurjen Bloo

05-03-2009

4.


Versie 2.0

Methodologie

In dit hoofdstuk zal ik een tweetal modellen gebruiken als referentie. De gegevens in de bovenstaande hoofdstukken zullen gebruikt worden om te meten welke procesen goed lopen en waar de zwakheden van de IT-Service organisatie liggen. Als referentie modellen maak ik gebruik van Information Technology Infrastructure Library (ITIL) om de processen te meten en

20

Auteur: Jurjen Bloo

05-03-2009


Versie 2.0

Capability Maturity Model Integrated(CMMI) om de volwassenheid van de processen te meten.

4.1

Information Technology Infrastructure Library (ITIL)

Information Technology Infrastructure Library is een framework voor het inrichten van beheerprocessen binnen een ICT-organisatie. ITIL bestaat uit een set van best practices. In de onderstaande opsomming staan de processen van ITIL versie twee.

Service Delivery 1. 2. 3. 4. 5. 6.

Financial Management for IT Services (FMITS) Capacity Management Availability Management IT Service Continuity Management (ITSCM) Service Level Management Security Management

Service Support 1. 2. 3. 4. 5. 6.

Change Management Release Management Problem Management Incident Management Configuration Management Service Desk

21

Auteur: Jurjen Bloo

05-03-2009

4.1.1


Versie 2.0

ITIL process assessment

Om de taken en processen van ITIL te meten heb ik een aantal vragen gedefinieerd. Deze vragen heb ik door de medewerkers van de IT-Service organisatie laten beantwoorden. De uitslag zal een duidelijk beeld creëren welke processen van ITIL gebruikt worden en op welke punten er laag gescoord wordt.. Hieronder zal de uitslag weergegeven worden. Voor de vragenlijst verwijs ik u door naar Bijlage I: Information Technology Infrastructure Library vragenlijst. De medewerkers konden antwoorden met cijfers. De cijfers staan voor het volgende: 1 Unsure 2

Strongly disagree (NO)

3

Disagree

4

Agree

5

Strongly agree (YES)

Average Process Score - all participants, all questions

Capacity Management

Service Desk 3 2.5

Security Management

2 Availability Management

Incident Management

1.5 1

Financial Management for IT

0.5 Problem Management

0

Average Score

IT Service Continuity Management

Configuration Management

Service Level Release Management Management Change Management

In de bovenstaande grafiek valt op te maken hoe de processen momenteel zijn ingevoerd. Gezien de uitslag is dit allemaal vrij laag. De Service Desk scoort het hoogst. Deze zit echter nog onder de 3 wat Disagree betekend. Dit zegt dat er momenteel geen gebruik wordt gemaakt van ITIL of iets dat in erop lijkt. De wens is om gebruik te maken van ITIL. Er zal nog een hoop aangepast moeten worden wil Leones ITIL invoeren. De score zou dan tussen de 4 en 5 moeten liggen.

22

Auteur: Jurjen Bloo

05-03-2009

4.2


Versie 2.0

Capability Maturity Model Integrated(CMMI)

Het CMMI model wordt gebruikt om de volwassenheid van een proces te kunnen meten en hier een niveau aan te kunnen koppelen. Doormiddel van de taak/proces matrix kan ik een duidelijke meting doen van het CMMI niveau van de ITIL processen binnen Leones. In het volgende diagram kan worden afgelezen, welk proces op welk niveau operationeel is. Voor meer informatie over het CMMI ® model kunt u zich wenden tot Bijlage II: Capability Maturity Model Integration (CMMi).

Servicedesk

Financial Management for IT Services (FMITS) 5

Capacity Management

4 ICT infrastructure Management

Availability Management

3 2

ApplicatieManagement

Continuity Management

1 0

Service Level Management

Security Management


Change Management

Incident Management

Release Management Problem Management

23

Auteur: Jurjen Bloo

5.

Advies

Gezien de wensen van Leones en hoe Leones er momenteel voorstaat moet er het een en ander veranderd worden. In dit hoofdstuk zullen de doelstellingen voor korte en langer termijn beschreven staan.

5.1

Korte termijn doelstellingen

Op korter termijn adviseer ik om een aantal doelstellingen te behalen. Als we kijken naar de analyse en de problemen die naar voren komen. Komen een aantal problemen duidelijk naar voren. In de volgende paragrafen zullen deze belicht worden.

Communicatie Binnen de IT-Service organisatie bestaan twee eilanden(Software Solutions en Infrastructure). Dit komt doordat de afdelingen aan de andere kant van het gebouw zitten. Communicatie onderling is daardoor minder. Om het probleem te verhelpen zullen de IT-Service medewerkers van Software Solutions en Infrastructure samen moeten komen te zitten om zo de communicatie te versterken. Er is momenteel ook geen intranet. Intranet maakt het mogelijk om makkelijker met elkaar te communiceren binnen Leones. Hierbij moet gedacht worden aan een smoelenboek, forum maar ook een up-to-date telefoonlijst zodat iedereen elkaar weet te vinden.

Verandering in de informatie management De kennis van de medewerkers zit op het ogenblik in het hoofd van de medewerkers. Door een kennismanagement systeem op te zetten zal de kennis die men heeft niet verloren gaan bij ziekte of vertrek. Ook als een collega iets moet weten kan hier de oplossing eventueel gevonden worden. Dit voorkomt dat het wiel opnieuw uitgevonden moet worden.

11-02-2009

Procesbeschrijving Incident Management

Versie 1.0

Verandering binnen de organisatie Ik adviseer om de organisatie in te richten volgens ITIL. ITIL is een bekend begrip binnen de ICT. Uit de meting, eerder in dit rapport, valt op te maken dat er een hoop zal moeten veranderen wil het voldoen aan het framework ITIL. Gezien de omvang van Leones raad ik aan om alleen de Support Set van ITIL in te voeren. Dit zal voldoende zijn om de juiste service te bieden aan de klanten en Leones zelf.

Klant 1

Klant 2

Gebruiker 1

Leones Front Office

Back Office

Systeem- en Netwerkbeheer

Change Management

Onderhoud en beheer informatiesystemen


Applicatiebeheer

Problem Management

Release Management

De Servicedesk zal uit een Front Office en een Back Office moeten bestaan. De Front Office is het aanspreekpunt van de klanten. Ik adviseer om de Front Office in te richten als een Skilled servicedesk - De medewerker bezit over enige kennens en diskundigheid en zal eenvoudige problemen proberen op te lossen. Een Skilled servicedesk heeft als voordeel dat incidenten sneller verholpen zullen worden. Hierdoor is het voor de Back Office mogelijk om op een proactieve manier incidenten te voorkomen.

2

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

Verandering binnen het proces De nieuwe organisatie zal een aantal nieuwe processen met zich meebrengen, sommige huidige processen zullen ook veranderen. Voor inzicht in de verschillende processen en de procedures ervan verwijk ik u door naar de bijlagen achteraan het document.

3

Auteur: Jurjen Bloo

11-02-2009

5.2


Versie 1.0

Langer termijn doelstellingen

Om van de reactieve IT-Service organisatie een proactive IT-Service organisatie te maken zal het gedrag dat de IT-Service organisatie moeten veranderen. Er zal verder vooruit gedacht moeten worden en de gemaakte processen zullen goed uitgevoerd moeten worden. Als we kijken naar het CMM model zien we dat de score laag is. De processen en procedures zijn slecht gedocumenteerd en worden niet tot nauwelijks uitgevoerd. Wil Leones de kwaliteit omhoog brengen dan zal hier zeker aan gewerkt moeten worden. In Nederland zitten de meeste bedrijven gemiddeld rond CMM level 3. CMM level 3 staat voor Defined. Dit is het niveau waarbij de belangrijkste processen zijn gestandaardiseerd. Dit is ook het niveau waar Leones naartoe moet.

Om tot dit niveau te komen zullen de processen gestandaardiseerd worden en iedere medewerker volgens de processen en procedures werken.

4

Auteur: Jurjen Bloo

11-02-2009

6.


Versie 1.0

Bijlage I: Information Technology Infrastructure Library vragenlijst

1 2 3 4 5

De vragen kunnen beantwoord worden met de volgende nummers. Achter elke nummer staat de betekenis van het antwoord. Unsure Strongly disagree (NO) Disagree Agree Strongly agree (YES)

1

Service Desk

1

3

Is there a Service Desk in place within your organisation (either formal or informal)? Are new employees to the organisation briefed on the ways to contact the Service Desk and for what type of issues? Is the Service Desk the known contact point for all IT problems?

4

Are calls that are taken at the Service Desk recorded in an electronic system?

5

Does the Service Desk advise end users of upcoming expected outages?

6

Does the organisation as a whole feel that the Service Desk is a good investment?

7

Are there easily accessible reports on numbers of calls received, types of calls, etc.? Does the Service Desk proactively advise users of the status of their calls, when certain time limits are reached? Is there a user satisfaction survey system in place (either automated for each issue or for instance a quarterly/annual survey)? Do the number of staff working on the Service Desk change in times of peak load? Do the Service Desk staff receive adequate training in the use of tools, telephone techniques and general customer support skills? Is there an escalation process in place for calls that cannot be resolved at first point of contact with the Service Desk? Is there a regular review of Service Desk performance against expected Key Performance Indicators? Is the Service Desk tool selected appropriate for the level of activities performed by Service Desk personnel? Is working on the Service Desk seen as a highly demanding role, requiring expert skills in troubleshooting and people management? Does the Service Desk provide trending information and customer satisfaction rating reports to Management? SCORE

2

8

9 10 11 12 13 14 15 16

5

Auteur: Jurjen Bloo

11-02-2009 2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16


Versie 1.0

Security Management Is there a clear understanding in the organisation of who or which department is responsible for IT security? Are there physical barriers in place preventing unauthorized access to critical IT equipment? Have the security needs of the business been documented? Is there a commitment within the management team to protect the organisations information? Is there an IT Security Plan in place that is constantly reviewed and updated? Are there preventative systems in place to protect against electronic attacks (e.g.. Firewalls)? Are there clear steps in place for handling security breaches? Do staff in the organisation appreciate the importance of protecting their information and IT Assets? Is Management provided security reports highlighting areas under attack, with suggested strategies? Are changes to the security profile of the organisation handled through a formal change management process? Is the cost of providing security known and balanced against the value of the information being protected? Are there procedures in place to ensure that the systems protecting the organisation are updated to the latest versions on a known schedule? Are there regular reviews with suppliers to ensure that their security measures are adequate? Are there regular reviews with clients/customers to ensure that your security measures do not hamper the smooth operation of the business? Do the Security Management team and the IT Service Continuity Management team have excellent communication channels between them? Are contracts/agreements with external security providers reviewed on a regular basis for completeness, reporting and relevance? SCORE

6

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

3

Incident Management

1

Is there a clear understanding by the IT Staff in the organisation of this process?

2

15

Is there enough information captured about incidents when they are registered? Are incidents assigned a classification code that may point to the likely cause of the incident? Is there a feeling within the business users that reducing the number of incidents will increase overall productivity? Is there a budget for the provision of incident management tracking tools and the overall Incident reduction? When closed are incidents assigned a code that points to the actual cause of the incident? Before effort is put into solving a new incident are there checks to see if the same incident was dealt with in the past? Is there sufficient time and budget allowed for training staff in this process area? Are the procedures in place to assess the user satisfaction levels of incident resolution? Are there suitable reports provided to Management that indicate incidents solved at the Service Desk, first level support, etc.? Are there regular reviews on performance of this process area against documented Key Performance Indicators (KPI's)? Are all incidents recorded or is there some informal ways users can bypass the process? Is there a good flow of information from Incident Management into the Problem Management process? Is there a list of high priority users that receive preferential treatment when registering incidents? Is there a procedure in place for dealing with high impact incidents?

16

Is each incident given it's own unique identifying number?

3 4 5 6 7 8 9 10 11 12 13 14

SCORE

7

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

4

Problem Management

1


2

Is it clear who in the organisation should be assigned problems to be dealt with? Is there a list of workarounds maintained and used while more detailed analysis is done? Does the process owner undertake proactive problem management (looking for potential areas of failure, before they occur)? Is there sufficient time and budget allowed for training staff in this process area?

3 4 5 6 7 8 9 10 11 12 13 14 15 16

Does the Process owner analyze incident information to look for incident trends? Is there management commitment to support staff allocating sufficient time for structural problem solving activities? Is the organisation committed to reducing the total number of problems and the number of incidents that interrupt the conduct of business? Are there suitable reports provided to Management that indicate numbers of problems outstanding & resolved, etc.? Have the responsibilities for problem management been assigned? Are electronic tools used in this process area well utilized? Is there a procedure by which potential problems are classified, in terms of category, urgency, priority and impact and assigned for investigation? Does the Problem Management process have a good line of communication with the Change Management process area? Is infrastructure monitored after problem resolution? Are there regular reviews on performance of this process area against documented Key Performance Indicators (KPI's)? Does this process area exchange information with a variety of other process areas? SCORE

8

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

5


1

4

Is there sufficient time and budget allowed for training staff in this process area? Is there a published and accepted list of what is considered to be the highest priority components of the infrastructure? Is there a known and documented naming convention in place for all Configuration items (CI's)? Are there procedures in place to ensure that the process cannot be bypassed?

5


6

Is the level of information held matched to the organizational requirements?

7

9

Are electronic tools used in this process area well utilized? Is there a Definitive Software Library and a Definitive Hardware Store within the organisation (physical storage locations for software and hardware)? Are all relevant components adequately labeled?

10

Does this process area exchange information with a variety of other process areas?

11

Are problem CI's identified automatically highlighted by defining rules in the CMDB? Does the structure of the Configuration Management Database (CMDB) help to prevent duplication of entries? Is there a regular review of the activities associated with this process? Is there a good flow of information from Configuration Management into the Release Management area? Are there regular reviews on performance of this process area against documented Key Performance Indicators (KPI's)? Is there a schedule of audit activity that is followed to check CMDB accuracy?

2 3

8

12 13 14 15 16

SCORE

9

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

6

Release Management

1

Has a release policy been agreed with the business representatives?

2

4

Is their a well defined change management process within the organisation? Is the master copy software/applications used in the organisation held in a physically secure location (DSL)? Is there sufficient time and budget allowed for training staff in this process area?

5

Are electronic tools used in this process area well utilized?

6

Are test plans and back out plans prepared for each release?

7

Is there a regular review of the activities associated with this process?

8

Is the CMDB updated with new details once a release is distributed? Are there standard setups that can be quickly deployed on standard equipment that comes into the organisation? Is there a schedule maintained of expected releases and their expected release date? Is there a clear understanding by the IT Staff in the organisation of this process?

3

9 10 11 12 13 14 15 16

Are the release numbers and naming conventions in place? Is the development environment properly insulated from the production or live environment? Are post release reviews held as part of a continual improvement program? Does this process area exchange information with a variety of other process areas? Are there regular reviews on performance of this process area against documented Key Performance Indicators (KPI's)? SCORE

10

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

7

Change Management

1


2

Are change requests check and verified for completeness prior to their submission?

3

Is there sufficient time and budget allowed for training staff in this process area?

4

Are electronic tools used in this process area well utilized? Has the Change Advisory Board (CAB) been established with appropriate terms of reference (meeting times, authority, etc.)? Are all changes submitted recorded (even ones that are rejected)?

5 6 7 8 9 10 11 12 13 14 15 16

Is there a procedure in place to handle Emergency Changes? Does the process area produce a Forward Schedule of Changes (FSC) (expected changes for the future)? Is there a regular review of the activities associated with this process? Are business representatives involved with major changes? Is there a clear distinction between a change request (e.g.. Upgrade application) and a service request (e.g.. Resetting a password)? Does this process area exchange information with a variety of other process areas? Are there regular reviews on performance of this process area against documented Key Performance Indicators (KPI's)? Are multiple changes grouped and then properly scheduled to minimize the impact to the business users? Are changes categorized according to their impact and urgency? Are changes assessed on the value they will deliver to the business prior to their approval? SCORE

11

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

8

Service Level Management

1


2


3

Are there Service Level Agreements (SLA) in place that follow a defined structure?

4

Does this process area exchange information with a variety of other process areas? Are agreements with external suppliers (Underpinning contracts) documented and reflected in the SLA's? Is there a Service Catalog that describes the services offered by the IT organisation? Is there a good communication channel between the IT Service Level Manager and the customer/business representative? Have all SLA's been accepted (signed off) by customers/business representatives? Is there an adequate Service Improvement Plan (SIP) that can be followed when SLA's are seriously breached? Is there sufficient time and budget allowed for training staff in this process area?

5 6 7 8 9 10 11 12 13 14 15 16

Are electronic tools used in this process area well utilized? Are there regular reviews on performance of this process area against documented Key Performance Indicators (KPI's)? Are SLA's written in such a way that changing Service Level Requirements (SLRs) can be easily incorporated and agreed upon? Are regular service review meetings held to discuss current and future requirements of the IT organisation? Does the SLA structure include features such as reliability, security, service hours, support, response times, turnaround times, performance criteria? Can new services be easily incorporated into the Service Level Management process? SCORE

12

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

9

IT Service Continuity Management

1


2

6

Is there a regular review of the activities associated with this process? Is there a regular Business Impact Analysis (BIA) that reviews the services used by the business and the impact if they are lost? Is there a documented and known recovery plan in place for each service area, in the event of an unforeseen issue? Do changes to the IT Service Continuity Plans go through a formal change management process? Does this process area exchange information with a variety of other process areas?

7

Are there regular backups of critical data taken and stored securely?

8

Are electronic tools used in this process area well utilized?

9

Is the cost of continuity planning balanced against the value to the business?

10

Is there sufficient time and budget allowed for training staff in this process area? Is there a continual check to find more effective solutions to incorporate into the ITSCM plan? Does the IT Service Continuity Management plan form part of the Business Continuity Plan? Is there a clear understanding of the recovery options available (manual workaround, reciprocal, gradual, intermediate, immediate)? Is there sufficient testing of the ITSCM plan?

3 4 5

11 12 13 14 15 16

Are critical backups of information tested on a regular basis? Are there regular reviews on performance of this process area against documented Key Performance Indicators (KPI's)? SCORE

13

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

10

Financial Management for IT

1


2


3

Do you have a good insight into the costs of running the IT environment?

4

Can costs of providing current services to the business be demonstrated easily?

5

Are actual costs compared to budgeted costs on a regular basis?

6

Are financial audits conducted regularly?

7

Is there sufficient time and budget allowed for training staff in this process area?

8

Can variances of actual to budgeted costs be easily traced?

9

Does this process area exchange information with a variety of other process areas? Is there clear understanding of operating versus capital costs, indirect versus direct and fixed costs versus variable costs? Are financial reports simple and easy to understand? Is it understood whether the IT department operates as a recovery center, profit center or simply an accounting center? Are electronic tools used in this process area well utilized?

10 11 12 13 14 15 16

Is the charging model used by the IT organisation defined and understood? Are there regular reviews on performance of this process area against documented Key Performance Indicators (KPI's)? Are checks made on the suitability for outsourcing or insourcing aspects of the IT environment against current known costs? SCORE

14

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

11

Availability Management

1


2

5

Is there a regular review of the activities associated with this process? Are there regular reviews on performance of this process area against documented Key Performance Indicators (KPI's)? Are the availability targets set by the organisation SMART (Simple, Measurable, Achievable, Realistic, Time bound)? Are electronic tools used in this process area well utilized?

6

Are availability statistics published on a regular basis?

7

Does this process area exchange information with a variety of other process areas? Does this process area provide information to the Change Management process area, about the impact of proposed changes? Is it accepted that high service availability is one of the key factors in high customer satisfaction ratings? Is there sufficient time and budget allowed for training staff in this process area? Is there a regular review of current infrastructure against required availability, with a view to optimizing equipment (lowering cost)? Can the cost of system failure be calculated (tangible and intangible)? Has the cost of high systems availability been analyzed alongside the business benefits? Are any accepted periods of service downtime for maintenance known and accepted by the customer/business representative? There is an accepted procedure for investigating reasons for high unavailability? Trend analysis is carried out on availability data, to help identify potential future bottlenecks? SCORE

3 4

8 9 10 11 12 13 14 15 16

15

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

12

Capacity Management

1


2

Is there a regular review of the activities associated with this process? Are there regular reviews on performance of this process area against documented Key Performance Indicators (KPI's)? Are electronic tools used in this process area well utilized? Attempts are made to influence the behavior of users to spread the peak load on services into non-peak times? Is there sufficient time and budget allowed for training staff in this process area? Threshold alarms in place for individual services that alert staff about approaching maximum capacity limits? There is a clear understanding of the differences between Business Capacity, Service Capacity and Resource Capacity Management? Does this process area exchange information with a variety of other process areas? Key components (resources) are monitored for capacity load (e.g.. Hard disk, memory, CPU, etc.). Capacity data is constantly analyzed to help in resolution of incidents and problems? Changes to the capacity of the IT environment are handled through a formal Change Management process? There is continual review of new products and technologies? Business capacity requirements are known well in advance - due to regular meetings and discussions about new services and changing requirements? The process is able to simulate the effects on capacity of new services or changes to existing services? Data relating to capacity is stored in a Capacity database (CDB) - allowing for powerful analysis and investigation? SCORE

3 4 5 6 7 8 9 10 11 12 13 14 15 16

16

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

Bijlage II: Capability Maturity Model® Integration (CMMi)

7. sm

CMMI is ontwikkeld door het Software Engineering Institute (SEI) en staat voor het Cabability ® sm Maturity Model Integration. Het CMMI is een procesmodel met verschillende representaties dat gebruikt kan worden om de volwassenheid van systeemontwikkelprocessen te beoordelen. ®

sm

Als opvolger van het Software CMM is het CMMI in vele opzichten sterk verbeterd. Daarmee is het een van de meest krachtige procesmodellen die beschikbaar zijn. In het model is aandacht voor procesgebieden in de volgende categorieën: projectmanagement, engineering, support en procesmanagement. Per procesgebied wordt aandacht geschonken aan doelen, activiteiten, voorwaarden en verificatie & validatie. Het model onderscheidt vijf levels (niveaus): 1. Initial is chaotisch en ad hoc. Dit is het niveau dat iedere organisatie aankan. 2. Repeatable is het niveau waarbij een proces zover geprofessionaliseerd is dat bij het ontwikkelproces gebruik wordt gemaakt van de kennis die eerder is opgedaan. 3. Defined is het niveau waarbij de belangrijkste processen zijn gestandaardiseerd. 4. Managed is het niveau waarbij de kwaliteit van het ontwikkelproces wordt gemeten zodat het kan worden bijgestuurd. 5. Optimizing is het niveau waarbij het ontwikkelproces als een geoliede machine loopt en er alleen maar sprake is van fijnafstemming (de puntjes op de i).

17

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

Leones


18

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

Inhoudsopgave 1.

ALGEMEEN ............................................................................................................................................... 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7

2.

AFHANDELEN MELDINGEN FRONT OFFICE ................................................................................................ 3 2.1 2.2 2.3 2.4

3.

DOEL ........................................................................................................................................................ 3 TOEPASSINGSGEBIED .................................................................................................................................... 3 STROOMSCHEMA......................................................................................................................................... 4 INHOUD STROOMSCHEMA ............................................................................................................................. 6

AFHANDELEN MELDINGEN BACK OFFICE .................................................................................................. 9 3.1 3.2 3.3 3.4

4.

INLEIDING .................................................................................................................................................. 1 DOEL PROCES.............................................................................................................................................. 1 BEREIK PROCES............................................................................................................................................ 1 INPUT PROCES ............................................................................................................................................. 1 ACTIVITEITEN PROCES ................................................................................................................................... 1 OUTPUT PROCES.......................................................................................................................................... 2 RELATIES MET ANDERE PROCESSEN .................................................................................................................. 2

DOEL ........................................................................................................................................................ 9 TOEPASSINGSGEBIED .................................................................................................................................... 9 STROOMSCHEMA....................................................................................................................................... 10 INHOUD STROOMSCHEMA ........................................................................................................................... 11

VOORTGANGSBEWAKING INCIDENT MANAGEMENT.............................................................................. 13 4.1 4.2 4.3 4.4

DOEL ...................................................................................................................................................... 13 TOEPASSINGSGEBIED .................................................................................................................................. 13 STROOMSCHEMA....................................................................................................................................... 14 INHOUD STROOMSCHEMA ........................................................................................................................... 15

19

Auteur: Jurjen Bloo

1.

Algemeen

1.1

Inleiding

Een incident is een afwijking van het afgesproken of verwachte kwaliteitsniveau van de ITdienstverlening. De Servicedesk is verantwoordelijk voor het ontvangen, registeren en afhandelen van incidenten.

1.2

Doel proces

Dit proces heeft tot doel zorg te dragen voor continuïteit in de dienstverlening door het zo spoedig mogelijk herstellen van het afgesproken dienstenniveau wanneer een afwijking hierop wordt geconstateerd en het verzamelen en registreren van informatie ten behoeve van mogelijke verdere analyse.

1.3

Bereik proces

De volgende organisatorische eenheden kunnen inhoudelijk met het proces Incidentbeheer te maken krijgen: - Servicedesk (eerste lijn) - Systeem- en netwerkbeheer (tweede lijn) - Onderhoud en beheer informatiesystemen (tweede lijn) - Applicatiebeheer (tweede lijn) - Ontwikkelafdeling - Klant

1.4

Input proces

Dit proces heeft de volgende input: - Incident - Standaardwijziging - Exploitatieopdracht - Foutmeldingen van systemen.

1.5

Activiteiten proces

De activiteiten van dit proces zijn als volgt: - Detectie en registratie - Classificatie en toewijzing - Diagnose en oplossing - Afsluiting - Rapportage. Deze activiteiten (met uitzonder van rapportage) worden in de volgende hoofdstukken nader uitgewerkt.

17-02-2009

1.6

Procedures Incident Management

Versie 1.0

Output proces

Dit proces heeft de volgende output: - Terugkoppeling over aangemelde incidenten

1.7

Relaties met andere processen

Dit proces heeft de volgende relaties met andere beheerprocessen: -

Configuration Management: De Configuration Management Database(CMDB) spelt een belangrijke rol voor Incident Management omdat relaties tussen productiemiddelen, diensten, gebruikers en Service Levels daarin terug te vinden zijn, waardoor een betere impact inschatting gemaakt kan worden. Verder geeft Configuration Management een inzicht in wie er voor een onderdeel van de infrastructuur verantwoordelijk is zodat incidenten effectiever gerouteerd. Tijdens de incident registratie worden configuratiegegevens gekoppeld aan het incidentrecord zodat het een beter beeld geeft van de storing. Eventueel kan de status van de betrokken componenten in de Configuratie Management Database worden bijgewerkt.

-

Problem Management: Problem Management stelt eisen aan de kwaliteit van de incidentregistratie om te kunnen zoeken naar mogelijke structurele fouten. Problem Managemetn helpt het Incident Management door informatie beschikbaar te stellen over Problems, Known Errors, Workarounds en Quick Fixes.

-

Change Management: Incidenten worden soms opgelost door het uitvoeren van standard-changes zoals bij het vervangen van een beeldscherm. Change Management stelt hiervoor een lijst van standaard changes, met de bijhorende procedures en/of werkinstructies, aan Incident Management ter beschikking. Verder levert Change Management ten behoeve van Incident Management inforamtei op over geplande Changes en de status daarvan. Daarnaast kunnnen Changes ook Incidenten veroorzaken als ze niet goed uitgevoerd

-

Service Level Management: Service Level Management bewaakt de afspraken met klanten over de te leveren ondersteuning. Incident Management moet van de Service Level Agreement(SLA) op de hoogte zijn, zodat deze informatie kan worden gebruikt in de contacten met de gebruikers. Uit de incident registratie kunnen rapportages worden gemaakt om te beoordelen of de diensten volgens afspraak is geleverd.

-

Dienstenniveaubeheer: Dienstenniveaubeheer maakt afspraken met klanten over het te leveren niveau van dienstverlening. De Servicedesk moet van deze overeenkomsten op de hoogte zijn, zodat deze informatie gebruikt kan worden bij het aannemen en oplossen van incidenten.

2

Auteur: Jurjen Bloo

17-02-2009


2.

Afhandelen meldingen Front Office

2.1

Doel

Versie 1.0

Het doel van deze activiteit is het zo spoedig mogelijk herstellen van het afgesproken dienstenniveau wanneer een afwijking hierop wordt geconstateerd.

2.2

Toepassingsgebied

Deze procedure is van toepassing op de ICT-afdeling en is geldig vanaf het moment van aanmelding van een incident tot het moment dat een door de gebruiker geaccepteerde oplossing van het incident is uitgevoerd. De Servicedesk is voor incidenten betreffende standaardtoepassingen de gehele procedure verantwoordelijk. Indien het incident echter niet voldoet aan de SLA dan wordt het incident door de Servicedesk toegewezen aan Contact Manager. Het valt daarna buiten het bereik van deze procedure en dit proces.

3

Auteur: Jurjen Bloo

17-02-2009


2.3

Versie 1.0

Stroomschema Begin

Servicedesk

0100

Aannemen melding

0200

Servicedesk

Is het een incident?

Change Mangement

Nee

Ja Servicedesk

0300

Registreren incident 0410 Toewijzen contract manager 0400

Servicedesk

Nee

Voldoet incident aan SLA Nee D

Servicedesk

0500

Standaard incident afhandeling mogelijk?

Ja

C

Servicedesk Servicedesk

0610

0600

Betreft het een bekend probleem

Ja

Koppelen aan bekend probleem en workaround opvragen

C

Nee Servicedesk

0700

Classificatie incident

B

4

Auteur: Jurjen Bloo

17-02-2009


Versie 1.0

B

Servicedesk

0800

Afhandeling mogelijk door Servicedesk? Nee Ja Servicedesk

0900

Diagnose stellen en oplossing zoeken

Servicedesk Servicedesk

Afhandeling mogelijk binnen vastgestelde tijdslimiet?

Nee

Ja

Servicedesk

C

1010

1000 Nee

Toewijzen/escaleren incident aan/naar Back Office

1100

Herstel dienstverlening

Gebruiker

1200

Acceptatie oplossing door gebruiker?

Servicedesk

D

Ja 1300

Afsluiten en coderen incident

Einde

5

Auteur: Jurjen Bloo

17-02-2009

2.4


Versie 1.0

Inhoud stroomschema

0100 Aannemen melding Een incident wordt aangemeld door de gebruiker bij de Servicedesk of een storing wordt door de Servicedesk opgemerkt door een foutmelding op een (monitor)systeem.

0200 Is het een incident? De binnengekomen meldingen worden beoordeeld of het gaat om een incident of om een change

0300 Registreren incident De Servicedesk registreert het incident in het Servicedesk Informatiesysteem op een eenduidige vastgestelde manier. De Servicedesk geeft aan de gebruiker het door het systeem gegenereerde incidentnummer door en de binnen de SLA vastgestelde oplossingstermijn.

0400 Voldoet incident aan SLA? De Servicedesk controleert of het incident voldoet aan de afgesproken dienstverlening in de SLA. Als dit het geval is wordt het incident geaccepteerd. Indien het incident niet wordt geaccepteerd wordt de gebruiker daarvan op de hoogte gebracht met vermelding van de reden. Zo ja, ga naar 0500. Zo nee, ga naar 1300. Indien het incident niet voldoet aan de SLA zal er een contract manager aan te pas komen, ga naar 0410.

0410 Toewijzen contract manager De naam en het telefoonnummer van de gebruiker wordt genoteerd en doorgegeven aan de contract manager. Het incident wordt afgesloten.

0500 Standaard incident afhandeling mogelijk? Nagegaan wordt of het gemelde incident overeenkomt met een van de vooraf gedefinieerde routineincidenten. Dit zijn incidenten (vaak standaardwijzigingen) die vaak binnenkomen en direct en eenvoudig kunnen worden afgehandeld. Voor deze zogenaamde standaardincidenten bestaat een werkinstructie, waarin precies beschreven staat hoe de Servicedesk het incident kan oplossen. Het Servicedesk Informatiesysteem wordt ook op een standaard manier (automatisch) verder ingevuld. Zo ja, ga naar 1100. Zo nee, ga naar 0600.

0600 Betreft het een bekend probleem? De Servicedesk gaat na m.b.v. de problemenadministratie of het incident als een bekend probleem geregistreerd staat. Zo ja, ga naar 0610. Zo nee, ga naar 0700.

6

Auteur: Jurjen Bloo

17-02-2009


Versie 1.0

0610 Koppelen aan bekend probleem en workaround opvragen Het incident wordt in het Servicedesk Informatiesysteem gekoppeld aan het bekende probleem. De vastgestelde workaround voor het bekende probleem wordt opgevraagd uit de problemenadministratie. De Servicedesk kan het incident nu (tijdelijk) oplossen totdat er een wijziging plaats gaat vinden waardoor het bekende probleem definitief wordt opgelost.

0700 Classificatie incident De Servicedesk bepaalt de prioriteit (impact, urgentie en verwachte inspanning) van het incident. Met behulp van een tabel met urgentiecategorieën bepaalt de Servicedesk de prioriteit van het incident. Hieruit volgt de maximale doorlooptijd die de Servicedesk mag besteden bij een gegeven prioriteitcode, alvorens te escaleren naar de Back Office. Hieruit volgt tevens de maximale doorlooptijd die de Back Office mag besteden bij een aan/naar een Expertiseteam toegewezen / geëscaleerd incident.

0800 Afhandeling mogelijk door Servicedesk? Kan het incident binnen de daarvoor vastgestelde maximale doorlooptijd door de Servicedesk worden afgehandeld (volgens schatting)? Heeft de Servicedesk genoeg kennis of bevoegdheden om het incident te kunnen oplossen? Indien het de Servicedesk hieraan ontbreekt wordt het incident toegewezen aan de Back Office. Bij een hoge prioriteitcode (calamiteit) kan het noodzakelijk zijn direct functionele en/of hiërarchische escalatie binnen de ICT-afdeling te laten plaatsvinden. Zo ja, ga naar 0900. Zo nee, ga naar 1010.

0900 Diagnose stellen en oplossing zoeken Op basis van de classificatie vindt het stellen van de diagnose en het zo snel mogelijk zoeken naar een mogelijke oplossing plaats. Er moet een voor de gebruiker bevredigende oplossing aangedragen worden. Indien blijkt dat het een incident is dat vaak binnenkomt en direct en eenvoudig kan worden afgehandeld moet besloten worden of dit incident een standaardincident wordt. Zo ja, dan moet voor dit zogenaamde standaardincident een werkinstructie worden gemaakt, waarin precies beschreven staat hoe de Servicedesk het incident in de toekomst kan oplossen.

1000 Afhandeling mogelijk binnen vastgestelde tijdslimiet? Voortgangsbewaking per individueel incident. Als het incident niet binnen de vastgestelde maximale doorlooptijd door de Servicedesk kan worden opgelost, wordt er geëscaleerd naar de Back Office. Zo ja, ga naar 1100. Zo nee, ga naar 1010.

1010 Toewijzen/escaleren incident aan/naar Back Office Het incident wordt toegewezen of geëscaleerd aan/naar de Back Office. De Servicedesk bepaalt welk expertiseteam in de Back Office voor de verdere afhandeling van het incident verantwoordelijk wordt gesteld. De Servicedesk stelt de gebruiker en het Expertiseteam hiervan op de hoogte.

7

Auteur: Jurjen Bloo

17-02-2009


Versie 1.0

1100 Herstel dienstverlening De Servicedesk voert een herstelactie uit. De uit te voeren actie kan voortkomen uit: - Het Servicedesk heeft zelf de benodigde acties geanalyseerd. - De workaround van een bekend probleem. De uit te voeren acties staan in de problemenadministratie. - Een bestaande standaard incident afhandeling. Voor de zogenaamde standaardincidenten bestaat een werkinstructie, waarin beschreven staat hoe de Servicedesk het incident kan oplossen - Een uit te voeren herstelactie is door de Back Office opgesteld en aan de Servicedesk meegedeeld. - Een uit te voeren herstelactie is door de Back Office uitgevoerd. De Servicedesk informeert de gebruiker welke herstelacties zijn uitgevoerd. Indien de herstelactie een nieuw opgestelde workaround betreft (de achterliggende oorzaak is dus nog niet gevonden) informeert de Servicedesk in geval van spoed Probleembeheer, opdat het proces Probleembeheer direct gestart wordt. In andere gevallen worden de calls naderhand periodiek door Probleembeheer geanalyseerd.

1200 Acceptatie oplossing door gebruiker? Als de aanmelder tevreden is met het resultaat van de herstelactie kan het incident worden afgesloten. Zo ja, ga naar 1200. Zo nee, ga naar 0900.

1300 Afsluiten en coderen incident De Servicedesk sluit het incident af als de gebruiker tevreden is met het resultaat of indien een melding door de Servicedesk niet wordt geaccepteerd omdat het niet voldoet aan de SLA. Bij afsluiting wordt het incident gecodeerd zodat analyse op de incidentgegevens door probleembeheer mogelijk wordt gemaakt. Codering vindt plaats bij afsluiting, aangezien dan pas met redelijke zekerheid de categorie, het incidentverloop en de herstelactie bepaald zijn. Als het incident binnen vijf werkdagen niet opgelost blijkt te zijn of als de gebruiker de oplossing binnen twee dagen toch niet accepteert en het incident is al afgesloten, dan wordt het afgesloten incident heropend en de afsluitgegevens worden ongedaan gemaakt. Na de genoemde werkdagen wordt een nieuw incident aangemaakt. Na afsluiting worden incidenten voor een bepaalde tijd bewaard. Op periodieke tijdstippen worden alle incidenten van voor een bepaalde datum gearchiveerd.

8

Auteur: Jurjen Bloo

17-02-2009


3.

Afhandelen meldingen Back Office

3.1

Doel

Versie 1.0

Het doel van deze activiteit is het zo spoedig mogelijk herstellen van het afgesproken dienstenniveau wanneer een afwijking hierop wordt geconstateerd.

3.2

Toepassingsgebied

Deze activiteit is geldig vanaf het moment dat een incident aan/naar de Back Office is toegewezen/geëscaleerd, tot het moment dat de herstelacties naar de Servicedesk zijn teruggekoppeld.

9

Auteur: Jurjen Bloo

17-02-2009

3.3


Versie 1.0

Stroomschema Begin

Expertiseteam

0100

Aannemen toegewezen/ geescaleerd incident

0200

Expertiseteam


Nee

Expertiseteam

0300

Afhandeling mogelijk door applicatie-/ systeembeheer

Expertiseteam

Ja

Nee

Ja 0400


Expertiseteam Expertiseteam


Expertiseteam

0510

0500 Nee

Uitbesteden/escaleren aan/ naar externe leverancier of maatregelen nemen

Ja 0600


Expertiseteam

0700

Terugkoppeling incident naar de Servicedesk

Einde

10

Auteur: Jurjen Bloo

17-02-2009

3.4


Versie 1.0

Inhoud stroomschema

0100 Aannemen toegewezen / geëscaleerd incident Een door de Servicedesk aan een Expertiseteam toegewezen incident wordt in behandeling genomen. Of het incident is geëscaleerd naar een Expertiseteam, omdat de toegestane doorlooptijd voor de Servicedesk is verstreken.

0200 Standaard incident afhandeling mogelijk? Nagegaan wordt of het gemelde incident overeenkomt met één van de vooraf gedefinieerde routineincidenten. Dit zijn incidenten (vaak standaardwijzigingen) die vaak binnenkomen en direct en eenvoudig door het desbetreffende Expertiseteam kunnen worden afgehandeld. Voor deze zogenaamde standaardincidenten bestaat een werkinstructie, waarin precies beschreven staat hoe het Expertiseteam het incident kan oplossen. Het Servicedesk Informatiesysteem wordt op een standaard manier (automatisch) verder ingevuld. Zo ja, ga naar 0600. Zo nee, ga naar 0300.

0300 Afhandeling mogelijk door Expertiseteam? -

-

Indien het incident niet aan het juiste expertiseteam is toegewezen (na een eerste diagnose kan de oorzaak/oplossing anders zijn dan in eerste instantie werd gedacht) dan wijst de specialist het incident toe aan een ander expertiseteam. Kan het incident binnen de daarvoor vastgestelde maximale doorlooptijd door het Expertiseteam worden afgehandeld (volgens schatting)? Heeft het Expertiseteam genoeg kennis of bevoegdheden om het incident te kunnen oplossen? Indien het het Expertiseteam hieraan ontbreekt dan wordt het incident geëscaleerd naar een externe leverancier of er worden maatregelen genomen om het expertiseteam alsnog in staat te stellen het incident op te lossen.

Bij hoge prioriteit (calamiteit) kan het noodzakelijk zijn direct functionele escalatie naar een externe leverancier te laten plaatsvinden. Tevens kan dan hiërarchische escalatie binnen de ICT-afdeling plaatsvinden. Zo ja, ga naar 0400. Zo nee, ga naar 0510

0400 Diagnose stellen en oplossing zoeken Op basis van de classificatie vindt het stellen van de diagnose en het zo snel mogelijk zoeken naar een mogelijke oplossing plaats. Er moet een voor de gebruiker bevredigende oplossing aangedragen worden. Indien blijkt dat het een incident is dat vaak bij het desbetreffende Expertiseteam binnenkomt en direct en eenvoudig kan worden afgehandeld moet besloten worden of het in de toekomst als een standaardincident wordt beschouwd. Zo ja, dan moet voor dit zogenaamde standaardincident door het Expertiseteam een werkinstructie worden gemaakt, waarin precies beschreven staat hoe het Expertiseteam, of indien mogelijk de Servicedesk, het incident in de toekomst kan oplossen.

0500 Afhandeling mogelijk binnen vastgestelde tijdslimiet? Voortgangsbewaking per individueel incident. Als het incident niet binnen de vastgestelde maximale doorlooptijd door het Expertiseteam kan worden opgelost, wordt er geëscaleerd naar een externe leverancier of worden er maatregelen getroffen om het expertiseteam alsnog in staat te stellen het incident op te lossen. Zo ja, ga naar 0600. Zo nee, ga naar 0510.

0510 Uitbesteden/escaleren incident aan/naar externe leverancier Het incident wordt uitbesteed of geëscaleerd aan/naar een externe leverancier. Het Expertiseteam bepaalt welke externe leverancier voor de verdere afhandeling van het incident verantwoordelijk wordt gesteld. Het Expertiseteam stelt de Servicedesk en de externe leverancier hiervan op de hoogte. Het 11

Auteur: Jurjen Bloo

17-02-2009


Versie 1.0

expertiseteam dat het incident heeft uitbesteed is verantwoordelijk voor de bewaking van de oplostijden van de externe leverancier.

0600 Herstel dienstverlening Het is mogelijk dat het Expertiseteam de uit te voeren acties opstelt, maar laat uitvoeren door de Servicedesk. Ook kan het zo zijn dat de externe leverancier de acties zelf uitvoert. Als het Expertisteam de acties zelf uitvoert kunnen de uit te voeren acties voortkomen uit: - Het Expertiseteam heeft zelf de benodigde acties geanalyseerd. - Een bestaande standaard incident afhandeling. Voor de zogenaamde standaardincidenten bestaat een werkinstructie, waarin precies beschreven staat hoe het Expertiseteam het incident kan oplossen - Een uit te voeren herstelactie is door de externe leverancier opgesteld en aan het Expertiseteam meegedeeld. De status van het incident wordt nu op opgelost gezet door het expertiseteam.

0700 Terugkoppeling incident naar de Servicedesk De te nemen of reeds ondernomen herstelacties worden in het Servicedesk Informatiesysteem beschreven zodat de Servicedesk de gebruiker over de oplossing kan informeren en er een kennisbestand wordt opgebouwd. Indien het expertiseteam de gebruiker al op de hoogte heeft gesteld van de oplossing staat dit duidelijk beschreven in het Servicedesk Informatiesysteem. De Servicedesk sluit het incident af door de status op gesloten te zetten.

12

Auteur: Jurjen Bloo

17-02-2009


4.

Voortgangsbewaking Incident Management

4.1

Doel

Versie 1.0

Het doel van deze activiteit is het bewaken van alle openstaande incidenten, zodat maatregelen kunnen worden genomen als het oplossingstraject niet volgens de afspraken dreigt te verlopen en zodat de aanmelder tijdig wordt geïnformeerd over de voortgang. Deze activiteit heeft betrekking op alle openstaande incidenten op een bepaald moment. Het betreft dus geen voortgangsbewaking per individueel incident. In principe is elke medewerker zelf verantwoordelijk voor de voortgangsbewaking van het incident dat hij/zij in behandeling heeft. Voortgangsbewaking dient om incidenten te signaleren die te lang bij de Servicedesk of een Expertiseteam open blijven staan. Of om ervoor te zorgen dat incidenten “tussen wal en schip” vallen of door geen enkele Expertiseteam wordt opgelost.

4.2

Toepassingsgebied

Deze activiteit is van toepassing op alle openstaande incidenten. De activiteit wordt periodiek gestart en kan ook direct gestart worden als het Servicedesk Informatiesysteem automatisch een melding geeft dat de toegestane tijd voor een incident is verlopen. De procedure eindigt als voor alle openstaande incidenten de stappen zijn doorlopen.

13

Auteur: Jurjen Bloo

17-02-2009

4.3


Versie 1.0

Stroomschema Begin

Incident Manager

0100

Verzamelen tijdsoverschrijdingen Front Office en Back Office

Incident Manager

0200

Achterhalen oorzaak tijdsoverschrijdingen

Incident Manager

0300

Overschrijding afgesproken of terecht?

Nee

Incident Manager

0400

Functionele of hierarchische escalatie

Ja

Manager

0500

Beoordelen en maatregelen nemen

Einde

14

Auteur: Jurjen Bloo

17-02-2009

4.4


Versie 1.0

Inhoud stroomschema

0100 Verzamelen tijdsoverschrijdingen Front Office en Back Office Van een tijdsoverschrijding is sprake als een incident volgens het Servicedesk Informatiesysteem langer bij de Servicedesk of een Expertiseteam open blijft staan dan volgens afspraak toegestaan. Het openstaande incident is dan niet door de behandelaar geëscaleerd, nadat de beschikbare doorlooptijd was verstreken.

0200 Achterhalen oorzaak tijdsoverschrijdingen Degene die het incident, waarvan de toegestane doorlooptijd verstreken is, in behandeling heeft wordt hierop aangesproken. Nagegaan wordt wat de oorzaak van de tijdsoverschrijding is.

0300 Overschrijding afgesproken of terecht? In een aantal gevallen kan het voorkomen dat de behandelaar zijn call vergeten is of zijn call vergeten is bij te werken. Dit wordt ter verbetering aan de behandelaar gemeld. -

Indien in overleg met de gebruiker is afgesproken dat de behandelaar meer tijd dan toegestaan mag gebruiken ter oplossing, maar vergeten is zijn call bij te werken. Vanwege bijv. grote drukte heeft de behandelaar nog geen tijd gehad of is hij vergeten na tijdsoverschrijding zijn call te escaleren.

Zo ja, ga naar “einde”. Zo nee, ga naar 0400.

0400 Functionele of hiërarchische escalatie Al naar gelang de oorzaak van de tijdsoverschrijding vindt functionele of hiërarchische escalatie plaats. In de meeste gevallen gebeurt dit conform activiteiten afhandelen meldingen Front Office en Back Office. In een aantal gevallen kan de duur van de tijdsoverschrijding of de oorzaak zodanig zijn dat specifieke functionele of hiërarchische escalatie nodig is of dat maatregelen moeten worden genomen. De aanmelder van het incident wordt hierover geïnformeerd.

0500 Beoordelen en maatregelen nemen De call wordt in specifieke gevallen geëscaleerd naar de persoon met de juiste bevoegdheden. De duur van de tijdsoverschrijding en de oorzaken worden beoordeeld. Aan de hand van deze beoordeling kunnen maatregelen worden genomen, bijvoorbeeld: - Toewijzen middelen - Toewijzen capaciteit - Toewijzen budget - Toewijzen benodigde bevoegdheden.

15

Auteur: Jurjen Bloo

17-02-2009


Versie 1.0

Leones


16

Auteur: Jurjen Bloo

17-02-2009


Versie 1.0

Inhoudsopgave 1.

ALGEMEEN ............................................................................................................................................... 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7

2.

PROCEDURE AANNEMEN & REGISTREREN MELDING ................................................................................ 3 2.1 2.2 2.3 2.4 2.5

3.

DOEL ...................................................................................................................................................... 11 AANLEIDING ............................................................................................................................................. 11 RESULTAAT............................................................................................................................................... 11 BESCHRIJVING ........................................................................................................................................... 12 VERANTWOORDELIJKHEDEN ......................................................................................................................... 13

PROCEDURE AFSLUITEN INCIDENTEN ..................................................................................................... 14 6.1 6.2 6.3 6.4 6.5

7.

DOEL ........................................................................................................................................................ 9 AANLEIDING ............................................................................................................................................... 9 RESULTAAT................................................................................................................................................. 9 BESCHRIJVING ............................................................................................................................................. 9 VERANTWOORDELIJKHEDEN ......................................................................................................................... 10

PROCEDURE AFHANDELEN INCIDENTEN BACK OFFICE ............................................................................ 11 5.1 5.2 5.3 5.4 5.5

6.

DOEL ........................................................................................................................................................ 7 AANLEIDING ............................................................................................................................................... 7 RESULTAAT................................................................................................................................................. 7 BESCHRIJVING ............................................................................................................................................. 7 Verantwoordelijkheden ...................................................................................................................... 8

PROCEDURE AFHANDELEN INCIDENTEN FRONT OFFICE ............................................................................ 9 4.1 4.2 4.3 4.4 4.5

5.

DOEL ........................................................................................................................................................ 3 AANLEIDING ............................................................................................................................................... 3 RESULTAAT................................................................................................................................................. 3 BESCHRIJVING ............................................................................................................................................. 4 VERANTWOORDELIJKHEDEN ........................................................................................................................... 6

PROCEDURE CLASSIFICEREN INCIDENT ..................................................................................................... 7 3.1 3.2 3.3 3.4 3.4.1

4.

INLEIDING .................................................................................................................................................. 1 DOEL PROCES.............................................................................................................................................. 1 BEREIK PROCES............................................................................................................................................ 1 INPUT PROCES ............................................................................................................................................. 1 ACTIVITEITEN PROCES ................................................................................................................................... 1 OUTPUT PROCES.......................................................................................................................................... 2 RELATIES MET ANDERE PROCESSEN .................................................................................................................. 2

DOEL ...................................................................................................................................................... 14 AANLEIDING ............................................................................................................................................. 14 RESULTAAT............................................................................................................................................... 14 BESCHRIJVING ........................................................................................................................................... 14 VERANTWOORDELIJKHEDEN ......................................................................................................................... 14

PROCEDURE VOORTGANGSBEWAKING INCIDENT MANAGEMENT ......................................................... 15 7.1 7.2 7.3 7.4 7.5

DOEL ...................................................................................................................................................... 15 AANLEIDING ............................................................................................................................................. 15 RESULTAAT............................................................................................................................................... 15 BESCHRIJVING ........................................................................................................................................... 16 VERANTWOORDELIJKHEDEN ......................................................................................................................... 17 17

Auteur: Jurjen Bloo

17-02-2009


Versie 1.0

8.

BIJLAGE I: REQUEST FOR CHANGE FORMULIER ....................................................................................... 18

9.

BIJLAGE II: UITLEG RACI .......................................................................................................................... 20

18

Auteur: Jurjen Bloo

1.

Algemeen

1.1

Inleiding

Een incident is een afwijking van het afgesproken of verwachte kwaliteitsniveau van de ITdienstverlening. De Servicedesk is verantwoordelijk voor het ontvangen, registeren en afhandelen van incidenten.

1.2

Doel proces

Dit proces heeft tot doel zorg te dragen voor continuïteit in de dienstverlening door het zo spoedig mogelijk herstellen van het afgesproken dienstenniveau wanneer een afwijking hierop wordt geconstateerd en het verzamelen en registreren van informatie ten behoeve van mogelijke verdere analyse.

1.3

Bereik proces

De volgende organisatorische eenheden kunnen inhoudelijk met het proces Incidentbeheer te maken krijgen: - Servicedesk (eerste lijn) - Systeem- en netwerkbeheer (tweede lijn) - Onderhoud en beheer informatiesystemen (tweede lijn) - Applicatiebeheer (tweede lijn) - Ontwikkelafdeling - Klant

1.4

Input proces

Dit proces heeft de volgende input: - Incident - Standaardwijziging - Exploitatieopdracht - Foutmeldingen van systemen.

1.5

Activiteiten proces

De activiteiten van dit proces zijn als volgt: - Detective en registratie - Classificatie en toewijzing - Diagnose en oplossing - Afsluiting - Rapportage. Deze activiteiten worden in de volgende hoofdstukken nader uitgewerkt.

11-02-2009

1.6

Processbeschrijving Change Management

Versie 1.0

Output proces

Dit proces heeft de volgende output: - Terugkoppeling over aangemelde incidenten

1.7



Configuration Management: De Configuration Management Database(CMDB) spelt een belangrijke rol voor Incident Management omdat relaties tussen productiemiddelen, diensten, gebruikers en Service Levels daarin terug te vinden zijn, waardoor een betere impact inschatting gemaakt kan worden. Verder geeft Configuration Management een inzicht in wie er voor een onderdeel van de infrastructuur verantwoordelijk is zodat incidenten effectiever gerouteerd. Tijdens de incident registratie worden configuratiegegevens gekoppeld aan het incidentrecord zodat het een beter beeld geeft van de storing. Eventueel kan de status van de betrokken componenten in de Configuratie Management Database worden bijgewerkt.

-

Problem Management: Problem Management stelt eisen aan de kwaliteit van de incidentregistratie om te kunnen zoeken naar mogelijke structurele fouten. Problem Managemetn helpt het Incident Management door informatie beschikbaar te stellen over Problems, Known Errors, Workarounds en Quick Fixes.

-

Change Management: Incidenten worden soms opgelost door het uitvoeren van standard-changes zoals bij het vervangen van een beeldscherm. Change Management stelt hiervoor een lijst van standaard changes, met de bijhorende procedures en/of werkinstructies, aan Incident Management ter beschikking. Verder levert Change Management ten behoeve van Incident Management inforamtei op over geplande Changes en de status daarvan. Daarnaast kunnnen Changes ook Incidenten veroorzaken als ze niet goed uitgevoerd

-

Service Level Management: Service Level Management bewaakt de afspraken met klanten over de te leveren ondersteuning. Incident Management moet van de Service Level Agreement(SLA) op de hoogte zijn, zodat deze informatie kan worden gebruikt in de contacten met de gebruikers. Uit de incident registratie kunnen rapportages worden gemaakt om te beoordelen of de diensten volgens afspraak is geleverd.

-

Dienstenniveaubeheer: Dienstenniveaubeheer maakt afspraken met klanten over het te leveren niveau van dienstverlening. De Servicedesk moet van deze overeenkomsten op de hoogte zijn, zodat deze informatie gebruikt kan worden bij het aannemen en oplossen van incidenten.

2

Auteur: Jurjen Bloo

11-02-2009


2.

Procedure aannemen & registreren melding

2.1

Doel

Versie 1.0

Het doel van deze procedure is het juist aannemen en registreren van meldingen die gemeld worden door de klanten van Leones.

2.2

Aanleiding

De aanleiding van deze procedure is een nieuw binnengekomen melding van een klant van Leones.

2.3

Resultaat

Na uitvoering is de melding op de juiste manier geregistreerd.

3

Auteur: Jurjen Bloo

11-02-2009

2.4


Versie 1.0

Beschrijving

Aannemen telefoon

Opzoeken klant in CMDB

Opzoeken Object-ID

Controleren Object-ID

Is het een incident?

Nee

Change Mangement

Ja

Registreren incident

4

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

Wanneer een melding wordt aangemeld bij de Servicedesk zal de klant en de daarbij horende ObjectID opgezocht worden in de CMDB. Tijdens het zoeken in de CMDB wordt meteen geverifieerd of de gegevens van de Object-ID kloppen. De volgende gegevens worden voor wat betreft verificatie, door de servicedesk aan de klant gevraagd: - Object ID - Locatiecode - Afdeling/Groep Dit zorgt voor een continue verificatie van de CMDB. Dit zal uiteindelijk de betrouwbaarheid van de CMDB vergroten. Meldingen komen in twee categorieën binnen. Er moet bepaald gaan worden onder welke categorie een melding valt. De categorieën van de meldingen zijn: - Incidenten – eigenlijk alle meldingen behalve changes: o Storingsmeldingen: de echte incidenten en de klachten over de dienstverlening o Service Requests: eenmalige opdrachten, zoals batch-jobs, restores, passwords/autorisaties, queries, verzoeken om handleidingen en kleine attributen zoals muizen, en vragen over bijvoorbeeld functionaliteit of naar de status van een incident. - Changes – in de meeste gevallen standaard Requests for Change (RfC’s). o Standaard RfC’s: eenvoudige standaardinstallaties en standaardbestellingen van werkstation, randapparatuur en locale applicaties. De servicedesk kan ook belast zijn met het verhuizen van apparatuur. o RfC’s: Het maken van wijzigen binnen de bestaande ICT-diensten. Het maken van wijzigingen binnen de infrastructuur, nieuwe server(s), aanpassen van softwarecode, etc. Als het gaat om een change, dan zal er door de Servicedesk medewerker een RfC(zie Bijlage I) naar de klant gestuurd worden. Deze zal vervolgens ingevuld, doorgestuurd worden naar de Change Manager. Betreft het een incident dan worden de volgende activiteiten uitgevoerd: - Incidentnummer toekennen - Basisgegevens vastleggen o Tijdstip o Symptomen o Klant o Object-ID o Behandelaar - Incidentgegevens aanvullen o Relaties met CMDB o Known Errors - Waarschuwen o Bij incidenten met een hoge impact, zoals bij het uitvallen van een belangrijke server, dan kunnen de overige gebruikers en de beheerafdeling worden gewaarschuwd.

5

Auteur: Jurjen Bloo

11-02-2009

2.5 Activiteiten


Versie 1.0

Verantwoordelijkheden Servicedesk medewerker I R

Melden melding Aannemen melding Controleren R gegevens CMDB Bepalen of het R gaat om een incident of change Registreren R incident Voor uitleg van RACI, zie bijlage II.

Servicedesk coördinator

Change Manager

Klant R

A AC AC

AC

6

I I

I

I

Auteur: Jurjen Bloo

11-02-2009


3.

Procedure Classificeren Incident

3.1

Doel

Versie 1.0

Incidentclassificatie heeft tot doel een incident in te delen zodat het beter kan worden bewaakt.

3.2

Aanleiding

De aanleiding van deze procedure is prioriteit aan de incidenten te koppelen.

3.3

Resultaat

Na uitvoering van deze procedure is bekend onder welke categorie en wat de prioriteit is van de desbetreffende incident.

3.4

Beschrijving

Bepaal Category

Bepaal prioriteit

Classificatie incident

Incidenten worden allereerst onderverdeeld in een categorie. De categorieën zijn:

-

Autorisatie – aanmaken gebruikers, rechten gebruikers wijzigen Netwerk – router, switch, server Werkstation – beeldscherm, pc, notebook Software – softwareproducten van Leones Service Request – een verzoek van de gebruiker aan de Servicedesk om ondersteuning, informative, advies

Met de categorie wordt aangegeven met welk onderdeel er een probleem is. Tevens is duidelijk naar welke expertiseteam de incident gestuurd kan worden mocht de Servicedesk er niet uitkomen. Vervolgens wordt een prioriteit toegekend. Wanneer meerdere incidenten tegelijk in behandeling zijn, moeten er gekeken worden naar de incidenten met de meeste prioriteit. De Servicedesk zal in overleg met de klant, en volgens de afspraken in de SLA, een prioriteit toekennen.

7

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

Voor de klant heeft het eigen incident altijd de hoogste prioriteit. Om tot een objectieve inschatting te komen wordt met de klant overleg gepleegd over onderstaande criteria:

-

De impact van een incident – de mate van afwijking van het normale service level De urgentie van een incident – de mate van uitstel die de klant kan dulden.

Aan de hand van het onderstaande tabel kan de hersteltijd van de incident bepaald worden.

Impact Prioriteit

Hoog

Middel

Laag

Hersteltijd

Urgentie

Kritiek

Hoog

Middel

Hoog < 1 uur

< 8 uur

< 24 uur

Middel

Hoog

Laag

Middel < 8 uur Middel

< 48 uur

< 24 uur Laag

Planning

Laag < 24 uur

inplannen

< 48 uur

Dit samen zorgt ervoor dat de incident is geclassificeerd.

3.4.1

Verantwoordelijkheden

Activiteiten Bepaal Categorie Bepaal Prioriteit Classificeren incident

Servicedesk medewerker R R R

Servicedesk coördinator AC AC AC

8

Klant

I

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

4.

Procedure afhandelen incidenten Front Office

4.1

Doel

Het doel van deze procedure is het afhandelen van de incidenten.

4.2

Aanleiding

Aanleiding van deze procedure is het afhandelen van incidenten.

4.3

Resultaat

Het oplossen van incidenten.

4.4

Beschrijving Afhandeling mogelijk door Servicedesk? Nee Ja



Nee

Nee

Toewijzen/escaleren incident aan/naar Back Office

Ja


Acceptatie oplossing door gebruiker?

9

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

De Servicedesk medewerker zal beginnen met kijken of de incident opgelost kan worden door Servicedesk. Zo niet zal de incident toegewezen worden naar iemand van de Back Office die zich bezig houdt met de categorie van de incident. Kan de Servicedesk medewerker het incident zelf oplossen dan zal deze beginnen met het opstellen van een diagnose en zal bezig gaan met het zoeken naar een oplossing. Gebeurt dit niet binnen de afgesproken tijd dan spreken we van een escalatie. Escalaties worden onderscheiden naar functionele en hiërarchische escalaties: - Functionele escalatie – bij een functionele escalatie is sprake van inschakeling van meer specialisme in het oplostrjaect. - Hiërarchische escalatie – bij een hiërarchische escaltie wordt een verticaal beroep gedaan op hogere lagen van de organisatie omdat de huidige autoriteit onvoldoende is. Als er sprake is van een escalatie zal dit doorgecommuniceerd worden naar de klant.

4.5


Activiteiten Afhandelen door Servicedesk mogelijk? Toewijzen incident Diagnose stellen en oplossing zoeken Afhandeling mogelijk binnen vastgestelde tijdslimiet Escaleren incident naar Back Office Herstellen dienstverlening Acceptatie oplossing

Servicedesk medewerker R

Servicedesk coördinator AC

R

AC

R

AC

R

AC

R

AC

R

AC

I

AC

10

Klant

I

R

Auteur: Jurjen Bloo

11-02-2009


5.

Procedure afhandelen incidenten Back Office

5.1

Doel

Versie 1.0

Het doel van deze procedure is het afhandelen van toegewezen/geëscaleerde incidenten.

5.2

Aanleiding

De aanleiding voor deze procedure is dat de incidenten een specialisme vereisen.

5.3

Resultaat

Het verhelpen van de incidenten.

11

Auteur: Jurjen Bloo

11-02-2009

5.4


Versie 1.0

Beschrijving Aannemen toegewezen/ geescaleerd incident


Nee

Afhandeling mogelijk door applicatie-/ systeembeheer

Nee

Ja

Ja



Uitbesteden/escaleren aan/ naar externe leverancier of maatregelen nemen

Ja


Terugkoppeling incident naar de Servicedesk

12

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

Het incident wordt toegewezen aan het juiste expertiseteam. Binnen dit expertiseteam zitten specialisten op dat gebied waar de incident over gaat. Er zal gekeken worden of het oplossen van de incident mogelijk is door het expertiseteam of dat er contact gezocht moet worden met de externe leverancier. Ook hier geld een hersteltijd. Is het niet mogelijk om het binnen de tijd op te lossen zal het geëscaleerd worden naar de externe leverancier. Nadat de dienst hersteld is wordt het incident teruggekoppeld naar de Servicedesk

5.5


Activiteiten Toewijzen incident Controle of het mogelijk is om zelf de incident op te lossen Uitbesteden/escaleren aan/naar externe leverancier of maatregelen nemen Diagnose stellen en oplossing zoeken Herstellen incident Terugkoppeling incident naar de Servicedesk

Servicedesk medewerker R

Expertiseteam

I

13

Klant

I R

Servicedesk coördinator AC AC

R

AC

I

R

AC

R R

AC AC

Auteur: Jurjen Bloo

11-02-2009


6.

Procedure afsluiten incidenten

6.1

Doel

Versie 1.0

Het doel van deze procedure is het juist afsluiten van de incidenten.

6.2

Aanleiding

De incident is hersteld en is klaar om afgesloten te worden.

6.3

Resultaat

Het resultaat zal zijn een goedgekeurde en afgesloten incident.

6.4

Beschrijving Acceptatie oplossing door gebruiker?

Ja

Afsluiten en coderen incident

Als de incident terug is gekoppeld door de Back Office zal de Front Office contact zoeken met de klant. De klant zal aangeven als deze akkoord gaat met de oplossing. Indien de klant niet akkoord gaat zal het proces opnieuw beginnen. Bij goedkeuring kan de incident afgesloten worden.

6.5


Activiteiten Acceptatie oplossing Afsluiten en coderen incident

Servicedesk medewerker I R

Servicedesk coördinator AC AC

14

Klant R

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

7.

Procedure voortgangsbewaking Incident Management

7.1

Doel

Het doel van deze procedure is het bewaken van alle openstaande incidenten, zodat maatregelen kunnen worden genomen als het oplossingstraject niet volgens de afspraken dreigt te verlopen.

7.2

Aanleiding

De aanleiding van deze procedure is het voorkomen dat incidenten afwijken van het oplossingstraject.

7.3

Resultaat

De incidenten zullen volgens het oplossingstraject opgelost worden.

15

Auteur: Jurjen Bloo

11-02-2009

7.4


Versie 1.0

Beschrijving

Verzamelen tijdsoverschrijdingen Front Office en Back Office

Achterhalen oorzaak tijdsoverschrijdingen

Overschrijding afgesproken of terecht?

Nee

Functionele of hierarchische escalatie

Beoordelen en maatregelen nemen

Regelmatig zal er door de Servicedesk coördinator gegevens worden verzameld over de tijdsoverschrijdingen van de Front en Back Office. Er zal per incident gekeken worden wat de reden hiervan is en wat er gedaan moet worden om dit in het vervolg te verhelpen. Vervolgens zal de juiste escalatie gekozen worden(zie procedure afhandelen Front Office). De Service coördinator zal dan kijken of er maatregelen getroffen moeten worden om dit te verbeteren.

16

Auteur: Jurjen Bloo

11-02-2009

7.5


Versie 1.0


Activiteiten Verzamelen tijdsoverschrijdingen Front en Back Office Achterhalen oorzaak tijdsoverschrijdingen Beoordelen en maatregelen nemen

Servicedesk medewerker

Servicedesk coördinator R

R R

17

Auteur: Jurjen Bloo

11-02-2009

8.


Versie 1.0

Bijlage I: Request for Change formulier

Hieronder ziet u een voorbeeld van een Request for Change formulier. Dit formulier is aan te passen door de Change Management.

Request for Change Datum ontvangst Change Manager: Change nummer:

SECTIE A – In te vullen door aanvrager Datum van indiening: Ingediend door: Organisatie: E-mail: Telefoon: Change omschrijving:

Reden van Change:

SECTIE B – In te vullen door Change Manager Proces: Filteren Change(s) Change Categorie ______ Change Prioriteit ___ Route bepaald Feasibility Study Risico Analyse Bouwen Change Testen Implementeren

Status: Change Goedgekeurd Change Doorgevoerd Change Afgewezen Change Teruggetrokken door indiener Doelstelling datum doorvoering

_____._____._____ _____._____._____ _____._____._____

Reden van afwijzing: Behandeld door:________________ Reactie indiener:

18

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

Goedkeuring: Indiener: Change Manager:

Datum:________________ Datum:________________

19

Auteur: Jurjen Bloo

11-02-2009

9.


Versie 1.0

Bijlage II: Uitleg RACI

R = Responsible: De persoon/functie die een bepaalde taak moet uitvoeren. De mate van verantwoordelijkheid is gedefinieerd door de persoon die Accountable is (zie definitie hiervoor). Meerdere personen kunnen responsible (uitvoerend) zijn. A = Accountable: De persoon/functie die het vetorecht heeft, die aangesproken zal worden als zaken niet goed verlopen, die dus aansprakelijk is voor de uitvoering van de werkzaamheden, op de juiste manier, met het juiste resultaat, binnen de beschikbare tijd, met gebruik van de juiste middelen. De persoon die accountable is heeft binnen zijn of haar verantwoordingsgebied en de daarvoor geldende randvoorwaarden (geformuleerd door het hogere hiërarchische niveau) de laatste beslissing. Voor elke (hoofd)activiteit is er maar één persoon accountable. C = Consulted: De persoon/functie die verantwoordelijk is voor het verstrekken van de benodigde informatie of advies voordat de activiteit wordt uitgevoerd of een beslissing wordt genomen. Dit kan variëren van simpele informatieverstrekking tot een vetorecht. Deze persoon moet altijd, hoe dan ook, worden geraadpleegd. I = Informed: De persoon/functie die altijd moet worden geïnformeerd nadat een beslissing is genomen of een actie of taak is uitgevoerd.

20

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

Leones

Procesbeschrijving Change Management

21

Auteur: Jurjen Bloo

11-02-2009


Versie 1.0

Inhoudsopgave 1.

ALGEMEEN ............................................................................................................................................... 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7

2.

INLEIDING .................................................................................................................................................. 1 DOEL PROCES.............................................................................................................................................. 1 SCOPE CHANGE MANAGEMENT...................................................................................................................... 1 INPUT PROCES ............................................................................................................................................. 1 ACTIVITEITEN PROCES ................................................................................................................................... 1 OUTPUT PROCES.......................................................................................................................................... 2 RELATIES MET ANDERE PROCESSEN .................................................................................................................. 2

AFHANDELEN CHANGES............................................................................................................................ 3 2.1 2.2 2.3 2.4

DOEL ........................................................................................................................................................ 3 TOEPASSINGSGEBIED .................................................................................................................................... 3 STROOMSCHEMA......................................................................................................................................... 4 INHOUD STROOMSCHEMA ............................................................................................................................. 7

22

Auteur: Jurjen Bloo

1.

Algemeen

1.1

Inleiding

Change Management richt zich op het onder controle krijgen van het proces van wijzigen en streeft ernaar om de aan changes gerelateerde storingen te bepreken.

1.2

Doel proces

Dit proces heeft tot doel om op gecontroleerde en efficiënte wijze doorvoeren van wijzigingen in de door Leones beheerde ICT-diensten, zonder daarbij incidenten of problemen te veroorzaken in de overeengekomen dienstverlening met de (interne) klanten van Leones.

1.3

Scope Change Management

Binnen de scope van het Change Management proces vallen: - Het registeren, monitoren, bewaken van en het rapporteren over alle wijzigingen die betrekking hebben op diensten, die Leones verleent aan haar klanten. Buiten de scope van het Change Management proces vallen: - Procesaanpassingen als gevolg van implementatie van het Change Management process op de andere service management of bedrijfsprocessen of specifieke afdeling/product handboeken en procedures; - Technische specificaties van de procesondersteunende hulpmiddelen; - Werkdocumenten en gedetailleerde werkinstructies. Dit is de verantwoordelijkheid van de lijnmanagers.

1.4

Input proces

Dit proces heeft de volgende input: - RfC’s; - CMDB-informatie; - Informatie uit andere processen (budget-informatie, etc)

1.5

Activiteiten proces

De activiteiten van dit proces zijn als volgt: - Registratie - Acceptatie - Classificatie - Planning - Coördinatie - Evaluatie Deze activiteiten (met uitzonder van rapportage) worden in de volgende hoofdstukken nader uitgewerkt.

16-02-2009

1.6

Procedures Configuration Management

Versie 1.0

Output proces

Dit proces heeft de volgende output: - Triggers voor Configuration Management en Release Management; - CAB-agenda, -notuleren en actielijsten; - Change Management rapportages; - Change Planning(Forward Schedule of Change: FSC)

1.7



Incident Management: Uit het doorvoeren van changes komen ondanks veel voorzorgsmaatregelen toch regelmatig incidenten voort. Deze kunnen te maken hebben met een gebrekkige implementatie waarbij fouten zijn gemaakt of met gebruikers die niet geod waren voorbereid op de change. Het is van belang dat de betrokkenen in Incident Managemetn geïnformeerd zijn over het moment van implementeren van een change, zodat zij de daaruit voortkomende incidenten snel kunnen traceren en verhelpen

-

Configuration Management: Omdat Change Managemetn verantwoordelijk is voor het autoriseren van wijzigingen in de ITinfrastructuur en Configuration Management verantwoordelijk is voor het bewaken van de status van de infrastructuur, zijn de twee processen zeer geschikt om met elkaar te worden geïntegreerd. De OGC geeft daar zelfs de voorkeur aan. Het registeren van changes vindt plaats onder de controle van Configuration Management en ook de impactanalyse van changes wordt gedaan met behulp van Configuration Management. Configuration Management laat de relaties van een CI tot andere CI’s zien, waardoor duidelijk wordt wie en wat er bij de change is betrokken.

-

Problem Management: Changes worden vaak aangevraagd als oplossing voor problems. Wanneer deze en andere oplossingen niet goed gecontroleerd worden doorgevoerd, dan kunnen zij nieuwe incidenten en daarmee mogelijk ook problems veroorzaken. Het is van belang dat er een goede verbinding ligt tussen de problem-database en de change-database.

-

Release Management: Changes resulteren vaak in de ontwikkeling en distributie van een nieuw, samengesteld pakket programma’s. Release Management heeft daarin een uitvoerende taak. De uitrol van nieuwe programmaversies vindt plaats onder de controle van Change Management.

-

Service Level Management: Service Level Management is betrokken bij het bepalen van de impcakt van changes. Afhankelijk van de situatie kan Service Level Management vertegenwoordigd zijn in de CAB. Bij changes met een hoge impact of met een hoog risico zal altijd met de klant moeten worden overlegd over de invoering en de doorlooptijd. Change Management rapporteert aan Service Level Managemetn in de vorm van een Projected Service Availability (PSA) rapport. Hierin geeft Change Management een overzicht van aanpassingen op afgesproken SLA’s en de gevolgen van de Forward Schedule of Changes (FSC) voor de beschikbaarheid van diensten.

2

Auteur: Jurjen Bloo

16-02-2009


2.

Afhandelen Changes

2.1

Doel

Versie 1.0

Het doel van deze activiteit is het zeker te stellen dat gestandaardiseerde methoden en procedures gebruikt worden, zodat changes conform afspraken kunnen worden afgehandeld. Hierdoor wordt het beoogde doel van de changes bereikt en de kans op kwaliteitsvermindering in de dienstverlening door optredende incidenten geminimaliseerd.

2.2

Toepassingsgebied

Deze procedure is van toepassing op de ICT-afdeling en is geldig vanaf het moment van aanmelding van een change tot het moment dat de change is geëvalueerd en afgesloten. De Change Management is voor de gehele procedure verantwoordelijk.

3

Auteur: Jurjen Bloo

16-02-2009

2.3 A


Versie 1.0

Stroomschema Begin

0100

Indienen RfC’s; Registeren

0200

Afgekeurd Evt. Nieuwe RfC

Accepteren; Filteren van RfC’s

0300

Classificeren; Categorie & Prioriteit

0400 Urgent?

Ja

B

Nee 0500 Evt. opnieuw

Plannen; Impact & Resources

0600 0610 Bouwen

0620 Testen

0630 Implementeren

0640 Werkt het?

C

0700

Evalueren & Afsluiten

4

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

B 0800

Change Management overlegt met CAB

0900

CAB beoordeelt impact, resources en urgentie

1000 A

Nee

Urgent?

Ja

1100

Change bouwen

1200 Tijd om te testen?

Ja

1300

Nee

Urgente test

Nee 1400 Succes?

Ja

1500

Implementeren

1600 Werkt het?

Ja

Nee

C

1700

Administratie bijwerken

Sluit RfC

5

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

C 1800

Uitvoeren Fallback

Nee 1900 Testen succesvol?

Ja

2000

Trigger Update relatie in CMDB

2010

Update CMDB

2100

Informeren & Afsluiten

Fallback uitgevoerd

6

Auteur: Jurjen Bloo

16-02-2009

2.4


Versie 1.0

Inhoud stroomschema

0100 Indienen RfC’s; Registeren Alle RfC’s behoren eerst te worden geregistreerd. De registratie moet voldoen aan de eisen die Change Management heeft gesteld t.a.v. de wijze waarop een wijzigingsverzoek kan worden ingediend en welke informatie daarbij minimaal moet worden versterkt. Als de RfC aangevraagd is voor de oplossing van een problem, dan moet het nummer van de Known Error ook worden vastgelegd.

0200 Accepteren; Filteren van RfC’s Na de registratie zal Change Management een globale controle uitoefenen om te zien of er RfC’s bij zitten die onlogisch, onwerkbaar of onnodig zijn. Dergelijke aanvragen worden afgewezen met opgaaf van redenen. De indiener van de aanvraag behoort altijd gelegenheid te krijgen zijn aanvraag alsnog te verdedigen.

0300 Classificeren; Categorie & Prioriteit Aan een RfC die is geaccepteerd word een categorie en prioriteit. De categorie wordt door Change Management bepaald op basis van impact en resources. Deze classificatie bepaalt hoe de aanvraag verder wordt behandeld. Net als bij incidenten en problems is de prioriteit afgeleid van de urgentie en impact en wordt aangeduid met een code.

0400 Urgent? Is de changes urgens? Zo ja, ga naar 0800. Zo nee, ga naar 500.

0500 Plannen; Impact & Resources De planning van de changes wordt door Change Management in een Forward Schedule of of Changes(FSC) gezet. Hierin staan de details van alle goedgekeurde changes en hun planning. Om goed te kunnen plannen onderhoudt Change Management contacten met projectgroepen van bouwactiviteiten.

0600 Coördineren Goedgekeurde changes worden doorgegeven aan de betrokken productspecialisten voor de bouw en samenstelling van de changes. Voordat zij kunnen worden doorgevoerd, worden de changes eerst getest. Change Management speelt een coördinerende rol.

0610 Bouwen Niet alle changes kennen een expliciete bouwfase. Zo zullen gestandaardiseerde changes(bijvoorbeeld de verhuizing van een PC) direct kunnen worden ingepland en uitgevoerd. Het bouwen kan inhouden dat er een nieuwe softwareversie komt, met nieuwe documentatie, handleidingen, installatieprocedures, inclusief een fallback-plan en aanpassing op de hardware.

0620 Testen Zowel de change als de fallback-procedure en de invoermethode van de change dienen gronding te worden getest. Daarbij moet worden getest. Daarbij moet worden gelet op de criteria die eerder al in de CAB zijn bepaald.

7

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

0630 Implementeren Iedereen die vanuit de betrokken afdeling het beheer van de IT-infrastructuur onder zijn verantwoording heeft, kan worden belast met het implementeren van een change op die infrastructuur. Change Management ziet erop toe dat de change op schema ligt.

0640 Werkt het? Werkt de change? Zo ja, ga dan naar 0700. Zo nee, ga dan naar 1800.

0700 Evalueren & Afsluiten Elke change wordt na verloop van tijd geëvalueerd. Tijdens de evaluatie wordt het doel van de change, de resultaten, de kosten en de tevredenheid van de gebruikers gemeten. Als alles naar tevredenheid is verlopen, kan de RfC worden afgesloten. Als de change geen succes is, zal een nieuwe RfC nodig zijn om het beoogde resultaat alsnog te bereiken.

0800 Change Management overlegt met CAB Om te voorkomen dat de Change Management de controle over het proces gaat verliezen zal, als de tijd het toelaat, er een noodvergadering van de CAB plaatsvinden.

0900 CAB beoordeelt impact, resources en urgentie In de noodvergadering wordt de impact, resources en urgentie besproken. Hier zal bekeken worden of de change urgent is of niet en wordt de juiste autorisatie toegekend.

1000 Urgent? Is de Change urgens? Zo ja, ga dan naar 1100. Zo nee, ga dan naar 0100.

1100 Change bouwen Het bouwen kan inhouden dat er een nieuwe softwareversie komt, met nieuwe documentatie, handleidingen, installatieprocedures, inclusief een fallback-plan en aanpassing op de hardware.

1200 Tijd om te testen? Is er tijd om te testen? Zo ja, ga dan naar 1300. Zo nee, ga dan naar 1500.

1300 Urgente test De Change Manager zal de risico’s moeten afzetten tegen de urgentie. Na afloop moet altijd alle oorspronkelijke stappen alsnog worden doorlopen en worden de overgeslagen testen alsnog uitgevoerd.

1400 Succes? Is het testen succesvol? Zo ja, ga dan naar 1500. Zo nee, ga dan naar 1100.

1500 Implementeren Iedereen die vanuit de betrokken afdeling het beheer van de IT-infrastructuur onder zijn verantwoording heeft, kan worden belast met het implementeren van een change op die infrastructuur. Change Management ziet erop toe dat de change op schema ligt.

1600 Werkt het? Werkt de change? Zo ja, ga dan naar 1700. Zo nee, ga dan naar 1800.

8

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

1700 Administratie bijwerken Change-administratie en CMDB kunnen ook achteraf worden bijgewerkt, ze mogen nooit worden overgeslagen.

1800 Uitvoeren Fallback Als een change moet worden teruggedraaid, mag nooit verder terug worden gegaan dan de vorige versie, de Previous Trusted State.

1900 Testen succesvol? Is het testen van de teruggedraaide change succesvol? Zo ja, ga naar 2000. Zo nee, ga naar 1800.

2000 Trigger Update relatie in CMDB Het bijwerken van de CMDB.

2010 Update CMDB Het bijwerken van de CMDB.

2100 Informeren & Afsluiten Het informeren van de betrokken partijen dat de Fallback is uitgevoerd.

9

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Leones

Procedures Change Management

10

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Inhoudsopgave 1.

ALGEMEEN ................................................................................................................................................... 13 1.1 1.2 1.3 1.4 1.5 1.6 1.7

2.

PROCEDURE ACCEPTEREN: FILTEREN VAN RFC’S ........................................................................................... 15 2.1 2.2 2.3 2.4 2.5

3.

DOEL ........................................................................................................................................................... 23 AANLEIDING .................................................................................................................................................. 23 RESULTAAT.................................................................................................................................................... 23 BESCHRIJVING ................................................................................................................................................ 24 VERANTWOORDELIJKHEDEN .............................................................................................................................. 25

PROCEDURE FALLBACK ................................................................................................................................. 26 6.1 6.2 6.3 6.4 6.5

7.


PROCEDURE URGENTE CHANGE ................................................................................................................... 23 5.1 5.2 5.3 5.4 5.5

6.


PROCEDURE COÖRDINEREN ......................................................................................................................... 20 4.1 4.2 4.3 4.4 4.5

5.


PROCEDURE CLASSIFICEREN: CATEGORIE & PRIORITEIT ............................................................................... 17 3.1 3.2 3.3 3.4 3.5

4.

INLEIDING ..................................................................................................................................................... 13 DOEL PROCES................................................................................................................................................. 13 SCOPE CHANGE MANAGEMENT......................................................................................................................... 13 INPUT PROCES ................................................................................................................................................ 13 ACTIVITEITEN PROCES ...................................................................................................................................... 13 OUTPUT PROCES............................................................................................................................................. 14 RELATIES MET ANDERE PROCESSEN ..................................................................................................................... 14


PROCEDURE RAPPORTAGES ......................................................................................................................... 28 7.1 7.2 7.3

DOEL ........................................................................................................................................................... 28 AANLEIDING .................................................................................................................................................. 28 RESULTAAT.................................................................................................................................................... 28 11

Auteur: Jurjen Bloo

16-02-2009

7.4 7.5 8.


Versie 1.0

BESCHRIJVING ................................................................................................................................................ 28 VERANTWOORDELIJKHEDEN .............................................................................................................................. 28

BIJLAGE I: UITLEG RACI ................................................................................................................................. 29

12

Auteur: Jurjen Bloo

16-02-2009


1.

Algemeen

1.1

Inleiding

Versie 1.0

Change Management richt zich op het onder controle krijgen van het proces van wijzigen en streeft ernaar om de aan changes gerelateerde storingen te bepreken.

1.2

Doel proces

Dit proces heeft tot doel om op gecontroleerde en efficiënte wijze doorvoeren van wijzigingen in de door Leones beheerde ICT-diensten, zonder daarbij incidenten of problemen te veroorzaken in de overeengekomen dienstverlening met de (interne) klanten van Leones.

1.3

Scope Change Management

Binnen de scope van het Change Management proces vallen: - Het registeren, monitoren, bewaken van en het rapporteren over alle wijzigingen die betrekking hebben op diensten, die Leones verleent aan haar klanten. Buiten de scope van het Change Management proces vallen: - Procesaanpassingen als gevolg van implementatie van het Change Management process op de andere service management of bedrijfsprocessen of specifieke afdeling/product handboeken en procedures; - Technische specificaties van de procesondersteunende hulpmiddelen; - Werkdocumenten en gedetailleerde werkinstructies. Dit is de verantwoordelijkheid van de lijnmanagers.

1.4

Input proces

Dit proces heeft de volgende input: - RfC’s; - CMDB-informatie; - Informatie uit andere processen (budget-informatie, etc)

1.5

Activiteiten proces

De activiteiten van dit proces zijn als volgt: - Registratie - Acceptatie - Classificatie - Planning - Coördinatie - Evaluatie Deze activiteiten worden in de volgende hoofdstukken nader uitgewerkt.

13

Auteur: Jurjen Bloo

16-02-2009

1.6


Versie 1.0

Output proces

Dit proces heeft de volgende output: - Triggers voor Configuration Management en Release Management; - CAB-agenda, -notuleren en actielijsten; - Change Management rapportages; - Change Planning(Forward Schedule of Change: FSC)

1.7



Incident Management: Uit het doorvoeren van changes komen ondanks veel voorzorgsmaatregelen toch regelmatig incidenten voort. Deze kunnen te maken hebben met een gebrekkige implementatie waarbij fouten zijn gemaakt of met gebruikers die niet geod waren voorbereid op de change. Het is van belang dat de betrokkenen in Incident Managemetn geïnformeerd zijn over het moment van implementeren van een change, zodat zij de daaruit voortkomende incidenten snel kunnen traceren en verhelpen

-

Configuration Management: Omdat Change Managemetn verantwoordelijk is voor het autoriseren van wijzigingen in de ITinfrastructuur en Configuration Management verantwoordelijk is voor het bewaken van de status van de infrastructuur, zijn de twee processen zeer geschikt om met elkaar te worden geïntegreerd. De OGC geeft daar zelfs de voorkeur aan. Het registeren van changes vindt plaats onder de controle van Configuration Management en ook de impactanalyse van changes wordt gedaan met behulp van Configuration Management. Configuration Management laat de relaties van een CI tot andere CI’s zien, waardoor duidelijk wordt wie en wat er bij de change is betrokken.

-

Problem Management: Changes worden vaak aangevraagd als oplossing voor problems. Wanneer deze en andere oplossingen niet goed gecontroleerd worden doorgevoerd, dan kunnen zij nieuwe incidenten en daarmee mogelijk ook problems veroorzaken. Het is van belang dat er een goede verbinding ligt tussen de problem-database en de change-database.

-

Release Management: Changes resulteren vaak in de ontwikkeling en distributie van een nieuw, samengesteld pakket programma’s. Release Management heeft daarin een uitvoerende taak. De uitrol van nieuwe programmaversies vindt plaats onder de controle van Change Management.

-

Service Level Management: Service Level Management is betrokken bij het bepalen van de impcakt van changes. Afhankelijk van de situatie kan Service Level Management vertegenwoordigd zijn in de CAB. Bij changes met een hoge impact of met een hoog risico zal altijd met de klant moeten worden overlegd over de invoering en de doorlooptijd. Change Management rapporteert aan Service Level Managemetn in de vorm van een Projected Service Availability (PSA) rapport. Hierin geeft Change Management een overzicht van aanpassingen op afgesproken SLA’s en de gevolgen van de Forward Schedule of Changes (FSC) voor de beschikbaarheid van diensten.

14

Auteur: Jurjen Bloo

16-02-2009


2.

Procedure Accepteren: filteren van RfC’s

2.1

Doel

Versie 1.0

Het doel van deze procedure is het controleren of er RfC’s bij zitten die onlogisch, onwerkbaar of onnodig zijn.

2.2

Aanleiding

De aanleiding van deze procedure is een nieuwe registratie van een RfC

2.3

Resultaat

Na uitvoering van deze procedure zijn onlogische, onwerkbare en onnodige RfC’s weg gefilterd.

2.4

Beschrijving 0100

Indienen RfC’s registreren

0200

Accepteren: Filteren van RfC’s

RfC

0300

Aanvraag geldig?

Ja

Classificeren: Categorie & prioriteit

Nee

Informate verzamelen

Aanvrager informeren

15

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Zodra er een RfC is geregistreerd zal gekeken worden of het daadwerkelijk om een change gaat. De Change Manager zal eerst informatie verzamelen over het onderwerp. Waar gaat het over en wat moet er gebeuren. Als de Change Manager voldoende informatie heeft verzameld zal deze beslissen of de aanvraag geldig is. We spreken van een change als iets een aanpassing is binnen de huidige ICT-dienst. Denk hierbij aan een plaatsing van een router, toevoegen van een werkstation en het aanpassen van de broncode van een applicatie. Een change leidt tot aanpassing van gegevens in de CMDB, zoals bij: - Statusverandering van een bestaande CI - Een gewijzigde relatie van het CI met andere CI’s - Een nieuw CI of een variant op een bestaand CI - Een andere eigenaar of locatie voor een CI Als een aanvraag afgewezen wordt zal de aanvrager geïnformeerd worden. De aanvrager krijgt altijd de gelegenheid zijn aanvraag te verdedigen. Als een aanvraag geaccepteerd is, dan wordt de informatie voor het verdere verloop van de change opgenomen. De volgende informatie zal worden toegevoegd: - Beoordeling van impact en benodigde resources - Aanbevelingen van de Change Manager - Datum en tijd van de autorisatie - Datum van de uitvoering

2.5


Activiteiten Change Manager Informatie R verzamelen change Aanvraag geldig? R Voor uitleg van RACI, zie bijlage I.

Aanvrager Change

I

16

Auteur: Jurjen Bloo

16-02-2009


3.

Procedure Classificeren: Categorie & Prioriteit

3.1

Doel

Versie 1.0

Het doel van deze procedure is het bepalen van de categorie en het stellen van de prioriteit van de change.

3.2

Aanleiding

De aanleiding van deze procedure is een goedgekeurde change.

3.3

Resultaat

Na uitvoering van deze procedure is de change in een categorie verdeeld en er een prioriteit aan toegekend.

17

Auteur: Jurjen Bloo

16-02-2009

3.4


Versie 1.0

Beschrijving 0200

Accepteren: Filteren van RfC’s 0300

Classificeren: Categorie & prioriteit

Impact analyse

Bepaal Prioriteit

Resource analyse

Bepaal Category

0800 0400 Urgent?

Ja

Urgente procedures

Nee 0500

Plannen: Impact & Resources

18

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Na het accepteren van de RfC zal deze geclassificeerd worden. De categorie bepaald hoe de aanvraag verder zal worden behandeld en is dus een aanduiding van het gewicht van de change. De prioriteit geeft het belang van de change aan. Het OGC hanteert de volgende codes voor categorie en prioriteit: De categorie wordt door de Change Manager bepaald op basis van impact en resources. Deze classificatie bepaalt hoe de aanvraag verder wordt behandeld. De meeste changes vallen in de eerste twee categorieën. Categorie: - Lage impact: er zijn weinig resources nodig, de Change Manager kan hier zelf over beslissen of de verantwoordelijkheid delegeren naar bijvoorbeeld de Servicedesk. - Significante impact: er is een aanzienlijke hoeveelheid resources nodig. Dit wordt besproken op de volgende CAB-vergadering, nadat eerst documentatie is rondgestuurd naar specialisten en ontwikkelaars. - Grote impact: er zijn veel resources nodig. De Change Manager zal eerst autorisatie moeten vragen aan het ICT-management en daarna de change alsnog voorleggen aan de CAB. Prioriteit: - Urgent: wijzigingen die geen uistel dulden, omdat zee en probleem betreffen dat bij de gebruiker ernstige overlast veroorzaakt of een grote groep gebruikers raakt. Dit zijn de wijzigingen waarvoor een spoedvergadering van de CAB vereist kan zijn. - Hoog: een ernstig probleem dat een aantal gebruikers raakt of minder ernstig probleem dat een grote groep gebruikers raakt. Deze change krijg topprioriteit op de volgende CABvergadering - Middelmatig: een probleem zonder ernstige gevolgen, maar de wijziging mag niet worden uitgesteld tot de volgende release. Deze change krijgt een gemiddelde prioriteit bij de eerstvolgende CAB-vergadering. - Laag: de change is terecht en rechtmatig, maar kan wachten tot de volgende release.

3.5


Activiteiten Impact analyse Resources analyse Bepaal categorie Bepaal prioriteit Urgent?

Change Manager RA RA RA RA RA

19

Auteur: Jurjen Bloo

16-02-2009


4.

Procedure Coördineren

4.1

Doel

Versie 1.0

Het doel van deze procedure is het coördineren van het juist bouwen en doorvoeren van een change.

4.2

Aanleiding

Aanleiding is dat een change goed is gekeurd en dat de change opgelost kan worden.

4.3

Resultaat

Het resultaat van deze procedure is een werkende oplossing van een change.

20

Auteur: Jurjen Bloo

16-02-2009

4.4


Versie 1.0

Beschrijving 0500

Plannen: Impact & resources 0600

Coordineren: Bouwen,testen en Implementeren Nee

Nieuwe versie nodig?

Ja

Release Management

Nee

Ontwerpen

Bouwen

Testen

Testen succesvol?

Ja

Implementeren

Werkt het?

Nee

C

0700

Ja

21

Evalueren & Afsluiten

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Zodra een change juist is geclassificeerd zal er overgegaan worden tot het bouwen van de change. Er zal beslist worden of er een nieuwe release nodig is van het product. Zo ja, zal de Release Manager op de hoogte gebracht worden. Is er geen nieuwe release nodig dan zal er een team samengesteld worden om hieraan te werken. Ontwerpen De change zal eerst ontworpen worden. Dit gebeurt middels een nieuwe netwerktekeningen of het aanmaken of aanpassen van de UML schema’s die bestaan van het softwarepakket. Na goedkeuring van de Change Manament zullen de gegevens ingevoerd worden in de CMDB zodat deze up-to-date blijft. Bouwen Het bouwen kan inhouden dat er een nieuwe softwareversie komt, met nieuwe documentatie, handleidingen, installatieprocedures, etc. Change Management vervult daarbij een controlerende en coördinerende rol. Als onderdeel van de oplevering van een change zal ook een Fallback procedure moeten worden geschreven om de situatie terug te kunnen draaien als de change niet het gewenste resultaat oplevert. Change Management mag de change niet goedkeuren als er geen Fallback procedure is. Testen Zowel de change als de Fallback procedure en de invoermethode van de change dienen grondig te worden getest. Testen wordt uitgevoerd door de bouwers, degenen die de RfC hebben ingediend en een lid van een expertiseteam waar de change betrekking op heeft. Implementeren Iedereen die vanuit de betrokken afdeling in aanraking komt met de change, kan worden belas met het implementeren van de change. Change Management ziet erop toe dat de change op schema ligt en de juiste mensen op de juiste manier worden geïnformeerd over de implementatie van de change.

4.5


Activiteiten Nieuwe versie? Ontwerpen Bouwen Testen Implementeren

Klant

Ontwikkelteam

I R

R R R R

Expertiseteam

C R

22

Change Manager RA A A A A

Auteur: Jurjen Bloo

16-02-2009


5.

Procedure urgente change

5.1

Doel

Versie 1.0

Het doel van deze procedure is uitvoeren van een change die geen uitstel duld.

5.2

Aanleiding

Een aanleiding kan zijn als er zich iets voordoet wat geen uitstel kan dulden, bijvoorbeeld als de mailserver uitvalt, zal er snel gehandeld moeten worden.

5.3

Resultaat

Het resultaat van deze procedure is het snel uitvoeren van een change.

23

Auteur: Jurjen Bloo

16-02-2009

5.4


Versie 1.0

Beschrijving B 0800

Change Management overlegt met CAB

0900

CAB beoordeelt impact, resources en urgentie

1000 A

Nee

Urgent?

Ja

1100

Change bouwen

1200 Tijd om te testen?

Ja

1300

Nee

Urgente test

Nee 1400 Succes?

Ja

1500

Implementeren

1600 Werkt het?

Ja

Nee

C

1700

Administratie bijwerken

Sluit RfC

24

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Ondanks alle planningen kan het toch voorkomen dat een change onmiddellijk voorrang moet krijgen. Urgente Changes kenmerken zich door het grote en spoedeisende belang dat aan hun uitvoering wordt gekoppeld. Meestal moeten voor dergelijke changes direct resources van andere activiteiten worden vrijgemaakt. Er zal snel overleg zijn tussen de Change Manager en de CAB om zo juiste beslissingen te maken om de Urgente Change op te lossen. Door de Change Manager zullen gedurende het proces beslissingen gemaakt moeten worden omtrent mogelijke verkorting van het proces. Dit verschilt per Urgente Change. De administratie die normaal gemaakt wordt zal naderhand gemaakt worden en de CMDB zal dan upto-date gebracht worden.

5.5


Activiteiten Overleg CAB Bouwen Tijd om te testen? Urgente test Implementeren Administratie bijwerken

CAB

Ontwikkelteam

Expertiseteam

R R R R R

25

R

Change Manager RA A RA A A A

Auteur: Jurjen Bloo

16-02-2009


6.

Procedure Fallback

6.1

Doel

Versie 1.0

Het doel van deze procedure is mocht een change mis gaan zal er altijd terug worden gegaan naar de vorige versie.

6.2

Aanleiding

De aanleiding is het mislukken van het doorvoeren van een change.

6.3

Resultaat

Het resultaat is dat de changes teruggedraaid worden.

6.4

Beschrijving C 1800

Uitvoeren Fallback

Nee 1900 Testen succesvol?

Ja

2000

Trigger Update relatie in CMDB

2010

Update CMDB

2100

Informeren & Afsluiten

Fallback uitgevoerd

26

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Door de Fallback goed te laten lopen zal er gebruik worden gemaakt van de beschreven procedure tijdens het proces coördineren. Nadat de Fallback uit is gevoerd zal deze getest moeten worden. Vervolgens zal de CMDB up-to-date gebracht worden en de aanvrager van de change geïnformeerd worden.

6.5


Activiteiten Uitvoeren Fallback Testen Fallback Update CMDB Informeren

Ontwikkelteam R R R

Change Manager A A A A

27

Aanvrager change

I

Auteur: Jurjen Bloo

16-02-2009


7.

Procedure Rapportages

7.1

Doel

Versie 1.0

Het beschikbaar stellen van informatie over de verschillende changes.

7.2

Aanleiding

Het inzicht krijgen in de prestaties van het Change Management.

7.3

Resultaat

Rapportages die inzicht geven in de presentaties van Change Management

7.4

Beschrijving

Change Management zal rapporten moeten opstellen over de volgende punten: - Het aantal geïmplementeerde changes in een periode, total en per CI - Een overzicht van de oorzaken van changes en RfC’s - Het aantal met succes uitgevoerde changes - Het aantal Fallback situaties en de redenen daarvoor - Het aantal incidenten in relatie tot uitgevoerde changes

7.5


Activiteiten Inventariseren wensen rapportage Samenstellen rapportage Opleveren rapportage

Change Management RA

Managers

RA RA

I

28

Auteur: Jurjen Bloo

16-02-2009

8.


Versie 1.0

Bijlage I: Uitleg RACI


29

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Leones


30

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Inhoudsopgave 1.

ALGEMEEN ...................................................................................................................................32 1.1 1.2 1.3 1.4 1.5 1.6 1.7

2.

PROCEDURE ONTVANGST EN REGISTRATIE CI’S..................................................................34 2.1 2.2 2.3 2.4 2.5

3.

DOEL .......................................................................................................................................40 AANLEIDING ..............................................................................................................................40 RESULTAAT ..............................................................................................................................40 BESCHRIJVING ..........................................................................................................................41 VERANTWOORDELIJKHEDEN ......................................................................................................43

PROCEDURE VERIFIËREN CI’S ..................................................................................................44 5.1 5.2 5.3 5.4 5.4.1 5.4.2 5.5

6.


PROCEDURE BIJHOUDEN WIJZIGINGEN CI’S .........................................................................40 4.1 4.2 4.3 4.4 4.5

5.


PROCEDURE INSTALLATIE/AFLEVERING CI’S ........................................................................37 3.1 3.2 3.3 3.4 3.5

4.

INLEIDING .................................................................................................................................32 DOEL PROCES ..........................................................................................................................32 BEREIK PROCES ........................................................................................................................32 INPUT PROCES ..........................................................................................................................32 ACTIVITEITEN PROCES ...............................................................................................................32 OUTPUT PROCES ......................................................................................................................33 RELATIES MET ANDERE PROCESSEN...........................................................................................33

DOEL .......................................................................................................................................44 AANLEIDING ..............................................................................................................................44 RESULTAAT ..............................................................................................................................44 BESCHRIJVING ..........................................................................................................................45 Continue verificatie ...................................................................................................................... 46 Periodieke verificatie .................................................................................................................... 46 VERANTWOORDELIJKHEDEN ......................................................................................................46

PROCEDURE RAPPORTEREN .....................................................................................................47 6.1 6.2 6.3 6.4 6.5 6.6

DOEL .......................................................................................................................................47 AANLEIDING ..............................................................................................................................47 RESULTAAT ..............................................................................................................................47 BESCHRIJVING ..........................................................................................................................47 VERANTWOORDELIJKHEDEN ......................................................................................................47 INHOUD STROOMSCHEMA ......................................................... ERROR! BOOKMARK NOT DEFINED.

7.

BIJLAGE I: CMDB REGISTRATIEFORMULIER ...........................................................................48

8.

BIJLAGE II: UITLEG RACI ............................................................................................................50

31

Auteur: Jurjen Bloo

16-02-2009


1.

Algemeen

1.1

Inleiding

Versie 1.0

Configuratie Management stelt zich ten doel om betrouwbare en accurate informatie te kunnen verschaffen over de IT-diensten. De informatie bevat niet alleen details over de kenmerken van die diensten, maar ook informatie over de relaties tussen de verschillende componenten.

1.2

Doel proces

Configuration Management heeft als doel de registratie van alle relevante onderdelen van de ICTdiensten en het verschaffen van informatie daarover aan alle andere ITIL processen. Aangezien dit proces de basis vormt voor alle andere ITIL processen, staat of valt de succesvolle implementatie van ITIL met de kwaliteit van dit proces.

1.3

Bereik proces

De volgende organisatorische eenheden kunnen inhoudelijk met het proces Configuration Management te maken krijgen: - Servicedesk (eerste lijn) - Werkplekondersteuning (tweede lijn) - Systeem- en netwerkbeheer (derde lijn) - Onderhoud en beheer informatiesystemen (derde lijn) - Applicatiebeheer (derde lijn) - Configuration Management

1.4

Input proces

Dit proces heeft de volgende input: - Voortgang changes - Gegevens inkoop

1.5

Activiteiten proces

De activiteiten van dit proces zijn als volgt: - Ontvangst en registratie CI’s - Installatie/aflevering CI’s - Bijhouden wijzigingen CI’s - Verifiëren CI’s - Rapporteren Deze activiteiten worden in de volgende hoofdstukken nader uitgewerkt.

32

Auteur: Jurjen Bloo

16-02-2009

1.6


Versie 1.0

Output proces

Dit proces heeft de volgende output: - Verschillende rapportages aan andere processen en aan het IT management

1.7



Incident Management: Incident Management heeft overzicht nodig over de breedte van de infrastructuur. Incident Management moet tijdens het registreren van incidenten een koppeling kunnen maken met CI gegevens, om te weten waar het staat, wie het beheert, of er een problem of Known Error bij hoort met een workaround, voor welke klant het is met welke dienst en welke SLA.

-

Problem Management: Problem Management heeft inzicht nodig in de complexiteit van de infrastructuur. Problem Management moet problems en Known Errors kunnen koppelen aan CI’s en maakt gebruik van de CMDB data voor het bepalen van de business impact van incidenten en problemen, en het vervolgens analyseren van die incidenten en problemen.

-

Change Management: Change Management wil inschatten wat de impact kan zijn van uit te voeren changes. Change Management is de autorisator van changes en een change moet kunnen worden gerelateerd aan de betrokken CI’s. Change Management is verantwoordelijk voor het registreren van RfC’s. Daarmee levert Change Management de belangrijkste input voor het up-to-date houden van de CMDB.

-

Release Management: Release Management geeft informatie over release-planningen en –versies, zoals wanneer major releases en minor releases gepland staan. Release Management meldt terug wanneer een chage is uitgevoerd en vraagt vooraf informatie over betrokken CI’s, waaronder status, locatie, broncode, documentatie.

-

Service Level Management: Service Level Management vraagt informatie over kenmerken van de diensten, en over de relatie tussen diensten en de onderliggende infrastructuur. SLA’s kunnen in de CMDB worden opgenomen. SLA’s, OLA’s en UC’s vormen dat deel van de documentatie van de IT configuratie, waarin beschreven staat welke afspraken er zijn gemaakt betreffende de infrastructuur, software, de dienstverlening en de wederzijdse verantwoordelijkheden, bevoegdheden, rechten en plichten.

33

Auteur: Jurjen Bloo

16-02-2009


2.

Procedure ontvangst en registratie CI’s

2.1

Doel

Versie 1.0

Het doel van deze procedure is het inventariseren en registreren van nieuwe gebruikersgerelateerde componenten van de IT-oplossingen die beheerd worden door Leones.

2.2

Aanleiding

De aanleiding van deze procedure is een nieuw binnengekomen CI (configuratie item) dat onder het beheer van Leones valt.

2.3

Resultaat

Na uitvoering van deze procedure is een nieuw CI in de CMDB geregistreerd.

2.4

Beschrijving

Binnenkomst en controle goederen

Ophalen goederen

Controleren goederen en registratie gegevens op CMDB formulier

Registratie gegevens en status in CMDB

34

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Wanneer er vanuit de afdeling Sales bericht komt dat er nieuwe goederen zijn geleverd, worden deze door een Servicedesk medewerker opgehaald. De nieuwe goederen worden in de daarvoor bestemde ruimte opgeslagen. De goederen worden door de Servicedesk medewerker voorzien van een sticker met het Object ID erop. Voordat de goederen zijn opgeslagen, wordt door de Servicedesk medewerker de volgende gegevens genoteerd op het CMDB registratieformulier (zie bijlage I): PC/notebook : Object ID (sticker nummer) Soort Merk Type Specificatie Serienummer Leverancier Aanschafdatum Garantie tot Aankoopbedrag Status Printer : Object ID (sticker nummer) Soort Merk Type Serienummer Functie (netwerk, standalone) Leverancier Aanschafdatum Garantie tot Aankoopbedrag Status Randapparatuur : Object ID (sticker nummer) Soort (scanner, modem, etc) Merk Type Serienummer Leverancier Aanschafdatum Garantie tot Aankoopbedrag Status

35

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Software : Object ID Naam Versie Merk Licentienummer(s) Licentiesoort Maximaal aantal licenties Aankoopbedrag In gebruik aantal licenties Opdrachtgever Onderliggend contract Beheerder De gegevens van het ingevulde CMDB registratieformulier wordt door de Servicedesk medewerker in de CMDB geregistreerd. Daarna worden de ingevulde CMDB registratieformulieren aan de Configuration Manager overhandigd. De Configuration Manager controleert steekproefsgewijs de ingevoerde goederen.

2.5


Activiteiten Serivcedesk medewerker Controleren R binnengekomen CI’s Registreren CI’s R Inlichten RI binnengekomen CI’s en gegevens Voor uitleg van RACI, zie bijlage II.

Configuration Manager A AC A

36

Auteur: Jurjen Bloo

16-02-2009


3.

Procedure installatie/aflevering CI’s

3.1

Doel

Versie 1.0

Het doel van deze procedure is het verwerken van de installatie en aflevering in de CMDB.

3.2

Aanleiding

De aanleiding van deze procedure is de aflevering en/of installatie van een CI dat onder het beheer van Leones valt.

3.3

Resultaat

Na uitvoering van deze procedure is een afgeleverde of geïnstalleerde CI in de CMDB geregistreerd.

37

Auteur: Jurjen Bloo

16-02-2009

3.4


Versie 1.0

Beschrijving Installeren/afleveren CI’s

Invullen CMDB formulier

Gegevens in CMDB verwerken

IS het CI een PC/ Notebook

Ja

Interne gegevens scannen en in CMDB verwerken

Nee

Afsluiten melding

38

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Na de installatie van een PC scant de systeembeheerder de hardwaregegevens en plaatst deze in de database onder het Object ID van het betreffende systeem. Gegevens zoals geheugencapaciteit, harde schijf capaciteit en processor type/snelheid worden hierbij opgeslagen. Dezelfde procedure geldt voor een notebook. De systeembeheerder vult tevens het CMDB registratieformulier in. Hierop worden de volgende gegevens genoteerd: Status Installatie door Locatiecode Afdeling Wall-outlet nummer

Nadat de installatie/aflevering volledig in de CMDB is verwerkt, sluit de systeembeheerder de desbetreffende melding af.

3.5


Activiteiten Aanleveren gegevens CMDB na installatie/levering CI Registreren gegevens in CMDB Wijzigen locatiecode en status

Serivcedesk medewerker

Systeembeheerder R

Configuration Manager A

I

R

A

I

R

A

39

Auteur: Jurjen Bloo

16-02-2009


4.

Procedure bijhouden wijzigingen CI’s

4.1

Doel

Versie 1.0

Het doel is dat de CMDB up-to-date blijft en alle wijzigingen in de IT-infrastructuur worden verwerkt in de CMDB.

4.2

Aanleiding

Aanleiding is een uitgevoerde wijziging in de IT-infrastructuur.

4.3

Resultaat

Het resultaat is een CMDB die betrouwbaar is.

40

Auteur: Jurjen Bloo

16-02-2009

4.4


Versie 1.0

Beschrijving Uitvoeren wijziging

Is de wijziging een verhuizing of verplaatsing?

Nee

Ja



Verwerken gegevens in CMDB

Verwerken gegevens in CMDB

Heeft de wijziging betrekking gehad op interene hardware gegevens?

Ja

Interne gegevens scan en verwerken in CMDB

Nee

Afsluiten melding

41

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Nadat een wijziging in de IT-infrastructuur is uitgevoerd, voert de desbetreffende systeembeheerder de wijzigingen door in de CMDB en past de melding aan. In de CMDB worden de volgende statussen onderscheiden: - Vervanging Component is actief bij eindgebruiker ter vervanging van een gelijksoortig defect component -

Uitbreiding Component is actief bij eindgebruiker als uitbreiding

-

Diefstal Component is gestolen

-

Tijdelijke vervanging Leencomponent is tijdelijk ingezet ter vervanging van een defect component

-

Vermist Component is tijdens audit niet aangetroffen op locatie

-

Vervallen Component is in garantieperiode defect geraakt en vervanagen

-

Voorraad Component staat in voorraad

Voorbeelden van een wijziging zijn: - Verplaatsing/verhuizing CI - Upgrade software - Verwijderen CI - Etc Wanneer een wijziging betrekking heeft op de interne hardware gegevens van het CI, zal de systeembeheerder de desbetreffende PC scannen en de recente interne hardwaregegevens opslaan in de CMDB. Nadat de wijziging volledig in de CMDB is verwerkt, sluit de systeembeheerder de desbetreffende melding af. Verplaatsing/Verhuizing Na een verhuizing wijzigt de systeembeheerder de volgende gegevens in de CMDB: - Object ID - Loctiecode - Outlet nummer - Afdeling

42

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Naar aanleiding van een audit of verificatie door een Servicedesk medewerker, dienen die wijzigingen door de desbetreffende medewerker direct in de CMDB aangepast te worden. Wijzigingen die door overige medewerkers worden geconstateerd/geïnitieerd, worden middels en CMDB formuier doorgegeven aan de CMDB beheerder.

4.5


Activiteiten Invullen en inleveren CMDB registratieformulier Scannen interne hardwaregegevens Bijwerken CMDB

Applicatiebeheerder

Systeembeheerder

R

R

CR

CR

R

R

43

Servicedesk medewerekr

Configuration Manager A

A I

A

Auteur: Jurjen Bloo

16-02-2009


5.

Procedure verifiëren CI’s

5.1

Doel

Versie 1.0

Het doel van deze procedure is het controleren van de betrouwbaarheid van de CMDB.

5.2

Aanleiding

Verificatie wordt gestart door de Servicedesk bij de telefonische aanname van meldingen. Tevens vindt verificatie op verzoek van de Configuratie Manager plaats.

5.3

Resultaat

Het resultaat van deze procedure “verifiëren” is een overzicht van de verschillen tussen de in de CMDB geregistreerde gegevens en de fysieke situatie.

44

Auteur: Jurjen Bloo

16-02-2009

5.4


Versie 1.0

Beschrijving

Inventarisatie/ verificatieronde initieren

Verifieren gegevens bij telefonische melding

Uitvoeren inventarisatie/ verificatie

Kloppen de gegeven in CMDB

Nee

Gegevens inventarisatie/ verificatieronde verwerken in CMDB

Verifieren gegevens bij telefonische melding

Ja

Rapporteren betrouwbaarheids percentage CMDB

Nee

Wijken de gegevens in de CMDB vaak af van de fysieke situatie?

Ja

Incidnet Management

45

Rapporteren onbetrouwbaarheid CMDB

Auteur: Jurjen Bloo

16-02-2009

5.4.1


Versie 1.0

Continue verificatie

Verifactie vindt door de Servicedesk plaats op het moment dat de klant een incident meldt. Telefonisch wordt door de Servicedesk aan de hand van de gegevens die in de database staan gevraagd aan de klant of de gegevens kloppen. De volgende gegevens worden voor wat betreft verifcactie, door de servicedesk aan de klant gevraagd: - Object ID - Locatiecode - Afdeling/Groep Indien de gegevens die de klant doorgeeft niet overeenkomt met de gegevens in de CMDB of niet aanwezig zijn in de CMDB, wijzigt de desbetreffende medewerker de gegevens direct in de CMDB of voegt de gegevens toe. Indien de Servicedesk merkt dat de gegevens in de CMDB veel afwijkt van de fysieke situatie zal deze dit melden aan de Configuration Manager. Deze zal beslissen of een inventarisatieronde zal plaatsvinden.

5.4.2

Periodieke verificatie

Per kwartaal staat een audit van de CMDB gepland. Deze wordt op verzoek van de Configuration Manager gestart. De Configuration Manager is verantwoordelijk voor de uitvoering van de audit. De audit bestaat uit een steekproef. Indien uit de steekproef blijkt dat de CMDB niet betrouwbaar is, zal de Configuratie Manager een inventarisatieronde opstarten met als doel, de CMDB met de meest recente gegevens gevuld te hebben. De Configuration Manager werkt aan de hand van de gegevens van de audit en inventarisatieronde de CMDB bij. De periodieke verificatie per kwartaal dien in één werkdag afgerond te kunnen worden.

5.5


Activiteiten Initieren inventarisatie/audit ronde Aanleveren inventarisatie gegevens Vergelijken inventarisatie/auditgegevens met CMDB Bijwerken CMDB Rapporteren verschillen CMDB en fysieke situatie Telefonische verificatie Rapporteren betrouwbaarheid CMDB

Servicedesk medewerker I

Servicedesk coördinator IC

Configuration Manager RA

R

I

A

C

C

RA

RA RA R

A RA

46

Auteur: Jurjen Bloo

16-02-2009


6.

Procedure rapporteren

6.1

Doel

Versie 1.0

Het leveren van informatie over de CI’s die onder het beheer van Leones vallen.

6.2

Aanleiding

De aanleiding is een verzoek van een klant, IT management of medewerker.

6.3

Resultaat

Het resultaat is informatie over de IT-infrastructuur.

6.4

Beschrijving

De Configuration Manager levert op verzoek informatie aan geautoriseerde klanten en de afdeling operations over de IT infrastructuur. Deze informatie haalt de Configuration Manager uit de CMDB middels het uitdraaien van rapporten. De rapporten die geleverd worden aan klanten of andere managers, zijn afhankelijk van de wensen van de klanten en managers. Samen met de klant en managers worden de eisen en wensen ten aanzien van rapportage vastgesteld door de Configuration Manager.

6.5


Activiteiten Inventariseren wensen rapportage Samenstellen rapportage Opleveren rapportage

Servicedesk medewerker

R

Configuration Manager RA

Klant

Managers C

C

I

I

A RA

47

Auteur: Jurjen Bloo

16-02-2009

7.


Versie 1.0

Bijlage I: CMDB registratieformulier

Hieronder ziet u voorbeelden van hoe een CMDB registratieformulier eruit moet komen te zien. Dit kan aangepast worden naar de wensen van de Configuration Management.

Registratieformulier Hardware Datum: Naam medewerker: Object ID(sticker nummer): Soort:

PC Notebook Printer Software

Anders,……. Merk: Type: Specificatie:

Serienummer: Functie¹: Leverancier: Aanschafdatum: Garatie tot: Aankoopbedrag: Status: ¹ Indien van toepassing

Netwerk

Standalone

48

Auteur: Jurjen Bloo

16-02-2009


Versie 1.0

Registratieformulier Software Datum: Naam medewerker: Object ID(sticker nummer): Naam: Versie Merk: Licentienummer(s):

Licentiesoort: Maximaal aantal licenties: In gebruik aantal licenties: Opdrachtgever: Aankoopbedrag: Onderliggend contract: Beheerder:

49

Auteur: Jurjen Bloo

16-02-2009

8.


Versie 1.0

Bijlage II: Uitleg RACI


50

Auteur: Jurjen Bloo

Leones. IT Service Assessment & Improvement

Recommend Documents