isoiec 20000_nodrm

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

ISO/IEC 20000 – Een Introductie


Andere uitgaven bij Van Haren Publishing

Van Haren Publishing (VHP) is gespecialiseerd in uitgaven over Best Practices, methodes en standaarden op het gebied van de volgende domeinen: - IT-management, - Architecture (Enterprise en IT), - Business management en - Projectmanagement.

Deze uitgaven worden uitgegeven in verschillende talen in series, zoals ITSM Library, Best Practice, IT Management Topics en I-Tracks.

VHP is tevens de uitgever voor toonaangevende instellingen en bedrijven, onder andere The Open Group, PMI-NL, IPMA-NL, CA, Getronics Consulting, Pink Elephant.

Onderwerpen per domein zijn:

IT (Service) Management / IT GovernanceASLBiSLCATSCMMICOBITeSCMISO 17799ISO 27001ISO/IEC 20000ISPLIT Service CMMITIL® V2ITIL® V3ITSMMOFMSF

Architecture (Enterprise en IT)Archimate®

TOGAFTM

GEA®

Business ManagementEFQMISA-95ISO 9000SixSigmaSOXSqEME®

Project-, Programma- en RiskmanagementA4-ProjectmanagementICB / NCBMINCE®

M_o_R®

MSPTM

PMBOK®

PRINCE2TM

Voor een compleet overzicht van alle uitgaven, ga naar onze website: www.vanharen.net.


ISO/IEC 20000Een introductie


IV

Colofon

Titel: ISO/IEC 20000 – Een introductie

Redactie: Jan van Bon (hoofdredacteur) Selma Polter (co-auteur en redacteur) Tieneke Verheijen (co-auteur en redacteur)

Co-auteur: Leo van Selm

Uitgever: Van Haren Publishing, Zaltbommel, www.vanharen.net

ISBN: 978 90 8753 585 8

Druk: Eerste druk, eerste oplage, April 2010

Design & Layout: CO2 Premedia, Amersfoort - NL

Toestemming voor hergebruik van onderdelen van BS ISO/IEC 20000-1:2005 & BS ISO/IEC 20000-2:2005 is toe-gekend door BSI. BSI standaarden kunnen in pdf-formaat worden besteld via de online webwinkel van BSI: http://www.bsi-global.com/en/Shop / of telefonisch via BSI Customer Services: Tel: +44 (0)20 8996 9001, E-mail: [email protected]

ISO (de International Organization for Standardization) en IEC (de International Electrotechnical Commission) vor-men het gespecialiseerde system voor wereldwijde standaardisatie. Nationale instituten die lid zijn van ISO of IEC participeren in de ontwikkeling van internationale standaarden door middel van technische commissies van die betref-fende organisatie die zich met een specifi ek technisch werkveld bezighouden. De technische commissies van ISO en IEC werken samen op gebieden van gemeenschappelijk belang. Andere internationale organisaties, overheid of niet-overheid, nemen ook deel aan het werk, gekoppeld aan ISO en IEC. Voor het werkveld informatietechnologie hebben ISO en IEC een gemeenschappelijke technische commissie ingesteld, de ISO JTC 1.Internationale standaarden worden ontwikkeld in overeenstemming met de regels die in de ISO Directives, Part 2 wor-den gegeven.De hoofdtaak van de gemeenschappelijke technische commissie is om de internationale standaarden voor te bereiden. Een conceptversie van een internationale standaard wordt na acceptatie door de gemeenschappelijke technische commis-sie naar nationale instuten gestuurd voor een stemming. Publicatie als een internationale standaard vereist instemming van ten minste 75% van de nationale instituten die meedoen aan de stemming.

ISO/IEC 20000 is de offi ciële naam van de standaard. In het werkveld wordt naar de standaard verwezen als ‘ISO 20000’. Om praktische redenen is in dit boek de kortere naam van de standaard gebruikt.

Voor meer informatie over Van Haren Publishing, e-mail naar [email protected]

©Van Haren Publishing, 2008, 2010Alle rechten voorbehouden. Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt door middel van druk, fotokopie, microfi lm of op welke andere wijze ook, zonder voorafgaande schriftelijke toestemming van de uitgever.

Alhoewel deze uitgave met de grootst mogelijke zorg is opgesteld, kan noch de redactie, noch de uitgever enige aanspra-kelijkheid aanvaarden voor schade voortvloeiend uit fouten of onvolkomenheden in de tekst.

Toelichting Trademarks:PRINCE2™, M_o_R® and ITIL® are Registered Trade Marks and Registered Community Trade Marks of the Offi ce of Government Commerce, and are registered in the U.S. Patent and Trademark Offi ce.COBIT® is a registered trademark of the Information Systems Audit and Control Association (ISACA)/IT Governance Institute (ITGI).


V

Voorwoord

Het voorwoord is geschreven door John Stewart, directeur van Procurementbeleid en Standaarden van het Government’s Offi ce of Government Commerce (OGC) van het Verenigd Koninkrijk. John Stewart bedacht samen met wijlen Peter Skinner het ITIL-concept. John leidde de vroege ontwikkeling van ITIL en was de verantwoordelijke persoon voor ITIL bij OGC.

“Het ethos achter de ontwikkeling van ITIL is de erkenning dat organisaties steeds afhankelijker worden van IT om corporate doelen te realiseren en te voldoen aan de bedrijfsbehoeften. Deze groeiende afhankelijkheid leidt tot een groeiende behoefte aan IT-services van een hoge kwaliteit. Kwaliteit houdt in dat IT-services aansluiten op de businessbehoeften en gebruikerseisen terwijl deze zich ontwikkelen. Dit boek is onderdeel van een serie van codes of practice die bedoeld zijn om het kwaliteitsmanagement van IT-services te faciliteren”. Zo luidde een gedeelte van het voor-woord van de ITIL versie 2 publicaties, waarvan de eerste 19 jaar geleden werden uitgebracht door de overheid van het Verenigd Koninkrijk.

Er circuleren verschillende verhalen over hoe ITIL begon, en waarom. Sommige van deze verha-len zijn uitermate vreemd, fantastisch en fi ctioneel. De waarheid is dat wij het als projectontwik-kelaars hebben voorgesteld, omdat we ons zorgen maakten over het feit dat de overheid van het Verenigd Koninkrijk te afhankelijk werd van IT. De manier waarop IT werd gemanaged werd overgelaten aan individuele organisaties, zonder gemeenschappelijke aanpak en zonder vastom-lijnd idee van hoe het zou moeten gaan. Toen het bestuur toestemde om het begin van de ont-wikkeling te fi nancieren zijn we gaan rondkijken naar goede praktijkvoorbeelden en hebben we samen met stakeholders gewerkt aan de realisatie van een consistente aanpak.

Omdat ITIL eigendom was van de overheid van het Verenigd Koninkrijk kon het ‘boven de markt’ worden geplaatst. Hierdoor kreeg ITIL de potentie om een de-factostandaard voor IT-servicemanagement te worden. Door een open, concurrerend aanbod van ITIL-ondersteunende services en producten te stimuleren, hebben we het concept ontsloten voor organisaties buiten de publieke sector van het Verenigd Koninkrijk, zodat zij er van kunnen profi teren. ITIL zelf profi teert ook van bijdragen en feedback van een groot aantal belangrijke stakeholders.

ITIL levert de lingua franca voor een meer uniforme benadering van IT-servicemanagement. ITIL is een gebruiksklare maar ook aanpasbare aanpak, die ervoor zorgt dat gebruikers niet opnieuw een aanpak hoeven uit te vinden. Het is onderdeel van het concept servicekwaliteits-management.

In hoeverre kwaliteitsmanagement onderdeel uitmaakte van onze eerste gedachtegang wordt dui-delijk in twee aspecten. Ten eerste publiceerden we kort na de eerste ITIL-boeken een kwaliteits-managementbibliotheek. Ten tweede behaalden we - waarschijnlijk als eersten in het Verenigd Koninkrijk - een ISO 9001-certifi caat voor ons werk met ITIL en de daarmee samenhangende ontwikkelingen.

Dankzij de inzet van verschillende organisaties en personen is ITIL een internationaal succes geworden. Ik wil graag de vele organisaties bedanken die hun business hebben gebaseerd op het


VI

bedienen van de ITIL-markt. Daarnaast wil ik ook graag de vele gebruikersorganisaties bedanken die ITIL hebben omarmd als de basis voor hun IT-servicemanagement. Zonder deze organisaties zou ITIL niet zo’n succes zijn geweest. Er zijn natuurlijk nog veel mogelijkheden voor ITIL in veel delen van de wereld, en als u in zo’n gebied woont, zet het goede werk dan voort!

We hebben altijd gedacht dat een wereldwijde verbreiding van het ITIL-concept voordeel zou behalen met een aanvullende internationale standaard. Ik prijs de mensen achter ISO 20000 voor hun vooruitziende blik bij het opstellen van de standaard en voor hun motivatie en inzet om het te laten groeien. Ik zie ISO 20000 en ITIL samen op weg gaan naar verbetering van IT en de effectiviteit van IT-support voor business en overheid.

Ik hoop dat de lezers meegaan op deze weg en hier hun voordeel mee zullen doen.


VII

Dankwoord

ISO/IEC 20000, de internationale standaard voor IT-servicemanagement, krijgt veel aandacht in het vakgebied. Veel organisaties en individuen houden zich bezig met de voordelen die de standaard kan bieden, en delen hun ervaringen. Het doel van dit boek is om een introductie op de standaard te bieden voor iedereen die betrokken is bij een certifi ceringsproject, of die zich voorbereidt op één van de examens die recentelijk op de markt zijn verschenen. Deze examens worden waarschijnlijk de belangrijkste examens in het vakgebied IT-servicemanagement.

Ten eerste willen we Selma Polter bedanken. Ze was de oorspronkelijke redacteur en was ver-antwoordelijk voor het opstellen van de inhoudsopgave en een eerste versie van het manuscript.

Vanaf dit punt nam Tineke Verheijen het van haar over als managing redacteur. Zij vulde het boek aan met een introducerend hoofdstuk en met aanvullende best practice-richtlijnen voor de verschillende processen die de standaard introduceert. Ook heeft ze veel tijd besteed aan de grafi sche weergaven, die veel duidelijkheid scheppen in de materie.

Hoofdredacteur Jan van Bon was verantwoordelijk voor het gehele project en zorgde ervoor dat het boek zou voldoen aan de behoeften van de markt. Hij werkte ook aan de grafi sche weergaven en het bijschaven van de inhoud.

Onze dank gaat ook uit naar Leo van Selm, die zich aanbood als co-auteur en zorgde ervoor dat de inhoud van dit boek overeenkomt met de examenvereisten van ISO/IEC 20000. Hij schreef ook het aanvullende hoofdstuk over examenvoorbereiding en de onderdelen over certifi cering voor individuen en organisaties.

Het uiteindelijke manuscript werd gereviewed door 30 reviewers, die met veel enthousiasme aan het project hebben meegewerkt. In het bijzonder willen we Renate Eberle bedanken. Als voor-zitter van de EXIN/TÜV-commissie die één van de eerste ISO/IEC 20000-examens op markt bracht, ondersteunde zij de review met de inzet van de volgende commissieleden: Michael Brenner – Leibniz Supercomputing Centre - Duitsland Marcus Giese – TÜV SÜD Management Service GmbH – Duitsland

Als lid van het EXIN-ontwikkelteam dat het ontwerp voor het certifi ceringsprogramma ontwik-kelde, bracht Leo van Selm ons in contact met zijn collega-teamleden, die we ook bedanken voor hun inzet:Michael Busch – it SolutionCrew GmbH – DuitslandDavid Clifford – PRO ATTIVO – Verenigd KoninkrijkBryan Shoe – Process Catalyst Solutions – USA

We bedanken ook de volgende reviewers, die via verschillende kanalen ons team hebben ver-sterkt:Gérald Audenis – ORSYP Consulting – FrankrijkRob van den Burg – Microsoft – NederlandRosario Fondacato – Quint Wellington Redwood – Italië


VIII

Peter van Gijn – Logica – NederlandRalph Graph – Lucid IT Pty Ltd – Nieuw ZeelandJohn Groom – West Groom Consulting – Verenigd KoninkrijkMatiss Horodishtiano – Amdocs – IsraelWim Hoving – BHVB – NederlandAlfons Huber – TÜV SÜD Informatik und Consulting Services GmbH – DuitslandLuis F. Martínez Sánchez – Gestió I Govern de les TIC (G2TIC) – SpanjeAlex Tito de Morais – Fujitsu do Brasil – BraziliëAlan Nance – BMC – USATatiana Orlova – EC-leasing – RuslandJoel A. Pereira – The Centre for IT Service Management Pte. Ltd. (CISM™) – SingaporeSelma Polter – Independent - Nederland Silvia Prickel United Airlines – USADouglas Read – PRO-ATTIVO – Verenigd KoninkrijkClaudio Restaino – BITIL.COM – ItaliëMart Rovers – InterProm USA Corporation – USARui Soares – GFI Portugal – PortugalJaap van Staalduine - ING Service Centre Budapest – NederlandRay Tricker – Herne European Consultancy Ltd – Verenigd KoninkrijkTony Verlaan – Getronics PinkRoccade – NederlandFlip van de Waerdt – HP – NederlandPaul Wigzel – Parity Training – Verenigd KoninkrijkStuart Wright – PRO-ATTIVO – Verenigd Koninkrijk

Bij elkaar leverden deze reviewers ongeveer 700 issues, die stuk voor stuk werden meegenomen door de redacteuren en de co-auteur. Hierdoor werd het manuscript op één lijn gebracht met wat het boek volgens de experts zou moeten bevatten. Alle reviewers gaven aan dat hun commentaar goed was verwerkt en gaven allen een sign-off.

We hopen dat dit boek u op een prettige manier door ISO 20000 heen loodst en dat het een goede voorbereiding is op individuele examens en organisatorische certifi cering. Aanvullende praktische richtlijnen voor de certifi cering kunt u vinden in het boek: “Implementing ISO/IEC 20000 Certifi cation, The Roadmap”. Alle mogelijkheden tot verbetering van het boek zijn welkom bij het redactieteam en zullen worden meegenomen bij volgende edities. Mail uw op-merkingen naar [email protected].

Jan van BonManaging Editor


IX

Inhoud

Voorwoord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VDankwoord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII

1 Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Hoe u dit boek kunt gebruiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21.2 Gebruikte terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

2 De principes van service kwaliteitsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 Inzicht in kwaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52.2 Inzicht in service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152.3 Inzicht in IT-servicemanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212.4 Inzicht in processen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232.5 Inzicht in continue verbetering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

3 Inzicht in de positie van ISO 20000 in IT-servicemanagement . . . . . . . . . . . . . . . . . 333.1 Inzicht in het landschap van normen en frameworks. . . . . . . . . . . . . . . . . . . . . . .333.2 Inzicht in de concepten van certifi ceringspractices . . . . . . . . . . . . . . . . . . . . . . . .353.3 Inzicht in het ISO 20000-concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

4 De specifi caties en code of practice van ISO 20000 . . . . . . . . . . . . . . . . . . . . . . . . . . 634.1 Managen en verbeteren van ITSM-processen . . . . . . . . . . . . . . . . . . . . . . . . . . . .644.2 Beheersing van IT-services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .904.3 Alignment van IT en de business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1264.4 Levering van IT-services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1594.5 Support van IT-services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192

5 Het ISO/IEC-Foundation examen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2115.1 Voorwaarden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2125.2 Examenvorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2125.3 Klachten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2135.4 Examenvoorbereiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2135.5 Voorbeeldvragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214

Acroniemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223Bronnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229


X


In IT-servicemanagement (ITSM) is kwaliteit een van de belangrijkste voorwaarden voor het leveren van services die door het bedrijf worden opgemerkt en gewaardeerd. Met het publice-ren van de ISO 20000-norm voor IT-servicemanagement zijn de principes van ISO-kwaliteits-management gecombineerd met de industriestandaard voor ITSM-processen. Deze combinatie levert een erg praktische en bruikbare internationale standaard op voor kwaliteitsvol IT-service-management. Met andere woorden: een standaard voor het leveren van gemanagede IT-services die voor de klant van de IT-serviceprovider van acceptabele kwaliteit zijn.

Servicekwaliteitsmanagement speelt een steeds belangrijker wordende rol in het wereldwijde do-mein van IT-servicemanagement. In de afgelopen jaren zijn er veel standaarden ontstaan. Deze vereisen een bepaalde focus op kwaliteit en de serviceverlening, en zijn alle gebaseerd op klanten bedrijfseisen. De ISO 20000-norm specifi ceert een aantal minimumeisen waaraan alle services behoren te voldoen. Het levert een onafhankelijke baseline van waaruit verdere verbeteringen kunnen worden gerealiseerd.

Met de introductie van ITIL V3 wordt de standaard nog belangrijker. De standaard levert een middel om het uitgebreide aanbod van best practicerichtlijnen te interpreteren, zowel in de nieu-we versie van ITIL als in andere frameworks, bijvoorbeeld COBIT.

ISO 20000 is onafhankelijk van alle frameworks, het is ‘framework-neutraal’ . Er is geen sturing gedefi nieerd of geïmpliceerd tussen de standaard en de frameworks (zoals MOF, ITIL, en het ITSM Reference Model van HP) of ondersteunende kwalifi catieprogramma’s hiervan. Echter, er zijn veel frameworks, zowel publiek als privaat (in-house best practices) die ervoor kunnen zorgen dat vermogens worden herkend. Gebruik van zulke frameworks kan zeker leiden tot ISO 20000-certifi cering.

Interne en externe serviceproviders worden op de proef gesteld om te bewijzen dat hun service-managementprocessen de kwaliteit leveren die de klanten eisen. Externe serviceproviders zijn in verband met offertetrajecten al geneigd om zich voor de standaard te certifi ceren.

Hoofdstuk 1Introductie


2 ISO/IEC 20000 – Een Introductie

Hoewel iedereen een organisatie volgens de ISO 20000-normen kan laten certifi ceren, geeft het certifi ceringsprogramma van EXIN en TÜV SÜD geloofwaardigheid aan de certifi cering. Dit programma kent de ISO 20000-certifi cering toe nadat geregistreerde certifi ceringsinstituten (Registered Certifi cation Bodies - RCB’s ) audits hebben uitgevoerd op ISO 20000-1 - ‘De speci-fi catie’. Deze specifi catie zorgt ervoor dat een serviceprovider een IT-servicemanagementsysteem ontwikkelt, implementeert en managet dat in lijn is met de eisen van de standaard.

Wereldwijde ervaring met ISO 20000 en haar voorgangers (BS 15000, AS 8018 en SANA 15000) tonen aan dat certifi ceringsprogramma’s voor IT-serviceproviders een vraag naar training en certifering creëert, zoals bijvoorbeeld voor auditors, proceseigenaren of procesmanagers en consultants.

Interesse voor het onderwerp ontstaat ook onder IT-servicemanagementprofessionals, en dit geldt voor zowel de klant als voor de serviceprovider. In de nabije toekomst zal kennis (in ieder geval van de essentie van ISO 20000) een eis zijn voor vele IT-servicemanagementposities.

1.1 Hoe u dit boek kunt gebruikenDeze publicatie kan worden gebruikt als ondersteunende literatuur voor ISO 20000 Foundation-examens. Onderwerpen als kwaliteit en de kwaliteitsnorm ISO 20000 worden geïntroduceerd en de positie van ISO 20000 in IT-servicemanagement wordt uitgelegd. Daarnaast worden teksten van de standaard geïntroduceerd, met behulp van fi guren en best practice-adviezen.

Dit boek kan ook worden gebruikt bij de voorbereiding van de ISO 20000-certifi cering van een bedrijf. De ISO 20000-eisen worden uitgelegd en er wordt tevens uitleg gegeven over hoe best practices gebruikt kunnen worden bij het voldoen aan deze eisen.

Lezers die niet direct betrokken zijn bij een certifi cering kunnen deze publicatie gebruiken als een richtlijn om de kwaliteit van de services die zij leveren te verbeteren.

In hoofdstuk 2 worden de principes van servicekwaliteitsmanagement geïntroduceerd. Total Quality Management en de concepten kwaliteit, services en IT-servicemanagement, processen en continue verbetering worden besproken.

In hoofdstuk 3 wordt de ISO 20000-norm in het vakgebied IT-servicemanagement gepositio-neerd. In dit hoofdstuk wordt ook het concept certifi ceringspractices besproken.

Daarna worden alle onderdelen van de ISO 20000-norm geïntroduceerd, met zowel de eisen als de practices. Tekst met de eisen uit de ISO 20000-1 specifi catie (de ‘shalls’) is in gekleurde kaders weergegeven en de bijbehorende best practice uit ISO 20000-2 (de ‘shoulds’) staat daaronder in cursieve tekst. In zoverre mogelijk is in de fi guren aangegeven welke eisen ISO 20000-1 stelt en welke code of practice -richtlijnen ISO 20000-2 geeft.

Hoofdstuk 5 gaat over het ISO 20000 Foundation-examen: de eisen die gesteld worden en de voorbereiding op het examen. Momenteel ontwikkelen itSMF UK, ISEB en EXIN/TÜV SÜD examens die erop zijn gericht om mensen kundig te maken op het gebied van ISO 20000, inclu-


Introductie 3

sief consulting en auditing rondom de standaard. Ten tijde van de ontwikkeling van dit boek was er alleen informatie beschikbaar over het EXIN/TÜV SÜD certifi ceringsprogramma . Daarom is de meeste informatie in dit boek gebaseerd op dit materiaal, inclusief een set van proefvragen. Het boek behandelt echter alle informatie die een nieuwe ISO 20000-student zou moeten weten en kan daarom gebruikt worden bij de voorbereiding op het ISO 20000 Foundation-examen.

1.2 Gebruikte terminologieDe Nederlandse vakorganisatie itSMF, uitgever Van Haren Publishing, exameninstituut EXIN en redactiebureau Inform-IT hebben gezamenlijk een uniforme terminologie ontwikkeld voor Nederlandstalige producties in het vakgebied IT-beheer. Deze terminologie is toegepast bij de productie van ITIL-gerelateerde publicaties en examens, en is geadopteerd door APMG, de exa-menaccreditatieorganisatie voor ITIL. De vertaallijst wordt door APMG gratis op het internet beschikbaar gemaakt. Bij de vertaling van de ISO20000-norm naar het Nederlands door NEN is geen gebruik gemaakt van deze lijst.


Bedrijven wordt steeds afhankelijker van op technologie gebaseerde services. Het succes van een bedrijf hangt, net als het succes van IT, meer dan ooit af van hoe goed de levering is versus de toenemende verwachtingen van een steeds veeleisender klant. Corporate governance-schandalen en de druk van nieuwe regelgeving, zoals de Sarbanes-Oxley Act, hebben ertoe geleid dat be-drijven van de IT-sector eisen dat ze een klantgerichte , kwaliteitgeoriënteerde en consistente benadering van de levering van IT-services biedt. Om kwaliteit te kunnen managen, moet er eerst een defi nitie worden afgesproken over wat kwaliteit precies is. Dit zal besproken worden in de volgende sectie.

2.1 Inzicht in kwaliteit Er zijn veel persoonlijke defi nities van ‘kwaliteit’ maar ISO 9000 (waarop ISO 20000 is geba-seerd) stelt:

We kunnen van kwaliteit spreken wanneer alle aspecten van een product (of service) die een klant wenst ook daadwerkelijk aan de klant worden geleverd.

Kwaliteitsmanagement houdt dus in dat de organisatie ervoor zorgt dat de producten of services voldoen aan de kwaliteitseisen van de klant en tevens voldoen aan eventuele regel-geving die van toepassing is op de desbetreffende producten of services.

Voor de IT-serviceafdeling houdt kwaliteitsmanagement inzicht in kwaliteit en waarde vanuit bedrijfsperspectief in, en borging dat de service wordt ontwikkeld en gemanaged om aan deze specifi caties te voldoen.

Hoofdstuk 2De principes van service-kwaliteitsmanagement



2.1.1 Total Quality Management (TQM)

Total Quality Management (TQM) moedigt iedereen in de organisatie voortdurend aan om te voldoen aan de eisen van de interne en externe klant, om de concurrentiepositie te verbeteren. Het is een generieke term die gebruikt wordt om een groot aantal denkwijzen, concepten, methoden en tools te beschrijven.

Er zijn verschillende methoden voor het managen van IT-servicekwaliteit. Ze zijn alle gebaseerd op methoden uit het eerste gedeelte van de twintigste eeuw. Sinds die tijd, met de technologische revolutie als belangrijkste drijfveer, hebben organisaties geprobeerd om de kwaliteit van de pro-ducten die ze maakten te beheersen. In de jaren 80 van de vorige eeuw werd dit bekend als Total Quality Management (TQM).

De Plan-Do-Check-Act cyclusWilliam Edwards Deming introduceerde de Plan-Do-Check-Act cyclus (de PDCA-cyclus , zie fi guur 2.1)1 als toevoeging op een bestaand diagram:• Plan - Wat moet er gedaan worden, wanneer moet het gedaan worden, wie moet het doen,

hoe moet het gedaan worden, en wat moet er gebruikt worden?• Do - De geplande activiteiten worden geïmplementeerd.• Check - Vaststellen of de activiteiten hebben geleid tot het beoogde resultaat.• Act - De plannen aanpassen om afwijkingen naar aanleiding van de checkfase te herstellen.

1 Deming werd geÏnspireerd door Walter Shewhart, een van zijn leraren die zich bezighield met een ‘learning and improve-ment cycle’.

Figuur 2.1 De PDCA-cyclus. Terwijl de cyclus de heuvel oprolt worden achtereenvolgens de fasen P, D, C, A doorlopen

TIJD

KWALITEIT

Kwaliteits-verbetering

Draairichting

Kwaliteitsmanagement1 Plannen (PLAN)2 Uitvoeren (DO)3 Meten (CHECK)4 Aanpassen (ACT) Kwaliteits-

borging

ISO/IEC 20000

P D

A C


De principes van servicekwaliteitsmanagement 7

ISO 9000 en ISO 20000 hebben beide deze cyclus opgenomen in aanpak voor continue verbete-ring. Joseph Juran introduceerde dit ‘concept voor continue verbetering’ . Deze grondlegger van TQM maakte ook klantgerichtheid tot een fundamenteel concept van Total Quality Manage-ment. Een continue dialoog met de klant is essentieel om ervoor te zorgen dat de klant en de leverancier beiden weten wat er van een service wordt verwacht.

Het derde concept dat Juran introduceerde was de waarde die elke partij voor een organisatie heeft. Werknemers hebben invloed op verandering en zij kunnen de belangrijkste asset voor kwa-liteitsverbetering zijn. Elke werknemer moet een duidelijk en consistent beleid worden geboden over wat hun rol is in het realiseren van de doelstellingen van de organisatie. Op deze manier worden zij in staat gesteld hun functie uit te voeren en verantwoordelijk te zijn voor de uitvoering van hun taken. Dit zal leiden tot een toename van de tevredenheid onder de werknemers en tot een hogere productiviteit en innovatie. ISO 20000-opleiding en - examinering kan duidelijkheid geven over de rol van werknemers binnen een organisatie.

2.1.2 De groeiende rol van kwaliteit in IT-servicemanagementIn de jaren tachtig van de vorige eeuw groeide in veel bedrijfstakken het belang van informatie-technologie snel en dit leidde tot een behoefte aan software en op IT-gerichte modellen, metho-den en tools. Voor een groeiend aantal producten werd de doorlooptijd van productontwikkeling vastgesteld op basis van de doorlooptijd van de softwareontwikkeling (bijvoorbeeld producten in de elektronicasector en de telecommunicatiesector). Daarom moest de effi ciëntie en de effectivi-teit van in het bijzonder de ontwikkelingprocessen van software worden verbeterd.

In dezelfde periode groeide de belangstelling voor IT-servicemanagement. Dit leidde tot de ont-wikkeling van de IT Infrastructure Library , oftewel ITIL. Hiermee werd de kwaliteit van IT-services een aandachtspunt.

IT-servicekwaliteitsmanagement behoort ervoor te zorgen dat informatie betrouwbaar en vei-lig is. Het verbeteren van processen in een organisatie is niet mogelijk als er een gebrek is aan complete en accurate informatie als basis voor de besluitvorming. Managementinformatie is het eerste terrein waarop de kwaliteit geborgd moet zijn, omdat dit alle andere producten en proces-sen ondersteunt en informeert.

TQM is een samensmelting van verschillende kwaliteitsmanagementsystemen en daarom is er geen offi ciële TQM-certifi cering. Naast kwaliteitsprijzen, zoals de Malcolm Balridge National Quality Award en de European Foundation for Quality Management prijzen, geeft een ISO 9001:2000 -certifi cering aan dat een organisatie werkt volgens TQM-principes. Van bedrijven met een ISO 20000-certifi cering kan worden verwacht dat ze ge-audit zijn volgens internationale best practises in ITSM.

2.1.3 Principes van kwaliteitsmanagement (componenten)Om een organisatie succesvol te leiden is het nodig om het op een systematische en transparante manier te besturen en beheersen. Succes kan worden behaald met een managementsysteem dat continu performance verbetert en in de behoefte van alle betrokken partijen voorziet. Het ma-nagen van een organisatie omvat kwaliteitsmanagement naast de andere managementdisciplines.



De ISO 20000-norm voor IT-servicemanagement heeft de kenmerken van ISO 9000 , de inter-nationale norm voor kwaliteitsmanagement. Het bevat alle acht kwaliteitsmanagementprincipes van ISO 9000 (zie fi guur 2.2):• klantgerichtheid• leiderschap• betrokkenheid van mensen• procesaanpak• continue verbetering• feitengebaseerde benadering van besluitvorming• wederzijds voordelige leveranciersrelaties• systematische aanpak van management

Deze principes kunnen worden beschouwd als de componenten van kwaliteit. Het topmanage-ment kan deze componenten gebruiken om de performance van hun organisatie te verbeteren. In de volgende secties worden deze componenten besproken.

KlantgerichtheidOrganisaties zijn afhankelijk van hun klanten. Daarom moeten ze inzicht hebben in de actuele en toekomstige behoeften van de klant, voldoen aan eisen van de klant en de verwachtingen van de klant meer dan waarmaken.

De belangrijkste voordelen van klantgerichtheid zijn:• een toenemende winst en marktaandeel, bereikt door fl exibele en snelle reacties op kansen in

de markt

Figuur 2.2 De acht principes van kwaliteitsmanagement van ISO 9000

Leveranciersrelaties

systematische aanpak van management

Continue verbetering

Betrokkenheid van mensen

Procesaanpak

LeiderschapFeitengebaseerde

benadering

DE ACHT PRINCIPES VAN

KWALITEITSMANAGEMENT

Klantgerichtheid



• toenemende effectiviteit in het gebruik van de resources van de organisatie, om klanttevreden-heid te bevorderen

• terugkomende klanten, als gevolg van een toegenomen loyaliteit van de klant

Het toepassen van het principe van klantgerichtheid leidt over het algemeen tot:• ontwikkelen van een bedrijfsstrategie, gebaseerd op het vaststellen van de toekomstige behoef-

ten van de klant• onderzoeken en begrijpen van behoeften en verwachtingen van de klant• een link leggen tussen de doelstellingen van de organisatie en behoeften en verwachtingen van

de klant • behoeften en verwachtingen van de klant kenbaar maken aan de hele organisatie• meten van klanttevredenheid en daarop reageren• systematisch managen van klantrelaties • zorgen voor een gebalanceerde aanpak voor het tevreden stellen van klanten en andere betrok-

ken partijen (zoals eigenaren, werknemers, leveranciers, fi nancierders, locale gemeenschappen en de samenleving in het algemeen)

Er kan een verschil zijn tussen de klant en de gebruiker van een service. De persoon die voor een service betaalt is altijd de klant, maar dit is niet altijd de persoon die de service gebruikt, bij defi nitie de gebruiker. Uiteindelijk zijn de eisen van de klant het belangrijkst. De klant zal echter ervaringen van gebruikers meenemen bij de beoordeling van de geleverde services.

LeiderschapLeiders stellen een eenduidig doel en richting van de organisatie vast. Zij behoren een interne omgeving te creëren en te onderhouden waarin mensen volledig betrokken kunnen worden bij het realiseren van de doelstellingen van de organisatie.

De belangrijkste voordelen van leiderschap zijn:• Mensen zullen de doelen en doelstellingen van de organisatie begrijpen en gemotiveerd zijn

om deze te realiseren.• Activiteiten worden op een uniforme wijze geëvalueerd, op elkaar afgestemd en geïmplemen-

teerd.• Miscommunicatie tussen lagen van de organisatie wordt beperkt.

Het toepassen van de principe van leiderschap leidt over het algemeen tot:• rekening houden met de behoeften van alle betrokken partijen, inclusief eigenaren, werkne-

mers, leveranciers, fi nancierders, lokale gemeenschappen en de samenleving in het algemeen• vaststellen van een duidelijk beeld van de toekomst van de organisatie• stellen van uitdagende doelen en targets• creëren en naleven van gedeelde waarden, eerlijkheid en ethische rolmodellen voor alle lagen

van de organisatie• wekken van vertrouwen en wegnemen van angsten• zorgdragen voor de vereiste resources, training en vrijheid om verantwoordelijk en controleer-

baar te handelen • inspireren, aanmoedigen en erkennen van bijdragen van mensen



Betrokkenheid van mensenMensen uit alle lagen vormen de essentie van een organisatie. Hun volledige betrokkenheid zorgt ervoor dat hun capaciteiten kunnen worden gebruikt ten voordele van de organisatie.

De belangrijkste voordelen van betrokkenheid van mensen zijn:• gemotiveerde, toegewijde en betrokken mensen in de organisatie• innovatie en creativiteit in het realiseren van de doelstellingen van de organisatie• mensen zijn verantwoordelijk voor hun eigen performance• mensen zijn gedreven om te participeren en bij te dragen aan continue verbetering

Het toepassen van het principe van betrokkenheid van mensen leidt over het algemeen tot:• Mensen begrijpen het belang van hun bijdrage en hun rol binnen de organisatie.• Mensen erkennen hun eigen beperkingen.• Mensen accepteren hun fouten en de verantwoordelijkheid voor de oplossing ervan• Mensen evalueren hun eigen performance ten opzichte van persoonlijke doelen en doelstel-

lingen.• Mensen zoeken actief naar mogelijkheden om hun competenties, kennis en ervaring te verbe-

teren.• Mensen delen kennis en ervaring met elkaar.• Mensen durven te discussiëren over problemen en issues.• Een vermindering van confl icten binnen de organisatie. • Een verbeterde perceptie van de organisatie door de klant.

ProcesaanpakAls activiteiten en hieraan gerelateerde resources worden gemanaged als een proces kan het ge-wenste resultaat effi ciënter worden gerealiseerd. Zie ook paragraaf 2.4.

Een proces is een gestructureerde serie van activiteiten die erop gericht is een bepaalde doelstel-ling te realiseren (zie sectie 2.4 voor meer details). Een proces heeft input en output . Organisa-ties die effectief willen functioneren moeten talloze samenhangende en gerelateerde processen identifi ceren. De output van een proces vormt vaak direct de input van een volgend proces. Het systematisch vaststellen en managen van de processen in een organisatie, in het bijzonder de interactie tussen deze processen, noemt met de procesaanpak.

De belangrijkste voordelen van de procesaanpak zijn:• lagere kosten en kortere cyclustijden door effectief gebruik van resources• verbeterde, consistente en voorspelbare resultaten• doelgerichte en geprioriteerde verbeterkansen

Figuur 2.3 illustreert het procesgebaseerde kwaliteitsmanagementsysteem zoals beschreven in ISO 9000. Hoewel de processen niet in detail beschreven worden, geeft de fi guur wel weer dat betrokken partijen een belangrijke rol spelen als het gaat om het leveren van input voor de or-ganisatie. Om de tevredenheid van de betrokken partijen te monitoren , is informatie over hun perceptie nodig. Dit vereist tevens informatie over de mate waarin is voldaan aan hun behoeften en verwachtingen.



Het toepassen van de procesaanpak leidt over het algemeen tot:• richten op verwachte resultaten van de geïntegreerde activiteiten van het proces• systematisch defi niëren van de activiteiten die nodig zijn om een gewenst resultaat te behalen• vaststellen van duidelijke verantwoordelijkheden en bevoegdheden voor het managen van de

belangrijkste activiteiten• analyseren en meten van de capabelheid van de belangrijkste activiteiten • lokaliseren van raakvlakken van de belangrijkste activiteiten in en tussen de functies van de

organisatie• richten op factoren als resources, methoden, en materialen die de belangrijkste activiteiten van

de organisatie verbeteren• evalueren van risico’s, gevolgen en impact van activiteiten op klanten, leveranciers en andere

betrokken partijen

Continue verbeteringHet continu verbeteren van een kwaliteitsmanagementsysteem is nodig om de performance van de organisatie en de klanttevredenheid te vergroten. Dit behoort een permanente doelstelling van de organisatie te zijn.

De belangrijkste voordelen van continue verbetering zijn:• verbeterde performance door middel van verbeterde organisatorische capabelheden (capabili-

ties)• verbeterde kwaliteit van de geleverde service

Figuur 2.3 Model van een procesgebaseerd kwaliteitsmanagementsysteem (Tricker, 2006).

Service Delivery Processes

Control Processes

ReleaseProcess

Configuration ManagementChange Management

Release Management

Capacity Management

Service Continuity andAvailability

Management

ResolutionProcesses

Incident Management

Problem Management

Service Level Management

Service Reporting

RelationshipProcesses

Business RelationshipManagement

Supplier Management

Information SecurityManagement

Budgeting andAccounting

for IT services

MetingAnalyse

Verbetering

Management-verantwoordelijkheid

Productrealisatie

Resourcemanagement

INPUT OUTPUTPROCES

Klanteis Klanttevredenheid

Continueverbetering

Check

Act

Plan

Do



• op elkaar afstemmen van verbeteractiviteiten op alle niveaus, volgens de bedrijfsstrategie• fl exibiliteit om snel te handelen bij kansen

Het toepassen van het principe van continue verbetering leidt over het algemeen tot:• gebruiken van een consistente, organisatiebrede aanpak voor continue verbetering van de

performance van de organisatie• mensen training bieden in de methoden en tools voor continue verbetering• continue verbeteren van producten, processen en systemen tot doelstelling voor iedereen in de

organisatie maken• analyseren en evalueren van de bestaande situatie om verbeterpunten te lokaliseren• bepalen van doelstellingen voor verbeteringen• zoeken naar mogelijke oplossingen en maken van een selectie • de geselecteerde oplossing implementeren• bepalen van manieren om de status van continue verbetering te volgen• meten, verifi ëren, analyserenen evalueren van resultaten van de implementatie om vast te stel-

len of de doelen zijn behaald• formaliseren van changes• herkennen en accepteren van verbeteringen • verminderen van confl icten met klanten en genereren van meer business door proactief de

relatie te verbeteren, evenals de geleverde producten

Indien nodig, worden resultaten gereviewd om verdere mogelijkheden voor verbeteringen te be-palen. Op deze manier is verbeteren een continue activiteit. Ook feedback van klanten en andere betrokken partijen, audits en een review van het kwaliteitsmanagementsysteem kunnen worden gebruikt om mogelijke verbeterpunten te identifi ceren.

Feitengebaseerde aanpak van besluitvorming Effectieve besluiten worden gebaseerd op de analyse van data en informatie.

De belangrijkste voordelen van een feitengebaseerde aanpak van besluitvorming zijn:• besluiten worden gebaseerd op accurate en complete informatie• toegenomen capabelheid om de effectiviteit van eerder genomen besluiten te tonen door te

verwijzen naar feitelijke records• toegenomen capabelheid om meningen en besluiten te reviewen, aan de kaak te stellen en te

wijzigen

Het toepassen van het principe van een feitengebaseerde aanpak van besluitvorming leidt over het algemeen tot:• borgen dat data en informatie voldoende accuraat en betrouwbaar zijn• data beschikbaar maken voor wie die nodig heeft• analyseren van data en informatie met behulp van geldige methoden

Deze aanpak leidt over het algemeen tot besluiten en acties die gebaseerd zijn op feitenanalyse, gecombineerd met ervaring en kennis.



Wederzijds voordelige leveranciersrelatiesEen organisatie en zijn leveranciers zijn afhankelijk van elkaar en een wederzijds voordelige relatie vergroot voor beide partijen de mogelijkheden om waarde te creëren.

De belangrijkste voordelen van wederzijds voordelige leveranciersrelaties zijn:• toegenomen vermogen voor beide partijen om waarde te creëren• fl exibiliteit en snelheid van gezamenlijke reacties op een veranderende markt of veranderende

behoeften en verwachtingen van de klant• optimalisatie van kosten en resources

Het toepassen van het principe van wederzijds voordelige leveranciersrelaties leidt over het alge-meen tot:• relaties die kortetermijnbaten en langetermijnoverwegingen met elkaar in evenwicht brengen• delen van kennis en resources met partners• vaststellen en selecteren van de belangrijkste leveranciers • duidelijke en open communicatie• delen van informatie en toekomstplannen• gezamenlijke ontwikkelingen en verbeteractiviteiten• inspireren, aanmoedigen en herkennen van verbeteringen en verrichtingen van leveranciers

Systematische aanpak van management De systematische aanpak heeft als doel de relaties tussen processen te identifi ceren, begrijpen en managen en deze als een systeem te managen. Dit verhoogt de effectiviteit en effi ciency van een organisatie bij het realiseren van de doelstellingen.

De belangrijkste voordelen van de systematische aanpak van management zijn:• integratie en het op elkaar laten afstemmen van de processen die het tot de gewenste resultaten

leiden• vermogen om inspanning te richten op de belangrijkste processen• vertrouwen leveren aan de betrokken partijen met betrekking tot de consistentie, effectiviteit

en effi ciëntie van de organisatie

Het toepassen van het principe van de systematische aanpak van management leidt over het algemeen tot:• structureren van een systeem om de doelstellingen van een organisatie op de meest effectieve

en effi ciënte manier te realiseren• inzicht in de onderlinge afhankelijkheden tussen de processen van het systeem• gestructureerde benaderingen die processen met elkaar in overeenstemming brengen en doen

laten integreren• een beter begrip creëren van de rollen en verantwoordelijkheden die nodig zijn voor de reali-

satie van algemene doelstellingen, waardoor barrières tussen functies worden verminderd• inzicht verwerven in de capabelheden van de organisatie en beperkingen stellen aan resources

voordat er tot acties wordt overgegaan • vaststellen en defi niëren hoe specifi eke activiteiten binnen een systeem behoren te functione-

ren• continu verbeteren van het systeem met behulp van metingen en evaluaties



Voor meer informatie zie paragraaf 2.1.4.

2.1.4 KwaliteitsmanagementsystemenEen kwaliteitsmanagementsysteem is de manier waarop een organisatie functioneert. Het defi ni-eert de manier waarop een organisatie de kwaliteit van zijn producten of services managet. ISO 9000:2005 beschrijft de grondbeginselen van kwaliteitsmanagementsystemen en defi nieert de gerelateerde termen.

Zoals eerder al is vermeld, behoort het voldoen aan klanteisen het ultieme doel van elke organisa-tie te zijn die kwaliteit hoog in het vaandel heeft. De systematische aanpak van kwaliteitsmanage-ment moedigt organisaties aan om klanteisen te analyseren, processen te defi niëren die bijdragen aan de realisatie van een product dat acceptabel is voor de klant en deze processen te beheersen. Het levert een framework voor continue verbetering, wat leidt tot een toename van de klantte-vredenheid en tevredenheid van andere betrokken partijen. Zo krijgen zowel de organisatie en de klanten van de organisatie het vertrouwen dat de geleverde producten op consistente wijze aan de eisen voldoen.

Een aanpak om een kwaliteitsmanagementsysteem te ontwikkelen en implementeren bestaat uit verschillende stappen:• Stel de behoeften en de verwachtingen van klanten en andere betrokken partijen vast.• Bepaal het kwaliteitsbeleid en kwaliteitsdoelstellingen van de organisatie.• Stel de processen vast en de benodigde verantwoordelijkheden om de kwaliteitsdoelstellingen

te verwezenlijken.• Stel de de resources vast die nodig zijn om de kwaliteitsdoelstellingen te verwezenlijken en

lever deze.• Stel de methoden vast om de effectiviteit en effi ciëntie van elk proces te meten.• Meet de effectiviteit en effi ciëntie van elk proces.• Stel manieren vast om afwijkingen te voorkomen en de oorzaken ervan te elimineren.• Richt een proces in en pas het toe, voor de continue verbetering van het kwaliteitsmanage-

mentsysteem.

Deze aanpak kan ook worden toegepast op het onderhouden en verbeteren van een bestaand kwaliteitsmanagementsysteem.

Kwaliteitsbeleid en kwaliteitsdoelstellingen geven richting aan de focus voor de organisatie. Beide stellen de gewenste resultaten vast en helpen de organisatie met het aanwenden van resources om deze resultaten te bereiken. Het kwaliteitsbeleid vormt een framework voor het vaststellen en reviewen van kwaliteitsdoelstellingen. De kwaliteitsdoelstellingen moeten consistent zijn met het kwaliteitsbeleid en de verplichting tot continue verbetering en de resultaten moeten meetbaar zijn. De resultaten van kwaliteitsdoelstellingen kunnen een positieve impact hebben op product-kwaliteit, operationele effectiviteit en fi nanciële performance, en daarmee op de tevredenheid en het vertouwen van de betrokken partijen.



2.2 Inzicht in service

2.2.1 Wat is een IT-service?IT werd lange tijd beschouwd als een leverancier van producten: hardware, software, pc’s enzo-voort. De toenemende afhankelijkheid van bedrijven ten opzichte van IT heeft echter duidelijk gemaakt dat dit niet langer het geval is. Hoewel de IT producten gebruikt voor het leveren van IT-services, wordt het nu beschouwd als een typisch servicedomein. Dus wat is het verschil tussen een product en een service? Dit kan worden uitgelegd aan de hand van de volgende kenmerken:• Services zijn in grote mate ontastbaar – Een service is niet fysiek, het kan niet worden aan-

geraakt of gewogen. Het bestaat voor een deel uit tastbare componenten zoals de hardware die wordt gebruikt om de service te leveren, het netwerk en de disk waar de software op staat. Maar services zijn veel meer dan alleen een combinatie van deze tastbare producten.

• Services worden gelijktijdig geproduceerd en geconsumeerd – De service wordt geconsu-meerd terwijl deze geproduceerd wordt. Services kunnen niet opgeslagen worden en daarom is proactieve verzekering van kwaliteit in servicemanagement belangrijker dan elke controle die achteraf wordt gedaan op de geleverde kwaliteit.

• Services zijn erg verschillend – Services worden niet alleen geleverd door machines, maar ook door mensen. Het belangrijkste verschil tussen machines en mensen is dat mensen niet continu een service kunnen leveren op een hetzelfde constante niveau als een machine dat kan. Een vermoeide servicedeskmedewerker levert een service die van mindere kwaliteit is ten opzichte van zijn normale performance. Producten zijn over het algemeen machinegerelateerd en hun variatie is beter te beheersen.

• De gebruiker neemt deel aan de productie van de service – Een service kan vaak niet wor-den geconsumeerd zonder enkele specifi eke acties vanuit de gebruiker. Op deze manier heeft de gebruiker (en daarmee de klant) invloed op de kwaliteit van de service. Een product wordt meestal geproduceerd door een eenzijdige actie van een externe provider.

• Tevredenheid is subjectief – De consumptie van services wordt beïnvloed door de klant, in dit geval de IT-gebruiker. En services kunnen alleen gemeten en beoordeeld worden nadat ze geleverd zijn, niet daarvoor. Producten kunnen worden beoordeeld, getest en geëvalueerd voordat ze worden gekocht.

Veel van de verschillen tussen services en producten worden bepaald door het percentage tastbare goederen in de service (zie fi guur 2.4). Vanwege de subjectiviteit zijn de ontastbare kenmerken van een service over het algemeen minder goed te meten dan materiële goederen. Hoe minder goederen een service bevat, hoe moeilijker het is om de service op een objectieve manier te meten.

Voornamelijkgoederen

Service-intensievegoederen Gemengd Goederen-intensieve

servicesVoornamelijkservices

Tastbaar onderdeel van het product Ontastbaar onderdeel van het product

Figuur 2.4 Services en producten



2.2.2 Componenten van een IT-serviceDe entiteit ‘service’ is een kernentiteit van IT-servicemanagement. Volgens ITIL V3:

Een service is een middel om waarde aan de klant te leveren door het faciliteren van eindresultaten die de klant wil bereiken zonder eigenaarschap van specifi eke kosten en risico’s.

Maar wat is een IT-service nu precies? De IT-service is een output van de IT-organisatie (intern of extern) en geen resultaat van de business, waar met behulp van de service de werkelijke waarde moet worden gecreëerd. Vanuit het oogpunt van deze output van de interne of externe IT-or-ganisatie kan een IT-service beschreven worden als een verzameling van aan elkaar gerelateerde elementen die samen een service vormen en potentiële waarde bieden voor de klant.

Vanuit technisch oogpunt is een IT-service een ondersteunend informatiesysteem dat aan de klant wordt geleverd volgens de afgesproken kwaliteit. Deze samenstelling omvat drie elementen:• een informatiesysteem• ondersteuning• kwaliteitsspecifi caties

De volgende paragrafen gaan dieper in op elk van deze elementen.

InformatiesysteemHet informatiesysteem is een samenhangend dataprocessingsysteem voor het beheersen of onder-steunen van één of meerdere bedrijfsprocessen. Het kan worden onderverdeeld in de volgende categorieën: mensen, processen en technologie (People, Process, Technology) en kan, samen met partners, worden gebruikt om het gebied waar de focus uiteindelijke op ligt: informatie (zie fi guur 2.5).

Mensen =personeel

Informatie

Informatiesysteem

Kwaliteitseisen

IT-service

BeschikbaarheidPerformanceCapaciteitSecurityVertrouwelijkheidSchaalbaarheidInstelbaarheidPortabiliteit.......

Mensen

Hardware

Systeemsoftware

Netwerken

Toepassings-software

Databases

Faciliteiten

Applicaties

Technischeinfrastructuur Technologie

Informatie-technologie

DocumentatieProces

Figuur 2.5 Terminologieboom die de uitsplitsing en de aggregatieniveaus van de componenten van een IT-service illustreert (Bron: Compendium ITSM)



De mensen die onderdeel uitmaken van de IT-service zijn de medewerkers die als taak hebben ervoor te zorgen dat het informatiesysteem naar behoren functioneert. Zij voeren gedurende de hele servicelevenscyclus alle activiteiten uit die zijn gericht op het verlenen en onderhouden van service die voldoet aan de gestelde specifi caties. Zonder mensen zou een informatiesysteem slechts een kort bestaan zijn beschoren.

De processen worden gedocumenteerd in de procesbeschrijvingen . Deze documenten bevatten ook de benodigde procedures, werkinstructies en handleidingen. Zonder goed gedocumenteerde instructies zou een organisatie alleen de informatie tot zijn beschikking hebben die mensen per-soonlijk bij zich dragen. Dit kan grote gevolgen hebben als iemand iets vergeet of zijn baan ver-laat, of als men het niet eens is over een bepaalde kwestie. Standaardisatie zou bijna onmogelijk zijn als er geen betrouwbare gedocumenteerde informatie voorhanden is.

Het domein van de technologie is bekend bij IT-experts. De infrastructuur van informatietech-nologie kan worden opgedeeld in verschillende elementen. Een bekende onderverdeling is: ap-plicaties werken op systemen in omgevingen. In meer technische termen zou dit zijn: [applicaties] werken op [technische infrastructuur] gebruikmakend van [faciliteiten]. Afhankelijk van toegepaste technologie kunnen deze domeinen van hoog niveau verder onder-verdeeld worden. De technische infrastructuur kan bijvoorbeeld onderverdeeld worden in hard-ware, systeemsoftware en netwerken. Een andere onderverdeling kan infrastructuurelementen opleveren zoals middleware, fi rmware, enzovoort. Zolang alle componenten maar goed gema-naged worden, kan de onderverdeling afhankelijk zijn van de zienswijze van de manager en de toegepaste technologie aankijkt. De onderverdeling van applicaties kan op dezelfde manier variëren: in een tweeledige architec-tuur kan dit worden opgedeeld in applicatiesoftware en databases. In een drieledige structuur kan dit worden opgedeeld in een presentatielaag, een proceslaag en een datalaag.

De faciliteiten kunnen bijvoorbeeld opgedeeld worden in energie, temperatuur en ruimte.

SupportDe tweede belangrijke term in IT-servicemanagement is support. Het informatiesysteem moet worden ondersteund om ervoor te zorgen dat het functioneert zoals is afgesproken. Dit betekent dat als er veranderingen gedaan moeten worden als die vereist zijn en dat het systeem moet wor-den hersteld als er iets niet functioneert zoals dat zou moeten. Onderhoud is een onderdeel van support.De mensen van het informatiesysteemteam moeten deze ondersteunde acties uitvoeren volgens de richtlijnen van de processen. Deze acties bestaan onder meer uit het herstellen van een IT-service als deze verstoord is, het aanpassen van een IT-service als de klant andere kenmerken wil en het minder of meer leveren van een service. Als dit goed verloopt, dan ondersteunt het infor-matiesysteem de bedrijfsprocessen zoals bedoeld is.

KwaliteitHet informatiesysteem moet worden geleverd zoals met de klant is afgesproken. Dit betekent dat de kwaliteitseigenschappen van het informatiesysteem moeten worden gespecifi ceerd en be-sproken. De kwaliteit van een IT-service blijkt vaak in de praktijk uit specifi eke kenmerken van een service die de klant tevredenstellen. Deze kenmerken kunnen slaan op gedragsaspecten zoals



responsietijd, of meer fysieke kenmerken zoals ‘laptop’. Klant en provider zijn betrekkelijk vrij in het kiezen van de specifi caties van servicekwaliteit, maar een aantal eigenschappen zijn meer algemeen geaccepteerd dan andere: • Beschikbaarheid van het informatiesysteem is de eerste van de meest essentiële en wijdver-

spreide eigenschappen van servicekwaliteit. Het betekent dat het informatiesysteem beschik-baar moet zijn voor de klant op de afgesproken tijd en plaats.

• Capaciteit is de tweede belangrijke eigenschap van kwaliteit. Het geeft het vermogen van een eigenschap aan, zoals bijvoorbeeld de opslagcapaciteit van een disk, de verwerkingscapaciteit van een CPU, de herstelcapaciteit van een servicedesk, enzovoort.

• Performance is de derde kwaliteitseigenschap. Het slaat op de snelheid waarmee informatie wordt verwerkt vanuit het oogpunt van de klant. In ISO 20000 is performance onderdeel van capaciteitsmanagement. De performance van het informatiesysteem is niet te vergelijken met de performance van IT, applicaties, systemen, facilities, personeel en processen. De perfor-mance van een component is niet relevant voor de klant of de gebruiker: de gebruiker ervaart de totale output van de performance van alle componenten van het informatiesysteem.

• Security wordt door veel organisaties als cruciaal beschouwd en is over het algemeen onderdeel van afspraken over IT-services.

• Vertrouwelijkheid is, afhankelijk van het type organisatie, vaak een belangrijk onderdeel van security.

• Schaalbaarheid kan belangrijk zijn voor een snelgroeiende organisatie. Een provider moet er daarom voor kunnen zorgen dat die groei mogelijk is, op de gewenste snelheid en zonder de business te verstoren.

• Instelbaarheid kan belangrijk zijn voor een innovatieve organisatie. Een provider moet zijn ontwikkelmethoden, de architectuur en andere elementen die het informatiesysteem onder-steunen zo kiezen dat het informatiesysteem in- en bijgesteld an worden.

• Overdraagbaarheid kan belangrijk zijn voor een klant die van provider wil wisselen, bijvoor-beeld aan het einde van een contract of tussentijds.

Eigenschappen van service kunnen afhankelijk van elkaar zijn. De duur van het afsluiten van een incident kan bijvoorbeeld direct invloed hebben op de beschikbaarheid van het informatie-systeem.

2.2.3 Relatie tussen IT-services en kwaliteitOrganisaties zijn vaak afhankelijk van hun IT-services en verwachten niet alleen dat IT-services de organisatie ondersteunen, maar ook dat ze nieuwe mogelijkheden bieden om veranderende behoeften te ondersteunen. IT-serviceproviders kunnen niet langer alleen aandacht besteden aan technologie en hun eigen, interne organisatie. Ze moeten tegenwoordig ook aandacht besteden aan de kwaliteit van de services die ze leveren en aan de relatie met de klanten.

Zoals beschreven in de vorige sectie, kan de kwaliteit van een product beoordeeld worden voordat het wordt aangeschaft. Een service wordt echter geleverd via de interactie tussen een provider en zijn klanten en gebruikers. Dit heeft als gevolg dat de kwaliteit van services niet vooraf kunnen worden beoordeeld, maar pas als ze worden geleverd.

De kwaliteit van een service is afhankelijk van de interactie tussen de serviceprovider, de klanten en de gebruikers. In tegenstelling tot het industriële productieproces, kunnen de provider en de



klant nog aanpassingen doen terwijl de services worden geleverd. Hoe de klant en de gebruikers de service ervaren en wat de provider denkt dat hij levert hangt voor een groot deel af van per-soonlijke ervaringen en verwachtingen. Dit betekent dat het proces van servicelevering een com-binatie is van productie en gebruik, waaraan de provider en de klant tegelijkertijd deelnemen.

De perceptie van de klant en de gebruikers is essentieel voor het leveren van services. Klanten en gebruikers stellen over het algemeen de volgende vragen om de kwaliteit te beoordelen:• Voldoet de service aan de overeengekomen verwachtingen?• Kan ik de volgende keer een soortgelijke service verwachten?• Wordt de service geleverd tegen een redelijke prijs?

KwaliteitsperceptieDe perceptie van kwaliteit is grotendeels gebaseerd op verwachtingen die kunnen zijn gebaseerd op de dialoog tussen de provider en de klant, of op een andere bron. Deze verwachtingen kunnen meer invloed hebben op de waargenomen kwaliteit dan de feitelijke technische kwaliteit van de geleverde services. De perceptie van een service is van cruciaal belang voor de relatie tussen de klant en de provider. Echter, de kwaliteitsperceptie kan grote kloven bevatten (zie fi guur 2.6).

• Kloof 1: De kloof tussen wat klanten verwachten en wat de provider begrijpt van deze ver-wachtingen. Deze kloof kan veroorzaakt worden door een gebrek aan begrip of een verkeerde uitleg van de behoeften van de klant. Communicatie is van groot belang voor het overbruggen van deze kloof.

• Kloof 2: De kloof tussen wat de provider begrijpt van de klantverwachtingen en de klantge-stuurde servicedesigns en standaarden van de provider. Deze kloof kan worden veroorzaakt door het onvermogen om de klanteisen te vertalen naar servicespecifi caties.

• Kloof 3: De kloof tussen servicedesign en standaarden en de service die daadwerkelijk gele-verd wordt. Deze kloof kan worden veroorzaakt door het onvermogen van de provider om te leveren wat is afgesproken.

• Kloof 4: De kloof tussen de services die daadwerkelijk zijn geleverd en wat de klant is gezegd dat hij zou ontvangen. Deze kloof kan worden veroorzaakt door miscommunicatie of zelfs misleiding.

• Kloof 5: De kloof tussen de service die klanten bij de levering ervaren en de services die ze aanvankelijk verwachtten. Deze kloof kan meerdere oorzaken hebben: een klant kan meer krijgen dan verwacht, maar in de meeste gevallen komt deze kloof aan het licht als de service onder de maat is en de klant niet tevreden is.

Continue dialoog met de klant, inclusief medewerkers, is van essentieel belang voor de verbete-ring van de services en voor de borging dat de klant en de leverancier beiden weten wat er van de service wordt verwacht. Om dit te bereiken is het belangrijk om dezelfde taal te spreken. Het kost soms wat moeite om alle neuzen in dezelfde richting te krijgen, maar het delen van referen-tiemodellen en best practices (CobiT, ITIL) terminologie werkt erg goed.

Om een voorbeeld te geven: in een restaurant legt een ober eerst het menu uit en hij vraagt bij het serveren van een nieuwe gang of alles naar wens is. Gedurende de hele maaltijd is de ober bezig met het actief coördineren van supply en demand. De opgedane ervaringen worden vervolgens gebruikt om de klanttevredenheid in de toekomst te verbeteren.



Onder de kwaliteit van een service verstaan we de mate waarin de service voldoet aan de eisen en de verwachtingen van de klant (inclusief de gebruikers). Om kwaliteit te leveren, moet de leverancier voortdurend inventariseren hoe de service wordt ervaren en wat de klant in de toe-komst zou kunnen verwachten. Wat de ene klant gewoon vindt, wordt door een andere klant als bijzonder beschouwd. Daarnaast kan een klant gewend raken aan een bepaalde service die aanvankelijk wel als bijzonder werd beschouwd. Het resultaat van de continue service-assessment kan worden gebruikt om te bepalen of een service moet worden aangepast, de klant beter moet worden voorgelicht of de prijs moet worden bijgesteld.

Redelijke kosten kunnen worden beschouwd als een afgeleide van de verwachtingen. Als over-eengekomen is wat er van de service verwacht kan worden, is de volgende stap het afspreken van een prijs. De kosten kunnen worden gezien als een kwaliteitseigenschap waar rekening mee moet worden gehouden in samenhang met andere kwaliteitseigenschappen, om een balans te vinden waar de klant zich in kan vinden. Op dit punt moet een serviceprovider zich bewust zijn van de kosten en van de in de markt gangbare prijzen voor vergelijkbare services.

Een klant zal niet tevreden zijn met een serviceprovider die de verwachtingen af en toe overstijgt, maar het op andere keren af laat weten. Het leveren van een constante kwaliteit is een van de belangrijkste, maar dikwijls ook een van de moeilijkste aspecten van de servicesector.

Kortom, bij het leveren van een service is de algehele kwaliteit het resultaat van de kwaliteit van een aantal deelprocessen die samen een service vormen. Deze deelprocessen vormen een keten en de onderdelen daarvan hebben invloed op elkaar en de kwaliteit van de service. Een effectieve co-ordinatie van de deelprocessen vereist niet alleen een bevredigende kwaliteit tijdens het uitvoeren van elk van de processen, maar ook een consistente kwaliteit.

Mondelinge communicatie Persoonlijkebehoeften

Ervaring uit hetverleden

Verwachte service

Kloof 5

Kloof 1

Kloof 3

Kloof 2

Kloof 4

Waargenomenservice

Feitelijke service

Vertaling van verwachtingennaar kwaliteitsstandaarden

De perceptie van de provider

Externe communicatiemet de klant

Klant

Provider

Figuur 2.6 Perceptie van kwaliteit (Bron: het SERVQUAL-model van Parasuraman, Zeithaml en Berry)



2.3 Inzicht in IT-servicemanagement

2.3.1 Het concept IT-managementOrganisaties hebben steeds vaker behoefte aan IT-services die overeenkomen met de doelstel-lingen van hun bedrijfsvoering. Daarom wordt er steeds meer aandacht besteed aan het mana-gen van IT-services in plaats van aan het ontwikkelen van IT-applicaties. Een informatiesysteem (soms ook wel een IT-applicatie genoemd) draagt alleen bij aan het realiseren van bedrijfsdoel-stellingen als het systeem beschikbaar is voor gebruikers en als het in geval van fouten of beno-digde aanpassingen ondersteund wordt door onderhoud en operationeel management.

In de algehele levenscyclus van IT-producten wordt het meeste geld uitgegeven aan de pro-ductiefase. Het productiebudget bestaat vooral uit personeelskosten en doorlopende kosten van het onderhouden van informatiesystemen en beslaat het grootste van de totale deel van de IT-uitgaven, ongeveer 70% in een gemiddelde onderneming[Gartner2]. De overige 30% wordt uitgegeven aan productontwikkeling (of productaanbesteding). Kortom, effectieve en effi ciënte IT-servicemanagementsystemen , -processen en –strategieën zijn van essentieel belang voor het succes van IT. Dit is van toepassing op elke organisatie, groot of klein, publiek of privaat, met gecentraliseerde of gedecentraliseerde IT-services met interne of uitbestede IT-services. In alle ge-vallen moet de service betrouwbaar, consistent, van een hoge kwaliteit en acceptabel geprijsd zijn.

IT-servicemanagement is het management van alle processen die samenwerken om de kwaliteit van live IT-services te borgen, conform de servicelevels die met de klant overeen zijn gekomen.

IT-servicemanagement omvat de initiëring, ontwerp, organisatie, beheersing, levering, onder-steuning en verbetering van IT-services die toegepast zijn op de behoeften van de klant. Er zijn verschillende bronnen die praktische richtlijnen bieden voor IT-servicemanagement waaronder ISO 20000 en volwassenheidsmodellen zoals CMMI. Er zijn ook veel andere bruikbare stan-daarden, best practices en frameworks beschikbaar, zoals ITIL, en governanceframeworks zoals COBIT.

2.3.2 Voordelen en risico’s van IT-servicemanagementHet belangrijkste voordeel van IT-servicemanagement is dat het kwantitatieve kwaliteitscriteria levert voor klantgerichte end-to-endservices. Dit is de enige basis voor volwassen management van de IT-infrastructuur. Deze infrastructuur bestaat uit IT-en niet-IT-gereleateerde componen-ten, gegroepeerd in services die zich in verschillende fasen van de servicelevenscyclus bevinden (in productie, in ontwikkeling of afgesloten).

De onderstaande lijsten sommen een aantal voordelen en mogelijke problemen op die kunnen ontstaan bij het gebruik van IT-servicemanagement best practices. De lijsten zijn niet uitputtend, maar noemen enkele voordelen die kunnen worden behaald en enkele fouten die kunnen worden gemaakt bij gebruik van bekende procesgebaseerde IT-servicemanagementframeworks.

2 IT Spending: How Do You Stack Up? Gartner Research report, 2003.



Voordelen voor de klant of de gebruiker:• De levering van IT-services wordt meer klantgericht en afspraken over de kwaliteit van de

services verbeteren de relatie met de serviceprovider.• De services zijn beter en gedetailleerder beschreven op een manier die begrijpelijk is voor de

klant.• De beschikbaarheid, betrouwbaarheid, kosten en andere aspecten van de services worden be-

ter gemanaged. • De communicatie met de IT-organisatie is verbeterd door afspraken te maken over aanspreek-

punten.

Voordelen voor de IT-organisatie:• De IT-organisatie wordt overzichtelijker, effi ciënter en is meer gericht op de bedrijfsdoelstel-

lingen. • De IT-organisatie heeft meer controle over de infrastructuur en de services die onder de ver-

antwoordelijkheid van de organisatie vallen. Het managen van changes wordt eenvoudiger.• Een effectieve processtructuur levert een framework op voor de effectieve uitbesteding van

onderdelen van de IT-services. • Het volgen van best practices moedigt aan tot een cultuurverandering in de servicelevering en

ondersteunt de invoering van kwaliteitsmanagementsystemen gebaseerd op ISO 9000 of ISO 20000.

• Frameworks kunnen zorgen voor samenhangende referentiekaders voor interne communica-tie en communicatie met leveranciers, en voor de standaardisatie en identifi catie van procedu-res.

Mogelijke knelpunten:• Het invoeringstraject kan lang duren. Als er incorrect ontworpen en gepland is, kan er een

substantiële inspanning zijn vereist, net als een cultuurverandering. Een té ambitieuze invoe-ring kan leiden tot frustraties omdat de doelen nooit behaald kunnen worden.

• Als de processtructuur een doel op zichzelf wordt, komt de kwaliteit van de servicelevering in gevaar. Onnodige en overontwikkelde procedures worden in dat geval gezien als bureaucrati-sche obstakels die moeten worden vermeden.

• Verbeteringen blijven uit door gebrek aan inzicht in wat processen moeten opleveren, wat de performance-indicatoren zijn en hoe processen kunnen worden bijgestuurd.

• Verbetering in de levering van services en kostenreducties kunnen niet voldoende zichtbaar zijn als er geen baselinedata beschikbaar zijn om mee te vergelijken, of als de verkeerde targets zijn geïdentifi ceerd.

• Een succesvolle implementatie vereist de betrokkenheid en de toewijding van personeel in alle lagen van de organisatie. Als de ontwikkeling van de processtructuren overgelaten wordt aan een specialistische afdeling, kan deze afdeling geïsoleerd raken van de rest van de organisatie en een richting op gaan die de andere afdelingen niet erkennen.

• Als er niet voldoende is geïnvesteerd in geschikte training en ondersteunende tools kan een proces niet optimaal functioneren, waardoor de service niet wordt verbeterd. Extra resources en mankracht kunnen op korte termijn nodig zijn als de organisatie al is overbelast met IT-servicemanagementactiviteiten die niet gebruikmaken van best practices.



2.3.3 Tools voor IT-servicemanagementIn de performance van IT-servicemanagementtaken kunnen tal van geautomatiseerde hulpmid-delen worden gebruikt. Deze hulpmiddelen worden tools genoemd. Met behulp van deze tools kunnen managementtaken worden geautomatiseerd, bijvoorbeeld monitoringstaken of software-distributietaken.

Andere tools ondersteunen de performance van de activiteiten zelf, zoals servicedesktools of ser-vicemanagementtools. Deze ondersteunen het management van meerdere processen en worden daarom vaak workfl owtools genoemd, alhoewel daadwerkelijke workfl ow-engines kunnen ont-breken.

Het feit dat de focus in de IT vooral ligt op geautomatiseerde faciliteiten (voor de verwerking van gegevens) heeft ertoe geleid dat een groot aantal tools op de markt zijn verschenen.

Tools spelen een grote rol bij het behalen van het doel van continue kostenbesparing. Met be-hulp van softwaredistributietools en tools voor het op afstand besturen van computers is infra-structuurmanagement gemakkelijker. Dit leidt tot effi ciënte, gecentraliseerde productiecentra, waar services gemonitored en geleverd kunnen worden met een hogere kwaliteit en tegen lagere kosten.

Servicemanagementtools kunnen van groot belang zijn voor het leveren van bewijs voor een ISO 20000-certifi cering. Dat er voldaan wordt aan de eisen kan worden aangetoond door records die zijn opgeslagen in een adequaat servicemanagementsysteem. Bij het kiezen van servicemanage-menttools is het verstandig om de ISO 20000-eisen in het achterhoofd te houden.

Ondanks alle systemen en servicemanagementtools is de gevleugelde uitdrukking “a fool with a tool is still a fool” nog altijd van toepassing. Daarom moet het gebruik van tools gebaseerd zijn op effi ciëntie die is opgebouwd met een ITSM-procesgebaseerde werkwijze. Tooling moet altijd in de context van mensen, processen en partners worden geplaatst om de vereiste performance te kunnen leveren. Tools en technologie hebben in het verleden de meeste aandacht gekregen van IT-organisaties, maar om succesvol te zijn hoort aan ieder aspect evenveel aandacht te worden besteed.

2.4 Inzicht in processen

2.4.1 Voordelen en kenmerken van een procesgebaseerde aanpak

VoordelenElke organisatie heeft als doel zijn missie, strategie, doelstellingen en richtlijnen te realiseren, wat betekent dat toepasselijke activiteiten moeten worden uitgevoerd. Om de serie activiteiten die deel uitmaakt van de dagelijkse productie te kunnen beheersen, is het van belang dat deze activi-teiten en hun verbanden van begin tot eind van de serviceketen worden gemanaged.



Een restaurant koopt bijvoorbeeld verse producten, waarvan het aanbod met de seizoenen verandert. De chefs moeten samenwerken om een consistent resultaat te leveren en er kan niet te veel verschil zijn in de stijl van het bedienend personeel. Een restaurant zal alleen in staat zijn om drie sterren te vergaren als gedurende lange tijd dezelfde kwaliteit kan worden geleverd. Dit is niet altijd het geval: er zullen wijzigingen zijn in bedienend personeel, het succes van een bepaalde aanpak kan tijdig zijn en chefs vertrekken vaak om hun eigen restaurant te openen. Het leveren van een constante, hoge kwaliteit betekent ook dat de deelactiviteiten moet worden gecoördineerd. Hoe beter en effi ciënter de keuken functioneert, hoe hoger de kwaliteit van de service die aan de gast wordt geleverd.Toepasselijke activiteiten zijn onder andere: groenten inslaan, boekhouden, reclamemateriaal bestellen, gasten ontvangen, tafels schoonmaken, aardappels schillen en koffi e zetten. Met alleen deze ongestructureerde lijst is de kans groot dat iets over het hoofd wordt gezien en dat het personeel in de war raakt. Het is daarom beter om de activiteiten te structureren. Deze worden bij voorkeur zo gestructureerd dat het duidelijk is wat elke groep van activiteiten bijdraagt aan de doelstellingen van de business en hoe ze samenhangen.

De logische combinatie van activiteiten leidt tot duidelijke overdrachtspunten waar de kwaliteit van de processen kan worden gemonitord. In het voorbeeld hierboven kan een duidelijk onder-scheid gemaakt worden tussen de verantwoordelijkheid voor de inkoop en de verantwoordelijk-heid voor de bereiding. Hierdoor hoeven de chefs niet zelf alles te kopen en kunnen zij zich volledig richten op hun kerntaken.

De meeste organisaties zijn hiërarchisch gestructureerd, met afdelingen die verantwoordelijk zijn voor de activiteiten van een groep medewerkers. IT-services zijn daarentegen over het algemeen afhankelijk van verschillende afdelingen en disciplines. Als een IT-service bijvoorbeeld gebruikers toegang geeft tot een accountingprogramma op een centrale computer, dan zijn hier meerdere disciplines bij betrokken. Het computercentrum moet ervoor zorgen dat het programma en de database toegankelijk zijn, de data-afdeling en de telecommunicatie-afdeling moeten ervoor zorgen dat het computercentrum toegankelijk is en het pc-supportteam moet ervoor zorgen dat gebruikers een interface hebben om de applicatie te kunnen gebruiken.

Processen waarbij verschillende afdelingen, of teams, betrokken zijn, kunnen de kwaliteit van een service monitoren door afzonderlijke aspecten van kwaliteit te monitoren, bijvoorbeeld be-schikbaarheid, capaciteit, kosten en stabiliteit. Een service-organisatie zal proberen deze kwali-teitsaspecten in overeenstemming te brengen met de eisen van de klant. De structuur van zulke processen kan ervoor zorgen dat er goede informatie beschikbaar is over de levering van services, zodat de planning en de beheersing van services kan worden verbeterd.

De beschrijving van de processtructuur levert bovendien een gedeeld en stabiel referentiekader op dat kan helpen bij het onderhouden van de kwaliteit van IT-services tijdens en na reorganisa-ties. Dit houdt ook het wijzigen van leveranciers en partners in. Dit maakt dat serviceproviders minder kwetsbaar zijn voor organisatorische veranderingen. Het maakt ze ook fl exibeler: ze kun-nen hun organisatie voortdurend aanpassen aan veranderde omstandigheden, terwijl de kern van de processen ongemoeid blijft. Op deze manier kan bijvoorbeeld een winkel openblijven tijdens een verbouwing. In de praktijk zal dit echter toch lastiger zijn dan het in theorie lijkt.



IT-servicemanagement omvat alle activiteiten van de IT-afdeling. Deze activiteiten zijn ingedeeld in processen die, als ze geïntegreerd zijn, een effectief framework vormen. Dit framework verbe-tert de capabelheid en de volwassenheid van IT-servicemanagement. Elk van de processen omvat het uitvoeren van één of meer taken van de IT-organisatie, zoals serviceontwikkeling, infrastruc-tuurmanagement en ondersteuning van de services. Deze procesaanpak maakt het mogelijk om de best practices van IT-servicemanagement onafhankelijk van de structuur van de organisatie te beschrijven.

Zie sectie 2.1.3 voor meer voordelen van de procesaanpak.

Kenmerken

Een proces is een gestructureerde set activiteiten die gericht is op de realisatie van een bepaalde doelstelling.

Bij het rangschikken van activiteiten in processen maken we geen gebruik van de bestaande taakverdeling op afdelingen. Dit is een bewuste keuze. Door te kiezen voor een processtructuur kunnen we aantonen dat bepaalde activiteiten in een organisatie ongecoördineerd, dubbel, ver-waarloosd of onnodig zijn. Het is belangrijk om uit te gaan van de doelstelling van een proces en de relaties met andere processen. In fi guur 2.7 is te zien hoe activiteiten op verschillende organisatorische deelterreinen kunnen worden gecombineerd in een proces (aangegeven in de onderbroken lijnen). In fi guur 2.8 is een voorbeeld van een proces te zien.

Als de processtructuur van een organisatie duidelijk beschreven is, bevat deze informatie over:• wat er gedaan moet worden• wat de verwachte inputs en resultaten zijn• hoe gemeten moet worden of de processen de verwachte resultaten leveren• hoe de resultaten van een proces invloed hebben op andere processen

IT-management

Softwareontwikkeling ProductieService desk

ProjectorganisatieSoftwareonderhoud

en applicatie-management

Kantoorautomatiseringen -telecommunicatie

Netwerkmanagement

UIT

IN

Figuur 2.7 Processen en afdelingen (voorbeeld)



Gedurende de afgelopen jaren was IT-servicemanagement de proces- en servicegerichteaanpak van wat offi cieel informatietechnologiemanagement werd genoemd. Deze verschuiving van in-frastructuur naar processen heeft de basis gelegd voor de term IT-servicemanagement als een proces- en klantgerichte discipline.

Omdat processen altijd een helder gedefi nieerde doelstelling moeten hebben is het streven van IT-servicemanagementprocessen om bij te dragen aan de kwaliteit van IT-services. Kwaliteitsma-nagement en procesbeheersing zijn onderdeel van de organisatie en zijn richtlijnen.

2.4.2 Meten en beheersen van processenProcessen bestaan uit twee soorten activiteiten: activiteiten die te maken hebben met het realise-ren van doelen (operationele activiteiten voor de doorvoer) en activiteiten die te maken hebben met het managen van doelen (controlactiviteite n). Deze controlactiviteiten zorgen ervoor dat de operationele activiteiten (de workfl ow ) tijdig en op de juiste manier worden uitgevoerd. Bij het verwerken van changes wordt er bijvoorbeeld op toegezien dat er een test is uitgevoerd vóórdat een release in productie wordt genomen.

Deze denkwijze wordt weergegeven in fi guur 2.9 en wordt ook wel het ITOCO-model genoemd. Volgens dit model is een proces een serie activiteiten die uitgevoerd wordt om input om te zetten in output, wat uiteindelijk leidt tot een uitkomst:• input• throughput• output

Indienen van een RfC

Registratie

Acceptatie voor behandeling

Classificatie

Planning

Acceptatie voor bouwen

Bouwen

Testen

Acceptatie voor implementatie

Evaluatie

Afsluiting

Figuur 2.8 Changemanagement: voorbeeld van een stroomschema van een proces



• control• outcome

De input heeft te maken met de resources die in het proces worden gebruikt. De (gerappor-teerde) output beschrijft de onmiddellijke resultaten van het proces, terwijl de uitkomst over de langetermijnresultaten van het proces gaat (in termen van een betekenisvol resultaat). Door controlactiviteiten kunnen input en output van elk van de processen in verband worden gebracht met richtlijnen en normen, om zodoende informatie te krijgen over de resultaten van het proces.

Control reguleert de input en de doorvoer in het geval dat de doorvoer- of outputparameters niet overeenkomen met de richtlijnen en normen. Dit levert zowel procesketens op die weergeven welke input een organisatie heeft en wat het resultaat is, als monitoringpunten in die ketens om de kwaliteit van de geleverde producten en services te controleren.

De normen voor de output van elk van de processen moeten worden gedefi nieerd, zodat de complete procesketen in het procesmodel de bedrijfsdoelstelling ondersteunt. Als de output van een proces voldoet aan de gedefi nieerde eisen dan is het proces effectief in het transformeren van input naar output.

Als de activiteiten in het proces ook worden uitgevoerd met een minimum aan inspanning en kosten, dan is het proces effi ciënt . Het is de taak van procesmanagement om met planning en control te borgen dat de processen op effi ciënte en effectieve wijze worden uitgevoerd.

2.4.3. Rollen voor procesmanagementRollen bestaan uit een combinatie van verantwoordelijkheden , activiteiten en bevoegdheden die aan een bepaald persoon of team zijn toegekend. Elk proces heeft een proceseigenaar nodig die verantwoordelijk is voor de resultaten van het proces. De procesmanager is verantwoordelijk voor het realiseren en structureren van de processen, en voor de rapportage naar de proceseigenaar. De procesuitvoerders (technici) zijn verantwoordelijk voor de gedefi nieerde activiteiten en rapporte-ren hierover naar de procesmanager.

standaardenen richtlijnen

eisen

efficiëntie effectiviteit

realisatie vandoelen

INPUTThroughput(doorvoer)

OUTPUTOUTCOME(resultaat)

CONTROL

Figure 2.9 Procesdiagram, gebaseerd op het ITOCO-model



Het management van de organisatie kan control baseren op kwaliteitsassessments van elk proces. In de meeste gevallen zijn de relevante performance-indicatoren en normen al overeengekomen. De dagelijkse control van de processen kan dan aan de procesmanager worden overgelaten. De proceseigenaar zal de resultaten beoordelen op basis van een rapport over de performance-indi-catoren en zal beoordelen of er aan die overeengekomen standaard is voldaan. Zonder duidelijke indicatoren is het voor een proceseigenaar moeilijk om te bepalen of een proces goed verloopt en of de geplande verbeteringen worden geïmplementeerd.

Een persoon of een team kan meerdere rollen hebben. Zo kunnen de rollen van confi guratiema-nager en changemanager uitgevoerd worden door dezelfde persoon.

2.5 Inzicht in continue verbeteringZoals besproken in sectie 2.1.3 is continue verbetering één van de acht kwaliteitsmanagement-principes van ISO 9000. Continue verbetering is nodig voor het verbeteren van performance en het verbeteren van de tevredenheid van zowel de klanten als andere betrokken partijen. Continue verbetering zou een permanente doelstelling van een organisatie moeten zijn.

Continue verbetering houdt het wiel van de PDCA-cyclus draaiende. Zie fi guur 2.1.1 voor meer informatie over deze cyclus.

De volgende paragraaf gaat dieper in op volwassenheidsmodellen en hun relatie met capability-assessments.

2.5.1 VolwassenheidsmodellenSinds de introductie van Richard Nolans fasenmodel voor de toepassing van IT in organisaties in 1973, hebben velen stapsgewijze verbetermodellen gebruikt. Deze modellen werden al snel gezien als de meest geschikte instrumenten voor kwaliteitsverbeterprogramma’s en daardoor als hulp voor organisaties in hun streven naar (meer) volwassenheid.

Er zijn tientallen varianten van fasenmodellen, variërend van vakgebieden zoals softwareontwik-keling, acquisitie, systeemontwikkeling, testen van software, websiteontwikkeling, data-opslag en security-ontwikkeling tot helpdesks en kennismanagement.

Een aantrekkelijke toepassing van Nolans modelleringsprincipe is het Software Capability Ma-turity Model (SW-CCM) dat werd gepubliceerd door het Software Engineering Institute (SEI) van de Carnegie Mellon Universiteit. Het CMM werd overgenomen en toegepast op veel van de bovengenoemde vakgebieden, waardoor CMM ongeveer tot norm voor volwassenheidsmodel-lering werd verheven. Het CMM werd later opgevolgd door nieuwe edities, zoals CMMI (CMM Integration). Een ander bekend volwassenheidsmodel is het World Class IT Maturity Model.

Het CMMI beschrijft de volwassenheidsniveau ’s van een organisatie als volgt:• Volwassenheidsniveau 1: Initieel – Processen zijn ad hoc en chaotisch. De organisatie biedt

geen stabiele omgeving voor de ondersteuning van de processen. Succes hangt af van de com-petentie van de mensen in de organisatie en niet van het gebruik van bewezen processen. On-danks deze chaos produceren organisaties met een volwassenheid van niveau 1 vaak services die wel functioneren, maar het budget wordt vaak overschreden en planningen lopen vaak uit.



• Volwassenheidsniveau 2: Herhaalbaar (Managed) – De projecten van de organisatie borgen dat de processen conform het beleid worden gepland en uitgevoerd. Er zijn kundige mensen in dienst genomen die voldoende resources tot hun beschikking hebben om gecontroleerde outputs te produceren, relevante stakeholders erbij te betrekken, die gemonitored, beheerst en gereviewd worden en die worden geëvalueerd op naleving van de procesbeschrijvingen.

• Volwassenheidsniveau 3: Gedefi nieerd – Processen worden gekenmerkt en begrepen en worden beschreven in normen, procedures, tools en methoden. De standaardprocessen van de organisatie, die de basis vormen voor volwassenheidsniveau 3, zijn ingericht en worden verbeterd. Deze standaardprocessen worden gebruikt om consistentie te creëren door de hele organisatie. Projecten richten processen in door de standaardprocessen van de organisatie toe te passen op de richtlijnen van het proces.

• Volwassenheidsniveau 4: Kwantitatief Gemanaged – De organisatie en projecten stellen kwantitatieve kwaliteitsdoelstellingen en procesperformance vast en gebruiken deze als criteria bij het managen van processen. Kwantitatieve doelstellingen zijn gebaseerd op de behoeften van de klant, eindgebruikers, organisatie en degenen die processen implementeren. Kwaliteit en procesperformance worden weergeven in statistische termen en worden tijdens de gehele levenscyclus van de processen gemanaged.

• Volwassenheidsniveau 5: Optimaliseren – Dit niveau legt de nadruk op het continu verbe-teren van procesperformance door incrementele en innovatieve verbeteringen van processen en technologieën. Doelstellingen voor kwantitatieve procesverbeteringen worden vastgesteld, voortdurend aangepast op veranderende bedrijfsdoelstellingen en gebruikt als criteria bij het managen van procesverbeteringen. De effecten van de ingevoerde procesverbeteringen wor-den gemeten en geëvalueerd tegen de doelstellingen voor kwantitatieve procesverbeteringen. Zowel de gedefi nieerde processen als de standaardprocessen van de organisatie zijn targets van meetbare verbeteractiviteiten.

Later werden deze modellen toegepast in kwaliteitsmanagementmodellen, zoals de European Foundation for Quality Management (EFQM). Naast de brede kwaliteitsmanagementmodellen zijn er ook verscheidene andere algemeengeaccepteerde practices, zoals Six Sigma en TQM. Deze practices zijn aanvullend op ITIL.

De beschikbare normen en best practice-frameworks bieden richtlijnen voor organisaties die streven naar een operationeel topniveau (‘operational excellence’) van IT-servicemanagement. De soort richtlijnen die organisaties nodig hebben, is afhankelijk van de ontwikkelingsfase waarin ze zich bevinden. ISO 9000 en ISO 20000 leggen de nadruk op de defi nitie, beschrijving en ontwerp van proces-sen en het ontwikkelen en onderhouden van een kwaliteitssysteem dat voldoet aan hun eisen. Daarom kunnen ze worden beschouwd als het gereedschap waarmee een organisatie een vante-voren gedefi nieerd volwassenheidsniveau kan bereiken en onderhouden.

2.5.2 Capability-assessments en hun relatie met volwassenheidsmodellenEen assessment vergelijkt de performance van de processen met een performancenorm. Dit kan een overeenkomst zijn in een service level agreement (SLA), maar ook een volwassenheidsnorm of een vergelijking met bedrijven uit dezelfde bedrijfstak. Dit laatste type assessment staat bekend als benchmark.



Een ISO 20000-assessment is duidelijk een capability-assessment : het geeft aan of er voldaan wordt aan de ISO 20000-eisen. Als aan alle eisen is voldaan betekent dit dat de organisatie ser-vices kan leveren tegen het kwaliteitsniveau dat door de norm is gespecifi ceerd. Een volwassen-heidsassessment geeft aan welk volwassenheidsniveau is bereikt, zodat de organisatie kan bepalen welke acties ze moet ondernemen om het volgende volwassenheidsniveau te bereiken.

Assessments zijn erg geschikt om een antwoord te vinden op de vraag: ‘waar zijn we nu?’ en te bepalen hoe groot de afstand is met ‘waar we willen zijn’. Een erkend framework kan een steun zijn bij het benchmarken van de volwassenheid. Verlies daarbij niet uit het oog dat het gewenste performance- of volwassenheidsniveau van een proces afhangt van de impact dat het proces heeft op de bedrijfsprocessen van de klant.

Bepaal om te beginnen de relatie tussen bedrijfsprocessen, IT-services, IT-systemen en compo-nenten van deze systemen. Beoordeel daarna de effectiviteits- en de effi ciëntieresulaten van elk onderdeel. Dit helpt bij het vaststellen van gebieden die verbetering kunnen gebruiken.

Het is van cruciaal belang om duidelijk te defi niëren wat er wordt beoordeeld. Dit moet worden gebaseerd op de doelen en het verwachte gebruik van de rapportages. Een assessment kan op drie niveau’s plaatsvinden:• Alleen het proces – alleen de procescomponenten uit de procesbeschrijving worden beoor-

deeld. • Mensen, processen en technologie – de beoordeling omvat ook vaardigheden, rollen en ta-

lenten van managers en medewerkers die participeren in het proces en de technologie die het proces ondersteunt.

• Compleet – de beoordeling omvat ook het vermogen en het voorbereidingsniveau voor het accepteren van processen en de mogelijkheid tot formulering en volgen van processtrategieën en procesdoelen.

Deze assessments kunnen met het geselecteerde volwassenheidsmodel worden vergeleken.

Assessments zijn nuttig in de:• Planningsfase (Plan)– als uitgangspunt (baseline ) voor procesperformance.• Uitvoeringsfase (Do)– meten of de schattingen correct zijn.• Meetfase (Check)– de balans opmaken en meer mogelijk verbeteringen identifi ceren.

Voordelen van assessments zijn:• Ze meten bepaalde delen van een proces onafhankelijk van de rest en bepalen de impact van

een specifi eke component op de rest van het proces.• Ze kunnen worden herhaald.• Ze kunnen worden gebruikt bij benchmarking.

Nadelen van assessments zijn:• Ze geven slechts een momentopname en geven geen inzicht in de culturele dynamiek van een

organisatie.• Ze kunnen een doel op zich worden in plaats van een middel.• Ze zijn arbeidsintensief.



• De metingen kunnen objectief zijn, maar de resultaten nooit helemaal omdat deze afhankelijk zijn van subjectieve beoordelaars.

• Interviewers en geïnterviewden vinden het soms moeilijk te begrijpen wat de vragen precies betekenen, wat kan leiden tot onvolledige resultaten en miscommunicatie.

Hieronder wordt besproken hoe kwaliteitsmanagemensystemen kunnen worden geëvalueerd.

Evalueren van processen binnen het kwaliteitsmanagementsysteemBij het evalueren van kwaliteitsmanagementsystemen zijn er vier basisvragen voor elke procese-valuatie:• Is het proces vastgesteld en voldoende gedefi nieerd?• Zijn de verantwoordelijkheden toegewezen? • Worden de processen geïmplementeerd en onderhouden?• Is het proces effectief als het gaat om het behalen van de gewenste resultaten?

De collectieve antwoorden op de bovenstaande vragen bepalen het resultaat van de evaluatie. De scope van de evaluatie van een kwaliteitsmanagementsysteem kan variëren en een groot aan-tal activiteiten omvatten, zoals auditen, reviewen van het kwaliteitsmanagementsysteem en self-assessments.

Auditen van het kwaliteitsmanagementsysteemAudits worden gebruikt om te bepalen in welke mate aan de eisen van het kwaliteitsmanage-mentsysteem wordt voldaan. De bevindingen van audits worden gebruikt om de effectiviteit van het kwaliteitsmanagement-systeem te beoordelen en om mogelijkheden tot verbetering te bepalen.Audits kunnen worden uitgevoerd door de organisatie zelf, of in naam van de organisatie, voor interne doeleinden, en kunnen de basis vormen voor een conformiteitsverklaring van conformi-teit van de organisatie zelf (fi rst party audits).Audits kunnen ook worden uitgevoerd door klanten van de organisatie of door andere personen in naam van de klant (second party audits).Ten slotte kunnen audits nog worden uitgevoerd door externe, onafhankelijke organisaties. Zulke organisaties, die meestal zijn geaccrediteerd, geven een certifi cering of een verklaring van conformiteit met de eisen van bijvoorbeeld ISO 9001. ISO 90011 geeft richtlijnen voor audits.

Reviewen van het kwaliteitsmanagementsysteemTopmanagement behoort op systematische wijze de geschiktheid, toereikendheid, effectiviteit en effi ciëntie van het kwaliteitsmanagementsysteem te evalueren op het kwaliteitsbeleid en de kwaliteitsdoelstellingen . Dit kan ook de overweging omvatten of kwaliteitsbeleid en -doelstellin-gen aangepast moeten worden naar aanleiding van veranderde behoeften en verwachtingen van de betrokken partijen. De review omvat het vaststellen of er acties nodig zijn. Auditrapporten worden samen met andere informatiebronnen gebruikt om het kwaliteitsmanagementsysteem te reviewen.

Self-assessmentDe self-assessment van een organisatie is een allesomvattende en systematische review van de activiteiten en resultaten van de organisatie, ten opzichte van het kwaliteitsmanagementsysteem of een ander kwaliteitsmodel.



Self-assessments kunnen een totaalbeeld geven van de performance van de organisatie en de mate van volwassenheid van het kwaliteitsmanagementsysteem. Ze kunnen ook bijdragen aan het be-palen van de verbeterpunten in een organisatie en aan het bepalen van prioriteiten.

De itSMF benchmarkBenchmarkprojecten , zoals het project dat itSMF-Nederland heeft ontwikkeld, combineren al het bovenstaande. Het procesmodel-deel is een ontwerp dat is gebaseerd op de ISO 20000-norm en uitgebreid met operationsmanagement. Elke allesomvattende proces-vragenlijst combineert de specifi eke onderwerpen van 20000-1 en 20000-2 met vragen over CMMI-volwassenheid. Dit resulteert in gedetailleerde activiteitenlijsten voor performanceverbetering, en vergemakkelijkt de weg naar certifi cering. Het is noodzakelijk dat een externe consultant de resultaten ondersteunt en valideert omdat is gebleken dat organisaties zonder een externe beoordelaar 25% positiever scoren dan in werkelijkheid het geval is. Ook is een betrouwbare database vereist. Weten waar je organisatie staat in vergelijking met de norm en CMM, in combinatie met de resultaten van andere organisaties op deze terreinen, biedt uitstekend inzicht en maakt het gemakkelijker om betekenisvolle en reëele targets te stellen.


3.1 Inzicht in het landschap van normen en frameworksHieronder volgt een samenvatting van de doelen en doelorganisaties van verschillende belang-rijke frameworks in het vakgebied IT-servicemanagement.

• CMMI:− Doel: verbeteren van het gebruik van volwassenheidsmodellen voor softwareontwikkeling

en andere disciplines door samenvoeging van verschillende modellen in één framework.− Doelorganisatie: organisaties die ondernemingsbrede procesverbetering willen.

• CobiT :− Doel: leveren van een uniforme structuur voor het begrijpen, implementeren en evalueren

van IT-capabilities, performance en risico’s, met als hoofddoel het voldoen aan de bedrijf-seisen.

− Doelorganisatie: organisaties die hun governance willen structureren. • ISO 9000:

− Doel: aantonen van de capability van een organisatie om aan de eisen van de klant te voldoen met behulp van een kwaliteitsmanagementsysteem dat fl exibel, gestructureerd en klantgericht is.

− Doelorganisatie: alle soorten organisaties die willen bewijzen dat ze capabel zijn voor de levering van producten en services en daarbij voortdurend dezelfde processen volgen.

• ISO 15540 :− Doel: leveren van een handleiding voor de uitvoering van een capability-assessment om

processen te verbeteren.− Doelorganisatie: technologische organisaties die de capabilities van de organisatie in elke

procesfase willen beoordelen en de effectiviteit van de processen ten opzichte van de doelen willen bepalen.

• ISO 20000 − Doel: promoten van het gebruik van een geïntegreerde procesaanpak om effectief gema-

nagede services te leveren en te voldoen aan de eisen van het bedrijf en de klant.

Hoofdstuk 3Inzicht in de positie van ISO 20000 in IT-servicemanagement



− Doelorganisatie: alle IT-serviceproviders die een wereldwijd geaccepteerde standaard willen gebruiken en hun capability willen laten zien om kwaliteitsvolle IT-services te leveren aan interne en externe klanten.

• ISO 27001 :− Doel: verminderen van de blootstelling van een organisatie aan informatiesecurityrisico’s

door gebruik van een informatiesecuritymanagementsysteem (ISMS).− Doelorganisatie: organisaties die hun risico’s onder controle willen hebben en hun assets

willen beschermen. • ITIL :

− Doel: leveren van zowel best practice-richtlijnen voor IT-servicemanagement, als een set van geïntegreerde processen voor de levering en de ondersteuning van IT-services van een hoge kwaliteit.

− Doelorganisatie: organisaties die hun IT-servicemanagementprocessen willen standaardise-ren conform een wereldwijd geaccepteerd best practiceframework.

• Six Sigma :− Doel: bedrijven voorzien van tools waarmee ze de capability van hun bedrijfsprocessen of

IT-processen statistisch kunnen meten en kunnen verbeteren. Hierdoor wordt de perfor-mance hoger en procesvariatie lager door foutreductie.

− Doelorganisatie: organisaties die een beter inzicht willen hebben in hun procesperformance en verbetermogelijkheden.

• Bedrijfsspecifi eke normen – Bedrijven kunnen hun eigen bedrijfsspecifi eke normen hebben. Deze kunnen gebaseerd zijn op de hierboven genoemde frameworks en modellen, maar zul-len zijn toegepast op de specifi eke situatie van de organisatie. Deze bedrijfsspecifi eke normen kunnen richtlijnen voor verschillende aspecten van IT-servicemanagement zijn, zoals security-richtlijnen, of normen voor IT-architectuur of standaardisatie. Microsoft heeft bijvoorbeeld MOF (Microsoft Operations Framework) ontwikkeld, dat op ITIL is gebaseerd en is ontwik-keld om een reeks van Microsoft producten te ondersteunen. Deze bedrijfsspecifi eke normen moeten overeenkomen met de eisen van het bovenste niveau van ISO 20000-1 en het hele spectrum van bedrijfspecifi eke normen, frameworks en ISO-normen moet op elkaar worden afgestemd. Daarom moet er aan het begin van een ISO 20000-certifi cering aandacht worden besteed aan het zorgvuldig analyseren van de interne normen. Deze interne normen moeten worden afgestemd op de eisen zoals die beschreven worden in ISO 20000-1.

De doelorganisatie is een van de stakeholders, normaal gesproken is er sprake van meerdere stake-holders. De defi nitie van een stakeholder is:

Een stakeholder is een persoon, groep of organisatie die invloed heeft, beïnvloed wordt of denkt beïnvloed te worden door een actie van een systeem of organisatie, waardoor zij een aandeel hebben in, recht hebben op, of belang hebben bij dat systeem of die organisatie.

Dit houdt in dat ook de klanten, leveranciers, individuen van service providers en andere partijen stakeholder kunnen zijn.


Inzicht in de positie van ISO 20000 in IT-servicemanagement 35

3.2 Inzicht in de concepten van certifi ceringspracticesBSI en nu ook ISO stellen serviceproviders in staat om formeel aan best practices te voldoen door de kerninformatie van de ITIL-servicemanagementprocessen in een internationaal gefor-maliseerde standaard samen te voegen. Voordat BS 15000 werd ontwikkeld, was de formele certifi cering alleen gericht op individuen (ITIL Foundation, ITIL Service Manager, ITIL Prac-titioner) en niet op organisaties. ISO 20000-certifi cering is geen formele ITIL-certifi cering. De standaard refereert niet aan ITIL, zelfs niet in de literatuurlijst. Toch kan de inhoud van ITIL V2 makkelijk worden teruggevonden in de standaard (zie sectie 3.3.1). Met ISO 20000 kan een serviceprovider dus een internationale, bedrijfsgerichte certifi cering behalen op het gebied van IT-servicemanagement. Dit stimuleert de verdere acceptatie van IT-servicemanagement als een belangrijk vakgebied.

3.2.1 Bedrijfscertifi ceringDe ISO 20000-norm is ontwikkeld als een standaard waarop serviceproviders kunnen worden gecertifi ceerd. Een serviceprovider die wil laten zien dat hij waarde hecht aan kwaliteit in IT-servicemanagement, kan zijn organisatie onafhankelijk laten certifi ceren.

Rollen en verantwoordelijkhedenHoewel iedereen een organisatie tegen ISO 20000 kan laten certifi ceren, wordt aan deze certifi ce-ring meer waarde gehecht als dit gebeurt door het certifi ceringsschema van EXIN, TÜV SÜD en itSMF-UK. itSMF UK registreert certifi ceringsinstituten (ook wel registered certifi cation bodies genoemd, oftewel RCB’s) die certifi cering verlenen. De meeste landen hebben lokale certifi ce-ringsinstituten, of lokale dochterorganisaties van internationale certifi ceringsinstituten, die in-terne audits uitvoeren. De cerifi ceringsinstituten zijn geregistreerd bij het nationale accreditatie-instituut, de National Accreditation Body (NAB) . Veel van deze nationale accreditie-instituten zijn geregistreerd bij het International Accredition Forum (IAF) . Certifi caten van instituten die zijn geaccrediteerd door leden van het IAF Multilateral Recognition Arrangement (MLA) wor-den wereldwijd erkend, omdat het MLA klanten de garantie biedt dat het certifi caat gedegen is.

Dit proces van certifi ceren en accrediteren wordt al jaren succesvol gebruikt voor alle ISO-certifi -ceringen. Het verzekert internationale klanten van een gegarandeerd certifi ceringsproces.

ToepasbaarheidToepasbaarheid betekent dat er aan de voorwaarden voor certifi cering wordt voldaan. De toepas-baarheid van ISO 20000 is breed. Servicemanagementsystemen zijn daarom toepasbaar op een groot bereik aan serviceproviders. ISO 20000 kan worden toegepast bij interne en externe ser-viceproviders, grote en kleine serviceproviders en commerciële en niet-commerciële organisaties.

Een serviceprovider die graag gecertifi ceerd wil worden kan een organisatie op zichzelf zijn, of deel uitmaken van een grotere organisatie. De serviceprovider mag in geen geval bestaan uit een groep van organisaties, het moet een enkelvoudige juridische entiteit zijn. Een andere voorwaarde is dat de serviceprovider volledig in control is van alle ISO 20000-processen. Dit is het geval als alle services en activiteiten volledig binnen het servicemanagementsysteem worden beheerst. Als een serviceprovider geen volledige controle heeft over deze processen, komt deze niet in aanmer-king voor een ISO 20000-certifi cering.



Bijvoorbeeld: als een bedrijf slechts de controle heeft over enkele processen, zoals incident-management en problemmanagement, dan komt het niet in aanmerking voor een ISO 20000-certifi cering. Het bedrijf moet een IT-service leveren waarin alle ISO 20000-processen zijn vertegenwoordigd. Dit betekent niet dat een serviceprovider geen IT-services kan uitbeste-den. Als een serviceprovider bijvoorbeeld de servicedesk uitbesteedt, en gerelateerde activiteiten van incidentmanagement- en problemmanagementprocessen, dan voert hij deze activiteiten niet meer zelf uit. Echter, als is vastgelegd wat de performance van deze activiteiten moet zijn en managementcontrol kan worden aangetoond door SLA’s, regelmatige analyses van rapportages en het ondernemen van acties, dan kan het bedrijf nog steeds in aanmerking komen voor certi-fi cering.

ScopingDe scope van de geleverde service moet worden beschreven in een scopeverklaring . Een ser-viceprovider kan worden gecertifi ceerd worden voor een gedeelte van de services die hij levert. Certifi cering kan ook worden verkregen voor een bepaald land, of een bepaalde klant. Dit moet worden weergegeven in een scopeverklaring. Deze verklaring bevestigt de certifi cering voor een bepaalde situatie. Als bijvoorbeeld een grote internationale organisatie alleen gecertifi ceerd is voor de in-house IT-services binnen een bepaald land, dan moet dit zijn vastgelegd in de scope-verklaring bij die certifi cering.

De typische structuur van de scopeverklaring:

De <service> geleverd door <naam van de organisatorische afdeling van de service provider> aan <naam van de klantorganisatie en/of organisatorische afdeling> uit <geografi sch gebied en/of locatie>.

De service (of services) moet(en) dus worden genoemd. Ook de naam van de organisatie (juridi-sche entiteit), de naam van de ontvanger van de service en de lokatie van waaruit de service wordt geleverd moeten zijn opgenomen in de scopeverklaring.

De voordelen van certifi ceringISO 20000 levert een framework en een systematische aanpak voor het managen van IT-service-managementprocessen, teneinde een IT-service te leveren die voldoet aan de verwachtingen van de klant. De implementatie van ISO 20000-processen verbetert de effectiviteit en de effi ciëntie van bedrijfsprocessen en bespaart geld. Veel organisaties die ISO 20000-gecertifi ceerd zijn geven aan een stijging in de proceseffi ciëntie, een hogere klanttevredenheid en een verbeterde service-kwaliteit te ervaren.

De ISO 20000-certifi cering van leveranciers betekent voor klanten dat zij zeker kunnen zijn dat de ontwikkeling en de levering van de services overeenkomen met wereldwijd erkende normen. Dit betekent dat klanten en leveranciers een concurrentiepositie hebben op de internationale markt.

Er zijn veel voordelen van een ISO 20000-certifi cering. Organisaties moeten er zeker van zijn dat ze gecertifi ceerd willen zijn om de juiste redenen:• Om te voldoen aan de eisen van nieuwe klanten. Steeds meer ondernemingen zien ISO

20000-certifi cering als een belangrijke vereiste om zaken te doen met een nieuwe verkoper.



• Om de internationale markt op te gaan. ISO 20000 normen worden wereldwijd erkend.• Om betere documentatie beschikbaar te hebben voor verschillende doeleinden• Om de organisatie een betere concurrentiepositie te geven, en te laten zien dat er wordt ge-

streefd naar kwaliteitsservices.

Het certifi ceringsprocesAls de serviceprovider de implementatieprocessen voor het kwaliteitsmanagementsysteem heeft uitgevoerd en als een interne assessment aangeeft dat de processen voldoen aan de ISO 20000- eisen, is de provider klaar voor het certifi ceringsproces .

Het certifi ceringsproces bestaat uit 7 stappen:1. vragenlijst2. assessmentaanvraag3. optionele pre-audit4. initiële audit (fase 1)5. certifi ceringsaudit (fase 2)6. surveillance-audits7. hercertifi ceringsaudit

De stappen worden hieronder besproken.

Het geselecteerde certifi ceringsinstituut stuurt een vragenlijst . Het certifi ceringsproces begint met informatie over de eisen en de organisatie. Dit levert voor het certifi ceringsinstituut de gegevens op die nodig zijn voor een prijsopgave.

Nadat besloten is door te gaan met de certifi cering bij het gekozen certifi ceringsinstituut, moet het aanvraagformulier worden ingevuld en opgestuurd naar het certifi ceringsinstituut. Daarna zal er een eerste bezoek moeten worden geregeld van de hoofdauditor. Bij het eerste bezoek kunnen de vertegenwoordigers van de organisatie kennis maken met de hoofdauditor die het manage-mentsysteem gaat beoordelen voor de ISO 20000-certifi cering. De auditor zal uitleg geven over het assessmentproces en een review uitvoeren van het bestaande gedocumenteerde management-systeem. Er worden afspraken gemaakt over een assessmentdatum en een auditprogramma . Bij elke audit is het van groot belang dat de betrokkenen goed met elkaar overweg kunnen. Ook is het belangrijk om een goed beeld te krijgen van het proces, het bedrijf en van de hoofdauditor.

Een pre-audit is een evaluatie op hoog niveau, die aangeeft waar de organisatie momenteel staat in relatie tot de ISO 20000-normen. Als ISO-audits nieuw zijn voor de organisatie, kan een pre-audit helpen om management en het personeel duidelijk te maken wat er gaat gebeuren. De auditor geeft aan wat de probleemgebieden zijn. Door in deze fase mogelijke issues aan te geven, is tijdens de feitelijke audit het risico kleiner dat er niet aan de eisen wordt voldaan. Deze eerste observaties kunnen worden geïmplementeerd in het managementsysteem, zodat er aanpassingen kunnen worden aangebracht voordat de offi ciële audit begint.

De initiële audit controleert of het managementsysteem geïmplementeerd is door een selectie van beheersingsmechanismen, waaronder de documentatie van de richtlijnen en procedures die hier-bij van toepassing zijn. De auditor plant fase 2 van de audit (certifi cering). In deze sessie wordt



de scopeverklaring besproken en afgesproken. De documentatie van het managementsysteem en de procesdocumenten ondergaan de initiële assessment . Als er sprake is van auditfouten, dat wil zeggen afwijkingen van de norm, dan worden deze toegevoegd aan het Corrective Action Plan (CAP) . De klant moet documenteren hoe deze CAP’s aangepakt gaan worden en moet dit voor akkoord doorgeven aan het certifi ceringsinstituut.

Tijdens de certifi ceringsaudit zal een objectieve assessment van de organisatorische procedures en practices worden uitgevoerd, ten opzichte van het gedocumenteerde managementsysteem (dat in de initiële audit is gereviewd). De auditor zal uitkijken naar bewijs dat het managementsysteem wordt uitgevoerd volgens gedocumenteerde managementsysteem. Na voltooiing van de assess-ment legt de auditor de bevindingen vast in een geschreven rapport . Afwijkingen en observaties worden opgenomen in het CAP. Als een certifi ceringsaudit succesvol is verlopen en er een positief besluit is, wordt er een certifi caat van registratie toegekend. De organisatie mag zich vanaf dat moment ISO 20000-gecertifi ceerd noemen en gebruik maken van het certifi ceringslogo van het certifi ceringsinstituut en het relevante ISO 20000-logo.

Een programma van regelmatig terugkerende surveillance-audits wordt opgesteld, zodat er kan worden nagegaan of er nog steeds wordt voldaan aan de ISO 20000-norm. Indien nodig, worden afwijkingen van de norm toegevoegd aan het CAP. Deze surveillance-audits worden uitgevoerd in een driejaarlijkse cyclus, om te borgen dat het managementsysteem naar behoren functioneert. Deze audits zijn een aanvulling op interne audits en op voortdurende interne monitoring en management. De feitelijke frequentie hangt af van de RCB, maar over het algemeen geldt het volgende:• Surveillance-audits worden regelmatig uitgevoerd (normaal gesproken iedere zes tot twaalf

maanden).• Bij elke audit worden openstaande CAP’s behandeld.• Alle vereisten worden geaudit gedurende drie jaar.• Een representatieve steekproef van alle andere controls wordt geaudit (zodat alle controls in de

managementsystemen in de surveillancecyclus worden gereviewd).

De re-certifi ceringsaudit wordt elke drie jaar uitgevoerd. Deze audit is vergelijkbaar met de ori-ginele audit, maar zal minder tijd kosten omdat de auditor van het certifi ceringsinstituut de systemen nu kent, tenzij er een scope- of andere wijziging heeft plaatsgevonden. Alle controls worden geëvalueerd om te borgen dat het managementsysteem naar behoren functioneert. Als dit het geval is, is de certifi cering weer drie jaar geldig. Als dit niet het geval is, worden afwijkin-gen en observaties opgenomen in het Service Improvement Plan (SIP) en het CAP , waarna ze in behandeling worden genomen. Het driejaarlijkse surveillance-auditproces start van voren af aan.

3.2.2 Persoonlijke certifi ceringDe wereldwijde erkenning van kwalifi caties in ISO 20000 voor professionals (volgens het kwali-fi catieschema) wordt steeds belangrijker voor zowel organisaties als individuele professionals. De optimalisering van professionaliteit is een belangrijke hoeksteen van succesvolle IT-serviceverbe-terprogramma’s. Organisaties kunnen de betrokkenheid van hun personeel bij zulke programma’s stimuleren door werknemers met internationaal erkende certifi ceringen meer uitdaging te bieden en te belonen.



Om ISO 20000-gecertifi ceerd te worden, moeten organisaties kunnen aantonen dat ze een kwa-liteitsmanagementsysteem hebben en dat hun ITSM-processen duidelijk zijn ingericht. De ISO 20000-1 -norm beschrijft echter slechts summier aan welke eisen medewerkers moeten voldoen die betrokken zijn bij het leveren van de services. De introductie stelt:

Er wordt vanuit gegaan dat de uitvoering van de bepalingen van dit gedeelte van ISO 20000 wordt toevertrouwd aan voldoende gecertifi ceerde en competent personeel .

Maar wat houdt dit precies in? Welk kennisniveau zouden deze ‘voldoende gecertifi ceerde en capabele personen’ daadwerkelijk van de ITSM-processen moeten hebben? En hoe kunnen we op een objectieve manier meten of ze aan deze eis voldoen?

Het is moeilijk om de standaard en de audit hiervan effectief toe te passen als er geen algemeen geaccepteerde terminologie en rolbeschrijving zijn. Educatieve en kwalifi catieprogramma’s met duidelijke defi nities en eisen voor de werknemers zouden de toepassing van de standaard aanzien-lijk vergemakkelijken. Bovendien hebben klantorganisaties vaak meer vertrouwen in organisaties die certifi caten kunnen laten zien die aantonen dat hun personeel de geschikte kwalifi caties heeft.

Een ISO 20000-certifi ceringsproces vereist veel inzet en kennis van bijna al het personeel dat betrokken is bij het leveren van IT-services. Niet alleen consultants, managers en trainers moeten zich bewust zijn van de principes van kwaliteitsmanagement. Ook werknemers op productie-niveau behoren kennis te verwerven van kwaliteit, ITSM en algemene management- en verbeter-processen. Dit geeft hen inzicht en versterkt hun motivatie. Auditors behoren een goede kennis te hebben van IT-servicemanagement om in staat te zijn organisaties te auditen volgens het ISO 20000-schema.

Tabel 3.1 geeft weer welke rollen deel uitmaken van IT-servicemanagement en kwaliteit. Er be-hoort een opleidingsplan te worden ontwikkeld voor elk van deze rollen, om aan te geven welke kennis en competenties nodig zijn. Dit zijn echter generieke rollen, die geen beschrijvingen zijn van daadwerkelijke functies of professionele profi elen. Verschillende van deze rollen kunnen sa-men één functie vormen.

IT-servicemanagement-rol Korte beschrijving

IT-manager Is verantwoordelijk voor (een gedeelte) van de IT-organisatie. Is vaak ook de eigenaar van een of meer ITSM-processen.

IT-servicemanager/ professional Implementeert, verbetert en onderhoudt de IT-servicelevering en de onderliggende processen in een IT-organisatie. In deze rol wordt ook vaak de taak van procesmanager vastgelegd.

IT serviceconsultant Adviseert een IT-organisatie over het introduceren, verbeteren en onderhouden van IT-services en de onderliggende processen.

ITSM-operator Voert een of meerdere activiteiten uit binnen een proces.

Systeemadministrator Installeert en onderhoudt een of meerdere onderdelen van de IT-infrastructuur.

Projectmanager Managet ITSM (kwaliteitsverbetering) of infrastructuurprojecten.



IT-servicemanagement-rol Korte beschrijving

Kwaliteitsmanager Is verantwoordelijk voor het kwaliteitsmanagementsysteem van de IT-organisatie.

Consultant servicekwaliteitsmanagement Adviseert een IT-organisatie over het introduceren, verbeteren en onderhouden van een kwaliteitsmanagementsysteem.

Externe auditor Beoordeelt het kwaliteitsmanagementsysteem van een IT-serviceprovider op ISO 20000, voor externe certifi cering.

Interne auditor Beoordeelt het kwaliteitsmanagementsysteem van een IT-serviceprovider op ISO 20000 om kansen tot verbeteringen in kaart te brengen.

Tabel 3.1 Overzicht van de rollen van IT-servicemanagement en servicekwaliteitsmanagement

Voordelen van het kwalifi catieschemaEen onafhankelijk certifi caat vormt een betrouwbaar bewijs dat u de cursus succesvol heeft afge-rond. Het toont uw inzet om uw competenties te verbeteren en van grotere waarde zijn voor uw organisatie en klanten.

Gecertifi ceerd worden helpt deelnemers bij:• verbetering van vaardigheden en prestaties • actualisatie van ISO 20000-kennis• verhoging van de waarde voor de werkgever• kwalifi catie voor banen waarvoor gespecialiseerde ISO 20000-kennis is vereist• verkrijgen van erkenning in het bedrijfsleven en van gelijkgestemden• behoud van de concurrentiepositie en creëren van nieuwe kansen op de arbeidsmarkt

Gecertifi ceerd worden levert ook voordelen op voor de business, zoals:• een beter gebruik van human resources• bewezen kwaliteit van het IT-personeel• mogelijkheid om te onderscheiden wie er bekwaam is voor functies die te maken hebben met

ISO 20000• bezit van specifi eke kennis en vaardigheden die nodig zijn om IT-werkzaamheden met succes

uit te voeren• stimulansen, beloningen en uitdagingen voor werknemers

Het ISO 20000-kwalifi catieschema helpt organisaties om de trainingsbehoeften van IT-service-managementpersoneel in kaart te brengen. Een organisatie die besluit het ISO 20000-framework te gaan gebruiken voor het verbeteren van IT-services moet beseffen dat een groot gedeelte van het personeel op de een of de andere manier daarbij betrokken zal zijn. De meesten van hen hoeven geen expert te zijn, maar enige kennis van de gangbare terminologie en kernprincipes van servicekwaliteitsmanagement is van essentieel belang.

Training in de grondbeginselen van ISO 20000 geeft de deelnemers een overzicht van ISO 20000 en de belangrijkste kwaliteitsmanagementprocessen die hierbij zijn betrokken. Het geeft ook een zekere voorbereiding op veranderingen in attitude, cultuur en procedures die nodig zijn om de focus van de klant en de IT-serviceverlening te verbeteren. Het ISO 20000 Foundations certifi -caat is zowel een beloning voor de deelnemers als een manier om de vooruitgang van de kennis



en het bewustzijn van ISO 20000 in de organisatie te meten. Het ISO 20000-kwalifi catieschema helpt ook bij het evalueren van leveranciers van cursussen en cursusmateriaal.

Om de bedrijfsplannen voor het verbeteren van de kwaliteit van IT-services te ontwikkelen en te implementeren, kunt u gebruikmaken van deskundigen met een bewezen staat van dienst op dit gebied. De belangrijkste kwalifi catie van een dergelijke deskundige is een passende certifi cering in IT-servicemanagement, dit vormt tenslotte de basis voor servicekwaliteitsmanagement.

Geaccrediteerde cursusleveranciersEr zijn enkele factoren die invloed kunnen hebben op de kwaliteit van een ISO 20000-cursus:• de kwaliteit van de docenten• de cursusplanning• de geschiktheid van de locatie• consistentie van het cursusmateriaal met ISO 20000 • de ervaring van de deelnemers• het gebruik van praktijkgerichte voorbeelden• de opdrachten• de mogelijkheden voor groepsdiscussies

Exameninstituten werken nauw samen met de geaccrediteerde trainingsorganisaties, om de kwa-liteit van de training te monitoren, en om waar nodig verbeteringen te implementeren.

Het is vaak nodig om een training te volgen bij een geaccrediteerd instituut om een kwalifi catie te krijgen die wereldwijd wordt erkend.

De accreditatieregels borgen:• de kwaliteit van alle ISO 20000-trainingsinstituten• de kennis, het begrip en de ervaring van de docenten op het gebied van IT-servicemanage-

ment, kwaliteit en educatie• de kwaliteit van het cursusmateriaal• de overeenstemming tussen de inhoud van de cursus en de eisen van de examinators van het

kwalifi catieschema van servicekwaliteitsmanagement

De exameninstituten hebben de eisen voor geaccrediteerde cursusleveranciers op hun website staan.

Een exameninstituut geeft zelf geen cursussen in servicekwaliteitmanagement en opereert on-afhankelijk van de commerciële belangen van de opleidingsinstituten. Dit zorgt ervoor dat de onpartijdigheid van het exameninstituut bij de accreditatie van cursusleveranciers en bij de exa-minering is verzekerd.

Kwalifi catieschemaAls een organisatie ISO 20000-gecertifi ceerd wil worden, dan zal al het personeel dat betrokken is bij IT-servicekwaliteitmanagement op de hoogte moeten zijn van de specifi eke eisen van zowel deel 1 als deel 2 van de norm, evenals van andere algemene onderwerpen van kwaliteitsmanage-ment.



Tot 2007 was het voor individuen alleen mogelijk om ISO 20000-certifi caten te behalen bij itSMF-UK , dat twee ISO 20000-examens biedt:• ISO/IEC 20000 Auditor• ISO/IEC 20000 Consultant

In 2007 werden een andere optie geboden door het International Register of Certifi cated Auditors (IRCA) , een internationaal certifi ceringsinstituut voor auditors van managementsy-stemen. Het IRCA houdt een Information Technology Service Management Systems Auditor examen (ITSMS), dat gebaseerd is op ISO 20000 en ISO 19011, en verschillende niveaus kent:• ITSMS Provisional Internal Auditor• ITSMS Internal Auditor• ITSMS Provisional Auditor• ITSMS Auditor• ITSMS Lead Auditor• ITSMS Principal Auditor

Daarnaast hebben itSMF Frankrijk en AFAQ AFNOR Certifi cation hun krachten gebundeld voor de ontwikkeling van een ISO/IEC 20000-1 lead auditor certifi ceringsprogramma: ICA® IT Service Management Lead Auditor (ISO/IEC 20000-1). Het is ISO 17024 geaccrediteerd door COFRAC en ICA levert dit certifi ceringsprogramma (dat ook voldoet aan de internatio-nale ISO-standaard ISO 17021) om erop toe te zien dat gecertifi ceerde auditors mensen zijn die ervaring hebben met ITSM, ISO/IEC 20000-1 en auditing methodologie.

EXIN and TÜV SÜD ontwikkelden in 2007 het kwalifi catie- en trainingsprogramma ‘ISO/IEC 20000 Qualifi cation Scheme for Personnel’. Dit programma werd ontwikkeld volgens de ISO-accreditatienormen (ISO 17024), zodat het zou worden erkend door het International Ac-creditation Forum (IAF). Het EXIN/TÜV SÜD kwalifi catie- en trainingsprogramma biedt een aantal certifi ceringen die zijn toegepast op de onderstaande ITSM-rollen :• ISO/IEC 20000 Foundation • ISO/IEC 20000 Professional (5 mogelijke certifi caten)• ISO/IEC 20000 IT Service Consultant/Manager • ISO/IEC 20000 Internal Auditor • ISO/IEC 20000 Lead Auditor

Zie ook het kwalifi catieschema in fi guur 3.1. De huidige individuele certifi cering biedt een inter-nationaal erkend kwalifi catieschema in kennis van en inzicht in IT-servicekwaliteitsmanagement.

Het belangrijkste verschil met de andere certifi ceringsopties is de structuur: EXIN/TÜV SÜD biedt bouwstenen voor een certifi ceringstraject. Deze bouwstenen zijn bedoeld om de compe-tentie voor een bepaalde rol aan te tonen. Op deze manier kan de ISO 20000 Foundation als bouwsteen worden gebruikt in verschillende certifi ceringstrajecten.



Zo kan bijvoorbeeld een auditor of een consultant die net begonnen is met een ISO 20000-traject het ISO 20000 Foundation examen en de examens voor een bepaald professioneel niveau behalen, en kennis opdoen van alle processen. Dit houdt in dat drie van de vijf modules moeten worden behaald, met Management & Improvement of ITSM Processes als verplichte module. Na het behalen van het professionele niveau moet de auditor doorgaan met de Auditing Track om meer gedetailleerde auditvaardigheden te verwerven. De consultant volgt daarentegen de Management Track om meer gedetailleerde kennis over de methoden en valkuilen van ISO 20000-implementaties te verwerven.

Tabel 3.2 geeft aan wat de meest geschikte certifi cering is voor elk van de rollen in ITSM en kwaliteit.

IT-servicemanagement volgens ISO/IEC 20000Basiskwalificatieschema voor personeelOverzicht van de beschikbare certificaten

MANAGEMENT TRACK AUDITING TRACK

PROFESSIONAL NIVEAU

FOUNDATION NIVEAU

Foundation

DO

OR

STR

OO

M

IT ServiceConsultant/Manager

Management &verbetering vanITSM-processen

Control vanIT-services

Support vanIT-services

Delivery vanIT-services

Alignment vanIT en Business

Senior IT ServiceConsultant/Manager Internal Auditor Lead Auditor

DO

OR

STR

OO

M

Figure 3.1 EXIN/TÜV SÜD ISO 20000 kwalifi catieschema voor personeel



EXIN/TÜ

V S

ÜD

ISO

/IEC 20000 Foundation

EXIN/TÜ

V S

ÜD

ISO

/IEC 20000 Professional

EXIN/TÜ

V S

ÜD

ISO

/IEC 20000 (S

enior) IT-serviceconsultant/ m

anager

EXIN/TÜ

V S

ÜD

ISO

/IEC 20000 Internal A

uditor

EXIN/TÜ

V S

ÜD

ISO

/IEC 20000 Lead A

uditor

itSM

F ISO

/IEC 20000 Auditor

itSM

F ISO

/IEC 20000 Consultant

IRC

A ITS

M System

s Auditor

meerdere gradaties

ICA

IT Service M

anagement

Lead Aauditor (IS

O/IEC 20000-1)

IT-servicemanagement-rol

IT-manager √

IT-servicemanager/ professional √ √ √

IT-serviceconsultant √ √ √

ITSM-operator √ √

Systeemadministrator √

Projectmanager √

Servicekwaliteitsmanagement-rol

Kwaliteitsmanager √ √ √ √ √

Servicekwaliteitsmanagement-consultant

√ √ √ √

Externe auditor √ √ √ √ √ √ √

Interne auditor √ √ √ √ √ √

Tabel 3.2 ITSM- en kwaliteitsrollen in relatie tot ISO 20000-certifi cering

ISEB kondigde in november 2007 aan dat het in gesprek zou gaan met itSMF-UK om mee te doen met hun kwalifi catieschema, en ook een examen op Foundationniveau toe te voegen aan het schema. Zie de bronvermelding achterin dit boek voor verwijzingen naar de verschillende organisaties die certifi ceringen bieden.

3.3 Inzicht in het ISO 20000-conceptISO 20000 is een internationale norm voor het leveren van gemanagede IT-services van een kwaliteit die acceptabel is voor de klant.

3.3.1 De geschiedenis en de eigenaar van ISO 20000De ISO 20000-norm werd voor het eerst gepubliceerd in 2005 door de International Organi-zation for Standardization. Op die datum werd de British Standard 15000 (BS 15000) naar een internationale standaard verheven.

De oorsprong van BS 15000 ligt in DISC PD 0005 , de Code of Practice voor IT-servicemanage-ment. DISC PD 0005 is aan het eind van de jaren negentig opgezet voor de British Standard



Institution (BSI) , door een werkgroep van Britse experts. Het is ontwikkeld om de leemte te vullen die ITIL open liet. De eerste ITIL boeken (ITIL versie 1) misten concrete handvatten over hoe IT-servicemanagementprocessen in de praktijk moesten worden ontwikkeld. DISC PD 0005 bood duidelijke eisen en aanbevelingen.

Hoewel ITIL het uitgangspunt was, zorgde de ontwikkeling van dit framework ervoor dat er aanvullende processen werden opgenomen. Dit hielp bij de verduidelijking van de relaties tussen de verschillende processen. Figuur 3.2 toont de servicelevering- en supportprocessen van ITIL op een andere manier. Het geeft de nieuwe procesclusters weer, waaronder de relatiemanagement-processen en het servicerapportageproces. Deze clusters zijn nu opgenomen in ITIL V3. Het clustermodel werd niet veranderd toen de BS 15000-norm evolueerde naar de ISO 20000-norm, hoewel de namen van de processen werden aangepast. Het model bevat geen processen voor IT-infrasctructuurmanagement en applicatiemanagement.

BS 15000 werd in november 2000 door itSMF-UK geïntroduceerd. Deze Britse standaard voeg-de eisen voor een kwaliteitsmanagementsysteem toe, evenals de eisen voor de kwaliteit van de verschillende processen. Binnen een paar jaar ontving itSMF, die ook als het verantwoordelijke certifi ceringsinstituut fungeerde, veel verzoeken van organisaties die zich wilden laten certifi ce-ren. De internationale interesse bleef groeien, wat uiteindelijk leidde tot de erkenning van een internationale standaard.

Internationale standaarden worden ten minste iedere vijf jaar gereviewd door de verantwoorde-lijke commissies van de ISO-organisatie. De commissie besluit of de standaard wordt goedge-keurd, aangepast of ingetrokken. Voor ISO 20000 zijn er twee aanvullende delen in ontwikkeling (2007): ISO 20000-3: Guidance on compliance with ISO/IEC 20000-1 (afbakening en toepas-selijkheid) en ISO 20000-4: Service Management Process Reference Model.

SERVICELEVERINGSPROCESSEN

CONTROLPROCESSEN

RELEASEPROCES

ConfiguratiemanagementChangemanagement

Releasemanagement

Capaciteitsmanagement

Servicecontinuïteits- enbeschikbaarheidsmanagement

OPLOSSINGSPROCESSEN

Incidentmanagement

Problemmanagement

Servicelevelmanagement

Servicerapportage

RELATIEMANAGEMENT-PROCESSEN

Klantrelatiemanagement

Leveranciersmanagement

Informatiesecuritymanagement

Budgettering enaccounting voor

IT-services

Figuur 3.2 IT-servicemanagement volgens DISC PD 0005 en ISO 20000



ISO 9000 en ITIL in ISO 20000ITIL is niet de enige voorganger van ISO 20000. De IT-servicemanagementstandaard bevat ook elementen van ISO 9000 , de internationale standaard voor kwaliteitsmanagement. ISO 9000 beschrijft alleen algemene processen voor het management van de organisatie, voor het manage-ment van de resources, voor de realisatie van het product of de service en voor metingen, analyses en verbetering. Zoals genoemd in sectie 2.1.3 over procesaanpak, zijn de ITIL-servicemanage-mentprocessen de realisatieprocessen van ISO 9000 voor de IT-serviceorganisatie.

Tabel 3.3 geeft een samenvatting van alle processen van ISO 9000, ISO 20000 en ITIL V2 en V3. De processen in een rij van de tabel lijken erg op elkaar en er is sprake van overlap. In ISO 9000 ontbreken de productrealisatieprocessen. Deze leemte wordt opgevuld door de ITIL-servicemanagementprocessen en de ISO 20000-eisen.

ITIL: heden, verleden en toekomstDe Information Technology Infrastructure Library (ITIL) biedt een algemeen framework voor alle activiteiten van een IT-afdeling, met als doel de volwassenheid van de levering, ondersteu-ning en beheersing van IT-services te verbeteren. ITIL werd in de jaren tachtig ontwikkeld door de British Government’s Central Computer and Telecommunications Agency (CCTA, nu het Offi ce of Government Commerce, OGC). De escalerende IT-kosten motiveerden de Britse oveheid om een aanpak te ontwikkelen voor een effi ciënter en beter gebruik van IT-resources.

De IT Infrastructure Library begon als een reeks boeken, waarbij elk boek een specifi eke practice van IT-servicemanagement behandelde. Na de eerste publicatie groeide het aantal boeken snel uit tot een reeks van 48 delen. Het werd vervolgens door veel organisaties gebruikt, ook in de particuliere sector.

De inhoud van de library werd vanaf 1999 voortdurend aangepast om aan te sluiten op mo-derne practices, gedistribueerde verwerking en het internet. Het resultaat was ITIL V2 (2000), dat als doel had om ITIL toegankelijker en betaalbaarder te maken. ITIL V2 hield ook in dat de oorspronkelijke reeks boeken werd samengevoegd tot logische ‘sets’ waarin richtlijnen voor gerelateerde processen werden gegroepeerd in de verschillende aspecten van IT-management, applicaties en services.

De ITIL V2 boeken en de bijbehorende disciplines zijn:• Service Support• Service Delivery• ICT Infrastructure Management• Planning to Implement Service Management• Application Management• Business Perspective• Security Management• Software Asset Management

OGC gaf in december 2005 aan bezig te zijn een ‘ITIL Refresh’, algemeen bekend als ITIL versie 3 (V3). Dit project werd afgerond op 30 mei 2007 met de publicatie van vijf nieuwe kernboe-ken en een online verklarende woordenlijst. ITIL V3 beschrijft IT-servicemanagement als een



ITIL

ver

sie

3IT

IL v

ersi

e 2

ISO

200

00IS

O 9

000

Eise

n vo

or e

en

man

agem

ents

yste

emPr

oces

sen

voor

or

gani

sati

eman

agem

ent

Proc

esse

n vo

or m

etin

gen,

ana

lyse

en

ver

bete

ring

Man

agem

entv

eran

twoo

rdel

ijk-

heid

, doc

umen

tati

e-ei

sen,

co

mpe

tent

ie, b

ewus

twor

ding

en

trai

ning

Stra

tegi

sche

pla

nnin

g, b

epal

en

van

rich

tlijn

en, b

epal

en v

an

doel

stel

linge

n, c

omm

unic

eren

, bo

rgen

van

bes

chik

baar

heid

va

n be

nodi

gde

reso

urce

s en

m

anag

emen

t rev

iew

s (P

lan

en D

o-fa

sen

van

PDC

A)

Proc

esse

n di

e no

dig

zijn

om

te

met

en e

n ge

geve

ns te

ver

zam

elen

vo

or p

erfo

rman

ce-a

naly

se e

n de

eff

ecti

vite

it e

n ef

fi cië

ntie

te

verb

eter

en. D

eze

omva

tten

mee

t-,

mon

itor

ing-

en

audi

ting

proc

esse

n,

corr

ecti

eve

en p

reve

ntie

ve a

ctie

s en

zi

jn e

en in

tegr

aal o

nder

deel

van

het

m

anag

emen

t, re

sour

cem

anag

emen

t en

real

isat

iepr

oces

sen

(Con

trol

e-en

aa

npas

sing

sfas

en v

an P

DC

A)

Proc

esse

n vo

or m

anag

emen

t van

re

sour

ces

Leve

ren

van

de

beno

digd

e re

sour

ces

voor

or

gani

sati

eman

agem

ent-

, re

alis

atie

- en

mee

tpro

cess

enCo

ntin

ue

serv

icev

erbe

teri

ngP

lann

ing

voor

impl

emen

tati

e se

rvic

eman

agem

ent

Ser

vice

man

agem

ent p

lann

en e

n im

plem

ente

ren

Serv

icem

anag

emen

t pla

nnen

(P

lan)

Serv

icem

anag

emen

t im

plem

ente

ren

en s

ervi

ces

leve

ren

(Do)

CSI-

verb

eter

ings

proc

esM

onit

oren

, met

en e

n re

view

en

(Che

ck)

Cont

inue

ver

bete

ring

(Act

)

Ser

vice

stra

tegi

eN

ieuw

e of

aan

gepa

ste

chan

ges

plan

nen

en im

plem

ente

ren

Prod

uctr

eali

sati

e pl

anne

n

Serv

icep

ortf

olio

-m

anag

emen

t



ITIL

ver

sie

3IT

IL v

ersi

e 2

ISO

200

00IS

O 9

000

Ser

vice

-ont

wer

p S

ervi

cepr

oduc

tie

De

busi

ness

pers

pect

ief-

seri

eR

elat

iem

anag

emen

tpro

cess

enK

lant

gere

late

erde

pro

cess

en

(+ V

1 kl

antv

erbi

ndin

gen)

klan

trel

atie

man

agem

ent

Leve

ranc

iers

man

agem

ent

(v1

man

agen

van

faci

litei

ten

en

rela

ties

met

der

den)

Leve

ranc

iers

man

agem

ent

Serv

iced

esk

(eer

ste

over

lap)

Ser

vice

man

agem

ent

Rea

lisa

tiep

roce

ssen

Alle

pro

cess

en d

ie d

e be

doel

de

outp

ut v

an d

e or

gani

sati

e le

vere

nS

ervi

cest

rate

gie,

ser

vice

-on

twer

p en

con

tinu

e se

rvic

ever

bete

ring

Ser

vice

leve

ring

Ser

vice

leve

ring

spro

cess

en

Serv

icel

evel

man

agem

ent

Serv

icel

evel

man

agem

ent

Serv

icel

evel

man

agem

ent

Serv

icer

appo

rtag

eSe

rvic

erap

port

age

(nie

t ee

n au

tono

om p

roce

s,

maa

r ond

erde

el v

an

serv

icel

evel

man

agem

ent)

Serv

icer

appo

rtag

e

Serv

icec

atal

ogus

-m

anag

emen

tFi

nanc

ieel

man

agem

ent

Fina

ncie

el m

anag

emen

t van

IT-

serv

ices

Bud

gett

eren

en

vera

ntw

oord

en

van

IT-s

ervi

ces

IT-s

ervi

ceco

ntin

uite

its-

man

agem

ent

IT-

serv

icec

onti

nuït

eits

man

agem

ent

Serv

icec

onti

nuït

eit-

en

besc

hikb

aarh

eids

man

agem

ent

Bes

chik

baar

heid

s-m

anag

emen

tB

esch

ikba

arhe

idsm

anag

emen

t

Capa

cite

itsm

anag

emen

tCa

paci

teit

sman

agem

ent

Capa

cite

itsm

anag

emen

t

Dem

andm

anag

emen

tD

eman

dman

agem

ent (

niet

ee

n au

tono

om p

roce

s,

maa

r ond

erde

el v

an

capa

cite

itsm

anag

emen

t)In

form

atie

secu

rity

-m

anag

emen

tSe

curi

tym

anag

emen

tIn

form

atie

secu

rity

man

agem

ent



ITIL

ver

sie

3IT

IL v

ersi

e 2

ISO

200

00IS

O 9

000

Ser

vice

supp

ort

Ser

vice

prod

ucti

eO

plos

sing

spro

cess

enIn

cide

ntm

anag

emen

tIn

cide

ntm

anag

emen

tIn

cide

ntm

anag

emen

t

Requ

est f

ulfi l

lmen

t

Serv

iced

esk

(tw

eede

ov

erla

p)Se

rvic

edes

k

Prob

lem

man

agem

ent

Prob

lem

man

agem

ent

Prob

lem

man

agem

ent

Ser

vice

tran

siti

e,

Ser

vice

prod

ucti

eB

ehee

rsin

gspr

oces

sen

Serv

icea

sset

en

confi

gur

atie

man

agem

ent

Confi

gur

atie

man

agem

ent

Confi

gur

atie

man

agem

ent

Chan

gem

anag

emen

tCh

ange

man

agem

ent

Chan

gem

anag

emen

tTr

ansi

tiep

lann

ing

en –

supp

ort (

eers

te o

verl

ap)

Serv

icev

alid

atie

en

test

enEv

alua

tie

Serv

iced

esk

(der

de

over

lap)

Serv

iced

esk

Ser

vice

tran

siti

eR

elea

sepr

oces

sen

Rele

ase-

en

depl

oym

entm

anag

emen

tRe

leas

eman

agem

ent

Rele

asem

anag

emen

t

Plan

nen

en s

uppo

rt v

an

tran

siti

e(t

wee

de o

verl

ap)

Bui

ten

de s

cope

van

ISO

20

000

Bui

ten

de s

cope

van

ISO

200

00

Acce

ssm

anag

emen

tEv

entm

anag

emen

tIT

-ope

rati

ons

Kenn

ism

anag

emen

tM

onit

orin

g en

con

trol

ICT-

infr

astr

uctu

urm

anag

emen

tAp

plic

atie

man

agem

ent

Figu

ur 3

.3

Proc

esse

n in

ITIL

ver

sie

2 en

3, I

SO 2

0000

en

ISO

900

0



doorlopende cyclus van het ontwerp, overdracht en uitvoering van services. Echter, voordat een service wordt ontworpen moet de IT-servicestrategie worden bepaald. Tijdens de cyclus moeten processen voortdurend worden verbeterd. Dit resulteert in de volgende vijf fasen (zie ook fi guur 3.3):1. Servicestrategie (Service Strategy) legt uit hoe servicemanagement moet worden ontworpen,

ontwikkeld en geïmplementeerd als een capability van de organisatie en als een strategische asset.

2. Service-ontwerp (Service Design) gaat over het ontwerpen en ontwikkelen van services en servicemanagementprocessen.

3. Servicetransitie (Service Transition) gaat over het managen van changes, risico’s en kwaliteits-borging en het implementeren van serviceontwerpen, zodat serviceproductie de services en de infrastructuur kan beheersen.

4. Serviceproductie (Service Operation) geeft richtlijnen voor het bereiken van effectiviteit en effi ciëntie, terwijl de services in productie zijn.

5. Continue serviceverbetering (Continual Service Improvement) controleert de kwaliteit van de services en verbetert deze door beter ontwerp, introductie en uitvoering van services.

De servicelevenscyclusfasen van ITIL V3 kunnen op de fasen van de PDCA-cyclus heen worden gelegd. De servicestrategiefase en service-ontwerpfase komen overeen met de plan-fase uit de PDCA-cyclus. De servicetransitiefase en serviceproductiefase komen overeen met de do-fase, In de fase van continue serviceverbetering wordt de procesperformance gemonitord en gerappor-teerd en dit komt overeen met Deming’s check- en act-fase.Natuurlijk behoort elke levenscyclus zichzelf continu te verbeteren.

Hoewel ISO 20000 geen formele binding heeft met ITIL (er zijn geen controlebepalingen over en weer gedefi nieerd of geïmpliceerd), is het wel in overeenstemming gebracht met de ITIL V2 boeken. Dit betekent dat de veranderingen van inhoud, scope en terminologie van ITIL V3 nog niet zijn opgenomen in ISO 20000. Echter, bij de ontwikkeling van ITIL V3 werd ISO 20000 in het achterhoofd gehouden. Er zijn nog steeds verschillen tussen ITIL V3 en ISO 20000, maar de frameworks hebben nooit eerder zo op een lijn gezeten.

Continue serviceverbetering

servicetransitie

Serviceproductie

Servicestrategie

ITIL V3

Serv

ice-ontwerp

Figuur 3.3 Het ITIL® V3 levenscyclusmodel



Om een voorbeeld te geven: ISO 20000 behandelt service requests als incidents, wat ook ge-beurt in ITIL V2. ITIL V3 maakt formeel onderscheid tussen incidentmanagement, request fulfi llment en eventmanagement. Naar verwachting wordt deze best practice van ITIL V3 bij de volgende update van ISO 20000 meegenomen. Dit kan enige tijd duren, omdat ISO-normen een rigoureus changeproces moeten doorlopen, om een kwaliteitsproduct te kunnen garanderen. Het is daarom niet aan te raden op de volgende versie van de standaard te wachten, ook omdat met de huidige norm genoeg voordelen kunnen worden behaald. Bovendien zal een auditor ITIL V3-practice waarschijnlijk beschouwen als ondersteuning van de ontwikkeling naar ISO 20000. De standaard geeft namelijk aan dat de serviceprovider elk van de bestaande servicemanagement-frameworks kan gebruiken.

ISO 9000De International Organization for Standardization (ISO) bestaat sinds 1947. De eerste ISO-normen waren technische productienormen voor onderdelen als bouten, moeren, schroeven en pinnen. De eerste versie van ISO 9000, de ISO-norm voor kwaliteitsmanagementsystemen, werd gepubliceerd in 1987.

ISO 9000 is een standaard voor een generiek managementsysteem. Zo’n standaard stelt eisen aan alle bedrijven, ongeacht het type activiteiten dat wordt uitgevoerd, de grootte van het bedrijf of de complexiteit van de bedrijfsprocessen. De organisatie die een generiek managementsysteem implementeert kan variëren van een pretpark tot een serviceprovider en van een overheidsorgaan tot een kleine zelfstandige.

De huidige versie van de ISO 9000-standaard werd gepubliceerd in 2000. De eerdere versie dateert uit 1994 en had de reputatie een papieren tijger te zijn. ISO 9000:1994 bestond uit een groot aantal documenten met eisen. Dit was voor veel organisaties een reden om veel papierwerk te genereren om er zo zeker van te zijn aan de eisen van ISO 9000:1994 te voldoen.

Met de komst van ISO 9001:2000 is dit veranderd. ISO 9001:2000 legt de focus op perfor-mance , continue verbetering en klanttevredenheid . De hoeveelheid documentatie kan worden beperkt, afhankelijk van de organisatie, de complexiteit van de processen en competentieniveaus van de medewerkers. Zoals wordt gesteld in de documentatierichtlijnen op de website van het ISO (www.iso.org), behoeft ISO 9001:2000 een gedocumenteerd kwaliteitsmanagementsysteem en geen systeem van documenten (ISO, 2001).

De ISO 9000 -familie bestaat uit ISO 9000, ISO 9001:2000 en ISO 9004 . ISO 9000 bevat de kerngegevens en de vocabulaire voor kwaliteitsmanagementsystemen. ISO 9001 geeft de eisen voor een kwaliteitsmanagementsysteem. ISO 9004 geeft richtlijnen voor de verbetering van per-formance.

3.3.2 De bedoeling en de voordelen van ISO 20000ISO 20000 wil, net als BS 15000 daarvoor, een gemeenschappelijk standaard-referentiekader bieden voor elke organisatie die IT-services aanbiedt aan interne of externe klanten. Omdat communicatie erg belangrijk is in servicemanagement, is één van de belangrijkste doelen van de standaard het creëren van gemeenschappelijke terminologie voor serviceproviders, hun toeleve-ranciers en hun klanten.



De standaard bevordert het gebruik van een geïntegreerde procesaanpak voor het management van IT-services (zie sectie 3.3.4). Het behandelt alle wat noodzakelijk is voor goed servicema-nagement - zaken die algemeen gelden en vereist zijn voor elke servicemanagementprovider. Directe, plaatselijke eisen worden echter niet gesteld.

De specifi catie in ISO 20000-1 stelt:

ISO20000-1:2005 defi nieert de voorwaarden waaraan een serviceprovider moet voldoen om gemanagede services van een acceptabele kwaliteit aan zijn klanten te kunnen leveren.

Dit kan worden gebruikt:• door bedrijven die een offertetraject voor hun services gaan opstarten• door bedrijven die een consistente benadering eisen van alle serviceproviders in een

leveringsketen• door serviceproviders die hun IT-servicemanagement willen benchmarken• als basis voor een onafhankelijke beoordeling• door organisaties die moeten aantonen dat ze in staat zijn services te leveren die voldoen

aan de eisen van de klant• door organisaties die de service willen verbeteren door middel van een effectieve

toepassing van processen voor het monitoren en verbeteren van de servicekwaliteit.

3.3.3 Het verschil tussen ISO 20000-1 en ISO 20000-2De ISO 20000 standaard bestaat uit twee delen:• Deel 1: Specifi catie – gepubliceerd als ISO 2000-1:2005. Dit is de formele specifi catie van de

normen.• Deel 2: Code of practice – gepubliceerd als ISO 2000-2:2005. Dit beschrijft in detail de best

practices en geeft richtlijnen en aanbevelingen voor de servicemanagementprocessen in de scope van de formele normen.

Algemeen beschouwd bevat deel 1 van de standaard een lijst van verplichte controls (‘shalls’), dat-gene dat een serviceprovider moet doen. Deel 2 bestaat daarentegen uit een lijst van richtlijnen en suggesties van datgene dat behoort (‘shoulds’) te worden gedaan.

3.3.4 Het groeperen van de processenISO 20000 staat voor een geïntegreerde procesaanpak. Om een kwaliteitsmanagementsysteem te ontwikkelen moet een organisatie de bedoeling ervan vaststellen, de richtlijnen defi niëren, de processen bepalen en de volgorde van deze processen bepalen. Om een proces te plannen moet een organisatie de activiteiten binnen een proces defi niëren.

ISO 20000-1 vereist een aantal activiteiten. Er worden 170 punten genoemd die noodzakelijk zijn en 135 elementen die behoren te gebeuren. Er wordt ook gerefereerd aan processen en de procesinterfaces, maar de standaard blijft vaag als het gaat om de relaties tussen de processen. Een reden die de standaard hiervoor geeft is dat deze relaties afhankelijk zijn van de toepassing binnen een organisatie. Een andere reden is dat ze te complex zijn om in een model te vangen.



Subsectie 1 van ISO 20000-1 bevat een fi guur dat een aantal aan elkaar gerelateerde servicema-nagementprocessen laat zien(zie fi guur 3.2). Figuur 3.4 laat de andere drie typen processen van ISO 9000 zien, namelijk voor organisatiemanagement, management van resources en metingen, en analyses en verbeteringen van de ISO 20000-processen. Deze processen worden behandeld in subsectie 3.1 van ISO 20000 (management responsibility), subsectie 4 (planning and implemen-ting service management) en subsectie 5 (planning and implementing new or changed services). Subsectie 4 van ISO 20000-1 bevat ook de processen voor verbetering.

De specifi catie in ISO 20000-1 stelt:De relaties tussen de processen zijn afhankelijk van de toepassing binnen een organisatie en zijn over het algemeen te complex om in een model te vangen. Daarom zijn deze relaties niet weergegeven in het diagram (fi guur 3.2).

De lijst met doelstellingen and controls in ISO20000-1 is niet volledig. Een organisatie kan besluiten dat aanvullende doelen en controles nodig zijn voor hun specifi eke bedrijfsbehoeften. De aard van de businessrelatie tussen de serviceprovider en de business bepaalt hoe de vereisten in ISO 20000-1 worden geïmplementeerd om de algehele doelstelling the realiseren. ISO 20000 is een procesgerichte standaard en is niet bedoeld voor het beoordelen van producten. Toch kunnen ISO 20000 en de code of practice gebruikt worden door bedrijven die servicemanagementtools en -systemen ontwikkelen die servicemanagement best practices ondersteunen.

Plan

Check

Act

Planning en implementatie van nieuwe

of gewijzigde services

Managementverantwoordelijkheid Documentatievereisten

Competentie, bewustzijn en training

Managementsysteem

Serviceleveringsprocessen• Servicelevelmanagement• Servicerapportage• Capaciteitsmanagement

• Servicecontinuïteitsmanagement & beschikbaarheidsmanagement

• Informatiesecuritymanagement• Budgettering en accounting van IT-services

Releaseproces

• Releasemanagement Oplossingsprocessen• Incidentmanagement• Problemmanagement

Controlprocessen• Configuratiemanagement• Changemanagement

Relatiemanagement-processen

• Klantrelatiemanagement• Leveranciersmanagement

Planning en implementatie van service-management

Plan

Check

DoAct

Figure 3.4 IT-service kwaliteitsmanagementsysteem volgens ISO 20000



De code of practice in ISO 20000-2 stelt:

ISO 20000-2 representeert de consensus die in een bedrijfstak leeft over kwaliteitsnormen voor IT-servicemanagementprocessen. Deze servicemanagementprocessen leveren de best mogelijke service om te kunnen voldoen aan de bedrijfsbehoeften van de klant, binnen de afgesproken resources. Met andere woorden: een service die professioneel en kosteneffectief is, met inzicht in en management van de risico’s.

Het kan voor een nieuwe manager verwarrend zijn dat er veel verschillende termen voor hetzelfde proces worden gebruikt en voor processen en functiegroepen (en titels van functies en rollen). Ge-brek aan begrip van de terminologie kan de inrichting van effectieve processen verhinderen. Begrip van de terminologie is een tastbaar en aanmerkelijk voordeel van ISO 20000. ISO 20000-2 ad-viseert serviceproviders om een gemeenschappelijke terminologie en een meer consistente benadering van servicemanagement te gebruiken. Dit biedt een gemeenschappelijke basis voor verbetering van services. Het levert bovendien een framework dat gebruikt kan worden door toeleveranciers van IT-servicemanagementtools.

ISO 20000-2 biedt handvatten voor auditors en biedt ondersteuning aan serviceproviders die service-verbeteringen plannen of zich voorbereiden op een ISO 20000-1-audit.

Processen voor het managen van resources worden besproken in subsectie 3.3 van ISO 20000 en in de budgettering en accounting van processen in subsectie 6.4: “Er horen heldere richtlijnen en processen te zijn voor: a) budgettering en accounting van alle componenten, met inbegrip van IT-assets, gedeelde resources, overheads, extern geleverde service, mensen, verzekering en licenties.” Kortom, terwijl ISO 9000 de resourcingprocessen als één van de drie types van onder-steunende processen positioneert, formuleert ISO 20000 resourcingprocessen als onderdeel van het serviceleveringsproces.

3.3.5 Benodigde documentatie, processen, procedures en recordsMet betrekking tot documentatie , processen, procedures en records stelt sectie 3.2 van ISO 20000-1:

Serviceproviders moeten documenten en records kunnen leveren die een effectieve planning, uitvoering en beheersing van servicemanagement borgen. Deze moeten de volgende informatie bevatten:• gedocumenteerde servicemanagementrichtlijnen en -plannen • gedocumenteerde service level agreements • gedocumenteerde processen en procedures vereist door deze standaard • records vereist door deze standaard

Voor het bedenken, reviewen, goedkeuren, onderhouden, verwijderen en beheersen van de verschillende soorten documenten en records moeten procedures en verantwoordelijkheden worden vastgesteld NOOT: voor de documentatie kan elk mogelijk medium gebruikt worden.

Zoals in elke ISO/IEC-standaard zijn alle processen uit deel 1 verplicht. Alle processen moeten documenten en records hebben, inclusief een procesbeschrijving . Zonder de ondersteunende documenten is het niet mogelijk om te controleren of alle verplichte processen voldoen aan hun



beschrijving en te controleren op hun effectiviteit en effi ciëntie. Een organisatie mag aanvullende processen en procedures ontwerpen om aan de eisen van ISO 20000-1 te voldoen.

ISO geeft geen defi nitie van de term ‘procedure’, maar geeft wel aan dat er gedocumenteerde en bijgehouden procedures moeten zijn voor elk proces of reeks van processen (zie sectie 4.2 ‘implement Service Management and provide the services’). ITIL V3 geeft in de woordenlijst de volgende defi nitie van procedure:

Een procedure is een document waarin de stappen staan die aangeven hoe een activiteit moet worden uitgevoerd. Procedures worden gedefi nieerd als onderdelen van processen.

Bij het beschrijven van processen behoren de procedures ook te worden beschreven. Daarnaast zijn er enkele aanvullende procedures die te maken hebben met de scope van de standaard, maar die buiten de genoemde processen vallen, bijvoorbeeld een auditproces of -procedure. Tabel 3.4 geeft enkele expliciet genoemde processen en procedures, maar moet met het bovenstaande in het achterhoofd gelezen worden, wat betekent dat de lijst nooit uitputtend kan zijn.

(sub)sectie deel1 vereiste proces of procedure3.2 Documentatie-eisen Documentatieprocedures4.2 Servicemanagement implementeren

en de service leveren (Do)Gedocumenteerde en bijgehouden procedures voor elk proces of set van processen

4.3 Monitoren, meten en reviewen (Check) Voer audits uit4.4 Continue verbetering (Act) Verbeter servicemanagement6.1 Servicelevelmanagement Ondersteunende SLA-procedures6.4 Budgettering en accounting van IT-

servicesBugetteer en verantwoord alle componentenVerdeel indirecte kosten en wijs directe kosten toe aan servicesBeheers de fi nanciën en autoriseer effectief

6.5 Capaciteitsmanagement Monitor servicecapaciteitStem serviceperformance afLever adequate capaciteit

6.6 Informatiesecuritymanagement Onderzoek alle security-incidenten Neem managementactie

7.2 Klantrelatiemanagement KlachtenprocesKlanttevredenheidproces

7.3 Leveranciersmanagement Manage de leverancier:– houd een groot contractreview– handel contractuele geschillen af– handel de beëindiging van de service af

8.2 Incidentmanagement Manage de impact van incidentenDefi nieer de registratie, prioritering, bedrijfsimpact, classifi cering, actualisering, escalatie, oplossing en formele afsluiting van incidenten

8.3 Problemmanagement Bepaal, beperk of vermijd de impact van incidenten9.1 Confi guratiemanagement Borg het onderhoud van de integriteit van de systemen,

services en servicecomponentenRegistreer gebreken, initieer correctieve acties en rapporteer

9.2 Changemanagement Beheers de autorisatie en implementatie van emergency changes

10.1 Releasemanagement Actualiseren en wijzigen van confi guratie-informatie en changerecords

Tabel 3.4 Vereiste processen en procedures in ISO 20000-1



Serviceproviders behoren documentatie en records te leveren om de managementprocessen te ondersteunen, zoals:• richtlijnen en plannen• service level agreements (SLA’s)• procedures en processen• records vereist door ISO 20000

Bepaal procedures en verantwoordelijkheden voor de creatie, review, goedkeuring, onderhoud, verwijdering en control van documenten en records. De senior verantwoordelijke eigenaar be-hoort erop toe te zien dat bewijs beschikbaar is voor een audit van servicemanagementrichtlijnen, -plannen en -procedures. Er behoort een proces operationeel te zijn voor de ontwikkeling en het management van documenten.Bescherm documentatie tegen mogelijke schade.

Net als voor processen of procedures, worden er slechts enkele specifi ek vereiste documenten genoemd in ISO 20000. Dit betekent echter niet dat een organisatie die alleen de expliciet genoemde documenten op orde heeft automatisch gecertifi ceerd wordt voor de standaard. Zij behoren te kunnen bewijzen dat alle vereiste processen duidelijk zijn vastgesteld, terwijl zij daar-naast ook de benodigde documentatie moeten kunnen overleggen (dit hoeft niet per defi nitie op papier te zijn).

Tabel 3.5 beschrijft de plannen of richtlijnen of andere documenten die een organisatie nodig heeft voor planning, productie en beheersing.

(sub)sectie deel1 Vereiste documenten

4.1 Plan servicemanagement (Plan) Managementrichting en gedocumenteerde verantwoordelijkheden

4.2 Implementeer servicemanagement en lever de services (Do)

Richtlijnen, plannen, procedures en defi nities voor elk proces of set van processen

4.3 Monitor, meet en review (Check) Doelstellingen van reviews, assessments en audits

4.4 Continue verbetering (Act) Serviceverbeteringsbeleid

6.1 Servicelevelmanagement Service level agreements samen met ondersteunende service agreements, leverancierscontracten

6.3 Servicecontinuiteit en beschikbaarheidsmanagement

Beschikbaarheids- en servicecontinuiteitsplannen

6.5 Capaciteitsmanagement Capaciteitsplan

6.6 Informatiesecuritymanagemenent InformatiesecuritybeleidSecuritycontroles

7.2 Klantrelatiemanagement Service voor stakeholders en klantenNotulen van vergaderingen

7.3 Leveranciersmanagement LeveranciersmanagementprocesServicelevel agreement metleverancierProcesinterfacesRollen en relaties tussen hoofd- en subleveranciers

9.1 Confi guratiemanagement Beleid voor de defi nitievan confi guratie-items

9.2 Changemanagement Scope van changes aan service en infrastructuur

10.1 Releasemanagement Releasebeleid

Tabel 3.5 Documenten vereist door ISO 20000-1



Een specifi ek type bewijs dat wordt vereist zijn records . Records zijn documenten waarin de be-haalde resultaten of het bewijs van activiteiten (zie ook sectie 3.2.8, terminologie) is weergegeven.

Tabel 3.6 beschrijft de records die expliciet vereist zijn voor ISO 20000-1. Nogmaals, dit bete-kent niet dat het in orde hebben van alle records uit de lijst automatisch tot certifi cering leidt.

(sub)sectie deel1 Vereiste records

4.3 Monitoren, meten en reviewen (Check) Review-, assessment- en auditrecordsVastgestelde herstelacties

4.4 Continue verbetering (Act) Voorgestelde serviceverbeteringen

6.1 Servicelevelmanagement Service-, target- en werklastkenmerkenRecords van vastgestelde verbeteracties

6.3 Servicecontinuiteit- en beschikbaarheids-managementprocessen

BeschikbaarheidsrecordsTestrecords van servicecontinuïteitsplannen

6.4 Budgeting en accounting for services Financiële records van budgetten en beramingen

6.6 Informatiesecuritymanagemenent Security-incidentrecordsVerbeteracties

7.2 Klantrelatiemanagement Records van serviceklachtenVerbeteracties

7.3 Leveranciersmanagement Verbeteracties

8.2 Incidentmanagement Incidentrecords

8.3 Problemmanagement ProblemrecordsVerbeteracties

9.1 Confi guratiemanagement Confi guratierecordsRelaties en documentatie die nodig zijn voor effectief servicemanagementGebreken

9.2 Changemanagement Requests for changeChange(analyse)recordsVerbeteracties

10.1 Releasemanagement Releasedata en –deliverables, gelinkt met gerelateerde change requests, known errors en problems

Tabel 3.6 Records vereist door ISO 20000-1

Het is belangrijk om te beseffen dat ISO 20000 geen verzameling is van processen, procedures, documenten en records, maar een geïntegreerd managementsysteem, met de daaraan gerelateerde documentatie.

3.3.6 Bedoeling van de verschillende onderdelen van de standaardElk onderdeel van de standaard heeft een doelstelling in de specifi catie van de standaard. Deze doelstellingen zijn:• Sectie 3: eisen voor een managementsysteem – leveren van een managementsysteem, in-

clusief richtlijnen en een framework voor het effectief managen en implementeren van alle IT-services

• Sectie 4.1: plannen van servicemanagement (Plan) – plannen van de implementatie en levering van servicemanagement

• Sectie 4.2: implementeren van servicemanagement en leveren van de services (Do) – im-plementeren van servicemanagementdoelstellingen en -plannen.



• Sectie 4.3: monitoren, meten en reviewen (Check) – monitoren, meten en reviewen met oog op de realisatie van de servicemanagementdoelstellingen

• Sectie 4.4: continue verbetering (Act) – verbeteren van de effectiviteit en de effi ciëntie van servicelevering en management.

• Sectie 5: plannen en implementeren van nieuwe of aangepaste services – borgen dat nieu-we services en aanpassingen van services leverbaar en managebaar zijn tegen de overeengeko-men kosten en servicekwaliteit.

• Sectie 6.1: servicelevelmanagement – defi niëren, overeenkomen, registreren en managen van servicelevels.

• Sectie 6.2: servicerapportage – produceren van overeengekomen, tijdige, betrouwbare, nauwkeurige rapportage als informatie voor besluitvorming en effectieve communicatie.

• Sectie 6.3: servicecontinuïteit- en beschikbaarheidsmanagement – borgen dat de over-eengekomen servicecontinuïteit- en beschikbaarheidsverplichtingen aan de klant onder alle omstandigheden kunnen worden nageleefd.

• Sectie 6.4: budgetteren en accounting voor IT-services – budgetteren en accounten voor de kosten van servicelevering.

• Sectie 6.5: capaciteitsmanagement – borgen dat de serviceprovider altijd genoeg capaciteit heeft om te voldoen aan de huidige en toekomstige overeengekomen eisen van de klant.

• Sectie 6.6: informatiesecuritymanagement – effectief managen van informatiesecurity bin-nen alle service-activiteiten.

• Sectie 7.2: klantrelatiemanagement – vaststellen en onderhouden van een goede relatie tus-sen de serviceprovider en klant, gebaseerd op inzicht in de klant en de aandrijvers van zijn business.

• Sectie 7.3: leveranciersmanagement – managen van leveranciers om de levering van naad-loze kwaliteitsservices te borgen.

• Sectie 8.2: incidentmanagement – zo snel mogelijk herstellen van de overeengekomen ser-vice aan de business, of reageren op service requests.

• Sectie 8.3: problemmanagement – beperken van verstoringen van de business door de oor-zaak van incidenten proactief op te sporen en analyseren en problems tot de afsluiting te managen.

• Sectie 9.1: confi guratiemanagement – defi niëren en beheersen van de componenten van de service en de infrastructuur en onderhouden van nauwkeurige confi guratie-informatie.

• Sectie 9.2: changemanagement – borgen dat alle changes op een beheerste manier worden beoordeeld, goedgekeurd, geïmplementeerd en gereviewd.

• Sectie 10.1: releasemanagement – leveren, distribueren en volgen van een of meer changes in een release naar de productieomgeving.

3.3.7 Gebruik van ISO 20000 in de levenscyclus van een IT-serviceZoals besproken in paragraaf 3.3.1, bestaat ITIL V3 uit een kern van servicestrategie en een levenscyclus van service-ontwerp, servicetransitie, serviceproductie, omarmd door continue ser-viceverbetering (fi guur 3.3). Tot op zekere hoogte komen de eisen van ISO 20000 overeen met de levenscyclusfasen van ITIL V3.

In het levenscyclusmodel van ITIL visualiseert het managementsysteem, zoals vereist door ISO 20000, de strategie rond servicemanagement.



De eisen voor het plannen en implementeren van servicemanagement gaan over ontwerpen van het management van de geleverde services. Het Service Design boek van ITIL V3 behandelt het ontwerpen van de geleverde service. Daarnaast wordt er aandacht besteed aan hoe moet wor-den geborgd dat de kwaliteit van de gespecifi ceerde services ook daadwerkelijk wordt geleverd. De eisen voor het plannen van implementeren van nieuwe of gewijzigde services zijn erop gericht dat de transitie van nieuwe services naar productieomgeving zorgvuldig gebeurt, zodat de kwaliteit van de nieuwe en de bestaande services is gegarandeerd. Het ITIL V3 boek Service Transition behandelt dit onderwerp en geeft een aantal voorbeelden van best practices.De ISO 20000-tekst over processen (hoofdstuk 6 tot en met 10 van de standaard) defi nieert de eisen voor alle servicemanagementprocessen die nodig zijn om kwaliteitsservices volgens ISO 20000 te leveren. Dit kan niet een-op-een vergeleken worden met de best practices uit Service Operations van ITIL V3, omdat de in ISO 20000 genoemde processen verspreid zijn over alle vijf kernboeken van ITIL V3.

3.3.8 Termen en defi nities van ISO 20000

De specifi catie in ISO 20000-1 stelt:De volgende termen en defi nities gelden voor de doeleinden van ISO 20000:

2.1beschikbaarheid vermogen van een component of service om zijn vereiste functie uit te voeren op een vastgesteld moment of binnen een bepaalde termijn

NOOT: Beschikbaarheid wordt meestal uitgedrukt als de verhouding van de tijd dat de service feitelijk beschikbaar is voor bedrijfsgebruik tot de overeengekomen servicetijden

2.2baseline momentopname van de status van een service of individuele confi guratie-items op een gegeven moment (zie 2.4)

2.3changerecord record dat details bevat over welke confi guratie-items (zie 2.4) worden beïnvloed en op welke wijze ze worden beïnvloed door een geautoriseerde change

2.4confi guratie-item (CI) component van een infrastructuur of een item dat wordt, of zal worden, beheerst door confi guratiemanagement

NOOT: Confi guratie-items kunnen grote onderlinge verschillen vertonen in complexiteit, grootte en type. Ze kunnen variëren van een compleet systeem inclusief alle hardware, software and documentatie tot een enkele module of een minuscule hardwarecomponent



2.5confi guratiemanagementdatabase (CMDB) database die alle relevante details bevat van elk confi guratie-item en details over de onderlinge verbanden tussen confi guratie-items

2.6document informatie en het medium waarin dit wordt weergegeven

NOOT 1: in deze standaard onderscheiden records (zie 2.9) zich van documenten doordat ze functioneren als bewijs van activiteiten in plaats van bewijs van intenties

NOOT 2: voorbeelden van documenten zijn: beleidsdocumenten , plannen, procedures , service level agreements en contracten

2.7incidentelke gebeurtenis die geen deel uitmaakt van de standaarduitvoering van een service en die een verstoring veroorzaakt, of kan veroorzaken, in de kwaliteit van de desbetreffende service, of die kwaliteit kan verminderen

2.8problem onbekende, onderliggende oorzaak van een of meer incidenten

2.9record document dat de behaalde resultaten bevat of bewijs levert van de uitgevoerde activiteiten

NOOT 1: In deze standaard onderscheiden records zich van documenten doordat deze functioneren als bewijs van activiteiten in plaats van bewijs van intentiesNOOT 2: Voorbeelden van records zijn: auditrapportages , requests for change, incidentrapportages, individuele trainingrecords en aan klanten verstuurde facturen

2.10release verzameling van nieuwe en/of gewijzigde confi guratie-items die gezamenlijk worden getest en geïntroduceerd in de productieomgeving

2.11request for change formulier of scherm dat gebruikt wordt om details van een request for change te registreren voor elk confi guratie-item binnen een service of infrastructuur



2.12servicedesk op de klant gerichte supportgroep die een groot deel van de ondersteunende werkzaamheden voor zijn rekening neemt

2.13service level agreement (SLA) geschreven overeenkomst tussen een serviceprovider en een klant waarin de services en de overeengekomen servicelevels zijn vastgelegd

2.14servicemanagement management van services om te voldoen aan de bedrijfseisen

2.15serviceprovider de organisatie die ernaar streeft te voldoen aan de ISO 20000-norm


Dit hoofdstuk legt de eisen van ISO 20000 uit en biedt handvatten voor het evalueren, onder-houden en verbeteren van het IT-servicemanagementsysteem. Het bevat de feitelijke specifi ca-tie voor de levering van kwaliteitsservices volgens ISO 20000-1 en de code of practice in ISO 20000-2. In elke paragraaftitel wordt tussen haakjes verwezen naar de originele sectie van ISO 20000.

Voor ieder onderdeel worden eerst de eisen en best practices van ISO 20000-1 en ISO 20000-2 geciteerd en daarna wordt in een fi guur getoond, hoe deze eisen in een procemodel kunnen worden weergegeven.De procesaanpak is een kwaliteitsmanagementprincipe dat afkomstig is uit ISO 9000. Dit principe houdt in dat een gewenst resultaat effi ciënter wordt gerealiseerd als de activiteiten en de hieraan gerelateerde resources als een proces worden gemanaged. Een ander kwaliteitsmanagementprincipe is de systeemaanpak van management, waarmee wordt bedoeld dat onderling van elkaar afhankelijke processen als een systeem worden gedefi nieerd, begrepen en gemanaged. Deze benadering draagt bij tot effectiviteit en de effi ciëntie bij de realisatie van de doelstellingen van een organisatie.

Om de standaard te verduidelijken zijn de fi guren weergegeven in Business Process Modeling (BPM) notatie. In veel gevallen bevatten deze illustraties verschillende activiteiten zonder bin-ding met andere activiteiten in een procesmodel. Zoals is beschreven is sectie 1.1 van deel 1 van de ISO-normen, hangt de relatie tussen de processen af van de toepassing ervan in een organisa-tie. Dit geldt ook voor de relaties tussen activiteiten.

De standaard spreekt vooral over activiteiten, en niet over processen. Sommige van de processen of processtappen kunnen overlap vertonen. Strikt genomen kan elk werkwoord in de standaard worden weergegeven als een enkele activiteit. Voor het gemak combineren we een aantal activi-teiten in een processtap.

De code of practice , deel 2, geeft uitleg over de eisen. Dit betekent in sommige gevallen dat er meer details en dus meer activiteiten en documenten genoemd worden dan die volgens deel 1 van de standaard zijn vereist.

Hoofdstuk 4De specifi caties en code of practice van ISO 20000



In een aantal gevallen geeft de standaard een expliciete eis voor een proces, een procedure of een document. Voorbeelden hiervan zijn documentatieprocedures en het auditproces. Zie ook fi guur 4.1.

Om het gemakkelijker te maken, zijn aan iedere sectie best practicerichtlijnen toegevoegd. Hier-mee wordt duidelijk gemaakt hoe de standaard in de praktijk kan worden gebruikt.

4.1 Managen en verbeteren van ITSM-processen

4.1.1 Eisen voor een managementsysteem

Doelstelling: Het leveren van een managementsysteem, inclusief richtlijnen en een framework om effectief management en implementatie van alle IT services mogelijk te maken.

Richtlijnen van ISO 20000-1 Richtlijnen van ISO 20000-2

Impliciete activiteitvan ISO 20000-2

Expliciete activiteitvan ISO 20000-1


Trigger inISO 20000-1

Expliciete activiteitvan ISO 20000-2




Trigger vanISO 20000-2


ISO 20000-1 ISO 20000-2

Figuur 4.1 Illustraties in notatie van bedrijfsprocesmodellering


De specifi caties en code of practice van ISO 20000 65

Managementverantwoordelijkheid (3.1)


Het top- of uitvoerend management moet door middel van leiderschap en acties bewijs leveren dat ze zich inzet om servicemanagementcapaciteiten te ontwikkelen, te implementeren en te verbeteren in de context van de eisen van de business en de klanten van de organisatie.Het management moet:a) servicemanagementbeleid -doelstellingen en -plannen vaststellenb) het belang van de realisatie van servicemanagementdoelstellingen en continue verbetering

communicerenc) borgen dat de eisen van de klant worden vastgesteld en dat aan die eisen wordt voldaan,

met als doel de klanttevredenheid te verbeteren.d) een manager aanwijzen die verantwoordelijk is voor de coördinatie en het management

van alle servicese) de resources vaststellen en beschikbaar stellen die nodig zijn om de dienstverlening en het

management te kunnen plannen, implementeren, monitoren, reviewen en verbeteren, bijvoorbeeld werving van geschikt personeel en management van het personeelsverloop

f ) risico’s managen voor de servicemanagementorganisatie en -servicesg) regelmatige reviews van servicemanagement houden om blijvende geschiktheid,

bekwaamheid en effectiviteit te borgen

De code of practice in ISO 20000-2 stelt: De rol van het management bij het borgen van de toepassing en ondersteuning van best-practiceproces-sen is fundamenteel voor elke serviceprovider die wil voldoen aan ISO-20000-1. Om te zorgen voor betrokkenheid, behoort de verantwoordelijkheid voor servicemanagementplannen te worden belegd bij een eigenaar op seniorniveau. Deze senior verantwoordelijke eigenaar hoort aan-sprakelijk te zijn voor de gehele levering van het servicemanagementplan.Tot de rol van senior verantwoordelijke eigenaar hoort het beschikbaar stellen van middelen voor alle continue en projectgebaseerde serviceverbeteractiviteiten.De senior verantwoordelijke eigenaar hoort te worden ondersteund door een besluitvormingsgroep met voldoende autoriteit om beleid te bepalen en beslissingen ten uitvoer te leggen.

Figuur 4.1.1 laat zien hoe dit gedeelte van de standaard kan worden gevisualiseerd in een pro-cesfl ow.

Managementactiviteiten maken geen onderdeel uit van de processen in fi guur 3.2. Toch vormen ze een belangrijk deel van het bedrijfsproces.

Draagkracht bij topmanagement is onmisbaar voor een succesvolle implementatie van ISO 20000. Leiderschap is één van de acht kwaliteitsmanagementprincipes die hun oorsprong in ISO 9000 hebben.



Draagkracht bij het management is een ontastbaar concept. Compliance aan de eis van manage-mentverantwoordelijkheid kan worden aangetoond met gedocumenteerd leiderschap en acties voor ontwikkeling, implementatie en verbetering van de servicemanagementcapability van dit leiderschap.

Documenten die de draagkracht bij het management kunnen laten zien zijn:• documenten van de benoeming van een managementteamlid dat verantwoordelijk is voor de

coördinatie en management van alle services• schriftelijk servicemanagementbeleid , -doelstellingen en -plannen

Bepaal service-managementbeleid,

doelstellingen enplannen

Servicemanagement-beleid, doelstellingen

en plannen

Communiceer hetbelang

Communicatierecords

Zorg ervoordat klanteisen zijn

vastgesteldKlanteisen

Zorg ervoor dataan klanteisenwordt voldaan

Klanteisen

Metingen vanserviceresultaten

Klanttevreden-heidsmetingen

Bepaal en biedtresources

Vastgestelderesources

Manage risico's

Voer reviews uit Reviewrecords

Benoemverantwoordelijke

manager

Levering van alle resources voorserviceverbeteractiviteiten

Ondersteund door eengeautoriseerde beslisgroep

Benoemingverantwoordelijke

manager

Geplandeinterval

Interfaces:

Continue verbetering (Act)- doe verbetervoorstellen voor SIP

Figuur 4.1.1 Managementverantwoordelijkheden



• plan van implementatieresultaten • communicatiedocumenten• documentatie over klanteisen en klanttevredenheidsmetingen • documenten over resourcebepalingen• documenten over servicemanagementreviews , zoals notulen van reviewmeetings, actieplannen

en vervolgcontroles

4.1.2 Documentatie-eisen (3.2)

De specifi catie in ISO 20000-1 stelt:Serviceproviders moeten documenten en records leveren om een effectieve planning, uitvoering en beheersing van servicemanagement te borgen. Hieronder moeten vallen:a) gedocumenteerde servicemanagementrichtlijnen en -plannenb) gedocumenteerde service level agreementsc) gedocumenteerde processen en procedures die voor deze standaard zijn vereistd) records die voor deze standaard zijn vereist

Er moeten procedures en verantwoordelijkheden worden vastgesteld voor de ontwikkeling, review, goedkeuring, onderhoud, verwijdering en beheersing van de verschillende types documenten en records.

NOOT: voor de documentatie kan elke vorm of elk type medium worden gebruikt.

De code of practice in ISO-20000-2 stelt:De senior verantwoordelijke eigenaar moet ervoor zorgen dat er bewijsmateriaal beschikbaar is voor een audit van servicemanagementrichtlijnen, -plannen en -procedures, en alle activeiten die hiermee zijn verbonden.Veel bewijsmateriaal van servicemanagementplanning en -productie hoort aanwezig te zijn in de vorm van documenten. Hiervoor kan elk type, vorm of medium worden gebruikt dat geschikt is voor het doel.

De volgende documenten worden gewoonlijk geschikt bevonden als bewijsmateriaal van servicema-nagementplanning:a. richtlijnen en plannenb. servicedocumentenc. proceduresd. processene. records van procescontrol

Er hoort een proces te zijn voor het maken en managen van documenten om ervoor te zorgen dat aan de beschreven kenmerken wordt voldaan.Documentatie hoort te worden beschermd tegen schade die wordt veroorzaakt door bijvoorbeeld slechte milieuvoorwaarden en computerrampen.

Figuur 4.1.2 laat zien hoe dit gedeelte van de standaard kan worden gevisualiseerd in een pro-cesfl ow.



Zoals in ISO 20000-1 wordt beschreven, moeten er procedures zijn voor het ontwerpen, revie-wen, goedkeuren, onderhouden, verwijderen en beheersen van documenten en records. Dit is een van de weinige verplichtingen (shalls) voor processen en procedures in ISO 20000-1.

Documentatie is een communicatiemiddel en een medium voor het delen van kennis. Docu-mentatie draagt ook bij aan het verbeteren van de performance van een organisatie. Zonder enige vorm van documentatie kan een organisatie geen algemene kennis vergaren over de performance.

SM-richtlijnenen –plannen

SLA's

Processen en procedures

(Procesbeheersings)records

Bepaaldocumentatieprocedures en

verantwoordelijkheden

Documentatieveran-woordelijkheden

Inclusief bescherming vandocumentatie tegen schade

Documentatieprocedures

Verklarende woordenlijst

Voor de documentatie kan elktype medium worden gebruikt

Lever documenten /bewijsmateriaal voor audits

Interfaces:

Continue verbetering (ACT)- doe verbetervoorstellen voor SIP

Figuur 4.1.2 Documentatievereisten



De ISO 9000-serie vormen een gedeelte van de achtergrond van ISO 20000. Zoals eerder ge-noemd, stond de 1994-versie van ISO 9001 bekend als een papieren tijger. De 2000-versie van de ISO 9000-serie bevat een procesaanpak, net als ISO 20000. Dit houdt niet in dat er geen papierwerk of andere documentatie moet zijn, maar de nadruk ligt nu meer op het managen van processen. Documentatie is nodig om compliance met de standaard aan te kunnen tonen. Zoals is beschreven in de standaard, kunnen voor de documentatie verschillende media worden gebruikt.

4.1.3 Competentie, bewustwording en training (3.3)


Alle servicemanagementrollen en -verantwoordelijkheden moeten worden gedefi nieerd en onderhouden, samen met de competenties die nodig zijn om ze effectief uit te voeren.De kundigheid van het personeel en de trainingsbehoeften moeten worden gereviewd en gemanaged, zodat het personeel zijn taak zo effectief mogelijk kan volbrengen.Het topmanagement moet erop toezien dat het personeel zich bewust is van de relevantie en het belang van hun werkzaamheden en hoe zij bijdragen aan het behalen van de service-managementdoelstellingen.

De code of practice in ISO-20000-2 stelt:

AlgemeenPersoneel dat werk uitvoert binnen servicemanagement hoort competent te zijn op basis van passende opleiding, training, vaardigheden en ervaring.

De serviceprovider hoort:a) te bepalen wat de noodzakelijke competentie is voor elke servicemanagementrolb) ervoor te zorgen dat het personeel zich bewust is van de relevantie en het belang van hun activitei-

ten binnen de brede context van het bedrijf en hoe ze kunnen bijdragen aan het bereiken van de kwaliteitsdoelstellingen

c) te zorgen voor geschikte records van opleiding, training, vaardigheden en ervaringd) training te bieden of andere acties te nemen om aan deze behoefte te voldoene) te evalueren wat de effectiviteit is van de genomen acties

Professionele ontwikkelingDe serviceprovider wordt geacht de professionele competentie van zijn werknemers te ontwikkelen en ontplooien. Om dit te bereiken, hoort de serviceprovider de volgende maatregelen te nemen:a) werving: met als doelstelling de geldigheid van de gegevens van de sollicitant te controleren (inclu-

sief hun beroepskwalifi caties) en hun sterke en zwakke punten en mogelijkheden te bepalen, op basis van een functiebeschrijving of -profi el servicemanagementdoeleinden en de algemene servicekwali-teitsdoelstellingen

b) planning: met als doelstelling nieuwe of uitgebreide services (ook uitbestede services) te bemannen met gebruikmaking van nieuwe technologie, servicemanagementpersoneel aan ontwikkelteams toe te wijzen, opvolging te plannen en andere gaten die ontstaan bij het verwachte personeelsverloop te overbruggen



c) training en ontwikkeling: met als doelstelling trainings- en ontwikkelingseisen te bepalen, zoals een trainingen ontwikkelingsplan en voorwaarden voor effectieve levering

Het personeel hoort te worden getraind in de relevante aspecten van servicemanagement (bijvoorbeeld via cursussen, zelfstudie, mentorschap en training op de werkplek) en hun samenwerkings- en leider-schapsvaardigheden horen te worden ontwikkeld. Voor elke persoon hoort een chronologisch trainings-document te worden bijgehouden, samen met een beschrijving van de trainingen.

AandachtspuntenOm teams met het geschikte competentieniveau te verkrijgen hoort de serviceprovider te beslissen wat de optimale combinatie van tijdelijke en vaste aanstellingen is. De serviceprovider hoort ook te beslis-sen wat de optimale combinatie is van nieuw personeel met de benodigde vaardigheden en herscholing van het bestaande personeel.

NOOT: De optimale balans tussen tijdelijke en vaste aanstellingen is in het bijzonder van belang als de serviceprovider plant hoe hij een service zal bieden tijdens en na grootschalige wijzigingen in het aantal supportmedewerkers en de vaardigheden van supportmedewerkers.

Factoren om in overweging te nemen bij het vaststellen van de meest geschikte combinatie van bena-deringen:a) korte- of langetermijnkarakter van nieuwe of gewijzigde competentiesb) snelheid van de veranderingen in vaardigheden en competentiesc) verwachte pieken en dalen in de workload en in de benodigde vaardighedenmix, gebaseerd op

servicemanagement- en serviceverbeterplannend) beschikbaarheid van voldoende competent personeele) snelheid van personeelsverloopf ) opleidingsplannen

De serviceprovider wordt geacht om de performance van elk individueel personeelslid ten minste jaar-lijks te reviewen en hier passende actie op te nemen.

In een procesaanpak defi nieert een organisatie de inputs en de outputs van een proces, maar ook de activiteiten die de processtappen vormen. De organisatie defi nieert verder de rollen en verant-woordelijkheden die bij elke processtap horen. De werknemer die een bepaalde rol is toegewezen moet bij het functieprofi el passen dat overeenkomt met de rol en de verantwoordelijkheden (fi guur 4.1.3). Een belangrijk onderdeel van het procesmodel van de organisatie is erop toe te zien dat de proces-stappen worden uitgevoerd door competente, bewuste en getrainde werknemers.

Er zijn drie managementprincipes die gelden voor het creëren van competentie, bewustwording en training:• Leiderschap – de vaardigheid van een individu om invloed uit te oefenen op anderen, en hen

te motiveren en de mogelijkheid te geven om bij te dragen aan de effectiviteit en het succes van de organisatie.

• Betrokkenheid van mensen – de unieke talenten van mensen moeten worden herkend en ten bate van de organisatie worden gebruikt.



• Continue verbetering – de competentie en bewustwording van mensen moet continu wor-den ontwikkeld en verbeterd.

RichtlijnenBij de organisatie van werknemers moet de aandacht niet alleen uitgaan naar het maken van een goede match tussen de vereiste en de beschikbare competenties. Er moet ook aandacht worden be-

SM-rollen en–verantwoordelijkheden

Records vancompetenties

en trainingsbehoeften

Samen met de vereistecompetenties

Records van opleiding,training, kundigheden

en ervaring

Gekwantificeerde mix

Trainings- enontwikkelingsplan

Ten minstejaarlijks

Aard van nieuwe of gewijzigde

competenties

Percentage wijzigingenvan kundigheden en

competenties

Verwachtingen overwerklast en vereiste mix

Beschikbaarheid vancompetent personeel

Verloopspercentagepersoneel

Trainingsplannen

Definieer en onderhoudSM-rollen en

–verantwoordelijkheden

Review en managecompetenties en

trainingsbehoeftenvan het personeel

Zorg voor bewustzijnvan relevantie en belangvan activiteiten personeel

Bepaal een optimalemix van werving voortijdelijk en vast, nieuw

personeel en herscholingvan bestaan personeel

Review de prestatiesvan iedere medewerker

afzonderlijk

Neem passende actie

Plan en bied training ofneem andere actie om

tegemoet te komen aantrainingsbehoeften

Evalueer de effectiviteitvan de genomen acties

Interfaces:

Continue verbetering (ACT)- doe verbetervoorstellen voor SIP

Figuur 4.1.3 Competentie, bewustzijn en training



steed aan de mogelijkheden om competenties te ontwikkelen, aan het overbrengen van expertise en aan het leren van vaardigheden. Mentors of coaches kunnen werknemers ondersteunen. Het opzetten van groepen voor werknemers met dezelfde vaardigheden kan leiden tot de uitwisseling van ervaringen en kan aanmoedigen tot de ontwikkeling van nieuwe competenties.

Stakeholders, inclusief klanten en werknemers, moeten begrijpen hoe zij voordeel kunnen be-halen bij een meer volwassen IT-management, en waarom bepaalde changes en maatregelen zijn gepland. Deze bewustwording helpt bij het wegnemen van weerstand tegen veranderingen van de bestaande manier van werken.

Het is van belang om vast te stellen wat de bestaande kennishiaten binnen de organisatie zijn en om de resultaten van zo’n analyse te delen. Deze kennishiaten kunnen worden overbrugd door tijdens de gehele IT-levenscyclus kennis in de processen te verwerken. De IT-levenscyclus is zelfsturend voor wat betreft de prioriteitstelling in de ontwikkeling van kennis en ook voor het proces om deze kennis te delen. Het bepaalt ook welke kennisbank nodig is en dat deze wordt ontwikkeld voordat de kennis feitelijk nodig is. Veel organisaties herkennen deze behoefte niet en trainen hun personeel niet. Dit kan als gevolg hebben dat het proces wordt stopgezet vanwege een gebrek aan kennis. Het signaleren van een gebrek aan kennis is een activiteit die aandacht behoeft voor, tijdens en na de toepassing van kennis bij een taak.

4.1.4 Plannen en implementeren van servicemanagement


NOOT: De methode die bekend staat als ‘Plan-Do-Check-Act’ (PDCA) kan worden toegepast op alle processen. PDCA kan als volgt worden beschreven:a) Plan: stel de doelstellingen en processen vast die nodig zijn om resultaten te behalen

conform klanteisen en beleid van de organisatie.b) Do: implementeer de processen.c) Check: monitor en meet processen en services ten opzichte van beleid, doelstellingen en

vereisten en rapporteer de bevindingen.d) Act: onderneem acties om de performance van processen te verbeteren.

Figuur 4.1.4 illustreert het proces en de proceskoppelingen die besproken worden in bepaling 4 tot 10 van ISO 20000.

Figuur 4.4 geeft het algemene, complete procesmodel weer van een serviceprovider op het hoog-ste niveau.

De inputs voor de servicemanagementprocessen zijn:• bedrijfseisen• klanteisen• aanvraag voor een nieuwe of gewijzigde service• andere processen, zoals businessprocessen, toeleverancierprocessen, klantprocessen• records van de servicedesk• andere teams, zoals security van IT-operations



De outputs voor de servicemanagementprocessen zijn:• bedrijfsresultaten• klanttevredenheid• een nieuwe of gewijzigde service• andere processen, zoals bedrijfsprocessen, leveranciersprocessen, klantprocessen• tevredenheid van teams en mensen in het algemeen

De verantwoordelijkheid van het management overstijgt de Plan-Do-Check-Act-cyclus in fi guur 4.1.4. Alle servicemanagementprocessen die worden uitgevoerd zijn de verantwoordelijkheid van het topmanagement. Alle processen hebben de Plan-Do-Check-Act-methode nodig.

RichtlijnenEen aanbevolen techniek voor de implementatie of verbetering van processen is de introductie van een algemeen continue serviceverbeterplan (Service Improvement Plan, SIP ). Figuur 4.1.5 geeft de structuur van zo’n plan, met de zes iteratieve kernfasen waar het om gaat.

Deze fasen tonen de volgende overlap met de PDCA-cyclus:• Plan – Wat is onze visie? Waar zijn we nu? Waar willen we zijn? ( bedrijfsdoelstellingen op het

hoogste niveau, assessments, meetbare targets)• Do – Hoe komen we waar we willen zijn? (procesverbetering)• Check – Hoe weten we of we een mijlpaal hebben bereikt? (metingen en metrics)• Act – Hoe houden we het momentum gaande?

Bedrijfsbehoeften

Klanteisen

Verzoek om nieuweof gewijzigde service

Andere processen \ bv.bedrijf, leverancier,

klant

Servicedesk

Andere teamsbijvoorbeeld Security

IT-operations

Bedrijfsresultaten

Klanttevredenheid

Nieuwe ofgewijzigde service

Andere processenbijvoorbeeld bedrijf,

leverancier, klant

Team- enpersoonstevredenheid

ACTContinue verbetering

PLANPlan service-management

Managementverantwoordelijkheid

Manage services

CHECKMonitor, meet

en review

DOImplementeer

servicemanagement

Figuur 4.1.4 Plan-Do-Check-Act methode voor servicemanagementprocessen (Deming’s kwaliteitscirkel)



4.1.5 Het plannen van servicemanagement (plan) (4.1)

Doelstelling: Het plannen van de implementatie en levering van servicemanagement


Servicemanagement moet worden gepland. De plannen moeten tenminste de volgende informatie bevatten:a) de servicemanagementscope van de serviceproviderb) de doelstellingen die servicemanagement moet realiseren en de eisen waaraan het moet

voldoenc) de processen die moeten worden uitgevoerdd) het framework van managementrollen en -verantwoordelijkheden, inclusief de senior

verantwoordelijke eigenaar, proceseigenaar en het leveranciersmanagement.e) de interfaces tussen servicemanagementprocessen en de manier waarop de activiteiten

moeten worden gecoördineerdf ) de aanpak die moet worden gebruikt bij het vaststellen, beoordelen en managen van

issues en risico’s die optreden bij de realisatie van de gedefi nieerde doelstellingeng) de aanpak voor de koppeling aan projecten die services ontwikkelen of aanpassenh) de middelen, faciliteiten en budgetten die nodig zijn om de vastgestelde doelstellingen te

realisereni) tools die geschikt zijn om de processen te ondersteunenj) hoe de kwaliteit van de service moet worden gemanaged, geaudit en verbeterd

Visie, missie, doelenen doelstellingen

van het bedrijf

Baseline vaststellen

Meetbare doelen

Service- &procesverbeteringen

Metingen & metrics

Hoe behouden wehet momentum?

Wat is de visie?

Waar zijn we nu?

Waar willen we zijn?

Hoe komen we daar?

Zijn we daar gekomen?

Figuur 4.1.5 De zes fasen van een plan voor continue serviceverbetering (Bron: OGC)



Er moet een duidelijke managementrichting zijn, evenals gedocumenteerde verantwoorde-lijkheden voor het reviewen, autoriseren, communiceren, implementeren en onderhouden van de plannen. Alle processpecifi eke plannen moeten verenigbaar zijn met dit service-managementplan.


De defi nitie van de scope van servicemanagement hoort te zijn opgenomen in het servicemanage-mentplan .

De scope kan bijvoorbeeld worden gedefi nieerd vanuit het perspectief:a) organisatieb) locatiec) service

Het management behoort de defi nitie van scope te zien als onderdeel van hun managementverant-woordelijkheden (en onderdeel van het servicemanagementplan). De scope moet daarna op geschikt-heid voor ISO 20000-1 worden gecontroleerd.

NOOT: De planning voor operationele changes is beschreven in sectie 9.2, Changemanagement.

In plaats van één groot plan of programma kunnen er meerdere planningsaanpakken voor service-management worden gebruikt In dat geval behoren de onderliggende servicemanagementprocessen consistent met elkaar te zijn. Het behoort ook mogelijk te zijn om te laten zien hoe elke planningseis wordt gemanaged door deze te koppelen aan de bijbehorende rollen, verantwoordelijkheden en pro-cedures. Servicemanagementplanning hoort deel uit te maken van het proces waarin de eisen van de klant en de intenties van het hoger management worden vertaald naar services en waarin een routekaart wordt gemaakt voor het sturen van de voortgang.

Een servicemanagementplan hoort de volgende onderwerpen te omvatten:a) implementatie van servicemanagement ( of een deel van servicemanagement)b) levering van servicemanagementprocessenc) wijzigingen van servicemanagementprocessend) verbeteringen van servicemanagementprocessene) nieuwe services (voor zover ze invloed hebben op de processen binnen de afgesproken servicemanage-

mentscope)

Het servicemanagementplan hoort rekening te houden met wijzigingen in servicemanagementproces-sen en - services die het gevolg zijn van events zoals:a) serviceverbeteringb) servicewijzigingc) standaardisatie van de infrastructuurd) wijzigingen in wettelijke regelingene) wijzigingen in regelgeving, bijvoorbeeld locale wijzigingen in belastingtarievenf ) voorschriften of opheffen van voorschriften binnen bedrijfstakkeng) fusies en acquisities



Het servicemanagementplan hoort de volgende inhoud te hebben:a) de servicemanagementscope van de serviceproviderb) de doelstellingen en eisen die door servicemanagement moeten worden gerealiseerdc) de middelen, faciliteiten en budgetten die nodig zijn om de gedefi nieerde doelstellingen te behalend) het framework van managementrollen en -verantwoordelijkheden, inclusief de senior verantwoor-

delijke eigenaar, de proceseigenaren en het management van leverancierse) de interfaces tussen servicemanagementprocessen en de wijze waarop de activiteiten en/of processen

moeten worden gecoördineerdf ) de aanpak die moet worden gebruikt voor het vaststellen, beoordelen en managen van issues en

risico’s met oog op de realisatie van de gedefi nieerde doelstellingeng) een planningsschema voor resources, weergegeven als de datums waarop fi nanciën, vaardigheden en

resources beschikbaar moeten zijnh) de aanpak voor wijziging van het plan en van de service die met het plan is gedefi nieerdi) hoe de serviceprovider blijk kan geven van continue kwaliteitscontrole (bijvoorbeeld tussentijdse

audits)j) de processen die moeten worden uitgevoerdk) de tools die geschikt zijn om de processen te ondersteunen

Figuur 4.1.6 laat zien hoe dit gedeelte van de standaard in een procesfl ow kan worden weerge-geven.

ISO 20000-1 eist dat de organisatie zijn scope plant, en de doelstellingen en eisen die in het ser-vicemanagementplan moeten worden gerealiseerd. De organisatie moet zijn servicemanagement-processen defi niëren, met de rollen en verantwoordelijkheden , de interfaces tussen processen en de interfaces met projecten. Ook de manier waarop de activiteiten worden gecoördineerd moet worden gedefi nieerd. Als er processpecifi eke plannen zijn moeten deze overeenkomen met het servicemanagementplan. Om dit te bevestigen, beschrijft ISO 20000 in de subsectie ‘Planningsaanpakken’ dat als er meer-dere servicemanagementplannen gebruikt worden in plaats van één groot plan of programma, de onderliggende servicemanagementprocessen consistent moeten zijn.

Alle hierboven genoemde ingrediënten voor de planning van servicemanagement vormen samen het model voor de realisatieprocessen van servicemanagement.

RichtlijnenEen IT-organisatie die aan een verbeterprogramma begint kan zichzelf in een meer succesvolle positie brengen door zich als een bedrijf te gaan gedragen en een visie vast te stellen (stage 1) met doelen, budgetten en metrics. Een ITSM-visie is een verklaring van “Waar willen we zijn” die business en IT zijn overeengekomen. Het beschrijft het doel en de betekenis van een SIP.

De visieverklaring behoort het verbeterprogramma te verduidelijken wat de bedrijfsdoelstellin-gen en technische doelstellingen betreft. Ook moet het de betrokkenheid en de opvattingen van het hoger management duidelijk maken en mensen motiveren om hiernaar te handelen.

Het gevoel van urgentie dat wordt opgeroepen in “wat als we niks doen?” en het persoonlijke perspectief op de visie in “wat levert het mij op?” vormen de basis voor alle communicatie naar stakeholders die betrokken zijn bij een SIP of hierdoor worden beïnvloed.



De bedrijfs- en IT-strategieën moeten op elkaar aansluiten door de koers te bepalen in het SIP. Duidelijke richtlijnen en normen moeten een consistente en continue aanpak van IT-servicema-nagement borgen. De IT-management- en toolarchitectuur moeten ook de bedrijfseisen onder-steunen.

De belangrijkste activiteiten die moeten worden uitgevoerd om de algehele koers te bepalen zijn:• analyseren van de bedrijfsbehoeften en hoe IT hieraan tegemoet kan komen• vaststellen van een risicomanagementbeleid en borgen dat deze wordt meegenomen in de

plannings- en besluitvormingsprocessen• vaststellen van een IT-strategie en borgen dat deze wordt geïntegreerd in de bedrijfsstrategie• ontwerpen van richtlijnen rond de gewenste bedrijfsresultaten en borgen dat IT-investeringen

maximaal worden benut.

Processpecifieke plannen (moeten aansluiten op de

service-management-

plannen)

Service-management-

plannen

Inclusief:- scope van SM serviceprovider- doelstellingen en eisen die SM moet realiseren- processen die SM moet uitvoeren- framework van managementrollen en -verantwoordelijkheden- interfaces van SM-processen en coördinatie van activiteiten- aanpak voor risicomanagement- aanpak voor koppeling aan SM-projecten- resources, faciliteiten en budgetten- Tools die geschikt zijn voor ondersteuning processen- Methoden voor SQ-management, -audits en -verbetering

Om plannen te kunnen reviewen, autoriseren, communiceren, implementeren en onderhouden

Rekening houdend met processen en changes die worden opgeroepen door events zoals:- serviceverbetering- servicewijziging- standaardisatie van infrastructuur- wijzigingen in wettelijke regelingen- wijzigingen in regelgeving- voorschriften of opheffen van voorschriften binnen bedrijfstakken- fusies en acquisities

Met inbegrip van:- implementatie van (deel van) SM- levering van SM-processen- wijzigingen van SM-processen- verbeteringen van SM-processen- nieuwe services

Hoort de koppeling van planningseisen aan rollen, verantwoordelijkheden en procedures te ondersteunen

Managementkoers en gedocumen-teerde verant-

woordelijkheden

Lever heldere managementkoers

en gedocumen-teerde verant-

woordelijkheden

Plan service-

management

Interfaces:


Figuur 4.1.6 Plan servicemanagement (Plan)



Kritieke succesfactoren voor een succesvolle afstemming van IT op bedrijfsdoelstellingen zijn:• een gevoel van urgentie creëren • een sterke coalitie aan het hoofd hebben • visie en leiderschap in het behouden van de strategische koers, duidelijke doelen en metingen

van de realisatie van doelen• innovatie en nieuwe werkwijzen accepteren • een algemeen inzicht hebben in het bedrijf, zijn stakeholders en zijn omgeving • IT-personeel heeft inzicht in de bedrijfsbehoeften• bedrijf heeft inzicht in het potentieel van IT• informatie en communicatie is beschikbaar en toegankelijk voor iedereen die dat nodig heeft• technologische ontwikkelingen bijhouden om mogelijkheden voor de business te signaleren• quick wins creëren, zonder de langtermijnbaten uit het oog te verliezen• organisatorische veranderingen institutionaliseren

Voordat er met een SIP kan worden begonnen moet een IT-organisatie begrijpen wat ze willen (fase 1) en waar ze nu zijn (fase 2) vanuit verschillende perspectieven:• Businessdrivers – de bedrijfsstrategie, koers en issues waar het bedrijf mee te maken heeft, en

welke invloed deze hebben op IT.• Technologische drijfveren – technologische ontwikkelingen en hoe deze het best kunnen wor-

den ingezet om het bedrijf te ondersteunen.• De kijk van het bedrijf op de drivers en hoe het bedrijf gebruik wil maken van de nieuwe

businessvoordelen van technologie• Hebben de business en IT dezelfde opvatting over de huidige rol van IT en de volwassenheid

en de kwaliteit van IT-servicelevering in relatie tot de businessdrivers?• Wat zijn de opvattingen en behoeften van de stakeholders?• Is er een duidelijk antwoord op de vraag: “wat als we niets doen”?

Een helder inzicht in de actuele structuur helpt om de schaal, complexiteit en inzet te bepalen die nodig zijn om de visie te realiseren. Volwassenheidsmodellen , benchmarking en gap-assessment-rapportages leiden tot een identifi catie van hiaten (gaps)in de capabilities van de medewerkers, de processen en de technologie. Zij geven ook zicht op de waarde van de potentiële bedrijfsresulta-ten als het hiaat wordt opgevuld. Een gedocumenteerde gap-assessment faciliteert prioriteitstel-ling bij hiaten en vaststelling van gebieden die verbetering behoeven.

Zowel het bedrijf als de IT-organisatie moeten de vraag: “waar willen we zijn?” beantwoorden en het aan de hand hiervan eens worden over de rol en de kenmerken van de IT-organisatie. (fase 3). De volgende vragen moeten daarbij worden gesteld:• Is het een rol die leuk is om erbij te hebben?• Is het een rol die nodig is?• Wat zijn de gevolgen voor zowel de business als de IT-organisatie als deze vereiste rol niet

vervuld kan worden?

Om een SIP te rechtvaardigen, behoren de kosten en baten van een project te worden vergeleken in een businesscase. De kosten zijn relatief eenvoudig te meten (mensen, tools enzovoort), maar de baten zijn moeilijker als direct resultaat van een SIP aan te merken. Procesmatige projecten leveren vaak een hogere kwaliteit van servicelevering, hogere servicelevels en een meer fl exibele organisatie op, maar deze resultaten zijn niet altijd fi nancieel kwantifi ceerbaar.



Een businesscase vereist een senior sponsor die het SIP ondersteunt en belang heeft bij succes van de SIP. Zonder een sponsor is het risico groot dat er geen geld en resources beschikbaar worden gemaakt en dat er geen verbeteringen kunnen worden gerealiseerd. De sponsor moet de basis leggen voor acceptatie door de business.

Een SIP kan een langdurig veranderprogramma zijn. Quick wins kunnen helpen om de energie en betrokkenheid hoog te houden. Zorg ervoor dat deze quick wins voor iedereen zichtbaar zijn en plan ze in het SIP. Verzeker u er ook van dat de quick wins zichtbaar zijn voor alle stakeholders en dat ze regelmatig worden gecommuniceerd.

4.1.6 Servicemanagement implementeren en services leveren (Do) (4.2)

Doelstelling: Het implementeren van de servicemanagementdoelstellingen en het service-managementplan.


De serviceprovider moet het servicemanagementplan implementeren om services te managen en leveren, inclusief:a) toekenning van fondsen en budgettenb) toekenning van rollen en verantwoordelijkhedenc) documentatie en onderhoud van de richtlijnen, plannen, procedures en defi nities voor elk

proces of set van processen.d) vaststelling en management van de risico’s voor de service e) management van teams, bijvoorbeeld werving en opleiding van geschikt personeel en

management van personeelsverloopf ) management van faciliteiten en budgetg) management van de teams, inclusief die van de servicedesk en van productieh) rapportage over de voortgang ten opzichte van de planneni) coördinatie van servicemanagementprocessen


Als de oorspronkelijke services niet voldoen aan de implementatie-eisen van ISO 20000-1, kunnen er geen best practice- servicemanagementprocessen worden gerealiseerd die voldoen aan de eisen van ISO 20000.Als de service en servicemanagementprocessen eenmaal zijn geïmplementeerd, behoren ze te worden onderhouden.Er behoren reviews plaats te vinden die in overeenstemming zijn met sectie 4.3 (Monitoren, meten en reviewen (Check)).

NOOT: De persoon die geschikt is voor de planning en initiële implementatie hoeft niet geschikt te zijn voor de lopende productie.

Figuur 4.1.7 laat zien hoe dit gedeelte van de standaard in een procesfl ow kan worden weerge-geven.



Interfaces:

Continue verbetering (ACT – aanpassen)- doe verbetervoorstellen voor SIP

Changemanagement:- dien requests for changes in

Servicerapportage-ontvang informatie

Budgetteren en accounting- budgetteer en verantwoord alle componenten

Toegewezen fondsen budgetten

Toegewezen rollen enverantwoordelijkheden

Geactualiseerderichtlijnen, plannen,

procedures en definitiesvoor processen

Reviewrecords

Voortgangsrapportage

Servicemanagementplan

Bepaal risico'sen metingen

Service-managementplannen

Wijs fonds enbudgetten toe

Wijs rollen enverantwoordelijkheden

toe

Documenteer enonderhoud richtlijnen,plannen, procedures endefinities voor processen

Manage teams,inclusief servicedesk

en productie

Manage faciliteitenen budget

Rapporteer voortgangten opzichte van

de plannen

Review richtlijnen,plannen, procedures endefinities voor processen

Implementeerservicemanagementplan

Coördineerservice-

managementprocessen

Bepaal enmanage risico's

Richtlijnen, plannen,procedures en definities

voor processen

Richtlijnen, plannen,procedures en definities

voor processen

Figuur 4.1.7 Implementeer servicemanagement en lever de services (Do - uitvoeren)



In de Do-fase van de PDCA cyclus worden het procesmodel en de rollen en verantwoordelijkhe-den geïmplementeerd. In deze fase begint de organisatie volgens het ontworpen procesmodel te werken. De organisatie ‘bevriest’ het procesmodel door het ontwerp vast te leggen en specifi eke resources en medewerkers aan het servicemanagementplan toe te wijzen. Wijzigingen van het proces moeten worden gedocumenteerd en geïmplementeerd via een gemanaged proces. Op deze manier wordt het procesmodel ‘ontdooid’ en weer ‘bevroren’ via het algemene changeproces.

RichtlijnenBij de beantwoording van de vraag “hoe komen we waar we moeten zijn” (fase 4) komen de vol-gende onderwerpen aan de orde:• HOE worden de vereiste changes uitgevoerd?• WELKE items zijn essentieel in de SIP?

Het antwoord op de vraag “waar moeten we beginnen” hangt af van:• het volwassenheidsniveau van de hele IT-organisatie (actuele en toekomstige target)• de volwassenheid van individuele ITSM-processen (actuele en toekomstige target)• de strategische doelen van de organisatie• de prioriteiten gebaseerd op de onderlinge relaties tussen de processen

Over het algemeen kunnen organisaties geen hoog volwassenheidsniveau bereiken als ze alleen individuele ITSM-processen hebben ingericht. De afhankelijke processen moeten op hetzelfde volwassenheidsniveau worden geïmplementeerd.

Een samenvatting van de ontdekte hiaten (gaps) moet worden gepresenteerd aan een functieover-schrijdende groep van de belangrijkste stakeholders. Deze groep moet inzicht en betrokkenheid hebben bij de vereiste verbeteringen , voordat er acties worden gepland. Om een groter draagvlak bij het management te creëren is het zaak om veel zorg te besteden aan het winnen van vertrou-wen in de assessment - of benchmarkresultaten.

De implementatie en verbetering van IT-servicemanagement vereist organisatorische verandering en is daarom een organisatorisch veranderprogramma. Veel van zulke programma’s behalen niet de gewenste resultaten door de vele moeilijkheden die moeten worden overwonnen. Immers: mensen moeten hun oriëntatie en de manier waarop zij werken veranderen en mensen hebben over het algemeen een weerstand tegen veranderingen. Daarom moeten de voordelen van de ver-andering worden uitgelegd aan alle betrokkenen, om hun steun te verkrijgen en om erop toe te zien dat zij hun oude werkwijze verruilen voor de nieuwe. Goed leiderschap is hier erg belangrijk.

Cultuur is een ander cruciaal aspect waar rekening mee moet worden gehouden. De cultuur kan een implementatie ondersteunen, maar het kan ook een bron van weerstand vormen. Als een SIP start, zijn de nieuwe organisatorische structuur en nieuw technologie vaak de belangrijkste aandachtspunten, terwijl er maar weinig aandacht uitgaat naar de cultuur van de organisatie. De cultuur van een organisatie heeft zijn weerslag op leiderschap, en leiderschap heeft zijn weerslag op het succes van een organisatorische verandering. Cultuur is ontastbaar, maar moet wel worden gemanaged:• stel vast wat de bestaande cultuur is• bepaal ondersteunend gedrag • verander ongewenste cultuur



Voorgestelde organisatorische veranderingen hebben een effect op mensen en hoe ze zich voelen. In tijden van radicale veranderingen, is het belangrijk om erop toe te zien dat deze emoties zo worden gekanaliseerd dat ze de veranderingen bevorderen. Emoties hebben namelijk een belang-rijke impact op succes. Plan snelle successen (quick wins) om het personeel enthousiast te maken en de betrokken medewerkers aan te moedigen om de mogelijkheden van de nieuwe situatie te verkennen. Op die manier worden verbeteringen geconsolideerd en verankerd in de organisatie. Communicatie is niet iets dat maar één keer hoeft te gebeuren, maar een doorlopende eis om te zorgen voor behoud en versterking van het aanvankelijke enthousiasme.

Zorg ervoor dat iedereen wordt betrokken bij het meedenken over waarom organisatorische ver-andering nodig is. Het aanmoedigen van directe feedback maakt het gemakkelijker om issues aan te gaan. De aanpak van issues kan de organisatorische verandering op de lange termijn versnellen en effectiever maken.

De organisatie moet wel openstaan voor feedback en handelen als dit nodig is. Weerstand tegen verandering moet niet worden genegeerd, omdat het dan ‘ondergronds’ blijft bestaan. Door de weerstand open te breken, te analyseren en erover te discussiëren kunnen nieuwe gebieden voor zelfverantwoordelijkheid worden vastgesteld, of aanvullende barrières die moeten worden ver-wijderd.

De nieuwe processen en werkwijzen worden vaak geïmplementeerd binnen bestaande organisa-torische structuren. De implementatie van ITSM practice kan nieuwe rollen in een organisatie introduceren die de traditionele grenzen van de organisatie overschrijden. Dit kan moeilijkheden veroorzaken. Duidelijke defi nities van bevoegdheden en verantwoordelijkheden zijn belangrijk. Zonder deze rollen en verantwoordelijkheden zijn de nieuwe processen onduidelijk, en kunnen medewerkers terugvallen in hun oude manier van werken.

Als de processen zijn gedefi nieerd moeten ze eerst onder controle worden gebracht. Als ze onder controle zijn, kunnen ze zich ontwikkelen naar een herhaalbaar niveau en vervolgens naar een volwassenheidsniveau dat gemanaged kan worden.

Een procesgebaseerd verbeterplan vereist inzicht in wat de processen zijn, hun relaties met de be-staande organisatorische structuren en de werkwijzen. Om ervoor te zorgen dat afdelingen wer-ken als functie-overschrijdende teams in plaats van als technologiegebaseerde silo’s, moeten de volgende fundamentele veranderingen plaatsvinden:• Organisatiebreed gedefi nieerde, herhaalbare en afdelingsoverschrijdende processen moeten

worden ingericht.• Nieuwe verantwoordelijkheidsgebieden moeten in functiebeschrijvingen worden opgenomen.• Waarden, gedrag,en cultuur moeten klantgericht worden gemaakt.• Het personeel moet over een grotere kennis van complexe processen beschikken.• Een geïntegreerde toolset, die zorgt voor data-uitwisseling en workfl ow.• Management moet draagvlak bieden voor businessgerichte IT-services.• Proceseigenaren met autoriteit, die verantwoording dragen voor de processen, zijn vereist.

De processen en procedures horen eenvoudig en rechttoe-rechtaan te zijn, en horen rechtstreeks een bedrijfsfunctie te ondersteunen. Ze mogen geen doel op zich zijn , maar behoren te functio-neren als ondersteuning van de bedrijfsdoelstellingen.



Implementatie van ITSM-ondersteunende tools is van essentieel belang voor succes. De tool moet echter het proces ondersteunen (‘Structuur volgt strategie’). Na vaststelling van het huidige niveau van procesvolwassenheid en de ambities van de organisatie, kan blijken dat de bestaande ITSM-tool(s) niet meer volstaan. In dit geval moeten er nieuwe eisen worden opgesteld, en een evaluatie- en selectieproces voor een nieuwe of aangepaste ITSM-toolsoplossing worden opge-start. Als er in de organisatie geen ervaring is met tools, is het aan te raden om met een eenvou-dige tool te beginnen. Deze kan als prototype worden gebruikt om eisen vast te leggen voor een grondiger toolselectie later in het programma.

Een krachtig sponsorschap is onmisbaar voor alle initiatieven.

4.1.7 Monitoren, meten en reviewen (Check) (4.3)

Doelstelling: Het monitoren , meten en reviewen of de servicemanagementdoelstellingen en het servicemanagementplan zijn behaald.


De serviceprovider moet geschikte methoden toepassen voor monitoring en, indien van toe-passing, metingen. Deze methoden moeten aantonen dat de processen in staat zijn om de geplande resultaten te behalen.

Het management moet met vaste regelmaat reviews houden om te beoordelen of de servicemanagementeisen :a) conform het servicemanagementplan en de vereisten van deze standaard zijnb) effectief zijn geïmplementeerd en onderhouden

Er moet een auditprogramma worden gepland dat rekening houdt met de status en het belang van de processen en de gebieden waarop de audit moet plaatsvinden, en tevens rekening houdt met de resultaten van eerdere audits. De criteria , scope , frequentie en methoden van de audit moeten in een procedure worden gedefi nieerd. Bij de selectie van auditors en de uitvoering van audits moeten objectiviteit en onpartijdigheid van het auditproces worden geborgd. Auditors mogen niet hun eigen werk auditeren.De doelstelling van servicemanagementreviews , -assessments en -audits moeten worden vastgelegd, samen met de bevindingen van deze audits en reviews, en alle eventuele herstelactiviteiten . Alle relevante gebieden die niet voldoen aan de eisen of die aandacht behoeven moeten onder de aandacht van de betrokken partijen worden gebracht.

The code of practice in ISO 20000-2 stelt: De serviceprovider hoort monitoring, metingen, analyses en reviews te plannen en implementeren, evenals servicemanagementprocessen en gerelateerde systemen. De volgende items horen te worden ge-monitord, gemeten en gereviewd:a) resultaat vergeleken met de gedefi nieerde servicedoeleindenb) klanttevredenheidc) resourcegebruik



d) trendse) grootschalige afwijkingen

Figuur 4.1.8 laat zien hoe dit gedeelte van de standaard kan worden weergegeven in een proces-workfl ow.

Monitoren, meten en reviewen zijn de kernactiviteiten van continue verbetering, een van de kwaliteitsmanagementprincipes afkomstig uit ISO 9000. Continue verbetering kan niet bestaan zonder vaststelling van de feitelijk behaalde resultaten. Een organisatie kan alleen controleren of de doelen zijn behaald als er performancerecords beschikbaar zijn.

Het minimum aantal key performance indicators (KPI’s) van servicemanagement bestaat uit:• resultaten ten opzichte van gedefi nieerde servicedoelen• klanttevredenheid• resourcegebruik• trends• grootschalige afwijkingen

Deze subsectie van deel 1 van de standaard formuleert een van de weinige procedures waar docu-mentatieexpliciet vereist is: de auditprocedure. Deze subsectie noemt ook expliciet de records die zijn vereist van de doelstellingen van servicemanagementreviews, -assessments en -audits, en van de bevindingen van deze audits en elke vastgestelde herstelactie.

RichtlijnenOm te controleren of mijlpalen bereikt zijn (fase 5) moeten er duidelijk gedefi nieerde doelstel-lingen met meetbare targets zijn. Deze targets kunnen beschrijven wat het proces zou moeten realiseren (output), maar ze kunnen ook volwassenheidscriteria bevatten voor het proces zelf, zoals auditen en reviewen.

Een metric meet de resultaten van een proces of een activiteit door te bepalen of een bepaalde variabele zijn gestelde target haalt. De essentiële elementen van metrics zijn tijd, kosten, kwaliteit en effectiviteit. Het is van belang om te bepalen welke benadering van performancemetingen het meest effectief is voor een gegeven situatie. De resultaten kunnen vertekend zijn als niet alle belangrijke componenten worden gemeten. Om dit probleem te voorkomen, is het van belang om ervoor te zorgen dat er een gebalanceerde set van metrics wordt geselecteerd. De metingen moeten frequent worden uitgevoerd om ervoor te zorgen dat de nodige aanpassingen tijdig kun-nen worden aangebracht, maar niet zo vaak dat er onnodige workloads ontstaan. Zorg er ook voor dat relevante projectresultaten en metrics worden opgenomen in performancereviews van werknemers.

De beste metrics zijn objectief, geloofwaardig en vereisen weing downtime of procesresources. Gebruik waar mogelijk geautomatiseerde tools voor het verzamelen, rapporteren en volgen van metingen. Review ook regelmatig metingen en metrics op hun geschiktheid voor de business, en pas ze aan indien nodig.



Meten waar toepasbaar

Items te monitoren:- prestatie tegen gedefinieerde servicetargets- klanttevredenheid- resourcegebruik- trends- grote afwijkingen

Interfaces:

Continue verbetering (Act):- Doe verbetervoorstellen voor SIP

Servicerapportage:- Ontvang informatie

Houd tijdens het bepalen van deauditfrequentie rekening met:– risicograad van een process– frequentie van uitvoering– problemhistorie

Komt overeen met SM-plan?Effectief geïmplementeerd enonderhouden?

Proces en selectie van auditorsmoeten objectief en onpartijdigzijn

Procedure omvat audit-:- criteria- scope- frequentie- methoden

Geplandetussenpozen

Planauditprogramma

Communiceeraandachtsgebieden

naar relevantepartijen

Voer audits uit

Definieerauditprocedure

Monitor en toon hetvermogen van

servicemanagement-processen

ReviewSM-eisen

Leg doelstellingen,bevindingen en

herstelacties vast

Auditprogramma

Communicatierecords

Doelstellingenreviews,

assessmentsen audits

Data over vermogenSM-processen om

resultaten te behalen

Review-,assessment-

en auditrecords

Records vanherstelacties

Reviewrecords

Voorgaandeauditresultaten

Figuur 4.1.8 Continue verbetering (Act)



Kritieke succesfactoren (CSF’s) zijn essentieel voor het realiseren van de missie van de business. De key performance indicators (KPI’s) komen van deze CSF’s en zij bepalen de kwaliteit, performance, waarde en procescompliance. In elk ITSM-proces moet rekening worden gehouden met CSF’s. Om te borgen dat er aan de CSF’s wordt voldaan moeten voor elk proces KPI’s worden bepaald en regelmatig worden gemeten.

CSF’s en KPI’s gaan van afdelingsniveau naar persoonlijk niveau en bepalen de baseline en de mechanismen voor het volgen van de performance. Focus op een minimum aantal KPI’s per proces, bijvoorbeeld vijf per proces. Als een KPI is gehaald, kan de aandacht worden verlegd naar nieuwe KPI’s. Elke organisatie moet afspraken maken over de toepasselijke CSF’s en KPI’s. Elke stakeholder en elke servicemanagementdiscipline kan andere metrics vereisen.

Een veelgebruikte methode bij metrics is om KPI’s te gebruiken bij de audit op verbetering. Trendanalyses kunnen worden uitgevoerd met behulp van een balanced scorecard. Een balanced scorecard draagt bij aan performancemanagement van de organisatie. De doelen voor organisa-tieperformance moeten de volgende vier perspectieven bevatten:• Klantperspectief – relevant voor de meeste processen en in het bijzonder voor SLM met

gedocumenteerde SLA-targets.• Interne procesperspectief – bevat de ISO 20000-processen.• Leer- en groeiperspectief – personeelsvoorziening, training en investeringen in software.• Financieel perspectief – IT-fi nancieelmanagement gaat over hoe kosten en heffi ngen worden

toegewezen aan de klantorganisatie.

CSF’s en KPI’s kunnen ook dienen als doelstellingen voor een SIP. Voer telkens als een signifi -cante fase van de SIP is afgerond, een post implementation review (PIR) uit om te borgen dat aan de doelstellingen is voldaan. Vergelijk de behaalde resultaten met de originele doelen, en defi nieer nieuwe targets voor verbetering.

4.1.8 Continue verbetering (Act) (4.4)

Doelstelling: Het verbeteren van de effectiviteit en effi ciëntie van serviceverlening en servicemanagement.

De specifi catie in ISO20000-1 stelt:BeleidEr moet een gepubliceerd beleid zijn voor serviceverbetering . Alle aspecten die niet voldoen aan de standaard of servicemanagementplannen moeten worden hersteld. Rollen en verantwoordelijkheden voor serviceverbeteringsactiviteiten moeten duidelijk worden gedefi nieerd.

Management van verbeteringenAlle voorgestelde serviceverbeteringen moeten worden beoordeeld, vastgelegd, geprioriteerd en geautoriseerd. Er moet een plan worden opgesteld om de activiteit te beheersen.De serviceprovider moet een proces realiseren dat de verbeteractiviteiten continu identifi ceert, meet, rapporteert en managet. Dit omhelst:



a) verbeteringen van een afzonderlijk proces die de proceseigenaar kan implementeren met de gebruikelijke personeelscapaciteit, bijvoorbeeld de uitvoering van afzonderlijke corrigerende en preventieve acties.

b) verbeteringen die meerdere processen of de hele organisatie betreffen

ActiviteitenDe serviceprovider moet de volgende activiteiten uitvoeren:a) data verzamelen en analyseren om een baseline te creëren voor, en een bench-

mark uit te voeren op, de capabiliteit van de serviceprovider om service en service-managementprocessen te leveren

b) identifi ceren, plannen en implementeren van verbeteringenc) overleggen met alle betrokken partijend) doelen stellen voor verbeteringen van kwaliteit, kosten en gebruik van resourcese) bepalen van relevante input voor verbeteringen van alle servicemanagementprocessenf ) meten, rapporteren en communiceren van de serviceverbeteringeng) waar nodig aanpassen van servicemanagementbeleid,-processen, -procedures en -plannenh) erop toezien dat alle goedgekeurde acties worden geleverd en dat deze voldoen aan de

vooraf gestelde doelen


BeleidServiceproviders behoren te erkennen dat er altijd potentieel is om de levering van services nog ef-fectiever en effi ciënter te maken. Er behoort een gepubliceerd beleid te zijn voor servicekwaliteit en -verbetering.Al degenen die betrokken zijn bij servicemanagement en serviceverbetering behoren zich bewust te zijn van het beleid voor servicekwaliteit en van hun persoonlijke bijdrage aan het bereiken van de doelstel-lingen die in dit beleid zijn uiteengezet. Vooral alle werknemers van de serviceprovider die betrokken zijn bij servicemanagement, behoren een breed inzicht te hebben in de gevolgen hiervan voor servicemanagementprocessen. Er behoort een effectief contact te zijn binnen de managementstructuur van de serviceprovider zelf, bij klant en toeleveranciers van de serviceprovider, over zaken die invloed hebben op de servicekwaliteit en klanteisen.

Plannen van serviceverbeteringenServiceproviders behoren een methodische en gecoördineerde aanpak van serviceverbetering te gebrui-ken om te voldoen aan de eisen van het beleid, vanuit hun eigen perspectief en vanuit het perspectief van de klant. Voordat een serviceverbeterplan wordt uitgvoerd, behoren de kwaliteit en het niveau van de service als een uitgangspunt (baseline) te worden vastgelegd, zodat de feitelijke verbeteringen hiermee kunnen worden vergeleken. De feitelijke verbetering behoort te worden vergeleken met de voorspelde verbetering om de effectiviteit van de change te kunnen beoordelen.

NOOT 1: Eisen voor serviceverbetering kunnen vanuit alle processen komen. Serviceproviders behoren hun personeel en de klant aan te moedigen om ideeën aan te dragen voor het verbeteren van services.



NOOT 2: Dit kan worden gedaan met behulp van ideeënschema’s, kwaliteitscirkels, gebruikersgroe-pen en verbindingsbijeenkomsten.

Targets voor serviceverbetering behoren meetbaar te zijn, gekoppeld aan bedrijfsdoelstellingen en ge-documenteerd in een plan.

Serviceverbetering behoort actief te worden gemanaged, en de voortgang hoort te worden gemonitord ten opzichte van de formeel overeengekomen doelstellingen.

Figuur 4.1.9 laat zien hoe dit gedeelte van de standaard kan worden gevisualiseerd in een pro-cesworkfl ow. Zoals eerder genoemd, kan de plan-do-check-actmethode op alle processen worden toegepast. Een zorgvuldige planning is nodig voor de laatste fase van de methode, waarin actie wordt geno-men op verbetermogelijkheden.

Continue verbetering is een van de acht kwaliteitsmanagementprincipes. Een proces voor con-tinue verbetering is een van de weinige expliciet vereiste gedocumenteerde processen in ISO 20000. De subsectie over continue verbetering vereist ook expliciet de registratie van alle voor-gestelde serviceverbeteringen.

RichtlijnenHet moeilijkste deel van elke SIP is het onderhouden van de verbeteringen (fase 6) die zijn gere-aliseerd. Procesverbeteringen moeten worden gedocumenteerd om te zorgen dat processen her-haalbaar zijn en om de realisatie van een kwaliteitsstandaard te faciliteren. Verzamel de kennis die tijdens de ontwikkeling van het SIP is verkregen en maak dit toegankelijk door kennismanage-mentechnieken toe te passen. Het zal moeilijker worden om verbetering te ondersteunen omdat het verandertempo in de IT in een continue versnelling zit. De toegenomen vraag naar verandering is een reactie op de toe-nemende behoefte van het bedrijf om te innoveren en concurrerend te blijven. Onderscheid kor-tetermijn-, middellangetermijn- en langetermijnbaten en veranker major changes in de dagelijkse praktijk, om te borgen dat procesverbeteringen beklijven. Gebruik het succes van ‘quick wins’ om de gang erin te houden en om aan te sporen tot verdere veranderingen.Monitor en review processen voortdurend. Als het bedrijf signifi cante investeringen doet in ver-beterinitiatieven van ITSM en SIP’s, zorg er dan voor dat u kunt aantonen dat deze investeringen daadwerkelijk iets hebben opgeleverd. Doe dit met behulp van metingen en metrics die zijn gerelateerd aan het bedrijf en zijn IT-gebruik. Metrics helpen ook om de werknemers inzicht te bieden in waar ze nu zijn, hoeveel er is bereikt, waar ze heen moeten en wanneer substantiële hordes zijn genomen. Gebruik meetinformatie om het team in staat te stellen de resultaten te reviewen en te begrijpen, en om al gaande aanpassingen te doen.

Versterk continu de aansluiting van IT op de business, op alle niveaus. Prioriteiten van het bedrijf bieden duidelijkheid over hoe operations het bedrijf beïnvloedt; welke delen worden beïnvloed en op welke manier dit gebeurt. Als gevolg hiervan zal de algehele productiviteit van het bedrijf van een hogere kwaliteit zijn, en de bedrijfsactiviteiten zullen in de juiste volgorde van worden uitgevoerd, gerangschikt naar belangrijkheid.



Serviceverbetertargets horen alsvolgt te zijn:- meetbaar- gekoppeld aan bedrijfsdoelstellingen- gedocumenteerd in een plan

Stel verbetertargets vast voorkwaliteit, kosten en inzetresources

Uitgangspunt (baseline) omwerkelijke verbeteringen tegen temonitoren en mee te vergelijken

Serviceverbeterbeleid

Herzienservicemanagement-

beleid en verbeterplan

Verbeterrapport

SIP

Records van actueleservicekwaliteit en

servicelevels

Geautoriseerde SIP

Gedefinieerde rollen enverantwoordelijkheden

Personeel mot zich bewust zijn vanhet servicekwaliteitsbeleid

Serviceverbeterplan,inclusief voorgesteldeserviceverbeteringen

Verzamel en analyseerdata over capabiliteitvan serviceprovider

Bepaal en planverbeteringen

Overleg met allebetrokken partijen

Meet, rapporteer encommuniceer de

serviceverbeteringen

Herzieservicemanagement-

beleid, processen,procedures en plannen

Beoordeelverbeterkansen en

leg ze vast

Bepaal en publiceereen

serviceverbeterbeleid

Definieer rollen enverantwoordelijkheden

Implementeerverbeteringen

Vergelijk feitelijkeverbeteringen met

voorspeldeverbeteringen

Herstel afwijkingenvan de

servicemanagement-plannen

Houd rekening metrelevante input

van verbeteringen

Moedig personeel enklant aan om

verbetervoorstellente doen

Zorg ervoor datgoedgekeurde acties

zijn geleverd endoelstellingen bereikt

SIP

Waar nodig

Van andere service-managementprocessen

SIP

SIP

Interfaces:

Alle processen:- ontvang verbeterkansen voor SIP

Change management:- dien requests for change in

Service reporting:- ontvang informatie

Informatiesecuritymanagement:- ontvang managementinformatie over trends in informatiesecurity-incidenten

Problem management:- review van major incidenten

Klantrelatiemanagement:- lever voortgangsrapporten

Figuur 4.1.9



4.2 Beheersing van IT-services

4.2.1 Plannen en implementeren van nieuwe of aangepaste services (5)

Doelstelling: Ervoor zorgen dat de nieuwe services en changes van services leverbaar en beheerbaar zijn volgens de afgesproken voorwaarden over kosten en servicekwaliteit.


Voorstellen voor nieuwe of aangepaste services moeten rekening houden met de kosten en de organisatorische, technische en commerciële impact die deze aanpassingen kunnen hebben op serviceverlening en management.De implementatie van nieuwe of gewijzigde services, alsook de afsluiting van een service, moeten worden gepland en goedgekeurd door formeel changemanagement. Voor planning en implementatie moeten voldoende fi nanciële middelen en resources beschikbaar zijn, zodat de changes die nodig zijn voor serviceverlening en management kunnen worden doorgevoerd.

De plannen moeten de volgende informatie bevatten:a) de rollen en verantwoordelijkheden voor de implementatie, de uitvoering en het

onderhoud van de nieuwe of gewijzigde service, inclusief activiteiten die worden uitgevoerd door klanten en toeleveranciers

b) changes van het bestaande servicemanagementframework en de servicesc) communicatie naar de relevante partijend) nieuwe of gewijzigde contracten en overeenkomsten om deze te laten aansluiten op de

changes in de bedrijfsbehoeftene) eisen die gesteld worden aan mankracht en de werving daarvanf ) eisen die gesteld worden aan vaardigheden en trainingen, bijvoorbeeld eisen aan

gebruikers en technische support g) processen, maatregelen, methoden en tools die worden gebruikt bij de nieuwe of

gewijzigde service, bijvoorbeeld capaciteitsmanagement, fi nancieel managementh) budgetten en tijdsschaleni) criteria voor service-acceptatiej) de verwachte resultaten van de uitvoering van de nieuwe service, weergegeven in meetbare

waarden

Nieuwe of gewijzigde services moeten worden geaccepteerd door de serviceprovider voordat deze in de productieomgeving worden geïmplementeerd.De serviceprovider moet rapporteren over de resultaten die zijn bereikt met de nieuwe of gewijzigde service, in relatie tot de geplande resultaten. Changemanagement moet een post implementation review uitvoeren waarin feitelijke en geplande resultaten worden vergeleken.




Onderwerpen ter overweging:In de planning voor nieuwe of gewijzigde services horen de volgende reviews te zijn opgenomen:a) budgettenb) personeelsresourcesc) bestaande servicelevelsd) SLA’s en andere targets of serviceverplichtingene) bestaande servicemanagementprocessen, -procedures en -documentatief ) de scope van servicemanagement, inclusief de implementatie van servicemanagementprocessen die

eerder buiten de scope lagen

ChangerecordsAlle changes van services horen te worden weergegeven in changemanagementrecords. Dit geldt ook voor:a) werving of herscholing van personeelb) verhuizingc) gebruikerstrainingd) communicatie over de changese) changes op de aard van de ondersteunde technologief ) formele afsluiting van services

Figuur 4.2.1 laat zien hoe dit gedeelte van de standaard kan worden gevisualiseerd in een proces-workfl ow.

Als de business van een serviceprovider goed loopt, zal er altijd vraag zijn naar nieuwe of gewijzig-de services. Deze nieuwe services of wijzigingen in de servicecatalogus moeten worden behandeld door het changemanagementproces. De ISO 20000-1-sectie over het plannen en implementeren van nieuwe of gewijzigde services stelt eisen aan de input voor het changemanagementproces, namelijk de voorstellen voor nieuwe en gewijzigde services.Planning en implementatie van nieuwe of gewijzigde services moet in samenwerking met het changemanagementproces gebeuren. Deze interface of koppeling moet worden gedocumenteerd.



4.2.2 Controlprocessen: confi guratiemanagement (9.1)

Doelstelling: het defi niëren en beheersen van de onderdelen van de service en de infrastructuur en het onderhouden van gedetailleerde confi guratie-informatie.

Voorstel voor nieuwe of

gewijzigde services

Daarbij lettend op:- kosten- impact op organisatie- technische impact- commerciële impact Inclusief- rollen en verantwoordelijkheden- veranderingen van bestaande SM-framework en services- communicatie met relevante partijen- nieuwe of gewijzigde contracten moeten aansluiten op veranderingen in bedrijfsbehoeften- mankracht- en wervingseisen- eisen aan vaardigheden en training- aangepast gebruik van processen, metingen, methoden en tools- budgetten en tijdschema's- criteria voor service-acceptatie- verwachte uitkomsten in meetbare termen weergegeven

- scope van servicemanagement

Changemanagementrecords,met daarin opgenomen:- werving/herscholing van personeel- relocatie- gebruikerstraining- communicatie over wijzigingen- wijzigingen van de aard van de ondersteunde technologie- formele afsluiting van services

Plan nieuwe ofgewijzigde services

Verkrijg goedkeuringvoor het plan via

changemanagement

Accepteergewijzigde services

Implementeernieuwe of gewijzigde

services viachangemanagement

Postimplementatie-review (PIR)

Rapport overbereikte versus

geplande resultaten

Ìnterfaces:

Continue verbetering (Act – aanpassen)- doe verbetervoorstellen voor SIP

Changemanagement:- plan en zorg voor goedkeuring van de implementatie van nieuwe of gewijzigde services, inclusief voldoende financiële middelen en resources; met formele acceptatie- dien requests for change in

Servicerapportage:- ontvang informatie

Figuur 4.2.1 Plan en implementeer nieuwe of gewijzigde services




Er moet een geïntegreerde aanpak zijn van de planning van change- en confi guratiemanagement. De serviceprovider moet de interface defi niëren naar accountingprocessen van fi nanciële assets.

NOOT: accounting van fi nanciële assets valt buiten de scope van deze sectie. Er moet een beleid zijn voor wat als een confi guratie-item kan worden gedefi nieerd, en wat de samenstellende onderdelen van een confi guratie-item zijn.

Er moet worden gedefi nieerd welke informatie voor elk item dient te worden vastgelegd, inclusief de relaties en documentatie die nodig zijn voor effectief servicemanagement.Confi guratiemanagement moet de mechanismen leveren voor het identifi ceren, beheersen, en volgen van versies van herkenbare componenten van de service en infrastructuur. Er moet voor worden gezorgd dat de mate van beheersbaarheid (control) voldoende is om de bedrijfsbehoeften, het faalrisico en de servicekriticiteit aan te kunnen. Confi guratiemanagement moet informatie aan het changemanagementproces leveren over de impact die een aangevraagde change heeft op de service en de infrastructuurconfi guraties. Indien van toepassing, moeten changes van confi guratie-items zijn te traceren en auditen, bijvoorbeeld in het geval van changes en verplaatsingen van software en hardware.Procedures voor confi guratiecontrol moeten ervoor zorgen dat de integriteit van systemen, services en servicecomponenten wordt gehandhaafd. Voordat confi guratie-items worden vrijgegeven in een productieomgeving, moet een confi guratie-uitgangspunt (baseline) van de betreffende items worden bepaald.Originele versies van digitale confi guratie-items moeten worden beheerd in beveiligde fysieke of elektronische bibliotheken . Deze items moeten verwijzen naar de confi guratierecords, bijvoorbeeld software, testproducten of ondersteunende documenten.Alle confi guratie-items moeten uniek identifi ceerbaar zijn en vastgelegd zijn in een CMDB . Toegang tot het updaten van de CMDB moet streng worden gecontroleerd. De CMDB moet actief worden gemanaged en gecontroleerd, om betrouwbaarheid en nauwkeurigheid te borgen. De status van confi guratie-items, de versies daarvan, de locatie, gerelateerde changes en problems en gerelateerde documentatie moeten zichtbaar zijn voor degenen die deze informatie nodig hebben.Confi guratie-auditprocedures moeten de registratie van gebreken, initiatie van corrigerende acties en rapportage over het resultaat omvatten.


Om te zorgen dat de serviceprovider zijn IT-assets en confi guraties effectief kan managen, behoort confi guratiemanagement samen met change- en releasemanagement te worden gepland en geïmple-menteerd. Bij de release en distributie van nieuwe en geactualiseerde services en systemen behoort er nauwkeurige informatie over de confi guratie beschikbaar te zijn om de planning en control van de changes te on-dersteunen. Het resultaat behoort een effi ciënt systeem te zijn dat de confi guratie-informatieprocessen van de serviceprovider integreert, evenals - indien van toepassing - die van de klant en leveranciers.



Alle belangrijke assets en confi guraties behoren te worden verantwoord en behoren een verantwoorde-lijke manager te hebben die zorgt voor het behoud van passende bescherming en control, bijvoorbeeld autorisatie van changes voordat ze worden geïmplementeerd.Verantwoordelijkheid voor de implementatie van beheersingsmechanismen (controls) kan worden ge-delegeerd, maar de aansprakelijkheid hoort bij de verantwoordelijke manager te blijven. De verant-woordelijke manager hoort te worden voorzien van informatie die nodig is om aan zijn verantwoorde-lijkheden te voldoen. Bijvoorbeeld: de persoon die een change autoriseert kan informatie nodig hebben over de kosten, risico’s, impact van de change en resources voor de implementatie.

De infrastructuur en/of services behoren een actueel confi guratiemanagementplan te hebben, op zich-zelf staand of als onderdeel van andere planningsdocumenten. Dit plan moet de volgende informatie omvatten of beschrijven:a) scope, doelstellingen, richtlijnen, standaarden, rollen en verantwoordelijkhedenb) de confi guratiemanagementprocessen om de confi guratie-items van de service(s) en infrastructuur

te defi niëren, de wijzigingen van de confi guraties te beheersen, de status van de confi guratie-items te registreren en erover te rapporteren, en de volledigheid en juistheid van de confi guratie-items te verifi ëren

c) de eisen aan aansprakelijkheid, traceerbaarheid, auditeerbaarheid; bijvoorbeeld met oog op secu-rity-, wetgevings-, regelgevings- of bedrijfsdoeleinden

d) confi guratiecontrol (beheersing van toegang, bescherming, versie, samenstelling en release)e) interfacecontrolproces voor het vaststellen, registreren en managen van confi guratie-items en infor-

matie op het gemeenschappelijke grensvlak van twee of meer organisaties; bijvoorbeeld systeemin-terfaces, releases

e) planning en inzetten van de resources die nodig zijn om de assets en confi guraties onder control te krijgen en het confi guratiemanagementsysteem te onderhouden; bijvoorbeeld training

g) management van leveranciers en toeleveranciers die confi guratiemanagement uitvoeren

NOOT: er moet een passend niveau van automatisering worden geïmplementeerd om ervoor te zorgen dat processen niet ineffi ciënt of foutgevoelig zijn, of zelfs helemaal niet worden nagevolgd.

Confi guratie-identifi catieAlle confi guratie-items horen uniek te worden geïdentifi ceerd en gedefi nieerd door attributen die hun functionele en fysieke eigenschappen beschrijven. Informatie moet relevant en auditeerbaar zijn.Er horen geschikte markeringen, of andere identifi catiemethoden, te worden gebruikt en geregistreerd in de confi guratiemanagement-database.

De te managen items horen met vastgelegde selectiecriteria te worden geïdentifi ceerd en horen de vol-gende informatie te omvatten:a) alle issues en releases van informatiesystemen en software (inclusief software van derden) en gerela-

teerde systeemdocumentatie; bijvoorbeeld eisenspecifi caties, ontwerpen, testrapporten, releasedocu-mentatie

b) confi guratie-uitgangspunten (baselines) of uitspraken over de samenstelling van iedere toepasbare omgeving, standaardsamenstellingen van hardware en release

c) originele hardcopy en elektronische bibliotheken; bijvoorbeeld defi nitive software library d) confi guratiemanagement-package of tools die in gebruik zijne) licenties



f ) securitycomponent, bijvoorbeeld fi rewallsg) fysieke assets die moeten worden getraceerd voor fi nancieel management of bedrijf; bijvoorbeeld

veilig stellen van geautomatiseerde gegevensdragers, uitrustingh) servicegerelateerde documentatie, bijvoorbeeld SLA’s, proceduresi) service-ondersteunende faciliteiten, bijvoorbeeld stroom naar de computerkamerj) relaties en afhankelijkheden tussen confi guratie-items

NOOT: Andere items die als confi guratie-items kunnen worden beschouwd zijn:a) andere documentatieb) andere assetsc) andere faciliteiten, bijvoorbeeld vestigingd) business-unitse) mensen

Zinvolle relaties en afhankelijkheden tussen confi guratie-items behoren te worden geïdentifi ceerd om te zorgen voor het benodigde controlniveau.

Waar traceerbaarheid is vereist, behoort het proces ervoor te zorgen dat confi guratie-items door de hele levenscyclus kunnen worden getraceerd, van eisendocument tot releaserecords; bijvoorbeeld door een traceermatrix te gebruiken.

Confi guratiecontrolHet proces behoort te borgen dat alleen geautoriseerde en identifi ceerbare confi guratie-items worden geaccepteerd en geregistreerd van ontvangst tot verwijdering.Er behoort geen enkel confi guratie-item te worden toegevoegd, gewijzigd, verplaatst of verwijderd/onttrokken zonder passende controldocumentatie, bijvoorbeeld goedgekeurde change requests, geactu-aliseerde release-informatie.

Om de integriteit van systemen, services en de infrastructuur te beschermen, behoren confi guratie-items te worden bewaard in een geschikte en veilige omgeving, die:a) ze beschermt tegen ongeautoriseerde toegang, wijziging of corruptie, bijvoorbeeld een virusb) een middel voor disaster recovery biedtc) het gecontroleerd terughalen van een kopie van het beheerste origineel toestaat; bijvoorbeeld soft-

ware

Verantwoording van en rapportage over de status van de confi guratieEr behoren actuele en nauwkeurige confi guratierecords te worden bijgehouden die wijzigingen weerge-ven in de status, locatie en versies van confi guratie-items.

Verantwoording van de status behoort informatie te bieden over de actuele en historische data van ieder confi guratie-item door zijn hele levenscyclus heen. Het behoort tracering van wijzigingen van confi -guratie-items mogelijk maken tijdens verschillende stadia; bijvoorbeeld ‘besteld’, ‘ontvangen’, ‘in ac-ceptatietest’, ‘live’, ‘in wijziging’, ‘teruggetrokken’, ‘verwijderd’. Informatie over de confi guratie behoort actueel te worden gehouden en toegankelijk worden gemaakt voor gebruikers, klanten, leveranciers en partners, om hen te ondersteunen bij hun planning en besluitvorming. Een externe serviceprovider kan bijvoorbeeld informatie over de confi guratie toegankelijk maken voor de klant en andere partijen om de andere servicemanagementprocessen te ondersteunen bij de end-to-end-service.



Confi guratiemanagementrapporten behoren beschikbaar te zijn voor alle relevante partijen. De rap-porten behoren de identifi catie en status van de confi guratie-items te beschrijven, evenals de versies en de hiermee samenhangende documentatie.

Rapporten behoren het volgende te beschrijven:a) recente versies van het confi guratie-itemb) locatie van het confi guratie-item en, voor software, de locatie van de originele versiesc) wederzijdse afhankelijkhedend) versiehistoriee) status van confi guratie-items die samen het volgende vormen:

1) serviceconfi guratie of systeem2) een change, baseline, bouw of release3) versie of variant

Confi guratieverifi catie en -auditHet confi guratieverifi catie en -auditproces , zowel fysiek als functioneel, behoort te worden geregeld, en er behoort een controle te worden uitgevoerd om ervoor te zorgen dat er toereikende processen en resources zijn om:a) de fysieke confi guraties en het intellectuele kapitaal van de organisatie te beschermenb) ervoor te zorgen dat de serviceprovider in control is van zijn eigen confi guraties, originelen en licen-

tiesc) vertrouwen te bieden dat confi guratie-informatie nauwkeurig, beheerst en zichtbaar isd) ervoor te zorgen dat een change, een release, een systeem of een omgeving overeenkomt met de gecon-

tracteerde of gespecifi ceerde eisen en dat de confi guratierecords nauwkeurig zijn

Confi guratie-audits horen met regelmaat te worden uitgevoerd, voor en na een major change, na een disaster, en met willekeurige intervallen.Gebreken en afwijkingen behoren te worden geregistreerd, beoordeeld en er behoort corrigerende actie te worden opgestart, nagevolgd, en teruggekoppeld naar relevante partijen. Vervolgens behoort een plan te worden gemaakt voor verbetering van de service.

NOOT: Gewoonlijk zijn er twee typen confi guratie-audits:a) Functionele confi guratie-audit: een formele inspectie om te verifi ëren dat een confi guratie-item

voldoet aan de performance- en functionele eigenschappen die in de confi guratiedocumenten zijn gespecifi ceerd.

b) Fysieke confi guratie-audit: een formele inspectie van de confi guratie van een confi guratie-item ‘zoals gebouwd/geproduceerd’, om te verifi ëren dat het aan de productconfi guratie-documenten vol-doet.

De basisactiviteiten van confi guratiemanagement zijn plannen en implementeren, identifi ceren, beheersen, bewaken van en rapporteren over de status, en verifi ëren en auditen. Specifi ek vereiste documenten in het confi guratiemanagementproces zijn confi guratierecords en records van gebre-ken . Confi guratiemanagement heeft interfaces met het changemanagementproces, het release-managementproces en het proces voor de accounting van de fi nanciële resources. Deze interfaces moeten worden gedocumenteerd (zie fi guren 4.2.2, 4.2.3 en 4.2.4).



RichtlijnenConfi guratiemanagement houdt het uitvoeren van de volgende activiteiten in:• plannen• identifi ceren• beheersen• bewaken statusverifi ëren• rapporteren

Het doel, de doelstellingen, de scope en de prioriteiten van confi guratiemanagement behoren in overeenstemming te zijn met de bedrijfsdoelstellingen. De scope van confi guratiemanagement wordt gespecifi ceerd in de identifi catiestap.

Identifi catie richt zich op het bepalen en onderhouden van naamgevingsconventies en versie-nummering van de fysieke componenten van de IT-infrastructuur, de documentatie hiervan, de onderlinge relaties en de relevante attributen. Baselineconfi guraties van huidige en toekomstige hardware kan worden omschreven in de vorm van CI-clusters.

Configuratiemanagementplan

Inclusief relaties en documentatie

Beleid voor hoe eenconfiguratie-item (CI) en zijnsamenstellende onderdelenmoet worden gedefinieerd

Plan hoort te omvatten:-scope, doelstellingen, richtlijnen, standaardrollen en verantwoordelijkheden-change- en configuratiecontrolprocedures-eisen aan verantwoordingsplicht, traceerbaarheid, auditeerbaarheid-gedefinieerde interface met releasemanagement-interfacebeheersingsproces-leveranciersmanagement

Definieer de interfacemet financiële

asset-accountingprocessen

Zorg voor mechanismenvoor identificatie,

beheersing entracering van CI-versies

Benoemverantwoordelijkemanager voor alle

belangrijke assets enconfiguraties

Planconfiguratiemanagement

in aansluiting opchangemanagement en

stel vast welkeinformatie moet

worden geregistreerd

Figuur 4.2.2 Confi guratiemanagement



De algemene vraag voor de identifi catie van IT-componenten is:

‘Welke services en daaraan gerelateerde componenten van de IT-infrastructuur willen we onder de controle van servicemanagementdisciplines brengen, en welke informatie hebben we daarvoor nodig?’

Bij het opzetten van een identifi catiesysteem moeten er beslissingen worden genomen over de scope en het specifi ceringsniveau van de te registreren informatie.

Alle assets horen te wordengeclassificeerd volgenshun kriticiteit

Configuratierecords

Beheers de toegangvoor lezen enactualiseren

van de CMDB

Identificeer CI

Onderhoudintegriteit van CI's

Geactualiseerde CMDB

Markeer CI's

Neem daarbij ook relatiesen afhankelijkhedentussen CI's op

Beperkt tot geautoriseerdeCI's

Bewaar CI's in eenveilige omgeving

Voorkom allemutaties van

CI's zonder de juistebeheersings-

documentatie

Registreer CI's

Originelen van digitaleconfiguratie-items

CMDB

Beheers originelenvan digitale

configuratie-items inveilige bibliotheken

Neem in origineleneen verwijzing op naar

configuratierecords

Figuur 4.2.3 Confi guratiemanagement - vervolgd



Voor elk kenmerk dat moet worden geregistreerd, moet een eigenaar of stakeholder worden vast-gesteld. Hoe meer kenmerken worden geregistreerd, des te meer werk het kost om de informatie actueel te houden. Om te bepalen welke informatie moet worden geregistreerd, is het zinvol de bovenstaande vraag verder uit te werken. Hieronder volgen enkele voorbeelden daarvan:

Rapport, met daarin:- records van gebreken- opgestarte corrigerende acties- resultaat van corrigerende acties

Rapporten naar allegerelateerde partijen

Baseline van CI's

Leverimpactinformatie aanchangemanagement

Auditkalender

Configuratie-management-

rapporten

Met hierin opgenomen:- versie-informatie- locatie van CI's en originele versies- wederzijdse afhankelijkheden- CI status

Bepaal voor eenrelease de baselinevan geschikte CI's

Plan audit in

Lever informatieover configuratiedata

AuditkalenderControleer en audit

CMDB actief en neemcorrigerende actie

Interfaces:

Financiële asset-accountingprocessen

Continue verbetering (Act – aanpassen):- doe verbetervoorstellen voor SIP

Changemanagement:- dien requests for change in- voor en na belangrijke wijzigingen horen configuratie-audits te worden ingepland- lever impactinformatie aan changemanagement


Budgetteren en accounting:- budgetteer en verantwoord alle componenten

Servicecontinuïteits- en beschikbaarheidsmanagement:- de CMDB moet beschikbaar zijn als normale kantoortoegang is belemmerd- na een ramp horen configuratie-audits te worden ingepland

Informatiesecuritymanagement- de CMDB hoort informatie te bevatten over assets die relevant zijn voor informatiesecurity- informatiesecuritymanagement houdt een inventarisatie bij van informatie-assets

Incidentmanagement:- wissel relevante informatie uit

Figuur 4.2.4 Confi guratiemanagement – vervolgd



• Welke resources zijn beschikbaar voor het verzamelen en actueel houden van de informatie?• Hoe volwassen zijn de administratieve en logistieke processen?• Op welke niveaus worden componenten, onafhankelijk van de hoofdcomponent, door de

organisatie zelf geïnstalleerd, vervangen, ontwikkeld en/of gedistribueerd?• Welke activiteiten die door derden (third parties) worden uitgevoerd moeten meetbaar en

onder controle zijn?• Welke componenten hebben in geval van een fout impact op de services en welke informatie

is relevant voor het diagnosticeren van zulke fouten? • Welke kostbare componenten moeten worden beschermd tegen diefstal of vermissing?• Wat zijn de huidige en toekomstige informatiebehoeften van de andere processen?• Welke eisen zijn verbonden aan de voorwaarden van de SLA?• Welke informatie is nodig voor het doorberekenen van de kosten?• Zijn de ambities realistisch of zijn er issues die moeten worden uitgesteld?

De antwoorden op deze vragen leveren informatie over een aantal activiteiten op. Er moet een beslissing worden genomen over de scope (breedte) van de CMDB, het detailleringsniveau en het uitvalsniveau (diepte).

Figuur 4.2.5 laat de relaties tussen een service en de CMDB-componenten zien binnen de scope. Daaronder staan de overige CI’s die nodig zijn voor de service. Het bijhouden van deze relaties maakt het gemakkelijker om de impact van incidenten op services te bepalen. Het is ook moge-lijk om een rapport op te stellen van alle componenten die in een service worden gebruikt. Deze informatie kan worden gebruikt om verbeteringen van de service te plannen. De CI-’service’ kan ook relaties hebben met andere CI’s, zoals overeenkomsten met de klant in de vorm van een SLA. In het voorbeeld valt service B compleet buiten de scope van de CMDB. Dit houdt in dat de scope van de CMDB niet alle CI’s dekt die bijdragen aan service A wat betekent dat service A niet volledig kan worden ondersteund.

IT-infrastructuur

CI # 1

Applicatie A

CI # 2

Module A

CI # 4

Module B

CI # 5

LAN 2

CI # 3

Systeem 21

CI # 6

NIC 12

CI # 7

PABX

Lijn 1, digitaal

Lijn 2, digitaal

Modem 5

CI # 8

Lijn 3, analoog

Service B

Scope

Service A

Figuur 4.2.5 Scope van de CMDB



Na vaststelling van het aantal gebieden in de scope kunnen we vaststellen welke elementen van de CI-levenscyclus in de scope moeten worden opgenomen. Hierbij moeten vragen worden be-antwoord als: nemen we CI’s al in de CMDB op als zij nog de status ‘in ontwikkeling’ of ‘in bestelling’ hebben, of pas als zij in de infrastructuur zijn gerealiseerd? Opname van producten die nog in ontwikkeling zijn, heeft als voordeel dat de specifi caties daarvan niet zonder meer mogen worden gewijzigd en ook de overdracht naar de beheeromgeving soepeler zal verlopen. De beslissing die u in deze kwestie neemt, zal gevolgen hebben voor de activiteit ‘statusbewaking’ van confi guratiemanagement en voor de inzet van resources. Wat dit laatste betreft: de scope van confi guratiemanagement wordt breder als er een groter deel van de levenscyclus van het product wordt opgenomen en dit zal meer resources opeisen.

Een belangrijk aandachtspunt voor het inrichten van confi guratiemanagement is de vaststelling van het detailleringsniveau van attributen. Dit bepaalt welke informatie straks over elke afzon-derlijke CI beschikbaar moet zijn en welke namen en attributen moeten worden meegenomen. Bij het bepalen van de benodigde detaillering moeten de eisen voor change-, incident-, problem-management en andere managementdisciplines zorgvuldig met elkaar in evenwicht worden ge-bracht, net als de daarmee samenhangende werklast en beschikbare resources.

De relaties tussen CI’s zijn van nut voor de diagnose van storingen, voor het voorspellen van de beschikbaarheid van services, en het beoordelen van changes. Er kunnen vele soorten relaties worden bijgehouden: • Fysieke relaties:

– Is een onderdeel van - dit is de moeder-dochterrelatie van het CI, zoals een harde schijf een onderdeel is van een pc en een softwaremodule een onderdeel is van een programma (zie fi guur 4.2.6).

– Is verbonden met - bijvoorbeeld een pc die is aangesloten op een LAN-segment.– Is nodig voor - bijvoorbeeld hardware die nodig is voor een applicatie.

• Logische relaties:– Is een kopie van - een kopie van een standaardmodel, baseline of programma.– Heeft betrekking op – een procedure, handleidingen, documentatie, een SLA of een klantgebied. – Wordt benut door – bijvoorbeeld een CI die nodig is voor het leveren van een dienst,of een soft-

waremodule die door meerdere programma’s wordt aangeroepen.

Ouder-kindrelaties

Systeem A

A1

A2

A 3

A4

A 3.1

A 3.2

A 3.3

Figuur 4.2.6 Ouder-kindrelaties van CI’s (Source: OGC)



Bij het defi niëren van de diepgang van de CMDB, de uitsplitsingsniveaus van een systeem of component, wordt een hiërarchie van componenten en onderdelen opgezet (zie fi guur 4.2.7). De moeder-CI’s worden geselecteerd en het aantal uitsplitsingsniveaus van CI’s gedefi nieerd. Het hoogste niveau is de IT-infrastructuur zelf. Het laagste niveau is het meest gedetailleerde niveau waarop nog control moet worden uitgeoefend. Opname van een CI in de CMDB is alleen nut-tig als de beheersing ervan en de informatie die erbij hoort voordeel biedt voor de andere ISO 20000-processen. De eerste implementaties beginnen meestal op het hoogste niveau, waarna selectiefl agere uitsplitsingsniveaus worden geïntroduceerd, vooral in het geval van releasemanage-ment.

De volgende algemene overwegingen zijn van toepassing op de CMDB:• Hoe meer niveaus, hoe meer informatie moet worden bijgehouden. Dat is meer werk en het

resulteert in een grotere en complexere CMDB.• Hoe minder niveaus, des te geringer de control en informatie over de IT-infrastructuur.

Als er verschillende vormen van een CI naast elkaar bestaan, kan er gebruik worden gemaakt van varianten. Dit houdt in dat er een parallelle relatie is. Men spreekt van versies als er een oude en een nieuwe versie van een CI op hetzelfde moment in gebruik zijn. Dit betekent dat er een seriële relatie is. Effectief gebruik van deze twee concepten is van nut bij de planning van changes.

De naamgeving van een CI moet uniek en systematisch zijn om onderscheid te kunnen maken tussen verschillende CI’s. De meest elementaire oplossing is een eenvoudig nummeringsysteem, dat kan worden ingedeeld in reeksen voor elk gebied. Nieuwe nummers kunnen worden gegene-reerd als er een nieuwe CI is gecreëerd. Indien mogelijk, moeten de namen betekenis hebben, om de communicatie met de gebruiker gemakkelijker te maken. Deze naamgevingsconventies kunnen

IT-infrastructuur

Hardware Software Netwerk Documentatie

Suite 1 Suite 2

Programma 1-1 Programma 1-2 Programma 1-3

Module 1-2-1 Module 1-2-2

Figuur 4.2.7 CMDB-boomstructuur(Bron: OGC)



ook worden gebruikt voor het fysiek labellen van CI’s, waardoor deze makkelijker te identifi ceren zijn tijdens audits, onderhoud en het bijhouden van incidenten.

Voor de ontwikkeling van de CMDB in detail moeten de attributen en relaties van elk CI-type worden gedefi nieerd. Met behulp van attributen wordt informatie opgeslagen die relevant is voor het betreffende CI. De attributen uit tabel 4.2.1 kunnen worden gebruikt bij het opzetten van de infrastructuur-CI’s in een CMDB.

Attribuut Omschrijving

CI-nummer/label of -barcodenummer

Het unieke nummer van het CI. Vaak is dat het recordnummer dat automatisch wordt toegekend door de database. Niet alle CI’s kunnen een label krijgen maar ze hebben wel allemaal een uniek nummer.

Kopie- of serienummer Het identifi catienummer van de leverancier in de vorm van een serienummer of licentienummer.

Audittool identifi catienummer Audittools gebruiken vaak een eigen identifi catie die kan verschillen per aandachtsgebied. Dit attribuut legt de link met een dergelijke omgeving.

Modelnummer/catalogusreferentie Unieke identifi catie die de leverancier in de catalogus gebruikt. Elke versie van een model heeft een ander nummer, bijvoorbeeld: PAT-NL-C366-4000-T.

Modelnaam Volledige modelnaam, vaak voorzien van versieaanduidingen, bijvoorbeeld: ‘PII MMX 400Mhz’.

Fabrikant Fabrikant van het CI.

Categorie Rubricering van het CI (bijvoorbeeld hardware, software, documentatie).

Type Omschrijving van het CI-type, verdere detaillering van de ‘categorie’, bijvoorbeeld hardwareconfi guratie, softwarepakket of programmamodule.

Garantie einddatum Datum waarop de garantie afl oopt.

Versienummer Het versienummer van het CI.

Locatie De locatie van het CI, bijvoorbeeld de bibliotheek of het opslagmedium waar software CI’s zich bevinden of de locatie of kamer waar de hardware CI’s zich bevinden.

Verantwoordelijke/eigenaar De naam en/of aanduiding van de eigenaar of de persoon die verantwoordelijk is voor het CI.

Datum in beheer Datum waarop bovenstaande verantwoordelijke het CI in beheer kreeg.

Bron/leverancier De herkomst van het CI, bijvoorbeeld zelf ontwikkeld, gekocht van leverancier X.

Licentie Licentienummer of referentie naar een licentieovereenkomst.

Leverdatum Datum waarop het CI aan de organisatie is geleverd.

Acceptatiedatum Datum waarop de organisatie het CI heeft geaccepteerd.

Huidige status Huidige status van het CI, bijvoorbeeld: ‘in testfase’, ‘in gebruik’, ‘uitgefaseerd’.

Geplande status Volgende geplande status van het CI met de datum en een indicatie van de benodigde actie.

Aanschafwaarde De aanschafprijs van het CI.

Restwaarde na afschrijving De huidige waarde van het CI na afschrijving.

Opmerking Een tekstveld voor opmerkingen, bijvoorbeeld om uit te leggen hoe een variant verschilt van een andere.

Tabel 4.2.1 Voorbeelden van attributen



Het is afhankelijk van de servicemanagementtool hoe events zoals incidenten in de CMDB wor-den opgenomen: als attribuut van het CI of op een andere manier. Doorgaans worden de num-mers van de relevante CI’s in het incidentrecord, problemrecord en changerecord opgenomen. In welke vorm dat ook plaatsvindt, er dient een relatie te worden onderhouden tussen het CI en records van tabel 4.2.2.

Attribuut Beschrijving

RfC-nummers RfC-nummers die voor dit CI open staan, of hebben gestaan.

Problem-nummers Problem-nummers die voor dit CI open staan, of hebben gestaan.

Incident-nummers Incident-nummers die aan dit CI gerelateerd zijn.

Tabel 4.2.2 Andere aan CI’s gerelateerde records

Het bijhouden van relaties tussen CI’s is een belangrijk onderdeel van confi guratiemanagement. Afhankelijk van het type database kunnen die relaties worden opgenomen als attributen van het CI of worden ze bijgehouden in een aparte tabel (zie tabel 4.2.3).

Attribuut Beschrijving

Moeder-CI-relaties Sleutel of CI-nummer van de moeder-CI’s

Dochter-CI-relaties Sleutel of nummer van de dochter-CI’s

Andere relaties De relaties van het CI met andere CI’s los van de boven omschreven moeder-dochterrelaties, bijvoorbeeld dit CI ‘gebruikt’ of ‘is verbonden met’.

Tabel 4.2.3 Relatie-attributen

In sommige databasesystemen kan voor bepaalde velden een optie worden ingeschakeld die er-voor zorgt dat een verandering van waarde wordt bijgehouden, zodat een log met historische gegevens van attributen en relaties ontstaat. De ‘Huidige Status’-velden kunnen hier informatie uithalen over uitval (downtime), reparaties en onderhoud. Ook kan het handig zijn om een his-torie bij te houden van de verschillende eigenaren.

Het kan nodig zijn om voor elk CI-type een attribuutlijst met technische informatie bij te hou-den. Ook behoren koppelingen te worden gemaakt met andere betrouwbare bronnen, voor ge-gevens over huisvesting, locaties, gebruikers, afdelingen, telefoonnummers, budgethouders en budgetnummers. Er is veel mogelijk, maar er dient steeds rekening te worden gehouden met de hoeveelheid werk en de changebeheersingsmethoden die nodig zijn om dergelijke gegevensbe-standen te onderhouden.

Een confi guratie-uitgangspunt (baseline) is een momentopname van een groep van CI’s. Een con-fi guratie-uitgangspunt kan worden gebruikt als:• een geautoriseerd/ondersteund product dat kan zijn opgenomen in de IT-infrastructuur (deze

baselines zijn terug te vinden in de productcatalogus)• standaard-CI’s voor de registratie van gegevens over kosten (kostenposten)• uitgangspunten voor het ontwikkelen en testen van nieuwe confi guraties• terugval als er na changes problemen ontstaan met nieuwe confi guraties• als standaard voor het leveren van confi guraties aan de gebruikers, bijvoorbeeld een standaard-

werkplek• een uitgangspunt voor het uitleveren van nieuwe software



Een standaardwerkplek is een veelgebruikt voorbeeld van een confi guratie-uitgangspunt. Door het aantal standaardwerkplekken te beperken, wordt het eenvoudiger om de impact en benodig-de resources te bepalen voor het uitrollen en testen van nieuwe functionaliteit en verbeteringen. De baselines kunnen ook worden gebruikt voor het combineren en plannen van changes, zoals releasepackages. Baselines drukken de managementkosten en faciliteren projectplanning.Een productcatalogus is een andere nuttige toepassing van baselines. In de productcatalogus staan de gecertifi ceerde confi guraties die in gebruik kunnen zijn in de IT-infrastructuur en die gebruikers kunnen aanvragen. In dat geval is een nieuwe CI een kopie uit de catalogus, met een uniek nummer en label. Kijk altijd eerst naar de businesscase van een product voordat het wordt toegevoegd aan de catalogus.

De levenscyclus van een component kan worden verdeeld in een aantal fasen waarbij aan elke fase een statuscode wordt toegekend. Dit is afhankelijk van de eigenschappen van de IT-infrastructuur die de organisatie wil vastleggen. Door de datum van elke statusverandering te bewaren, kan een goed beeld ontstaan van de levenscyclus van een product: de besteltijden, de installatietijden en de hoeveelheid onderhoud en ondersteuning die eraan besteed is. De status van een component kan ook bepalend zijn voor wat er mee mag gebeuren. Bijvoorbeeld, reserveonderdelen met de status niet-operationeel kunnen niet zomaar zonder overleg worden ingezet.

De volgende statusindeling kan worden toegepast:• nieuwe CI’s:

– in ontwikkeling of in bestelling– getest– geaccepteerd

• bestaande CI’s:– ontvangen– in aanvraag (request for change (RfC)– is goedgekeurd en bijgevoegd in de plannen, een nieuw CI en documentatie (is ook een CI)

wordt geleverd– in onderhoud– down

• gearchiveerde CI’s:– uitgefaseerd– weggegooid– verwijderd– gestolen– verkocht of huur verlopen– in opslag voor donatie, verkoop, of vernietiging– vernietigd

• alle CI’s:– in voorraad– order ontvangen of gewijzigde versie beschikbaar– wordt getest– vrijgegeven voor installatie– live (active), de CI wordt gebruikt– reserve



De informatie moet effectief worden gemanaged om de CMDB up-to-date te houden. Als een activiteit de eigenschappen van een CI verandert, of de relatie tussen CI’s, moet de change in de CMDB worden geregistreerd. Opmerking: CI’s mogen alleen worden gewijzigd door middel van een change die door changemanagement is goedgekeurd. Incidentmanagement mag alleen de status van een CI wijzigen, bijvoorbeeld: ‘systeemuitval’.

Confi guratiemanagement beheerst alle IT-componenten van de organisatie en zorgt ervoor dat zij worden opgenomen in het systeem. Hardware wordt in het systeem vastgelegd als het is besteld of afgeleverd, software als het is toegevoegd aan de Defi nitive Media Library (DML) of Defi nitive Software Library (DSL).

Een van de beheerstaken is ervoor te zorgen dat CI’s alleen worden vastgelegd als ze zijn goedge-keurd en opgenomen in de productcatalogus. Hiertoe onderhoudt confi guratiemanagement nau-we relaties met leveranciers, incidentmanagement, problemmanagement en changemanagement. Als er changes plaatsvinden op de IT-infrastructuur (gecoördineerd door changemanagement), voegt confi guratiemanagement deze informatie toe aan de CMDB. Confi guratiemanagement bepaalt de mate van volwassenheid van andere processen in de organisatie zoals changemanage-ment, releasemanagement en de inkoopprocessen.

Om te borgen dat de werkelijke situatie overeenkomt met de goedgekeurde CMDB, worden de volgende acties gemonitord:• toevoegen CI• statusverandering van CI, bijvoorbeeld ‘up’ of ‘down’• verandering van eigenaar CI• verandering van relatie tussen CI’s• verwijdering CI• nieuwe relatie met een service, document of andere CI’s• vernieuwing of wijziging licentie van CI• update van CI na audit

Het is de verantwoordelijkheid van confi guratiemanagement om ervoor te zorgen dat procespro-blemen worden opgelost.

Er worden audits uitgevoerd om te verifi ëren of de huidige situatie nog wel overeenkomt met de gegevens in de CMDB. Sommige audittools kunnen automatisch werkstations analyseren en rapporteren over de huidige status van de IT-infrastructuur. Deze informatie kan worden gebruikt om de CMDB te controleren en actualiseren. Audits kunnen in de volgende situaties worden uitgevoerd:• na implementatie van de CMDB • een periode na implementatie• voor en na grote changes• na disaster recovery• op willekeurige momenten, als de confi guratiemanager denkt dat de informatie incorrect is

Audittools mogen de CMDB niet automatisch updaten als er verschillen worden gevonden tus-sen de CMDB en de werkelijkheid. Verschillen zijn juist ontstaan omdat het changemanage-



mentproces niet is gevolgd. Verschillen moeten met zorg worden onderzocht en opgepakt door changemanagement.

De kritieke succesfactor voor confi guratiemanagement is een database die up-to-date is. Dit bete-kent dat change- en releasemanagement nauwkeurig moeten worden toegepast en er altijd een stakeholder hoort te zijn voor de informatie die moet worden geregistreerd.

Implementatie van confi guratiemanagement kan het beste in fasen plaatsvinden. Pogingen om in een keer confi guratiemanagement - met een brede scope - op te zetten, mislukken vaak omdat de organisatie daar niet klaar voor is. De records die voor de implementatie van het proces zijn bijgehouden moeten worden uitgefaseerd om redundantie te vermijden. Bij introductie van het proces is het belangrijk om voor quick wins te gaan en de registratie van CI’s over te laten aan personeel dat niet alleen de juiste vaardigheden bezit, maar ook de juiste houding.

Confi guratiemanagementrapporten kunnen bestaan uit:• informatie over de kwaliteitsaspecten van het proces • aantal geconstateerde verschillen (na audit) tussen de records in de database en de werkelijke

situatie (delta’s)• aantal gevallen van niet-goedgekeurde of ongeautoriseerde confi guraties• aantal gevallen waarin een vastgelegde confi guratie onvindbaar was• verschillen in niveau van attributen (gevonden na audit)• tijdsduur van verzoek tot registratie• lijst van CI’s waarop meer dan een gegeven aantal incidenten of changes geregistreerd zijn• statistische informatie over de structuur en samenstelling van de IT-infrastructuur

4.2.3 Beheersprocessen: changemanagement (9.2)

Doelstelling: Ervoor zorgen dat alle changes op een gecontroleerde manier worden beoor-deeld, goedgekeurd, geïmplementeerd en gereviewd.


Service- en infrastructuurchanges moeten een duidelijk gedefi nieerde en gedocumenteerde scope hebben.Alle requests for change moeten worden vastgelegd en geclassifi ceerd, bijvoorbeeld als ‘urgent’, ‘emergency’, ‘major’ of ‘minor’. Requests for change moeten worden beoordeeld op hun risico, impact en voordelen voor de business.De manier waarop de change kan worden teruggedraaid of gecorrigeerd als deze niet succes-vol is moet zijn opgenomen in het changemanagementproces.Changes moeten worden goedgekeurd en vervolgens gecontroleerd, en moeten op een gecontroleerde manier worden geïmplementeerd.Alle changes moeten worden gereviewd op hun succes, evenals alle acties die na de imple-mentatie zijn genomen.



Er moeten richtlijnen en procedures zijn om de autorisatie en implementatie van emergency changes te beheersen.De ingeplande implementatiedata van changes moeten als basis worden gebruikt voor het plannen van changes en releases . Er moet een schema worden bijgehouden met alle details van de changes die zijn goedgekeurd voor implementatie en de voorgestelde implementatiedata, en dit moet kenbaar worden gemaakt aan alle betrokken partijen.Changerecords moeten met regelmaat worden geanalyseerd om toegenomen aantallen changes, terugkerende typen changes, opkomende trends en andere relevante informatie op te sporen. De resultaten en conclusies die gebaseerd zijn op de changeanalyse moeten worden vastgelegd.Verbeteracties die tijdens het changemanagementproces zijn bepaald, moeten worden vastgelegd en vormen de input voor een serviceverbeterplan.


Planning en implementatieDe changemanagementprocessen en -procedures horen ervoor te zorgen dat:a) changes een helder gedefi nieerde en gedocumenteerde scope hebbenb) alleen changes die voordeel voor de business opleveren worden goedgekeurd; bijvoorbeeld voordelen

op commercieel, juridisch, regelgeving- en wettelijk terreinc) changes worden ingepland op basis van prioriteit en risicod) changes van confi guraties kunnen worden geverifi eerd tijdens de implementatie van de changese) de tijd die nodig is om changes te implementeren wordt gemonitord en waar nodig verbeterdf ) kan worden aangetoond hoe een change wordt:

1) opgestart, geregistreerd en geclassifi ceerd (met verwijzing naar de documenten die de change aan de orde hebben gesteld)

2) beoordeeld op de impact, urgentie, kosten, voordelen en risico’s voor de service, klant en releaseplannen

3) teruggezet of gecorrigeerd als niet succesvol4) gedocumenteerd; bijvoorbeeld de change request wordt gekoppeld aan de betrokken confi gu-

ratie-items en de geactualiseerde versie van de implementatie- en releaseplannen5) goedgekeurd of afgewezen door een change-autoriteit, afhankelijk van het type, de grootte en

het risico van de change6) geïmplementeerd door de aangewezen eigenaar binnen de groepen die verantwoordelijk zijn

voor de componenten die gewijzigd worden7) getest, geverifi eerd en afgetekend 8) afgesloten en gereviewd9) ingepland, gemonitord en gerapporteerd10) gekoppeld aan incident, problem, andere records van change en confi guratie-items waar van

toepassing

De status van changes en ingeplande implementatiedata horen als basis te worden gebruikt voor de inplanning van changes en releases.Informatie over de inplanning hoort beschikbaar te worden gemaakt aan de mensen die te maken hebben met de gevolgen van de change. Waar tijdens normale service-uren een uitval kan ontstaan, moeten de betrokken mensen eerst akkoord gaan met de change voordat de implementatie wordt gestart.



Afsluiting en review van de change requestAlle changes horen na de implementatie te worden gereviewd op succes of falen en elke verbetering hoort te worden geregistreerd. Voor major changes hoort een post implementation review te worden uitgevoerd om te controleren of:a) de change aan de doelstellingen heeft voldaanb) de klanten tevreden zijn met de resultatenc) zich geen onverwachte neveneffecten hebben voorgedaan

Elke afwijking van de norm hoort te worden geregistreerd en er hoort actie op te worden genomen.Alle zwakke punten of gebreken die in een review van het changemanagementproces worden vastge-steld, horen in serviceverbeterplannen te worden opgenomen.

Emergency changesEmergency changes (noodwijzigingen) zijn soms noodzakelijk. Waar mogelijk, hoort het changeproces te worden gevolgd, maar sommige details kunnen met terugwerkende kracht worden gedocumenteerd. Waar het emergencyproces is voorbijgegaan aan andere eisen van changemanagement, hoort de change zo snel als praktisch mogelijk is aan deze eisen te worden aangepast. Emergency changes horen door de uitvoerder te worden gerechtvaardigd en na de change te worden gereviewd, om te verifi ëren dat het een echte emergency was.

Changemanagementrapportage, -analyse en -actiesChangerecords horen regelmatig te worden geanalyseerd om toenemende aantallen changes op te spo-ren, evenals vaak terugkerende typen, opkomende trends en andere relevante informatie.

Figuur 4.2.8 visualiseert dit deel van de standaard in een procesfl ow.

De basisactiviteiten van changemanagement zijn: registreren, accepteren en classifi ceren van RfC’s. Nadat een change is goedgekeurd, wordt de change ingepland, geïmplementeerd, gesloten en geëvalueerd.Changemanagementdocumenten die minstens moeten worden bijgehouden zijn RfC-records en records van verbeteracties. Een RfC kan voortkomen uit een ander proces, van een gebruiker of een medewerker. Deze in-terfaces en die met continue serviceverbetering, moeten worden gedocumenteerd.

RichtlijnenElk RfC goedgekeurd of afgewezen. Het proces wordt gefaciliteerd door de changemanager, maar daadwerkelijke beslissingen over niet-standaardchanges worden genomen door de Change Advisory Board (CAB). De CAB heeft leden uit meerdere delen van de organisatie en van klan-ten en leveranciers. Confi guratiemanagement levert informatie over de potentiële impact van voorgestelde changes.

Input van changemanagement:• RfC’s van klanten, regelgeving of leveranciers• CMDB-informatie (in het bijzonder impact analyses)• informatie uit andere processen zoals problemen capacitymanagement• changeplanning (Forward Schedule of Change: FSC)



Planchangemanagement

Alle emergencychanges horenuiteindelijk hetstandaardchange-proces te volgen

Lever inputvoor SIP

Met een heldergedefinieerde engedocumenteerdescope voor service- eninfrastructuurchanges

Breng het plan overnaar relevante partijen

Records vanverbeteractiviteiten

Records vanchangeanalyses

Inclusief impact op: - beschikbaarheids- en continuïteitsplannen en gerelateerde documenten- securitycontrols- securityrisico- assessment

Request forchange (RfC)

Beheers changesvan SLA's en andere

contracten

Beheersimplementatieen uitfaseringvan services

Neem een postimplementationreview op

Bepaal beleid enprocedure om

emergencychangeste beheersen

Registreer de RfC

Classificeer RfC:beoordeel risico,

impact,bedrijfsvoordeel,

kosten

Keur de changegoed en

controleer deze

Changeplan Plan de change in

Implementeerchange

Herroep ofherstel succesvolle

changes

Changerecords

Records vanverbeteractiviteiten

Analyseerchangerecords en

review change

Wijzigingsbeleiden –procedure voor

noodgevallen

Changerecords

Geactualiseerdechangeplan

RfC-records

Interfaces:Alle relevante processen:- dien requests for change in Continue verbetering (Act)- doe verbetervoorstellen voor SIP

Plan en implementeer nieuweof gewijzigde services- plan en geef goedkeuring voor implementatie van nieuwe of gewijzigde services, inclusief toereikende financiële middelen en resources; met formele acceptatie

Configuratiemanagement:- voor en na belangrijke changes horen configuratie-audits te worden ingepland Releasemanagement:- beheers de implementatie van services- beoordeel requests for change op hun impact op releaseplannen- actualiseer wijzigingsrecords- manage emergencyreleases volgens het changemanagementproces voor noodgevallen

Servicelevelmanagement- beheers wijzigingen van SLA's en andere contracten


Budgettering en accounting- budgetteer en account voor alle componenten- bereken de kosten en geef goedkeuring voor alle wijzigingen van services

Klantrelatiemanagement:- manage wijzigingen van contract(en), indien aanwezig, en SLA('s)

Leveranciersmanagement- manage wijzigingen van contracten en SLA's

Servicecontinuïteits- en beschikbaarheidsmanagement- beoordeel de impact van alle wijzigingen van het beschikbaarheids- en servicecontinuïteitsplan- beheers alle wijzigingen van beschikbaarheids- en servicecontinuïteits- documentatie - Koppel documentatie aan changemanagement

Informatiesecuritymanagement- beoordeel de impact van changes in securitycontrols voordat changes worden geïmplementeerd- houd securityrisico-assessments- voorkom dat changes de effectieve uitvoering van controls in gevaar brengen

Figuur 4.2.8 Changemanagement



Output van changemanagement:• bijgewerkte changeplanning • triggers voor confi guratiemanagement en releasemanagement• CAB-agenda, notulen en actiepunten• changemanagementrapporten

Changemanagement gebruikt de volgende activiteiten voor de behandeling van changes (fi guur 4.2.9):• registreren• accepteren• classifi ceren• plannen en goedkeuren• coördineren• evalueren

Alle RfC’s moeten worden geregistreerd. Als een RfC is ingediend met het doel een problem op te lossen, moet ook het nummer van de known error worden vastgelegd.

Niet elke request for change wordt als een change behandeld: sommige routinematige activiteiten - die duidelijk zijn gedefi nieerd en vastgelegd in procedures (standaardchanges), maar wel aan-passingen zijn op de infrastructuur - kunnen op dezelfde wijze worden behandeld als een service request . Dit leidt tot de volgende indeling van changes:• Standaardchanges – als service request – Changes die van te voren zijn gedefi nieerd en

goedgekeurd, een laag risico hebben, en een goedgekeurde procedure volgen, kunnen routine-matig worden uitgevoerd (opmerking: niet alle service requests zijn changes).

• Niet-standaardchanges – Dit zijn alle andere wijzigingen van de beheerde infrastructuur die geen standaardchanges zijn.

Informatie die bij het registreren van een RfC kan worden vastgelegd:• RfC-nummer ter identifi catie• nummer van problem of known error waaraan de RfC is gerelateerd• beschrijving en identifi catie van relevante CI’s• reden voor de change, inclusief zakelijke rechtvaardiging of voordelen • huidige of nieuwe versies van CI’s die veranderd moeten worden• naam, locatie, e-mailadres en telefoonnummer van de indiener• datum van indienen• geschatte resources en tijd

Na registratie van de RfC wordt een initiële assessment uitgevoerd om te controleren of een RfC onduidelijk, onlogisch, onpraktisch of onnodig is. Als dat het geval is, dan wordt het verzoek met opgaaf van reden afgewezen. De indiener wordt hiervan op de hoogte gesteld zodat hij in de gelegenheid is om het verzoek te verdedigen.



Een change leidt tot een aanpassing van data in de CMDB, bijvoorbeeld:• statusverandering van een CI• verandering van relatie tussen CI’s• nieuwe CI of variatie op een bestaande• nieuwe CI-eigenaar of locatie

Als de RfC is geaccepteerd, wordt de informatie die nodig is voor verdere behandeling van de change toegevoegd aan het changerecord.

Coördinatie

Acceptatie;Filteren RfC's

ClassificeringCategorie & prioriteit

PlanningImpact & resources

Evaluatie & afsluiting

Nee

JaU

rgen

tiep

roce

du

res

Star

t ee

nte

rug

valp

lan

Nee

Indienen RfC Registratie

Bouw

Test

Implementatie

Ja

Afwijzing,mogelijk

nieuwe RfC

Misschien iteratief

Werkt het?

Urgent?

Figuur 4.2.9 Changemanagementactiviteiten volgens ITIL V2



Eerst wordt de prioriteit en categorie van de change bepaald:• De prioriteit geeft aan hoe belangrijk de RfC is ten opzichte van andere. Dit kan variëren van

laag tot hoog(ste), en wordt afgeleid van de urgentie (in tijd) en het belang voor de business.• De categorie wordt bepaald op basis van het risico die de change vormt voor de service (de

impact ) en de benodigde resources. Dit kan variëren van gering tot groot. Daarna wordt de volgende informatie toegevoegd aan het record:• aanbevelingen van de changemanager• datum en tijd van goedkeuring• geplande implementatiedatum• back-up-plannen• supporteisen• implementatieplan• informatie over ontwikkelaars en medewerkers die de implementatie verzorgen• daadwerkelijke datum en tijd van change• evaluatiedatum• testresultaten en geconstateerde problemen• redenen voor afwijzing van het verzoek (indien relevant)• informatie over scenario en evaluatie

Changemanagement plant de changes door gebruik te maken van een changekalender of For-ward Schedule of Change (FSC). Het FSC bevat details van alle goedgekeurde changes en hun geplande implementatiedatums. Leden van de CAB adviseren over de planning van belangrijke changes, de beschikbaarheid van personeel, resources, kosten, aspecten van betrokken services, en zorgen voor betrokkenheid van de klant. De CAB treedt op als een adviesorgaan. Changema-nagement heeft een gedelegeerde bevoegdheid en treedt op namens het IT-management. Belang-rijke (major) changes moeten aan het IT-management worden voorgelegd voordat ze gepresen-teerd worden aan de CAB. Deze vorm van goedkeuring kan bestaan uit fi nanciële, technische en bedrijfsaspecten.

Voor effectieve planning moet changemanagement contact onderhouden met de projectbureaus en alle anderen in de organisatie die de changes implementeren. Het changeplan moet effectief worden gecommuniceerd.

In overleg met de betrokken IT-afdelingen kan de CAB regelmatige tijdsvensters afspreken voor de implementatie van changes op momenten waarop de verstoring van de service minimaal is.

Informatie over de planning van een change hoort voor het CAB-overleg te worden gedistribu-eerd. Relevante documenten en informatie over de agendapunten moeten ook voor het overleg worden rondgestuurd. De CAB moet een aantal vaste items op de vergaderagenda hebben, waar-onder:• ongeautoriseerde changes• goedgekeurde changes die niet zijn aangemeld bij de CAB• RfC’s die door leden van het CAB moeten worden beoordeeld • open en gesloten changes• evaluaties van reeds uitgevoerde changes



CAB-leden kunnen ook adviseren over prioritering.

Bij het inschatten van de benodigde resources en de impact van de change moeten de CAB-leden, de changemanager en alle andere betrokkenen (uitgezocht door CAB) rekening houden met de volgende aspecten:• capaciteit en performance van de betrokken service(s)• betrouwbaarheid en herstelbaarheid• continuïteitsplan• terugvalplan• beveiliging• impact op andere services• registratie en goedkeuring• benodigde resources en kosten• aantal en beschikbaarheid van benodigde specialisten• benodigde doorlooptijd van de change• nieuw aan te schaffen en te testen resources• impact op operations• eventuele confl icten met andere changes

Goedgekeurde changes worden doorgegeven aan relevante productspecialisten zodat zij de chan-ges kunnen samenstellen en integreren. Samenstellen kan bestaan uit het ontwikkelen van nieu-we software met documentatie, handleidingen, installatieprocedures, terugvalplan en hardware changes. Changemanagement levert de controle en coördinatie. De samenstelling en integratie worden ondersteund door releasemanagement en lijnmanagement, die ervoor zorgen dat de juis-te resources worden toegewezen voor het implementeren van de plannen.

Er moet een terugvalprocedure worden geschreven als onderdeel van een change om de situatie terug te kunnen draaien als de change niet het gewenste resultaat oplevert. Changemanagement mag een change niet goedkeuren als er geen terugvalprocedure is. Als de change impact heeft op de gebruikersomgeving, dan moet er een communicatieplan worden geschreven. Een implemen-tatieplan wordt ook opgesteld gedurende de bouw- of ontwikkelfase.

De terugvalprocedure, change-implementatie en voorziene resultaten van de change moeten al-lemaal goed worden getest. Daarbij moet worden gelet op de criteria die eerder al door de CAB zijn bepaald. In de meeste gevallen zal er een testomgeving of testlaboratorium voor het testen nodig zijn. Er kan door de ontwikkelaars of bouwers al in een vroeg stadium worden getest, maar een change mag nooit worden geimplementeerd zonder onafhankelijke testen. Meestal zijn dit in ieder geval:• gebruikersacceptatietesten – (eind)gebruikers uit de business testen de functionaliteit van de

change• operationele acceptatietesten – de medewerkers die support en beheer van de gewijzigde

infrastructuur verzorgen, zoals de service desk, voeren een onafhankelijke test uit

Als een change onvoldoende kan worden getest, is het mogelijk om een pilot van de change te starten voor een kleine groep gebruikers. De pilot kan dan eerst worden geëvalueerd voordat de change op grote schaal wordt uitgerold.



Op de afdeling die verantwoordelijk is voor het beheer van de IT-infrastructuur, kan een ieder worden belast met het implementeren van een change op die infrastructuur. Changemanagement zorgt ervoor dat de change op schema ligt. Er moet een duidelijk communicatieplan zijn waarin wordt aangegeven wie over de change moet worden geïnformeerd zoals de gebruikers, servicedesk en netwerkbeheer.

Alle geïmplementeerde changes – mogelijk met uitzondering van standaardchanges – moeten worden geëvalueerd. Indien nodig besluit de CAB of er een vervolgonderzoek nodig is. Er moet rekening worden gehouden met de volgende zaken:• Heeft de change zijn beoogde doel bereikt?• Zijn de gebruikers tevreden met het resultaat?• Waren er neveneffecten?• Zijn de geschatte kosten en inspanningen overschreden?• Is de planning gehaald?• Wat ging er mis?

Als de change succesvol is, kan de RfC worden afgesloten. De resultaten worden toegevoegd in de Post Implementation Review (PIR) of change-evaluatie. Als de change is mislukt, dan wordt het proces opnieuw gestart vanaf het punt waar het is misgegaan, en wordt er een aangepaste benadering gebruikt. Meestal is het het beste om de change terug te draaien (back-out/terugval) en een nieuwe RfC aan te maken die gebaseerd is op de origineel ingediende RfC.

Evaluatieprocedures met een gespecifi ceerde tijdslimiet kunnen ervoor zorgen dat change-evalu-aties niet worden verwaarloosd. Afhankelijk van de aard van de change kan een evaluatie plaats-vinden na een paar dagen een of naar een paar maanden.

Ondanks alle planningen kan het toch voorkomen dat een change onmiddellijke voorrang moet krijgen. Urgente changes zijn erg belangrijk en moeten zo spoedig mogelijk worden uitgevoerd. In de meeste gevallen worden resources van andere activiteiten afgehaald en ingezet op deze chan-ges. Urgente changes kunnen een ernstige impact hebben op het geplande werk. Daarom moet er worden gestreefd naar zo weinig mogelijk urgente of onverwachte changes (met prioriteit: ‘hoogste’). Preventieve maatregelen hiertoe zijn:• Ervoor zorgen dat changes op tijd worden aangevraagd, voordat ze urgent worden.• Bij het oplossen van fouten die het gevolg zijn van een slecht voorbereide change, moet de

change niet verder worden teruggedraaid dan de vorige versie: de zogenaamde ‘previous trus-ted state’. Daarna kan een verbeterde implementatie zorgvuldig worden voorbereid.

Ondanks bovengenoemde maatregelen kunnen er toch urgente changes optreden en daarvoor zijn procedures nodig die een snelle afhandeling mogelijk maken, zonder dat changemanagement de control op het proces verliest. Als er voldoende tijd is, kan de changemanager een emergency CAB-overleg (ECAB) plannen. Hiervoor worden alleen degenen uitgenodigd die nodig zijn voor goedkeuring, evaluatie en resourcetoewijzing. Als er geen tijd is, of als de change request buiten kantooruren is ingediend, dan moet de goedkeuring op een alternatieve manier worden verkre-gen. Bij een ECAB hoeft men niet per se lijfelijk aanwezig te zijn, dit kan ook via bijvoorbeeld video of teleconferentie.



Het kan ook voorkomen dat er onvoldoende tijd is voor het reguliere testtraject. Daarom moeten alle fasen van de testprocedure na de implementatie volledig worden uitgevoerd. Hiermee wordt geborgd dat alle testen alsnog worden uitgevoerd, alle bestanden worden bijgewerkt en de change traceerbaar is: “Wat is er veranderd?”.

Changemanagement streeft naar een balans tussen fl exibiliteit en stabiliteit. Om de actuele situa-tie van de organisatie weer te geven, kunnen de volgende managementrapporten worden geleverd:• aantal geïmplementeerde changes in een bepaald periode (totaal en per CI)• lijst van oorzaken van changes en RfC’s• aantal geïmplementeerde changes die succesvol zijn• aantal gevallen van terugval (back-outs) en de redenen daarvoor• aantal incidenten die samenhangen met de uitgevoerde changes• grafi eken en trendanalyses voor relevante perioden

KPI’s voor changemanagement zijn:• aantal changes dat per tijdseenheid, per categorie is afgerond• snelheid waarmee changes worden geimplementeerd• aantal afgewezen changes• aantal incidenten als gevolg van changes• aantal terugvallen (back-outs) gerelateerd aan changes• kosten van geimplementeerde changes• aantal changes dat binnen geschatte resources en tijd is uitgevoerd

Meerdere RfC’s kunnen worden gecombineerd tot een release. In dat geval zal een enkel terug-valplan volstaan als er iets misgaat. Een dergelijk gebundelde release kan als een change worden beschouwd, ook al bestaat het uit meerdere changes die onafhankelijk van elkaar moeten worden goedgekeurd. Releases worden uitgevoerd door releasemanagement. Dit is het onderwerp van de volgende paragraaf.

4.2.4 Releasemanagementproces (10.1)

Doelstelling: Het leveren, distribueren en volgen van een of meer changes binnen een release in een productieomgeving.


NOOT: Het releasemanagementproces behoort te zijn geïntegreerd met het confi guratie- en changemanagementproces.

Het releasebeleid waarin de frequentie en het type van de releases beschreven staat, moet worden gedocumenteerd en goedgekeurd.De serviceprovider moet samen met de business een planning maken voor de release van services, systemen, software en hardware.Alle betrokken partijen, bijvoorbeeld klanten, gebruikers, productie, supportmedewerkers, moeten goedkeuring geven aan plannen voor de wijze waarop de uitrol van de release plaatsvindt.



In het proces moet zijn opgenomen op welke wijze de change moet worden teruggedraaid of gecorrigeerd als deze niet succesvol is.Plannen moeten de releasedata en deliverables bevatten en verwijzen naar de gerelateerde change requests, known errors en problems. Het releasemanagementproces moet zinvolle informatie doorgeven aan het incidentmanagementproces.Requests for change moeten worden beoordeeld op hun impact op releaseplannen.Het actualiseren en wijzigen van confi guratie-informatie en changerecords moet deel uitmaken van releasemanagementprocedures. Emergency releases moeten worden gemanaged volgens een gedefi nieerd proces dat aansluit op het emergency changemanagementproces .Er moet een gecontroleerde acceptatietestomgeving worden opgezet om alle releases te bouwen en te testen voordat ze worden gedistribueerd.Release en distributie moeten zodanig worden ontwikkeld en geïmplementeerd dat de inte-griteit van de hardware en software geborgd blijft tijdens installatie , transport, verpakking en levering.Het succes en falen van releases moet worden gemeten. Metingen moeten de incidenten omvatten die gerelateerd zijn aan een release en in de periode vallen die op de release volgt. De analyse moet tevens de impact bepalen die de release heeft op de personeelresources van de business, IT-productie en de helpdesk. Deze informatie levert input op voor een serviceverbeterplan.


AlgemeenReleasemanagement behoort de activiteiten te coördineren van de serviceprovider, vele leveranciers en de business, om een release te plannen en te distribueren over verspreide locaties.Goede planning en management zijn essentieel om een release samen te stellen en met succes te distri-bueren, en de verbonden impact en risico’s voor business en IT te managen. De release van betrokken informatiesystemen, infrastructuur, services en documentatie hoort samen met de business te worden gepland. Alle verbonden updates van documentatie horen in de release te worden opgenomen; bijvoorbeeld van bedrijfsprocessen, supportdocumenten en service level agreements.Van alle nieuwe of gewijzigde confi guratie-items die nodig zijn om de geautoriseerde changes te reali-seren, hoort de impact te worden beoordeeld. De serviceprovider hoort ervoor te zorgen dat zowel technische als niet-technische aspecten van de release tezamen in ogenschouw worden genomen.De release-items horen traceerbaar te zijn en beveiligd tegen mutaties.Alleen releases die naar behoren zijn getest en goedgekeurd, horen in de productieomgeving te worden geaccepteerd.

ReleasebeleidEr hoort een releasebeleid te zijn waarin de volgende informatie is opgenomen:a) frequentie van releases en type releaseb) rollen en verantwoordelijkheden van releasemanagementc) autoriteit voor de vrijgave naar acceptatietesten productieomgevingen d) unieke identifi catie en beschrijving van alle releasese) aanpak voor groeperen van changes in een release



f ) aanpak voor het automatiseren van de processen voor samenstelling, installatie, releasedistributie, ter ondersteuning van herhaalbaarheid en effi ciëntie

g) verifi catie en acceptatie van een release

Planning van release en uitrolDe serviceprovider hoort met de business samen te werken om ervoor te zorgen dat de confi guratie-items die moeten worden vrijgegeven, verenigbaar zijn met elkaar en met confi guratie-items in de doelomgeving.Releaseplanning hoort ervoor te zorgen dat de changes van betrokken informatiesystemen, infrastruc-tuur, services en documentatie, worden goedgekeurd, geautoriseerd, ingepland, gecoördineerd en ge-traceerd. De release en de uitrol horen per fase te worden gepland, omdat het kan zijn dat details van de uitrol in het begin nog niet bekend zijn.

De planning voor een release en een uitrol hoort de volgende informatie te bevatten:a) releasedata en beschrijving van deliverablesb) gerelateerde changes, problems en known errors die door deze release zijn afgesloten of opgelost en

known errors die zijn geïdentifi ceerd tijdens het testen van de releasec) gerelateerde processen om een release te implementeren over alle business- en geografi sche units heend) de wijze waarop de release zal worden teruggezet of gecorrigeerd als hij niet succesvol ise) verifi catie- en acceptatieproces f ) communicatie, voorbereiding, documentatie en training voor klant en supportmedewerkersg) logistiek en processen om goederen in te kopen, op te slaan, af te leveren, aan te sluiten, te accepteren

en van de hand te doen h) supportresources die nodig zijn om ervoor te zorgen dat servicelevels behouden blijveni) de identifi catie van afhankelijkheden, gerelateerde changes en verbonden risico’s die de soepele over-

dracht van een release naar de acceptatietest en productieomgevingen kunnen beïnvloeden j) sign-off (aftekening) van de releasek) tijdschema van audits van de productie-omgeving - indien nodig voor grootschalige upgrades - om

ervoor te zorgen dat de productie-omgeving in de verwachte staat is bij de installatie van de release

Ontwikkeling of aanschaf van softwareInformatiesystemen en softwarereleases van interne teams, systeembouwers, systeemintegreerders of an-dere organisaties horen bij ontvangst te worden gecontroleerd. Het gehele proces hoort te worden gedocumenteerd in het confi guratiemanagementplan.

Ontwerp, samenstelling en confi guratie van de releaseRelease en distributie horen zo te worden ontworpen en geïmplementeerd dat:a) geconformeerd wordt aan de systeemarchitectuur, servicemanagement- en infrastructuurstandaar-

den van de serviceproviderb) gezorgd wordt voor behoud van integriteit tijdens de samenstelling, installatie, vervoer, verpakking

en distributiec) gebruik wordt gemaakt van softwarebibliotheken en gerelateerde depots om componenten tijdens

het samenstelling- en releaseproces te managen en beheersend) risico’s helder zijn gedefi nieerd en indien nodig tussentijdse actie kan worden genomene) voor de installatie geverifi eerd kan worden dat het doelplatform aan de basisvoorwaarden voldoetf ) bij aankomst op de bestemming kan worden geverifi eerd of de release compleet is



De output van dit proces hoort releasenotes, installatie-instructies, geïnstalleerde software en hardware met de gerelateerde confi guratie-uitgangspunt te omvatten. De output van de release hoort te worden overgedragen aan de groep die verantwoordelijk is voor het testen. Processen voor de samenstelling, installatie, release en distributie kunnen worden geautomatiseerd om fouten te beperken, en te borgen dat het proces herhaalbaar is en nieuwe releases snel kunnen worden uitgerold.

Verifi catie en acceptatie van de release Het eindresultaat hoort een sign-off (aftekening) te zijn van de volledigheid van de hele releasepackage ten opzichte van de eisen.

De verifi catie- en acceptatieprocessen behoren: a) te verifi ëren dat de gecontroleerde acceptatietestomgeving overeenstemt met de eisen van de target-

productieomgevingb) ervoor te zorgen dat de release wordt gecreëerd vanuit versies die onder confi guratiemanagement

vallen en dat de release in de acceptatietestomgeving wordt geïnstalleerd met gebruik van het ge-plande productieproces

c) te verifi ëren dat het passende testniveau is voltooid; bijvoorbeeld, functionele en niet-functionele testen, businessacceptatietesten, testen van de procedures voor samenstelling, release, distributie en installatie

d) ervoor te zorgen dat de release is getest naar tevredenheid van de medewerkers van de klant en de serviceprovider

e) ervoor te zorgen dat elke fase van de acceptatietest wordt afgetekend door de juiste release-autoriteitf ) voor de installatie te verifi ëren dat het doelplatform voldoet aan de basisvoorwaarden van software

en hardwareg) te verifi ëren dat een release bij aankomst op bestemming volledig is

DocumentatieBij voltooiing hoort er passende documentatie beschikbaar te zijn en deze hoort bij confi guratiema-nagement te worden opgeslagen, bij het vrijgegeven confi guratie-item. Deze documentatie hoort te omvatten:a) supportdocumentatie, bijvoorbeeld service level agreementsb) supportdocumentatie, bijvoorbeeld systeemoverzicht, installatie- en supportprocedures, meetinstru-

menten voor foutdiagnose, bedienings- en administratie-instructies c) processen voor samenstelling, release, installatie en distributied) rampen- en terugvalplannene) trainingsschema voor servicemanagement, supportmedewerkers en klantenf ) een confi guratie-uitgangspunt voor de release, inclusief verbonden confi guratie-items zoals systeem-

documentatie, testomgevingen, testdocumentatie, versies van bouwen ontwikkeltoolsg) gerelateerde changes, problems en known errorsh) bewijs van autorisatie van de release en hiermee samenhangend bewijs van verifi catie en acceptatie

Uitrol, distributie en installatieHet uitrolplan hoort te worden gereviewd en indien nodig worden aangevuld met details, om zodoende te borgen dat alle benodigde activiteiten zullen worden uitgevoerd.



Het is belangrijk dat de release veilig en in de verwachte staat op de bestemming wordt afgeleverd. De uitrol-, distributie - en installatie processen horen ervoor te zorgen dat:a) alle opslagplaatsen voor hardware en software veilig zijnb) er geschikte procedures zijn voor de opslag, verzending, ontvangst en overdracht van goederenc) controles van installatie, omgeving, elektronica en faciliteiten zijn gepland en voltooidd) dat het personeel van de klant en van de serviceprovider op de hoogte zijn gesteld van nieuwe relea-

sese) overbodige producten, services en licenties uit bedrijf worden genomen

Na de distributie van software in een netwerk is het essentieel om te controleren of de release bij bereik van bestemming volledig en operationeel is. Na een succesvolle installatie horen de records van asset- en confi guratiemanagement te worden geac-tualiseerd met de locatie en de eigenaar van de hardware en de software.Een klantacceptatie- en tevredenheidsenquete kan worden gebruikt om succes of falen van de instal-latie in kaart te brengen. Resultaten van alle klantonderzoeken behoren naar klantrelatiemanagement te worden teruggekop-peld.

Post-release en uitrolHet aantal incidenten dat is gerelateerd aan de release, in de periode die onmiddellijk op een uitrol volgt, hoort te worden gemeten en geanalyseerd om te beoordelen welke impact ze hebben op de busi-ness, de productie en de resources voor supportpersoneel.Het changemanagementproces hoort een post implementation review te omvatten.Aanbevelingen horen te worden verwerkt in een serviceverbeterplan.

Figuur 4.2.10 visualiseert dit deel van de standaard in een procesfl ow

De belangrijkste processtappen van releasemanagement zijn: ontwikkelen van een releasebeleid , plannen, ontwerpen, bouwen en confi gureren, testen en accepteren, uitrollen, distribueren en installeren, en controleren van een release. De uitkomst van de laatstgenoemde controle is de registratie van een geslaagde of mislukte release in een record. Deze records zijn input voor het serviceverbeterplan. Het enige document dat echt verplicht is voor releasemanagement is het releasebeleidsdocument en de enige records die echt moeten worden vastgelegd zijn de release-datums, deliverables (op te leveren producten), referenties naar change requests, known errors en problems.

In ISO 20000 heeft het releasemanagementproces drie interfaces:1. met het changemanagementproces, voor het beoordelen van de impact die RfC’s hebben op

de releaseplannen2. met het changemanagementproces, voor het actualiseren van changerecords3. met het emergencymanagementproces, voor het managen van emergencyreleases

Andere gedefi nieerde interfaces zijn de interface naar het incidentmanagementproces, voor het doorgeven van geschikte informatie en de interface naar het confi guratiemanagementproces, voor het actualiseren van assets en confi guratierecords.



Maak frequentie entype releases bekend

Bepaaltestacceptatieomgeving

Releasebeleid

Lever inputvoor het SIP

Release- enroll-outplan

Met inbegrip van dewijze waarop de releasehoort te wordenherroepen of hersteldals deze niet succesvolverloopt.

Registreer releasedataen –deliverables enverwijs naargerelateerde requestsfor change, knownerrors en problems

In beheersteacceptatietestomgeving

Met inbegrip van:- metingen van releasegerelateerde incidenten - beoordeling van de impact op business, IT-operations

Records vanreleasesuccessen

en – mislukkingen,en verbeterkansen

Communicatie-,voorbereidings- entrainingsplanneninbegrepen

Aangeschaftesoftware inbegrepen

Releasenotes

Installatie-instructies

Configuratie-uitgangspunt

Documentatie metinbegrip van: - ondersteunende documentatie, bijvoorbeeld SLA's, systeemoverzicht, installatie- en ondersteunings- procedures, instrumenten voor foutendiagnose, bedienings- en administratieve instructies- bouw-, release-, installatie- en distributieprocessen- rampen- en terugvalplan- trainingschema's- configuratie-uitgangspunt- gerelateerde changes, problems en known errors- bewijs van autorisatie, verificatie en acceptatie

Met inbegrip vanactualisatie van allebijbehorendedocumentatie

Aftekening

Rapportage overafwijkingen aan

problem- enincidentmanagement

Moet wordenafgetekend door erkenderelease-autoriteit

Gedefinieerde interfacemet het emergencychangemanagementproces

Beoordeelimpact van RfC'sop releaseplan.

Documenteer enaccordeer

releasebeleid

Plan uitrol releaseen informeer

incidentmanagement

Ontwerp, bouwen configureer

de releaseReleasenotes

Installatie-instructies

Configuratie-uitgangspunt

Uitrolplan

Test en acceptatievan release

Identificeer enregistreer afwijkingen

van de eisen(known errors)

Uitrol, distributie eninstallatie van

(emergency)release

KlantonderzoekMeet en analyseersuccesvolle release

Herstel/herroeprelease als

niet succesvol

Eisen

Records vanreleasesuccessen

en – mislukkingenen verbeterkansen

Actualisatie vanconfiguratie enchangerecords

Sign-off (aftekening)op volledigheid tenopzichte van eisen

Interfaces:

Continue verbetering (Act)- stel verbeteringen voor SIP voor

Configuratiemanagement- actualiseer asset- en configuratie-informatierecords

Changemanagement:- Beoordeel RfC's voor hun impact op releaseplannen- actualiseer changerecords- manage emergencyreleases volgens het emergency changemanagementproces


Budgettering en accounting- budgetteer en verantwoord alle componenten

Incident management:- wissel relevante informatie uit

Figuur 4.2.10 Releasemanagement



RichtlijnenZoals eerder gezegd, meerdere RfC’s kunnen worden gebundeld in een release. Releases worden gepland met een functioneel doel voor het bedrijf, in het algemeen als onderhoudsreleases. Relea-ses kunnen bestaan uit hardware en software en worden uitgevoerd door releasemanagement. Het is aan te bevelen releasebeleid te defi nieren en dit beleid te communiceren aan de IT-organisatie en de gebruikers. Het beleid is er op gericht onnodige verstoringen voor de gebruiker te vermij-den (zoals elke week de weg opbreken).

Releasemanagement bestaat uit de volgende activiteiten:• releasebeleid en -planning• releases ontwerpen, bouwen en samenstellen• testen en release-acceptatie• uitrolplanning• communicatie, voorbereiding en training• releasedistributie en -installatie Deze activiteiten zijn niet echt chronologisch. Releasebeleid en planning kunnen elke zes maan-den of jaarlijks plaatsvinden terwijl de andere activiteiten dagelijks plaatsvinden. Figuur 4.2.11 laat de releasemanagementactiviteiten zien.

De releasemanager stelt van tevoren een releasebeleid op waarin wordt bepaald hoe en wanneer releases worden samengesteld. Major releases kunnen vooruit worden gepland, met inbegrip van de release-identifi catie of het versienummer zodat rekening kan worden gehouden met het toevoegen van changes.

De releasemanager specifi ceert ook op welk niveau CI’s onafhankelijk van elkaar kunnen worden gedistribueerd (release-units). De keuze is afhankelijk van het soort systeem dat onder release-control valt :

OntwikkelomgevingBeheerste

testomgevingProductieomgeving

Release-beleid

Release-planning

Ontwerp enontwikkel,of bestel en

schafsoftware aan

Bouw enconfigureerde release

Fit-for-purposetest

Communicatie-voorbereiding

en training

Distributie &installatie

Configuratiemanagementdatabase (CMDB)en

Definitive Software Library (DSL)

Releasemanagement

Release-acceptatie

Uitrol-planning

Figuur 4.2.11 Releasemanagementactiviteiten volgens ITIL V2 (Bron: OGC)



• de impact die de release kan hebben op andere componenten• het aantal mensuren en de doorlooptijd die nodig zijn om een opzichzelfstaande change te

bouwen en te testen, in verhouding tot wat het kost om er een aantal op te sparen en tegelij-kertijd uit te voeren

• de moeilijkheidsgraad van een eventuele installatie bij de gebruikers; zo kan het bijvoorbeeld eenvoudiger zijn een compleet programma te installeren omdat daar al standaardscripts en procedures voor zijn

• de complexiteit van de afhankelijkheden tussen de nieuwe software, de hardware en de rest van de IT-infrastructuur; hoe eenvoudiger het is de software of hardware te isoleren, des te eenvoudiger is het deze te testen

Voordat een release kan worden gepland, moet er informatie worden verzameld over de levens-cyclus van het product, over de producten die moeten worden overgedragen, de beschrijving van de relevante IT-service en service levels, en de goedkeuring van de relevante RfC’s.

Bij het plannen van een release moet met de volgende zaken rekening worden gehouden:• coördineren van de inhoud van een release• afspraken maken over fasering in tijd, locaties en organisatieonderdelen• opstellen van een releaseplanning• opstellen van een communicatieplan• bezoeken van locaties om te onderzoeken welke hard- en software daadwerkelijk in gebruik

zijn• afstemmen van rollen en verantwoordelijkhedenopvragen van gedetailleerde tarieven en on-

derhandelen met leveranciers over nieuwe hardware, software en installatiekosten• opstellen van terugvalplannen• opstellen van een kwaliteitsplan voor de release• planning van release-acceptatie door het management team en de gebruikers

De resultaten van deze activiteiten maken deel uit van het changeplan en bestaan uit releaseplan-nen, testplannen en acceptatiecriteria.

Het is aan te bevelen om standaardprocedures te ontwikkelen voorhet ontwerpen, bouwen en confi gureren van releases. De samenstelling van een release kan zijn gebaseerd op een aantal componenten (CI’s) die intern zijn ontwikkeld of gekocht van derden en geconfi gureerd. Ook de montagevoorschriften en de instructies voor het samenstellen van de re-lease moeten worden behandeld als een onderdeel van de release en moeten als CI onder control van changemanagement en confi guratiemanagement zijn gebracht.

De hard- en software moet in een testomgeving worden getest, voordat u overgaat tot de instal-latie op locatie. De hard- en softwarecomponenten van een release moeten zorgvuldig worden samengesteld en geregistreerd, zodat ze reproduceerbaar zijn. Er moeten gebruiksaanwijzingen worden opgesteld om te borgen dat steeds dezelfde set van CI’s wordt gebruikt. Meestal wordt er standaardhardware gereserveerd die alleen gebruikt wordt voor het compileren of maken van ‘images’. Dit deel van het proces wordt bij voorkeur geautomatiseerd om het betrouwbaarder te maken.



In een terugvalplan (back-outplan) voor de gehele release staan de activiteiten die nodig zijn om de service te herstellen als er iets misgaat met de release. Het opstellen van terugvalplannen is de verantwoordelijkheid van changemanagement, maar releasemanagement hoort mee te werken aan het borgen van de bruikbaarheid van de plannen. Het is aan te bevelen om vooraf aan de eisen van het terugvalplan te voldoen, denk bijvoorbeeld aan het maken van back-ups of beschik-baar maken van een reserve-server. Het terugvalplan moet onderdeel zijn van de risiscoanalyse van de change en de gebruikers moeten het plan hebben goedgekeurd.

De daadwerkelijke samenstelling van de release kan bestaan uit compilatie en koppeling van de software-modules en vulling van de databases met testdata of data zoals postcodetabellen, belas-tingtarieven, tijdzones en gebruikersinformatie. Dit wordt meestal afgehandeld door automati-sche installatiescripts uit de DSL. Volledige releases horen in de CMDB te worden vastgelegd als confi guratie-uitgangspunt zodat ze voor toekomstige wijzigingen kunnen worden gebruikt. Testplannen beschrijven het testen en de acceptatiecriteria van de software en hardware; proce-dures, gebruiksaanwijzingen en uitrolscripts voor de release maar ook evaluatietesten voor na de release. De informatie die voor deze activiteit nodig is, omvat:• de defi nitie van de release• de releaseplanning• instructies voor het samenstellen en bouwen van de release• omschrijving en volgorde van de benodigde aankopen en licenties• geautomatiseerde installatiescripts en testplannen• bronkopieën van de software in de DSL• terugvalprocedures

Voorafgaand aan de implementatie moet een vertegenwoordiging van de eindgebruikers de re-lease functioneel testen en personeel van de IT-afdeling moet de release operationeel testen. De IT’ers kijken naar de technische en operationele aspecten, performance en integratie met de rest van de infrastructuur. Installatiescripts, terugvalprocedures en wijzigingen van managementpro-cedures moeten ook te worden getest. Elke stap moet formeel door changemanagement worden goedgekeurd. De laatste stap is de goedkeuring van de release voor implementatie. Changema-nagement moet zorgen voor de formele gebruikersacceptatie en de sign-off van het ontwikkel-team voordat releasemanagement kan starten met de uitrol van de release.

Releases moeten worden geaccepteerd in een gecontroleerde testomgeving die kan worden terug-gezet naar de confi guratie-uitgangspunt. Deze uitgangssituatie van de release hoort te worden omschreven in de release-defi nitie en hoort te zijn opgenomen in de CMDB. Als de release wordt afgekeurd, wordt hij teruggestuurd naar changemanagement als mislukte change.

De resultaten van deze activiteiten zijn onder meer:• geteste installatieprocedures• geteste releasecomponenten• known errors en tekortkomingen in de release• testresultaten• documentatie voor management en support• lijst met betrokken systemen• instructies voor operations en diagnostische tools



• rampenplannen en geteste uitvalplannen• trainingsprogramma voor personeel, managers en gebruikers• ondertekende acceptatiedocumenten• goedkeuring van change voor de release

Het releaseplan dat eerder is opgesteld wordt nu aangevuld met informatie over de implementa-tieactiviteiten en planning, de uitrolplanning. De uitrolplanning omvat:• het opstellen van een exact tijdschema en een overzicht van taken en benodigde mankracht• het maken van een lijst van de te installeren CI’s, de uit te faseren CI’s en de gekozen manier

van uitfaseren• het schrijven van een activiteitenplan per implementatielocatie, rekening houdend met be-

schikbare releasemomenten en, in geval van een internationale organisatie, verschillende tijd-zones

• het uitsturen van release-memo’s en andere communicatie naar de belanghebbenden• het maken van plannen voor de aanschaf van hard- en software• de daadwerkelijke aanschaf, veilige opslag, identifi catie en registratie in de CMDB van alle

nieuwe CI’s die bij de release horen• het inplannen van de benodigde vergaderingen met het management, de managementafdelin-

gen, changemanagement en de vertegenwoordigers van de gebruikers Er bestaan verschillende opties voor een uitrol van een release:• De release wordt in één keer geheel uitgerold, de zogenaamde ‘bigbangaanpak’.• De release wordt gefaseerd uitgerold, waarbij combinaties zijn te maken van verschillende

vormen zoals:– aanvullingen (incrementen) per functie, waarbij alle gebruikers tegelijkertijd een functie

erbij krijgen– aanvullingen per locatie, waarbij de functionaliteit per groepgebruikers wordt uitgebreid – evolutionair, waarbij de functionaliteit in fasen geleidelijk wordt uitgebreid

Medewerkers die contact onderhouden met klanten (servicedesk en klantrelatiemanagement), operationsmedewerkers en vertegenwoordigers van de gebruikersorganisatie, moeten op de hoogte zijn van de plannen en van de invloed die de uitrol van de release kan hebben op de da-gelijkse activiteiten. Dit kan worden gerealiseerd met behulp van gezamenlijke trainingssessies, samenwerking en een gemeenschappelijke betrokkenheid bij de acceptatie van releases. Er moet aandacht worden besteed aan het communiceren van verantwoordelijkheden en daarbij moet worden gecontroleerd of iedereen die verantwoordelijkheden begrijpt. Als de release gefaseerd wordt uitgerold, dan moeten de gebruikers daarvan op de hoogte worden gesteld door ze te in-formeren over de plannen en de nieuwe functionaliteit.

Wijzigingen aan service level agreements (SLA’s), operational level agreements (OLA’s) en under-pinning contracts (UC’s) moeten tijdig worden doorgegeven aan alle betrokken medewerkers.

Releasemanagement monitort de logistieke processen voor aankoop, opslag, transport, levering en overdracht van hard- en software. Dit proces wordt ondersteund door procedures en docu-mentatie zoals pakbonnen, wat betrouwbare informatie oplevert voor confi guratiemanagement. De opslagfaciliteiten voor hard- en software moeten zijn beveiligd en alleen toegankelijk zijn voor bevoegd personeel.



Het is aan te bevelen om zoveel mogelijk gebruik te maken van geautomatiseerde tools voor softwaredistributie en -installatie. Dit verlaagt de distributietijd en verhoogt de kwaliteit, terwijl minder resources nodig zijn. Deze tools verifi eren meestal ook of de installatie goed is gegaan. Daarnaast is het raadzaam om voorafgaand aan elke installatie na te gaan of de omgeving waarin de release plaatsvindt aan de eisen voldoet, zoals voldoende diskruimte, beveiliging, klimaat, ruimte UPS/stroom.

Na de installatie moet de CMDB worden bijgewerkt met informatie over de licenties.

Planning en implementatie van releasemanagement is erg afhankelijk van confi guratie- en chan-gemanagement. Daarnaast moeten de volgende zaken continu worden beoordeeld en verbeterd:• richtlijnen over releaseniveaus, typen, eenheden, identifi catie, frequentie, planning, scope en

documentatie • procedures van releaseactiviteiten die eerder zijn genoemd• rollen en verantwoordelijkheden van de medewerkers, vooral die van releasemanagement• tools, inclusief managementtools, CMDB-tools en confi guratiemanagementtools voor soft-

ware

4.3 Alignment van IT en de business

4.3.1 Serviceleveringsproces: servicelevelmanagement (6.1)

Doelstelling: Het defi niëren, overeenkomen, vastleggen en managen van servicelevels.


De partijen moeten instemmen met het complete aanbod van services dat moet worden geleverd, samen met de bijbehorende serviceleveltargets en werklastkenmerken , en ze moeten dit vastleggen.Elke geleverde service moet worden gedefi nieerd, overeengekomen, en vastgelegd in één of meerdere service level agreements (SLA’s). Alle betrokken partijen moeten overeenstemming bereiken over de SLA’s, de ondersteunende serviceovereenkomsten, leverancierscontracten en bijbehorende procedures en ze moeten dit vastleggen. De SLA’s vallen onder de verantwoordelijkheid van het changemanagementproces. De betrokken partijen moeten de SLA’s onderhouden door regelmatig reviews uit te voeren en hiermee te borgen dat ze up-to-date zijn en effectief blijven. Servicelevels moeten worden gemonitord en gerapporteerd met oog op de targets, en zowel huidige informatie als trends weergeven. De redenen voor afwijkingen van de servicelevels moeten worden gerapporteerd en gereviewd. Verbeteracties die tijdens dit proces zijn bepaald, moeten worden vastgelegd en vormen de input voor een serviceverbeterplan.




ServicecatalogusEen servicecatalogus hoort alle services te defi niëren. Er kan naar worden verwezen vanuit de SLA en hoort informatie te bevatten die als te vluchtig wordt beschouwd voor de SLA zelf. De servicecatalogus hoort te worden onderhouden en up-to-date gehouden.

NOOT. De servicecatalogus kan generieke informatie bevatten, zoals:a) de naam van de serviceb) targets, bijvoorbeeld tijd om een printer af te stemmen of te installeren, tijd om een service te herstel-

len na een grootschalige foutc) contactpuntend) service-uren en uitzonderingene) securityregelingen

De servicecatalogus is een kerndocument voor het bepalen van de verwachtingen van de klant en hoort gemakkelijk toegankelijk te zijn en breed beschikbaar, zowel voor personeel van de klant als supportpersoneel.

Service level agreements (SLAs)Een service hoort formeel te worden gedocumenteerd in een service level agreement (SLA). De SLA hoort formeel te worden geautoriseerd door senior vertegenwoordigers van de klant en de serviceprovi-der. De SLA hoort onder toezicht te staan van changemanagement, net als de service die erin wordt beschreven.

De bedrijfsbehoeften en het budget van de klant horen de drijvende kracht te vormen voor de defi nitie van de inhoud, structuur en targets van de SLA. De targets waar de geleverde service tegen hoort te worden afgemeten, horen te worden gedefi nieerd vanuit het perspectief van de klant. De SLAs horen slechts een passende subset van de targets te bevatten, zodat de aandacht wordt gericht op de belangrijkste aspecten van de service.

NOOT 1. Teveel targets kunnen verwarring aanrichten en leiden tot buitensporige overhead-kosten.De minimuminhoud die een SLA hoort te hebben of waar de SLA direct naar kan verwijzen is:a) korte beschrijving van de serviceb) geldigheidsperiode en/of controlemechanisme voor een wijziging in de SLAc) details over autorisatied) korte beschrijving van communicatie, inclusief rapportagee) contactgegevens van mensen die zijn geautoriseerd om te handelen bij emergencies, te participeren

in de correctie van incidenten en problems, bij herstel of workaroundf ) service-uren, bijvoorbeeld 9.00 uur tot 17.00 uur, uitzonderingsdata (bijvoorbeeld weekends, al-

gemene vakantiedagen), dekking van kritieke bedrijfsperioden en van tijd buiten kantooruren g) ingeplande en overeengekomen onderbrekingen, inclusief mededelingen die moeten worden gedaan,

aantal per periodeh) klantverantwoordelijkheden, bijvoorbeeld securityi) aansprakelijkheid en verplichtingen van de serviceprovider, bijvoorbeeld securityj) richtlijnen voor impact en prioriteitk) escalatie- en kennisgevingsprocesl) klachtenprocedure



m) servicetargetsn) grenzen aan de werklast (boven en onder), bijvoorbeeld het vermogen van de service om het over-

eengekomen aantal gebruikers/werkomvang en systeemdoorvoer te ondersteuneno) gedetailleerde gegevens voor fi nancieel management, bijvoorbeeld kostencodesp) actie die moet worden genomen bij een serviceonderbrekingq) administratieve proceduresr) verklarende woordenlijsts) ondersteunende en gerelateerde servicest) alle uitzonderingen op de voorwaarden die in de SLA zijn geboden

NOOT 2. Vanuit de SLA kan worden verwezen naar vluchtige informatie, of informatie die veel SLA’s gemeenschappelijk hebben (zoals contactgegevens), zonder dat dit de kwaliteit van SLM-proces-sen aantast, zolang de documenten waar naar verwezen wordt maar onder beheer van het changema-nagementproces vallen.

NOOT 3. Gewoonlijk wordt vanuit de SLA verwezen naar het continuïteitsplan en de accounting- en budgetteringsdetails.

NOOT 4. Een verklarende woordenlijst wordt gewoonlijk op één plaats bewaard en wordt gedeeld door alle documenten, inclusief de servicecatalogus.

Servicelevelmanagement (SLM) procesGrootschalige bedrijfsveranderingen, bijvoorbeeld groei, bedrijfsreorganisaties en -fusies, en verande-rende klanteisen, kunnen vereisen dat de servicelevels worden aangepast, geherformuleerd of zelfs tij-delijk worden bevroren. Het SLM-proces hoort bijdragen aan de servicelevels te managen en coördineren, hieronder vallen:a) overeenkomst over service-eisen en verwachte werklastkenmerken van de serviceb) overeenkomst over servicetargetsc) meting van en rapportage over de behaalde servicelevels, werklast en een verklaring als niet is vol-

daan aan de overeengekomen targets (zie ISO 20000-2, sectie 6.2: Servicerapportage, sectie 4.3.2 over servicerapportage in dit boek)

d) initiëren van correctieve actiee) input voor een serviceverbeterplan

Het proces hoort zowel de serviceprovider als de klant te stimuleren om een proactieve houding aan te nemen, waardoor wordt geborgd dat ze gezamenlijk verantwoordelijkheid dragen voor de service.Klanttevredenheid is een belangrijk onderdeel van servicelevelmanagement maar het hoort te worden beschouwd als een subjectieve maat, terwijl servicedoelen in een SLA een objectieve maat horen te zijn. Het SLM-proces hoort nauw samen te werken met klantrelatiemanagement- en leveranciersmanage-mentprocessen.

Ondersteunen van serviceovereenkomstenDe ondersteunende service waarvan de geleverde service afhankelijk is hoort te worden gedocumen-teerd en overeengekomen met elke leverancier. Hiertoe behoren ook interne groepen die een deel van de service van de serviceprovider bieden.




SLA

Leverancierscontracten

Accordeer enregistreer services,

targets enwerklastkenmerken

Definieer,accordeer en

documenteer elkegeleverde service

Monitor servicelevelsmet oog op targets

Rapporteerservicelevels metoog op targets

Toont redenen voor afwijkingen aan

Review hetservicelevelrapport

en registreerverbeteracties

Ondersteunendeserviceovereenkomsten

Overeenkomstigeprocedures

Lever input voor SIPVerbeteracties

Verbeteracties

Servicelevelrapport

Records vanservices, targets enwerklastkenmerken

Servicecatalogus

Onderhoudservicecatalogus

Servicecatalogus Servicecatalogus

Bedrijfsbehoeftenen budget van

de klant

Spreek voor iedere klantgroepen service af:- maximaal aanvaardbare aaneengesloten periode van verloren service- maximaal aanvaardbare perioden van verminderde service- aanvaardbare verlaagde servicelevels gedurende een periode van serviceherstel- gezamenlijke betrokkenheid bij continuïteit- en beschikbaarheidstesten

Interfaces:

Continue verbetering (Act)- manage verbeteractiviteiten- doe verbetervoorstellen voor SIP

Changemanagement:- beheers de SLA- dien een request for change in


Budgettering en accounting:- budgetteer en verantwoord alle componenten

Klantrelatiemanagement:- SLA- en servicelevelreview


Servicecontinuïteit en beschikbaarheidsmanagement:- spreek servicelevels af voor elke klantgroep en service- beoordeel impact op servicecontinuïteitsdocumentatie voordat afspraken worden gemaakt over klanteisen

Figuur 4.3.1 Servicelevelmanagement



Servicelevelmanagement bestaat uit een serie activiteiten:• opstellen servicecatalogus• overeenkomen servicelevering• monitoren servicelelevels• rapporteren resultaten• beoordelen servicelevels

Het beoordelen van de servicelevels moet leiden tot een serviceverbeterplan.

Changemanagent behoort wijzigingen aan de servicelevels te beheren. De interface tussen change- en servicelevelmanagement moet worden gedocumenteerd, evenals de interface met het continue verbeterproces dat alle serviceverbeteringen beoordeelt, vastlegt, prioriteert en autoriseert.

RichtlijnenServicelevelmanagement bestaat uit de volgende activiteiten:• behoeften identifi ceren• eisen defi nieren• servicelevels overeenkomen• performance monitoren• performance rapporteren• performance reviewen

Omdat ISO 20000 een apart proces heeft voor servicerapportage, wordt dit besproken in 4.3.2.

De waargenomen kwaliteit van een service hangt af van de verwachtingen van de klant, het door-lopende management van de klantperceptie, de stabiliteit van de service en de aanvaardbaarheid van de kosten. Om de meest geschikte kwaliteit te leveren is het daarom beter om eisen of issues eerst met de klant te bespreken.

Vaak zijn klanten ook onduidelijk over hun verwachtingen. Soms nemen ze aan dat bepaalde aspecten van een service worden geleverd zonder dat daar iets over is afgesproken. Deze veronder-stelde aspecten van de IT-services zijn vaak de oorzaak van veel verwarring. Dit onderstreept de noodzaak dat servicelevelmanagers hun klanten goed kennen en hun klanten helpen om helder te krijgen welke services en servicelevels ze echt nodig hebben en tegen welke kosten.

Om een bijdrage te kunnen leveren aan het ontwerpen en monitoren van IT-services, moeten de wensen van de klant in meetbare waarden worden uitgedrukt. Als er geen metrics zijn afge-proken met de klant, is niet het na te gaan of de IT-service voldoet aan de vastgelegd afspraken. Servicelevelmanagement speelt een centrale rol in het begrijpen en defi niëren van de behoeften van de klant.

De eerst stap in de afronding van SLA’s over de geleverde of nog te leveren IT-services, is om de klanteisen te bepalen en vast te leggen in service level requirements. Dit hoort echter niet alleen een eenmalige activiteit in deloop van het proces te zijn, maar hoort op regelmatige basis te wor-den uitgevoerd, geïnitieerd door rapportages en reviews, op aanvraag van de klant, of op initiatief van de IT-organisatie zelf.



Het bepalen van de defi nitie en scope van de klanteisen wordt in servicelevelmanagement be-schouwd als een ontwerpproces. Volgens de ISO 9001-kwaliteitstandaard moet een ontwerp-proces voldoen aan de volgende stappen:• ontwerp• ontwikkeling• productie• installatie• onderhoud

Het ontwerpproces moet op een gecontroleerde manier plaatsvinden, om te kunnen garanderen dat de resultaten aan het eind van het proces ook overeenkomen met de wensen van de klant. Tijdens het ontwerpproces wordt de term ‘extern’ gebruikt om aan te geven dat het om commu-nicatie met de klanten gaat, en ‘intern’ wordt gebruikt voor de technische onderbouwing binnen de IT-organisatie.

De eerste stap in het kwantifi ceren van nieuwe of bestaande IT-services is het (opnieuw) bepalen van de klantverwachtingen over de dienstverlening in het algemeen. Deze verwachtingen worden geformaliseerd in de gedocumenteerde service level requirements. Hier moet de hele klantorga-nisatie bij betrokken zijn. Deze stap wordt over het algemeen beschouwd als het meest ingewik-kelde onderdeel van servicelevelmanagement.

Aan het begin van deze fase moet de servicelevelmanager voorbereid zijn op het overleg met de klantorganisatie. De eerste vragen die de servicelevelmager moeten stellen zijn: “welke eisen worden gesteld aan de IT-service?” en “welke elementen moet deze IT-service bevatten?”. Een technische service kan gebruik maken van een begrensde infrastructuur zoals een Wide Area Net-work (WAN). Een dergelijke service kan bijdragen aan een samengestelde service zoals toegang tot een volledig informatiesysteem, inclusief de volledige onderliggende infrastructuur (WAN, LAN, servers, werkstations, applicaties).

Tijdens deze bijeenkomsten met de klant worden de gebruikers opgedeeld in verschillende groe-pen. De servicelevelmanager stelt een lijst op van de verschillende gebruikersgroepen en hun eisen en bevoegdheden. De volgende informatie is nodig om de service level requirements te defi niëren:• een omschrijving, vanuit de klant gezien, van de functionaliteit die de dienst moet leveren • tijden en dagen waarop de service beschikbaar moet zijn• servicecontinuiteïtseisen• IT-functies die nodig zijn om de service te leveren• verwijzingen naar de huidige werkwijzen en/of kwaliteitsstandaarden waarmee rekening moet

worden gehouden bij het ontwerpen van de service • verwijzing, indien van toepassing, naar de SLA die moet worden aangepast of vervangen

Tijdens de ontwerpfase wordt een document opgesteld met de service level requirements. Dit wordt ondertekend door de servicelevelmanager en de klantvertegenwoordiger. De service level requirements kunnen nog worden aangepast terwijl de afdeling werkt aan het ontwerp, inkoop en implementatie. Dergelijke veranderingen kunnen betrekking hebben op de praktische haalbaar-heid van de functies of de kosten. Beide partijen moeten dergelijke veranderingen goedkeuren.



Tijdens de specifi catiefase worden de service level requirements in detail uitgewerkt, rekening houdend met interne standaarden of normen. Deze fase heeft als doel om de volgende informatie te verstrekken:• eenduidige en gedetailleerde beschrijving van de IT-services en benodigde componenten• een specifi catie van de wijze waarop de service wordt geimplementeerd en geleverd• specifi catie van de procedure voor kwaliteitscontrole

Het wordt aanbevolen om onderscheid te maken tussen documentatie voor intern gebruik en documentatie voor extern gebruik (fi guur 4.3.2). Specifi caties voor extern gebruik hebben be-trekking op doelstellingen die zijn overgekomen met de klant, en deze doelstellingen sturen het ontwerpproces. De specifi caties worden opgesteld in samenwerking met de klantorganisatie en vormen de input voor specifi caties voor intern gebruik.

Specifi caties voor intern gebruik verwijzen naar interne doelstellingen van de IT-organisatie die IT moet realiseren om aan de vraag van de gebruikers te voldoen. Een scheiding tussen interne en externe specifi caties is nuttig als het servicelelevelmanagementproces eenmaal gestart is. Klanten worden dan niet ‘lastig gevallen’ met technische details. Het beheren van servicelevels is vanaf dat moment een kwestie van het op één lijn houden van interne en externe specifi caties. Do-cumentbeheer en interne reviews dragen hieraan bij door lijsten bij te houden van gerelateerde documenten, door versiebeheer en door hierop regelmatig een audit uit te voeren.

Servicespecifi caties (spec sheets) beschrijven in detail wat de klanten willen (extern) en welke im-pact dat heeft op de IT-organisatie (intern). Servicespecifi caties hoeven niet door beide partijen te worden ondertekend maar vallen wel onder documentbeheer. De servicecatalogus kan worden

Externe documenten- Serviceleveleisen- Service level agreements- Servicecatalogus

Interne documenten- Specsheets- Operational level agreements- Underpinning contracts

Bedrijfsmanagement

IT-afdeling

Leveranciers

Documentbeheer

Interne review

Eindgebruikers

Figuur 4.3.2 Specifi catiefase



opgesteld aan de hand van de servicespecifi caties. Veranderingen in de servicelevels kunnen di-rect worden toegevoegd in de servicespecifi caties en de servicecatalogus. Daarna wordt de SLA opnieuw opgesteld, in aansluiting op de gewijzigde spec sheets. Neem alle managementinformatie (key performance indicators ) en specifi caties voor interne en externe providers op in een servicekwaliteitsplan . Dit plan levert samenhangende informatie over de bijdragen die de verschillende servicemanagementprocessen leveren aan de IT-services.

Als de specifi catiefase is afgerond heeft de IT-organisatie de bedrijfseisen effectief omgezet in IT-resources en confi guraties.Deze informatie wordt vervolgens gebruikt voor het opstellen of aanpassen van de: • Service level agreement – Bij het ontwikkelen van een SLA-structuur is het raadzaam om

eerst de algemene services te defi niëren (zoals netwerkservices voor de hele organisatie) en een algemeen - op services gebaseerd - SLA-model te ontwikkelen, voordat de onderhandelingen worden gestart. De SLA kan een hiërarchische structuur hebben (zoals die van de klantor-ganisatie) in de vorm van een frameworkovereenkomst met een aantal lagen. Elke laag heeft zijn eigen mate van detaillering. De hoogste lagen omvatten overeenkomsten over algemene services die aan de organisatie worden geleverd. De onderste lagen bevatten informatie die relevant is voor specifi eke klanten en services. De structuur van SLA’s hangt af van een aantal factoren zoals:– fysieke aspecten van de organisatie zoals schaal en complexiteit– culturele aspecten zoals taal en de relatie tussen de IT-organisatie en de klant – aard van de bedrijfsactiviteiten (in de zin van algemene voorwaarden) en openingstijden

(5x8 of 7x24) • UC’s en OLA’s - Elke UC of OLA moet worden aangepast tijdens het ontwerpproces. Betrok-

kenen moeten zich bewust zijn van de UC’s en OLA’s die van toepassing zijn op de verlening van een specifi eke service. Confi guratiemanagement kan behulpzaam zijn bij het ophelderen van relaties tussen verschillende servicespecifi caties.

• Servicecatalogus - De volgende tips kunnen helpen bij het samenstellen van een servicecata-logus:– Spreek de taal van de klant. Vermijd technisch jargon en hanteer termen die in de business

gebruikelijk zijn.– Probeer naar de services te kijken zoals de klant dat zou doen en gebruik die aanpak voor

het verzamelen van relevante informatie.– Zorg voor een aantrekkelijke lay-out omdat de IT-organisatie zich via de servicecatalogus

presenteert aan de klant. – Zorg dat het document beschikbaar wordt gemaakt aan alle mogelijke stakeholders (be-

langhebbenden). Bijvoorbeeld door de catalogus te publiceren via het intranet of een cd.

Servicelevels kunnen alleen worden gemonitord als ze vooraf helder gedefi nieerd zijn en overeen-komen met de afgesproken doelstellingen. De servicelevels worden gemeten vanuit het perspec-tief van de klant. Monitoring mag zich niet beperken tot technische aspecten, maar ook procedu-rele zaken moeten omvatten. Zolang gebruikers bijvoorbeeld niet zijn ingelicht over herstel van een service, zullen ze aannemen dat de service nog niet beschikbaar is.



Beschikbaarheids- en capaciteitsmanagement leveren over het algemeen de informatie over de realisatie van de technische doelstellingen van de servicelevels. In sommige gevallen wordt ook informatie geleverd door de servicesupportprocessen, vooral door incidentmanagement. Het is niet voldoende om interne waarden te meten, omdat daarmee nog geen verband wordt gelegd met de beleving van de gebruiker. Parameters zoals responsietijd, escalatietijd en supporttijd moeten ook worden gemeten. Om een compleet overzicht te krijgen, moet de managementinfor-matie van zowel de technische infrastructuur als van de servicemanagementactiviteiten worden gecombineerd.

In veel organisaties waar servicelevelmanagement wordt geïntroduceerd, is er discussie over het al dan niet gebruiken van sancties als niet wordt voldaan aan de SLA. Dit is een lastige kwestie omdat servicelevelmanagement gebaseerd is op de interactie tussen de IT-afdeling en de ge-bruikers van IT-services, vaak binnen dezelfde organisatie. In dergelijke situaties, waar zowel de IT-afdeling als de gebruikers gericht zijn op de realisatie dezelfde bedrijfsdoelstellingen, is het on-waarschijnlijk dat (fi nanciële) sancties bijdragen aan het gemeenschappelijke belang. Het is dan beter om afspraken te maken die gebaseerd zijn op dat gemeenschappelijke belang, en gericht zijn op maatregelen die voorkomen dat de servicelevels niet worden gehaald. Sancties zijn wel een optie als de IT-services worden afgenomen van een externe IT-leverancier. In dat geval zal er eerder - een voor de wet bindend - contract (UC) worden afgesloten dan een SLA.

Servicelevels moeten regelmatig worden gereviewd. Houd daarbij rekening met de volgende as-pecten:• SLA’s sinds de vorige review• problemen gerelateerd aan de services• vaststelling van trends in de dienstverlening• changes van services binnen de overeengekomen servicelevels• veranderingen van procedures en schattingen van de kosten van extra resources• de gevolgen van het niet nakomen van de afgesproken servicelevels

Als de services niet voldoen aan de overeengekomen servicelevels, kunnen er verbeteracties wor-den ondernomen, waaronder:• opstellen van een serviceverbeterplan (SIP)• toewijzen van extra personeel en andere resources• aanpassen van de in SLA vastgelegde servicelevels• aanpassen van processen en procedures• aanpassen OLA’s en UC’s

Het succes van servicelevelmanagement hangt af van de volgende kritieke succesfactoren:• een bekwame servicelevelmanager met deskundigheid van IT en de business en indien nodig

een supportorganisatie• duidelijke procesdoelstellingen• bewustzijnscampagne om mensen te informeren over het proces, en inzicht en draagkracht te

bevorderen• duidelijk gedefi nieerde taken, bevoegdheden en verantwoordelijkheden, waarbij onderscheid

wordt gemaakt tussen procesbeheer en operationele taken (contacten met de klant)



De volgende KPI’s kunnen worden gebruikt om de effectiviteit en effi ciëntie van het servicelevel-managementproces te bepalen:• service-elementen opgenomen in SLA’s• elementen van de SLA, ondersteund door OLA en UC’s• elementen van de SLA’s die worden gemonitord en waarvan tekortkomingen worden gerap-

porteerd• elementen van SLA’s die regelmatig worden beoordeeld• elementen van SLA’s waarvoor wordt voldaan aan de overeengekomen servicelevels• tekortkomingen die zijn vastgesteld en opgenomen in een verbeterplan• acties die genomen worden om deze tekortkomingen op te heffen• trends in relatie tot de huidige servicelevels

4.3.2 Serviceleveringsproces: servicerapportage

Doelstelling: Het produceren van afgesproken, stipte, betrouwbare en accurate rapporten voor een goed geïnformeerde besluitvorming en effectieve communicatie.

De specifi catie in ISO 20000-1 stelt:Er moet een heldere beschrijving zijn van elk servicerapport waarin ook de identiteit, het doel, de doelgroep en de brondetails zijn opgenomen.

Servicerapporten moeten worden geproduceerd om aan de vastgestelde behoeften en eisen van de klant te voldoen. Servicerapportage moet de volgende elementen bevatten:a) performance in relatie tot serviceleveltargetsb) niet-naleving en issues, bijvoorbeeld met betrekking tot de SLA of een

beveiligingsverstoringc) werklastkenmerken, bijvoorbeeld volume, gebruik van resourcesd) prestatierapportage volgend op ingrijpende events, bijvoorbeeld major incidenten en

changese) trendinformatief ) tevredenheidsanalyse

Bij het nemen van managementbeslissingen en corrigerende acties moet rekening worden gehouden met de bevindingen in de servicerapportage. De beslissingen moeten kenbaar worden gemaakt aan de betrokken partijen.


NOOT Het succes van alle servicemanagementprocessen is afhankelijk van de informatie die geboden wordt in servicerapporten.

BeleidDe eisen voor servicerapportage horen te worden overeengekomen en geregistreerd voor klanten en voor intern management.



Servicemonitoring en –rapportage omvat alle meetbare aspecten van de service en biedt daarbij zowel actuele als historische analyse. Waar sprake is van meerdere leveranciers, hoofdleveranciers en toeleveranciers, horen de rapporten de relaties tussen de leveranciers weer te geven. Een hoofdleverancier hoort bijvoorbeeld te rapporteren over de gehele service die hij biedt, inclusief alle services van toeleveranciers die hij managet als onder-deel van de service aan de klant.

Doel en kwaliteitscontroles van servicerapportenServicerapporten horen tijdig, helder, betrouwbaar en bondig te zijn.Ze horen te zijn toegepast op de behoeften van de ontvanger en voldoende nauwkeurig om als onder-steuning te dienen voor de besluitvorming.De presentatie van de rapporten hoort het begrip ervan te ondersteunen zodat ze gemakkelijk zijn te lezen, bijvoorbeeld door gebruik van grafi eken.

Er horen verschillende typen rapporten te worden geproduceerd: a) reactieve rapporten die laten zien wat er is gebeurdb) proactieve rapporten die vooraf waarschuwen voor signifi cante events en hierdoor mogelijk maken

dat bij voorbaat preventieve actie kan worden genomen (bijvoorbeeld rapporten over ophanden zijnde breuken in SLA’s)

c) vroegtijdig ingeplande rapporten die de geplande activiteiten weergeven

ServicerapportenDe serviceprovider hoort rapporten te produceren voor klanten en management. Deze horen de vol-gende informatie te bevatten: a) performance ten opzichte van serviceleveltargets, bijvoorbeeld uitvalrapporten, resultatenb) afwijkingen van de normc) kenmerken van werklast en informatie over werkomvang, bijvoorbeeld incidenten, problems, chan-

ges en taken, classifi catie, locatie, klant, seizoentrends, vermenging van prioriteiten, aantal verzoe-ken om hulp

d) performancerapportage die volgt op grootschalige events, bijvoorbeeld change en releasese) trendinformatie per periode (bijvoorbeeld per dag, week, maand, periode)f ) rapporten die informatie bevatten van elk proces, bijvoorbeeld het aantal incidenten en de meest

gestelde vragen (FAQ’s), onbetrouwbare componenten van de infrastructuur, resource- of kosten-intensieve taken

g) rapporten die licht werpen op toekomstige en ingeplande werklast

Figuur 4.3.3 visualiseert dit deel van de standaard in een procesfl ow

Servicerapportage is een belangrijke activiteit omdat klantgerichtheid een kwaliteitsmanage-mentprincipe is. Servicerapportage is een activiteit van servicelevelmanagement. De servicerap-portage-activiteiten uit dit deel van de standaard zijn activiteiten die tegemoet komen aan de eisen van het interne management en de klant. Deze servicerapportage-activiteiten hebben een interface met alle processen om informatie te vergaren.

Servicerapportage is een activiteit die niet alleen wordt uitgevoerd door de serviceprovider. Le-veranciers moeten ook rapporteren over de services die zij aan de serviceprovider leveren. Deze servicerapporten moeten de relaties tussen (toe)leveranciers weerspiegelen.



RichtlijnenServicerapporten moeten worden opgeleverd volgens de regelmaat die in de SLA is overeenge-komen. Deze rapporten vergelijken de daadwerkelijk gemeten servicelevels met de afgesproken servicelevels. Voorbeelden van wat er gerapporteerd wordt zijn: • beschikbaarheid en storingstijd gedurende een bepaalde periode• gemiddelde responsietijden in piekperioden • transactiesnelheid in piekperioden• aantal functionele fouten in de IT-service• frequentie en duur van servicevermindering• gemiddeld aantal gebruikers bij pieken• aantal succesvolle en mislukte pogingen om de beveiliging te omzeilen• gedeelte van de servicecapaciteit dat benut wordt• aantal afgeronde en open changes• kosten van de geleverde service

Accordeer enregistreer eisen aanservicerapportage

Beschrijfservicerapporten

Produceerservicerapporten

Communiceermanagementbeslissingen

en corrigerendeacties naar

relevante partijen

Eisen aanservicerapportage

Beschrijvingenvan

servicerapporten

Met inbegrip van - identiteit- doel- doelgroep- details van de databron

Met inbegrip van:- performance met oog op serviceleveltargets- afwijkingen en issues- werklastkarakteristieken- performancerapportage na major events- trendinformatie tevredenheidsanalyse

Types rapporten:- reactieve rapporten: wat is er gebeurd?- proactieve rapporten: waarschuwing voorafgaand aan belangrijke events- vooraf ingeplande rapporten: geplande activiteiten

Servicerapport

Servicerapport

Met inbegrip van:- informatie van elk proces- data om toekomstige en ingeplande werklast te belichten

Met weergave van derelaties tussen leveranciers

Interfaces:

Alle relevante processen:- lever informatie


Servicelevelmanagement:- Rapporteer servicelevels met oog op targets

Figuur 4.3.3 Servicerapportage



Managementrapporten zijn in tegenstelling tot servicelevelrapportages niet bedoeld voor de klant, maar om de interne processen te beheren en controleren. Zij kunnen metrics bevatten over de huidige servicelevels en trends zoals:• aantal afgesloten SLA’s• aantal malen dat niet voldaan is aan SLA• meet- en monitoringkosten van SLA’s• klanttevredenheid gebaseerd op klachten uit enquêtes• statistieken over incidenten, problems en changes• voortgang van verbeteracties

4.3.3 Serviceleveringsproces: budgetteren en accounting van IT-services

Doelstelling: De budgettering en accounting van de kosten van de servicelevering.


NOOT. Dit gedeelte betreft de budgettering en accounting van IT-services. In de praktijk zijn veel serviceproviders betrokken bij het doorbelasten van zulke services. Doorbelasten is echter een optionele activiteit en is daarom niet in de standaard beschreven. Serviceproviders wordt aangeraden om als doorbelasten aan de orde is, ervoor te zorgen dat het mechanisme dat hiervoor wordt gebruikt volledig is gedefi nieerd en door alle partijen duidelijk is. Alle gebruikte accountingmethoden behoren aan te sluiten op de organisatiebrede accountingmethoden van de serviceprovider.

Er moeten duidelijke richtlijnen en processen zijn voor:a) budgetteren en accounting van alle componenten, inclusief IT-activa, gedeelde resources,

overheads, extern geleverde service, mensen, verzekeringen en licentiesb) verdelen van indirecte kosten en toewijzen van directe kosten aan services c) effectieve fi nanciële controle en autorisatie

Kosten moeten in voldoende detail worden gebudgetteerd om effectieve fi nanciële control en besluitvorming te waarborgen.De serviceprovider moet de kosten monitoren en rapporteren met oog op het budget, de fi nanciële voorspellingen in de gaten houden, en daarop gebaseerd de kosten managen. Changes van services moeten worden bekostigd en goedgekeurd door het changemanagementproces.


AlgemeenDit onderdeel gaat over budgettering en accounting van IT-services. In de praktijk zullen veel ser-viceproviders betrokken zijn bij de doorbelasting van zulke services. Echter, omdat doorbelasting een optionele activiteit is, is het niet opgenomen in de standaard. Serviceproviders wordt aanbevolen om, waar doorbelasting aan de orde is, ervoor te zorgen dat het mechanisme dat hiervoor wordt gebruikt volledig is gedefi nieerd en duidelijk is voor alle partijen.



De verantwoordelijkheid voor veel fi nanciële beslissingen zal buiten het werkterrein van servicema-nagement liggen, en de eisen voor de benodigde fi nanciële informatie, evenals de vorm en frequentie ervan, zullen van buitenaf worden opgelegd. Deze sectie is gefocust op de werkwijze die hoort te wor-den gevolgd om aan de eisen van de standaard te voldoen. Er zal echter ook rekening moeten worden gehouden met bredere eisen, omdat deze invloed zullen hebben op een aantal van de gedefi nieerde richtlijnen en procedures. Alle werkwijzen die voor accounting worden gebruikt horen te worden aan-gesloten op de organisatiebrede accountancywerkwijze van de serviceprovider.

BeleidEr hoort een beleid te zijn voor fi nancieel management van services. Het beleid hoort te defi nië-ren aan welke doelstellingen budgettering en accounting moeten voldoen.

Het beleid hoort ook aan te geven tot in welk detail budgetting en accounting moeten worden uitge-voerd, rekening houdend met:a) kostentypen die moeten worden verantwoordb) omslag van overheadkosten, bijvoorbeeld proportioneel tarief, vast percentage, of gebaseerd op de

hoogte van het variabele elementc) structuur van het bedrijf van de klant, bijvoorbeeld business-unit als een unit, onderverdeeld naar

afdeling of locatied) regels die bepalen hoe moet worden omgegaan met afwijkingen ten opzichte van het budget, bij-

voorbeeld bij welke omvang de afwijking naar het hoger management moet worden geëscaleerde) koppelingen naar servicelevelmanagement

De mate waarin wordt geïnvesteerd in budgettering- en accountingprocessen, hoort te worden geba-seerd op de behoefte die klant, serviceprovider en leveranciers hebben aan fi nanciële details. Dit hoort te zijn aangegeven in het beleid.

NOOT. Serviceproviders die in een commerciële omgeving werken zullen aanzienlijk meer tijd en energie in hun fi nancieel management moeten investeren. Dit in tegenstelling tot serviceproviders die werken in een situatie waar een eenvoudige kostenidentifi catie voldoende is, hier kan fi nancieel management veel eenvoudiger zijn.

Budgettering en accounting horen te worden uitgevoerd door alle serviceproviders, hoe hun beleid voor fi nancieel management er verder ook uitziet.

BudgetteringBudgettering hoort rekening te houden met de geplande changes van services gedurende de budget-periode en, waar eisen aan het budget de beschikbare fi nanciële middelen overschrijden, horen ze te plannen hoe tekorten moeten worden gemanaged.Budgettering kan rekening houden met accountfactoren, zoals seizoensvariaties en op korte termijn geplande wijzigingen in servicekosten en -heffi ngen.Tracking van kosten met oog op het budget zal tijdig te waarschuwen voor afwijkingen van het budget.Er hoort een proces te zijn dat de gevolgen managet van afwijkingen ten opzichte van het budget.Budgettering en kostentracking horen de planning van productie en wijziging van services te onder-steunen, zodat servicelevels door het jaar heen behouden kunnen blijven.



AccountingAccountingprocessen horen te worden gebruikt om de kosten te volgen tot op een overeengekomen de-tailniveau, gedurende een overeengekomen periode.Beslissingen over servicevoorziening horen te worden gebaseerd op vergelijkingen van kosteneffectivi-teit. Kostenmodellen horen de kosten van servicevoorziening te kunnen verduidelijken.Rekeningen horen over- of onderbesteding/herstel te verduidelijken, en horen het de lezer mogelijk te maken om de kosten van lage servicelevels of serviceverlies te begrijpen.


Bij een serviceprovider kan fi nancieel management worden onderverdeeld in actviteiten voor budgettering, accounting en doorbelasting.

RichtlijnenEen effectief systeem van kostenbeheersing moet aan de volgende criteria voldoen:• Het moet ondersteuning verlenen bij het opstellen van een gedegen investeringsstrategie waar-

in rekening wordt gehouden met de fl exibiliteit die de moderne techniek te bieden heeft.• Het moet prioriteiten stellen ten aanzien van het gebruik van resources.• Het moet zorg dragen voor de kosten van alle IT-resources die in de organisatie worden ge-

bruikt, inclusief de update van relevante gegevens.• Het moet het management ondersteunen bij het nemen van dagelijkse beslissingen, zodat

langetermijnbeslissingen met het laagst mogelijke fi nanciële risico kunnen worden genomen.• Het moet fl exibel en capabel zijn om snel in te spelen op veranderende omstandigheden in de

businessactiviteiten.

Figuur 4.3.5 illustreert de fi nanciële cyclus van budgettering, accounting en doorbelasting.

De doelstelling van budgettering is het plannen en beheersen van de activiteiten van een organi-satie. De bedrijfsplanning en strategische planning betreffen de langetermijndoelstellingen van de business. Budgets bepalen de fi nanciële plannen voor de doelstellingen gedurende de periode waarop het budget betrekking heeft. Deze periodes variëren normaal gesproken van één tot vijf jaar.

Selecteer afhankelijk van het fi nanciële beleid van de business een van de volgende budgetterings-methoden:• Incrementele budgettering – Bij incrementeel budgetteren worden de cijfers van het vorige

jaar als basis genomen voor het nieuwe budget. Dit wordt dan aangepast aan de verwachte veranderingen.

• Zero-base budgettering – Deze methode start met een wit vel papier: de zero-base. Ervarin-gen uit het verleden worden genegeerd.

Dit vereist dat managers de kosten voor resources in hun budget moeten rechtvaardigen: alle uitgaven moeten worden beoordeeld, of ze wel kunnen worden gemaakt en wat ze mogen kosten. Deze methode kost veel meer tijd en wordt daarom slechts een keer in de zoveel jaren gebruikt. In de tussenliggende jaren wordt de incrementele methode gebruikt.



Het budgetteringsproces start met de vaststelling wat de sleutelfactoren zijn die de groei van het bedrijf beperken. Bij veel bedrijven is de omvang van de verkopen de sleutelfactor, maar het kan bijvoorbeeld ook een gebrek aan ruimte of materialen zijn. Vaak bepalen fi nanciële beperkingen het budget. Dit proces omvat ook de beschrijving van de volgende secundaire budgetten of be-grotingen:

Budgetteer enverantwoord alle

componenten

Beleid voor financieelmanagement van

IT-services

Stel financiëleberaming op

Verdeel indirect kostenen wijs directe kosten

aan services toe

Monitor en rapporteerkosten met oog op

het budget

Review de financiëleverwachtingen

Het financiële-verwachtingsreviewFinanciële verwachting

Kostenrapporten

Financiële beraming

Met inbegrip vankostenmodellen

Beheers financiënen autorisaties

Definieer richtlijnenen processen voor

financieelmanagement van

IT-services

Met inbegrip van IT-assets,gedeelde resources,overheads, externgeleverde service,mensen, verzekeringen licenties

Interface:

Alle relevante processen:- budgetteer en verantwoord alle componenten

Continue verbetering (Act):- doe verbetervoorstellen voor SIP

Changemanagementproces- begroot en geef toestemming aan servicewijzigingen- dien requests for change in

Servicerapportage- ontvang informatie

Figuur 4.3.4 Budgettering and accounting voor IT-services



• Sales- en marketingbudget – Als het verkoopvolume van een bedrijf bepalend is voor het budget, dan ligt een belangrijke verantwoordelijkheid van het proces bij de marketingafdeling. Een accurate inschatting en analyse van klanten, markten, verkoopgebieden en producten is van wezenlijk belang voor een goede begroting.

• Productiebudget - Het productiebudget levert gedetailleerde informatie over de service die moeten worden geleverd: hoeveelheid, leverdatums, werkuren en benodigd materiaal.

• Administratiebudget – Gebaseerd op de service die moet worden geleverd, moeten de bud-getten voor de vaste kosten (‘overhead budgets’) worden bepaald voor relevante afdelingen zoals productie, sales, distributie en research & ontwikkeling.

• Kosten- en investeringsbudget – Het kostenbudget komt voort uit de plannen van bovenge-noemde budgetten. Het investeringsbudget beschrijft de uitgaven die horen bij het vervangen en inkopen van productiemiddelen. Investeringsprojecten die in het vorige jaar zijn gestart, kunnen ook van invloed zijn op het investeringsbudget.

Een natuurlijke keuze voor de budgetperiode is het fi scale jaar. Voor regelmatige controle van de daadwerkelijke uitgaven in relatie tot het budget, wordt de periode opgedeeld in maanden of andere reguliere periodes, zoals een keer per vier weken.

Sommige bedrijven maken niet alleen een gedetailleerd jaarbudget maar doen ook voorspellingen voor de komende drie of vijf jaar. Hiermee wordt het hoger management geïnformeerd over de verwachtingen op langere termijn.

Om IT als een business te besturen is het noodzakelijk dat alle kosten waarvoor IT verantwoor-delijk is inzichtelijk worden gemaakt met behulp van accounting. Kosten moeten zijn vastgesteld, ook al worden ze niet doorberekend aan klanten.

Een van de belangrijkste accountingactiviteiten is het indelen van de kostenposten. Deze indeling wordt vastgelegd voor een jaar, waarna deze weer kan worden aangepast. In de meeste gevallen zal een kostenaccountingmethode zijn gekozen bij het introduceren van de kostenelementenstruc-tuur. In de meeste gevallen worden de kosten vastgelegd voor iedere afdeling, klant of product.

IT-behoeften vanbedrijfsactiviteiten

IT-plannen(inclusief budgetten)

Accounting Doorbelasting

Feedback overgeplande kosten

Identificeer financiëledoelstellingen

Methoden voorkostenbeheersing

Servicelevel-management

Financieelmanagement

Methoden voordoorbelasting

Figuur 4.3.5 De fi nanciële cyclus



Idealiter zou de structuur een weerspiegeling moeten zijn van de geleverde services. Zelfs als ac-counting niet voor doorbelasting wordt gebruikt, is het zinvol om de kostentypenstructuur te baseren op een servicestructuur zoals die gebruikt wordt in een servicecatalogus.

Figuur 4.3.6 laat een voorbeeld zien van een hiërarchische structuur van service-elementen die door de IT-organisatie is gemaakt. In deze structuur ondersteunen de service-elementen op de lagere niveaus de elementen op de hogere niveaus. Des te hoger de positie van een element in deze structuur, des te relevanter is de functie voor de business. Na de defi niëring van de service-elementen moeten de kostenelementen worden gedefi nieerd die vervolgens worden onderver-deeld in kosteneenheden voor personeel, hardware, software en overhead.

Het voordeel van een indeling van kostenposten die in overeenstemming is met de service- elementen, is dat uitgaven aan hardware, software en ondersteuning van services duidelijk zicht-baar zijn. In aanvulling op een structuur die gebaseerd is op directe kosten, kan ook worden besloten om indirecte kosten aan de services toe te wijzen.

Netwerkservices (lan & wan)

WerkstationUitgangspunt-A (baseline-A)

Krachtige desktop-pc

WerkstationUitganspunt-B

Thin client

WerkstationUitgangspunt-C

Laptop-pc

BesturingssysteemWindows Vista

BesturingssysteemWindows XP

Algemene bedrijfsapplicaties

GroupwareMail- en directoryservices

Intranet, extranet en internetInformatieservices

Werkstation-emulatorIBM omgeving

Werkstation-emulatorandere omgeving

BedrijfsapplicatieAccounts (rekeningen)

BedrijfsapplicatieRelatiemanagement

BedrijfsapplicatieMarketinggegevens

Bestandservices & printservices

Kantoorapplicaties

Figuur 4.3.6 Voorbeeld van een servicestructuur



Het alternatief zou een minder gedetailleerde catalogus zijn, waarin slechts drie standaard werk-stations zijn opgenomen die alles bevatten. In dat geval zou het diagram slechts drie kolommen tonen en veel minder kostenelementen. Dit zou misschien duidelijker zijn, maar laat veel minder details zien.

Voor elk service- en kostenelement worden budgetten (begrotingen) gemaakt voor het komende jaar. Dit gebeurt op basis van ervaringen uit het verleden en schattingen voor het komende jaar. Deze budgetten worden maandelijks gemonitord om nieuwe ontwikkelingen vast te stellen, zo-als onverwachte groei, en om op gepaste wijze en in overeenstemming met het bedrijfsbeleid te reageren.

Intern doorbelasten is een effectieve manier om gebruikers te stimuleren om de IT-middelen met zorg te gebruiken. Maar het doorbelasten van kosten van IT-services is niet zo zinvol als de budgethouders in de klantorganisatie niet worden doorbelast voor andere services zoals telefonie, accommodatie, postkamer, catering en personeelsadministratie.

Normaal gesproken wordt doorbelasting ingevoerd om alle gemaakte kosten terug te vorderen. In dat geval handelt de IT-organisatie als een businessunit. Dit kan alleen als de daadwerkelijke exploitatiekosten van de IT-services bekend zijn.

Het is handig om een doorbelastingsbeleid te formuleren voordat u de tarieven bepaalt. Er zijn een aantal richtlijnen voor doorbelasting. Het is afhankelijk van de doelstellingen van fi nancieel ma-nagement welke methode het meest geschikt is. Als doorbelasting in fasen wordt geïntroduceerd kunnen per fase verschillende richtlijnen worden gebruikt. Richtlijnen voor doorbelasting zijn:• Communicatie van informatie – klantmanagers worden geïnformeerd over de doorbelastin-

gen om ze bewust te maken van de kosten van de IT-services die door hun afdelingen worden gebruikt. Hiervoor zijn twee mogelijkheden:– de kosten voor iedere businessunit berekenen en de betreffende managers hierover infor-

meren– idem als hierboven, maar inclusief de kosten die zullen worden doorbelast (gebaseerd op

een specifi eke doorbelastingsmethode)• Prijsfl exibiliteit – Prijzen worden op jaarbasis bepaald en doorbelast. Als de serviceprovider

het initiatief neemt om te investeren in een service omdat deze vaker wordt gebruikt, kan het contract een clausule bevatten voor het doorbelasten van extra kosten. Het alternatief is om deze extra capaciteit aan andere potentiële klanten aan te bieden.

• Pro-formaverrekening – De kosten worden gefactureerd, maar hoeven niet te worden be-taald. Hierdoor kan de IT-organisatie ervaring opdoen met het proces, en eventuele fouten in het doorbelastingsysteem corrigeren. Het geeft de klant eveneens de kans om te wennen aan doorbelasting van kosten. Deze methode is alleen zinvol als op termijn de kosten daadwerke-lijk zullen worden doorbelast, anders zal het kostenbewustzijn snel weer verdwijnen.

Het is moeilijk om het juiste prijs te bepalen voor een service. Bij het bepalen van de tarieven worden de volgende activiteiten uitgevoerd:• doelstellingen van doorbelasting bepalen• directe en indirecte kosten bepalen• gangbare markttarieven vaststellen



• vraag naar services analyseren• het aantal klanten en de concurrentie analyseren

Voordat de prijs kan worden vastgesteld, moet de organisatie eerst bepalen wat de doelstelling van de service is en wat het beoogde voordeel is voor klanten en IT-medewerkers.

Prijs is een van de vier P’s in marketing: Product, Prijs, Promotie en Plaats. De prijs is niet alleen van belang om de gemaakte kosten terug te verdienen, maar beïnvloedt ook de vraag naar het product. Met een fl exibele prijsstrategie kunnen producten extra promotie krijgen of worden uitgefaseerd. Een nieuwe dienst waarvoor nog weinig klanten bestaan, kan bijvoorbeeld worden gefi nancierd met de inkomsten uit andere diensten. De kosten van een service moeten helder zijn voordat een prijsstrategie kan worden gekozen.

Afhankelijk van het gekozen doorbelastingbeleid, wordt de klant gefactureerd voor, of op de hoogte gebracht van het daadwerkelijke gebruik van de IT-services. De kosten worden besproken tijdens het reguliere overleg dat binnen het servicelevelmangementproces met de klant plaats-vindt. Servicelevelmanagement wordt daarvoor van de volgende informatie voorzien:• IT-service-uitgaven per klant• verschillen tussen de daadwerkelijke en geschatte kosten• gebruikte methoden voor doorbelasting en accounting• meningsverschillen over doorbelastingen, inclusief oorzaken en oplossingen

Financieel management levert regelmatig rapportages aan IT-management over zaken als:• totale kosten en baten van de IT-services• kostenanalyses per IT-afdeling, platform of andere relevante eenheid• kosten die gerelateerd zijn aan het fi nanciële managementsyteem• planning van toekomstige investeringen• geschatte resultaten versus daadwerkelijke resultaten• mogelijkheden voor kostenreductie

Voordat fi nancieel management wordt ingevoerd moeten gebruikers, personeel en IT-manage-ment worden geïnformeerd over de doelstelling van de invoering, de kosten, de baten en de potentiële problemen die verbonden zijn aan de invoering.

Kritieke succesfactoren (CSF’s) voor de invoering van een effectief doorbelastingsysteem zijn onder andere:• Gebruikers moeten op de hoogte zijn van de services waarvoor ze worden doorbelast.• Gebruikers moeten op de hoogte zijn van de doorbelastingsmethoden zodat ze de kosten

beter kunnen beheersen (bijvoorbeeld via overeenkomsten of rapporten over kwantifi ceerbare performance-eenheden).

• Het kostenmonitoringsysteem moet details leveren over de rechtvaardiging van de IT-uitga-ven

• IT-servicemanagement moet uitgebalanceerde systemen leveren die effectieve IT-services bie-den tegen redelijke kosten

• IT-management moet volledig op de hoogte zijn van de impact en kosten van de invoering van fi nancieel management en hier volledig achter staan.



• Confi guratiemanagement moet relevante informatie leveren over de structuur van de services voor het opzetten van het accountingsysteem.

4.3.4 De relatieprocessen: algemeen (7.1)


Relatiemanagementprocessen beschrijven de twee gerelateerde aspecten van leveranciers-management en klantrelatiemanagement.

De code of practice in ISO 20000-2 stelt:Relatiemanagementprocessen beschrijven de twee gerelateerde aspecten van leveranciersmanagement en klantrelatiemanagement. Deze norm behandelt de rol van een serviceprovider, die logisch gezien een rol vervult tussen de leveranciers die goederen of services aan de serviceprovider leveren, en de klant die de services ontvangt. Zowel de leveranciers als de klant kunnen intern of extern zijn van de organisatie van de servicepro-vider. Externe relaties zullen via een contract worden geformaliseerd. Interne relaties zullen worden geformaliseerd door een service of door een interne underpinning overeenkomst die vaak operational level agreement (OLA) wordt genoemd.

Figuur 4.3.7. laat een vereenvoudigde weergave zien van de relaties.

Zoals fi guur 4.3.7. laat zien, vervult de serviceprovider een rol binnen een leveringsketen, waarin elke stap in de keten waarde hoort toe te voegen, met de serviceprovider die services of goederen van de leverancier ontvangt en een verrijkte service aan de klant levert.Ter verduidelijking: binnen deze sectie wordt de term serviceprovider altijd gebruikt om de organisatie te beschrijven waar dit document (red: ISO 20000-2) op is gericht, ongeacht de rol, of richting in de keten deze inneemt in het proces dat wordt beschreven.

Leverancier Serviceprovider


Klant

Klantrelatiemanagement

Figuur 4.3.7 Relatiemanagementprocessen



In de praktijk zullen relaties zelden zo eenvoudig zijn, maar meerdere spelers omvatten die zowel de rol van leverancier als de rol van klant aannemen, met vele onderlinge businessverbandens, zowel direct als via de serviceprovider.

De relatiemanagementprocessen horen ervoor te zorgen dat alle partijen:a) bedrijfsbehoeften begrijpen en hieraan voldoenb) capabilities en beperkingen begrijpenc) verantwoordelijkheden en verplichtingen begrijpen

Ze horen er ook voor te zorgen dat klanttevredenheidniveaus passend zijn en dat toekomstige bedrijfs-behoeften worden gecommuniceerd en begrepen.

De scope, rollen en verantwoordelijkheden van de klantrelatie en de leveranciersrelatie horen te worden gedefi nieerd en overeengekomen. Dit hoort de identifi catie van de stakeholders te omvatten, evenals de contacten en de kanalen en frequentie van de communicatie.

Figuur 4.3.8 laat zien hoe de algemene relatiemanagementprocessen kunnen worden gevisuali-seerd in BPM-taal.

Een van de acht kwaliteitsmanagementprincipes is klantgerichtheid . Dit maakt van klantrela-tiemanagement een belangrijk proces. Om hoog kwalitatieve IT-services te leveren aan de klant moet de serviceprovider de eigen processen goed beheersen, maar ze moet ook de services van leveranciers beheersen omdat die ook bijdragen aan de busisness van de serviceprovider.

4.3.5 Relatieproces: klantrelatiemanagement (7.2)

Doelstelling: het realiseren en onderhouden van een goede relatie tussen de serviceprovider en de klant, gebaseerd op begrip van de klant en zijn businessdrivers.


De serviceprovider moet vaststellen wie de stakeholders en de klanten van de services zijn en deze documenteren.De serviceprovider en de klant moeten een servicereview bijwonen om te overleggen over elke change van de servicescope, SLA, contract (indien aanwezig) of de bedrijfsbehoeften. Dit moet in ieder geval één keer per jaar plaatsvinden. Daarnaast moeten de serviceprovider en de klant regelmatig tussentijdse bijeenkomsten beleggen om de prestaties, behaalde resultaten, issues en actieplannen te bespreken. Deze bijeenkomsten moeten worden gedocumenteerd.Andere stakeholders van de service kunnen ook worden uitgenodigd om de bijeenkomsten bij te wonen.Waar nodig, moeten deze bijeenkomsten worden gevolgd door changes van contract(en), indien aanwezig, en SLA(‘s). Deze changes vallen onder het changemanagementproces.De serviceprovider moet bewust blijven van bedrijfsbehoeften en major changes om op deze behoeften in te kunnen spelen.



Changes van servicescope, SLA,contract of bedrijfsbehoeften

Om performance, resultaten, issues enactieplannen te bespreken

Stakeholders enklanten vande service

Identificeeren documenteerstakeholders en

klanten van de service

Woon eenservicereview bij om

changes te bespreken

Houd tussentijdsebijeenkomsten en

lever nieuwerecords voor SIP

Speel in opbedrijfsbehoeftenen major changes

Plan formelebijeenkomsten

Bepaal en bereikovereenstemming

over bereik rollen enverantwoordelijkheden

van klant- enleveranciersrelaties

Identificeerstakeholdercontacten

en lijnen en frequentievan de communicatie

Tenminste jaarlijks

Voor en namajor changes

Benoem personen dieverantwoordelijk

zijn voorklantrelatieprocesenklanttevredenheid

Verstrek records vande servicereview

Met afgesprokenregelmaat

RfC indien nodig

Notulen

Notulen

Records van deservicereview

Interfaces:

Continue serviceverbetering (Act)- doe verbetervoorstellen voor SIP- ontvang rapporten over voortgang

Changemanagementproces- dien requests for change in- manage changes aan contract(en), indien aanwezig, en SLA('s)Servicelevelmanagement- SLA en servicelevelreview



Figuur 4.3.8 Klantrelatiemanagement



Er moet een klachtenproces zijn. Met de klant moet worden overeengekomen wat de defi nitie van een formele klacht over een service is. Alle formele klachten over service moeten door de serviceprovider worden vastgelegd, onderzocht, behandeld, gerapporteerd en formeel gesloten.Als een klacht niet via de normale kanalen kan worden opgelost, moet de klant de moge-lijkheid hebben om de klacht te escaleren.De serviceprovider moet een individu of individuen aanwijzen die verantwoordelijk zijn voor het managen van de klanttevredenheid en het volledige klantrelatiemanagenent. Er moet een proces zijn voor het verkrijgen van en reageren op feedback uit regelmatig uitgevoerde klanttevredenheidsmetingen. Verbeteracties die tijdens dit proces zijn bepaald moeten worden vastgelegd en vormen de input voor een serviceverbeterplan.


ServicereviewsDe serviceprovider en klant(en) horen servicereviews te houden, tenminste jaarlijks en voor en na major changes. De review hoort rekening te houden met de performance in het verleden, actuele en verwachte bedrijfsbehoeften te bespreken en voorstellen in te dienen voor changes van de servicescope en SLA’s. Andere stakeholders, bijvoorbeeld toeleveranciers, klanten, gebruikersgroepen of andere repre-sentatieve organen, kunnen worden uitgenodigd om reviewbijeenkomsten bij te wonen. De serviceprovider en klant(en) horen ook overeen te stemmen over tussentijdse reviewprocedures om voortgang, resultaten en issues te bespreken. Deze bijeenkomsten horen te worden ingepland en bekend-gemaakt aan relevante stakeholders. De serviceprovider hoort alle formele bijeenkomsten te plannen en registreren, records te verschaffen en gevolg te geven aan afgesproken acties.De serviceprovider hoort een relatie met de klant op te bouwen, zodanig dat ze mogen verwachten op de hoogte te zijn van bedrijfsbehoeften en major changes en in staat zijn om zich voor te bereiden om op deze behoefte in te spelen.

Klachten over de serviceDe serviceprovider en klant(en) horen een formele klachtenprocedure overeen te komen, zodat er geen dubbelzinnigheid is over wat een klacht is en hoe deze hoort te worden behandeld. De serviceprovider hoort alle klachten over de service te registreren, onderzoeken, er actie op te nemen, te rapporteren en formeel af te sluiten.Eruitspringende klachten horen regelmatig te worden gereviewd en als ze niet binnen de met de klant(en) afgesproken deadlines zijn opgelost, horen ze te worden geëscaleerd naar het hoger manage-ment.Serviceproviders horen de geregistreerde klachten periodiek te analyseren, om trends te identifi ceren en deze analyse te rapporteren aan klanten. De resultaten van een dergelijke analyse horen, indien van toepassing, te worden gebruikt in een ser-viceverbeterplan.

KlanttevredenheidsmetingenKlanttevredenheid hoort te worden gemeten om de serviceprovider in staat te stellen om performance te vergelijken met klanttevredenheidsdoelen en voorgaande enquêtes. De scope en complexiteit van de enquête hoort te worden ontworpen, zodat klanten gemakkelijk kunnen reageren en zonder dat er extreem veel tijd nodig is de enquête nauwkeurig kunnen invullen.



Signifi cante variaties in tevredenheidsniveaus horen te worden onderzocht en er moet inzicht zijn in de redenen. Trends of vergelijkingen horen alleen te worden gemaakt op basis van vergelijkbare vragen over tevredenheid en tussen vergelijkbare steekproeftrekkingen. De resultaten en conclusies van klanttevredenheidsonderzoeken horen te worden besproken met de klant. Een actieplan hoort te worden overeengekomen, evenals input voor een serviceverbeterplan en de voortgang hoort te worden teruggekoppeld naar de klant.Complimenten over de service horen te worden gedocumenteerd en gerapporteerd aan het serviceleve-ringsteam.

Volgens het klantgerichtheidsprincipe van kwaliteitsmanagement zijn organisaties afhankelijk van hun klanten en moeten dus rekening houden met huidige en toekomstige wensen, tegemoet komen aan de klanteisen , en er naar streven de klantverwachtingen te overschrijden.

Twee processen zijn onmisbaar in klantrelatiemanagement:• klachtenmanagement (fi guur 4.3.9)• klanttevredenheidsmanagement (fi guur 4.3.10)

Documenten die nodig zijn voor businessrelatiemanagement zijn: document over de stakehol-ders en klanten van de service, de notulen van de klantrelatievergaderingen, registratie van for-mele serviceklachten en registratie van verbeteracties.

Het businessrelatiemanagementproces heeft een interface met het changemanagementproces. Changemanagement beheerst de contractwijzigingen en, indien aanwezig, de SLA(‘s).

RichtlijnenFiguur 4.3.11 toont de ‘horizontale’ communicatie tussen de klant en de IT-organisatie over sup-port en coördinatie. De vertikale communicatie gaat over beleid, control en rapportages.

In klantrelatiemanagement is het de grootste uitdaging om ervoor te zorgen dat er op alle niveaus goede en effectieve relaties zijn tussen de IT-organisatie en de klantorganisatie. Het is belangrijk om eerst te defi niëren wat we precies bedoelen met ‘gebruiker’ en ‘klant’.

De gebruiker is de ‘vingers-op-het-toetsenbord-gebruiker’, de werknemer die IT-services gebruikt voor de uitoefening van zijn dagelijkse werkzaamheden.

De klant is de ‘betaal-de-rekeningen-klant’. De persoon die gemachtigd is een overeenkomst te sluiten met de IT-organisatie over de levering van IT-services (bijvoorbeeld een SLA), en wie verantwoordelijk is voor de betaling van de rekeneningen voor de IT-services.

Natuurlijk kan degene die ‘de rekening betaalt’ ook zijn ‘vingers op het toetsenbord’ hebben.

Klantrelatiemanagement speelt een belangrijke rol in business-IT alignment . In de praktijk is dit in de eerste plaats een kwestie van in contact blijven met de klantorganisatie en mogelijkheden zoeken voor het koppelen van strategische doelstellingen van beide organisaties. Dit kan de basis zijn voor een langetermijnrelatie waarin de IT-organisatie gericht is op de klant en IT-oplossin-gen voorstelt die de klant helpt zijn bedrijfsdoelstellingen te realiseren.



Servicelevelmanagement stelt vervolgens servicelevelvoorstellen op, op basis van de overeenkom-sten met de klant over de te leveren services. Bijvoorbeeld als de klant een intranet in gebruik wil nemen, moet er overeenstemming komen over de beschikbaarheid, gebruiksersondersteuning, implementatie van RfC’s en de kosten. De overeenkomsten worden vastgelegd in een service level agreement (SLA).

Escalatie mogelijk

Records vanserviceklachten

Trends

Trends

Registreer alleserviceklachten

Onderzoekserviceklachten

Neem actie opserviceklachten

Rapporteerserviceklachten

Sluit serviceklachtenformeel af

Spreek een formeleklachtenprocedure af

Review opmerkelijkeklachten regelmatig

en escaleer indien nodig

Analyseerklachtenrecords

periodiek omtrends te ontdekken

Rapporteer analysesaan de klanten

Spreek een definitieaf van formeleserviceklacht

Bepaal contactpuntvoor formele

klachten

Lever input voor SIP

Trends

Records vanserviceklachten

Figuur 4.3.9 Klantrelatiemanagement: klachtenmanagement



Als de klantorganisatie changes (uitbreiding of aanpassing) wil van de IT-services die onder de overeenkomsten van de SLA vallen, wordt een request for change (RfC) ingediend. Na installatie moet de informatie over, en de status van, een CI worden aangepast in de CMDB. Dit faciliteert verifi catie van licentieovereenkomsten.

Klanttevredenheidsmetingen

Klanttevredenheidsmetingen

Records van verbeteracties

Records van verbeteracties

Serviceverbeterplan

Complimenten

Voertevredenheidsmetingen uit

Registreer vastgesteldeverbeteracties

Lever input aan SIP

Vergelijk performance metklanttevredenheidstargets

en voorgaandeonderzoeken

Onderzoek en verkrijginzicht in opmerkelijke

afwijkingen intevredenheidsniveaus

Bespreek resultaten vantevredenheidsonderzoeken

met de klant en spreekeen actieplan af

Rapporteer over voortgangserviceverbetering

aan de klant

Documenteercomplimenten

Rapporteercomplimenten aan

serviceleveringsteam

Figuur 4.3.10 Klantrelatiemanagement: klanttevredenheidsmanagement



Figuur 4.3.11 laat naast informatie over de horizontale en verticale communicatie ook de plan-ningshorizon van het proces zien. Coördinatie op strategisch niveau heeft een planningshorizon van meerdere jaren. Servicelevelmanagement gaat over overeenkomsten op tactisch niveau, met een planningshorizon van ongeveer een jaar. Changemanagement, incidentmanagement en de servicedesk spelen zich af op operationeel niveau, met een planningshorizon van maanden, we-ken, dagen of zelfs uren.

Klanttevredenheidsonderzoeken kunnen regelmatig uitgevoerde formele enquêtes zijn, aangevuld met informatie die wordt verzameld door de servicedesk: willekeurig gekozen bellers kunnen een aantal vragen beantwoorden over hun perceptie van de servicekwaliteit. Alle informatie die op deze wijze door de servicedesk wordt verzameld is aanvullend op de volledige klanttevredenheids-onderzoeken. Wees zorgvuldig met de formulering van de vragen en de daadwerkelijke vragen die worden gesteld. Stel vragen over onderwerpen die voor de klant van belang zijn en start met de meest belangrijke vragen. Geef deelnemers de resultaten van de enquêtes, inclusief details over de voorgestelde verbeteracties.

Voer trendanalyses uit op de resultaten van de klanttevredenheidsonderzoeken met als doel de continue verbetering van de perceptie van de klant over de servicekwaliteit. Houd hierbij in gedachten dat onder normale omstandigheden een betere performance leidt tot hogere klantver-wachtingen.

4.3.6 Relatiemanagementproces: toeleveranciersmanagement (7.3)

Doelstelling: Het managen van toeleveranciers om services van naadloze kwaliteit te kunnen leveren.


NOOT: De scope van deze standaard laat de inkoop van de toeleveranciers buiten beschouwing.

Servicelevels

Aanbod (supply)Vraag (demand)

Afdelingsmanagers

Projectmanagers

Gebruikers

Bedrijfsmanagers

Budgethouder

Klantorganisatie IT-organisatie

strategischeuitlijning

IT-management

requests forchange

Sup-port

Strategisch

Tactisch

Operationeel

Rapportage

Beleid

IT-klantrelatiemanagement


Changemanagement

Incidentmanagement

ServicedeskProductie

Figuur 4.3.11 Klantrelatiemanagement



NOOT 2: De serviceprovider kan (toe)leveranciers gebruiken voor de levering van een gedeelte van de service. De serviceprovider moet laten zien dat hij conform deze toeleveranciersmanagementprocessen handelt. Er kunnen complexe relaties ontstaan, zoals te zien is in het onderstaande voorbeeld-diagram.

De serviceprovider moet toeleveranciersmanagementprocessen hebben gedocumenteerd en moet een contractmanager aanwijzen die verantwoordelijk is voor elke toeleverancier. De eisen, scope, servicelevel en communicatieprocessen die de toeleverancier(s) moet(en) leveren, moeten worden vastgelegd in SLA’s of andere documenten en moeten worden overeengekomen door alle partijen.De SLA’s van de toeleveranciers moeten op de SLA’s van de business zijn gericht.De interfaces tussen de processen die door elke partij worden gebruikt, moeten worden vastgelegd en overeengekomen.Alle rollen en relaties tussen de hoofdleverancier en de subleveranciers moeten duidelijk worden vastgelegd. Hoofdleveranciers moeten in staat zijn om processen te demonstreren, om te borgen dat de secundaire toeleveranciers zich houden aan de contractuele eisen.Er moet een proces zijn om te zorgen voor een (ten minste) jaarlijks terugkerend grootschalig review van het contract of de formele overeenkomst, om te borgen dat nog steeds aan de bedrijfsbehoeften en contractuele verplichtingen wordt voldaan. Changes van de contract(en), indien aanwezig, en SLA(’s), moeten waar nodig volgen op deze reviews, of desgewenst op andere momenten. Elke change valt onder het changemanagementproces. Er moet een proces zijn voor het omgaan met contractuele geschillen .Er moet een proces zijn voor de afhandeling van het verwachte einde van de service, een vroegtijdig einde van de service of een overdracht van de service naar een andere partij.Performance moet worden gemonitored en gereviewd in het licht van de serviceleveltargets.Verbeteracties die tijdens dit proces zijn vastgesteld, moeten worden geregistreerd en vormen de input voor een serviceverbeterplan.


IntroductieProcedures voor toeleveranciersmanagement horen ervoor te zorgen dat:a) de toeleverancier begrijpt wat zijn verplichtingen jegens de serviceprovider zijn

BedrijfServiceprovider(kan intern of

extern zijn)

Leverancier 1

Leverancier 2

Hoofdleverancier 3 Toeleverancier/-onderaannemer

Figuur 4.3.12 Voorbeeld van relatie tussen serviceproviders en toeleveranciers



b) aan geldige en overeengekomen eisen wordt voldaan, binnen overeengekomen servicelevels en -scopec) changes worden gemanagedd) businesstransacties tussen alle partijen worden geregistreerde) informatie over de performance van alle toeleveranciers in het oog kan worden gehouden en dat hier

actie op wordt genomen

ContractmanagementDe serviceprovider hoort een manager aan te stellen die verantwoordelijk is voor contracten en over-eenkomsten met toeleveranciers.Waar een aantal personeelsleden zich met deze taak bezighouden, hoort er een gemeenschappelijk pro-ces te zijn die ervoor zorgt dat informatie over toeleverancierperformance in het oog wordt gehouden en dat hier actie op wordt genomen. Er hoort een vastomlijnd contact bij de serviceprovider te zijn die verantwoordelijk is voor de relatie met elke toeleverancier. Alle leverancierscontracten horen een reviewkalender te bevatten om te beoordelen of de bedrijfsdoel-stellingen bij de besteding van een service geldig blijven.Er hoort een helder gedefi nieerd proces te zijn voor het managen van ieder contract. Het proces voor aanpassing van een contract hoort ook helder te zijn gedefi nieerd. Alle wijzigingen van deze procedure horen formeel te worden bekendgemaakt aan alle betrokken leveranciers.Er hoort een lijst van contactpunten binnen de onderscheiden organisaties (van toeleveranciers en serviceprovider) te worden bijgehouden. Als in een contract boetes of bonussen zijn opgenomen, hoort duidelijk te zijn gesteld wanneer deze moeten worden uitgevaardigd of verleend. Als er is voldaan aan de eisen, hoort dit te worden gerapporteerd.

Defi nitie van serviceDe serviceprovider hoort voor elke service en toeleverancier te onderhouden:a) een defi nitie van services, rollen en verantwoordelijkhedenb) scope van de servicec) contractmanagementproces, autorisatieniveaus en een contract-exitpland) betalingstermijnen indien relevante) overeengekomen rapportageparameters en records van gerealiseerde performance

Managen van leveranciersketensHet hoort duidelijk te zijn of de serviceprovider direct met alle toeleveranciers contact heeft of dat een hoofdleverancier de verantwoordelijkheid neemt voor toeleveranciers. De hoofdleverancier hoort de namen, verantwoordelijkheden en relaties tussen alle toeleveranciers te registreren en dit indien nodig beschikbaar te stellen aan de serviceprovider.De serviceprovider hoort bewijs te verwerven dat hoofdleveranciers de toeleveranciers formeel mana-gen, waar van toepassing begeleid door de eisen in ISO 20000-1.

Management van contractuele geschillenZowel de serviceprovider als de toeleverancier hoort een proces in werking te hebben voor het managen van geschillen en dit hoort te zijn beschreven of naar te zijn verwezen in het contract. Er hoort een escalatieroute beschikbaar te zijn voor geschillen die niet via de normale weg kunnen worden opgelost.Het proces hoort te borgen dat geschillen worden geregistreerd, onderzocht, dat er actie op wordt geno-men en dat ze formeel worden afgesloten.



Einde van het contractHet contractmanagementproces hoort voorzieningen te omvatten voor het einde van een contract -het-zij een verwacht einde, hetzij een vroegtijdig einde. Het hoort ook te voorzien in de overdracht van de service naar een andere organisatie.

Figuur 4.3.13 toont hoe dit deel van de standaard in een processchema kan worden gevisuali-seerd.

De relatie met de toeleverancier is vastgelegd in SLA’s of andere overeenkomsten. Deze documen-ten beschrijven de eisen die gesteld worden aan de services van de toeleveranciers. Het managen van de relatie met de toeleverancier en beheer van het contract zijn daarom belangrijke processen.

Gedocumenteerde leveranciersmanagementprocessen zijn een expliciete eis in de standaard. In deze processen moeten activiteiten worden beschreven voor belangrijke contractreviews, en voor de aanpak van contractuele geschillen en beëindiging van services. Als er meerdere toeleveranciers zijn, moet de hoofdleverancier het proces kunnen laten zien voor de beheersing van alle aanleve-rende leveranciers.

Documenten die niet mogen ontbreken bij toeleveranciersmananagement zijn leveranciers-SLA’s en geregistreerde verbeteracties.

RichtlijnenEen doorsnee organisatie zal veel toeleveranciers hebben, waarvan de meeste services of produc-ten leveren die de business gebruikt als een basisproduct (commodity), die de waardeketen van de business ondersteunen, maar onder controle van de klant. Het type leverancier en zijn contracten kunnen een beslissende invloed hebben op de wijze waarop de organisatie en het gehele SLA-raamwerk wordt opgebouwd. De relatie met sommige kernleveranciers is kritieker dan andere, en de kwaliteit van de service die ze leveren heeft een signifi cante invloed op de waardeketen. Dit beïnvloed de relatie met de IT-organisatie op drie niveaus:• strategisch – partnerstijlen, zoals het uitbesteden van een belangrijk deel van de IS-levering• tactisch – relaties die commerciele activiteiten en businessinteractie ondersteunen• operationeel – producten en services, in het bijzonder daar waar kant-en-klare alternatieven

te vinden zijn

Om de services te leveren moeten de juiste typen relaties worden ontwikkeld en onderhouden. Veel voorkomende typen zijn:• Interne leverancier – Een deel van de organisatie levert services aan een ander deel van de-

zelfde organisatie.• Enkel-, twee- of meervoudige uitbestedingen – Een verbintenis met een enkele leverancier

kan voortkomen uit voorkeurstarieven, of uit specialisatie en aanpak van de leverancier. Meer-voudige uitbesteding (multiple-sourcing) vermindert de afhankelijkheid van één leverancier en bevordert prijscompetitie.

• Partnerschap – Wordt vastgelegd op leidinggevend niveau. Echte partnerschaprelaties verei-sen een samenwerking op strategisch niveau en zijn gebaseerd op risicodeling.

• Outsourcing – In toenemende mate wordt het eigendom van servicelevering overgedragen van een interne naar een externe leverancier.



Escalatieroute beschikbaar

Met inbegrip van:- reviewrooster- basis voor straffen en bonussen indien van toepassing- verwijzing naar processen voor het managen van geschillen- lijst van contactpunten binnen respectievelijke organisaties- een definitie van services, rollen en verantwoordelijkheden- servicescope- contractmanagementproces, de autorisatieniveaus en een contractbeëindigingsplan- betalingsvoorwaarden indien relevant- afgesproken rapportageparameters en records van bereikte performance

Omvat namen en verantwoordelijkheden

- verwacht einde- vroegtijdig einde- overdracht aan andere partij

Ten minste jaarlijks

Legenda van verantwoordelijke rollen:

Records vanverbeteracties

Compliancerapport

****

****

*

***

***

*

**

*

*

*

*

**********

Serviceproviderserviceprovider en hoofdleverancierhoofdleverancieralle relevante partijen

Benoem eencontractmanager

voor elke leverancier

Accordeer endocumenteer

procesinterfaces

Documenteer allerollen en relatiestussen hoofd- entoeleveranciers

Handel contractuelegeschillen af

Toon aan dattoeleveranciers aan

eisen kunnen voldoen

Voer een groot reviewuit van het contract

of de formeleovereenkomst

Change the contract

Documenteerleveranciers-

managementproces

Accordeer endocumenteer eisen,

bereik, serviceniveau encommunicatieprocessenwaar toeleverancier(s)aan moeten voldoen

Handel eindeservice af


Monitor en reviewtoeleveranciers-

performance metoog op targets

Stel verbeteractiesvast en registreer ze

Zorg voor bewijs dathoofdleveranciersde toeleveranciers

managen

Toeleveranciers-SLA ofandere documenten

Procesinterfaces

Rollen en relaties

RfC's indien vantoepassing

Geschilrecord

Toeleveranciers-managementproces

Records vanverbeteracties

Compliancerapport

Interfaces:

Toeleveranciersprocessen- documentinterfaces


Changemanagementproces- manage wijzigingen van de contract(en) en SLA('s)




Figuur 4.3.13 Leveranciersmanagement



Verschillende factoren zullen de relatie of mix van relaties beinvloeden. Een strategisch hulpmid-del voor positionering zoals het profi elmodel in fi guur 4.3.14 kan de organisatie helpen beslissen over de juiste aanpak.

Ongeacht het type relatie moet de relatie altijd worden ondersteund door een contract of SLA, of een OLA als het een relatie met een interne leverancier betreft. Hiermee worden alleen de elementen van de relatie geformaliseerd en vastgelegd. Het succes van de relatie is afhankelijk van mensenkennis en inzicht in de business De geformaliseerde relaties betreffen:• scope en dekking• documentatieaanpak en verantwoordelijkheid• contractmanagement• reviews en changemanagement• relatie- en perfomancemanagement• baten, kosten risicomanagement• performance-acceptatiecriteria• beschikbaarheidsacceptatiecriteria • kostencriteria• overeenstemming over performance, beschikbaarheid, grens aan kosten• juridische clausules

Belangrijke toeleverancier

Basisproductenmet hoge waarde,

laag risico

Hoofdleverancier

Service metlage waarde,hoog risico

Koppeling leveranciers

Bedrijfswaarde

Strategische toeleverancier

Service methoge waarde,hoog risico

Toeleverancier van basisproducten

Basisproductenmet lage waarde,

laag risico

Toenemend risico

Figuur 4.3.14 Profi leren van een leveranciersrelatie



4.4 Levering van IT-services

4.4.1 Servicecontinuïteit en beschikbaarheidsmanagement (6.3)

Doelstelling: Zorgen dat onder alle omstandigheden kan worden voldaan aan de ver-plichtingen die met de klant zijn aangegaan voor servicecontinuïteit en beschikbaarheid .


Beschikbaarheid en servicecontinuïteitseisen moeten op basis van bedrijfsplannen, SLA’s en risicoanalyses worden bepaald. De eisen moeten zowel toegangsrechten en responsietijden, als end-to-endbeschikbaarheid van systeemcomponenten betreffen.Beschikbaarheids- en servicecontinuïteitsplannen moeten ten minste jaarlijks worden ont wikkeld en gereviewd, om ervoor te zorgen dat onder alle omstandigheden aan de afgesproken eisen wordt voldaan, zowel bij een normale als bij een grootschalige verstoring van de service. Deze plannen moeten worden onderhouden om te borgen dat ze de overeen-gekomen changes weergeven die de business nodig heeft.De beschikbaarheidsplannen en de servicecontinuïteitsplannen moeten bij elke grootschalige change van de bedrijfsomgeving opnieuw worden getest.Het changemanagementproces moet de impact van elke change op het beschikbaarheids- en servicecontinuïteitsplan beoordelen.Beschikbaarheid moeten worden gemeten en vastgelegd. Ongeplande niet-beschikbaarheid moet worden onderzocht en hier moeten passende acties op worden genomen.

NOOT: Waar mogelijk moeten potentiële problemen worden voorspeld en moeten er preventieve acties worden genomen.

Servicecontinuïteitsplannen, contactlijsten en de confi guratiemanagementdatabase moeten beschikbaar zijn als er geen normale kantoortoegang is. Het servicecontinuïteitsplan moet informatie bevatten over de terugkeer naar de normale werksituatie. Het servicecontinuïteitsplan moet worden getest in het licht van de bedrijfsbehoeften. Alle continuïteitstesten moeten worden vastgelegd en testfouten moeten worden omgezet in actieplannen.

The code of practice in ISO 20000-2 stelt:

NOOT Aan grootschalige servicestoringen en of -calamiteiten kunnen vele redenen ten grondslag liggen, waaronder een denial-of-serviceaanval, grootschalige virusuitbraak, toegangsverbod of een na-tuurramp.

Algemeen

Servicecontinuïteit- en beschikbaarheidseisen horen te worden vastgesteld op basis van de bedrijfsprio-riteiten van de klant, de service level agreements en de ingeschatte risico’s. De serviceprovider hoort vol-doende servicevermogen te handhaven, met haalbare plannen die borgen dat in alle omstandigheden aan de overeengekomen eisen kan worden voldaan, zowel bij normaal als bij grootschalig serviceverlies.



De serviceprovider hoort planningen te maken voor bekende toe- of afname van data of gebruikersaan-tallen en voor verwachte pieken en dalen in werklast en andere toekomstige veranderingen die bekend zijn. Eisen horen toegangsrechten en responsietijden te omvatten, evenals end-to-endbeschikbaarheid van systeemcomponenten.

Servicebeschikbaarheid- en servicecontinuïteitsmanagement horen samen te werken om ervoor te zor-gen dat afgesproken servicelevels worden gehandhaafd. Deze eisen horen bepalend te zijn voor de acties, inspanningen en toekenning van resources voor de handhaving en ondersteuning van de be-schikbaarheid van de services.Processen die ervoor zorgen dat de vereiste beschikbaarheid wordt gehandhaafd horen ook de elementen van de servicelevering te omvatten die onder toezicht staan van de klant of andere serviceproviders.

Beschikbaarheid: monitoring en activiteitenBeschikbaarheidsmanagement hoort:a) beschikbaarheid van de service te monitoren en registrerenb) accurate historische data bij te houdenc) vergelijkingen maken met in SLA’s vastgelegde eisen, om afwijkingen van de afgesproken beschik-

baarheidstargets aan te tonend) afwijkingen te documenteren en reviewene) toekomstige beschikbaarheid te voorspellenf ) waar mogelijk, potentiële problemen te voorspellen en preventieve acties te nemen

Beschikbaarheidsmanagement hoort voor beschikbaarheid van alle componenten van de service te zorgen en corrigerende acties te registreren en uit te voeren.

Strategie van servicecontinuïteitDe serviceprovider hoort een strategie te ontwikkelen en onderhouden voor de algemene aanpak die moet worden gebruikt om te voldoen aan servicecontinuïteitsverplichtingen . Dit hoort risicoanalyse te omvatten en rekening te houden met afgesproken service-uren en kritieke bedrijfsperioden. De service-provider hoort voor iedere klantgroep en service overeen te komen:a) wat de maximaal acceptabele continue periode van serviceverlies isb) wat de maximaal acceptabele perioden van serviceverminderingc) wat acceptabele vervangende servicelevels zijn tijdens een periode van serviceherstel

De continuïteitsstrategie hoort met overeengekomen tussenpozen, ten minste jaarlijks, te worden gere-viewd. Alle wijzigingen van de strategie horen formeel te worden overeengekomen.

Planning en testen van servicecontinuïteitDe serviceprovider hoort ervoor te zorgen dat:a) continuïteitsplannen rekening houden met afhankelijkheden tussen service- en systeemcomponentenb) servicecontinuïteitsplannen en andere documenten die nodig zijn voor de ondersteuning van ser-

vicecontinuïteit, worden geregistreerd en onderhoudenc) verantwoordelijkheid voor de activering van continuïteitsplannen duidelijk is belegd, en de plan-

nen duidelijk verantwoordelijkheid toewijzen voor het nemen van actie op elke doelstelling



d) back-ups van data, documenten en software, en de uitrusting en medewerkers die nodig zijn voor serviceherstel, snel beschikbaar zijn bij een grootschalige servicestoring of -calamiteit

e) ten minste één kopie van alle servicecontinuïteitsdocumenten wordt bewaard en onderhouden op een veilige locatie op afstand, samen met de uitrusting die nodig is om de kopie te kunnen gebruiken

f ) medewerkers hun rol in de activering en/of uitvoering van de plannen begrijpen, en toegang kun-nen krijgen tot servicecontinuïteitsdocumenten

Servicecontinuïteitsplannen en gerelateerde documenten (bijvoorbeeld contracten) horen te worden gekoppeld aan het changemanagementproces en het contractmanagementproces. Servicecontinuïteitsplannen en gerelateerde documenten (bijvoorbeeld contracten) horen te worden beoordeeld op hun impact voordat systeem- en servicewijzigingen worden goedgekeurd, en voordat signifi cant nieuwe of aangepaste klanteisen zijn overeengekomen. Testen moeten worden uitgevoerd met een frequentie die voldoende is om zekerheid te verkrijgen over de effectiviteit van continuïteitsplannen, en het behoud hiervan bij veranderende systemen, processen, personeel en bedrijfsbehoeften. Het testen hoort een gezamenlijke betrokkenheid van klant en service-provider te zijn, gebaseerd op een overeengekomen set van doelstellingen. Teststoringen horen te worden gedocumenteerd en gereviewd om als input te dienen voor een serviceverbeterplan.


Servicecontïnuiteits- en beschikbaarheidsmanagementprocessen bestaan uit activiteiten die er-voor zorgen dat systemen beschikbaar zijn en blijven. In ISO 20000 bestaat een gecombineerd servicecontïnuiteits- en beschikbaarheidssysteem, terwijl dit in de praktijk twee verschillende, maar sterk gerelateerde, processen zijn.

Beschikbaarheidsplanning/-testen en servicecontinuïteitsplanning/-testen kunnen worden uit-gevoerd als een set van activiteiten. Monitoring- en beheeractiviteiten voor beschikbaarheid en servicecontinuïteit moeten echter apart worden uitgevoerd.

Beschikbaarheid- en servicecontinuïteitsmanagement hebben een interface met change- en con-fi guratiemanagement. Voor continuïteitsdoeleinden moet de CMDB beschikbaar zijn als nor-male toegang tot het kantoor is verhinderd. Het changemanagementproces beoordeelt de impact van een change op het beschikbaarheid- en continuïteitsplan. Changemanagement beheert ook alle changes in beschikbaarheids- en continuïteitsdocumentatie.

De interfaces tussen de beschikbaarheids- en servicecontinuïteitsmanagement en change- en con-fi guratiemanagement moeten worden vastgelegd (fi guur 4.4.2).

RichtlijnenIT-servicecontinuïteitsmanagement (ITSCM) maakt deel uit van businesscontinuïteitsmanage-ment (BCM) en is afhankelijk van informatie uit dit proces. De beschikbaarheid van IT-services wordt verzekerd door het combineren van risicobeperkende maatregelen , zoals het installeren van betrouwbare systemen met herstelopties (back-up, redundatie). Figuur 4.4.3 toont de ITSCM-activiteiten.



Met inbegrip van:– toegangsrechten– responsietijden– end-to-endbeschikbaarheid van systeemcomponenten

Met– bekende data van toename of afname gebruikers– verwachte pieken en dalen in werklast– elke andere toekomstige wijziging die bekend is

Hoort rekening te houden met:– afhankelijkheden tussen service- en systeemcomponenten– verantwoordelijkheid voor aansturing continuïteitsplannen is toegewezen– verantwoordelijkheid voor doelstellingen is toegewezen

Beschikbaar als normaletoegang wordt verhinderd,samen met contactlijstenen de CMDB

Met inbegrip van terugkeernaar normaal werken

Hoort risicoanalyse te omvattenen rekening te houden met:– afgesproken service-uren– kritieke bedrijfsperioden

Review ten minste jaarlijks

Changes moeten formeelworden overeengekomen

Neem externe factoren op(zoals externe serviceprovidersvan klant e.a.)

Snel beschikbaar hebben van:– backups van data, documenten en software– alle uitrusting en personeel dat nodig is voor serviceherstel na een belangrijke servicestoring

Ten minste een exemplaarvan alle documenten, samenmet de nodige uitrustingom gebruik mogelijk te maken

Bedrijfsplannen

SLA's

Risicoanalyse

Eisen voorbeschikbaarheid enservicecontinuïteit

Beschikbaarheid- enservicecontinuïteits-

plannen

Eisen voorbeschikbaarheid enservicecontinuïteit

Onderhoud voldoendeservicecapabiliteit omaan eisen te voldoen

Archiveer en onderhoudalle documenten

en uitrusting voorservicecontinuïteit

op een veilige plaats

Zorg dat medewerkershun rol begrijpen endat SC-documenten

beschikbaar zijn

Ontwikkel,onderhoud en

review strategie voorservicecontinuïteit

Bepaal eisen voorbeschikbaarheid enservicecontinuïteit

Ontwikkel, onderhoud,beschikbaarheid- enservicecontinuïteits-

plannen

Interfaces:


Changemanagement:- dien requests for change in- beoordeel de impact van elke change op het beschikbaarheids- en servicecontinuïteitsplan- beheers alle wijzigingen van beschikbaarheids- en servicecontinuïteitsdocumentatie- koppel documentatie aan changemanagement

Contractmanagementproces- koppel documentatie aan contractmanagement

Configuratiemanagementproces:- de CMDB hoort beschikbaar te zijn als normale kantoortoegang is verhinderd- na een calamiteit horen configuratie-audits te worden ingepland

Servicelevelmanagement- spreek servicelevels af voor elke klantgroep en service- beoordeel impact op servicecontinuïteitsdocumentatie alvorens afspraken te maken over klanteisen



Figuur 4.4.1 Processen voor servicecontinuïteit- en beschikbaarheidsmanagement



Actieplan

Records vancontinuïteitstesten

Beschikbaarheidsrecords

Records vanafwijkingen

Records vancorrigerende acties

Ten minstejaarlijks

In overeenstemmingmet bedrijfsbehoeften

Vertaal teststoringennaar actieplan

Monitor en registreerbeschikbaarheid

Onderzoek ongewildeniet-beschikbaarheid

Neem passende(corrigerende) acties

Constateer,documenteer en review

afwijkingen van debeschikbaarheidseisen

Voorspel toekomstigebeschikbaarheid en

potentiële problemen

Neem preventieve actie

Reviewbeschikbaarheids- en

servicecontinuïteitsplannen

Test beschikbaarheids- enservicecontinuïteitsplannen

(opnieuw)s

Records vancontinuïteitstesten

Bij elkebelangrijke change

Beschikbaarheids- enservicecontinuïteits-

plannen

Beschikbaarheidsrecords

Eisen aan SLA's

Beschikbaarheids- enservicecontinuïteitsplannen

Voer continuïteitstestenuit en registreer resultaten

Figuur 4.4.2 Processen voor servicecontinuïteit- en beschikbaarheidsmanagement - beschikbaarheidsprocessen



Bij het initiëren van ITSCM moeten de volgende activiteiten worden uitgevoerd:• Defi niëren van beleid – Dit beleid moet gebaseerd zijn op het businesscontinuïteitsbeleid en

er moet zo spoedig mogelijk mee worden gestart. Communiceer het beleid organisatiebreed zodat alle betrokkenen doordrongen zijn van het belang van ITSCM. Het management moet betrokkenheid tonen.

• Defi neer scope en relevante gebieden – Verzekeringseisen, kwaliteitsstandaarden zoals ISO 9000, securitymanagementstandaarden zoals BS 7799 en algemene bedrijfsrichtlijnen worden gebruikt om de aanpak en methoden te kiezen voor risicoanalyse en buisinessimpactanalyse. Ook wordt bepaald wat de geschikte managementstructuur (met toegewezen verantwoorde-lijkheden) en processtructuur zijn voor het omgaan met calamiteiten.

Initieer BCM

Bedrijfsimpactanalyse

Strategie voorservicecontinuïteit

Risicoanalyse

Implementeerstandby-regelingen

Ontwikkelherstelplannen

Verzekering

Opleidingen inzicht

ChangemanagementReviewen audit

Testen

Training

Initiatie

Eisen en strategie

Implementatie

Operationeel management

Fase 1

Fase 2

Fase 3

Stage 4

Implementeerrisicobeperkende

maatregelen

Organisatie- enimplementatieplanning

Ontwikkel procedures

Eerste testen

Figuur 4.4.3 ITSCM-procesmodel (gebaseerd op OGC’s BCM-model, nu gericht op ITSCM)



• Toewijzen resources – Het opzetten van een ITSCM-omgeving vereist soms een aanzienlijke investering in personeel en andere resources. Er is ook training nodig om te borgen dat het personeel is voorbereid op het ondersteunen van de eisen en strategie.

• Opzetten projectorganisatie – Het is aan te bevelen om een formele projectmanagementme-thode te gebruiken, bijvoorbeeld PRINCE2TM, ondersteund door planningsoftware.

Voordat u begint met de analyse van de IT-services is het raadzaam om vast te stellen welke rede-nen het bedrijf heeft om ITSCM onder te brengen bij businesscontinuïteitsmanagement. Ook moet de potentiële impact van een grote serviceonderbreking worden onderzocht. In sommige gevallen kan de business het een tijdje uithouden en zal de nadruk liggen op het herstellen van de services. In andere gevallen kan de business niet verder zonder IT-services en zal de nadruk liggen op preventieve maatregelen. De meeste bedrijven moeten een een balans zien te vinden tussen deze twee extremen.

Er wordt een service-analyse gemaakt gemaakt van de IT-services die essentieel zijn voor de busi-ness (zoals informatiesystemen, kantoorapplicaties, accountingapplicaties en e-mail) en die in overeenstemming moeten zijn met de SLA’s. Voor sommige niet-essentiele services volstaat wel-licht een ‘nood’-service met beperkte capaciteit en beschikbaarheid. Servicelevels mogen echter gedurende disaster recovery alleen worden aangepast in overeenstemming met de klant. Voor de kritieke services moet een afweging worden gemaakt tussen preventieve maatregelen en herstel-opties.

Deze analyse wordt gevolgd door een assessment van de afhankelijkheden tussen services en IT-resources. Informatie van beschikbaarheidsmanagement wordt gebruikt om te analyseren in hoeverre IT-middelen een kritieke functie vervullen in de ondersteuning van eerder besproken IT-services. Capaciteitsmanagement levert informatie over de noodzakelijke capaciteit. Het is nodig om de mate te bepalen waarin deze services in de toekomst verstoord kunnen raken: van uitval van de service tot volledig herstel van de service. Deze informatie wordt later gebruikt voor het onderkennen van herstelopties voor elke service.

Een risicoanalyse kan behulpzaam zijn bij het vaststellen van de risico’s waaraan de business bloot-staat en bij het leveren van waardevolle managementinformatie over eventuele preventieve maat-regelen. Het bijhouden van een disaster recovery-plan kan kostbaar zijn, preventieve maatregelen hebben daarom de voorkeur. Daar waar preventieve maatregelen ontoereikend zijn, moet worden vastgesteld of er nog risico’s zijn waarvoor een rampenplan (contingency plan) nodig is. Figuur 4.4.4 laat de relaties zien tussen risicoanalyse en risicomanagement. Dit voorbeeld is gebaseerd op CRAMM , de risicoanalyse- en managementmethode van het voormalige Central Computing and Telecommunications Agency (CCTA), nu OGC.

Dit model gaat uit van vier stappen:1. Het in kaart brengen van de relevante IT-componenten (assets) – denk aan gebouwen, syste-

men, data, et cetera. Effectieve identifi catie van assets vereist vastlegging van eigenaar en doel.2. Het analyseren van de bedreigingen voor de assets en hun afhankelijkheden, en inschatten van

de waarschijnlijkheid (hoog, midden, laag) dat zich een calamiteit zal voordoen. Bijvoorbeeld een onbetrouwbaar elektriciteitsnetwerk in een stormgevoelig gebied.



3. Het identifi ceren van de kwetsbaarheid van de assets en classifi catie daarvan (hoog, midden, laag). Een bliksemafl eider geeft wel wat bescherming tegen blikseminslag, maar bliksem kan nog steeds het netwerk en de computersystemen aantasten.

4. De bedreigingen voor, en kwetsbaarheden van, de IT-componenten worden geëvalueerd. Dit levert een schatting op van het risiconiveau.

Er bestaat verschil tussen risicoreductie (preventie), herstelacties van bedrijfsactiviteiten en IT-herstelopties . Preventieve maatregelen kunnen op basis van risicoanalyse worden getroffen, na zorgvuldige overweging van de kosten van de maatregelen en het risiconiveau. Als er nog risico’s zijn die niet kunnen worden geëlimineerd door preventieve maatregelen, dan moeten die wor-den opgepakt door herstelplanning (recovery planning). Om businesscontinuïteit te waarborgen, moeten herstelopties met de volgende zaken rekening houden:• Personeel en accommodatie – Hoe wordt omgegaan met alternatieve locaties, meubels,

transport en reisafstanden en de medewerkers die nodig zijn voor de ondersteuning van de business?

• IT-systemen en netwerken – Herstelopties worden na deze opsomming besproken bespro-ken.

• Supportdiensten – Denk aan elektriciteit, water, telefoon, post en koeriersdiensten.• Archieven – Denk aan bestanden, documenten, papiergebaseerde systemen en referentiema-

teriaal.• Services van derden – Denk aan services zoals e-mail en internet serviceproviders.

Er zijn een aantal opties voor het herstel van IT-services:• Niets doen – Slechts weinig bedrijven kunnen zich deze aanpak permitteren. Niettemin

hoortvoor elke service te worden onderzocht of deze optie aanvaardbaar is, bijvoorbeeld als kortetermijnoplossing.

• Teruggaan naar een handmatig (papiergebaseerd) systeem - Deze aanpak is in het alge-meen onacceptabel voor bedrijfskritieke services omdat er onvoldoende personeel zal zijn dat ervaring heeft met traditionele systemen. Papiergebaseerde systemen kunnen echter wel een oplossing zijn voor minder belangrijke en kleine services.

• Wederzijdse afspraken – Als twee organisaties dezelfde soort hardware hebben kunnen zij afspreken om elkaar bij calamiteiten van faciliteiten te voorzien. Hiertoe moeten de twee bedrijven tot een overeenkomst komen. Ook moeten ze ervoor zorgen dat changes zodanig

Risicoanalyse

Risicomanagement

Assets Bedreigingen Kwetsbaarheden

Tegenmaatregelen(preventie & herstel)

Risico's

Figuur 4.4.4 Het CCTA-model voor risicoanalyse (Bron: OGC)



worden gecoördineerd dat beide omgevingen inwisselbaar blijven. Capaciteitsmanagement hoort ervoor te zorgen dat reservecapaciteit niet voor andere doeleinden wordt ingezet of snel kan worden toegekend. Deze optie is echter minder aantrekkelijk in de gedistribueerde com-puteromgevingenvan tegenwoordig, waarin meer vraag is naar afzonderlijke processorkracht en systemen met hoge beschikbaarheid, zoals bankautomaten en online bankieren.

• Geleidelijk herstel(cold stand-by) – Deze aanpak kan worden ingezet door bedrijven die enige tijd zonder IT-services kunnen, bijvoorbeeld 72 uur. Er wordt een lege computerruimte geleverd op een overeengekomen vaste locatie of een mobiele computerruimte op het be-drijfsterrein, de zogenaamde mobiele faciliteit. De ruimte wordt geleverd met elektriciteit, airconditioning, netwerkfaciliteiten en telefoonlijnen. Deze optie kan via een contract met een externe leverancier worden geleverd. Er moeten afzonderlijke overeenkomsten worden gesloten met toeleveranciers van IT-componenten, om ervoor te zorgen dat de benodigde componenten tijdig kunnen worden geleverd. Het voordeel van deze aanpak is dat de faciliteit altijd beschikbaar is. De opbrengsten en kosten verschillen bij een vaste of mobiele faciliteit.

• Tussentijds herstel (warm stand-by) – Deze aanpak geeft toegang tot een vergelijkbare ope-rationele omgeving, waar de services na een korte onderbreking (24-72 uur) normaal kunnen worden voortgezet. Deze aanpak heeft drie varianten:– Intern (mutual fallback): Levert volledig herstel met een minimale omschakeltijd. Orga-

nisaties met meerdere gedistribueerde systemen gebruiken meestal een variatie van deze aanpak waarbij op elk systeem een deel van de benodigde capaciteit wordt gereserveerd. Deze reservecapaciteit wordt gemonitord door capaciteitsmanagement (net als bij de optie van wederzijdse afspraken, zie boven).

– Extern: Een commerciële service die een derde partij (herstelorganisatie) aan verschillende klanten levert. De kosten van de service worden gedeeld tussen de klanten en zijn afhanke-lijk van de benodigde hard- en software en de overeengekomen periode waarin de faciliteit wordt geleverd (bijvoorbeeld, zestien weken). Deze regelingen worden meestal getroffen om de tijd te overbruggen die nodig is voor het inrichten van een cold-stand-by-faciliteit. Deze variant is relatief duur en de faciliteit zal vaak verder van het bedrijfsgebouw zijn verwijderd.

– Mobiel: De infrastructuur voor deze variant wordt ‘klaar voor gebruik’ in een trailer gele-verd. De trailer functioneert als een computerruimte en heeft faciliteiten voor klimaatrege-ling, zoals airconditioning. Elektriciteit, data en telecommunicatie moeten beschikbaar zijn op aangewezen punten, op bepaalde afstand van het gebouw. Voordelen van deze variant zijn onder andere de korte responsietijd en de nabijheid van het bedrijfsgebouw. Deze vari-ant is alleen beschikbaar voor een beperkt aantal hardwareplatformen. Een aantal van de grotere hardwareleveranciers leveren deze service met behulp van een aantal verschillende standaard hardwareconfi guraties. Op afgesproken tijden, bijvoorbeeld een keer per jaar, komt de trailer bij het bedrijf langs om de hersteloptie te testen.

• Onmiddelijk herstel (hot start, hot stand-by) – Deze variant levert onmiddellijk, of zeer snel, herstel van services. Bijvoorbeeld binnen 24 uur. Dit kan worden gerealiseerd door de levering van een duplicaat productieomgeving met spiegeling van data of zelfs productiepro-cessen. Deze laatste optie wordt meestal in nauwe samenwerking met beschikbaarheidsma-nagement opgezet.

In veel gevallen kan een combinatie van bovenstaande varianten worden toegepast. Bijvoorbeeld een trailer met een operationeel computercentrum (mobiele hot start) als tijdelijke oplossing tot-dat draagbare faciliteiten zijn opgezet en nieuwe hostcomputers zijn afgeleverd (mobiele koude



start). Normale werkzaamheden worden hervat na renovatie van het gebouw en de verhuizing van de hostcomputers.

Als de businessstrategie is bepaald en de keuzes zijn gemaakt, wordt ITSCM geïmplementeerd en worden de plannen voor IT-faciliteiten in detail uitgewerkt. Een organisatie moet zijn ingericht om ITSCM te implementeren. Dit houdt in: management (crisismanager), coördinatie, en her-stelteams voor elke service. Op het hoogste niveau moet er een allesomvattend plan zijn waarin de volgende (deel-)plannen aan bod komen: • reactieplan voor noodsituaties• schade-assessmentplan• herstelplan• plan waarin staat wat te doen met vitale data, inclusief records op papier• crisismanagement- en PR-plannen

Al deze plannen worden gebruikt voor de beoordeling van, en de reactie op, noodsituaties. Er kan daarna worden besloten of het bedrijfsherstelproces moet worden gestart. Als dat het geval is, moet het volgende niveau van plannen in gang worden gezet, waaronder:• accommodatie- en servicesplannen• computersysteem- en netwerkplan• telecommunicatieplannen (toegankelijkheid en links)• securityplannen (integriteit van data en netwerken)• personeelsplannen• fi nanciële en administratieve plannen

Preventieve maatregelen om de impact van een incident te beperken, worden genomen in samen-werking met beschikbaarheidsmanagement en kunnen bestaan uit:• gebruik van UPS en back-up stroomvoorzieningen• fouttolerantiesystemen• externe (off-site) opslag- en RAID-systemen

Er moet ook worden gestart met de introductie van stand-by-overeenkomsten over personeel, gebouwen en telecommunicatie. Zelfs tijdens de calamiteitsperiode kan er een start worden ge-maakt met het herstellen van de normale situatie en het bestellen van nieuwe IT-componenten. Vooraf kunnen slapende contracten worden opgesteld met leveranciers. Dit betekent dat er gete-kende orders beschikbaar zijn voor de te leveren componenten en levertijd en prijs vooraf bekend zijn. Als de ramp dan plaatsvindt kan de leverancier de order verwerken zonder eerst offertes te hoeven sturen. Dergelijke ‘slapende contracten’ moeten elk jaar worden bijgewerkt omdat prijzen en modellen veranderen. Bij het updaten van de contracten hoort rekening te worden gehouden met de confi guratie-uitgangspunten .

De volgende activiteiten kunnen worden uitgevoerd voor het opzetten van stand-by-overeen-komsten:• onderhandelen met derden over off-site-herstelfaciliteiten • onderhouden en bevoorraden van de herstelfaciliteiten• kopen en installeren stand-by-hardware (slapende contracten)• beheren van de slapende contracten



De herstelplannen moeten gedetailleerd zijn, alle benodigde procedures bevatten en onder for-meel beheer van changemanagement staan. Alle direct betrokkenen of degenen die invloed on-dervinden van de plannen, moeten worden geïnformeerd. Confi guratiemanagement speelt een belangrijke rol in het monitoren van confi guratie-uitgangspunten zoals vermeld in het herstel-plan. Als ze dit niet zouden doen, kan het bijvoorbeeld gebeuren dat er in noodsituaties geen ‘ko-pie’ van een server aanwezig is in de back-up-faciliteit die nodig is voor een warme, externe start.

Het herstelplan moet alle elementen bevatten die relevant zijn voor het herstellen van de bedrijfs-activiteiten en IT-services, inclusief:• Introductie – Beschrijft de structuur van het plan en voorziene herstelfaciliteiten.• Update – Beschrijft de procedures en overeenkomsten voor het onderhouden van het plan, en

houdt wijzigingen aan de infrastructuur bij.• Routeringslijst – Laat zien welke delen van het plan naar wie moeten worden verzonden (als

het plan is onderverdeeld waarbij wordt aangegeven wie wat moet doen).• Herstelinitiatie – Beschrijft wanneer en onder welke voorwaarden een beroep wordt gedaan

op het plan.• Calamiteitenclassifi catie – Als het plan de procedures beschrijft voor verschillende calamitei-

ten, moet hier de ernst van de calamiteit worden beschreven (klein, gemiddeld, groot), duur (dag, week, weken), en de schade (licht, gemiddeld, zwaar).

• Specialistische delen – het plan moet worden verdeeld in zes specialistische delen: – Administratie - Hoe en wanneer wordt er een beroep gedaan op het plan, welke managers

en personeelsleden zijn betrokken en waar is het controlcentrum?– IT- infrastructuur - Hardware, software en telecommunicatie die het herstelsysteem moet

leveren. Herstelprocedures en slapende contracten voor de aankoop van nieuwe IT-compo-nenten.

– Personeel - Personeel dat nodig is bij de herstelfaciliteit en, als de faciliteit ver van het bedrijf verwijderd is, transport en verblijf.

– Security - Instructies over bescherming tegen diefstal, brand en explosies op de ‘thuislocatie’ en op de ‘locatie op afstand’. Informatie over externe opslagfaciliteiten zoals datakluizen.

– Uitwijklocaties - Informatie over contracten, personeel en functies, security en transport.– Herstel/restoratie - Procedures om de normale situatie te herstellen (bijvoorbeeld het ge-

bouw), de omstandigheden waaronder de procedures worden aangeroepen en slapende contracten.

Het herstelplan levert het framework voor het opstellen van herstelprocedures. Het is belangrijk om effectieve procedures te ontwikkelen, zodat iedereen herstel kan realiseren door de procedures te volgen. Deze horen de volgende zaken te behandelen:• installatie van hardware en netwerkcomponenten• herstel van applicaties, databases en data

Voeg deze en andere relevante procedures toe aan het herstelplan.

Het initieel testen van de plannen, procedures en technische componenten is een belangrijk as-pect van ITSCM. Testen moeten plaatsvinden op basis van scenario’s en moet duidelijke doelstel-lingen en succescriteria hebben.



Effectieve training van (IT-)medewerkers en bewustzijn van alle andere medewerkers en de or-ganisatie, zijn essentieel voor het succes van het ITSCM-proces. IT-medewerkers moeten de medewerkers van de bedrijfsherstelteams trainen om er zeker van te zijn dat zij bekend zijn met mogelijke problemen, en in staat zijn ondersteuning te leveren bij hersteloperaties. De daadwer-kelijke noodfaciliteiten op de thuislocatie of locatie op afstand moeten ook deel uitmaken van de training en testen.

Plannen moeten regelmatig worden gereviewd en geverifi eerd om te borgen dat ze actueel blijven. Het gaat hierbij om alle ITSCM-aspecten. Als het om IT gaat, moet een dergelijke audit elke keer worden uitgevoerd als er een signifi cante change van de IT-infrastructuur heeft plaatsgevonden, bijvoorbeeld de introductie van een nieuw systeem, netwerk of serviceprovider.

Audits moeten ook worden uitgevoerd bij een verandering van de businessstrategie of IT-strate-gie. Organisaties waar regelmatig changes plaatsvinden, kunnen een programma implementeren voor het verifi ëren van ITSCM-concepten. All changes in plannen en strategie vallen onder regie van changemanagement. Changemanagement speelt een belangrijke rol in het actueel houden van alle ITSCM-plannen en zorgt ervoor dat de impact van elke change aan het herstelplan wordt geanalyseerd.

Borging (Assurance) zorgt ervoor dat de kwaliteit van het proces (procedures en documenten) en de deliverables voldoen aan de businesseisen van het bedrijf.

CSF’s voor ITSCM zijn:• een effectief confi guratiemanagementproces• support en betrokkenheid van de gehele organisatie• actuele en effectieve tools• specifi eke training voor iedereen die in het proces actief is• regelmatig testen van het herstelplan

KPI’s zijn onder andere:• aantal onderkende tekortkomingen van het herstelplan• gederfde opbrengsten als gevolg van de calamiteit• kosten van het proces

Bij een calamiteit zullen er managementrapporten zijn over de oorzaak en het gevolg ervan en in hoeverre deze succesvol is afgehandeld. Alle geconstateerde zwakheden worden aangepakt met verbeterplannen.

De managementrapportages van het ITSCM-proces bevatten ook evaluatierapporten van her-stelplantesten. Deze zijn voor kwaliteitsborging. Het proces rapporteert ook over het aantal wij-zigingen aan herstelplannen als gevolg van andere belangrijke changes. Rapportages behandelen ook nieuw bedreigingen.

Wat beschikbaarheidsmanagement (hoge beschikbaarheid) betreft, dupliceer essentiële componen-ten zoveel mogelijk, en gebruik foutdetectie- en correctiesystemen om aan hoge beschikbaar-heidsnormen te voldoen. Automatische terugvalvoorzieningen worden vaak aangesproken als



zich daadwerkelijk een probleem voordoet. Daarnaast is het nodig om organisatorische maatre-gelen te treffen. Hierin kan worden voorzien door beschikbaarheidsmanagement .

Er kan met beschikbaarheidsmanagement worden gestart als de business heeft aangegeven wat de beschikbaarheidseisen voor de service zijn. Het is een proces dat pas eindigt wanneer de service wordt uitgefaseerd. De input voor beschikbaarheidsmanagement bestaat uit (zie fi guur 4.4.5):• beschikbaarheidseisen van de business • impactanalyse van alle businessprocessen die door IT worden ondersteund• beschikbaarheids-, betrouwbaarheids-, en onderhoudbaarheidseisen van IT-componenten• gegevens over defecten die services of componenten aantasten zoals incidenten problemre-

cords en rapporten• confi guratie- en monitoringdata van services en componenten• gerealiseerde servicelevels, vergeleken met overeengekomen servicelevels, voor alle services die

in de SLA zijn opgenomen

De output van beschikbaarheidsmanagement is:• ontwerpcriteria (voor beschikbaarheid en herstel) voor nieuwe en verbeterde services• technologie die nodig is voor het realiseren van een infrastructuur die de benodigde veerkracht

heeft om de impact van defecte infrastructuurcomponenten teniet te doen• garanties over beschikbaarheid, herstel en onderhoudbaarheid van infrastructuurcomponen-

ten die nodig zijn voor de service• rapporten over de behaalde beschikbaarheid, herstel en onderhoudbaarheid• monitoringeisen aan beschikbaarheid, herstel en onderhoudbaarheid• een beschikbaarheidsplan voor de proactieve verbetering van de IT-infrastructuur• actieplannen en maatregelen in reactie op het niet halen van de SLA-afspraken

Businesseisen aanbeschikbaarheid

Bedrijfsimpactanalyse

Eisen aan beschikbaarheid,betrouwbaarheid enonderhoudbaarheid

Incident- en problemdata

Configuratie- enmonitoringdata

Servicelevelresultaten

Ontwerpcriteria voorbeschikbaarheid en herstel

Assessment van veerkracht vanen risico's voor IT-infrastructuur

Afgesproken targets voorbeschikbaarheid, betrouwbaarheiden onderhoudbaarheid

Rapporten over de gerealiseerdebeschikbaarheid, betrouwbaarheiden onderhoudbaarheid

Monitoren van beschikbaarheid

Verbeterplannen voor beschikbaarheid

ActieplannenMaatregelen volgend op schending van SLA's

Beschikbaarheidsmanagement

Figuur 4.4.5 Input en output van beschikbaarheidsmanagement (Bron: OGC)



Beschikbaarheidsmanagement bestaat uit een aantal kernactiviteiten die te maken hebben met planning en monitoring.• Planning:

– bepalen beschikbaarheidseisen– ontwerpen voor beschikbaarheid– ontwerpen voor herstelbaarheid– managen van security-issues– managen van onderhoud– opstellen beschikbaarheidsplan

• Monitoring:– meten en rapporteren

Voordat een SLA kan worden afgerond, moeten de beschikbaarheidseisen zijn vastgesteld. Deze eisen moeten zowel betrekking hebben op de nieuwe IT-services als op changes van bestaande IT-services. Het moet in een zo vroeg mogelijk stadium bekend zijn of en hoe de IT-organisatie aan de eisen kan voldoen.

Deze activiteit identifi ceert:• belangrijkste businessfuncties• overeengekomen defi nitie van storingstijd (downtime)• kwantifi ceerbare beschikbaarheidseisen• kwantifi ceerbare impact van ongeplande storingstijd op businessfuncties• openingstijden van de klant• overeenkomsten over onderhoudsschermen

Het is van groot belang om in een vroeg stadium de beschikbaarheidseisen te defi niëren om mis-verstanden en verschil in interpretatie in een later stadium te voorkomen.

Kwetsbaarheden die van invloed zijn op de beschikbaarheid horen zo snel als mogelijk te wor-den onderkend. Hiermee kunnen buitensporige ontwikkelkosten, ongeplande uitgaven, Single Points Of Failure (SPOF), extra kosten van leveranciers en uitgestelde releases worden vermeden.

Een goed ontwerp, dat gebaseerd is op de juiste beschikbaarheidsnormen, maakt het mogelijk om effectieve onderhoudscontracten af te sluiten met leveranciers. Tijdens het ontwerpproces kunnen meerdere technieken worden gebruikt zoals Component Failure Impact Analysis (CFIA) voor het identifi ceren van SPOF’s, CCTA Risk Analysis and Management Method (CRAMM) of elke andere risicomanagement- en simulatietechniek.

Als niet kan worden voldaan aan de beschikbaarheidsnormen is de beste optie om te kijken of het ontwerp kan worden verbeterd. Ook kan het gebruik van extra technologie, andere methoden, een nieuwe releasestrategie, een beter of ander ontwerp en ontwikkeltools leiden tot verbetering. Als de eisen zeer hoog zijn, zal moeten worden overwogen om een andere foutbestendige tech-nologie te gaan gebruiken, effi ciënter gebruik te maken van andere serviceprocessen (incident, problem, change) of extra servicemanagementhulpmiddelen in te zetten. De mogelijkheden en keuzes worden in belangrijke mate bepaald door de fi nanciële middelen die beschikbaar zijn.



Omdat volledig ononderbroken beschikbaarheid zeer onwaarschijnlijk is, kunnen periodes van onbeschikbaarheid worden gebruikt voor preventieve acties zoals soft- en hardware upgrades. Changes kunnen ook in deze periodes worden geïmplementeerd.

Als een IT-service wordt onderbroken, is het belangrijk dat het incident snel en adequaat wordt opgelost en dat wordt voldaan aan de overeengekomen beschikbaarheidsnormen. Een effectief incidentmanagementproces met passende escalatie-, communicatie-, back-up- en herstelproce-dures draagt hiertoe bij.

Security en betrouwbaarheid zijn nauw met elkaar verbonden. Een slecht informatiesecurity-ont-werp kan een negatieve invloed hebben op de beschikbaarheid van de service. Daarom moeten securitykwesties, en de invloed die ze hebben op de servicelevering, gedurende de planningsfase worden geanalyseerd.

Belangrijke securitykwesties zijn:• bepalen wie er bevoegd zijn om beveiligde ruimtes te betreden• bepalen welke kritieke autorisaties mogen worden uitgegeven

Meten en rapporteren zijn belangrijke activiteiten van beschikbaarheidsmanagement. Ze dragen namelijk bij aan het toetsen van serviceovereenkomsten, het oplossen van problems en verbeter-voorstellen. De tijd dat een service onbeschikbaar is kan worden gereduceerd door de fasen, zoals die worden getoond in fi guur 4.4.6, zo kort mogelijk te houden:• detectie/registratie – de tijd tussen het tijdstip waarop het incident plaatsvindt en de detectie

en registratie.• diagnose – de tijd die nodig is voor het stellen van de diagnose• reparatie – de tijd die nodig is voor de fysieke reparatie• herstel – de tijd die nodig is om het systeem weer te activeren• hervatting – de tijd die nodig is om de service weer volledig te hervatten en beschikbaar te

maken voor de klant

Incident Incident

Opgespoord

Opsporingstijd

Uptime, tijd tussen storingen

Betrouwbaarheidsfactor

Tijd tussen systeemincidenten

Storingstijd, hervattingstijd service

Onderhoudbaarheidsfactor

Registratietijd Diagnosetijd Reparatietijd Hersteltijd Hervattingstijd

Geregistreerd Gediagnosticeerd Gerepareerd Hersteld Hervat

Figuur 4.4.6 De uitgebreide levenscyclus van incidenten



Services moeten zo snel als mogelijk weer beschikbaar komen voor de gebruikers. De Mean Time to Restore Service (MTRS) is de gemiddelde hersteltijd binnen welke een functie (service, systeem of component) na uitval weer operationeel is. Analyses van de reactie van de MTRS op elke factor zijn nuttig voor de verbetering van de performance en het ontwerp van services. De MTRS kan worden verkleind door te sturen op elk van zijn componenten.

Het is van belang om over beschikbaarheid te rapporteren vanuit het perspectief van de klant. Lever alleen informatie over de beschikbaarheid van essentiële businessfuncties, applicatieservices en data, in plaats van informatie te geven over de beschikbaarheid van technische componenten.

Het beschikbaarheidsplan is een van de belangrijkste producten van beschikbaarheidsma-nagement. Dit is niet een implementatieplan voor beschikbaarheidsmanagement, maar een langetermijn plan over beschikbaarheid voor de komende jaren. Het plan moet in ieder geval de huidige situatie beschrijven. Verder kan het (op een later moment) worden uitgebreid met verbeteracties en richtlijnen voor bestaande services, en ook met plannen voor nieuwe services en richtlijnen voor beheer. Een volledig en accuraat plan vereist samenwerking met servicelevelma-nagement, ITSCM, capaciteitsmanagement, fi nancieel management, en applicatieontwikkeling (direct of via changemanagement).

Voor effi ciënt beschikbaarheidsmanagement zijn tools nodig ter ondersteuning van de volgende activiteiten:• bepalen storingsduur• vastleggen historische informatie • genereren rapporten • uitvoeren statistische analyses • uitvoeren van impactanalyses

Beschikbaarheidsmanagement gebruikt informatie van incidentrecords, informatie uit de CMDB en de capaciteitsdatabase. Informatie kan worden opgeslagen in een eigen beschikbaarheidsma-nagementdatabase.

Er is een groot aantal methoden en technieken ter ondersteuning van planning, verbetering en rapportage, waaronder:• Component Failure Impact Analysis (CFIA) - gaat uit van een beschikbaarheidsmatrix

waarin per service wordt bijgehouden welke componenten van strategisch belang zijn en welke rol zij spelen. Een goed ingerichte CMDB, waarin de relaties tussen services en pro-ductiemiddelen zijn vastgelegd is een goed hulpmiddel bij het opstellen van de matrix. Figuur 4.4.7 toont een voorbeeld van een CFIA-matrix. Uit analyse blijkt dat confi guratie-items die bij veel services een ‘X’ opleveren (wat betekent dat bij een storing van de CI de service niet beschikbaar is), een belangrijke rol spelen in de IT-infrastructuur (horizontale analyse). Daarnaast blijkt dat services die veel ‘X’-markeringen hebben complex en foutgevoelig zijn (verticale analyse). De techniek kan ook worden toegepast op afhankelijkheden van derden (advanced CFIA).

• Fault Tree Analysis (FTA) - is een techniek die wordt gebruikt om de keten van events te bepalen die tot een storing van een IT-service leidt. Voor elke service wordt een aparte boom-



structuur opgesteld met behulp van Boolean-symbolen. Deze structuur wordt van onder naar boven gelezen. FTA maakt onderscheid in de volgende events:– Basic events - betreft de input in het diagram (de bolletjes), zoals stroomstoringen en bedie-

ningsfouten. Naar deze events wordt geen verder onderzoek verricht.– Resulting events - knooppunten in het diagram die het resultaat zijn van een combinatie van

eerdere events.– Conditional events - events die alleen onder bepaalde voorwaarden voorkomen, zoals bij het

uitvallen van de airconditioning.– Trigger events - events die de oorzaak zijn van andere events, zoals een door een UPS aange-

stuurde automatische shutdown.Events kunnen worden gecombineerd met behulp van logische schakelingen, zoals:

– AND-schakeling - het resulterende event treedt alleen op als alle inputs tegelijk optreden.– OR-schakeling - het resulterende event treedt alleen op als een of meer van de inputs optre-

den.– XOR-schakeling - het resulterende event treedt op als slechts een van de inputs optreedt.– Inhibit-schakeling - het resulterende event treedt op als niet aan de inputvoorwaarden wordt

voldaan.• CCTA Risk Analysis and Management Method (CRAMM) - beschrijft een aantal manieren

voor het opstellen van tegenmaatregelen ter bescherming van vertrouwelijkheid, integriteit en beschikbaarheid van de IT-infrastructuur.

• Beschikbaarheidsberekeningen - de hiervoor genoemde gegevens kunnen worden gebruikt om met de klant afspraken te maken over de beschikbaarheid van een service. Deze afspra-ken zijn opgenomen in het SLA. Om het beschikbaarheidspercentage te berekenen moet de gerealiseerde beschikbare tijd worden gedeeld door de overeengekomen beschikbare tijd. De uitkomst moet worden vermenigvuldigd met 100.

• Service Outage Analysis (SOA) - is een techniek die kan worden gebruikt om de oorzaken van storingen te achterhalen, de effectiviteit van de IT-organisatie en -processen te onderzoe-ken, en verbetervoorstellen te presenteren en te implementeren. Kenmerken van SOA zijn:– een brede onderzoeksscope: er wordt niet alleen gekeken naar de infrastructuur, maar ook

naar processen, procedures en culturele aspecten)– issues worden bekeken vanuit het perspectief van de klant– gezamenlijke aanpak (SOA-team) door vertegenwoordigers van de klant en de IT- organisatie.De voordelen zijn onder meer een effi ciëntere aanpak, directe communicatie tussen klant en leverancier en een breder draagvlak voor verbetervoorstellen.

• Technical Observation Post (TOP) - een speciaal geformeerd team van IT-specialisten richt zich op een detailaspect van beschikbaarheid. Dit kan worden gedaan in situaties waar tools onvoldoende ondersteuning bieden. De TOP-methode kan ook de deskundigheid van ont-werpers en beheerders bij elkaar brengen. Het belangrijkste kenmerk van deze methode is een effi ciënte, effectieve en ongedwongen aanpak die snel tot resultaten leidt.

De CSF’s van beschikbaarheidsmanagement zijn:• De business moet helder gedefi nieerde beschikbaarheidsdoelen en -eisen hebben.• Servicelevelmanagement moet zijn ingericht om overeenkomsten te formaliseren.• Beide partijen moeten dezelfde defi nities gebruiken van beschikbaarheid en storingstijd.• Zowel de business als de IT-organisatie moeten zicht bewust zijn van de voordelen van be-

schikbaarheidsmanagement.



De volgende KPI’s laten zien hoe effectief en effi ciënt capaciteitsmanagement is:• percentage beschikbaarheid (uptime) per service of groep gebruikers• duur storingstijd (downtime)• frequentie storingstijd

De beschikbaarheidsrapporten voor de klant zijn eerder besproken. Voor de control (beheersing) van het proces kunnen de volgende metrics worden gerapporteerd:• detectietijden• reactietijden

Configuratie-item

PC #1PC #2Kabel #1Kabel #2Outlet #1Outlet #2EthernetsegmentRouterWAN-verbindingRouterSegmentNICServerSysteemsoftwareApplicatieDatabase

Service A

B

B

X

XXXXXABBBX

Service B

BBBBXXXXXXXABBBX

X = storing, dienst niet beschikbaarA = faalveilige configuratieB = faalveilig, met overschakelingstijd" " = geen impact

Servicestoring

OF

BlokkeringBuiten

service-uren?

Systeemstoring

Netwerkstoring

EN

Computerstoring Applicatiestoring

Storing

normale lijn

Storing

backuplijn

Figuur 4.4.7 CFIA-matrix

Figuur 4.4.8 Fault Tree Analysis (Bron: OGC)



• reparatietijden• hersteltijden• succesvolle toepassing van toepasselijke (CFIA, CRAMM, SOA)• stand van zaken procesimplementatie: dekking van SLA’s in services en klantgroepen

Van sommige metrics kunnen de resultaten steeds per service, per team of per infrastructuurdo-mein (netwerk, rekencentrum, werkplekomgeving) worden vastgesteld.

4.4.2 Serviceleveringsproces: capaciteitsmanagement (6.5)

Doelstelling: Borgen dat de serviceprovider altijd voldoende capaciteit heeft om te voldoen aan de huidige en toekomstige overeengekomen vraag vanuit de bedrijfsbehoeften van de klant.


Capaciteitsmanagement moet een capaciteitsplan produceren en onderhouden.

Capaciteitsmanagement moet zich richten op de bedrijfsbehoeften en het volgende omvatten:a) huidige en voorspelde capaciteits- en performance-eisenb) vastgestelde tijdschalen, drempels en kosten van service-upgradesc) evaluatie van effecten van de verwachte service-upgrades, requests for change, nieuwe

technologieën en technieken voor capaciteitd) voorspelde impact van externe changes , bijvoorbeeld vanuit de wetgevinge) data en processen die een voorspellende analyse mogelijk maken

Er moeten methoden, procedures en technieken worden bepaald om de servicecapaciteit te monitoren, de serviceperformance af te stemmen en voldoende capaciteit te bieden.


De actuele en verwachte bedrijfseisen aan services behoren te worden gezien als benodigdheden voor een bedrijf om aan zijn klanten te kunnen leveren.Bedrijfsvoorspellingen en schattingen van werklast behoren te worden vertaald naar specifi eke eisen en behoren te worden gedocumenteerd.Het gevolg van variaties in werklast of omgeving hoort voorspelbaar te zijn; om het proces te ondersteu-nen horen data over componenten resourcegebruik, actueel en historisch, op zinvol niveau te worden opgehaald en geanalyseerd. Capaciteitsmanagement hoort het contactpunt te zijn bij alle performance- en capaciteitskwesties. Het proces hoort de ontwikkeling van nieuwe en gewijzigde services direct te ondersteunen door middel van ‘sizing’ en modellering.Met gepaste regelmaat hoort een capaciteitsplan te worden geproduceerd waarin de actuele perfor-mance van de infrastructuur en de verwachte eisen zijn gedocumenteerd. Hierbij hoort rekening te worden gehouden met het changepercentage van services en serviceomvang, met informatie uit change-managementrapporten en de bedrijfsvoering van de klant.



Dit hoort ten minste jaarlijks te worden geproduceerd. Het hoort kostenscenario’s vast te leggen voor het voldoen aan bedrijfseisen en oplossingen aan te bevelen om de overeengekomen serviceleveldoelen van de SLA te realiseren.Er hoort een goed inzicht te zijn in de technische infrastructuur en zijn actuele en verwachte vermogen.

De kernactiviteiten in het capaciteitsmanagementproces zijn de monitoring, afstemming (tu-ning) en levering van capaciteit. Deel 1 van ISO 20000 eist expliciet gebruik van specifi eke methoden, procedures en technieken om deze activiteiten uit te voeren, na het opstellen van een capaciteitsplan (zie fi guur 4.4.9). De code of practice raadt enkele aanvullende processen en documenten aan.

RichtlijnenDe kosten van IT worden niet zo zeer gemaakt bij het investeren in capaciteit, maar bij het ma-nagen ervan. Bijvoorbeeld, een grote toename van opslagcapaciteit heeft impact op het maken van back-ups en het duurt langer om bestanden op het netwerk te vinden. Door middel van goed capaciteitsmanagement kan de IT-serviceprovider bijvoorbeeld zien dat de achttien strategische initiatieven die dit jaar voor IT zijn gesteld, de huidige back-up-oplossing overbodig maken. Met deze kennis kan de capaciteitsmanager borgen dat de werkelijke kosten van de initiatieven duidelijk zijn, door ervoor te zorgen dat de kosten van de nieuwe back-upoplossing verdeeld zijn over deze achttien initiatieven. Dit is proactief. Als er geen actief capaciteitsmanagement is, kan de IT-organisatie alleen reageren als de back-updrempel worden overschreden. In dit geval, zal de klant de IT-organisatie zien als niet meer dan een kostenpost, omdat IT niet proactief is geweest in het vantevoren opstellen van verwachtingen en toewijzen van kosten.

Capaciteitsmanagement bestaat uit drie deelprocessen, of niveaus waarop capaciteit van toepas-sing is:• Bedrijfscapaciteitmanagement heeft als doel inzicht te verkrijgen in de huidige en toekom-

stige bedrijfsbehoeften. Dit kan worden gerealiseerd door informatie van de klant te verkrij-gen, bijvoorbeeld strategische- of marketingplannen, en door trendanalyses. Dit deelproces is grotendeels proactief.

• Servicecapaciteitsmanagement heeft als doel de IT-services te bepalen en inzicht te verkijgen in IT-services. Er moet inzicht zijn in de performance en de piekbelasting om te borgen dat de juiste service-overeenkomsten kunnen worden gemaakt en geleverd. Dit deelproces heeft sterke banden met servicelevelmanagement als het gaat om het defi nieren en onderhandelen over de serviceovereenkomsten.

• Resourcecapaciteitsmanagement heeft als doel de IT-infrastructuur en -componenten te bepalen en inzicht te verkrijgen in het gebruik ervan. Voorbeelden van resources zijn band-breedte van het netwerk, verwerkingscapaciteit en diskcapaciteit. Om deze resources effectief te kunnen managen, moeten potentiële problemen in een vroeg stadium worden gesignaleerd. Ook moet de organisatie op de hoogte blijven van technologische ontwikkelingen. Een andere activiteit is actieve trendmonitoring.

Figuur 4.4.10 geeft enkele kernactiviteiten binnen dit gebied weer.

Het capaciteitsplan geeft een beeld van de bestaande capaciteit binnen de IT-infrastructuur en de verwachte ontwikkelingen in de vraag naar IT-services, van de vervanging van verouderde



Produceer enonderhoud eencapaciteitsplan

Toeleggen op bedrijfsbehoeften,met inbegrip van: – actuele en voorspelde capaciteit

en performance-eisen– vastgestelde tijdsschema's, drempels en kosten voor opwaardering services– evaluatie van effecten van geanticipeerde opwaarderingen van services, requests for

change, nieuwe technologieën entechnieken voor capaciteit

– voorspelde impact van externe wijzigingen– data en processen om voorspellende analyses mogelijk te maken

Analiseergebruiksdata

Data over actueelen voorgaand

gebruik

Met documentatie van: – feitelijke performance van de infrastructuur en verwachte eisen– begrotingsscenario's om aan bedrijfseisen te voldoen

Met aanbeveling van oplossingen omrealisatie van SLA-doelen te borgen

Rekening houdend met:– het aantal changes in services en serviceomvang– de informatie in de

changemanagementrapporten– klantbedrijf

Stem de maataf en modelleer

services

Bepaal methoden,procedures en

technieken

Om servicecapaciteit te monitoren,serviceperformance in te stellen,geschikte capaciteit te bieden

Vertaalvoorspellingenen schattingen

naar eisen

Verwerfgebruiksdata

Capaciteitsplan

Capaciteitseisen

Data over actueelen voorgaand

gebruik

Interfaces:



Budgettering en verantwoording- budgettering en verantwoording vanalle componenten

Figuur 4.4.9 Capaciteitsmanagement



componenten en de technische ontwikkelingen. Het capaciteitsplan bevat ook een planning van de aanpassingen die nodig zijn om tegen acceptabele kosten te blijven voldoen aan de in de SLA overeengekomen servicelevels. Het capaciteitsplan hoort de volgende informatie te bevatten:• verwachte performance• punten voor upgrading• verwachte kosten voor upgrades van infrastructuur (kapitaal, herhaling, operationeel, perso-

neel)

Deze gegevens moeten in dynamische omgevingen regelmatig worden geactualiseerd.

Het capaciteitsplan kan worden beschouwd als de belangrijkste output van capaciteitsmanage-ment. De output bevat vaak een jaarplan, dat gelijk op loopt met het budget of de fi nanciële planning, de langetermijnplanning en kwartaalplannen die een overzicht geven van de geplande wijzigingen in de capaciteit. Dit levert een samenhangend geheel van plannen op, die gedetail-leerder worden naarmate de deadline van de planning nadert.

Modelling is een krachtige tool voor capaciteitsmanagement en wordt gebruikt om het gedrag van de infrastructuur te voorspellen. De tools die capaciteitsmanagement ter beschikking heeft variëren van tools voor het maken van schattingen en metingen tot tools voor het uitgebreid testen van prototypes. Het eerste type tools is goedkoop en voldoet voor de dagelijkse gang van zaken. Het tweede type is meestal alleen geschikt voor grootschalige implementatieprojecten. Tussen deze twee uitersten zijn meerdere technieken beschikbaar die nauwkeuriger zijn dan schattingen en goedkoper dan een uitgebreide pilot. Beginnend met de goedkoopste zijn dit:• vuistregels• trendanalyse• analytisch modelling• simulatie

CD

B

Monitoring

Analyse

Afstemming

Implementatie(via

changemanagement)

Drempels voorresourcegebruik

Rapporten overuitzonderingen

in SLM

Rapporten overuitzonderingen inresourcegebruik

Drempelsvoor SLM

Figuur 4.4.10 Iteratieve activiteiten van capaciteitsmanagement (Bron: OGC)



• baseline-assessment (benchmark, het nauwkeurigst)• feitelijke systeem

Application sizing bekijkt welke resources nodig zijn voor nieuwe of gewijzigde services, zoals applicaties die in ontwikkeling of in onderhoud zijn, of op verzoek van de klant kunnen worden aangeschaft. Deze voorspellingen omvatten informatie over de verwachte performanceniveaus, de benodigde resources en de kosten.

Aplication sizing is vooral relevant bij de eerste fasen van productontwikkeling en bij belangrijke momenten van ontwikkelprojecten. Duidelijke informatie over de benodigde hardware, andere IT-resources en de verwachte kosten is in dat stadium zeer nuttig voor het management. Ook in het voortraject van nieuwe service level requirements of SLA’s kan application sizing belangrijk zijn. In grote of complexe omgevingen kan application sizing een omvangrijke taak zijn. Capaciteits-management maakt afspraken met de ontwikkelaars over de service level requirements waaraan het product moet voldoen. Als de service het overdracht- en acceptatiestadium heeft bereikt moet worden getest of de afgesproken servicelevels ook kunnen worden gerealiseerd.

Een deel van de output van capaciteitsmanagement bestaat uit het effect van workloadvariatie. Deze kan worden gebruikt om te voorspellen wat de vereiste capaciteit zal zijn als bijvoorbeeld het aantal gebruikers met 25% groeit. Andere werklastkenmerken zijn de capaciteitseisen in de tijd (piekbelastingen per dag/week/jaar en toekomstige groei).

Monitoring volgt en bewaakt de diverse infrastructuurcomponenten om er voor te zorgen dat de afgesproken service levels worden gerealiseerd. Voorbeelden van resources die kunnen worden gemonitord zijn: CPU-capaciteit, diskopslag, netwerkbandbreedte en aantal licenties.

De meetgegevens moeten worden geanalyseerd. Door middel van trendanalyse kunnen voorspel-lingen worden gedaan over de toekomstige groei en potentiële knelpunten. Dit kan leiden tot het nemen van effi ciëntieverbeterende maatregelen of bestelling van aanvullende IT-componenten. Analyse van activiteiten vereist een diepgaand inzicht in de totale infrastructuur, de bedrijfsproces-sen en de relatie tussen de onderdelen van business-, service- en resource-capaciteitsmanagement.

Tuning optimaliseert systemen voor de werkelijke of de verwachte werklast, op basis van de ge-analyseerde en geïnterpreteerde monitoring-gegevens.

Het doel van implementatie is het beschikbaar maken van de aangepaste of nieuwe capaciteit. Als het een wijziging betreft, wordt dit uitgevoerd door het changemanagementproces.

Demandmanagement heeft als doel de capaciteitsvraag te beïnvloeden. Als een gebruiker bijvoor-beeld midden op de dag een slechtgeschreven SQL-rapport genereert, levert dit een onverwacht grote hoeveelheid netwerkverkeer op. De capaciteitsmanager kan dan besluiten om het rapport ’s nachts te laten draaien zodat de gebruiker deze de volgende ochtend op zijn bureau heeft liggen. Demandmanagement levert belangrijke input voor het opstellen, monitoren en eventueel bijstel-len van zowel het capaciteitsplan als de SLA’s.



Demand (vraag) kan ook worden gemanaged met behulp van differentiële doorbelasting. Deze methode beïnvloedt het gedrag van klant en gebruiker tijdens perioden waarin de vraag groot is.

De bouw en invulling van de capaciteitsdatabase, de CDB, bestaat uit het verzamelen en onder-houden van technische gegevens, zakelijke gegevens en alle overige gegevens die belangrijk zijn voor capaciteitsmanagement. Het is in de praktijk niet altijd haalbaar om de capaciteitsinforma-tie in een enkele fysieke database op te slaan. Beheerders van netwerken en computersystemen hebben vaak hun eigen aanpak en technieken. De term CDB staat voor een verzameling van gegevensbronnen die gegevens over capaciteit bevatten (zie fi guur 4.4.11).

De kwaliteit van het capaciteitsmanagementproces hangt af van de volgende kritieke succes-factoren:• nauwkeurige businessvoorspellingen en -verwachtingen• inzicht in de IT-strategie en de nauwkeurige planning hiervan• kennis van huidige en toekomstige technologieën • samenwerking met andere processen• vermogen om effectief met de kosten om te gaan

Het succes van capaciteitsmanagement wordt bepaald door de volgende prestatie-indicatoren:• Voorspelbaarheid van de vraag van de klant – vaststellen van werklastontwikkelingen en

trends en de nauwkeurigheid van het capaciteitsplan.• Techniek – de mogelijkheden om de prestaties van IT-services te meten, de snelheid waarmee

nieuwe technologie kan worden geïmplementeerd en het blijvend kunnen voldoen aan de afspraken van de SLA, ook als er oudere technologie wordt gebruikt.

• Kosten – verminderen van het aantal impulsaankopen, verminderen van onnodige en dure overcapaciteit en tijdig opstellen van investeringsplannen.

Bedrijfsvoorspellingen Servicedata Technische data Financiële data Gebruiksdata

CDB

Managementrapporten Capaciteitsplannen Technische rapporten

Figuur 4.4.11 CDB-informatiebronnen



• Operationeel – verminderen van het aantal incidenten die het gevolg zijn van performance- of capaciteitsproblemen, continu kunnen voldoen aan de vraag van de klant en de mate waar-in het proces serieus wordt genomen.

De managementrapporten van het capaciteitsmanagementproces bevatten controlgegevens van het proces in de zin van:• kenmerken van het capaciteitsplan• resources die voor de implementatie van het proces zijn gebruikt• de voortgang van verbeterinitiatieven

Het kunnen echter ook uitzonderingsrapporten zijn over kwesties als:• afwijkingen tussen de feitelijke en de geplande capaciteit• trends in de afwijkingen• invloed op de servicelevels• verwachte groei of afname van capaciteit en gebruik op de lange en korte termijn• drempelwaarden die bij dreigende overschrijding mogelijk aanvullende capaciteit vereisen

Deze capaciteitsplannen en performancemanagementrapporten moeten beschikbaar zijn voor alle geïnteresseerde partijen: van de business, applicaties en IT.

4.4.3 Serviceleveringsproces: informatiesecuritymanagement (6.6)

Doelstelling: Het effectief managen van informatiesecurity in alle service-activiteiten. De specifi catie in ISO 20000-1 stelt:

NOOT: ISO 17799 , Informatietechnologie - securitytechnieken - code of practice voor informatiesecuritymanagement biedt handvatten voor informatiesecuritymanagement.

Management met geschikte bevoegdheden moet een informatiesecuritybeleid goedkeuren. Dit beleid moet worden bekendgemaakt aan alle relevante personeelsleden en indien van toepassing ook aan klanten.

Er moeten passende securitycontrols in werking zijn om:• de eisen van het informatiesecuritybeleid te implementeren• risico’s te managen die samenhangen met toegang tot de service of de systemen

Securitycontrols moeten worden gedocumenteerd. De documentatie moet de risico’s beschrijven waarop de controls betrekking hebben en de wijze waarop de controls moeten worden uitgevoerd en onderhouden. De impact van changes op controls moet worden beoordeeld voordat changes worden geïmplementeerd.Regelingen waarbij externe organisaties toegang hebben tot informatiesystemen en services moeten worden gebaseerd op een formele overeenkomst, waarin alle benodigde security-eisen zijn gedefi nieerd.Security-incidenten moeten zo snel mogelijk worden gerapporteerd en vastgelegd, in lijn met de incidentmanagementprocedure. Er moeten procedures zijn die erop toezien dat alle security-incidenten worden onderzocht en dat managementacties worden ondernomen.



Er moeten mechanismen zijn die ervoor zorgen dat type, omvang en impact van security-incidenten en -storingen kunnen worden gekwantifi ceerd en gemonitord. Verbeteracties die tijdens dit proces worden bepaald moeten worden vastgelegd, en vormen de input voor een serviceverbeterplan.


AlgemeenInformatiesecurity is het resultaat van een systeem van richtlijnen en procedures dat gericht is op het vaststellen, beheersen en beschermen van informatie en op de uitrusting die wordt gebruikt in verband met de opslag, transmissie en verwerking van die informatie.De medewerkers van de serviceprovider met specialistische informatiesecurityrollen horen vertrouwd te zijn met ISO/IEC 17799, Informatietechnologie - securitytechnieken - code of practice voor infor-matiesecuritymanagement.

Bepalen en classifi ceren van informatie-assetsDe serviceprovider hoort:a) een inventarisatie bij te houden van informatie-assets die nodig zijn om services uit te voeren (bij-

voorbeeld computers, communicatietechniek, documenten en andere informatie) b) elke asset te classifi ceren naar de kriticiteit voor de services en het benodigde beschermingsniveau, en

een eigenaar te benoemen die verantwoordelijk is voor het bieden van die beschermingc) ervoor te zorgen dat de verantwoordelijkheid voor assetbescherming bij de eigenaar van de asset ligt,

hoewel deze de dagelijkse securitymanagementverantwoordelijkheden kan delegeren

Werkwijzen voor securityrisicoanalyseSecurityrisicoanalyse hoort:a) met overeengekomen regelmaat te worden uitgevoerdb) te worden geregistreerdc) te worden onderhouden bij wijzigingen (van veranderende bedrijfsbehoeften, processen en confi gu-

raties)d) inzicht te stimuleren in wat een managed service kan beïnvloedene) informatie te leveren voor beslissingen over de soorten control die moeten worden uitgevoerd

Risico’s voor informatie-assetsRisico’s voor informatie-assets horen te worden beoordeeld naar:a) hun aard (bijvoorbeeld softwarestoring, productiefouten, verbindingsgebreken)b) waarschijnlijkheidc) potentiële impact op de bedrijfsvoeringd) ervaring uit het verleden

Security en beschikbaarheid van informatieBij de beoordeling van risico’s hoort aandacht te worden besteed aan:a) ontsluiting van gevoelige informatie voor ongeautoriseerde partijenb) onnauwkeurige, onvolledige of ongeldige (bijvoorbeeld onwettige) informatiec) informatie die niet beschikbaar is voor gebruik (bijvoorbeeld door stroomuitval)d) fysieke schade aan of vernieling van uitrusting die nodig is om services te bieden



Er hoort ook rekening te worden gehouden met doelstellingen na informatiesecurity, met de noodzaak om aan door de klant gespecifi ceerde security-eisen te voldoen (bijvoorbeeld beschikbaarheidsniveaus), en met statutaire en regelgevende eisen die van toepassing zijn.

ControlsIn aanvulling op andere controls die nodig kunnen zijn en advies dat elders in ISO 20000-2 wordt gegeven (bijvoorbeeld over servicecontinuïteit), is het voor serviceproviders een goede informatie-securitymanagement-werkwijze om de volgende controls uit te voeren:a) Het hoger management hoort het informatiesecuritybeleid te defi niëren, te communiceren aan per-

soneel en klanten en actie te nemen om effectieve implementatie te borgen. b) Er horen rollen en verantwoordelijkheden voor informatiesecuritymanagement te worden gedefi ni-

eerd en aan personeelsleden worden toegewezen.c) Een representatieve managementgroep (deze rol kan worden bekleed door de senior verantwoorde-

lijke eigenaar) hoort de effectiviteit van het informatiesecuritybeleid te monitoren en onderhouden.d) Personeelsleden met belangrijke securityrollen horen een informatiesecuritytraining te krijgen.e) Alle personeelsleden horen zich bewust te zijn van het informatiesecuritybeleid.f ) Er hoort deskundige hulp beschikbaar te zijn voor risicosanalyse en controlimplementatie.g) Wijzigingen horen de effectieve uitvoering van controls niet in gevaar te brengen.h) Informatiesecurity-incidenten horen volgens incidentmanagementprocedures te worden gerappor-

teerd en er hoort een response te worden opgestart.

Documenten en recordsRecords horen periodiek te worden geanalyseerd om het management van informatie te voorzien over:a) de effectiviteit van het informatiesecuritybeleidb) nieuwe trends in informatiesecurity-incidentenc) input voor een serviceverbeterpland) toegangscontrole op informatie, assets en systemen

Het informatiesecuritymanagementsysteem hoort zorgvuldig te worden gedocumenteerd.

ISO/IEC 17799, de code of practice voor informatiesecuritymanagement, biedt richtlijnen voor het proces voor het leveren van kwaliteits IT-services in subonderdeel 6.6 van de standaard. Deel 2 van ISO 20000 geeft daarom aan dat het personeel van de serviceprovider specialistische infor-matiesecurityrollen moeten hebben die overeenkomen met ISO/IEC 17799.

Een informatiesecuritybeleid is een expliciete eis in ISO 20000, evenals gedocumenteerde se-curitycontrols, security-incidentrecords en records van de vastgestelde verbeteracties. Expliciet vereiste procedures in informatiesecuritymanagement zijn procedures voor het onderzoeken van security-incidenten en het nemen van managementacties, zie fi guur 4.4.12 en 4.4.13.

Informatiesecuritymanagement heeft interfaces met het changemanagementproces, het incident-managementproces, het confi guratiemanagementproces en het continue verbeterproces.



Met inbegrip van: – implementatie van de eisen van het

informatiesecuritybeleid– managen van risico's die samenhangen met toegang

tot de service of systemen

Met beschrijving van:– de risico's waar de controls aan zijn gerelateerd– de wijze van uitvoering en het onderhoud van de controls

Informatiesecuritybeleid

Security-eisenvan de SLA

Maak afspraken overtoegang voor externe

organisaties

Definieerinformatiesecuritybeleid

Documenteer de ISMS

Definieer rollen enverantwoordelijkheden

en wijs deze toe

Benoem de eigenaar,verantwoordelijk voor

bescherming assets

Accordeerinformatiesecuritybeleid

Breng het over naar allerelevante medewerkers

en klanten

Documenteersecuritycontrols

Securitycontrols

Regelingen voorexterne toegang

ISMS


Toegewezen rollen enverantwoordelijkheden


Interfaces:

Continue verbetering (Act)- doe verbetervoorstellen voor SIP- lever managementinformatie over trends in informatiesecurity-incidenten Configuratiemanagement:- bepaal en classificeer informatie-assets- houd een inventarisatie van informatie-assets bij

Changemanagement:- beoordeel de impact van changes van securitycontrols voordat de changes worden geïmplementeerd- houd tijdens de changes assessments van securityrisico's - voorkom dat changes de effectieve uitvoering van controls tegenwerken- dien requests for changes in


Budgettering en verantwoording:- budgetteer en verantwoord alle componenten

Incidentmanagementproces:- rapporteer en registreer security-incidenten in lijn met de incidentmanagementprocedure- alle security-incidenten zijn onderzocht en er is managementactie genomen- kwantificeer en monitor type, omvang en impact van security-incidenten

Problem management:- wissel managementinformatie uit over trends in informatiesecurity-incidenten- security-incidenten horen te worden onderzocht door problem management

Figuur 4.4.12 Informatiesecuritymanagement



Records vansecurityrisico-assessments

Onderhoud risicoassessment(tijdens changes)

Met inbegrip van impact op manage

Assetrisico's horen te worden beoorvanuit de invalshoeken:– aard– waarschijnlijkheid– potentiële bedrijfsimpact– ervaring uit het verleden

Besteed aandacht aan:– ontsluiting van informatie aan ongeautoriseerde partijen– onnauwkeurige, onvolledige of ongeldige informatie– niet beschikbare informatie– fysieke schade aan noodzakelijke Houd rekening met:– beleidsdoelstellingen– voldoen aan klanteisen– toepassen van statutaire of reglementaire eisen

Er hoort deskundige hulp beschikbaAnaliseer records om

management vaninformatie te voorzien

Met oog op:– effectiviteit van informatiesecurity– opkomende trends in informatiesecurity-incidenten– input voor een serviceverbeterplan– beheersing van toegang naar infor assets en systemen

Monitor en onderhoud

effectiviteit van hetinformatie-

securitybeleid

Met afgesprokenregelmaat

Maak personeel bewust van informatie-

securitybeleiden implementeer

het effectief

Verwerf kennisover ISO/IEC 17799

Securitypersoneel hoort bekend tezijn met ISO/IEC 17799

Bied trainingaan personeel met

belangrijkesecurityrollen

Houd een inventarisbij van

informatie-assets

Classificeerkriticiteit en

beschermingsniveauvan assets

Voersecurityrisico-assessments

uit

Informatie-securitybeleid

Figuur 4.4.13 Informatiesecuritymanagement - vervolgd



RichtlijnenOrganisaties en hun informatiesystemen veranderen. Daarom moeten securitymanagementacti-viteiten continu worden gereviewd, zodat hun effectiviteit geborgd blijft. Securitymanagement is een oneindige cyclus van plan, do, check en act, zoals te zien is in fi guur 4.4.14.

De klanteisen staan rechtsboven in de fi guur (4.4.14) en vormen de input van het proces. Het security-onderdeel van de SLA defi nieert deze eisen in termen van de securityservices en het securityniveau dat moet worden geleverd. De serviceprovider maakt deze afspraken bekend aan de organisatie in de vorm van een securityplan, waarin de securitynormen of de operational level agreements zijn beschreven. Dit plan wordt geïmplementeerd, en de implementatie wordt geëva-lueerd. Vervolgens worden het plan en de implementatie geactualiseerd. Servicelevelmanagement rapporteert over deze activiteiten aan de klant. Zo vormen de klant en de serviceprovider samen een compleet cyclisch proces. De klant kan zijn eisen aanpassen naar aanleiding van de rappor-ten. De serviceprovider kan op basis van deze observaties ook het plan of de implementatie ervan aanpassen, of proberen de overeenkomsten van de SLA aan te passen.

IT-serviceprovider

PLAN:

Service level agreementsUnderpinning contractsOperational level agreementsInterne richtlijnen

IMPLEMENTEER:

Verbeter bewustzijn

Classificering en management van resourcesPersoneelsecurityFysieke securitySecuritymanagement van hardware,netwerken, applicaties, etc.

ToegangscontrolLos securityincidenten op

CONTROL:

Organiseer!

Creëer managementframeworkWijs verantwoordelijkheden toe

EVALUEER:

Interne auditsExterne auditsSelf-assessmentsSecurity-assessments

ONDERHOUD:

LeerVerbeterPlanImplementeer

Klant definieert bedrijfseisen

Rapportage

Volgens de SLA

Service level agreement / Security hoofdstuk

Overeenkomst tussen klant en provider

Figuur 4.4.14 Het securitymanagementproces (Bron: OGC)



De activiteit control in het midden van fi guur 4.4.14, is het eerste deelproces van securitymanage-ment en is gericht op organisatie en management van het proces. Dit omvat ook het framework voor informatiesecuritymanagement. Dit framework beschrijft de volgende deelprocessen:• defi niëren van de securityplannen• implementeren van de securityplannen• evaluatie van de geïmplementeerde securityplannen• opname van de evaluatie in de jaarlijkse securityplannen (actieplannen)

Het framework behandelt ook de rapporten die via servicelevelmanagement aan de klant worden geleverd. ‘Control’ defi nieert de deelprocessen, securityfuncties en de rollen en verantwoordelijkheden. Ook beschrijft het de organisatiestructuur, de rapportagelijnen en de beheersingslijnen (wie geeft opdrachten aan wie, wie doet wat en hoe wordt gerapporteerd over de uitvoering). De volgende maatregelen uit de ISO/IEC 17799 code of practice worden door deze activiteit geïmplemen-teerd:• beleid

– beleidsontwikkeling en -implementatie, relaties met ander vormen van beleid– doelstellingen, algemene principes en belang– beschrijving van de deelprocessen– toekenning van functies en verantwoordelijkheden voor deelprocessen– links met andere ISO 20000-processen en management daarvan– algemene verantwoordelijkheden van personeel– afhandeling van securityincidenten

• organisatie van informatiesecurity– managementframework– managementstructuur (organisatiestructuur)– gedetailleerde toekenning van verantwoordelijkheden– opzetten stuurgroep voor informatiesecurity– coördinatie van informatiesecurity– afspraken maken over tools (bijvoorbeeld voor risicoanalyse en het verbetering van bewust-

wording)– beschrijving van het autorisatieproces voor IT-voorzieningen, in afstemming met de klant– specialistisch advies– samenwerking tussen organisaties, interne en externe communicatie– onafhankelijke audit van informatiesystemen– securityprincipes voor de toegang van derden– informatiesecurity in contracten met derden

Het deelproces plan omvat de defi nitie van het security-onderdeel van de SLA in overleg met servicelevelmanagement, en de aan security gerelateerde activiteiten in de underpinning con-tracts. De doelstellingen in de SLA worden verfi jnd en nader gespecifi ceerd in de vorm van een operational level agreement (OLA). Een OLA kan worden beschouwd als een securityplan voor een organisatie-eenheid van de serviceprovider, bijvoorbeeld per IT-platform, per applicatie en per netwerk. Het deelproces ‘plan’ krijgt ook input vanuit de beleidsprincipes van de servicepro-vider (uit het deelproces ‘control’). Voorbeelden van beleidsprincipes zijn: ‘iedere gebruiker moet uniek identifi ceerbaar zijn’, of ‘aan alle klanten wordt te allen tijde een basisniveau van security geboden’.



De operational level agreements voor informatiesecurity (specifi eke securityplannen) worden opgesteld en geimplementeerd met behulp van de normale procedures. Dat betekent dat als er activiteiten nodig zijn voor andere processen, er samenwerking moet zijn met deze processen. Changemanagement verzorgt de vereiste wijzigingen van de IT-infrastructuur, op basis van input die securitymanagement heeft aangeleverd. Het deelproces ‘plan’ wordt afgestemd met service-levelmanagement voor het opstellen van, het onderhouden van, en het voldoen aan het security-onderdeel van de SLA. De SLA hoort de security-eisen te defi niëren, waar mogelijk in meetbare termen. Het security-onderdeel van de overeenkomst hoort te borgen dat alle securitybehoeften van de klant op een controleerbare manier worden gerealiseerd.

Het deelproces implementatie zorgt er voor dat alle maatregelen worden geïmplementeerd zoals in de plannen is gespecifi ceerd. Hieronder is een checklist opgenomen:• Classifi catie en beheersing van IT-resources

– levering van input voor het onderhoud van CI’s in de CMDB– classifi catie van resources volgens afgesproken richtlijnen

• Security van personeel– taken en verantwoordelijkheden in functiebeschrijvingen– screening– geheimhoudingsverklaringen van personeel– training– richtlijnen voor het personeel voor de afhandeling van security-incidenten en geconsta-

teerde security-zwakheden – disciplinaire maatregelen– stimuleren van securitybewustzijn

• Het managen van security– implementatie van verantwoordelijkheden en functiescheiding– schriftelijke bedieningsinstructies– huisregels– security hoort de gehele levenscyclus te volgen: er horen securityrichtlijnen te zijn voor de

ontwikkeling, het testen, de acceptatie, de productie, het onderhoud en de uitfasering van het systeem

– scheiding van de ontwikkelen testomgevingen van de productieomgeving– procedures voor incidentafhandeling (uit te voeren door incidentmanagement)– implementatie van herstelvoorzieningen– input leveren voor changemanagement– implementatie van maatregelen ter bescherming van virussen– implementatie van maatregelen voor management van computers, applicaties, netwerken

en netwerkservices– behandeling en security van informatiedragers

• Toegangssecurity– implementatie van het beleid voor toegang en toegangsbeheersing– onderhoud van toegangsrechten van gebruikers en applicaties tot netwerken, netwerkservi-

ces en computers– onderhoud van securitybarrières in netwerken (fi rewalls, inbelfaciliteiten, bridges en rou-

ters)– implementatie van maatregelen voor de identifi catie en authenticiteit van computersyste-

men, werkstations en pc’s in het netwerk



Een onafhankelijke evaluatie is nodig om de performance van de geïmplementeerde maatregelen te kunnen beoordelen en wordt ook geëist door klanten en derde partijen. De resultaten kunnen, in overleg met de klant, worden gebruikt voor het actualiseren van de afgesproken maatregelen en ook ook voor de implementatie ervan. Evaluatieresultaten kunnen aanleiding geven tot chan-ges, waarna er een RfC wordt gedefi nieerd en ingediend bij changemanagement.

Er zijn drie vormen van evaluatie:• Self-assessments – worden vooral uitgevoerd door de lijnorganisatie van de processen. • Interne audits - worden uitgevoerd door interne auditors .• Externe audits – worden uitgevoerd door externe auditors .

In tegenstelling tot self-assesments, worden audits niet uitgevoerd door medewerkers uit de an-dere subprocessen. Hiermee wordt geborgd dat de verantwoordelijkheden gescheiden blijven. Een interne auditafdeling kan audits uitvoeren.

Evaluaties worden ook uitgevoerd als antwoord op security-incidenten. The belangrijkste activi-teiten zijn:• verifi eren van compliance met het securitybeleid en de implementatie van de securityplannen• uitvoeren van security-audits op IT-systemen• vaststellen van en actie nemen op oneigenlijk gebruik van IT-resources• uitvoeren van de security-aspecten van andere IT-audits

Security vereist onderhoud, omdat de risico’s veranderen door veranderingen in de IT-infrastruc-tuur, de organisatie en de bedrijfsprocessen. Onderhoud van de security omvat ook onderhoud van het security-onderdeel van de SLA en onderhoud van de gedetailleerde securityplannen (OLA’s).

Onderhoud wordt uitgevoerd op basis van de resultaten van de evaluatie van deelprocessen en een beoordeling (assesment) van eventuele wijzigingen in de hieraan gerelateerde risico’s. De voorstellen voor onderhoud kunnen worden opgenomen in het deelproces ‘plan’, of in het onder-houd van de volledige SLA. In ieder geval leiden de voorstellen tot de opname van activiteiten in het jaarlijkse securityplan. Eventuele changes vallen onder het changemanagementproces.

Rapportage is geen deelproces, maar een output van andere deelprocessen. Rapporten worden opgesteld om informatie te leveren over de behaalde securityperformance en om klanten te infor-meren over securitykwesties. Deze rapporten vallen meestal onder de afspraken die met de klant zijn gemaakt.

Voorbeelden van ingeplande rapporten en rapporteerbare events zijn:• het deelproces plan:

– rapporten over de mate van compliance aan de SLA en de overeengekomen KPI’s voor security

– rapporten over underpinning contracts en eventuele problemen daarmee– rapportage over de operational level agreements (interne securityplannen) en de beleids-

principes van de serviceprovider zelf (bijvoorbeeld uitgangspunt of baseline)– rapporten over securityjaarplannen en actieplannen



• het deelproces implementatie:– statusoverzichten van de implementatie van informatiesecurity– lijst van security-incidenten en acties op die incidenten, met optioneel een vergelijking met

de voorgaande overzichtsperiode– identifi catie van trends in incidenten– status van het awareness-programma

• het deelproces evaluatie– rapporten over de performance van het deelproces– resultaten van audits, reviews en interne assessments– waarschuwingen en vaststelling van nieuwe bedreigingen

Om te rapporteren over in de SLA vastgelegde security-incidenten moet de serviceprovider een rechtstreekse communicatielijn hebben van de servicelevelmanager, incidentmanager of security-manager naar een vertegenwoordiger van de klant (mogelijk de corporate informatiesecurityma-nager). Voor de communicatie in bijzondere omstandigheden moet ook een procedure worden opgesteld.

Afgezien van speciale omstandigheden worden rapporten door servicelevelmanagement gecom-municeerd.

De kritische succesfactoren zijn:• participatie van de gebruikers bij het opzetten van het proces• gescheiden en heldere verantwoordelijkheden

De performance-indicatoren voor security zijn dezelfde als bij servicelevelmanagement. Deze zijn besproken in paragraaf 4.3.1, in zoverre deze zijn gerelateerd aan securitykwesties in de SLA.

4.5 Support van IT-services


Incidentmanagement en problemmanagement zijn verschillende processen, alhoewel ze nauw met elkaar zijn verbonden.


Prioriteiten stellenOplossingstargets horen te zijn gebaseerd op prioriteit. Prioriteit hoort te zijn gebaseerd op impact en urgentie . Impact hoort te zijn gebaseerd op de omvang van feitelijke of potentiële schade aan de busi-ness van de klant. Urgentie hoort te zijn gebaseerd op de tijd tussen de detectie van het probleem of incident en de tijd dat de business van de klant hiervan gevolgen ondervindt.

De inplanning van het oplossen van incidenten of problems hoort ten minste met het volgende rekening te houden:a) prioriteit



b) beschikbare vaardighedenc) concurrerende resourcevereistend) inspanning/kosten om een oplossingsmethode te vindene) tijd die nodig is om een oplossingsmethode te vinden

NOOT - Prioriteiten worden overal in servicemanagement gesteld, maar bij incidenten problem-management staat prioriteitstelling centraal.

WorkaroundsIndien van toepassing, hoort problemmanagement workarounds te ontwikkelen en onderhouden om incidentmanagement te faciliteren gebruikers of medewerkers te helpen bij serviceherstel.Een known error hoort alleen te worden afgesloten als een corrigerende change met succes is aangebracht of als de fout niet meer van toepassing is, bijvoorbeeld omdat de service niet meer wordt gebruikt.Problemmanagement hoort toegang te hebben tot informatie over de bedrijfsterreinen die gevolgen ondervinden van problems.De toepasbaarheid en effectiviteit van de informatie over workarounds hoort te worden bewaard en onderhouden in de kennisbank.

De prioriteiten van incidentmanagement en problemmanagement zijn afhankelijk van de impact en de urgentie van een problem of incident. De impact hangt af van de omvang van de schade. De urgentie voor het oplossen van het problem of incident is afhankelijk van het tijdsverloop tus-sen het moment van detectie en het moment waarop de business impact begint te ondervinden.

Voor zowel incidentmanagement als problemmanagement geldt dat er moet worden ingepland op basis van prioriteit en andere feitelijke businessredenen zoals die in de code of practice worden genoemd.

4.5.1 Oplossingsproces: incidentmanagement (8.2)

Doelstelling: Het zo snel mogelijk herstellen van de afgesproken service bij de business of het reageren op service requests.


Alle incidenten moeten worden vastgelegd.Er moeten procedures worden ingesteld om de impact van incidenten te managen. Procedures moeten een beschrijving geven van de registratie, prioritering, de businessimpact, classifi catie , actualisatie, escalatie, oplossing en formele afsluiting van alle incidenten.De klant moet worden geïnformeerd over de voortgang van het door hem gemelde incident of service request en moet van tevoren worden gewaarschuwd als er niet kan worden voldaan aan hun servicelevels. In het laatste geval moet tevens worden afgesproken welke actie moet worden genomen.Al het personeel dat betrokken is bij incidentmanagement moet toegang krijgen tot relevante informatie zoals known errors, problemoplossingen en de confi guratiemanagementdatabase (CMDB).Major incidenten moeten volgens een proces worden geclassifi ceerd en gemanaged.




AlgemeenNOOT 1 Het incidentmanagementproces kan worden uitgevoerd door een servicedesk, die het dage-lijkse contactpunt voor de gebruikers is.

NOOT 2 Incidentmanagement hoort:a) zowel een proactief als een reactief proces te zijn, reagerend op incidenten die de service beïnvloeden

of mogelijk kunnen beïnvloedenb) zich bezig te houden met het herstel van de service aan de klant, niet met het vaststellen van de

oorzaak van het incident

Het incidentmanagementproces hoort het volgende te omvatten:a) ontvangst, registratie, prioriteitsbepaling en classifi catie van callsb) eerstelijnsoplossing of -verwijzingc) overweging van securitykwestiesd) volgen en managen van de levenscyclus van incidentene) verifi catie en afsluiting van incidentenf ) eerstelijnsrelatie met de klantg) escalatie

Incidenten kunnen worden gerapporteerd via telefooncalls, voicemails, bezoeken, brieven, faxen of e-mails, of kunnen direct worden geregistreerd door gebruikers die toegang hebben tot het incident-registratiesysteem, of door automatisch monitorende software. Alle incidenten horen op zo’n manier te worden geregistreerd dat relevante informatie kan worden teruggehaald en geanalyseerd.De voortgang van (of gebrek aan) oplossing van incidenten hoort te worden medegedeeld aan al de-genen die feitelijk of mogelijk hinder ondervinden. Alle acties horen te worden geregistreerd in het incidentrecord.Incidentmanagementpersoneel hoort toegang te hebben tot een actuele kennisbank met informatie over technische specialisten, voorgaande incidenten, gerelateerde problems en known errors, workarounds en checklijsten die kunnen helpen om de service aan de klant te herstellen.Waar mogelijk, hoort de klant te worden voorzien van de middelen om de bedrijfsvoering voort te zetten, zelfs al is dit met een verminderde service, bijvoorbeeld door een onderdeel met gebreken uit te schakelen. Drijfveer is om de impact op de bedrijfsactiviteiten van de klant te beperken. Als de oorzaak onbekend blijft en er een workaround wordt ingesteld, horen de details te worden geregistreerd die bij de voortzetting van de problemanalyse en bij het optreden van soortgelijke incidenten kunnen worden gebruikt. Defi nitieve afsluiting van een incident hoort alleen plaats te vinden als de gebruiker die het heeft aan-gekaart de gelegenheid heeft gekregen om te bevestigen dat het incident is opgelost en de service hersteld.



Major incidentenEr hoort een heldere defi nitie te zijn van wat een major incident is en wie gemachtigd is tot het wijzi-gen van de normale werking van het incident/problemproces. Alle major incidenten horen te allen tijde een duidelijk bepaalde verantwoordelijke manager te heb-ben. De benoeming tot manager van een major incident hoort een persoon de geschikte bevoegdheden te geven voor de rol van de coördinatie en beheersing van alle aspecten van de oplossing. Hiertoe behoort ook de verantwoordelijkheid voor effectieve escalatie en communicatie op alle terreinen die betrokken zijn bij de oplossing, en naar de klanten die hinder ondervinden van het major incident.

NOOT Dit autoriteitsniveau kan tijdelijk zijn en alleen van toepassing gedurende het betreffende major incident.

Het proces voor een major incident hoort een review te omvatten die informatie verschaft voor een serviceverbeterplan.

Procedures voor het management van de impact van incidenten worden expliciet vereist in ISO 20000. De vereiste activiteiten in deze procedures zijn in detail beschreven, zoals registreren, prioriteren, impact op business, classifi ceren , updaten, escaleren, oplossen en formeel afsluiten . Incidentrecords zijn de vereiste output van de registratie van incidenten (zie fi guur 4.5.1 en 4.5.2). Incidentmanagement heeft interfaces met problemmanagement en met confi guratiemanage-ment, in beide gevallen voor het leveren van informatie over zoals known errors, problemoplos-singen, de inhoud van de CMDB, technische specialisten, workarounds en checklijsten. Beide interfaces moeten worden gedocumenteerd.

RichtlijnenFiguur 4.5.3 geeft de stappen van het proces weer:• acceptatie en registratie van het incident• classifi catie en initiële ondersteuning• matching van incident met eerdere incidenten en records van known errors• analyse en diagnose• oplossing en herstel• afsluiting• tracking en monitoring (volgen en bewaken)van de voortgang

Alle incidenten moeten meteen worden geregistreerd, in de meeste gevallen zal de servicedesk dit doen. Een incident kan op verschillende manieren worden opgemerkt:• een gebruiker die het incident aanmeldt bij de servicedesk• een systeem, als een applicatie of een technisch infrastructuurevent wordt onderbroken, bij-

voorbeeld bij overschrijding van een kritieke grenswaarde, het incident wordt dan gelogd in het incidentregistratiesysteem en indien noodzakelijk doorgespeeld naar een oplosgroep

• een medewerker van de servicedesk, die ervoor zorgt dat het incident wordt geregistreerd• een medewerker van een andere IT-afdeling die het incident zelf registreert in het incident-

registratiesysteem of het meldt bij de servicedesk



Met inbegrip van servicerequests(die worden beschouwd alseen type incident) enmajor incidenten

Prioriteit bepaalt oplossingstargets Prioriteit moet gebaseerd zijn opimpact en urgentieImpact heeft betrekkingop schade voor debusiness van de klantUrgentie heeft betrekking optijdsdruk in de businessvan de klant

Inplanning is gebaseerd opprioriteiten, beschikbare resources,tijd en kosten

Via eerstelijn of doorverwijzing

Na bevestiging van deinitiator dat het incidentnu is opgelosten de service is hersteld

In geval van major incident:neem een review op voor SIP

Met inbegrip van:- definitie van major incident- toewijzing van gezag om van het normale proces af te wijken- aanstelling van manager die verantwoordelijk is voor major incident

Zoals known errors, problem-oplossingen en CMDB

Zoals technische specialisten,voorgaande incidenten,gerelateerde problems en knownerrors, workaroundsen checklijsten

Incidentrecords

Incidentrecords

IncidentrecordsGeactualiseerdeincidentrecords

Geactualiseerdeincidentrecords

Interfaces:

Continue verbetering (Act):- doe verbetervoorstellen voor SIP- review van major incidenten

Changemanagement:- dien requests for change in

Release-, configuratie- en problemmanagement:- wissel relevante informatie uit


Informatiesecuritymanagement:- het incidentmanagementproces bestrijkt security-incidenten

Registreerincidenten

Sluit incidenten af

Los incidenten op

Classificeerincidenten

Definieerbusinessimpactvan incidenten

Prioriteerincidenten

Ontvang calls

Controleerde oplossing

Bereid deafhandelingvan major

incidenten voor

Lever toegangtot relevante

informatie

Figuur 4.5.1 Incidentmanagement



Registratie bestaat uit de volgende stappen:• Incidentnummer toekennen – in de meeste gevallen wordt door het systeem automatisch

een uniek incidentnummer toegekend. Dat nummer wordt meestal aan de gebruiker medege-deeld, zodat deze het bij latere communicatie kan vermelden.

• Basisgegevens registreren - tijdstip, symptomen, gebruiker, behandelaar, locatie en gegevens over de aangetaste service of hardware.

• Incidentgegevens aanvullen - met andere relevante gegevens over het incident (bijvoorbeeld via een script of uitvraagprocedure) of uit de CMDB (over het algemeen gebaseerd op de relatie die is vastgelegd in de database).

• Waarschuwen – als er een incident is met een hoge impact, bijvoorbeeld uitval van een belangrijke server, dan worden de overige gebruikers en de managementafdelingen gewaar-schuwd.

Voordat een incident wordt geregistreerd, moet worden gecontroleerd of er soortgelijke inciden-ten openstaan. Als dit het geval is en als blijkt dat het om hetzelfde incident gaat, actualiseer dan de informatie over dat incident, of registreer het incident apart en link het naar het hoofdinci-dent.

Hoe uitgebreider de mogelijkheden tot classifi catie, des te beter. Maar dit stelt ook hogere eisen aan de inzet van personeel. Soms wordt geprobeerd om meerdere aspecten van classifi catie in één

Actualiseerincidentrecords

IncidentrecordsGeactualiseerdeincidentrecords Met details over workarounds

Volg incidentendoor hun helelevenscyclus

Review majorincidenten

Lever input aan SIP

Escaleer incidenten

Informeer klantenover de voortgang

van gerapporteerdeincidenten

Als niet aan servicelevels kanworden voldaan en als eenactie is overeengekomen- waarschuw klant van te voren

Figuur 4.5.2 Incidentmanagement - vervolgd



lijst onder te brengen, zoals soort, oplosgroep en oorsprong. Dit kan echter leiden tot verwarring. Het is beter om verschillende korte lijsten te gebruiken.

Incidenten worden eerst onderverdeeld naar categorie en subcategorie, bijvoorbeeld op basis van de verwachte oorsprong van het incident of de relevante oplosgroep:• centrale verwerking - toegang, systeem, applicatie• netwerk - router, segment, hub, IP-adres• werkstation - beeldscherm, netwerkkaart, diskdrive, toetsenbord• gebruik en functionaliteit - dienst, capaciteit, beschikbaarheid, backup, handleiding• organisatie en procedures - bestelling, aanvraag, ondersteuning, communicatie

Opgelost?nee

ja

ja

Acceptatie & registratievan incidenten

Classificatie &initiële support

Matchen Servicerequestprocedure

Match?

Servicerequest

Analyse & diagnose

Oplossing & herstel

Afsluiting incident

nee

nee

ja

Trac

kin

g &

mo

nit

ori

ng

van

de

voo

rtg

ang

:es

cala

tie

ind

ien

no

dig

Figuur 4.5.3 Incidentmanagementproces



• service request - verzoek van de gebruiker aan de servicedesk om ondersteuning, levering, informatie, advies of documentatie. Hiervoor kan een aparte procedure worden opgesteld, of er wordt gebruik gemaakt van dezelfde afhandeling als bij ‘echte’ incidenten.

Vervolgens wordt een prioriteit toegekend, om ervoor te zorgen dat de verschillende oplosgroe-pen de vereiste hoeveelheid aandacht aan het incident besteden. De prioriteit van een incident is gebaseerd op urgentie (hoe snel moet het worden hersteld) en op impact (hoeveel schade er kan ontstaan als het niet snel wordt hersteld?).

Prioriteit = urgentie * impact

Er kan een lijst worden opgesteld om aan te geven welke services bij het incident betrokken zijn, met een verwijzing naar de relevante SLA. Deze lijst kan ook de escalatietijden voor de gerela-teerde service bevatten, zoals deze in de SLA zijn vastgelegd.

Op basis van de prioriteit en de SLA kan er aan de betreffende gebruiker(s) worden medegedeeld hoe lang de oplostijd is (tijdscyclus), en wanneer er meer nieuws is over de voortgang. Deze tijds-lijnen worden vastgelegd in het systeem.

De status van het incident geeft de positie aan in de incidentworkfl ow. Voorbeelden van deze status zijn:• nieuw• aangenomen• ingepland• toegewezen• actief• bevroren• opgelost• gesloten

Na de classifi catie wordt gecontroleerd of een soortgelijk incident eerder is voorgekomen en zo ja, of er een oplossing of een workaround is. Deze activiteit wordt matching genoemd. Als het incident dezelfde symptomen heeft als een problem of een known error, dan kan het incident daar aan worden gekoppeld.

De servicedesk stuurt de incidenten waarvoor geen directe oplossing beschikbaar is door naar een oplosgroep met meer expertise en technische competentie. Deze oplosgroep onderzoekt het incident en lost het op, of stuurt het door naar een andere oplosgroep. Dit doorsturen wordt ook wel functionele escalatie genoemd en is vaak gebaseerd op de categorie die aan het incident is toegewezen. Bij het bepalen van de categorieën wordt de structuur van de oplosgroepen vaak meegenomen. Het juiste doorsturen van incidenten is van essentieel belang voor effectief inci-dentmanagement. Een van de KPI’s voor de kwaliteit van incidentmanagement zou daarom ‘het aantal correct doorgestuurde incidenten’ kunnen zijn.

Na de succesvolle afronding van de analyse en de oplossing van het incident, registreert de op-losgroep de oplossing in het systeem. Voor sommige oplossingen moet er een RfC worden aan-



gemeld bij changemanagement. In het ergste geval wordt er geen oplossing gevonden en blijft het incident open.

Als een oplossing is geïmplementeerd, stuurt de oplosgroep het incident terug naar de service-desk. De servicedesk neemt contact op met de persoon die het incident heeft gemeld om te veri-fi ëren of het incident daadwerkelijk is opgelost. Als deze persoon akkoord gaat met de oplossing kan het incident worden afgesloten. Gaat de aanmelder niet akkoord, dan wordt het proces op de vereiste plaats hervat. Actualiseer het record om weer te geven wat de uiteindelijke categorie en prioriteit van het incident is, de aangetaste service(s)/gebruiker(s)/klanten en de CI’s die hier de oorzaak van waren.

De servicedesk is als eigenaar van alle incidenten, verantwoordelijk voor de voortgangsbewaking en voor het informeren van de gebruikers over de status van ‘hun’ incident. Het is zinvol om na een statuswijziging terug te koppelen naar de klant, bijvoorbeeld bij verdere routering of bij een wijziging in de verwachte doorlooptijd.

Procesbeheersing is gebaseerd op rapportage aan de verschillende doelgroepen. De incidentmana-ger is verantwoordelijk voor de rapporten, en ook voor het opstellen van een distributielijst en een rapportagekalender. De rapporten kunnen zeer gedetailleerd zijn en specifi ek zijn gericht op de volgende betrokkenen:• Incidentmanager - rapport vereist voor het:

– signaleren van hiaten in het proces– signaleren van confl icten met SLA’s– bijhouden van het proces– identifi ceren van trends

• IT-lijnmanagement - rapport voor het management van de oplosgroepen om sturing bin-nen de eigen oplosgroep mogelijk te maken. Daarvoor is informatie nodig over:– de voortgang van de incidentafhandeling– de doorlooptijden van incidenten in verschillende oplosgroepen

• servicelevelmanagement - rapport met informatie over de kwaliteit van de geleverde services, bedoeld voor klanten

• procesmanagers van andere servicemanagementprocessen – de rapporten aan de managers van andere processen zullen voornamelijk informatief zijn. Incidentmanagement kan bijvoor-beeld de volgende informatie opleveren uit de incidentenrecords:– aantal gemelde en geregistreerde incidenten– aantal opgeloste incidenten, onderverdeeld naar responsietijd– aantal onopgeloste incidenten en hun status– incidenten per tijdsperiode, klantgroep, oplosgroep en afhandeling conform de SLA– incidenten per categorie en prioriteit, per oplosgroep

Voorwaarden voor succesvol incidentmanagement (CSF’s) zijn:• een goed bijgehouden CMDB die helpt bij het schatten van impact en urgentie van inci-

denten• een kennisbank, bijvoorbeeld een actuele problem- of known error- database, waarin staat

hoe incidenten kunnen worden herkend en welke oplossingen en workarounds er zijn • een geautomatiseerd systeem voor het registreren, volgen en bewaken van incidenten



• nauwe samenwerking met servicelevelmanagement om de juiste prioriteitstellingen en op-lostijden te kunnen hanteren

Voorbeelden van KPI’s zijn:• het totaal aantal incidenten• gemiddelde oplostijden (per prioriteit)• percentage incidenten opgelost binnen de SLA-targets• percentage incidenten opgelost in de eerste lijn (zonder doorsturen)• gemiddelde supportkosten per incident• opgeloste incidenten per servicedeskstation of -werknemer• incidenten opgelost zonder de gebruiker te bezoeken• aantal incidenten (of percentage) met een initieel juiste classifi catie• aantal incidenten (of percentage) dat correct is doorgestuurd

4.5.2 Oplossingsproces: problemmanagement (8.3)

Doelstelling: Het beperken van verstoringen voor de business door een proactieve vaststelling en analyse van de oorzaak van incidenten en door problems tot de afsluiting te managen.


Alle vastgestelde problems moeten worden vastgelegd.Er moeten procedures worden ingesteld om de impact van incidenten en problems te bepalen, te beperken of te vermijden. Deze procedures moeten voor alle problems aangeven hoe deze moeten worden vastgelegd, geclassifi ceerd, geactualiseerd, geëscaleerd, opgelost en formeel afgesloten.Er moeten preventieve acties worden genomen om potentiële problems te beperken, bijvoorbeeld het volgen van trendanalyses van omvang en typen van incidenten.Changes die nodig zijn om onderliggende oorzaken van problems aan te pakken moeten worden behandeld door het changemanagementproces. Het oplossen van problems moet worden gemonitord, gereviewd en gerapporteerd met oog op de effectiviteit.Problemmanagement moet verantwoordelijk worden gehouden voor het up-to-date houden van informatie over known errors en gecorrigeerde problems en zorgen dat deze informatie beschikbaar is voor incidentmanagement.Verbeteracties die tijdens dit proces zijn bepaald moeten worden vastgelegd, en vormen de input voor een serviceverbeterplan.


Scope van problemmanagementHet problemmanagementproces hoort de onderliggende oorzaken van incidenten te onderzoeken. Problemmanagement hoort proactief de terugkeer of herhaling van incidenten of known errors te voorkomen, in overeenstemming met de bedrijfseisen.



Initiatie van problemmanagementIncidenten horen te worden geclassifi ceerd om oorzaken van problemen te helpen vaststellen. Classifi -catie kan verwijzen naar bestaande problemen en changes.

NOOT Bij eerste registratie zal de categorisatie van incidenten ook worden beïnvloed door andere factoren, waaronder de getroffen service of het getroffen bedrijfsonderdeel en de vertoonde symptomen.

Known errorsAls problemmanagement de hoofdoorzaak van een incident heeft gevonden en een methode om het incident op te lossen, hoort het probleem te worden geclassifi ceerd als een known error. Alle known errors horen te worden geregistreerd in het licht van de actuele en potentieel getroffen ser-vices, naast het confi guratie-item dat verdacht wordt van een defect.Informatie over known errors in services die in de productieomgeving zijn geïntroduceerd, hoort te worden doorgegeven aan servicemanagement en hoort te worden geregistreerd in de kennisbank, samen met alle workarounds.Een known error hoort niet eerder te worden afgesloten dan dat deze succesvol is opgelost.

NOOT: De klant of serviceprovider kan beslissen dat de oplossing te duur is of de bedrijfsvoering niet ten goede komt. Als dit het geval is, moet het helder zijn gedocumenteerd. Het known error-record hoort echter open te blijven, omdat het waarschijnlijk is dat er nog vervolgincidenten optreden die workarounds nodig hebben en/of heroverweging vereisen van de beslissing tot afsluiting.

Oplossing van problemsAls de hoofdoorzaak is vastgesteld en de beslissing om deze op te lossen is genomen, hoort de oplossing te worden voortgezet via het changemanagementproces.

CommunicatieInformatie over workarounds, permanente fi xes of voortgang van problemen horen te worden mede-gedeeld aan degenen die hier hinder van ondervinden of degenen die nodig zijn om ondersteuning te bieden bij de getroffen services.

Tracking en escalatie De voortgang van alle problems hoort te worden gevolgd.

Alle issues horen te worden geëscaleerd naar de passende partijen. Het proces hoort de volgende activi-teiten te omvatten:a) registratie van wijzigingen aan de identiteit van degenen die verantwoordelijk zijn voor de oplos-

sing van problems gedurende de levenscyclus van elke problemb) identifi catie van incidenten die inbreuk doen op serviceleveldoelenc) doorspelen van informatie naar klanten en collega’s zodat zij passende actie kunnen nemen om de

impact van het onopgeloste problem te beperkend) defi nitie van escalatiepuntene) registratie van gebruikte resources en alle genomen acties



Afsluiting van incidenten problemrecordsIn de afsluitingsprocedure van records hoort controle te zijn opgenomen, om te borgen dat:a) details van de oplossing nauwkeurig zijn gelogdb) de oorzaak is gecategoriseerd, om analyse te faciliterenc) zowel de klant als het supportpersoneel op de hoogte zijn van de oplossing, indien van toepassingd) de klant ermee instemt dat de oplossing is gerealiseerde) als een oplossing niet wordt gerealiseerd of niet mogelijk is, de klant wordt geïnformeerd

ProblemreviewsEr horen problemreviews te worden uitgevoerd als de analyse van onopgeloste, ongewone problems of problems met veel impact dit rechtvaardigt. Het doel van deze reviews is om naar procesverbeteringen te streven en herhaling van incidenten of fouten te voorkomen.

Standaard problemreviews zijn: a) reviews van afzonderlijke incidentniveaus en van de status van problems ten opzichte van service-

levelsb) managementreviews om licht te werpen op problems die onmiddellijk actie vereisenc) managementreview om trends vast te stellen en analyseren en input voor andere processen te c)

bieden, zoals opleiding en training van gebruikers

Onderwerpen voor reviewsDe reviews horen identifi catie te omvatten van:a) trends, bijvoorbeeld terugkerende problems en incidenten, known errors, enzovoortb) terugkerende problems van een bijzondere classifi catiecomponent of locatiec) gebreken die zijn veroorzaakt door toewijzing van resources, training of documentatied) afwijkingen, bijvoorbeeld van standaarden, richtlijnen en regelgevinge) known errors in geplande releasesf ) inzet van personeelsresources bij de oplossing van incidenten en problemsg) terugkeer van opgeloste incidenten of problems

Verbeteringen aan de service of aan het problemmanagementproces horen te worden geregistreerd en opgenomen in een serviceverbeterplan.De informatie hoort te worden toegevoegd aan de kennisbank van problemmanagement.Alle relevante documentatie hoort te worden geactualiseerd, bijvoorbeeld gebruikershandleidingen en systeemdocumentatie.

ProblempreventieProactief problemmanagement hoort te leiden tot een afname van incidenten en problems. Het hoort ook informatie te raadplegen die ondersteunend is voor analyse, zoals:a) asset en confi guratieb) changemanagementc) gepubliceerde informatie van leveranciers over known errors en workarounds d) historische informatie over soortgelijke problems

Problempreventie hoort te variëren van preventie van afzonderlijke incidenten, zoals herhaaldelijke moeilijkheden met een bijzonder systeemkenmerk, tot strategische beslissingen. De implementatie van deze beslissingen kan fi kse uitgaven vereisen zoals investering in een beter netwerk. Op dit niveau gaat



proactief problemmanagement samen met beschikbaarheidsmanagement. Problempreventie houdt ook in dat de klant zodanig wordt geïnformeerd, dat ze in de toekomst niet meer om hulp te hoeven vragen. Dit voorkomt bijvoorbeeld incidenten die veroorzaakt worden door gebrek aan gebruikerskennis of -training.

Net als bij incidentmanagement stelt ISO 20000 specifi eke eisen aan gedetailleerde procedures voor problemmanagement. Deze procedures bevatten een aantal activiteiten die identiek zijn aan die van het incidentmanagementproces: registreren, classifi ceren , escaleren, oplossen en afsluiten. Prioriteren en defi niëren van de impact op de business zijn de aanvullende stappen in incident-management. De specifi ek vereiste documenten in het problemmanagementproces zijn problemrecords en re-cords van de vastgestelde verbeteracties (zie fi guur 4.5.4 en 4.5.5).Problemmangement heeft interfaces met het changemanagementproces voor het managen van de vereiste changes. Het incidentmanagementproces en alle andere servicemanagementprocessen halen actuele informatie uit het problemmanagementproces. Een andere interface is continue verbetering. Alle interfaces moeten worden gedocumenteerd.

RichtlijnenDe input van problemmanagement bestaat uit:• incidentgegevens, inlcusief workarounds• details van het incident uit de confi guratiemanagementdatabase (CMDB)• details van de leverancier over de producten die gebruikt worden in de infrastructuur, inclusief

technische details en de known errors van deze producten• de servicecatalogus en de service level agreements• details over de infrastructuur en de manier waarop deze zich gedraagt, zoals capaciteitsrecords,

performancemetingen en rapportages over servicelevels

De output bestaat uit:• een known error-database, die in feite een deelverzameling is van de problemmanagementda-

tabase• RfC’s• actuele problemrecords• afgesloten problemrecords als de hoofdoorzaak is verholpen• managementinformatie

De hoofdactiviteiten van problemmanagement zijn:• problembeheersing• foutbeheersing• proactief problemmanagement• leveren van informatie

Het doel van problembeheersing is het omzetten van problemen naar known errors door de on-derliggende oorzaak te bepalen en een workaround te vinden. Figuur 4.5.6 is een weergave van problembeheersing.



Registreer gebruikte resources,genomen acties, wijzigingen inverantwoordelijke personen enreview de resultaten

Kan ook betere training vanklanten omvatten

Monitor, review en rapporteerover de effectiviteit van de oplossing

Prioriteit bepaalt oplossingstargetsPrioriteit hoort te worden gebaseerdop impact en urgentieImpact heeft betrekking op schadeaan de business van de klantUrgentie heeft betrekking optijdsdruk in de business van de klant

Inplanning is gebaseerd opprioriteiten, beschikbare resources,tijd en kosten

Met inbegrip van:- actueel en potentieel getroffen services- CI verdacht van fout

Met inbegrip van:- toepasbaarheid- effectiviteit

Samen met workarounds

Definieer escalatiemomenten

Bijvoorbeeld door trendanalysevan omvang en types incidenten

Gebaseerd op bepalen welkeincidenten inbreuk doen opserviceleveldoelen

Zorg ervoor dat:- oplossingsdetails worden gelogd- oorzaak wordt gecategoriseerd- klant- en supportpersoneel zijn op de hoogte van oplossing- klant accordeert de oplossing- klant wordt geïnformeerd als de oplossing niet is gevonden

Problemrecords

Problemrecords

Problemrecords

Incidentrecords

Andereinformatiebronnen,

zoals asset- enconfiguratie, known

errors en workarounds Registreer problems

Stel de problems vast(reactief en proactief)

Classificeer problems

Acualiseerproblemrecords

Escaleer problems

Sluit problems af

Los problems op

Prioriteer problems

Onderzoek enbepaal oorzaak enclassificeer problem

als known error

Bepaal oplossing

Ontwikkel enonderhoudworkaround

Stel procedures in

Problemrecords

Geactualiseerdeproblemrecords

Geactualiseerde problemrecords

RfC

Geactualiseerdeproblemrecords

Known error

Workarounds

Interfaces:

Klant:- informatie over de getroffen bedrijfsgebieden


Changemanagement:- dien requests for changes in



Informatiesecuritymanagement:- wissel managementinformatie uit over trends in informatiesecurity-incidenten- security-incidenten horen te worden onderzocht door problemmanagement

Incidentmanagement:- wissel relevante informatie uit

Figuur 4.5.4 Problemmanagement - vaststelling, beperking of vermijding van de impact van incidenten en problems



KennisbankrecordsSamen met workarounds

Zowel naar de getroffen klantals naar de getroffen medewerkers

Met inbegrip van:- trends- gebreken- afwijkingen- known errors in geplande releases- betrokkenheid van personele resources- herhaling van opgeloste problemen


Lever informatie overknown errors aan alle

ITSM-processen alseen service in de

productieomgevingwordt geïntroduceerd

en registreer ditin de kennisbank

Communiceerinformatie overworkarounds,

permanent fixesof voortgang van

problems

Volg voortgangvan problems

Review problemindien van toepassing

(Foutbeheersing)

Vo

lgen

en

mo

nit

ore

n v

an p

rob

lem

s

Bepaling enregistratie van

problems

Problemonderzoeken -diagnose

Oplossing enafsluiting van

RfC's en problems

Problemclassificatie

Figuur 4.5.5 Problemmanagement - vervolg

Figuur 4.5.6 Problembeheersing volgens ITIL V2 (Bron: OGC)Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


In principe hoort elk incident met onbekende oorzaak als een problem te worden behandeld. Dit is echter alleen de moeite waard als verwacht wordt dat het incident herhaaldelijk optreedt of als er sprake is van een enkel ernstig incident.De activiteit ‘vaststellen van problemen’ wordt vaak toegekend aan problemanalisten. Ander per-soneel, zoals werknemers bij capaciteitsmanagement, kunnen echter ook helpen bij de opsporing van problems. De details van een problem lijken op die van een incident, met dat verschil dat het niet nodig is om informatie over de gebruiker op te nemen. Er moet echter worden vastgesteld welke inciden-ten samenhangen met het problem en deze incidenten moeten aan dit problem worden gekop-peld. Voorbeelden van situaties waarin problems worden vastgesteld:Een analyse van incidentgegevens geeft aan dat er sprake is van herhaling van een incident, wat leidt tot een signifi cante omvang of trend.• Een analyse van de infrastructuur geeft aan dat er zwakke plekken zijn waar nieuwe incidenten

uit kunnen ontstaan (wordt ook genanalyseerd door beschikbaarheidsmanagement en capaci-teitsmanagement).

• Er treedt een ernstig incident op, waarvoor een structurele oplossing moet worden gevonden om herhaling te voorkomen.

• Servicelevels komen onder druk te staan (capaciteit, performance, kosten).• Geregistreerde incidenten zijn niet toe te wijzen aan een bestaand problem of een known

error.

Trendanalyse kan leiden tot de ontdekking van gebieden die extra aandacht behoeven. Die extra aandacht kan worden uitgedrukt in kosten en baten voor de organisatie, bijvoorbeeld door vast te stellen welke aandachtsgebieden meer ondersteuning vragen en hoe belangrijk die aandachts-gebieden zijn voor de serviceverlening.

Deze assessment kan worden gebaseerd op de ernst of de ‘pijnfactor’ van incidenten. Dit wordt vastgesteld op basis van:• de impact die de incidenten op businessactiviteiten hebben• het aantal incidenten• het aantal gebruikers en bedrijfsprocessen dat er last van heeft• de duur en de kosten van het oplossen van incidenten

Problems kunnen per aandachtsgebied (categorieën) worden ingedeeld. Identifi catie leidt naar het laagste CI-niveau dat het problem beïnvloedt. Tegelijk met de classifi catie wordt een impact-analyse gedaan, waarbij wordt gekeken naar de ernst van het problem en naar de gevolgen voor de serviceverlening (urgentie en impact). Vervolgens wordt een prioriteit toegekend, op dezelfde manier als bij het incidentmanagementproces. Personeel en resources worden toegewezen op basis van de problemclassifi catie en er wordt tijd beschikbaar gesteld voor het oplossen van het problem.

De classifi catie omvat:• categorie – toewijzing aan relevant domein, bijvoorbeeld hardware en software• impact – op het bedrijfsproces• urgentie – de mate waarin uitstel van een oplossing acceptabel is



• prioriteit – combinatie van urgentie, impact, risico en benodigde resources• status – bijvoorbeeld problem, known error, opgelost, afgesloten

De classifi catie is niet statisch, er kunnen gedurende de levenscyclus van een problem wijzigingen optreden. Zo kan bijvoorbeeld de aanwezigheid van een workaround of een tijdelijke herstelactie de urgentie en impact van een problem verminderen, terwijl het optreden van nieuwe incidenten de impact en urgentie van een problem kan verhogen.

Onderzoek en diagnose wordt verschillende keren herhaald en komt daarbij telkens dichter bij het beoogde resultaat. Vaak wordt in een testomgeving geprobeerd of het incident te reproduceren is. Daarbij kan meer expertise worden ingeschakeld, bijvoorbeeld een specialist of oplosgroep die een bijdrage levert aan de analyse en diagnose van het problem.

Problems worden niet alleen veroorzaakt door hardware en software. Ze kunnen veroorzaakt worden door een documentatiefout, een menselijke of een procedurele fout, zoals bijvoorbeeld bij het vrijgeven van een verkeerde softwareversie. Daarom kan het nuttig zijn om ook procedures te registreren in de CMDB en ze onder versiebewaking te stellen. De meeste fouten zijn te her-leiden naar onderdelen van de infrastructuur.

Als men weet wat de oorzaak is van het problem en de CI, of van de combinatie van CI’s, kan een verband worden gelegd tussen het CI en het incident (de incidenten). Het problem krijgt dan de status van known error, of wordt daaraan gekoppeld, en het foutbeheersingsproces kan van start gaan. Dit houdt in dat known errors - waar mogelijk en indien van toepassing - worden bewaakt

(Foutbeheersing)

Vo

lgen

en

mo

nit

ore

n v

an f

ou

ten

Foutidentificatieen -registratie

Registreeroplossing fout RfC

Foutassessment

Sluit de fouten de problem(s)

die hiermeesamenhangen

af

De change is succesvolgeïmplementeerd

Figuur 4.5.7 Foutbeheersing volgens ITIL V2 (Bron: OGC)



en gemanaged tot ze zijn opgelost. Dit gebeurt door een RfC bij changemanagement aan te mel-den en door de changes te evalueren in een post implementation review (PIR). Bij foutbeheersing kunnen verschillende afdelingen zijn betrokken en het beslaat zowel de productieomgeving als de ontwikkelomgeving (zie fi guur 4.5.7).

Problemmanagement moet bepalen wat de beste oplossing is voor elk problem, met oog op de servicelevel agreements, de kosten en baten en de impact en urgentie van de known error. Dit houdt in dat er bepaald moet worden of er een tijdelijke oplossing of een permanente oplossing nodig is, of misschien beide. Er kan ook worden besloten om niets aan het problem te doen, bij-voorbeeld omdat er geen businesscase voor is. Wat er ook wordt besloten, het moet in ieder geval worden vastgelegd zodat incidentmanagement er gebruik van kan maken.

Als er een geschikte oplossing is gekozen, zijn er ook voldoende gegevens beschikbaar voor een RfC. Changemanagement handelt op grond van deze RfC de implementatie van de daadwerke-lijke oplossing af.

De changes die bedoeld zijn om problems, known errors en hiermee samenhangende incidenten op te lossen, moeten na hun implementatie in een post implementation review (PIR) worden gereviewd voordat de bijbehorende records kunnen worden afgesloten. Als de change succesvol is geweest, dan worden alle problemrecords en known error-records gesloten, samen met de bijbehorende incidentrecords. In het geval van een problemrecord wordt de status in de problem-database veranderd in ‘opgelost’. Incidentmanagement wordt op de hoogt gebracht, zodat de incidenten die bij het problem horen ook kunnen worden gesloten. Voor major problems hoort er een afzonderlijke review te worden gehouden om in kaart te brengen:• wat er goed is gegaan• wat er niet goed is gegaan• hoe het volgende keer beter kan• hoe de situatie in de toekomst kan worden voorkomen

NOOT: veel organisaties implementeren het proces zo, dat een problem alleen kan worden ge-sloten als de bijbehorende incidenten zijn gesloten (en dus geverifi eerd door de klant), anders zou het problem moeten worden heropend als de bijbehorende incidenten niet gesloten kunnen worden.

Tracking en monitoring volgt de voortgang van problems en known errors gedurende hun gehele levenscyclus. Deze acties worden ondernomen binnen problembeheersing en foutbeheersing. De doelstellingen zijn:• bepalen of de impact of de urgentie van het problem wijzigt en indien nodig aanpassen van de

toegewezen prioriteit• monitoren van de voortgang van het vinden en implementeren van een oplossing, en het

monitoren van het succes van de RfC; changemanagement informeert problemmanagement regelmatig over het ingediende RfC

Over het algemeen houdt proactief problemmanagement zich bezig met de kwaliteit van de servi-ces en de infrastructuur. Om problems te voorkomen, hoort het zich te concentreren op trend-analyse en de identifi catie van potentiële problemen voordat deze zich voordoen. Dit wordt



gedaan door te kijken naar componenten die zwak of te zwaar belast zijn. Als er meerdere domei-nen zijn, dan worden er pogingen gedaan om storingen die in het ene domein voorkomen niet te laten voorkomen in andere domeinen. Zwakheden van infrastructuurcomponenten kunnen wor-den geïdentifi ceerd en onderzocht. Met behulp van een goed ontworpen en geïmplementeerde CMDB kan er een wat-als-analyse worden gedaan om potentiële zwakke punten te herkennen en om proactief te reageren teneinde de risico’s te beperken.

Gedurende het proces wordt aan incidentmanagement informatie geleverd over workarounds en quick fi xes, zodat de servicedesk de getroffen gebruiker snel kan informeren. Om uit te vinden welke informatie aan welke groep moet worden gegeven, kan er gebruik worden gemaakt van de CMDB en de SLA.

Kritieke succesfactoren van problemmanagement zijn:• een goed gedefi nieerd procesframework en verzameling van procesdoelstellingen, interfaces en

resources• een verzaming van allesomvattende en goed gedocumenteerde procedures• goede gegevens van incidentmanagement en effectieve samenwerking tussen incidentmanage-

ment en problemmanagement

KPI’s van problemmanagement zijn:• de vermindering van het aantal incidenten door het managen en oplossen van problems• de vermindering van de oplostijd van problems• de vermindering van de kosten van het oplossen van storingen

Procesparameters kunnen ook worden gerapporteerd voor interne managementdoeleinden, om de effi ciëntie van problemmanagement te beoordelen en te beheersen. Rapporten over problem-management kunnen erg uitgebreid zijn, en kunnen de volgende onderwerpen bevatten: • tijdsrapportages – onderverdeeld in probleembeheersing, foutbeheersing en proactief pro-

blemmanagement en onderverdeeld in oplosgroep en leverancier• kwaliteit van componenten – details van incidenten, problems en known errors kunnen

worden gebruikt om componenten vast te stellen die aangetast worden door regelmatig optre-dende storingen, en te bepalen of leveranciers voldoen aan hun contractuele verplichtingen.

• effectiviteit van problemmanagement – details over het aantal incidenten voor en na het oplossen van een problem, vastgelegde problems, vastgelegde known errors en het aantal RfC’s dat is ingediend en succesvol is geïmplementeerd

• relatie tussen reactief en proactief problemmanagement - toenemende proactieve interven-ties in plaats van het reacties op incidenten, dit geeft een toenemende volwassenheid van het proces aan

• kwaliteit van de ontwikkelde services – rapporten over nieuwe services en componenten en hun known errors

• status en actieplannen voor openstaande problems – samenvatting van wat er tot dusver is gedaan en wat er gedaan gaat worden om de impact van problems te verminderen, omvat ook geplande RfC’s en de benodigde tijd en resources

• voorstellen tot verbetering van problemmanagement – als de informatie over de boven-staande factoren aangeeft dat het proces niet in overeenstemming is met doelstellingen van problemmanagement in het servicekwaliteitsplan, dan kunnen er voorstellen worden gedaan voor procesverbeteringen en bepaling van extra resources


De doelgroep voor servicemanagementcertifi caten bestaat uit medewerkers van zowel (bedrijfs-)interne als externe serviceproviders die betrokken zijn bij, of belang stellen in servicekwaliteits-management, ook als de organisatie nog niet is gecertifi ceerd. Het ISO/IEC 20000 Foundation certifi caat richt zich in het bijzonder op dit relatief brede publiek. Daarnaast stelt het klanten, die overwegen een ISO/IEC-certifi cering van hun serviceproviders te eisen, in staat zich een beeld te vormen van wat ze op dat gebied van hun serviceproviders kunnen verwachten.

De exameneisen zijn:1. Inzicht in de defi nities en principes van servicekwaliteitsmanagement:

a. De kandidaat heeft inzicht in kwaliteit.b. De kandidaat heeft inzicht in service.c. De kandidaat heeft inzicht in IT-servicemanagement.d. De kandidaat heeft inzicht in processen.e. De kandidaat heeft inzicht in continue verbetering.

2. Inzicht in de posititionering van ISO/IEC 20000 in IT-servicemanagement:a. De kandidaat heeft inzicht in de diverse normen en frameworks.b. De kandidaat heeft inzicht in de concepten van certifi ceringen.c. De kandidaat heeft inzicht in het concept van ISO/IEC 20000.

3. De kwaliteitsspecifi catie van IT-servicemanagementa. De kandidaat heeft inzicht in de kwaliteitsspecifi caties voor management en verbetering

van ITSM-processen.b. De kandidaat heeft inzicht in de kwaliteitsspecifi caties voor de control (beheersing) van

IT-services.c. De kandidaat heeft inzicht in de kwaliteitsspecifi caties voor de alignment van IT met de

business.d. De kandidaat heeft inzicht in de kwaliteitsspecifi caties voor de levering van IT-services.e. De kandidaat heeft inzicht in de kwaliteitsspecifi caties voor de support van IT-services.

4. De praktijkcode voor IT-servicemanagement gebaseerd op ISO/IEC 20000:a. De kandidaat heeft inzicht in de best practices voor management en verbetering van ITSM-

processen.

Hoofdstuk 5Het ISO/IEC-Foundation examen



b. De kandidaat heeft inzicht in de best practices voor de control (beheersing) van IT-services.c. De kandidaat heeft inzicht in de best practices voor de alignment van IT met de businessd. De kandidaat heeft inzicht in de best practices voor de levering van IT-services.e. De kandidaat heeft inzicht in de best practices voor de support van IT-services.

5.1 VoorwaardenEr zijn geen formele criteria of toelatingseisen voor kandidaten die deel willen nemen aan het ISO 20000 Foundation-examen. Het wordt kandidaten echter wel aangeraden om een geaccre-diteerde opleiding te volgen (die ook kan bestaan uit zelfstudie via het internet), bij een van de geaccrediteerde cursusaanbieders.

Er zijn geen strenge criteria voor degenen die willen deelnemen aan een geaccrediteerde cursus, al is enige bekendheid met IT-servicemanagement wel gewenst. Verder wordt aangeraden om het IT Service Management Foundation Certifi caat te behalen alvorens een ISO/IEC 20000-oplei-ding te volgen.

5.2 ExamenvormHet examen bestaat uit 40 meerkeuzevragen, duurt één uur en is een gesloten boek-examen. Elke vraag heeft vier keuzemogelijkheden. De kandidaat moet het juiste antwoord selecteren. Voor elk goed antwoord wordt één punt toegekend.

De vragen voor elk examen worden gekozen uit een vragenbank die regelmatig wordt geactuali-seerd. Vragen en examens worden meer dan eens gebruikt en daarom is het opleiders, kandidaten en surveillanten niet toegestaan om kopieën van de examens te bewaren.

Om kandidaten goed voor te bereiden op het examen, ontvangen alle geaccrediteerde opleiders een proefexamen en een nakijkvel. Examens die computergestuurd of via internet worden afge-nomen worden automatisch nagekeken en het resultaat wordt meteen aan de kandidaat mede-gedeeld. Examens op papier worden teruggestuurd naar het exameninstituut of de gemachtigde om te worden nagekeken.

Om te slagen moet een kandidaat een score van 26 punten of hoger behalen. Als een kandidaat zakt, kan hij een herexamen doen. Er is geen limiet aan het aantal keren dat een kandidaat her-examen kan doen.

De meeste kandidaten zullen het examen afl eggen na voltooiing van een geaccrediteerde training. Opleiders kunnen samenwerken met het Accredited Examination Center (AEC) om het examen af te nemen op hun locatie. Het AEC is verantwoordelijk voor het waarborgen van de integriteit van het examenproces en voor het terugsturen van de ingevulde examenformulieren naar het exameninstituut of de gemachtigde.

Exameninstituten en -gemachtigden bieden doorgaans ook een algemene examenplanning, waarin is aangegeven wanneer kandidaten zich kunnen inschrijven voor een examen en wanneer


Het ISO/IEC-Foundation examen 213

ze dit vervolgens kunnen afl eggen. Speciale omstandigheden voor het afnemen van examens bui-ten de voorwaarden van het exameninstituut of de gemachtigde, zoals extra examentijd, worden gepubliceerd door de examinerende instelling.

5.3 KlachtenKandidaten die klachten hebben kunnen deze voorleggen aan de desbetreffende opleider, aan het exameninstituut of de gemachtigde. Elk exameninstituut en elke gemachigde heeft een klachten-regeling die de relatie tussen opleiders en kandidaten regelt. Deze regeling is algemeen beschik-baar, bijvoorbeeld via een website.

5.4 ExamenvoorbereidingOm de kans op succes te verhogen zijn er enkele voorzorgsmaatregelen die u kunt nemen. Voor-op staat dat u het examen serieus neemt.

5.4.1 Voorbereiding op het examen• Doe mee aan een geaccrediteerde training. Het leren van de grondbeginselen van servicekwa-

liteitsmanagement is leuker en effectiever in een groep van vakgenoten die ervaringen delen. Daarnaast heeft u het voordeel van een ervaren begeleider met grondige kennis en ruime praktijkervaring.

• Neem voldoende tijd voor zelfstudie en bestudering van het cursusmateriaal, ISO 20000-ma-teriaal en dit boek. Als vuistregel wordt geadviseerd om ongeveer 20 uur aan zelfstudie te besteden.

• Bespreek met collega’s en vrienden wat u heeft geleerd tijdens de cursus en uit de boeken. Het delen van ervaringen met best practice helpt bij het begrijpen van de principes van servicekwa-liteitsmanagement.

• Maak gebruik van het meest recente voorbeeldexamen van uw exameninstituut om u voor te bereiden op het type vragen dat in het examen wordt gebruikt.

5.4.2 Voorbereiding op de dag zelf• Bereid uw reis naar de examenlocatie goed voor. Kom vijftien minuten voor aanvang zodat u

een rustige start kunt maken, bijvoorbeeld met een kopje koffi e of thee.• Zorg dat u de nacht van te voren goed slaapt, zodat u goed uitgerust aan het examen kunt

beginnen. Ga niet nog tot diep in de nacht studeren.• Trek kleren aan die comfortabel zitten. U hoeft uw bedrijf niet te vertegenwoordigen , u komt

voor uzelf.• Vergeet niet om een geldig identifi catiebewijs mee te nemen (paspoort, rijbewijs, identiteits-

bewijs).

5.4.3 Hints en tips voor het examen• Lees alle vragen zorgvuldig. • Begin met het beantwoorden van de makkelijke vragen.• Probeer bij de meerkeuzevragen eerst zelf een antwoord te bedenken, en kijk dan pas naar de

mogelijkheden. Uw eerste idee vaak het beste.• Er is maar één juist antwoord. Kies het antwoord dat de vraag het beste beantwoordt. Dit

antwoord hoeft niet noodzakelijk alles weer te geven wat u over het onderwerp heeft geleerd.



• Maak de vraag niet ingewikkelder door tegenvoorbeelden te bedenken voor het antwoord dat volgens u het beste past. De vragen zijn niet bedoeld als strikvragen.

• Controleer voor het einde van de examensessie of u alle vragen heeft beantwoord. Als u niet zeker bent van een antwoord, vul dan in wat u het beste lijkt.

• Maakt u zich geen zorgen. Met een goede voorbereiding hoeft het examen niet moeilijk te zijn. U kunt het!

5.5 VoorbeeldvragenDe volgende set oefenvragen geven een goed beeld van het type vragen dat u kunt verwachten tijdens het echte examen. De voorbeeldvragen kunt u gebruiken om het introductieboek effec-tiever te bestuderen.

Voor extra examenvoorbereiding kunt u het meest recente voorbeeldexamen opvragen bij een exameninstituut of een geaccrediteerde opleider. De meest recente voorbeeldexamens geven de laatste wijzigingen en verbeteringen van de examens weer en bevatten een uitgebreide versie van de antwoordsleutel, inclusief commentaar en uitleg bij elke keuzemogelijkheid.

Vraag 1 Een benadering voor het ontwikkelen en implementeren van een kwaliteitsmanagementsysteem bestaat uit enkele stappen.

Welk van de volgende stappen is niet noodzakelijk?

A. overeenkomen van het kwaliteitsbeleid en -doelstellingen met de changemanagerB. bepalen en ter beschikking stellen van middelen die nodig zijn voor het verwezenlijken van de

kwaliteitsdoelstellingenC. bepalen van de eisen en verwachtingen van klanten en andere belanghebbende partijenD. vaststellen van methodes om de doeltreffendheid en doelmatigheid van elk proces te kunnen

meten

A. Juist. Het kwaliteitsbeleid en de kwaliteitsdoelstellingen dienen met meer mensen overeengekomen te worden, niet alleen met de changemanager.

B. Onjuist. Dit is een stap bij het ontwikkelen en implementeren van een kwaliteitsmanagementsys-teem.

C. Onjuist. Dit is een stap bij het ontwikkelen en implementeren van een kwaliteitsmanagementsys-teem.

D. Onjuist. Dit is een stap bij het ontwikkelen en implementeren van een kwaliteitsmanagementsys-teem.

Vraag 2 De relatiebeheerprocessen beschrijven de zakelijke relaties en het beheer van leveranciers. Wat behoren de relatiebeheerprocessen te bewerkstelligen?



A. Dat alle partijen de bedrijfsmatige behoeften, verantwoordelijkheden en verplichtingen be-grijpen.

B. Dat de business en de leveranciers direct worden geïnformeerd over ingrijpende incidenten.C. Dat de dienstenniveaus voor alle diensten in de gehele leverketen consistent zijn.D. Dat er een regelmatig contact is tussen de leveranciers en de business om eventuele ontevre-

denheidsproblemen op te lossen.

A. Juist. De relatiebeheerprocessen omvatten supplier management en business relationship manage-ment. Samen behoren zij te bewerkstelligen dat de bedrijfsbehoeften van de klant worden begrepen en dat de verantwoordelijkheden en verplichtingen van alle partijen zijn begrepen en gedocumen-teerd.

B. Onjuist. Het proces voor de afhandeling van een ingrijpend incident behoort communicatie naar alle bij het herstel betrokken gebieden en de getroffen klanten te omvatten. Echter, dit wordt be-heerd binnen het incidentmanagementproces en in de verantwoordelijkheid van een aangewezen beheerder van het ingrijpende incident. Het valt dus buiten de scope van de relatiebeheerprocessen.

C. Onjuist. Het is niet nodig dat de dienstenniveaus consistent zijn naar alle leveranciers en het is ook onwaarschijnlijk dat dit het geval zal zijn. Het is echter noodzakelijk dat de dienstenniveaus voor de leveranciers in lijn zijn gebracht met deze voor de business, zodat de service level agreements (SLAs) overeengekomen met de klant kunnen worden gehaald.

D. Onjuist. De business behoort geen direct contact met de leveranciers te hebben. De dienstverlener is verantwoordelijk voor het beheren van de leveranciers en het waarborgen van de kwaliteit van de aan de business geleverde diensten.

Vraag 3Wat moet worden opgenomen in de releasemanagementprocedures conform ISO/IEC 20000?

A. de autorisatie en implementatie van noodwijzigingen (emergency changes)B. het onderzoeken en voorkomen van beveiligingsincidentenC. het registreren van alle gemelde incidentenD. het bijwerken en wijzigen van confi guratie-informatie en wijzigingsregistraties

A. Onjuist. Dit is onderdeel van de changemanagementprocedures.B. Onjuist. Dit is onderdeel van de information security management-procedures. C. Onjuist. Dit is onderdeel van de incidentmanagementprocedures. D. Juist. Conform de norm is dit een vereiste. Releasemanagementprocedures moeten het bijwerken en

wijzigen van confi guratie-informatie en wijzigingsregistraties omvatten.

Vraag 4Welk van de onderstaande frameworks biedt specifi ek ondersteuning voor IT-governance?

A. CobITTM

B. ISO 9000C. ISO/IEC 20000D. MOF



A. Juist. CobITTM is ISACA’s richtlijn voor IT-governance.B. Onjuist. ISO 9000 is de algemene norm voor kwaliteitsmanagementsystemen. C. Onjuist. ISO/IEC 20000 is de IT-servicemanagementnorm. D. Onjuist. MOF is het service managementframework van Microsoft®.

Vraag 5De Plan-Do-Check-Act (PDCA) methodologie kan worden toegepast op alle ISO/IEC 20000-processen.

Wat dekt de Act-fase van deze methodologie af?

A. vaststellen van de doelstellingen en processen die nodig zijn om resultaten te bereiken die in overeenstemming zijn met klantvereisten en het beleid van de organisatie

B. implementeren van de processenC. bewaken en meten van processen en diensten en het rapporteren van de resultatenD. treffen van maatregelen om de procesprestaties continu te verbeteren

A. Onjuist. Deze actie wordt ondernomen in de Plan-fase van de methodologie. B. Onjuist. Deze actie wordt ondernomen in de Do-fase van de methodologie. C. Onjuist. Deze actie wordt ondernomen in de Check-fase van de methodologie. D. Juist. Deze actie wordt ondernomen in de Act-fase van de methodologie.

Vraag 6Hoe behoort de Deming-cyclus te worden gebruikt?

A. als een model voor continue verbeteringB. als een model voor klantgerichtheidC. als een model om te gebruiken in de ontwerpfase van een dienstD. als een model voor het berekenen van de kosten voor de verbetering van de dienstverlening

A. Juist. Dit is waar de cyclus zich op richt. B. Onjuist. De cyclus richt zich op continue verbetering en niet specifi ek op klantgerichtheid. C. Onjuist. Het model kan in de ontwerpfase worden gebruikt, maar de cyclus richt zich op continue

verbetering in alle fasen van het beheer van de dienstverlening. D. Onjuist. Kostenmodellen als onderdeel van budgeting & accounting kunnen dit doen.

Vraag 7Wat is de defi nitie van beschikbaarheid (availability)?

A. Een registratie die details bevat van confi guratie-items (CI’s) die betrokken zijn bij een geau-toriseerde wijziging en de wijze waarop deze daardoor beïnvloed worden.

B. Een snapshot van de status van een dienst of van een individuele confi guratie-item (CI) op een willekeurig moment.

C. Iedere gebeurtenis die niet onderdeel is van de standaardwerking van een dienst en die de oorzaak is, of zou kunnen zijn, van een onderbreking of vermindering in de kwaliteit van die dienst.



D. Het vermogen de vereiste functie van een component of IT-dienst binnen een vastgestelde interval of een vastgestelde tijdsduur uit te voeren.

A. Onjuist. Dit is de defi nitie van een wijzigingsregistratie (changerecord). B. Onjuist. Dit is de defi nitie van een ‘baseline’. C. Onjuist. Dit is de defi nitie van een incident. D. Juist. Dit is de defi nitie van beschikbaarheid (availability).

Vraag 8Nieuwe of gewijzigde diensten moeten worden geaccepteerd voordat deze in de productie omge-ving worden geïmplementeerd.

Wat moet er worden gedaan nadat een nieuwe of gewijzigde dienst is geïmplementeerd?

A. Een ‘post implementation review’ (PIR) waarin de werkelijke resultaten worden vergeleken met de geplande resultaten.

B. Er moet een benadering worden gekozen om te communiceren met projecten die een wijzi-ging op een bestaande service maken of nieuwe service maken.

C. Niets aanvullends: de nieuwe of gewijzigde dienst gaat over naar ‘business as usual’ en zal worden beheerd als een reguliere dienst.

D. Indien een wijziging niet succesvol is, zal er moeten worden vastgesteld wat de wijze is waarop de wijziging zal moeten worden teruggedraaid of aangepast.

A. Juist. Deze frase is opgenomen in de norm. B. Onjuist. Dit is onderdeel van de Plan-fase van ‘planning & implementing service management’ en

is niet van toepassing na de implementatie van nieuwe of gewijzigde diensten. C. Onjuist. Conform de norm is een PIR een noodzaak. Niets extra’s doen is geen optie. D. Onjuist. Deze frase is opgenomen onder changemanagement. Dit moet bovendien al zijn geregeld

voordat er geïmplementeerd gaat worden.

Vraag 9Wat is SixSigma®?

A. Het is een kwaliteitsinstrument om fouten in de output van een proces te meten.B. Het is een volwassenheidsmodel met zes stappen om te komen tot verbetering van de capabi-

lity van businessprocessen.C. Het is een standaard die recentelijk is ontwikkeld voor de verbetering van IT-processen.D. Het is een gestructureerde, op statistiek gebaseerde benadering voor procesverbetering.

A. Onjuist. Het is niet alleen een kwaliteitsinstrument, het omvat ook een verbeteringsmethodologie. B. Onjuist. Het is geen volwassenheidsmodel. C. Onjuist. Het is ontwikkeld in de jaren ’80 voor businessprocessen in het algemeen. D. Juist.



Vraag 10Wat is de doelstelling van de service continuity & availibility management processen?

A. Het bewerkstelligen van overeengekomen doeltreffende communicatie met klanten.B. Het bewerkstelligen dat verplichtingen tegenover de klant ten aanzien van overeengekomen

niveaus van dienstverlening in alle omstandigheden kunnen worden nagekomen.C. Het bewerkstelligen dat verplichtingen tegenover de klant ten aanzien van overeengekomen

continuïteit en beschikbaarheid van dienstverlening in alle omstandigheden kunnen worden nagekomen.

D. Het bewerkstelligen dat verplichtingen tegenover leveranciers ten aanzien van overeengeko-men continuïteit en beschikbaarheid van dienstverlening in alle omstandigheden kunnen worden nagekomen.

A. Onjuist. Doeltreffende communicatie is geen doelstelling van de processen service continuity & availability management. Het is wel relevant voor service reporting.

B. Onjuist. Het beheren van de dienstenniveaus is een doelstelling van het servicelevelmanagement-proces.

C. Juist. Dit is de doelstelling van de service continuity & availability management processen. D. Onjuist. service continuity & availability management zijn processen tussen een dienstverlener en

een klant, niet tussen een leverancier en een dienstverlener.

Vraag 11Het personeel behoort bekwaam te zijn gebaseerd op passende opleiding en ervaring.Welk van de volgende zaken is een best practice in relatie tot bekwaamheid?

A. Geschikte registraties van opleiding, training, vaardigheden en ervaring behoren te worden bijgehouden.

B. Ten minste twee medewerkers behoren passend getraind te zijn voor iedere rol.C. Medewerkers behoren minimaal een bachelorsdiploma te hebben.D. Personeel behoort getraind te zijn in beveiliging zoals vastgelegd in ISO/IEC 27002.

A. Juist. Dit is een best practice conform de norm. B. Onjuist. Dit is relevant voor de beschikbaarheid van mensen en middelen, echter geen best practice

voor bekwaamheid. C. Onjuist. Een bachelorsdiploma is geen vereiste, relevante training wel. D. Onjuist. Dit is een specifi eke training voor security, maar geen best practice voor bekwaamheid in

het algemeen.

Vraag 12Voor welk type organisaties is ISO/IEC 20000 van toepassing?

A. Voor organisaties als bevestiging dat alle ITIL®-richtlijnen zijn ingevoerd.B. Voor organisaties die alignment met klanteisen moeten aantonen.C. Voor organisaties die hun diensten wensen te certifi ceren.D. Voor tool-leveranciers om de dienstverleningsprocessen te specifi ceren.



A. Onjuist. ITIL® is veel uitgebreider dan ISO/IEC 20000 en daarom zal het geen bevestiging zijn dat alle aspecten van ITIL® zijn geïmplementeerd.

B. Juist. Dit wordt beschreven in de norm. C. Onjuist. Het is het managementsysteem dat wordt gecertifi ceerd en niet de diensten. D. Onjuist. Dienstverleners (en niet tool-leveranciers) specifi ceren hun processen op basis van ISO/IEC

20000 en ITIL®.

Vraag 13Welke details behoren te zijn geregistreerd in de vorm van een ‘baseline’ voordat het ‘service improvement plan’ (SIP) wordt geïmplementeerd?

A. achterstanden in de afhandeling van wijzigingen in de dienstverleningB. hoeveelheid betrokken personeelC. kwaliteit en niveaus van dienstverleningD. gebruikte tijd bij de uitvoering van het proces

A. Onjuist. Dit kan een van de maatregelen zijn als een achterstand in de afhandeling van wijzigin-gen teruggebracht moet worden, maar het kan ook om andere details gaan.

B. Onjuist. Dit kan een van de maatregelen zijn als de hoeveelheid personeel vergroot moet worden, maar het kan ook om andere details gaan.

C. Juist. De standaard beveelt het aan om service quality en baseline levels te verzamelen om langs deze weg verbeteringen te kunnen meten.

D. Onjuist. Dit kan een van de maatregelen zijn als de gebruikte tijd verbeterd moet worden, maar het kan ook om andere details gaan.

Vraag 14Waar zou een IT-dienst voor een klant normaliter worden vastgelegd?

A. in het IT-frameworkB. in de operational level agreement (OLA)C. in de dienstencatalogus of de service level agreement (SLA)D. in de servicerapportage

A. Onjuist. Het IT-framework geeft een structuur aan voor service management maar is geen vastleg-ging van IT-diensten zelf.

B. Onjuist. De OLA bepaalt een ondersteuningsregeling achter de primaire klantdienstverlening. C. Juist. Een dienstencatalogus of de SLA bepaalt de dienstverlening aan de klant. D. Onjuist. Servicerapportage geeft inhoudelijke details van de prestaties van de dienstverlening, maar

is geen vastlegging van de IT-dienst.

Vraag 15Waarom moeten dienstverleners documenten en registraties produceren?

A. Het is onderdeel van de vereisten (bewijsstukken) om naleving van ISO/IEC 20000 aan te kunnen tonen.



B. Omdat alle confi guratie-items (CI’s) uniek identifi ceerbaar moeten zijn en in de confi guration management database (CMDB) moeten zijn geregistreerd.

C. Om doeltreffende planning, exploitatie en besturing van service management te kunnen be-werkstelligen.

D. Om te bewerkstelligen dat medewerkers zich bewust zijn van de relevantie en het belang van hun activiteiten.

A. Onjuist. Het maken van documenten behoort nooit op zichzelf het doel te zijn van het naleven van ISO/IEC 20000.

B. Onjuist. Dit is onderdeel van confi guration management. C. Juist. Bij het aansturen van service management, zijn documenten en registraties nodig. Gevolg

hiervan is dat de dienstverlener moet bewijzen dat hij controle heeft over de dienstverlening. Het maken van documenten behoort nooit op zichzelf het doel te zijn van het naleven van ISO/IEC 20000.

D. Onjuist. Dit is onderdeel van bekwaamheid, bewustzijn en training en is irrelevant voor documen-tatie.

Vraag 16Wat wordt aanbevolen met betrekking tot de implementatie van een noodwijziging (emergency change)?

A. Alleen de senior manager behoort noodwijzigingen te autoriseren.B. Het wijzigingsproces behoort volledig omzeild te worden.C. Er is een apart proces voor noodwijzigingen.D. Waar mogelijk behoort het wijzigingsproces gevolgd te worden.

A. Onjuist. De autorisatie van noodwijzigingen (emergency changes) is onderdeel van het proces en er is geen aanbeveling t.a.v. degene die dit zou moeten doen.

B. Onjuist. Het wordt afgeraden om het hele proces te omzeilen, alhoewel sommige activiteiten kun-nen worden uitgesteld tot een later moment.

C. Onjuist. Er is een vereiste t.a.v. een afzonderlijk beleid voor noowijzigingen, maar geen aanbeve-ling voor een afzonderlijk proces.

D. Juist. Het wordt aanbevolen dat het wijzigingsproces gevolgd behoort te worden en activiteiten die worden omzeild behoren zo snel mogelijk alsnog uitgevoerd te worden.

Vraag 17Aan welk proces moet problemmanagement actuele informatie over bekende fouten en gecor-rigeerde problemen ter beschikking stellen?

A. Alle ISO/IEC 20000 processenB. AvailabilitymanagementC. Confi gurationmanagementD. Incidentmanagement



A. Onjuist. Conform de norm moet problemmanagement deze informatie beschikbaar stellen aan incidentmanagement, niet aan alle ISO/IEC processen.

B. Onjuist. Conform de norm moet problemmanagement deze informatie beschikbaar stellen aan incidentmanagement.

C. Onjuist. Conform de norm moet problemmanagement deze informatie beschikbaar stellen aan incidentmanagement.

D. Juist. Problemmanagement moet deze informatie beschikbaar stellen aan incidentmanagement, om Incident matching mogelijk te maken.

Vraag 18Waarom is een ‘scope statement’ voor ISO/IEC 20000 belangrijk?

A. Het bepaalt tegen welke eisen het managementsysteem is gecertifi ceerd.B. Het specifi ceert alle bedrijven die zijn gecertifi ceerd.C. Het specifi ceert alle diensten die zijn gecertifi ceerd.D. Het benoemd de processen die buiten de ‘scope’ zijn gelaten.

A. Juist. De ‘scope statement’ laat zien op welke eisen het managementsysteem was getest voor toeken-ning van het certifi caat.

B. Onjuist. Slechts één bedrijf kan een certifi caat toegekend krijgen (‘single legal entity’).C. Onjuist. Het is het managementsysteem dat wordt gecertifi ceerd, niet de diensten. D. Onjuist. Alle processen binnen de ‘scope’ (bereik) van de norm moeten zijn geaudit.

Vraag 19Doelen voor herstel van de dienstverlening behoren te worden gebaseerd op prioriteiten. Met welk van de onderstaande zaken behoort, bij het inplannen van de oplossing van incidenten of problemen, geen rekening te worden gehouden?

A. beschikbare vaardighedenB. strijdige eisen voor mensen en middelenC. inspanning/kosten om een herstelmethode te leverenD. aantal eerder gemelde incidenten voor het betreffende confi guratie-item (CI)

A. Onjuist. Dit is een relevant aspect bij het inplannen van herstel van een incident of probleem. B. Onjuist. Dit is een relevant aspect bij het inplannen van herstel van een incident of probleem. C. Onjuist. Dit is een relevant aspect bij het inplannen van herstel van een incident of probleem. D. Juist. Dit is niet relevant bij het inplannen van herstel. Het is relevant bij het identifi ceren van

problemen.

Vraag 20Wat is de juiste manier om een wijziging in een contract, resulterend in een omvangrijke evalu-atie van een geautoriseerd contract, te maken?A. door middel van het proces business relationship managementB.door middel van het proces changemanagementC.door middel van de klantvertegenwoordigerD.door middel van het proces supplier management



A. Onjuist. Het proces business relationship management is verantwoordelijk voor het organiseren van evaluatiebijeenkomsten voor de dienstverlening om wijzigingen in het bereik van de dienst-verlening, SLA’s, contracten e.d. te bespreken. Wijzigingen in een contract voortkomend uit deze besprekingen zullen middels het proces changemanagement worden afgehandeld.

B. Juist. Wijzigingen in een contract zullen middels het proces changemanagement worden afgehan-deld.

C. Onjuist. Deze vertegenwoordigers zullen middels andere processen hierbij betrokken worden (bijv. business relationship management).

D. Onjuist. Supplier management is verantwoordelijk voor het inregelen van een proces voor grote eva-luaties van een contract. Wijzigingen in een contract zullen middels het proces changemanagement worden afgehandeld.


Acroniemen

ACP Accredited Course ProviderANSI American National Standards InstituteAS Australian StandardBPM Business Process ModelingBS British StandardBSC Balanced ScorecardBSI British Standard InstitutionCAB Change Advisory BoardCAP Corrective Action PlanCCTA Central Computer and Telecommunications Agency

(British Government, now OGC)CEO Chief Executive Offi cerCFIA Component Failure Impact AnalysisCIO Chief Information Offi cerCI Confi guration ItemCISM Certifi ed Information Security ManagerCMDB Confi guration Management DatabaseCMM Capability Maturity ModelCMMI Capability Maturity Model IntegrationCobiT® Control Objectives for ITCPD Continual Professional DevelopmentCRAMM CCTA Risk Analysis and Management MethodCSI Continual Service ImprovementCSF Critical Success FactorCSS Customer Satisfaction SurveysDML Defi nitive Media LibraryDSL Defi nitive Software LibraryEA European co-operation for AccreditationEFQM European Foundation for Quality ManagementENAC Entidad Nacional de Acreditación (Spain)ESP External Service ProviderFISM Fellow of the Institute of Service ManagementFSC Forward Schedule of ChangeFTA Fault Tree AnalysisIAF International Accreditation Forum, Inc.IRCA International Register of Certifi cated AuditorsIS Information SystemIEC International Electrotechnical CommissionISACA Information Systems Audit and Control AssociationISO International Organization for StandardizationISM Institute of Service ManagementISMS Information Security Management SystemIT Information Technology



ITIL Information Technology Infrastructure LibraryITOCO Input-Throughput-Output-Control-OutcomeITSM IT Service ManagementITSCM IT service continuity managementitSMF IT Service Management ForumITT Invitation to TenderJAB The Japan Accreditation Board For Conformity AssessmentJQA Japanese Quality AssociationKPI Key Performance IndicatorMI Management InformationMISM Member of the Institute of Service ManagementMLA Multilateral Recognition ArrangementMOF Microsoft Operations FrameworkMTRS Mean Time to Restore ServiceNAB National Accreditation BodyOGC Offi ce of Government CommerceOLA Operational Level AgreementOSS Operational Support SystemPDCA Plan-Do-Check-ActPIR Post Implementation ReviewPRINCE2TM Projects In Controlled EnvironmentsQMS Quality Management SystemRAID Risks, Assumptions, Issues, DependenciesRCB Registered Certifi cation BodyRfC Request for ChangeRfP Request for ProposalROI Return on InvestmentRvA Raad voor AccreditatieSANS Institute SysAdmin, Audit, Network, Security InstituteSEI Software Engineering InstituteSIP Service Improvement ProgramSLA Service Level AgreementSLM Service Level ManagementSOA Service Outage AnalysisSOX Sarbanes-Oxley ActSPOF Single Points Of FailureSQM Service Quality ManagementTGA German Association for AccreditationTOP Technical Observation PostTQM Total Quality ManagementUC Underpinning ContractUKAS The United Kingdom Accreditation Service


Bronnen

Over ISO/IEC 20000• Bon, J. van (2006). ISO/IEC 20000, A Pocket Guide. Zaltbommel: Van Haren Publishing.• Bon, J. van (Ed.) (2008). ISO/IEC 20000, An Introduction. Zaltbommel: Van Haren Publi-

shing.• Dugmore, J., & S. Lacy (2006). BIP 0030:2006. Achieving ISO/IEC 20000. Management

decisions. London: BSI.• Dugmore, J., & S. Lacy (2006). BIP 0031:2006. Achieving ISO/IEC 20000. Why people mat-

ter. London: BSI. • Dugmore, J., & S. Lacy (2006). BIP 0032:2006. Achieving ISO/IEC 20000. Making metrics

work. London: BSI. • Dugmore, J., & S. Lacy (2006). BIP 0033:2006. Achieving ISO/IEC 20000. Managing end-to-

end service. London: BSI.• Dugmore, J., & S. Lacy (2006). BIP 0034:2006. Achieving ISO/IEC 20000. Finance for service

managers. London: BSI.• Dugmore, J., & S. Lacy (2006). BIP 0035:2006. Achieving ISO/IEC 20000. Enabling change.

London: BSI.• Dugmore, J., & S. Lacy (2006). BIP 0036:2006. Achieving ISO/IEC 20000. Keeping the service

going. London: BSI.• Dugmore, J., & S. Lacy (2006). BIP 0037:2006. Achieving ISO/IEC 20000. Capacity manage-

ment. London: BSI.• Dugmore, J., & S. Lacy (2006). BIP 0038:2006. Achieving ISO/IEC 20000. Integrated service

management. London: BSI.• Gartner Inc., 2006. G00136652, ISO/IEC 20000 Has an Important Role in Sourcing Ma-

nagement. Gartner.• ISO (2006). ISO 9000 and ISO 14000 - An Introduction. ISO. Verkrijgbaar bij: www.iso.org/

iso/en/iso9000-14000/index.html• ISO JTC 1/SC 7 (2005) ISO/IEC 20000-2 - Information technology - Service management

- Part 2: Code of practice. ISO.• ISO JTC 1/SC 7 (2005). ISO/IEC 20000-1 - Information technology - Service management

- Part 1: Specifi cation. ISO.• ISO TC 176/SC 1 (2000). ISO 9000:2000 - Quality management systems - Fundamentals

and vocabulary. ISO.• ISO TC 176/SC 2 (2000). ISO 9001:2000 - Quality Management Systems - Requirements.

ISO.• ISO (2001). Introduction and Support Package. Guidance on the Documentation Requirements

of iso 9001:2000. Document: ISO/TC 176/SC 2/N525R. Verkrijgbaar bij: www.iso.org/iso/en/iso9000-14000/explore/transition/2000rev7.html

• itSMF UK (2007). ISO/IEC 20000 Certifi cation web site. www.isoiec20000certifi cation.com/index.asp.

• McFarlane, I., & J. Dugmore (2006). BIP 0015:2006. IT service management. Self assessment workbook. 2nd edition. London: BSI.



• Page, D. (2006). Top 10 tips to achieve ISO 20000. Verkrijgbaar bij: www.nccmembership.co.uk/pooled/ar t ic le s /BF_WEBART/view.asp?Q=BF_

WEBART_212190• Read, D (2006). ISO/IEC 20000. Pitfalls of ISO/IEC 20000 certifi cation programmes. White

paper for PRO-ATTIVO.

Over de ISO 9000-familie• ISO (2006). Understand the basics. Verkrijgbaar bij: www.iso.org/iso/en/iso9000-14000/understand/index_one.html• ISO (2006). Explore further. Verkrijgbaar bij: www.iso.org/iso/en/iso9000-14000/explore/index_three.html• Tricker, Ray (2006). ISO 9001:2000 - The Quality Management Process. Zaltbommel: Van

Haren Publishing.

Over securitystandaarden• Calder, A. (2006). Information Security based on ISO 27001/ISO 17799; A Management Gui-

de. Zaltbommel: Van Haren Publishing.• ISO 17799:2005, Information technology - Security techniques - Code of practice for information

security management. (2005). Geneve: International Organization for Standardization.• ISO 27001:2005, Information technology - Security techniques - Information Security manage-

ment Systems - Requirements. (2005). Geneve: International Organization for Standardization

Over TQM• Bent, B.J. van der (2006). TQM - Total Quality Management. In J. van Bon (ed.) Frameworks

for IT Management. Zaltbommel: Van Haren Publishing.• Bent, B.J. van der (1999). Organisatieleren: een zoektocht naar de geheugendragers en de rol van

organisatiegeheugen in veranderingsprocessen. Rotterdam: Erasmus University.• Brassard, M. (Ed.) (1991). Memory jogger (tools for continual improvement). Salem, NH:

GOAL/QPC.• Conti, T. (1993). Building Total Quality. A guide for management. London: Chapman and

Hall.• Crosby, P.B. (1979). Quality is Free. New York: McGraw-Hill.• Deming, W.E. (1986). Out of the Crisis. Cambridge, MA: MIT Center for Advanced Enginee-

ring Study.• Deming, W.E. (1994, 2nd edition). The New Economics for Industry, Government, Education.

Cambridge, MA: MIT Center for Advanced Engineering Study.• Garvin, D. (1988). Managing Quality. The Strategic and Competitive Edge. New York: The Free

Press.• Hardjono, T, S. ten Have, & W. ten Have (1997). The European Way to Excellence. Brussels:

Directorate-Generale III Industry, European Commission.• Imai, M. (1986). Kaizen. The key to Japan’s competitive success. New York: Random House

Business Division.


Bronnen 227

• Juran, J. (1988). Juran on Planning for Quality. New York: The Free Press.• MacLeod, A., & L. Baxter (2001). The Contribution of Business Excellence Models in Resto-

ring Failed Improvement Initiatives. European Management Journal, Vol. 19, No. 4, 392-403.• Mulè, G. (2007). EFQM - European Foundation for Quality Management Excellence Model.

in J. van Bon (ed.) Frameworks for IT Management (second edition). Zaltbommel: Van Haren Publishing.

• March, A. (1996). A Note on Quality: The Views of Deming, Juran, and Crosby. IEEE Engi-neering Management Review, Vol. 24, No. 1, 6-14.

• Martin, P., & Tate, K. (1997). Project Management Memory jogger. Salem, NH: GOAL/QPC.• Nuland, Y. van, G. Broux, L. Crets, W. De Cleyn, J. Legrand, G. Majoor, & G. Vleminckx

(1999). Excellent: A guide for the implementation of the EFQM-Excellence model. Leuven: Co-matech.

• Peach, R.W., Peach, B., & Ritter, D.S. (2000). Memory jogger 9000/2000 (implementing ISO 9001). Salem, NH: GOAL/QPC.

• Ritter, D., & Brassard, M. (1998). The creative tools memory jogger (creative thinking). Salem, NH: GOAL/QPC.

• Wentink, T. (1999). Kwaliteitsmanagement en organisatieontwikkeling. Den Haag: Lemma.

Websites• www.iso.org International Organization for Standardization• www.bsi-global.com British Standard Institution• www.deming.org The W. Edwards Deming Institute®

• www.efqm.org European Foundation for Quality Management• www.ink.nl Instituut Nederlandse Kwaliteit• www.juran.com Juran Institute inc.• www.kaizen-institute.com Kaizen Institute• www.kdi.nl Schouten & Nelissen – KDI (Kwaliteit, Duurzaamheid en

Innovatie)• www.olkk.nl On-Line KwaliteitsKring• www.vck.be Vlaams Centrum voor Kwaliteitszorg

Certifi ceringsmogelijkheden• www.isoiec20000certifi cation.com informatie over itSMF UK ISO/IEC 20000-kwalifi caties• www.exin-exams.com informatie over EXIN ISO/IEC 20000-kwalifi caties• www.tuev-sued.de/it-zert informatie over TÜV SÜD ISO/IEC 20000-kwalifi caties• www.irca.org/certifi cation/certifi cation_12.html informatie over IRCA ISO/IEC 20000 kwalifi caties• www.afaq.org informatie over AFAQ ISO/IEC 20000 kwalifi caties (ICA)


229

Index

AAanvraagformulier . . . . . . . . . . . . . . . . . . .37Acceptatietestomgeving . . . . . . . . . .117, 119Accounting van fi nanciële assets . . . . . . . . .93Afsluiting van een service . . . . . . . . . . . . . .90Afwijking . . . . . . . . . . . . . . . . . . . . . . . . . .38Alignment . . . . . . . . . . . . . . . . . . . . . . . .150Assessment . . . . . . . . . . . . . . . . . . . . . . . . .29Asset . . . . . . . . . . . . . . . . . . . . . . . . .165, 184Auditcriteria . . . . . . . . . . . . . . . . . . . . . . . .83Auditor. . . . . . . . . . . . . . . . . . . . . . . . .39, 83Auditprogramma . . . . . . . . . . . . . . . . .37, 83Auditrapport . . . . . . . . . . . . . . . . .31, 38, 60

BBalanced scorecard . . . . . . . . . . . . . . . . . . .86Baseline . . . . . . . . . . . . . . . . . . .1, 30, 59, 87Bedrijfscertifi cering . . . . . . . . . . . . . . . . . .35Bedrijfseisen . . . . . . . . . . . . . . . . . . . . . . .177Beleid . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14Beleidsdocument . . . . . . . . . . . . . . . . . . . .60Benchmarken . . . . . . . . . . . . . . . . . . . . . . .32Benchmarking . . . . . . . . . . . . . . . . . . . . . .78Beschikbaarheid . . . . . . . . . .18, 59, 159, 171Beschikbaarheidsberekening . . . . . . . . . . .175Beschikbaarheidsmatrix . . . . . . . . . . . . . .174Beschikbaarheidsmonitoring . . . . . . . . . .160Beschikbaarheidsplan . . . . . . . . . . . .159, 174Betrokken partijen . . . . . . . . . . . . . . .7, 9, 10Bewijs . . . . . . . . . . . . . . . . . . . . . . .23, 56, 65Bewustwording. . . . . . . . . . . . . . . . . . .70, 72British Standard Institution (BSI) . . . . .35, 45BS 15000 . . . . . . . . . . . . . . . . . . . . . . .35, 45Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Budgettering . . . . . . . . . . . . . . . . . .139, 140Businessdrivers . . . . . . . . . . . . . . . . . . . . . .78

CCapability-assessment . . . . . . . . . . . . . . . . .30Capaciteit . . . . . . . . . . . . . . . . . . . . . . . . . .18Capaciteitsplan . . . . . . . . . . . . . . . . .177, 178Categorie . . . . . . . . . . . . . . . . . . . . .113, 207CCTA Risk Analysis and Management

Method (CRAMM) . . . . . . . . . .165, 175Certifi ceringsassessment . . . . . . . . . . . . . . .38Certifi ceringsaudit . . . . . . . . . . . . . . . . . . .38Certifi ceringsproces . . . . . . . . . . . . . . . . . .37Certifi ceringsprogramma . . . . . . . . . . . . .2, 3Change- en releaseplanning . . . . . . . . . . .108Changerecord . . . . . . . . . . . . . . . . . . . . . . .59Classifi catie . . . . . . .193, 195, 202, 204, 207CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Code of practice . . . . . . . . . . . . . . . .2, 52, 63Competent personeel . . . . . . . . . . . . . . . . .39Component . . . . . . . . . . . . . . . . . . .8, 16, 30Component Failure Impact Analysis

(CFIA) . . . . . . . . . . . . . . . . . . . . . . . .174Confi guratiecontrol . . . . . . . . . . . . . . .94, 95Confi guratiecontrolprocedures . . . . . . . . . .93Confi guratie-item (CI) . . . . . . . . . . . . .59, 93Confi guratiemanagementdatabase

(CMDB) . . . . . . . . . . . . . . . . . . . .60, 93Confi guratiemanagementrapport . . . . . . .107Confi guratierecord . . . . . . . . . . . . . . . .95, 96Confi guratie-uitgangspunt .93, 104, 119, 168Confi guratieverifi catie en audit . . . . . . . . . .96Consensus bedrijfstak . . . . . . . . . . . . . . . . .54Consistente benadering . . . . . . . . . .5, 52, 54Continual Service Improvement (CSI) . . . .50Continue serviceverbetering . . . . . . . . . . . .58Continue verbetering . . . . . .7, 11, 28, 51, 84Contract . . . . . . . . . . . . . . . . . . . . . . .60, 155Contractmanagement . . . . . . . . . . . .155, 156Contractueel geschil . . . . . . . . . . . . .154, 155



Control . . . . . . . . . . . . . . . . . . . . . . . .27, 35Controlactiviteit . . . . . . . . . . . . . . . . . . . . .26Corrective Action Plan (CAP) . . . . . . . . . .38

DDeelprocesComponent . . . . . . . . . . . . . . . .20Defi nitive Software Library (DSL) . . . . . .106Deming . . . . . . . . . . . . . . . . . . . . . . . . .6, 50Digitale confi guratie-items . . . . . . . . . . . . .93DISC PD 0005 . . . . . . . . . . . . . . . . . . . . .44Distributie . . . . . . . . . . . . . . . . . . . .117, 120Document . . . . . . . . . . . . . . . .54, 56, 60, 67Documentatie . . . . . . . . . . . . . . . . . . .54, 56Documentatierichtlijnen . . . . . . . . . . . . . .51Doorvoer . . . . . . . . . . . . . . . . . . . . . . . . . .27Draagkracht management . . . . . . . . . . . . .66

EEffectiviteit . . . . . . . . . . . . . . . . . . . . . . . . .27Effi ciëntie . . . . . . . . . . . . . . . . . . . . . . . . . .27Elektronische bibliotheek . . . . . . . . . . . . . .93Emergency change . . . . . . . . . . . . . .109, 117Emergency release . . . . . . . . . . . . . . . . . .117Escalatie . . . . . . . . . . . . . .155, 195, 199, 202Evaluatie. . . . . . . . . . . . . . . . . . . . . . . . . . .31EXIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42Externe audit . . . . . . . . . . . . . . . . . . . . . .191Externe auditor . . . . . . . . . . . . . . . . . . . .191Externe change . . . . . . . . . . . . . . . . . . . . .177

FFault Tree Analysis (FTA) . . . . . . . . . . . . .174Feitengebaseerde aanpak van

besluitvorming . . . . . . . . . . . . . . . . . . .12Financiële middelen . . . . . . . . . . . . . . . . . .90Formele afsluiting . . . . . . . . . . . . . . .193, 195Forward Schedule of Change (FSC) . . . . .113Foutenrecord . . . . . . . . . . . . . . . . . . . . . . .96Framework-neutraal . . . . . . . . . . . . . . . . . . .1

GGap-assessment . . . . . . . . . . . . . . . . . .78, 81Gebreken . . . . . . . . . . . . . . . . . . . . . .96, 109Gebruiker . . . . . . . . . . . . . . . . . . . . . . .9, 150Geïntegreerde procesaanpak . . . . . . . . .10, 52Gemeenschappelijke terminologie . . . .51, 54Gewenste resultaten . . . . . . . . . . . .13, 14, 81

Governance . . . . . . . . . . . . . . . . . . . . . . . .33

HHerstel . . . . . . . . . . . . . . . . . . . . . . .161, 166Herstelactiviteit . . . . . . . . . . . . . . . . . . . . .83Hoofdleverancier . . . . . . . . . . .136, 154, 155

IImpact . . . . . . . . . . .113, 192, 193, 199, 207Incident . . . . . . . . . . . . . . . . . . . . . . . . . .193Incidentoplossing . . . . . . . . . . . . . . . . . . .192Individuele certifi cering . . . . . . . . . . . . . . .38Informatiesecuritybeleid . . . . . . . . . .183, 185Information Technology Infrastructure

Library (ITIL) . . . . . . . . . . . . . . . . . . .46Initiële assessment . . . . . . . . . . . . . . .38, 111Initiële audit . . . . . . . . . . . . . . . . . . . . . . . .37Input . . . . . . . . . . . . . . . . . . . . . . . . . .10, 27Installatie . . . . . . . . . . . . . . . . . . . . .117, 120Instelbaarheid . . . . . . . . . . . . . . . . . . . . . . .18International Accredition Forum (IAF) . . .35International Organization for

Standardization (ISO) . . . . . . . . . . . . . .51International Register of Certifi cated

Auditors (IRCA) . . . . . . . . . . . . . . . . . .42Interne assessment . . . . . . . . . . . . . . . . . . .37Interne audit . . . . . . . . . . . . . . . . . .191, 192Interne auditor . . . . . . . . . . . . . . . . . . . . .191ISO 9000 . . . . . . . . . . . . . . . . . . .5, 8, 46, 51 2005 . . . . . . . . . . . . . . . . . . . . . . . . . . . .14ISO 9001 2000 . . . . . . . . . . . . . . . . . . . . . . . . . .7, 51ISO 9004 . . . . . . . . . . . . . . . . . . . . . . . . . .51ISO 15540 . . . . . . . . . . . . . . . . . . . . . . . . .33ISO/IEC 17799 . . . . . . . . . . . . . . . .183, 189ISO/IEC 20000 . . . . . . . . . . . .33, 44, 45, 51ISO/IEC 20000-1 specifi catie . . . . . . . . . . .2ISO/IEC 20000-2 specifi catie . . . . . . . . . . .2ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . .34IT Infrastructure Library (ITIL) . . . .7, 34, 45IT-manager . . . . . . . . . . . . . . . . . . . . . . . .39ITOCO-model . . . . . . . . . . . . . . . . . . . . . .26IT-service . . . . . . . . . . . . . . . . . . . . . . . . . .16IT-servicemanagement (ITSM) . . . . . . . . .21IT-servicemanagementsysteem . . . . . . . . . .21itSMF-UK . . . . . . . . . . . . . . . . . . . . . .42, 45


Index 231

KKey performance indicator (KPI) .84, 86, 133Klachtdefi nitie . . . . . . . . . . . . . . . . . . . . .149Klachtenmanagement . . . . . . . . . . . . . . . .150Klachtenprocedure . . . . . . . . . . . . . . . . . .149Klachtenproces . . . . . . . . . . . . . . . . . . . . .149Klant . . . . . . . . . . . . . . . . . . . . . . . . . .9, 150Klantbehoefte . . . . . . . . . . . . . . . . . . . . .9, 14Klanteis . . . . . . . . . . . . . . .8, 14, 19, 65, 150Klantgericht . . . . . . . . . . . . . . . . . . . . . . . . .5Klantgerichtheid . . . . . . . . . . . . . . . . . .8, 147Klanttevredenheid . . . .51, 67, 128, 149, 150Klanttevredenheidsonderzoek . . . . . . . . . .153Klantverwachting . . . . . . . . . . . . . . . . . .9, 14Known error . . . . . . . . . . . . . . . . . . .202, 204Kritieke succesfactor (CSF) . . . . . . . . . . . .86Kwaliteitsbeleid . . . . . . . . . . . . . . . . . .31, 87Kwaliteitsdoelstelling . . . . . . . . . . . . . .14, 31Kwaliteitsmanagementsysteem . . . . . . .14, 31Kwaliteitsnorm . . . . . . . . . . . . . . . . . . . . . .54Kwaliteitsperceptie . . . . . . . . . . . . . . . . . . .19

LLeverancier . . . . . . . . . . . . . . . . . . . . . . . .154Leverancierscontract . . . . . . . . . . . . .126, 155

MManagementsysteem . . . . . . . . . . . . . . . . . .7Mean Time to Restore Service (MTRS) . .174Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . .84Modelling. . . . . . . . . . . . . . . . . . . . . . . . .180Monitor . . . . . . . . . . . . . .10, 50, 72, 83, 209Multilateral Recognition

Arrangement (MLA) . . . . . . . . . . . . . . .35

NNational Accreditation Body (NAB). . . . . .35

OObjectiviteit . . . . . . . . . . . . . . . . . . . . . . . .83Onpartijdigheid . . . . . . . . . . . . . . . . . .41, 83Operational Level Agreement (OLA) . . . .133Originele versie . . . . . . . . . . . . . . . . . . . . .93Output . . . . . . . . . . . . . . . . . . . . . . . . .10, 27Overdraagbaarheid . . . . . . . . . . . . . . . . . . .18

PPDCA-cyclus . . . . . . . . . . . . . . . . . . . . .6, 50Performance . . . . . . . . . . . . . . . . . . . . .18, 51Planningsschema . . . . . . . . . . . . . . . . . . . .76Post implementation review (PIR) 86, 90, 115Pre-audit . . . . . . . . . . . . . . . . . . . . . . . . . .37Prioriteit . . . . . . . . . .113, 192, 193, 199, 208Proactief rapport . . . . . . . . . . . . . . . . . . .136Proactieve vaststelling . . . . . . . . . . . . . . . .201Problem . . . . . . . . . . . . . . . . . . . . . . .60, 201Problemoplossing . . . . . . . . . . . . . . .192, 202Problemreview . . . . . . . . . . . . . . . . . . . . .203Procedure . . . . . . . . . . . . . . . . .55, 56, 60, 67Proces . . . . . . . . . . . . . . . . . . . . . . . . . .10, 25Procesbeschrijving . . . . . . . . . . . . . . . .17, 54Proceseigenaar . . . . . . . . . . . . . . . . . . . . . .27Procesgebaseerde kwaliteitsmanagement-

systeem . . . . . . . . . . . . . . . . . . . . . . . . .10Proceskoppelingen . . . . . . . . . . . . . . . . . . .72Procesmanager . . . . . . . . . . . . . . . . . . . . . .27Procesuitvoerder . . . . . . . . . . . . . . . . . . . . .27

QQuick wins . . . . . . . . . . . . . . . . . . . . . . . . .79

RReactief rapport . . . . . . . . . . . . . . . . . . . .136Re-certifi ceringsaudit . . . . . . . . . . . . . . . . .38Record . . . . . . . . . . . . . . . .54, 56, 57, 60, 67Registered Certifi cation Body (RCB) . . .2, 35Release . . . . . . . . . . . . . . . . . . . .60, 116, 122Releasebeleid . . . . . . . . . .116, 117, 120, 122Releasecontrol . . . . . . . . . . . . . . . . . . . . .122Release- en uitrolplan . . . .116, 118, 119, 125Releaseverifi catie- en acceptatie . . . . . . . .119Request for change (RfC) . . . . . .60, 111, 122Resources . . . . . . . . . . . . . . . . . . . . . . .54, 63Richtlijnen . . . . . . . . . . . . . . . . . . . . . . . . .52Risicoanalyse . . . . . . . . . . . . . .159, 160, 164Risicobeperking . . . . . . . . . . . . . . . . . . . .161Rol . . . . . . . . . . . . . . . . . . . . . . . . .27, 42, 76

SSchaalbaarheid . . . . . . . . . . . . . . . . . . . . . .18Scope . . . . . . . . . . . . . . . . . . . . . . .36, 75, 83Scopeverklaring . . . . . . . . . . . . . . . . . . . . .36



Security . . . . . . . . . . . . . . . . . . . . . . . . . . .18Securitycontrol . . . . . . . . . . . . . . . . . . . . .183Securityrisicoanalyse . . . . . . . . . . . . . . . . .184Self-assessment . . . . . . . . . . . . . . . . . .31, 191Senior verantwoordelijke eigenaar . . . .56, 65Servicecatalogus . . . . . . . . . . . .127, 132, 133Servicecontinuïteitsplan . . . . . . . . . .159, 161Servicecontinuïteitstrategie . . . . . . . . . . . .160Servicedefi nitie . . . . . . . . . . . . . . . . . . . . .155Servicedesk . . . . . . . . . . . . . . . . . . . . .61, 199Service Improvement Plan (SIP) . . . . . .38, 73Servicekwaliteitsmanagement . . . . . . . . . .1, 7Servicekwaliteitsplan . . . . . . . . . . . . . . . .133Service level agreement (SLA) 29, 61, 133, 151Service Level Agreement (SLA) . . . . . . . . . .56Service level agreements (SLAs) . . . . . . . .126Serviceleveltarget . . . . . . . . . . . . . . . . . . .126Servicemanagement . . . . . . . . . . . . . . . . . .61Servicemanagementbeleid . . . . . . . . . . .65, 66Servicemanagementeisen . . . . . . . . . . . . . .83Servicemanagementplan . . . . . . . . .65, 75, 76Servicemanagementplanning . . . . . . . . . . .67Servicemanagementreview . . . . . . . . . .67, 83Servicemanagementsysteem . . . . . . . . . . . . .2Service Outage Analysis (SOA) . . . . . . . . .175Serviceprovider . . . . . . . . . . . . . . . . . . . . . .61Servicerapport . . . . . . . . . . . . . . . . .135, 136Service request . . . . . . . . . . . . . . . . .111, 199Servicereview . . . . . . . . . . . . . . . . . .147, 149Serviceverbeteringsbeleid . . . . . . . . . . . . . .86Serviceverbeteringstargets . . . . . . . . . . . . . .88Set activiteiten . . . . . . . . . . . . . . . . . . .10, 25Six Sigma . . . . . . . . . . . . . . . . . . . . . . . . . .34Specifi catie . . . . . . . . . . . . . . . . . . . . . . . . .52Stakeholder . . . . . . . . . . . . . . . . . . . . . . . .34Status . . . . . . . . . . . . . . . . . . . . . . . . . . . .208Subleverancier . . . . . . . . . . . . . . . . . . . . .154Surveillance-audit . . . . . . . . . . . . . . . . . . . .38

TTechnical Observation Post (TOP) . . . . . .175Terugvalplan . . . . . . . . . . . . . . . . . . .116, 124Terugvalprocedure . . . . . . . . . . . . . . . . . .114Testplan . . . . . . . . . . . . . . . . . . . . . . . . . .124Toepasbaarheid . . . . . . . . . . . . . . . . . . . . . .35Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23Traceerbaarheid . . . . . . . . . . . . . . . . . . . . .95Tracking . . . . . . . . . . . . . . . . . . . . . .202, 209Trendanalyse . . . . . . . . . . . . . . . . . . .86, 207TÜV SÜD . . . . . . . . . . . . . . . . . . . . . . . . .42

UUitgangspunt . . . . . . . . . . . . . . . . . . . . . . .30Uitkomst . . . . . . . . . . . . . . . . . . . . . . . . . .27Underpinning contract (UC) . . . . . . . . . .133Urgentie . . . . . . . . . . . . . .192, 193, 199, 207

VVerantwoordelijkheid . . . . .27, 56, 67, 73, 76Verpakking . . . . . . . . . . . . . . . . . . . . . . . .117Verplichte controls . . . . . . . . . . . . . . . . . . .52Vertrouwelijkheid . . . . . . . . . . . . . . . . . . . .18Volwassenheidsassessment . . . . . . . . . . . . .30Volwassenheidsmodel . . . . . . . . . . . . . .28, 78Volwassenheidsniveau . . . . . . . . . . . . . . . . .28Vragenlijst . . . . . . . . . . . . . . . . . . . . . . . . .37

WWederzijds voordelige leveranciersrelaties . .13Werkinstructie . . . . . . . . . . . . . . . . . . . . . .17Werklastgrens . . . . . . . . . . . . . . . . . . . . . .128Werklastkenmerk . . . . . . . . . . . . . . .126, 181Workfl ow . . . . . . . . . . . . . . . . . . . . . . . . . .26


isoiec 20000_nodrm

Documents

van druk

online webwinkel van

gekoppeld aan iso en

standardization en iec

management topics en

iso jtc

iso directives

een introductie copyright