it-service management op basis van itil 2011 editie [2011 ed.] 9789087538019, 9789087530198 [PDF]

Zitiervorschau

Colophon Titel:

IT-servicemanagement op basis van ITIL® 2011 Editie

Auteur:

Pierre Bernard m.m.v. René Visser (Nederlandse vertaling)

Reviewers:

Bert Boesjes (Sogeti Nederland) Dick Pondman (Leaneraz) René Visser (Pink Elephant)

Uitgever:

Van Haren Publishing, Zaltbommel, www.vanharen.net

Tekstredactie:

Harry Ousen

Design & layout:

CO2 Premedia, Amersfoort

ISBN Hard copy:

978 90 8753 801 9

ISBN eBook:

978 90 8753 019 8

Druk:

Eerste druk, eerste oplage, november 2013

Copyright:

© Van Haren Publishing, 2012, 2013

© Crown copyright 2011. Reproduced under license from AXELOS: cover diagram and diagrams and highlighted boxes. Any ITIL core book 1.1, 2.2 Continual Service Improvement 2.4, 2.8, 3.1, 3.4, 3.5, 4.1, 5.6 Continual Service Improvement (2007) 5.6, A.3 Service Design 3.2, 4.1, 4.10, 4.13, 4.14, 4.16, 4.17, 4.2, 4.20, 4.21, 4.24, 4.25, 4.27, 4.6, 4.8, 4.9 Service Operation 4.2, 4.3, 4.6, 4.7, 4.9, 5.2, 5.3, 5.4, 6.1, 6.2, 6.4, 6.6 Service Strategy 2.6, 4.14, 4.15, 4.18, 4.2, 4.25, 4.3, 4.41, 4.42, 4.43, 5.5 Service Transition 1.2, 4.1, 4.19, 4.2, 4.28, 4.31, 4.33, 4.35, 4.37, 4.5, 4.6, 4.7, 5.6, 6.3

Alle rechten voorbehouden. Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt door middel van druk, fotokopie, microfilm of op welke andere wijze ook, zonder voorafgaande schriftelijke toestemming van de uitgever.

Hoewel deze uitgave met de grootst mogelijk zorg is opgesteld, kan noch de redactie, noch de uitgever enige aansprakelijkheid aanvaarden voor schade voortvloeiend uit fouten of onvolkomenheden in de tekst.

TRADEMARK NOTICES ITIL® is a registered trade mark of AXELOS. The ITIL Swirl logo™ is a trade mark of AXELOS.

Voor u ligt de volledig herziene versie van Foundations van IT Servicemanagement – op basis van ITIL. Dit boek is een, ingrijpend bewerkte, vertaling van de Engelstalige door Pierre Bernard geschreven uitgave Foundations of ITIL 2011 Edition. Na de publicatie van de in 2011 gepubliceerde update van ITIL, hierna ITIL Editie 2011 genoemd, is ervoor gekozen om een geheel nieuw boek te ontwikkelen, maar wel met dezelfde uitgangspunten als de vorige edities, om in het oorspronkelijk doel te voorzien: het bieden van een eenvoudige introductie over het ITIL-framework, dat is beschreven in de bijna 2000 pagina’s van de vijf ITIL-boeken, en het ondersteunen van het inzicht in de samenhang daarvan. En dat is, zoals u dat van ons mag verwachten, met dit nieuwe boek ook weer gelukt. Net als de vorige versies, dekt ook dit boek alle exameneisen voor het ITIL Foundation examen van AXELOS af en kan dus prima worden gebruikt ter voorbereiding van dit examen. Tevens biedt dit boek een goede ondersteuning bij de voorbereiding van de zogeheten ITIL Intermediate examens (lifecycle- en capability-examens). We zijn er van overtuigd dat we onze lezers hiermee opnieuw een goede dienst bewijzen.

In tegenstelling tot de vorige versie van dit boek, wordt in dit nieuwe boek de uitleg over ITIL volledig gekoppeld aan de servicelevenscyclus. Verdeeld over de vijf fasen van de levenscyclus worden alle 26 ITIL-processen besproken. Tevens worden in een apart hoofdstuk de vier functies binnen ITIL besproken. De tekst wordt op veel plaatsen verduidelijkt door heldere figuren, schema’s en tabellen.

Al jaren is IT Servicemanagement op basis van ITIL een bestseller in de wereld van IT-management en we verwachten dat deze nieuwe editie deze positie

opnieuw zal waarmaken. Bij dit boek is een Nederlandstalige/Engelstalige Glossary (verklarende woordenlijst) beschikbaar op www.vanharen.net op de productpagina voor dit boek.

Oktober 2013, René Visser (lead-reviewer) en uitgever

1   INLEIDING 1.1

Achtergrond

1.2

Waarom dit boek

1.3

Organisaties betrokken bij ITIL

1.4

Verschillen met eerdere versies

1.5

Structuur van dit boek

1.6

Hoe dit boek te gebruiken

DEEL 1   DE ITIL-SERVICE LEVENS CYCLUS 2   INLEIDING OP SERVICEMANAGEMENT EN DE SERVICELEVENSCYCLUS 2.1

Basisbegrippen

2.2

Functies en processen

2.3

Governance en managementsystemen

2.4

Organisatorische volwassenheid

2.5

Voordelen en risico’s van ITSM-Frameworks

2.6

De servicelevenscyclus

3   FUNCTIES 3.1

IT-operationsmanagement

3.2

Servicedesk

3.3

Technisch management

3.4

Applicatiemanagement

DEEL 2   DE FASEN VAN DE LEVENS CYCLUS 4   SERVICESTRATEGIEFASE 4.1

Inleiding tot Servicestrategie

4.2

Strategiemanagement voor IT-services

4.3

Serviceportfoliomanagement

4.4

Financieel management voor IT-services

4.5

Demandmanagement

4.6

Klantrelatiebeheer

5   SERVICEONTWERPFASE 5.1

Inleiding tot Serviceontwerp

5.2

Ontwerpaspecten

5.3

Ontwerpactiviteiten

5.4

Basisbegrippen van serviceontwerp

5.5

Ontwerpcoördinatie

5.6

Servicecatalogusmanagement

5.7

Servicelevelmanagement

5.8

Capaciteitsmanagement

5.9

Availabilitymanagement

5.10

IT-service continuity management

5.11

Information security management

5.12

Leveranciersmanagement

5.13

Organisatie

5.14

Methoden, technieken en tools

5.15

Implementatie-afwegingen

6   SERVICETRANSITIEFASE 6.1

Inleiding tot servicetransitie

6.2

Basisbegrippen

6.3

Transitieplanning en -ondersteuning

6.4

Changemanagement

6.5

Serviceasset- en configuratiemanagement (SACM)

6.6

Release & deployment management

6.7

Service validation & testing

6.8

Wijzigingsevaluatie

6.9

Kennismanagement

6.10

Organisatie

6.11

Methoden, technische systemen en tools

6.12

Implementatie

7   DE SERVICEPRODUCTIEFASE 7.1

Inleiding tot serviceproductie

7.2

Monitoren en controleren

7.3

Eventmanagement

7.4

Incidentmanagement

7.5

Request fulfillment

7.6

Problemmanagement

7.7

Accessmanagement

7.8

Implementatie

7.9

Organisatiestructuren van serviceproductie

8   DE CONTINUE SERVICEVERBETERINGSFASE 8.1

Inleiding tot continue serviceverbetering

8.2

Basisbegrippen

8.3

CSI-activiteiten

8.4

Verbeterproces in 7 stappen

8.5

Organisatie

8.6

Methoden, technieken en tools

8.7

Implementatie

BIJLAGE A LITERATUUR BIJLAGE B VERSCHILLEN TUSSEN ITIL V3 EN ITIL 2011 EDITIE B.1

Servicestrategie

B.2

Serviceontwerp

B.3

Servicetransitie

B.4

Serviceproductie

B.5

Continue serviceverbetering

Register

■ 1.1   ACHTERGROND Sinds het jaar 2000 hebben technologische ontwikkelingen als smartphones, tablets, cloud services, near-field-content, Wi-Fi en vooral sociale media een enorm effect gehad op de wereld waarin wij leven. Door het verschijnen van extreem krachtige hardware, zeer veelzijdige software en supersnelle netwerken, en het alom accepteren en inzetten ervan, zijn organisaties wereldwijd in staat gesteld hun informatie-afhankelijke producten en services verder te ontwikkelen en deze sneller op de markt te brengen. In het “informatietijdperk”, waarin alles met elkaar verbonden is, is de verspreiding van data (gegevens) en informatie sneller, dynamischer maar meteen ook een wereldwijd fenomeen.

Bob Dylan’s nummer “The Times They Are A-Changin” is hier volledig op zijn plaats, omdat de traditionele visie en de rol van de IT-organisatie (Informatie Technologie) inderdaad dramatisch zijn veranderd als gevolg van bovenstaande. Om succesvol te zijn, moeten organisaties zo snel mogelijk reageren op snel veranderende eisen van de markt en op nieuwe technologieën. Ten eerste spreken we minder van IT maar meer van informatieservices (IS). Ten tweede wordt cloud computing steeds meer een haalbare optie en een voor de hand liggende oplossing. Dit komt doordat organisaties gaan beseffen dat technologie niet altijd een kernactiviteit is en dat outsourcing hen een nauwkeuriger en beter te voorspellen kostenstructuur biedt.

Organisaties zullen ook moeten nadenken over de grote invloed van de komst van de generatie medewerkers die zeer vertrouwd is met technologie. Deze nieuwe medewerkers maken al vanaf zeer jeugdige leeftijd gebruik van technologie; ze hebben zich niet alleen de mobiele technologieën vroeg eigen

gemaakt, maar ook sociale media. Informatie is nu binnen handbereik en ze verwachten hetzelfde op hun werkplek. Behalve voor de nieuwe generatie werknemers moeten organisaties ook nadenken over hoe ze omgaan met diezelfde wensen en eisen bij hun bestaande en potentiële klanten.

Er zijn tal van boeken, white papers en artikelen over de noodzaak om verticale bedrijfszuilen af te breken en het businessmodel om te vormen naar meer horizontale

processen, dus naar een “platte” organisatie. Deze

ontwikkeling brengt met zich mee dat de besluitvormingsbevoegdheden in toenemende mate op een lager niveau in organisaties worden belegd. Volgens deze bronnen hebben procesgerichte organisaties als voordeel dat processen kunnen worden ontworpen die een

klantgerichte aanpak ondersteunen. Dat

maakt de afstemming tussen de IT-organisatie (verantwoordelijk voor het verstrekken van informatie) en de klant (die verantwoordelijk is voor het gebruik van deze informatiesystemen in hun bedrijf ) steeds belangrijker. De term

Business-IT Alignement (BITA) wordt hiervoor meestal gebruikt.

Het is tegen deze achtergrond dat de wereld van IT-servicemanagement (ITSM, IT Service Management) is opgekomen en aan populariteit heeft gewonnen.

Naarmate organisaties meer ervaring opdeden met de

procesgerichte

benadering van IT-servicemanagement, werd het duidelijk dat deze processen steeds in samenhang moeten worden gemanaged. Bovendien is duidelijk geworden dat de invoering van een procesgerichte werkwijze een grote verandering betekent voor functioneel ingerichte of projectgeoriënteerde organisaties. Management van cultuur en verandering is een cruciaal element voor een succesvol organisatieontwerp. Management van verandering verwijst hier naar veranderingen in het bedrijf, maar ook naar veranderingen in de houdingen, competenties, gedragingen en de toepassing van frameworks en methoden die afgestemd zijn op de behoeften van de organisatie.

Organisaties hebben altijd al gebruikgemaakt van processen en voor de IT is dat niet anders. Processen worden echter vaak geïsoleerd uitgevoerd door enkele personen of groepen en kennis met betrekking tot de processen wordt vaak niet gedeeld of gedocumenteerd.

Een andere belangrijke les is dat de IT-organisatie zich niet dient te verliezen in een procescultuur. Net zoals de eenzijdige project- of vanuit de lijn gestuurde organisatie, is een eenzijdig procesgerichte organisatie niet de optimale organisatievorm. Balans is, zoals altijd, het toverwoord. Daarnaast is duidelijk geworden dat de klantgerichte aanpak vereist dat er een end-to-end en een

user-centric benadering (waarbij de gebruiker centraal staat) moet

worden gevolgd. Voorbeeld: voor de gebruiker heeft het geen toegevoegde waarde om te weten dat ‘de server nog steeds in bedrijf is’ als het informatiesysteem niet beschikbaar is op de werkplek van de gebruiker.

Als gevolg van de snel groeiende zakelijke afhankelijkheid van informatie, gelden voor de kwaliteit van de informatievoorziening in bedrijven steeds

interne en externe eisen. De rol van standaardnormen wordt steeds belangrijker, en frameworks van best practices (bewezen aanpak) helpen strengere

bij het ontwikkelen van een managementsysteem om aan deze eisen te voldoen. Organisaties die hun processen niet beheersen, zullen niet in staat zijn goede resultaten neer te zetten op het niveau van de servicelevenscyclus (service life cycle) en het end-to-end-beheer van deze services. Organisaties die hun interne organisatie niet op orde hebben zullen ook niet ver komen. Daarom worden al deze aspecten naast elkaar behandeld in dit boek.

■ 1.2   WAAROM DIT BOEK Dit boek is bestemd voor degenen die verantwoordelijk zijn voor het opzetten en uitvoeren van de levering van de informatiediensten en bevat daarnaast veel nuttige informatie voor degenen die verantwoordelijk zijn voor strategische informatievraagstukken. Dit wordt ondersteund door zowel de beschrijving van de servicelevenscyclus, zoals gedocumenteerd in ITIL en door de beschrijving van de bijbehorende processen. De officiële ITIL manual bestaat uit vijf handboeken, met in totaal bijna 2000 pagina’s. Deze vormt de kern van ITIL en kan gebruikt worden voor een grondige studie van de hedendaagse best practice-voorbeelden. Het hier voorliggende boek biedt de lezer een eenvoudig leesbare, uitgebreide kennismaking met ITIL. Tevens dekt de inhoud van dit boek de examenspecificaties van het ITIL Foundation

examen, waardoor dit boek ook prima te gebruiken is voor de voorbereiding op het betreffende examen.

In 2007 verscheen versie 3 van het ITIL-framework. Deze nieuwe versie bracht een nieuwe benadering van servicemanagement. Naast de procesbenadering introduceerde ITIL V3 het begrip servicelevenscyclus. Vervolgens verscheen in 2011 een herdruk van de uitgave van 2007. In deze 2011-editie zijn vooral indelings-, grammaticale en syntactische fouten gecorrigeerd.

ITIL biedt een systematische aanpak voor het leveren van kwalitatief hoogwaardige IT-services. Het geeft een gedetailleerde omschrijving van de belangrijkste processen voor een IT-organisatie en verstrekt informatie over procedures, taken, rollen en verantwoordelijkheden. Deze best practices die zijn verzameld in het ITIL-framework kunnen worden aangepast aan de specifieke behoeften en situatie van een organisatie.

Door de jaren heen is ITIL uitgegroeid tot meer dan alleen een serie nuttige boeken over IT-servicemanagement. Het framework voor de best practice in IT-servicemanagement wordt gepromoot en verder ontwikkeld en beïnvloed door adviseurs, opleiders, trainers en leveranciers. Onder deze leveranciers vallen een breed scala aan technologische oplossingen zoals hardware-, software- en cloud computing-producten. Sinds de jaren ‘90 van de vorige eeuw heeft ITIL zich ontwikkeld van een theoretisch framework tot de aanpak en filosofie voor IT-servicemanagement.

Als een uitgebreid framework van best practices voor IT-servicemanagement zijn de voor- en nadelen van frameworks in het algemeen (beschreven in paragraaf 2.6) ook van toepassing op ITIL. Uiteraard werd ITIL ontwikkeld vanwege de eerder genoemde voordelen. Veel richtlijnen van de best practices zijn bedoeld om potentiële problemen te voorkomen, of, als die zich toch voordoen, op te lossen.

ITIL-examens Voor ITIL 2011 Editie zijn de syllabi voor alle examenkwalificaties bijgewerkt. De belangrijkste wijzigingen hebben betrekking op nieuwe/gewijzigde

paragrafen en verbeterde formulering en/of verduidelijking van sommige leerdoelen en paragraafonderdelen.

Ten tijde van de publicatie van dit boek hebben meer dan 2 miljoen mensen wereldwijd een of meer ITIL-certificaten behaald.

Er zijn vier kwalificatieniveaus met betrekking tot het ITIL-framework, te weten:

■ Foundation-niveau ■ Intermediate-niveau (Service Lifecycle Stream en Service Capability Stream) ■ ITIL Expert ■ ITIL Master Meer informatie over het kwalificatieschema is te vinden op: http://www.itil-officialsite.com

■ 1.3   ORGANISATIES BETROKKEN BIJ ITIL Cabinet Of ce en AXELOS Oorspronkelijk is ITIL een product van CCTA, een organisatie van de Britse overheid. In 2001 werd CCTA ingelijfd door het Office of Government Commerce (OGC), die daarmee de nieuwe eigenaar van ITIL werd. De Britse overheid (UK Government) werd daarmee dus de eigenaar van het intellectuele eigendom (handelsmerken en copyright) van ITIL. Sinds juni 2010 wordt de uitvoering en toezicht hiervan uitgevoerd door het Cabinet Office.

Op 1 juli 2013 is een nieuwe organisatie gecreëerd ten behoeve van de verdere ontwikkeling en exploitatie van ITIL, PRINCE2 en andere gerelateerde producten, AXELOS. Deze organisatie is een joint venture van het Cabinet Office met Capita PLC. Deze joint venture is daarmee de eigenaar van genoemde producten geworden. De Britse overheid bezit 49 procent van de aandelen van AXELOS en Capita PLC 51 procent.

itSMF

Tot de doelgroep voor deze publicatie behoort iedereen die betrokken is bij of geïnteresseerd is in IT-servicemanagement. De belangrijkste internationale organisatie voor IT-servicemanagementprofessionals is het in 1991 opgerichte itSMF (Information Technology Service Management Forum). Deze organisatie was oorspronkelijk bekend als het Information Technology Infrastructure Management Forum (ITIMF), opgezet als een Brits genootschap. In 1994 werd een zustergenootschap opgericht in Nederland, naar Brits voorbeeld. Sindsdien zijn er ‘chapters’, nationale itSMF-organisaties, opgezet in meer dan veertig landen, verspreid over de gehele wereld. Al deze ‘chapters’ werken onder de paraplu van itSMF International (itSMF-I).

De itSMF is gericht op de integrale, professionele uitvoering van ITservicemanagement. Het promoot de uitwisseling van informatie en ervaringen die IT-organisaties kunnen gebruiken om hun dienstenlevering te verbeteren. Het itSMF is ook betrokken bij het gebruik en de kwaliteit van de relevante best practices, methoden en standaarden. Een daarvan is ITIL. itSMF-I heeft een rol bij het promoten van het gebruik van ITIL.

Certi cering, examinering en accreditatie AXELOS is niet alleen verantwoordelijk voor het beheer van ITIL-rechten, maar ook voor de certificering van ITIL-examens en accreditatie van exameninstituten. AXELOS is tevens verantwoordelijk voor de publicatie van het ITIL certificeringssysteem en voor de officiële ITIL publicaties (manuals).

In 2013 wordt de wereldwijde levering van de ITIL-examens ondersteund door zeven examensinstituten, die zijn geaccrediteerd door APMGInternational (en waarvan AXELOS de accreditatie zal overnemen):

■ BCS-ISEB CERT-IT, ■ CSME, DANSK IT, ■ DF Certifiering AB, ■ EXIN, ■ LCS (Loyalist Certification Services), ■ PEOPLECERT Group, ■ TÜV SÜD Akademie. Voor meer informatie, zie www.itil-officialsite.com.

■ 1.4   VERSCHILLEN MET EERDERE VERSIES Het boek Foundations of ITIL® speelt al jaren een sleutelrol in de verspreiding van ideeën over IT-servicemanagement en ITIL. Het is vertaald in dertien talen en wordt erkend als de meest praktische inleiding tot de voornaamste best practices op dit gebied. De nu voorliggende uitgave over ITIL 2011 Editie verschilt wat betreft structuur en inhoud van de vorige versie, Foundations van ITIL v3. Allereerst natuurlijk vanwege de verschillen tussen ITILv3 en ITIL 2011 Editie. Zie Bijlage C voor een overzicht van de meest essentiele verschillen tussen beide versies van ITIL. Daarnaast is de inhoud aangepast aan de gewijzigde wensen van trainingsorganisaties wat betreft een leermiddel dat kan worden gebruikt bij training voor het ITIL Foundation examen en de verdere ITIL-examens.

■ 1.5   STRUCTUUR VAN DIT BOEK Deel 1 behandelt servicemanagement, de servicelevenscyclus en de afzonderlijke functies en Deel 2 behandelt de vijf Dit boek bestaat uit twee delen:

afzonderlijke fasen in de ITIL-servicelevenscyclus en de 26 processen binnen deze fasen.

Deel 1, bestaande uit hoofdstuk 2 en 3, introduceert de servicelevenscyclus in de context van IT-servicemanagement en IT-governance. De principes van organisatorische groei/ ontwikkeling en de voordelen en risico’s van het werken binnen een servicemanagementframework worden besproken. De functies die betrokken zijn bij de best practiceaanpak van servicemanagement worden geïntroduceerd en behandeld. Hierdoor kan de lezer de processen in deel 2, en hun gerelateerde begrippen en activiteiten, beter herleiden tot de mens- en organisatiekant van servicemanagement.

Deel 2 bestaat uit de hoofdstukken 4 t/m 8 en bevat gedetailleerde uitleg over elk van de vijf fasen in de servicelevenscyclus in een gestandaardiseerde structuur:

■ servicestrategie, ■ serviceontwerp,

■ servicetransitie, ■ serviceproductie en ■ continue serviceverbetering. In deze hoofdstukken worden de karakteristieken van de servicelevenscyclus, de structuur en de elementen ervan uitgebreid behandeld. Aan het begin van ieder hoofdstuk worden de kernpunten van elke fase op een uniforme wijze toegelicht, gericht op een goede studeerbaarheid. Vervolgens worden, in een afzonderlijke paragraaf, één van de 26 processen beschreven.

Elk van die processen wordt in een vaste volgorde beschreven: 1.

Inleiding (met daarbinnen: doel, doelstellingen, bereik en basisbegrippen),

2.

Activiteiten, methoden en technieken,

3.

Informatiemanagement,

4.

Interfaces,

5.

Aanleidingen (triggers),

6.

Invoer,

7.

Uitvoer,

8.

Kritieke succesfactoren,

9.

Metrics (meetwaarden),

10. Uitdagingen, 11. Risico’s.

De bijlagen vormen een nuttige informatiebron voor de lezer. Bijlage A is een referentielijst van de bronnen die zijn gebruikt in dit boek. In bijlage B is aangegeven waar de Woordenlijst van ITIL-begrippen is te vinden. Deze woordenlijst is gebaseerd op de officiële glossary Engels-Nederlands van AXELOS, versie 2.0, 31 januari 2013.

■ 1.6   HOE DIT BOEK TE GEBRUIKEN Lezers die vooral geïnteresseerd zijn in de servicelevenscyclus kunnen zich concentreren op deel 1 van het boek en de processen die voor hen van belang zijn halen uit deel 2.

Lezers die vooral geïnteresseerd zijn in de functies en processen en nog niet klaar zijn voor de levenscyclusbenadering, of die de voorkeur geven aan een procesmethode, kunnen de inleidende hoofdstukken lezen en zich dan richten op de functies en processen die voor hen van belang zijn.

Lezers die op zoek zijn naar een grondige introductie in ITIL en het bereik en de karakteristieken ervan willen onderzoeken, kunnen deel 1 over de levenscyclus lezen en vervolgens zoveel van de processen in deel 2 als nodig.

Op deze manier biedt deze nieuwe uitgave ondersteuning voor verschillende benaderingen van IT-servicemanagement op basis van ITIL.

Dit boek dekt tevens alle exameneisen voor het ITIL Foundation examen af en kan dus prima worden gebruik ter voorbereiding van dit examen. Echter niet alle onderwerpen, die in dit boek behandeld worden maken deel uit van de exameneisen. Indien de lezer zich alleen tot de examenstof wenst te beperken kan hij of zij dat het beste doen aan de hand van de Preparation Guide (Syllabus Het ITIL Foundation Certificaat in IT-service management), die te vinden is op de website van EXIN (http://www.exin.com). Tevens biedt dit boek een goede ondersteuning bij de voorbereiding van de zogeheten ITIL Intermediate examens (lifecycle- en capability-examens).

Voor lezers die een overzicht willen raadplegen van alle ITIL-termen, zoals gebruikt in dit boek, is een Glossary (verklarende woordenlijst) beschikbaar op www.vanharen.net op de productpagina voor dit boek.

■ 2.1   BASISBEGRIPPEN De rol van de informatievoorziening is gegroeid en veranderd sinds de lancering van ITIL versie 2 (in 2000/2002). IT ondersteunt en maakt deel uit van een toenemend aantal goederen en services. In bedrijven en organisaties is de rol van informatievoorziening eveneens veranderd: de rol van de ITorganisatie is niet meer alleen ondersteunen, maar is uitgegroeid tot het fundament voor het creëren van zakelijke waarde.

ITIL beoogt inzicht te verschaffen in de nieuwe rol van IT in al zijn complexiteit en dynamiek. Daartoe is een nieuwe servicemanagementbenadering uitgewerkt, die niet om processen draait, maar die zich richt op de levenscyclus van een service. Alvorens de servicelevenscyclus te beschrijven, moeten we een aantal basisbegrippen definiëren.

2.1.1 Best practice ITIL wordt gezien als een best practice. Een best practice is een aanpak of methode die zich heeft bewezen in de praktijk. Best practices kunnen een solide steun zijn voor organisaties die hun IT-dienstverlening willen verbeteren. In dergelijke gevallen kan het beste een selectie gemaakt worden uit generieke standaarden en aanpakken die voor iedereen toegankelijk zijn, bijvoorbeeld: ITIL, COBIT, CMMI, PRINCE2® en ISO/IEC 20000. Een van de voordelen van deze vrij beschikbare best practices en frameworks is dat ze kunnen worden toegepast op een groot aantal praktijkomgevingen en situaties.

2.1.2 Service (dienst)

Een service, ook wel dienst genoemd, betreft het creëren van waarde voor de klant. ITIL definieert een service als volgt:

Een service (dienst) is een manier om waarde te leveren aan klanten door klanten in staat te stellen de door hen gewenste resultaten te realiseren zonder zelf eigenaar te zijn van de speci eke kosten en/of de risico’s die verbonden zijn aan de service. De volgende tabel biedt nadere uitleg over bovenstaande definitie.

Tabel 2.1 De nitie van belangrijkste termen in de de nitie van ‘service’ (dienst)

Resultaten worden mogelijk door het uitvoeren van taken en ze worden beperkt door regelgeving, benodigde tijd, geld, menskracht en dergelijke. Services (diensten) verbeteren prestaties en verminderen de druk van beperkingen.

IT-service (dienst) IT-services (diensten) worden geleverd door IT-serviceproviders (dienstverleners). ITIL definieert een IT-service als volgt.

Een IT-service is samengesteld uit een combinatie van informatietechnologie, mensen en processen (people, processes and technology). Een klantgerichte IT-service ondersteunt direct het businessproces van één of meer klanten en de bijbehorende service level targets dienen te worden vastgelegd in een service level agreement. Andere IT-services, die ondersteunende services worden genoemd, worden niet direct gebruikt door de business, maar zijn services die de serviceprovider nodig heeft om klantgerichte services aan te kunnen bieden. Ondersteunende services worden door de serviceprovider afgenomen van in- of externe leveranciers.

Indeling van services ITIL maakt een onderscheid tussen een drietal verschillende groepen van klantgerichte services: kerndiensten (core services), de zogeheten enabling services en de enhancing (prestatieverhogende) services (zie ook tabel 2.2).

Een serviceprovider kan ervoor kiezen om een klein aantal klanten te bedienen met op maat gesneden, unieke services. Hier hangt echter wel een hoog prijskaartje aan vanwege de hoge ontwikkelkosten en specifieke resources. Voor dit type services zullen niet heel veel klanten te vinden zijn. Veel serviceproviders volgen daarom een strategie waarbij ze in staat zijn om meer generieke services te leveren aan een potentieel grote groep van klanten. Op deze wijze kan voldoende schaalgrootte bereikt worden door services te bundelen of in één groep onder te brengen. Op deze wijze biedt de serviceprovider verschillende service packages (servicepakketten) aan haar klanten aan. Een service package is een verzameling van twee of meer services, die samen specifieke business doelstellingen mogelijk maken. Tevens is het mogelijk om een service of een service package aan te bieden met verschillende niveau’ s van utility en warranty. Bijvoorbeeld in de vorm van bronzen, zilveren of gouden service level packages.

Tabel 2.2 Drie soorten klantgerichte services

Utility en warranty van een service Vanuit de klant bekeken is waarde subjectief. Hoewel waarde in de kern bestaat uit het realiseren van zakelijke resultaten, zijn de percepties en voorkeuren van de klant van invloed. Vanuit een serviceprovider gezien wordt de waarde van een service gecreëerd door twee primaire elementen te combineren: utility (geschiktheid voor het doel) en warranty (geschiktheid voor het gebruik). Deze twee elementen werken samen om te zorgen voor de

gewenste resultaten waarop de klant en het bedrijf hun percepties van de service baseren.

Utility is de functionaliteit die wordt geboden door het product of de service om tegemoet te komen aan een bepaalde behoefte. Utility kan worden samengevat als ‘wat de service doet’, of ‘geschikt voor het doel’. Het refereert aan alle aspecten van een service die bijdragen aan taken die verband houden met het realiseren van doelstellingen: het wegnemen van beperkingen en een verhoging in prestatie.

Warranty is de garantie dat een product of service zal voldoen aan de overeengekomen specificaties. Warranty verwijst naar het in staat zijn van een service om wanneer nodig beschikbaar te zijn, de benodigde capaciteit te leveren en te zorgen voor de vereiste betrouwbaarheid in de zin van continuïteit en beveiliging (security). Warranty kan worden samengevat als ‘hoe de service wordt geleverd’ of ‘geschikt voor gebruik’.

2.1.3 Servicemanagement Om services aan te bieden en te leveren, moet de serviceprovider de gehele levenscyclus van de services effectief en efficiënt beheren. Het omzetten van de competenties en middelen van de serviceprovider in waardevolle services is de kern van servicemanagement. Servicemanagement is eveneens een professionele aanpak ondersteund door een uitgebreid kennisgebied, ervaring en competenties.

Afbeelding 2.1 Services: ontworpen, gebouwd en geleverd met zowel utility als warranty (Bron: AXELOS) ITIL formuleert servicemanagement als volgt:

Servicemanagement is een verzameling gespecialiseerde, organisatorische capabilities (= het vermogen om een activiteit uit te voeren) voor het leveren van waarde aan klanten in de vorm van services.

2.1.4 IT-servicemanagement Een IT-organisatie is, per definitie, een dienstverlener (serviceprovider). Zij maakt gebruik van de basisprincipes van servicemanagement om te zorgen voor de succesvolle oplevering van de doelstellingen die de klanten wensen.

Tabel 2.3 IT-servicemanagement en IT-serviceproviders

De IT-serviceprovider moet ITSM effectief en efficiënt gebruiken. Door de IT te beheren op basis van zakelijke uitgangspunten zal de serviceprovider betere organisatorische prestaties genereren en meer waarde creëren.

2.1.5 Serviceproviders Er zijn drie typen serviceproviders. Hoewel bijna alle aspecten van servicemanagement gelden voor alle soorten serviceproviders, zijn er bepaalde aspecten die verschillende betekenissen hebben afhankelijk van het type. Onder deze aspecten vallen zaken als klanten, contracten, concurrentie, markten, inkomsten en strategie.

Tabel 2.4 Soorten serviceprovider

2.1.6 Stakeholders (belanghebbenden) in servicemanagement Een stakeholder is een persoon of een groep die een belang heeft in een organisatie, project, service enzovoort. De drie belangrijkste groepen stakeholders in servicemanagement zijn: klanten, gebruikers en leveranciers, zie tabel 2.5.

Tabel 2.5 Stakeholders (belanghebbenden)

2.1.7 Assets (bedrijfsmiddelen), resources en capabilities Het gebruik van assets (bedrijfsmiddelen) vormt de basis voor de relatie tussen serviceproviders en hun klanten. Tijdens de serviceverlening vindt er een interactie plaats tussen de assets van de serviceproviders en die van de klant.

Tabel 2.6 Soorten assets

Zowel serviceproviders als klanten maken gebruik van resources en capabilities. Resources zijn directe invoer voor productie, ze worden ‘geconsumeerd’ of ‘gemodificeerd’. Volgens ITIL zijn de belangrijkste resources: kapitaal, applicaties, infrastructuur, informatie en mensen. Capabilities verwijzen naar het in staat zijn van een organisatie tot coördineren, controleren en inzetten van resources. Volgens ITIL zitten de capabilities van een organisatie in respectievelijk mensen, kennis, processen, organisatie en management.

■ 2.2   FUNCTIES EN PROCESSEN 2.2.1 Functies Volgens ITIL bestaat servicemanagement in de kern uit een verzameling gespecialiseerde capabilities (kerncompetenties) die een organisatie in de loop der tijd heeft weten te ontwikkelen. Met behulp van deze capabilities kan een IT-serviceprovider waarde leveren aan klanten in de vorm van services. Deze capabilities nemen onder andere de vorm aan van functies en processen. Door het goed inrichten van functies en processen is een IT-serviceprovider in staat services gedurende hun hele levenscyclus te managen.

Het is daarmee belangrijk om het verschil en de samenhang te begrijpen tussen functies en processen. In het Nederlandse taalgebied denken we bij het woord ‘functie’ al snel aan de positie, die iemand in een organisatie heeft (bijvoorbeeld de functie systeembeheerder of IT-architect). Als echter in ITIL het begrip ‘functie’ wordt gebruikt, dan gaat het niet over de positie die iemand in een organisatie heeft. Het gaat dan over te onderscheiden onderdelen van een organisatie die specifieke en essentiele bijdrages leveren

aan de totale organisatie. Of zoals het begrip functie binnen ITIL wordt gedefinieerd:

Een functie is een onderdeel van een organisatie dat gespecialiseerd is in het vervullen van een bepaald soort werk en dat verantwoordelijk is voor speci eke eindresultaten. Functies zijn te onderscheiden groepen of teams met speci eke middelen (tools) die nodig zijn voor het uitvoeren van één of meer processen of activiteiten. Functies hebben hun eigen verzameling tools, taken, rollen, verantwoordelijkheden en een eigen kennisgebied.

De wijze waarop functies een organisatorische vertaling krijgen verschilt per organisatie en hangt af van variabelen als omvang, geschiedenis, type organisatie en cultuur. Veel organisaties hebben een structuur waarin groepen, teams, afdelingen en soms ook divisies te onderkennen zijn.

Tabel 2.7 Opsplitsing van de organisatiestructuur

ITIL onderkent vier noodzakelijk functies die elk een belangrijke rol spelen bij het ontwerpen, testen, in gebruik geven en verbeteren van IT-services, namelijk: 1. de servicedesk, 2. IT-operationsmanagement, 3. technisch management en 4. applicatiemanagement.

Deze functies worden uitvoerig beschreven in hoofdstuk 3. Naast de vier functies worden in ITIL in totaal 26 processen beschreven. De beschrijving van deze processen is in dit boek te vinden in de hoofdstukken 4 tot en met 8.

Tabel 2.8 De vier functies in ITIL

2.2.2 Processen Processen bestaan uit groepen van activiteiten, die uitgevoerd worden om bepaalde doelen te realiseren. ITIL geeft onderstaande definitie van een proces:

Een proces is een gestructureerde verzameling activiteiten die bedoeld is om speci eke doelen te bereiken. Processen resulteren in een doelgerichte verandering en maken gebruik van feedback voor zelfverbetering en zelfcorrigerende maatregelen. In processen worden gerelateerde activiteiten gegroepeerd om daarmee hun uitvoering en prestatie te vereenvoudigen en te verenigen. De kenmerken van de processen worden genoemd en toegelicht in tabel 2.9.

Mensen (en hulpmiddelen) voeren de activiteiten van de verschillende processen uit. Medewerkers, die onderdeel uitmaken van een bepaalde functie zullen in de dagelijkse praktijk activiteiten binnen diverse processen uitvoeren. Medewerkers van de functie servicedesk kunnen bijvoorbeeld betrokken zijn bij processen als incidentmangement, problemmanagement, request fulfilment en changemanagement.

Tabel 2.9 De vier kenmerken van processen

Op zichzelf doen processen niets. Mensen (en hulpmiddelen) voeren de activiteiten van de verschillende processen uit. Uitgaande van de bovenstaande definities, voert een functie (groep) de activiteiten van verschillende processen uit. Een goed voorbeeld van een functie is een servicedesk, een goed voorbeeld van een proces is incidentbeheer.

Bij het regelen van activiteiten in processen kijken we naar de

bedoeling (het

doel) van het proces en de relaties met andere processen. Een proces is een reeks activiteiten die wordt uitgevoerd om invoer in uitvoer om te zetten

invoer betreft de resources die worden gebruikt in het proces. De (gerapporteerde) uitvoer beschrijft de onmiddellijke resultaten van het proces, terwijl het doel de teneinde een bepaald doel te realiseren. De

langetermijnresultaten van het proces (in de zin van betekenisvol effect)

controle activiteiten kunnen we de invoer en uitvoer van elk van de processen koppelen aan beleidsregels en standaardnormen om te aangeven. Door

zorgen voor informatie over de resultaten die moeten worden verkregen met het proces. Door controle wordt de

invoer en de doorvoer gereguleerd in

geval de doorvoer- of uitvoerparameters niet voldoen aan deze standaardnormen en beleidsregels. Hierdoor ontstaan procesketens die de invoer laten zien die de organisatie in gaat en wat het resultaat is. Tevens wordt de kwaliteit van producten en services die de organisatie levert op bepaalde punten in de ketens gecontroleerd.

De standaardnormen voor de uitvoer van elk proces moeten zo worden vastgesteld, dat de gehele procesketen in het procesmodel voldoet aan het uiteindelijke zakelijke doel. Als de uitvoer van een proces voldoet aan de vereisten, is het proces

effectief in het omzetten van invoer in uitvoer. Om

werkelijk effectief te zijn, moet eerder gelet worden op het doel dan alleen te focussen op de uitvoer. Als de activiteiten in het proces eveneens worden uitgevoerd met de minimaal benodigde inspanning en kosten, dan is het

efficiënt. Het is de taak van procesmanagement om met planning en controle te zorgen dat processen op een effectieve en efficiënte manier proces

worden uitgevoerd.

Indien iemand een activiteit binnen een bepaald proces uitvoert, dan doet hij of zij dat vanuit een bepaalde rol. Rollen worden vaak verward met

functieaanduidingen, maar zijn niet hetzelfde. Elke organisatie legt functieaanduidingen en functieomschrijvingen vast (vaak in de vorm van een functiehuis). Personen met een bepaalde functieaanduiding kunnen echter één of meer van de vereiste rollen vervullen.

Rol: Een rol is een verzameling verantwoordelijkheden, activiteiten en bevoegdheden die zijn toegekend aan een persoon of team. Een rol wordt vastgelegd in een proces of functie. Een persoon of team kan meerdere rollen hebben.

2.2.3 Rollen en verantwoordelijkheden Goed presterende organisaties kunnen snel en accuraat tot de juiste beslissingen komen en die met succes uitvoeren. Om dat te bereiken is het cruciaal dat de rollen en verantwoordelijkheden helder zijn vastgelegd.

Een van de mogelijke modellen die in dit opzicht behulpzaam kan zijn, is het RACI-model. RACI is een Engels acroniem op basis van de eerste letter van de vier soorten van verantwoordelijkheid bij een rol:

■ Responsible

(verantwoordelijk) – de persoon of personen die

verantwoordelijk is/zijn voor het verrichten van de activiteit(en).

■ Accountable

(eindverantwoordelijk, rekenschap verschuldigd) – slechts één

persoon is eindverantwoordelijk en geeft goedkeuring aan het resultaat.

■ Consulted (geconsulteerd) – personen die advies geven. ■ Informed (geïnformeerd) – personen die op de hoogte moeten worden gehouden van de voortgang van de activiteiten.

In afbeelding 2.2 zien we een voorbeeld van een ingevuld RACI-model.

Afbeelding 2.2 Voorbeeld van een ingevuld RACI-model Om te komen tot een RACI-systeem, zijn de volgende stappen nodig:

■ Activiteiten en processen identificeren. ■ Functionele rollen identificeren en vastleggen. ■ Bijeenkomsten houden en de RACI-regels uitdragen. ■ Hiaten en mogelijke overlappingen identificeren. ■ De RACI-kaart verspreiden en feedback inbouwen. ■ Zorgen dat de toewijzingen in praktijk worden gebracht. In ITIL wordt een drietal generieke procesrollen onderkend: proceseigenaar, procesmanager en procesuitvoerder. De

proceseigenaar is verantwoordelijk voor het vaststellen van de

procesdoelen, het beleid m.b.t. het proces, de normen waaraan de procesuitvoer moet voldoen, de prestatie-indicatoren, het ter beschikking stellen van de benodigde resources en de procesresultaten. De

procesmanager is verantwoordelijk voor de realisatie en structuur van het

proces. Hij/zij rapporteert aan de proceseigenaar. Hij/zij is verantwoordelijk voor het operationeel management van het proces. De verantwoordelijkheden van een procesmanager zijn: planning en coördinatie van alle activiteiten die

moeten worden uitgevoerd, bewaken van het proces en rapportage over het proces. De

procesuitvoerder is verantwoordelijk voor het correct uitvoeren van

specifieke activiteiten binnen het proces.

Het management van de organisatie kan voorzien in controle op basis van de proceskwaliteit zoals die blijkt uit de resultaatgegevens van elk proces. In de meeste gevallen zal over de relevante

prestatie-indicatoren en

standaardnormen al consensus bestaan. In dat geval kan de procesmanager de dagelijkse controle van het proces uitvoeren. De proceseigenaar zal de resultaten evalueren op basis van een

rapport met prestatie-indicatoren en

gaat na of de resultaten voldoen aan de afgesproken norm. Zonder duidelijke indicatoren zou het voor een proceseigenaar moeilijk zijn te bepalen of het proces onder controle is en of de geplande verbeteringen worden uitgevoerd.

Processen worden vaak beschreven met behulp van

procedures en

werkinstructies. Een procedure is een gespeci ceerde manier om een activiteit of een proces uit te voeren. Een procedure beschrijft het ‘hoe’ en kan ook beschrijven ‘wie’ de activiteiten uitvoert. Een procedure kan stadia omvatten van verschillende processen. Een procedure kan variëren afhankelijk van de organisatie. Werkinstructies geven in detail aan, hoe een of meer activiteiten in een procedure uitgevoerd moeten worden met behulp van technologie of andere resources.

Een proces wordt gezien als een reeks logisch verwante activiteiten die men uitvoert om te voldoen aan een bepaald doel. Processen bestaan uit twee soorten activiteiten: de activiteiten waarmee de doelstellingen worden gerealiseerd (operationele activiteiten die betrekking hebben op de doorvoer) en de activiteiten om deze te managen (controleactiviteiten). Controleactiviteiten zorgen ervoor dat de operationele activiteiten (de werkstroom) tijdig, in de juiste volgorde, enzovoort, worden uitgevoerd. (Bij het doorvoeren van wijzigingen, bijvoorbeeld, wordt altijd gezorgd dat een

test wordt uitgevoerd vóór een versie in productie wordt genomen en niet achteraf.)

Processen en afdelingen De meeste bedrijven zijn hiërarchisch georganiseerd. Er zijn afdelingen die verantwoordelijk zijn voor de activiteiten van een groep medewerkers. Er zijn verschillende manieren om afdelingen te structureren, bijvoorbeeld per klant, product, regio of discipline. IT-services zijn over het algemeen afhankelijk van verschillende afdelingen, klanten of disciplines. Bij een IT-service, bijvoorbeeld, gebruikers toegang geven tot een boekhoudkundig programma op een centrale computer, zullen meerdere disciplines betrokken zijn. Het computercentrum moet het programma en de database toegankelijk maken, de afdeling data- en telecommunicatie moet het computercentrum bereikbaar maken en het PC-ondersteuningsteam moet gebruikers voorzien van een interface voor de toepassing.

Processen, die vaak afdelingsoverstijgend zijn, kunnen de kwaliteit van een service bewaken door aandacht te besteden aan specifieke kwaliteitsaspecten zoals beschikbaarheid, capaciteit, kosten en stabiliteit. Een organisatie die servicegericht werkt, probeert vervolgens die kwaliteitsaspecten in overeenstemming te brengen met de vraag van de klant. De inrichting van dergelijke processen kan ervoor zorgen dat er kwalitatief goede informatie beschikbaar komt over de serviceverlening zodat die services beter te plannen en te sturen zijn.

Processen, projecten, programma’s en portfolio’s Activiteiten kunnen worden gemanaged vanuit een procesperspectief, een organisatorisch hiërarchisch (dus: lijn-)perspectief, een projectperspectief of een combinatie van deze drie. Organisaties die de neiging hebben om slechts een van managementperspectieven toe te passen missen vaak de voordelen van de andere. De praktische keuze hangt vaak af van voorgeschiedenis, cultuur, beschikbare vermogen en competenties, en van persoonlijke voorkeuren.

Welke praktische keuze ook gemaakt wordt, het is in alle gevallen van belang om een helder onderscheid te maken tussen processen, projecten, programma’s en portfolio’s.

De volgende definities worden gebruikt:

■ Proces – Een proces is een gestructureerde verzameling activiteiten die is ontworpen om een bepaald doel te realiseren.

■ Project – Een project is een tijdelijke organisatie met mensen en andere assets, die ‘in het leven is geroepen’ om een bepaalde doelstelling te realiseren.

■ Programma – Een programma bestaat uit een aantal projecten en activiteiten die samen worden gepland en gemanaged om een overkoepeld geheel van met elkaar verwante (strategische) doelstellingen te realiseren.

■ Portfolio – Een portfolio is een verzameling projecten en/of programma’s die niet noodzakelijk aan elkaar verwant zijn en die zijn samengebracht vanwege beheersing, coördinatie en optimalisatie van het portfolio in zijn geheel.

Het meest elementaire verschil tussen een proces en een project is het eenmalige karakter van een project ten opzichte van het continue karakter van het proces. Als een project zijn doelstellingen heeft bereikt, betekent dit het einde van het project. Processen kunnen vele malen worden uitgevoerd, zowel parallel als na elkaar. In de basis is een proces gericht op herhaalbaarheid: processen worden alleen bepaald voor een herhaalbare reeks die belangrijk genoeg is om te worden gestandaardiseerd en geoptimaliseerd.

Projecten zijn gericht op het veranderen van een situatie A een in een situatie B. Dit kan een eenvoudige serie activiteiten betreffen, maar ook een zeer complexe. Andere elementen die van belang zijn voor de projecten zijn onder meer geld, tijd, kwaliteit, organisatie en informatie.

2.2.4 Organisatiecultuur en -gedrag De organisatiecultuur is een verzameling gedeelde waarden en normen die de interacties tussen een serviceprovider en alle stakeholders, inclusief klanten, gebruikers, leveranciers, interne medewerkers, enzovoort beheersen. De waarden van een organisatie zijn gewenste vormen van gedrag die op de cultuur van invloed zijn. Onder organisatiewaarden vallen bijvoorbeeld eerlijkheid, klantvriendelijkheid, respect voor traditie en autoriteit, behoedzaam en zorgvuldig optreden en zuinig zijn.

Beperkingen, zoals governance, normen, waarden, competenties, middelen en ethiek spelen een belangrijke rol in het vormgeven en/of het beïnvloeden van de cultuur en het gedrag van een organisatie. De managementstructuur en stijlen kunnen een positieve of een negatieve invloed hebben op de organisatiecultuur. Organisatiestructuren en managementstijlen zijn ook factoren die bijdragen aan het gedrag van mensen, processen, producten en partners.

Het adopteren/implementeren van een servicemanagementaanpak en het aanpassen daarvan aan de organisatie heeft invloed op haar cultuur, dus is het belangrijk om mensen voor te bereiden met effectieve communicatieplannen, beleid, procedures, opleiding, training, coaching en begeleiding om de houding en het gedrag bij te stellen.

Cultuur, afhankelijk van de normen en waarden van de mensen in de organisatie, kan niet worden afgedwongen, maar is wel beïnvloedbaar. Het beïnvloeden van de cultuur van een organisatie vereist leiderschap in de vorm van een duidelijk en consistent beleid, evenals een ondersteunend personeelsbeleid.

■ 2.3   GOVERNANCE EN MANAGEMENTSYSTEMEN 2.3.1 Governance Met de groeiende rol van informatie, informatiediensten en ITSM groeien ook de eisen aan de besturing (governance) van de IT-organisatie. Deze eisen concentreren zich rond twee aspecten. Het eerste is naleving (compliance) van intern en extern beleid, wetten en regelgeving. Het tweede aspect is het behalen van een toegevoegde waarde (performance) voor de stakeholders bij de organisatie.

Governance: Garandeert daadwerkelijke implementatie van richtlijnen en strategie en dat vereiste processen op de juiste manier worden gevolgd. Governance bevat het de niëren van rollen en verantwoordelijkheden, meten en rapporteren en het in gang zetten van acties om elke geïdenti ceerde kwestie op te lossen.

Governance zorgt voor toepassing van een consistente, beheerste werkwijze op alle niveaus van de organisatie. Dit begint bij het vaststellen van een duidelijke strategie met vastgestelde richtlijnen volgens welke het strategische doel wordt bereikt. De richtlijnen geven grenzen aan: wat valt binnen het bereik en wat buiten het bereik van organisatieactiviteiten.

De International Organization for Standardisation (ISO) introduceerde in 2008 een norm voor IT-governance: ISO/IEC 38500:2008.

2.3.2 Managementsystemen ITIL geeft de volgende definitie van een systeem:

Een systeem is een groep met elkaar verband houdende of onderling afhankelijke componenten die een organisatorisch geheel vormen en samenwerken om een gemeenschappelijk doel te realiseren.

Systemen hebben een zelfregulerende vermogen, waardoor ze wendbaar zijn en zich kunnen aanpassen aan hun omgeving. Belangrijke onderdelen van het systeem zijn de structuur en de samenwerkende processen.

Feedback (terugkoppeling) en leren zijn twee belangrijke aspecten bij de prestaties van systemen. Ze zetten processen, functies en organisaties om in dynamische systemen. Feedback kan leiden tot leren en groei, niet alleen binnen een proces, maar ook binnen een organisatie als geheel.

Binnen een proces is bijvoorbeeld de feedback over de prestaties van een bepaalde procescyclus de input voor de volgende procescyclus. In organisaties kunnen feedbacklussen plaatsvinden tussen processen, functies en fasen van de levenscyclus.

Een serviceprovider kan aanzienlijke voordelen voor klanten realiseren door te begrijpen hoe de eigen organisatie van de klant als systeem functioneert. Waarbij het gaat om de structuur, de relaties tussen componenten en de effecten van veranderingen in de tijd. Voorbeelden van deze voordelen zijn:

■ Aanpasbaarheid aan de voortdurend wisselende behoeften van klanten en markten.

■ Duurzame prestaties.

■ Vastgestelde methode van servicemanagement, risico’s, kosten en waarde. ■ Effectief en efficiënt servicemanagement. ■ Minder conflicten tussen processen en personeel. ■ Minder duplicatie en bureaucratie. Een goed ingericht managementsysteem is een voorwaarde om deze voordelen te kunnen realiseren.

Managementsysteem (ISO 9001): het framework van beleid, processen, functies, standaarden, richtlijnen en instrumenten dat ervoor zorgt dat een organisatie of een deel van een organisatie haar doelstellingen kan bereiken. Een organisatie kan werken met meerdere standaarden, zoals weergegeven in tabel 2.10. Tabel 2.10 ISO-standaarden voor management afgestemd op ITSM

Het ontwikkelen en onderhouden van een kwaliteitssysteem dat voldoet aan de eisen van de ISO 9000-serie (ISO-9000: 2005) kan worden beschouwd als een hulpmiddel voor de organisatie om het systeemgerichte (of ‘beheerd’ in IT Service CMM) groeiniveau te bereiken en onderhouden. Deze ISO-normen geven de definitie, de aanduiding en het ontwerp van processen. Voor ITservicemanagementorganisaties is er een specifieke ISO-norm geïntroduceerd: de ISO / IEC 20000 (zie afbeelding 2.3).

Afbeelding 2.3 Overzicht van het servicemanagementsysteem ISO/IEC 20000

■ 2.4   ORGANISATORISCHE VOLWASSENHEID Vanaf het moment dat

Richard Nolan in 1973 zijn stappenmodel voor de

toepassing van IT in organisaties introduceerde, hebben veel mensen modellen gebruikt voor trapsgewijze ontwikkeling. Deze modellen werden snel erkend als geschikte instrumenten voor kwaliteitsverbetering die organisaties helpen op hun groeipad.

Er bestaat een overvloed aan variaties op het thema, in uiteenlopende vakgebieden van softwareontwikkeling, acquisitie, systeemengineering, softwaretesten, websiteontwikkeling, datawarehousing en beveiligingstechnieken, tot helpdesks en kennismanagement.

Het meest bekende procesvolwassenheidsmodel is het Software Capability Maturity Model (SW-CMM®) dat is ontwikkeld door het Software Engineering Institute (SEI) van Carnegie Mellon University, USA. Het CMM®-model werd overgenomen en toegepast in de meeste van de bovengenoemde gevallen, zodat CMM zoiets als de norm voor

volwassenheidsmodellen werd. Het CMM werd later gevolgd door nieuwe versies, waaronder CMMI® (CMM Integration).

2.4.1 Groeimodel: CMMI In de IT-industrie wordt bij het in kaart en op het op een hoger niveau brengen van de procesvolwassenheid veelal gebruikgemaakt van

Capability

Maturity Model Integration (CMMI). Voor de

trapsgewijze weergave van CMMI zijn vijf volwassenheidniveaus

geformuleerd, elke laag legt de basis voor de volgende fase in de doorlopende procesverbetering, aangeduid met de cijfers 1 tot en met 5 (zie tabel 2.11).

Tabel 2.11 CMMI-volwassenheidniveaus

■ 2.5   VOORDELEN EN RISICO’S VAN ITSMFRAMEWORKS

Voordelen voor de klant/gebruiker:

■ Het leveren van IT-services wordt meer klantgericht en overeenkomsten over servicekwaliteit verbeteren de relatie.

■ De services worden duidelijker (in de taal van de klant) en gedetailleerder beschreven.

■ Het managen van servicekwaliteit, beschikbaarheid, betrouwbaarheid en servicekosten worden verbeterd.

■ De communicatie met de IT-organisatie wordt verbeterd door contactpunten af te spreken.

Voordelen voor de IT-organisatie:

■ De IT-organisatie ontwikkelt een duidelijkere structuur, wordt efficiënter en is meer gericht op de zakelijke doelstellingen.

■ De IT-organisatie krijgt meer controle over de infrastructuur en services waarvoor ze verantwoordelijk is en wijzigingen worden eenvoudiger te beheren.

■ Een effectieve processtructuur levert een raamwerk voor de effectieve outsourcing van elementen van de IT-services.

■ Best practices volgen moedigt een culturele verandering aan wat betreft het leveren van services en ondersteunt de introductie van kwaliteitsmanagementsystemen gebaseerd op de ISO 9000-serie of op ISO/IEC 20000.

■ Frameworks kunnen coherente referentiekaders opleveren voor interne communicatie en communicatie met leveranciers, evenals voor de standaardisatie en identificatie van procedures.

Potentiële problemen/misvattingen:

■ De introductie van ITSM kan lang duren en aanzienlijke inspanning vergen, en kan een verandering van cultuur vragen in de organisatie; een overambitieuze introductie kan leiden tot frustratie omdat de doelstellingen nooit worden bereikt.

■ Als processtructuren een doelstelling op zich worden, kan de servicekwaliteit negatief worden beïnvloed; in dit scenario worden onnodige of al te kunstmatige procedures gezien als bureaucratische obstakels, die waar mogelijk moeten worden vermeden.

■ Verbeteringen in het leveren van services en kostenreducties zijn onvoldoende zichtbaar, omdat er geen vastgestelde beginwaarden beschikbaar waren ter vergelijking en/of er verkeerde doelen waren vastgesteld.

■ Als er onvoldoende wordt geïnvesteerd in de juiste trainingen en ondersteuning, zal er geen recht worden gedaan aan de processen en wordt de service niet verbeterd. Een succesvolle doorvoering vereist immers de betrokkenheid en de inzet van medewerkers op alle niveaus in de organisatie.

■ 2.6   DE SERVICELEVENSCYCLUS ITIL benadert servicemanagement vanuit de levenscyclus van een service. De servicelevenscyclus is een model dat inzicht geeft in:

■ De manier waarop servicemanagement is gestructureerd. ■ De manier waarop de verschillende componenten van de levenscyclus aan elkaar zijn gekoppeld.

■ De impact die wijzigingen in een component zullen hebben op andere componenten en op het totale systeem van de levenscyclus.

De servicelevenscyclus bestaat uit vijf fasen: servicestrategie, serviceontwerp, servicetransitie, serviceproductie en continue serviceverbetering.

Tabel 2.12 De vijf fasen van de servicelevenscyclus

Servicestrategie is de as van de servicelevenscyclus (afbeelding 2.4) die alle andere fasen ‘verbindt’. Dit is de fase waarin verwachtingen, positie, plannen, patronen en beleidsregels worden vastgesteld. De fasen serviceontwerp, servicetransitie en serviceproductie zetten de strategie om in realiteit; hun continue thema is aanpassing en wijziging. De CSI-fase (continue serviceverbetering) staat voor leren en verbeteren, en omvat alle fasen. Deze fase analyseert en initieert verbeterprogramma’s en projecten, en stelt hierin prioriteiten vast op basis van de strategische doelstellingen van de organisatie.

Afbeelding 2.4 De servicelevenscyclus (Bron: AXELOS) Het patroon dat de levenscyclus domineert is de beweging van servicestrategie naar serviceontwerp, servicetransitie en serviceproductie en, vervolgens, door middel van continue serviceverbetering, terug naar servicestrategie enzovoort. In de praktijk vormen alle fasen voor het managen van een bepaalde service een herhalend patroon. Bovendien omvat de cyclus een groot aantal gelijktijdige patronen omdat services binnen organisaties zich al in bepaalde fasen bevinden. Iedere organisatie heeft services in het stadium concept/idee; sommige worden ontworpen (nieuw of gewijzigd), sommige zijn in transitie, sommige zijn in productie en van sommige worden verbetermogelijkheden onderzocht.

De vier functies en de 26 processen hebben allemaal plek gekregen binnen een bepaalde fase van de levenscyclus. Hierbij moeten echter twee kanttekeningen geplaatst worden: 1. Een aantal processen is in feite ondersteunend aan alle of aan meerdere fasen in de levenscylus. Een voorbeeld van zo’n proces is changemanagement dat ondersteuning biedt aan alle fasen, maar geplaatst is in de fase servicetransitie vanwege de cruciale rol die dit proces speelt in de transitie van services van ontwerp naar operationalisering. 2. De vier functies zijn geplaatst in de fase serviceproductie, maar spelen een belangrijke rol in alle fasen van de levenscyclus. Afbeelding 2.5 geeft het volledige overzicht van alle fasen van de levenscyclus met de 26 processen en de 4 functies.

ITIL-bibliotheek De IT Infrastructure Library (ITIL) bestaat uit de volgende delen:

De vijf kernboeken van de servicelevenscyclus ■ Service Strategy (servicestrategie). ■ Service Design (serviceontwerp). ■ Service Transition (servicetransitie).

■ Service Operations (serviceproductie). ■ Continual Service Improvement (CSI, continue serviceverbetering). Aanvullende literatuur Uitgegeven door TSO (de uitgever van de officiële ITIL-publicaties)

■ ITIL Foundation Handbook – pocketboek van de officiële uitgever van ITIL.

■ ITIL Guide to Software Asset Management. ■ ITIL Lite, a road map to full or partial implementation. ■ Designing and transforming IT organizations. ■ Delivering IT Services using ITIL, PRINCE2 and DSDM. ■ Building an ITIL-based Service Management Department. ■ Agile Project and Service Management – Delivering IT Services using PRINCE2, ITIL and DSDM.

■ Secrets of Service Level Management – A process owner's guide.

In ITIL worden vier functies beschreven, zie afbeelding 3.1: 1.

IT-operationsmanagement.

2.

Servicedesk.

3.

Technisch management.

4.

Applicatiemanagement.

Afbeelding 3.1 De vier functies in kaart gebracht

■ 3.1   IT-OPERATIONSMANAGEMENT 3.1.1 Inleiding IT-operationsmanagement is de

functie

die verantwoordelijk is voor het

uitvoeren van de dagelijkse operationele activiteiten. Ze zorgt ervoor dat de IT-service op het overeengekomen niveau wordt geleverd aan de organisatie.

IT-operationsmanagement vervult een dubbele rol:

■ Ze is verantwoordelijk voor de implementatie van activiteiten en prestatienormen die gedefinieerd zijn in de fase serviceontwerp en getest tijdens de servicetransitie. In die zin is deze functie gericht op het handhaven van de stand van zaken, waarbij de stabiliteit van de IT-infrastructuur en de consistentie van IT-services haar belangrijkste taken zijn.

■ Tegelijkertijd is IT-operations onderdeel van het proces dat waarde toevoegt aan de business en het waardenetwerk ondersteunt (zie hoofdstuk 4 Servicestrategie). IT-operations moet in staat zijn zich continu aan te passen aan de eisen en behoeften van de organisatie.

3.1.2 De doelstellingen van IT-operationsmanagement ■ Handhaven van de bestaande situatie om stabiliteit in de processen en activiteiten van de organisatie te bereiken.

■ Continu kritisch onderzoeken of er verbeteringen mogelijk zijn om een betere service tegen lagere kosten te bereiken met behoud van de stabiliteit.

■ Snelle inzet van kennis binnen het domein van IT-operationsmanagement om de operationele storingen te analyseren en op te lossen.

3.1.3 De meetwaarden (metrics) van IT-operationsmanagement IT-operationsmanagement meet zowel de effectieve implementatie van geformuleerde activiteiten en procedures, als de uitvoering van procesactiviteiten. Voorbeelden zijn onder andere:

■ Het percentage succesvolle uitvoeringen van geplande taken. ■ Het aantal uitzonderingen op geplande activiteiten en taken. ■ Proces-metrics, zoals responstijd op events, oplossingstijden voor incidenten, aantal opgemerkte ongeautoriseerde wijzigingen et cetera.

■ Metrics van onderhoudsactiviteiten, zoals het aantal keren dat de beschikbare tijd voor onderhoud is overschreden, het percentage onderhoudswerkzaamheden dat conform het rooster is uitgevoerd et cetera.

■ Metrics gerelateerd aan het facilitymanagement. Denk hierbij aan kosten versus budget gerelateerd aan het onderhoud aan en de beveiliging van gebouwen en dergelijke. En denk aan statistieken met betrekking tot het energieverbruik, het aantal beveiligingsincidenten en de wijze waarop deze incidenten zijn opgelost et cetera.

3.1.4 De documentatie van IT-operationsmanagement

IT-operationsmanagement genereert en gebruikt een aantal documenten, waaronder:

■ Standard Operating Procedures (SOP) – een reeks documenten met gedetailleerde instructies en activiteitenplanningen voor alle IToperationsmanagementteams, -afdelingen of -groepen.

■ Activiteitenlogs – Elke activiteit die wordt uitgevoerd als onderdeel van de IT-operations moet worden geregistreerd om verschillende redenen: •

Bevestigen dat specifieke taken of activiteiten succesvol zijn voltooid.

•

Bevestigen dat een IT-service volgens afspraak werd geleverd.

•

Zorgen voor een basis voor ‘problemmanagement’ om de onderliggende oorzaak van incidenten te onderzoeken.

•

Zorgen voor een basis voor rapportage over de prestaties van IToperationsteams en -afdelingen.

■ Ploegenroosters en -rapporten – Documenten waaruit precies de activiteiten blijken die tijdens een ploegendienst moeten worden uitgevoerd. Er is ook een lijst die alle afhankelijkheden en volgorde van activiteiten kenbaar maakt. Er kunnen meerdere operationele roosters zijn omdat elk team een versie kan krijgen voor de eigen systemen.

3.1.5 De rollen binnen IT-operationsmanagement ■ IT-productiemanager. ■ Ploegleider. ■ IT-productieanalisten. ■ Console operators. ■ Input/output operators. ■ Facility manager. ■ Facility medewerker. 3.1.6 De organisatie van IT-operationsmanagement IT-operationsmanagement wordt gezien als een afzonderlijke functie, maar in veel gevallen dragen medewerkers van het technische en het applicatiemanagement aan deze functie bij. De functie IToperationsmanagement is onderverdeeld in een tweetal subfuncties:

productieactiviteiten en Facilitymanagement. 1. IT-productieactiviteiten

IT-

IT-productieactiviteiten overziet het uitvoeren en monitoren van operationele activiteiten en events binnen de IT-infrastructuur. Deze werkzaamheden vinden veelal plaats vanaf een zogeheten operations bridge. De operations bridge is een centraal coördinatiepunt dat verschillende incidenten en routinematige operationele activiteiten uitvoert en rapporteert over de status of prestatie van technologische componenten.

Op een operations bridge worden alle cruciale observatiepunten in de ITinfrastructuur bijeengebracht, zodat die kunnen worden bewaakt en beheerd vanuit een centrale locatie met minimale inspanning.

De operations bridge-functie combineert meerdere activiteiten zoals het beheren van het bedieningspaneel (console), de afhandeling van incidenten, het eerstelijns netwerkbeheer, de takenplanning en de ondersteuning na de reguliere kantooruren. In sommige organisaties is de servicedesk een onderdeel van de operations bridge.

In aanvulling op het uitvoeren van routinetaken, zoals query’s of rapportages die de teams van het technische en het applicatiemanagement hebben overgedragen, voert IT-productie ook de volgende specifieke taken uit:

■ Consolemanagement, waarbij het erom gaat om op basis van informatie, die afkomstig is van de consoles (bedieningsschermen), eventmanagement, monitoring en controleactiviteiten uit te voeren.

■ Backup- en herstelwerkzaamheden in opdracht van het technisch management en het applicatiemanagement of gebruikers. Sommige organisaties, zoals financiële dienstverleners en beursgenoteerde ondernemingen, moeten een formele backup- en herstelstrategie doorvoeren en bewaken zoals vereist door de wet- en regelgeving. De exacte eisen verschillen per land en per sector. Een organisatie moet haar data beschermen. Dat houdt onder andere in dat er een

backup en opslag van

data moet zijn in gereserveerde locaties waar ze beschermd zijn en, indien nodig, benaderbaar. Een

herstelactie (restore) kan worden geïnitieerd

vanuit verschillende bronnen, variërend van een gebeurtenis (incident/event) die duidt op corruptie van de data tot een service request van een gebruiker of klant. Herstel kan nodig zijn in geval van: •

Corrupte data.

•

Verloren data.

•

Een calamiteitensituatie die de continuïteit van de IT-dienstverlening kan schaden of in gevaar brengen.

•

Historische data vereist voor forensisch onderzoek.

•

Print- en outputwerkzaamheden. Veel serviceproviders leveren hun informatie in papieren (print) of in elektronische vorm (output). De serviceprovider moet zorgen dat de informatie correct is en in de juiste vorm op de juiste plaatsen terechtkomt. Informatiebeveiliging speelt hierin vaak een rol.

• •

Job planning. Het beheren van batch jobs of scripts. Onderhouds- en performance gerelateerde werkzaamheden in opdracht van het technisch management of van het applicatiemanagement.

2. Facilitymanagement Facilitymanagement verwijst naar het beheer van de fysieke omgeving van van de IT-operations en is gewoonlijk ondergebracht in datacenters of computerruimtes. Facilitymanagement heeft twee hoofdtaken: 1. Het beheren van de fysieke IT-omgeving (fysieke toegang, gebouwenbeheer, verlichting, luchtvochtigheid, elektriciteitsvoorziening en dergelijke). 2. De coördinatie van grootschalige consolidatieprojecten: datacenterconsolidatie of serverconsolidatieprojecten.

■ 3.2   SERVICEDESK Een servicedesk is een

functionele eenheid met medewerkers die

verschillende service-incidenten afhandelen. Aanvragen kunnen binnenkomen via de telefoon, het internet of als automatisch gerapporteerde infrastructuurincidenten.

De servicedesk is een belangrijk onderdeel van de IT-afdeling van een organisatie. Het moet het eerste aanspreekpunt zijn voor IT-gebruikers en het verwerkt alle incidenten en service requests. Vaak gebruiken de medewerkers softwaretools om incidenten vast te leggen en te beheren.

3.2.1 Rechtvaardiging en rol van een servicedesk

Veel organisaties beschouwen een servicedesk als de beste bron voor eerstelijns ondersteuning bij IT-problemen. Een servicedesk heeft de volgende voordelen:

■ Verbeterde klantenservice, verbeterd klantbegrip van de service en verbeterde klanttevredenheid.

■ Betere toegankelijkheid vanwege het enkele aanspreekpunt wat betreft de communicatie en informatieverstrekking.

■ Op verzoeken van klanten en gebruikers wordt sneller en beter gereageerd. ■ Verbeterde samenwerking en communicatie. ■ Een verbeterde focus op service en een proactieve servicemethode. ■ Verminderen van negatieve business impact. ■ Verbetering van infrastructuurbeheer en controle. ■ Verbeterd gebruik van resources voor IT-ondersteuning en verhoogde productiviteit van de medewerkers van het bedrijf.

■ Beheerinformatie met meer betekenis als basis voor beslissingen. ■ Een goed carrièrestartpunt voor IT-medewerkers.

3.2.2 Doelen van de servicedesk Het hoofddoel van de servicedesk is de ‘normale dienstverlening’ zo snel mogelijk te herstellen voor gebruikers. Dit kan betekenen het oplossen van een technische storing, het voldoen aan een service request of het beantwoorden van een vraag.

3.2.3 Organisatiestructuur van een servicedesk Een servicedesk kan op vele manieren zijn gestructureerd. De oplossing zal per organisatie verschillen. De belangrijkste opties zijn:

■ Lokale servicedesk. ■ Gecentraliseerde servicedesk. ■ Virtuele servicedesk. ■ Een servicedesk die in zekere zin de zon volgt. ■ Gespecialiseerde servicedeskgroepen. Deze opties zijn hieronder verder uitgewerkt. In de praktijk zal een organisatie werken met een structuur waarin een aantal van deze opties is gecombineerd om aan de bedrijfsbehoeften te voldoen.

De

lokale servicedesk (afbeelding 3.2) is gevestigd op dezelfde locatie of

fysiek dicht bij de gebruikers die worden ondersteund. Hiermee verloopt de communicatie vaak veel soepeler en de zichtbare aanwezigheid is aantrekkelijk voor sommige gebruikers. Een lokale servicedesk is echter kostbaar en kan inefficiënt zijn als het aantal incidenten een eigen servicedesk niet echt rechtvaardigt.

Afbeelding 3.2 Voorbeeld lokale servicedesk (Bron: AXELOS) Er kunnen goede redenen zijn voor een lokale servicedesk:

■ Taalbarrières, culturele en politieke verschillen. ■ Verschillende tijdzones. ■ Gespecialiseerde groepen gebruikers. ■ Bestaan van aangepaste of speciale services waarvoor gespecialiseerde kennis nodig is.

■ Status van de gebruikers.

Het aantal servicedesks kan worden verminderd door deze op één locatie onder te brengen (of door het aantal lokale servicedesks te verminderen). In dat geval worden de medewerkers toegewezen aan een of meer

gecentraliseerde servicedeskstructuren. Dit kan minder kostbaar en efficiënter zijn, omdat minder medewerkers de meldingen (calls) kunnen afhandelen, terwijl het kennisniveau van de servicedesk er waarschijnlijk door stijgt.

Door te werken met technologie, in het bijzonder internet, en met supporttools, is het mogelijk de indruk van een gecentraliseerde servicedesk te wekken, terwijl de servicedeskmedewerkers in werkelijkheid verspreid zijn over een aantal geografisch of structureel gescheiden locaties. In dit geval spreken we van een

virtuele servicedesk (afbeelding 3.3).

Afbeelding 3.3 Voorbeeld van een virtuele servicedesk (Bron: AXELOS) Sommige internationale organisaties combineren graag twee of meer geografisch verspreide servicedesks om een

24/7-service

te kunnen bieden.

Op die manier kan een servicedesk in Azië, bijvoorbeeld, inkomende serviceincidenten afhandelen tijdens kantooruren, waarbij aan het eind van die periode een servicedesk in Europa eventueel nog uitstaande incidenten kan oppakken. Die servicedesk handelt deze service-incidenten samen met de eigen incidenten af. Aan het eind van de werkdag wordt de verantwoordelijkheid overgedragen naar een servicedesk in Amerika, die deze vervolgens overdraagt aan een Aziatische servicedesk, zodat de cirkel rond is.

Het kan voor sommige organisaties aantrekkelijk zijn gespecialiseerde

servicedeskgroepen te creëren, zodat incidenten die samenhangen met een specifieke IT-service direct naar de hierin gespecialiseerde groep worden geleid. Op die manier kunnen incidenten sneller worden opgelost.

De

omgeving van de servicedesk moet zorgvuldig worden gekozen, bij

voorkeur een locatie met voldoende ruimte voor de werkstations en met natuurlijk licht. Stilte en goede akoestiek zijn even zo belangrijk, omdat de medewerkers geen hinder moeten ondervinden van elkaars telefoongesprekken. Ergonomisch verantwoord kantoormeubilair is ook belangrijk.

3.2.4 Servicedeskmedewerkers Er moet op worden toegezien dat het beschikbare

aantal medewerkers

voldoende is, zodat de servicedesk voortdurend kan voldoen aan de vraag vanuit de business. Het aantal service-incidenten kan uiteraard van dag tot dag en van uur tot uur sterk fluctueren. Een organisatie zal rekening houden met piekuren en rustige periodes.

Er moet een beslissing worden genomen over welke competentieniveaus nodig zijn voor de servicedeskmedewerkers. Weeg om het vereiste

competentieniveau te bepalen de ingerichte oplossingstijd af tegen de complexiteit van de ondersteunde systemen en de onkosten die de business bereid is te betalen. De optimale en meest efficiënte methode is gewoonlijk

een eerstelijns ondersteuning via de servicedesk, die de gebeurtenis vastlegt en het incident of servicerequest indien mogelijk zelf afhandelt en anders snel doorzet naar tweedelijns en derdelijns ondersteuningsgroepen met meer expertise.

Als de competentieniveaus zijn bereikt, moet de servicedesk op een zodanige wijze worden aangestuurd dat de medewerkers de mogelijkheid krijgen hun competenties op peil te houden en om ze verder te ontwikkelen. Tijdens alle werkuren moet er een goede combinatie van competenties aanwezig zijn.

Het is essentieel dat alle servicedeskmedewerkers voldoende

training krijgen.

Alle nieuwe medewerkers moeten een formeel introductieprogramma volgen. De precieze inhoud ervan zal variëren per nieuwe medewerker, afhankelijk van bestaande expertise en ervaring.

Om de servicedeskmedewerkers up-to-date te houden, is een programma nodig dat hen geïnformeerd houdt over nieuwe ontwikkelingen, services en technieken. De timing voor dit soort activiteiten is essentieel, want ze moeten de normale taken niet beïnvloeden. Veel servicedesks organiseren korte trainingssessies gedurende stille periodes wanneer de medewerkers minder calls af te handelen hebben.

Het is belangrijk dat alle IT-medewerkers zich bewust zijn van het belang van de servicedesk en de mensen die daar werken. Een aanzienlijk verloop van medewerkers heeft een storend effect en kan leiden tot een onsamenhangende dienstverlening. Dus moeten de managers zich ook inspannen voor het

behoud van medewerkers. Veel organisaties vinden het nuttig een aantal zogeheten

supergebruikers

(super users) te benoemen in de gebruikersgemeenschap. Hun functie is die van contactpersoon voor de IT-organisatie en vooral voor de servicedesk.

3.2.5 De rollen binnen de servicedesk Servicedeskmanager:

■ Stuurt servicedeskactiviteiten aan. ■ Treedt op als escalatiepunt voor teamleiders. ■ Vervult een bredere klantenservicerol.

■ Rapporteert aan het hoger management over kwesties die de business behoorlijk kunnen beïnvloeden.

■ Neemt deel aan vergaderingen van de adviescommissie voor wijzigingen. ■ Is eindverantwoordelijk voor verwerking van incidenten en serviceaanvragen. Teamleider servicedesk:

■ Zorgt dat de personeels- en competentieniveaus op peil blijven. ■ Is verantwoordelijk voor de productie van managementrapportages. ■ Treedt op als escalatiepunt bij lastige calls. Servicedeskanalisten:

■ Leveren eerstelijns ondersteuning bij het ontvangen van calls en het verwerken van de resulterende incidenten of serviceaanvragen via incidenten request fulfillmentprocessen. Super users:

■ Gebruikers die optreden als een verbinding tussen de business en de IT.

3.2.6 Metrics Om de prestaties van de servicedesk regelmatig te kunnen evalueren, moeten er

metrics (meetwaarden) bepaald zijn. Op die manier kan de ontwikkeling of

groei, de efficiëntie, de effectiviteit en het potentieel worden vastgesteld en kunnen de acties van de servicedesk worden verbeterd. Metrics voor de prestatie van een servicedesk moeten voorzichtig en realistisch worden geselecteerd. Voor het bepalen daarvan zijn verdere analyse en meer gedetailleerde metrics nodig die gedurende een bepaalde periode worden onderzocht. Naast de eerder genoemde meetwaarden betreffende het afhandelen van serviceincidenten, bestaan de metrics onder andere uit:

■ Eerstelijns afhandelingstijd: het percentage service-incidenten dat op het eerste niveau wordt opgelost zonder dat escalatie naar andere ondersteuningsteams nodig is.

■ Gemiddelde tijd voor het oplossen van een incident (of ander type call) (indien opgelost op het eerstelijns niveau).

■ Gemiddelde tijd tot het escaleren van een incident (als een eerstelijns oplossing niet mogelijk is).

■ Gemiddelde afhandelingskosten van een incident.

■ Percentage klant- en gebruiker-updates dat wordt uitgevoerd binnen de doelstellingen, zoals omschreven in de SLA-overeenkomst.

■ Gemiddelde tijd tot de evaluatie en het afsluiten van een opgelost incident. Naast het volgen van ‘harde’ metrics in de prestatie van de servicedesk, is het ook belangrijk te werken met ‘zachte’ metrics:

de enquêtes naar

tevredenheid van klanten en gebruikers. Bijvoorbeeld, vinden klanten en gebruikers dat hun telefonische meldingen correct zijn beantwoord? Was de servicedeskmedewerker vriendelijk en professioneel? Het beste is als de gebruiker of klant dit soort metrics levert, maar specifieke vragen over de servicedesk kunnen ook worden gesteld.

■ 3.3   TECHNISCH MANAGEMENT Technisch management verwijst naar de

groepen, afdelingen of teams die

technische expertise en algemeen beheer van de IT-infrastructuur bieden.

3.3.1 De rol van technisch management Technisch management heeft een dubbele rol:

■ Het is de bewaker van technische kennis en expertise met betrekking tot het beheer van de IT-infrastructuur. In deze functie zorgt technisch management ervoor dat de kennis wordt verkregen die nodig is voor het ontwerpen, testen, beheren en verbeteren van IT-services, en dat deze kennis (verder) wordt ontwikkeld en verfijnd.

■ Het zorgt voor de resources die nodig zijn om de levenscyclus van ITservicemanagement te ondersteunen. In deze functie zorgt het technisch management ervoor dat de resources worden opgeleid en doeltreffend worden ingezet, zodat deze het technisch systeem kunnen ontwerpen, bouwen, overdragen, verwerken en verbeteren die nodig is om IT-services te bieden en te ondersteunen.

Door het vervullen van deze twee functies zorgt technisch management ervoor dat de organisatie toegang heeft tot het juiste type en niveau van menselijke resources om het technisch systeem te beheren en dus te voldoen aan de zakelijke doelstellingen.

Technisch management stuurt daarnaast ook IT-operations aan, terwijl het de technologische activiteiten beheert en richtlijnen aan IT-operations verstrekt.

3.3.2 Doelen van technisch management Technisch management assisteert in de planning, implementatie en het onderhoud van een stabiele technische infrastructuur om de zakelijke processen van de organisatie te ondersteunen. Dat gebeurt door:

■ Goed ontworpen en kosteneffectieve technische topologie. ■ Inzetten van de juiste technische competenties om de technische infrastructuur in een optimale conditie te houden.

■ Effectief inzetten van technische competenties om technische storingen snel te analyseren en op te lossen.

3.3.3 Algemene activiteiten van technisch management Technisch management is betrokken bij verschillende algemene taken, zoals:

■ Starten van trainingsprogramma’s. ■ Ontwerpen en uitvoeren van trainingen voor gebruikers, de servicedesk en andere groepen.

■ Onderzoeken en ontwikkelen van oplossingen die de serviceportfolio kunnen helpen uitbreiden, of die kunnen helpen de IT-activiteiten te vereenvoudigen of te automatiseren.

■ Releases die vaak worden doorgevoerd met behulp van technisch managers.

3.3.4 Speci eke activiteiten van technisch management Mainframebeheer Mainframes zijn nog steeds vaak essentiële systemen waar IT-services en de te leveren prestaties van afhankelijk zijn.

Serverbeheer en -ondersteuning De meeste organisaties werken met servers om flexibele en toegankelijke services te leveren voor hostingapplicaties of databases, uitvoeren van cliënt/serverdiensten, opslag, afdruk- en bestandsbeheer.

Het serverteam of de serverafdeling moet de volgende procedures en activiteiten uitvoeren:

■ Ondersteunen van het besturingssysteem.

■ Licentiebeheer voor alle configuratie-items. ■ Tweedelijns ondersteuning. ■ Inkoopadvies. ■ Systeembeveiliging. ■ Definitie en beheer van virtuele servers. ■ Capaciteit en prestatie. Netwerkbeheer Omdat de meeste services afhankelijk zijn van connectiviteit, is netwerkbeheer cruciaal voor de levering van services. Personeel van IToperationsmanagement gebruikt belangrijke servicecomponenten via netwerkbeheer.

Netwerkbeheer is verantwoordelijk voor alle Local Area-netwerken (LAN’s), Metropolitan Area-netwerken (MAN’s) en Wide Area-netwerken (WAN’s) in een organisatie.

Opslag en archiveren Bij veel services moeten data voor een bepaalde tijd worden opgeslagen. Vaak moeten dergelijke data beschikbaar worden gemaakt als een offlinearchief wanneer ze niet langer dagelijks nodig zijn. Dat is niet alleen vanwege het voldoen aan externe wet- en regelgeving, maar ook omdat data om allerlei redenen binnen de organisatie van onschatbare waarde kunnen zijn.

Opslaan en archiveren vraagt niet alleen om beheer van infrastructurele componenten, maar ook om beleidsregels die voorschrijven waar data moeten worden opgeslagen, voor hoe lang, in welke vorm en wie er toegang toe heeft.

Databasemanagement Databasemanagement moet nauw samenwerken met belangrijke applicatiemanagementteams of -afdelingen. In sommige organisaties kunnen deze functies worden gecombineerd of ondergebracht in één beheerstructuur.

Databasemanagement moet zorgen voor optimale databaseprestatie, beveiliging en -functionaliteit. Databasemanagers hebben, onder andere, de volgende verantwoordelijkheden:

■ Ontwerpen en onderhouden van databasestandaarden en richtlijnen.

■ Databaseontwerp, -creatie en testen. Beheer van directory services Een directory service is een gespecialiseerde softwareapplicatie die informatie beheert over de beschikbare resources in een netwerk en voor welke gebruikers die toegankelijk is. Deze service is de basis voor het verschaffen van toegang tot die resources en voor het opsporen en voorkomen van ongeautoriseerde toegang.

Directory services zien iedere resource als een object van de directory server en geven er een naam aan. Elke naam wordt gekoppeld aan een netwerkadres, zodat gebruikers geen verwarrende en complexe adressen hoeven te onthouden.

Werkplekondersteuning Veel gebruikers hebben toegang tot IT-services via een desktop of laptop. Desktopsupport is verantwoordelijk voor alle desktop- en laptop-hardware, software en omgevingsapparatuur in een organisatie. Specifieke verantwoordelijkheden zijn onder andere (tabel 3.1):

Tabel 3.1 Speci eke verantwoordelijkheden van desktopondersteuning

Beheer van middleware Middleware verbindt softwarecomponenten of integreert die met gedistribueerde of afwijkende applicaties en systemen. Middleware maakt effectieve overdracht van data tussen applicaties mogelijk. Om die reden is middleware belangrijk voor services die afhangen van meerdere applicaties of databronnen. Dit is in het bijzonder relevant in de context van servicegeoriënteerde software/architectuur (SOA).

Internet-/webbeheer

Veel organisaties gebruiken internet voor hun bedrijfsactiviteiten en zijn dan ook erg afhankelijk van de beschikbaarheid en prestaties van hun website. In dergelijke gevallen is een afzonderlijk internet-/websupportteam vereist. Dit team heeft, onder andere, de volgende taken:

■ Ontwerpen van de architectuur voor internet- en webservices. ■ Specificeren van standaardnormen voor de ontwikkeling en het beheer van webapplicaties, content, websites en webpagina’s; gewoonlijk in de fase serviceontwerp.

■ Onderhouden van alle applicaties voor de webontwikkeling en het -beheer. ■ Ondersteunen van interfaces met backend- en bestaande systemen. ■ Monitoren en beheren van webprestaties, zoals met gesimuleerde gebruikerservaring, benchmarking en virtualisatie.

3.3.5 De organisatie van technisch management Het beheer van IT-activiteiten bestaat uit een aantal technologische gebieden. Elk gebied vereist een specifiek aantal competenties voor het beheren en bedienen. Sommige competenties zijn aan elkaar verwant zodat generalisten kunnen worden ingezet, terwijl andere specifiek zijn voor een onderdeel, systeem of platform.

Technisch management bestaat uit gespecialiseerde technische architecten, ontwerpers, onderhoudsspecialisten en ondersteunend personeel.

3.3.6 De rollen binnen technisch management Technisch managers/teamleiders:

■ Verantwoordelijk voor het dagelijkse leiderschap, controle en besluiten. Technisch analisten/architecten:

■ Vastleggen en onderhouden van kennis over hoe systemen met elkaar in verband staan en zorgen dat deze afhankelijkheden zijn begrepen. Technische uitvoerders:

■ Uitvoeren van de dagelijkse productietaken.

3.3.7 De metrics voor technisch management Bepaalde metrics voor technisch management hangen in grote mate af van het technisch systeem dat wordt beheerd. Een aantal algemene metrics zijn:

■ Meting van de afgesproken uitvoer.

■ Proceswaarden. ■ Technologische prestaties. ■ Gemiddelde tijd tussen storingen (MTBF, Mean Time Between Failures) van bepaalde apparaten.

■ Metingen van onderhoudsactiviteiten. ■ Training en ontwikkeling van competenties.

3.3.8 De documentatie van technisch management De documentatie van technisch management bestaat onder andere uit:

■ Technische documentatie (handleidingen, beheer- en administratiehandleidingen, gebruikershandleidingen voor configuratieitems – CI’s).

■ Onderhoudsroosters. ■ Inventarisatie van competenties.

■ 3.4   APPLICATIEMANAGEMENT Applicatiemanagement is verantwoordelijk voor het beheren van applicaties gedurende hun levenscyclus. De

functie

applicatiemanagement wordt

uitgevoerd door een afdeling, groep of team betrokken bij het beheer en de ondersteuning van operationele applicaties. Applicatiemanagement speelt ook een belangrijke rol in het ontwerpen, testen en verbeteren van applicaties die deel uitmaken van IT-services.

3.4.1 De rol van applicatiemanagement Applicatiemanagement is voor applicaties wat technisch management is voor IT-infrastructuur. Het speelt een rol in alle applicaties, of die nu aangeschaft zijn of intern ontwikkeld. Een van de belangrijkste beslissingen waaraan wordt meegewerkt, is het aanschaffen dan wel intern ontwikkelen van een applicatie (zie hoofdstuk 5 Serviceontwerp). Wanneer deze beslissing is genomen, speelt applicatiemanagement een tweeledige rol:

■ Bewaken van technische kennis en expertise voor het beheer van applicaties. ■ Voorzien in de daadwerkelijke resources voor de ondersteuning van de levenscyclus van IT-servicemanagement.

Twee andere rollen die worden vervuld door applicatiemanagement zijn:

■ Advies geven aan IT-operations over de beste manier om voortdurend operationeel beheer van applicaties uit te voeren.

■ Integreren van de levenscyclus van applicatiemanagement met de levenscyclus van IT-servicemanagement.

3.4.2 Doelen van applicatiemanagement Applicatiemanagement ondersteunt de bedrijfsprocessen van de organisatie door de functionele en beheervereisten voor applicaties vast te stellen. Een ander doel is het assisteren bij het ontwerpen en doorvoeren van de applicaties en het ondersteunen en verbeteren ervan.

3.4.3 Principes van applicatiemanagement Een van de belangrijkste beslissingen in applicatiemanagement is of een applicatie die de gevraagde functionaliteit ondersteunt moet worden

ontwikkeld of gekocht. De hoogste technische functionaris (CTO, Chief Technical Officer) of de IT-stuurgroep neemt de uiteindelijke beslissing, maar zijn daarbij beide afhankelijk van een aantal informatiebronnen. Als wordt besloten dat de applicatie moet worden ontwikkeld, moet nog worden bepaald of dit door eigen personeel wordt gedaan of dat de ontwikkeling wordt uitbesteed. Dit wordt uitvoerig behandeld in hoofdstuk 5 Serviceontwerp.

3.4.4 De levenscyclus van applicatiemanagement De levenscyclus die wordt gevolgd om de applicatie te ontwikkelen en te beheren kent verscheidene namen, bijvoorbeeld de softwarelevenscyclus (SLC) en de software-ontwikkelingslevenscyclus (SDLC, Software Development Lifecycle). Deze benamingen worden meestal gebruikt door de applicatieontwikkelaars en hun projectmanagers om hun betrokkenheid bij het ontwerpen, ontwikkelen, testen, doorvoeren en ondersteunen van applicaties te bepalen. Voorbeelden van deze methode zijn Structured Systems Analysis & Design Methodology (SSADM) en Dynamic Systems Development Method (DSDM).

Relatie tussen de levenscyclus van applicatiemanagement en de levenscyclus van servicemanagement De levenscyclus van applicatiemanagement is geen alternatief voor die van servicemanagement. Applicaties zijn onderdeel van services en moeten in overeenstemming daarmee worden gemanaged. Niettemin zijn applicaties unieke

combinaties van technologie en functionaliteit en die vereisen speciale aandacht gedurende elke fase van de levenscyclus van servicemanagement. Elke fase van de levenscyclus van applicatiemanagement heeft eigen speci eke doelen, activiteiten, deliverables en teams. Elke fase heeft ook een duidelijke verantwoordelijkheid ervoor te zorgen dat de uitvoer correspondeert met de speci eke doelstellingen van de levenscyclus van servicemanagement. 1. Tijdens de eerste fase worden de vereisten voor een nieuwe applicatie verzameld, gebaseerd op de behoeften van de organisatie. Er zijn zes soorten eisen waaraan een applicatie moet voldoen (tabel 3.2). Het maakt daarbij niet uit of de applicatie in huis of via outsourcing wordt ontwikkeld, of wordt gekocht.

Tabel 3.2 Voorbeeld van eisen

2. In de

ontwerpfase

worden eisen vertaald in specificaties. Ook worden in

deze fase de applicatie en de omgeving of het operationele model waarin de applicatie draait ontworpen. Afwegingen ten aanzien van de architectuur voor het ontwerp en de werking zijn de belangrijkste aspecten van deze fase, want deze kunnen de structuur en inhoud van zowel de applicatie als het operationele model beïnvloeden.

3. In de

bouwfase

worden de applicatie en het operationele model

klaargemaakt om te worden ingezet/uitgerold. Applicatiecomponenten worden geprogrammeerd geïntegreerd en getest. Testen is geen afzonderlijke fase in de levenscyclus hoewel het een afzonderlijke activiteit is. Testen maken een integraal onderdeel uit van ontwikkelen en uitrollen, om de activiteit en uitvoer van die fasen te valideren.

4. In de

implementatiefase

worden het operationele model en de applicatie

ingezet. Het operationele model wordt in de bestaande IT-omgeving opgenomen en de applicatie wordt daar bovenop geïnstalleerd. Hierbij zijn de processen van release- en implementatiebeheer betrokken die zijn beschreven onder Servicetransitie (hoofdstuk 6).

5. Tijdens de

operationele fase

gebruikt de serviceorganisatie de applicatie als

onderdeel van de service delivery die gevraagd wordt door de business. De prestaties van de applicatie in relatie tot de totale service wordt continu gemeten met betrekking tot het servicelevelniveau en de belangrijkste stuureenheden van de business.

6. In de

optimalisatiefase

worden de verkregen prestatie-metrics van het

servicelevelniveau geëvalueerd en geanalyseerd. Mogelijke verbeteringen worden besproken en de nodige ontwikkelingen geïnitieerd. Twee hoofdstrategieën hebben betrekking op onderhouden en iteratief verbeteren van het servicelevelniveau tegen lagere kosten. Dit kan tot een wijziging in de levenscyclus van een applicatie of tot uitfasering ervan leiden. Goede communicatie met gebruikers tijdens deze fase is van groot belang.

3.4.5 Algemene applicatiemanagementactiviteiten Hoewel de meeste applicatiemanagementteams en -afdelingen gewijd zijn aan bepaalde applicaties, hebben ze een aantal activiteiten gemeen. Hieronder vallen:

■ Het vaststellen van de benodigde kennis voor het beheren en draaien van applicaties in de serviceproductiefase.

■ Het initiëren van trainingsprogramma’s om competenties te ontwikkelen en te verfijnen in de juiste resources van applicatiemanagement en het onderhouden van trainingsrapporten voor deze resources.

■ Het definiëren van standaardnormen voor het ontwerpen van nieuwe architectuur en het bepalen van applicatiearchitecturen gedurende servicestrategieprocessen.

■ Het testen, ontwerpen en uitvoeren van de functionaliteit, prestaties en controleerbaarheid van IT-services.

■ Het vaststellen van standaarden voor eventmanagement.

■ Het vaststellen, beheren en onderhouden van attributen en relaties van applicatie-CI’s in het configuratiemanagementsysteem.

Afbeelding 3.4 Voorbeeld levenscyclus van applicatiemanagement (Bron: AXELOS)

3.4.6 De organisatie van applicatiemanagement Hoewel applicatiemanagementafdelingen, -groepen en -teams allemaal vergelijkbare functies vervullen, heeft elke applicatie een eigen verzameling beheer- en productieeisen. Verschillen kunnen onder meer zijn:

■ Het doel van de applicatie. ■ De functionaliteit van de applicatie. ■ Het platform waarop de applicatie draait. ■ Het soort of merk technisch systeem dat wordt gebruikt. Applicatiemanagementteams en -afdelingen zijn meestal georganiseerd op basis van de applicatiecategorie die zij ondersteunen. Voorbeelden van typische applicatiemanagement-organisaties zijn:

■ Financiële applicaties. ■ HR-applicaties. ■ Productieondersteuning.

■ Verkoopondersteuning. ■ Callcenter- en marketingapplicaties. ■ Bedrijfsspecifieke applicaties. ■ IT-applicaties. ■ Webportalen. Van oudsher werken teams/afdelingen voor applicatieontwikkeling en beheer als autonome eenheden. Elk team beheert een eigen omgeving op de eigen manier en ze hebben elk een eigen interface met de business.

3.4.7 De rollen binnen applicatiemanagement Applicatiemanagement heeft twee rollen:

■ De applicatiemanager – houdt toezicht op en is eindverantwoordelijk voor het beheer en de beslissingen die worden genomen.

■ De applicatieanalist/-architect – is verantwoordelijk voor de eisen die overeenkomen met de specificaties van de applicatie.

Applicatiemanagement vereist applicatiemanagers en teamleiders. Zij zijn eindverantwoordelijk voor het leiderschap, de controle en besluiten van het applicatiemanagementteam of -afdeling.

Metrics van applicatiemanagement De metrics van applicatiemanagement zijn voornamelijk afhankelijk van de manier waarop de applicaties worden beheerd, maar algemene metrics zijn onder andere:

■ Metingen van afgesproken uitvoer. ■ Proces-metrics. ■ Prestaties/resultaten van de applicatie. ■ Metingen van onderhoudsactiviteiten. ■ Metingen die duidelijk moeten maken of applicatiemanagementteams goed samenwerken met applicatieontwikkelteams.

■ Metrics met betrekking tot training en ontwikkeling van competenties.

■ 4.1   INLEIDING TOT SERVICESTRATEGIE In dit hoofdstuk worden de processen en activiteiten uiteengezet waarvan effectieve servicestrategie afhankelijk is. Alle processen in deze fase worden uitgebreid beschreven en de belangrijkste elementen van het proces of de activiteit worden besproken.

De processen en activiteiten die in het bijzonder aandacht krijgen in dit hoofdstuk zijn (zie ook afbeelding 4.0):

■ Strategiemanagement voor IT-services. ■ Serviceportfoliomanagement. ■ Financieel management voor IT-services. ■ Demandmanagement. ■ Klantrelatiebeheer.

Afbeelding 4.0 De vijf processen van servicestrategie, gekoppeld aan de ITILlevenscyclus De meeste van deze processen zijn de gehele servicelevenscyclus werkzaam, maar worden in ITIL Servicestrategie behandeld omdat ze centraal staan in effectieve servicestrategie.

4.1.1 Doel en doelstellingen Het doel van servicestrategie is om in staat te zijn het vermogen te ontwikkelen om strategisch voordeel te behalen en te behouden. Dit door het vaststellen van:

■ perspectief; ■ positie; ■ plannen, en: ■ patronen. waar een IT-serviceprovider invulling aan moet kunnen geven om in staat te zijn de door de business gewenste resultaten mogelijk te maken.

Door invulling te geven aan de fase servicestrategie is een organisatie in staat de volgende

doelstellingen te realiseren:

■ Antwoord kunnen geven op de vraag ‘wat is onze strategie?’

■ Vaststellen welke services aan wie aangeboden moeten worden. ■ Zich onderscheiden van concurrenten. ■ Waarde creëren voor de klanten. ■ Kwaliteit van een service definiëren. ■ Bepalen hoe services geleverd moeten worden. ■ Inrichten van de benodigde processen.

4.1.2 Bereik Servicestrategie is bedoeld voor zowel in- als externe IT-serviceproviders. Twee onderwerpen zijn binnen servicestrategie aan de orde:

■ Het definiëren van een strategie, waarbij een IT-serviceprovider services levert om klanten in staat te stellen hun gewenste business-doelstellingen te realiseren (servicestrategie).

■ Het definiëren van een strategie voor hoe die services gemanaged moeten worden (servicemanagementstrategie).

■ 4.2   STRATEGIEMANAGEMENT VOOR IT-SERVICES 4.2.1 Inleiding Strategiemanagement voor IT-services is het proces van het bepalen en onderhouden van perspectief, positie, plannen en patronen van een organisatie met betrekking tot haar services en het managen van die services.

Het

doel van een servicestrategie is te verwoorden hoe een serviceprovider een

organisatie in staat zal stellen haar bedrijfsdoelstellingen te realiseren; het stelt de criteria en mechanismen vast om besluitvorming mogelijk te maken over de vraag welke services geschikt zullen zijn om gewenste bedrijfsdoelstellingen mogelijk te maken en wat vervolgens de meest effectieve en efficiënte manier is om deze services te managen.

De

doelstellingen van strategiemanagement voor IT-services zijn:

■ Analyseren van de interne en externe omgevingen van de serviceprovider, om de kansen die de organisatie ten goede komen te identificeren.

■ Identificeren van (potentiële) beperkingen die het behalen van bedrijfsdoelstellingen, de levering of het managen van services verhinderen

en te identificeren hoe de effecten van beperkingen weggenomen of verminderd moeten worden.

■ Het perspectief van de serviceprovider afstemmen en regelmatig evalueren op doorlopende relevantie. Dit zal de visie- en missieverklaring van de serviceprovider verhelderen.

■ Vaststellen van de positie van de serviceprovider ten opzichte van diens klanten en andere serviceproviders. Dit omvat het in kaart brengen van services die op de markt zijn en het onderhouden van een concurrentievoordeel.

■ Produceren en onderhouden van strategieplanningsdocumenten en ervoor zorgen dat alle stakeholders over bijgewerkte documenten beschikken. Onder deze documenten vallen die van de strategie voor IT, servicemanagementstrategie en de strategie voor elk van de services.

■ Zorgen dat strategische plannen zijn vertaald in tactische en operationele plannen voor elke organisatorische eenheid die betrokken is bij het uitvoeren van de strategie.

■ Managen van veranderingen in de strategieën en bijbehorende documenten om in de pas te blijven met veranderingen in de interne en externe omgevingen.

Bereik Strategiemanagement is de verantwoordelijkheid van het management van een organisatie. Daarmee kunnen zij de doelen van de organisatie vaststellen, specificeren hoe de organisatie deze doelstellingen realiseert en prioriteit toekennen aan de investeringen die daarvoor nodig zijn. De strategie van een organisatie beperkt zich niet tot een enkel document of enkele afdeling. De complete strategie van een organisatie wordt uitgesplitst in een strategie voor elke business unit.

Kernboodschap Een servicestrategie is een deelverzameling van de complete strategie voor de organisatie. Bij een IT-organisatie zal de IT-strategie de IT-servicestrategie omvatten. Opmerking over strategie voor services Strategiemanagement voor IT-services is bedoeld voor het managen van de strategie van een serviceprovider. Het omvat een speci catie van de soorten services die deze serviceprovider zal leveren, de klanten van die services en de algemene

bedrijfsdoelstellingen die moeten worden gerealiseerd wanneer de serviceprovider de strategie uitrolt. De strategie van een afzonderlijke service wordt bepaald tijdens het managementproces van en gedocumenteerd in de serviceportfolio. Dit houdt onder andere in dat de specifieke bedrijfsdoelstellingen worden beschreven, die de service zullen ondersteunen en die mede bepalen hoe de service zal worden geleverd.

Het is verder belangrijk op te merken dat een servicestrategie niet hetzelfde is als een IT-servicemanagementstrategie (ITSM-strategie), wat in feite een tactisch plan is. Het verschil kan als volgt worden samengevat:

■ Servicestrategie

– De strategie die een serviceprovider volgt om services te

definiëren en uit te voeren die voldoen aan de zakelijke doelstellingen van de klant. Voor een IT-serviceprovider is de servicestrategie een deelverzameling van de IT-strategie.

■ IT-servicemanagementstrategie

– Het plan voor het identificeren,

doorvoeren en uitvoeren van de processen waarmee services worden beheerd die zijn aangewezen in een servicestrategie. Voor een IT-serviceprovider is de ITSM-strategie een deelverzameling van de servicestrategie.

Waarde voor de business De strategie van een organisatie verwoordt de doelstellingen en bepaalt hoe deze worden gerealiseerd en hoe wordt nagegaan of deze zijn gerealiseerd. Een goed geformuleerde en uitgevoerde strategie zorgt ervoor dat de resources en mogelijkheden van de organisatie zijn afgestemd op het bereiken van de zakelijke doelstellingen en dat investeringen passen bij de bedoelde ontwikkeling en groei van de organisatie.

Strategiemanagement zorgt ervoor dat alle stakeholders vertegenwoordigd zijn in de besluitvorming over de juiste richting voor de organisatie en dat zij het allemaal eens zijn over de doelstellingen en de middelen waarmee resources, mogelijkheden en investeringen worden geprioriteerd. Strategiemanagement zorgt ook dat het beheer van resources, mogelijkheden en investeringen is afgestemd op realisatie van de strategie.

Verder bevordert strategiemanagement voor IT-services de juiste investeringsniveaus met als mogelijke resultaten:

■ Kostenbesparingen, omdat investeringen en uitgaven zijn afgestemd op het behalen van goedgekeurde zakelijke doelstellingen, in plaats van ongefundeerde verlangens.

■ Verhoogde investeringsniveaus voor belangrijke projecten of serviceverbeteringen.

■ Verschuiving van investeringsprioriteiten. De serviceprovider zal in staat zijn de aandacht bij de ene service weg te halen en zich te richten op een andere, zodat inspanningen en budget worden ingezet in de gebieden met de hoogste zakelijke impact.

4.2.2 Activiteiten, methoden en technieken Het strategiemanagementproces is geïllustreerd in afbeelding 4.1.

Strategiemanagement voor IT-services kent drie hoofdactiviteiten: strategische assessment, strategie generen en strategie-uitvoering.

1. Strategisch assessment In de strategische assessment worden zowel de interne omgeving (de eigen organisatie van de serviceprovider) als de externe omgeving (de wereld waarmee de organisatie van de serviceprovider te maken heeft) geanalyseerd. Deze assessment heeft als resultaat een verzameling doelstellingen, die worden gebruikt voor het vaststellen van de feitelijke strategie.

Strategische assessment: analyse van de interne omgeving

■ Bestaande services. ■ Financiële analyse. ■ Human resources. ■ Productie. ■ Relaties met de business units. ■ Middelen en mogelijkheden. ■ Bestaande projecten. Strategische assessment: analyse van de externe omgeving

■ Industrie- en marktanalyse.

■ Klanten. ■ Leveranciers. ■ Partners. ■ Concurrenten. ■ Wet- en regelgeving. ■ Politiek. ■ Sociaaleconomisch. ■ Technisch systeem. Strategisch assessment: definitie van markten Markten bepalen de kansen voor een serviceprovider om waarde aan zijn klant(en) te leveren. Serviceproviders identificeren kansen door te bepalen welke service-archetypen bij de assets van klanten passen.

Strategisch assessment: identificatie van strategische industriefactoren Voor elk marktgebied gelden kritische succesfactoren die het succes of falen van een servicestrategie bepalen. In de zakelijke literatuur worden deze factoren strategische industriefactoren genoemd (Amit en Schoemaker, 1993). Die worden beïnvloed door klantbehoeften, zakelijke trends, concurrentie, wet- en regelgeving, leveranciers, standaardnormen, best practices van de bedrijfstak en technische systemen.

Afbeelding 4.1 Voorbeeld van een strategiemanagement work ow Strategische industriefactoren hebben de volgende algemene kenmerken:

■ Ze worden omschreven in termen van mogelijkheden en middelen. ■ Ze vormen de belangrijkste succesfactoren van marktleiders. ■ Ze worden bepaald op het niveau van een marktgebied. ■ Ze zijn de basis voor concurrentie tussen rivalen. ■ Ze veranderen in de loop der tijd, dus ze zijn dynamisch en niet statisch. ■ Ze vereisen gewoonlijk behoorlijke investeringen en ontwikkeltijd. Tabel 4.1 Assessment om na te gaan of de bestaande services zich voldoende onderscheiden

Kritieke succesfactoren op zich worden veranderd of beïnvloed door één of meer van de volgende factoren: klanten, concurrenten, partners, leveranciers en toezichthouders.

Strategisch assessment: doelstellingen realiseren De doelstellingen die zijn vastgesteld als uitvoer van de strategische assessment zijn de resultaten die de serviceprovider verwacht te bereiken door de strategie te volgen. Zodra de doelstellingen bepaald zijn, zal de serviceprovider moeten vaststellen hoe de verwachte resultaten bereikt zullen worden. Dit is/zijn de strategie(ën).

Een verzameling richtlijnen die vaak wordt gebruikt om voor de vaststelling van betekenisvolle doelstellingen te zorgen, wordt aangegeven met het

acroniem ‘SMART’. Dit staat voor specifiek, meetbaar, haalbaar (achievable), realistisch en tijdgebonden.

2. Strategie genereren Als de assessment is voltooid en de serviceprovider de doelstellingen van de strategie heeft vastgesteld, is het mogelijk de feitelijke strategie te genereren in termen van de vier P’s: perspectief, positie, plannen en patronen.

Perspectief bepalen Het perspectief van een serviceprovider omschrijft de algemene richting, waarden, overtuigingen en doelen, en, op een hoger niveau, hoe die te bereiken. De meest gebruikelijke vorm van perspectiefbepalingen zijn de missie- en visiestatements. Het visiestatement verwoordt wat de serviceprovider wil bereiken.

Een positie innemen De strategische positie omschrijft hoe de serviceprovider zich zal onderscheiden van andere serviceproviders in de industrie.

Een plan opstellen Een strategisch plan identificeert hoe de organisatie haar doelstellingen, visie en positie zal bereiken. Het plan is een bewuste koers naar de strategische doelen en beschrijft hoe de organisatie van het ene punt naar het andere beweegt in een bepaald scenario.

Actiepatronen tot stand laten komen Een actiepatroon is hoe een organisatie werkt. Formele hiërarchieën tonen één beeld van de organisatie, maar de interacties tussen deze hiërarchieën, de informatie-uitwisseling, het overdragen van eenheden werk en het uitwisselen van geld dragen allemaal bij aan een netwerk van activiteiten, waarin resultaten tot stand komen.

3. Strategie-uitvoering Tactische plannen beschrijven welke benaderingen en methoden worden gebruikt om de strategie te verwezenlijken. Als een strategie antwoord geeft op

de vraag ‘waar gaan we heen?’, dan zal op tactisch niveau een antwoord op de vraag ‘hoe komen we daar?’ gevonden moeten worden.

Andere servicemanagementprocessen Een serviceprovider kan geen strategie uitvoeren zonder in staat te zijn de services te managen die geleverd gaan worden. Servicemanagementprocessen zorgen ervoor dat de serviceprovider zijn services en de gewenste doelstellingen voortdurend op één lijn kan brengen.

Assets op één lijn brengen met klantdoelstellingen Strategie-uitvoering hangt af van de mogelijkheid van de serviceprovider te weten welke serviceassets hij heeft, waar die zich bevinden en hoe die benut kunnen worden.

Kritieke succesfactoren optimaliseren De term ‘kritische succesfactor’ verwijst naar een aspect van de strategie, het proces, het project of het initiatief dat aanwezig moet zijn om te kunnen slagen. Kritieke succesfactoren kunnen bepaalde competenties, hulpmiddelen (tools), omstandigheden, financiën, ondersteuning vanuit het management of de voltooiing van een andere activiteit of project zijn.

Prioriteit toekennen aan investeringen Elke nieuwe service of elk nieuw project heeft financiering nodig. Ken strategische investeringen prioriteit toe op basis van klantbehoeften.

Meten en evalueren Deze fase binnen strategiemanagement wordt uitgevoerd op verschillende terreinen, waaronder:

■ Klanten en gebruikers. ■ Servicemanagementprocessen. ■ Continue serviceverbetering. ■ Het management van de organisatie. Serviceproviders moeten zich realiseren dat zij in veel gevallen niet in staat zullen zijn te meten wat belangrijk is voor de klant. In deze gevallen is het van belang dat de klant verantwoordelijkheid neemt voor de uitvoering van de

meting en dat de serviceprovider bereid is te voorzien in een passend antwoord voor eventuele uitzonderingen.

Meten en evalueren: continue serviceverbetering (Continual Service Improvement (CSI)) Onder de CSI-activiteiten vallen het meten en evalueren – aan de hand van die metingen – in hoeverre de strategie is verwezenlijkt. Men identificeert die gebieden die niet volgens verwachting presteren en daarmee de realisatie van de strategie bedreigen. Aan de hand van deze assessment wordt een (nieuwe) baseline vastgesteld die dient als referentiepunt voor de volgende assessmentronde. CSI is een iteratief proces. Omdat zowel de omgeving (markt) waarin een bedrijf actief is, als het bedrijf zelf, voortdurend aan veranderingen onderhevig zijn, moet de strategie continu geëvalueerd en eventueel bijgesteld of herzien worden.

Meten en evalueren: expansie en groei Als de organisatie haar bestaande strategie verwezenlijkt, is ze beter in staat de services te leveren aan haar bestaande markten.

4.2.3 Strategiemanagement voor interne IT-serviceproviders Interne IT-organisaties maken vaak de fout te denken dat zij geen strategische rol spelen in de organisatie en dat zij hun activiteiten moeten beperken tot tactische planning en uitvoering. IT is echter een strategisch onderdeel van de meeste organisaties en het is belangrijk dat de IT-organisatiestrategie nauw aansluit bij de bedrijfsstrategie.

Strategisch assessment voor interne serviceproviders Strategisch assessment is vergelijkbaar met het strategiemanagementproces dat hierboven is beschreven, echter met dit verschil dat men bij de strategische assessment zowel de interne als de externe omgeving van de IT-organisatie heel nauwkeurig in kaart brengt. Het doel van de strategische assessment is om de huidige situatie van de IT-organisatie te bepalen.

De interne omgeving die moet worden geëvalueerd door IT-organisaties omvat:

■ De bedrijfsstrategie van de organisatie. ■ Bestaande services.

■ Bestaande technologieën. ■ IT-servicemanagement. ■ Human resources. ■ Relatie met de business units. De externe omgeving die moet worden geëvalueerd door IT-organisaties omvat in het bijzonder:

■ Andere organisaties. ■ Uitgaven aan IT door bedrijven. ■ Leveranciersstrategieën en productplannen. ■ Partners. ■ Technologietrends. ■ Klanten. ■ Standaarden of wettelijke eisen voor IT. ■ Productie. ■ De relatie tussen applicatieontwikkeling en productie.

4.2.4 Informatiemanagement ■ Informatie over de externe omgeving. ■ Resultaten van assessments van de interne omgeving. ■ Informatie over de behoeften van de klant, tevredenheidsniveaus, huidige capaciteit van de dienstverlening (servicecapaciteit) en prestatieniveaus.

■ Strategiebeheer van IT-servicedocumentatie. ■ De serviceportfolio. ■ Financieel management. ■ Klantrelatiebeheer. ■ Demandmanagement. ■ Continue serviceverbetering.

4.2.5 Interfaces ■ Het leveren van de richtlijnen en het framework waarbinnen de serviceportfolio wordt vastgesteld en gemanaged.

■ Het leveren van input aan het financieel management om de vereiste soorten rendement te bepalen en de investeringen te prioriteren.

■ Het identificeren van beleidsregels waarmee rekening moet worden gehouden bij het ontwerpen van services.

■ Servicetransitie in staat stellen de ontworpen/ontwikkelde services te prioriteren en te evalueren om ervoor te zorgen dat die voldoen aan de oorspronkelijke bedoeling en strategische eisen van die services.

■ Continue serviceverbetering helpt om te kunnen evalueren of de strategie effectief is uitgevoerd en of de doelen zijn verwezenlijkt.

4.2.6 Aanleidingen (triggers) ■ Jaarlijkse planningscycli. ■ Nieuwe zakelijke kans. ■ Kansen in interne of externe omgevingen. ■ Fusies of overnames. 4.2.7 Invoer ■ Bestaande plannen. ■ Onderzoek aan aspecten van de omgeving door gespecialiseerde onderzoeksorganisaties.

■ Leveranciersstrategieën en productplannen. ■ Klantinterviews en strategische plannen. ■ Serviceportfolio om de huidige en geplande toekomstige verbintenissen voor de dienstverlening aan te geven.

■ Servicerapportage om de effectiviteit van de strategie aan te geven. ■ Auditverslagen die aangeven dat wordt voldaan aan (of afgeweken van) de strategie van de organisatie.

4.2.8 Uitvoer ■ Strategische plannen. ■ Tactische plannen die aangeven hoe de strategie uitgevoerd zal worden. ■ Missie- en visiestatements. ■ Beleid ten aanzien van de wijze waarop de plannen moeten worden uitgevoerd en services moeten worden ontworpen, overgezet, bediend en verbeterd.

■ Strategische eisen voor nieuwe services.

4.2.9 Kritieke succesfactoren ■ Toegang tot gestructureerde informatie over de interne en externe omgevingen.

■ Identificatie en eliminatie van beperkingen voor de serviceprovider om zakelijke doelstellingen te realiseren en services te leveren en beheren.

■ Een duidelijk begrip van het perspectief, de posities, de patronen en de plannen van de organisatie.

■ De mogelijkheid strategieplanningsdocumenten te produceren, te bewaren, onderhouden en communiceren.

■ De mogelijkheid strategische plannen te vertalen in tactische en operationele plannen.

4.2.10 Metrics ■ Voor elk marktgebied bestaat gedocumenteerd bewijs. ■ Elke bevinding of aanbeveling is gebaseerd op getoetste informatie. ■ Voorspellingen en bevindingen afkomstig van extern onderzoek zijn getoetst.

■ Aantal corrigerende acties dat is uitgevoerd om beperkingen weg te nemen en wat het resultaat van die acties is op het realiseren van strategische doelen.

■ Missie- en visiestatements zijn geformuleerd en gecommuniceerd aan alle medewerkers.

■ Elke service in de serviceportfolio heeft een statement waaruit blijkt aan welke zakelijke doelstellingen wordt voldaan, en die doelstellingen worden gemeten.

■ Stakeholders kunnen een overzicht leveren van de inhoud van de strategiedocumenten die relevant zijn voor hun business unit.

■ Op alle documenten wordt documentcontrole uitgevoerd en op wijzigingen in de documenten heeft de juiste wijzigingencontrole plaatsgevonden.

■ Afwijkingen van activiteiten en patronen zijn geïdentificeerd in de strategie.

4.2.11 Uitdagingen ■ Accurate informatie over de externe omgeving. ■ Steun van stakeholders. ■ Geschikte hulpmiddelen of begrip van het gebruik van de tools en technieken.

■ Geschikte documentcontrolemechanismen en –procedures. ■ Operationele doelen moeten in overeenstemming worden gebracht met de strategische doelen.

4.2.12 Risico’s ■ Een gebrekkig governance model. ■ Strategiemanagement voor IT-services wordt uitgevoerd op het verkeerde niveau in de organisatie.

■ Korte-termijnprioriteiten hebben voorrang op strategische doelen en richtlijnen.

■ Strategische beslissingen nemen terwijl informatie over de interne of externe omgevingen ontbreekt of niet is gevalideerd.

■ De verkeerde strategie kiezen. ■ Strategieën worden als een oefening gezien die een keer in het jaar plaatsvindt en geen gevolgen heeft voor wat er de rest van het jaar gebeurt.

■4.3 SERVICEPORTFOLIOMANAGEMENT 4.3.1 Inleiding Een serviceportfolio beschrijft de services van een serviceprovider in termen van zakelijke waarde. De zakelijke behoeften en het antwoord van serviceproviders op die behoeften worden verwoord. Per definitie corresponderen de termen van zakelijke waarde met die van marketing, wat een middel is voor het vergelijken met het servicecompetitievermogen van alternatieve aanbieders. Een serviceportfolio verheldert de volgende strategische vragen of helpt die te verhelderen:

■ Waarom zou een klant deze services kopen? ■ Waarom zou een klant de services bij ons kopen? ■ Wat zijn de prijs- of verrekenmodellen? ■ Wat zijn onze sterktes en zwaktes, prioriteiten en risico’s? ■ Hoe zouden onze resources en capaciteiten moeten worden toegewezen? De serviceportfolio is de volledige verzameling services die door een serviceprovider worden beheerd. De serviceportfolio wordt gebruikt om de gehele levenscyclus van alle services te beheren. Drie categorieën services maken er deel van uit: services in de pijplijn (voorgesteld of in ontwikkeling), servicecatalogus (live of beschikbaar om in te zetten) en stopgezette services. De serviceportfolio vertegenwoordigt de investering die is gedaan in de services van een organisatie en verwoordt ook de waarde die services helpen realiseren.

Serviceportfoliomanagement is verantwoordelijk voor het managen van de serviceportfolio. Daarom is het ook het proces dat verantwoordelijk is voor het bepalen welke services in de serviceportfolio worden opgenomen en hoe die services worden gemonitord gedurende hun levenscyclus. Met andere woorden, serviceportfoliomanagement treedt op als een poortwachter voor de serviceprovider, en ziet erop toe dat alleen die services worden geleverd die bijdragen aan strategische doelstellingen en die voldoen aan de afgesproken zakelijke doelstellingen.

Het

doel van serviceportfoliomanagement is om erop toe te zien dat de

serviceprovider de juiste mix van services levert tegen de juiste prijs. Immers de investering in de services moet zich terugverdienen en uiteindelijk vertalen naar de gewenste zakelijke doelstellingen. Om dit te bereiken moeten de services, evenals de koppeling met het gewenste businessresultaat, helder zijn omschreven. Of de services ook opleveren wat beoogd is, wordt gemonitord. Serviceportfoliomanagement doet dit door de investeringen in de services te volgen over de gehele levenscyclus van deze services.

De

doelstellingen van serviceportfoliomanagement zijn:

■ Voorzien in een proces en mechanismen om een organisatie in staat te stellen onderzoek te doen naar en te beslissen over de te leveren services.

■ Onderhouden van definitieve portfolio van services die worden geleverd. ■ Voorzien in een mechanisme dat de organisatie in staat stelt te evalueren hoe services haar in staat stellen de strategie te verwezenlijken.

■ Controleren welke services worden geleverd, onder welke voorwaarden en op welk investeringsniveau.

■ Volgen van investeringen in services gedurende de levenscyclus ervan. ■ Analyseren welke services niet meer levensvatbaar zijn en wanneer zij gestopt moeten worden.

Bereik Onder het bereik van serviceportfoliomanagement verstaan we de services die de serviceprovider van plan om is leveren, services die de serviceprovider op dit moment levert en services die uitgefaseerd zijn. De primaire taak van serviceportfoliomanagement is om erop toe te zien dat de services, die de

serviceprovider levert, daadwerkelijk (toegevoegde) waarde creëren voor de serviceprovider.

Waarde voor de business Serviceportfoliomanagement stelt de business in staat verstandige beslissingen te nemen over investeringen. De klanten zijn in staat om te beoordelen of de service een goede of slechte investering is en de potentiële extra kansen te evalueren. Daarmee is dit portfoliomanagement een innovatie-instrument (tool) voor de organisatie. De serviceprovider wordt gezien als een rentmeester van serviceassets die belangrijk zijn voor het succes van de klant.

4.3.2 Beleidsregels, principes en basisbegrippen De serviceportfolio is een verzameling services die wordt gemanaged door een serviceprovider. De serviceportfolio identificeert ook de services die in een conceptueel stadium verkeren, namelijk alle services die de organisatie zou leveren als deze onbeperkte resources, mogelijkheden en financiële middelen had.

Afbeelding 4.2 Serviceportfoliorelaties (Bron: AXELOS) De serviceportfolio vertegenwoordigt alle resources die betrokken zijn bij of worden vrijgegeven in verschillende stadia van de servicelevenscyclus. Elke fase

vereist resources voor voltooiing van projecten, initiatieven en contracten. Dit is een heel belangrijk governance-aspect van serviceportfoliomanagement.

Servicepijplijn De servicepijplijn is een database of gestructureerd document met alle services die worden overwogen of ontwikkeld, maar nog niet beschikbaar zijn voor klanten. Ook grote investeringskansen maken er deel van uit. De servicepijplijn levert een zakelijk overzicht van mogelijke toekomstige services en is een deel van de serviceportfolio doe gewoonlijk niet voor klanten wordt gepubliceerd.

Servicecatalogus De servicecatalogus is een database of gestructureerd document met informatie over alle operationele IT-services met inbegrip van die welke beschikbaar zijn voor distributie. De servicecatalogus is het enige deel van het serviceportfolio dat wordt vrijgegeven aan klanten en wordt gebruikt om de verkoop en levering van IT-services te ondersteunen. De servicecatalogus bevat informatie over af te nemen services (deliverables), prijzen, contact- en besteldata.

Items kunnen pas in de servicecatalogus komen nadat due diligence (boekenonderzoek) is uitgevoerd op kosten en risico’s. Alleen operationele services zijn te vinden in de servicecatalogus en resources worden ingezet om actieve services volledig te ondersteunen.

Bovendien dient de servicecatalogus als een kanaal voor bestelling en aanbod. En ook de communicatie over het beleid, de richtlijnen en de verantwoording (de input/informatie die de serviceprovider nodig heeft om services te leveren en ondersteuning te bieden aan zijn klanten) wordt gevoerd via de servicecatalogus.

Afbeelding 4.3 illustreert de volgende verbanden:

■ De blokjes aan de linkerkant zijn serviceassets die door de serviceprovider worden gebruikt voor het leveren van services. Dit kunnen servers, databases, applicaties, netwerkapparaten en dergelijke zijn.

■ Services in de servicecatalogus. Er zijn twee lagen services in afbeelding 4.3. De laag aan de linkerkant toont ondersteunende services, die meestal niet

rechtstreeks worden gezien door de klant (die in het overzicht van de servicecatalogus de technische of ondersteunende servicecatalogus wordt genoemd). De tweede laag van de services zijn klantgerichte services.

■ De blokjes aan de rechterzijde zijn zakelijke resultaten die het bedrijf behaalt wanneer het gebruikmaakt van deze services.

Afbeelding 4.3 De Servicecatalogus en verbanden tussen services en doelstellingen (Gebaseerd op bron: AXELOS)

Uitgefaseerde services Sommige services in de serviceportfolio zijn uitgefaseerd of gestopt. Er moet na een service-assessment door elke organisatie een beslissing worden genomen wanneer een service moet worden verplaatst van catalogus naar gestopt. Dit is noodzakelijk omdat dergelijke services veel kosten aan ondersteuning met zich mee kunnen brengen en schaal- en bereikvoordelen kunnen verstoren.

Serviceportfoliomanagement zal een beleid formuleren voor hoe lang een services in de serviceportfolio blijft. Dat wordt uitgedrukt in tijd, of hoeveel

alternatieven er beschikbaar zijn in de servicecatalogus. Uitgefaseerde services worden beheerd via servicetransitie.

Configuratiemanagementsysteem Het configuratiemanagementsysteem (CMS) is een verzameling tools en databases die kunnen worden gebruikt voor het beheren van de configuratiegegevens van een IT-serviceprovider. Het CMS omvat ook informatie over incidenten, problemen, bekende fouten (known errors), wijzigingen en releases, en kan data bevatten over medewerkers, leveranciers, locaties, business units, klanten en gebruikers. Het CMS bevat tools voor het verzamelen, opslaan, beheren, bijwerken en presenteren van data van alle configuratie-items en hun relaties.

Applicatieportfolio De applicatieportfolio is een database of gestructureerd document en wordt gebruikt om applicaties gedurende hun levenscyclus te beheren. De applicatieportfolio bevat de belangrijke attributen van alle applicaties.

Klantportfolio De klantportfolio is een database die, of een gestructureerd document dat, wordt gebruikt om alle klanten van de IT-serviceprovider vast te leggen. De klantportfolio is bedoeld voor de klantrelatiebeheerder en bevat een overzicht van de services die klanten ontvangen van de IT-serviceprovider.

Klantovereenkomstenportfolio De klantovereenkomstenportfolio is een database die, of gestructureerd document dat, wordt gebruikt om servicecontracten of -overeenkomsten tussen een IT-serviceprovider en zijn klanten te beheren. Voor elke IT-service die aan een klant wordt geleverd, moet er een contract of andere overeenkomst zijn opgenomen in de klantovereenkomsten-portfolio.

Projectportfolio Het projectportfolio is een database die, of gestructureerd document dat, wordt gebruikt om gestarte projecten te beheren. De projectportfolio wordt gebruikt om projecten te coördineren, te zorgen dat doelen tijdig, binnen begroting en volgens de specificaties worden behaald, dat projecten niet

dubbel worden uitgevoerd, dat ze binnen het afgesproken bereik blijven en dat resources beschikbaar zijn voor elk project. Het projectportfolio is de tool die wordt gebruikt voor zowel het managen van afzonderlijke projecten als grootschalige programma’s, bestaande uit meerdere projecten.

Opstartverklaring (charter): een document dat het project autoriseert en het bereik, de voorwaarden en referenties kenbaar maakt.

Servicemodellen Serviceportfoliomanagement gebruikt servicemodellen om de impact te analyseren van nieuwe services of wijzigingen in bestaande diensten. Als er geen servicemodel bestaat voor een service in de pijplijn, zorgt serviceportfoliomanagement ervoor dat er een wordt geformuleerd. Een servicemodel toont hoe door de wisselwerking tussen serviceassets en customer assets waarde gecreëerd kan worden. Servicemodellen beschrijven de structuur van een service ‘hoe configuratie-items samenhangen’ en de dynamiek van een service (activiteiten, inzet van middelen en interacties).

Marktgebieden en groei van services Marktgebieden helpen serviceportfoliomanagement de impact van een voorgestelde nieuwe service of wijziging in een bestaande service te evalueren, omdat de analyse van een marktgebied duidelijk maakt of en hoe succesvol het leveren van services binnen dat marktgebied kan zijn.

Serviceassets, services en zakelijke doelstellingen op één lijn brengen Serviceportfoliomanagement speelt een belangrijke rol in het bereiken van het op één lijn brengen van serviceassets, services en zakelijke doelstellingen, omdat de serviceportfolio en het configuratiemanagementsysteem (CMS) de relaties tussen zakelijke doelstellingen, services en serviceassets documenteren.

4.3.3 Serviceportfoliomanagement gedurende de levenscyclus van services Servicestrategie

Hoewel serviceportfoliomanagement een proces binnen servicestrategie is, speelt het een belangrijke rol in elke fase van de levenscyclus van services.

Serviceontwerp In serviceontwerp zorgt serviceportfoliomanagement dat ontwerpwerkzaamheden geprioriteerd worden in overeenstemming met de zakelijke behoeften en dat er een helder begrip is van hoe de service gemeten zal worden door de business.

Servicetransitie Servicetransitie bouwt en test de services die in de servicecatalogus opgenomen gaan worden. De serviceportfolio biedt een leidraad voor servicetransitie in het bouwen, testen en evalueren van de service. Autorisatie vanuit changemanagement is nodig om een service in de servicecatalogus op te nemen.

Serviceproductie Serviceproductie levert de service in het servicecatalogusdeel van de serviceportfolio. Serviceportfoliomanagement verschaft serviceproductie (service operation) duidelijkheid over de service en informatie over hoe en waarom deze geleverd moeten worden.

Continue serviceverbetering De continue serviceverbetering evalueert of de services in het portfolio voldoen aan de gestelde doelen en identificeert als dat niet zo is de manieren waarop de situatie kan worden rechtgezet. Continue serviceverbetering evalueert ook de business cases en doelstellingen om vast te stellen in hoeverre die nog gelden en zorgt daarmee dat serviceportfoliomanagement services voortdurend op de juiste wijze prioriteert.

4.3.4 Activiteiten, methoden en technieken De activiteiten van serviceportfoliomanagement kunnen we indelen in vier hoofdfasen, te weten: preciseren, analyseren, goedkeuren en opstarten (zie afbeelding 4.4).

Afbeelding 4.4 Een werkstroom in serviceportfoliomanagement (Gebaseerd op bron: AXELOS)

Procesinitiatie Nieuwe services en wijzigingen in bestaande services kunnen worden geïnitieerd vanuit een aantal bronnen en in een aantal verschillende vormen. Wijzigingen in plannen of de identificatie van een serviceverbeterplan kan deze activiteit vaak triggeren.

De input voor het proces kan achtereenvolgens komen uit: 1. Strategiemanagement voor IT-services. 2. Klantrelatiebeheer. 3. Continue verbetering van services. 4. Andere servicemanagementprocessen.

Procesactiviteiten In het proces zelf vinden de volgende activiteiten plaats.

1. Preciseren

Deze activiteit betreft het vaststellen van gewenste zakelijke doelstellingen, kansen, utility- en warranty-eisen en de services zelf, alsmede de investeringen die nodig zijn om deze wensen te realiseren.

2. Analyseren De analyse van nieuwe of gewijzigde services in de overgang tussen levenscyclusfasen wordt uitgevoerd door de service te koppelen aan de servicestrategie. Bij externe serviceproviders gaat het bij deze analyse om de koppeling met de overallstrategie van de organisatie. Bij interne serviceproviders betreft het de koppeling tussen de IT-strategie en de strategieën van de andere business units.

3. Goedkeuren: wijzigingsvoorstel (changevoorstel) Op basis van het wijzigingsvoorstel kan changemanagement de activiteiten coördineren die nodig zijn om de eisen van de klant- en infrastructuur te onderzoeken. Tevens kan changemanagement in relatie tot andere geautoriseerde wijzigingen die worden gebouwd, getest en doorgevoerd, zorgen voor de prioritering van de uit te voeren activiteiten en de menskracht en middelen die daarvoor nodig zijn.

4. Service-opstartdocument (servicecharter) De servicecharter zorgt dat alle stakeholders, ontwikkel-, test- en productiemedewerkers een gemeenschappelijk begrip hebben van de kosten, tijdlijnen, deliverables en wie erbij betrokken is.

Afbeelding 4.5 Voorbeeld van de inhoud van een serviceportfolio (Bron: AXELOS)

4.3.5 Informatiemanagement ■ De serviceportfolio, servicepijplijn, servicecatalogus en uitgefaseerde services. ■ De projectportfolio. ■ De applicatieportfolio. ■ De klantportfolio. ■ De klantovereenkomstenportfolio. ■ Servicemodellen. ■ De servicestrategie. ■ Het configuratiemanagementsysteem.

4.3.6 Interfaces ■ Bepalen welke services in de servicecatalogus worden geplaatst terwijl servicecatalogusmanagement alle activiteiten uitvoert die hiervoor nodig zijn.

■ Strategiemanagement voor IT-services – De algemene servicestrategie en doelstellingen voor investeringen formuleren.

■ Financieel management voor IT-services – Informatie en tools leveren waarmee serviceportfoliomanagement ROI-calculaties (return on investment) kan uitvoeren.

■ Demandmanagement – Informatie leveren over de patronen van de bedrijfsactiviteit.

■ Klantrelatiebeheer – Initieert aanvragen en verkrijgt zakelijke informatie en eisen.

■ Servicelevelmanagement – Zorgt dat services de vastgestelde prestatieniveaus kunnen behalen.

■ Capaciteits- en availabilitymanagement – Zorgt dat de capaciteits- en beschikbaarheidseisen van chartered services worden ontworpen en gebouwd.

■ IT service continuity management – Om de zakelijke impact te identificeren van risico’s die gepaard gaan met het leveren van services en om tegenmaatregelen en herstelplannen te ontwerpen.

■ Information security management – Om te zorgen voor de vereiste vertrouwelijkheid, integriteit en beschikbaarheid.

■ Leveranciersmanagement – Om aan te geven dat een leverancier niet langer services kan leveren of dat een relatie met een toeleverancier risico loopt.

■ Changemanagement – Om de resources te evalueren die nodig zijn om nieuwe services of wijzigingen in bestaande services te introduceren.

■ Serviceasset & configuratiemanagement – Om te zorgen voor de tools, informatie en data waarop de serviceportfolio is gebaseerd.

■ Servicevalidation & testing – Om te zorgen dat de verwachte functionaliteit en doelstellingen van elke service kunnen worden bereikt.

■ Kennismanagement – Om IT-managers en -architecten in staat te stellen weloverwogen beslissingen te nemen over de beste serviceopties.

■ Continue serviceverbetering – Voor feedback over het werkelijke gebruik en de werkelijke ROI van services afgezet tegen het verwachte gebruik en de

verwachte ROI.

4.3.7 Aanleidingen (triggers) ■ Een nieuwe strategie is opgesteld, of een bestaande strategie is gewijzigd. ■ Klantrelatiebeheer ontvangt een aanvraag voor een nieuwe service of een wijziging in een bestaande service.

■ Serviceverbeterkansen vanuit continue serviceverbetering. ■ Feedback vanuit ontwerp-, bouw- of transitieteams. ■ Assessments van servicelevelmanagement. ■ Financieel management voor IT-services geeft aan dat de kosten van een service aanzienlijk meer of minder zijn dan verwacht.

4.3.8 Invoer ■ Strategieplannen. ■ Serviceverbeterkansen. ■ Financiële rapporten. ■ Aanvragen, suggesties of klachten vanuit de business. ■ Project-updates voor services in de opzet-/wijzigingsfase van het proces. 4.3.9 Uitvoer ■ Een bijgewerkte serviceportfolio. ■ Servicecharters. ■ Rapporten over de status van nieuwe of gewijzigde services. ■ Rapporten over de gedane investeringen in services in het serviceportfolio en de ROI daarvan.

■ Wijzigingsvoorstellen. ■ Geïdentificeerde strategische risico’s en RfC’s.

4.3.10 Kritieke succesfactoren ■ Het bestaan van een formeel proces om te onderzoeken en te besluiten welke services aan te bieden.

■ Een model om de potentiële ROI en acceptabele risiconiveaus te analyseren voor nieuwe services of wijzigingen in bestaande services.

■ De mogelijkheid om elke geleverde service te documenteren, samen met de zakelijke behoefte waaraan deze voldoet en de zakelijke doelstelling die deze ondersteunt.

■ Een formeel proces om te evalueren of services de organisatie in staat stellen de strategie te verwezenlijken.

■ De mogelijkheid services te wijzigen in reactie op wijzigingen in de interne en externe omgeving – waar dat wenselijk is.

■ Tools die de serviceprovider in staat stellen de investering in services te volgen gedurende de gehele levenscyclus.

■ Er is een formeel proces om de levensvatbaarheid van services te evalueren en deze te stoppen als ze niet langer levensvatbaar zijn.

4.3.11 Metrics ■ Het serviceportfoliomanagementproces wordt jaarlijks ge-audit en geëvalueerd en voldoet aan de doelstellingen.

■ Elke service heeft een gedocumenteerde verklaring van de initiële investering in de service.

■ Boekhoudkundige rapporten worden periodiek geproduceerd en tonen de voortgaande investering in elke service. De ROI (return on investment) wordt berekend.

■ Klantonderzoek laat een hoog tevredenheidsniveau zien met de waarde die de klant ontvangt.

■ Elke service heeft gedocumenteerde risico’s die ermee samenhangen. Beperkende of tegenmaatregelen zijn genomen en waar risico is, is deze acceptabel.

■ Een serviceportfolio wordt gebruikt voor beslissingen over te leveren services. Alle services zijn gedocumenteerd in het serviceportfolio.

■ Services zijn gekoppeld aan ten minste één zakelijke doelstelling. ■ Regelmatige en gestructureerde feedback toont de prestatie van elke service en de mogelijkheid ervan om gestelde zakelijke doelstellingen te realiseren.

■ Elke wijziging aan een omgeving krijgt een bijbehorende melding in serviceportfoliomanagement.

■ Aan alle gewijzigde zakelijke doelen en doelstellingen wordt steeds voldaan door de services in de serviceportfolio.

■ Uit klantonderzoek blijkt een voortdurend hoog klanttevredenheidsniveau. ■ De investering in elke service is gekwantificeerd in de serviceportfolio. ■ Investering in elke service wordt periodiek gerapporteerd vanaf de initiële investering.

4.3.12 Uitdagingen ■ Beschikking hebben over: •

toegang tot zakelijke informatie over klanten;

•

een formele aanpak van projectmanagement;

•

een projectportfolio;

•

een klantportfolio;

•

een klantovereenkomstenportfolio.

■ De serviceportfolio niet alleen richten op de dienstverlenende aspecten van services.

■ Ook aan het proces changemanagement op strategisch niveau invulling geven, op een geformaliseerde wijze.

4.3.13 Risico’s ■ Een besluit nemen services aan te gaan bieden zonder gevalideerde of volledige informatie.

■ Services aanbieden zonder te omschrijven hoe deze gemeten gaan worden.

■ 4.4 FINANCIEEL MANAGEMENT VOOR IT-SERVICES 4.4.1 Inleiding Financieel management is een complex proces dat voor alle organisaties de basis vormt voor hun bedrijfsvoering. Het is meestal de verantwoordelijkheid van een directielid en is ondergebracht bij een (overkoepelende) financiële afdeling. Met financieel management kan de organisatie haar resources beheren en ervoor zorgen dat deze resources worden gebruikt om de organisatiedoelstellingen te bereiken.

De IT-organisatie, evenals alle andere afdelingen in de organisatie, is betrokken in het proces financieel management van de organisatie. Zij passen de procedures en werkwijzen voor financieel management van de organisatie toe om te zorgen dat zij werken volgens de doelstellingen en het financiële beleid van de organisatie. Op die manier creëren deze afdelingen vaak hun eigen financieel managementproces

In deze paragraaf zal de term financieel management daarom als volgt worden gebruikt:

■ Financieel management – verwijst naar het algemene gebruik van de term. ■ Financieel management van de onderneming– verwijst specifiek naar het proces van de overkoepelende financiële afdeling van het bedrijf.

■ Financieel management voor IT-services – verwijst naar de manier waarop de IT-serviceprovider het proces heeft toegepast.

Financieel management voor IT-services is het proces dat verantwoordelijk is voor het managen van de budgetteringseisen, boekhoudingseisen en factureringseisen van de IT-serviceprovider. Het is ook het proces dat wordt gebruikt om de waarde te kwantificeren die IT-services in zakelijk opzicht bijdragen.

Meer dan enig ander proces stelt financieel management een ITserviceprovider in staat een strategische rol te spelen in de business. Het helpt de waarde en bijdragen van IT te kwantificeren en kwantificeert de zakelijke kansen die IT-services beschikbaar maken.

Het

doel van financieel management voor IT-services is het niveau te

garanderen van financieren tot ontwerpen, ontwikkelen en leveren van services dat past binnen de strategie van de organisatie. Financieel management voor IT-services identificeert de balans tussen de kosten en kwaliteit van een service en onderhoudt de balans van aanbod en vraag tussen de dienstverlener en diens klanten.

Onder de

doelstellinge n van financieel management voor IT-services vallen:

■ Vaststellen en onderhouden van een raamwerk voor het identificeren, beheren en communiceren van de kosten van het leveren van services.

■ Evalueren van de financiële impact van nieuwe of gewijzigde strategie op de serviceprovider.

■ Veiligstellen van de financiering voor het managen van de dienstverlening. ■ Faciliteren van goed beheer van service- en customerassets. ■ Inzicht in de relatie tussen kosten en doelstellingen. ■ Beheren en rapporteren van uitgaven aan dienstverlening. ■ Uitvoeren van de financiële beleidsregels tijdens het leveren van services.

■ Administratieve verwerking van geld besteed aan de creatie, levering en ondersteuning van services.

■ Voorspellen van de financiële behoeften voor de organisatie. ■ In voorkomende gevallen, het vaststellen van een raamwerk om de kosten van de dienstverlening te herstellen.

Bereik Financieel management is gewoonlijk een goed opgezet en goed begrepen onderdeel van een organisatie. Professionele accountants managen financiële afdelingen, die financiële beleidsregels, budgetteringsprocedures, standaardnormen voor financiële verslaglegging, boekhoudpraktijken en regels voor het genereren van winst of het verhalen van kosten vaststellen.

Financieel management bestaat uit drie hoofdprocessen:

■ Budgetteren – Dit is het proces van voorspellen en beheren van de inkomsten en uitgaven (geldstromen) binnen de organisatie. Budgetteren bestaat uit een periodieke onderhandelingscyclus om budget vast te stellen en het maandelijkse bewaken van het lopende budget.

■ Boekhouden – Dit is het proces waarmee de IT-organisatie volledige verantwoording kan afleggen voor de manier waarop het geld is uitgegeven. Hierbij zijn gewoonlijk boekhoudkundige systemen betrokken, met grootboeken, rekeningoverzichten, journalen enzovoort.

■ Doorbelasten – Dit is het proces waarbij de geleverde services bij klanten in rekening worden gebracht. Dit vereist een goede IT-boekhoudpraktijk en bijbehorend IT– systeem.

Tabel 4.2 toont dat boekhouden, budgetteren en doorbelasten twee afzonderlijke cycli kennen:

■ Een planningscyclus (jaarlijks) waarin kostenramingen en werklastprognoses een basis vormen voor kostenberekeningen en de prijszetting.

■ Een operationele cyclus (elke maand of kwartaal) waarin kosten worden bewaakt en afgezet tegen budget, facturen worden uitgebracht en inkomsten worden verzameld.

Tabel 4.2 De cycli budgetteren, IT-boekhouding en doorbelasting

Waarde voor de business Net als hun zakelijke tegenhangers, gebruiken IT-organisaties financieel management in toenemende mate als hulp voor:

■ Verbeterde besluitvorming. ■ Verandersnelheid. ■ Serviceportfoliomanagement. ■ Financiële compliance en controle. ■ Operationele controle. ■ Waarde vastlegging en waardecreatie. Specifieke voordelen voor de business zijn onder andere:

■ De mogelijkheid om zaken te doen op een financieel verantwoorde wijze en te voldoen aan eisen van wet- en regelgeving en algemeen aanvaarde boekhoudkundige principes.

■ Accurate planning en voorspelling van het benodigde budget om de kosten van services te dekken.

■ Inzicht in de kosten van IT voor elke business unit. ■ Betere afstemming van IT-services op zakelijke doelstellingen. ■ De mogelijkheid weloverwogen zakelijke beslissingen te nemen betreffende het gebruik van en de investering in IT.

4.4.2 Beleidsregels, principes en basisbegrippen Algemene bedrijfsbeleidsregels voor financieel management De algemene bedrijfsbeleidsregels voor financieel management bieden een raamwerk waarbinnen IT moet werken om alle financiële aspecten van zijn services en organisatie te beheren.

Financiering

Financiering is de verwerving en toewijzing van geld voor een bepaald doel of project. Financiering komt uit twee bronnen, extern en intern.

Compliance (naleving) Compliance heeft betrekking op de mogelijkheid om aan te tonen dat goede en consistente boekhoudkundige methoden en/of praktijken worden ingezet. Het is belangrijk dat bedrijfsbeleidsregels voor financieel management duidelijk schetsen welke wettelijke en andere eisen gelden voor de serviceprovider en de klantorganisatie.

4.4.3 Activiteiten, methoden en technieken

Het financieel beheerproces bestaat uit drie hoofdactiviteiten: boekhouden (accounting), budgetteren en doorbelasten (charging).

1. Boekhouden (accounting) Boekhouding is het proces dat verantwoordelijk is voor het vaststellen van de werkelijke kosten van het leveren van IT-services, de vergelijking met gebudgetteerde kosten en het beheren van afwijkingen van het budget. Boekhouding is ook verantwoordelijk voor het volgen van de inkomsten die de services opbrengen.

- Boekhouding: Kostenmodel Een kostenmodel is een raamwerk dat de serviceprovider de mogelijkheid geeft de kosten van dienstlevering vast te stellen en te zorgen dat die correct worden toegerekend.

Kostenmodellen geven de serviceprovider bijvoorbeeld inzicht in de impact van voorgestelde wijzigingen in de huidige service. Een organisatie kan met elk van de volgende kostenmodellen werken:

■ Kosten per IT-organisatie. ■ Kosten per service. ■ Kosten per klant. ■ Kosten per locatie. ■ Hybride kostenmodellen.

- Boekhouding: kostenplaatsen, kostensoorten en kosteneenheden Kostenplaatsen:

■ In de context van kostenmodellen en boekhoudsystemen, is een kostenplaats iets waaraan kosten kunnen worden toegerekend.

■ Een kosteneenheid is het laagste categorieniveau waaraan kosten worden toegerekend. Deze worden (gewoonlijk) eenvoudig gemeten en gecommuniceerd in termen die de klant gebruikt.

Kostensoorten en kostenelementen Kostensoorten zijn het hoogste categorieniveau waaraan kosten worden toegerekend bij het budgetteren en boekhouden, bijvoorbeeld, hardware, software, mensen, adviesdiensten en faciliteiten.

Kostenelementen zijn de subcategorieën waaraan kosten worden toegerekend bij het budgetteren en boekhouden. Kostenelementen zijn subcategorieën van kostensoorten. De kostensoort ‘mensen’ bijvoorbeeld, kan de kostenelementen salarissen, bonussen, onkosten, training, overwerk, enzovoort omvatten. Kostenelementen zijn gewoonlijk identiek aan budgetregelitems omdat het doel van het model eenvoudig het dekken van de kosten is.

- Boekhouding: kostenclassificatie Er zijn vier belangrijke classificaties, waarvan er drie bestaan uit twee opties. De vierde classificatie betreft afschrijving als een bijzondere vorm van kostenkwalificatie.

■ Kapitaalgoederen of operationele kosten. ■ Directe of indirecte kosten. ■ Vaste of variabele kosten. ■ Afschrijving. - Boekhouding: rekeningenoverzicht Met het rekeningenoverzicht wordt een overzicht bedoeld van alle rekeningen die worden gebruikt om inkomsten en uitgaven vast te leggen.

- Boekhouding: analyse en rapportage

Naast vele andere doelstellingen, is de activiteitenanalyse en -rapportage bedoeld om de baten, lasten en investeringen van de serviceprovider op organisatieniveau inzichtelijk te maken. Deze activiteit communiceert de kosten van de services aan alle stakeholders.

- Boekhouding: actieplannen Actieplannen, gewoonlijk voor de korte termijn, zijn gericht op het terugleiden van de organisatie naar het geplande pad binnen een bepaalde periode, meestal een maand of een kwartaal. Actieplannen kunnen helpen om stakeholders te laten instemmen met veranderingen in de oorspronkelijke plannen.

2. Budgetteren Budgetteren is de activiteit van het voorspellen en onder controle brengen van de uitgaven. Budgetteren bestaat uit een periodieke onderhandelingscyclus om toekomstig budget vast te stellen (gewoonlijk jaarlijks) en het routinematige bewaken en aanpassen van lopend budget.

Er zijn vijf subactiviteiten binnen de activiteit budgetteren:

■ Analyseren van vorig budget. ■ Evalueren van plannen. ■ Specificatie van wijzigingen in financiering en uitgaven. ■ Kosten- en batenschatting. ■ Bepalen van het/de budget(ten). 3. Doorbelasting (Charging) Doorbelasten is de activiteit waarbij betaling wordt gevraagd voor geleverde services. Voor interne serviceprovider is doorbelasten optioneel en veel organisaties kiezen ervoor hun IT-serviceprovider als een kostenplaats te behandelen. In die situatie wordt doorbelasting vaak ‘terugboeking’ genoemd omdat de kosten van de serviceprovider eenvoudig terug-toegerekend worden aan andere business units door de centrale financiële functie, via een interne doorbelastingsmethode.

Als de IT-serviceorganisatie niet de steun van de hele organisatie heeft wanneer ze doorbelasting introduceert, zal het mislukken. Het moet eenvoudig, eerlijk

en realistisch gebeuren.

Er zijn drie subactiviteiten binnen de hoofdactiviteit doorbelasting. 1. Doorbelasting: beleid voor het doorbelasten. Er zijn twee soorten beleidsbeslissingen mogelijk in het bepalen hoe de doorbelasting zal plaatsvinden en beide worden vastgesteld door het financieel management op bedrijfsniveau: •

De eerste beleidsbeslissing is wel of niet doorbelasten.

•

De tweede beleidsbeslissing is het niveau van kostendekking dat moet

worden bereikt. 2. Doorbelasting: besluiten op welke wijze services worden doorbelast. De klant dient exact te begrijpen wat aan hem wordt doorbelast. Het helpt ook verwachtingen vast te stellen en te beheren ten aanzien van het servicelevel dat wordt ontvangen. 3. Doorbelasting: prijsvaststelling. De beslissing hoeveel wordt doorbelast hangt van twee dingen af: •

De gemaakte kosten voor de geleverde service.

•

De verwachte waarde die de service voor de klant heeft en de mate van

gebruik.

- Doorbelasting: facturering Facturering kan onderdeel zijn van de activiteit doorbelasting. Er zijn drie hoofdopties voor facturering: 1. Geen facturering. 2. Informatieve facturering (fictieve doorbelasting). 3. Facturering en inning (echte doorbelasting).

4.4.4 Informatiemanagement ■ Systemen voor financieel management, zoals boekhoud-, budgetterings- en factureringssystemen.

■ Beleidsregels, wet- en regelgeving voor financieel management. ■ Structuren, sjablonen, rapporten en spreadsheets voor financiële rapportage. ■ Het rekeningenoverzicht van de organisatie. ■ Het kennismanagementsysteem van de serviceprovider.

4.4.5 Interfaces

■ Alle servicemanagementprocessen – Met financieel management de kosten en baten van het proces zelf vaststellen.

■ Strategiemanagement voor IT-services – Samen met financieel management op bedrijfsniveau de financiële doelstellingen voor de organisatie vaststellen.

■ Serviceportfoliomanagement – Om te voorzien in de servicestructuur die zal worden gebruikt om de kostenmodellen, boekhoud- en budgetteringssystemen en de basis voor doorbelasting te bepalen.

■ Klantrelatiebeheer – Om te voorzien in informatie over de manier waarop de business de waarde van services meet en wat deze bereid is te betalen voor services.

■ Capaciteits- en availabiltymanagement – Om te voorzien in waardevolle informatie over de verschillende opties van technologie en serviceprestaties.

■ Changemanagement – Met financiële informatie de financiële impact of eisen van wijzigingen bepalen.

■ Serviceasset en configuratiemanagement – Om financiële data van activa en configuratie-items te documenteren.

■ Continue serviceverbetering – Om te bepalen of de opbrengst van een voorgestelde verbetering de investering waard is die nodig is om die verbetering te realiseren.

4.4.6 Aanleidingen (triggers) ■ Maandelijkse, kwartaal- en jaarlijkse cyclus van financiële rapportage. ■ Auditrapporten. ■ Verzoeken om financiële informatie over andere servicemanagementprocessen.

■ Onderzoek naar nieuwe kansen voor dienstverlening. ■ De introductie van doorbelasting voor IT-services. ■ Een wijzigingsverzoek.

4.4.7 Invoer ■ Beleidsregels, standaardnormen en -praktijken vastgesteld door wetgeving, regelgeving en de financieel managers in de bedrijfstop.

■ International Financial Reporting Standards en locale variaties. ■ Alle gegevensbronnen met opgeslagen financiële informatie. ■ De serviceportfolio.

■ Elk servicemanagementproces levert financiële informatie over hoe geld wordt uitgegeven, welke services betrokken zijn.

■ Service-, contract-, klant-, applicatie- en projectportfolio’s. ■ Het kennismanagementsysteem van de serviceprovider.

4.4.8 Uitvoer ■ Servicewaardering (servicewaardebepaling). ■ Service-investeringsanalyse. ■ Compliance. ■ Kostenoptimalisatie. ■ Business-impactanalyse (BIA). ■ Vertrouwen in planning. 4.4.9 Kritieke succesfactoren ■ Er is een organisatiebreed geldend raamwerk voor het identificeren, beheren en communiceren van financiële informatie, kosten en bijbehorende opbrengsten.

■ Financieel management voor IT-services is een belangrijke component voor het evalueren van strategieën.

■ Financiering is beschikbaar om de levering van services te ondersteunen. ■ Goed serviceasset- & configuratiemanagement maakt rentmeesterschap van service- en customerassets mogelijk.

■ De serviceprovider begrijpt de relatie tussen uitgaven en inkomsten. ■ Financiële rapportage aan de stakeholders van de organisatie stelt deze in staat weloverwogen beslissingen te nemen.

■ Het moet mogelijk zijn het geld dat is uitgegeven aan de creatie, levering en ondersteuning van services te verantwoorden.

■ Rapportage over en accurate voorspellingen van financiële vereisten.

Afbeelding 4.6 De belangrijkste invoer, uitvoer en activiteiten van nancieel management voor IT-services. (Bron: AXELOS)

4.4.10 Metrics ■ Financieel management op ondernemingsniveau heeft standaarden, beleidsregels en rekeningoverzichten vastgelegd.

■ Het raamwerk van financieel management voor IT-services specificeert hoe services worden verantwoord.

■ Tijdige en accurate verstrekking van financiële rapporten. ■ Alle strategieën hebben een uitgebreide analyse van investeringen en opbrengsten.

■ Uit de assessment van strategieën blijkt dat de financiële voorspellingen accuraat waren dan wel binnen acceptabele marges bleven.

■ Tijdige en accurate levering van financiële informatie voor serviceanalyse binnen het serviceportfoliomanagement.

■ Interne serviceproviders ontvangen de benodigde financiering voor het leveren van de afgesproken services.

■ Externe serviceproviders zijn in staat services te verkopen tegen de vereiste winstniveaus.

■ Er is financiering voor onderzoek aan en ontwikkeling van nieuwe services of verbeterinitiatieven.

■ Customer- en serviceassets zijn vastgelegd in het configuratiemanagementsysteem.

■ Er zijn regelmatige rapportages over de kosten van services in de levensloopstadia ontwerp, transitie en productie.

4.4.11 Uitdagingen ■ Financiële rapportage- en kostenmodellen zijn gericht op infrastructuur- en applicatiekosten in plaats van de kosten van services.

■ Voldoen aan standaarden en beleidsregels van de onderneming. ■ Gericht zijn op kostenbesparing en niet op kostenoptimalisatie. ■ In het begin kan het moeilijk zijn erachter te komen waar financiële gegevens zijn gelokaliseerd en hoe die worden gecontroleerd.

■ Interne serviceproviders kunnen problemen ondervinden bij het introduceren van doorbelasting.

■ Externe serviceproviders zullen de kosten van services in balans moeten brengen met de ervaren waarde van deze services om te zorgen voor correcte prijsmodellen.

4.4.12 Risico’s ■ Het introduceren van processen speciaal voor financieel management die als onnodig en als een verspilling van geld en tijd worden beschouwd.

■ Geen adequate processen voor financieel management van IT-services hebben, kan de organisatie boetes bezorgen vanwege gebrek aan naleving van wet- en regelgeving.

■ Gebrek aan beschikbaar personeel dat zowel de wereld van de dienstverlening als die van kostenverantwoording kent.

■ 4.5 DEMANDMANAGEMENT 4.5.1 Inleiding Demandmanagement is een belangrijk aspect van servicemanagement. Een slecht gemanagde vraagkant is een bron van risico voor serviceproviders vanwege onzekerheid van de vraag die eruit voortvloeit. Overcapaciteit genereert kosten zonder waarde te creëren die een basis is voor kostendekking. Klanten betalen niet graag voor overcapaciteit die geen waarde voor hen heeft.

Het

doel van demandmanagement is het begrijpen van, anticiperen op en

beïnvloeden van de vraag van de klant naar services en er met capaciteitsmanagement voor zorgen dat de serviceprovider capaciteit heeft om aan de vraag te voldoen. Demandmanagement gebeurt in elke fase van de levenscyclus om te zorgen dat services zodanig worden ontworpen, getest en geleverd dat zakelijke doelstellingen worden bereikt met de juiste activiteitsniveaus.

De

doelstellingen van demandmanagement zijn:

■ Identificeren en analyseren van patronen in de bedrijfsactiviteit. ■ Vaststellen en analyseren van gebruikersprofielen. ■ Zorgen dat services zo worden ontworpen dat ze aan de patronen in de bedrijfsactiviteit voldoen.

■ Samen met capaciteitsmanagement zorgen dat voldoende resources beschikbaar zijn op het juiste moment en de juiste plaats.

■ Anticiperen op, voorkomen of managen van situaties waarin vraag naar een service de capaciteit om die te leveren overschrijdt.

■ Balans aanbrengen in het gebruik van resources om tegemoet te kunnen komen aan de fluctuerende vraag naar services.

Bereik Het bereik van het proces demandmanagement is het identificeren en analyseren van de patronen in de bedrijfsactiviteit die vraag naar services initiëren en het identificeren van verschillende soorten gebruikers en analyseren hoe die de vraag naar services beïnvloeden.

De volgende demandmanagementactiviteiten moeten plaatsvinden:

■ Identificeren en analyseren van patronen in bedrijfsactiviteit waar ITservices bij betrokken zijn.

■ Identificeren van gebruikersprofielen en hun servicegebruikspatronen analyseren.

■ Identificeren, afspreken en doorvoeren van maatregelen om de vraag te beïnvloeden.

Waarde voor de business De belangrijkste waarde van het managen van de vraagkant is het bereiken van een balans tussen de kosten van een service en de waarde van de zakelijke doelstellingen die deze ondersteunt. Demandmanagement verfijnt het begrip van hoe, wanneer en op welk niveau zakelijke doelstellingen, services, resources en competenties op elkaar inwerken.

Tabel 4.3 Demandmanagement vergeleken met capaciteitsmanagement

4.5.2 Beleidsregels, principes en basisbegrippen Vraag en aanbod Vanuit een strategisch perspectief gaat het bij demandmanagement om het op elkaar afstemmen van vraag en aanbod. Bij dienstverlening zijn vraag en

aanbod strak aan elkaar gekoppeld. In tegenstelling tot goederen kunnen services niet vooraf worden gefabriceerd en in voorraad worden gehouden.

Serviceassets afstemmen De balans tussen vraag en aanbod wordt bereikt door de serviceassets te laten aansluiten op dynamische patronen in de vraag naar services.

■ De services identificeren via de serviceportfolio. ■ De patronen in bedrijfsactiviteit identificeren. ■ De juiste architectuur specificeert de soort en hoeveelheid vraag. ■ Werken met capaciteits- en beschikbaarheidsplanning om te zorgen dat de juiste serviceassets op het juiste moment beschikbaar zijn en presteren op de juiste niveaus.

■ Performancemanagement en afstemmen van serviceassets om mee te bewegen met veranderingen in vraag.

4.5.3 Managen van de vraag gedurende de levenscyclus Om volledig effectief te zijn, moet demandmanagement actief zijn gedurende de gehele levenscyclus. De activiteiten van demandmanagement in elke fase van de levenscyclus omvatten onder andere:

■ Servicestrategie

– Identificeren van de services en doelstellingen, en de

patronen in bedrijfsactiviteit die zijn gegenereerd door het bereiken van deze doelstellingen.

■ Serviceontwerp – Bevestigen van de eisen van de klant met betrekking tot beschikbaarheid en prestatie en valideren dat de serviceassets daarop zijn afgestemd.

■ Servicetransitie

– Omdat demandmanagement betrokken is bij het testen

en valideren van services om gebruik en patronen in bedrijfsactiviteit te voorspellen.

■ Serviceproductie

– Omdat technisch management, applicatiemanagement

en IT-operationsmanagement serviceassets en de mate van gebruik van een service zullen monitoren en bewaken.

■ Continue serviceverbetering – Omdat demandmanagement trends in patronen van bedrijfsactiviteit tracht te identificeren en verbeteringen in de service- en customerassets initieert of klantgedrag probeert te beïnvloeden.

4.5.4 Activiteiten, methoden en technieken

De belangrijkste activiteiten binnen dit proces zijn:

1. Identificeren van bronnen die de vraag voorspellen Potentiële informatiebronnen die demandmanagement helpen de vraag te voorspellen:

■ Zakelijke plannen. ■ Marketingplannen en voorspellingen. ■ Productieplannen. ■ Verkoopvoorspellingen. ■ Plannen voor het lanceren van nieuwe producten. Patronen in bedrijfsactiviteit Als een patroon in bedrijfsactiviteit (PBA) eenmaal is geïdentificeerd, moeten een PBA-profiel worden opgemaakt en details van het PBA worden gedocumenteerd.

Gebruikersprofielen Gebruikersprofielen (UP’s, User Profiles) zijn gebaseerd op rollen en verantwoordelijkheden binnen organisaties. Patroonafstemming met behulp van PBA’s en UP’s zorgt voor een systematische aanpak om de vraag van klanten te begrijpen en te managen.

Activity-based demandmanagement Bedrijfsprocessen zijn de primaire bron van vraag naar services (afbeelding 4.7). PBA’s beïnvloeden de vraagpatronen die door de serviceproviders worden gezien.

2. Gedifferentieerd aanbod ontwikkelen Uit de analyse van de PBA’s kan blijken dat verschillende niveaus van utility en warranty nodig zijn op verschillende tijden. Demandmanagement formuleert samen met serviceportfoliomanagement de juiste servicepakketten (service packages).

3. Management van de operationele vraag Deze activiteit werkt aan het managen of beïnvloeden van de vraag wanneer live/operationele services of resources overbezet zijn.

Afbeelding 4.7 Voorbeeld van activity-based demandmanagement (Bron: AXELOS)

4.5.5 Informatiemanagement ■ De serviceportfolio. ■ De klantportfolio. ■ De projectportfolio. ■ Verslag van de vergaderingen tussen klantrelatiebeheer (BRM, Business Relationship Management) en klanten.

■ Servicelevelovereenkomsten (SLA’s). ■ Het configuratiemanagementsysteem (CMS).

4.5.6 Interfaces ■ Strategiemanagement voor IT-services – Om de belangrijke zakelijke doelstellingen en bedrijfsactiviteiten te identificeren.

■ Serviceportfoliomanagement – Om servicemodellen te creëren en evalueren, en gebruikseisen vast te stellen en te voorspellen.

■ Financieel management voor IT-services – De kosten van het voorzien in de vraag voorspellen op basis van voorspelde patronen in bedrijfsactiviteit.

■ Klantrelatiebeheer – Als de primaire bron van informatie over de bedrijfsactiviteiten van de klant.

■ Servicelevelmanagement – Om afspraken te formaliseren waarin de klant zich committeert aan gebruiksniveaus en de serviceprovider zich committeert aan prestatieniveaus.

■ Capaciteitsmanagement – Om exact te formuleren hoe aanbod en vraag in overeenstemming te brengen in het ontwerp en de uitvoering van de service.

■ Availabilitymangement – De informatie over patronen in bedrijfsactiviteit gebruiken om te bepalen wanneer de beschikbaarheid van de service het belangrijkste is.

■ IT-service continuity management – Om de business-impactanalyse uit te voeren en de PBA’s en UP’s te bepalen tijdens een grote uitval, crisis of ramp.

■ Changemanagement – Om te evalueren welke impact wijzigingen hebben op hoe de business services gebruikt.

■ Serviceasset & configuratiemanagement – Om de relatie tussen de vraag naar services en de vraag naar systemen en apparaten te bepalen.

■ Servicevalidation & testing – Om vast te stellen dat de service correct is omgegaan met vraagpatronen en dat maatregelen ter voorkoming van overbezetting effectief zijn.

■ Eventmanagement – Om informatie te verstrekken over actuele patronen in het gebruik van een service en de eventuele afwijkingen tussen de voorspelde en de daadwerkelijke gebruikspatronen.

4.5.7 Aanleidingen (triggers) ■ Een verzoek van een klant voor een nieuwe service, of wijziging aan een bestaande services.

■ Een nieuwe service wordt gecreëerd om aan een strategisch initiatief toe te komen.

■ Een servicemodel moet worden geformuleerd. ■ Gebruiksratio’s veroorzaken potentiële prestatiekwesties. ■ Een uitzondering (exceptie) is opgetreden.

4.5.8 Invoer ■ Initiatief om een nieuwe service te creëren of om een bestaande service aan te passen.

■ Servicemodellen. ■ De klantportfolio, serviceportfolio en klantovereenkomstenportfolio. ■ Doorbelastingsmodellen. ■ Door te belasten producten, zoals notebooks, pc’s en dergelijke. ■ Plannen maken en kansen grijpen voor het verbeteren van de services.

4.5.9 Uitvoer ■ Gebruikersprofielen. ■ Patronen in bedrijfsactiviteit. ■ Beleidsregels voor het managen van de vraag. ■ Beleidsregels voor het omgaan met toenemend of verminderd, werkelijk of verwacht gebruik van services.

■ Documentatie van opties voor gedifferentieerd aanbod.

4.5.10 Kritieke succesfactoren ■ Begrip van vraagniveaus door identificatie en analyse van patronen in bedrijfsactiviteit.

■ Begrip van typische vraagprofielen door identificatie en analyse van verschillende gebruikersprofielen.

■ Services zijn afgestemd op het voldoen aan zowel patronen in bedrijfsactiviteit als zakelijke doelstellingen.

■ Samen met capaciteitsmanagement zorgen dat voldoende resources beschikbaar zijn op de juiste plaats en juiste tijd om aan de vraag te voldoen.

4.5.11 Metrics ■ Patronen in bedrijfsactiviteit. ■ Elk gedocumenteerd gebruikersprofiel bevat een vraagprofiel voor de services die dit type gebruiker benut.

■ Capaciteitsplannen omvatten gegevens van patronen in bedrijfsactiviteit en de corresponderende werkdruk.

■ Uit de bewaking van het gebruik blijkt een uitgebalanceerde werkdruk. ■ Capaciteitsplannen en SLA’s bevatten technieken om de vraag te beheren.

4.5.12 Uitdagingen ■ De beschikbaarheid van informatie over bedrijfsactiviteiten. ■ Klanten kunnen het moeilijk vinden afzonderlijke activiteiten te benoemen die voor de serviceprovider betekenisvol zijn.

■ Ontbreken van een formeel serviceportfoliomanagementproces of serviceportfolio.

4.5.13 Risico’s ■ Ontbreken van configuratiemanagementgegevens, of deze zijn inaccuraat. ■ Er worden geen toezeggingen gedaan voor een minimaal of maximaal gebruiksniveau.

■ 4.6 KLANTRELATIEBEHEER 4.6.1 Inleiding Klantrelatiebeheer is het proces dat de klantrelatiebeheerder (business relationship manager (BRM)) in staat stelt om op strategisch en tactisch niveau verbanden te leggen tussen de serviceprovider en klanten. Het eerste waaraan het succes van dit proces kan worden afgemeten is de mate waarin de klant tevreden is.

De twee primaire

doelen van klantrelatiebeheer zijn:

■ Het komen tot en onderhouden van een zakelijke relatie tussen de serviceprovider en de klant op basis van begrip voor de klant en diens bedrijfsbehoeften.

■ Vaststellen van de klantbehoeften en zorgen dat de serviceprovider hieraan kan voldoen in een situatie waarin de bedrijfsbehoeften constant veranderen.

Doelstellingen van klantrelatiebeheer zijn onder andere: ■ Zorgen dat de serviceprovider begrijpt hoe de klant tegen dienstverlening aankijkt.

■ Zorgen voor een hoog klanttevredenheidsniveau. ■ Opzetten en onderhouden van een constructieve relatie tussen serviceprovider en klant.

■ Vaststellen van wijzigingen in de klantomgeving die gevolgen kunnen hebben voor services.

■ Vaststellen van technologische trends die gevolgen kunnen hebben voor de geleverde diensten.

■ Opstellen en verwoorden van bedrijfsbehoeften voor nieuwe services of wijzigingen in bestaande services.

■ Zorgen dat de serviceprovider voldoet aan de bedrijfsbehoeften van de klant.

■ Samen met klanten ervoor zorgen dat services en servicelevels waarde opleveren.

■ Opzetten van formele processen voor het omgaan met escalaties en de afhandeling van klachten.

Bereik Bij interne serviceproviders vindt klantrelatiebeheer gewoonlijk plaats tussen een vertegenwoordigend hoofd van IT en het hogere management van de business units. Hierbij ligt de nadruk op het afstemmen van de bedrijfsdoelstellingen met de activiteit van de serviceprovider.

Klantrelatiebeheer is gericht op begrip van de wijze waarop services voldoen aan de eisen van de klant.

■ Zakelijke doelstellingen die de klant wil realiseren. ■ Services die al worden geleverd. ■ Hoe klanten services gebruiken. ■ Hoe services worden geleverd, inclusief afgesproken niveaus en kwaliteitsniveaus.

■ Technologische trends en de potentiële impact op huidige en toekomstige behoeften van de business en services.

■ Niveaus van klanttevredenheid en verbeterinitiatieven die ontevredenheid moeten wegnemen.

■ Hoe services voor de toekomst te optimaliseren.

Er zijn nog andere processen betrokken bij klanttevredenheid, maar die zijn gericht op de kwaliteit van services en op wat gedaan kan worden om te voldoen aan de verwachtingen van de klant ten aanzien van de services.

Een goed voorbeeld is het verschil tussen klantrelatiebeheer (BRM) en servicelevelmanagement (SLM). In beide processen zijn er regelmatig ontmoetingen met klanten en beide hebben te maken met voortdurend evalueren van de service en de kwaliteit ervan.

Tabel 4.4 Verschillen tussen klantrelatiebeheer en servicelevelmanagement

Waarde voor de business De waarde van klantrelatiebeheer ligt in de mogelijkheid van de serviceprovider de zakelijke behoeften van zijn klanten te verwoorden en erin te voorzien. Klantrelatiebeheer creëert een forum voor voortgaande, gestructureerde communicatie met de klanten. Dit maakt dat het klantrelatiebeheer mogelijk in de toekomst een betere afstemming en integratie van services kan bereiken, evenals de lopende zakelijke doelstellingen te realiseren.

4.6.2 Beleidsregels, principes en basisbegrippen

Klantrelatiebeheer en de accountmanager Het proces klantrelatiebeheer wordt vaak verward met de rol van account- of businessrelatiemanager (BRM). Dit komt doordat het een uiterst zichtbare rol is en veel klanten associëren de procesactiviteiten met deze persoon.

Klantportfolio De klantportfolio is een database die, of gestructureerd document dat, wordt gebruikt om alle klanten van de IT-serviceprovider te registreren. De klantportfolio is de manier waarop klantrelatiebeheer de klanten ziet die services van de IT-serviceprovider ontvangen.

Tabel 4.5 Procesactiviteiten klantrelatiebeheer en andere servicemanagementprocessen

Klantovereenkomstenportfolio De klantovereenkomstenportfolio is een database die, of gestructureerd document dat, wordt gebruikt om servicecontracten of afspraken tussen een IT-serviceprovider en zijn klanten te beheren. Voor elke aan een klant geleverde IT-service moet er een contract of andere afspraak zijn opgenomen in de klantovereenkomstenportfolio.

Klanttevredenheid Klantrelatiebeheer meet de klanttevredenheid en vergelijkt de prestaties van de serviceprovider met de doelstellingen en eerdere scores op het gebied van klanttevredenheid. Vragenlijsten zijn de meest gebruikelijke vorm voor het meten van klanttevredenheid. De vragenlijsten moeten eenvoudig en in korte tijd kunnen worden ingevuld.

Servicevereisten Klantrelatiebeheer is betrokken bij het formuleren en helder krijgen van de eisen waaraan een service gedurende de levenscyclus moet voldoen. De betrokken hoofdprocessen hierbij zijn serviceportfoliomanagement in servicestrategie en ontwerpcoördinatie en servicelevelmanagement in serviceontwerp.

Dit type activiteit is specialistisch en vereist expertise in bedrijfsanalyse. Klanten weten niet altijd hoe de eisen te verwoorden, vooral wanneer zij die moeten vertalen in de taal en indeling die de serviceprovider kan begrijpen en gebruiken om de service te ontwerpen en te bouwen, en om metrics vast te stellen die het succes ervan bepalen.

Afbeelding 4.8 Overzicht van activiteiten binnen klantrelatiebeheer (Bron: AXELOS)

Klantrelatiebeheer faciliteert strategische partnerschappen Klantrelatiebeheer zorgt dat relevante informatie over de strategische richting van de klant wordt doorgegeven aan de juiste mensen in de organisatie van de

serviceprovider. Hiermee kunnen zij hun eigen strategie, markten, toekomstkansen en serviceportfolio opnieuw evalueren.

4.6.3 Activiteiten, methoden en technieken De aard van het klantrelatiebeheerproces Het klantrelatiebeheerproces bestaat uit activiteiten in elke fase van de servicelevenscyclus, maar wordt zelden uitgevoerd als een afzonderlijk proces dat in zijn geheel wordt doorlopen. Welke activiteiten er precies worden uitgevoerd, hangt af van de situatie die ervoor zorgde dat de serviceprovider of klant het proces initieerde.

Het klantrelatiebeheerproces kent verschillende groepen en reeksen activiteiten, ook als die niet allemaal elke keer van begin tot eind worden uitgevoerd wanneer het proces wordt geïnitieerd. Het proces kan bijvoorbeeld door servicelevelmanagement worden geïnitieerd in het stadium serviceontwerp van de levenscyclus, zonder eerst langs servicestrategie te gaan.

Initiatie van het proces Het klantrelatiebeheerproces wordt geïnitieerd door door de klant, de serviceprovider of de servicemanagenentprocessen en -functies.

Initiatie door klanten Klanten communiceren op een aantal manieren en om vele redenen met de serviceprovider over hun behoeften, kansen en vereisten, zoals: een kans, een wijzigingsverzoek, andere verzoeken, een klacht, een compliment.

Initiatie door de serviceprovider De serviceprovider kan het klantrelatiebeheerproces initiëren wanneer er input van klanten nodig is. De serviceprovider kan het proces ook initiëren vanwege de creatie van een nieuwe service of voor het wijzigen van een bestaande service.

4.6.4 Het klantrelatiebeheerproces gedurende de levenscyclus De kern van het klantrelatiebeheerproces is dat het interne proces van de serviceprovider in staat wordt gesteld om af te stemmen en aan te sluiten op en waar nodig te integreren met de business van de klant. De activiteiten per

stadium worden niet altijd allemaal uitgevoerd en ze worden niet altijd allemaal in dezelfde volgorde uitgevoerd.

Servicestrategie De belangrijkste gebieden waar klantrelatiebeheer mee werkt in dit stadium zijn:

■ IT-strategie, IT-beleidsregels en IT-plannen. ■ Serviceportfoliomanagement. ■ Demandmanagement. ■ Financieel management voor IT-services. Serviceontwerp ■ Projectmanagement. ■ Financieel management voor IT-services. ■ Servicelevelmanagement. ■ Demandmanagement. ■ Servicecatalogusmanagement. ■ Availabilitymanagement. ■ Capaciteitsmanagement. ■ IT-service continuity management. Servicetransitie De accountmanager of klantrelatiebeheerder zal de klantbetrokkenheid in de processen die actief zijn gedurende servicetransitie coördineren. Deze processen zorgen dat wijzigingen/releases voldoen aan de eisen van de klant.

■ Changemanagement. ■ Kennismanagement. ■ Testen en valideren van de service. ■ Release & deployment management. ■ Evaluatie van wijzigingen. Serviceproductie Veel organisaties hebben het idee dat zodra een service is uitgerold, het klantrelatiebeheerproces voor die service niet langer nodig is, tot zich een nieuwe eis aandient. Dat is niet juist omdat dit proces ook een raakvlak heeft met:

■ Request fulfilment. ■ Incidentmanagement. Continue serviceverbetering Processen en activiteiten waarmee klantrelatiebeheer in dit stadium van de servicelevenscyclus een raakvlak heeft, zijn onder andere:

■ Servicerapportage. ■ Servicelevelmanagement. ■ Verbeterproces in zeven stappen.

4.6.5 Informatiemanagement ■ De serviceportfolio. ■ De projectportfolio. ■ De applicatieportfolio. ■ De klantportfolio. ■ De klantovereenkomstenportfolio. ■ De servicecatalogus. ■ Klanttevredenheidsonderzoeken. 4.6.6 Interfaces ■ Strategiemanagement voor IT-services – Om markten te identificeren en om informatie te verzamelen over klanten.

■ Serviceportfoliomanagement – Voor gedetailleerdere eisen en gegevens van de klantomgeving, nodig voor het creëren van servicemodellen en het evalueren van voorgestelde services.

■ Financieel management voor IT-services – Om informatie te verkrijgen over de financiële doelstellingen van de klant en het helpt de serviceprovider te begrijpen welk financierings- of prijsniveau de klant bereid is te accepteren.

■ Demandmanagement – Om patronen in bedrijfsactiviteit en gebruikersprofielen vast te stellen en te valideren.

■ Servicelevelmanagement – Om gebruik te maken van informatie over klanten en servicevereisten en de prioriteiten van de klant ten aanzien van serviceprestaties en deliverables te begrijpen.

■ Servicecatalogusmanagement – Om te voorzien in de basis voor veel discussies, reviews en verzoeken, geïnitieerd via klantrelatiebeheer.

■ Capaciteits- en availabiltymanagement – Voor het verwerken, analyseren en begrijpen van zakelijke doelstellingen en vereisten van services.

■ IT-service continuity management – Om te voorzien in waardevolle inzichten en informatie over zakelijke prioriteiten en doelstellingen gedurende een crisis of calamiteit.

■ Changemanagement – Om de impact en prioriteit van wijzigingen te evalueren.

■ Release & deployment management – Om te zorgen voor het juiste niveau van klantbetrokkenheid bij de release-activiteiten en bij de servicevalidatie, het testen en evalueren van wijzigingen.

■ Het verbeterproces in 7 stappen – Verbeterkansen en –plannen identificeren, valideren, prioriteren en communiceren met de klant.

4.6.7 Aanleidingen (triggers) ■ Een nieuw strategisch initiatief. ■ Een nieuwe service of een kans voor een bestaande service is geïnitieerd. ■ Een nieuwe kans is vastgesteld. ■ Een service is toegevoegd door serviceportfoliomanagement. ■ Klantaanvragen of -suggesties. ■ Klacht van een klant. ■ Compliment van een klant. ■ Een geplande ontmoeting met de klant. ■ Een gepland klanttevredenheidsonderzoek. 4.6.8 Invoer ■ Klanteisen. ■ Klantaanvragen, klachten, escalaties of complimenten. ■ De servicestrategie. ■ De strategie van de klant. ■ De serviceportfolio. ■ De projectportfolio. ■ Servicelevelovereenkomsten (SLA’s). ■ Wijzigingsaanvragen (RfC’s). ■ Patronen in bedrijfsactiviteit en gebruikersprofielen. 4.6.9 Uitvoer

■ Documentatie over belanghebbenden (stakeholders). ■ Vastgestelde zakelijke doelstellingen. ■ Financieringsafspraken (intern) of betalingsafspraken (extern) voor services. ■ De klantportfolio. ■ Servicevereisten voor strategie, ontwerp en transitie. ■ Gepubliceerde resultaten van klanttevredenheidsonderzoeken. ■ Schema’s van klantactiviteit in verschillende servicemanagementprocesactiviteiten.

■ Schema’s van trainings- en bewustwordingsdagen. ■ Rapporten over hoe de klant de serviceprestaties ervaart.

4.6.10 Kritieke succesfactoren ■ De mogelijkheid om de eisen die de klant aan services stelt en de zakelijke doelstellingen die deze wil bereiken te documenteren en te begrijpen.

■ De mogelijkheid om klanttevredenheidniveaus te meten, en de actie naar aanleiding van de resultaten.

■ De mogelijkheid wijzigingen in de klantomgeving vast te stellen die het type, niveau of gebruik van geleverde services zouden kunnen beïnvloeden.

■ De mogelijkheid trends in technologie vast te stellen die het type, niveau of gebruik van geleverde services zouden kunnen beïnvloeden.

■ De mogelijkheid zakelijke vereisten voor nieuwe services of wijzigingen aan bestaande services vast te stellen en te verwoorden.

■ Klantrelatiebeheer moet in staat zijn te meten of de serviceprovider voldoet aan de zakelijke behoeften van de klant.

■ Er zijn formele klachten- en escalatieprocessen voor klanten.

4.6.11 Metrics ■ Zakelijke doelstellingen en klantvereisten zijn gedocumenteerd en onderschreven.

■ Klanttevredenheids- en klantbehoudcijfers zijn onveranderd hoog. ■ Wijzigingen in service en strategie die verandering aanbrengen in de klantom geving resulteren in verbeterde klanttevredenheidsscores/hogere opbrengsten.

■ Kansen die nieuwe technologieën benutten zijn vastgesteld en zakelijk geëvalueerd en de ROI van een kans is gemeten.

■ De serviceprovider blijft consequent boven een bepaalde prestatiedrempel.

■ Serviceprestaties zijn in overeenstemming met zakelijke doelstellingen. ■ Het aantal klachten/escalaties wordt gemeten en de trend per periode en klant wordt vastgesteld.

4.6.12 Uitdagingen ■ De noodzaak betrokken te zijn bij het definiëren van services en te volgen (tracking) dat deze worden geleverd met de afgesproken servicelevels.

■ Een verleden van slechte services. ■ Klanten die niet bereid zijn hun requirements (eisen), feedback en kansen te delen.

■ Verwarring tussen de rol van de klantrelatiebeheerder en het proces klantrelatiebeheer. Klantrelatiebeheerders zijn vaak nodig om activiteiten uit te voeren van andere processen omdat zij het klantcontact onderhouden. Deze activiteiten zijn daarmee echter geen onderdeel van het proces klantrelatiebeheer.

4.6.13 Risico’s ■ Verwarring over waar precies de grenzen liggen met veel andere bedrijfsprocessen.

■ Een breuk tussen de klantgerichte processen en de op technologie gerichte processen.

■ 5.1 INLEIDING TOT SERVICEONTWERP Serviceontwerp volgt op servicestrategie in de servicelevenscyclus en houdt zich bezig met het ontwerpen en ontwikkelen van nieuwe of gewijzigde services en de daaraan gekoppelde processen. De focus in deze fase van de levenscyclus ligt op het ontwerpen van nieuwe of gewijzigde services, die worden geïntroduceerd in de productieomgeving.

Goed serviceontwerp heeft de volgende voordelen:

■ Betere afstemming van services met de behoeften van de business. ■ Verbeterde kwaliteit van dienstlevering. ■ Verbeterde consistentie van de service. ■ Verbeterde effectiviteit van prestaties. ■ Vereenvoudigde besluitvorming. ■ Verbeterde IT-administratie. ■ Vereenvoudigde invoering van nieuwe of gewijzigde services. ■ Het effectiever kunnen managen van services en IT-processen. ■ Verlaagde Total Cost of Ownership (TCO). Alle ontwerpactiviteiten in deze fase van de levenscyclus komen voort uit de behoeften en de vraag van de klant en zijn een weerslag van de strategie, de planning en het beleid geproduceerd in de fase servicestrategie. Elke fase van de levenscyclus vormt de input voor de volgende fase van de levenscyclus. Servicestrategie levert belangrijke input voor serviceontwerp, dat vervolgens input levert voor de servicetransitiefase en is daarom in wezen de ruggengraat van de servicelevenscyclus.

Om effectieve en efficiënte services te ontwerpen die voldoen aan de behoeften van de klanten, is het essentieel dat de uitvoer van de andere gebieden en processen is opgenomen in het serviceontwerpproces. De acht processen in de serviceontwerpfase zijn, zijn (zie ook afbeelding 5.0): 1. Ontwerpcoördinatie. 2. Servicecatalogusmanagement. 3. Servicelevelmanagement. 4. Capaciteitsmanagement. 5. Availabilitymanagement. 6. IT-service continuity management (ITSCM). 7. Information security management. 8. Leveranciersmanagement.

Afbeelding 5.0 De acht processen van serviceontwerp, gekoppeld aan de ITILlevenscyclus

5.1.1 Doel en doelstellingen Het doel van de serviceontwerpfase is het ontwerpen van nieuwe of aangepaste IT-services om daarmee de strategie van een serviceprovider te realiseren. Op deze wijze dient het mogelijk gemaakt te worden dat nieuwe of aangepaste

services zodanig in operationele omgevingen kunnen worden geïntroduceerd, dat de kwaliteit van levering, klanttevredenheid en kosteneffectiviteit verzekerd zijn.

De primaire

doelstelling is het zodanig ontwerpen van services, dat er

gedurende hun levenscyclus zo min mogelijk verbeteringen noodzakelijk zijn.

Om te zorgen dat de ontwikkelde services voldoen aan de verwachtingen van de klant, moeten de volgende acties worden ondernomen:

■ De nieuwe service moet worden gedocumenteerd vanaf de conceptfase van de serviceportfolio en deze documentatie moet worden bijgehouden gedurende het proces.

■ De service level requirements (SLR) (servicelevelvereisten) moeten duidelijk worden geformuleerd, gedocumenteerd, onderschreven en begrepen door alle stakeholders vóórdat de service wordt geleverd.

■ Op basis van de SLR’s kan het capaciteitsmanagementteam deze vereisten modelleren binnen de bestaande infrastructuur en daarmee assisteren in het ondersteunen van de uitvoering van het demandmanagementproces.

■ Als blijkt dat een nieuwe infrastructuur nodig is of meer ondersteuning is gewenst, moet financieel management worden ingeschakeld.

■ Voor de implementatiefase begint, moeten een bedrijfsimpactanalyse (BIA) en een risico-evaluatie worden uitgevoerd. Hieruit komt waardevolle informatie voort voor IT service continuity management (ITSCM) en het availability- en capaciteitsmanagement.

■ De servicedesk moet op snelheid worden gebracht wat betreft de nieuwe servicelevering voordat nieuwe services geleverd gaan worden.

■ Servicetransitie kan een plan opstellen voor de implementatie van de service.

■ Leveranciersmanagement moet worden ingeschakeld als er inkoop nodig is. Alle aspecten van de serviceontwerpfase en verwante gebieden vragen een holistische aanpak om te zorgen voor de effectieve en efficiënte integratie tussen functies en procesactiviteiten in de gehele IT-organisatie (inclusief alle resources en capabilities). Door te voorzien in een consistente, herhaalbare en meetbare holistische methode, zal de IT-organisatie beter zijn uitgerust voor

het leveren van de benodigde businessgerelateerde end-to-end-functionaliteit en kwaliteit om waarde aan klanten leveren. Om te voldoen aan de veranderende behoeften en vraag van de business, is het ontwerpen van effectieve en efficiënte IT-services een proces van balanceren tussen functionaliteit, beschikbare resources (menselijk, technisch en financieel) en beschikbare tijd. Dit is een continu proces in alle fasen van de levenscyclus van IT-services.

De serviceontwerpfase in de levenscyclus begint met verzoeken om nieuwe of gewijzigde eisen van de klant. Uiteindelijk moet er aan het einde van het ontwerpproces een serviceoplossing ontworpen zijn die aan de vereisten voldoet voordat de service in het transitieproces wordt opgenomen. De uiteindelijke uitvoer van de ontwerpfase is het serviceontwerppakket – daarover meer, later in dit hoofdstuk. Een goede voorbereiding en effectieve en efficiënte inzet van personeel, processen, producten (technologie en tools) en partners – de vier P’s van ITIL – is noodzakelijk om de ontwerpplannen en projecten kans van slagen te geven.

Tabel 5.1 De vier P’s van serviceontwerp

Gezien de onderlinge afhankelijkheid van afdelingen kunnen IT-services niet geïsoleerd worden ontworpen, transitie ondergaan of worden doorgevoerd. Iedereen in de organisatie moet op de hoogte worden gesteld van de onderliggende componenten en onderlinge relaties van de IT-dienstverlening (en de daarmee verband houdende betrokken afdelingen). Dit proces vereist een holistische aanpak, heldere communicatie en eist dat iedereen toegang heeft tot de juiste, meest recente en eenduidige IT-plannen, en dat iedereen wordt voorzien van de juiste informatie.

5.1.2 Bereik Serviceontwerp geeft richtlijnen voor het ontwerpen van geschikte en innovatieve services die voorzien in de huidige en toekomstige overeengekomen businessvereisten. In deze fase worden IT-services/oplossingen geïdentificeerd, gedefinieerd en in lijn gebracht met de eisen vanuit de business (business requirements). Figuur 5.1 laat het precieze bereik van serviceontwerp zien.

■ 5.2 ONTWERPASPECTEN Om te zorgen dat de organisatie streeft naar de hoogst mogelijke kwaliteit met een continue ‘focus op verbetering’ is een gestructureerde en resultaatgerichte aanpak nodig in elk van de vijf afzonderlijke aspecten van het ontwerp. Resultaatgericht betekent in dit geval gericht op ‘het voldoen aan de wensen van de klanten/gebruikers’. De vijf aspecten zijn: 1. Serviceoplossingen voor nieuwe of gewijzigde services. 2. De managementinformatiesystemen en -tools, waaronder de serviceportfolio. 3. De technologiearchitecturen en managementarchitecturen. 4. De vereiste processen. 5. De metrics.

5.2.1 Het ontwerpen van serviceoplossingen voor nieuwe of gewijzigde services Een gestructureerde ontwerpmethode is noodzakelijk om een nieuwe dienst te kunnen produceren tegen afgesproken kosten, functionaliteit en kwaliteit, en binnen het afgesproken tijdsbestek. Het proces moet iteratief en stapsgewijs zijn om aan de wijzigende wensen en eisen van klanten te voldoen. De gebieden die moeten worden beschouwd in het ontwerp van de serviceoplossing zijn onder andere:

■ Analyseren van de afgesproken zakelijke vereisten. ■ Evalueren van de bestaande IT-services en infrastructuur, en produceren van alternatieve serviceoplossingen, met een visie op het hergebruiken, anders inzetten, recyclen van bestaande componenten.

■ Budget- en uitgavenplannen voor ontwerp, transitie, productie en verbetering van de service.

Afbeelding 5.1 Het bereik van serviceontwerp (Bron: AXELOS)

■ Tijdslijnen voor de voltooiing van het ontwerpen, ontwikkelen, bouwen, testen en in gebruik nemen van de service.

■ Voor zover van toepassing, het evalueren van ROI (return on investment), VOI (value on investment) en TCO (total cost of ownership).

■ Overeenstemming bereiken over de voorkeursoplossing in termen van geplande doelstellingen en beoogde niveaus van utility en warranty.

■ Zorgen voor aansluiting op alle strategieën, beleidsregels, plannen en architectonische documenten.

■ Voltooide evaluatie van: organisatorische bereidheid, risicoanalyse, risicobeperking, operationele, zakelijke mogelijkheden en groei, IT-capaciteit en ontwikkeling.

■ Afstemming van afspraken over het operationele niveau en in onderliggende contracten met de serviceleveleisen.

5.2.2 Het ontwerp van de managementinformatiesystemen en tools, waaronder de serviceportfolio De serviceportfolio is het meest cruciale managementinformatiesysteem dat wordt gebruikt om alle processen te ondersteunen en dat de services van een serviceprovider beschrijft in termen van waarde voor de business. De zakelijke behoeften van de klant(en) worden in de serviceportfolio verwoord met het antwoord van de serviceprovider daarop. De zakelijke waarde van services beschrijven geeft inzicht in de kosten en opbrengsten ervan en maakt het daarmee mogelijk het concurrerend vermogen van het eigen serviceaanbod met die van andere aanbieders te vergelijken.

Net als binnen goede projectmanagementpraktijken mag er niet worden begonnen aan een nieuwe of gewijzigde service voordat het serviceportfoliomanagementproces de service heeft opgenomen. Zodra een strategische beslissing is genomen om een service op te nemen, begint de servicelevenscyclus aan de fase serviceontwerp: ‘het ontwerpen’ van de service, die uiteindelijk deel gaat uitmaken van de servicecatalogus.

De servicecatalogus is in wezen een subverzameling van de totale serviceportfolio. De servicecatalogus is een database (of een gestructureerd document) met informatie over alle operationele IT-services, met inbegrip van die welke beschikbaar zijn voor distributie. De servicecatalogus is het enige deel van het serviceportfolio dat wordt gepubliceerd voor klanten en wordt gebruikt om de verkoop en levering van IT-services te ondersteunen – meer hierover verderop in dit hoofdstuk.

De serviceportfolio bevat de informatie met betrekking tot elke service en de huidige status ervan binnen de organisatie. Hierna volgt een overzicht van de serviceportfolio, waarin de verschillende fasen worden uitgelicht. Het is belangrijk op te merken dat de klant alleen inzage heeft in de servicecatalogus. De andere delen van de portfolio zijn niet beschikbaar voor de klant.

Belangrijke opmerking: De serviceportfolio...

■ ...is eigendom van en wordt gemanaged door het serviceportfoliomanagementproces.

■ ...wordt ontworpen tijdens de servicetontwerpfase (zie het servicecatalogusmanagementproces).

■ ...wordt gecreëerd (gebouwd/getest/doorgevoerd) tijdens de servicetransitiefase.

5.2.3 Het ontwerpen van de technologie- en beheerarchitecturen De architectuurontwerpactiviteiten omvatten het voorbereiden van de blauwdrukken voor de ontwikkeling en ingebruikname van een ITinfrastructuur, de applicaties en data (in overeenstemming met de behoeften van de business). De term ‘architectuur’ wordt in verschillende contexten in verschillende betekenissen gebruikt. In de context van ITIL, wordt architectuur omschreven als de fundamentele organisatie van een systeem, belichaamd in zijn componenten, hun relaties onderling en met de omgeving, en de principes die leidend zijn voor het ontwerp en de evolutie ervan.

In de bovenstaande omschrijving wordt de term ‘systeem’ gebruikt in de meest algemene betekenis, verwijzend naar een verzameling componenten die zijn georganiseerd om een bepaalde functie of verzameling functies te vervullen.

Een systeem kan daarom variëren van de hele organisatie of een bedrijfsfunctie tot aan een informatiesysteem. Elk systeem op zich heeft een eigen architectuur, bestaande uit het volgende:

■ Componenten van het systeem. ■ De relaties ertussen (zoals controle-interfaces en data-uitwisselingen). ■ De relaties tussen het systeem en zijn omgeving (politiek, organisatorisch, technologisch enzovoort).

■ Ontwerpprincipes die de structuur en werking informeren, leiden en inperken.

ITIL formuleert dit architectuurontwerp als volgt:

Architectuurontwerp is het ontwikkelen en onderhouden van IT-beleid, strategieën, architecturen, ontwerpen, documenten, plannen en processen voor het uitrollen, doorvoeren en verbeteren van goede IT-services en -oplossingen op alle niveaus in de organisatie. ITIL doet de aanbeveling om businessprocessen en oplossingen met behulp van een servicegerichte architectuur (Service Oriented Architecture, SOA) te ontwerpen en te ontwikkelen.

Het ontwerpen van de architectuur is niet eenvoudig en varieert; soms moet men rekening houden met conflicterende behoeften. In elk geval moet ervoor worden gezorgd dat:

■ Er wordt voldaan aan de behoeften van de business en de producten en services ervan.

■ Een goede balans wordt gevonden tussen innovatie, risico’s en kosten. ■ Men zich conformeert aan frameworks, strategieën, beleidsregels enzovoort. ■ Er coördinatie is tussen de ontwerpers, planners, strategen enzovoort. Elke bedrijfsorganisatie (enterprise) is een complex systeem van functies, processen, structuren en informatiebronnen. De enterprise-architectuur moet inzicht geven in hoe dit alles met elkaar is verbonden om de doelstellingen van de organisatie te kunnen bereiken. De enterprise-architectuur is zowel groot als complex.

Er zijn verschillende architectuurframeworks beschikbaar, zoals TOGAF en Zachman, voor het ontwikkelen van enterprise-architecturen. De enterprisearchitectuur moet de volgende elementen bevatten:

■ Servicearchitectuur. ■ Applicatie-architectuur. ■ Informatie-architectuur. ■ IT-infrastructuurarchitectuur: •

Productarchitectuur;

•

Managementarchitectuur.

■ Omgevingsarchitectuur. Naast een technische component (applicaties, systeemsoftware, informatie en data, infrastructuur en omgevingssystemen) moet een

managementarchitectuur worden ontwikkeld. In dit verband zijn er vijf elementen om rekening mee te houden, te weten: de bedrijfstak / industrie (behoeften, eisen), personeel, processen, tools en technologie (IT-producten die worden gebruikt bij het verlenen van de services). Het is belangrijk dat de technologie niet de primaire focus is, maar de wensen en eisen van de klant.

Binnen het eerder beschreven framework is het mogelijk (ten minste) drie rollen voor de architectuur aan te wijzen. Deze zouden allemaal kunnen rapporteren aan een senior enterprise-architect in de organisatie:

Bedrijfs/organisatiearchitect – deze rol heeft te maken met: ■ De bedrijfsmodellen, de bedrijfsprocessen en het organisatieontwerp. ■ De structurele en functionele componenten van de organisatie en hun onderlinge relaties.

■ Hoe de bedrijfsfuncties en activiteiten van de organisatie onderling zijn verdeeld.

■ De governance van de organisatie en de benodigde rollen en verantwoordelijkheden.

Servicearchitect – deze rol heeft te maken met: ■ De service, de data en de applicatiearchitecturen. ■ De logische architecturen die de business ondersteunen. ■ De relaties tussen logische architecturen. IT-infrastructuurarchitect – deze rol heeft te maken met: ■ Het fysieke technologiemodel. ■ De infrastructuurcomponenten en hun relaties. ■ De keuzes in technologieën, interfaces en protocollen. ■ De selectie van producten om de infrastructuur te implementeren.

5.2.4 Het ontwerpen van de benodigde processen Werken met vastgestelde processen is de basis van ITIL. Door vast te leggen wat de activiteiten zijn en wat de in- en uitvoer, is het mogelijk efficiënter en effectiever te werken, en dat vooral op een meer klantgerichte manier. Door evaluatie van de processen kan de organisatie de efficiëntie en effectiviteit nog verder verbeteren. De volgende stap is het bepalen van normen en

standaarden. Daarmee kan de organisatie de kwaliteitseisen met de uitvoer in verband brengen. Deze methode correspondeert met de managementcyclus plannen-doen–controleren–actie (Plan – Do – Check – Act) van Deming.

Elk proces moet een proceseigenaar hebben die eindverantwoordelijk is voor het proces en het managen ervan. Serviceontwerp ondersteunt de proceseigenaar in het ontwerpproces door het standaardiseren van termen en sjablonen, en door ervoor te zorgen dat processen consistent en geïntegreerd zijn.

Tevens moeten ook de verschillende rollen in het proces ontworpen worden. Hiervoor kan het RACI-model, zoals besproken in hoofdstuk 2, gebruikt worden.

5.2.5 Het ontwerpen van metrics Om het proces van ontwikkelen effectief te leiden en te beheren moeten regelmatig assessments worden uitgevoerd. Het geselecteerde assessmentsysteem moet worden gesynchroniseerd met de capaciteit en de volwassenheid van de processen die worden geëvalueerd. Zorgvuldigheid is nodig omdat dit het gedrag van de servicelevering kan beïnvloeden. Een gedetailleerde assessment van onvolwassen processen is niet mogelijk. Er zijn vier elementen die kunnen worden onderzocht, namelijk de

nakoming (compliance), effectiviteit en efficiëntie

voortgang,

van het proces. Waar de

processen zich in de loop der tijd ontwikkelen, moeten de meeteenheden zich ook ontwikkelen. Daarom ligt de nadruk bij volgroeide processen meer op de beoordeling van efficiëntie en effectiviteit.

De redenen om te meten zijn om te leiden, te rechtvaardigen, in te grijpen en te valideren. Aanvullende informatie kan worden gevonden in hoofdstuk 8 over continue serviceverbetering.

■ 5.3 ONTWERPACTIVITEITEN 5.3.1 Ontwikkeling van eisen Er zijn drie soorten eisen voor elk systeem, namelijk:

1.

Functionele eisen – Deze beschrijven datgene wat noodzakelijk is om een bepaalde businessfunctie (Inkoop, Marketing, Productie enzovoort) of proces te ondersteunen. Functionele eisen hebben betrekking op de utilityaspecten van een service.

2.

Beheer- en operationele eisen – Deze beschrijven de niet-functionele eisen van de IT-serviceverlening. De eisen dienen als basis voor het schatten van de kosten en ondersteuning voor de levensvatbaarheid van de voorgestelde service. Eisen van beheer en uitvoering hebben betrekking op de warranty-aspecten van een service.

Afbeelding 5.2 Processchema van serviceontwerp (Gebaseerd op bron: AXELOS) 3.

Gebruikseisen – Deze eisen betreffen een groot aantal kwaliteitsaspecten, zoals: beheersbaarheid, efficiency, beschikbaarheid en betrouwbaarheid, capaciteit en performance, security, installatie, continuïteit, controleerbaarheid, onderhoudbaarheid, bedienbaarheid, meetbaarheid en capability om te rapporteren.

Deze eisen zorgen ervoor dat de services voldoen aan de verwachtingen van de gebruikers in termen van gebruiksgemak en gebruiksvriendelijkheid.

Eisenonderzoek Er zijn verschillende onderzoekstechnieken om te komen tot heldere eisen. Omdat klanten vaak onzeker zijn over de eisen, is de ondersteuning van een ontwikkelaar soms noodzakelijk. Deze persoon moet zich bewust zijn van het feit dat mensen hem/haar kunnen zien als ‘iemand van de IT-afdeling’ die de eisen oplegt. Daarom moet er met een zekere voorzichtigheid te werk worden gegaan.

5.3.2 Problemen bij het ontwikkelen van eisen Er kunnen verschillende problemen optreden bij het ontwikkelen van eisen:

■ Gebrek aan relevantie ten opzichte van de doelstellingen van de service. ■ Gebrek aan duidelijkheid of dubbelzinnigheid in de verwoording. ■ Duplicatie van eisen. ■ Conflicten tussen eisen. ■ Onzekerheid aan de kant van gebruikers. ■ Inconsistentie in het detailleringsniveau. Om deze en andere problemen het hoofd te bieden, is het belangrijk deelnemers aan te wijzen. Drie groepen moeten betrokken zijn bij het opstellen van eisen: de klant, de gebruikersgemeenschap en het serviceontwikkelingsteam.

Eisen documenteren Het eisendocument is de kern van het proces. Dit document bevat elke afzonderlijke eis in een standaard sjabloon. De eisen die uiteindelijk van de gebruikers komen moeten ook worden opgenomen. Elke eis moet SMART (specifiek, meetbaar, bereikbaar/geschikt (Achievable/Appropriate), realistisch/relevant en tijdig/tijdsgebonden) worden geformuleerd. Daarnaast moeten ze worden gecontroleerd om er zeker van te zijn dan ze helder, ondubbelzinnig en redelijk zijn, gesynchroniseerd met de doelstellingen van de klant en niet in conflict met enige andere eis.

Het resultaat wordt vervolgens vastgelegd in de eisencatalogus. De eisencatalogus moet een component zijn van de eisenportfolio in de complete serviceportfolio. De gebruikerseisen moeten hierin zijn opgenomen, voorzien van een identificatienummer, de bron, de eigenaar en een prioritering (bijvoorbeeld volgens de MoSCoW -methode: Must have, Should have, Could have, Won’t have). En ook moet het betrokken bedrijfsproces erin beschreven worden.

De eisenanalyse is een iteratief proces. Met andere woorden, de eisen veranderen in de loop van het ontwikkelingsproces van de service. Het is dan ook belangrijk om de gebruikers bij het gehele ontwikkelingsproces te betrekken.

Nadat de gewenste serviceoplossing is ontworpen, moeten de daarop volgende activiteiten ook worden uitgevoerd in de serviceontwerpfase voordat de oplossing overgaat naar de servicetransitiefase. Deze daaropvolgende activiteiten zijn:

■ Evaluatie van alternatieve serviceoplossingen. ■ De serviceoplossing ontwikkelen.

5.3.3 Evaluatie van alternatieve oplossingen Als er sprake is van services en oplossingen van een externe serviceprovider, kunnen aanvullende evaluaties nodig zijn:

■ Een aantal leveranciers selecteren en een aanbestedingsprocedure doorlopen. ■ Evaluatie en beoordeling van de reacties van de leveranciers en de oplossingen die ze voorstellen. En op basis daarvan de leverancier(s) selecteren waar de voorkeur naar uitgaat.

■ Evaluatie en begroting van de alternatieve ontwerpen. Wanneer externe leveranciers betrokken zijn bij de voorkeursoplossing, moet de organisatie:

■ Alle noodzakelijke controles op de voorkeursleverancier uitvoeren. ■ De bepalingen en condities van eventuele nieuwe contracten vastleggen. ■ De geselecteerde oplossing inkopen.

5.3.4 De serviceoplossing ontwikkelen

De fase ‘ontwikkeling’ bestaat uit het vertalen van het serviceontwerp in een plan. Afhankelijk van het bereik en de schaal van de nieuwe of gewijzigde service zal een programma- of projectmatige aanpak nodig zijn. Ongeacht de gebruikte methode zal het plan, project of programma verantwoordelijk zijn voor het leveren van een of meer componenten van de service. Hieronder kunnen vallen:

■ Zakelijke behoeften/eisen. ■ Strategie voor de ontwikkeling en/of acquisitie van de oplossing. ■ Betrokken tijdschema’s. ■ Benodigde resources, financiering, architecturen, applicaties, informatie en medewerkers.

■ Ontwikkeling van alle samenstellende componenten van de service, inclusief beheermechanismen zoals metingen, bewaking en rapportage.

■ Alle testplannen. Tabel 5.2 Strategieën voor het leveren van IT-services

Men moet de juiste projectmanagement-aanpak volgen om conflicten te vermijden. Zorgvuldig projectmanagement is noodzakelijk om ervoor te zorgen dat de verschillende te ontwikkelen componenten goed op elkaar aansluiten.

Ontwerpers zijn natuurlijk vrij om services te ontwerpen. Maar het zal duidelijk zijn dat zij afhankelijk zijn van interne resources (zoals beschikbare

financiële middelen) en externe omstandigheden. Denk bij dat laatste aan bijvoorbeeld de impact van ISO 20000-certificering, SOx en COBIT.

■ 5.4 BASISBEGRIPPEN VAN SERVICEONTWERP 5.4.1 Leveringsopties voor IT-services De kloof tussen de huidige en de gewenste situatie hoeft niet noodzakelijk te worden overbrugd door de organisatie zelf. Er zijn verschillende strategieën die kunnen worden overwogen voor het outsourcen van sommige of alle services, elk met voor- en nadelen. De meest voorkomende hiervan zijn samengevat in tabel 5.2

De keuze voor een van de bovenstaande leveringsstrategieën hangt af van de situatie waarin de organisatie zich bevindt. Verschillende dingen kunnen bij de beslissing een rol spelen. De interne competenties en behoeften van de organisatie en de medewerkers (organisatiecultuur) hebben een aanzienlijke invloed op de leveringsstrategie. Welke strategie er ook wordt gekozen, het is altijd essentieel de prestaties te evalueren en te herzien om uiteindelijk te kunnen blijven voldoen aan de veranderende vraag in de markt.

5.4.2 Applicatieontwikkeling en -management De ITIL-definitie van een applicatie is:

Een applicatie is een softwareprogramma (of meerdere softwareprogramma’s) met een speci eke functie die directe ondersteuning biedt voor de uitvoering van bedrijfsprocessen en/of procedures. Applicaties, samen met data en infrastructuur, omvatten de technische component van IT-services. Het is essentieel dat de applicaties die worden geleverd overeenkomen met de eisen van de klant. Organisaties besteden vaak veel tijd aan de functionele eisen van de nieuwe service, terwijl er te weinig tijd wordt besteed aan het ontwerp van de beheer- en operationele (nietfunctionele) eisen van de service. Dit betekent dat wanneer de service wordt verricht, dit geheel voldoet aan de functionele eisen, maar niet aan de verwachtingen van het bedrijf en de klant op het gebied van kwaliteit en prestaties.

Twee alternatieve methoden zijn nodig om applicatiemanagement te implementeren, namelijk:

■ Serviceontwikkelingslevenscyclus – (SDLC, Service Development Lifecycle) is een systematische methode voor probleemoplossing ter ondersteuning van de ontwikkeling van een IT-service.

■ Applicatieonderhoud – Bekijkt alle services in het algemeen om te zorgen voor een doorlopend proces van applicatiemanagement en -onderhoud. Alle applicaties worden consistent beschreven in de applicatieportfolio, die is afgestemd op de eisen van de klanten.

Applicatieframeworks Het applicatieframework omvat alle management- en operationele aspecten en biedt oplossingen voor alle of beheer- en operationele eisen voor een applicatie. Architectuur-gerelateerde activiteiten moeten wat betreft planning en management gescheiden worden van activiteiten die gericht zijn op het ontwikkelen van een specifieke applicatie. Applicatieontwerpers concentreren zich op één applicatie. Ontwikkelaars van een applicatieframework daarentegen richten zich op meerdere applicaties en op de gemeenschappelijke kenmerken van de betreffende applicaties in het bijzonder.

CASE-tools Ontwikkelomgevingen hebben van oudsher hun eigen Computer Assisted/Aided Software Engineering tools (CASE tools) die, bijvoorbeeld, de middelen bieden om eisen te specificeren, ontwerpdiagrammen te tekenen of applicaties te ontwikkelen.

Applicatiemanagement Na de ontwerpfase moet de applicatie verder worden ontwikkeld. Zowel de applicatie als de omgeving moet worden voorbereid op de lancering. In de applicatieontwikkelingsfase spelen de volgende kwesties:

■ Consistente coderingsconventies. ■ Onafhankelijke structurele richtlijnen voor applicaties. ■ Bedrijfsgereedheid testen. ■ Beheerchecklist voor de bouwfase. ■ Bepalen van de teamrollen voor de organisatiestructuur.

Belangrijke uitvoer van applicatieontwikkeling is onder andere:

■ Scripts voor het starten en stoppen van een applicatie. ■ Scripts voor het bewaken van zowel hardware- als softwareconfiguraties. ■ Specificaties van de meeteenheid die kunnen worden verkregen uit de applicatie.

■ SLA-doelstellingen en eisen. ■ Operationele eisen en documentatie. ■ Supporteisen. Rapid Application Development Het is noodzakelijk om de verschillen te begrijpen tussen objectgeoriënteerde en gestructureerde systeemontwikkeling en wat de basisprincipes zijn van Rapid Application Development (RAD). Dit leert ons in te zien hoe de keuze van een softwareoplossing de structuur van de levenscyclusbenadering wijzigt.

Traditionele ontwikkelmethoden gaan uit van het principe dat de eisen van de klant/ gebruiker aan het begin van de levenscyclus kunnen worden bepaald, en dat de ontwikkelkosten onder controle kunnen worden gehouden door changemanagement. RAD– benaderingen beginnen met het besef dat wijzigen onvermijdelijk is en dat ontmoedigen van wijzigingen eenvoudigweg wijst op passiviteit ten opzichte van de marktontwikkelingen. De RAD–methode is een incrementele en iteratieve ontwikkelmethode.

De

incrementele methode

houdt in dat een service beetje bij beetje wordt

ontworpen. Onderdelen worden afzonderlijk ontwikkeld en opgeleverd. Elk onderdeel wordt ondersteund door een van de bedrijfsfuncties en samen ondersteunen zij het geheel. Het grote voordeel van deze methode is de kortere levertijd. De ontwikkeling per onderdeel vereist echter dat alle fasen van de levenscyclus worden doorgelopen.

De

iteratieve methode

impliceert dat de levenscyclus vele malen wordt

herhaald gedurende de ontwerpfase. Prototypen van het gehele proces worden gebruikt om klantspecifieke eisen beter te begrijpen en daarna het ontwerp daarop aan te passen. Een combinatie van de twee methoden is mogelijk. Een organisatie kan beginnen met het specificeren van de eisen voor de gehele service, gevolgd

door het stapsgewijs ontwerpen en ontwikkelen van de applicatie.

Commerciële standaardoplossingen Veel organisaties kiezen standaard softwareoplossingen om aan de behoeften en vraag te voldoen. Voor de selectie, aanpassing en implementatie van dergelijke pakketten is een framework nodig. Het is van essentieel belang om van begin af aan te weten welke eisen aan de pakketten worden gesteld op het management- en operationele niveau. Het is, in verband met inkoop, even belangrijk om inzicht te hebben in de voor- en nadelen van dergelijke pakketten. Naast de functionele eisen, is het tevens belangrijk om de eisen vast te stellen waaraan het product, de leverancier en de integratie van het servicepakket moeten voldoen.

Data- en informatiemanagement Het is van kritisch belang om bedrijfsinformatie (-data) goed onder controle te hebben teneinde in staat te zijn om effectieve services te ontwikkelen, te leveren en te ondersteunen. Factoren voor succesvol datamanagement zijn onder andere:

■ De gebruikers hebben toegang tot de informatie die zij nodig hebben voor hun werk.

■ Informatie wordt gedeeld in de organisatie. ■ De kwaliteit van de informatie wordt op een acceptabel niveau gehouden. ■ Juridische aspecten op het gebied van privacy, security en vertrouwelijkheid zijn in acht genomen.

Als data niet effectief worden beheerd, kan dat risico’s met zich meebrengen. Bijvoorbeeld mensen verzamelen verkeerde informatie, informatie die er niet toe doet, of ze gebruiken verouderde informatie. Datamanagement is nodig om dit te voorkomen. Datamanagement zorgt er ook voor dat informatie alleen toegankelijk wordt gemaakt voor degenen die geautoriseerd zijn om over deze informatie te mogen beschikken.

Bereik Er zijn vier beheergebieden op het gebied van data- en informatiemanagement: 1. Beheer van data.

2. Beheer van data- en informatietechnologie. 3. Beheer van informatieprocessen. 4. Beheer van datastandaarden en beleid.

Databeheer en de servicelevenscyclus Om het gebruik van data in bedrijfsprocessen te begrijpen is het aan te raden antwoord te geven op de volgende vragen:

■ Welke data hebben we nu en hoe zijn die geclassificeerd? ■ Welke data moeten worden verzameld via de bedrijfsprocessen? ■ Hoe worden de data opgeslagen en beheerd? ■ Hoe wordt toegang tot de data verkregen en door wie? ■ Hoe worden data vernietigd en door wie? ■ Hoe wordt de kwaliteit van de data beschermd? ■ Hoe kunnen de data toegankelijker en beschikbaarder worden gemaakt? Data zijn belangrijk, niet alleen voor organisaties waarvoor het verstrekken van data een core business (kernactiviteit) is, bijvoorbeeld voor een persbureau als Reuters. Data worden steeds meer gezien als een gemeenschappelijk eigendom met een waarde die kan worden uitgedrukt in financiële termen. Daarvoor bestaan diverse mogelijkheden:

■ Data waarderen op hun beschikbaarheid. Welke bedrijfsprocessen zouden niet mogelijk zijn zonder de betreffende data?

■ Verloren data waarderen. Wat zijn de kosten om de data opnieuw te verkrijgen als ze verloren zouden gaan?

■ Data waarderen met het oog op de datalevenscyclus. Hoe worden data gecreëerd of verkregen, hoe worden ze beschikbaar gesteld voor gebruik en hoe worden ze verwijderd (archivering of fysieke vernietiging)? Wat zijn de kosten als één van deze fasen overgedaan moet worden?

Data classificeren Data kunnen op drie niveaus worden geclassificeerd: 1. Operationele data. Deze data zijn noodzakelijk voor de continuïteit van de organisatie en zijn het minst specifiek. 2. Tactische data. Dit zijn data die nodig zijn voor het lijn- of hoger management; onder andere verwijzen deze naar historische data, uit de managementinformatiesystemen.

3. Strategische data. Deze verwijzen naar de langetermijntrends in vergelijking met externe (markt-)informatie.

Data-eigenaar Onder de verantwoordelijkheden van de data-eigenaar vallen:

■ Bepalen wie data mag aanmaken, aanpassen, lezen en verwijderen. ■ Toestemming voor de wijze waarop data worden vastgelegd of verkregen. ■ Goedkeuren van securityniveaus. ■ Goedkeuren van bedrijfsbeschrijving en een doel. Data-integriteit Bij het formuleren van IT-services is het belangrijk dat ook de niet-functionele eisen (beheer- en operationele eisen, zie paragraaf 5.3) ten aanzien van de ITserviceverlening worden meegenomen. In het bijzonder voor de volgende gebieden:

■ Terughalen van verloren data. ■ Gecontroleerde toegang tot data. ■ Implementatie van beleid voor het archiveren van data. ■ Periodieke bewaking van data-integriteit.

■ 5.5 ONTWERPCOÖRDINATIE 5.5.1 Inleiding Het doel van het proces ontwerpcoördinatie is ervoor te zorgen dat de doelen en de doelstellingen van de serviceontwerpfase worden gerealiseerd, door het verzorgen en onderhouden van één enkel punt ten behoeve van de coördinatie en controle van alle activiteiten en processen in deze fase van de servicelevenscyclus

De

doelstellingen van ontwerpcoördinatie zijn:

■ Ervoor zorgen dat de te ontwerpen nieuwe services, of het herontwerp van bestaande services, voldoen aan de door de organisatie gestelde eisen.

■ Coördineren van alle ontwerpactiviteiten in programma’s, projecten, wijzigingen en supportteams (intern en extern) evenals planningen, resources en het bemiddelen bij (eventuele) conflicten.

■ Produceren van serviceontwerppakketten (SDP’s, service design packages) op basis van servicecharters en wijzigingsverzoeken (change requests).

■ Zorgen dat geschikte serviceontwerpen en/of serviceontwerppakketten (SDP’s) worden geproduceerd en dat die worden overgedragen aan servicetransitie zoals afgesproken.

■ Beheren van de kwaliteitscriteria, eisen en overdrachtspunten van servicestrategie naar serviceontwerp en dan naar servicetransitie.

■ Zorgen dat alle servicemodellen, -oplossingen en -ontwerpen in overeenstemming zijn met alle strategische, architecturale, governance en andere eisen van de (bedrijfs)-organisatie.

■ De effectiviteit en efficiëntie van serviceontwerpactiviteiten en -processen verbeteren.

■ Erop toezien dat alle betrokken partijen hetzelfde ITSM-framework toepassen. Dit framework beschrijft standaarden ten aanzien van (herbruikbare) ontwerppraktijken in de vorm van activiteiten, processen en ondersteunende systemen.

■ Bewaken en verbeteren van de prestaties tijdens de gehele serviceontwerplevenscyclus.

Bereik Het bereik van het ontwerpcoördinatieproces omvat alle ontwerpactiviteiten. In het bijzonder alle nieuwe of gewijzigde serviceoplossingen die worden ontworpen voor transitie naar de operationele omgeving.

Niet elke ontwerpactiviteit vereist hetzelfde nauwkeurigheidsniveau om succes te verzekeren. Dus een aanzienlijk aantal ontwerpinspanningen zal weinig of geen afzonderlijke aandacht vragen van het ontwerpcoördinatieproces. Ontwerpinspanningen kunnen de volgende kenmerken hebben:

■ Ze zijn onderdeel van een programma en/of van een project. ■ Af te handelen via het changeproces. ■ Uitgebreid en complex. ■ Eenvoudig en snel. Elke organisatie moet criteria vastleggen die het niveau van nauwkeurigheid en de details exact beschrijven. Ontwerpcoördinatie dient deze criteria per ontwerp toe te passen. Van welk perspectief een organisatie ook uitgaat, het

eindresultaat van het ontwerpcoördinatieproces moet altijd zijn dat wijzigingen met succes worden doorgevoerd. Onder een succesvolle wijziging verstaan we dat de gestelde eisen aan de zakelijke doelstellingen behaald worden. Dat er geen, of zo minimaal mogelijke, verstoringen optreden op de bedrijfsvoering. En dat de wijziging op tijd, binnen budget en met het juiste kwaliteitsniveau is gerealiseerd.

Waarde voor de business De belangrijkste waarde van het ontwerpcoördinatieproces voor de business is dat er een verzameling kwalitatief goede oplossingsontwerpen en serviceontwerppakketten ontwikkeld wordt waarmee de organisatie de door haar gewenste zakelijke doelstellingen kan realiseren.

Het werk van ontwerpcoördinatie kan:

■ zorgen dat de gewenste waarde voor de business wordt bereikt tegen een acceptabel risico- en kostenniveau;

■ herbewerking en niet-geplande arbeidskosten minimaliseren gedurende latere stadia in de servicelevenscyclus;

■ leiden tot grotere klant- en gebruikerstevredenheid; ■ ervoor zorgen dat alle services voldoen aan een consistente architectuur, zodat naadloze integratie mogelijk is;

■ een verbeterde focus op de servicewaarde en zakelijke doelstellingen opleveren;

■ een verbeterde efficiëntie en effectiviteit van alle ontwerpactiviteiten en processen bewerkstelligen;

■ ervoor zorgen dat de kwaliteit van de ontworpen serviceoplossingen hoger wordt.

Serviceontwerppakket Tijdens de serviceontwerpfase is ontwerpcoördinatie ervoor verantwoordelijk dat er een serviceontwerppakket (service design package, SDP) tot stand komt. Het serviceontwerppakket bestaat uit een verzameling documenten die alle aspecten van de service definiëren inclusief de vereisten in elke fase van zijn levenscyclus. Deze informatie is vooral van belang voor het servicetransitieteam. Voorbeelden van genoemde documenten zijn:

■ Businessvereisten (requirements). ■ Functionele vereisten (requirements). ■ Service level requirements. ■ Beheervereisten. ■ Het serviceontwerp. ■ Organizational readiness-beoordeling. ■ Servicetransitieplan (hoe dient het bouwen, testen en uitrollen plaats te vinden?).

■ Acceptatieplan voor serviceproductie. ■ Service operationeel acceptatieplan (Hoe dient de service operationeel gemaakt te worden?).

Een serviceontwerppakket wordt geproduceerd voor elke nieuwe IT-service, omvangrijke wijziging of bij het uitfaseren van een service.

5.5.2 Activiteiten, methoden en technieken Ontwerpcoördinatieactiviteiten vallen uiteen in twee categorieën: algemene activiteiten binnen het levenscyclusstadium en afzonderlijke ontwerpactiviteiten. De algemene activiteiten binnen het levenscyclusstadium omvatten: 1. Formuleren en onderhouden van beleidsregels en methoden. 2. Plannen van ontwerpmiddelen en -mogelijkheden. 3. Coördineren van ontwerpactiviteiten. 4. Managen van ontwerprisico’s en -problemen. 5. Verbeteren van het serviceontwerp.

De afzonderlijke ontwerpactiviteiten moeten het volgende omvatten: 1. Plannen van de ontwerpactiviteiten. 2. Coördineren van de ontwerpactiviteiten. 3. Monitoren van de voortgang van de ontwerpactiviteiten. 4. Review van de ontwerpen en zekerstellen dat de serviceontwerppakketten worden overgedragen.

Het werk tijdens de serviceontwerpfase bestaat uit de volgende activiteiten, die worden gecoördineerd door ontwerpcoördinatie:

■ Verzamelen, analyseren en technisch uitwerken van eisen om te zorgen dat:

•

de zakelijke, technische eisen en de eisen van de serviceprovider op elkaar zijn afgestemd en dat deze eisen duidelijk gedocumenteerd worden;

•

deze allemaal de zakelijke eisen op een correcte wijze ondersteunen.

■ Op een juiste manier ontwerpen van alle aspecten van de serviceoplossingen.

■ Evalueren, herzien en onderhouden van alle processen die zijn betrokken bij serviceontwerp, inclusief de ontwerpen, planning, architecturen, beleidsregels en documentatie.

■ Ontwikkelen en onderhouden van IT-beleidsregels en ontwerpdocumenten. ■ Evalueren/herzien van ontwerpdocumenten met het oog op de compleetheid en om te beoordelen of ze voldoen aan de standaardnormen.

■ Planningen maken voor het inzetten en doorvoeren van IT-strategieën met behulp van ‘roadmaps’, programma’s en projectplannen.

■ Risicoassessment en -management van alle ontwerpprocessen en deliverables.

■ Zorgen voor aansluiting op alle (bedrijfs)organisatie- en IT-strategieën en beleidsregels.

■ Productie van serviceontwerpen en/of serviceontwerppakketten voor nieuwe of gewijzigde services.

5.5.3 Informatiemanagement De belangrijke informatie die wordt gegenereerd door het ontwerpcoördinatieproces wordt opgenomen in het serviceontwerppakket. Het serviceontwerppakket bevat alles wat nodig is om de service alle stadia van de servicelevenscyclus te laten doorlopen. Het serviceontwerppakket kan bestaan uit meerdere documenten die opgenomen moeten zijn in het complete kennismanagementsysteem voor services (SKMS, Service Knowledge Management System) en moeten zijn beschreven in het configuratiemanagementsysteem (CMS).

5.5.4 Interfaces ■ Servicestrategie

– Gebruiken van informatie die is opgenomen in de IT-

strategie en serviceportfolio.

■ Servicetransitie

– De overdracht van het ontwerp van serviceoplossingen

in het serviceontwerppakket.

■ Serviceportfoliomanagement – Levert de servicecharter (opstartdocument) en alle bijbehorende documentatie zoals zakelijke eisen, eisen van serviceutility en -warranty, risico’s en prioriteiten.

■ Changemanagement – Beleidsregels en afspraken die overeengekomen zijn tussen ontwerpcoördinatie en changemanagement.

■ Financieel management voor IT-services – Geeft een overzicht van de waardepropositie voor de nieuwe of gewijzigde service en het beschikbare budget.

Afbeelding 5.3 Activiteiten van ontwerpcoördinatie (Gebaseerd op bron: AXELOS)

■ Klantrelatiebeheer – Biedt inlichtingen en informatie over de vereisten van de bedrijfsdoelstellingen, klantbehoeften en -prioriteiten en dient als de interface met de klant op strategisch niveau.

■ Transitieplanning en -support •

Ontwerpcoördinatie levert het serviceontwerppakket aan de servicetransitiefase.

•

Transitieplanning en -support voert de complete planning en coördinatie uit voor het servicetransitiestadium, op dezelfde manier als ontwerpcoördinatie dat doet voor serviceontwerp.

■ Strategiemanagement voor IT-services – Biedt informatie over de huidige en zich ontwikkelende servicestrategie om te zorgen dat ontwerprichtlijnen en -documentatie in overeenstemming blijven met de strategie.

■ Release & deployment management – Managet de planning en uitvoering van afzonderlijke geautoriseerde wijzigingen, releases en het uitrollen. De planning en het ontwerpen voor de uitgave en uitrol worden uitgevoerd tijdens serviceontwerp.

■ Servicevalidation & -testing – Plannen en uitvoeren van de testen om na te gaan dat de service overeenkomt met zijn ontwerpspecificatie en zal voldoen aan de behoeften van de business.

■ Change evaluation – Stelt de prestaties van een servicewijziging vast. Omvat de evaluatie van het serviceontwerp om er zeker van te zijn dat deze aan de bedoelde vereisten kan voldoen.

■ Servicelevelmanagement – Verantwoordelijk voor het formuleren en afstemmen van de serviceleveleisen voor nieuwe of gewijzigde services, en dat op een consistente manier volgens de werkwijzen die in samenwerking met ontwerpcoördinatie zijn ontwikkeld.

■ Availability, capaciteit, IT-service continuity management en information security management – Elk van deze processen is actief betrokken in serviceontwerp en moet deze ontwerpactiviteiten consistent uitvoeren, volgens de werkwijzen die in samenwerking met ontwerpcoördinatie zijn ontwikkeld.

■ Leveranciersmanagement – Zorgt dat de bijdragen van leveranciers aan de ontwerpactiviteiten goed worden gemanaged. Dit proces zorgt ervoor dat afspraken over werkwijzen waar nodig worden genomen in de leverancierscontracten en -overeenkomsten en managet vervolgens de prestaties van de leveranciers tijdens de serviceontwerpfase.

5.5.5 Aanleidingen (triggers) Triggers voor het ontwerpcoördinatieproces zijn wijzigingen in de zakelijke eisen en services. Wijzigingsverzoeken (RfC’s, Requests for Changes) en het opstarten van nieuwe programma’s en projecten zijn de hoofdaanleidingen.

Een andere belangrijke aanleiding voor het herzien van ontwerpcoördinatieactiviteiten is als de algemene IT-strategie wordt herzien.

5.5.6 Invoer ■ Servicecharters voor nieuwe, aanzienlijk gewijzigde services of in te trekken services.

■ Wijzigingsverzoeken vanuit enig stadium van de servicelevenscyclus. ■ Changerecords en geautoriseerde wijzigingen. ■ Zakelijke informatie over de huidige en toekomstige eisen. ■ Businessimpactanalyse. ■ Governance-eisen. ■ Beleidsregels en eisen van de (bedrijfs)organisatie en vanuit wet- en regelgeving.

■ De enterprise-architectuur. ■ De IT-strategie, waaronder beperkingen en beperkte middelen. ■ De programma- en projectplanningen. ■ De serviceportfolio. ■ De servicecatalogus. ■ De wijzigingenplanning. ■ Het configuratiemanagementsysteem (CMS). ■ Feedback van alle andere processen. ■ Managementsystemen. ■ Metrics en meetmethoden.

5.5.7 Uitvoer ■ Uitgebreide en consistente verzameling serviceontwerpen en serviceontwerppakketten.

■ Een bewerkte enterprise-architectuur. ■ Aangepaste managementsystemen. ■ Aangepaste metrics en meetmethoden. ■ Aangepaste processen. ■ Bijgewerkt serviceportfolio. ■ Bijgewerkte servicecatalogus. ■ Bijgewerkte changerecords.

5.5.8 Kritieke succesfactoren

■ Accurate en consistente serviceontwerppakketten. ■ Het managen van conflicterende vraag naar gedeelde middelen. ■ Nieuwe en gewijzigde services voldoen aan de verwachtingen van de klant.

5.5.9 Metrics ■ Daling van het aantal opeenvolgende revisies van de inhoud van serviceontwerppakketten.

■ Daling (procentueel) van de noodzakelijke herbewerkingen voor nieuwe of gewijzigde serviceoplossingen in volgende levenscyclusstadia.

■ Toename van de tevredenheid over de serviceontwerpactiviteiten in het project en bij medewerkers.

■ Minder problemen vanwege conflicten over serviceontwerpmiddelen. ■ Procentuele stijging van het aantal succesvolle nieuwe en gewijzigde services in de zin van uitkomsten, kwaliteit, kosten en tijdigheid.

■ Verbeterde effectiviteit en efficiëntie in de serviceontwerpprocessen, activiteiten en ondersteunende systemen.

■ Lager aantal/percentage noodwijzigingsverzoeken vanuit projecten. ■ Procentuele stijging in het aantal services in transitie dat consistent de afgesproken servicelevels bereikt.

5.5.10 Uitdagingen ■ Het in stand houden van kwalitatief goede en duurzame ontwerpen en serviceontwerppakketten op alle terreinen van de business, services en infrastructuur.

■ Zorgen dat voldoende tijd en middelen worden besteed aan ontwerpcoördinatie-activiteiten en dat de rollen en verantwoordelijkheden van het proces zijn toegewezen aan de juiste personen en/of groepen om deze te vervullen.

■ Ontwikkelen van algemene ontwerppraktijken om ontwerpen van een hoge kwaliteit te produceren zonder daarbij onnodige bureaucratie te introduceren.

5.5.11 Risico’s ■ Potentieel gebrek aan vaardigheden en kennis (competenties). ■ De business is terughoudend om erbij betrokken te worden. ■ Slechte sturing en strategie.

■ Gebrek aan informatie over zakelijke prioriteiten. ■ Eisen en gewenste uitkomsten zijn slecht geformuleerd. ■ Terughoudendheid van projectmanagers om te communiceren en mee te doen.

■ Slechte communicatie. ■ Gebrek aan betrokkenheid van alle stakeholders. ■ Onvoldoende interactie met en inbreng van andere levenscyclusfasen. ■ Proberen tijd en geld te besparen tijdens het ontwerpstadium.

■ 5.6 SERVICECATALOGUSMANAGEMENT 5.6.1 Inleiding Het doel van servicecatalogusmanagement (service catalogue management, SCM) is om een consistente informatiebron te zijn voor alle overeengekomen services. Ze zorgt ervoor dat de informatie beschikbaar wordt gesteld aan degenen die hiertoe toegang mogen hebben.

De

doelstellingen van servicecatalogusmanagement zijn:

■ Het beheren van de informatie in de servicecatalogus. ■ Zekerstellen dat de servicecatalogus accuraat is met alle benodigde details, statusinformatie en afhankelijkheden van alle services die worden aangeboden.

■ Zekerstellen dat de servicecatalogus beschikbaar en bruikbaar is voor iedereen die geautoriseerd is om er toegang toe te hebben.

■ Zekerstellen dat de servicecatalogus voorziet in de behoeften van andere servicemanagementprocessen, voornamelijk waar het gaat om interfaces en afhankelijkheden.

Bereik Verschaffen en onderhouden van accurate informatie over alle services die in transitie zijn of overgegaan zijn naar de operationele omgeving. Deze services kunnen individueel opgenomen zijn in de servicecatalogus of als service packages.

Waarde voor de business

De servicecatalogus is de centrale bron met informatie over de IT-services die de organisatie van de serviceprovider levert. De servicecatalogus biedt een accuraat, consistent beeld van de IT-services die geleverd worden, de details van deze services en de status ervan. De servicecatalogus ligt ter inzage voor de klant en voor eenieder die daartoe autorisatie heeft. Klanten kunnen aan de hand van de servicecatalogus beoordelen of de aangeboden services, en de servicelevelniveaus die daarbij horen, geschikt zijn om de gewenste businessresultaten te realiseren.

Basisbegrippen Door de jaren heen groeien de IT-infrastructuren van organisaties snel en dan kan het totaalplaatje van de services, dat een organisatie aanbiedt en aan wie, niet meer duidelijk zijn.

■ Serviceportfolio – De serviceportfolio bevat informatie over elke service en de status ervan. De portfolio beschrijft het gehele proces, te beginnen met de klanteisen voor de ontwikkeling, bouw en uitvoering van de service. De serviceportfolio vertegenwoordigt alle actieve en niet-actieve services in de verschillende fasen van de levenscyclus.

■ Servicecatalogus – De catalogus is onderdeel van de serviceportfolio en bestaat uit alle actieve en goedgekeurde services (op retailniveau) die beschikbaar zijn of binnenkort beschikbaar komen. De catalogus verdeelt services in componenten en bevat beleidsregels, richtlijnen en verantwoordelijkheden, evenals de prijzen, servicelevelovereenkomsten en leveringsvoorwaarden.

Veel organisaties integreren en onderhouden de portfolio en catalogus als onderdeel van hun configuratiemanagementsysteem (CMS). Iedere service moet dan als configuratie-item worden opgenomen in het configuratiemanagementsysteem. De organisatie kan dan een relatie leggen tussen incidenten en wijzigingsverzoeken van betreffende services. Het is om deze reden dat besluitvorming over wijzigingen in zowel de serviceportfolio als de servicecatalogus plaatsvindt binnen het changemanagementproces.

De servicecatalogus kan ook gebruikt worden voor een businessimpactanalyse (BIA) als onderdeel van IT service continuity management (ITSCM), of als uitgangspunt voor de herverdeling van de werklast als onderdeel van

capaciteitsmanagement. Deze voordelen rechtvaardigen de investering (in tijd en geld) die nodig is voor het opstellen van een servicecatalogus en maken dat de moeite waard.

Een servicecatalogus met twee invalshoeken: Tabel 5.3

Een servicecatalogus met drie invalshoeken: Tabel 5.4

5.6.2 Activiteiten, methoden en technieken De servicecatalogus is de enige bron van constante informatie over alle services van de serviceprovider. De catalogus moet toegankelijk zijn voor elke persoon die daarvoor autorisatie heeft.

De belangrijkste activiteiten in dit proces zijn: 1. Afstemmen en documenteren van een servicedefinitie met alle relevante partijen.

2. Overleggen met serviceportfoliomanagement om het eens te worden over de inhoud van de serviceportfolio en servicecatalogus. 3. Een accurate servicecatalogus produceren en de inhoud daarvan onderhouden in samenhang met de serviceportfolio. 4. Overleggen met de business en IT service continuity management. In kaart brengen op welke wijze de bedrijfsprocessen van de businessunits afhankelijk zijn van de IT-services, zoals die is opgenomen in de servicecatalogus. 5. Overleggen met supportteams, IT-serviceproviders en configuratiemanagement over interfaces en afhankelijkheden tussen klantgerichte IT-services en de ondersteunende IT-services, zoals die onder de invalshoek ‘ondersteunende services’ zijn opgenomen in de servicecatalogus. 6. Overleggen met klantrelatiebeheer en servicelevelmanagement om te zorgen dat de informatie in lijn is met de business en het bedrijfsproces.

5.6.3 Informatiemanagement De belangrijkste informatie voor dit proces is opgenomen in de servicecatalogus. Het serviceportfoliomanagement, het klantrelatiebeheer en/of de servicelevelmanagementprocessen zijn de hoofdbronnen van informatie voor de servicecatalogus. De servicecatalogus wordt beschouwd als een configuratie-item en valt dus onder het bereik van het changemanagementproces. Changemanagement wordt in paragraaf 6.4 besproken. Er zijn veel verschillende methoden om de informatie in de servicecatalogus te managen waaronder:

■ Intranetoplossingen gebouwd door de organisatie van de serviceprovider, gebruikmakend van aanwezige technologie.

■ Commercieel beschikbare oplossingen bedoeld voor servicecatalogusmanagement.

■ Oplossingen die onderdeel zijn van een uitgebreider servicemanagementpakket.

De medewerkers van de klant(en)organisatie(s) zullen gerechtigd zijn tot het bekijken en gebruiken van de servicecatalogus of delen daarvan, afhankelijk van hun taakbeschrijving en gebruikersprofiel. De gebruikersprofielen worden

vastgesteld in de servicestrategiefase. Ze worden ontworpen met behulp van het securitymanagementproces en vooral gebruikt door accessmanagement. Dit laat zien dat er goede samenwerking en coördinatie van activiteiten moet zijn tussen de fasen van de servicelevenscyclus en de activiteiten vanuit de vier functies (servicedesk, IT-operationsmanagement, technisch-en applicatiemanagement).

5.6.4 Interfaces ■ Serviceportfoliomanagement – Bepaalt van welke services een service charter wordt gemaakt en dus welke services eventueel worden opgenomen in de servicecatalogus. Ze levert ook essentiële informatie met betrekking tot elke service of potentiële service, waaronder informatie over goedgekeurde servicepakketten en service options.

■ Klantrelatiebeheer – Zorgt dat de relatie tussen de service en de klant die van deze service gebruik wilt maken, helder is gedocumenteerd in termen van hoe de service de behoefte van de klant(en) ondersteunt.

■ Serviceasset & configuratiemanagement – Zij werken samen om er zeker van te zijn dat de informatie in het CMS en in de servicecatalogus op de juiste wijze aan elkaar is gekoppeld. Dit zorgt voor een consistent, accuraat en uitgebreid zicht op de raakvlakken en afhankelijkheden tussen services, klanten, bedrijfsprocessen en serviceassets en CI’s.

■ Servicelevelmanagement – Onderhandelt over specifieke niveaus van te leveren service warranty, die hun weerslag krijgen in de servicecatalogus.

■ Demandmanagement – Bepaalt hoe services worden samengebracht in de te leveren service packages. Samen met servicecatalogusmanagement zorgt demandmanagement ervoor dat deze service packages goed worden weergegeven in de servicecatalogus.

5.6.5 Aanleidingen (triggers) ■ De triggers voor het proces servicecatalogusmanagement zijn wijzigingen in de zakelijke eisen en services. Hoofdaanleidingen zijn wijzigingingsverzoeken (Requests for Changes, RfC’s) en het changemanagementproces. Hieronder vallen nieuwe services, wijzigingen in bestaande services en services die worden beëindigd.

5.6.6 Invoer

■ Zakelijke informatie over de bedrijfs- en IT-strategieplannen en financiële plannen van de organisatie.

■ Businessimpactanalyse. ■ Serviceportfolio. ■ CMS. ■ Feedback vanuit andere processen.

5.6.7 Uitvoer ■ Documentatie van en overeenstemming over een ‘definitie van de service’. ■ Updates van de serviceportfolio. ■ Updates van de servicecatalogus. 5.6.8 Kritieke succesfactoren ■ Accurate servicecatalogus. ■ Zakelijke gebruikers zijn op de hoogte welke services worden geleverd. ■ IT-medewerkers hebben voldoende kennis van het technisch systeem dat de services ondersteunt.

5.6.9 Metrics ■ Het aantal services dat is vastgelegd en wordt onderhouden in de servicecatalogus als percentage van het aantal services dat wordt geleverd en overgaat naar de operationele omgeving.

■ Het aantal verschillen dat er bestaat tussen de informatie in de servicecatalogus en de situatie zoals die in werkelijkheid is.

■ Procentuele stijging van operationele services die zijn opgenomen in de servicecatalogus, vergeleken met het totale aantal operationele services.

■ Procentuele stijging van ondersteunende services die zijn opgenomen in de servicecatalogus, vergeleken met het totaal aantal ondersteunende services.

■ Procentuele afname van het aantal incidenten dat door de servicedesk als onderdeel van de incidentenregistratie niet gekoppeld is (of kon worden) aan een in de servicecatalogus opgenomen service.

5.6.10 Uitdagingen ■ Onderhouden van een accurate servicecatalogus als onderdeel van een serviceportfolio, met daarin alle invalshoeken van de catalogus (klant(en) en ondersteunende services) als onderdeel van een volledig CMS en SKMS.

5.6.11 Risico’s ■ Onnauwkeurige informatie in de servicecatalogus en dat changemanagement hier geen controle over heeft.

■ De servicecatalogus wordt matig geaccepteerd en gebruikt in de operationele processen.

■ De informatie verstrekt door de business, IT en serviceportfoliomanagement is onnauwkeurig.

■ Gebrek aan tools en middelen benodigd om de informatie up-to-date te houden.

■ Gebrekkige toegang tot accurate informatie uit het changemanagementproces.

■ Het daadwerkelijk gebruik van de serviceportfolio en de servicecatalogus wordt vermeden.

■ De informatie is te gedetailleerd om deze zorgvuldig te kunnen onderhouden. Of de informatie is op een te hoog abstractieniveau beschreven om van enige waarde te zijn.

■ 5.7 SERVICELEVELMANAGEMENT 5.7.1 Inleiding Het doel van het proces servicelevelmanagement (SLM) is te zorgen dat een afgesproken IT-servicelevel wordt geleverd voor alle lopende IT-services. En ook dat toekomstige services worden geleverd op afgesproken haalbare niveaus.

De

doelstellingen van servicelevelmanagement zijn:

■ Formuleren, documenteren, overeenkomen, bewaken, meten, rapporteren en uitvoeren van een evaluatie van het servicelevel.

■ Verzorgen en verbeteren van de relatie en communicatie met de business en de klanten.

■ Zorgen dat specifieke en meetbare streefdoelen worden ontwikkeld. ■ Bewaken en verbeteren van klanttevredenheid door de kwaliteit van services die worden geleverd.

■ Zorgen dat de IT-organisatie en de klanten een heldere en ondubbelzinnige verwachting hebben van het servicelevel dat wordt geleverd.

■ Zorgen dat proactieve maatregelen voor verbetering van geleverde servicelevels worden doorgevoerd waar dit wat kosten betreft gerechtvaardigd is.

Bereik SLM vertegenwoordigt de IT-serviceprovider richting de business en de business richting de IT-serviceprovider. Er is regelmatig contact in beide richtingen, waarbij zowel de aanwezige service als de toekomstige service worden besproken. SLM moet de verwachtingen managen van beide partijen (zowel intern als extern). Bovendien zorgt SLM ervoor dat de geleverde servicekwaliteit voldoet aan de verwachtingen van de business.

Het SLM-proces omvat de volgende activiteiten:

■ Ontwikkeling van bedrijfsrelaties. ■ Ontwikkeling en management van operationele niveauafspraken (OLA, Operational Level Agreements).

■ Evalueren van onderliggende leverancierscontracten (underpinning contracts – UC’s).

■ Proactieve preventie van verstoringen van de serviceverlening, beperking van service-gerelateerde risico’s en verbetering van servicekwaliteit.

■ Rapportage en management van alle services en evaluatie van een niet of zwak nakomen van de servicelevelagreement (SLA).

Waarde voor de business SLM biedt een eenduidig communicatiekanaal aan de business voor alle service-gerelateerde kwesties. Ze levert de business de afgesproken servicelevels en de benodigde managementinformatie om te garanderen dat daaraan is voldaan. Waar streefdoelen niet worden bereikt, levert SLM feedback over de oorzaak. Ook levert ze informatie over de acties die genomen worden om te voorkomen dat het niveau opnieuw te laag wordt.

Het proces servicelevelmanagement houdt in het plannen, coördineren, opstellen, accorderen, bewaken van en rapporteren over servicelevelovereenkomsten (SLA’s). De SLA is een schriftelijke overeenkomst tussen de serviceprovider en zijn klanten, waarin de servicedoelen en de verantwoordelijkheden van beide partijen zijn vastgelegd.

Ook het voortdurend evalueren van serviceprestaties behoren tot de activiteiten van SLM. Het doel daarvan is om te zorgen dat de vereiste kwaliteit met de te rechtvaardigen kosten wordt behouden en geleidelijk aan wordt verbeterd.

Tabel 5.4 Voorbeeld van een overzicht van de behaalde servicelevelresultaten

De SLA is een schriftelijke overeenkomst tussen de IT-serviceprovider en zijn klanten waarin de servicedoelen en verantwoordelijkheden van beide partijen zijn vastgelegd. Een operational level agreement (OLA) aan de andere kant, is een overeenkomst tussen een IT-serviceprovider en een ander onderdeel van dezelfde organisatie die assisteert bij de levering van services. Het proces leveranciersmanagement is verantwoordelijk voor het afsluiten en onderhouden van de contracten met externe toeleverende partijen. Deze contracten worden onderliggende contracten (UC’s, underpinning contracts) genoemd.

5.7.2 Activiteiten, methoden en technieken De activiteiten in het proces zijn: 1. Ontwerpen van SLA-frameworks inclusief het formuleren van een SLAstructuur (service-gebaseerde SLA, klant-gebaseerde SLA, multi-niveau-SLA).

Afbeelding 5.4 Voorbeeld van de work ow van servicelevelmanagement (Gebaseerd op bron: AXELOS) 2. Bepalen, documenteren van en overeenstemming bereiken over eisen voor nieuwe services en productie van serviceleveleisen (SLR’s, Service Level Requirements). 3. Monitoren van de prestaties ten opzichte van de SLA en rapporteren van de uitkomsten. 4. Verbeteren van klanttevredenheid. 5. Evalueren en laten aanpassen door leveranciersmanagement van onderliggende contracten (UC’s, Underpinning Contracts). 6. Produceren van servicerapportages. 7. Evalueren en verbeteren van services. 8. Evalueren en aanpassen van de SLA. 9. Ontwikkelen van contacten en relaties.

5.7.3 Informatiemanagement ■ Levert belangrijke informatie over alle operationele services, hun verwachte niveaus en de serviceprestaties en -gebreken voor alle operationele services.

■ Levert informatie over de kwaliteit van IT-services die zijn geleverd aan de klant en informatie over de verwachtingen en perceptie van de klant over de servicekwaliteit.

5.7.4 Interfaces ■ Klantrelatiebeheer – Zorgt dat de serviceprovider volledig begrip heeft van de behoeften en prioriteiten van de business en dat klanten op de juiste wijze betrokken/ vertegenwoordigd worden bij het werk van servicelevelmanagement.

■ Servicecatalogusmanagement – Levert accurate informatie over services en hun interfaces en afhankelijkheden ter ondersteuning van het vaststellen van het SLA-raamwerk. Identificeren van klanten/bedrijfseenheden die betrokken moeten zijn bij SLM en om SLM te ondersteunen bij de communicatie met klanten over geleverde services.

■ Incidentmanagement – Aan de hand van KSF’en (kritieke succesfactoren) wordt gemeten hoe de prestaties zich verhouden tot de afspraken zoals die zijn vastgelegd in de SLA. Incidentmanagement speelt deze informatie door aan SLM. SLM maakt met de klant onder andere afspraken over doelen met betrekking tot de ondersteuning van het gebruik van de services. Het gaat daarbij om onderwerpen als hersteltijden en hoe om te gaan met prioritering van incidenten. Deze afspraken zijn vervolgens input voor het incidentmanagementproces.

■ Leveranciersmanagement – Werkt samen met SLM om servicevereisten te formuleren en zorgvuldig te documenteren. Ze onderhandelt om overeenstemming te bereiken met de de externe serviceproviders over de te leveren services. En ook managet ze de prestaties van de externe serviceproviders en ziet erop toe dat de prestaties conform de afspraken zijn zoals die in de SLA zijn overeengekomen.

■ Availabilitymanagement, capaciteitsmanagement, information security management en IT-service continuity management – Deze processen helpen SLM bij het definiëren van de serviceleveldoelen en beoordelen mede of deze doelen realistisch (haalbaar) zijn. Elk van de vier processen levert hiertoe input vanuit het gezichtspunt van zijn eigen discipline. Zodra de

doelen zijn gedefinieerd en er overeenstemming is bereikt over de haalbaarheid ervan, dienen deze processen ervoor te zorgen dat hun prestaties in overeenstemming zijn met de geformuleerde doelen.

■ Financieel management voor IT-services – Werkt samen met SLM aan het kostenplaatje voor de serviceverlening. Er wordt een raming gemaakt (voorspelling) van de kosten die gepaard gaan met het kunnen leveren van servicelevels zoals de klant die eist. Deze kostenraming dient als informatie voor het besluitvormingsproces van de klant. De kostenraming wordt later vergeleken met het werkelijke kostenplaatje. Hiermee ontwikkelt de serviceprovider het vermogen om de kosten van de service-verlening steeds beter te kunnen voorspellen en te beheersen.

■ Ontwerpcoördinatie

– Is ervoor verantwoordelijk dat alle activiteiten van

serviceontwerp succesvol worden afgerond. SLM ontwikkelt afgesproken SLR’s (service level requirements) en daaraan gerelateerde doelen.

5.7.5 Aanleidingen (triggers) ■ Wijzigingen in de serviceportfolio. ■ Nieuwe of gewijzigde afspraken, SLR, SLA, OLA, of contracten. ■ Service-evaluatievergaderingen en -acties. ■ Falen of dreigend falen van de service. ■ Klagende klanten of klanten die suggesties ter verbetering naar voren brengen.

■ Periodieke activiteiten zoals reviews, rapporteren en klanttevredenheidonderzoek.

■ Wijzigingen in strategie of beleid.

5.7.6 Invoer ■ Bedrijfsinformatie voortkomend uit de bedrijfsstrategie, plannen en financiële plannen van de organisatie.

■ Zakelijke eisen. ■ Serviceportfolio en servicecatalogus. ■ Wijzigingsinformatie. ■ Configuratiemanagementsysteem (CMS).

5.7.7 Uitvoer ■ Servicerapportage (service reports).

■ Serviceverbeterplan (SIP). ■ Servicekwaliteitsplan (SQP). ■ Standaard documentsjablonen. ■ SLA, SLR en OLA. ■ Notulen van service-evaluatievergaderingen.

5.7.8 Kritieke succesfactoren ■ Het kunnen managen van de benodigde overall-kwaliteit van de IT-services. Kwaliteit wil hier zeggen voldoen aan de afspraken zoals die zijn vastgelegd in de SLA.

■ De service leveren zoals overeengekomen tegen aanvaardbare kosten. ■ De interface met de business en gebruikers managen.

5.7.9 Metrics Objectieve metrics: ■ Aantal of percentage van de servicedoelen dat wordt bereikt. ■ Aantal en ernst van de verstoringen van de serviceverlening. ■ Aantal services met bijgewerkte SLA’s. ■ Aantal services waarvan de rapportages op tijd zijn opgeleverd en de servicereviews daadwerkelijk hebben plaatsgevonden.

Subjectieve metrics: ■ Verbetering van de klanttevredenheid.

5.7.10 Uitdagingen ■ Bepalen welke klantvertegenwoordigers geschikt zijn om mee te onderhandelen.

■ Geen eerdere ervaring met servicelevelmanagement. ■ De doelstellingen en percepties van klantmedewerkers kunnen per niveau verschillen.

5.7.11 Risico’s ■ Gebrek aan accurate invoer, betrokkenheid en medewerking van zowel de business als de klanten.

■ Gebrek aan geschikte tools en middelen benodigd voor het maken, documenteren, bewaken, rapporteren en evalueren van afspraken en

servicelevels.

■ Het proces wordt te bureaucratisch. ■ Problemen met de toegang tot het CMS en het SKMS. Of de ondersteuning die deze systemen bieden is onvoldoende omdat ze niet upto-date zijn gehouden.

■ Het gebruik van het SLM-proces omzeilen. ■ Metingen aan de kant van de business en de klant zijn moeilijk uitvoerbaar en vinden daarom niet plaats.

■ Business- en klantcontacten op het verkeerde niveau of met de verkeerde persoon, waardoor het niet of onvoldoende mogelijk is om invulling te geven aan het maken en bijstellen van afspraken over de serviceverlening.

■ De verwachtingen van de klant zijn hoog, maar de geboden kwaliteit van de serviceverlening wordt door de klant als laag waargenomen.

■ Slechte, gebrekkige communicatie met de business en klanten.

■ 5.8 CAPACITEITSMANAGEMENT 5.8.1 Inleiding Het doel van capaciteitsmanagement is te zorgen dat benodigde IT-capaciteit wordt geleverd die zowel overeenstemt met de huidige als toekomstige behoeften van de klanten, tegen verantwoorde kosten. De

doelstellingen van capaciteitsmanagement zijn:

■ Een capaciteitsplan maken en bijhouden dat in de huidige en toekomstige behoeften van de klant voorziet.

■ Intern en extern advies over services met betrekking tot de capaciteit en prestaties.

■ Zorgen dat de geleverde services voldoen aan de vastgestelde doelstellingen door het managen van zowel de prestaties als de capaciteit van services.

■ Bijdragen aan de diagnose van prestaties en capaciteit gerelateerde incidenten en problemen.

■ Onderzoeken van de impact van alle wijzigingen op het capaciteitsplan. ■ Proactieve maatregelen nemen om prestaties te verbeteren. Bereik

Het capaciteitsmanagementproces moet het centrale uitgangspunt zijn voor alle IT-prestaties en capaciteitskwesties. Netwerk- en serversupport of operationeel management kan de meeste van de dagelijkse operationele taken oppakken, maar zal de informatie over de prestaties verstrekken aan het capaciteitsmanagementproces. Daarnaast houdt capaciteitsmanagement zich ook bezig met de inrichting van de fysieke ruimtes. Capaciteitsmanagement kan ook een taak hebben bij bepaalde aspecten van Personeelszaken (HRM) maar alleen wanneer een gebrek aan menskracht kan leiden tot een inbreuk op OLA of SLA’s. Personeelszaken (Human Resource Management, HRM) is echter in eerste instantie de verantwoordelijkheid van het lijnmanagement. Echter, door de medewerkers van een servicedesk kunnen dezelfde capaciteitsmanagementtechnieken worden toegepast.

Capaciteitsmanagement moet input leveren voor het serviceportfolio en inkoopproces om ervoor te zorgen dat de beste deals met IT-serviceproviders tot stand komen. Capaciteitsmanagement geeft de nodige informatie over het huidige en de geplande belasting van de afzonderlijke IT-componenten, zoals servers, routers en dergelijke, om organisaties in staat te stellen om met vertrouwen te beslissen:

■ Welke componenten een upgrade gaan krijgen. ■ Wanneer ze een upgrade gaat doen. ■ Wat de upgrade zal gaan kosten. Capaciteitsmanagement heeft een hechte relatie met servicestrategie omdat servicestrategie gebaseerd is op de organisatieplannen, die op hun beurt zijn afgeleid van de strategie. Met andere woorden, capaciteitsmanagement moet goed weten wat de korte, middellange en lange termijnplannen van de organisatie zijn om haar taken naar behoren uit te kunnen voeren.

Waarde voor de business Capaciteitsmanagement is verantwoordelijk voor het plannen en inroosteren van IT-resources om te zorgen voor een consistent servicelevel dat past bij de huidige en toekomstige eisen van de klant. Capaciteitsmanagement levert een capaciteitsplan op in overleg met de klant. In het plan worden de IT- en financiële resources gespecificeerd die nodig zijn om de business te ondersteunen, inclusief een verantwoording van de uitgaven.

Afbeelding 5.5 Voorbeeld work ow van capaciteitsmanagement (Gebaseerd op bron: AXELOS) Het capaciteitsmanagementproces zorgt er ook voor dat de kosten in balans zijn met de benodigde resources en dat het aanbod is afgestemd op de vraag.

Capaciteitsmanagementprocessen en -planning moeten in elke fase van de servicelevenscyclus plaatsvinden, van servicestrategie en serviceontwerp via servicetransitie en service-uitvoering naar continue serviceverbetering.

Afbeelding 5.6 Voorbeeld work ow subprocessen van capaciteitsmanagement (Bron: AXELOS)

5.8.2 Activiteiten, methoden en technieken Het capaciteitsmanagementproces bestaat uit:

- Proactieve activiteiten: 1. Inspelen op issues die wellicht de prestaties kunnen beïnvloeden. 2. Identificeren van trends in het huidige componentgebruik en het inschatten van toekomstige eisen die aan het componentgebruik worden gesteld. 3. Trends voorspellen over hoe de IT-services in de toekomst zullen veranderen, en manieren vinden om die wijzigingen te vertalen naar nieuwe of aangepaste services. 4. Ervoor zorgen dat de upgrades al gebudgetteerd zijn en gepland staan zodat ze, mocht dat nodig zijn, direct doorgevoerd kunnen worden. 5. Actieve houding ten aanzien van het continu verbeteren van de serviceverlening – ook vanuit het oogpunt van kosteneffectiviteit. 6. Een capaciteitsplan produceren en onderhouden.

7. De prestaties van services en hun componenten op elkaar afstemmen (optimaliseren).

- Reactieve activiteiten: 1. Bewaken, meten, rapporteren en evalueren. 2. Corrigerende maatregelen nemen indien drempelwaarden (thresholds) ten aanzien van de capaciteit worden overschreden. 3. Reageren op prestatieproblemen en hulp bieden om deze problemen op te lossen.

Hoe proactiever het capaciteitsmanagement proces, des te kleiner de behoefte aan reactieve activiteiten. Capaciteitsmanagement is een uiterst technisch, complex en veeleisend proces dat drie subprocessen omvat (afbeelding 5.6).

1. Bedrijfscapaciteitsmanagement Het eerste aspect van dit subproces ondersteunt het ontwerpcoördinatieproces door:

■ Assisteren bij gesprekken waar afspraken worden gemaakt over de serviceleveleisen.

■ Ontwerpen, inkopen of aanpassen van de serviceconfiguratie. ■ Verifiëren van servicelevelafspraken. ■ Ondersteuning bieden bij onderhandelingen over de servicelevelafspraken. ■ Controle en implementatie. Het tweede aspect ondersteunt de serviceproductiefase door:

■ Zakelijke eisen en plannen te vertalen in eisen voor services en ITinfrastructuur.

■ Ervoor zorgen dat de toekomstige zakelijke eisen voor IT-services tijdig worden gekwantificeerd, ontworpen, gepland en doorgevoerd.

■ Trendanalyses, prognosticeren, modelleren of voorspellen van toekomstige eisen.

2. Servicecapaciteitsmanagement ■ Richt zich op het management, de controle en voorspelling van de end-toend-prestaties, capaciteit, gebruik en werklast van de operationele IT-services.

■ Zorgt ervoor dat de prestaties van alle services worden bewaakt en gemeten.

■ Zorgt ervoor dat de verzamelde data worden geregistreerd, geanalyseerd en gerapporteerd.

■ Initieert proactieve en reactieve activiteiten. ■ Gebruikt geautomatiseerde systemen voor het meten/monitoren van de kwaliteit van alle operationele services. Voor deze kwaliteitsbeoordeling zijn bepaalde drempelwaarden vastgesteld. Op basis van de gemeten drempelwaarden wordt beoordeeld of er herstelacties nodig zijn.

■ Identificeert omstandigheden (mogelijke risico’s) die de realisatie van de servicedoelstellingen in gevaar kunnen brengen. Ze onderneemt actie om de impact van de risico’s te verminderen of te voorkomen.

3. Componentcapaciteitsmanagement ■ Richt zich op het beheer, de controle en voorspelling van de prestaties, en op het gebruik en de capaciteit van de afzonderlijke ITtechnologiecomponenten, zoals servers, routers en dergelijke.

■ Zorgt ervoor dat de prestaties van alle onderdelen worden bewaakt en gemeten.

■ Zorgt ervoor dat de verzamelde data worden geregistreerd, geanalyseerd en gerapporteerd.

■ Zet tot proactieve en reactieve activiteiten aan. ■ Gebruikt geautomatiseerde systemen voor het meten/monitoren van de kwaliteit van alle operationele services. Voor deze kwaliteitsbeoordeling zijn bepaalde waarden vastgesteld. Op basis van de gemeten drempelwaarden wordt beoordeeld of er herstelacties nodig zijn.

■ Identificeert omstandigheden (mogelijke risico’s) die de realisatie van de servicedoelstellingen in gevaar kunnen brengen. Ze onderneemt actie om de impact van de risico’s te verminderen of te voorkomen.

Ondersteunende activiteiten van capaciteitsmanagement Sommige activiteiten moeten herhaaldelijk worden uitgevoerd (proactief of reactief ). Ze bieden basisinformatie en aanleidingen voor andere activiteiten en processen in capaciteitsmanagement. Onder deze activiteiten vallen:

■ Afstemmen en optimaliseren. ■ Monitoren van het gebruik. ■ Monitoren responstijd. ■ Analyse.

■ Implementatie. ■ Exploitatie van nieuwe technologie. ■ Ontwerpen van veerkracht (redundantie) in systemen. Capaciteitsmanagement omvat ook:

■ Drempelbeheer en -controle. ■ Demandmanagement. ■ Voorspellen van ‘het gedrag’ van IT-services. ■ Dimensionering van de applicatie, de raming van de vereiste resources om voorgestelde wijzigingen te ondersteunen.

Ontwerpgerelateerde activiteiten De drie subprocessen voor capaciteitsmanagement hebben baat bij onderzoek naar nieuwe technologieën en het inbouwen van veerkracht in services en in de IT-infrastructuur.

■ Exploitatie van nieuwe technologie. ■ Ontwerpen van systemen met voldoende veerkracht. Dit betekent systemen dusdanig redundant ontwerpen dat bij het uitvalleen van een of meer componenten, waaruit het systeem bestaat, de werking van het totale systeem niet wordt onderbroken.

5.8.3 Informatiemanagement Capaciteitsmanagement onderhoudt een capaciteitsmanagementinformatiesysteem (CMIS). Het CMIS bevat informatie over de capaciteit en de prestatieniveaus van de verleende ITservices, de componenten alsmede de ondersteunende services. Het doel van het CMIS is om het capaciteitsmanagementproces te ondersteunen, en om de IT-serviceprovider te voorzien van relevante informatie die hij nodig heeft voor het produceren van rapporten over capaciteitsvraagstukken, voor onderzoek naar de mogelijkheden om de services te verbeteren en voor analyse van trends zoals die zich binnen de serviceverlening afspelen. Deze activiteiten en de informatie in het CMIS vormen de basis voor het ontwikkelen van de inhoud van het capaciteitsplan.

Afbeelding 5.7 Voorbeeld van iteratieve activiteiten in het proces capaciteitsmanagement (Bron: AXELOS)

Capaciteitsmanagementinformatiesysteem (CMIS) ■ Het CMIS is een verzameling tools, data en informatie die wordt gebruikt om capaciteitsmanagement te ondersteunen en het is de hoeksteen van een succesvol capaciteitsmanagementproces. De informatie wordt opgeslagen en geanalyseerd door alle subprocessen van capaciteitsmanagement.

■ Het CMIS is een geheel aan instrumenten, data en informatie dat gebruikt wordt om capaciteitsmanagement te ondersteunen. Het maakt deel uit van het configuratiemanagementsysteem (CMS).

■ Het CMIS kan worden gebruikt voor het vastleggen en opslaan van geselecteerde data en informatie die nodig zijn voor het genereren van rapporten en voor het uitvoeren van statistische analyses. Op basis van de informatie in het CMIS worden ook capaciteitsvoorspellingen en -planning gemaakt.

Capaciteitsplan

Het capaciteitsplan beschrijft een breed scala aan initiatieven waarmee de capaciteit verbeterd kan worden. Het is aan te bevelen om het capaciteitsplan af te stemmen op het beschikbaarheidsplan en het financiële plan.

5.8.4 Interfaces ■ Availabilitymanagement – Om te bepalen welke middelen nodig zijn om de gemaakte afspraken over de huidige en toekomstige beschikbaarheid na te kunnen leven.

■ Servicelevelmanagement – Om capaciteitsdoelen te bepalen en capaciteitgerelateerde problemen te onderzoeken en op te lossen.

■ IT-service continuity management – Biedt hulp bij het beoordelen in hoeverre een risico of incident impact heeft op de business. Bepaalt de capaciteit die nodig is om risicobeperkende maatregelen en herstelactiviteiten te ondersteunen.

■ Incident- en problemmanagement – Biedt hulp bij probleemonderzoek, het oplossen van incidenten en bij zaken die te maken hebben met capaciteitsproblemen.

■ Demandmanagement – Anticipeert op de vraag naar services op basis van gebruikersprofielen en patronen in bedrijfsactiviteit en zoekt naar manieren om klantgedrag te beïnvloeden.

5.8.5 Aanleidingen (triggers) ■ Nieuwe en gewijzigde services waarvoor extra capaciteit nodig is. ■ Service-gerelateerde problemen, waarschuwingen (alerts) die te maken hebben capaciteitsissues.

■ Afwijkingsrapporten. ■ Verzoek van SLM om bij te staan met uitleg van de prestaties voor de capaciteits- en/ of prestatiedoelstellingen.

5.8.6 Invoer ■ Zakelijke informatie. ■ Service- en IT-informatie. ■ Componentprestaties en capaciteitsinformatie. ■ Informatie over problemen t.a.v. de serviceprestaties. ■ Service-informatie. ■ Financiële informatie.

■ Wijzigingsinformatie. ■ Prestatie-informatie. ■ CMS. ■ Werklastinformatie.

5.8.7 Uitvoer ■ Capaciteitsmanagementinformatiesysteem (CMIS). ■ Capaciteitsplan. ■ Informatie en rapportages over serviceprestaties. ■ Werklastanalyse en -rapporten. ■ Ad-hoccapaciteits- en prestatierapporten. ■ Prognoses en voorspellende rapportages. ■ Grenswaarden, waarschuwingen en events. ■ Verbeteringsacties. 5.8.8 Kritieke succesfactoren ■ Nauwkeurigheid van de voorspellingen met betrekking tot de mate van het gebruik van services door de business.

■ Kennis van huidige en toekomstige technologieën. ■ Mogelijkheid om kosteneffectiviteit aan te tonen. ■ Het vermogen om de IT-capaciteit te plannen en te implementeren waarmee aan zakelijke behoeften wordt voldaan.

5.8.9 Metrics ■ Afname van het aantal verstoringen aan de business-kant, dat het gevolg is van een gebrek aan adequate IT-capaciteit.

■ Accurate voorspellingen van de geplande uitgaven. ■ Procentuele nauwkeurigheid van de prognoses van trends. ■ Procentuele beperking in gemiste zakelijke kansen als gevolg van capaciteitsgebrek.

■ Tijdig produceren van prognoses m.b.t. werklast. ■ Beter in staat zijn om de prestaties en doorvoer van services en componenten te controleren.

■ Tijdig implementeren van nieuwe technische systemen. ■ Vermindering in het gebruik van oude technische systemen.

■ Vermindering van het aantal incidenten en problemen als gevolg van capaciteitsgebrek.

5.8.10 Uitdagingen ■ De business ervan overtuigen om informatie te leveren over de strategische bedrijfsplannen. Alleen dan is de IT-serviceprovider in staat zijn capaciteitsmanagementproces effectief – zakelijk gezien – uit te voeren.

■ Alle data van en informatie over het proces capaciteitsmanagement onderbrengen in een geïntegreerde database die op een consistente manier kan worden geanalyseerd.

■ Het selecteren en analyseren van de enorme hoeveelheid data die capaciteitsmanagement verzamelt.

5.8.11 Risico’s ■ Een gebrek aan: •

betrokkenheid van de business bij het capaciteitsmanagementproces;

•

informatie over de toekomstplannen en strategieën van de organisatie;

•

betrokkenheid van het hoger management;

•

middelen en/of budget voor het capaciteitsmanagementproces.

■ De subprocessen van capaciteitsmanagement worden geïsoleerd uitgevoerd, er is een gebrek aan geschikte en nauwkeurige bedrijfsinformatie.

■ De processen worden te bureaucratisch of te bewerkelijk. ■ Te veel gericht op een van de subprocessen. Deze eenzijdige aandacht gaat ten koste van de andere subprocessen.

■ De rapporten en informatie zijn te omvangrijk of te technisch van aard.

■ 5.9 AVAILABILITYMANAGEMENT 5.9.1 Inleiding Het doel van availabilitymanagement (availability = beschikbaarheid) is om zeker te stellen dat de mate waarin een service beschikbaar is voldoet aan de huidige en toekomstige behoeften van de business. En dat op een kosteneffectieve wijze.

De

doelstellingen van availabilitymanagement zijn:

■ Creëren en onderhouden van een up-to-date beschikbaarheidsplan dat is afgestemd op de huidige en toekomstige behoeften van de klant.

■ Adviseren over kwesties die te maken hebben met de beschikbaarheid. ■ Zorgen dat de mate van de gerealiseerde beschikbaarheid voldoet aan de vastgestelde eisen, of deze zelfs overstijgen.

■ Assisteren bij de diagnose van en het vinden van oplossingen voor incidenten en problemen die de beschikbaarheid beïnvloeden.

■ De impact inschatten van wijzigingen op het beschikbaarheidsplan en op de prestaties en capaciteit van de services en middelen.

■ Proactief maatregelen nemen om de beschikbaarheid te verbeteren. Bereik Availabilitymanagement omvat het ontwerpen, invoeren, meten, beheren en verbeteren van IT-services. Ze is ook verantwoordelijk voor de beschikbaarheid van componenten. Availabilitymanagement moet het perspectief dat de business heeft op en de eisen die ze stelt aan de beschikbaarheid van haar services en componenten goed begrijpen. Het gaat hierbij om de:

■ huidige bedrijfsprocessen (hun functies en eisen); ■ toekomstige bedrijfsplannen en eisen; ■ servicedoelen en de huidige serviceproductie en -levering; ■ IT-infrastructuur, data, applicaties en de omgeving (inclusief prestaties); ■ impact die de services en het gebruik ervan hebben op de business.

Afbeelding 5.8 Voorbeeld van een work ow binnen availabilitymanagement (Bron: AXELOS) Kennis van deze zaken maakt het voor availabilitymanagement mogelijk om ervoor te zorgen dat alle services en componenten zodanig worden ontworpen dat deze voldoen aan de eisen en dus aan de behoefte van de business. Availabilitymanagement moet worden toegepast op alle operationele services, nieuwe, gewijzigde en ondersteunende services. Het dekt alle dienstaspecten die een impact hebben op beschikbaarheid, zoals training, vaardigheden, procedures en tools.

Waarde voor de business De beschikbaarheid en betrouwbaarheid van IT-services heeft een directe impact op de klanttevredenheid en de bedrijfsreputatie. Availabilitymanagement is van levensbelang. Daarom moet ze (net als capaciteitsmanagement) bij alle stadia van de servicelevenscyclus betrokken worden.

5.9.2 Activiteiten, methoden en technieken De hoofdactiviteiten van availabilitymanagement zijn: 1. Bepalen van de beschikbaarheidseisen van de business. 2. Identificeren van de essentiële bedrijfsfuncties (vital business functions, VBF’s). Het is echter de business die de VBF’s bepaalt en valideert. 3. Samen met de business bepalen wat de impact is van falende componenten. 4. Vaststellen van de doelen ten aanzien van beschikbaarheid, betrouwbaarheid en onderhoudbaarheid van de IT-componenten. 5. Monitoren en analyseren van IT-componenten met betrekking tot hun beschikbaarheid, betrouwbaarheid en onderhoudbaarheid. 6. Uitvoeren van metingen en rapportages met betrekking tot de beschikbaarheid, betrouwbaarheid en onderhoudbaarheid, die recht doen aan de wijze waarop zakelijke gebruikers de beschikbaarheid van IT-services ervaren. Tegelijk moeten deze rapportages en metingen ook voldoende informatie verschaffen aan de technische specialisten die verantwoordelijk zijn voor de ondersteuning van de te leveren services. 7. Onderzoek doen naar de onderliggende redenen indien de beschikbaarheid onacceptabel is. 8. Opstellen en onderhouden van een beschikbaarheidsplan.

Availabilitymanagement bewaakt, meet, analyseert en rapporteert over de volgende aspecten: beschikbaarheid, betrouwbaarheid, onderhoudbaarheid en onderhoudsgemak.

■ Beschikbaarheid – het vermogen van een IT-service of configuratie-item (CI) om de overeengekomen functie te leveren op het moment dat dat vereist is. Beschikbaarheid wordt veelal als percentage berekend. Deze berekening is meestal gebaseerd op de overeengekomen openstellingstijden en de storingstijden.

■ Betrouwbaarheid – de mate waarin een IT-service of configuratie-item (CI) zijn overeengekomen functie zonder onderbreking kan uitoefenen.

■ Onderhoudbaarheid – het vermogen om een service of configuratie-item dat niet naar behoren werkt eenvoudig te kunnen wijzigen of repareren.

■ Onderhoudsgemak – het vermogen van een externe leverancier om te voldoen aan de afspraken en bepalingen in het onderhoudscontract.

Meten is extreem belangrijk. Dit kan vanuit drie perspectieven: -

het zakelijk perspectief;

-

het gebruikersperspectief;

-

het perspectief van de IT-serviceprovider.

Availabilitymanagement moet zorgen dat alle services voldoen aan de gemaakte afspraken. Nieuwe of gewijzigde services moeten zodanig zijn ontworpen dat zij aan de afgesproken doelen voldoen. Om dit te bereiken voert availabilitymanagement reactieve en proactieve activiteiten uit.

Reactieve activiteiten – worden uitgevoerd in de operationele fase van de levenscyclus:

■ het bewaken, meten, analyseren van en rapporteren over de beschikbaarheid van services en componenten;

■ analyse van beschikbaarheidsgebreken; ■ analyse van de uitgebreide incidentlevenscyclus; ■ identificeren van de onderliggende oorzaken van verstoringen in de services. Ook wel Service Failure Analysis (SFA) genoemd.

Proactieve activiteiten – moeten worden uitgevoerd in de ontwerpfase van de levenscyclus:

■ identificeren van vitale bedrijfsfuncties; ■ ontwerpen voor beschikbaarheid; ■ impactanalyse van componentfouten (Component Failure Impact Analysis (CFIA) ;

■ analyse van enkelvoudige (onder)delen van een systeem die bij uitval een ernstige verstoring veroorzaken (SPOF, Single Point of Failure);

■ foutenboomanalyse (FTA, Fault Tree Analysis); ■ modelleren; ■ risicoanalyse en -management; ■ gepland en preventief onderhoud; ■ continue evaluatie en verbetering. Leidende principes Effectief availabilitymanagement bestaat uit zowel reactieve als proactieve activiteiten. Het is belangrijk de volgende zaken niet te vergeten:

■ De beschikbaarheid van services is een van de belangrijkste aspecten om klanten tevreden te stellen.

■ In het geval van problemen kan een effectieve reactie nog altijd resulteren in klanttevredenheid.

■ De beschikbaarheid kan alleen worden verbeterd als men begrijpt hoe de services het bedrijf van de klant ondersteunen.

■ De zwakste schakel in de keten bepaalt hoe goed/effectief beschikbaarheid kan worden gemanaged.

■ Het is niet slechts een reactief proces, maar ook – en vooral – proactief. ■ Het is verstandig en meer kosteneffectief om van begin af aan het juiste beschikbaarheidsniveau in te bouwen in het ontwerp van nieuwe services.

Startpunten voor availabilitymanagement In afbeelding 5.9 is een aantal startpunten voor availabilitymanagement weergegeven. Het niet beschikbaar zijn van services kan men reduceren door elke fase in de uitgebreide incidentlevenscyclus (zie afbeelding 5.9) zo kort mogelijk te houden.

Afbeelding 5.9 Voorbeeld van beschikbaarheidstermen en – metingen (Bron: AXELOS) Services moeten snel weer worden hersteld wanneer ze niet beschikbaar zijn voor gebruikers. De

gemiddelde tijd tot herstel van de service

(MTRS,

Mean Time to Restore Service) is de tijd waarbinnen een functie (service, systeem of component) wordt hersteld voor operationeel gebruik na problemen. De MTRS hangt af van een aantal factoren, zoals:

■ Configuratie van serviceassets. ■ MTRS van afzonderlijke componenten. ■ Competenties van supportmedewerkers. ■ Beschikbare middelen. ■ Beleidsplannen. ■ Procedures. ■ Redundantie.

Analyse van de MTRS in relatie tot elke factor is nuttig voor verbetering van prestaties en het ontwerp van services.

Afbeelding 5.10 Voorbeeld van een uitgebreide incidentlevenscyclus (Bron: AXELOS) Andere metrics voor het meten van de beschikbaarheidsaspecten zijn:

■ Gemiddelde tijd tussen storingen (MTBF, Mean Time Between Failures) – de gemiddelde tijd die een CI of service de afgesproken functie ononderbroken kan uitvoeren. Deze metric geeft uitdrukking aan de mate van betrouwbaarheid van een service.

■ Gemiddelde tijd tussen incidenten (MTBSI, Mean Time Between Service Incidents) – de gemiddelde tijd vanaf het moment dat een service of systeem faalt tot het volgende faalmoment. Ook deze metric geeft uitdrukking aan de mate van betrouwbaarheid van een IT-service of configuratie-item (CI).

■ Gemiddelde tijd tot herstel van de service (MTRS, Mean Time To Restore Service) – de gemiddelde tijd die het kost om een CI of service na een falen te repareren. MTRS wordt gemeten vanaf het storingsmoment van de CI of service tot het moment waarop de service weer beschikbaar is. Deze metric geeft uitdrukking aan de onderhoudbaarheid van een service.

Redundantie

Redundantie is een manier om de betrouwbaarheid en duurzaamheid van de systemen te verhogen. ITIL maakt een onderscheid tussen een viertal typen van redundantie:

1. Actieve redundantie

– Dit type wordt gebruikt voor essentiële services, die

niet onderbroken mogen worden. De productieve capaciteit van de redundante componenten of systemen moet altijd beschikbaar zijn. Bij dit type redundantie werken alle redundante eenheden tegelijkertijd. Een voorbeeld daarvan is set ‘gespiegelde’ schijven (RAID 1 t/m 6 configuraties) in een server.

2. Passieve redundantie

– Het gebruik van redundante componenten of

systemen, die niet in gebruik zijn tot het moment van een storing. Bijvoorbeeld stand-by servers of geclusterde systemen.

3. Heterogene redundantie

– Redundantie door middel van het inzetten van

verschillende typen serviceassets, die tot hetzelfde in staat zijn om zo risico’s te spreiden. Dit type redundantie wordt gebruikt als de oorzaak van een mogelijke storing moeilijk te voorspellen is. Voorbeelden zijn het gebruik van verschillende opslagmedia, programmeertalen of ontwikkelteams.

4. Homogene redundantie

– Dit type refereert aan het inzetten van hetzelfde

type serviceasset. Dit type is toepasbaar als er een hoge mate van zekerheid is over de mogelijke oorzaken van een storing. Bijvoorbeeld het gebruik van twee identieke processoren.

Actieve en passieve redundantie kunnen afzonderlijk of in combinatie worden toegepast met de homogene en heterogene redundantie. Bijvoorbeeld: redundantie die zowel actief als homogeen is, heeft een lage fouttolerantie en een hoge zekerheid over de storingsoorzaken.

5.9.3 Informatiemanagement Availabilitymanagement onderhoudt een availabilitymanagementinformatiesysteem (AMIS). Het AMIS bevat alle metingen en informatie die nodig zijn voor het ondersteunen en kunnen uitvoeren van het availabilitymanagementproces. Het AMIS bevat ook informatie over het beschikbaarheidsniveau van de geleverde IT-service, over

de componenten en de ondersteunende services. De informatie in het AMIS gebruikt de IT-serviceprovider voor het produceren van rapporten over beschikbaarheidsvraagstukken, voor het vaststellen van trends en voor het in gang zetten van verbeteractiviteiten. Deze activiteiten en de informatie in het AMIS vormen de basis voor het ontwikkelen van de inhoud van het beschikbaarheidsplan.

Availabilitymanagementinformatiesysteem (AMIS) ■ Het AMIS is een verzameling tools, data en informatie die wordt gebruikt om availabilitymanagement te ondersteunen en is de hoeksteen van een succesvol availabilitymanagementproces. De informatie wordt opgeslagen en geanalyseerd door alle activiteiten binnen availabilitymanagement.

■ Het AMIS is een bewaarplaats (repository) die verschillende typen informatie bevat, waaronder informatie over de business, over de services en resource- en gebruiksgegevens vanuit alle technologiegebieden. Het AMIS is onderdeel van het servicekennismanagementsysteem (SKMS).

Beschikbaarheidsplan Het beschikbaarheidsplan beschrijft een breed scala aan initiatieven waarmee de beschikbaarheid verbeterd kan worden.

Het beschikbaarheidsplan is niet hetzelfde als een implementatieplan voor availabilitymanagement, maar het kan aanvankelijk samen met het implementatieplan worden ontwikkeld. Availabilitymanagement wijzigt voortdurend en daarom moet het beschikbaarheidsplan de volgende elementen bevatten:

■ Huidige beschikbaarheidsniveaus, in vergelijking met de afgesproken niveaus (vanuit het perspectief van de klant).

■ Acties genomen om tekortkomingen in beschikbaarheid op te lossen. ■ Informatie over gewijzigde beschikbaarheidseisen voor bestaande en toekomstige services.

■ Een toekomstgerichte planning voor SFA-opdrachten (Service Failure Analysis).

■ Regelmatige evaluatie van de SFA-opdrachten. ■ Voordelen en kansen van geplande upgrades.

Het is raadzaam het beschikbaarheidsplan te beschouwen als een aanvulling op het capaciteitsplan. Tevens is het verstandig om de publicatie van deze plannen af te stemmen op de jaarlijkse budgetteringsronde. De eerste zes maanden moet gedetailleerd zijn uitgewerkt. Het plan moet elk kwartaal worden bijgewerkt met kleine revisies. Grote revisies gebeuren elke zes maanden.

5.9.4 Interfaces ■ Servicelevelmanagement – Om de beschikbaarheidsdoelen vast te stellen en beschikbaarheid-gerelateerde onderwerpen te onderzoeken en op te lossen.

■ IT-service continuity management – Availabilitymanagement werkt met dit proces samen bij de beoordeling van de impact en risico’s waarmee de business te maken heeft indien bepaalde services niet beschikbaar zijn. Tevens werken ze samen als het gaat om de maatregelen die getroffen moeten worden op het vlak van veerkracht en herstelmechanismen. Daarbij is de focus van availabilitymanagement gericht op de normale businessoperatie en focust IT-service continuity management zich op onderbrekingen van de serviceverlening die het gevolg zijn van een calamiteit.

■ Incident- en problemmanagement – Biedt ondersteuning bij probleemonderzoek, het oplossen van incidenten en bij kwesties die te maken hebben met problemen rondom beschikbaarheid.

■ Demandmanagement – Anticipeert op de vraag naar services op basis van gebruikersprofielen en patronen in bedrijfsactiviteit, en zoekt naar manieren om klantgedrag te beïnvloeden.

■ Capaciteitsmanagement – Om de veerkracht en de algemene beschikbaarheid van de service te ondersteunen.

■ Changemanagement – Om te assisteren bij het opstellen van het PSOrapport. PSO staat voor Projected Service Outage. Het PSO-rapport is een document dat beschrijft wanneer men verwacht dat een service niet beschikbaar is (niet geleverd kan worden). Bijvoorbeeld door geplande wijzigings-, test- of onderhoudsactiviteiten.

■ Information security management – Voor het formuleren van de veiligheidsmaatregelen en beleidsregels die in het ontwerp voor beschikbaarheid en in het ontwerp voor herstel moeten worden opgenomen.

■ Accessmanagement – Om te voorzien in de methoden voor het op de juiste wijze verlenen en intrekken van toegangsrechten tot het AMIS.

5.9.5 Aanleidingen (triggers) ■ Nieuwe of gewijzigde bedrijfsbehoeften, services, doelstellingen binnen eerder overeengekomen, vastgelegde afspraken zoals SLR-, SLA- of OLAcontracten.

■ Storingen die voortkomen uit de onbeschikbaarheid van componenten, systemen en/ of services.

■ Periodieke evaluatie en het bijstellen van: •

prognoses, rapporten en plannen van availabilitymanagement;

•

bedrijfs- en IT-plannen en -strategieën;

•

ontwerpen en ontwerpstrategieën.

■ Herkennen dat een wijziging een risico of een zekere impact heeft op een bedrijfsproces, een essentiële bedrijfsfunctie (vital business function, VBF), een service of component.

■ Verzoek van SLM om te assisteren bij de uitleg van behaalde resultaten voor availabilitydoelen.

5.9.6 Invoer ■ Bedrijfsinformatie. ■ Bedrijfsimpactinformatie. ■ Rapporten en registers. ■ Service-informatie. ■ Financiële informatie. ■ Wijzigings- en release-informatie. ■ Informatie over serviceasset- en configuratiemanagement. ■ Servicedoelen. ■ Componentinformatie. ■ Informatie over het technisch systeem. ■ Prestaties in het verleden. ■ Informatie over availabilitygebreken. ■ Planningsinformatie. 5.9.7 Uitvoer ■ Het informatiesysteem van availabilitymanagement (AMIS).

■ Het beschikbaarheidsplan. ■ Ontwerpdata voor beschikbaarheid en herstel. ■ Rapporten over de beschikbaarheid, betrouwbaarheid en onderhoudbaarheid van services.

■ Beschikbaarheids-, betrouwbaarheids- en onderhoudbaarheidsrapporten met behaalde resultaten tegenover doelen.

■ Bijgewerkt risicoregister. ■ Bewaking, beheer en rapportage. ■ Testschema van availabilitymanagement. ■ Schema voor gepland en preventief onderhoud. ■ Projected Service Outage (PSO)-rapport. ■ Risicoassesments en -rapporten en een bijgewerkt risicoregister. ■ Bijdragen leveren aan de PSO, die vanwege wijzigingen moet worden opgesteld in samenwerking met release & deployment management.

■ Informatie over de proactieve availabilitytechnieken en -maatregelen. ■ Verbeteringsacties voor opname in het serviceverbeterplan (Service Improvement Plan, SIP).

5.9.8 Kritieke succesfactoren ■ Managen van de beschikbaarheid en betrouwbaarheid van IT-services. ■ Beschikbaarheid van de IT-infrastructuur (zoals afgesproken in de SLA) geleverd tegen optimale kosten.

■ Voldoen aan de behoefte vanuit de business om gebruik te kunnen maken van IT-services.

5.9.9 Metrics ■ Procentuele daling in de uitval van services en componenten. ■ Procentuele stijging in de betrouwbaarheid van services en componenten. ■ Procentuele verbetering in algehele end-to-end-beschikbaarheid van services. ■ Procentuele daling van de kosten van uitval. ■ Procentuele stijging in klanttevredenheid. 5.9.10 Uitdagingen ■ De business ervan overtuigen om informatie te leveren over de strategische bedrijfsplannen. Alleen dan is de IT-serviceprovider in staat zijn availabilitymanagementproces effectief uit te voeren.

■ Alle availabilitymanagementdata over de componenten onderbrengen in een geïntegreerde database die op een consistente manier kan worden geanalyseerd.

■ Het analyseren van de grote hoeveelheid data die availabilitymanagement verzamelt.

■ Bepalen welke componenten deel uitmaken van de end-to-end-service. ■ De end-to-end-beschikbaarheid berekenen.

5.9.11 Risico’s ■ Gebrek aan: •

betrokkenheid van de business bij het availabilitymanagementproces;

•

informatie over de toekomstplannen en strategieën van de organisatie;

•

betrokkenheid van het hoger management;

•

middelen en/of budget voor het availabilitymanagementproces.

■ De availabilitymanagementactiviteiten, -methoden en -technieken worden los van elkaar (geïsoleerd) uitgevoerd.

■ De processen worden te bureaucratisch of te bewerkelijk. ■ Te veel focus op component/systeem in plaats van op de end-to-endbeschikbaarheid van services.

■ De rapporten en informatie zijn te omvangrijk of te technisch van aard.

■ 5.10 IT-SERVICE CONTINUITY MANAGEMENT 5.10.1 Inleiding Het doel van IT-service continuity management (ITSCM) is ondersteuning geven aan het overall business-continuïteitsmanagementproces door te zorgen dat de noodzakelijke technische en IT-servicefaciliteiten weer beschikbaar zijn binnen de vereiste en overeengekomen tijd.

Doelstellingen van IT-service continuity management zijn onder andere: ■ Handhaven van continuïteitsplannen en herstelplannen. ■ Regelmatig uitvoeren van een businessimpactanalyse (BIA). ■ Regelmatig uitvoeren van risico-inschattingen en calamiteitenoefeningen. ■ Verstrekken van advies aan en begeleiding van alle andere gebieden van de business en IT voor alle continuïteit- en herstel-gerelateerde zaken.

■ Ervoor zorgen dat de juiste continuïteits- en herstelmechanismen worden opgezet om te voldoen aan de overeengekomen bedrijfscontinuïteitsdoelen.

■ Beoordeling van het effect van alle wijzigingen op de continuïteit en herstelplannen.

■ De implementatie van proactieve maatregelen om de availability van de services te verbeteren.

■ Onderhandelingen over overeenkomsten met IT-serviceproviders in relatie tot de vereiste herstelmogelijkheid om continuïteitsplannen te ondersteunen.

Bereik ITSCM is gericht op de gebeurtenissen (events) die de business als een ramp beschouwt. Minder ingrijpende events worden door het incidentmanagementproces afgehandeld. ITSCM houdt zich primair bezig met de IT-middelen en configuraties die de bedrijfsprocessen ondersteunen.

ITSCM richt zich meestal niet rechtstreeks op de risico’s op langere termijn, zoals die van wijzigingen in de bedrijfsvoering. Hoewel deze een enorme impact kunnen hebben, is er over het algemeen genoeg tijd om dergelijke risico’s te identificeren en actie te ondernemen. Kleine technische problemen, zoals niet-cruciale schijfuitval, vallen niet onder dit proces – ze worden behandeld door incidentmanagement.

ITSCM gaat over:

■ Afspraken over het bereik van ITSCM. ■ Een businessimpactanalyse om de impact van het verlies van IT-services te kwantificeren.

■ Risicoanalyse. Het identificeren van risico’s die potentiële bedreigingen vormen voor de continuïteit van de business. Er wordt een inschatting gemaakt wat de mate van waarschijnlijkheid is dat deze bedreigingen werkelijkheid worden.

Afbeelding 5.11 Activiteiten tijdens de levenscyclus van ITSCM in relatie met de activiteiten van BCM

■ Creëren van een algehele ITSCM-strategie die moet worden geïntegreerd in de strategie van het bedrijfscontinuïteitsmanagement.

■ Maken van continuïteitsplannen. ■ De continuïteitsplannen testen. ■ Doorlopende bewerking en onderhoud van de plannen. Waarde voor de business ITSCM heeft een waardevolle rol in het ondersteunen van het proces bedrijfscontinuïteitsplanning. Organisaties gebruiken het ITSCM-proces vaak om bewustzijn te creëren voor de noodzaak van continuïteits- en herstelmaatregelen en rechtvaardiging van hun beslissing om het proces van bedrijfscontinuïteitsplanning (inclusief plannen) te implementeren.

5.10.2 Activiteiten, methoden en technieken ITSCM is een cyclisch proces bestaande uit vier fasen (afbeelding 5.11). Het zorgt ervoor dat de ontwikkelde servicecontinuïteitsplannen en herstelplannen in lijn zijn en blijven met de bedrijfscontinuïteitsplannen en hun updates.

5.10.3 Informatiemanagement Informatiemanagement legt alle informatie vast die is vereist om de ITSCMplannen te onderhouden en brengt het plan op één lijn met de BCMinformatie (bedrijfscontinuïteitmanagement).

■ De meest recente versie van de BCM-strategie en bedrijfsimpactanalyse. ■ Risico’s in een risicoregister waaronder risico-inschattingen en mogelijke antwoorden daarop.

■ Uitgevoerde en geplande testen. ■ Informatie over het ITSCM en gerelateerde plannen. ■ Bestaande herstelfaciliteiten, leveranciers, partners en overeenkomsten. ■ Informatie over back-up- en herstelprocessen. ■ Informatie over de laatste BIA-versie. ■ Uitgebreide informatie over risico in een risicoregister, inclusief risicoinschattingen en antwoorden daarop.

■ De laatste versie van de BCM-strategie en bedrijfscontinuïteitsplannen. Elk cruciaal bedrijfsdomein is verantwoordelijk voor de ontwikkeling van een plan. Dit plan vermeldt de personen die deel uitmaken van de herstelteams en de taken die uitgevoerd moeten worden voor de herstelwerkzaamheden.

5.10.4 Interfaces ■ Changemanagement – Om wijzigingen te beoordelen aan de hand van ITSCM-plannen en -activiteiten. Het plan zelf moet onder controle van changemanagement staan.

■ Incident- en problemmanagement – Incidenten kunnen uitgroeien tot ernstige incidenten of calamiteiten.

■ Availabilitymanagement – Om risico-evaluatie te coördineren en de reacties op risico’s te implementeren.

■ Servicelevelmanagement – Hersteleisen worden afgestemd en gedocumenteerd in de SLA.

■ Capaciteitsmanagement – Om te zorgen dat er voldoende middelen zijn om de herstelwerkzaamheden uit te voeren op vervangende computers na een ramp.

■ Serviceasset & configuratiemanagement – Het CMS documenteert de componenten die deel uitmaken van de infrastructuur en de relaties tussen de componenten.

■ Information security management – Een grote inbreuk op de security kan als rampzalig worden beschouwd, dus worden securityaspecten meegenomen in een BIA en in de risicoanalyse.

5.10.5 Aanleidingen (triggers) ■ Inschatting van de veranderingen en het bijwonen van vergaderingen van de Change Advisory Board.

■ Lessen geleerd vanuit eerdere continuïteitsevents en bijbehorende herstelactiviteiten.

■ Nieuwe of gewijzigde zakelijke behoeften, services, doelstellingen binnen eerder overeengekomen, vastgelegde afspraken zoals SLR-, SLA-, OLAcontracten.

■ Storingen die de omvang van een (potentiële) calamiteit hebben en die voortkomen uit de onbeschikbaarheid van componenten, systemen en/of services.

■ Periodieke evaluatie en herziening van: •

businessimpactanalyse;

•

risicoanalyseactiviteiten;

•

resultaten van continuïteits- en hersteltesten.

■ Voorspellingen, rapporten en plannen van continuïteitsmanagement. ■ Bedrijfs- en IT-plannen en -strategieën. ■ Ontwerpen en strategieën. ■ Herkennen dat een wijziging een risico of een zekere impact heeft op een bedrijfsproces, een essentiële bedrijfsfunctie, een service of component.

5.10.6 Invoer ■ Bedrijfsinformatie. ■ Een bedrijfscontinuïteitstrategie en bedrijfscontinuïteitplannen. ■ IT-informatie. ■ Service-informatie.

■ Financiële informatie. ■ Wijzigingsinformatie. ■ Verificatie- en auditrapporten van serviceasset- & configuratiemanagement. ■ Testschema’s van bedrijfscontinuïteitmanagement- en availabilitymanagement.

■ Capaciteitsmanagementinformatie. ■ Plannen van IT-service continuity management en testrapporten van leveranciers en partners.

5.10.7 Uitvoer ■ Aangepast(e) ITSCM-beleid en -strategie. ■ Businessimpactanalyse-rapporten. ■ Evaluaties en rapporten van risicoanalyse en -management. ■ ITSCM-plannen. ■ Testschema. ■ Testscenario’s. ■ Testrapporten en -evaluaties. 5.10.8 Kritieke succesfactoren ■ IT-services worden geleverd en kunnen worden hersteld in overeenstemming met bedrijfsdoelstellingen.

■ In de gehele organisatie moet men zich bewust zijn van het belang van de continuïteitsplannen die de business en het ITSCM hebben ontwikkeld.

5.10.9 Metrics ■ Toename van: •

aanwezige (aantoonbare) kennis in de IT-organisatie over de impact van calamiteiten op de business, en over de behoeften vanuit de business met betrekking tot benodigde continuïteit van primaire bedrijfsprocessen;

•

het aantal succesvolle testresultaten;

•

het succes van regelmatige audits van de ITSCM-plannen.

■ Periodiek en regelmatig: •

De doelstellingen van het ITSCM-proces zijn aantoonbaar gecommuniceerd naar alle stakeholders en tevens zijn alle taken, verantwoordelijkheden en bevoegdheden binnen dit proces aantoonbaar gecommuniceerd naar alle betrokkenen.

•

Succesvolle validatie dat alle servicehersteldoelen die zijn afgesproken, ook haalbaar zijn.

•

Uitgebreide testen van ITSCM-plannen vinden volgens plan plaats.

•

Evaluatie van alle plannen.

■ Algehele afname van de risico’s en de impact van mogelijk falen van ITservices.

5.10.10 Uitdagingen ■ Zorgen voor goede plannen als er geen BCM-proces is. ■ Wijzigen van het beeld dat continuïteit een IT-verantwoordelijkheid is en de business er daardoor van uitgaat dat IT-services onder alle omstandigheden blijven draaien.

■ Afstemming en integratie met een bestaand BCM-proces.

5.10.11 Risico’s ■ Een gebrek aan: •

een BCM-proces;

•

betrokkenheid van de business bij ITSCM;

•

informatie over de toekomstige plannen en strategieën van de organisatie;

•

betrokkenheid van het hogere management;

•

middelen en/of budget voor ITSCM.

■ Te veel focus op technologiekwesties ten koste van de behoeften en de prioriteiten van de business en/of IT-services.

■ Risicoanalyse en -management worden los van elkaar uitgevoerd zonder input vanuit andere serviceontwerpprocessen.

■ Verouderde en/of ITSCM-plannen en -informatie die onvoldoende zijn afgestemd op de business en de BCM-informatie en -plannen.

■ ITSCM-activiteiten, methoden en technieken worden los van elkaar (geïsoleerd) uitgevoerd.

■ De processen worden te bureaucratisch of te bewerkelijk. ■ De rapporten en informatie zijn te omvangrijk of te technisch van aard.

■ 5.11 INFORMATION SECURITY MANAGEMENT

5.11.1 Inleiding Het doel van information security management is om de security (beveiliging) van de IT en de organisatie op één lijn te brengen. Ze zorgt ervoor dat informatie wordt beveiligd en effectief gemanaged in alle services en servicemanagementactiviteiten.

De

doelstellingen van information security management zijn:

■ Informatie is beschikbaar en bruikbaar wanneer nodig (beschikbaarheid). ■ Informatie is alleen beschikbaar voor geautoriseerde personen (vertrouwelijkheid).

■ De informatie is compleet, accuraat en beschermd tegen wijzigingen door personen die hiertoe niet bevoegd (geautoriseerd) zijn (integriteit).

■ Transacties en informatie-uitwisselingen tussen bedrijven en partners moeten betrouwbaar zijn (authenticiteit en onweerlegbaarheid).

Bereik Information security management moet begrijpen hoe het totaalplaatje van de security-omgeving van de organisatie en haar IT-afdeling eruitziet. Denk daarbij aan:

■ Het huidige en toekomstige securitybeleid van de organisatie en de bijbehorende plannen.

■ Security-eisen. ■ Wettelijke eisen. ■ Verplichtingen en verantwoordelijkheden. ■ Business- en IT-risico’s (en het managen ervan). Dit stelt information security management in staat de huidige en toekomstige securityaspecten van de organisatie kosteneffectief te beheren. Het proces omvat de volgende elementen:

■ Het ontwikkelen, onderhouden en distribueren van een information security-beleid en er (dwingend) op toezien dat dit beleid wordt nageleefd.

■ Begrip van de afgesproken huidige en toekomstige security-eisen van de business.

■ Implementeren (en documenteren) van controles die het information security -beleid ondersteunen en waarmee risico’s kunnen worden gemanaged.

■ Managen van IT-serviceproviders en contracten betreffende toegang tot systemen en services.

■ Managen van inbreuk op de security en security-incidenten. ■ Proactieve houding ten aanzien van de verbetering van de securitycontrolesystemen.

Waarde voor de business Information security management zorgt ervoor dat het information securitybeleid voldoet aan het algehele securitybeleid van de organisatie en aan de eisen van corporate governance. Ze kweekt intern bewustzijn over de noodzaak om alle services en assets te beveiligen. Het uitvoerend management is verantwoordelijk voor de bedrijfsinformatie en onderneemt actie in het geval de security in het geding komt. Van het hogere management wordt verwacht dat ze de informatiesecurity een integraal deel van corporate governance maakt.

Basisbegrippen Het proces information security management omvat:

■ Information security-beleid. ■ Information Security Management System (ISMS). ■ Uitgebreide securitystrategie (gerelateerd aan de bedrijfsdoelstellingen en strategie).

■ Effectieve securitystructuur in de organisatie. ■ Bepaalde securitycontroles om het beleid te ondersteunen. ■ Risicomanagement. ■ Bewakingsprocessen. ■ Communicatiestrategie. ■ Training en beveiligingsbewustzijnsstrategie.

5.11.2 Activiteiten, methoden en technieken De belangrijke activiteiten binnen het proces information security management zijn:

■ Ontwikkeling en onderhoud van een algemeen information security-beleid en van een aantal op ondersteuning gerichte beleidsregels.

■ Communicatie over en implementatie van het information security-beleid alsmede erop toezien dat dit beleid wordt nageleefd.

■ Beoordeling en ordening (classificatie) van alle informatie-assets en documentatie.

■ Implementatie, evaluatie, revisie en verbetering van het geheel aan beveiligingscontroles. Uitvoeren van risicoanalyses en de verwerking van de reacties op deze analyses.

■ Bewaking tegen inbreuken op de security en het managen van ernstige security-incidenten.

■ Analyse, rapportage, beperking van het aantal en de impact van securityincidenten.

■ Planning en uitvoering van security-evaluaties, audits en penetratietesten. Information security management system Het information security management proces dient gebaseerd te zijn op een formeel systeem op basis waarvan beleid en doelstellingen geformuleerd kunnen worden.

Dit systeem zal in het algemeen bestaan uit:

■ Een information security-beleid en specifieke securityrichtlijnen. ■ Een SMIS (Security Management Information System). ■ Een allesomvattende securitystrategie. ■ Een effectieve organisatorische securitystructuur. ■ Een verzameling securitycontroles om het beleid te ondersteunen bij het beheersen van securityrisico’s.

■ Het monitoren van processen om te borgen dat men zich houdt aan de richtlijnen (compliance) en om feedback te verzamelen over de effectiviteit van de maatregelen.

Afbeelding 5.12 De hoofdonderwerpen van information security management (Bron: AXELOS)

■ Communicatiestrategie en een securityplan. ■ Training en bewustwording met betrekking tot de strategie en het plan. ISO 27001 is de internationale standaard op basis waarvan organisaties hun ISMS kunnen certificeren. Figuur 5.13 is gebaseerd op verschillende richtlijnen, waaronder ISO27001.

Securitygovernance Wanneer IT-securitygovernance goed geïmplementeerd wordt, moet het een zestal fundamentele uitkomsten kunnen leveren: 1. Strategisch alignement (van IT en business). 2. Waardelevering. 3. Risicomanagement. 4. Prestatiemanagement.

5. Resourcemanagement. 6. Zekerheid met betrekking tot het bedrijfsproces.

De information security manager moet begrijpen dat security niet slechts een stap in de levenscyclus is en dat het niet alleen met technologie kan worden opgelost. Informatiesecurity moet een integraal deel zijn van alle services (en systemen) en is een doorlopend proces dat continu moet worden gemanaged. Afbeelding 5.13 beschrijft controles die in het proces kunnen worden gebruikt.

Afbeelding 5.13 Voorbeeld van een work ow voor information security management (Bron: AXELOS) Afbeelding 5.14 laat zien dat een risico kan resulteren in een op haar beurt een

bedreiging die

incident kan veroorzaken, waarvan schade het gevolg is.

Verschillende maatregelen kunnen tussen deze fasen genomen worden:

■ Preventieve maatregelen – voorkomen van effecten (bijv. accessmanagement).

■ Beperkende maatregelen – beperken van effecten (bijv. back-up en testen).

■ Opsporende maatregelen – detecteren van effecten (bijv. bewaking). ■ Repressieve maatregelen – onderdrukken van effecten (bijv. blokkeren). ■ Correctieve maatregelen – repareren van effecten (bijv. terugdraaiing).

Afbeelding 5.14 Voorbeeld van een framework voor het IT-information security management (Bron: AXELOS)

5.11.3 Informatiemanagement Alle informatie die information security management nodig heeft, moet zijn opgenomen in het securitymanagementinformatiesysteem (SMIS). Hieronder moeten vallen alle securitycontroles, risico’s, inbreuken, processen en rapporten die nodig zijn om het information security-beleid en het SMIS te ondersteunen en te onderhouden. Het SMIS zal ook voorzien in de input voor security-audits en -evaluaties en voor de continue verbeteractiviteiten.

■ Het SMIS bestaat uit een aantal tools, data (gegevens) en informatie dat wordt gebruikt ter ondersteuning van securitymanagement en is de hoeksteen van een succesvol proces en is onderdeel van de SKMS.

■ Het SMIS kan worden gebruikt voor vastlegging en opslag van bepaalde data en informatie die nodig zijn ter ondersteuning van belangrijke activiteiten zoals genereren van rapporten, statistische analyse en securityvoorspellingen en -planning.

5.11.4 Interfaces ■ Incident- en problemmanagement – Information security management biedt ondersteuning aan het besluitvormingsproces met betrekking tot securityincidenten en -problemen.

■ Servicelevelmanagement – Biedt ondersteuning bij het vastleggen van de security-eisen en de bijbehorende verantwoordelijkheden en de opname daarvan in het SLR en de SLA.

■ Accessmanagement – Om de acties uit te voeren waarmee toegang wordt verleend of ontzegd en past de beleidsregels toe die zijn omschreven door information security management.

■ Changemanagement – Information security management ondersteunt changemanagement bij het bepalen van de mogelijke impact van wijzigingen op de security.

■ IT-service continuity management – Om samen te werken met ITSCM aan de beoordeling van bedrijfsimpact en risico en het voorzien in mechanismen die zorgen voor veerkracht en herstel na storingen.

■ Serviceasset- en configuratiemanagement – Om te voorzien in accurate informatie over serviceassets als hulp bij bepalen van het securityniveau.

■ Availabilitymanagement – Data die niet beschikbaar zijn of data die integriteitsgebreken hebben, kunnen bepaalde aspecten (functies) van de service verstoren.

■ Capaciteitsmanagement – Ter overweging bij de aanschaf en/of introductie van nieuwe technische systemen of software.

■ Financieel management voor IT-services – Om voldoende middelen te verschaffen die de security financieren.

■ Leveranciersmanagement – Om te helpen bij het managen van leveranciers en de voorwaarden die moeten worden opgenomen in de contracten betreffende de verantwoordelijkheid die serviceproviders hebben ten aan zien van de security.

■ Wettelijke

en

HR-kwesties – Om securitykwesties te onderzoeken. ISM

moet geïntegreerd zijn met deze overkoepelende processen en functies.

5.11.5 Aanleidingen (triggers) ■ Nieuw of gewijzigd: •

Richtlijnen van corporate governance.

•

Organisatie security-beleid.

•

Risicomanagementprocessen en -richtlijnen op ondernemingsniveau.

•

Bedrijfsbehoeften.

•

Services.

•

Doelen binnen overeenkomsten zoals SLR, SLA, OLA-contracten.

■ Securityfouten in een service of component, security-events en waarschuwingen, met inbegrip van drempelevents en exceptierapporten.

■ Periodieke evaluatie en revisie van: •

bedrijfs- en IT-plannen en strategieën.

•

herkenning/notificatie van een wijziging in het risico of de impact voor een bedrijfsproces, vitale bedrijfsfunctie, een service of component.

■ Verzoeken vanuit ander gebieden, vooral van SLM, voor assistentie bij securitykwesties.

5.11.6 Invoer ■ Businessinformatie. ■ Corporate governance en organisatie security-beleid vastgelegd in regels en richtlijnen.

■ IT-informatie. ■ Service-informatie. ■ Risicoanalyseprocessen en -rapporten. ■ Gedetailleerde informatie over security-events en -fouten. ■ Wijzigingsinformatie. ■ Informatie over het configuratiemanagementsysteem. ■ Gedetailleerde informatie over partner- en serviceproviders ten aanzien van hun toegang tot informatie.

5.11.7 Uitvoer ■ Algemeen beleid voor information security management. ■ Een informatiesysteem voor securitymanagement (SMIS). ■ Aangepaste beoordelingsprocessen en rapporten voor securityrisico’s. ■ Securitycontroles, -audits en -rapporten. ■ Securitytestschema’s en -plannen. ■ Een aantal securityclassificaties. ■ Een aantal geclassificeerde gegevensverzamelingen. ■ Evaluaties en rapporten van securityfouten en ernstige incidenten.

■ Beleidsregels, processen en procedures voor het managen van partners en leveranciers en hun toegang tot services en informatie.

■ Algemeen beleid voor information security management. ■ Een informatiesysteem voor securitymanagement (SMIS). ■ Aangepaste beoordelingsprocessen en rapporten voor securityrisico. ■ Securitycontroles, -audits en -rapporten. ■ Securitytestschema’s en -plannen. ■ Een aantal niveaus van security. ■ Een aantal geclassificeerde informatie-assets. ■ Evaluaties en rapporten van securityfouten en ernstige incidenten. ■ Beleidsregels, processen en procedures voor het beheren van partners en leveranciers en hun toegang tot services en informatie.

5.11.8 Kritieke succesfactoren ■ De business is beschermd tegen schendingen van de security. ■ Vaststelling van een helder en geaccepteerd beleid, geïntegreerd met de behoeften van de business.

■ Securityprocedures die gerechtvaardigd en geschikt zijn en ondersteund door het hogere management.

■ Effectieve communicatie over het securitybeleid in combinatie met training met betrekking tot security-eisen.

■ Een mechanisme voor verbetering. ■ Een integraal onderdeel van IT-services, ITSM-processen en het securitymanagement van de organisatie.

■ De beschikbaarheid van services wordt niet in gevaar gebracht door securityincidenten.

■ Duidelijk eigenaarschap en bewustzijn van de securitybeleidsregels binnen de klantgemeenschap.

5.11.9 Metrics ■ Procentuele daling in securityfouten. ■ Procentuele daling in de impact van securityfouten en incidenten. ■ Procentuele stijging in de mate waarin de geleverde security-gerelateerde prestaties voldoen aan de in de SLA overeengekomen beveiligingsclausules.

■ Daling in het aantal afwijkingen van het securitybeleid en -proces. ■ Stijging in de acceptatie en het volgen van securityprocedures.

■ Gestegen ondersteuning en betrokkenheid van het hoger management. ■ Gestegen bewustzijn over het securitybeleid in de gehele organisatie.

5.11.10 Uitdagingen ■ Zorgen dat er adequate ondersteuning is van de business, bedrijfsbeveiliging en hoger management.

■ Het beeld wijzigen dat continuïteit een IT-verantwoordelijkheid is waardoor de business veronderstelt dat IT-services onder alle omstandigheden blijven draaien.

■ Afstemming en integratie met een bestaand business security-proces.

5.11.11 Risico’s ■ Risicofactoren kunnen zowel intern als extern zijn, waaronder: •

Wijdverspreid gebruik van technologie.

•

Groeiende afhankelijkheid van de business van IT.

•

Groeiende complexiteit van en connectiviteit tussen systemen.

•

Verdwijnen van de traditionele organisatiegrenzen.

•

Steeds meer zware regelgeving.

•

Groeiende eisen voor beschikbaarheid en robuustheid.

•

Externe gevaren van hackers, malware, afpersing, industriële spionage en lekken van organisatie- of privé-data.

■ Een gebrek aan betrokkenheid van: •

De business bij het proces information security management en bijbehorende procedures.

•

De business bij toekomstige plannen en strategieën.

•

Het hoger management.

•

Middelen en/of budget voor het information security management.

■ Te veel focus op technologiekwesties in plaats van op de behoeften/prioriteiten van de business.

■ De beleidsregels, plannen, risico’s en informatie zijn verouderd en/of onvoldoende afgestemd op de huidige organisatie om haar security nog langer te kunnen garanderen.

■ 5.12 LEVERANCIERSMANAGEMENT

5.12.1 Inleiding Het doel van het leveranciersmanagementproces is het managen van leveranciers en de services die zij leveren. Haar taak is om erop toe te zien dat er IT-services worden geleverd die naadloos aansluiten op de verwachtingen van de business, of anders gezegd: waarde voor geld.

Doelstellingen van leveranciersmanagement zijn: ■ Waarde voor geld krijgen van leveranciers en contracten. ■ Zorgen dat onderliggende contracten en overeenkomsten met leveranciers afgestemd zijn op de bedrijfsbehoeften.

■ Relaties met leveranciers en hun prestaties managen. ■ Onderhandelen en overeenkomen van contracten met leveranciers. ■ Onderhouden van een leveranciersbeleid en een ondersteunende leveranciers- en contractendatabase (SCMIS, Supplier and Contract Management Information System).

Bereik Het leveranciersmanagementproces omvat het managen van alle leveranciers en contracten die nodig zijn om het leveren van IT-services aan de business te ondersteunen. Hoe groter de bijdrage van een leverancier, hoe meer energie de serviceprovider moet stoppen in de relatie met de leverancier, en hoe meer deze betrokken moet zijn bij de ontwikkeling en implementatie van de strategie. Hoe kleiner de waarde-bijdrage van de leverancier, hoe waarschijnlijker het is dat de relatie voornamelijk wordt gemanaged op een operationeel niveau. Het proces kent de volgende aspecten:

■ Implementatie en afdwinging van het leveranciersbeleid. ■ Onderhouden van een informatiesysteem voor het managen van leveranciers en contracten (supplier and contract management information system, SCMIS).

■ Categoriseren van leveranciers, contracten en risicoanalyse. ■ Evaluatie van contracten en leveranciers. ■ Ontwikkelen, onderhandelen en overeenkomen van contracten. ■ Revisie, vernieuwing en beëindiging van contracten. Waarde voor de business

Een van de belangrijkste doelen van leveranciersmanagement is om waarde voor geld te krijgen via leveranciers en contracten, en te zorgen dat alle servicedoelen in onderliggende contracten en overeenkomsten zijn afgestemd op bedrijfsbehoeften en de doelen zoals vastgelegd in de SLA. Dit zorgt voor de levering van end-to-end IT-services die naadloos aansluiten op de verwachtingen van de business. Het leveranciersmanagementproces moet aansluiten bij alle bedrijfseisen en de eisen van alle andere IT- en servicemanagementprocessen, in het bijzonder information security management en ITSCM.

Basisbegrippen Alle activiteiten in dit proces moeten worden aangedreven vanuit een leveranciersstrategie en een servicestrategiebeleid. Er moet een informatiesysteem voor leveranciers- en contractmanagement (SCMIS) ontwikkeld worden zodat het beleid consistent en effectief uitgevoerd kan worden. In het ideale geval is het SCMIS een geïntegreerd element van CMS of SKMS. Het SCMIS moet alle data bevatten betreffende leveranciers en contracten, en ook die data van het soort service of product en eventuele informatie over en relatie met configuratie-items.

Deze data leveren belangrijke informatie voor activiteiten en procedures zoals:

■ Categoriseren van leveranciers. ■ Onderhouden van een leveranciers- en contractendatabase. ■ Evaluatie en set-up van nieuwe leveranciers en contracten. ■ Contracteren van nieuwe leveranciers. ■ Managen van de leverancierscontracten en -prestaties. ■ Het vernieuwen of beëindigen van contracten.

5.12.2 Activiteiten, methoden en technieken Voor externe leveranciers is het raadzaam een formeel contract op te stellen waarin de over-eengekomen en gedocumenteerde verantwoordelijkheden en doelen duidelijk zijn vastgelegd. Dit contract moet gedurende alle fasen van zijn levenscyclus worden gemanaged.

Afbeelding 5.15 Voorbeeld work ow leveranciersmanagement (Bron: AXELOS) De activiteiten die binnen dit proces worden uitgevoerd zijn: 1. Definitie van nieuwe leveranciers- en contractvereisten. 2. Evaluatie van nieuwe leveranciers en contracten. 3. Het categoriseren van leveranciers en contracten, en het onderhoud aan het SCMIS. 4. Regelen van nieuwe leveranciers en contracten. 5. Beheren van de leverancier- en contractuele prestaties. 6. Contractvernieuwing of beëindiging.

5.12.3 Informatiemanagement

Alle informatie die leveranciersmanagement nodig heeft, moet zijn opgenomen in het SCMIS. Hieronder moeten vallen alle informatie die verband houdt met leveranciers en contracten, evenals alle informatie die te maken heeft met de uitvoering van ondersteunende services geleverd door leveranciers. Informatie die betrekking heeft op deze ondersteunende services moet ook zijn opgenomen in het serviceportfolio, samen met de relaties tot alle andere services en componenten. Deze informatie moet zijn geïntegreerd en onderhouden in lijn met alle andere informatiesystemen voor ITmanagement, in het bijzonder het serviceportfolio.

5.12.4 Interfaces ■ Serviceportfoliomanagement – Zorgt dat het serviceportfolio alle ondersteunende systemen en data accuraat weergeeft.

■ Financieel management voor IT-services – Financiert eisen en contracten van leveranciersmanagement, levert financieel advies en begeleiding bij inkoop.

■ SLM – Assisteert bij het bepalen van doelen, eisen en verantwoordelijkheid. ■ ITSCM – Werkt samen met leveranciersmanagement met betrekking tot het beheer van leveranciers, die continuïteitsvoorzieningen leveren (uitwijklocaties, apparatuur e.d.).

■ Information security management – Managet leveranciers en beheert hun toegang tot services.

■ Changemanagement – Voor leverancierscontracten en -afspraken gelden changemanagementprocedures. De betrokkenheid van leveranciers wordt beoordeeld en meegenomen in de planning van wijzigingen.

5.12.5 Aanleidingen (triggers) ■ Nieuwe of gewijzigde: •

richtlijnen van corporate governance;

•

bedrijfs- en IT-strategieën, -beleidsregels of -plannen;

•

bedrijfsbehoeften;

•

services;

•

eisen binnen overeenkomsten zoals SLR-, SLA- of OLA-contracten.

■ Periodieke evaluatie en revisie van de ontwerpen en de strategieën en van de beleidsregels, -rapporten en -plannen ten aanzien van leveranciersmanagement.

■ Verzoeken vanuit andere gebieden, met name SLM en information security management, om te assisteren bij leverancierskwesties.

■ Vereisten voor nieuwe contracten, contractvernieuwing of contractbeëindiging.

■ Categorisatie van leveranciers en/of contracten.

5.12.6 Invoer ■ Bedrijfsinformatie. ■ Leverancier- en contractenstrategie. ■ Leveranciersplannen en -strategieën. ■ Leverancierscontracten, -afspraken en doelen. ■ Informatie over leverancier- en contractuele prestaties. ■ IT-informatie. ■ Prestatieproblemen. ■ Financiële informatie. ■ Service-informatie. ■ CMS. 5.12.7 Uitvoer ■ SCMIS. ■ Informatie en rapporten over leverancier- en contractuele prestaties. ■ Notulen van leverancier- en contractevaluaties. ■ Leverancier-SIP’s. ■ Leveranciersonderzoeksrapporten. 5.12.8 Kritieke succesfactoren ■ Bedrijf is beschermd tegen slechte leveranciersprestaties. ■ Ondersteunende services en hun doelen zijn afgestemd op bedrijfsbehoeften en -eisen.

■ Beschikbaarheid van services wordt niet in gevaar gebracht door leveranciersprestaties.

■ Duidelijk eigenaarschap en bewustzijn van leveranciers- en contractuele problemen.

5.12.9 Metrics ■ Stijging in het aantal:

•

Leveranciers dat voldoet aan de doelen in het contract.

•

Service- en contractuele evaluaties met leveranciers.

•

Leveranciers- en contractuele doelen die zijn afgestemd op SLA- en SLRdoelen.

•

Leveranciers met een aangewezen leveranciersmanager.

•

Contracten met een aangewezen contractmanager.

■ Daling in het aantal: •

Inbreuken op services veroorzaakt door leveranciers.

•

Bedreigende inbreuken op services veroorzaakt door leveranciers.

•

Inbreuken contractuele doelen.

5.12.10 Uitdagingen ■ Constant wijzigende bedrijfs- en IT-behoeften. ■ Bestaande gebrekkige contracten. ■ Kwesties met betrekking tot services die gebaseerd zijn op legacysystemen, vooral met onlangs uitbestede services.

■ Onvoldoende expertise behouden binnen de organisatie. ■ Gebonden zijn aan langetermijncontracten. ■ Geschillen over in rekening gebrachte kosten. ■ Interferentie door een der partijen in de bedrijfsvoering van de ander. ■ Gevangen zijn in dagelijkse brandjesbestrijding en de proactieve methode verliezen.

■ Slechte communicatie. ■ Botsende persoonlijkheden en/of culturele conflicten. ■ Een partij gebruikt het contract om de ander partij te benadelen. ■ Verlies van het strategische perspectief, focussen op operationele problemen.

5.12.11 Risico’s ■ Gebrek aan: •

Betrokkenheid van de business bij het leveranciersmanagementproces.

•

Betrokkenheid van het hogere management bij het leveranciersmanagementproces.

•

Geschikte informatie over de toekomstige plannen en strategieën van de business.

•

Middelen en/of budget voor het leveranciersmanagementproces.

•

Bekendheid en integratie van de leverancier met servicemanagementprocessen, beleidsregels en procedures van de serviceprovider.

■ Uit het verleden afkomstige of slecht geschreven (onduidelijke afspraken) contracten.

■ Leveranciers falen of zijn niet in staat te voldoen aan de voorwaarden van het contract.

■ Cultuurbotsingen tussen serviceprovider en leverancier. ■ Leveranciers die niet-coöperatief/onwillig zijn in het ondersteunen van het leveranciersmanagementproces.

■ Leveranciers worden overgenomen en relaties, personeel en contracten wijzigen.

■ Excessieve en bureaucratische eisen.

■ 5.13 ORGANISATIE 5.13.1 Rollen en verantwoordelijkheden Goed presterende organisaties kunnen snel en accuraat tot de juiste beslissingen komen en die met succes uitvoeren. Om dat te bereiken is het cruciaal dat de rollen en verantwoordelijkheden helder zijn vastgelegd. Dit is ook essentieel in de serviceontwerpfase. Een van de mogelijke modellen die in dit opzicht behulpzaam kan zijn, is het al eerder in hoofdstuk 2 besproken RACI-model.

Vaardigheden Ondanks het feit dat elke functie bepaalde kennis en vaardigheden met zich meebrengt (zie: ‘Rollen’ hieronder), moet de verantwoordelijke persoon:

■ Zich bewust zijn van de zakelijke prioriteiten en doelstellingen. ■ Zich bewust zijn van de rol die IT speelt. ■ Beschikken over klantenservicevaardigheden. ■ Zich bewust zijn van wat IT de klant kan bieden. ■ De vaardigheden en kennis hebben die nodig zijn om de functie goed uit te voeren.

■ In staat zijn goede praktijkbeleidsregels en -procedures te gebruiken, begrijpen en interpreteren om te zorgen dat die worden opgevolgd.

Rollen Deze paragraaf bevat een beschrijving van de rollen en verantwoordelijkheden voor de belangrijkste functies in de serviceontwerpfase. Afhankelijk van de grootte van organisaties kunnen deze rollen worden gecombineerd. De belangrijkste rollen zijn:

■ De proceseigenaar is ervoor verantwoordelijk dat het proces wordt doorgevoerd zoals afgesproken en dat de vastgestelde doelstellingen zodoende worden bereikt. Taken zijn: •

Documenteren en vastleggen van het proces.

•

De KPI’s formuleren en waar nodig aanpassen.

•

De effectiviteit en efficiëntie van het proces verbeteren.

•

Input leveren voor het serviceverbeterplan.

•

Het proces, de rollen en verantwoordelijkheden evalueren.

■ De serviceontwerpmanager is verantwoordelijk voor de algehele coördinatie en het aanleveren van de serviceontwerpen. Taken zijn onder andere: •

Ervoor zorgen dat de ontwerpactiviteiten binnen de serviceontwerpfase in lijn zijn met de servicestrategie en dat de ontwerpen voldoen aan de vastgestelde eisen.

•

Ervoor zorgen dat de functionele aspecten van de services worden ontworpen.

•

Ervoor zorgen dat de ontwerpdocumentatie wordt geproduceerd en onderhouden.

•

De effectiviteit en efficiëntie van het ontwerpproces beoordelen.

■ De servicecatalogusmanager is verantwoordelijk voor de productie en het onderhoud van de servicecatalogus. Daarnaast moet de servicecatalogusmanager: •

Zorgen dat de services worden vastgelegd in de servicecatalogus.

•

Zorgen dat de opgenomen informatie actueel is en consistent met de informatie in de serviceportfolio.

•

Zorgen dat de servicecatalogus beveiligd is en dat er back-ups zijn.

■ De servicelevelmanager heeft als belangrijkste verantwoordelijkheden om: •

Inzicht te hebben in de wijzigende eisen van de klant en de markt.

•

Te zorgen dat de bestaande en toekomstige eisen van de klanten zijn geïdentificeerd.

•

Te onderhandelen en overeenkomsten aan te gaan over de levering van services.

•

Te assisteren in de productie en het onderhoud van een accurate serviceportfolio.

•

Te zorgen dat de doelstellingen die zijn bekrachtigd in onderliggende contracten worden afgestemd op de SLA.

■ De availabiltymanager is er verantwoordelijk voor om: •

te zorgen dat de bestaande services beschikbaar zijn zoals overeengekomen;

•

te assisteren in het onderzoek en de diagnose van alle incidenten en problemen;

•

bij te dragen aan het ontwerp van de IT-infrastructuur;

•

de beschikbaarheid van services proactief te verbeteren.

■ De information security manager heeft als belangrijkste taken om: •

Het information security-beleid te ontwerpen en te onderhouden.

•

Te communiceren met de betrokken partijen over zaken die te maken hebben met het securitybeleid.

•

Te assisteren bij de businessimpactanalyse.

•

Risicoanalyses en risicomanagement uit te voeren samen met availabilitymanagement en ITSCM.

Daarnaast zijn er nog de volgende verantwoordelijke functies te herkennen in deze fase:

■ IT-planner. ■ IT-ontwerper/architect. ■ Servicecontinuïteitsmanager. ■ Capaciteitsmanager. ■ Leveranciersmanager.

■ 5.14 METHODEN, TECHNIEKEN EN TOOLS 5.14.1 Technologische afwegingen Het is zeer belangrijk dat iemand zorgt dat tools worden gebruikt om processen te ondersteunen en niet andersom. Er zijn verschillende tools en technieken die kunnen worden gebruikt om het ontwerpen van services en

componenten te ondersteunen. Deze maken niet alleen het ontwerpen van de hardware en software mogelijk, maar ook de ontwikkeling van omgevings-, proces- en dataontwerpen. Gebruikmaken van de grote variatie in tools en technieken heeft de volgende voordelen:

■ Bereiken van snelheid in het ontwerpproces. ■ Naleving van standaardnormen. ■ De ontwikkeling van prototypen en modellen. ■ Rekening houden met diverse scenario’s (wat als…?) Het ontwerpproces kan worden vereenvoudigd door gebruik te maken van tools die de service en de bijbehorende componenten grafisch kunnen weergeven. Als de tool ook financiële informatie omvat en gekoppeld is aan de ‘metricsboom’, kan de service worden bewaakt en gemanaged in alle fasen van de levenscyclus.

Deze tools faciliteren niet alleen het ontwerpproces, zij ondersteunen alle fasen in de servicelevenscyclus, waaronder:

■ Het managen van alle niveaus van de servicelevenscyclus. ■ Alle aspecten van de service en serviceprestaties. ■ Kostenbeheer. ■ Het managen van de serviceportfolio en servicecatalogus. ■ Een configuratiemanagementsysteem (CMS) en een servicekennismanagementsysteem (SKMS).

De volgende generieke activiteiten moeten worden uitgevoerd:

■ Zorgen dat er een generieke levenscyclus is voor IT-middelen. ■ Formaliseren van de relaties tussen verschillende soorten IT-middelen. ■ De rollen en verantwoordelijkheden vastleggen. ■ Uitvoeren van studies om de totale kosten van eigenaarschap (TCO, Total Cost of Ownership) van een IT-service inzichtelijk te maken.

Voor applicatie-assets komt daar nog bij:

■ Een acquisitiestrategie voor IT-middelen vastleggen en analyseren hoe die kan worden gesynchroniseerd met zowel de IT- als de bedrijfsstrategie.

■ De rol documenteren die de applicatie speelt in de levering van IT-services.

■ Standaardnormen bepalen voor het gebruik van verschillende applicatieontwerpmethoden.

Voor informatie-assets kan nog worden toegevoegd:

■ Zorgen dat dataontwerpen zijn gemaakt in het licht van: •

het belang van standaardisatie;

•

de noodzaak van kwalitatief waardevolle data;

•

de waarde van data voor de organisatie.

Voor IT-infrastructuurassets kan worden toegevoegd:

■ Vaststellen van standaardnormen voor de acquisitie en het managen van ITen omgevingsinfrastructuur (elektriciteit, ruimte, middleware, databasesystemen enzovoort).

■ Activiteiten bepalen voor het optimale gebruik van de ITinfrastructuuractiva.

■ De noodzaak van tools specificeren en beschrijven hoe die zullen worden gebruikt.

Voor de immateriële middelen kan worden toegevoegd:

■ Formaliseren hoe competenties als bedrijfsmiddel moeten worden beschouwd in de organisatie.

■ Zorgen dat de competenties zijn gedocumenteerd. Om de interfaces en afhankelijkheden vast te stellen kan het volgende worden toegevoegd:

■ Formaliseren van de interfaces die de acquisitie en het beheer van ITmiddelen hebben met functies en processen buiten de IT-sfeer.

■ Formaliseren van kwaliteitscontrole in de acquisitie en het beheer van ITmiddelen.

5.14.2 Servicemanagementtools In de uitvoering van taken in IT-servicemanagement kunnen talloze geautomatiseerde, ondersteunende hulpmiddelen worden gebruikt: deze worden aangeduid als

tools. Met behulp van deze tools, kunnen beheertaken

worden geautomatiseerd, bijvoorbeeld bewakingstaken of softwaredistributietaken.

Het feit dat de IT-sector in beginsel is gericht op geautomatiseerde voorzieningen (voor informatieverwerking) heeft geleid tot een ware stortvloed van tools op de markt, die het prestatievermogen van de ITorganisaties sterk heeft opgevoerd.

Tools helpen ervoor te zorgen dat serviceontwerpprocessen effectief kunnen functioneren. Ze verbeteren de efficiëntie en bieden waardevolle managementinformatie voor het vaststellen van mogelijk zwakke punten. Het voordeel op langere termijn is dat het gebruik van tools helpt om de kosten te verlagen en productiviteit te verhogen, in het belang van de verbetering van de kwaliteit van IT-servicelevering. Bovendien maakt het gebruik van tools de centralisatie van essentiële processen en ook de automatisering en integratie van de ‘kern’-servicemanagementprocessen mogelijk.

Afwegingen in de evaluatie van servicemanagementtools zijn onder andere:

■ Datastructuur, -verwerking en -integratie. ■ Conformiteit met internationale standaarden. ■ Flexibiliteit in implementatie, gebruik en delen van data. ■ Ondersteuning in het bewaken van servicelevels. De tool dient om het proces te ondersteunen en niet andersom. Het is aan te bevelen een compleet geïntegreerde tool aan te schaffen, die veel servicemanagementprocessen ondersteunt. Als dat niet mogelijk is, moeten de interfaces tussen de verschillende tools in ogenschouw worden genomen. Het is aan te raden tijdens het selectieproces te werken met een programma van eisen (SoR, Statement of Requirements). De eisen moeten worden afgewogen volgens de MoSCoW -analyse:

■ M – (must have) moet. ■ S – (should have) zou moeten. ■ C – (could have) zou kunnen. ■ W – (would have) nu niet nodig, maar wellicht in de toekomst. De tool moet flexibel zijn zodat deze individuele toegangsrechten kan ondersteunen. Het is nodig te bepalen wie toegang heeft tot de data en met welk doel. Daarnaast moet worden beslist op welk platform de tool kan werken. Bij de eerste afweging is het verstandig de kredietwaardigheid van de

leverancier te controleren en na te gaan of deze ondersteuning biedt (training) voor een aantal maanden of jaren. In dit proces is het belangrijk te bedenken dat een oplossing bijna nooit 100 procent aan de eisen voldoet. De 80/20regel is wellicht realistischer in dit kader. Met andere woorden, de tool zal hooguit aan 80 procent van de vastgestelde eisen voldoen.

■ 5.15 IMPLEMENTATIE-AFWEGINGEN In deze paragraaf worden de implementatie-afwegingen voor serviceontwerp besproken. Daarnaast komen de interfaces van serviceontwerp met andere fasen van de servicelevenscyclus aan de orde.

5.15.1 Businessimpactanalyse De businessimpactanalyse (BIA) is een waardevolle informatiebron voor het vaststellen van klantenbehoeften en de impact en het risico van een service. De BIA is een essentieel element in het bedrijfscontinuïteitsproces en dicteert de te volgen strategie voor risicovermindering en herstel na een serieus incident. De BIA bestaat uit twee delen: aan de ene kant een onderzoek naar de impact van het verlies van een bedrijfsproces of -functie, aan de andere kant het stoppen van het effect van dat verlies.

5.15.2 Implementatie van serviceontwerp De processen, het beleid en de architectuur voor het ontwerpen van ITservices, zoals beschreven in dit boek, moet worden gedocumenteerd en gebruikt om goede IT-services te ontwerpen en implementeren. In principe is het raadzaam om alle processen tegelijkertijd te implementeren, omdat alle processen met elkaar in verband staan en vaak ook van elkaar afhankelijk zijn. Uiteindelijk is een geïntegreerde verzameling processen nodig die IT-services kunnen beheren en overzien gedurende hun gehele leven scyclus. Omdat organisaties zelden alles tegelijkertijd kunnen doorvoeren, moet het proces waaraan de grootste behoefte bestaat als eerste worden opgezet, met het besef dat alle processen met elkaar zijn verbonden. Daarnaast hangt het ook af van de ontwikkeling van het IT-servicemanagement van de organisatie. De implementatieprioriteiten moeten corresponderen met de doelstellingen van het serviceverbeterplan (Service Improvement Plan, SIP).

5.15.3 Randvoorwaarden Er zijn verschillende randvoorwaarden voor nieuwe of aangepaste processen. Vaak zijn dit randvoorwaarden van andere processen. Bijvoorbeeld, voordat servicelevelmanagement (SLM) de servicelevelovereenkomst (SLA) kan ontwerpen, zijn een bedrijfsservicecatalogus en een overzicht van de technische/ondersteunende services in de servicecatalogus noodzakelijk. Problemmanagement is afhankelijk van een volgroeid incidentmanagementproces. Deze zaken omvatten veel meer dan alleen ITSM: availability- en capaciteitsmanagement hebben informatie nodig van het bedrijfsplan. Er zijn meer van deze voorbeelden die eerst moeten worden bekeken voor een hoge mate van volwassenheid in procesgroei kan worden bereikt.

5.15.4 Kritieke succesfactoren De cruciale succesfactoren, die door de tijd heen veranderen, voor de serviceontwerpfase omvatten het volgende:

■ Ondersteuning door het management. ■ Ondersteuning vanuit de business. ■ Inhuren en behouden van goede medewerkers. ■ Servicemanagementtraining. ■ Adequate tooling. ■ Validiteit van het testen. ■ Meten en rapporteren.

5.15.5 KPI’s voor serviceontwerp ■ Percentage van de eisenspecificaties van serviceontwerp dat op tijd wordt geproduceerd.

■ Percentage van de eisenspecificaties van serviceontwerp dat binnen het budget wordt geproduceerd.

■ Percentage van serviceontwerp dat op tijd wordt geproduceerd. ■ Accuraatheid van serviceontwerp. ■ Accuraatheid van de SLA, OLA en overige contracten.

5.15.6 Uitdagingen ■ De noodzaak van afstemming van bestaande architectuur, strategie en beleid.

■ Het gebruik van verschillende technieken en applicaties. ■ Onduidelijkheid over gewijzigde klantbehoeften. ■ Gebrek aan bewustzijn en kennis van servicelevering. ■ Weerstand tegen systematisch werken. ■ Inefficiënt gebruik van middelen.

5.15.7 Risico’s ■ Als het volwassenheidsniveau van één van de processen laag is, is het onmogelijk een hoog ontwikkelingsniveau te bereiken in andere processen.

■ Bedrijfseisen zijn niet helder voor het IT-personeel. ■ Aan serviceontwerp wordt te weinig tijd toegekend. ■ De afstemming tussen infrastructuur, klant en partners is niet goed, wat betekent dat niet aan de eisen kan worden voldaan.

■ De serviceontwerpfase is niet duidelijk of als geheel niet aanwezig.

5.15.8 Interfaces met andere fasen in de levenscyclus Alle activiteiten in de serviceontwerpfase komen voort uit de behoeften en eisen van de klant en zijn ook een weerslag van de strategie, de plannen en het beleid zoals die zijn ontwikkeld de eerste fase van de levenscyclus: de servicestrategie.

De serviceontwerpfase in de levenscyclus begint met de nieuwe of gewijzigde behoeften van de klant. Uiteindelijk, tegen het einde van het ontwerpproces, moet een serviceoplossing zijn ontworpen die voldoet aan die behoeften voordat het servicetransitieproces begint op basis van het serviceontwerppakket. In de servicetransitiefase zal de service worden geëvalueerd, gestructureerd, getest en na het uitrollen wordt de implementatie overgedragen aan serviceproductie.

De uitvoer van elke fase vormt de input service voor de volgende fase in de levenscyclus. Zo levert servicestrategie belangrijke input aan serviceontwerp, dat op zijn beurt invoer levert aan de servicetransitiefase.

De serviceportfolio levert informatie aan elk proces in elke fase van de levenscyclus. In dit opzicht is de portfolio de ruggengraat van de servicelevenscyclus. De serviceportfolio moet een component zijn van het

servicekennismanagementsysteem en als document zijn opgenomen in het configuratiemanagementsysteem. Dit wordt uitgebreid beschreven in hoofdstuk 6 ‘Servicetransitie’.

■ 6.1 INLEIDING TOT SERVICETRANSITIE In dit hoofdstuk wordt besproken hoe de specificaties van serviceontwerp effectief kunnen worden omgezet in een nieuwe of gewijzigde service. Een effectieve servicetransitie zorgt ervoor dat de nieuwe of gewijzigde services beter zijn afgestemd op de bedrijfsvoering van de klant. In het bijzonder:

■ Het vermogen van de business om snel en adequaat te reageren op wijzigingen in de markt.

■ Het goed kunnen managen van wijzigingen (changes) in de organisatie als gevolg van overnames, contracten enzovoort.

■ Meer succesvolle changes en releases voor de business. ■ Betere naleving van de geldende bedrijfsregels. ■ Minder afwijkingen tussen geplande budgetten en de daadwerkelijke kosten. ■ Beter inzicht in de mogelijke risico’s tijdens en na de invoering van een service.

■ Hogere productiviteit van het personeel van de klant. De zeven processen in de servicetransitiefase zijn (zie ook afbeelding 6.0): 1. Transitieplanning en -ondersteuning. 2. Changemanagement. 3. Serviceasset- en configuratiemanagement. 4. Release & deployment management. 5. Service validation & testing. 6. Change evaluation. 7. Kennismanagement.

6.1.1 Doel en doelstellingen Het doel van servicetransitie is het zekerstellen dat nieuwe, gewijzigde of uit te faseren services aan de verwachtingen van de business voldoen, zoals die

gedocumenteerd zijn in onder andere het servicecharter en het serviceontwerppakket tijdens de servicestrategie en de serviceontwerpfasen van de levenscyclus.

Afbeelding 6.0 De zeven processen van servicetransitie gekoppeld aan de ITILlevenscyclus De

doelstellingen van servicetransitie zijn onder andere:

■ Servicewijzigingen op een efficiënte en effectieve wijze plannen en managen.

■ Het managen van de risico’s die verbonden zijn aan de nieuwe, gewijzigde of uit te faseren services.

■ Service releases succesvol uitrollen in de productieomgevingen. ■ Correcte verwachtingen weten te creëren met betrekking tot de performance en het gebruik van nieuwe of gewijzigde services.

■ Zekerstellen dat de servicewijzigingen de verwachte waarde voor de business opleveren.

■ Verschaffen van hoogwaardige kennis en informatie over services en serviceassets.

6.1.2 Bereik

ITIL formuleert het

bereik van servicetransitie als volgt:

Servicetransitie omvat het managen en coördineren van de processen, systemen en functies die nodig zijn voor het samenstellen, bouwen, testen en het uitrollen van een release naar de productieomgeving. Servicetransitie bestaat gewoonlijk uit de volgende stappen:

■ Planning en voorbereiding. ■ Bouwen en testen. ■ Eventuele pilots. ■ Plannen en voorbereiden van de uitrol. ■ Uitrol en overdracht. ■ Evaluatie en afsluiting van servicetransitie. Changemanagement, serviceasset- & configuratiemanagement en kennismanagement ondersteunen alle fasen van de levenscyclus. Men heeft de keuze gemaakt om deze processen in het boek ITIL Servicetransitie onder te brengen. De processen release & deploymentmanagement, servicevalidation & testing en change evaluation daarentegen vallen volledig binnen het bereik van de fase servicetransitie.

■ 6.2 BASISBEGRIPPEN De volgende beleidsregels zijn belangrijk voor een effectieve servicetransitie en gelden voor elke organisatie. Ze moeten nog wel worden aangepast aan de omstandigheden, die per organisatie verschillen:

■ Richtlijnen en procedures voor servicetransitie formuleren en invoeren. ■ Alle wijzigingen altijd via servicetransitie doorvoeren. ■ Frameworks en standaarden gebruiken. ■ Bestaande processen en systemen hergebruiken. ■ Servicetransitieplannen afstemmen op de behoeften van de business. ■ Relaties met stakeholders tot stand brengen en onderhouden. ■ Effectieve ‘controles’ opzetten. ■ Systemen leveren voor kennisoverdracht en voor de ondersteuning van besluitvorming.

■ Plannen van releases en distributie packages. ■ Anticiperen op wijzigingen en de richting ervan managen. ■ Betrokkenheid in een vroeg stadium van de servicelevenscyclus verzekeren. ■ De kwaliteit van een nieuwe of gewijzigde service bewaken. ■ Proactief verbeteren van de kwaliteit van een service tijdens een servicetransitie.

■ 6.3 TRANSITIEPLANNING EN -ONDERSTEUNING 6.3.1 Inleiding Het doel van transitieplanning en -ondersteuning is het verschaffen van een overallplanning voor de transitie van services en de coördinatie van alle resources die daarvoor nodig zijn.

De

doelstellingen van transitieplanning en -ondersteuning omvatten:

■ Waar nodig het coördineren van activiteiten over alle projecten, leveranciers en serviceteams heen.

■ Nieuwe of gewijzigde services invoeren binnen budget, met de vereiste kwaliteit en binnen de beschikbare tijd.

■ Nieuwe of veranderde managementinformatiesystemen, processen, meetmethoden en metrics kunnen invoeren.

Afbeelding 6.1 Het bereik van servicetransitie (Bron: AXELOS)

■ Plannen uitwerken die de klant en de business in staat stellen hun activiteiten in lijn te brengen met de plannen voor de transitie van services.

■ Identificeren, managen en controleren van risico’s. Bereik De volgende activiteiten vallen binnen het bereik van transitieplanning:

■ Onderhouden van richtlijnen (beleid), standaarden en modellen voor de servicetransitie-activiteiten en -processen.

■ Begeleiding van alle nieuwe en te wijzigen services door alle processen heen. ■ Coördinatie van alle inspanningen, die nodig zijn om meerdere transities in dezelfde tijdsperiode te kunnen managen.

■ Het maken van budgetten en resourceplanningen ten behoeve van toekomstige transitie-activiteiten.

■ Bewaken en verbeteren van de servicetransitieprestaties. ■ Afstemming van servicetransitie-activiteiten met programma- en projectmanagement, serviceontwerp en serviceontwikkelingsactiviteiten.

Waarde voor de business Een geïntegreerde methode voor planning verbetert de afstemming van transitieplannen met de klant, serviceprovider, business en de wijzigingsprojectplannen.

Basisbegrippen Transitieplanning en -ondersteuning dient zorg te dragen voor

releaserichtlijnen en -beleidsregels.Hierin komen de volgende onderwerpen aan de orde:

■ Naamconventies, waarmee releasesoorten worden onderscheiden, zoals: grote (major) release , kleine (minor) release en nood (emergency) release . ■ Rollen en verantwoordelijkheden – veel mensen van verschillende (IT-)organisaties kunnen betrokken zijn bij een release. In dit geval is het nuttig een verantwoordelijkhedenmatrix op te zetten.

■ Releasefrequentie, de verwachte frequentie voor elk type release. ■ Methode voor het accepteren en groeperen van wijzigingen in en tot een release.

■ Hoe de configuratiebaseline voor de release wordt vastgesteld en geverifieerd tegenover de feitelijke release-inhoud, bestaande uit hardware, software, documentatie en kennis.

■ Aanvangs- en exitcriteria en autoriteit voor acceptatie van de release in elk servicetransitiefase en in de gecontroleerde test-, trainings-, calamiteitenherstel- en productieomgeving(en).

■ De geautoriseerde criteria voor het verlaten van Early Life Support (ELS) en het overdragen aan serviceproductie.

6.3.2 Activiteiten, methoden en technieken De activiteiten voor planning en ondersteuning zijn: 1. Opstellen van een transitiestrategie. 2. Servicetransitie voorbereiden. 3. Servicetransitie plannen en coördineren. 4. Ondersteunen transitieproces.

1. Opstellen van een transitiestrategie

De transitiestrategie bepaalt de overallmethode voor het organiseren van de service-transitie en het toewijzen van resources. Aspecten die in de transitiestrategie aan de orde kunnen komen, zijn:

■ Missie, doelen en doelstellingen. ■ Context en bereik. ■ Toepasselijke standaarden, overeenkomsten, wet- en regelgeving en contractuele verplichtingen.

■ Organisaties en stakeholders die betrokken zijn bij de servicetransitie. ■ Framework voor servicetransitie. ■ Criteria voor succes en falen. ■ Mensen: rollen en verantwoordelijkheden. ■ Methode inclusief transitiemodel, plannen voor het beheren van wijzigingen, activa, configuraties en kennis; transitieschatting; voorbereiding; evaluatie; storingsafhandeling; KPI’s.

■ De producten (deliverables) die het resultaat zijn van de transitie-activiteiten zoals transitieplannen, schema van mijlpalen, financiële vereisten.

Het serviceontwerppakket (service design package, SDP) formuleert de verschillende fasen van servicetransitie. Deze kunnen bestaan uit: verwerven en testen van componenten, testen van de servicerelease, serviceproductie gereedheidtest, uitrol, early life support (ELS), evaluatie en afsluiten van servicetransitie.

2. Servicetransitie voorbereiden Voorbereidende activiteiten bestaan uit:

■ Beoordeling en acceptatie van invoer vanuit andere fasen van de servicelevenscyclus, beoordeling en controle van de in te voeren deliverables zoals het serviceontwerppakket (SDP), serviceacceptatiecriteria (SAC) en evaluatierapport.

■ Identificeren, oppakken en plannen van het wijzigingsverzoek (RfC, Request for Change).

■ Controles van de configuratiebaselines die zijn vastgelegd in configuratiemanagement voor de start van servicetransitie.

■ Controleren of zowel de klant als de IT-organisatie gereed is voor de transitie.

3. Servicetransitie plannen en coördineren Een servicetransitieplan beschrijft de taken en activiteiten die vereist zijn om een release uit te geven en uit te rollen in de testomgevingen en in productie, inclusief:

■ Werkomgeving en infrastructuur. ■ Plannen van mijlpalen. ■ Uit te voeren activiteiten en taken. ■ Personeel, middelenvereisten, budget en tijdschema per stadium. ■ Levertijden en noodvoorzieningen. Goed

geïntegreerde planning en coördinatie

zijn essentieel om een release

over verschillende omgevingen en locaties succesvol in productie te brengen. Er moet een

geïntegreerde verzameling transitieplannen worden

onderhouden die is gekoppeld aan plannen op lager niveau zoals release-, bouw- en testplannen.

Het is een best practice om verschillende releases in een managen, waarbij elke belangrijke uitrol

programma te

projectmatig wordt uitgevoerd.

Kwaliteitsbeoordelingen moeten worden doorgevoerd voor alle servicetransitie-, release- en uitrolplannen. Vragen die kunnen worden gesteld zijn:

■ Zijn de servicetransitie- en releaseplannen bijgewerkt, geautoriseerd en zijn de releasedatums bekend?

■ Is er rekening gehouden met risico’s gerelateerd aan impact op kosten, organisatie en technologie?

■ Zijn nieuwe configuratie-items (CI’s) compatibel met elkaar en met configuratie-items in de bedoelde omgeving?

■ Zijn de mensen die met IT moeten werken voldoende getraind? ■ Is er rekening gehouden met potentiële wijzigingen in de bedrijfsomgeving? 4. Ondersteuning vanuit het transitieproces Servicetransitie adviseert en ondersteunt alle stakeholders. Het plannings- en ondersteuningsteam biedt stakeholders inzicht in de servicetransitieprocessen en ondersteunende systemen en tools. Daarnaast zal het team de wijzigingen, werkopdrachten, problemen, risico’s, communicatie en uitrol

managen/administreren. Het team houdt ook stakeholders op de hoogte wat betreft de planning en het proces.

Ten slotte worden de servicetransitieactiviteiten

bewaakt: de implementatie

van activiteiten wordt vergeleken met hoe deze waren bedoeld (zoals geformuleerd in het transitieplan en -model).

Fasen van de servicetransitielevenscyclus In de service design package (SDP) zou onder andere beschreven moeten zijn welke fasen de service doorloopt gedurende de transitie naar de productieomgeving. De overgang van de ene fase naar de andere dient vanuit het changemanagementproces onderworpen te worden aan formele controles. Fasen die onderkend kunnen worden tijdens de transitie zijn:

■ Verwerven en testen van nieuwe componenten. ■ Bouwen en testen. ■ Testen van de servicerelease. ■ Testen of de service gereed is voor operationele toepassing. ■ Uitrol. ■ Early Life Support (ELS). ■ Evaluatie en afsluiting van servicetransitie.

6.3.3 Informatiemanagement ■ Het proces van transitieplanning en -ondersteuning maakt zwaar gebruik van het kennismanagementsysteem voor services om toegang te bieden tot alle informatie die nodig is voor de korte-, middel- en langetermijnplanning.

6.3.4 Interfaces Zoals alle processen heeft het proces transitieplanning en -ondersteuning relaties met andere processen. De meest zichtbare relaties zijn, maar niet uitsluitend:

■ Demandmanagement – Om te voorzien in informatie over te verwachten behoefte aan middelen op de lange termijn.

■ Serviceportfoliomanagementproces – Om transitieplanning en – ondersteuning te betrekken en input te leveren voor de planning en besluitvorming daarvan. Voor wijzigingsvoorstellen om

langetermijnplanningen te triggeren binnen transitieplanning en ondersteuning.

■ Klantrelatiebeheer – Om ervoor te zorgen dat communicatie met klanten goed (in twee richtingen) verloopt.

■ Serviceontwerpfase – In de vorm van een serviceontwerppakket. ■ Leveranciersmanagement – Om tijdens servicetransitie te zorgen dat er goede contracten zijn.

■ Servicetransitiefase

– Alle processen in deze fase worden gecoördineerd

door transitieplanning en -ondersteuning.

■ Pilots, overdracht en Early Life Support (ELS) – Deze zijn te coördineren met de serviceproductiefuncties.

■ Verschillende groepen binnen de organisatie

– Om te voorzien in het

personeel dat nodig is voor het uitvoeren van veel aspecten van servicetransitie.

6.3.5 Aanleidingen (triggers) ■ Voor de planning van een enkele transitie: een geautoriseerde wijziging. ■ Langetermijnplanning: ontvangst van een wijzigingsvoorstel vanuit serviceportfoliomanagement.

■ Budgetteren voor toekomstige transitievereisten: de budgettaire planningscyclus van de organisatie.

6.3.6 Invoer ■ Serviceontwerppakket (service design package). ■ Serviceontwerp. ■ Wijzigingsvoorstel. ■ Geautoriseerde wijziging. 6.3.7 Uitvoer ■ Transitiestrategie en -budget. ■ Geïntegreerde verzameling servicetransitieplannen. 6.3.8 Kritieke succesfactoren ■ Het kunnen managen van de wisselwerking tussen kosten, kwaliteit en tijd. ■ Effectieve communicatie met stakeholders. ■ Identificeren en beheren van risico’s van fouten en verstoring.

■ Coördineren van activiteiten van meerdere betrokken processen in elke transitie.

■ Beheren van strijdige behoeften aan gedeelde resources.

6.3.9 Metrics ■ Stijging in: •

Het aantal doorgevoerde releases dat voldoet aan de afgestemde eisen van de klant in termen van kosten, kwaliteit, bereik en overeengekomen releaseschema.

•

Klant- en gebruikerstevredenheid.

•

Tevredenheid van het project- en serviceteam.

■ Verbeterde: •

Verbeterde cijfers wat betreft het aantal succesvolle servicetransities.

•

Efficiëntie en effectiviteit van de processen en ondersteunende systemen.

■ Daling in: •

Aantal bedrijfsverstoringen.

•

Aantal problemen, risico’s en vertragingen.

•

Het verschil tussen de werkelijke geleverde kwaliteit, gemaakte kosten en bestede tijd versus de voorspelde.

•

Tijd en middelen voor het ontwikkelen en onderhouden van geïntegreerde plannen en coördinatie-activiteiten

•

Aantal problemen veroorzaakt door strijdige behoeften aan gedeelde resources.

6.3.10 Uitdagingen ■ Opbouwen van de relaties die nodig zijn om de vele stakeholders te managen en coördineren.

■ Coördineren en prioriteren van de vele nieuwe of gewijzigde services die naast elkaar bestaan.

■ De risico’s en issues van elk project begrijpen om de resourceplanning proactief te kunnen managen.

6.3.11 Risico’s ■ Gebrek aan informatie vanuit demandmanagement en serviceportfoliomanagement.

■ Slechte relaties met projecten en programma’s.

■ Vertragingen in een transitie heeft gevolgen voor toekomstige transities vanwege beperkte middelen.

■ Ontoereikende informatie voor het aanpakken van conflicten.

■ 6.4 CHANGEMANAGEMENT 6.4.1 Inleiding Het doorvoeren van wijzigingen heeft altijd een reden. We onderscheiden daarbij proactieve en reactieve redenen. Voorbeelden van een proactieve reden zijn kostenreductie en serviceverbetering. Voorbeelden van reactieve redenen zijn het oplossen van verstoringen en het aanpassen van de service aan een veranderende omgeving.

Het

doel van changemanagement is om van de hele levenscyclus van

wijzigingen te beheersen. Ze zorgt ervoor dat bij het doorvoeren van wijzigingen de verstoringen en onderbrekingen van de serviceverlening minimaal zijn.

De

doelstellingen van changemanagement zijn:

■ In staat zijn te reageren op veranderende eisen van de business. ■ In staat zijn zodanig te reageren op wijzigingsverzoeken (change requests) vanuit de business en de IT, dat de services in lijn komen met de behoeften van de business.

■ Zekerstellen dat wijzigingen op een gecontroleerde wijze geregistreerd en vervolgens geëvalueerd, geautoriseerd, geprioriteerd, gepland, getest, geïmplementeerd, gedocumenteerd en gecontroleerd worden

■ Zekerstellen dat alle wijzingen op CI’ s worden opgenomen in het CMS. ■ Optimaliseren van de overall businessrisico’s Het changemanagementproces moet:

■ Gestandaardiseerde methoden en procedures gebruiken. ■ Alle wijzigingen in de CMDB vastleggen. ■ Rekening houden met risico’s voor de business. Beleidsregels voor het ondersteunen van changemanagement zijn:

■ Zorgen voor een cultuur waarin niet-geautoriseerde wijzigingen niet worden getolereerd.

■ Het changemanagementproces afstemmen op andere changeprocessen in de organisatie.

■ Effectieve prioritering, dat wil zeggen innovatieve versus preventieve versus opsporende versus correctieve wijzigingen.

■ Aansprakelijkheid en verantwoordelijkheid voor wijzigingen voor de gehele levenscyclus bepalen.

■ Zorgen voor een centraal aanspreekpunt voor wijzigingen. ■ Zorgen voor integratie met andere servicemanagementprocessen. ■ ‘Changevensters’, prestatie- en risicoanalyses, prestatiemetingen opzetten. Bereik Het bereik van changemanagement omvat wijzigingen aan de baselines van serviceassets en CI’s over de gehele servicelevenscyclus. In paragraaf 6.5 ‘Serviceasset- en configuratiemanagement’ wordt uitgebreider op dit onderwerp ingegaan.

Elke organisatie moet voor zichzelf bepalen welke wijzigingen het changemanagementproces oppakt en welke niet. Het vervangen van een defecte harde schijf van een pc zou bijvoorbeeld buiten het changemanagementproces kunnen vallen.

Afbeelding 6.2 toont het bereik van het changemanagementproces en de interfaces van het proces met de business op strategisch, tactisch en operationeel niveau.

Afbeelding 6.2 Het bereik van changemanagement (Bron: AXELOS)

Waarde voor de business Wijzigingen in de service en infrastructuur kunnen een negatieve impact hebben op de business. Ze kunnen leiden tot verstoringen van de services en vertragingen bij het vaststellen van bedrijfsbehoeften. Maar een goed uitgevoerd changemanagementproces stelt de serviceproviders in staat waarde toe te voegen aan de business, bijvoorbeeld:

■ Wijzigingen die financiële regelgeving betreffen, zoals SOx, of andere regels van goed bestuur (governance).

■ Tijdige implementatie van wijzigingen zodat de deadlines van de business worden gehaald.

■ Verlaging van het aantal mislukte wijzigingen waardoor het aantal verstoringen van de serviceverlening afneemt.

■ Prioriteren van wijzigingen en reageren op change requests van de klant. ■ Verkorten van de gemiddelde tijd benodigd om services te herstellen (MTRS).

Door de vergrote afhankelijkheid van IT-services en omdat de onderliggende informatietechnologie zo complex is geworden, kunnen belangrijke

efficiëntievoordelen alleen worden gerealiseerd door middel van goed gestructureerde en geplande wijzigingen en releases. Indicatoren van onzorgvuldig changemanagement zijn:

■ Niet-geautoriseerde wijzigingen. ■ Ongeplande uitval. ■ Geïmplementeerde wijzigingen zijn weinig succesvol. ■ Hoog aantal noodwijzigingen (emergency changes). ■ Vertraagde projectimplementaties. Beleidsregels Beleidsregels voor het ondersteunen van changemanagement zijn:

■ Zorgen voor een cultuur waarin niet-geautoriseerde wijzigingen niet worden getolereerd.

■ Het changemanagementproces afstemmen op andere changeprocessen in de organisatie.

■ Effectieve prioritering, dat wil zeggen innovatieve versus preventieve versus opsporende versus correctieve wijzigingen.

■ Aansprakelijkheid en verantwoordelijkheid voor wijzigingen voor de gehele levenscyclus bepalen.

■ Zorgen voor een centraal aanspreekpunt voor wijzigingen. ■ Zorgen voor integratie met andere servicemanagementprocessen. ■ Het opzetten van ‘changevensters’, prestatie- en risicoanalyses en het verrichten van prestatiemetingen.

Ontwerp en planning Het changemanagementproces wordt gepland in combinatie met release- en configuratiemanagement. Dit maakt het mogelijk de impact van wijzigingen op services en releases te beoordelen.

Onder eisen en ontwerp voor changemanagementprocessen vallen:

■ Eisen gerelateerd aan relevante wetten en regels. ■ Een methode om niet-geautoriseerde wijzigingen te elimineren. ■ Identificatie en classificatie. ■ Organisatie, rollen, verantwoordelijkheden. ■ Stakeholders. ■ Wijzigingen groeperen en onderlinge relaties bepalen.

■ Procedures. ■ Interfaces met andere servicemanagementprocessen. Basisbegrippen De ITIL-definitie van wijziging is:

Een wijziging is de toevoeging, verandering of verwijdering van een geautoriseerde, geplande of ondersteunde service of servicecomponent en de bijbehorende documentatie. De termen ‘wijzigingsvoorstel’, ‘wijzigingsrecord’ en ‘wijzigingsverzoek (RfC)’ worden vaak niet consistent gebruikt, wat tot verwarring en misvatting leidt. ITIL formuleert ze als volgt:

■ Change proposal (change- of wijzigingsvoorstel) – Een document dat een beschrijving op hoofdlijnen bevat van een mogelijke service-introductie of een significante wijziging, samen met de daarbij behorende business case en het te verwachten implementatieschema.

■ Request for Change, RfC (wijzigingsverzoek) – een formeel voorstel voor een door te voeren wijziging, met alle benodigde details.

■ Changerecord (wijzigingsrecord) – een record (in een database, gewoonlijk een onderdeel van een geïntegreerd servicemanagementpakket) met gedetailleerde informatie betreffende een wijziging. Elk changerecord documenteert de levenscyclus van een afzonderlijke wijziging.

Change advisory board (CAB) De CAB is een adviesorgaan dat op gezette tijden bijeenkomt om wijzigingen te beoordelen en om changemanagement te ondersteunen bij het prioriteren van wijzigingen. Hierin kunnen alle belangrijke stakeholder en afdelingen zijn vertegenwoordigd, waaronder:

■ Klanten. ■ Eindgebruikers. ■ Applicatieontwikkelaars. ■ Systeembeheerders. ■ Experts. ■ Servicedesk. ■ Productie. ■ Serviceprovider.

De CAB heeft een aantal onderwerpen standaard op zijn agenda staan, waaronder:

■ Niet-geautoriseerde wijzigingen. ■ Geautoriseerde wijzigingen die niet door de CAB worden behandeld. ■ RfC’s die door CAB-leden moeten worden beoordeeld. ■ Lopende of afgesloten wijzigingen. ■ Beoordeling van doorgevoerde wijzigingen. Wijzigingsvoorstellen Wijzigingsvoorstellen worden doorgegeven aan changemanagement. Dit gebeurt voorafgaand aan de opname van nieuwe of gewijzigde services in het portfolio. Deze aanpak zorgt ervoor dat mogelijke conflicten, problemen met bijvoorbeeld resources of andere problemen (incidenten) al in een vroeg stadium worden onderkend. Autorisatie van het wijzigingsvoorstel wil niet zeggen dat de wijziging ook werkelijk wordt doorgevoerd (geïmplementeerd). Het betekent dat de service in het portfolio wordt opgenomen zodat men met het ontwerpen van de service kan beginnen.

Een wijzigingsvoorstel beschrijft de wijziging op hoofdlijnen en dient als communicatiemiddel bij de verdere besluitvorming. Het wijzigingsvoorstel wordt gewoonlijk gemaakt door het serviceportfoliomanagementproces. De uiteindelijke besluitvorming over wijzigingen vindt plaats in de IT-stuurgroep of in de Raad van Bestuur.

Wijzigingsverzoeken (Request for Changes, RfC’s) Wijzigingsverzoeken zijn vaak afkomstig van de verschillende servicemanagementprocessen of komen vanuit specifieke groepen zoals klanten en leveranciers. Een wijzigingsverzoek is een formeel voorstel om een wijziging door te voeren.

Wijzigingsmodellen en werkstromen In een wijzigingsmodel (changemodel) zijn de stappen (afspraken) vastgelegd die men moet nemen om met een bepaald soort wijziging om te gaan. Dit zorgt ervoor dat alle soorten wijzigingen volgens een vooraf bepaald pad en binnen het vooraf bepaalde tijdschema afgehandeld kunnen worden.

Het wijzigingsmodel beschrijft:

■ Een stappenplan, die de te nemen stappen in chronologische volgorde beschrijft.

■ De verantwoordelijkheden. ■ Tijdschema’s en drempels voor de voltooiing. ■ Escalatieprocedures. ITIL maakt een onderscheid tussen drie typen wijzigingen:

normale

wijzigingen, noodwijzigingen en standaard wijzigingen. Normale wijzigingen Een normale wijziging wordt aangevraagd via een RfC en doorloopt het reguliere wijzigingsproces, waaronder bespreking en beoordeling in de CAB.

Noodwijzigingen Een noodwijziging is bedoeld om een (ver)storing in een IT-service, die een grote negatieve impact op de business heeft, zo snel mogelijk te verhelpen. In een dergelijke situatie is er geen tijd om de volledige CAB bijeen te roepen. In plaats daarvan wordt een subgroep van de CAB, de Emergency CAB (ECAB), bijeengeroepen. De ECAB assisteert de changemanager bij het bepalen of het echt om een noodsituatie gaat en bij de beoordeling en autorisatie van de wijziging. Ook noodwijzigingen moeten vervolgens zo veel mogelijk getest en gedocumenteerd worden.

Standaard wijzigingen (vooraf geautoriseerd) Een standaard wijziging is een wijziging van een service, of een ander configuratie-item, waarvoor de wijzigingsmethode vooraf is geautoriseerd door changemanagement. De methode om standaard wijzigingen af te handelen verloopt volgens vastgelegde procedure. Kenmerken van standaard wijzigingen zijn.

■ De taken zijn goed bekend, gedocumenteerd en hebben bewezen dat ze werken.

■ De wijzigingsautoriteit (change authority) kan de directe manager van de indiener zijn.

■ De verantwoordelijkheid voor het goedkeuren van het budget ligt gewoonlijk bij directe manager van de indiener.

■ Risico’s zijn gewoonlijk minimaal, worden goed begrepen en geaccepteerd. ■ Ze kunnen worden gebruikt als workarounds (tijdelijke oplossingen) door het incidentmanagementproces.

■ Ze kunnen worden gebruikt om servicerequests af te handelen via het request fulfillmentproces.

■ Ze kunnen worden geautomatiseerd om events af te handelen via het eventmanagementproces.

Herstelplanning Geen enkele wijziging zou moeten worden goedgekeurd zonder antwoord op de vraag: ‘wat doen we als de wijziging niet succesvol blijkt’? Een organisatie moet er namelijk altijd voor zorgen dat ze een herstel- of uitwijkmogelijkheid heeft.

Indien een wijziging resulteert in ongewenste resultaten, dan moet de wijziging worden teruggedraaid. Terugdraaien van een wijziging vindt plaats door het uitvoeren van herstelacties. Voorbeelden van herstelacties zijn: terugzetten van de vorige versie van de service of van de applicatie, het inroepen van servicecontinuïteitsplannen of het uitvoeren van andere acties om het bedrijfsproces in staat te stellen verder te gaan.

Het plan van aanpak voor het doorvoeren van een wijziging moet onder andere mijlpalen en go/no go-momenten bevatten op basis waarvan besloten kan worden of een herstelactie moet worden uitgevoerd, zodat daar dan voldoende tijd voor beschikbaar is binnen het overeengekomen changevenster.

6.4.2 Activiteiten, methoden en technieken De activiteiten van changemanagement omvatten:

■ Het plannen van wijzigingen en controle houden op de voortgang van de planning.

■ Ontwikkelen van wijzigings- en releaseschema’s. ■ Communicatie. ■ Wijzigingsbesluitvorming en -autorisatie. ■ Ervoor zorgen dat er herstelplannen zijn. ■ Meten en controleren aan de hand van de KPI’s. ■ Managementrapportage.

■ Het doorgronden (analyseren, beschrijven bediscussiëren) van de impact. ■ Continu verbeteren. De specifieke activiteiten voor afzonderlijke wijzigingen worden besproken in volgende paragrafen: 1. RfC maken en registreren. 2. Beoordelen van RfC en wijzigingsvoorstel. 3. Beoordelen en evalueren van de wijziging.

Afbeelding 6.3 Voorbeeld van een work ow van een normale wijziging (Gebaseerd op bron: AXELOS)

4. De wijziging autoriseren. 5. Updates plannen. 6. Coördineren van de implementatie van de wijziging. 7. Evaluatie en afsluiting van de wijziging.

In deze paragraaf worden de aspecten van een ‘normale’ wijziging geschetst. De algemene principes die voor alle wijzigingen gelden en de ‘normale’ wijzigingsprocedure worden aangepast wanneer het gaat om standaardwijzigingen en emergency changes.

1. RfC maken en registreren De wijziging wordt in gang gezet naar aanleiding van een verzoek van de initiatiefnemer – de persoon, groep of afdeling die de wijziging wenselijk vindt. Alle RfC’s worden geregistreerd en voorzien van een uniek identificatienummer. Hoeveel informatie nodig is hangt af van het bereik en de impact van de wijziging.

2. Beoordelen van RfC en wijzigingsvoorstel Na de registratie verifiëren de stakeholders of de RfC:

■ praktisch haalbaar is; ■ eerdere RfC’s herhaalt (die al zijn geaccepteerd); ■ afgewezen of nog (her)overwogen wordt; ■ compleet is (bijvoorbeeld adequaat beschreven, budgettair goedgekeurd voorstel e.d.).

Afgewezen verzoeken worden teruggestuurd naar de indiener (initiatiefnemer) onder vermelding van de reden waarom het voorstel is afgewezen. De initiatiefnemer moet het recht hebben om in beroep te gaan tegen de afwijzing.

3. Beoordelen en evalueren van de wijziging Deze stap start met categorisering van de wijziging. Het risico moet zijn afgewogen voordat een wijziging wordt geautoriseerd. De waarschijnlijkheid dat het risico optreedt en de mogelijke impact ervan bepalen de

risicocategorie

van de wijziging. In de praktijk wordt hiervoor vaak een

zogeheten risicocategorisatiematrix gebruikt.

Nadat de wijziging is gecategoriseerd, wordt deze

geëvalueerd. Op basis van

de impact, de risicoanalyse, potentiële voordelen en kosten van de wijziging, bepaalt de

wijzigingsautoriteit (bijvoorbeeld de changemanager en/of CAB)

of de wijziging wordt goedgekeurd of niet.

De volgende vragen moeten worden beantwoord voor alle wijzigingen. Zonder deze informatie, kan de impactbeoordeling niet worden afgerond en de balans van risico en voordelen voor de operationele service niet worden begrepen. De

zeven R’s van changemanagement vertegenwoordigen een

goed uitgangspunt voor impactanalyse:

Raised)

1. Waar/bij wie rees de behoefte aan de wijziging? (

Reason) 3. Wat moet de wijziging opleveren? (Return) 4. Wat zijn de risico’s van de wijziging? (Risk) 5. Welke resources zijn er voor nodig? (Resources) 2. Wat is de reden voor de wijziging? (

6. Wie is verantwoordelijk voor het bouwen, testen en implementeren?

Responsible)

(

Relationship)

7. Welke relaties bestaan er tussen deze en andere wijzigingen? (

De

prioriteit van de wijziging moet bepalend zijn voor de volgorde waarin de

voorliggende wijzigingen worden overwogen. De prioriteit wordt afgeleid van de vastgestelde impact en urgentie. De

impact is gebaseerd op het voordeel dat

de wijziging oplevert voor de business of op de hoeveelheid schade en kosten voor de business als deze faalt. De

urgentie

geeft aan hoe lang de

implementatie kan worden uitgesteld.

Planning en inroostering van wijziging en Changemanagement plaatst de wijzigingen in de wijzigingskalender: het

wijzigingsschema (Schedule of Change, SC). Hierin staan de gegevens van alle goedgekeurde wijzigingen en hun planning, zoals hun implementatiedatum.

Wijzigingen kunnen worden gebundeld in een release. In overleg met de relevante IT-afdelingen kan de CAB de tijden vaststellen voor de implementatie van wijzigingen, momenten waarop services zo weinig mogelijk worden gehinderd door wijzigingen. Een herstelplan moet worden voorbereid voor het geval dat de implementatie van de wijziging niet succesvol blijkt.

4. De wijziging autoriseren Voor elke wijziging is formele autorisatie vereist van een wijzigingsautoriteit. Die autoriteit kan een rol, persoon of een groep mensen zijn. Het niveau waarop toestemming is vereist, hangt af van het soort wijziging. Afbeelding 6.4 toont een voorbeeld.

5. Coördineren van wijzigingsimplementatie Indien de wijziging deel uitmaakt van een release, dan zullen de werkzaamheden (inbouwen van de wijziging in een release en het testen van de betreffende release) gecoordineerd worden vanuit het release & deployment managementproces. Het samenstellen en creëren van een release wordt besproken in paragraaf 6.6 ‘Release & deployment management’.

Eenvoudige wijzigingen, die geen deel uitmaken van een release, zullen vanuit het changemanagementproces zelf gecoördineerd worden. De daarvoor verantwoordelijke technische- en/of applicatiespecialisten ontvangen in dat geval een opdracht (work package) om de goedgekeurde wijziging te bouwen en te testen.

De wijzigingen, het herstel en de implementatiemethode voor de wijzigingen moeten grondig worden getest. In paragraaf 6.7 ‘Service validation & testing’ wordt dit testen besproken.

Afbeelding 6.4 Voorbeeld van een autorisatiemodel (Gebaseerd op bron: AXELOS)

6. Evaluatie en afsluiting van de wijziging Doorgevoerde wijzigingen – wellicht met uitzondering van standaard wijzigingen – worden na verloop van tijd geëvalueerd. De CAB bepaalt dan of een follow-up nodig is.

Is de wijziging succesvol verlopen, dan kan deze worden afgesloten. De uitkomst moet worden meegenomen in de

wijzigingsevaluatie

(Post

Implementation Review, PIR). Als de wijziging geen succes was, bepaalt changemanagement of de CAB wat er moet gebeuren. Een nieuwe of gewijzigde RfC kan het resultaat zijn.

6.4.3 Informatiemanagement ■ Alle wijzigingsverzoeken moeten verband houden met services en andere CI’s. Dit betekent dat ze moeten worden opgenomen in het CMS.

■ Wijzigingen in verband brengen met incidenten en de geschiedenis van wijzigingen van een CI binnen incident- of problemmanagement beoordelen.

■ Changemanagement moet toegang hebben tot het CMS en tot informatie en documenten in het SKMS om wijzigingen te kunnen plannen en te beheren, om stakeholders bij een wijziging aan te wijzen en om de mogelijke impact van wijzigingen te voorspellen.

6.4.4 Interfaces ■ Transitieplanning en -ondersteuning – Ervoor zorgen dat er een gecoördineerde overallmethode is voor het managen van servicetransities.

■ Wijzigingsevaluatie

– Het wijzigingsevaluatierapport tijdig opleveren aan

change-management zodat de CAB (of een andere wijzigingsautoriteit) dit kan gebruiken in de besluitvorming.

■ Businessveranderingsprocessen – in voorkomende gevallen dient changemanagement betrokken te zijn bij veranderingsprogramma’s aan de kant van de business en de projectteams die aan deze veranderingen invulling geven. Dit om er zeker van te zijn dat wijzigingsissues, -doelen, gevolgen bij alle betrokkenen in beeld zijn en waar nodig plannen kunnen worden bijgesteld.

■ Serviceportfoliomanagement – Wijzigingsvoorstellen doorgeven voor opname van nieuwe of gewijzigde services, om potentiële conflicten over resources of andere problemen te ontdekken.

■ Alle servicemanagementprocessen •

Procesverbeteringen doorvoeren.

•

Participeren in impactbeoordeling en implementatie van servicewijzigingen.

•

De impact van een wijziging op de beleidsregels, plannen of initiatieven van dat proces beoordelen.

■ Service asset- en configuratiemanagement •

Zorgen voor betrouwbare, snelle en eenvoudige toegang tot accurate configuratie-xinformatie.

•

Stakeholders en personeel in staat stellen om de impact van voorgestelde wijzigingen te beoordelen en om de gewijzigde werkwijze te volgen.

•

Vaststellen welke CI’s betrokken zijn en hoe deze worden beïnvloed door de wijziging.

■ Problemmanagement – Workarounds (tijdelijke oplossingen) implementeren en bekende fouten oplossen.

■ Serviceportfoliomanagement – Beoordelen of een service naar een volgend stadium in de serviceportfolio moet doorschuiven.

6.4.5 Aanleidingen (triggers) Strategische wijzigingen ■ Wijziging vanwege wet- en regelgeving. ■ Organisatorische wijziging. ■ Wijziging in beleid en standaarden. ■ Wijziging na analyseren van de patronen van de business-, klant- en gebruikersactiviteiten.

■ Toevoeging van een nieuwe service aan de portfolio. ■ Updates van de serviceportfolio, klantportfolio, of klantenovereenkomstenportfolio.

■ Wijziging van het inkoopmodel. ■ Technologische innovatie. Operationele wijzigingen ■ Standaard wijzigingen zoals geformuleerd door het request fulfillmentproces.

■ Implementatie van correctieve en preventieve wijzigingen. Wijzigingen in een of meer services ■ Servicecatalogus. ■ Servicepakket. ■ Servicedefinitie en -karakteristieken. ■ Releasepakket. ■ Eisen t.a.v. capaciteit en resources. ■ Servicelevelvereisten. ■ Garanties. ■ Utilities. ■ Kosten van gebruik ■ Serviceassets. ■ Acceptatiecriteria. ■ Voorspelde servicekwaliteit.

■ Voorspelde prestaties. ■ Voorspelde waarde. ■ Organisatieontwerp. ■ Stakeholders- en communicatieplannen. ■ Fysieke wijziging in de omgeving. ■ Meetsysteem. ■ Plannen van capaciteit, ITSCM, wijziging, transitie, test en release en uitrol. ■ Ontmantelen/stoppen van services. ■ Procedures, handleidingen, servicedeskscripts. Wijzigingen vanwege continue verbetering ■ Bepaalde strategie- en servicewijzigingen worden geïnitieerd door CSI.

6.4.6 Invoer ■ Beleid en strategie voor wijziging en release. ■ Wijzigingsverzoek (RfC). ■ Wijzigingsvoorstel. ■ Plannen – wijziging, transitie, release, test, evaluatie en herstel. ■ Huidig wijzigingsschema en de verwachte onbeschikbaarheid (project service outage, PSO).

■ Evaluatierapporten en interim evaluatierapporten. ■ Huidige activa of configuratie-items. ■ Configuratiebaseline zoals gepland. ■ Testresultaten, testrapporten en evaluatierapporten.

6.4.7 Uitvoer ■ Afgekeurde en geannuleerde RfC’s. ■ Geautoriseerde wijzigingen. ■ Geautoriseerde wijzigingsvoorstellen. ■ Wijziging van de service of infrastructuur als resultaat van geautoriseerde wijzigingen.

■ Nieuwe, gewijzigde of verwijderde configuratie-items. ■ Aangepast wijzigingsschema. ■ Aangepaste verwachte onbeschikbaarheid periodes (projected service outage PSO).

■ Geautoriseerde wijzigingsplannen.

■ Wijzigingsbeslissingen en acties. ■ Wijzigingsdocumenten en -records. ■ Changemanagementrapporten.

6.4.8 Kritieke succesfactoren ■ Reageren op wijzigingsverzoeken van de business en de IT die de services afstemmen op de bedrijfsbehoeften en tegelijkertijd de waarde maximaliseren.

■ Optimaliseren van het overall-bedrijfsrisico. ■ Zorgen dat alle wijzigingen aan de configuratie-items goed worden gemanaged en dat ze worden vastgelegd in het configuratiemanagementsysteem.

6.4.9 Metrics ■ Stijging in: •

Het percentage wijzigingen om daarmee te voldoen aan de overeengekomen eisen van de klant.

•

Aantal accurate voorspellingen wat betreft tijd, kwaliteit, kosten, risico's, resources en commerciële impact.

■ Daling in: •

Achterstand in afhandeling van wijzigingsverzoeken.

•

Aantal verstoringen van services, defecten en dubbel werk door inaccurate specificatie of door slechte of incomplete impactbeoordeling.

•

Percentage wijzigingen dat wordt gecategoriseerd als emergency changes.

•

Aantal geïdentificeerde niet-geautoriseerde wijzigingen.

•

Aantal incidenten dat wordt toegeschreven aan wijzigingen.

6.4.10 Uitdagingen ■ Zorgen dat elke wijziging wordt vastgelegd en beheerd. ■ Zorgen voor een actieve en zichtbare betrokkenheid van het management en andere leidinggevenden.

■ Meer waardering kweken. Het beeld wijzigen dat het proces bureaucratisch is en tot tijdverspilling leidt.

■ De stap zetten van een puur operationele vorm van wijzigingscontrole naar een echt changemanagementproces, dat ondersteuning biedt aan de hele levenscyclus (van servicestrategie tot en met serviceproductie en continue

serviceverbetering), de beoordeling van kosten en opbrengsten omvat en de IT-provider in staat stelt wijzigingen over de hele levenscyclus heen te kunnen plannen en managen.

■ Afspraken vastleggen en goed communiceren over de vraag welke wijzingen (op basis van een indeling in kosten, risico’s en impact) op welk managementniveau en door welk orgaan goedgekeurd moeten worden.

6.4.11 Risico’s ■ Gebrek aan betrokkenheid bij het changemanagementproces van: •

de business;

•

het IT-management;

•

het IT-personeel

■ Gebrek aan duidelijkheid over interactie met: •

andere servicemanagementprocessen;

•

projectmanagement of serviceontwerpactiviteiten.

■ Implementatie van wijzigingen zonder changemanagement erbij te betrekken.

■ Wijzigingsbeoordeling gereduceerd tot het plaatsen van een vink op een ‘afvinklijst’.

■ Introduceren van vertragingen in de implementatie van wijzigingen zonder dat daar extra waardetoevoeging tegenover staat.

■ Bureaucratische changemanagementprocessen veroorzaken extreme vertragingen bij het implementeren van wijzigingen.

■ Onvoldoende: •

tijd voor een goede beoordeling; de druk op te nemen beslissingen neemt daardoor toe.

•

tijd voor de implementatie van wijzigingen; men probeert te veel wijzigingen in het changevenster te stoppen.

•

middelen voor de beoordeling, planning en implementatie.

■ 6.5 SERVICEASSET- EN

CONFIGURATIEMANAGEMENT (SACM) 6.5.1 Inleiding

Het

doel van serviceasset- en configuratiemanagement (SACM) is om de assets

(bedrijfsmiddelen), die noodzakelijk zijn om services te leveren, onder controle te houden (weten wat waar is) en dat er accurate en betrouwbare informatie over die assets beschikbaar is wanneer en waar die informatie nodig is. Deze informatie omhelst details over hoe de assets zijn geconfigureerd en wat de onderlinge relaties tussen de assets zijn.

De

doelstellingen van serviceasset- en configuratiemanagement zijn:

■ Zekerstellen dat de IT-bedrijfsmiddelen (assets) worden geïdentificeerd, dat alle statusveranderingen (bijvoorbeeld van opslag naar gebruik, en van gebruik naar archief ) gecontroleerd verlopen en dat verantwoording over de actuele status en het gebruik van de IT-bedrijfsmiddelen kan worden afgelegd.

■ Het identificeren, controleren, opslaan, rapporteren, controleren en verifiëren van services en andere CI’ s.

■ Administreren, beheren en beschermen van de integriteit van CI’ s gedurende hun levenscyclus.

■ Het inrichten en onderhouden van een accuraat en compleet CMS. ■ Het onderhouden van accurate configuratie-informatie over de historische, geplande en actuele status van services en andere CI’s.

■ Het ondersteuning van andere servicemanagementprocessen. Bereik Alle assets die worden gebruikt gedurende de servicelevenscyclus vallen binnen het bereik van assetmanagement. Het proces biedt een compleet overzicht van alle assets en toont wie verantwoordelijk is voor de controle en het beheer van deze assets.

Configuratiemanagement identificeert alle componenten (CI’s) die deel uitmaken van de service, of het product. Ze bepaalt de baseline ervan en zorgt ervoor dat er onderhoud aan plaatsvindt. Het proces levert ook een logisch model van alle services, assets, de fysieke infrastructuur en de onderlinge relaties.

Het bereik van het proces beslaat ook de assets en CI’s van andere leveranciers, voor zover deze relevant zijn voor de service.

Waarde voor de business SACM maakt zichtbaar hoe een service, een release of (een deel van) de ITinfrastrucuur is opgebouwd en welke prestaties door een service, een release of (een deel van) de IT-infrastructuur geleverd worden. Dit resulteert onder andere in:

■ Betere voorspelling en wijzigingen zijn beter te plannen. ■ Wijzigingen en releases worden beoordeeld, gepland en met succes opgeleverd.

■ Incidenten en problemen worden opgelost binnen de serviceleveldoelen. ■ Betere naleving van standaarden, verplichtingen op grond van wet- en regelgeving (minder afwijkingen).

■ De mogelijkheid om de kosten van een service vast te stellen. Beleidsregels De eerste stap is het ontwikkelen en onderhouden van de SACM-beleidsregels. Deze regels leggen de doelstellingen, het bereik en de principes en kritieke succesfactoren vast voor wat het proces moet bereiken. Het implementeren van SACM gaat gepaard met aanzienlijke kosten en gevolgen voor de noodzakelijke resources en daarom moeten strategische beslissingen worden genomen over de prioriteiten. Veel IT-serviceproviders richten zich aanvankelijk op de basis-IT-assets (hardware en software) en services die bedrijfskritisch zijn of door wet- en regelgeving worden opgelegd (zoals SOx), ofwel op softwarelicenties.

Ontwerp en planning De beleidsregels beschrijven de uitgangspunten voor de ontwikkeling en controle van assets en CI’s, bijvoorbeeld:

■ De kosten van SACM zijn proportioneel ten opzichte van de potentiële risico’s voor de service als SACM niet zou zijn doorgevoerd.

■ De noodzaak specificaties te leveren voor ‘corporate governance’. ■ De noodzaak de overeenkomsten in de SLA en andere contracten te garanderen.

■ De specificaties voor beschikbare, betrouwbare en kosteneffectieve services. ■ De specificaties voor prestatiecriteria. ■ De overgang van reactief onderhoud naar proactieve controle.

■ Eisen met betrekking tot het onderhouden van adequate informatie over assets- en configuratiesten behoeve van de stakeholders.

Basisbegrippen Serviceassets (configuratie-items, configuratierecords, het CMS en het SKMS) Het is belangrijk om onderscheid te maken tussen serviceassets, configuratieitems en configuratierecords, want in de praktijk worden deze begrippen vaak verwisseld.

Serviceasset Een serviceasset is iedere resource of competentie die kan bijdragen aan de levering van een service. NB: de definitie van serviceassets en customerassets is in wezen hetzelfde. Het voornaamste verschil is dat serviceassets door de serviceprovider en customerassets door de klanten (binnen de business) worden gebruikt.

Configuratie-item Een configuratie-item (CI) is een serviceasset die moet worden gemanaged om een IT-service te kunnen leveren. Dit valt onder de verantwoordelijkheid van het changemanagementproces. Een wijziging die wordt beschouwd als een ‘vooraf goedgekeurde standaard wijziging’ maakt evengoed deel uit van het changemanagementproces, ook al hoeft de CAB niet te worden ingeschakeld.

Configuratierecord Een configuratierecord wordt opgeslagen in een configuratiemanagementdatabase (CMDB) en beheerd met een configuratiemanagementsysteem (CMS). De CI-record bevat een verzameling attributen en relaties van een CI – een parent-child-relatie ofwel een peer to peer. Het is belangrijk op te merken dat een CI niet fysiek wordt opgeslagen in een CMDB; de configuratierecords in de CMDB beschrijven de CI.

De configuratiemanagementdatabase (CMDB) De CMDB is een verzameling tools en databases die wordt gebruikt voor het beheer van data en informatie over configuratie-items.

Afbeelding 6.5 Work ow changemanagement en serviceasset- & con guratiemanagement (Bron: AXELOS) Het configuratiemanagementsysteem (CMS) Het CMS is een verzameling tools, bestanden en databases die wordt gebruikt voor het beheer van data, informatie en kennis die de serviceprovider gebruikt voor de eigen werkzaamheden en voor de ondersteuning van de business. Het SACM-proces is verantwoordelijk voor het beheer van het CMS. Het SACMproces is eigenaar van de CMDB(‘s) in de CMS. Andere items zoals databases voor incidenten, problemen, bekende fouten, wijzigingen en releases en de managementinformatiesystemen van de serviceontwerpprocessen (om er een paar te noemen) zullen het eigendom zijn en beheerd worden door de betreffende processen.

Het kennismanagementsysteem voor services (SKMS) Het SKMS (servicekennismanagementsysteem) is een verzameling van tools, bestanden en databases geleverd en ondersteund door de serviceprovider voor het beheer van de data, informatie en kennis die de business gebruikt om zijn doelstellingen te realiseren. Het SACM-proces is niet verantwoordelijk voor het beheer van het SKMS. Net als bij het CMS, zijn verschillende items eigendom van verschillende processen die deze ook beheren. Het kennismanagementproces is verantwoordelijk voor het beheer van het SKMS.

Het CMS en het SKMS bestaan gewoonlijk uit vier logische lagen: 1. Presentatielaag (bovenste laag): Om verschillende ‘views’ van de drie eerdere lagen aan te bieden voor de serviceprovider en de business. 2. Kennislaag: Om de informatie te verwerken tot betekenisvolle rapporten en query’s voor analysedoeleinden. 3. Informatielaag: Om de gegevens te sorteren, structureren en integreren in betekenisvolle informatie. 4. Data (onderste laag): Om de data uit verschillende bronnen te verzamelen in verschillende bestandsformaten.

Het configuratiemodel Serviceassets- en configuratiemanagement (SACM) levert een model van services, assets, serviceassets, customerassets en infrastructuur door de relaties tussen configuratiemodellen van configuratie-items vast te leggen. Dit heeft tot doel om:

■ de impact en oorzaak van incidenten en problemen te beoordelen; ■ de impact van voorgestelde wijzigingen te beoordelen; ■ nieuwe of gewijzigde services te plannen en te ontwerpen; ■ Technologische vernieuwingen en software-upgrades te plannen; ■ releases te plannen; ■ het assetgebruik en de kosten daarvan te optimaliseren. Soorten CI’s Er zijn veel soorten CI’s, zoals: servicelevenscyclus-CI, service-CI, organisatieCI, interne CI, externe CI, interface-CI.

Afbeelding 6.6 Voorbeeld van een logisch con guratiemodel (Bron: AXELOS) Waar mogelijk worden geautomatiseerde tools (zoals detectie-, inventarisatieen audittools) gebruikt om de CMDB, het CMS en het SKMS te vullen en te onderhouden. Dit minimaliseert de kans op fouten en bespaart kosten.

Bibliotheken en opslagplaatsen In ITIL worden verschillende

bibliotheken onderscheiden ter ondersteuning

van de CMDB, het CMS en het SKMS. Naar de bibliotheken wordt uiteraard verwezen in de CMDB in de vorm van CI-records. Ze worden ook beschouwd als een onderdeel van het CMS of het SKMS.

Configuratiebaseline Een configuratiebaseline is een configuratie van een service, of een deel daarvan, die formeel is beoordeeld en waarvoor akkoord gegeven is. Deze

dient als basis voor verdere activiteiten en kan alleen via formele wijzigingsprocedures worden aangepast. Configuratiebaselines worden opgenomen in het CMS. Een baseline wordt ook gebruikt om:

■ Een mijlpaal in de levenscyclus van een service te markeren. ■ Een servicecomponent te bouwen met bepaalde invoer. ■ Een specifieke versie in een later stadium te wijzigen of te herbouwen. ■ Alle relevante componenten in gereedheid te brengen voor een wijziging of voor het assembleren van een release.

■ Herstel naar een vorige bekende toestand in geval van problemen gedurende of na een wijziging.

Snapshot Een snapshot (momentopname) is de meest recente status van een CI of omgeving. Een snapshot wordt opgeslagen in het CMS en bewaard als een historische record die alleen gelezen mag worden. Een snapshot is een hulpmiddel voor:

■ Problemmanagement bij het analyseren van de situatie op het moment dat zich incidenten voordeden.

■ Securitymanagement in het faciliteren van systeemherstel voor software die beveiligingsscans maakt.

6.5.2 Activiteiten, methoden en technieken De basis SACM-procesactiviteiten zijn: 1. Management en planning. 2. Configuratie-identificatie. 3. Configuratiecontrole. 4. Statusvastlegging en -rapportage. 5. Verificatie en audit.

1. Management en planning Het managementteam en configuratiemanagement beslissen welk niveau van configuratiemanagement nodig is en hoe dit niveau wordt bereikt. Dit wordt gedocumenteerd in een

configuratiemanagementplan.

2. Configuratie-identificatie

Configuratie-identificatie is gericht op het bepalen en onderhouden van de benaming en versienummering van assets en CI’s, de onderlinge relaties en de relevante attributen.

Een

configuratiestructuur voor elke IT-service toont de relaties en hiërarchie

tussen CI’s voor die bepaalde service. De configuratiestructuur heeft een topdownbenadering.

Gedocumenteerde

naamconventies worden toegepast bij de identificatie van

CI’s, documenten en wijzigingen, maar bijvoorbeeld ook in basisconfiguraties, releases en compilaties.

Elke CI moet uniek identificeerbaar zijn met een versienummer, want er kunnen meerdere versies zijn van dezelfde CI, bijvoorbeeld verschillende softwareversies. Bij het opstellen van de naamconventies moet rekening worden gehouden met toekomstige groei. De namen moeten tevens kort maar betekenisvol zijn en zoveel mogelijk corresponderen met de bestaande conventies.

Alle fysieke CI’s, zoals hardware, worden voorzien van een

label, zodat ze

eenvoudig te identificeren zijn. Het label moeten goed te lezen en toegankelijk zijn, zodat een gebruiker de informatie op het label aan de servicedesk kan doorgeven. Labels met een barcode zijn zeer efficiënt voor fysieke audits van de CI’s. Tijdens dergelijke audits wordt gecontroleerd of de CI’s in de organisatie corresponderen met die in het CMS.

Met behulp van

attributen wordt informatie opgeslagen die relevant is voor

de betreffende CI. Verschillende soorten CI vereisen verschillende attributen. Een gemeenschappelijk kenmerk moet worden vastgesteld en gebruikt om de verschillende soorten CI’s in de CMDB met elkaar in verband te brengen. Een relatieattributen is een manier om dat te bewerkstelligen. Hier volgt een lijst mogelijke attributen.

Tabel 6.1 Mogelijke CI-attributen

De attributen van een CI of CI-type worden vaak vastgelegd in

configuratiedocumentatie . Relaties beschrijven hoe CI’s samenwerken bij het leveren van een service. De CMDB onderhoudt deze relaties om de onderlinge afhankelijkheden tussen CI’s te tonen, bijvoorbeeld:

■ Een CI is een onderdeel van een andere CI – een softwaremodule is onderdeel van een applicatie (parent-childrelatie).

■ Een CI is verbonden met een andere CI – een werkstation is verbonden met het local area network (LAN).

■ Een CI maakt gebruik van een andere CI – een bedrijfsapplicatie gebruikt een database.

■ Een CI is geïnstalleerd op een andere CI – een tekstverwerkingsprogramma is geïnstalleerd op een pc.

Relaties zijn ook de mechanismen voor het associëren van RfC’s, incidenten, problemen, en bekende fouten en releases met CI’s. Relaties kunnen 1-op-1, 1-op-veel en veel-op-1 zijn. Configuratie-items kunnen met een

classificatie

worden ingedeeld, bijvoorbeeld naar: service, hardware, softwaredocumentatie, personeel.

3. Configuratiecontrole Configuratiecontrole zorgt dat de CI adequaat wordt beheerd. Geen enkele CI kan worden toegevoegd, gewijzigd, vervangen of verwijderd zonder dat de

afgesproken procedure wordt gevolgd.

4. Statusvastlegging en -rapportage De levenscyclus van een component wordt geclassificeerd in verschillende stadia en de stadia die verschillende soorten CI doorlopen moeten goed gedocumenteerd zijn. Een release doorloopt bijvoorbeeld de volgende stadia: geregistreerd, geaccepteerd, geïnstalleerd en teruggetrokken.

Statusrapporten geven een inzicht in de huidige en historische gegevens van elke CI en de statuswijzigingen die zich hebben voorgedaan.

Verschillende soorten

serviceassets en configuratierapporten zijn nodig

voor configuratiemanagement. De rapporten kunnen betrekking hebben op afzonderlijke CI’s, maar ook op een complete service. Dergelijke rapporten kunnen bestaan uit:

■ Een lijst CI’s en hun baselines. ■ Informatie over de huidige status en wijzigingsgeschiedenis. ■ Een lijst ontdekte niet-geautoriseerde CI’s. ■ Rapporten van het niet-geautoriseerde gebruik van hardware en software. 5. Verificatie en audit SACM voert verificaties en audits uit om te zorgen dat:

■ Er geen discrepanties bestaan tussen de gedocumenteerde uitgangspunten en de feitelijke bedrijfsomgeving waaraan die refereren.

■ CI’s fysiek aanwezig zijn in de organisatie, in de DML of in de vorm van reservevoorraad. De functionele en operationele karakteristieken van CI’s kunnen worden geverifieerd, en gecontroleerd kan worden of records in de CMDB overeenkomen met de fysieke infrastructuur.

■ Release- en configuratiedocumentatie aanwezig is voordat de release wordt uitgerold.

Alle afwijkingen die voortkomen uit de verificaties en audits moeten worden gedocumenteerd en gerapporteerd. Correctie-acties (CI’s toevoegen, wijzigen of verwijderen) worden afgehandeld via het changemanagementproces.

Audittools kunnen regelmatig, bijvoorbeeld wekelijks, controles uitvoeren. Bijvoorbeeld, een desktop-audittool vergelijkt de configuratie van de desktop van een persoon met de ‘master’-configuratie die was geïnstalleerd.

6.5.3   Informatiemanagement ■ Er moeten regelmatig back-ups van het CMS worden gemaakt en veilig worden bewaard. Het is raadzaam een kopie op een andere locatie te bewaren voor het geval er een calamiteit optreedt en herstel nodig is.

■ Het CMS bevat informatie over back-ups van CI’s. Ook bevat het oude versies van records van CI’s en CI-versies die zijn gearchiveerd en mogelijk ook van verwijderde CI’s of CI-versies.

■ In feite moet het CMS alleen records bevatten voor items die fysiek beschikbaar zijn of eenvoudig kunnen worden gecreëerd via procedures die bekend zijn bij en onder controle staan van service asset- en configuratiemanagement.

■ Het CMS bevat pointers naar kennis- en informatie-assets die zijn opgeslagen in het SKMS. Het is belangrijk deze koppelingen te onderhouden en hun geldigheid te verifiëren als onderdeel van periodieke audits.

■ SACM is verantwoordelijk voor het onderhoud van veel kennis- en informatie-assets binnen het SKMS. Deze assets moeten worden onderhouden met dezelfde mate van controle als het CMS.

6.5.4   Interfaces ■ Changemanagement – Identificeren van de impact van voorgestelde wijzigingen.

■ Financieel management voor IT-services – Om belangrijke financiële informatie te vangen zoals kosten, afschrijvingsmethoden, eigenaars- en gebruikers-, onderhouds- en reparatiekosten.

■ ITSCM – Voor vergroting van het bewustzijn met betrekking tot de activa waarvan de bedrijfsservices afhangen, controle van essentiële reserveonderdelen en software.

■ Incident- en problemmanagement – Voor het leveren en onderhouden van belangrijke diagnostische informatie.

■ Availabilitymanagement – Om te assisteren in het vinden van zwakke punten.

■ Wijzigings- en release & deployment management – Vanwege het voordeel van een planningsmethode met één centraal coördinatiepunt.

■ SACM heeft ook nauwe relaties met bepaalde bedrijfsprocessen, vooral beheer en inkoop van bedrijfsmiddelen (vaste activa).

6.5.5   Aanleidingen (triggers) ■ Updates van changemanagement. ■ Updates van release & deployment management. ■ Inkooporders. ■ Acquisities. ■ Service-aanvragen. 6.5.6   Invoer ■ Ontwerpen, plannen en configuraties van serviceontwerp. ■ Wijzigingsverzoeken en werkopdrachten van changemanagement. ■ Feitelijke configuratie-informatie verzameld via tools en audits. ■ Informatie in het vaste-activaregister van de organisatie. 6.5.7   Uitvoer ■ Nieuwe en bijgewerkte configuratierecords. ■ Bijgewerkte asset-informatie waarmee het bestaande assetregister wordt geüpdatet.

■ Informatie over kenmerken van en relaties tussen configuratie-items. ■ Configuratiesnapshots en -uitgangspunten. ■ Statusrapporten en andere geconsolideerde configuratie-informatie. ■ Auditrapporten.

6.5.8   Kritieke succesfactoren ■ De administratieve verwerking, het managen en de bescherming van de integriteit van CI’s in de gehele servicelevenscyclus.

■ Het ondersteunen van efficiënte en effectieve servicemanagementprocessen door op de juiste momenten te voorzien in accurate configuratie-informatie.

■ Opzetten en onderhouden van een accuraat en compleet configuratiemanagementsysteem (CMS).

6.5.9   Metrics ■ Verbeterde accuratesse met betrekking tot de assets die per klant of bedrijfseenheid worden gebruikt.

■ Stijging in het hergebruik en herverdeling van onderbenutte resources en assets.

■ Daling in het gebruik van niet-geautoriseerde service- en customerassets. ■ Lager aantal gerapporteerde uitzonderingen tijdens configuratie-audits. ■ Minder tijd en kosten voor onderzoeken en het oplossen van incidenten en problemen.

■ Verbeterde verhouding tussen gebruikte en betaalde licenties. ■ Minder risico’s door het vroegtijdig ontdekken van niet-geautoriseerde wijzigingen.

■ Verbeterde audit-compliance. ■ Kortere audits doordat accurate informatie over de configuratie-items makkelijk toegankelijk is.

6.5.10   Uitdagingen ■ Technisch ondersteunend personeel overhalen een check-in/check-outbeleid te volgen.

■ Aantrekken en verantwoorden van financiering voor SACM. ■ Een houding van ‘alleen gegevens verzamelen omdat het kan’. ■ Gebrek aan betrokkenheid en ondersteuning van het management.

6.5.11   Risico’s ■ De verleiding om meer op technologie gericht te zijn dan op de service- en bedrijfsbehoeften.

■ Configuratie-informatie wordt na verloop van tijd minder accuraat. ■ Het bereik te ruim instellen. ■ Het bereik te beperkt instellen. ■ Het CMS raakt verouderd door de verplaatsing van hardware-assets door niet-geautoriseerd personeel.

■ 6.6   RELEASE & DEPLOYMENT MANAGEMENT 6.6.1   Inleiding ITIL formuleert release & deployment management als volgt:

Release & deployment management is gericht op het bouwen, testen en creëren van de mogelijkheid de services te leveren die zijn gespeci eerd door serviceontwerp, die aan de behoeften van stakeholders voldoen en die de bedoelde uitkomsten realiseren. Het

doel van release & deployment management is het maken van plannen,

tijdschema’s voor en de beheersing van:

■ het bouwen; ■ het testen; ■ en de uitrol van releases, alsmede: ■ het leveren van de vereiste nieuwe functionaliteit, die nodig is voor de business en het beschermen van de integriteit van de bestaande services.

De

doelstellingen van release & deployment management zijn:

■ Opstellen en overeenkomen van release en uitrol plannen met klanten en andere stakeholders.

■ Maken en testen van release packages. ■ Garanderen van de integriteit van release packages gedurende alle transitieactiviteiten.

■ Uitrollen van release packages uit de DML naar de operationele (productie)omgeving op basis van een overeengekomen plan en tijdschema.

■ Zekerstellen dat release packages kunnen worden gevolgd, geïnstalleerd, getest, geverifieerd en/of kunnen worden teruggedraaid indien nodig.

■ Garanderen dat de wijzigingen aan de kant van de business en beheerorganisatie worden gemanaged gedurende de release en uitrolactiviteiten.

■ Zekerstellen dat de nieuwe service de vereiste utility en warranty biedt. ■ Registreren en managen van afwijkingen, risico’s en issues en het nemen van actie daarop.

■ Zekerstellen dat kennisoverdracht aan de klanten en beheerders plaatsvindt. Bereik

Alle processen, systemen en functies, die noodzakelijk zijn voor het samenstellen, bouwen, testen en in productie nemen van een release. In deze fase moet de service, zoals die gespecificeerd is in serviceontwerp, daadwerkelijk worden gerealiseerd om vervolgens overgedragen te kunnen worden aan serviceproductie.

Het proces is ervoor verantwoordelijk dat er op een juiste wijze getest wordt, maar het testen zelf is een activiteit binnen het proces servicevalidatie en testen.

Autorisatie voor het doorvoeren van wijzigingen komt vanuit het proces change-management

Waarde voor de business Effectief release & deployment management draagt bij aan de business omdat:

■ wijzigingen sneller, goedkoper en met minder risico’s worden gerealiseerd en de operationele doelstellingen beter worden ondersteund;

■ de implementatiemethode consistenter is en beter aan de traceerbaarheidseisen (van bijvoorbeeld audits, wetgeving en dergelijke) wordt voldaan.

Basisbegrippen Een release is een verzameling nieuwe of gewijzigde con guratie-items (CI’s) die zijn getest en samen worden doorgevoerd in productie.

Een

release-eenheid is het deel van de service of infrastructuur dat is

opgenomen in de release in overeenstemming met het releasebeleid en de richtlijnen van de organisatie. Releases worden gedocumenteerd in het CMS voor de ondersteuning van het release- en uitrolproces.

Het is belangrijk het correcte niveau van de release te bepalen. Voor een bedrijfskritische applicatie kan het zinvol zijn de gehele applicatie op te nemen in de release-eenheid, maar voor een website zou het alleen de gewijzigde HTML-pagina kunnen zijn.

Releases kunnen worden onderverdeeld in de volgende

releasecategorieën:

grote (major) releases, kleine (minor) releases en nood (emergency) releases.

In het

release -ontwerp gelden verschillende afwegingen wat betreft de

manier waarop de release wordt uitgerold. De meest voorkomende opties voor de uitrol van releases zijn:

■ Alles tegelijk (big bang) of gefaseerd. ■ Push en pull. ■ Geautomatiseerd of handmatig. Een

releasepakket is een afzonderlijke release-eenheid of een gestructureerd

aantal release-eenheden. In het geval van een nieuwe of gewijzigde service moet men met elementen waaruit de service bestaat (de infrastructuur, hardware, software, applicaties, documentatie, kennis, enz.) rekening houden.

Afbeelding 6.7 Voorbeeld van een releasepakket (Bron: AXELOS)

Release- en uitrolmodellen Release- en uitrolmodellen formuleren:

■ Releasestructuur. ■ De exit- en aanvangscriteria. ■ Gemanagede omgevingen voor het bouwen en testen. ■ De rollen en verantwoordelijkheden voor elke CI. ■ Het model van releasepromotie en configuratiebaseline. ■ Sjabloon voor release- en uitrolschema’s. ■ Ondersteunende systemen, tools en procedures voor documentatieactiviteiten.

6.6.2   Activiteiten, methoden en technieken Release & deployment management is onderverdeeld in vier fasen. In tabel 6.2 staan deze fasen beschreven

Tabel 6.2 De vier fasen van release & deployment management

1. Release- en uitrolplanning Voordat een release in productie wordt uitgerold, worden diverse plannen geformuleerd. Het type en aantal plannen hangt af van de grootte en complexiteit van de omgeving en van de gewijzigde of nieuwe service. Releaseen uitrolplannen vormen een onderdeel van het overall-servicetransitieplan. Changemanagement keurt de plannen goed of af.

De volgende (sub)plannen zijn relevant voor release en uitrol:

■ Goed-/afkeuringscriteria. ■ Bouw- en testplannen: • Gemanagede omgevingen. • Planning van het releasepakket en de samenstelling ervan. • Voorbereidingen treffen voor het bouwen en testen van de release. • Uitrolplanning.

• • •

Logistieke en leveringsplanning. Planning van pilots. Financiële/commerciële planning.

2. Release – bouwen en testen Bestaande services en infrastructuur kunnen een aanzienlijke invloed hebben op het bouwen en testen van een op technologie gebaseerde service en de infrastructuur waar die service gebruik van maakt. Tijdens het stadium releasesamenstelling en -testen moeten daarom de gedeelde services en infrastructuur zorgvuldig worden beheerd.

■ Documentatie over de release en de bouw ervan. ■ Verwerven en testen van de invoer bestaande uit configuratie-items en componenten.

■ Pakket van de release samenstellen. ■ Bouwen en managen van de testomgevingen. ■ Servicetesten en -pilots. ■ Service-oefeningen. ■ Pilots. 3. Uitrol ■ Plannen ontwikkelen en voorbereiden van de uitrol. ■ Wijziging/transfer van financiële assets. ■ Transfer/transitie van business en organisatie. ■ Uitrolprocessen en -materialen. ■ Uitrol van service management capability. ■ Transfer van de service. ■ Uitrol van de service. ■ Ontmanteling en beëindiging van de service. ■ Verwijderen van overbodige assets. ■ Verificatie van de uitrol. ■ Herstel/terugval (back out) van een release. ■ Early Life Support (ELS). 4. Evaluatie en afsluiting Om de servicetransitie als geheel af te ronden moet er een formele wijzigingsevaluatie worden uitgevoerd die is afgestemd op de schaal en het

bereik van de wijziging.

6.6.3   Informatiemanagement Tijdens het proces release & deployment management worden de bijbehorende records gecreëerd en onderhouden. Zodra configuratie-items met succes zijn uitgerold, wordt het CMS bijgewerkt met informatie zoals:

■ Nieuwe, gewijzigde of verwijderde configuratie-items. ■ Relaties tussen eisen en testgevallen. ■ Nieuwe, gewijzigde of verwijderde locaties en gebruikers. ■ Statusupdates. ■ Wijziging in eigenaarschap van assets. ■ Licentiehouderschap. Andere gegevens en informatie wordt ook afgevangen en vastgelegd in het bredere kennismanagementsysteem voor services (SKMS). Daarbij gaat het onder andere om:

■ Releasepakketten in de DML. ■ Installatie/bouwplannen. ■ Logistiek en leveringsplannen. ■ Validatie en testplannen, bewijs en rapporten. ■ Uitrolinformatie, uitrolgeschiedenis, wie betrokken waren, tijdmetingen enzovoort.

■ Trainingsrecords. ■ Toegangsregels en -niveaus. ■ Bekende fouten.

6.6.4   Interfaces ■ Ontwerpcoördinatie • Het ontwerpcoördinatieproces creëert het serviceontwerppakket, waarin staat uitgewerkt hoe de nieuwe service eruit moet gaan zien, inclusief de wijze waarop de service samengesteld en gebouwd moet worden.

•

Plannen en pakketten moeten worden ontwikkeld en gedocumenteerd tijdens het serviceontwerpstadium en ontwerpcoördinatie zorgt ervoor dat deze worden gedocumenteerd in het SDP.

■ Transitieplanning en -ondersteuning

•

Levert het kader waarbinnen release & deployment management werkt en transitieplannen leveren de context voor release- en uitrolplannen.

■ Changemanagement • Levert de autorisatie voor het werk. • Release & deployment management zorgt voor de uitvoer van veel wijzigingen.

•

Release- en uitrolplannen zijn een belangrijk onderdeel van het wijzigingsschema.

•

Uitrolevaluatie wordt vaak gecombineerd met de evaluatie en afsluiting van de wijziging.

■ Serviceasset- en configuratiemanagement • Release & deployment management is afhankelijk van gegevens en informatie in het CMS en levert veel updates aan het CMS.

■ Service validation & testing • Om te zorgen dat er wordt getest waar dat nodig is. • Om te zorgen dat de release beschikbaar is wanneer deze nodig is voor servicevalidatie en testen.

6.6.5   Aanleidingen (triggers) De uit te voeren activiteiten starten na de ontvangst van een geautoriseerd verzoek om een releasepakket te plannen, bouwen en te testen. De uitrol van het productie-gerede releasepakket vindt plaats na ontvangst van een geautoriseerd wijzigingsverzoek om het releasepakket uit te rollen in de daarvoor bestemde omgeving (fysieke ruimte en/of de IT-infrastructuur), waardoor de service ter beschikking gesteld kan worden aan de doelgroep (degenen die gebruik gaan maken van de uitgerolde service).

6.6.6   Invoer ■ Geautoriseerde wijziging, ■ Serviceontwerp. ■ IT-service continuity managementplan en bijbehorend bedrijfscontinuïteitsplan.

■ Servicemanagement- en productieplannen en -standaarden. ■ Technologie, inkoopstandaarden en catalogi. ■ Verworven serviceassets en componenten en de documentatie ervan. ■ Bouwmodellen en -plannen.

■ Omgevingseisen en -specificaties voor bouw, testen, release, training, herstel na een ramp, pilot en uitrol.

■ Releasebeleid en releaseontwerp van serviceontwerp ■ Release- en uitrolmodellen inclusief sjabloonplannen. ■ Exit- en aanvangscriteria voor elke fase van release & deployment management.

6.6.7   Uitvoer ■ Nieuwe, gewijzigde of uitgefaseerde services. ■ Release- en uitrolplan. ■ Updates naar changemanagement voor de release- en uitrolactiviteiten. ■ Servicenotificatie. ■ Notificatie naar servicecatalogusmanagement voor een update van de servicecatalogus met de relevante informatie over de nieuwe of gewijzigde service.

■ Nieuwe geteste servicecapaciteit en -omgevingen. ■ Nieuwe of gewijzigde servicemanagementdocumentatie. ■ SLA, onderliggende OLA en contracten. ■ Nieuwe of gewijzigde servicerapportages. ■ Geteste continuïteitsplannen. ■ Complete en accurate configuratie-itemlijst met een audittraject voor de CI’s in het releasepakket en ook de nieuwe of gewijzigde service- en infrastructuurconfiguraties.

■ Bijgewerkt servicecapaciteitsplan afgestemd op relevante businessplannen. ■ Releasepakket dat geldt als uitgangspunt – opgenomen in de DML en gereed voor toekomstige uitrol.

■ Servicetransitierapport.

6.6.8   Kritieke succesfactoren ■ Opstellen en overeenkomen van releaseplannen met klanten en stakeholders.

■ Zorgen voor integriteit van een releasepakket en de componenten daarin binnen de transitieactiviteiten.

■ Zorgen dat de nieuwe of gewijzigde service de benodigde utility en warranty kunnen leveren zoals die zijn overeengekomen.

■ Zorgen dat er goede kennisoverdracht plaatsvindt.

6.6.9   Metrics ■ Stijging van: • Aantal en percentage van de releases dat gebruikmaakt van een algemeen raamwerk van standaarden, herbruikbare processen en ondersteunende documentatie.

•

Aantal en percentage van de releases dat voldoet aan de klantverwachtingen wat betreft kosten, tijd en kwaliteit.

•

De score met betrekking tot de tevredenheid van de klanten, gebruikers en de serviceproductiemedewerkers over release & deployment management.

•

Klant- en gebruikerstevredenheid met de geleverde services.

■ Daling van: • Aantal negatieve CMS- en DML-auditresultaten in relatie tot releases. • Aantal releases vanuit andere bronnen dan de DML. • Aantal incidenten doordat incorrecte componenten worden uitgerold. • Afwijkingen in serviceprestaties die de klanten vereisen. • Aantal incidenten ten aanzien van de service. • Klantontevredenheid. • Resources en kosten nodig voor het onderzoeken en oplossen van incidenten en problemen in uitrol en operationeel gebruik.

•

Aantal incidenten ingedeeld als ‘gebruikerskennis’.

6.6.10 Uitdagingen ■ Ontwikkelen van standaard prestatiemetingen en meetmethoden over projecten en leveranciers heen.

■ Omgaan met projecten en leveranciers wanneer geschatte opleverdatums niet accuraat zijn en er vertraging optreedt in de planning van servicetransitieactiviteiten.

■ De verschillende standpunten van de stakeholders begrijpen, onderkennen en deze een uitgangspunt laten zijn voor effectief risicobeheer, binnen de beoordeling van de wijzigingsimpact en testactiviteiten.

■ Grondig inzicht opbouwen met betrekking tot de risico’s die gevolgen hebben gehad of kunnen gaan hebben voor het succes van de transitie van services en releases.

■ Aanmoedigen van een risicomanagementcultuur waarin mensen informatie delen en risico methodisch benaderen met een pragmatische aanpak en

metingen.

6.6.11   Risico’s ■ Slecht geformuleerde scope (bereik) en weinig besef van afhankelijkheden in eerdere levenscyclusstadia.

■ Gebruikmaken van personeel dat niet speciaal gericht is op de activiteiten van het proces.

■ Niet gebruikmaken van het proces release & deployment management voor het stopzetten of uitfaseren van services.

■ Gebrek aan: • Integratie met de juiste financiële cycli en activiteiten. • Integratie met de juiste corporate governance, wettelijke controles en eisen wat betreft licenties en beveiliging.

• • •

Operationele ondersteuning. Aandacht voor alle competenties en resources. Aandacht voor de aspecten van personeel, proces, producten en partners.

■ Niet managen of meenemen van veranderingen in de organisatie en bij de stakeholders.

■ Zwakke betrokkenheid en besluitvorming. ■ Er niet in slagen om tijdig de juiste autorisatie te verkrijgen. ■ Besluiteloosheid of late besluitvorming. ■ Niet-adequate en onnauwkeurige informatie. ■ Compromissen ten aanzien van gezondheid en veiligheid. ■ Onvoldoende tijd toegekend aan release & deployment management. ■ Het niet managen van leveranciers-/inkoop-/partnerrelaties tijdens de transitie.

■ Niet-adequate ‘herstel’ of ‘rampherstel’-plan als inkoop/partnerschap mislukt.

■ 6.7   SERVICE VALIDATION & TESTING 6.7.1   Inleiding Het testen van services is een belangrijke bijdrage aan de kwaliteit van ITservicelevering. Testen zorgt dat nieuwe (of gewijzigde) services

het doel en geschikt voor gebruik zijn.

geschikt voor

‘Geschikt voor het doel’ betekent dat de service doet wat de klant ervan verwacht, zodat de service de business ondersteunt. ‘Geschikt voor gebruik’ zegt iets over aspecten als availability, continuïteit, capaciteit en security van de service.

Onvoldoende aandacht voor testen kan resulteren in: stijging van het aantal incidenten, problemen en storingen, extra telefoongesprekken met de servicedesk vanwege vragen over het functioneren van de service, hogere kosten en een service die onjuist wordt gebruikt.

Het

doel van service validation & testing is zeker te stellen dat een nieuwe of

gewijzigde IT-service volledig in lijn is met de ontwerpspecificaties en dat ze zal voorzien in de behoeften van de business.

De

doelstellingen van service validation & testing zijn:

■ Vertrouwen verschaffen dat een release een nieuwe of gewijzigde service tot stand brengt, die de verwachte uitkomsten en waarde voor de klanten levert binnen de geprojecteerde kosten, benodigde capaciteit en gestelde randvoorwaarden.

■ Waarborgen van de kwaliteit van een release, de servicecomponenten waaruit de release is samengesteld en het vermogen tot serviceverlening dat wordt geleverd door de release.

■ Valideren dat een service ‘fit for purpose’ is – dat het de overeengekomen utility zal gaan leveren.

■ Valideren dat een service ‘fit for use’ is – dat het de overeengekomen warranty zal gaan leveren.

■ Zekerstellen dat de nieuwe of de te wijzigen service voldoet aan de eisen van de klant en andere stakeholders. En dat deze eisen correct zijn vastgesteld zodat herstel van fouten of varianties al vroegtijdig in de levenscyclus kan plaatsvinden.

■ Plannen en implementeren van een gestructureerd validerings- en testproces. Dit proces moet aantoonbaar maken of de nieuwe of gewijzigde service de business van de klant inderdaad ondersteunt en overeenkomt met de eisen van de stakeholders, inclusief de overeengekomen servicelevels.

■ Identificeren, beoordelen en adresseren van issues, fouten en risico’s gedurende de servicetransitiefase.

Bereik Service validation & testing wordt toegepast gedurende de gehele servicelevenscyclus en is gericht op het testen van de kwaliteit van de service(eenheden) en is bedoeld om te verifiëren of de serviceprovider voldoende capaciteiten en resources heeft om een service of release succesvol te leveren.

Testen is in het bijzonder ook ondersteunend aan de release- en uitrolprocessen. Verder maakt het proces wijzigingsevaluatie gebruik van de testresultaten.

Waarde voor de business Falen van of onderbrekingen in de serviceverlening kunnen schade toebrengen aan de bedrijfsvoering van de serviceprovider en die van klanten die de services ontvangen. Het kan resulteren in reputatie- en financiële schade en zelfs tot ernstige (fatale) ongelukken. Denk bij dit laatste bijvoorbeeld maar eens aan de rol van de IT in ziekenhuizen en in de auto- of vliegtuigindustrie.

Basisbegrippen Het servicemodel (afbeelding 6.8) beschrijft de structuur en dynamiek van een service die serviceproductie levert op basis van het serviceproductieplan. De structuur bestaat uit de klantgerichte- en ondersteunende services en de benodigde serviceassets. Wanneer een nieuwe (of gewijzigde) service is ontworpen, ontwikkeld en gebouwd, worden deze serviceassets getest in relatie tot de ontwerpspecificaties en -eisen. Activiteiten, resourcestromen, coördinatie en interacties beschrijven de dynamiek.

Beleidsregels voor service validation & testing zijn afkomstig van of hebben betrekking op:

■ servicetransitie; ■ changemanagement; ■ servicekwaliteit; ■ risico; ■ hergebruik; ■ release;

■ het verplichte integrale testen en de betrokkenheid van de stakeholders hierin.

De

teststrategie

formuleert de algehele testmethode en de toewijzing van

vereiste resources. Deze strategie kan van toepassing zijn in de gehele organisatie, een verzameling services of een afzonderlijke service. Alle teststrategieën worden ontwikkeld in samenwerking met de stakeholders. Aandacht wordt besteed aan doelstellingen, bereik, standaarden, testprocessen, testmetrics, testmethode, eisen en ‘deliverables’.

Een

testmodel bestaat uit een testplan, dat wat moet worden getest en

testscripts die de methode aangeven volgens welke elk element moet worden getest. Om te zorgen dat het proces herhaalbaar is, moeten testmodellen zo gestructureerd zijn dat:

■ de specificaties van ontwerpcriteria die worden getest traceerbaar zijn; ■ testactiviteiten, evaluaties en rapporten kunnen worden ge-audit.; ■ testelementen onderhoudbaar en wijzigbaar zijn.

Afbeelding 6.8 Voorbeeld van een servicemodel (Bron: AXELOS) Er zijn veel

testtechnieken en testmethoden. De techniek en methode

hangen af van het soort service, risicoprofiel, testdoel en testniveau. Voorbeelden zijn: document-beoordeling, modelleren, simulatie, scenariotesten, rollen spel en laboratoriumtest, operationele pilot.

Ontwerpafwegingen die belangrijk zijn voor het testen houden verband met: ■ financiën (is er voldoende budget?); ■ documentatie (is alles beschikbaar en in het correcte formaat?); ■ compositie (samenstelling); ■ testbaarheid (denk aan middelen, tijd en faciliteiten); ■ traceerbaarheid (traceerbaar voor specificaties); ■ de vraag waar en wanneer het testen plaatsvindt, en met wie; ■ herstel (is er een back-upplan?).

6.7.2   Activiteiten, methoden en technieken Men onderscheidt de volgende activiteiten. Deze activiteiten hoeven niet noodzakelijkerwijs in deze volgorde te worden uitgevoerd, men kan ze ook naast elkaar uitvoeren. 1. Validatie- en testmanagement. 2. Planning en ontwerp. 3. Verificatie van testplan en -ontwerp. 4. Voorbereiden testomgeving. 5. Testen uitvoeren. 6. Evaluatie van exitcriteria en -rapportage. 7. Opruimen en afsluiten.

In afbeelding 6.9 is het testproces schematisch weergegeven.

Afbeelding 6.9 Work ow van service validation & testing (Bron: AXELOS)

1. Validatie- en testmanagement Testmanagement bestaat uit plannen en beheren (controleren) van en rapporteren over de activiteiten die plaatsvinden gedurende alle testfasen van de servicetransitie.

2. Planning en ontwerp Testplannings- en -ontwerpactiviteiten vinden vroeg in de servicelevenscyclus plaats.

3. Verificatie van testplan en -ontwerp Testplannen en -ontwerpen worden geverifieerd om zeker te stellen dat alles (inclusief scripts) compleet is en dat testmodellen voldoende rekening houden met het risicoprofiel van de betreffende service en alle mogelijke interfaces.

4. Voorbereiden van de testomgeving De testomgeving voorbereiden en een uitgangsconfiguratie in de testomgeving maken.

5. Testen

De testen worden via handmatige of geautomatiseerde testtechnieken en – procedures uitgevoerd. Testers registreren alle resultaten. Als een test faalt, wordt de reden daarvan gedocumenteerd.

6. Evaluatie van exitcriteria en -rapportage De werkelijke resultaten worden vergeleken met de beoogde resultaten (exitcriteria). Testresultaten kunnen worden geïnterpreteerd in termen van ‘goed/fout’ (goedgekeurd of niet), risico’s die het geteste object voor de serviceprovider of klant kan inhouden, of in termen van benodigde kosten om het beoogde doel te bereiken.

7. Opruimen en afsluiten De testomgeving moet worden opgeruimd, de testmethode wordt geëvalueerd en verbeteringen worden aangegeven.

Kritieke succesfactoren bij implementatie zijn: ■ Problemen worden vastgesteld in een vroeg stadium van de levenscyclus. ■ Kwaliteit wordt in elke fase van de levenscyclus ingebouwd, bijvoorbeeld door gebruik van het V-model.

■ Herbruikbare testmodellen worden ontworpen en testen levert het bewijs dat alle configuraties zijn gebouwd en doorgevoerd in overeenstemming met de eisen van de klant.

Risico’s bij implementatie zijn: ■ Onduidelijke verwachtingen en doelstellingen, gebrek aan begrip dat testen een kritisch proces is in relatie tot kwaliteit van servicelevering.

■ Gebrek aan resources.

6.7.3   Informatiemanagement Testen is enorm gebaat bij hergebruik van testscripts en testbestanden en om die reden is het raadzaam om een bibliotheek te maken en te onderhouden van testscripts en -bestanden die herbruikbaar zijn. Ook is het belangrijk dat wordt vastgelegd hoe deze testen moeten worden uitgevoerd en doorgevoerd. Hoe goed de test ook is ontworpen, zonder goede testgegevens is iedere test zinloos. Daarom dient er veel aandacht te worden besteed aan het genereren van testgegevens. Het is belangrijk dat:

■ Testgegevens worden gescheiden van actuele gegevens. ■ Richtlijnen voor gegevensbescherming (privacy) worden toegepast. ■ Er goede backup- en herstelprocedures zijn.

6.7.4   Interfaces ■ Testen ondersteunt alle stappen van release & deployment management binnen servicetransitie.

■ De uitvoer van service validation & testing is een belangrijke invoer voor wijzigingsevaluatie. Deze input moet op het juiste moment worden geleverd en in een geschikt formaat om te zorgen dat wijzigingen op tijd kunnen worden geëvalueerd voor de besluitvorming van changemanagement.

■ De teststrategie

zorgt dat testproces binnen alle stadia van de levenscyclus

werkt.

■ Samenwerken met ontwerpcoördinatie

zorgt ervoor dat ontwerpen

testbaar zijn en er positieve ondersteuning wordt geleverd om dat te bereiken.

■ Nauw samenwerken met CSI voor inbreng van informatie over falen en verbeterideeën die uit testen voortkomen.

■ Serviceproductie

gebruikt onderhoudstesten om te zorgen voor

gecontinueerde werkzaamheid van services.

■ Servicestrategie

moet testen accommoderen in termen van adequate

financiering, resources, profiel enzovoort.

6.7.5   Aanleidingen (triggers) De aanleiding voor testen is een geplande activiteit in een releaseplan, testplan of plan voor kwaliteitsborging.

6.7.6   Invoer ■ RfC. ■ Het serviceontwerppakket met daarin: • De service charter. • Interfacedefinities door de serviceprovider • Productiemodellen. • Capaciteits-/resourcemodel en -plan. • Financiële/economische kostenmodellen.

• • • • •

Servicemanagementmodel. Testcondities en verwachte resultaten. Ontwerp- en interfacespecificaties. Release- en uitrolplannen. Acceptatiecriteria.

6.7.7   Uitvoer ■ De directe uitvoer van testen is het rapport dat geleverd wordt aan wijzigingsevaluatie:

• • • • •

Configuratiebaseline van de testomgeving. Uitgevoerde testen. Testincidenten, problemen en registratie van storingen. Resultaten van die testen. Analyse van de resultaten.

■ Andere uitvoer is: • Bijgewerkte data, informatie en kennis die wordt toegevoegd aan het kennismanagementsysteem behorende bij die service.

•

Vastleggingen in het CSI-register om potentiële verbeteringen aan te reiken in die gebieden die impact hebben op testen.

•

Relaties met derden (niet-direct betrokkenen), leveranciers van apparatuur of services, partners, gebruikers en klanten of andere stakeholders.

6.7.8   Kritieke succesfactoren ■ De verschillende standpunten van de stakeholders begrijpen. Deze standpunten vormen het uitgangspunt voor effectief risicomanagement binnen de beoordeling van de wijzigingsimpact en testactiviteiten.

■ Grondig inzicht opbouwen van de risico’s die gevolgen hadden voor of kunnen gaan hebben op het succes van de transitie van services en releases.

■ Aanmoedigen van een risicomanagementcultuur waarin mensen informatie delen en risico’s methodisch benaderen met een pragmatische aanpak en metingen.

■ Bewijs leveren dat de serviceassets en configuraties correct zijn gebouwd en doorgevoerd en dat de service levert wat de klant nodig heeft.

■ Testmodellen ontwikkelen die herbruikbaar zijn.

■ Een balans zien te vinden tussen de kosten van testen en de effectiviteit ervan.

6.7.9   Metrics ■ Rollen en verantwoordelijkheden voor: • Afspraken en documentatie van impactbeoordeling en testactiviteiten. • Afspraken en documentatie van klanten, gebruikers en personeel van de service-provider.

■ Toename van: • Het percentage impactbeoordelingen en testactiviteiten waaraan is deelgenomen door iedereen waarvan zijn of haar formele rol/functie dat vereist.

•

Het aantal risico’s dat in het serviceontwerp of eerder in de servicetransitie is vastgesteld, vergeleken met die risico’s die ontdekt zijn tijdens of na het testen;

•

De verhouding tussen het aantal ontdekte fouten in de serviceontwerpfase, vergeleken met het aantal ontdekte fouten in de servicetransitiefase.

•

De verhouding tussen het aantal ontdekte fouten in de servicetransitiefase, vergeleken met het aantal ontdekte fouten in de serviceproductiefase.

•

Het percentage serviceacceptatiecriteria die zijn getest voor nieuwe en gewijzigde services.

•

Het effectievere gebruik van resources en meer betrokkenheid van de klant.

•

Een beter begrip bij alle stakeholders van de rollen en verantwoordelijkheden die verband houden met de nieuwe of gewijzigde service.

• •

Het aantal testgegevens dat wordt hergebruikt. Het aantal known errors dat in de vroege fasen van het testen ontdekt en gedocumenteerd wordt.

■ Daling van de: • impact die incidenten en fouten hebben op zojuist getransitioneerde services;

•

variantie tussen testbudget en testuitgaven;

• • • •

kosten voor het herstel van fouten (door vroegtijdige ontdekking); impact op de business ten gevolge van vertragingen in het testen; inspanning en de kosten voor het opzetten van de testomgeving; benodigde inspanning voor het opsporen van fouten, en daling van het aantal fouten dat zich herhaalt.

6.7.10   Uitdagingen ■ Een testomgeving opzetten en testdata onderhouden die representatief zijn voor de operationele omgeving.

■ Geschikt personeel, met de juiste competenties, en het beschikken over testtools voor het adequaat kunnen uitvoeren van alle benodigde testen.

■ Voorkomen dat projecten uitlopen en dat de toegewezen testtermijnen worden ingekort om de ‘go live’-datum toch maar te halen. Dit gaat ten koste van de kwaliteit.

■ Ontwikkelen van standaard prestatiemetingen en meetmethoden over alle projecten en leveranciers heen.

■ Voorkomen dat serviceproviders opleverdatums niet goed inschatten. Dit veroorzaakt vertragingen in de planning van de servicetransitie-activiteiten.

6.7.11   Risico’s ■ Onduidelijke verwachtingen/doelstellingen. ■ Gebrek aan begrip omtrent de risico’s. Dit leidt ertoe dat testen niet is gericht op cruciale elementen. En juist die moeten goed onder controle gehouden worden en daarom goed getest.

■ Een tekort aan resources zorgt voor vertragingen, en dat heeft impact op andere servicetransities.

■ 6.8   WIJZIGINGSEVALUATIE 6.8.1   Inleiding Het doel van wijzigingsevaluatie is om in staat te zijn om op een consistente en gestandaardiseerde wijze vast te stellen of een te wijzigen of gewijzigde service de gewenste prestaties kan leveren. En tevens om vast te kunnen stellen wat de (potentiele) gevolgen van een wijziging zijn op de resultaten van de business, op bestaande en voorgestelde services en op de IT-infrastructuur.

De feitelijke prestaties van een wijziging worden afgezet tegen de voorspelde prestaties. Risico’s en problemen in verband met de wijziging worden geïdentificeerd en gemanaged.

De

doelstellingen van het wijzigingsevaluatieproces zijn:

■ Zorgen dat er aan de verwachtingen van de stakeholders voldaan wordt en dat er accurate informatie wordt geleverd aan changemanagement. Voorzien van de juiste informatie kan changemanagement voorkomen dat wijzigingen die een negatieve impact op de serviceverlening hebben, en die bepaalde risico’ s met zich meebrengen, ongehinderd door de transitiefase komen.

■ Bedoelde en onbedoelde effecten van een servicewijziging evalueren (voor zover mogelijk).

■ Kwalitatief goede en juiste informatie leveren aan changemanagement, zodat deze in staat is de juiste beslissing te nemen met betrekking tot de autorisatie van een servicewijziging

Bereik Het bereik bestrijkt de periodieke evaluatie van nieuwe of gewijzigde services gedurende de levenscyclus van een wijziging in zoverre als vereist door het wijzigingsmodel of de bedrijfsbehoeften.

Waarde voor de business Wijzigingsevaluatie levert belangrijke invoer voor CSI en de toekomstige verbetering van serviceontwikkeling en changemanagement.

Beleidsregels, uitgangspunten en basisbegrippen De volgende beleidsregels gelden: ■ Serviceontwerpen of servicewijzigingen worden geëvalueerd voor de transitie ervan aanvangt.

■ Alle afwijkingen tussen voorspelde en feitelijke prestaties worden gemanaged door de klant, bijvoorbeeld acceptatie ja/nee.

■ Alle wijzigingen worden onderworpen aan een assessment. ■ Risico’s en problemen vaststellen die betrekking hebben op de service die wordt geleverd.

■ De klant betrekken bij wijzigingsevaluatie.

De volgende

uitgangspunten zijn belangrijk in de uitvoering van het proces:

■ Onbedoelde effecten van een wijziging (en de consequenties) moeten worden vastgesteld.

■ Een servicewijziging wordt eerlijk, consistent, openlijk en objectief geëvalueerd.

6.8.2   Activiteiten, methoden en technieken Het wijzigingsevaluatieproces bestaat uit de volgende activiteiten: 1. Opstellen van een evaluatieplan. 2. Begrip van het bedoelde effect van een wijziging. 3. Begrip van het onbedoelde effect van een wijziging. 4. Bepalen van de factoren voor afweging van het effect van een servicewijziging. 5. Evalueren van de voorspelde prestaties. 6. Evalueren van de feitelijke prestaties. 7. Uitvoeren van risicomanagement. 8. Genereren van een evaluatierapport.

Afbeelding 6.10 toont het wijzigingsevaluatieproces inclusief invoer en uitvoer.

6.8.3   Informatiemanagement ■ Het SKMS biedt de meeste informatie die nodig is voor wijzigingsevaluatie. ■ Alle evaluatierapporten worden in- en uitgecheckt in het CMS. ■ Digitale versies van de rapporten moeten worden opgeslagen in het SKMS. 6.8.4   Interfaces ■ Transitieplanning en ondersteuning – Om te zorgen dat de vereiste resources er zijn wanneer ze nodig zijn.

■ Changemanagement – Om af te stemmen welke soorten wijzigingen worden onderworpen aan een formele evaluatie.

■ Serviceontwerp – Om het serviceontwerppakket te leveren. ■ Servicelevelmanagement en klantrelatiebeheer – om een volledige analyse te kunnen maken van de impact van vastgestelde problemen en om eventueel gebruik te kunnen maken van resources (middelen en mensen) van de klant als die nodig zijn voor het uitvoeren van een evaluatie.

■ Servicevalidation & testing – Om activiteiten met dit proces te coördineren en te zorgen dat de benodigde input binnen de aanvaarbare tijd aanwezig is.

6.8.5   Aanleiding (trigger) ■ De ontvangst van een verzoek tot evaluatie van de wijziging van changemanagement.

6.8.6   Invoer ■ SDP (Service Design Package), inclusief service charter en SAC (Service Acceptatie Criteria).

■ Wijzigingsvoorstel.

Afbeelding 6.10 Work ow wijzigingsevaluatie (Gebaseerd op bron: AXELOS)

■ RfC, wijzigingsrecord en gedetailleerde wijzigingsdocumentatie. ■ Besprekingen met stakeholders. ■ Testresultaten en -rapporten.

6.8.7   Uitvoer ■ Tussentijds(e) evaluatierapport(en) voor changemanagement.

■ Evaluatierapport voor changemanagement.

6.8.8   Kritieke succesfactoren ■ Stakeholders hebben goed begrepen welke prestaties van nieuwe en gewijzigde services mogen worden verwacht.

■ Changemanagement heeft goede kwaliteitsevaluaties voor het nemen van correcte beslissingen.

6.8.9   Metrics ■ Stijging in: • Tevredenheid van de stakeholders wat betreft de nieuwe of gewijzigde services (gemeten via klantonderzoek).

• •

Percentage evaluaties die binnen de afgesproken tijd worden geleverd. Tevredenheid met het wijzigingsevaluatieproces onder changemanagementpersoneel (gemeten in regelmatige onderzoeken).

■ Daling in het aantal: • Incidenten voor nieuwe of gewijzigde services door het niet leveren van de utility en de warranty die werden verwacht.

•

Wijzigingen die moeten worden teruggedraaid door onverwachte fouten of mislukkingen.

•

Mislukte wijzigingen.

6.8.10   Uitdagingen ■ Ontwikkelen van standaard prestatiemetingen en meetmethoden over projecten en leveranciers heen.

■ De verschillende standpunten van stakeholders begrijpen. ■ Begrijpen en in staat zijn in te schatten hoe de balans er uit moet zien tussen beheren en nemen van risico’s.

■ Meten en aantonen van de variatie in voorspellingen tijdens en na transitie. ■ Op een pragmatische en weloverwogen wijze leren omgaan met risico’s. ■ Effectief communiceren van de houding ten opzichte van en methode voor risicomanagement van de organisatie tijdens de risico-evaluatie.

■ Een grondig begrip opbouwen van hoe risico’s het succes van servicetransitie kunnen beïnvloeden.

■ Aanmoedigen van een cultuur waarin mensen informatie delen.

6.8.11   Risico’s ■ Gebrek aan een helder begrip van wanneer wijzigingsevaluatie nodig is. ■ Niet-realistische verwachtingen ten aanzien van de tijd die nodig is om de wijzigingsevaluatie volledig uit te voeren.

■ Personeel met onvoldoende ervaring of organisatorische autoriteit om invloed te kunnen hebben op de wijzigingsautoriteit.

■ Inaccurate schatting van datums voor oplevering door het project of de serviceprovider.

■ 6.9   KENNISMANAGEMENT 6.9.1   Inleiding Het doel van kennismanagement is ervoor zorgdragen dat ervaringen, ideeën en informatie dusdanig gedeeld (kunnen) worden dat beslissingen op basis van juiste en volledige informatie tot stand komen zonder dat daarvoor iedere keer weer het wiel opnieuw uitgevonden hoeft te worden.

De

doelstellingen van kennismanagement zijn:

■ Verbeteren van de kwaliteit van het besluitvormingsproces (door het management) door ervoor te zorgen dat betrouwbare informatie beschikbaar is gedurende de service-levenscyclus.

■ De serviceprovider ondersteunen om de efficiëntie en de kwaliteit van de services te verbeteren.

■ Zorgen dat het personeel van de serviceprovider beschikt over een helder en gedeeld begrip van de wijze waarop hun services/serviceverlening waarde oplevert voor de klanten.

■ Het onderhouden van Service Knowledge Management Systeem (SKMS). ■ Verzamelen, analyseren, opslaan, delen, gebruiken en onderhouden van kennis, informatie en data.

Bereik Kennismanagement wordt gebruikt gedurende de gehele levenscyclus.

Waarde voor de business Kennismanagement is bijzonder belangrijk gedurende de servicetransitie, omdat relevante en juiste kennis een van de belangrijkste elementen van de

servicetransitie is. Specifieke voorbeelden van de toepassing van kennismanagement tijdens servicetransitie zijn:

■ Training en kennisoverdracht, intellectueel eigendom, complianceinformatie en standaarden.

■ De documentatie van fouten, workarounds en testinformatie. Basisbegrippen Kennismanagement wordt vaak gevisualiseerd met behulp van de structuur:

DIKW-

Data-Informatie-Kennis-Wijsheid (afbeelding 6.11).

De basis van het servicekennismanagementsysteem (SKMS) van de service wordt gevormd door een aanzienlijke hoeveelheid data opgeslagen in een centrale database of configuratiemanagementsysteem (CMS) en in de configuratiemanagementdatabase (CMDB). De CMDB voedt het CMS en de CMS levert invoer voor het SKMS en ondersteunt dus het besluitvormingsproces. Het bereik van het SKMS is echter breder: er wordt ook informatie opgeslagen die verband houdt met zaken als:

■ De ervaring en competenties van het personeel. ■ Omgevingsaspecten zoals het gedrag van gebruikers en de prestaties van de organisatie.

■ Eisen en verwachtingen van de serviceproviders en partners. ■ Kwalitatieve informatie, zoals die gevonden kan worden op (interne) SharePoint sites en wiki’s.

Afbeelding 6.11 Het DIKW-model (Bron: AXELOS)

6.9.2   Activiteiten, methoden en technieken Kennismanagement bestaat uit de volgende activiteiten, methoden en technieken: 1. Kennismanagementstrategie. 2. Kennisoverdracht. 3. Data- en informatiemanagement. 4. Het gebruik van het SKMS.

1. Kennismanagementstrategie Een organisatie heeft een overall-kennismanagementstrategie nodig. Als die strategie er al is, kan de servicekennismanagementstrategie hierop inhaken. De kennismanagementstrategie richt zich ook specifiek op het documenteren van relevante kennis en op de data en informatie die deze kennis ondersteunen.

2. Kennisoverdracht De overdracht van kennis is een uitdagende taak. Allereerst is er een analyse nodig is om te bepalen wat het hiaat in kennis is tussen de afdeling of persoon die de kennis heeft en degenen bij wie die kennis ontbreekt. Op basis van de

uitkomst van deze analyse wordt een communicatie(verbeter)-plan geformuleerd dat de kennisoverdracht faciliteert.

3. Data- en informatiemanagement Data- en informatiemanagement omvat de volgende activiteiten:

■ Vaststellen van de informatiebehoeften. ■ Formuleren van de informatie-architectuur. ■ Vaststellen van data- en informatiemanagementprocedures. ■ Evalueren en verbeteren.

Afbeelding 6.12 Voorbeeld SKMS (Bron: AXELOS)

4. Gebruik van het SKMS Services leveren aan klanten in verschillende tijdzones en regio’s en met verschillende werktijden stelt zware eisen aan het delen van kennis. Om die reden moet de serviceprovider een SKMS-systeem ontwikkelen dat beschikbaar is voor alle stakeholders en voldoet aan alle informatiebehoeften.

Naast het opnemen van materiaal voor training en kennisvergaring zijn de volgende activiteiten nuttig:

■ Terminologielijsten (van IT en de business) en hun vertaling(en) verwerken in het sys-teem.

■ Documenteren van de operationele processen en hun interfaces met IT. ■ Opnemen van SLA’s en andere contracten die als gevolg van een servicetransitie kunnen wijzigen.

■ Opnemen van bekende fouten, workarounds en procesdiagrammen.

6.9.3   Informatiemanagement ■ Het SKMS bestaat uit een groot aantal tools en opslagplaatsen die ofwel onafhankelijk werken of binnen een federatief model dat kruisverwijzing toestaat en zo extra waarde creëert.

■ Het belangrijkste aspect van informatiemanagement is te begrijpen welke data, informatie en kennis de organisatie werkelijk nodig heeft en die te documenteren.

6.9.4   Interfaces ■ Het SKMS kan alleen werkelijk effectief zijn als al het personeel het, gedurende de uitvoering van alle procesactiviteiten, gebruikt om data en informatie in op te slaan en die te beheren. Alle processen die hun data en informatie managen zouden dat moeten doen volgens de principes en concepten zoals kennismanagement die hanteert.

■ Het kiezen voor een kennismanagementtool zal gevolgen hebben voor de toolselectie voor alle andere servicemanagementprocessen en vice versa.

6.9.5   Aanleidingen (triggers) ■ Klantrelatiebeheer slaat de notulen op van een vergadering met de klant. ■ Updates van de servicecatalogus of de serviceportfolio. ■ Wijziging van een serviceontwerppakket. ■ Opstellen of bijwerken van een capaciteitsplan. ■ Ontvangst van een bijgewerkte gebruikershandleiding van een serviceprovider.

■ Opgesteld klantrapport. ■ Updates in het CSI-register.

6.9.6   Invoer ■ Onder invoer voor kennismanagement vallen alle data, informatie en kennis die de serviceprovider gebruikt, alsmede de relevante zakelijke gegevens.

6.9.7   Uitvoer ■ De kennis, beheerd in het SKMS, die nodig is voor het nemen van besluiten over en het managen van IT-services.

■ Fouten die zijn ontdekt tijdens een servicetransitie worden beschikbaar gesteld voor het personeel dat betrokken is bij serviceproductiefuncties.

6.9.8   Kritieke succesfactoren ■ Beschikbaarheid van informatie en kennis die de besluitvorming van het management ondersteunt.

■ Vermindering van de tijd en inspanning benodigd voor het ondersteunen en onderhouden van services.

■ Succesvolle implementatie van nieuwe en gewijzigde services met weinig fouten die voortkomen uit een gebrek aan informatie of kennis.

■ Verbeteren van het managen van standaarden en beleidsregels. ■ Minder afhankelijk zijn van medewerkers als het gaat om kennis.

6.9.9   Metrics ■ Minder doorsturen van problemen naar andere personen, en meer oplossingen aangedragen door het lagere niveau.

■ Materiaal in documentatie zoals procedures, testontwerp en servicedeskscripts wordt vaker hergebruikt.

■ Een hoger percentage incidenten dat wordt opgelost met behulp van bekende fouten.

■ Een hoger percentage succesvolle servicetransities. ■ Meer gebruik van standaarden en beleidsregels in het SKMS. ■ Een hoger percentage standaarden en beleidsregels dat op tijd is beoordeeld. ■ Een hoger percentage zoekacties in het SKMS waarvan het resultaat als ‘goed’ wordt beoordeeld door de gebruikers, het IT-personeel en het management.

6.9.10   Uitdagingen

■ Rechtvaardiging van de inspanning die nodig is om een consistente architectuur te creëren voor het managen van data, informatie en kennis.

■ Alle stakeholders moeten inzien en begrijpen wat de algehele toegevoegde waarde is van kennismanagement. Ook ten aanzien van hun eigen processen en activiteiten.

6.9.11   Risico’s ■ Te veel focus op de technologie in plaats van op het creëren van waarde. ■ Te weinig inzicht in welke informatie en kennis de organisatie behoefte heeft.

■ Er wordt onvoldoende geïnvesteerd in plannen, ontwerpen en het implementeren en onderhouden van het SKMS, inclusief technologie en personeel.

■ Te veel gericht zijn op kennisvergaring ten koste van kennisoverdracht en hergebruik.

■ Opslaan en delen van verouderde en irrelevante data, informatie en kennis. ■ Gebrek aan ondersteuning en betrokkenheid van stakeholders.

■ 6.10   ORGANISATIE Gewoonlijk worden de activiteiten van een proces niet uitgevoerd door een enkele afdeling. De verschillende activiteiten, bijvoorbeeld van SACM, worden uitgevoerd door afdelingen zoals serviceproductie, applicatiemanagement, netwerkbeheer en systeembeheer. De procesactiviteiten worden daarom gekoppeld aan diverse IT-afdelingen en het personeel daarvan. Rollen en verantwoordelijkheden dienen ook geformuleerd te worden.

6.10.1   Generieke rollen Proceseigenaar – De proceseigenaar zorgt dat alle procesactiviteiten worden uitge voerd en:

■ is verantwoordelijk voor de processtrategie en assisteert in het ontwerp; ■ zorgt voor procesdocumentatie, richtlijnen en procedures en hun toepassing;

■ zorgt dat er voldoende resources zijn.

Service-eigenaar – De service-eigenaar heeft verantwoordelijkheid ten opzichte van de klant, voor de initiatie, transitie en het onderhoud van een service en: ■ is de contactpersoon die ervoor zorgt dat de service voldoet aan de eisen; ■ identificeert verbeterpunten en levert gegevens en rapporten voor het bewaken van de service;

■ legt verantwoording af aan het IT-management voor de levering van de service.

6.10.2   Organisatorische context De interfaces van andere afdelingen en derde partijen in servicetransitie moeten bekend en helder omschreven zijn. Programma’s, projecten, serviceontwerp en de serviceprovider dragen allemaal bij aan de servicetransitie.

Servicetransitie wordt actief gemanaged door een

transitiemanager. De

servicetransitiemanager is verantwoordelijk voor het dagelijkse management en heeft de controle over de servicetransitieteams en hun activiteiten. Een voorbeeld van een servicetransitieorganisatie is te zien in afbeelding 6.13.

6.10.3   Servicetransitierollen en -verantwoordelijkheden In deze paragraaf wordt een aantal rollen en verantwoordelijkheden binnen servicetransitie beschreven, maar enkele rollen vallen ook binnen andere levenscyclusfasen. Afhankelijk van de grootte van de organisatie en het bereik van de service die wordt gewijzigd, kunnen deze rollen worden uitgevoerd door één persoon.

Onder de verantwoordelijkheden van de

serviceasset- &

configuratiemanager vallen: ■ Formuleren van procesdoelstellingen en doorvoeren van het beleid, de processtandaarden, plannen en procedures.

■ Evalueren van bestaande configuratiemanagementsystemen en implementeren van de nieuwe systemen.

Afbeelding 6.13 Voorbeeld servicetransitieorganisatie (Bron: AXELOS)

■ Aangeven van het bereik en de functie van het proces, welke items beheerd en welke informatie verkregen moeten worden.

■ Zorgdragen voor communicatie over het proces en dit bekend maken. ■ Zorgdragen voor resources en training. ■ Opzetten van de identificatie en naamgevingsconventies van CI’s. ■ Zorgdragen voor de evaluatie van toolgebruik. ■ Opzetten van interfaces met andere processen. ■ Evalueren van bestaande CMS-systemen en implementeren van nieuwe systemen.

■ Plannen van de invulling van CMS in de CMDB’s. ■ Opstellen van rapporten. ■ Assisteren bij audits en zorgdragen voor correctieve acties. Onder de verantwoordelijkheden van de kunnen worden gedelegeerd) vallen:

changemanager (waarvan sommige

■ Ontvangen, vastleggen en prioriteren (in samenwerking met de initiatiefnemer) van RfC’s, afwijzen van RfC’s op basis van de overeengekomen criteria.

■ Voorbereiden en voorzitten van vergaderingen van de CAB en ECAB. ■ Beslissen wie deelneemt aan vergaderingen, RfC’s ontvangt en wat moet worden gewijzigd.

■ Wijzigingschema’s (Schedules of Changes, SC’s) publiceren. ■ Onderhouden van wijzigingslogboeken. ■ Afsluiten van RfC’s. ■ Evalueren van doorgevoerde wijzigingen. ■ Opstellen van rapporten. De

change advisory board (CAB) is een adviserend orgaan. De specifieke

rollen en verantwoordelijkheden van de CAB zijn uitgewerkt in paragraaf 6.4.

Onder de verantwoordelijkheden van

release & deployment manager

vallen:

■ De uiteindelijke releaseconfiguratie. ■ Samenstellen van de uiteindelijke release en testen ervan (voor de onafhankelijke test).

■ Bekende fouten en workarounds communiceren. ■ Input leveren voor de uiteindelijke implementatieafmelding. ■ De uiteindelijke implementatie van de service. ■ Coördinatie van alle releasedocumentatie, -opmerkingen en communicatie. ■ Planning van de uitrol in combinatie met changemanagement, kennismanagement en SACM.

■ Begeleiding van het releaseproces. ■ Geven van feedback over de effectiviteit van een release. ■ Vastleggen van metrics voor de uitrol om overeenstemming met de SLA’s te garanderen.

ITIL onderkent de volgende rollen binnen de servicetransitiefase van de servicelevenscyclus, maar deze vallen buiten de kaders van dit boek en het ITIL Foundations-examen:

■ Configuratieanalist. ■ Configuratiemanager.

■ CMS-manager. ■ Configuratiemanagementteam. ■ Wijzigingsautoriteit. ■ Risico-evaluatiemanager. ■ Kennismanager. ■ Testsupport. ■ Early Life Support (ELS). ■ Managen van samenstelling en testomgeving.

6.10.4   Managen van verandering Aanzienlijke wijziging van een service betekent ook een wijziging van de organisatie. Die kan variëren van ‘de overdracht van een personeelslid aan een andere afdeling’ tot grote wijzigingen zoals ‘de manier van werken in de organisatie’. Bijvoorbeeld: een post-orderbedrijf verkoopt zijn producten niet langer via een gedrukte catalogus maar via een website.

De volgende aspecten zijn belangrijk bij het managen van veranderingen in een organisatie:

■ De emotionele aspecten van verandermanagement. ■ De rol van servicetransitie in organisatieverandering. ■ Planning en implementatie van organisatieverandering. ■ Evalueren of men gereed is voor de organisatieverandering. ■ Voortgangsbewaking. ■ Het managen van de organisatorische gevolgen van besluitvorming met betrekking tot de sourcing van IT-services. Bijvoorbeeld het besluit om een (deel van de) de IT-infrastructuur te outsourcen.

6.10.5   Stakeholdersmanagement Stakeholdermanagement is een cruciale succesfactor in servicetransitie. Dit is de reden waarom een strategie moet worden ontwikkeld in de serviceontwerpfase. Daarin wordt bepaald:

■ Wie de stakeholders zijn. ■ Wat hun belangen zijn. ■ Wat hun invloed is. ■ Hoe ze in het project of programma zijn opgenomen. ■ Welke informatie met hen wordt gedeeld.

Een stakeholdermatrix is een handig hulpmiddel om de verschillende standpunten van de stakeholders in kaart te brengen (afbeelding 6.14).

Afbeelding 6.14 Voorbeeld van een stakeholdersanalyse in matrixvorm (Bron: AXELOS) Verder helpt een

stakeholderanalyse

om na te gaan welke behoeften en

interesses de stakeholders hebben en wat hun uiteindelijke invloed en macht zullen zijn tijdens de transitie.

En tot slot moet ook stilgestaan worden bij het personeelsverloop dat plaatsvindt gedurende de servicelevenscyclus. Er vindt in de praktijk een voortdurende in-, door- en uitstroom van betrokkenen (stakeholders) plaats met alle gevolgen van dien voor de kennis over de serviceverlening, onderlinge afspraken en wijzen van communiceren.

■ 6.11   METHODEN, TECHNISCHE SYSTEMEN EN TOOLS

Technische systemen hebben een belangrijk aandeel in de ondersteuning van servicetransitie. Deze technische systemen kunnen worden verdeeld in twee soorten:

■ IT-servicemanagementsystemen: • ERP-systemen (Enterprise Resource Planning) die mogelijkheden bieden voor integratie en koppeling met de CMDB of andere tools.

• Systeem-, netwerk en applicatiemanagementtools. • Servicedashboards en rapportagetools ■ Specifieke technische systemen en tools voor ITSM • Servicekennismanagementsystemen. • Samenwerkingstools, contentmanagementsystemen en workflowtools. • Tools voor datamining, dataextractie en datatransformatie. • Tools voor meten en rapporteren. • Test(management)tools. • Publicatietools. • Technieken voor release- en uitrol Bovendien zijn er gespecialiseerde tools beschikbaar voor changemanagement, configuratiemanagement en releasemanagement, zoals:

■ Configuratiemanagement. ■ Tools voor versiecontrole. ■ Documentmanagementsystemen. ■ Ontwerptools. ■ Distributie- en installatietools. ■ Constructie- en uitroltools.

■ 6.12   IMPLEMENTATIE De implementatie van servicetransitie vanaf nul is alleen uitvoerbaar wanneer er sprake is van een nieuwe serviceprovider. De meeste serviceproviders richten zich op de verbetering van de servicetransitie(processen). Voor de verbetering van servicetransitie(processen) zijn de volgende vijf aspecten ook belangrijk: 1. Rechtvaardiging. 2. Ontwerp. 3. Introductie.

4. Culturele aspecten. 5. Risico’s en voordelen.

Hoewel dit boek servicetransitie presenteert als een min of meer afgebakende levenscyclusfase, betekent dit niet dat het op zichzelf kan worden beschouwd. Zonder de input van serviceontwerp en de output naar serviceproductie, heeft servicetransitie geen zin.

6.12.1   Uitdagingen Voor een succesvolle servicetransitie moet aan verschillende uitdagingen het hoofd worden geboden, zoals:

■ Rekening houden met alle stakeholders (en hun verschillende standpunten) en rela-ties onderhouden die van belang kunnen zijn binnen servicetransitie.

■ Harmonisatie en integratie van processen en disciplines die servicetransitie beïnvloeden.

■ De balans vinden tussen een stabiele operationele omgeving en in staat zijn om flexibel te reageren op wijzigende zakelijke eisen.

■ De balans vinden tussen pragmatisme en bureaucratie. ■ Een omgeving creëren waarin standaardisatie en delen van kennis wordt bevorderd.

■ Een cultuur creëren waarin men openstaat voor samenwerking en culturele wijzigingen.

■ Zorgen dat de kwaliteit van services correspondeert met die van de business. ■ De balans vinden tussen ‘risico’s nemen’ en ‘risico’s vermijden’, een balans die moet corresponderen met die van de business.

■ De integratie met andere levenscyclusfasen, processen en disciplines. ■ Een heldere definitie van de rollen en verantwoordelijkheden.

6.12.2   Kritieke succesfactoren ■ Steun vanuit het management. ■ Steun vanuit de business. ■ Werving en behoud van goed gekwalificeerd personeel. ■ Personele opleidingen en trainingen gerelateerd aan servicemanagement. ■ Beschikken over adequate tooling. ■ Kwaliteit van het testen is dusdanig dat daardoor introductie van (onnodige) fouten in de operationele omgeving voorkomen kan worden.

■ In staat zijn te meten en te rapporteren.

6.12.3   Risico’s Potentiële risico’s van servicetransitie zijn:

■ Demotivatie van personeel als gevolg van gewijzigde verantwoordelijkheden en rollen.

■ Onvoorziene uitgaven. ■ Weerstand tegen wijziging. ■ Gebrek aan delen van kennis. ■ Onvoldoende integratie tussen processen. ■ Gebrek aan groei/ontwikkeling en integratie van systemen en tools.

■ 7.1   INLEIDING TOT SERVICEPRODUCTIE Goed ontworpen en doorgevoerde processen zijn van weinig waarde als de dagelijkse invulling van deze processen niet goed is georganiseerd. Ook zijn serviceverbeteringen niet mogelijk indien de dagelijkse prestatiemetingen, en de activiteiten waarbij data wor-den verzameld, niet systematisch worden uitgevoerd tijdens serviceproductie.

De vijf nauw verbonden processen in de serviceproductiefase zijn (zie ook figuur 7.0): 1. Eventmanagement. 2. Incidentmanagement. 3. Problemmanagement. 4. Request Fulfillment. 5. Accessmanagement.

Afbeelding 7.0 De 26 processen en 4 functies van ITIL, gekoppeld aan de ITILlevenscyclus

7.1.1   Doel en doelstellingen Het doel van serviceproductie is het coördineren en afwikkelen van de vereiste activiteiten en processen voor het leveren en managen van IT-services aan zakelijke gebruikers en klanten op de niveaus zoals die met hen overeengekomen zijn. Serviceproductie is ook verantwoordelijk voor het beheer van de technische systemen die nodig zijn voor het leveren en ondersteunen van de services.

De

doelstellingen van serviceproductie zijn:

■ Het in stand houden van de tevredenheid en het vertrouwen in de IT van de business door het op een effectieve en efficiënte wijze leveren van overeengekomen IT-services.

■ Het minimaliseren van de impact van service-onderbrekingen op de dagelijkse businessactiviteiten.

■ Zekerstellen dat toegang tot overeengekomen IT-services alleen verleend wordt aan diegenen die geautoriseerd zijn om van die services gebruik te maken.

7.1.2   Bereik Serviceproductie gaat over de processen, functies, organisatie en de tooling, die gebruikt worden om de operationele activiteiten mogelijk te maken. Deze activiteiten worden uitgevoerd om de IT-services te leveren en te ondersteunen conform afspraken. Hierbij gaat het om de:

■ IT-services zelf; ■ servicemanagementprocessen; ■ technische systemen, en: ■ de mensen (IT’ers én de niet-IT’ers).

■ 7.2   MONITOREN EN CONTROLEREN 7.2.1   Inleiding Het controleren van services in de serviceproductiefase is gebaseerd op een continue cyclus van monitoren, rapporteren en initiëren van acte. We bespreken deze cyclus in detail, omdat deze essentieel is voor de levering, ondersteuning en verbetering van de services.

Basisbegrippen Monitoren: verwijst naar het observeren van een situatie om wijzigingen te ontdekken die zich in de loop van de tijd voordoen. Rapporteren: verwijst naar het analyseren, produceren en distribueren van de uitkomst van de activiteit die wordt gemonitord. Controle: verwijst naar het managen van de bruikbaarheid of gedrag van een apparaat, systeem of service. Er zijn drie voorwaarden voor controle: 1. De actie moet ervoor zorgen dat het gedrag voldoet aan een geformuleerde standaard of norm. 2. De voorwaarden die tot een actie leiden moeten geformuleerd, begrepen en bevestigd zijn. 3. De actie moet beschreven en goedgekeurd zijn, en passen binnen deze voorwaarden.

7.2.2   De monitorings- en controlecyclus Het bekendste beheermodel is de monitorings- en controlecyclus. Hoewel het een eenvoudig model is, heeft het veel complexe toepassingen in ITservicemanagement. In deze paragraaf beschrijven we de basisbegrippen van het model. Vervolgens zullen we tonen hoe belangrijk deze begrippen zijn

voor de levenscyclus van servicemanagement. Afbeelding 7.1 toont de basisprincipes van dit controlemodel.

Afbeelding 7.1 Regelkring voor voortgangscontrole (Bron: AXELOS) Deze cyclus meet een activiteit en de opbrengsten met behulp van een vooraf bepaalde norm of standaard. Aan de hand daarvan wordt bepaald of de resultaten voldoen wat betreft de prestatie of kwaliteit. Als dat niet het geval is, moet er actie worden ondernomen om de situatie te verbeteren of om de prestatie weer op normale peil te krijgen.

Er zijn twee soorten monitoring en controlecycli: open en gesloten cyclussystemen.

Afbeelding 7.2 toont een complexe monitorings- en controlecyclus: een proces dat bestaat uit drie belangrijke activiteiten. Elke activiteit heeft een invoer en uitvoer en de uitvoer is vervolgens de invoer voor de volgende activiteit. Elke activiteit wordt gecontroleerd door een eigen cyclus van monitoring en controle met behulp van een aantal normen voor die specifieke activiteit. Een coördinerende monitoring en controlecyclus bewaakt het totale proces en zorgt dat alle normen geschikt zijn en worden nageleefd.

Een monitorings- en controlecyclus kan worden gebruikt voor het beheersen van:

■ De prestaties van activiteiten in een proces of procedure; in theorie kan elke activiteit en bijbehorende uitvoer worden gemeten om te zorgen dat problemen in het proces worden vastgesteld voor het proces is afgerond.

■ De effectiviteit van het proces of de procedure als geheel. ■ De prestatie van een apparaat of reeks apparaten. Afbeelding 7.3 toont een monitorings- en controlecyclus voor ITservicemanagement en hoe de controle van een proces, of de componenten van dat proces, ingezet kan (kunnen) worden om een service te leveren.

Er zijn twee niveaus waarop gemonitord wordt: intern monitoren en controle en extern monitoren en controle.

Monitoren zonder controle is ontoepasbaar en ineffectief. Het monitoren moet altijd gericht zijn op realisatie van de service en op de operationele doelstellingen. Als er geen duidelijke reden bestaat voor het toezicht houden op een systeem of service, moet het monitoren achterwege blijven.

Opdat een organisatie kan bepalen wat ze wil bewaken, moet eerst het gewenste resultaat worden bepaald als het gaat om

toezicht en

controledoelstellingen. Idealiter zou dit proces moeten beginnen met de definitie van serviceleveleisen.

7.2.3   Tools (instrumenten/hulpmiddelen)

■ Actief versus passief monitoren: • Actief monitoren verwijst naar de continue ‘ondervraging’ van een apparaat of sys-teem om de status ervan te bepalen.

•

Passief monitoren is meer algemeen bekend en heeft betrekking op het automatisch doorgeven van statusveranderingen van een systeem aan een monitoringtool.

■ Reactief versus proactief monitoren: • Reactief monitoren is bedoeld om een actie te initiëren na een bepaalde gebeurtenis of storing.

•

Proactief monitoren wordt gebruikt om patronen van incidenten te traceren die erop wijzen dat een systeem of apparaat kan gaan falen.

Afbeelding 7.2 Voorbeeld van een complexe regelkring voor voortgangscontrole (Bron: AXELOS)

Afbeelding 7.3 Voorbeeld van een ITSM-regelkring voor voortgangscontrole (Bron: AXELOS)

■ Continu meten versus op uitzondering gebaseerde meting: • Continu meten is gericht op de real-time-bewaking van een systeem om ervoor te zorgen dat het voldoet aan een bepaalde prestatienorm.

•

Op uitzondering (exceptie) gebaseerde meting meet niet de huidige prestatie van een service of systeem, maar ontdekt en rapporteert uitzonderingen.

■ Prestatie versus uitvoer • Er is een belangrijk verschil tussen rapporteren over de prestatie van componenten of die van medewerkers versus het rapporteren over de output – de kwaliteitsdoelen van de service – die gerealiseerd is.

■ 7.3   EVENTMANAGEMENT 7.3.1   Inleiding

Events zijn gewoonlijk meldingen (notificaties) aangemaakt door een ITservice, CI of bewakingstool. Om te zorgen voor effectieve serviceproductie moet een organisatie zich bewust zijn van de status van haar infrastructuur en in staat zijn afwijkingen van de reguliere of verwachte werking te ontdekken. Goede bewaking en controlesystemen zijn vereist.

Het

doel van eventmanagement is de beheersing van ‘events’ door hun hele

levenscyclus heen: detectie, toekennen van betekenis en het vaststellen van de juiste controleactie.

De

doelstellingen van eventmanagement zijn:

■ De detectie en interpretatie van alle toestandswijzigingen die van betekenis zijn voor het beheren van een CI of een IT-service.

■ Het vaststellen van de juiste controleactie voor events en ervoor zorgen dat betreffende functies daarover geïnformeerd worden.

■ Het verschaffen van de ‘trigger’ of startpunt voor de uitvoering van diverse service-productieprocessen en operationele beheeractiviteiten.

■ In staat zijn om de actuele operationele performance en systeemgedrag te vergelijken met de ontwerpstandaarden en SLA’ s.

■ Een basis verschaffen voor rapportage en verbetering van de services. Bereik Eventmanagement kan worden toegepast op elk aspect van servicemanagement waarvoor controle is vereist en dat geautomatiseerd kan worden. Voorbeelden zijn configuratie-items, beveiliging, softwarelicentiebewaking en omgevingscondities (bijvoorbeeld vuur- en rookalarmering).

Het verschil tussen monitoring en eventmanagement Monitoring en eventmanagement zijn nauw verwant, maar verschillen wel iets van karakter. Eventmanagement is gericht op het genereren en opsporen van betekenisvolle meldingen over de status van de IT-infrastructuur en services.

Waarde voor de business Eventmanagement heeft gewoonlijk indirecte waarde. Voorbeelden van voordelen voor de business zijn:

■ Eventmanagement levert mechanismen voor vroegtijdige detectie van incidenten.

■ Eventmanagement maakt het mogelijk dat bepaalde soorten geautomatiseerde activiteiten op basis van uitzonderingen worden bewaakt.

■ Als eventmanagement is geïntegreerd in andere servicemanagementprocessen, kan het statuswijzigingen of uitzonderingen opsporen en daardoor kan de juiste persoon of het juiste team sneller reageren en daarmee de procesprestaties verbeteren.

■ Eventmanagement levert een basis voor geautomatiseerde productie wat de effectiviteit verbetert en kostbare mankracht vrijmaakt voor innovatiever werk.

Basisbegrippen ITIL formuleert een event als volgt:

Een event kan worden omschreven als een toestandswijziging die betekenis heeft voor het beheer van een con guratie-item (CI) of IT-service. Er zijn veel verschillende soorten events, zoals:

■ Informerende events die op een normale productie duiden, zoals een gebruiker die inlogt om een applicatie te gebruiken.

■ Uitzonderlijke events die duiden op een uitzondering, zoals een gebruiker die probeert in te loggen op een applicatie met een verkeerd wachtwoord, of een pc-scan die laat zien dat niet-geautoriseerde software is geïnstalleerd.

■ Waarschuwingsevents die een ongebruikelijke maar niet uitzonderlijke werking aangeven. Dit kan een indicatie zijn dat de situatie wat meer toezicht vereist. Bijvoorbeeld, het gebruikte geheugen van de server komt binnen de vijf procent van het hoogste acceptabele niveau.

7.3.2   Activiteiten, methoden en technieken Afbeelding 7.4 toont een voorbeeld van een workflow (stroomdiagram) voor event-management. Net zoals alle voorbeelden van workflows in dit boek, is afbeelding 7.4 bedoeld als een generieke weergave en dient slechts als referentie. De figuur moet niet beschouwd en gebruikt worden als werkelijke workflow voor het eventmanagementproces.

De hoofdactiviteiten van het eventmanagementproces zijn hieronder samengevat.

1. Event vindt plaats Events vinden voortdurend plaats, maar worden niet allemaal ontdekt of geregistreerd. Het is daarom belangrijk dat allen die betrokken zijn bij het ontwerpen, ontwikkelen, beheren en ondersteunen van IT-services, en de ITinfrastructuur waarop deze draaien, begrijpen op welke soorten events moet worden gelet.

Afbeelding 7.4 Voorbeeld van work ow van eventmanagement (Bron: AXELOS)

2. Eventmelding Veel CI’s worden zo geconfigureerd dat zij een standaard verzameling events genereren, gebaseerd op de ervaring van de ontwerper van wat vereist is om de CI te laten werken, met de mogelijkheid extra eventtypen te genereren door

de relevante eventgeneratiemechanismen ‘aan te zetten’. Voor andere CI-typen zal een soort ‘agent’-software geïnstalleerd moeten worden om de bewaking in gang te zetten.

3. Eventdetectie Zodra een eventmelding is gegenereerd, zal die worden opgemerkt door een agent die op hetzelfde systeem draait of direct worden doorgegeven aan een beheertool dat speciaal is ontworpen om het event te lezen en te interpreteren.

4. Logbestand van events Er moet een record zijn van het event en eventuele vervolgacties. Het event kan worden gelogd als een eventrecord in de eventmanagementtool, of het kan eenvoudig een opgevoerd item zijn in de systeemlog van het apparaat dat, of de applicatie die, het event genereerde. In elk geval moet voor de betreffende productiemedewerkers de regel gelden dat ze loggegevens regelmatig controleren op basis van duidelijke instructies hoe die logbestanden gebruikt moeten worden.

5. Eventcorrelatie en -filtering op het eerste niveau Het doel van eventcorrelatie en -filtering is om op het eerste niveau te beslissen of het event aan een beheertool moet worden doorgegeven of niet. Zo niet, dan wordt het event gewoonlijk vastgelegd in een logbestand op het apparaat, maar wordt er verder geen actie ondernomen.

6. Belang van events Elke organisatie zal een eigen indeling hebben van de betekenis/belangrijkheid van een event, maar het is raadzaam om ten minste drie brede categorieën te onderscheiden:

■ Informatief – een event dat geen actie vereist en geen uitzondering vertegenwoordigt, bijvoorbeeld het inloggen van een gebruiker op een applicatie. Wordt meestal opgeslagen in het systeem- of servicelogbestanden en voor een bepaalde tijd bewaard.

■ Waarschuwing (alert) – ontstaat als een service of een apparaat een drempelwaarde bereikt. Waarschuwt de aangewezen persoon, proces of tool, zodat deze de situatie onder controle kan brengen en de juiste actie kan ondernemen om een uitzondering te voorkomen. Eén voorbeeld van een

alert: de benutte geheugencapaciteit op een server is momenteel 65 procent en neemt toe. Als ze de 75 procent bereikt, zijn de responstijden te hoog en wordt de OLA of SLA overschreden.

■ Exceptie

– betekent dat een service of een apparaat zich abnormaal

gedraagt en dat een OLA of SLA niet wordt gehaald. Voorbeelden van uitzonderingen zijn:

• •

Een server ligt eruit. De responstijd van een standaardtransactie over het netwerk is groter dan vijftien seconden.

•

Een onderdeel van het netwerk reageert niet op routineverzoeken.

7. Eventcorrelatie op het tweede niveau Als een event een waarschuwing is, moet er een beslissing worden genomen over het exacte belang en de acties die nodig zijn voor de afhandeling. Hiermee wordt de betekenis van het event bepaald.

Correlatie wordt gewoonlijk gedaan door een ‘correlatiemachine’, gewoonlijk een onderdeel van een beheertool die het event vergelijkt met criteria en regels in een voorgeschreven volgorde. Deze criteria worden vaak business rules (bedrijfsregels) genoemd, hoewel ze over het algemeen vrij technisch zijn.

8. Vervolgactie noodzakelijk? Als de correlatieactiviteit op het tweede niveau een event herkent, moet er actie ondernomen worden. Op dit punt in het proces bestaat hiertoe een aantal mogelijkheden. Het is belangrijk om er rekening mee te houden dat de mogelijke acties (responses) op allerlei wijzen kunnen worden gecombineerd.

■ Automatische reactie. ■ Alarm en menselijk ingrijpen. ■ Incident, probleem of wijziging? 9. Acties evalueren Omdat er dagelijks duizenden events worden gegenereerd, is het niet mogelijk om elk afzonderlijk event formeel te beoordelen. Het is echter van belang te controleren of belangrijke events of uitzonderingen goed zijn afgehandeld, ofwel om de trends te vol-gen van het aantal eventsoorten enzovoort.

10. Event afsluiten Bepaalde events zullen open blijven tot een bepaalde actie plaatsvindt, bijvoorbeeld een event dat is gekoppeld aan een open incident. De meeste events worden echter niet geopend of gesloten.

Ontwerpen voor eventmanagement Eventmanagement is de basis voor het bewaken van de prestaties en beschikbaarheid van een service. Dat is waarom availability- en capaciteitsmanagement de precieze bewakingsdoelen en monitoringsmechanismen moeten specificeren.

7.3.3   Informatiemanagement ■ Technische informatie over de status van componenten van een ITinfrastructuur.

■ De mogelijkheid om in verschillende databronnen en bestandsformaten te zoeken en deze te vergelijken met een vooraf bepaalde norm.

■ Software-agents voor eventbewakingstools. ■ Correlatiemachines die de regels aangeven voor het bepalen van het belang van events en de toepasselijke controleacties.

7.3.4   Interfaces Eventmanagement kan een interface hebben met elk proces dat bewaking en controle vereist, real-time of niet, en waarbij enige vorm van interventie volgend op het event of de groep van events noodzakelijk is.

Serviceontwerp ■ Servicelevelmanagement – Voor het vroegtijdig detecteren van events die afbreuk kunnen doen aan de serviceleveldoelen, zodat correctieve acties tijdig in gang kunnen worden gezet.

■ Informatiebeveiligingsmanagement – Interface met bedrijfsapplicaties en/of bedrijfsprocessen om te zorgen dat events die een potentiële bedreiging (kunnen) vormen voor de beveiliging snel worden ontdekt, zodat er ook snel op kan worden gereageerd.

■ Capaciteits- en availabilitymanagement – Deze processen stellen op basis van de ontwerpeisen drempelwaarden en toepasselijke controleacties vast wat

betreft de events die betrekking hebben op de prestaties of beschikbaarheid van componenten of services.

Servicetransitie ■ Serviceasset- en configuratiemanagement – Om aan de hand van events de huidige status (binnen de levenscyclus) te bepalen van een CI in de infrastructuur.

■ Kennismanagement – Als een rijke bron van informatie die kan worden verwerkt voor opname in het SKMS (servicekennismanagementsysteem).

■ Changemanagement – Om de condities te bepalen die vragen om een antwoord of actie.

Serviceproductie ■ Incident- en problemmanagement – Om te assisteren in het oplossen van incidenten en problemen, en bij het identificeren van de condities die mogelijk vragen om een bepaalde controleactie.

■ Accessmanagement – Om pogingen tot niet-geautoriseerde toegang en beveiligingsproblemen te ontdekken.

7.3.5   Aanleidingen (triggers) ■ Uitzonderingen op ieder niveau van CI-prestaties zoals die zijn vastgesteld in de ontwerpspecificaties.

■ Uitzonderingen op een geautomatiseerde procedure of proces. ■ Een uitzondering in een bedrijfsproces dat wordt bewaakt door eventmanagement.

■ De voltooiing van een geautomatiseerde taak of opdracht. ■ Een statuswijziging in een server- of database-CI. ■ Het gebruiken van een applicatie of database door een gebruiker of geautomatiseerde procedure of opdracht.

■ Een situatie waarin een apparaat, database, applicatie en dergelijke een vooraf bepaalde prestatiedrempel heeft bereikt.

7.3.6   Invoer ■ Operationele eisen en serviceleveleisen geassocieerd met events en hun acties.

■ Drempels voor herkenning van events, waarschuwingen en alarm.

■ Eventcorrelatietabellen, regels, eventcodes en geautomatiseerde oplossingen als antwoord die eventmanagementactiviteiten mogelijk maken of ondersteunen.

■ Rollen en verantwoordelijkheden voor het nemen van de juiste acties. ■ Operationele procedures voor het identificeren, loggen, correleren, escaleren en communiceren van events.

7.3.7   Uitvoer ■ Events gecommuniceerd en geëscaleerd naar degene(n) die verantwoordelijk zijn voor verdere actie.

■ Eventlogs met de gedetailleerde beschrijving van de events, escalatie- en communicatieactiviteiten als ondersteuning voor verdere activiteiten.

■ Events die erop duiden dat een incident is opgetreden. ■ Events die erop duiden dat een wijziging is opgetreden. ■ Events die duiden op de mogelijke inbreuk op afspraken; SLA, OLA of UC. ■ Events die de status aangeven van procesactiviteiten waarover informatie vereist is.

■ SKMS bijgewerkt met eventinformatie en -geschiedenis.

7.3.8   Kritieke succesfactoren ■ Opsporen van alle toestandswijzigingen die belangrijk zijn voor het managen van CI’s en IT-services.

■ Zorgen dat alle events worden gecommuniceerd naar de functies die hierover moeten worden geïnformeerd, alsmede naar de functies die verdere controleacties moeten uitvoeren.

■ De trigger of het aanvangspunt (entry point) leveren voor het uitvoeren van service-productieprocessen en productiebeheeractiviteiten.

■ De mogelijkheid bieden om werkelijke productieprestaties en -gedrag af te zetten tegen ontwerpstandaarden en SLA’s.

■ Een basis leveren voor het waarborgen van de service, het opleveren van rapportages en verbeteringen mogelijk maken.

7.3.9   Metrics ■ Events vergeleken met het aantal incidenten. ■ Elk type event per service, systeem of component. ■ Events die menselijk ingrijpen vereisen en vaststellen of dat is gebeurd.

■ Incidenten zonder corresponderend event. ■ Events die leiden tot incidenten of wijzigingen. ■ Events veroorzaakt door bestaande problemen of bekende fouten. ■ Events die duiden op utility- of warrantyproblemen. ■ Herhaalde of gedupliceerde events.

7.3.10   Uitdagingen ■ Financiering krijgen voor de nodige tools en inspanning voor het installeren en benutten van de voordelen van die tools.

■ Het juiste filteringsniveau instellen. ■ Inzetten van de nodige bewaking in de IT-infrastructuur. ■ Geautomatiseerde bewakingsactiviteiten kunnen extra netwerkverkeer genereren en dat kan invloed hebben op geplande netwerkcapaciteitsniveaus.

■ Inkopen van de noodzakelijke expertise kan tijdrovend en kostbaar zijn. ■ Inzetten van eventmanagementtools zonder dat er een behoorlijk eventmanagementproces is.

7.3.11   Risico’s ■ Er niet in slagen om de nodige financiering te krijgen. ■ Zorgen voor het correcte niveau van filtering. ■ Er niet in slagen momentum te houden voor het inzetten van de nodige bewaking in de IT-infrastructuur.

■ 7.4   INCIDENTMANAGEMENT 7.4.1   Inleiding Het incidentmanagementproces handelt alle incidenten af. Dit kunnen storingen zijn, die zijn gemeld door gebruikers (gewoonlijk via een telefoontje naar de servicedesk) of door het technisch personeel. Maar het kan ook om storingen gaan die automatisch zijn gedetecteerd en gerapporteerd door tools die events bewaken.

Het

doel van incidentmanagement is:

■ om in geval van incidenten de normale serviceproductie zo snel als mogelijk weer te herstellen;

■ het zo veel mogelijk beperken van de negatieve gevolgen (impact) van een incident op (de werkzaamheden van) de business;

■ het zekerstellen dat de best mogelijke niveaus van de kwaliteit en beschikbaarheid van de service gehandhaafd blijven.

‘Normale serviceproductie’ wordt omschreven als een operationele toestand waarin services en CI’s presteren binnen de daarvoor afgesproken service en operationele niveaus.

De doelstellingenvan incidentmanagement zijn: ■ Zekerstellen dat standaard methoden en procedures gebruikt worden. ■ Goed informeren en communiceren over de status en wijze van afhandeling van aangemelde incidenten.

■ Verhogen van de kwaliteit van de IT-serviceverlening zoals die door de business wordt ervaren.

■ Prioriteren van aangemelde of gesignaleerde incidenten en erop toezien dat deze prioritering en daaruit voortvloeiende activiteiten in lijn zijn met de impact en gevol-gen van die incidenten voor de business.

■ Ervoor zorgen dat de gebruikers tevreden blijven over de kwaliteit van de IT-services.

Bereik Incidentmanagement handelt over iedere gebeurtenis, die een service onderbreekt of kan onderbreken. Incidenten kunnen door de gebruikers, maar ook door de technische staf, direct gemeld worden bij de servicedesk (telefonisch of via de mail), of met behulp van een daartoe ingericht portal of servicemanagementtool worden gemeld en gelogd.

Hoewel incidenten en service requests beide aan de servicedesk worden gemeld, zijn ze niet hetzelfde. Service requests zijn geen serviceonderbrekingen maar verzoeken van de gebruikers om ondersteuning, advies of informatie en om levering van een standaard-service of documentatie.

Waarde voor de business ■ De mogelijkheid om incidenten te volgen en op te lossen resulteert in minder downtime voor de business. Het gevolg daarvan is dat de service

langer beschikbaar is.

■ De mogelijkheid om de wijze van incidentafhandeling (prioriteitstelling en snelheid van oplossing) af te stemmen op de prioriteiten en behoeften van de business.

■ De mogelijkheid om potentiële verbeteringen voor services te bewerkstelligen.

Incidentmanagement is duidelijk zichtbaar voor de business, wat betekent dat de waarde ervan eerder wordt aangetoond dan van andere gebieden in de serviceproductie. Om die reden is het een van de eerste processen die wordt doorgevoerd in servicemanagementprojecten.

Basisbegrippen ITIL formuleert een incident als volgt:

Een incident is een ongeplande onderbreking in een IT-service of vermindering in de kwaliteit van een IT-service. Het falen van een CI dat nog niet een service heeft beïnvloed, is ook een incident. Incidentmanagement moet met de volgende elementen rekening houden:

Tijdslimieten – Er moeten afspraken gemaakt zijn over de hoeveelheid tijd die beschikbaar is om incidenten met een bepaalde prioriteit op te lossen. Deze afspraken dienen als de te realiseren doelen opgenomen te zijn in de operational level agreements (OLA’s) en in de underpinning contracts (UC’s).

Incidentmodellen – Een incidentmodel is een manier om te bepalen welke stappen gezet moeten worden die noodzakelijk zijn om een bepaald proces correct uit te voeren (waarbij het hier gaat om het afhandelen van bepaalde incidenttype).

Major incidenten – Een afzonderlijke procedure is vereist voor ernstige incidenten, zogenoemde major incidenten, waar een kortere responstijd voor geldt en die een hoge urgentie hebben. Overeenstemming met de klant is noodzakelijk om vast te stellen wat een major incident is.

Soms wordt een ernstig incident verward met een probleem. Een incident blijft echter altijd een incident. De impact of prioriteit ervan kan stijgen, maar

het wordt nooit een probleem. Een probleem is de onderliggende oorzaak van een of meer incidenten. Het zijn afzonderlijke eenheden die ieder hun eigen registratie en wijze van afhandeling hebben.

7.4.2   Activiteiten, methoden en technieken De hoofdactiviteiten van het incidentmanagementproces zijn (zie ook afbeelding 7.5): 1. Identificatie. 2. Registratie. 3. Classificatie. 4. Prioritering. 5. Diagnose. 6. Escalatie. 7. Onderzoek en het stellen van diagnoses. 8. Oplossing en herstel. 9. Afsluiting.

1. Identificatie Het is belangrijk om zo snel mogelijk vast te stellen of een incident zich heeft voorgedaan. Dit wordt

incidentidentificatie

genoemd. Vanuit een zakelijk

oogpunt is het onacceptabel te wachten tot een gebruiker de gevolgen ervaart van een incident. De organisatie moet proberen om alle belangrijke componenten te bewaken zodat storin-gen, of potentiële storingen, zo vroeg mogelijk worden ontdekt en het incidentmanagementproces in gang kan worden gezet. In een ideale situatie worden incidenten opgelost voor zij gevolgen hebben voor gebruikers.

2. Registratie Incidentregistratie wil zeggen dat alle incidenten volledig worden geregistreerd, inclusief datum en tijd. Deze registratie geldt voor incidenten die aan de servicedesk worden gemeld en voor incidenten die automatisch worden ontdekt via een eventwaarschuwingssysteem. Door het registeren van alle relevante informatie met betrekking tot de aard van het incident verkrijgt men een compleet historisch overzicht. Als het incident dan wordt doorgezet

naar bijvoorbeeld een tweedelijns oplosgroep, dan hebben zij de beschikking over alle relevante informatie.

Afbeelding 7.5 Voorbeeld van work ow van incidentmanagement (Bron: AXELOS)

3. Classificatie

Aan de hand van de incidentregistratie kunnen incidenten worden geclassificeerd (ingedeeld).

Incidentclassificatie

wil zeggen dat incidenten

worden ingedeeld naar de impact die ze hebben op de business (bijvoorbeeld een service is niet beschikbaar of kent een slechte performance) en welke configuratie-items (CI’s) hierbij betrokken zijn (netwerk, servers, applicatie enzovoort). Classificatie van incidenten is belangrijk om in een later stadium, waarin de incidenttypen en hun frequenties worden geanalyseerd, trends vast te stellen. Deze informatie vormt een belangrijke input voor de processen problemmanagement, leveranciersmanagement alsmede voor diverse andere servicemanagementprocessen.

4. Prioritering Een ander belangrijk aspect bij het registeren van incidenten is het toewijzen van de juiste zogeheten

prioriteitscode . Supportmedewerkers en -tools

gebruiken deze code om te bepalen hoe zij het incident moeten behandelen. De prioriteit van een incident wordt bepaald door de de business een oplossing nodig?) en de

urgentie

(hoe snel heeft

impact vast te stellen. Het aantal

gebruikers dat gevolgen ondervindt van het incident is vaak een indicatie voor de impact.

5. Diagnose Wanneer een gebruiker een incident rapporteert aan de servicedesk, moet de service-deskmedewerker/-agent proberen zo veel mogelijk symptomen vast te leggen. Deze informatie vormt de input voor het stellen van een eerste

diagnose Incidentvergelijkingsprocedure Een procedure voor het vergelijken van incidentgegevens met die van problemen en bekende fouten maakt ef ciënte en snelle toegang mogelijk tot bewezen oplossingsacties, waardoor de tijd wordt gereduceerd die het kost om de service te herstellen voor de gebruikers. Deze activiteit minimaliseert de noodzaak voor escalatie naar andere supportmedewerkers.

De servicedeskmedewerker probeert ook vast te stellen wat er fout ging en hoe deze fouten kunnen worden gecorrigeerd. Diagnostische scripts en informatie over bekende fouten kunnen hierbij heel nuttig zijn. Waar mogelijk lost de

servicedeskmedewerker het incident onmiddellijk op en sluit het incident af. Als dat niet mogelijk is, wordt het incident geëscaleerd.

6. Escalatie Indien de servicedeskmedewerker vanuit de eerste lijn het incident niet kan afhandelen/oplossen binnen de tijd die daarvoor is vastgesteld, dan escaleert hij het incident naar een supportgroep in de tweede lijn (functionele escalatie). Eventueel kan ook het management geïnformeerd worden (hiërarchische escalatie).

7. Onderzoek en het stellen van diagnoses Tijdens het afhandelen van een incident onderzoekt elke supportgroep wat er fout ging. Ook wordt een diagnose gesteld. Al deze activiteiten worden in het incidentrecord gedocumenteerd zodat er een compleet overzicht van alle activiteiten beschikbaar is.

8. Oplossing, herstel en afsluiting Na het oplossen van het incident en het herstel van de service geeft de supportgroep het incident terug aan de servicedesk, die het incident afsluit . Echter voordat het incident wordt afgesloten, controleert men of het incident daadwerkelijk is opgelost en of de gebruikers tevreden zijn met de oplossing. Zijn de gebruikers tevreden, dan wordt de classificatie afgesloten en de incidentdocumentatie bijgewerkt. Ook gaat men na of het incident wellicht opnieuw zou kunnen optreden en wordt er besloten of men actie moet ondernemen om dit te voorkomen. Pas als dit alles gebeurd is, kan het incident formeel worden afgesloten.

7.4.3   Informatiemanagement De meeste informatie die in het proces incidentmanagement wordt gebruikt, is afkomstig uit de volgende bronnen: incidentmanagementtools, incidentrecords, servicecatalogus, problem records en known error records. Incidentmanagement heeft ook toegang nodig tot de databases waarin de bekende fouten zijn opgeslagen en tot het CMS.

7.4.4   Interfaces

■ Servicelevelmanagement – Om de acceptabele niveaus van services te formuleren waarbinnen incidentmanagement werkt.

■ Information security management – Levert beveiliging-gerelateerde incidentinformatie door het onderhouden van logs, auditbestanden en incidentrecords.

■ Capaciteitsmanagement – Incidentmanagement levert een aanleiding voor prestatiebewaking en capaciteitsmanagement assisteert in het ontwikkelen van workarounds (tijdelijke oplossingen) voor incidenten.

■ Availabiltymanagement – Bepaalt de beschikbaarheid van IT-services. Ook onderzoekt ze of er verbeteringen mogelijk zijn om incidenten sneller op te lossen en om de gemiddelde tijd, die tussen incidenten ligt, te vergroten.

■ Serviceasset & configuratiemanagement – Voor het leveren van de gegevens waarmee incidenten worden geïdentificeerd en verwerkt. Incidentmanagement kan assisteren bij de verificatieactiviteit van SACM wanneer een oplossing voor een incident wordt gezocht.

■ Changemanagement – Om een (nood)oplossing te implementeren met behulp van wijzigingsmodellen. Incidentmanagement identificeert incidenten die voortkomen uit wijzigingen.

■ Problemmanagement – Om de onderliggende oorzaken van incidenten te onderzoeken en op te lossen, en om de gevolgen van het opnieuw optreden van incidenten te reduceren of te voorkomen. Door deze activiteiten kan problemmanagement informatie verstrekken over problemen, bekende fouten en workarounds.

■ Accessmanagement – Om ontdekte niet-geautoriseerde toegangspogingen en inbreuken op de beveiliging vast te leggen.

7.4.5   Aanleidingen (triggers) ■ De servicedesk ontvangt een melding (telefonisch of via email) van een incident.

■ Een incident wordt door een gebruiker gemeld via een incidentlogscherm op een webportal.

■ Technisch personeel signaleert – door bijvoorbeeld gebruik te maken van eventmanagementtools – dat een incident zich heeft voorgedaan.

■ Leveranciers laten weten dat zij hebben geconstateerd dat er in de door hen beheerde of geleverde systemen zich bepaalde fouten voordoen.

7.4.6   Invoer ■ Informatie over CI’s en hun status. ■ Informatie over bekende fouten en hun workarounds. ■ Communicatie en feedback over incidenten en hun symptomen. ■ Communicatie en feedback over RfC’s en releases die zijn geïmplementeerd of daarvoor op de planning staan.

■ Communicatie over events die zijn getriggerd door eventmanagement. ■ Operationele en serviceleveldoelstellingen. ■ Feedback van de klant over de manier waarop het incident is opgelost, en over de algehele kwaliteit van de activiteiten van incidentmanagement.

■ Afgesproken criteria voor het prioriteren en escaleren van incidenten.

7.4.7   Uitvoer ■ Opgeloste incidenten en acties die tot de oplossingen hebben geleid. ■ Bijgewerkte registraties door incidentmanagement; deze registraties (records) bevat-ten accurate informatie over het soort incident en de geschiedenis ervan.

■ Bijgewerkte incidentenclassificatie ter ondersteuning van de proactieve activiteiten van problemmanagement.

■ Probleemrecords voor incidenten waarvan men de onderliggende oorzaak niet heeft kunnen identificeren.

■ Validatie dat er zich geen incidenten meer voordoen die te relateren zijn aan problemen die opgelost zouden moeten zijn.

■ Feedback over incidenten die te maken hebben met wijzigingen en releases. ■ Identificatie van CI’s die te maken hebben gehad met incidenten, of die gevolgen hebben ondervonden van incidenten.

■ Feedback van klanten die incidenten hebben ervaren. ■ Feedback over het niveau en de kwaliteit van de activiteiten van eventmanagement.

■ Communicatie over (de geschiedenis van) het incident en hoe deze is opgelost. Deze communicatie is nodig om de algehele kwaliteit van de service vast te kunnen stellen.

7.4.8   Kritieke succesfactoren ■ Incidenten zo snel mogelijk oplossen en de gevolgen voor de business beperken.

■ Kwaliteit van IT-services onderhouden. ■ Gebruikers van de IT-services tevreden zien te houden. ■ De activiteiten en prioriteiten van incidentmanagement afstemmen op die van de business.

■ Goede communicatie richting de business en het IT-supportpersoneel over de wijze waarop incidenten zijn afgehandeld (status voortgang, oplostijd).

7.4.9   Metrics ■ Gemiddelde tijd: • nodig voor reparatie; • nodig voor het herstel van de service; • tussen service- en systeemincidenten. ■ Aantal incidenten in de verschillende fasen van afhandeling. ■ Aantal nog af te handelen incidenten per service. ■ Gemiddelde kosten per incident. ■ Aantal en percentage incidenten: • gesloten op het ‘eerste contactmoment’, dat wil zeggen direct door de support-medewerker bij wie het incident wordt gemeld;

• • • • • • •

geclassificeerd als ernstig (major); foutief toegewezen; foutief gecategoriseerd; verwerkt door het IT-personeel; gerelateerd aan wijzigingen en releases; afgehandeld binnen afgesproken reactietijd; op afstand opgelost, zonder dat ter plekke werkzaamheden hoefden te worden uitgevoerd.

7.4.10   Uitdagingen ■ Mogelijkheden om incidenten zo vroeg mogelijk te ontdekken. ■ Alle IT-medewerkers overtuigen dat alle incidenten gelogd moeten worden en hen aanmoedigen om de zelfhulpmogelijkheden te gebruiken die op internet aanwezig zijn.

■ Beschikbaarheid van informatie over problemen en bekende fouten. ■ Integratie in het CMS om relaties tussen CI’s te bepalen en te verwijzen naar de geschiedenis van CI’s.

■ Integratie in het SLM-proces.

7.4.11   Risico’s ■ Gebrek aan beschikbare middelen of voldoende getrainde resources, met als gevolg een vertraging in de afhandeling van incidenten ten opzichte van wat is afgesproken.

■ Gebrek aan ondersteunende tools voor waarschuwingen en directe voortgang, met als gevolg een achterstand in de afhandeling van incidenten.

■ Niet-adequate tools of gebrek aan integratie tussen tools, met als gevolg ontbrekende of slecht toegankelijke gegevens en informatiebronnen.

■ Slecht afgestemde of niet-bestaande OLA en/of UC.

■ 7.5   REQUEST FULFILLMENT 7.5.1   Inleiding Request fulfillment verwerkt service requests (serviceverleningsverzoeken) van de gebruikers. Een service request kan bijvoorbeeld het verzoek zijn om een wachtwoord te wijzigen of een aanvraag voor het installeren van een softwareapplicatie op een bepaald werkstation. Omdat deze verzoeken regelmatig plaatsvinden en weinig risico’s met zich meebrengen, is het beter om deze in een afzonderlijk proces af te handelen.

Het

doel van request fulfillment is het managen van de levenscyclus van alle

service requests.

De

doelstellingen van het request fulfillmentsproces zijn:

■ Gebruikers een kanaal bieden waardoor zij services kunnen aanvragen en ontvangen; hiervoor moet een afgesproken goedkeurings- en kwalificatieproces bestaan.

■ Gebruikers en klanten voorzien van informatie over de beschikbaarheid van services en de procedure voor de verkrijging van deze services.

■ De componenten van standaard services leveren (bijvoorbeeld licenties en softwaremedia).

■ Assisteren bij algemene informatie, klachten of commentaren. Bereik Het proces voor de afhandeling van aanvragen hangt af van de aard van de aanvraag. In de meeste gevallen kan het proces worden gesplitst in een reeks

activiteiten die moeten worden uitgevoerd. Sommige organisaties behandelen service requests als een speciaal soort incident. Er is echter een belangrijk verschil tussen een incident en een service request. Een incident is gewoonlijk een niet-geplande gebeurtenis, terwijl een service request eerder iets is dat kan en zou moeten worden gepland.

Waarde voor de business De waarde van request fulfillment is de mogelijkheid om snel en effectief toegang te bieden tot standaard services die de business kan gebruiken om de productiviteit of de kwaliteit van de zakelijke services en producten te verbeteren.

Request fulfillment vermindert de hoeveelheid oponthoud in het aanvragen en verkrijgen van toegang tot bestaande of nieuwe services. Dit vermindert de kosten voor de levering van deze services.

Basisbegrippen ITIL gebruikt de term ‘service request’ als een algemene aanduiding voor de verschillende aanvragen die gebruikers doorgeven aan de IT-afdeling.

Een service request is een verzoek van een gebruiker voor het leveren van informatie, advies, een standaard wijziging of toegang tot een service. Veel service requests keren regelmatig terug. Daarom kan van te voren een processtroom worden geregeld, die de fasen die doorlopen moeten worden om aanvragen af te handelen, de personen of supportgroep die betrokken zijn, de tijdslimieten en escalatiepaden aangeeft.

Een substantieel deel van de alle service request betreffen aanvragen voor het leveren of het ter beschikking stellen van standaard services, zoals de aanvraag van een nieuwe pc of uitbreiding van het standaard Office-pakket met Visio. Voor dit type wijzigen geldt dat die kunnen worden afgehandeld als

standaard wijziging. Standaard wijzigingen brengen weinig risico met zich mee, hebben een beperkte impact en zijn procedureel en eventueel ook in de vorm van werkinstructies goed te beschrijven. Een standaard wijziging wordt

eenmalig geautoriseerd via het reguliere changemanagementproces en kan vervolgens lokaal worden uitgevoerd.

7.5.2   Activiteiten, methoden en technieken Request fulfillment omvat de volgende activiteiten:

1. Menuselectie

– Door middel van request fulfillment kunnen gebruikers

hun service requests indienen via een weblink naar een servicemanagementtool. In de ideale situatie wordt de gebruiker een keuzemenu aangeboden via een webportal, waar informatie te vinden is en services aangevraagd kunnen worden.

2. Financiële goedkeuring – De meeste service requests hebben financiële implicaties. Voor een deel van de aanvragen kunnen de kosten van te voren worden bepaald en kan direct autorisatie plaatsvinden. In de andere gevallen moeten de kosten geschat worden, waarna de gebruiker toestemming moet geven.

3. Afhandeling –Hoe de afhandeling precies plaatsvindt, hangt af van het type service request. De servicedesk kan eenvoudige verzoeken afhandelen, terwijl andere verzoeken doorgezet moeten worden aan gespecialiseerde groepen of leveranciers.

4. Afsluiting – Wanneer de service request is afgehandeld, dan zal de servicedesk de service request afsluiten.

Afbeelding 7.6 Voorbeeld van work ow bij het request ful llment-proces (Bron: AXELOS)

7.5.3   Informatiemanagement ■ Welke service wordt gevraagd? ■ Wie vroeg de service aan of autoriseerde deze? ■ Welk proces gaat de aanvraag verwerken?

■ Aan wie is de aanvraag toegewezen en welke actie is genomen? ■ Alle relevante datums en tijden gedurende de aanvraaglevenscyclus. ■ Informatie betreffende de afsluiting. ■ RfC. ■ De serviceportfolio en de servicecatalogus. ■ Regels voor het beveiligingsbeleid.

7.5.4   Interfaces ■ Financieel management voor IT-services – Om waar nodig de kosten van request fulfillment vast te stellen.

■ Servicecatalogusmanagement – Om ervoor te zorgen dat de aan te vragen services goed worden gecommuniceerd aan gebruikers.

■ Release & deployment management – Om ‘releasemodellen’ te maken die vooraf vastgesteld, gebouwd en getest kunnen worden, maar alleen worden uitgerold op verzoek van degenen die de ‘release’ willen.

■ Serviceasset en configuratiemanagement – Om wijzigingen te beoordelen die zijn aangebracht als onderdeel van afhandelingsactiviteiten.

■ Changemanagement – Om aanvragen correct te loggen die in feite wijzigingen zijn of juist niet, en om RfC’s via changemanagement te verwerken.

■ Incidentmanagement – Om aanvragen correct te loggen die in feite incidenten zijn of juist niet, en om incidenten te verwerken via incidentmanagement. Sommige organisaties ontwikkelen afzonderlijke processen voor de afhandeling van incidenten en aanvragen. Andere organisaties gebruiken het incidentproces om aanvragen af te handelen en gebruiken eenvoudig een categorie ‘aanvraag’.

■ Accessmanagement – Om erop toe te zien dat aanvragers hiertoe geautoriseerd zijn conform het informatiebeveiligingsbeleid.

7.5.5   Aanleidingen (triggers) ■ Gebruiker belt de servicedesk. ■ Een gebruiker meldt een incident via het incidentlogscherm op een webportal.

7.5.6   Invoer

■ Werkaanvragen, bijvoorbeeld het verzoek om een bepaalde rapportage te maken of een restore-actie uit te voeren.

■ Autorisatieformulieren. ■ Service requests. ■ RfC’s. ■ Informatieaanvragen.

7.5.7   Uitvoer ■ Geautoriseerde of geweigerde service requests. ■ Statusrapporten van request fulfillment. ■ Afgehandelde service requests. ■ Incidenten. ■ RfC’s/standaardwijzigingen. ■ Activa-/CI-updates. ■ Bijgewerkte aanvraagrecords. ■ Afgesloten service requests. ■ Geannuleerde service requests. 7.5.8   Kritieke succesfactoren ■ Aanvragen moeten efficiënt en tijdig worden verwerkt in overeenstemming met de afgesproken serviceniveaus die voor dit type aanvraag gelden.

■ Alleen geautoriseerde aanvragen mogen worden vervuld. ■ Ervoor zorgen dat gebruikers tevreden zijn en blijven.

7.5.9   Metrics ■ Percentage service requests: • voltooid binnen de afgesproken tijd; • dat is verwerkt en de vereiste autorisatie had; • per stadium van hun levenscyclus; • afgesloten op het ‘eerste contactmoment’ (dat wil zeggen direct door de medewerker bij wie het verzoek is ingediend);

•

behandeld op afstand of geautomatiseerd, ofwel zonder dat er ter plekke werkzaamheden nodig waren.

■ De gemiddelde kosten per type service request. ■ De gemiddelde tijd nodig voor de afhandeling, per type service request.

■ Mate van gebruikerstevredenheid over de afhandeling, per type service requests.

■ De grootte van de achterstand in uitstaande service requests.

7.5.10   Uitdagingen ■ Definiëren en documenteren van de verschillende typen service requests (aanvragen) die worden behandeld binnen het request fulfillment-proces.

■ Ervoor zorgen dat gebruikers kunnen beschikken over een gebruikersvriendelijke (front-end) interface voor het indienen van hun aanvragen.

■ Ervoor zorgen dat er voor elk type aanvraag goede afspraken bestaan en dat daarover duidelijk wordt gecommuniceerd (bijvoorbeeld binnen hoeveel werkdagen een werkstation of laptop moet worden uitgeleverd).

■ Overeenstemming bereiken over de kosten die gepaard gaan met de verwerking van de aanvragen.

■ Afstemmen welke services worden gestandaardiseerd en wie deze kan aanvragen.

■ Zorgen voor eenvoudige toegang tot informatie over welke aanvragen beschikbaar zijn voor de organisatie.

■ In stand houden van gebruiker- en klanttevredenheid.

7.5.11   Risico’s ■ Het bereik van het proces is niet precies vastgesteld. ■ Gebruikersinterfaces ten behoeve van het indienen van een verzoek zijn slecht ontworpen en daardoor gebruikersonvriendelijk.

■ De richtlijnen voor wijze waarop serviceaanvragen moeten worden afgehandeld zijn niet goed beschreven of worden niet nageleefd.

■ Niet in staat zijn de voortgang van de afhandeling van serviceverzoeken te monitoren.

■ 7.6   PROBLEMMANAGEMENT 7.6.1   Inleiding Het doel van problemmanagement is het managen van de levenscyclus van alle problemen vanaf het moment dat een probleem geïdentificeerd is en

vervolgens het onderzoek naar de oorzaak van het probleem, het vastleggen van alle informatie daarover en de eventueel te ondernemen acties om het probleem op te lossen.

De

doelstellingen van problemmanagement zijn:

■ Het elimineren van incidenten die zich herhaaldelijk voordoen door de onderliggende oorzaak (root cause) van die incidenten weg te nemen.

■ Het minimaliseren van de impact van incidenten die niet voorkomen kunnen worden.

■ Het voorkomen van problemen en daaruit voortvloeiende incidenten. Bereik Problemmanagement omvat alle activiteiten die vereist zijn om een diagnose te stellen van de onderliggende oorzaak van incidenten en voor het vinden van een oplossing voor deze problemen. Het zorgt er ook voor dat de oplossing wordt doorgevoerd via de correcte controleprocedures, dus via changemanagement en releasemanagement.

Waarde voor de business Problemmanagement werkt samen met incidentmanagement en changemanagement. Doel van die samenwerking is om de beschikbaarheid en kwaliteit van de IT-services te verbeteren. Onderzoek in problemmanagement naar de onderliggende oorzaak van incidenten kan een workaround (tijdelijke oplossing) opleveren. Die oplossing wordt dan nauwkeurig gedocumenteerd in de known error-database. Deze informatie over workarounds kan door het proces incidentmanagement gebruikt worden om het afhandelen van incidenten te versnellen. Met als resultaat een kortere onderbrekingstijd van de serviceverlening en een betere beschikbaarheid van bedrijfskritische systemen. Als binnen het proces problemmanagement de onderliggende oorzaak (root cause) van de optredende incidenten is gevonden, dan is het daardoor in principe mogelijk om tot een definitieve oplossing voor het probleem te komen. Als voor het realiseren van die oplossing een wijziging noodzakelijk is, dan dient daarvoor wel eerst goedkeuring verkregen te worden van het proces changemanagement.

Basisbegrippen

Veel problemen zijn uniek en moeten afzonderlijk worden afgehandeld. Veel incidenten komen echter vaker dan één keer voor als gevolg van onderliggende problemen.

ITIL formuleert een probleem als volgt:

Een probleem is de nog onbekende oorzaak van een of meer incidenten.. ITIL formuleert een bekende fout als volgt:

Een bekende fout is een probleem dat een gedocumenteerde grondoorzaak heeft en een workaround. ITIL formuleert een workaround als volgt:

Workaround: het: verminderen of elimineren van de impact van een incident of probleem waarvoor een volledige oplossing nog niet beschikbaar is.

Known Error Database (KEDB) De KEBD (bekende-foutendatabase) is een database waarin alle bekende fouten (known errors) inclusief de beschikbare workarounds geregistreerd staan. Dit maakt een snelle diagnose mogelijk. Naast het ontwikkelen van een KEDB kan het opzetten van een

probleemmodel voor de afhandeling van

toekomstige problemen nuttig zijn. Een dergelijk standaardmodel helpt bij het vaststellen van:

■ de stappen die moeten worden gezet; ■ de verantwoordelijkheden van betrokken personen; ■ en de vereiste tijdsplanning.

7.6.2   Activiteiten, methoden en technieken Problemmanagement omvat twee belangrijke hoofdactiviteiten, namelijk:

reactief en proactief problemmanagement. Reactief problemmanagement houdt zich bezig met het oplossen van problemen die onderkend zijn door het optreden van incidenten. Proactief problemmanagement is gericht op het

identificeren en oplossen van problemen en bekende fouten vóórdat daaraan gerelateerde incidenten kunnen optreden

Reactief problemmanagement Reactief problemmanagement omvat de volgende activiteiten (zie ook figuur 7.7): 1 Identificatie. 2 Registratie. 3 Classificatie. 4 Prioritering. 5 Onderzoek en diagnose. 6 Beslissen over workarounds. 7 Identificatie van bekende fouten. 8 Oplossing. 9 Afsluiting. 10 Evaluatie.

1. Identificatie Identificatie van problemen wordt uitgevoerd via de volgende methoden:

■ De servicedesk vermoedt of identificeert een onbekende oorzaak voor een of meer incidenten. Dit resulteert in een probleemregistratie.

■ Uit de analyse van een incident door de technische supportgroep blijkt een onderliggend probleem.

■ Een infrastructurele of applicatiefout wordt automatisch getraceerd en event- of waarschuwingstools creëren automatisch een incidentregistratie die de noodzaak van probleemregistratie aangeeft.

■ De leverancier rapporteert een probleem dat moet worden opgelost. ■ De analyse van incidenten vindt plaats als onderdeel van reactief probleembeheer.

2. Registratie Ongeacht de identificatiemethode moeten alle gegevens van het probleem

probleemregistratie ), zodat een uitgebreid archief

worden geregistreerd (

wordt gecreëerd. De informatie moet een datum- en tijdvermelding hebben, zodat goede controle en escalatie mogelijk zijn.

3. Classificatie Problemen moeten op dezelfde wijze worden geclassificeerd als incidenten, zodat de ware aard van het probleem snel en eenvoudig kan worden vastgesteld.

Probleemclassificatie

levert nuttige managementinformatie.

4. Prioritering Net als aan incidenten moet ook aan problemen een

prioriteit worden

toegekend, op een soortgelijke manier en om dezelfde reden. In deze context moet ook rekening worden gehouden met de frequentie en impact van de gerelateerde incidenten en de ernst van de problemen.

Afbeelding 7.7 Work ow reactief problemmanagement (Bron: AXELOS)

5. Onderzoek en diagnose Om de onderliggende oorzaak van het probleem te vinden en een stellen, wordt een

diagnose

te

onderzoek uitgevoerd. De snelheid en het karakter van dit

onderzoek zijn afhankelijk van de impact, ernst en urgentie van het probleem.

Het juiste niveau van resources en expertise moet worden gebruikt voor het vinden van een oplossing.

Tabel 7.1 Voorbeelden van probleemanalyse-, diagnose- en oplossingstechnieken

6. Beslissing over workarounds In veel gevallen is een tijdelijke oplossing, een workaround, mogelijk voor de incidenten die door een probleem werden veroorzaakt. Het is echter belangrijk dat het probleemrecord open blijft en dat de informatie over de workaround daarin wordt opgenomen.

7. Identificatie van bekende fouten Zodra de diagnose is gesteld en vooral als een workaround is gevonden, moeten de

geïdentificeerde bekende fouten worden opgenomen in de

bekende-foutendatabase. Als andere incidenten en problemen optreden, kunnen die worden geïdentificeerd en kan de service sneller worden hervat.

8. Oplossing Zodra een oplossing is gevonden, moet die, idealiter, worden toegepast om het probleem te verhelpen. In de praktijk moeten er preventieve maatregelen worden genomen om te zorgen dat de oplossing geen verdere problemen veroorzaakt. Als een wijziging nodig is, is een wijzigingsverzoek (Request for Change, RfC) vereist die de stappen van het changemanagementproces doorloopt.

9. Afsluiting Als de wijziging is voltooid en als succesvol is geëvalueerd, en de oplossing is toegepast, kan het probleemrapport formeel worden

afgesloten, evenals de

gerelateerde incident-rapporten die nog kunnen uitstaan. Men moet niet

vergeten te controleren of het rapport een volledige beschrijving van alle gebeurtenissen bevat.

10. Evaluatie Na elk ernstig probleem moet een evaluatie

worden uitgevoerd om lessen

voor de toekomst te leren.

Het gebeurt zelden dat nieuwe applicaties, systemen of softwarereleases geen

fouten bevatten. In de meeste gevallen wordt een prioriteringssysteem gebruikt tijdens het tes-ten zodat de ernstigste fouten worden weggenomen, maar het is mogelijk dat daarbij kleinere fouten niet zijn gecorrigeerd.

Proactief problemmanagement Proactief problemmanagement is serie van meer doorlopende activiteiten die als doel hebben de overall beschikbaarheid en tevredenheid van de eindgebruikers te verbeteren.

Voorbeelden van proactieve probleembeheer activiteiten zijn: 1. Uitvoeren van periodieke reviews op incidentregistraties. 2. Uitvoeren van reviews op grote (major) incidenten. 3. Uitvoeren van reviews op operationele logboeken en onderhoudsgegevens. 4. Uitvoeren van periodieke reviews op loggegevens vanuit eventmanagement. 5. Uitvoeren van brainstormsessies om trends te identificeren die in de toekomst tot incidenten kunnen leiden. 6. Het gebruik van afvinklijsten om proactief gegevens te verzamelen met betrekking tot operationele of service-gerelateerde kwaliteitsissues, die kunnen helpen om onderliggende problemen te detecteren.

Geïdentificeerde problemen vanuit bovengenoemde activiteiten vormen de input voor het CSI-register en worden gebruikt om verbetermogelijkheden te registreren en te managen.

7.6.3   Informatiemanagement ■ Configuratiemanagementsysteem. ■ Bekende-foutendatabase (KEDB). ■ Incidentregistraties..

7.6.4   Interfaces Servicestrategie ■ Financieel management voor IT-services – Om te assisteren bij het beoordelen van de impact van voorgestelde oplossingen, workarounds en ‘pijnwaardeanalyses’. Problemmanagement levert informatie over de kosten van het oplossen en voorkomen van problemen.

Serviceontwerp ■ Availabilitymanagement – Om de downtime te reduceren en de uptime te verhogen via availabilitymanagementmethoden en -technieken, en om te helpen bij het beoordelen van proactieve maatregelen.

■ Capaciteitsmanagement – Om prestatieproblemen te verhelpen, te assisteren bij probleemonderzoek via capaciteitsmanagementmethoden, en om te helpen bij het beoordelen van proactieve maatregelen.

■ IT-service continuity management – Als enkel aanspreekpunt voor ITSCM om een ernstig probleem dat niet is opgelost aan te pakken voordat dit impact heeft op de business.

■ Servicelevelmanagement – Om bij te dragen aan de verbetering van de servicelevels. SLM levert parameters voor prioritering.

Servicetransitie ■ Changemanagement – Om te zorgen dat alle oplossingen of workarounds waarvoor een wijziging van een CI nodig is, via een RfC worden doorgegeven.

■ Service asset- en configuratiemanagement – Om CI’s met fouten te identificeren en ook om de impact van problemen en oplossingen te bepalen.

■ Release & deployment management – Assisteert bij het invoeren van nieuwe bekende fouten (known errors) in de ontwikkelde KEDB (Known Error Database).

■ Kennismanagement – De problemen en de KEDB maken deel uit van het SKMS.

Continue serviceverbetering

■ Het verbeteringsproces in zeven stappen. – Het leveren van een basis voor het aanwijzen van kansen voor serviceverbetering.

7.6.5   Aanleidingen (triggers) ■ Er is sprake van reactief problemmanagement. ■ Er hebben zich één of meer incidenten voorgedaan. ■ Uitkomsten van een releasetest. ■ Meldingen van leveranciers. ■ Er is sprake van proactief problemmanagement. ■ Identificatie van patronen en trends. ■ Een evaluatie van: • operationele logs; • operationele communicatie; • eventlogs. 7.6.6   Invoer ■ Incidentrecords. ■ Incidentrapporten en -geschiedenis. ■ Informatie over CI’s en hun status. ■ Communicatie en feedback over incidenten, RfC’s, releases en events. ■ Operationele en serviceleveldoelen. ■ Feedback van klanten. ■ Afspraken wat betreft het prioriteren en de criteria voor escalatie. ■ Risicomanagementrapporten. 7.6.7   Uitvoer ■ Opgeloste problemen en de acties die zijn uitgevoerd om tot de oplossing te komen.

■ Nieuwe of bijgewerkte problemmanagementrecords. ■ Wijzigingsverzoeken. ■ Workarounds voor incidenten. ■ Nieuwe of bijgewerkte records van de bekende fouten. ■ Problemmanagementrecords. ■ Actie-items en rapporten voor de evaluatie van een ernstig probleem.

7.6.8   Kritieke succesfactoren

■ Minimaliseren van de impact op de business van niet te voorkomen incidenten.

■ Kwaliteit van de IT-services onderhouden door eliminatie van terugkerende inciden-ten.

■ Algehele kwaliteit en professionaliteit van probleemafhandelingsactiviteiten om het vertrouwen van de business in IT-competenties te behouden.

7.6.9   Metrics ■ Het aantal bekende fouten op de juiste wijze ingevoerd in de KEDB. ■ Aantal en percentage: • incidenten die zijn gesloten bij het ‘eerste contactmoment’; • succesvol en tijdig afgeronde evaluaties van ernstige problemen met behulp van workarounds die opgenomen zijn in de known error database (KEDB);

• • • •

niet correct toegewezen problemen; niet correct gecategoriseerde problemen; uitstaande problemen en de bijbehorende trends; problemen opgelost/niet opgelost binnen serviceleveldoelen.

■ De gemiddelde oplossingstijd voor incidenten die zijn gekoppeld aan probleem-records.

■ Gemiddelde kosten per probleem.

7.6.10   Uitdagingen ■ Zorgen voor een effectief incidentmanagementproces en gerelateerde tools. ■ Verbeteren van de analytische en onderzoekscompetenties en mogelijkheden van het personeel werkzaam binnen problemmanagement.

■ Zorgen dat personeel binnen het problemmanagement in staat is alle beschikbare middelen te gebruiken (CMS en SKMS) voor het onderzoeken en oplossen van problemen.

■ Het organiseren van trainingen ten behoeve van het technisch personeel. Deze trainingen zijn gericht op de technische aspecten van het werk dat zij doen, maar laten (vooral) ook zien welk belang de business heeft bij de services zoals die door hen worden ondersteund.

■ De mogelijkheid om: • Incidentrecords te linken aan probleemrecords.

• •

De activiteiten van problemmanagement te integreren met het CMS. Een goed werkende relatie te hebben en te onderhouden tussen de functies service-desk, IT-productie (dat de IT-services levert, ofwel dat de operationele activiteiten daartoe uitvoert), het technisch en applicatiemanagement alsmede met de leveranciers.

7.6.11   Risico’s ■ Resources zijn beperkt beschikbaar of mensen zijn onvoldoende getraind, met als gevolg dat problemen niet binnen een acceptabele tijd kunnen worden afgehandeld.

■ Gebrek aan adequate supporttools, waardoor onderzoek naar mogelijke oorzaken niet of niet goed mogelijk is met als gevolg dat een achterstand (backlog) ontstaat in de afhandeling van problemen.

■ Inadequate tools of een gebrek aan integratie tussen tools, met als gevolg dat er geen of beperkte toegang mogelijk is tot informatiebronnen.

■ Slecht afgestemde of ontbrekende OLA’s en/of UC’s waardoor de activiteiten binnen problemmanagement onvoldoende in lijn gebracht kunnen worden met de afspraken die in de SLA zijn vastgelegd met betrekking tot onderwerpen als beschikbaarheid, performance, security en continuïteit.

■ Gebrek aan analytische en onderzoeksvaardigheden van het personeel werkzaam binnen problemmanagement.

■ 7.7   ACCESSMANAGEMENT 7.7.1   Inleiding Het doel van accessmanagement is om alleen die gebruikers de rechten te verlenen voor toegang tot een service, of een groep van services, die hiertoe geautoriseerd zijn. Sommige organisaties noemen dit ook rechtenmanagement of identiteitsmanagement.

De

doelstellingenvan het accessmanagementproces zijn:

■ Uitvoering geven aan het beleid en de richtlijnen van het proces information security management.

■ Mogelijk maken dat de vertrouwelijkheid, integriteit en beschikbaarheid van de bedrijfsdoelstellingenvagegevens en het intellectueel eigendom worden gemanaged.

■ Zekerstellen dat rechten op een correcte wijze worden verleend. Bereik Accessmanagement zorgt dat gebruikers toegang hebben tot een service, maar dat garandeert nog niet dat de toegang te allen tijde beschikbaar is. Dat laatste wordt gere-geld door availabilitymanagement.

Waarde voor de business ■ Gecontroleerde toegang tot services stelt de organisatie in staat de vertrouwelijkheid van haar informatie effectiever te onderhouden.

■ Personeel heeft het juiste toegangsniveau voor een goede uitvoering van hun werk.

■ Het risico van fouten tijdens gegevensinvoer of het gebruik van een vitale service door een niet gekwalificeerde gebruiker is lager.

■ Er is de optie de toegangsrechten weer eenvoudig in te kunnen trekken wanneer toegang nodig is voor compliance (bijvoorbeeld SOx en CoBIT).

Basisbegrippen ■ Toegang – verwijst naar het niveau en bereik van de functionaliteit van een service of gegevens die een gebruiker mag gebruiken.

■ Identiteit – betreft de informatie over de individuele gebruikers met betrekking tot hun positie in de organisatie.

■ Rechten (ook privileges genoemd) – verwijst naar de feitelijke instellingen voor een gebruiker, welke service(groep) hij of zij mag gebruiken. Gebruikelijke rechten zijn lezen, schrijven, uitvoeren, bewerken en verwijderen.

■ Services of servicegroepen – de meeste gebruikers hebben toegang tot meerdere services. Het is daarom effectiever om iedere gebruiker of groep van gebruikers toegang te geven tot een volledige serie van services, waarvoor ze gemachtigd zijn om die gelijktijdig te gebruiken.

■ Directory service

– verwijst naar een specifiek soort tool waarmee toegang

en rech-ten worden beheerd.

7.7.2   Activiteiten, methoden en technieken De volgende activiteiten vinden binnen het proces accessmanagement plaats (zie ook afbeelding 7.8).

1. Verificatie

– accessmanagement moet elke toegangsaanvraag voor een IT-

service in twee opzichten verifiëren: a. Is de gebruiker die toegang vraagt echt de persoon die hij/zij beweert te zijn? b. Heeft de gebruiker een legitieme reden om de service te gebruiken?

2. Toekenning van rechten – accessmanagement beslist niet wie toegang krijgt tot welke IT-services, maar voert slechts het beleid en de regels uit zoals die door het information security managementproces zijn bepaald.

3. Bewaken van de identiteitsstatus – de functies van gebruikers kunnen door de tijd heen veranderen en dat kan invloed hebben op hun servicebehoeften. Voorbeelden van wat kan wijzigen zijn: functiewijzigingen, promotie, ontslag, pensioen of overlijden.

4. Registeren en bewaken van toegang – accessmanagement reageert niet alleen op aanvragen, het moet ook zorgen dat de toegekende rechten correct worden gebruikt.

5. Intrekken of beperken van rechten – behalve voor het toekennen van rechten om een service te gebruiken, is accessmanagement ook verantwoordelijk voor het intrekken van die rechten, echter de beslissing daartoe wordt niet door accessmanagement genomen.

Afbeelding 7.8 Voorbeeld van work ow bij accessmanagement (Bron: AXELOS)

7.7.3 Informatiemanagement

■ De identiteit wordt gewoonlijk vastgesteld aan de hand van de volgende gegevens: •

Naam.

•

Adres.

•

Contactgegevens.

•

Fysieke documentatie.

•

Unieke identificatie.

•

Biometrische informatie.

•

Vervaldatum.

■ Een gebruikersidentiteit kan worden verstrekt aan iemand die een legitieme behoefte heeft om toegang te krijgen tot informatie over de IT-services of over de organisatie. Denk hierbij aan: •

Medewerkers, zowel IT als niet-IT.

•

Contractanten.

•

Personeel van leveranciers.

•

Klanten.

•

Gebruikers, groepen, rollen en servicegroepen.

■ Omdat elke gebruiker een eigen identiteit heeft en elk IT-service kan worden gezien als een entiteit op zich, is het vaak nuttig om deze te groeperen, zodat ze gemakkelijker kunnen worden gemanaged. Soms worden termen gebruikt als gebruikersprofiel, gebruikerssjabloon of gebruikersrol om dergelijke groepering te beschrijven.

7.7.4 Interfaces ■ Demandmanagement – Om de noodzakelijke resources (mensen en middelen) te bepalen voor het afhandelen van het verwachte aantal toegangsaanvragen.

■ Strategiemanagement voor IT-services – Om te bepalen of de activiteiten van accessmanagement efficiënter verlopen als deze lokaal in plaats van centraal worden uitgevoerd.

■ Information security management – Voorziet accessmanagement van de nodige beleidsregels en tools voor de beveiliging en gegevensbescherming. Human Resource Management kan hierbij assisteren door het verifiëren van de gebruikersidentiteit en de toegang tot de service(s) die men op basis daarvan heeft.

■ Servicecatalogusmanagement – Om de methoden en middelen te leveren waarmee gebruikers toegang krijgen tot de services waarvoor zij rechten hebben.

■ IT-service continuity management – Beheert de toegang tot de services in geval van een ernstige bedrijfsstoring.

■ Servicelevelmanagement – Onderhoudt de overeenkomsten (SLA, OLA, UC) voor toegang tot elke service.

■ Changemanagement – Controleert de toegangsaanvragen, omdat zo’n aanvraag gewoonlijk wordt verwerkt als een standaard wijziging of als een service request.

■ Serviceasset- en configuratiemanagement – Om de gegevens op te slaan en de CI’s te ondervragen over huidige toegangsgegevens.

■ Request fulfillment – Levert de methoden en middelen waarmee gebruikers toegang kunnen aanvragen tot de services die zij mogen gebruiken.

7.7.5 Aanleidingen (triggers) ■ Een RfC. ■ Een service request. ■ Een verzoek van Human Resources Management. ■ Een verzoek van een manager. ■ Een verzoek van een gebruiker. 7.7.6 Invoer ■ Beleidsregels voor informatiebeveiliging. ■ Operationele en serviceleveleisen en -doelen voor accessmanagementactiviteiten.

■ Geautoriseerde aanvragen voor toekenning of intrekking van toegangsrechten.

7.7.7 Uitvoer ■ Verlenen van toegang tot IT-services in overeenstemming met beleidsregels voor informatiebeveiliging.

■ Accessmanagementrecords en -rapporten. ■ Tijdige communicatie betreffende ongeoorloofde toegang of misbruik van services.

7.7.8 Kritieke succesfactoren ■ Zorgen dat de vertrouwelijkheid, integriteit en beschikbaarheid van services zijn beschermd conform het informatiebeveiligingsbeleid.

■ Tijdige communicatie naar de verantwoordelijke security officer over ongeoorloofde toegang of misbruik van services.

■ Op een juiste manier toegang tot services leveren binnen een tijdsbestek dat aansluit bij de bedrijfsbehoeften.

7.7.9 Metrics ■ Aantal en percentage: •

Incidenten met betrekking tot ongeoorloofde pogingen om toegang te krijgen tot een service.

•

Incidenten die vereisen dat toegangsrechten opnieuw ingesteld moeten worden.

•

Incidenten veroorzaakt door verkeerde toegangsinstellingen.

•

Afgehandelde toegangsaanvragen die werden geleverd binnen de daarover gemaakte SLA- en OLA-afspraken.

■ Aantal audits met betrekking tot correct ingetrokken of gewijzigde toegangsrechten van gebruikers die van functie zijn gewisseld of het bedrijf hebben verlaten.

■ Gemiddelde duur van toegang-gerelateerde incidenten.

7.7.10 Uitdagingen ■ Monitoren van en rapporteren over toegangsactiviteit, toegang-gerelateerde incidenten en problemen.

■ Het verifiëren van: •

de identiteit van een gebruiker;

•

de identiteit van diegene die de bevoegdheid heeft om een gebruiker de toegang tot de service te verlenen, en:

•

of een gebruiker voldoet aan de voorwaarden om hem toegang te kunnen verlenen tot een specifieke service.

■ Meerdere toegangsrechten koppelen aan een individuele gebruiker. ■ De status van gebruikers op een bepaald moment bepalen. ■ Wijzigingen in toegangsbehoeften van een gebruiker beheren. ■ Toegangsrechten voor niet-geautoriseerde gebruikers beperken.

■ Een database opzetten en onderhouden van alle gebruikers en de aan hen toegekende rechten.

7.7.11 Risico’s ■ Gebrek aan geschikte ondersteunende technische systemen voor het beheren en controleren van toegang tot services.

■ Controleren van toegang via ‘achterdeuren’ zoals applicatie-interfaces en wijzigingen in firewallregels voor speciale doeleinden.

■ Beheren en controleren van toegang tot services door externe derdepartijleveranciers.

■ Gebrek aan managementondersteuning voor het uitvoeren van de accessmanagementactiviteiten en -controles.

■ Ervoor zorgen dat noodzakelijke niveaus van toegang tot services en de noodzakelijke beheercontroles worden geleverd zonder de business onnodig te hinderen.

■ 7.8   IMPLEMENTATIE 7.8.1 Balans bereiken in serviceproductie Procedures en activiteiten vinden plaats in een continu veranderende omgeving. Dit kan leiden tot een conflict tussen het behouden van de huidige situatie en het reageren op veranderingen in de omgeving van het bedrijf en in de technische systemen. Het omgaan met dit conflict is een van de belangrijkste rollen van serviceproductie, ze moet een evenwicht zien te bereiken tussen tegenstrijdige prioriteiten.

Intern IT-perspectief versus extern zakelijk perspectief De opvatting dat IT een onderdeel is van IT-services (het externe zakelijke perspectief ) is het tegenovergestelde van het idee dat IT bestaat uit een aantal technologische componenten (de interne kijk op IT). Dit verschil in perspectief veroorzaakt het voornaamste conflict in alle fasen van de levenscyclus van IT-servicemanagement.

Volgens het externe zakelijke perspectief gaat het bij IT om de manier waarop gebruikers en klanten services ervaren. Intern draait het om hoe de ITorganisatie IT-componenten en -systemen managet om services te leveren.

Stabiliteit versus reactiesnelheid Aan de ene kant moet serviceproductie ervoor zorgen dat de IT-infrastructuur stabiel en beschikbaar is, en tegelijkertijd moet serviceproductie erkennen dat zakelijke en IT-eisen veranderen. Ofwel, in de IT-organisatie moeten stabiliteit en reactiesnelheid in balans zijn:

■ Investeren in aanpasbare technische systemen en processen, bijvoorbeeld, virtual server- en applicatietechnologie.

■ Moedig integratie aan tussen het servicelevelmanagement en de andere serviceontwerpprocessen, zodat de eisen van de business op een juiste wijze vertaald worden naar de uit te voeren operationele IT-activiteiten en naar een goede vormgeving van de IT-infrastructuur.

■ Betrek IT zo snel mogelijk in het wijzigingsproces in geval van zakelijke wijzigingen. Dit helpt om ervoor te zorgen dat in de schaalbaarheid, consistentie en IT-services de wijzigingen worden meegenomen.

■ Laat serviceproductieteams input geven op het ontwerp en de verfijning van de architectuur en IT-services.

■ Implementeer en gebruik servicelevelmanagement om te voorkomen dat het bedrijfsen IT-management en -personeel informele afspraken gaan maken.

Servicekwaliteit versus servicekosten Serviceproductie moet doorlopend IT-services leveren aan klanten en gebruikers, en dat op een afgesproken niveau. Tegelijkertijd moeten de kosten en het gebruik van resources op een optimaal niveau worden gehouden. Veel organisaties staan onder sterke druk om de servicekwaliteit te verhogen en tegelijkertijd de kosten te drukken.

Een optimale balans bereiken tussen kosten en kwaliteit is een belangrijke taak van servicemanagement. Veel organisaties laten dit over aan het serviceproductieteam, dat daarover geen zeggenschap heeft. De fasen servicestrategie en serviceontwerp zijn hiervoor geschikter. Servicelevelspecificaties en een duidelijk inzicht in de doelen en gevaren van serviceverlening kan helpen ervoor te zorgen dat de service wordt geleverd tegen de juiste kosten.

Afbeelding 7.9 Een voortdurend zoeken naar balans (Bron: AXELOS)

Reactief versus proactief Een reactieve organisatie doet niets totdat een externe impuls haar tot actie dwingt. Zo’n organisatie ontwikkelt, bijvoorbeeld, alleen een nieuwe applicatie als een nieuwe zakelijke specificatie daarom vraagt. Een proactieve organisatie is altijd op zoek naar nieuwe kansen om de huidige situatie te verbeteren. Gewoonlijk wordt proactief gedrag als positief gezien, want het stelt de organisatie in staat haar concurrentievoordeel te behouden in een veranderende omgeving. Echter, een overdadig proactieve houding kan zeer kostbaar zijn en ervoor zorgen dat het personeel te snel afgeleid is. Voor een optimaal resultaat moeten reactief en proactief gedrag goed in balans zijn.

7.8.2 Uitdagingen

De implementatie van serviceproductie op een zodanige wijze dat zij haar doel kan realiseren, kent een groot aantal uitdagingen.

Interne en externe relaties Een van de belangrijkste uitdagingen waar serviceproductiemanagers mee te maken hebben is de balans tussen de vele interne en externe relaties. Er wordt in toenemende mate gebruikgemaakt van netwerken, partners en gedeeldeservicemodellen. Een serviceproductiemanager moet investeren in relatiemanagementkennis en vaardigheden om te kunnen omgaan met de complexiteit van deze uitdagingen. Serviceproductiemanagers krijgen ook te maken met het gebruik van virtuele teams. Traditionele, hiërarchische managementstructuren zijn niet opgewassen tegen de complexiteit en diversiteit van de meeste organisaties. Kennismanagement wordt in toenemende mate belangrijk met de uitbreiding en diversificatie van organisaties. Servicestrategie gaat hier nader op in.

Rechtvaardiging van kosten Vaak is het moeilijk om uitgaven voor serviceproductie te rechtvaardigen omdat wat wordt gespendeerd vaak als ‘infrastructuur’-kosten wordt gezien. In de praktijk kunnen veel investeringen in IT-servicemanagement, vooral voor serviceproductie, geld besparen en leiden tot een positieve ROI naast verbeterde servicekwaliteit.

Risico’s door wijzigingen Serviceproductiemedewerkers moeten wijzigingen doorvoeren zonder dat dit een negatieve impact heeft op de stabiliteit van de geboden IT-services.

Aanleidingen voor wijzigingen Er zijn veel dingen die een wijziging in de serviceproductie omgeving kunnen triggeren, waaronder:

■ Nieuwe (of voor een upgrade in aanmerking komende) hardware of software.

■ Wetgeving. ■ Verouderde componenten. ■ Zakelijke vereisten. ■ Procesverbeteringen.

■ Wijzigingen in management of personeel. ■ Wijziging in servicelevels. ■ Nieuwe services. Beoordeling van wijzigingen Serviceproductie moet zo vroeg mogelijk worden betrokken in de beoordeling van alle wijzigingen. Op die manier kunnen operationele kwesties op een behoorlijke wijze worden afgehandeld.

Beoordelen en beheren van risico’s in serviceproductie In een aantal gevallen is het noodzakelijk om een risico-evaluatie snel uit te voeren, zodat passende maatregelen op tijd genomen kunnen worden. Dit geldt met name voor wijzigingsverzoeken of bekende fouten, maar ook in geval van storingen, projecten, omgevingsrisico’s, leveranciers, beveiligingsrisico’s en nieuwe klanten die ondersteuning nodig hebben.

Gebrek aan betrokkenheid bij ontwikkelaars en projectmedewerkers Serviceontwerp heeft de neiging zich te focussen op een service terwijl serviceproductie gericht is op het leveren en ondersteunen van alle services. Serviceontwerp wordt vaak uitgevoerd in projecten, terwijl serviceproductie gericht is op continue beheerprocessen en -activiteiten. De twee fasen van de levenscyclus kennen andere meetwaarden die serviceontwerp aanmoedigen het project op tijd af te ronden, zoals gespecificeerd en binnen het vastgestelde budget. Het is echter moeilijk te voorspellen hoe de service eruit gaat zien en wat de kosten na de uitrol en in de beginperiode van het gebruik zullen zijn. Als de service niet werkt zoals verwacht, is IT-operations management verantwoordelijk.

Van oudsher is er een scheiding tussen serviceproductiepersoneel en personeel dat betrokken is bij de ontwikkeling van nieuwe applicaties – of in de uitvoering van projecten die nieuwe functionaliteit leveren in een operationele omgeving. Deze scheiding is schadelijk, want aan kwesties die te maken hebben met serviceproductie kan het best in het begin van een nieuwe ontwikkeling of project aandacht worden besteed, wanneer er nog tijd is om ze mee te nemen in de planningsstadia. Het betrekken van serviceproductiepersoneel in de vroege stadia van serviceontwerp en

servicetransitie zorgt ervoor dat de nieuwe services in de praktijk echt zullen werken en kunnen worden ondersteund door serviceproductiemedewerkers.

Verbeteren van serviceproductie Serviceproductie kan op twee manieren worden verbeterd: 1. Incrementele verbetering op lange termijn – deze is gebaseerd op de evaluatie van de prestaties en uitvoer van alle serviceproductieprocessen, functies en uitvoer in de loop van de tijd. Voorbeelden zijn het in gebruik nemen van nieuwe tools en wijzigingen in het ontwerpproces. 2. Doorlopende kortetermijnverbetering van bestaande situaties binnen de serviceproductieprocessen, functies en technische systemen – dit zijn kleine wijzigingen die worden doorgevoerd in een proces of technologie en die de fundamentele werking ervan niet veranderen. Voorbeelden zijn inwerken, training of overplaatsing van personeel.

■ 7.9   ORGANISATIESTRUCTUREN VAN SERVICEPRODUCTIE 7.9.1 Inleiding Serviceproductiefuncties kunnen op diverse manieren worden georganiseerd en elke organisatie zal tot eigen beslissingen komen op grond van haar grootte, geografische ligging, cultuur en omgeving.

Organisatie naar technische specialisatie Dit organisatietype richt afdelingen in, in overeenstemming met de technische systemen en met de vaardigheden en activiteiten die nodig zijn voor het managen van die technische systemen. IT-productie volgt de structuur van de afdelingen technisch management en applicatiemanagement.

Organisatie naar activiteit Dit type organisatiestructuur is gericht op het feit dat gelijksoortige activiteiten worden uitgevoerd op alle technische systemen in een organisatie. Dit betekent dat mensen die gelijksoortige activiteiten verrichten, ongeacht het technische systeem, in een groep zijn ondergebracht, hoewel er binnen elke

afdeling teams kunnen zijn die zijn betrokken bij een bepaald technisch systeem, applicatie enzovoort.

Organiseren om processen te managen Het is geen goed idee om de organisatie volledig te structureren volgens processen. Processen zijn er juist om het verzuilingseffect van afdelingen weg te nemen, niet om die te creëren.

In procesgeoriënteerde organisaties worden mensen georganiseerd in groepen of afdelingen die een bepaald proces uitvoeren of managen. Een dergelijke organisatiestructuur moet echter alleen worden gebruikt als IT-operations management verantwoordelijk is voor meer dan IT-productie. In sommige organisaties is IT-productie ook verantwoordelijk voor het vaststellen van SLA’s en onderhandelen van UC’s.

IT-productie organiseren volgens geogra sche ligging IT-activiteiten kunnen fysiek verspreid zijn en in sommige gevallen moet elke locatie worden georganiseerd volgens de eigen context. Deze structuur wordt meestal gebruikt wanneer:

■ Datacenters geografisch verspreid zijn. ■ Verschillende regio’s of landen verschillende technische systemen hebben of andersoortige services aanbieden.

■ Verschillende bedrijfsmodellen of organisatorische structuren in de verschillende regio’s voorkomen, met andere woorden: de business is gedecentraliseerd in samenhang met de geografische ligging en elke business unit is tamelijk autonoom.

■ Er verschil is in regelgeving tussen land en regio. ■ Er verschillende standaardnormen van toepassing zijn per land of regio. ■ Er culturele of taalverschillen bestaan tussen de medewerkers die IT managen.

Hybride organisatiestructuren Het is onwaarschijnlijk dat IT-operations management alleen zal worden gestructureerd volgens het soort organisatiestructuur. De meeste organisaties werken met een technische specialisatie gecombineerd met een paar extra afdelingen op basis van activiteit of proces:

■ Gecombineerde functies – De IT-productie en de afdelingen technisch management en applicatiemanagement zijn in één structuur ondergebracht. Dit gebeurt soms wanneer alle groepen zijn ondergebracht in één datacenter. In deze situatie neemt de datacentermanager verantwoordelijkheid voor het technisch, applicatie- en het IT-operationeel beheer.

■ Gecombineerde structuur voor technisch en applicatiemanagement – Sommige bedrijven organiseren hun technische en applicatiemanagementfuncties op basis van de belangrijkste bedrijfsapplicaties en de bijbehorende componenten van de ITinfrastructuur. Dit betekent dat elke afdeling applicatiespecialisten en technische IT-infrastructuurspecialisten heeft die services beheren op basis van een reeks applicaties en bijbehorende componenten van de ITinfrastructuur.

7.9.2 Kritieke succesfactoren Managementondersteuning Ondersteuning van het hoger en middenmanagement is noodzakelijk voor alle IT-servicemanagementactiviteiten en -processen, vooral in serviceproductie; het is cruciaal voor het verkrijgen van voldoende financiering en resources. Seniormanagement moet ook voldoende zichtbare ondersteuning bieden tijdens de lancering van nieuwe initiatieven van serviceproductie.

Business-support Het is ook belangrijk dat serviceproductie wordt ondersteund door de businessunits. Dit werkt beter als het serviceproductiepersoneel de business betrekt in alle activiteiten en open en eerlijk is over succes en falen.

Reguliere communicatie met de business is cruciaal voor het opbouwen van een goede relatie en om de steun ervan te krijgen. Serviceproductie zal een beter begrip krijgen van de aspiraties en zorgen van de business. Bovendien kan de business feedback leveren over de inspanningen van serviceproductie om te voldoen aan de behoeften van de business.

Personeel inhuren en behouden

Het juiste aantal medewerkers met de juiste competenties is van cruciaal belang voor succesvolle serviceproductie. Hierbij moet gedacht worden aan de volgende uitdagingen:

■ Projecten voor nieuwe services specificeren vaak wel duidelijk welke nieuwe competenties er moeten zijn, maar onderschatten soms hoeveel medewerkers er nodig zijn en hoe competenties kunnen worden behouden.

■ Er kan gebrek aan personeel zijn met grondige kennis van servicemanagement. Goede technici hebben is belangrijk, maar er moet ook mensen zijn die zowel verstand hebben van technologische als van servicegerelateerde problemen.

■ Omdat personeel met zowel technologische kennis als kennis van de services zeldzaam is, wordt zij vaak speciaal daarvoor getraind. Het is belangrijk deze mensen te behouden door hen een duidelijk carrièrepad en goede compensatie te bieden.

■ Personeel wordt vaak te snel aan nieuwe taken toegewezen, terwijl ze nog zeer zwaar belast zijn met hun huidige werklast. Succesvolle servicemanagementprojecten kunnen een kortetermijninvestering in tijdelijk personeel vereisen.

Servicemanagementtraining Goede training en bewustzijn kunnen grote voordelen opleveren. Naast de expertise groeit het enthousiasme van de mensen. Serviceproductiemedewerkers moeten zich bewust zijn van de consequenties van hun acties voor de organisatie. Een ‘servicemanagementcultuur’ moet worden gecreëerd. Servicemanagement wordt alleen een succes als de mensen de algehele servicemanagementdoelstellingen voor ogen hebben.

Geschikte tools Veel servicemanagementprocessen en activiteiten kunnen niet effectief worden uitgevoerd zonder de juiste supporttools. Seniormanagement moet zorgen dat de financiering van zulke tools is opgenomen in de jaarbudgetten en moeten de inkoop, de implementatie en het onderhoud ervan ondersteunen.

Testvaliditeit De kwaliteit van IT-services geleverd door serviceproductie is afhankelijk van de kwaliteit van systemen en componenten die worden geleverd in de

operationele omgeving.

Het kwaliteitsniveau zal aanmerkelijk verbeteren als er tijdig grondige en complete testen op nieuwe componenten en releases worden uitgevoerd. Ook de documentatie moet onafhankelijk worden getest op volledigheid en kwaliteit.

Meten en rapporteren Heldere overeenkomsten zijn nodig wat betreft de manier waarop dingen worden gemeten en gerapporteerd. Alle medewerkers hebben duidelijke doelen om zich op te richten, en IT- en businessmanagers zijn in staat om snel en eenvoudig te evalueren of er voortgang is en welke gebieden extra aandacht vragen.

7.9.3 Risico’s De volgende risico’s moeten in ogenschouw worden genomen:

■ Serviceverlies – Het grootste risico dat serviceproductie loopt is het verlies van essentiële IT-services, met negatieve impact op personeel, klanten en financiën. In extreme gevallen is sprake van verlies van leven en gevaar voor de gezondheid wanneer IT-services worden gebruikt voor essentiële gezondheids- en beveiligingsdoeleinden.

■ Risico’s voor succesvolle serviceproductie : •

Onvoldoende financiering en resources.

•

Verlies van momentum.

•

Verlies van belangrijke medewerkers.

•

Weerstand tegen veranderingen.

•

Gebrek aan steun vanuit het management.

•

Als het ontwerp niet aan de eisen voldoet, zal succesvolle implementatie nooit leiden tot de vereiste resultaten; daarvoor is een nieuw ontwerp nodig.

•

In sommige organisaties wordt servicemanagement argwanend bekeken door zowel de IT als de business. De voordelen van servicemanagement moeten voor alle stakeholders duidelijk zijn. Dit probleem kan worden opgelost door helder service levelmanagement en zorgvuldige communicatie tijdens het serviceontwerp.

■ 8.1   INLEIDING TOT CONTINUE SERVICEVERBETERING

IT moet de IT-services voortdurend afstemmen op de veranderende behoeften van de organisatie. Continu wordt onderzocht waar verbeteringen in de ITservices mogelijk zijn en hoe deze doorgevoerd kunnen worden. ITIL plaatst deze verbeteractiviteiten in de levenscyclusfase

continue serviceverbetering

(Engels: Continual Service Improvement, CSI).

Afbeelding 8.0 Continue serviceverbetering gekoppeld aan de ITIL-levenscyclus In het Engels is er een onderscheid tussen continual (continu, telkens) en continuous (onafgebroken, doorlopend):

■ Continuous wil zeggen dat de organisatie zonder onderbreking bij een activiteit betrokken is. De inspanningen bevinden zich constant op hetzelfde niveau, net zoals in een non-stopproductie.

■ Continual betekent een dichte opeenvolging van activiteiten. Op die manier creëert men een reeks verbeterinspanningen: continue verbetering.

Een IT-service komt tot stand via een aantal activiteiten. De kwaliteit van deze activiteiten en het proces dat deze activiteiten verbindt, bepaalt de kwaliteit van de uiteindelijke service. CSI is gericht op het waar nodig verbeteren van de kwaliteit van alle activiteiten en processen, waarmee de IT-services tot stand komen. Hiervoor gebruikt het de PDCAcyclus van Deming. Deze cyclus beschrijft vier activiteiten – (1) Plan, (2) Do, (3) Check en (4) Act – waarmee men tot kwaliteitsverbetering kan komen. Het cyclische karakter benadrukt dat men de PDCA-activiteiten steeds herhaalt en dus dat men continu aandacht blijft besteden aan kwaliteitsverbetering. Het is een patroon dat zich blijft herhalen en waarbij de verbeterinspanningen steeds intensiever worden. Dat is de reden waarom in ITIL de ‘C’ van CSI voor continual staat en niet voor continuous.

Meten en analyseren zijn cruciale activiteiten binnen CSI. Door meting is het mogelijk te bepalen welke services profijtelijk zijn en welke services niet opleveren wat ervan verwacht wordt. Het meten en analyseren wordt uitgebreid besproken. Allereerst echter worden de rechtvaardiging van CSI en een aantal basisbegrippen besproken.

8.1.1 Doel en doelstellingen Het doel van CSI is om de IT-services in lijn te brengen met de veranderende behoeften van de business door het identificeren van verbetermogelijkheden en het implementeren van verbeterde IT-services, die de businessprocessen ondersteunen. Dit betekent zowel het bereiken als overtreffen van de

effectiviteit) als het bereiken van de doelstellingen tegen zo laag mogelijke kosten (efficiëntie ). Om de effectiviteit te vergroten kan doelstellingen (

bijvoorbeeld het aantal fouten in een proces worden verminderd. Om een proces efficiënter te maken, kunnen onnodige activiteiten worden geëlimineerd of handmatige bewerkingen worden geautomatiseerd.

Door de procesresultaten te meten en te analyseren in alle servicelevenscyclusfasen, kan men bepalen welke resultaten structureel slechter zijn dan andere. Daarin is de grootste verbeterkans te vinden.

CSI meet en bewaakt hoofdzakelijk het volgende:

■ Naleving van het proces – Volgt de organisatie de nieuwste of gewijzigde service-managementprocessen en gebruikt ze de nieuwe ‘tools’?

■ Kwaliteit – Bereiken de verschillende procesactiviteiten hun doelen? ■ Prestaties – Hoe efficiënt is het proces? Wat zijn de verstreken tijdsperioden? ■ De waarde die een proces voor de business heeft – Levert het proces iets op? Is het effectief? Hoe beoordeelt de klant het proces?

De belangrijkste

doelstellingen van CSI zijn:

■ Aanbevelingen doen voor verbeteringen in iedere fase van de levenscyclus. ■ Reviewen en analyseren van servicelevelprestaties. ■ Verbeteren van de kwaliteit van de IT-serviceverlening alsmede de efficiency en effectiviteit ervan.

■ Verbeteren van de kosteneffectiviteit zonder de tevredenheid van de klant daaraan op te offeren.

■ Zekerstellen dat gebruik wordt gemaakt van toepasbare kwaliteitsmanagementmethoden.

■ Zekerstellen dat processen heldere doelen hebben, die ook gemeten kunnen worden.

■ Meetresultaten kunnen begrijpen in relatie tot wat succesvolle uitkomsten zouden moeten zijn.

8.1.2 Bereik Het bereik van CSI omvat de volgende onderwerpen:

■ Te rechtvaardigen (qua kosten en baten) geleidelijke en continue verbetering van de kwaliteit van de serviceverlening.

■ Continu in lijn brengen van IT-services met de eisen en behoeften van de business.

■ Geleidelijke verbeteringen in kosteneffectiviteit. ■ Identificatie van mogelijkheden voor verbeteringen in alle fasen van de levenscyclus en binnen alle processen.

■ Identificatie van mogelijkheden om de organisatie beter te structureren, het vermogen om in de benodigde bedrijfsmiddelen te voorzien, samenwerking met partners, verhoging van de competenties van de medewerkers en de daarvoor benodigde training, en de kwaliteit van de communicatie.

■8.2   BASISBEGRIPPEN 8.2.1 Het CSI-register Het CSI-register bevat belangrijke informatie voor de serviceprovider. Het register maakt in zijn geheel deel uit van het kennismanagementsysteem voor services (het SKMS).

In het CSI-register worden alle verbeterinitiatieven vastgelegd, alsmede welke voordelen hiermee te behalen zijn of behaald zijn. Hiermee biedt dit register ondersteuning bij de activiteiten van het CSI en een overzicht van wat er al bereikt is. Uitkomsten van ondernomen acties worden gemeten en nagegaan wordt – aan de hand van KPI’s (Key Performance Indicator) – of het gewenste resultaat is bereikt. KPI’s zijn nodig om te kunnen beoordelen en te prioriteren welke initiatieven voor de business het meest profijtelijk zijn.

8.2.2 CSI en organisatieverandering Om continue verbetering tot een permanent onderdeel van de organisatiecultuur te maken, is vaak een mentaliteitsverandering nodig. Dit is een van de lastigste aspecten van CSI en, in de praktijk, mislukken veel CSIprogramma’s omdat veel organisaties deze cultuuromslag niet (kunnen) realiseren. John P. Kotter, emeritus hoogleraar organisatiekunde en verandermanagement aan de Harvard-universiteit, onderzocht meer dan honderd bedrijven en ontdekte acht cruciale stappen voor een succesvolle organisatieverandering: 1.

Creëer een gevoel van urgentie.

2.

Vorm een leidende coalitie.

3.

Creëer een visie.

4.

Communiceer de visie.

5.

Stel anderen in staat te handelen in overeenstemming met de visie.

6.

Plan en creëer kansen om snel resultaat te boeken.

7.

Consolideer verbeteringen en creëer meer veranderingen.

8.

Institutionaliseer de veranderingen.

8.2.3 De PDCA-cyclus Het invulling geven aan kwaliteitsverbetering met behulp van de Demingcirkel is een fundamenteel basisprincipe in CSI. Het idee van de Demingcirkel is dat kwaliteitsverbetering alleen tot stand kan worden gebracht door consequent alle vier de stappen (Plan – Do – Check – Act) van deze cirkel te blijven doorlopen (zie figuur 8.1).

De vier activiteiten in de kwaliteitscirkel van Deming zijn:

■ PLAN: Kijk naar huidige werkzaamheden en ontwerp een plan voor de verbetering van deze werkzaamheden. Stel voor deze verbetering doelstellingen vast.

■ DO: Voer de geplande verbetering uit op een gecontroleerde wijze. ■ CHECK: Meet het resultaat van de verbetering en vergelijk deze met de oorspronkelijke situatie en toets deze aan de vastgestelde doelstellingen.

■ ACT: Bijstellen aan de hand van de gevonden resultaten bij CHECK. Een fase van consolidatie na het doorlopen van de PDCA-cyclus voorkomt dat de cirkel weer naar beneden rolt. CSI past de PDCA-cyclus in twee gebieden toe, namelijk bij de implementatie van CSI en bij het continu verbeteren van services en processen.

De cyclus voor de implementatie van CSI (zie ook afbeelding 8.2):

■ CSI plannen (Plan):

•

•

Het bereik bepalen.

•

Vaststellen wat de eisen zijn waaraan CSI moet voldoen.

•

Doelen stellen, bijvoorbeeld aan de hand van een gap-analyse.

•

Actiepunten formuleren.

Bepalen welke controles moeten worden uitgevoerd in de controlefase.

Afbeelding 8.1 De Deming-cyclus (Bron: AXELOS) •

De interfaces tussen CSI en de rest van de levenscyclus bepalen.

•

Bepalen welke procesactiviteiten geïntroduceerd moeten worden.

•

(Management)rollen en verantwoordelijkheden toewijzen.

•

Nagaan welke tools nodig zijn voor het ondersteunen en documenteren van processen.

•

De methoden en technieken selecteren voor het meten en documenteren van de kwaliteit en effectiviteit van de services en processen.

■ CSI implementeren (Do): •

Het budget vaststellen.

•

Rollen en verantwoordelijkheden documenteren.

•

Het CSI-beleid en de CSI-plannen en -procedures vastleggen en onderhouden, deze communiceren en de medewerkers trainen.

•

Zorgen voor bewakings-, analyse en rapportagetools.

•

CSI integreren met servicestrategie, serviceontwerp, servicetransitie en serviceproductie.

■ CSI bewaken, meten en evalueren (Check):

•

Rapporteren over de resultaten ten opzichte van de planning.

•

De documentatie evalueren.

•

Procesevaluaties en -audits uitvoeren.

•

Voorstellen voor procesverbetering formuleren.

■ CSI aanpassen (Act): • •

De verbeteringen introduceren.

Het beleid, de procedures, rollen en verantwoordelijkheden aanpassen.

Afbeelding 8.2 Voorbeeld van een PDCA-cyclus voor het verbeteren van services

8.2.4 Metrics, KSF en KPI Meetresultaten met betrekking tot een proces of een activiteit komen tot stand door gebruik te maken van bepaalde meeteenheden (metrics). Bijvoorbeeld benodigde tijd uitgedrukt in aantal uren. Op basis van meetresultaten kan vastgesteld worden of de uitgevoerde activiteiten voldoen aan de daaraan gestelde doelen. Een voorbeeld is een meting om na te gaan of het beoogde aantal incidenten binnen een uur is opgelost.

Metrics worden voornamelijk geïnterpreteerd op strategisch en tactisch niveau. Voor CSI zijn drie soorten metrics nodig, namelijk:

■ Technologische metrics – Deze meten de prestaties en beschikbaarheid van componenten en applicaties.

■ Proces-gerelateerde metrics – Meten de prestaties van de servicemanagementprocessen (doorlooptijden, aantallen, wachttijden en dergelijke).

■ Service-gerelateerde metrics – De resultaten van de service zoals die end-toend geleverd wordt aan de gebruikers en waarover in de servicelevelagreement (SLA) prestatieafspraken zijn gemaakt

Metrics komen voort uit de doelen die een organisatie stelt. Als de business IT als een kostenplaats beschouwt, zal het waarschijnlijk de kosten willen verlagen. Ziet de organisatie haar IT als iets waarmee zij haar strategische doelen kan realiseren, dan zal zij gebruikmaken van metrics die gerelateerd zijn aan de ontwikkeling van flexibele IT-services, waardoor de business sneller met nieuwe producten en services op marktontwikkelingen kan reageren.

kritieke succesfactor (KSF) als volgt omschreven: iets dat essentieel is voor het bereiken van de missie. De KPI’s Voor de bedrijfsmissie wordt een

(Key Performance Indicators, de belangrijkste prestatie-indicatoren) die volgen uit deze KSF’s bepalen de kwaliteit, prestaties, waarde en procesnaleving. Zij kunnen kwalitatief zijn (zoals klanttevredenheid) of kwantitatief (zoals de kosten van een incident).

Bij de aanvang van het verbeterprogramma leveren twee tot drie KPI’s per KSF al veel informatie op die moet worden verwerkt. De KPI’s kunnen later worden uitgebreid en aangepast in overeenstemming met nieuwe ontwikkelingen, bijvoorbeeld als de organisatie de gestelde doelen heeft bereikt of wanneer nieuwe servicemanagementprocessen worden geïntroduceerd.

Data, informatie, kennis en wijsheid (DIKW) Metrics leveren kwantitatieve data, bijvoorbeeld dat de servicedesk 12.000 incidenten per maand registreert. CSI zet de data om in kwalitatieve

informatie , bijvoorbeeld het feit dat 18 procent van de gerapporteerde

incidenten betrekking heeft op de e-mailfaciliteit van de organisatie. Door informatie met ervaring, context, interpretatie en reflectie te combineren ontstaat

kennis, en kunnen we bijvoorbeeld, omdat we nu weten dat de

organisatie een webwinkel is, de impact van de incidenten met betrekking tot de e-mailfaciliteit beoordelen. Waar het op aankomt in CSI is

wijsheid: in staat zijn de juiste oordelen te

vellen en juiste besluiten te nemen door de data, informatie en kennis zo goed mogelijk te gebruiken. Zo kunnen we bijvoorbeeld, nu we de impact van de emailincidenten op de klant kennen, beslissen om ons op deze service te richten omdat we onze klantenservice willen verbeteren. Het CSIverbeterproces is gericht op het verwerven van wijsheid (zie paragraaf 8.4 ‘Verbeterproces in 7 stappen’, stap 6 over servicerapportage).

8.2.5 Governance Governance stuurt organisaties en controleert hen. Corporate governance zorgt voor goed, eerlijk, transparant en verantwoordelijk management van een organisatie. Business governance resulteert in goede bedrijfsprestaties. Samen vormen zij enterprise governance.

IT -governance

is ook onderdeel van enterprise governance. Het vormt de

processen en structuur van een IT-organisatie en zorgt dat zij haar doelen behaalt. Voldoen aan de nieuwe regels, zoals de Amerikaanse Sarbanes-Oxley Act van 2002 (corporate governance) en constant beter presteren tegen lagere kosten (business governance) zijn beide onderdeel van IT-governance.

Deze twee ontwikkelingen zijn het belangrijkste motief voor CSI: ITserviceproviders moeten hun services aanbieden vanuit een strategisch in plaats van een tactisch perspectief. IT-afdelingen die alleen oog hebben voor technologie worden al snel minder aantrekkelijk voor de business.

Een ITSM-standaard zoals ITIL helpt een organisatie om haarzelf onder controle te krijgen door deze aan een coherent systeem van regels, verantwoordelijkheden, processen, beleid en controles te onderwerpen.

8.2.6 CSI-beleidsregels en -procedures

De CSI-beleidsregels bevatten afspraken betreffende de metingen, rapportages, servicelevels, KSF’s, KPI’s en evaluaties. Deze moeten bekend zijn bij de gehele organisatie. De meeste organisaties beoordelen de procesresultaten elke maand. Het is verstandig om nieuwe services frequenter te beoordelen.

Een IT-organisatie moet de volgende CSI-beleidsregels doorvoeren:

■ Alle verbeterinitiatieven moeten het changemanagementproces doorlopen. ■ Alle functionele groepen zijn verantwoordelijk voor CSI-activiteiten. ■ CSI-rollen en -verantwoordelijkheden worden vastgelegd en bekendgemaakt.

■ 8.3   CSI-ACTIVITEITEN 8.3.1 Inleiding Om de services van de IT-organisatie te verbeteren, meet CSI het rendement van deze services. De belangrijkste CSI-activiteiten zijn:

■ Controleren: •

Resultaten van de processen controleren.

•

Klanttevredenheid onderzoeken.

•

Procesgroei beoordelen.

•

Controleren of het personeel interne richtlijnen volgt.

•

Analyseren van de meetgegevens en vergelijken met de doelen die in de SLA zijn gesteld.

■ Rapporteren: •

Verbeteringen voorstellen voor alle fasen in de levenscyclus.

•

Relevantie van bestaande doelen afwegen.

■ Verbeteren: •

Activiteiten introduceren die de kwaliteit, efficiëntie, effectiviteit en klanttevredenheid van de services verhogen.

•

Gebruikmaken van geschikte kwaliteitsmanagementmethoden voor verbeteractiviteiten.

8.3.2 CSI-methode Het effect van de verbetering wordt vooral bepaald door de richting waarin de verbetering gaat.

‘Kun je me alsjeblieft vertellen welke kant ik op moet vanaf hier?’ ‘Dat hangt er vooral vanaf waar je heen wilt,’ zei de kat. ‘Het maakt me niet uit waarheen,’ zei Alice. ‘Dan maakt het niet uit welke kant je opgaat,’ zei de kat. ‘Zolang ik maar ergens uitkom,’ voegde Alice toe als een verklaring. ‘O, dat kom je zeker,’ zei de kat, ‘als je maar lang genoeg loopt.’ Bron: Lewis Carroll, De avonturen van Alice in Wonderland , 1865 Zonder een visie op de richting van de verbetering kan een verbetering slechts beperkte waarde hebben. Daarom moet er een visie komen met bijbehorende doelen voor het verbeterproces.

De organisatie moet continu de lopende verbeterkoers (CSI-doelen) op relevantie, compleetheid en uitvoerbaarheid beoordelen. De afbeelding 8.3 kan daarbij behulpzaam zijn.

Afbeelding 8.3 De CSI-methode (Bron: AXELOS) Deze continue cyclus kent zes fasen:

CSI-methode

in

1.

Visie bepalen.

2.

Huidige situatie vastleggen.

3.

Meetbare doelen bepalen.

4.

Plannen.

5.

Controleren.

6.

Borging (het momentum gaande houden).

Aankondiging van het plan aan de gehele organisatie creëert bewustwording, begrip, enthousiasme en steun. Er moet een dialoog met de organisatie op gang komen en de feitelijke voortgang moet regelmatig worden gecommuniceerd en gerapporteerd.

8.3.3 Servicemeting Meten stelt een organisatie in staat de echte oorzaak en het effect van positieve dan wel negatieve situaties te analyseren en vast te stellen.

IT-services zijn een integraal middel geworden voor zakelijke activiteiten. Dit geldt voor bedrijven van elke aard en afmeting, in elke bedrijfstak, zowel in de private als in de publieke sector. Zonder IT-services zouden de meeste organisaties niet in staat zijn de producten en services aan de hedendaagse markt te leveren.

Ontwerpen en ontwikkelen van een framework voor servicemeting Een framework opzetten is evenzeer een kunst als een kunde. Servicemeting is geen doel op zich, maar moet zorgen voor, en ondersteuning bieden aan, verbetering van zowel services als verantwoording kunnen afleggen over de kwaliteit van de geleverde services.

Een framework voor servicemeting geeft de mogelijkheid om operationele, tactische of strategische beslissingen te nemen. Dat kan alleen als de organisatie een combinatie van metingen kiest die zorgt voor een accurate, uitgebalanceerde en onpartijdige informatie op basis waarvan besluitvorming mogelijk is over door te voeren wijzigingen.

Meten en rapporteren op verschillende niveaus

Voor het opzetten van een framework voor servicemeting is het nodig verschillende metrics en metingen met elkaar te kunnen combineren. Tevens is het belangrijk te begrijpen wat de meeste geschikte soorten rapporten, hun doelgroep en het bedoelde gebruik ervan zijn.

Servicemanagementprocesmeting Er zijn vier hoofdniveaus voor rapportage. Het eerste (laagste) niveau betreft de metrics voor een procesactiviteit. Het tweede niveau omvat de KPI’s behorend bij elk proces. Het derde niveau vertegenwoordigt het overkoepelend doel van het proces. Het vierde (top)niveau, ten slotte, vertegenwoordigt de Balanced Scorecard voor de IT of voor de organisatie.

Vaststellen van doelen en KPI’s Het is raadzaam om op een hoog niveau doelen vast te stellen in combinatie met KPI’s die deze doelen ondersteunen. KPI-categorieën kunnen als volgt worden geclassificeerd:

■ Compliance – Doen we het? ■ Kwaliteit – Hoe goed doen we het? ■ Performance – Hoe snel of langzaam doen we het? ■ Waarde – Leveren onze inspanningen iets op?

8.3.4 Servicerapportage Servicerapportage is de activiteit die verantwoordelijk is voor het genereren en leveren van rapporten over de bereikte resultaten en de ontwikkelingen in servicelevels. Een rapportagemethode die evenzeer is gericht op de toekomst als op het verleden biedt de serviceprovider middelen om zijn services en resultaten te vermarkten door direct aan te sluiten op de positieve dan wel negatieve ervaringen van de business.

Voor de verschillende doelgroep(en), met hun specifieke zakelijke kijk op de kwaliteit van de geleverde services, is het noodzakelijk om:

■ Overeenstemming te hebben over wat gemeten en gerapporteerd gaat worden.

■ Overeenstemming te bereiken over de te hanteren definities van alle te gebruiken begrippen in de SLA.

■ Inzicht te krijgen in hoe berekeningen uitgevoerd worden.

■ Afspraken te maken over rapportageschema’s. ■ Toegang te hebben tot rapportages en het medium dat voor rapportages wordt gebruikt.

■ Inplannen van bijeenkomsten voor de review van de rapportages. Juiste inhoud voor de juiste doelgroep Rapporten kunnen via verschillende media worden verspreid, zoals papier, digitaal, online, whiteboards (met een actuele momentopname) of zelfs via real time portalen/ dashboards. Al naar gelang waar de behoefte van de doelgroep naar uitgaat. Van belang is in ieder geval dat de doelgroep relevante, eenduidige en duidelijke informatie ontvangt in de gewenste vorm en taal.

■ 8.4   VERBETERPROCES IN 7 STAPPEN 8.4.1 Inleiding Het verbeterproces in 7 stappen beschrijft hoe services te meten zijn, hoe men over services rapporteert en ook hoe men verbeterinspanningen kan initiëren. Verbetering vindt plaats volgens de PDCA-cyclus. De belangrijkste uitvoer van deze fase, naast rapporten, is het

serviceverbeterplan (SIP,

Service Improvement Plan). In paragraaf 8.5 wordt uitgelegd hoe een organisatie een dergelijk plan kan opstellen.

Het is belangrijk om er rekening mee te houden dat alle verbeterinitiatieven een businessimpactanalyse en een kosten-batenanalyse vereisen en dat ze het changemanagementproces moeten doorlopen. Waar mogelijk moeten de voordelen die van de verbetering worden verwacht worden gekwantificeerd in de termen van geld. Hierbij gaat het om de return on investment (ROI). Niet alle voordelen zijn echter tastbaar; sommige hebben te maken met opvattingen en voorkeuren, twee aspecten waarmee de klant de waarde van de service beoordeelt. Daarbij gaat het om de value on investment (VOI).

8.4.2 Activiteiten, methoden en technieken CSI is al ingebed in elk proces, zodat iedereen betrokken is bij CSI. CSI gebruikt de uitvoer van andere processen, analyseert deze en draagt ideeën ter verbetering aan. In sommige gevallen kan het raadzaam zijn om iets niet te

verbeteren omdat de workaround prima voldoet aan de wensen van de klant, of omdat de oplossing veel geld kost of (te) veel tijd en inspanning vergen. Is dat laatste geval kan men besluiten om de service in de nabije toekomst niet meer aan te bieden.

Indien blijkt dat er in het servicelevelmanagementproces iets verbeterd moet worden, dan is dit een input in CSI. Vervolgens moet dan worden vastgesteld welke activiteiten uitgevoerd moeten worden om een verbetering te realiseren. Deze activiteiten worden beschreven in serviceverbeterplan (SIP).

CSI zal deze gegevens meten en verwerken in een continu verbeterproces (zie afbeelding 8.4). Dit vindt plaats in

zeven stappen van meting tot

verbetering: 1.

Identificeren van de verbeteringsstrategie.

2.

Bepalen van wat er wordt gemeten.

3.

Data verzamelen (meten).

4.

Data verwerken.

5.

Data analyseren.

Afbeelding 8.4 Het verbeterproces in zeven stappen (Bron: AXELOS) 6.

Informatie presenteren en gebruiken.

7.

Correctieve actie doorvoeren.

De zeven stappen worden voorafgegaan door het en

identificeren van de visie

doelen (identify). Dat wil zeggen, eerst worden de visie, strategie en de

tactische en operationele doelen bepaald. Deze vormen de input voor stap 1 en stap 2 in het verbeterproces. Stappen 1 en 2 zijn iteratief (herhalen zich) net zolang tot men zeker weet dat de juiste metingen worden gedaan teneinde bij stap 6 die informatie te krijgen die de business (het management) nodig heeft.

baseline is bepaald, moet dit eerst gebeuren. Er wordt dan een zogeheten nulmeting verricht. Dat wil zeggen, men meet hoe het er nu Indien er nog geen

aan toe gaat. De resultaten van de nulmeting vormen het uitgangspunt voor

verbeteracties. Daartoe definieert men KPI’s. Deze KPI’s dienen als referentie (ijkpunt) om te toetsen in hoeverre de ondernomen verbeteracties ook de resultaten opleveren zoals men die bedacht had. Op deze manier ontwikkelt zich een kennisspiraal. De informatie verkregen in stap 6, op het operationele niveau, vormt de input voor stap 3 (gegevens verzamelen), het tactische niveau. Op zijn beurt vormt de informatie over het tactische niveau weer input aan het strategische niveau (afbeelding 8.5).

Afbeelding 8.5 Voorbeeld van een kennisspiraal Het ‘meten’ mag echter nooit een doel op zich worden. Voordat een manager beslist wat zal worden gemeten en voor hoe lang, moet eerst worden afgewogen waarom men wil gaan meten en hoe de resultaten van nut kunnen zijn. Dit is afhankelijk van het doel dat het management voor ogen heeft (tabel 8.1).

Tabel 8.1 De vier meest gebruikelijke redenen om te meten

Bovendien is het belangrijk om ook te bepalen wat we gaan meten. We meten bijvoorbeeld om na te gaan of mensen zich aan de richtlijnen houden zoals die zijn afgesproken en vastgelegd. We meten om te zorgen dat de services en processen presteren zoals gepland. We meten om erop toe te zien dat services en processen worden geleverd op het juiste (overeengekomen) kwaliteitsniveau. En, tot slot, meten we om zekerheid te krijgen dat de services en processen werkelijk toegevoegde waarde leveren.

Het is altijd belangrijk om deze redenen voor ogen te houden. Wat betreft rapportages moet een manager zich afvragen:

■ Hebben we dit (nog) nodig? ■ Wat meet ik in feite? ■ Hoe vind ik de informatie terug?

Afbeelding 8.6 Waarom meten we? (Bron: AXELOS) De vragen hierboven zijn altijd belangrijk en moeten regelmatig worden gesteld voor alle rapportages. Het is de verantwoordelijkheid van het management om ervoor te zorgen dat er nuttige rapportages worden geproduceerd waar de (klant)organisatie daadwerkelijk gebruik van maakt.

Stap 1 – Identificeren van de verbeteringsstrategie Voordat activiteiten worden opgestart is het noodzakelijk om de overall-visie vast te stellen. Wat proberen we te realiseren voor de business als een geheel? De vraag die daarvoor beantwoord moeten worden is: welke initiatieven onderneemt de business, die ondermijnd zouden kunnen worden door een slechte kwaliteit van de IT-serviceverlening? Of meer positief geformuleerd: hoe kunnen verbeteringen aan de IT-kant de business in staat stellen haar visie te realiseren?

Hoe ziet de strategie van de business en de IT eruit voor de komende maanden en jaren? Waarom willen we meten ten behoeve van verbeteringen? De overall-strategie moet goed in kaart gebracht worden om te kunnen bepalen waar de focus op gelegd moet worden bij het uitvoeren van metingen.

Prioriteren van de CSI-activiteiten dient te gebeuren op basis van puur zakelijke overwegingen. Hierbij moet men ook de interne en externe serviceproviders niet vergeten. Welk deel van hun services moet worden gemeten (en mogelijk opgenomen) in de servicerapportage bij het bepalen in hoeverre de service wel of niet kan worden geleverd?

Invoer in stap 1: ■ Bedrijfsplannen en strategie. ■ Visie, missie, doelen en doelstellingen van de organisatie als geheel, als mede die van de verschillende bedrijfsonderdelen.

■ Wettelijke eisen. ■ Eisen op het gebied van governance. ■ Budgettering en eisen ten aanzien van de boekhouding. ■ Balanced Scorecard. ■ Serviceleveleisen en -doelen.

■ Serviceportfolio en servicecatalogus. ■ Vergaderingen waarin de service wordt geëvalueerd. ■ Klanttevredenheidsonderzoeken. ■ CSI-initiatieven die al in het CSI-register zijn opgenomen. ■ Servicemodellen. ■ Serviceontwerppakket. ■ Benchmark- en baselinegegevens. ■ Risicoanalyses en plannen om risico’s te beperken. De

uitvoer van stap 1 is:

■ Strategie om de service te verbeteren. ■ Geprioriteerde lijst van verbeteringen. ■ Bijgewerkt CSI-register. Stap 2 – Vaststellen wat er gemeten gaat worden In deze stap wordt het volgende bepaald/vastgesteld: 1.

Wat er moet worden gemeten, uitgaande van de verbeteringsstrategie.

2.

Wat we eigenlijk zelf kunnen meten uitgaande van de beschikbare/aanwezige resources en competenties.

3.

Hoe de gap-analyse eruit ziet op basis van de hierboven genoemde twee punten.

4.

Wat met de business besproken of onderhandeld moet worden, wanneer niet gemeten kan worden wat er gemeten zou moeten worden.

5.

Wanneer is het meetplan voltooid?

Stap 2 vindt iteratief plaats gedurende de rest van de CSI-activiteiten. Mogelijk dat de organisatie nieuwe technische systemen moet aanschaffen om het verzamelen en verwerken van de data te ondersteunen. Of ze kan daartoe anderen (derde partij) inhuren met de vereiste competenties. Een en ander hangt af van de doelstellingen die de organisatie erop nahoudt ten aanzien van de serviceverbeteringsactiviteiten.

Willen servicemetingen effectief zijn, dan moeten deze zich alleen richten op die zaken die van betekenis zijn voor de organisatie. De organisatie moet dus specifieke, kwantitatieve indicatoren vaststellen/ontwikkelen. Aan de hand van die indicatoren kan de organisatie de resultaten van die servicemetingen

toetsen, zodat ze direct inzicht krijgt of het resultaat voldoet aan de gewenste, zakelijke doelstellingen.

Er moet worden geïnventariseerd wat er al wordt gemeten, de rapporten die al worden geproduceerd, hun frequentie en hun doelgroep. Er moet worden vastgesteld wat er wordt gemeten en waarom. En of dat zinvol is, immers als niemand er gebruik van maakt, waarom dan meten?

Invoer in stap 2. Dit is de invoer in stap 1 plus: ■ Serviceverbeterstrategie. ■ Geprioriteerde lijst van verbeteringen. ■ Bijgewerkt CSI-register. ■ End-to-end servicedefinitie. ■ Processtromen. ■ Procedures. ■ Werkinstructies. ■ Technische en gebruikershandleidingen voor bestaande tools. ■ Bestaande rapportages. Uitvoer van stap 2: ■ Lijst van wat kan worden gemeten, inclusief KSF’s, KPI’s en metrics. ■ Lijst van vereiste resource-aanpassingen. ■ Lijst van vereiste aanpassingen in competenties. ■ Lijst van nieuwe resources die vereist zijn. Stap 3 – gegevens verzamelen (meten) Voor het verzamelen van data is het nodig om over hulpmiddelen te beschikken waarmee men activiteiten en processen kan monitoren. Voor het monitoren kan men gebruik maken van technische systemen. Denk aan tools voor applicatie-, systeem- en componentbewaking zoals die gebruikt worden in het eventmanagementproces. Houd er rekening mee dat het securitybeleid het verzamelen van data zeker zal beïnvloeden, vooral vanwege aspecten als vertrouwelijkheid, integriteit en beschikbaarheid.

Het voortdurend monitoren van kwaliteit is een belangrijke doelstelling van CSI. Het monitoren zal daarom gericht zijn op de effectiviteit en efficiëntie

van een service, proces, tool, organisatie of configuratie-item (CI).

CSI is geïnteresseerd in alle soorten events, zoals waarschuwingen en alarmsignalen, maar ook in de normale gang van zaken in de organisatie (business as usual). De mensen die bij CSI betrokken zijn dienen daarom te beschikken over het juiste toegangsniveau tot de informatiebronnen die zij voor hun werk nodig hebben.

Het is belangrijk te onthouden dat er drie soorten metrics zijn die een organisatie zal moeten verzamelen om CSI en andere procesactiviteiten te ondersteunen (tabel 8.2).

Tabel 8.2 Drie soorten metrics

Wanneer een nieuwe service wordt ontworpen of als men een bestaande service wijzigt, is dat de perfecte gelegenheid om datgene wat CSI moet monitoren (bewaken) ook in het ontwerp van de service-eisen op te nemen (zie hoofdstuk 5 over serviceontwerp).

Het ontwerpen van een nieuwe service of het wijzigen van een bestaande service is dé gelegenheid bij uitstek om de eisen die aan het monitoren worden gesteld in de servicevereisten op te nemen.

De eisen die de organisatie stelt aan het monitoren van haar processen, zullen in de loop der tijd veranderen. Om die reden moeten serviceproductie en CSI

vooruit kijken en samen een proces ontwerpen dat de business en IT in staat stelt om tot overeenstemming te komen over wat in de toekomst belangrijk zal zijn om te monitoren.

Medewerkers verzamelen voortdurend

handmatig gegevens en daarom

moeten er afspraken worden gemaakt hebben over het volgende:

■ Wie is verantwoordelijk voor het bewaken en verzamelen van de data? ■ Welke data worden verzameld? ■ Waar worden de data verzameld en bewaard? ■ Wanneer en hoe vaak worden de data verzameld? ■ Waarom zijn de data nodig? ■ Hoe worden de data verzameld? ■ Welke criteria garanderen de integriteit van de data, de correctheid, de betrouwbaarheid en de eerlijkheid van de bron?

Data verzamelen houdt de volgende

activiteiten in:

■ Op basis van het serviceverbeterplan, de doelen, doelstellingen en zakelijke eisen specificeren welke procesactiviteiten bewaakt moeten worden: •

Bewakingseisen specificeren.

•

De eisen vaststellen waaraan het verzamelen van data moet voldoen.

•

Resultaten vastleggen.

•

Goedkeuring vragen bij de interne IT-afdeling.

■ Bepalen hoe en hoe vaak data moeten worden verzameld. ■ Bepalen welke tools nodig zijn, deze zelf ontwikkelen of aanschaffen, of bestaande tools aanpassen.

■ De tool testen en installeren. ■ Bewakingsprocedures en werkinstructies ontwikkelen en vastleggen. ■ Een bewakingsplan opstellen en bespreken, en goed laten keuren door interne en externe IT-serviceproviders.

■ Beschikbaarheids- en capaciteitsplanning realiseren. ■ Beginnen met bewaken en verzamelen van gegevens. ■ De data logisch ordenen in een rapport. ■ Data evalueren om er zeker van te zijn dat die correct en bruikbaar zijn. Invoer in stap 3: ■ Lijst van wat moet worden gemeten.

■ Lijst van wat kan worden gemeten. ■ Lijst van wat gaat worden gemeten. ■ Bestaande SLA. ■ Nieuwe zakelijke eisen. ■ Bestaande mogelijkheden voor het monitoren en het vastleggen van data. ■ Voorgaande trendanalyses. ■ Analyserapport van de kloof tussen de bestaande en gewenste situatie. ■ Klanttevredenheidsonderzoeken. ■ Plannen en beleidsregels van andere processen. ■ Het CSI-register en bestaande serviceverbeterplannen. Uitvoer van stap 3: ■ Bijgewerkte beschikbaarheids- en capaciteitsplannen. ■ Procedures voor het monitoren. ■ Te gebruiken tools. ■ Bewakingsplan. ■ Input over IT-mogelijkheden. ■ Verzameling data. ■ Overeenstemming over de integriteit van de data. Stap 4 – data verwerken Hier worden de ruwe data uit stap 3 omgezet in het gewenste format voor de doelgroep. Hierbij wordt de ‘route’ gevolgd van metrics via KPI naar KSF en weer terug naar de visie, mocht dat nodig zijn (Afbeelding 8.7).

Afbeelding 8.7 Van visie naar metingen en weer terug (Bron: AXELOS) Helaas denken veel mensen dat als de gegevens (data) eenmaal door de tool zijn verwerkt, deze direct te presenteren en te gebruiken zijn. Dat is niet het geval. De gegevens moeten eerst worden geanalyseerd. Dit is de volgende activiteit in CSI.

Technische systemen voor rapportgeneratie hebben de mogelijkheid de ruwe gegevens om te zetten in een format dat eenvoudiger kan worden geanalyseerd. De rapportage-tools hebben ook de mogelijkheid tot een end-toend-meting van een service. Dit vereist de juiste toolconfiguratie, de identificatie en het onderhoud van configuraties en relaties waaruit de service bestaat.

Belangrijke vragen die gesteld moeten worden binnen de verwerkingsactiviteit zijn:

■ Wat is de frequentie van de dataverwerking? ■ Welk format is als uitvoer vereist?

■ Welke tools en systemen kunnen voor dataverwerking worden gebruikt? ■ Hoe wordt de accuraatheid van de verwerkte data geëvalueerd? Gegevensverwerking kan geautomatiseerd of handmatig plaatsvinden. Beide vormen van gegevensverwerking zijn belangrijk, maar handmatige verwerking is over het algemeen minder accuraat. Doorlopende communicatie over het belang en de voordelen van goede registratie en administratie is van het grootste belang.

Dataverwerking omvat de volgende

activiteiten:

■ Formuleren van de eisen die worden gesteld aan de verwerkte gegevens op basis van de strategie, doelen en SLA.

■ Bepalen hoe de data worden verwerkt: per uur, dag, week of maand? Voor nieuwe services of processen heeft een korte interval over het algemeen de voorkeur.

■ De categorisering van data bepalen op basis van de analysemethode en doelgroep.

■ Eisen voor verwerkings- en analysetools formuleren; deze ontwikkelen of kopen; deze testen en installeren.

■ De procedures ontwikkelen voor het verwerken van data en mensen trainen in de procedures.

■ Een bewakingsplan opstellen en bespreken; goedkeuring vragen van interne en externe IT-serviceproviders.

■ Beschikbaarheids- en capaciteitsplanning bijwerken. ■ Dataverwerking starten. ■ De data op een logische manier ordenen. ■ De accuraatheid van de data evalueren. Invoer in stap 4: ■ Data verzameld via het monitoringsproces. ■ Rapportage-eisen. ■ SLA, OLA en UC. ■ Servicecatalogus. ■ Lijst van metrics, KPI’s, KSF’s, doelstellingen en doelen. ■ Rapportagefrequentie. ■ Rapportagesjablonen.

Uitvoer van stap 4: ■ Huidige beschikbaarheid en capaciteitsplanning. ■ Rapporten. ■ Verwerkte, logisch gegroepeerde data, gereed voor analyse. Stap 5 – data analyseren Zonder analyse zijn data slechts data en leveren geen informatie. Analyse van de data is nodig om er informatie uit te kunnen winnen. En die informatie leidt weer tot kennis waarmee een antwoord kan worden gegeven op de vraag waar verbeteringen noodzakelijk zijn.

Voor het uitvoeren van data-analyses is meer vaardigheid en ervaring benodigd dan voor het verzamelen en verwerken van data. Het gaat bij deze activiteit om de vraag of op basis van de verzamelde data geconcludeerd kan worden dat de betreffende doelstellingen zijn gerealiseerd en dat er waarde is toegevoegd. Het is niet voldoende om eenvoudigweg verschillende grafieken te produceren; de observaties en conclusies moeten goed worden onderbouwd.

Wat wordt er feitelijk geanalyseerd?

■ Positieve en negatieve trends. ■ Wordt er voldaan aan de doelen die zijn afgesproken met de klant, binnen IT en met de leveranciers?

■ Oorzaak en effect. ■ Bedoelde versus feitelijke prestaties. Een aantal belangrijke vragen moet echter nog worden gesteld, zoals:

■ Is dit goed? ■ Is dit slecht? ■ Is dit verwacht? Door analyse komen verbeterkansen aan het licht. Binnen CSI moet beoordeeld worden of doelen zijn bereikt en zo ja, of nieuwe doelen (en dus nieuwe KPI’s) moeten worden geformuleerd. Als doelen werden bereikt maar de perceptie niet is verbeterd, kan het zijn dat nieuwe doelen moeten worden gesteld en dat men nieuwe maatregelen moet nemen om te zorgen dat die doelen worden gerealiseerd.

Vanwege voorgaande discussies over verbeteropties, zal IT het initiatief nemen in de dialoog met de business die volgt op de analyse. Een goede analyse van de informatie is ook in het voordeel van de business. Die leidt tot een nauwkeurige conclusie of verbetering nodig is op grond van strategische, tactische en operationele doelen. Op dit punt wordt informatie kennis volgens het DIKW-model.

Invoer in stap 5: ■ Resultaten van de gemonitorde data. ■ Bestaande KPI’s en doelen. ■ Percepties uit klanttevredenheidsonderzoeken, enzovoort. Stap 6 – informatie presenteren en gebruiken (servicerapportage) De zesde stap is om de informatie – die is weergegeven in de rapporten, monitors, actieplannen, beoordelingen, evaluaties – en mogelijkheden helder, behapbaar en tijdig te presenteren aan de doelgroep. Het rapporteren en presenteren van informatie dient afgestemd te zijn op de doelgroep waarvoor de informatie bestemd is. Gewoonlijk vallen er vier doelgroepen te onderscheiden: de klanten, IT-leidinggevenden/management, interne IT en de leveranciers. Voor iedere doelgroep moet het juiste format gekozen worden, maar de informatie moet altijd begrijpelijk, behapbaar en van waarde zijn, en op het goede moment gepresenteerd worden.

Binnen veel organisaties wordt informatie niet op de juiste wijze gerapporteerd en/of gepresenteerd. Zo worden bijvoorbeeld verzamelde ruwe data (vaak rechtstreeks van de tool) aan iedereen gerapporteerd, zonder de nodige verwerking of analyse. Een ander probleem ten aanzien van het presenteren en gebruiken van informatie is een overmaat die schaadt. Managers op alle niveaus worden gebombardeerd met te veel e-mails, te veel vergaderingen en te veel rapporten. De praktijk is dat de managers deze informatie vaak niet nodig hebben en er vervolgens ook niets mee doen.

Hieronder volgen enkele veel voorkomende problemen met presenteren en rapporteren:

■ Iedereen ontvangt hetzelfde rapport.

■ Het format is niet wat de mensen willen. ■ Het ontbreken van een managementsamenvatting. ■ De rapporten zijn niet gekoppeld aan een baseline of Balanced Scorecard. ■ Er zijn te veel ondersteunende gegevens opgenomen. ■ De rapporten worden gepresenteerd in een taalgebruik dat te moeilijk (technisch) is voor de doelgroep.

De

invoer omvat:

■ Verzamelde informatie. ■ Formatgegevens en sjablonen ■ Contactgegevens van stakeholders. Stap 7 – correctieve acties implementeren Een organisatie zal niet in staat zijn alle verbeteringen die zijn vastgesteld direct te implementeren. Om die reden zal zij aan de diverse opties een

prioriteit toewijzen op basis van de organisatiedoelen en externe reguleringen die zijn vastgesteld in de servicestrategie.

Het is raadzaam gebruik te maken van de verworven kennis en deze te combineren met voorafgaande ervaring voor weloverwogen beslissingen over optimalisering, verbetering en correctie van services. Managers moeten problemen vaststellen en oplossingen aandragen.

Dit stadium kan een aantal activiteiten omvatten zoals: goedkeuring van verbeteringsactiviteiten, prioritering en het opstellen van een business case, afstemming met changemanagement en de andere levenscyclusstadia en het ondersteunen van managers bij verbeterprojecten en het controleren of het verbeterproject de gestelde doelen gaat realiseren.

CSI identificeert veel verbeteringsmogelijkheden, maar organisaties kunnen zich niet veroorloven deze allemaal te implementeren. Zoals eerder gezegd, moet een organisatie verbeteringsactiviteiten prioriteren met het oog op de doelen, doelstellingen, Return of Investment (ROI), het soort services enzovoort en ze documenteren in het CSI-register. Verbeteringsinitiatieven kunnen ook van buitenaf opgelegd worden bijvoorbeeld door (veranderde) wetgeving, politieke besluiten en door de concurrentie.

Er zijn verschillende managementniveaus in een organisatie en bij het doorvoeren van verbeteringen is het belangrijk te begrijpen op welk niveau de activiteiten moeten zijn gericht. Elk managementniveau heeft een eigen perspectief. Op directieniveau moet aangetoond kunnen worden dat er wordt voldaan aan kwaliteits- en prestatiedoelen terwijl het risico is geminimaliseerd. Op operationeel niveau moet het management weten wat er gaande is, zodat zij weloverwogen keuzes kunnen maken en oordelen kunnen uitspreken. Alleen als die verschillende perspectieven goed begrepen worden is het mogelijk om informatie te leveren die maximale waarde heeft voor managers op een bepaald managementniveau.

De

invoer omvat:

■ Kennis verkregen door het presenteren en gebruiken van de informatie. ■ Overeengekomen implementatieplannen (uit stap 6). ■ Een CSI-register voor de initiatieven die zijn geïnitieerd vanuit andere bronnen.

Generieke procesinformatie De volgende informatie is specifiek voor het proces in 7 stappen maar niet noodzakelijk voor een bepaalde activiteit binnen het proces.

8.4.3 Informatiemanagement De informatie die nodig is om te begrijpen wat er moet worden verbeterd, hoeveel en wanneer, komt vanuit verschillende bronnen. Voor een volledig en helder beeld is het belangrijk om alle informatie te verzamelen en te analyseren.

■ De servicecatalogus. ■ Serviceleveleisen. ■ Monitoren en rapporteren van de serviceleveldoelen. ■ Kennismanagementsysteem voor services. ■ Configuratiemanagementsysteem. ■ Metrics van processen. ■ Klanttevredenheidsonderzoeken. ■ Klachten en complimenten. ■ Alle data, informatie en kennis geproduceerd door het proces zelf.

8.4.4 Interfaces Het verbeterproces in 7 stappen heeft relaties met alle andere processen. Elke stap van de CSI-levenscyclus is betrokken bij elk ander levenscyclusstadium.

■ Servicestrategie – Monitort de voortgang en analyseert de resultaten van de gekozen strategieën, beleid, standaarden en de genomen beslissingen op het architecturale vlak.

■ Serviceontwerp – Tijdens het in kaart brengen van de eisen van de business (business requirements) worden ook de kritische succesfactoren (KSF’S) en key performance indicatoren (KPI’S) van de betreffende service gedefinieerd. Vervolgens moet vastgesteld worden hoe effectief die KSF’s en KPI’s zijn en of het daadwerkelijk mogelijk is om aan de hand van de KPI’s metingen te verrichten.

■ Servicetransitie – Voor het ontwikkelen en testen van de bewakingsprocedures en kwaliteitscriteria die moeten worden gebruikt voor en na implementatie van de nieuwe of gewijzigde service.

■ Serviceproductie – Verzamelt, verwerkt, analyseert en presenteert data en informatie betreffende de services in de operationele omgeving.

8.4.5 Aanleidingen (triggers) Veel aanleidingen zijn al genoemd en besproken eerder in deze paragraaf.

8.4.6 Invoer Veel aspecten die de invoer van het verbeterproces vormen zijn eerder in deze paragraaf aan de orde geweest. Hieronder staat een deel van de input dat belangrijk is voor het verbeterproces in 7 stappen:

■ Servicecatalogus. ■ SLR’s. ■ De vergadering waarin de service wordt beoordeeld (service review meeting).

■ Visie- en missiestatements. ■ Ondernemings-, divisie- en afdelingsdoelen en -doelstellingen. ■ Wettelijke eisen. ■ Governance-eisen. ■ Begrotingscyclus. ■ Klanttevredenheidonderzoek. ■ De overall IT-strategie.

■ Marktverwachtingen. ■ Introductie van nieuwe technische systemen. ■ Flexibele commerciële modellen.

8.4.7 Uitvoer Ook de uitvoer van het proces is al eerder uitgebreid aan de orde geweest.

8.4.8 Kritieke succesfactoren De kritieke succesfactoren aan de hand waarvan het succes van het verbeterproces in 7 stappen wordt beoordeeld, zijn in feite die van de levenscyclusstadia en -processen waarop ze worden toegepast. Daarom komen de hier gegeven voorbeelden uit andere gebieden.

■ Alle geïdentificeerde verbeteringsmogelijkheden. ■ De kosten van het leveren van services dalen. ■ De vereiste zakelijke uitkomsten van IT-services worden gerealiseerd.

8.4.9 Metrics De belangrijkste prestatie-indicatoren aan de hand waarvan het succes van het verbeterproces in 7 stappen wordt beoordeeld, zijn in feite die van de levenscyclusstadia en -processen waarop ze worden toegepast. Daarom komen de hier gegeven voorbeelden uit andere gebieden.

■ Procentuele verbetering met betrekking tot defecten. ■ Procentuele daling in de overall-kosten van servicelevering. ■ Stijging van het aantal klanten (in procenten) dat tevreden is over de servicedesk.

8.4.10 Uitdagingen Enkele potentiële uitdagingen voor het verbeterproces in 7 stappen zijn:

■ De vereiste resources verkrijgen om het proces te implementeren en uit te voeren.

■ Op het juiste meetniveau data verzamelen en vervolgens tools ter beschikking hebben waarmee die data bewerkt kunnen worden.

■ De IT-organisatie zover krijgen dat CSI methodisch, consistent en gestructureerd plaatsvindt.

■ Betrokkenheid van leidinggevenden, managers en IT-personeel bewerkstelligen.

■ Voldoende informatie verkrijgen van de business wat betreft verbeteringseisen en kostenbesparingen.

■ Leveranciers overhalen om verbetering op te nemen in hun contractuele afspraken.

8.4.11 Risico’s Hier volgen enkele potentiële risico’s voor het verbeterproces in 7 stappen:

■ Verbeterinitiatieven komen op een random of ad hoc wijze tot stand. ■ CSI is niet geformaliseerd. ■ Onvoldoende monitoring en analyse van de data, en het ontbreekt aan kennis om die gebieden te prioriteren waar de noodzaak van verbetering het grootst is.

■ De houding van ‘We hebben het altijd zo gedaan’, ‘Het was altijd goed genoeg zo’.

■ Niet in staat zijn de voordelen van een geformaliseerde verbeteraanpak over de bühne te krijgen.

■ Gebrek aan van eigenaarschap. ■ Geen duidelijk inzicht in de behoeften en doelstellingen van de organisatie.

■ 8.5   ORGANISATIE De procesmanager moet de beschreven rollen toebedelen aan bestaande medewerkers. Heldere definities van de verantwoordelijkheden en aansprakelijkheid die gekoppeld zijn aan die rollen zijn daarbij vereist. Deze definities kunnen bijvoorbeeld uitgewerkt zijn in de vorm van een

RACI -

matrix (Responsible, Accountable, Consulted, Informed).

8.5.1 Rollen en verantwoordelijkheden CSI kent permanente rollen zoals de servicemanager, de service-eigenaar, de proceseigenaar, maar ook tijdelijke projectrollen zoals projectmanagers en projectteamleden. Tabel 8.3 biedt een overzicht van de begeleidende hoofdactiviteiten en rollen. Niet alle rollen zijn voltijds. Een eerste globale verdeling kan wanneer nodig worden aangepast.

Tabel 8.3 Belangrijkste activiteiten en de toe te kennen rollen

Tabel 8.4 biedt een overzicht van de rollen, activiteiten en competenties die nodig zijn voor de verschillende stappen in het CSI-verbeteringsproces.

Tabel 8.4 Rollen voor het verbeterproces in zeven stappen

Voor het ITIL Foundation-examen is kennis nodig behorende bij de rollen die vetgedrukt zijn in tabel 8.4. Deze rollen zullen hier worden besproken, behalve de rol van

servicelevel manager. Deze rol is al besproken in

hoofdstuk 5 ‘Serviceontwerpfase’ (paragraaf 5.13). De paragraaf ‘Andere rollen’, aan het eind van deze paragraaf, noemt nog drie andere belangrijke rollen binnen CSI.

Servicemanager De servicemanager managet de ontwikkeling, implementatie, evaluatie en het verdere beheer van nieuwe en bestaande producten en services. De servicemanager is verantwoordelijk voor:

■ Het realiseren van de bedrijfsstrategie en -doelen. ■ Benchmarking. ■ Financieel management. ■ Klantenbeheer. ■ Leveranciersmanagement. ■ Managen van de volledige levenscyclus. ■ Inventarisbeheer. De servicemanager dient kennis te hebben van marktanalyse. Hij moet in staat zijn te anticiperen op nieuwe markbehoeften, complexe programma’s kunnen formuleren, personeel begeleiden en services verkopen.

CSI-manager Dit is een essentiële rol om verbeterprogramma’s tot een succes te maken. De

CSI-manager is verantwoordelijk voor CSI in de organisatie. Onder die verantwoordelijkheid vallen het meten, analyseren, onderzoeken en het rapporteren over trends en initiatieven voor verbeteringsactiviteiten. Ook zorgt de CSI-manager dat er voldoende resources beschikbaar zijn om de CSIactiviteiten te ondersteunen. Deze CSI-manager is verantwoordelijk voor:

■ Ontwikkeling van het CSI-domein. ■ De communicatie over CSI in de organisatie; de organisatie bewust maken van het belang van CSI.

■ Toekennen van CSI-rollen. ■ Identificeren en prioriteren van verbeterkansen, en deze kansen communiceren met het seniormanagement en de service-eigenaar.

■ Samen met de servicelevelmanager ontwikkelen van de eisen met betrekking tot het monitoren van services.

■ Ervoor zorgen dat de juiste tools voor het monitoren zijn geïnstalleerd. ■ In samenwerking met de servicelevelmanager opstellen van serviceverbeterprogramma’s (SIP’s).

■ Bepalen van de baselines waarmee nagegaan kan worden (na metingen) of processen en services werkelijk verbeterd zijn.

■ Formuleren van en rapporteren over KSF’s en KPI’s. ■ Toepassen van frameworks en modellen die CSI ondersteunen. ■ Ervoor zorgen dat kennismanagement deel uitmaakt van de dagelijkse routine van de IT-organisatie.

■ Evalueren van geanalyseerde data. De CSI-manager moet in staat zijn om overal in de organisatie projecten te leiden. Dit betekent dat hij goede relaties met de business en het ITmanagement moet opbouwen en in stand houden, dat hij ‘een neus moet hebben’ voor verbeterkansen in de gehele organisatie en dat hij leidinggevende capaciteiten heeft richting zijn eigen medewerkers (adviseren, coachen, motiveren etc.)

Service-eigenaar Het is van groot belang een persoon aan te wijzen die voor een service verantwoordelijk is: dat is de

service-eigenaar. Deze is het centrale

aanspreekpunt voor een specifieke service. Het maakt niet uit waar de onderliggende technische componenten, het proces of de functies zich bevinden. De belangrijkste verantwoordelijkheden zijn:

■ Het eigenaar zijn en vertegenwoordigen van de service. ■ Begrijpen welke componenten deel uitmaken van de service. ■ De prestaties en beschikbaarheid meten. ■ Deelnemen aan vergaderingen van de Change Advisory Board (CAB) als daar wijzigingen besproken worden die relevant zijn voor de service die de service-eigenaar vertegenwoordigt.

■ Samenwerken met de CSI-manager om verbeteringen te identificeren en prioriteren.

■ Deelnemen aan interne en externe servicebeoordelingen (reviews). ■ De registratie van de service in de servicecatalogus onderhouden. ■ Deelnemen aan de onderhandelingen over SLA’s en OLA’s. Proceseigenaar Voor een proces is het hebben van een eigenaar net zo cruciaal als voor een service. De

proceseigenaar zorgt dat de organisatie een proces doorloopt. Dit

moet een senior-manager zijn met voldoende geloofwaardigheid, invloed en gezag in de onderdelen van de organisatie die deel uitmaken van het proces.

De proceseigenaar vervult de essentiële rol van proceskampioen, ontwerpleider, advocaat, coach en beschermer. Zie ook paragraaf 5.13.

Andere rollen Andere rollen die belangrijk zijn voor CSI:

■ Kennismanager – ontwerpt en onderhoudt een kennismanagementstrategie en implementeert die.

■ Rapportageanalist – evalueert en analyseert data en identificeert trends. Deze analist werkt vaak samen met SLM-rollen (zie ook paragraaf 5.3). Hij moet over goede communicatievaardigheden beschikken omdat rapportage een essentieel element van communicatie is.

■ Communicatieverantwoordelijke

– ontwerpt een communicatiestrategie

voor CSI.

■ 8.6   METHODEN, TECHNIEKEN EN TOOLS Er zijn verschillende methoden en technieken om te controleren of geplande verbeteringen werkelijk tot meetbare verbeteringen leiden. Een enkele methode of techniek is meestal niet genoeg. Er moet naar een beste ‘mix’ worden gezocht voor de organisatie. Men moet natuurlijk kiezen voor methoden en technieken die geschikt zijn om aan het desbetreffende proces te kunnen meten, en waarmee de meetresultaten grondig gedocumenteerd kunnen worden. Verder is het van belang dat medewerkers zich de methode of techniek snel eigen kunnen maken.

8.6.1 Evaluatie van de implementatie Om te bepalen of de verbeteringen de gewenste effecten hebben, moet men beoordelen of de oorspronkelijke probleemsituatie werkelijk is verbeterd, en hoe de organisatie de verbetering heeft gepland en doorgevoerd. De volgende vragen helpen daarbij:

■ Hebben we de huidige situatie correct beoordeeld en het probleem goed geformuleerd?

■ Hebben we de correcte beslissingen genomen wat betreft onze strategie? ■ Hebben we de strategie correct doorgevoerd? ■ Hebben we de juiste CSI-doelen geformuleerd?

■ Zijn de doelen behaald? ■ Bieden we nu betere IT-services? ■ Wat zijn de lessons learned en waar staan we nu?

8.6.2 Assessments In een assessment worden de prestaties van een operationeel proces afgezet tegen een prestatiestandaard. Dit kan een afspraak in een SLA zijn, een standaard voor procesvolwassenheid of een benchmark van bedrijven in dezelfde branche. Door het laten uitvoeren van assessments tonen ITorganisaties hun wil om in hun ontwikkeling te groeien.

Assessments zijn een geschikt middel om antwoord te vinden op de vraag ‘waar staan we nu?’, en om te bepalen hoe groot het verschil is met ‘waar willen we zijn’. Met een goed ontworpen framework voor het beoordelen van de groei/ontwikkeling kan men de levensvatbaarheid van alle aspecten van de procesomgeving evalueren, inclusief de mensen, het proces en de technologie, en de factoren die effect hebben op de overall-effectiviteit van de processen in het bedrijf. Men moet zich bedenken dat de gewenste prestaties of het gewenste volwassenheidsniveau van een proces zal afhangen van de impact die het proces heeft op de bedrijfsprocessen van de klant.

Eerst moet de relatie tussen bedrijfsprocessen, IT-services, IT-systemen en componenten worden vastgesteld. CSI kan de effectiviteit- en efficiëntieresultaten voor elke component afzonderlijk bepalen. Dat helpt bij het bepalen van de gebieden die voor verbetering vatbaar zijn.

Het is van cruciaal belang om helder vast te stellen wat aan een assessment onderworpen wordt. Tevens is het belangrijk om hierbij ook uitdrukkelijk stil te staan bij de doelen van de assessment en de verwachtingen ten aanzien van de wijze waarop de resultaten ervan de toekomst gebruikt zullen worden. De scope van een assessment kan gericht zijn op drie verschillende niveaus:

■ Assessment van alleen het proces op basis van de algemene principes en richtlijnen van het procesframework, waarbinnen het betreffende proces gedefinieerd is.

■ Assessment van de mensen, het proces en de technologie, waarbij de procesassessment wordt uitgebreid met een assessment van de organisatorische

structuur, competenties, rollen en de talenten van de managers en procesuitvoerenden alsook de mogelijkheden van de ondersteunende technologie om de doelstellingen van het proces te realiseren.

■ Volledige assessment waarbij ook gekeken wordt naar de culturele aspecten van een organisatie en het vermogen om een processtrategie te uit te werken.

Al deze factoren worden vergeleken met de volwassenheidsattributen van het geselecteerde volwassenheidsmodel.

Assessments zijn nuttig in de planningsfase (plan), implementatiefase (do) en meetfase (check).

Voordelen van assessments:

■ Bepaalde delen van een proces kunnen onafhankelijk van de rest worden beoordeeld, en de impact van die specifieke component op de rest van het proces kan worden bepaald.

■ Ze zijn herhaalbaar. Nadelen van assessments:

■ Ze zijn een momentopname in de tijd en bieden geen inzicht in de culturele dynamiek van een organisatie.

■ Ze worden een doel op zich in plaats van een middel om een doel te bereiken.

■ Ze zijn arbeidsintensief. ■ De resultaten zijn nog steeds afhankelijk van subjectieve assessoren en dus niet volledig objectief, zelfs niet als de metingen objectief zijn.

Dit geldt voor zowel interne en externe assessments. Tabel 8.5 toont een overzicht van de voor- en nadelen van beide vormen.

Benchmarks Een benchmark is een specifiek type assessment waarbij organisaties de resultaten van (delen van) hun processen vergelijken met de prestaties van dezelfde soort processen die over het algemeen worden erkend als best practice. Dit kan op vier manieren:

■ Intern – ten opzichte van een bepaalde vastgestelde baseline (uitgangspunt).

■ Intern – ten opzichte van een ander systeem of andere afdeling. Tabel 8.5 Interne versus externe assessments

■ Extern – ten opzichte van industriële standaarden. ■ Extern – direct tegenover gelijksoortige organisaties; dit is echter alleen nuttig als er voldoende van dergelijke organisaties zijn in termen van omgeving, sector en geografische locatie.

Om dit te bepalen kan een organisatieprofiel worden opgesteld, dat bestaat uit vier hoofdbestanddelen: bedrijfsinformatieprofiel, huidige bedrijfsmiddelen, huidige best practices, complexiteit.

In alle gevallen levert een benchmark de volgende resultaten:

■ Laat de prestatieniveaus zien. ■ Toont waar de prestaties tekortschieten. ■ Brengt in beeld welke risico’s deze tekortkomingen met zich meebrengen. ■ Helpt de verbeterprioriteiten vast te stellen. ■ Helpt om de informatie goed naar alle betrokken partijen te communiceren.

Op deze manier ontdekken organisaties of hun processen kosteneffectief zijn, of ze voldoen aan de klantbehoeften en hoe effectief ze zijn vergeleken met andere organisaties. Dit kweekt bewustzijn over de noodzaak voor verbetering (bijvoorbeeld op het terrein van schaalvoordeel, efficiëntie en effectiviteit) en over de manieren om die te realiseren. Het management kan er dan naar handelen. In het ideale geval wordt benchmarking regelmatig herhaald en wordt het een onderdeel van de continue cyclus van het verbeteringsproces.

Een bestudering van de prestaties van de eigen organisatie en afdelingen van andere organisaties vraagt tijd. Een benchmarkdatabase opzetten en andere organisaties bezoeken gaat ook gepaard met kosten.

Benchmarking gebeurt in samenwerking met:

■ De business. ■ Gebruikers of consumenten. ■ Interne serviceproviders. ■ Externe serviceproviders. ■ Gebruikers in het ‘publieke domein’. ■ Benchmarkpartners (andere organisaties die bij het vergelijkingsonderzoek betrokken zijn).

Eerst wordt nagegaan of er probleemgebieden zijn. De stappen van het CSIverbeteringsproces kunnen hiervoor worden gebruikt, ondersteund door (enkele van) de volgende technieken:

■ Informele besprekingen met de business, personeel of leveranciers. ■ Focusgroepen. ■ Marktonderzoek. ■ Kwantitatief onderzoek. ■ Interviews. ■ Vragenlijsten. ■ Re-engineeringanalyse. ■ In kaart brengen van processen. ■ Kwaliteitscontrolevariatierapporten. ■ Financiële-verhoudingenanalyse. Twee bijzondere vormen van benchmarking zijn:

■ Vergelijking van procesgroei. ■ Totale bedrijfskosten (TCO, Total Cost of Ownership) Gap-analyse Uit de resultaten van de assessments en benchmarks weet de organisatie waar zij nu staat (de zogeheten Ist-situatie), en kan ze ook bepalen waar ze in de toekomst wil zijn (Sollsituatie). De organisatie kan met een zogeheten gapanalyse bepalen hoe groot de kloof is die ze moet overbruggen om dat te bereiken.

Zo’n gap-analyse brengt ook nieuwe inzichten en mogelijkheden voor verbetering aan het licht gebracht. Het service gap-model in afbeelding 8.8 toont mogelijke gaps.

De analyse kan op een strategisch, tactisch of operationeel niveau plaatsvinden. De analyse levert ook een overzicht op van de hoeveelheid resources en geld die een organisatie moet investeren om gewenste, specifieke doelen te bereiken.

Afbeelding 8.8 Voorbeeld van een service gap-model

SWOT-analyse In een SWOT -analyse

wordt gekeken naar de sterke en zwakke punten en

de kansen en bedreigingen (Strengths, Weaknesses, Opportunities en Threats) van een organisatie(onderdeel) of project. De organisatie beantwoordt hiertoe de volgende vragen:

■ Hoe kunnen we profiteren van onze sterke punten? ■ Hoe komen we af van onze zwakke punten? ■ Hoe kunnen we kansen optimaal benutten? ■ Hoe elimineren en/of managen we bedreigingen? Voordat een SWOT-analyse wordt uitgevoerd moet eerst een einddoel worden gesteld. Men moet nagaan welke sterke punten bijdragen aan het bereiken van dat doel en welke zwakheden dit tegenwerken. Ook wordt gekeken naar de externe omstandigheden die het doel ten goede komen en welke externe omstandigheden daarin belemmerend zijn.

Om een SWOT-analyse te realiseren voor de gehele organisatie moet er eerst een SWOT per organisatieonderdeel of functie worden uitgevoerd. Deze worden dan bijeengebracht in een bedrijfs-SWOT. Zie tabel 8.6 voor voorbeelden van aspecten zoals die in SWOT’s opgenomen kunnen zijn.

Rummler-Brache swimlanediagram Geary Rummler en Alan Brache introduceerden het idee om de relaties tussen processen en organisaties of afdelingen als ‘banen in een zwembad’ weer te geven, het zogeheten Rummler-Brache

swimlane-diagram. Hiermee wordt de

stroom van een proces weergegeven: van de klant via de afdeling naar de technologie (zie afbeelding 8.9). De horizontale rijen (lanen) scheiden de afzonderlijke organisaties of afdelingen van elkaar. Activiteiten en beslissingen zijn verbonden via pijlen om de stroom aan te geven. De rij waarin deze componenten zijn geplaatst, geeft aan welke organisatiecomponent verantwoordelijk is voor de activiteit of beslissing.

Tabel 8.6 Voorbeelden van aspecten uit SWOT-analyses

Afbeelding 8.9 Rummler-Brache swimlane-diagram In een swimlane-diagram worden procesactiviteiten gekoppeld aan afdelingen in de organisatie. Processen krijgen daarmee een herkenbare plaats in de structuur van de organisatie. Het management krijgt daarmee een goed inzicht in hoe processen in de organisatie verlopen.

8.6.3 Tools CSI heeft verschillende soorten software nodig voor het ondersteunen, testen en monitoren van en rapporteren over de ITSM-processen. Als onderdeel van de assessment ‘waar willen we zijn?’ worden de eisen gesteld aan verbeteringstools bepaald en gedocumenteerd. De noodzaak en hoe technisch

‘vernuftig’ tools moeten zijn, hangt af van in hoeverre de organisatie behoefte heeft aan IT-services en van de grootte van de organisatie. In elk geval moeten tools de belangrijkste componenten van een service monitoren en analyseren op een manier die het CSI-verbeteringsproces ondersteunt. Ze kunnen de belangrijkste processen ook centraliseren, automatiseren en integreren. Hiermee worden dan weer nieuwe data geproduceerd voor trendanalyse.

Tools die te gebruiken zijn voor CSI zijn bijvoorbeeld:

■ IT-servicemanagementsuites. ■ Eventmanagement. ■ Systeem- en netwerkbeheer. ■ Geautomatiseerde incident- en probleemoplossing. ■ Kennismanagement. ■ Prestatiemanagement. ■ Monitoren van applicatie- en serviceprestaties. ■ Tools voor statistische analyses. ■ Softwareversiecontrole/softwareconfiguratiemanagement. ■ Softwaretestmanagement ■ Securitymanagement. ■ Project- en portfoliomanagement. ■ Financieel management. ■ Bedrijfsinformatie/-rapportage.

■ 8.7   IMPLEMENTATIE Voordat CSI wordt geïmplementeerd, moet worden gezorgd dat:

■ De kritieke rollen van CSI-manager, service-eigenaar en rapportageanalist zijn ingevuld.

■ Er een aanpak is voor het monitoren en rapporteren van de resultaten van de metricstechnieken.

■ Interne evaluatievergaderingen zijn gepland. ■ Externe evaluatievergadering is gepland volgend op de interne evaluatievergaderingen.

Communicatie vormt een belangrijk onderdeel van elk serviceverbeterproject. Een communicatieplan is vereist waarin afhandeling van de antwoorden en feedback van de doelgroep is opgenomen. Het communicatieplan moet altijd duidelijk maken wat de boodschap, de doelgroep, de timing, de frequentie van communicatie, de methode van communicatie en het feedbackmechanisme is.

CSI kan worden geïmplementeerd volgens verschillende aanpakken:

■ Service-aanpak – hiermee stelt men vast welke issues zich voordoen met betrekking tot de services. Men creëert vervolgens een actieplan met de service-eigenaar: hoe gaan we ervoor zorgen dat het betreffende issue wordt opgelost?

■ Levenscyclusaanpak – hiermee kijkt men naar de resultaten van de verschillende fasen van de levenscyclus en naar mogelijke verbeteringen.

■ Functionele aanpak – indien zich veel issues voordoen met betrekking tot een specifieke functie in een organisatie, bijvoorbeeld de serverbeheergroep, kan men zo veel mogelijk problemen in deze functiegroep verwijderen met een testproject.

8.7.1 Business case De business case moet duidelijk maken of het nut heeft met CSI te starten. Deze moet aangeven wat er exact verandert in de bedoelde toekomstige situatie in vergelijking met de uitgangssituatie. Vanaf een vastgestelde baseline kan een organisatie schatten wat de huidige situatie oplevert en kost en hoeveel de verbetering van de situatie zal opleveren en kosten. Dit moet worden geformuleerd in een taal die de business begrijpt. De volgende vragen moeten in elk geval worden beantwoord:

■ Waar zijn we? – Stel de huidige servicelevels vast. ■ Wat willen we? – Bepaal de visie, missie, doelen en doelstellingen van het bedrijf.

■ Wat hebben we nodig? – Bepaal welke services essentieel zijn voor het realiseren van de missie en stel op basis daarvan prioriteiten vast.

■ Wat kunnen wij ons veroorloven? – Stel met behulp van servicelevelmanagement en financieel management het budget voor ITservices vast en bekijk welke acties praktisch uitvoerbaar zijn.

■ Wat zullen we krijgen? – Stel in samenspraak met de business de vereiste resultaten vast.

■ Wat kregen we? – Laat serviceproductie de servicelevels monitoren en daarover rapporteren.

■ Beantwoordt het nog steeds aan onze wensen/behoeften? – Kijk samen met de business naar mogelijke verdere verbeteringen.

Voor een business case is het belangrijk om een overzicht te hebben van alle kosten en baten van CSI. Extra informatie over de meting en schatting van kosten en baten is te vinden in de paragrafen 8.4 en 8.5.

Kosten Wanneer een besluit wordt genomen over een verbeteringsinitiatief moet altijd rekening worden gehouden met de kosten van ontwikkeling, productie en doorlopend onderhoud. Voorbeelden hiervan zijn:

■ Arbeidskosten. ■ Trainingskosten. ■ Tools voor verwerking van meetgegevens. ■ Assessments of benchmarkstudies. ■ Managementtijd voor voortgangsbewaking. ■ Communicatiecampagnes om bewustzijn te creëren en de cultuur te wijzigen.

Baten/voordelen De resultaten van een serviceverbeteringsplan kunnen worden verdeeld in:

■ Verbeteringen – meetbare verbeteringen ten opzichte van de uitgangssituatie.

■ Baten – winst behaalt met de verbeteringen (gewoonlijk in financiële termen).

■ Return on Investment (ROI) – het verschil tussen de kosten en baten van de verbetering.

■ Value on Investment (VOI) – ROI plus de extra waarde die niet kan worden uitgedrukt in geld of die pas op langere termijn duidelijk wordt. Extra waarde van zoiets als meer klanttevredenheid is moeilijk te kwantificeren. Als er voldoende ‘harde cijfers’ zijn, voegen die nog niet veel toe; een toelichting in een bijlage over de kwalitatieve waarde is zinvoller.

Zowel directe als indirecte voordelen moeten worden geformuleerd en rekening moet worden gehouden met elke groep stakeholders voor elk organisatorisch niveau. De baten moeten meetbaar worden vastgesteld. De business staat op de eerste plaats. Toegevoegde waarde voor de business kan inhouden:

■ Sneller op de markt. ■ Klantenbinding. ■ Lagere onderhoudskosten voor inventaris. ■ Groter marktaandeel. CSI kan de volgende toegevoegde waarde opleveren:

■ Voor de business: •

Betrouwbaardere ondersteuning voor bedrijfsprocessen door incident-, probleemen changemanagement.

•

Hogere productiviteit door betere kwaliteit en beschikbaarheid van ITservices.

•

De business weet wat ze kunnen verwachten van de IT-afdeling en wat de IT-afdeling van hen verwacht.

•

Procedures om te zorgen dat de continuïteit van de IT-service is gericht op de behoeften van de business.

•

Betere managementinformatie over bedrijfsprocessen en IT-services.

•

De IT-afdeling heeft meer kennis van de bedrijfsprocessen, zodat er beter op de wensen van de business kan worden gereageerd.

•

Kwaliteitsprojecten, releases en wijzigingen lopen volgens plan en leveren de afgesproken kwaliteit tegen afgesproken kosten.

•

Minimaal aantal gemiste kansen.

•

Betere relatie tussen de business en IT.

•

Grotere klanttevredenheid.

■ Financieel: •

Efficiënte IT-services.

•

Kosteneffectieve IT-infrastructuur en -services.

•

Kostenreductie, bijvoorbeeld door lagere kosten voor de implementatie van wijzigingen en minder overbodige processen en uitrusting.

•

Wijzigingen hebben minder (financiële) impact op de business.

•

Services voldoen aan de eisen maar leveren geen overmatige prestatie.

•

Betere verdeling van middelen, zodat uitgaven voor de continuïteit van IT-services in proportie zijn met het belang van de bedrijfsprocessen die zij ondersteunen.

•

Kostenstructuur is afgestemd op bedrijfsbehoeften.

•

Minimale kosten en risico’s met controles dat aan wettelijke eisen wordt voldaan.

■ Innovatief: •

Proactievere ontwikkeling van technische systemen en services door betere informatie over gebieden waarin wijzigingen tot winst kan leiden.

•

De IT-afdeling reageert beter op wijzigingen als de business of de markt daarom vraagt en speelt beter in op nieuwe trends.

•

Een business die de IT-serviceproviders vertrouwt durft ‘groot te denken’.

■ Interne voordelen voor de IT -organisatie : •

Meer competente IT-afdeling, minder kans op fouten.

•

Integratie van mensen en processen.

•

Meer communicatie en teamwork (ook met de business).

•

Productievere en beter gemotiveerde medewerkers.

•

Vastgestelde rollen en verantwoordelijkheden.

•

effectievere processen, beter gebruik van middelen.

•

IT herhaalt en vergroot winstpunten door gestegen procesgroei.

•

Betere metrics en managementrapporten door gestructureerde methoden voor meting en kennisvergaring.

•

Beter beeld van en meer vertrouwen in huidige en toekomstige ITverbetermogelijkheden.

•

Services en systemen bereiken haalbare doelen binnen een realistische planning.

•

•

Betere aansturing van serviceproviders.

•

Betere relatie met de business.

Kosten afgestemd op bedrijfsbehoeften.

8.7.2 Kritieke succesfactoren (KSF) Een Kritieke Succesfactor (KSF) is een noodzakelijke voorwaarde voor een goed resultaat van een service of proces. Kritieke succesfactoren voor CSI zijn:

■ Een CSI-manager benoemen (zie ook paragraaf 8.5 ‘Organisatie’). ■ CSI moet door de hele organisatie worden opgepakt.

■ Constant zichtbare managementparticipatie in CSI-activiteiten, bijvoorbeeld door een visie te ontwikkelen en daarover te communiceren.

■ Heldere criteria voor de prioritering van verbeterprojecten. ■ Adoptie van de servicelevenscyclusaanpak. ■ Voldoende financiering. ■ Allocatie van middelen – mensen worden toegewezen aan de verbeteringsinspanning, niet alleen naast hun lange lijst taken die ze moeten uitvoeren.

■ Technische systemen om verbeteringsactiviteiten te ondersteunen. ■ Omarmen van servicemanagementprocessen in plaats van die aan te passen aan persoonlijke behoeften en agenda’s.

8.7.3 Uitdagingen en risico’s Introductie van CSI komt met de volgende uitdagingen en risico’s:

■ Gebrek aan managementsteun. ■ Slechte relatie en communicatie tussen IT en de business. ■ Te weinig kennis van de IT-impact op de business en de belangrijke processen.

■ Te weinig kennis van de prioriteiten van de business. ■ Gebrek aan informatie, monitoring en metingen. ■ Niet gebruiken van informatie uit rapporten. ■ Onvoldoende middelen, budget en tijd. ■ Onvolgroeide (onvolwassen) servicemanagementprocessen. ■ Te weinig of geen kennismanagement (zie ook paragraaf 8.5 ‘Organisatie’). ■ Proberen om alles tegelijk aan te passen. ■ Weerstand tegen (culturele) wijzigingen. ■ Niet voldoen aan bedrijfs- of IT-doelstellingen, strategiebeleid. ■ Zwak leveranciersmanagement. ■ Niet testen. ■ Gebruik van tools is te complex of onvoldoende vertegenwoordigd. ■ Verschillen in gebruikte technologie.

8.7.4 Interfaces CSI gebruikt veel van de gehele levenscyclus van een service. De informatie die hieruit voortvloeit, samen met de eisen van de business, de technische

specificaties, de kansen van IT, het budget, de trends en wetgeving, geven inzicht in de kansen op verbetering van de organisatie.

Servicelevelmanagement (SLM) Servicelevelmanagement is het belangrijkste proces voor CSI. Het bespreekt met de business wat de IT-organisatie moet meten en wat de resultaten moeten zijn. Dat is waarom deze paragraaf begint met informatie over wat SLM en CSI gemeen hebben. Voor meer informatie over het servicelevelmanagementproces, zie hoofdstuk 5 over ‘serviceontwerp’.

Na elke fase van de levenscyclus moet worden getest of het verbeteringsinitiatief aan de doelen heeft voldaan. Dit kan met behulp van de

implementatie-evaluatie (PIR, Post Implementatie Review) uit het changemanagementproces. Omdat de stappen 1 en 2 van het zeven stappen CSI-verbeteringsproces primair binnen SLM en CSI liggen, wordt alleen een overzicht gegeven van de gemeenschappelijke basis van CSI en de overige ITIL-processen en de verschillende vanaf stap 3. Serviceproductie levert ook informatie over wat kan worden gemeten voorafgaand aan stap 2.

In het licht van CSI is de doelstelling van SLM het onderhouden en verbeteren van de kwaliteit van IT-services. SLM doet dit door een constante cyclus van afspreken, bewaken van en rapporteren over IT-servicelevels.

In het CSI-verbeteringsproces speelt SLM een rol bij:

■ Identificeren van de strategie voor verbetering. ■ Formuleren wat gemeten zal worden. ■ Data verzamelen (meting). ■ Dataverwerking. ■ Data-analyse. ■ Presenteren van de informatie (rapporteren). ■ Implementeren van correctieve acties (serviceverbeterplan). Op deze manier bepaalt SLM wat de organisatie meet en bewaakt. Samen met de business bepaalt het SLM-proces waarover en op basis van welke metingen gerapporteerd moet worden. Tevens signaleert dit proces nieuwe bedrijfsbehoeften. Met behulp van deze informatie identificeert en prioriteert

CSI verbeteringsmogelijkheden. Dit is de belangrijkste input voor de SIP (het serviceverbeterplan).

Het is raadzaam om een jaarbudget vast te stellen voor SIP’s. SLM en CSI kunnen dan snel in actie komen, wat tot een proactieve houding leidt.

Als een organisatie zijn serviceproductieprocessen uitbesteedt, moet ook worden onderhandeld wat betreft CSI en zal dit in de SLA worden opgenomen. Anders zal de uitvoerende partij niet langer gemotiveerd zijn meer te leveren dan wat in het contract is afgesproken.

Monitoren en verzamelen van data meting (stap 3) In de servicelevenscyclus bewaakt servicestrategie het effect van de strategieën, de standaarden en de beleidsregels waarop het ontwerp berust.

Serviceontwerp bewaakt en verzamelt informatie die gerelateerd is aan het ontwerp en modificatie van services en servicemanagementprocessen. In deze fase wordt ook getest of de KSF’s en KPI’s die zijn afgesproken met de business meetbaar en effectief zijn. Ook wordt bepaald wat moet worden gemeten, en worden de planningen en mijlpalen daarvoor vastgelegd.

Servicetransitie bewaakt en meet gegevens over het werkelijke gebruik van services en servicemanagementprocessen. In deze fase worden de monitoringsprocedures ontworpen en meetcriteria voor na de implementatie vastgelegd.

Serviceproductie meet de prestaties van de services en componenten in de productieomgeving. Dit vormt opnieuw invoer voor het CSIverbeteringsproces: wat kan worden gemeten en wat zeggen die gegevens?

Buiten SLM, speelt ook availabilitymanagement een belangrijke rol in stap 3. Dit proces:

■ Creëert in overleg met de business metrics om de beschikbaarheid te meten. ■ Bepaalt welke tools nodig zijn om deze metingen te doen. ■ Bewaakt en meet de prestaties van de infrastructuur en maakt hiervoor genoeg resources vrij.

■ Levert gegevens aan CSI.

■ Werkt beschikbaarheidsplannen bij. Capaciteitsmanagement onderneemt deze acties ook en doet dat om te meten of de IT-organisatie de gevraagde services kan leveren. Dit gebeurt vanuit drie perspectieven: bedrijfscapaciteitsmanagement, servicecapaciteitsmanagement, componentcapaciteitsmanagement.

Incidentmanagement formuleert de monitoringseisen om events en incidenten te volgen, bij voorkeur geautomatiseerd, voor deze problemen veroorzaken. Ook bewaakt ze de reactie-, reparatie- en oplossingstijd en het aantal escalaties. De servicedesk, bijvoorbeeld, monitort het aantal rapporten, de gemiddelde responstijd en het percentage bellers dat voortijdig ophangt.

Securitymanagement monitort en meet de beveiliging en legt de beveiligingsincidenten en problemen vast.

En financieel management ten slotte, beheert en meet de kosten en houdt oog op het budget. Ze draagt ook bij aan rapporten wat betreft kosten en ROI van verbeteringsinitiatieven.

Data verwerken (stap 4) Serviceproductie verwerkt de gegevens in logische groepen. Binnen deze groepen verwerken availabilitymanagement en capaciteitsmanagement de gegevens op het componentniveau wat betreft beschikbaarheid en capaciteit. Samen met SLM wordt aan deze gegevens een end-to-end-perspectief toegekend en daarvoor wordt de afgesproken rapportagevorm gebruikt.

Incidentmanagement en servicedesk controleren en verwerken data over incidenten en servicerequests en de bijbehorende KPI’s. Beveiliging beheert, controleert en verwerkt data over beveiligingsincidenten en rapporteert daarover.

Data analyseren (stap 5) Servicestrategie analyseert trends, kijkt of de geïntroduceerde strategieën, beleidsregels en standaarden hun doel bereiken en kijkt of er verbetermogelijkheden zijn. Serviceontwerp analyseert de ontwerpresultaten en

projectactiviteiten en onderzoekt trends en verbetermogelijkheden. Ook kijkt het of de KSF’s en KPI’s die zijn vastgesteld in stap 2 nog adequaat zijn. Serviceproductie analyseert ook resultaten, trends en verbetermogelijkheden.

Het belangrijkste serviceproductieproces voor CSI is problemmanagement. Dit proces vindt de onderliggende oorzaken van problemen en deze vormen belangrijke verbetermogelijkheden.

Availabilitymanagement analyseert prestaties en trends op basis van component- en servicegegevens. Het vergelijkt data met eerdere maanden, kwartalen en jaren. Ook kijkt ze of het goede wordt gemeten (de correcte informatie wordt verkregen) en of er SIP’s nodig zijn. De volgende technieken worden gebruikt:

■ Component Failure Impact Analysis (CFIA) – zie afbeelding 8.10. ■ Fault Tree Analysis (FTA) – zie afbeelding 8.11. ■ Service Failure Analysis (SFA). ■ Technical Observation (TO). ■ Uitgebreide incidentlevenscyclus.

Afbeelding 8.10 Voorbeeld van een CFIA-matrix (Bron: AXELOS) Capaciteitsmanagement analyseert wanneer welke klant welke services gebruikt, hoe deze worden gebruikt en hoe dit de prestaties van een of meer systemen of componenten beïnvloedt. Dit biedt CSI opnieuw verbetermogelijkheden.

Waar problemmanagement is gericht op het oplossen van problemen die zich al hebben gemanifesteerd, probeert capaciteitsmanagement problemen proactief te voorkomen door bijvoorbeeld extra opslagcapaciteit tijdig gereed te maken. Vaak wordt dit gedaan door de situatie te reproduceren in een model en dan een aantal ‘wat als’-vragen te stellen.

Incidentmanagement en de servicedesk kunnen de verzamelde data vergelijken met eerdere resultaten en met de afgesproken servicelevels. Ze maken ook SIP’s of stellen correctieve acties voor.

Securitymanagment gebruikt alle andere processen om de oorsprong van beveiligingsincidenten en -problemen te vinden. Ze zoekt naar trends en verbetermogelijkheden in het gemonitorde gebied en bekijkt of beveiligingsstrategieën tot de beoogde resultaten leiden.

Elk verbeteringsinitiatief moet met IT-service continuity management (ITSCM) overleggen om te zorgen dat IT-services niet aan risico’s worden blootgesteld.

Risicomanagement speelt hierin een centrale rol. Ze analyseert

welke effecten tot verbeteringen kunnen leiden, terwijl CSI de resultaten van risicomanagementactiviteiten analyseert om verbetermogelijkheden te ontdekken. Zie ook hoofdstuk 5 ‘Serviceontwerp’ wat betreft het onderwerp risicomanagement.

Afbeelding 8.11 Voorbeeld van een foutenboomanalyse (Bron: AXELOS)

Presenteren en gebruiken (stap 6) Servicestrategie presenteert resultaten, trends en aanbevelingen voor de verbetering van aanvaarde strategieën, beleidsregels en standaarden. Serviceontwerp doet dit voor ontwerpverbeteringen en projectactiviteiten en servicetransitie en serviceproductie voor services en servicemanagementprocessen.

Availabilitymanagement, capaciteitsmanagement, incidentmanagement, servicedesk, problemmanagement en securitymanagement helpen bij het maken van rapporten en prioriteren van correctieve acties.

Het kennismanagementproces is belangrijk in CSI op het moment dat de informatie wordt gepresenteerd en gebruikt. Dit is de enige manier waarop CSI een goed overzicht kan krijgen van de kennis van de organisatie en de mogelijkheden voor verbetering. Het is ook belangrijk om te kunnen zorgen voor continue verbetering en te zorgen dat alle verzamelde kennis en ervaring wordt gedeeld en opgeslagen. Zie voor meer informatie over kennismanagement ook hoofdstuk 6 ‘Servicetransitie’, paragraaf 6.9.

Correctieve acties implementeren (stap 7) Availabilitymanagement, capaciteitsmanagement, incidentmanagement, servicedesk, problemmanagement en securitymanagement voeren incrementele of correctieve acties uit wanneer geen toestemming van de business is vereist.

Capaciteitsmanagement kan ook doorgaan met introduceren van metingen voor

demandmanagement om het gedrag van de eindgebruiker te

beïnvloeden:

■ Kostenberekeningen. ■ Beleid maken voor goed gebruik van de services. ■ Verwachtingen communiceren. ■ Opleiden in goed gebruik. ■ Onderhoudstijden onderhandelen. ■ Gebruiksrestricties instellen, zoals beperkt gebruik van opslagruimte. Zoals met alle andere wijzigingen in de levenscyclus, moeten ook wijzigingen afkomstig van CSI het proces van wijziging, release en uitrol doorlopen. CSI moet daarom een Request for Change (RfC) indienen bij changemanagement en een Post Implementation Review (PIR) uitvoeren na de implementatie. Ook moet het bijwerken van de CMDB door configuratiemanagement worden meegenomen. Hierna moet ITSCM het continuïteitsplan actueel houden.

8.7.5 Tot slot De introductie van CSI is niet eenvoudig. Het vereist een bewust streven naar continue verbetering als deel van de cultuur, en bijbehorend gedrag zoals een proactieve houding (van de mensen) in de organisatie. In een wereld waarin de

technologiewijzigingen elkaar snel opvolgen, is een dergelijke proactieve houding een grote uitdaging, we worden immers allemaal constant beheerst door de veranderingen. In een situatie van toenemende outsourcing en professionele ontwikkeling van IT-servicemanagement, wordt servicekwaliteit steeds meer een onderscheidende factor. Om het heft in handen te hebben en de gewenste kwaliteit te bereiken is proactief werken raadzaam. CSI is daarbij essentieel.

Bernard, P. (2012), The IT Service Part 1 - The Essentials, Van Haren Publishing Bernard, P. (2012), The IT Service Part 2 - The Handbook, Van Haren Publishing Bon, J. van (2011), ITIL® - A Pocket Guide, Van Haren Publishing Grembergen W. van (ed.), S. De Haes, E. Guldentops (2003), Structures, Processes and relational mechanisms for Information Technolog y Governance: Theories and practices, Strategies for Information Technolog y Governance, Idea Group Publishing. Kaplan, R., & D. Norton (1992), The Balanced Scorecard – measures that drive performance, in: Harvard Business Review, Vol. 70, Nr. 1, p. 71-79. Kaplan, R., & D. Norton (1993). Putting the Balanced Scorecard to work. in: Harvard Business Review, Vol. 71, Nr. 5, p. 134-142. Kotter, J.P. (1996). Leading Change. Harvard Business School Press. Mintzberg, H. (1994). The Rise and Fall of Strategic Planning: reconceiving roles for planning, plans, planners. The Free Press. Nolan, R. (1973). Managing the computer resource: a stage hypothesis, In: Communications of the ACM, Vol. 16, Issue 7, July, p. 399-405. OGC (1999), Security Management, TSO. OGC (2002), ICT Infrastructure Management, TSO. OGC (2003), Software Asset Management, TSO. OGC (2004), Business Perspective - Volume 1, TSO. OGC (2006), Business Perspective - Volume 2, TSO. OGC (2011), ITIL® Continual Service Improvement, TSO. OGC (2011), ITIL® Service Design, TSO. OGC (2011), ITIL® Service Operations, TSO. OGC (2011), ITIL® Service Strateg y, TSO. OGC (2011), ITIL® Service Transition, TSO.

OGC (2011), Planning to Implement Service Management, TSO. Rummler, G.A., & A.P. Brache (1995, 2nd edition). Improving Performance: How to Manage the White Space in the Organisation Chart, Jossey-Bass. Zeithaml, V.A., A. Parasuraman, & L. Berry (1990). Delivering Quality Service, The Free Press.

■ B.1   SERVICESTRATEGIE De begrippen in het deel Service Strateg y zijn verduidelijkt, zonder de algemene boodschap ervan te wijzigen. De nieuwe druk biedt meer praktische aanwijzingen en meer voorbeelden waar dat relevant is.

Het nieuw geschreven proces

strategiemanagement voor IT-services is

verantwoordelijk voor het ontwikkelen en onderhouden van bedrijfs- en ITstrategieën, en er zijn nu afzonderlijke beschrijvingen van bedrijfsstrategie en

Financieel management voor IT-services is uitgebreid en klantrelatiebeheer en het demandmanagement worden nu als aparte IT-strategie.

processen besproken.

Tabel B.1 Samenvatting van updates in ITIL 2011 Editie: ITIL servicestrategie

■ B.2   SERVICEONTWERP In ITIL 2011 Editie ligt bij Service Design de focus in het bijzonder op aansluiting bij ITIL-servicestrategie.

Een aantal begrippen en principes is verduidelijkt, vooral de workflow en het beheer van activiteiten in de totale serviceontwerpfase met de toevoeging van het proces

ontwerpcoördinatie . Andere belangrijke verduidelijkingen zijn de

vijf aspecten van serviceontwerp, het ontwerp van de serviceportfolio en de terminologie met betrekking tot methoden van de servicecatalogus.

Tabel B.2 Samenvatting van updates in ITIL 2011 editie: serviceontwerp

■ B.3   SERVICETRANSITIE In de ITIL 2011 Editie is het deel Service Transition op diverse punten gewijzigd. De structuur, inhoud en relaties van het configuratiemanagementsysteem (CMS) en servicekennismanagementsysteem (SKMS) zijn verduidelijkt om de lezer te helpen de belangrijkste begrippen te begrijpen.

Er is een uitleg toegevoegd hoe een wijzigingsvoorstel moet worden gebruikt. Het evaluatieproces heet nu ‘wijzigingsevaluatie’ en het doel en bereik zijn veranderd, om duidelijk te maken wanneer en hoe dit proces moet worden gebruikt.

De inhoud wat betreft het proces

serviceasset- en configuratiemanagement

is aangevuld in verband met activamanagement en er zijn verbeteringen in de stroom en integratie van een aantal processen, waaronder changemanagement,

release- en deploymentmanagement en change evaluation. Tabel B.3 Samenvatting van de wijzigingen in ITIL-servicetransitie

■ B.4   SERVICEPRODUCTIE De verschillen tussen ITIL v3 en ITIL 2011 Editie van het deel Service Operation zijn als volgt:

Processtromen zijn bijgewerkt en toegevoegd voor alle processen inclusief

request fulfillment, accessmanagement en eventmanagement. Hoofdprincipes – inclusief toelichting van servicerequests en aanvraagmodellen en proactief

problemmanagement – zijn verduidelijkt. De inhoud is

bijgewerkt om beter uit te leggen hoe eventmeldingen door het toepassen van filters en regels (rule engines) betekenisvolle eventinformatie opleveren. Ook is de relatie tussen applicatiemanagementactiviteiten en applicatieontwikkelingsactiviteiten verduidelijkt.

Andere verbeteringen zijn onder andere: een uitgebreide paragraaf over probleemanalysetechnieken; het stroomdiagram van een procedure voor

incidentafstemming en verdere toelichting voor de escalatie van incidenten naar problemmanagement. Daarnaast is de toelichting voor het beheer van fysieke facilities uitgebreid.

Tabel B.4 Samenvatting van updates in ITIL 2011 Editie: serviceproductie

■ B.5   CONTINUE SERVICEVERBETERING In ITIL 2011 editie is ten opzichte van ITIL v3 het deel Continual Service Improvement op enkele punten gewijzigd.

Het verbeterproces in zeven stappen en de relatie met de cyclus Plan-DoCheck-Act (Deming-cyclus) en kennismanagement zijn verduidelijkt. Het continue-serviceverbetermodel (CSI) heeft de nieuwe naam ‘CSI-methode’ gekregen en verder is het concept van een CSI-register geïntroduceerd als een plaats om gegevens vast te leggen van verbeterinitiatieven binnen een organisatie.

Kleine wijzigingen zijn aangebracht in de rest van dit deel om de betekenis te verduidelijken en de leesbaarheid te vergroten. Bijzondere nadruk is gelegd op het documenteren van de overgangen tussen CSI en andere levenscyclusstadia.

Tabel B.5 Samenvatting van update van ITIL 2011 Editie: continue serviceverbetering

A accessmanagement 279 – aanleidingen 283 – activiteiten 280 – doelstellingen 279 – informatiemanagement 282 – interfaces 282 – invoer 283 – kritieke succesfactoren 283 – metrics 283 – risico’s 284 – uitdagingen 284 – uitvoer 283 actief monitoren 248 applicatieframeworks 116 applicatie, ITIL-definitie 115 applicatiemanagement 116 applicatieonderhoud 116 applicatieontwikkeling 115 application analyst 48 architectuur 107 architectuurframeworks 108 architectuurontwerp 107 architectuurontwerpactiviteiten 107 assessment 322 availabilitymanagement 144 – aanleidingen 152 – activiteiten 146 – doelstellingen 145 – informatiemanagement 150

– interfaces 151 – invoer 152 – kritieke succesfactoren 153 – metrics 153 – risico’s 153 – uitdagingen 153 – uitvoer 152 availabilitymanagementinformatiesysteem (AMIS) 150 availabilitymanager 172

B bedrijfsarchitect 108 bedrijfscapaciteitsmanagement 140 bedrijfs-SWOT 326 bekende-foutendatabase 272 bekende fouten 272 – identificatie 275 benchmark 323 beschikbaarheid 146 beschikbaarheidsplan 150 betrouwbaarheid 146 bibliotheken 206 business continuity management 156 business governance 299 businessimpactanalyse (BIA) 175

C capaciteitsmanagement 136 – aanleidingen 143 – activiteiten 139 – doelstellingen 137 – informatiemanagement 141 – interfaces 142 – invoer 143 – kritieke succesfactoren 143 – metrics 144

– risico’s 144 – uitdagingen 144 – uitvoer 143 capaciteitsmanagementinformatiesysteem (CMIS) 142 capaciteitsplan 142 CASE-tools 116 Change Advisory Board (CAB) 191 changemanagement 188 – aanleidingen 198 – activiteiten 193 – doelstellingen 188 – informatiemanagement 197 – interfaces 198 – invoer 199 – kritieke succesfactoren 200 – metrics 200 – risico’s 201 – uitdagingen 200 – uitvoer 200 – zeven R’s 195 componentcapaciteitsmanagement 140 Component Failure Impact Analysis (CFIA) 147, 335 Computer Assisted/Aided Software Engineering tools (CASE) 116 configuratiebaseline 206 configuratiecontrole 209 configuratiedocumentatie 208 configuratie-identificatie 207 configuratie-item 203 configuratiemanagementdatabase 203 configuratiemanagementsysteem 205 configuratiemodel 205 configuratierecord 203 configuratiestructuur 207 Continual Service Improvement 293 continue serviceverbetering 293 controle 18, 247

corporate governance 299 CSI, Continual Service Improvement 293 – activiteiten 300, 304 – beleidsregels 300 – business case 329 – doelstellingen 294 – effectiviteit 294 – efficiëntie 294 – implementatie 296, 328 – manager 320 – methode 300 – metrics 298 – organisatie 318 – organisatieverandering 296 – procedures 300 – proceseigenaar 321 – register 295

D data 299 – classificeren 118 – eigenaar 119 data- en informatiemanagement 117, 233 Data-Informatie-Kennis-Wijsheid (DIKW) 232, 299 data-integriteit 119 definitieve mediabibliotheek 206 desktopsupport 42 directory services 42

E eisencatalogus 111 eisendocument 111 eisenonderzoek 111 emergency change advisory board (ECAB) 192 enterprise-architectuur 107 enterprise governance 299

event 252 – exceptie 254 – informatief 254 – logbestand 254 – waarschuwing 254 eventcorrelatie 254 eventdetectie 254 eventmanagement 251 – aanleidingen 256 – activiteiten 252 – informatiemanagement 255 – interfaces 256 – invoer 257 – kritieke succesfactoren 257 – metrics 257 – risico’s 258 – uitdagingen 258 – uitvoer 257 eventmelding 254 exceptie 254

F Fault Tree Analysis (FTA) 335 Foundation Level, ITIL certification 4 functionele escalatie 262

G Gap-analyse 325 governance 299

H herstelplanning 193 hiërarchische escalatie 262 hybride organisatiestructuren 289

I

identiteitsmanagement 279 implementatie-evaluatie 332 incident 259 – afsluiting 263 – classificatie 262 – diagnose 262 – escalatie 262 – prioritering 262 incidentidentificatie 260 incidentmanagement 258 – aanleidingen 264 – activiteiten 260 – doelstellingen 258 – informatiemanager 263 – interfaces 263 – invoer 264 – kritieke succesfactoren 265 – metrics 265 – risico’s 266 – uitdagingen 265 – uitvoer 264 incidentmodellen 260 incidentregistratie 260 incidentvergelijkingsprocedure 262 incrementele methode 117 informatie 299 informatiemanagement 163 information security management 159 – aanleidingen 164 – activiteiten 160 – doelstellingen 159 – interfaces 163 – invoer 164 – kritieke succesfactoren 165 – metrics 165 – risico’s 166

– uitdagingen 165 – uitvoer 164 information security manager 172 iteratieve methode 117 IT – extern zakelijk perspectief 284 – intern perspectief 284 IT-governance 299 IT-infrastructuurarchitect 108 IT Service Continuity Management (ITSCM) 154 – aanleidingen 156 – activiteiten 155 – doelstellingen 154 – informatiemanagement 156 – interfaces 156 – invoer 157 – kritieke succesfactoren 157 – metrics 158 – risico’s 158 – uitdagingen 158 – uitvoer 157

K kenmerken 208 kennis 299 kennismanagement 231 – aanleidingen 235 – activiteiten 233 – doelstellingen 232 – informatiemanagement 235 – interfaces 235 – invoer 235 – kritieke succesfactoren 236 – metrics 236 – risico’s 236 – uitdagingen 236

– uitvoer 236 kennismanagementstrategie 233 kennisoverdracht 233 Key Performance Indicator (KPI) 295 Known Error Database (KEDB) 272 Kotter, John P. 296 Kritieke Succesfactor (KSF) 299, 331

L label 208 leveranciersmanagement 166 – aanleidingen 169 – activiteiten 167 – doelstellingen 166 – informatiemanagement 168 – interfaces 169 – invoer 169 – kritieke succesfactoren 170 – metrics 170 – risico’s 171 – uitdagingen 170 – uitvoer 170 local service desk 36

M major incidenten 260 maturity 25 Mean Time Between Failures (MTBF) 149 Mean Time Between Service Incidents (MTBSI) 149 Mean Time To Restore Service (MTRS) 149 middleware 42 middleware management 42 monitoren 246 monitorings- en controlecyclus 247 MoSCoW 112, 175

N naamconventies 207 normale wijziging 192 noodwijziging 192

O onderhoudbaarheid 146 onderhoudsgemak 146 ontwerpactiviteiten 109 – beheer- en operationele eisen 109 – functionele eisen 109 – gebruikseisen 111 ontwerpaspecten 104 ontwerpcoördinatie 119 – aanleidingen 124 – activiteiten 121 – doelstellingen 119 – informatiemanagement 122 – interfaces 122 – invoer 124 – metrics 125 – risico’s 126 – uitdagingen 125 Operational Level Agreement (OLA) 132 operationele data 118 operations bridge 33 organisatiestructuur van serviceproductie 288 organisatieverandering, Kotter 296

P passief monitoren 248 PDCA-cyclus 296 portfolio 22 Post Implementation Review (PIR) 197, 332 prioriteitscode 262 proactief monitoren 248

proactief problemmanagement 276 proactieve organisatie 286 probleem 272 – diagnose 275 – evaluatie 275 – onderzoek 275 – prioritering 273 probleemclassificatie 273 probleemidentificatie 273 probleemmodel 272 probleemregistratie 273 problemmanagement 271 – aanleidingen 277 – activiteiten 272 – interfaces 276 – invoer 277 – kritieke succesfactoren 278 – metrics 278 – risico’s 279 – uitdagingen 278 – uitvoer 278 proceseigenaar 172, 237 programma van eisen 175 project 22 Projected Service Outage (PSO) 151

R Rapid Application Development 117 rapporteren 246 reactief monitoren 248 reactief problemmanagement 273 reactieve organisatie 286 rechtenmanagement 279 redundantie 149 – actief 149 – heterogeen 150

– homogeen 150 – passief 149 release 213 releasecategorieën 213 release & deployment management 212 – aanleidingen 217 – activiteiten 215 – doelstellingen 212 – informatiemanagement 216 – interfaces 217 – invoer 217 – kritieke succesfactoren 218 – metrics 218 – risico’s 219 – uitdagingen 219 – uitvoer 218 release-eenheid 213 release-ontwerp 214 releasepakket 214 Request for Change (RfC) 191 Request fulfillment 266 – aanleidingen 269 – activiteiten 267 – doelstellingen 266 – informatiemanagement 269 – interfaces 269 – invoer 269 – kritieke succesfactoren 270 – metrics 270 – risico’s 271 – uitdagingen 270 – uitvoer 270 return on investment (ROI) 303 risicocategorisatiematrix 195 Rummler & Brache, swimlanediagram 326

S SACM (serviceasset- en configuratie-management) 201 – audit 209 – verificatie 209 securitygovernance 161 securitymaatregelen 162 servicearchitect 108 serviceasset 203 serviceasset- en configuratiemanagement (SACM) 201 – activiteiten 207 – aanleidingen 211 – doelstellingen 201 – informatiemanagement 210 – interfaces 210 – invoer 211 – kritieke succesfactoren 211 – metrics 211 – risico’s 212 – uitdagingen 212 – uitvoer 211 servicecapaciteitsmanagement 140 servicecatalogus 127 servicecatalogusmanagement 126 – aanleidingen 129 – activiteiten 128 – basisbegrippen 127 – doelstellingen 126 – informatiemanagement 128 – interfaces 129 – invoer 129 – kritieke succesfactoren 130 – metrics 130 – risico’s 130 – uitdagingen 130 – uitvoer 130 servicecatalogusmanager 303

service desk 34 service-eigenaar 237, 321 Service Failure Analysis (SFA) 147, 335 service gap-model 325 servicegerichte architectuur 107 servicekennismanagementsysteem 205 service level agreement (SLA) 132 servicelevelmanagement 131, 332 – aanleidingen 135 – activiteiten 132 – doelstellingen 131 – informatiemanagement 134 – interfaces 134 – invoer 135 – kritieke succesfactoren 135 – metrics 136 – risico’s 136 – uitdagingen 136 – uitvoer 135 servicelevelmanager 172 servicelevelovereenkomst (SLA) 132 servicemanagementtools 174 servicemanagementtraining 291 servicemeting 302 serviceontwerp – basisbegrippen 115 – bereik 104 – implementatieafweging 175 – KPI’s 177 serviceontwerpfase 101 – doelstellingen 102 serviceontwerpmanager 172 serviceontwerppakket 121 serviceontwerpproces – rollen & verantwoordelijkheden 171 serviceontwerp – tools 173 serviceontwikkelingslevenscyclus 116 Service Oriented Architecture (SOA) 107

serviceportfolio 106, 127 serviceproductie 245 – doelstellingen 246 – implementatie 284 – organisatiestructuur 288 – verbeteren 288 serviceproductiefase 245 servicerapportage 303 service request 259, 267 servicetransitie 179 – doelstellingen 179 – verantwoordelijkheden 237 – voorbereiden 184 servicetransitieplan 184 servicetransitierollen 237 service validation & testing 220 – aanleidingen 225 – activiteiten 223 – beleidsregels 221 – doelstellingen 220 – informatiemanagement 225 – interfaces 225 – invoer 225 – kritieke succesfactoren 226 – metrics 226 – risico’s 227 – uitdagingen 227 – uitvoer 226 serviceverbeterplan 303 Single Point of Failure (SPOF) 147 snapshot 207 stakeholderanalyse 241 stakeholdermanagement 240 stakeholdermatrix 240 standaard wijzigingen 193, 267 Statement of Requirements (SoR) 175 strategische data 119

super users 39 swimlanediagram 326 SWOT-analyse 326

T tactische data 119 testmanagement 224 testmodel 221 teststrategie 221 toezicht en controledoelstellingen 248 TOGAF 108 transitiemanager 237 transitieplanning en -ondersteuning 181 – aanleidingen 186 – activiteiten 183 – informatiemanagement 186 – interfaces 186 – invoer 186 – kritieke succesfactoren 187 – metrics 187 – risico’s 187 – uitdagingen 187 – uitvoer 187 transitiestrategie 184

U uitgebreide incidentlevenscyclus 335 underpinning contract (UC) 132

V value on investment (VOI) 303, 330 veilige mediabibliotheek 206 verbeteringsstrategie 307 verbeterproces in 7 stappen 303 virtual service desk 37

W

waarschuwing 254 wijsheid 299 wijziging 191 – categorisering 195 – impact 196 – planning 196 – prioriteit 196 – risicocategorie 195 – urgentie 196 wijzigingsevaluatie 197, 228 – aanleiding 229 – activiteiten, 229 – informatiemanagement 229 – interfaces 229 – invoer 229 – kritieke succesfactoren 230 – metrics 231 – risico’s 231 – uitdagingen 231 – uitvoer 230 wijzigingsmodellen 192 wijzigingsschema 196 wijzigingsverzoek 191 wijzigingsvoorstel 191 workaround 272

Z Zachman, architectuurframework 108 zeven R’s bij changemanagement 195