Information Technology Infrastructure Library (ITIL)

Information Technology Infrastructure Library (ITIL) is een beheermethodiek die sterk gericht is op het beheren van IT-infrastructuren. ITIL is geen methode of model, maar eerder een set van best practices. Het resultaat van proces implementatie met behulp van ITIL is vergelijkbaar met de ISO 9000 regulering in de niet ICT branche. Enkele beoogde voordelen van ITIL zijn: reduceren van kosten, verbeteren serviceorganisatie en klanttevredenheid.

Information Technology Infrastructure Library (ITIL)

De eerste versie van ITIL uit de jaren tachtig is in 2001 opgevolgd door versie 2. ITIL versie 2 is jarenlang de wereldstandaard geweest voor het vakgebied IT Servicemanagement. Waarbij elf processen verdeelt over twee sets verdeelt een raamwerk zijn voor het beheren van IT Servicemanagement.

In 2007 werd ITIL versie 3 beschikbaar. Deze versie hanteert niet de processen als uitgangspunt (zoals versie 2), maar de dienstverlening. ITIL versie 3 is veel abstracter geworden en de 11 processen zijn uitgegroeid tot 32 processen. Het toepassen van ITIL versie 3 is alleen voor grote bedrijven interessant, die al reeks ITIL versie 2 volledig hebben geïmplementeerd en een hogere volwassenheid nastreven. ITIL versie 2 heeft de ICT beheerprocessen ingedeeld in achttal sets. De Service Support en Service Delivery sets zijn het meest populair van ITIL versie 2.

Service Delivery kent de onderdelen: Financial , Capacity, Availability,Continuity, Service Level en Sercurity Management. Service Delivery is gericht op de proactieve IT services, die nodig zijn om aan de behoefte van de zakelijke gebruiker te voldoen. Service Support kent de onderdelen: Change, Release, Problem, Incident, Configuration Management en Service Desk. Service Support heeft de focus op het ondersteunen van de zakelijke gebruiker.

De Servicedesk

Volgens ITIL is de Servicedesk geen proces, maar een organisatorische eenheid. De Servicedesk verzorgt, tussen de ICT en gebruiker overeengekomen dienstverlening, bereikbaarheid en toegankelijkheid te garanderen. Een Servicedesk is zowel reactief als proactief bezig. Een Servicedesk kent de volgende taken:

• Het snel verhelpen van eenvoudige storingen
• Het escaleren van incidenten
• Het verzorgen van voorlichtingen aan de gebruikers
• De installatie van standaard software en hardware
• De registratie van software en hardware incidenten
• Het in ontvangst nemen van wijzigingsverzoeken
• Het ondersteunen van de gebruikers bij hun werk

De Servicedesk is geen "single point of contact" voor gebruikers en klanten, maar een centrale, geconsolideerde en uitgebreide "single interface" tussen gebruikers en de IT dienstverlening.

Volgens ITIL worden de volgende activiteiten uitgevoerd:

• Configuration Management (registratie van ICT-infrastructuur)
• Incident Management (snel herstellen van de dienstverlening)
• Problem Management (analyse en oplossen van storingen)
• Change Management (gecontroleerd doorvoeren van wijzigingen)
• Release Management (Wordt niet behandeld in dit artikel)
• Service Level Management (melden van ongeautoriseerde wijzigingen)
• IT customer relations Management (Wordt niet behandeld in dit artikel)

Configuratie management

Configuratie management is een proces waarbij alle componenten van de IT infrastructuur en de gerelateerde documentatie onder controle brengt, ter ondersteuning van de overige Service Management processen. Hierbij in het bijzonder Incident, Problem en Change management om een kwalitatieve hoge dienstverlening te realiseren die aansluit aan de steeds wijzigende gebruikerswensen.

Het doel van Configuration management is de registratie van alle relevante onderdelen van de ICT infrastructuur en vormt hierdoor de basis van andere ITIL processen. Dit gebeurt door de Configuratie Items (CI) die worden gebruikt bij dienstverlening om vast te leggen in een Configuration Management Database (CMDB). Dit zijn zowel hardware als software componenten, maar ook gegevens met betrekking tot SLA afspraken, netwerktekeningen en overige documentatie. Bij configuration management komen de volgende aspecten kijken:

1. Planning

Vaststellen van strategie, beleid en doelstellingen van configuration management. Deze zouden in lijn moeten zijn met de doelstellingen van de organisatie.

2. Identificatie

Identificeren en vaststellen van de CI`s, hun eigenaar en de onderlinge relaties en welke eigenschappen in de CMDB moeten worden opgenomen.

3. Controle

Controle van CI`s, zodat CI`s in de CMDB geautoriseerd en geüpdate zijn. Zonder controle mag geen enkele CI toegevoegd, gewijzigd of verwijderd worden.

4. Statusbewaking

Bewaking van de actualiteit van de CI`s. CI`s meerdere statussen kunnen hebben zoals gepland, operationeel, ontwikkeling enz.

5. Verificatie

Verificatie en audits om de juistheid van de CI`s te controleren en om ervoor te zorgen dat de CMDB ten alle tijden geüpdate is en correct functioneert.

6. Rapportage

Andere ITIL processen voorzien van gegevens over CI`s. Rapportage moet ook leiden om Configuration management verder bij te stellen.

Incident management

Incident management is een proces dat gericht is op het afhandelen van verstoringen in de ICT dienstverlening (incidenten). Het doel van Incident management is het registeren en het begeleiden van het incident naar de juiste specialisten, maar ook om de negatieve impact van incidenten te minimaliseren.

Naast zorgen voor beschikbaarheid en functionaliteit is het wenselijk om zo snel en accuraat mogelijk een incident te verhelpen met oog op prioriteit. Op basis van de impact en urgentie wordt de prioriteit bepaald. Elk incident wordt vastgelegd in een registratiesysteem, die tevens dient als een "know-error" database. Deze database bestaat uit meerdere informatiebronnen en is gevuld met bekende incidenten en de bijbehorende oplossingen. Detectie van incidenten kunnen zowel proactief (systeemmonitor) als reactief (gebruiker) geïdentificeerd worden. Bij incident management komen de volgende aspecten kijken:

1. Registeren

Incidenten worden gelijk geregistreerd en of soort gelijke incidenten bekend zijn. ITIL gaat uit van het principe dat de 1e lijn support medewerker het incident registreert en classificeert.

2. Classificeren

Incidenten worden gecategoriseerd en krijgen een prioriteit afhankelijk van urgentie en impact. Gezien de prioriteitsbepaling bij DG vrijwel exact gelijk is aan de ITIL methode zal hier verder niet op ingegaan worden.

3. Bekend Incident

Het incident wordt gematched met een eventueel vergelijkbaar incident en of er een oplossing / workaround beschikbaar is. Dit is alleen mogelijk als Problem management is geïmplementeerd.

4. Onderzoeken

Incidenten worden onderzocht met eventuele ondersteuning van ICT specialisten. De 1e lijn support medewerker zal het incident (30min) onderzoeken en indien mogelijk een oplossing bieden.

5. Herstel 1e/2e/3e of op locatie

Incidenten waarvoor geen oplossing beschikbaar is of waarvoor meer expertise nodig is worden zullen worden doorverwijzen naar iemand met meer kennis of met meer bevoegdheid. Als het incident is opgelost moet deze geregistreerd worden met de bijbehorende oplossing. Als het incident niet is opgelost zal de melding open blijven voor verdere behandeling. Als de oplossing is gerealiseerd wordt het incident afgesloten en de betrokkenen CI`s bijgewerkt.

Problem Management

Problem Management is een proces dat er voor zorgt dat fouten in de ICT infrastructuur worden weg genomen, om een zo hoog mogelijk stabiliteit te bereiken. Er worden twee soorten typen problemen onderscheiden:

1. Incidenten die niet opgelost kunnen worden, maar is er eventueel een workaround beschikbaar.
2. Terugkomende incidenten, waarbij een trend waar te nemen is.

Problem management en Incident management moeten beide apart gezien worden. Incident management heeft als hoofddoel om de eindgebruik zo snel mogelijk te assisteren. Problem management kijkt naar de oorzaak van het incident en zorgt voor de daadwerkelijke oplossing. Problem management ondersteund Incident management door o.a. oplossingen en workarounds beschikbaar te stellen. Daarnaast levert Problem management input aan Change management.

De input voor Problem management bestaat uit o.a. incidenten, oplossingen, workarounds, configuratie bestanden, informatie van leveranciers, logboek bestanden en performance rapporten. Een problem manager zal noodzakelijk zijn om voor genoeg input te zorgen. Daarnaast is het niet wenselijk om de incident en problem manager uit één en dezelfde persoon te laten bestaan. Het is belangrijk de taken van Incident en Problem management te scheiden. Echter is het gebruikelijk dat de Problem manager eveneens de taak van Change manager op zich neemt. Bij Problem management komen de volgende aspecten kijken:

1. Registeren

Een probleem wordt vast gesteld in het registratiesysteem. Alle informatie die beschikbaar is over het probleem zou hierin opgenomen moeten worden. Voorgaande incidenten, gebruikers gegevens, enz.

2. Classificeren

Het probleem word geclassificeerd en krijgt een prioriteit toegewezen. De prioriteit is net zoals bij incident management afhankelijk van impact en urgentie. Daarnaast kan een bekende workaround invloed hebben om de prioriteitsbepaling.

3. Team samenstellen

Een team zal worden samengesteld uit IT specialisten en middelen.

4. Onderzoeken

Het team onderzoekt het probleem, waarbij het probleem wordt nagebootst in een testomgeving. In deze testomgeving zal er door herhaling van onderzoek en diagnose tot een oplossing gekomen kan worden.

5. Registeren "Know error"

De voortgang en uitkomst van het onderzoek, zal worden geregistreerd in de "Know error" database. Indien een tijdelijk oplossing is gevonden zal het probleem opnieuw onderzocht worden.

6. Change aanvraag

Indien de oplossing is gevonden kan de "change" ingediend worden bij Change management, dat in 9.4 word behandeld.

Change management

Het proces Change management zorgt ervoor dat elke wijzing in de ICT infrastructuur op gecontroleerde wijze wordt afgehandeld, zodat aan wijzigingen gerelateerde incidenten voorkomen worden. Bij het Change management proces worden de voorgestelde oplosacties en plan (Problem management) uitgevoerd. De zogeheten Request For Change (RFC).

1. Voorbereiding

Alle gegevens worden verzameld zoals incidenten, problemen, betrokken CI`s, personen, enz. Daarnaast worden de gevolgen van de RFC in kaart gebracht.

2. Autorisatie

De RFC dient toestemming te krijgen om in behandeling genomen te worden. De Change manager moet bepalen of de RFC wel nut heeft.

3. Classificeren

Als er toestemming is, kan de prioriteit van de RFC bepaald worden. De prioriteit wordt op dezelfde wijze uitgevoerd als bij Incident management en Problem management. Als een RFC een hoge urgentie kent zal deze direct in ontwikkeling worden genomen.

4. Planning

Indien de RFC geen directe urgentie kent zal, afhankelijk van de prioriteit de planning gemaakt worden. In de zo geheten Foward Schedule of Changes, staan alle goed gekeurde RFC`s en hun planning. Bijeenkomsten worden ook ingepland om de geautoriseerde RFC`s, de doorgevoerde RFC`s en lopende RFC`s te bespreken.

5. Ontwikkeling Installatie

De RFC zal indien nodig worden ontwikkeld, waarna het geïnstalleerd kan worden. Net zoals bij Problem management zal de wijziging in een testomgeving worden getest. Een RFC kan een probleem oplossen, maar een incident veroorzaken.

Hierdoor zal de wijziging voor implementatie uitvoerig getest moeten worden, door herhaling van onderzoek en diagnose. Release management dat niet verder in dit onderzoek behandeld wordt, kan een belangrijke rol hebben bij de ontwikkeling en installatie van RFC`s.

6. Vrijgave

Als de RFC door de testfase is gekomen word deze vrijgegeven om geïmplementeerd te worden.

7. implementatie

De RFC wordt geïmplementeerd, waarna de RFC afgesloten kan worden.

8. Evaluatie

Noodzakelijk is dat de voortgang van de RFC bijgehouden word, zodat er periodieke evaluatie kan plaats vinden.

Service level management

Om tot een goede dienstverlening te kunnen, zijn afspraken nodig over de concrete punten van de dienstverlening. Afspraken worden vastgelegd in Service Level Agreements (SLA), waarna ze vervolgens bewaakt worden.

Service level management

Service level management is verantwoordelijk voor het continu onderhouden en verbeteren van de met de klant overeengekomen dienstverlening. Door met de klant te onderhandelen over de aangeboden diensten, afspraken te maken over deze diensten en vervolgens de diensten te monitoren en hierover te rapporteren. Service level management kan worden onverdeeld in twee hoofdcategorieën: afspraken vastleggen en afspraken bewaken.

1. Identificeren

Onder identificeren kan men verstaan het in kaart brengen van de behoeften van de klant en het uitdrukken van deze behoefte in meetbare eenheden.

2. Definiëren

Tijdens het definiëren worden de verwachtingen van de klant vastgelegd in Service Level Requirements (SLR). Hierin wordt de functionaliteit van de dienst omschreven, tijden en dagen waarop de dienst beschikbaar is, de continuïteitseisen, de betrokken en kwaliteitsstandaarden.

In de Service Specsheets staan tot in detail beschreven wat de klant wil en wat de consequenties zijn voor de ICT organisatie. Als laatste wordt de Service Quality Plan opgesteld, waarin alle punten voor de interne en externe leveranciers zijn ondergebracht

3. Contracteren

De Service Catalogus wordt opgesteld nadat de diensten zijn gedefinieerd. Men onderscheid in ITIL drie soorten contracten: Service Level Agreements - afspraken over de diensten, Operational Level Management - verzorging van diensten bij het ICT bedrijf intern, en een Underpinning Contract - afspraken met externe leveranciers.

4. Monitoren

De bewaking van de contracten komt in feite neer op het nazien van de gemaakte afspraken. Het monitoren heeft niet alleen betrekking op technische zaken, maar ook de procedurele zaken. Niet alleen interne zaken al beschikbaarheid en capaciteit worden gemeten, maar ook de externe waarden als reactietijden en ondersteuning.

5. Rapporteren

Door middel van diverse rapporten kunnen vergelijkingen gemaakt worden tussen afgesproken service levels en streefwaarden. O.a. beschikbaarheid, responsetijden en transactiesnelheden komen hier in voor.

6. Evalueren

Het is belangrijk regelmatig de service levels te herzien en aan te passen op ontwikkelingen. Evaluatie gebeuren zowel intern als extern (met de klant).