NL ISM Procesmodel 19082021 D

Het ISM-procesmodel
Versie 2021
ISM-procesmodel
Voorwoord
In dit document treft u het uitgewerkte ISM-
procesmodel aan. Dit model is een onderdeel van de
ISM-methode.
De ISM-methode helpt service-organisaties op

eenvoudige wijze het nuttige uit ITIL, BiSL en DevOps,
maar ook Lean, Toc, Scrum en OBM toepasbaar te
krijgen.
ISM wordt veel toegepast in de IT-dienstverlening,

maar is ook geschikt voor dienstverlening op het
gebied van facilitair, HRM en medische technologie.
De ISM-methode bestaat uit 3 kern-onderdelen:

- Framework - de inrichting van de werkwijze van een serviceorganisatie
- Invoering - methoden om het framework in te voeren en door te groeien
- Support - hulpmiddelen bij het invoeren en toepassen van ISM
Deze drie onderdelen, en alle concepten, producten en diensten daarbinnen, vormen
samen één geïntegreerd eco-systeem. Het ISM-procesmodel is één van de onderdelen uit
het framework van de ISM-methode.
Alles in de ISM-methode is gericht op het creëren van klantwaarde, Customer Value,

door het realiseren van diensten die de klant nodig heeft. Essentieel daarbij is dat alle
betrokkenen in de serviceorganisatie als één geoliede machine samenwerken.
Dat lukt alleen als de samenwerking goed, toepasbaar en compact is georganiseerd. Een
volledig procesmodel is daarvoor een randvoorwaarde. Daarbij moet het procesmodel
holistisch alles afdekken om te voorkomen dat naast het procesmodel andere werkwijzen
nodig zijn die overlappen en verwarring of strijd gaan opleveren.
Dit betekent ook dat het ISM-procesmodel alle activiteiten beschrijft in het technische,
functionele én klantdomein. Van opdrachtgeving en aansturing door de klant via
functioneel beheer naar technisch beheer om systemen te bouwen en te beheren naar
functioneel support en vervolgens de toepassing door de (eind-)gebruiker. De service-
organisatie is dan ook virtueel en bestaat uit de klant, de (IT-)serviceafdeling en derde
partijen die ingezet worden.
Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 2 van 82

ISM-procesmodel
In slechts 6 processen, die elkaar versterken, zijn alle activiteiten op tactisch en

operationeel niveau beschreven. Zo ontstaat niet alleen een complete, maar vooral een
eenvoudig toepasbare én aanstuurbare werkwijze. De activiteiten in processen en
valuestreams vormen samen het ISM-operatingmodel.
Al meer dan 200 organisaties gebruiken het ISM-model om hun werkwijze aan te sturen.
Het model maakt onderdeel uit van het ISM-ecosysteem. Een groot aantal op elkaar
afgestemde diensten en producten zijn hierin opgenomen zoals:
• Besturingsmodel
Een praktisch model om de werkwijze aan te sturen en gezamenlijk de gestelde
doelen te halen
• Trainingen en games
Vele varianten om theorie en praktijkervaring op te doen in het toepassen
• Rapportages en dashboards
Direct inzicht in waar er knelpunten zitten om de doorstroming(flow) te versnellen
• Klanttevredenheidsonderzoeken
Snel inzicht in hoe de interne samenwerking of dienstverlening door de klant
ervaren wordt
• Scans
Snel inzicht in wat nu de grootste knelpunten zijn
• Coaching en begeleiding
Ondersteuning door ervaren medewerkers om sneller geborgd resultaat te
behalen
• Compliancy-integratie
Het voldoen aan compliancy opnemen in de werkwijze op basis van een
uitgewerkte lijst met activiteiten per proces
• Et cetera.
De ideeën en concepten van de ISM-methode, zoals deze procesmodel-beschrijving, zijn

met bronvermelding vrij door iedereen te gebruiken. Daarnaast zijn er een groot aantal
diensten en producten beschikbaar, deze worden geleverd door de ISM-partners.
Wij vertrouwen erop dat het procesmodel helpt uw werkwijze en dienstverlening verder
te professionaliseren. Wij staan voor u klaar om eventuele vragen te beantwoorden of u
op een andere manier te ondersteunen.
Namens Servitect,
Wim Hoving
Hoofdontwikkelaar ISM-methode

ISM-procesmodel

ISM-procesmodel
Inhoud
Het ISM-procesmodel is een onderdeel uit de ISM-methode en beschrijft op tactisch en
operationeel niveau de inrichting van de basisprocessen voor de uitvoering van de
dienstverlening. (We gebruiken voor IT-dienstverlening bewust de meer gebruikelijke
term IT, hoewel IV (Informatie Voorziening) formeel een adequatere term is.)
Het doel van dienstverlening is het conform afspraak, en in samenwerking met de klant,
leveren van services om de primaire bedrijfsprocessen te ondersteunen. Services zijn in
deze bedrijfsproces ondersteunende diensten zoals IT, facilitaire diensten en Medisch
technologische diensten.
Services zijn voor de klant alleen waardevol als het uiteindelijke resultaat goed werkt:
daarom zijn de inspanningen van beheer gericht op de integrale operationele omgeving.
De operationele omgeving omvat alle bedrijfsmiddelen die gebruikt worden om de dienst
te kunnen leveren. Beheer houdt zich om die reden bezig met alle componenten van die
omgeving.
Meer informatie: http://www.ismportal.nl
De positie van het ISM-procesmodel ................................................... 6

Het ISM-procesmodel...................................................................... 11
Service Level Management .............................................................. 13
Improvement management ............................................................. 24
Change management ...................................................................... 35
Incident management ..................................................................... 54
Knowledge management ................................................................. 66
Operations management ................................................................. 76

ISM-procesmodel
De positie van het ISM-procesmodel

Het ISM-procesmodel kent een structuur waarin de bedrijfsdoelstelling bepalend is voor
de servicebehoefte van de business, deze servicebehoefte wordt door functioneel beheer
gespecificeerd, op basis waarvan services worden gerealiseerd door technisch beheer.
In eerdere versies van ISM werd ISM beperkt tot het vakgebied Technisch Beheer, en
voor het vakgebied Functioneel Beheer werd Functional Service Management (FSM)
toegepast.
De groeiende behoefte om de inzet van de klant, functioneel beheer en technisch beheer

beter op elkaar te laten aansluiten heeft in het vakgebied IT Service Management geleidt
tot een verbrede scoop en één geïntegreerde oplossing waarin de werkwijze die leidt tot
het realiseren van IT-diensten met één procesmodel wordt afgedekt, Co-creation.
Organisaties die uitsluitende het functioneel beheer willen organiseren kunnen nog steeds
FSM voor dit doel gebruiken.
De business stuurt functioneel beheer aan, en functioneel beheer stuurt op haar beurt
technisch beheer aan. Vanuit het perspectief van technisch beheer zal functioneel beheer
dan ook vaak optreden als vertegenwoordiger van de business en als klant worden
beschouwd. In organisatorische zin zien we in de praktijk vaak dat functioneel beheer
binnen de business valt, en dat technisch beheer door een separate afdeling wordt
uitgevoerd, of (deels) geoutsourcet is.
Het is belangrijk om te beseffen dat diensten tot stand komen in nauwe en continue
samenwerking tussen de Business, Functioneel en Technisch Beheer, waarbij het niet van

ISM-procesmodel
belang is of deze inzet intern of extern wordt gerealiseerd. De serviceorganisatie is dus

groter dan de serviceafdeling. Het ISM-procesmodel beschrijft de werking van de gehele
serviceorganisatie.
Het is voor een klant bij een verstoring van een service niet relevant welk onderdeel van
een service faalt, een klant wil een integrale levering. ISM definieert een service dan ook
als “het leveren van functionerende functionaliteit”, oftewel de service moet de gebruiker
in staat stellen zijn werk te ondersteunen tegen eisen die afgesproken zijn.
Het Doel
Het doel van het ISM-procesmodel is het op eenvoudige wijze weergeven van het domein
van elk proces, en hoe de verschillende processen elkaar triggeren. Het gaat om een
model en dus om een versimpeling van de werkelijkheid.
“All models are wrong, some are useful”
Dit betekent dat niet alle mogelijke details van de werking van alle processen in het
model zijn terug te vinden. Alleen die zaken die van elementair belang zijn voor de
samenhang van de kernprocessen van een serviceorganisatie zijn expliciet beschreven.
De details komen aan de orde in de onderliggende proces- en activiteitenbeschrijvingen.
Zo zijn bijvoorbeeld in het model alleen de activerende relaties door pijlen aangegeven,
en niet de vele onderlinge informatie-uitwisselingstromen.
Bij het beschrijven van het procesmodel zijn de volgende criteria toegepast:
• Het model is onafhankelijk van de organisatie-inrichting.
• Het model is onafhankelijk van de verschillende services die geleverd worden.
• Het model is onafhankelijk van de gebruikte technieken.
• Het model borgt dat processen elkaar controleren.
• Voor eenzelfde serie opeenvolgende activiteiten is slecht één proces ingericht.
• Er is gestreefd naar maximale zuiverheid, activiteiten komen slechts één keer voor in
het procesmodel.
• De toelichtende omschrijvingen in het procesmodel zijn gebaseerd op een
organisatie-inrichting volgens variant 4 van de procesmanagementmatrix. In deze
matrix wordt beschreven op welke verschillende manieren de tussen lijn- en
procesmanagement georganiseerd kan worden.
De processen in het ISM-procesmodel kunnen algemeen in werkwoorden worden

beschreven. Afhankelijk van het vakgebied kunnen vakgerichte procesnamen
gedefinieerd worden. In deze beschrijving worden de Engelstalige, IT-gerelateerde
procesnamen gebruikt.

ISM-procesmodel
De processen zijn verantwoordelijk voor het organiseren van de werkwijze, ieder voor
zijn eigen doel:
1. Service Level Management – het maken, aansturen en onderhouden van
afspraken over de dienstverlening tussen de klant, de IT-afdeling en de
toeleveranciers
2. Change Management – het specificeren en doorvoeren van aanpassing op de
dienstverlening
3. Operations Management – het coördineren en aansturen van de handelingen aan
het informatiesysteem
4. Incident Management – het herstellen van de dienstverlening
5. Knowledge management – het beschikbaar stellen van informatie ten behoeve
van de IT-dienstverlening
6. Improvement Management – het optimaliseren van de dienstverlening door het
wegnemen van technische en organisatorische onvolkomenheden.
In het procesmodel zijn voor de 6 basisprocessen een groot aantal activiteiten

beschreven, dit wil niet zeggen dat deze activiteiten ook allemaal verplicht zijn. De keuze
welke activiteiten aanbevolen of verplicht zijn is onderdeel van het ISM-besturingsmodel.
(In 2021 is een ook uitgebreide versie van het procesmodel ontwikkeld waarin ook het
strategische proces “Positioneren” is toegevoegd. De Engelstalige naam voor het proces
is “Strategy Management”. Het doel van Strategy Management is het opstellen,
aansturen en realiseren van doelstellingen en beleid.)
Enterprise Service Management

Het ISM-procesmodel kent van oudsher een universele opbouw, dat betekent dat de
wijze waarop de processen zijn beschreven toepasbaar zijn voor de IT-dienstverlening,
en hier ligt ook de oorsprong, maar ook zeer goed bruikbaar zijn voor Facilitair
Management, HRM of bijvoorbeeld Medische Technologie.
In de uitwerking van het procesmodel is de procesbeschrijving zoveel mogelijk universeel

van aard, met voorbeelden vanuit de IT, facilitair, MT en HRM.

ISM-procesmodel
Het ISM-operatingmodel
Het ISM-procesmodel maakt deel uit van het ISM-operatingmodel.
Het gehele Operatingmodel bestaat uit de productiemiddelen:

- People – de beschrijving van de rollen:
o De professional – de vakman die door zijn handelingen diensten realiseert
o De eindgebruiker – de medewerker aan de klantzijde die de dienst gebruikt
- Proces – de beschrijving van de handelingen die moeten plaatsvinden
o Het ISM-procesmodel
o De beschrijving van de uit processen opgebouwde valuestreams
- Product –
o De inrichting van de IT Service Management tooling voor tools als
Topdesk, Ultimo, Clientele en (binnenkort) ServiceNow
o Dashboards en rapportages
Het operatingmodel omvat al het operationele dat leidt tot het creëren van diensten.
Het uitgangspunt van het Operatingmodel is dat Customer Value ontstaat door de
klantwaardering van diensten die het gevolg zijn van acties die door professionals
worden uitgevoerd om de in SxLA’s vastgelegde klantverwachting te realiseren.
Het ISM-procesmodel is een gedetailleerde uitwerking van de acties en processen uit het
ISM-operatingmodel.
Het ISM-operatingmodel is beschreven in presentaties, webinars, artikelen en blogs en in

het nieuw te verschijnen ISM-boek.
Het in dit artikel opgenomen ISM-procesmodel organiseert de acties in processen en in

het procesmodel.

ISM-procesmodel
Het ISM-besturingsmodel
Naast het Operatingmodel in het ook van belang om de aansturing van de Operating in te
richten. Dit gebeurt met het ISM-besturingsmodel:
Het ISM-besturingsmodel organiseert de aansturing van de operating door de

verschillende leidinggevende rollen. Deze rollen komen in iedere serviceorganisatie voor.
In grotere organisaties zijn dit soms functies, in kleinere kunnen ze terecht komen bij
een klein aantal leidinggevende functionarissen.
Iedere leidinggevende rol is verantwoordelijk voor het realiseren van een specifiek deel
van de overeengekomen serviceprestatie, afgeleid van de doelstelling van de
serviceorganisatie.
De eindverantwoordelijkheid voor de serviceprestatie, maar ook voor de teams met

daarin de professionals en voor de processen en valuestreams, en voor de werkwijze,
met daarin de processen en valuestreams, ligt altijd op het hoogste managementniveau
in de serviceorganisatie.
Dashboards
Voor succesvolle resultaatgerichte besturing is de beschikking over actuele informatie
over de serviceprestatie, de werking van de teams en de processen essentieel, de inzet
van BI-dashboards is daarbij een krachtig hulpmiddel
Het ISM-besturingsmodel is beschreven in presentaties, webinars, artikelen en blogs en

in het nieuw te verschijnen ISM-boek.

ISM-procesmodel
Het ISM-procesmodel
Procescontrol
Bij het beschrijven van procescontrol voor de verschillende processen is uitgegaan van
de bevoegdheid van procescontrol conform PMM4 (Proces Management Matrix):
• om zich te informeren over de voortgang;
• om uitvoerders van procesactiviteiten te informeren over afwijkingen in de
procesuitvoering of -voortgang;
• om procesuitvoerders te motiveren om afwijkingen in de procesuitvoering of
voortgang te corrigeren
• om te escaleren als een uitvoerder zijn werkwijze niet kan of wil aanpassen aan de
vastgestelde procesinrichting of -voortgang.
DOEL Het bewaken en bijsturen van de correcte afhandeling van het proces
INPUT De procesbeschrijving, de actuele servicenormen, en alle andere relevante informatie
OUTPUT Een correct uitgevoerd proces, waarbij tijdig en adequaat is ingegrepen bij (dreigende)
afwijkingen van de vastgestelde werkwijze
TOELICHTING Een correct uitgevoerd proces betekent dat het proces wordt uitgevoerd:
• conform de procesbeschrijving en werkinstructie
• conform de SLA-normen (tijdig, juist, volledig en geautoriseerd)
• op basis van actuele informatie
Procescontrol informeert zich over de wijze waarop serviceaanvragen worden afgehandeld.

Informatie kan afkomstig zijn uit de callregistratie, van degenen die een rol hebben in het
proces, of van derden. Ook kan procescontrol zich laten informeren door middel van alerts
van monitoring- en servicemanagementtools.
Indien nodig informeert procescontrol de call-eigenaars en verantwoordelijken over

(dreigende) afwijking van gemaakte service- en/of procesafspraken. Procescontrol kan geen
opdrachten geven aan de call-eigenaar. Als het informeren van de Call-eigenaar niet leidt tot
aanpassingen, waardoor de afspraak alsnog zo goed mogelijk wordt nagekomen, kan proces
control besluiten te escaleren naar het lijnmanagement.
Bewaken procesuitvoering
DOEL Borgen dat het proces zijn doelstellingen realiseert door het bewaken van de correcte en
tijdige uitvoering van de procesactiviteiten en het genereren van stuurinformatie
INPUT De procesbeschrijving, de procedurebeschrijving en actuele servicenormen
OUTPUT Informatie uit en over de procesactiviteiten
TOELICHTING Door de uitvoering van het proces te monitoren, wordt informatie verzameld die het mogelijk
maakt de uitvoering van het proces bij te sturen. De verzamelde informatie wordt ook
gebruikt om de procesrapportage op te stellen.

ISM-procesmodel
Bijsturen procesuitvoering
DOEL Het realiseren van een correcte procesuitvoering door tijdig bij te sturen
INPUT Informatie uit en over de procesactiviteiten
OUTPUT Procesuitvoering conform de doelstellingen van het proces
TOELICHTING De uitvoering van de procesactiviteiten kan op de volgende wijze worden bijgestuurd:
• door het informeren van de uitvoerder van de procesactiviteiten dat de door hem
uitgevoerde activiteiten niet conform de doelstellingen van het proces worden uitgevoerd
• door het informeren van de lijnmanager van de uitvoerder van de activiteiten dat de
activiteiten die door zijn medewerker worden uitgevoerd niet conform de doelstellingen
van het proces worden uitgevoerd
Rapporteren procesuitvoering
DOEL Het opstellen van procesrapportages waardoor de procesprestaties inzichtelijk worden
INPUT Informatie uit en over de procesactiviteiten
OUTPUT Rapportages:
• procesmanagementrapportage
• procesrapportage
• rapportage per service
TOELICHTING De rapportages verschaffen inzicht in de prestaties van het proces (output) en in de wijze
waarop het proces is uitgevoerd (throughput).

ISM-procesmodel
Service Level Management

DOEL Het maken van afspraken en het aansturen, bewaken en rapporteren van de
overeengekomen dienstverlening
INPUT Wensen en eisen van de klant, interne verzoeken tot wijziging van de SLA, en rapportages
van andere processen. Ook interne beleidsuitgangspunten zijn input.
OUTPUT Door rapportage aangetoonde dienstverlening conform SLA en projectafspraken;
servicecatalogus
TOELICHTING Door een goed samenwerkingsverband tussen klant, leverancier en toeleverancier, zorgt dit
proces voor het overeenkomen, aansturen, bewaken, rapporteren en evalueren van een
optimaal niveau van de dienstverlening.
Een service is het aan de opdrachtgever en gebruikers beschikbaar stellen van (een
onderdeel van) de ondersteunde operationele omgeving. Bijvoorbeeld, een IT-dienst, een
vergaderzaal of het beschikbaar stellen van een goedgekeurde thermometer. Over het
functioneren van die omgeving worden eisen overeengekomen. De service omvat de
geïntegreerde levering van alle functionerende onderdelen die tezamen zorgen dat de
gebruiker krijgt wat hij nodig heeft.
De klanttevredenheid wordt naast de kwaliteit van de functionaliteit en de wijze waarop deze

functioneert in toenemende mate bepaalt door de gebruikservaring van de klant (Customer
Experience). Het verdient aanbeveling Customer Experience op te nemen in de afspraken en
deze te meten en te bespreken
Door het structureren en begeleiden van de wijze waarop afspraken worden gemaakt, borgt
het proces dat de gemaakte afspraken overeenkomen met de wensen van de klant, en dat de
services de business op maat ondersteunen. Ook borgt het proces dat de gemaakte
afspraken qua serviceniveau, planning en kosten goed uitvoerbaar zijn door de
dienstverlener.
De kwaliteit en continuïteit van de dienstverlening wordt gespecificeerd door vast te leggen:
• welke producten/services worden geleverd
• onder welke voorwaarden deze producten/services worden geleverd
• aan welke eisen deze producten/services voldoen
• hoe deze producten/services worden ondersteund
• op welke wijze kwaliteitsbeheersing (service quality control) tot stand komt
De feitelijke levering van de overeengekomen services wordt aangestuurd, bewaakt,

gerapporteerd en regelmatig met de klant besproken.
De dienstverlener is verantwoordelijk voor het bewaken van de afspraken met de

toeleveranciers en het integreren van deelservices in één samengestelde levering aan de
klant.

ISM-procesmodel
Maken & onderhouden serviceafspraken

DOEL Het op een gestructureerde manier tot stand brengen van SLA's en projectcontracten die de
businesseisen en -wensen van de klant herkenbaar en meetbaar beschrijven, en die voor de
leverancier reëel uitvoerbaar zijn
INPUT Eisen en wensen van de klant
OUTPUT SLA's en projectafspraken
TOELICHTING Verzoeken tot het maken van afspraken over levering of aanpassing van services of de
uitvoering van projecten zijn meestal afkomstig van de klant. Soms zal de beheerafdeling zelf
de klant adviseren om de serviceafspraken aan te passen, bijvoorbeeld omdat de uitvoering
van de bestaande afspraken niet (meer) haalbaar of niet efficiënt is.
Indien op enig moment blijkt dat het uitvoeren van de gemaakte afspraak kan leiden tot
risico’s voor de klant of voor andere klanten, of strijdig is met geldende interne of externe
regelgeving, dan wordt met de klant overlegt over een oplossing.
Bij het maken van serviceafspraken kan onder andere gebruik gemaakt van de
servicecatalogus en van interne richtlijnen.
De gemaakte afspraken worden via het proces change management geoperationaliseerd.

ISM-procesmodel
Verzamelen eisen & wensen

DOEL Het verzamelen van de eisen en wensen van de klant
INPUT Eisen en wensen van klanten (RFP)
OUTPUT Een servicedefinitie of projectdefinitie
TOELICHTING Verzoeken tot het maken of aanpassen van service- of projectafspraken zijn vaak afkomstig
van de klant. Ze kunnen echter ook het gevolg zijn van een interne service-evaluatie
(Improvement Management). Bijvoorbeeld als de leverancier kans ziet om zijn klanten beter
te helpen door een aantal afspraken aan te passen (bijvoorbeeld in de zin van meer of
minder volume, kwaliteit, of kosten).
De omschrijving van de eisen en wensen van de klant kan onder andere de volgende
zaken bevatten:
• een omschrijving, vanuit de klant gezien, van de business-requirements die aan de
dienst worden gesteld of van de functionaliteit die de service of het project moet leveren.
• het niveau van gebruikers of opdrachtgeverstevredenheid dat de dienstverlening oplevert
• tijden en dagen waarop de service beschikbaar moet zijn, inclusief de continuïteitseisen
die aan de service worden gesteld
• de flexibiliteit van de service: het tempo waarin de functionaliteit, het functioneren of de
leveringsvorm aangepast kan worden
• de compliancy en governance: aan welke weten regelgeving moet de service voldoen
• bruikbaarheid (useability), aan welke bruikbaarheideisen (gebruiksgemak) moet de
service voldoen
• de capaciteitseisen die aan de service of de projectuitkomst worden gesteld (hoeveel
gebruikers moeten gelijktijdig kunnen werken, hoe zitplaatsen in een zaal, et cetera.)
• eisen over bijvoorbeeld leveringstermijnen, kosten en communicatie
• de gewenste ondersteuning door de leverancier
Specificeren gewenste service

DOEL Het eenduidig vastleggen van de technische en organisatorische consequenties van de
vastgestelde servicedefinitie
INPUT Een servicedefinitie of projectdefinitie
OUTPUT Een servicespecificatie (specsheet)
TOELICHTING Tijdens deze activiteit worden de bepalende eisen uit de service- of projectdefinitie vertaald
naar de technische en organisatorische consequenties voor technisch beheer.
De volgende gegevens worden in ieder geval opgeleverd:
• een eenduidige en gedetailleerde beschrijving van de middelen en technieken die nodig
zijn om te kunnen bouwen, leveren en beheren
• een specificatie van de manier waarop de levering tot stand wordt gebracht
• de functies die betrokken zijn bij het leveren van de vereiste resources en de
bijbehorende competenties
• verwijzingen naar de huidige werkwijze en/of kwaliteitsstandaarden waarmee rekening
moet worden gehouden bij het technisch ontwerpen van de service of de projectuitkomst
• verwijzing, indien van toepassing, naar de SLA die moet worden aangepast of vervangen

ISM-procesmodel
Verifiëren impact en haalbaarheid

DOEL Het toetsen van de gevolgen en haalbaarheid van de servicespecificaties
INPUT Een servicespecificatie
OUTPUT Een impact- en haalbaarheidsanalyse
TOELICHTING Het toetsen van de gevolgen en haalbaarheid wordt door de betrokken afdelingen en
functionarissen uitgevoerd.
Zij geven aan of, hoe, wanneer en tegen welke kosten de service of het project kan worden
gerealiseerd. Hiermee wordt voorkomen dat aan de klant toezeggingen worden gedaan die
achteraf niet haalbaar of efficiënt uitvoerbaar zijn. Voor zover vereist worden hierbij externe
leveranciers betrokken, die voor hun eigen bijdrage de vereiste informatie verschaffen.
Bij het toetsen van de gevolgen wordt gelet op:

• meetbaarheid - zijn de afspraken meetbaar en rapporteerbaar?
• beleid - past de uitvoering binnen de huidige beleidskaders, onder andere technisch
(denk aan beveiligingseisen) en organisatorisch (denk aan 7x24 ondersteuning)?
• kosten - wat zijn de kosten van de uitvoering en zijn efficiëntere alternatieven mogelijk?
Hiermee wordt de impact, de haalbaarheid en de meetbaarheid van de aanvraag getoetst,

rekening houdend met de geldende klanten leveranciersnormen.
Indien de gevraagde oplevering (deels) door externe partijen wordt gerealiseerd, dan zal ook
aan hen om een impactanalyse en offerte worden gevraagd.
Deze activiteit levert de informatie om verantwoord te kunnen beslissen over de wijze waarop
de aanvraag zal worden beantwoord.
De informatie die door in- en externe teams wordt verstrekt is de basis voor de eventueel
daarop overeen te komen interne afspraken (eventueel formeel vast te leggen in een
Onderlinge leveringafspraak (OLA)) en leveranciersafspraken (eventueel vast te leggen in
Underpinning contract (UC)).
Beslissen over offerte

DOEL Beslissen of een offerte wordt uitgebracht
INPUT Een impact- en haalbaarheidsanalyse
OUTPUT Een besluit om wel of niet te offreren
TOELICHTING Mede op basis van de opgestelde impact- en haalbaarheidsanalyse wordt besloten of een
offerte zal worden aangeboden. Het kan voorkomen dat de klantaanvraag moet worden
afgewezen omdat de gevraagde levering:
• technisch niet haalbaar is voor de leverancier (de eisen en wensen zijn niet haalbaar of
de vereiste techniek wordt onvoldoende beheerst)
• buiten de portfolio (core-business) van de leverancier valt (de leverancier kan of wil het
gevraagde werk niet uitvoeren)
• niet past binnen de doelstelling van de beheerorganisatie (bijvoorbeeld als er te veel
exotische technieken of producten door zouden moeten worden onderhouden)
• organisatorisch niet haalbaar of gewenst is (de opdracht is te groot, 7 x 24 uur on-site
beschikbaarheid kan niet worden geleverd)
Offreren?
JA Er wordt een offerte uitgebracht en de eventuele onderhandelingen kunnen starten.
NEE Er wordt geen offerte uitgebracht, de klant wordt hierover geïnformeerd.
Terugkoppelen afwijzing
DOEL De klant informeren dat er geen offerte wordt uitgebracht
INPUT De beslissing om niet te offreren
OUTPUT Een geïnformeerde klant
TOELICHTING Volgens de geldende afspraken wordt met de klant gecommuniceerd, dat er niet geoffreerd
gaat worden.

ISM-procesmodel
Onderhandelen
DOEL Het opstellen van een offerte en met de klant onderhandelen over de voorgestelde
dienstverlening
INPUT Het besluit om te offreren; de impact- en haalbaarheidsanalyse
OUTPUT Wel of geen overeenkomst
TOELICHTING Bij het vaststellen van de offerte wordt de opgestelde impact- en haalbaarheidsanalyse
gebruikt, om te bepalen tegen welke condities en prijs de gevraagde service wordt
aangeboden.
Eventueel kan worden besloten om af te wijken van de serviceaanvraag en wordt een
alternatieve aanbieding aan de klant gedaan.
Omdat aan een offerte vaak een tijdsaspect hangt (geldigheidsduur, oplevertermijn) is het
mogelijk dat er al in deze fase in de organisatie reserveringen worden gedaan voor de inzet
van resources.
Tijdens het onderhandelen wordt met de klant het niveau van de gewenste services in relatie
tot de kosten, en de vastlegging daarvan in SLA's of projectafspraken, bepaald.
De onderhandeling kent drie mogelijke uitkomsten:

1. Er wordt conform de servicedefinitie een SLA of projectafspraak overeengekomen.
2. De servicedefinitie wordt door de klant tijdens het onderhandelen op relevante punten
aangepast, bijvoorbeeld om de kosten te drukken. De impact hiervan moet getoetst
worden door de voorgaande procesactiviteiten opnieuw te doorlopen. In dat verband
dient te worden geborgd dat eventuele reserveringen worden bewaakt in het licht van de
tijd en de herdefinitie van de te leveren services.
3. Er komt geen overeenkomst (en dus geen levering) tot stand.
Het resultaat van de onderhandelingen wordt vastgelegd in een SLA of projectafspraak. De

afspraak beschrijft de service(s) in niet-technische termen (inspelend op de belevingswereld
van de klant) en dient gedurende de looptijd van de overeenkomst als norm voor het meten
en sturen van de service(s). Bij voorkeur wordt hier zo veel mogelijk verwezen naar de
servicecatalogus.
Akkoord?
JA Er is een overeenkomst gesloten tussen de klant en de leverancier, er wordt gestart met de
uitvoering.
NEE Er is geen overeenkomst gesloten en de procedure wordt opnieuw doorlopen.
NEE Er is geen overeenkomst gesloten, de klant wordt geïnformeerd, en de procedure wordt
beëindigd.
Doorvoeren serviceafspraken
DOEL Een nieuwe of gewijzigde afspraak via het proces change management laten doorvoeren
INPUT Een vastgestelde overeenkomst
OUTPUT De oplevering van een conform de nieuwe afspraak ingericht informatiesysteem
TOELICHTING Om de feitelijke aanpassing van de dienstverlening of projectoplevering te initiëren, wordt
een RFC opgesteld en ingediend. Nadat de aanpassing is gebouwd, geïmplementeerd en
indien nodig door de klant geaccepteerd, begint de levering van de service.
Het change management-proces borgt dat de wijziging in de dienstverlening als gevolg van
de nieuwe overeenkomst op een zorgvuldige wijze wordt doorgevoerd.
Behalve het implementeren van middelen worden ook organisatorische en
procedurewijzigingen doorgevoerd om de service conform afspraak te kunnen leveren. Zo
kunnen de afspraken uit de SLA worden doorvertaald naar afspraken in OLA’s. En voor zover
gebruik wordt gemaakt van leveringen door externe leveranciers kunnen deze op dezelfde
wijze worden vastgelegd in UC’s.

ISM-procesmodel
Toetsen aanpassing servicecatalogus

DOEL Vaststellen of de nieuwe overeenkomst aanleiding is om de servicecatalogus aan te passen
INPUT De oplevering van een conform de nieuwe afspraak ingericht informatiesysteem

OUTPUT Een op servicecatalogus-aanpassing getoetste aanvraag
TOELICHTING Indien een nieuw type service of een aangepaste service is overeengekomen en geleverd
moet beoordeeld worden of deze service mogelijkerwijs opgenomen kan worden in de
servicecatalogus.
Als dat het geval is wordt het (deel)proces “SLM.3 Onderhoud servicecatalogus” gestart.
Afsluiten serviceaanvraag
DOEL Het afsluiten van de serviceaanvraag
INPUT Een op servicecatalogus-aanpassing getoetste aanvraag, of een beslissing om de
dienstverlening niet aan te passen
OUTPUT Informatie over het doorlopen proces, en gearchiveerde documentatie
TOELICHTING Nadat de nieuwe of aangepaste service is doorgevoerd wordt bekeken of het proces correct
en tot tevredenheid van de klant is doorlopen, en of er nog verbeteringen uit kunnen worden
afgeleid. Mogelijke verbeteringen in de dienstverlening worden vastgelegd in een service
improvement plan.
De documentatie wordt gearchiveerd, zodat bij een vervolgaanvraag gebruik kan worden
gemaakt van de tussenresultaten. Ten slotte wordt gecontroleerd of het call-record volledig is
bijgewerkt en wordt dit zo nodig aangevuld, waarna de aanvraag wordt afgesloten.

ISM-procesmodel
Aansturen dienstverlening
DOEL Het conform SLA of projectafspraak laten uitvoeren van de dienstverlening. Hierover aan de
klant rapporteren en met hem overleggen.
INPUT SLA's of projectafspraken
OUTPUT Door rapportage aangetoonde prestaties
TOELICHTING De feitelijke levering of aanpassing is opgestart door de afhandeling van de ingediende RFC.
Nadat de aanpassing is gebouwd of de levering is gestart en geïmplementeerd, bewaakt
"Aansturen dienstverlening" de correcte naleving van de afspraken door te coördineren
tussen de uitvoerende processen en in te (laten) grijpen in wanneer dat nodig is. Aan de
hand van rapportage en regelmatig overleg met de klant wordt de levering geëvalueerd en
waar nodig bijgesteld. Dit laatste kan worden gedaan door de uitvoering van de
overeenkomst te laten aanpassen of door een aanpassing van de overeenkomst te initiëren.
Verzamelen deelprestaties
DOEL Verzamelen van informatie met betrekking tot de geleverde dienstverlening
INPUT Informatie over de geleverde dienstverlening
OUTPUT Geregistreerde informatie over de geleverde dienstverlening
TOELICHTING De servicelevels moeten vanuit het perspectief van de klant worden gemeten. Deze bewaking
betreft niet alleen technische zaken, maar ook procedurele zaken (Bijvoorbeeld: als een
gebruiker geen terugmelding heeft gehad dat de service na een storing weer operationeel is,
gaat hij er mogelijk vanuit dat de service nog niet beschikbaar is). De voortgang en kwaliteit
van de afhandeling moet worden bewaakt.
Tijdens deze activiteit wordt informatie verzameld uit verschillende bronnen, zoals:
• opdrachtgevers die afwijkingen van de afspraken constateren
• ISM-processen die serviceafwijkingen binnen hun procesdomein niet zelfstandig kunnen
afhandelen en daarover ad hoc rapporteren of escaleren
• ISM-processen die op reguliere basis rapporteren over de procesprestaties
• toeleveranciers die ad hoc of regulier hun prestaties melden.
Informatie wordt niet uitsluitend verzameld door op input te wachten, er wordt ook actief
gevolgd of de dienstverlening wel conform de afspraak plaats vindt. Daartoe informeert de
servicemanager actief bij de betrokken verantwoordelijke partijen.

ISM-procesmodel
Samenstellen servicerapportage
DOEL Het opstellen en verzenden van de overeengekomen rapportages
INPUT Geregistreerde informatie over de geleverde dienstverlening
OUTPUT Rapportages over de geleverde dienstverlening
TOELICHTING De met de klant overeengekomen rapportages moeten juist, volledig en op tijd aan de klant
worden geleverd, conform de afspraken in de SLA of projectafspraak. Interne rapportages
worden gestuurd naar de betrokken afdelingen.
Interne teams of processen rapporteren over hun bijdrage aan de overeengekomen levering.
Uit deze afzonderlijke rapportages wordt een integrale klantrapportage samengesteld.
Daarbij worden elementen van de deelrapportages samengevoegd en vertaald naar de
termen van de overeengekomen SLA of projectafspraak. De verzamelde informatie wordt
daarmee gebruikt om een rapportage op te stellen waarin helder wordt aangetoond in welke
mate de serviceverlening voldoet aan de overeengekomen SLA.
Rapportages moeten volgens een afgesproken regelmaat worden opgesteld. Een interne
servicerapportage (waaruit de rapportage aan de klant wordt samengesteld) bevat
bijvoorbeeld informatie over:
• De gebruikerstevredenheid m.b.t. de afhandeling van verzoeken
• De mate waarin de dienstverlening aan de weten regelgeving heeft voldaan
• de beschikbaarheid en niet-beschikbaarheid (downtime) van een service die over een
bepaalde periode is gemeten
• frequentie en duur van degradatie als services beneden hun afgesproken niveau draaien
• het aantal behandelde incidenten, changes en service requests en de mate waarin deze
correct zijn afgehandeld
• het aantal al dan niet succesvolle pogingen om de beveiliging te omzeilen
Waar nodig moet vervolgens worden ingegrepen. Dit kan op basis van reguliere rapportages
maar ook op ad hoc basis, bijvoorbeeld als er sprake is van een ernstige klacht van de
opdrachtgever, of bij een ernstige escalatie uit een van de processen. Bij zulke ad hoc
situaties worden geen uitgebreide rapportages opgesteld, om deze vervolgens in te brengen
in een overleg, maar worden veel sneller conclusies getrokken ten aanzien van de gewenste
ingrepen en bijsturing. Indien nodig vindt afstemming plaats tussen de verschillende
betrokkenen, zo nodig ook met de klant.
Evalueren serviceafspraken
DOEL Het zowel intern als extern evalueren van de geleverde dienstverlening
INPUT Rapportages over de geleverde dienstverlening
OUTPUT Geëvalueerde serviceafspraken
TOELICHTING Zowel met de klant als met interne afdelingen wordt de levering besproken aan de hand van
de opgeleverde rapportage en/of de bevindingen. Er wordt beoordeeld of de (afspraken over)
overeengekomen servicelevels moeten worden bijgesteld (naar boven of naar beneden).
De servicerapportage moet regelmatig met de klant worden besproken. Gedurende deze
activiteit komen de volgende onderwerpen aan de orde:
• de service level achievements sinds de vorige evaluatie
• problemen tijdens de levering
• identificatie van trends in de dienstverlening
• de gevolgen van het niet nakomen van de afspraken.
In het geval van ad hoc situaties kan deze bespreking met de klant zeer snel worden
doorlopen, of wordt besloten rechtstreeks bij te sturen op de uitvoering van de
dienstverlening. Als er sprake is van ernstige klachten of verstoringen van de dienstverlening
wordt meteen overlegd met de opdrachtgever en/of de betrokken interne of externe
uitvoerende partijen, om te bepalen welke verbetering nodig is.
Als de levering geheel conform wens is verlopen, en de klant is tevreden met de rapportage
daarover, wordt het proces vervolgd met evalueren en afsluiten.
Als de levering niet voldoet aan de afspraken, dan kunnen acties worden afgesproken om dat
te verbeteren, waaronder:
• toekennen van extra medewerkers en middelen
• bijstellen van de servicelevels in de afspraken
• aanpassen van de werkinstructies
• aanpassen van interne afspraken (eventueel vastgelegd in OLA's) en
leveranciersafspraken (eventueel vastgelegd in UC's).
Deze geplande verbeteringen worden vastgelegd in het Service improvement plan (SIP),
waarin de geplande acties, fasen en opleverdata zijn gedocumenteerd. De realisatie van het
service improvement plan kan worden uitgevoerd als een project.
Vanzelfsprekend wordt deze activiteit bij ad hoc situaties veel sneller doorlopen.

ISM-procesmodel
Bijsturen dienstverlening
DOEL Het bijsturen van de dienstverlening
INPUT Geëvalueerde serviceafspraken
OUTPUT Al dan niet bijgestuurde dienstverlening
TOELICHTING Als een verbetering wordt doorgevoerd door een aanpassing van de levering, dan wordt via
een RFC het CHM-proces opgestart.
Als een verbetering wordt doorgevoerd door een aanpassing van de overeenkomst met de
klant, dan wordt het deelproces 'Maken & onderhouden van serviceafspraken' opgestart.
Als een verbetering wordt doorgevoerd door alleen de uitvoering van de levering te
verbeteren, dan worden de betrokken partijen daartoe aangestuurd. Dit kan bijvoorbeeld
inhouden dat extra medewerkers en middelen beschikbaar worden gesteld, of dat prioriteiten
worden aangepast.
Vaak zal bijsturing van de dienstverlening niet nodig zijn.
Afsluiten aansturing
DOEL Het afsluiten van het proces en het vastleggen van alle noodzakelijke gegevens
INPUT Al dan niet bijgestuurde dienstverlening
OUTPUT Gedocumenteerde geëvalueerde aansturing van de dienstverlening
TOELICHTING Nadat de (geplande of ad hoc) meldingen, rapportages en bevindingen zijn afgehandeld
wordt bekeken of het proces correct is doorlopen, en of er nog verbeteringen uit kunnen
worden afgeleid.
De gemaakte rapportages, gewijzigde service improvement plans en alle relevante overige
documentatie worden gearchiveerd.
“Aansturen dienstverlening” loopt continu door zolang de SLA van toepassing is. Dat betekent
dat na “afsluiten aansturing” weer begonnen wordt met “verzamelen deelprestaties”.

ISM-procesmodel
Onderhoud servicecatalogus
DOEL Het vastleggen van de standaard dienstverlening in de servicecatalogus
INPUT Een voorstel om de servicecatalogus aan te passen
OUTPUT Een al dan niet aangepaste servicecatalogus
TOELICHTING De servicecatalogus beschrijft de verschillende services die de leverancier standaard aan zijn
klanten aanbiedt.
Op basis van de klantbehoefte en de eigen overwegingen bepaalt de leverancier de

standaardservices en de daarbij horende servicelevels.
Bij het bepalen van de standaardservices wordt het strategische beleid van klanten (aan
welke services heeft de klant nu of in de toekomst behoefte) en de leverancier (welke
services wil de leverancier leveren) als leidraad meegenomen.
Inventariseren servicewensen
DOEL Het inventariseren van de behoefte aan standaardservices en bijbehorende standaard
servicelevels
INPUT Ideeën om de servicecatalogus aan te passen
OUTPUT Een voorstel om de servicecatalogus aan te passen
TOELICHTING De servicecatalogus beschrijft de services die standaard door de leverancier geleverd worden.
Doel van de servicecatalogus is de klanten inzicht te geven in de mogelijkheden die technisch
beheer biedt.
Om de servicecatalogus actueel te houden, wordt voortdurend gekeken of het zinvol is de
servicecatalogus aan te passen, binnen de strategie van de leverancier, inspelend op de
behoefte van de klanten en gebaseerd op inzicht in de nieuwste technische ontwikkelingen.
Ook uit nieuwe SLA's kunnen verbetermogelijkheden voortkomen.
Als zinvolle aanpassingen mogelijk zijn, wordt in deze activiteit een voorstel uitgewerkt om
de servicecatalogus aan te passen. Dit kan ook betekenen dat bepaalde services niet meer
tot de standaard behoren en uit de servicecatalogus worden verwijderd.

ISM-procesmodel
Beslissen aanpassing servicecatalogus

DOEL Het toetsen van de haalbaarheid van de geïnventariseerde potentiële standaardservices
INPUT Een voorstel om de servicecatalogus aan te passen
OUTPUT Een besluit om de servicecatalogus aan te passen
TOELICHTING Op basis van het voorstel wordt besloten over de aanpassing van de servicecatalogus. Dit
gebeurt vaak door het management van de leverancier. De inhoud van de servicecatalogus is
niet vrijblijvend, maar een toezegging aan (potentiële) klanten dat de leverancier in staat is
te leveren onder de genoemde voorwaarden.
Aanpassen?
JA De voorgedragen standaardservices worden geregistreerd in de servicecatalogus.
NEE De voorgedragen standaardservices worden niet geregistreerd in de servicecatalogus, de
klant wordt hierover geïnformeerd.
Informeren aanmelder
DOEL De aanmelder informeren dat de voorgedragen standaardservices niet geregistreerd worden
in de servicecatalogus
INPUT De beslissing dat de voorgedragen standaardservices niet geregistreerd worden in de
servicecatalogus
OUTPUT Informatie over de beslissing dat de voorgedragen standaardservices niet toegevoegd worden
aan de servicecatalogus
TOELICHTING Volgens de geldende afspraken wordt met de aanmelder gecommuniceerd dat de
servicecatalogus niet wordt aangepast.
Registreren standaardservices
DOEL Het aanpassen van de servicecatalogus
INPUT Een besluit om de servicecatalogus aan te passen
OUTPUT Een aangepaste servicecatalogus
TOELICHTING De aangenomen voorstellen worden opgenomen in de servicecatalogus, waarna deze in een
nieuwe versie gepubliceerd wordt. Het uitvoeren van de aanpassing van de servicecatalogus
vindt plaats via het changeproces, omdat op deze wijze wordt geborgd dat alle partijen op de
juiste wijze betrokken worden.
Afsluiten onderhoud servicecatalogus

INPUT Een al dan niet aangepaste servicecatalogus
OUTPUT Een gedocumenteerde eventueel gewijzigde servicecatalogus
TOELICHTING Volgens de geldende afspraken wordt zo nodig aanvullend met de betrokken partijen
gecommuniceerd. Alle relevante documentatie wordt gearchiveerd, zodat bij een hernieuwde
aanpassing van de servicecatalogus gebruik gemaakt kan worden van deze informatie.
Eventuele verbeteracties met betrekking tot bijvoorbeeld de procesgang of betrokken
documentatie worden gestart, en het proces wordt afgesloten.

ISM-procesmodel
Improvement management
DOEL Het in stand houden en optimaliseren van effectieve en efficiënte dienstverlening zoals die
met de klant is overeengekomen
INPUT Serviceafspraken, interne kwaliteitsnormen, gesignaleerde risico´s
OUTPUT Weggenomen of beheerste risico's
TOELICHTING Door het wegnemen van risico’s borgt improvement management dat de operationele
omgeving effectief en efficiënt blijft functioneren conform de gemaakte serviceafspraken en
interne kwaliteitsnormen,
Een risico is een kans dat de SLA niet wordt gerealiseerd. Risico’s kunnen worden
veroorzaakt door zwakke plekken in de operationele omgeving (Technical Debt) of de
inrichting en het functioneren van de beheerorganisatie of de kwaliteit van de dienstverlening
door toeleveranciers (Organizational Debt). Risico’s worden ook vaak veroorzaakt door het
veranderen van omstandigheden. Zo kan de toename in het gebruik van een service leiden
tot problemen met de capaciteit. Ook kunnen bijvoorbeeld externe omstandigheden zodanig
wijzigen dat handhaving van het overeengekomen servicelevel niet mogelijk is zonder extra
maatregelen te treffen. Denk hierbij bijvoorbeeld aan het beëindigen van het onderhoud op
een product of platform door een leverancier.
Een belangrijke externe factor zijn de eisen die vanuit de externe regelgeving (compliancy)
worden gesteld. Niet alleen vormt het al dan niet voldoen aan deze eisen risico’s, ook kan de
inhoud van deze eisen extern worden verandert
In de beschrijving van QM ligt de nadruk op de dienstverlening. Het wegnemen van risico’s

bij het uitvoeren van projectafspraken is ook het domein van QM, maar zal in de praktijk een
veel kleiner aandachtsgebied zijn. Voor de leesbaarheid wordt in deze beschrijving alleen
gewezen op de dienstverlening.
Het proces stelt risico’s vast, bijvoorbeeld door incidenten te beoordelen op mogelijke
recidive, maar kijkt ook nadrukkelijk proactief naar zwakke plekken in de operationele
omgeving op het gebied van:
• functionaliteit
• governance
• security
• flexibiliteit
• bruikbaarheid
• beschikbaarheid
• capaciteit
• uitwijk
• beveiliging
• efficiency
• management
Het proactief vaststellen van risico’s kan onder andere gebeuren door het initiëren van
gericht onderzoek naar één van bovenstaande aandachtsgebieden of aspecten daarvan.
Naast het zorgvuldig afhandelen van risico’s die al effect hebben (bekende incidenten
veroorzaken), richt quality management zich nadrukkelijk op risico’s die verstoringen dreigen
te veroorzaken, en daarmee op het voorkomen van incidenten die nog niet eerder hebben
plaatsgevonden.
Specifiek voor IT geldt dat traditioneel problem management, zoals in ITIL beschreven, in
zijn geheel wordt afgedekt door het improvement management proces.
Hoewel risico’s feitelijk alleen kunnen worden beperkt of beheerst hanteren we voor de
leesbaarheid wel de termen 'wegnemen' of 'oplossen'.
De vraag of mogelijke tegenmaatregelen daadwerkelijk worden uitgevoerd, is afhankelijk van

enerzijds de kosten die de maatregel veroorzaakt, en anderzijds de schade die aan de
dienstverlening dreigt te worden toegebracht.
In de meeste gevallen zal het proces improvement management via een request for change
een tegenmaatregel laten uitvoeren. Soms zal geadviseerd worden de serviceafspraken te
bespreken met de klant. In een enkel geval zal geen tegenmaatregel worden voorgesteld,
omdat de kosten hoger zijn dan de baten, of domweg omdat de oplossing niet gerealiseerd
kan worden.

ISM-procesmodel

ISM-procesmodel
Identificeren risico
DOEL Het vaststellen van risico’s die bedreigend zijn voor het nakomen van de SLA's en
projectafspraken
INPUT Serviceafspraken, interne kwaliteitsnormen, data uit andere processen
OUTPUT Een gedefinieerd risico
TOELICHTING Van onbekende risico's kan niet bepaald worden welke bedreiging ze vormen voor het
optimaal nakomen van gemaakte serviceafspraken. Het is daarom van groot belang zoveel
mogelijk risico’s zo vroeg mogelijk vast te stellen.
Het identificeren van risico’s vindt vaak spontaan plaats tijdens de uitvoering van
beheerwerkzaamheden, maar het is de taak van improvement management om gericht naar
risico’s te zoeken. Het is de rol van improvement management om het proactief onderzoek
naar risico’s planmatig te organiseren.
Het is van groot belang dat ook de spontaan vastgestelde risico’s geregistreerd worden,
zodat gericht onderzoek naar de ernst van het risico kan plaatsvinden. Iedereen heeft dan
ook de opdracht spontaan geïdentificeerde risico’s te melden.
Van de vastgestelde risico’s moet bepaald worden hoe groot de bedreiging is die zij vormen
voor de dienstverlening. Op basis daarvan wordt de prioriteit van de afhandeling bepaald.

ISM-procesmodel
Verzamelen en analyseren gegevens

DOEL Het reactief en proactief definiëren van risico's
INPUT Serviceafspraken, interne kwaliteitsnormen, data uit andere processen
OUTPUT Een vastgesteld risico
TOELICHTING Het proces improvement management zoekt actief naar zwakke plekken in de
dienstverlening, ook als er geen meldingen van mogelijke risico's zijn ontvangen.
Het proactief en reactief vaststellen van risico’s vindt bij voorkeur planmatig plaats. In dit
op te stellen plan worden mogelijke risicogebieden en de frequentie van onderzoeken
vastgelegd. Ook wordt vastgelegd welk organisatieonderdeel of functie het onderzoek moet
uitvoeren. Op basis van dit plan initieert improvement management gericht risico-
inventarisaties.
Bij het verzamelen en analyseren van gegevens kunnen diverse gegevensbronnen worden
geraadpleegd, zoals de:
• incident database
• CMDB
• risk database
• monitoring database
• rapportages
Ook het niet tijdig inzetten of beschikbaar hebben van de vereiste resources kan een risico
voor de overeengekomen dienstverlening zijn.
Een belangrijke bron voor het vinden van mogelijke risico's zijn meldingen van beheerders
die tijdens hun werk situaties constateren die duiden op een zwakke plek in de operationele
omgeving, zoals:
• bij het werken aan een incident wordt de oorzaak niet weggenomen
• IT: bij het opschonen van data worden te volle schijven aangetroffen
• Facilitair: bureaus vertonen regelmatig speling tussen tafelblad en poten
• Medische Technologie: kasten met steriele apparatuur er in zijn soms niet afgesloten
De vastgestelde situatie wordt vergeleken met de in de SLA's vastgelegde serviceafspraken.

Indien de vastgestelde situatie een bedreiging vormt voor het nakomen van de
serviceafspraken wordt een risico vastgesteld en geregistreerd.
Ieder vastgesteld risico wordt toegevoegd aan de risicolijst. Deze lijst wordt onderhouden
door nieuwe bevindingen m.b.t. tot de vastgestelde risico’s toe te voegen, zoals:
• status
• prioriteit
• oplosgroep/eigenaar
• oorzaak
• maatregel

ISM-procesmodel
Vaststellen prioriteit
DOEL Het vaststellen van de prioriteit van een risico op basis van de impact en urgentie van het
risico
INPUT Een vastgesteld risico
OUTPUT Een geprioriteerd risico
TOELICHTING De prioriteit van afhandeling van een risico wordt bepaald door de bedreiging die een risico
voor de dienstverlening vormt. Deze bedreiging wordt weer gebaseerd op de impact en de
urgentie van het risico.
De impact van risico's wordt onder andere vastgesteld op basis van:
• de schade die het risico kan veroorzaken voor de business
• de geschatte frequentie waarmee het risico schade gaat veroorzaken
• of er wel of niet een workaround beschikbaar is
De urgentie geeft aan hoeveel tijd er beschikbaar is voordat de schade zou gaan optreden.
De volgende prioriteiten kunnen bijvoorbeeld worden toegekend:

• Geen prioriteit: het risico wordt voorlopig niet nader onderzocht (parkeerstand).
• Lage prioriteit: het risico wordt nader onderzocht - er zit geen tijdsdruk op.
• Middel prioriteit: het risico wordt nader onderzocht - er zit een beperkte tijdsdruk op.
• Hoge prioriteit: een risico met aanzienlijke tijdsdruk - er moet onmiddellijke actie
worden ondernomen.
Eenmaal vastgestelde risicoprioriteiten kunnen worden bijgesteld op basis van aanvullende

informatie, bijvoorbeeld door een toenemende impact of urgentie.
Bepalen oplosgroep
DOEL Het bepalen van de meest geschikte functies of rollen die gezamenlijk het risico verder zullen
analyseren
INPUT Een geprioriteerd risico
OUTPUT Een toegewezen risico
TOELICHTING Afhankelijk van de aard van het ingeschatte risico wordt bepaald wie het best in staat is het
risico verder te onderzoeken.
De prioriteit bepaalt de mate waarin aanspraak kan worden gemaakt op in te zetten
resources. Voor een risico met hoge prioriteit zal zelfs de meest exclusieve expert z’n
projectwerkzaamheden moeten onderbreken. Bij de vraag of resources kunnen worden
ingezet, is het steeds van belang de overeengekomen serviceafspraken centraal te stellen: de
realisatie van de gemaakte afspraken zal in het algemeen zwaarder wegen dan het
ontwikkelen van nieuwe services.
De selectie van de in de oplosgroep in te zetten risicoanalisten dient te worden voorbereid
door daarover vooraf basisafspraken met het lijnmanagement te maken.

ISM-procesmodel
Vaststellen oorzaak
DOEL Het analyseren van het risico
INPUT Een toegewezen risico
OUTPUT De vastgestelde oorzaak van het risico
TOELICHTING Voordat mogelijke maatregelen worden uitgewerkt, moet eerst de oorzaak van het risico
worden vastgesteld. Er wordt nog niet gestreefd naar het wegnemen of beheersen van het
risico. De vraag die hier eerst beantwoord moet worden is: wat is de oorzaak van het risico?
Uitvoeren risicoscan
DOEL Een risicoscan wordt uitgevoerd om te bepalen of het risico verder onderzocht moet worden
INPUT Een toegewezen risico
OUTPUT Een risicoscan rapport
TOELICHTING De risicoscan bevat een overzicht van:
• de schade die het risico kan veroorzaken
• de kans dat of de geschatte frequentie waarmee het risico schade veroorzaakt
De inschatting is mede gebaseerd op:

• de afspraken in de SLA (is het een keiharde klantafspraak of niet)
• de kosten die de gevolgen van het risico in de huidige situatie veroorzaken
• de inschatting in welke mate het risico in de toekomst schade zal veroorzaken
De doorlooptijd van een risicoscan is afhankelijk van de prioriteit van het risico, bijvoorbeeld:
• prioriteit Laag: 1 maand
• prioriteit Middel: 1 week
• prioriteit Hoog: 1 dag
Niet alleen nieuwe risico’s worden onderzocht maar ook risico’s op de risicolijst waarvan
eerder is vastgesteld dat ze op dat moment een laag risico hadden waardoor verder
onderzoek gestopt is. Regelmatig zal bekeken moeten worden of door veranderende
omstandigheden de vastgestelde prioriteit nog steeds actueel is.
Beslissen vervolgonderzoek
DOEL Beslissen over de wijze waarop de risicoafhandeling wordt voortgezet
INPUT Een risicoscanrapport
OUTPUT De beslissing om wel of niet verder te analyseren
TOELICHTING Op basis van de risicoscan wordt besloten hoe en met welke prioriteit de afhandeling van het
risico wordt vervolgd.
Op basis van voortschrijdend inzicht uit de risicoscan kan eventueel de prioriteit worden
bijgesteld. Indien uit de risicoscan blijkt dat het risico (achteraf) erg klein is, kan ook
besloten worden om de risicoafhandeling (voorlopig) niet te vervolgen. Het risico blijft dan op
de risicolijst staan. Op deze wijze kan later, bijvoorbeeld als omstandigheden zijn veranderd,
een herbeoordeling van het vastgestelde risico plaatsvinden.

ISM-procesmodel
Verder analyseren?
JA Er is besloten om het risico verder te analyseren teneinde de oorzaak vast te stellen.
NEE Er is besloten om het risico niet verder te analyseren. De risicoafhandeling wordt voorlopig
gestopt.
Vaststellen oorzaak
DOEL Het vaststellen van de oorzaak van het risico
INPUT Het besluit om het risico verder te onderzoeken teneinde de oorzaak vast te stellen
OUTPUT De vastgestelde oorzaak van het risico
TOELICHTING Het vaststellen van de oorzaak van het risico is essentieel om de juiste tegenmaatregelen te
kunnen treffen. Het is goed mogelijk dat er meerdere oorzaken ten grondslag liggen aan het
vastgestelde risico.
Bij het onderzoek kan gebruik worden gemaakt van:

• checklist risicoanalyse
• kennis aanwezig bij collega's en leveranciers
Ook meer ingrijpende technieken kunnen worden ingezet. Hierbij valt te denken aan het
monitoren van betrokken systemen, of het simuleren van omstandigheden waarin het risico
lijkt op te treden. Ook kan deskresearch worden uitgevoerd, al of niet door derden.
Dit vervolgonderzoek eindigt uiteindelijk met het vaststellen van de oorzaak van het risico.

ISM-procesmodel
Selecteren maatregel
DOEL Het vinden van geschikte maatregelen voor het wegnemen of beperken van het vastgestelde
risico
INPUT De vastgestelde oorzaak van het risico
OUTPUT Geselecteerde maatregelen
TOELICHTING Op basis van de vastgestelde oorzaak worden passende maatregelen vastgesteld. Om te
bepalen of het verstandig is deze maatregelen door te voeren worden kosten en baten tegen
elkaar afgewogen. Hier kan een businesscase voor worden opgesteld. En dus kan ook
besloten worden om gezien de uitkomst van de kosten-baten-afweging niets te doen.
Identificeren maatregelen
DOEL Het bepalen van de maatregelen die kunnen worden genomen om het risico goed af te
handelen
INPUT De vastgestelde oorzaak van het risico
OUTPUT De geïdentificeerde maatregel
TOELICHTING De verschillende maatregelen voor het wegnemen van het risico worden geïnventariseerd. Er
wordt zo breed mogelijk gekeken naar mogelijke oplossingen: de eerste oplossing is niet
altijd de beste.
Voor het inventariseren van de maatregelen kunnen onder andere de volgende bronnen
geraadpleegd worden:
• specialisten
• leveranciers
• literatuur
Van alle maatregelen worden de voor- en nadelen vastgesteld, eventueel wordt een formele
businesscase opgesteld. Hierbij gaat het om voor- en nadelen die betrekking hebben op:
• de impact op de eindgebruikers/klant: wat is het gevolg voor de afnemer?
• de impact op het beheer: wat is het gevolg voor de beheerder?
• technische impact: wat is het gevolg voor de techniek?
• financiële impact: wat is het gevolg voor de kosten?

ISM-procesmodel
Deze activiteit wordt uitgevoerd door het raadplegen van:

• klantvertegenwoordigers (accountmanagement/relatiebeheer)
• de beheerorganisatie
• specialisten
• leveranciers
• financiële afdeling
Categoriseren maatregel
DOEL Het categoriseren van de maatregel
INPUT De geïdentificeerde maatregel
OUTPUT De gecategoriseerde maatregel
TOELICHTING Er zijn drie mogelijke categorieën van maatregelen:
• Wijzigen van de operationele omgeving - het risico wordt weggenomen door een
wijziging in de operationele omgeving.
• Niets doen - Een goede beperkende maatregel is op dit moment niet voorhanden
• De SLA heroverwegen - het risico kan worden weggenomen door de afspraken met de
klant te wijzigen. Dit komt neer op “het wijzigen van de spelregels”, wat soms de meest
praktische uitkomst is van het overleg met de klant.
Selecteren maatregel
DOEL Het selecteren van de te nemen maatregel
INPUT De gecategoriseerde maatregel
OUTPUT De geselecteerde maatregel
TOELICHTING Beslissingen worden steeds genomen op basis van een kosten-batenanalyse. Afhankelijk van
de geselecteerde maatregelen worden bij de besluitvorming de verschillende
belanghebbenden betrokken. Er zijn diverse redenen denkbaar voor het niet uitvoeren van
een maatregel:
• De maatregel heeft teveel negatieve bijeffecten (denk aan gevolgen voor andere
klanten).
• De maatregel is in strijd met vastgesteld strategisch beleid.
• De maatregel kost meer dan deze oplevert. De beschikbaarheid van een workaround kan
in zo’n geval helpen.
Maatregel nemen?
JA Er is besloten om het risico weg te nemen door de operationele omgeving te wijzigen.
JA Er is besloten om het risico weg te nemen door de SLA te heroverwegen.
JA Er is besloten om het risico weg te nemen door advies te verstrekken.
NEE Er is besloten om het risico niet weg te nemen.
Klant adviseren
DOEL Het adviseren van de klant over de maatregel die de klant kan nemen om het risico weg te
nemen of te beperken
INPUT Het besluit om de klant te adviseren
OUTPUT Een advies
TOELICHTING Afhankelijk van het soort maatregel wordt er een advies opgesteld.

ISM-procesmodel
Doorvoeren maatregel
DOEL Het (laten) realiseren van de meest geschikte oplossing voor het wegnemen van het risico
INPUT Geselecteerde maatregelen
OUTPUT Een aangemeld verzoek voor het implementeren van de maatregel
TOELICHTING Er wordt een verzoek opgesteld en ingediend om de geselecteerde maatregel door te voeren.
Opstellen afhandelverzoek
DOEL Het opstellen van het afhandelverzoek om hiermee het risico weg te nemen
INPUT De geselecteerde maatregel
OUTPUT Een opgesteld afhandelverzoek
TOELICHTING Om de geselecteerde maatregel te laten doorvoeren wordt of:
• een verzoek opgesteld om de SLA te laten aanpassen via het proces service level
management òf
• een RFC opgesteld om de operationele omgeving te laten aanpassen via het change
management-proces.
Indienen afhandelverzoek
DOEL Het indienen van het afhandelverzoek om hiermee het risico weg te nemen, en het bewaken
van de afhandeling daarvan
INPUT Een opgesteld afhandelverzoek
OUTPUT Een uitgevoerd afhandelverzoek
TOELICHTING De wijziging wordt uitgevoerd door het proces change management (in geval van een
change) of door het proces service level management (in geval van een aanpassing van de
SLA). Improvement management stelt het afhandelverzoek op (eventueel voorzien van een
business case) en bewaakt de voortgang van de afhandeling op hoofdlijnen, vanuit de positie
van aanvrager. In geval van een change meldt change management het doorvoeren van de
wijziging terug aan Improvement management. In geval van een te wijzigen SLA meldt
service level management het wijzigen van de SLA terug aan Improvement management (en
worden de consequenties via de vereiste processen geregeld).

ISM-procesmodel
Evalueren
DOEL Controleren of het risico daadwerkelijk is weggenomen
INPUT De gereed gemelde risicoafhandeling
OUTPUT Een weggenomen risico
TOELICHTING Niet van toepassing.
Controleer resultaat wijziging

DOEL Controleren of het afhandelverzoek succesvol is uitgevoerd
INPUT Een uitgevoerd afhandelverzoek
OUTPUT Een geëvalueerd afhandelverzoek
TOELICHTING Getoetst moet worden of de getroffen maatregel het gewenste effect op het risico heeft
gehad. Indien de resultaten nog niet door het uitvoerende proces met de betrokkenen op hun
effect zijn getoetst moet dit alsnog gebeuren.
De controle kan de volgende resultaten opleveren:
• de maatregel heeft het gewenste effect op het risico
• de maatregel heeft niet het gewenste effect
Risico weggenomen?
JA De maatregel heeft het gewenste effect.
NEE De maatregel heeft niet het gewenste effect. Het proces wordt opnieuw doorlopen vanaf de
activiteit 'Verzamelen en analyseren gegevens'.
Afsluiten
INPUT Een positieve beoordeling van het resultaat van de change
OUTPUT Een gemitigeerd risico
TOELICHTING Niet van toepassing.

ISM-procesmodel
Change management
DOEL Planmatig doorvoeren en coördineren van changes op de operationele omgeving en de
overeengekomen dienstverlening
INPUT Een RFC
OUTPUT Een afgesloten RFC
TOELICHTING Change management vervult een sleutelrol binnen het ISM-model.
Alle wijzigingen op de dienstverlening worden aangestuurd door dit proces.
Het bouwen van nieuwe producten, systemen of grote aanpassingen vindt, al dan niet
projectmatig, onder de regie van change management plaats. En aangezien wijzigingen de
belangrijkste aanleiding voor incidenten zijn, is het zorgvuldig doorvoeren van wijzigingen de
belangrijkste manier om incidenten te voorkomen.
In IT wordt het fenomeen release onderkend, en vaak wordt daar een apart proces voor
beschreven. Een release is echter niets anders dan een verzameling wijzigingsverzoeken die
gezamenlijk planmatig worden afgehandeld. Ook in andere vakgebieden zijn vergelijkbare
verzamelingen bekend: denk bijvoorbeeld aan een grote verbouwing, bestaande uit diverse
kleinere maar samenhangende wijzigingen.
Change management ontvangt wijzigingsverzoeken van SLM, IMP, INC en KNO, maar ook
van de klantorganisatie. Verzoeken van de klantorganisatie kunnen rechtstreeks
binnenkomen, al dan niet voorzien van een Functioneel Ontwerp.
Change management stuurt de processen operations management en configuration

management aan, en daarmee de in- of externe partijen die verantwoordelijk zijn voor het
aanpassen van (delen van) de dienstverlening.
Binnen het change-proces vindt achtereenvolgens een viertal belangrijke beslissingen plaats
die borgen dat niet alle verzoeken klakkeloos in productie worden genomen:
• accepteren - de beslissing om de RFC in behandeling te nemen (voorbereiden en
plannen);
• accorderen - de beslissing om de gevraagde wijziging te realiseren (bouwen en testen);
• vrijgeven - de beslissing om de wijziging uit te voeren (implementeren en registreren).
• goedkeuren - de bevestiging door de aanvrager dat de change naar wens is uitgevoerd.

ISM-procesmodel
Aannemen RFC
DOEL Het ontvangen, registreren en beslissen over het in behandeling nemen van een RFC
INPUT Een RFC-melding
OUTPUT Een geaccepteerde RFC
TOELICHTING Iedereen kan een RFC indienen. Afhankelijk van de aard van de aanvraag wordt bepaald of
de indiener geautoriseerd is om een aanvraag in te dienen.
Er wordt getoetst of de aanvraag daadwerkelijk een change betreft en of de aanvraag gedekt

wordt door een SLA of project, waarmee er budget beschikbaar is.
Als de RFC voortkomt uit een idee vanuit technisch beheer om de kwaliteit van de
dienstverlening te verbeteren, dient deze via IMP te lopen, om te zijn getoetst aan de
prioriteitstelling van andere verbeterinitiatieven. Uit praktische overwegingen kan ook
besloten worden dat beheerders dit soort verbetervoorstellen rechtstreeks bij CHM indienen,
waarna de prioriteitstoets in de afhandeling van de change plaats vindt.

ISM-procesmodel
Ontvangen & registreren

DOEL Het in ontvangst nemen van een RFC en registreren van de basisgegevens van de RFC
INPUT Een RFC
OUTPUT Een geregistreerde RFC
TOELICHTING Een RFC kan door een gebruiker worden ingediend of vanuit één van de processen. De
volgende gegevens moeten in ieder geval worden geregistreerd:
• de naam van de aanvrager;
• de overeengekomen service waar de change betrekking op heeft;
• het onderdeel dat gewijzigd moet worden (CI);
• de gewenste aanpassing.
Later in het proces vinden regelmatig aanvullingen op de registratie plaats. Deze
registratiemomenten zijn niet afzonderlijk in de procesbeschrijving opgenomen. Relevante
zaken worden zo spoedig mogelijk geregistreerd in het record van de betreffende RFC.

ISM-procesmodel
Aanvullen informatie
DOEL Het verzamelen van ontbrekende informatie die voor de verdere afhandeling relevant is
INPUT Een geregistreerde RFC
OUTPUT Een volledig geregistreerde RFC
TOELICHTING De informatie die tijdens deze activiteit wordt verzameld, moet voldoende zijn om de
prioriteit, complexiteit en aard van de change te kunnen bepalen. Informatie die moet
worden verzameld, verschilt per soort change:
• Valt de RFC onder een SLA? En zo niet, is er dan budget voor beschikbaar?
• Wat is de functie van de aanvrager?
• Is de betrokken servicemanager op de hoogte van deze aanvraag en heeft deze hem
geautoriseerd?
• Is de aard van de wijziging voldoende duidelijk omschreven?
• Indien de Functionaliteit wordt veranderd moet een Functioneel Ontwerp aangeleverd
worden of opgesteld worden onder regie van het CHG proces
• Wat is de achtergrond van de aanvraag (en is dit van belang voor prioriteit)?
• Et cetera.
Om de juiste informatie voor de verschillende soorten RFC's beschikbaar te krijgen, kan per
soort RFC een uitvraagscript worden gebruikt.
Accepteren change
DOEL Toetsen of de aanvraag als change moet worden behandeld.
INPUT Een volledig geregistreerde RFC
OUTPUT Een geaccepteerde RFC
TOELICHTING Er moet worden bepaald of de aanvraag in behandeling moet worden genomen. Redenen om
de aanvraag af te wijzen kunnen zijn:
• De aanvrager is niet geautoriseerd voor deze aanvraag.
• De aanvraag betreft niet het aanpassen van een CI; het is dus geen change.
• De aanvraag valt niet onder de SLA, en een alternatieve stakeholder ontbreekt.
• Er is geen budget voor de uitvoering.
• De aanvraag is strijdig met het geldende beleid.
Het is afhankelijk van het type aanvraag wie de beslissing neemt over het al dan niet verder
behandelen van de aanvraag.
Afgewezen aanvragen kunnen alsnog worden vervolgd als de reden voor afwijzing is
verholpen. Zo kan een aanvraag die is afgewezen vanwege onvoldoende budget alsnog
worden vervolgd indien de vereiste fondsen zijn toegekend.
Aanvragen die op formele gronden worden afgewezen, kunnen alsnog in behandeling worden
genomen als er voldoende autorisatie wordt aangeboord. Zo kan bijvoorbeeld een aanvraag
die strijdig is met het geldende beleid alsnog worden afgehandeld als het management deze
fiatteert - en daarmee feitelijk het beleid aanpast.
Met het accepteren van de RFC is de eerste mijlpaal in de afhandeling bereikt.
Accepteren?
JA De RFC is geaccepteerd en wordt verder afgehandeld.
NEE De RFC is niet geaccepteerd, dit wordt aan de aanvrager teruggekoppeld.
DOEL De aanvrager informeren dat de RFC niet geaccepteerd is
INPUT De beslissing om de RFC niet te accepteren
OUTPUT Informatie over de beslissing
TOELICHTING Volgens geldende afspraken wordt de aanvrager geïnformeerd over de afwijzing. Daarbij
wordt de onderbouwing voor de afwijzing vermeld.

ISM-procesmodel
Prioriteren
DOEL Het vaststellen van de correcte prioriteit van de aanvraag
INPUT Een geaccepteerde RFC
OUTPUT Een geprioriteerde RFC
TOELICHTING De prioriteit van de aanvraag is afhankelijk van de urgentie en de impact van de aanvraag.
Hiertoe vindt een beperkte analyse plaats.
De prioriteit kan bijvoorbeeld als volgt worden ingedeeld:

• Prioriteit 4 - lage prioriteit: de change is gewenst, maar kan wachten.
• Prioriteit 3 - normale prioriteit: geen hoge urgentie of grote impact, maar de change
mag niet worden uitgesteld.
• Prioriteit 2 - hoge prioriteit: het gaat om een zwaarwegende wijziging, met hoge
urgentie en/of impact.
• Prioriteit 1 - hoogste prioriteit: de RFC betreft een zaak van het grootste belang,
bijvoorbeeld een probleem dat de gebruiker(s) aanzienlijke hinder veroorzaakt in het
gebruik van essentiële services, of een wijziging met externe dwang (zoals een
ministerieel besluit).
Wanneer er sprake is van grote urgentie om de change door te voeren kan de vastgestelde
procedure in eerste instantie versneld worden doorlopen:
• De vereiste resources worden onmiddellijk vrijgemaakt
• Normale testprocedures worden alleen doorlopen als de tijd dat toelaat
• Registratie wordt alleen op hoofdlijnen gedaan
• Alle andere planningen schuiven op
Na afloop van deze spoedprocedure wordt de change alsnog behandeld volgens de geldende
afspraken: eventuele overgeslagen testen worden alsnog uitgevoerd, de administratie wordt
alsnog bijgewerkt, aanpassingen om voorlopige ingrepen definitief te maken, worden alsnog
uitgevoerd. Op deze wijze wordt de afgesproken werkwijze - weliswaar achteraf - geheel op
de urgente change toegepast.
Koppelen
DOEL Bepalen of de RFC in aanmerking komt om releasematig af te handelen.
INPUT Een geprioriteerde RFC
OUTPUT Een al dan niet gekoppelde RFC
TOELICHTING Voor sommige (delen van) de operationele omgeving kunnen wijzigingen in samenhang
worden doorgevoerd. Redenen hiervoor kunnen zijn:
• Voor het betreffende onderdeel van de operationele omgeving is bepaald dat deze
releasematig wordt beheerd.
• Het is logisch dat verschillende wijzigingen in combinatie worden uitgevoerd,
bijvoorbeeld vanuit kostenefficiency, beperking van de overlast voor de gebruikers, of
een gewenste beperking van het aantal implementatiemomenten
Een release is niets anders dan een verzameling aanpassingen die gelijktijdig worden
gebouwd, getest en geïmplementeerd.
Tijdens het koppelen wordt bekeken of een RFC onder het vastgelegde releasebeleid valt, of
omwille van andere overwegingen (efficiency, effectiviteit) beter samen kan worden
afgehandeld met een andere RFC.
Alle gegevens van de RFC die relevant zijn voor de verdere afhandeling in een gekoppelde
RFC worden meegegeven bij de koppeling. Van alle gekoppelde RFC's worden de RFC-
nummers vastgelegd in de hoofd-RFC.
In de hoofd-RFC wordt indien nodig de planning bijgesteld, zodat de nieuw aangevraagde

wijziging wordt meegenomen. Zodra de hoofd-RFC wordt afgesloten, worden ook de daaraan
gekoppelde RFC's afgesloten.
Indien om dwingende redenen een RFC later alsnog wordt toegevoegd aan een reeds verder
in afhandeling zijnde hoofd-RFC, moet daarbij zorgvuldig gekeken worden naar de impact die
dit heeft op de hoofd-RFC en de activiteiten die deze hoofd-RFC inmiddels heeft doorlopen.

ISM-procesmodel
Informeren aanvrager
DOEL De aanvrager van de RFC informeren over het in behandeling nemen van de RFC
INPUT Een geprioriteerde, al dan niet gekoppelde, RFC
OUTPUT Een bevestigde RFC
TOELICHTING Hierbij wordt aangegeven volgens welke prioriteit de RFC wordt afgehandeld. Deze prioriteit
kan in de SLA aan een algemeen geldende afhandeltijd zijn gekoppeld. Op deze wijze krijgt
de aanvrager een eerste indicatie van het tijdschema van de afhandeling. In de definitieve
planning wordt later het exacte afhandelschema bepaald.
Classificeren
DOEL Het vaststellen van de gevolgen van het bouwen en implementeren van de RFC en het
vaststellen van de categorie van de RFC.
INPUT Een geaccepteerde RFC
OUTPUT Een geanalyseerde RFC
TOELICHTING Tijdens het classificeren wordt de change-categorie vastgesteld. De categorie is bepalend
voor de afhandelingswijze van een RFC. Ook vindt tijdens het classificeren een impactanalyse
plaats naar de gevolgen die de uitvoering van de RFC kan hebben. Een goede classificatie
levert de informatie, op basis waarvan besloten wordt of de RFC daadwerkelijk gerealiseerd
gaat worden en de vorm waarin dit gebeuren moet.
Categoriseren
DOEL Het bepalen van de categorie van de aanvraag
INPUT Een bevestigde RFC; eventueel gekoppelde RFC's
OUTPUT Een gecategoriseerde RFC
TOELICHTING De change-categorie is van belang voor de besluitvorming over, en de afhandeling van de
change.
De categorisering vindt plaats op basis van de impact die de change kan hebben op de
services, de operationele omgeving en de organisatie. De categorie wordt bepaald door het
vaststellen van de complexiteit, het risico, en de resources (kosten). De complexiteit en
risico’s hebben betrekking op technische (hoe moeilijk is de wijziging) en organisatorische
(wie zijn bij de wijziging betrokken) aspecten.
Om de categorie te kunnen bepalen, vindt een eerste beperkte analyse van de impact,
complexiteit, risico’s en kosten plaats.
Changes kunnen in bijvoorbeeld vier categorieën worden ingedeeld:

Categorie 0 - zeer geringe gevolgen: de uitvoerder beslist. Veel categorie 0 changes
kunnen na vaststelling van de bijbehorende instructie door change management als een
‘standaardchange’ worden afgehandeld.
Categorie 1 - geringe gevolgen: de changemanager (of coördinator) beslist. Soms kunnen
categorie 1 changes als standaardchange worden afgehandeld.
Categorie 2 - grote gevolgen: de changemanager beslist. Een impactanalyse is verplicht.
De changemanager raadpleegt de CAB.
Categorie 3 - zeer grote gevolgen: de changemanager betrekt het management bij de
change, en beslist daarna pas na advies van de CAB. Een impactanalyse is nodig.
Vaak wordt voor riskante, complexe of omvangrijke wijzigingen een tijdelijke

projectorganisatie gevormd om deze uit te voeren. Vaak is voor dergelijke wijzigingen zelfs
een apart proces gedefinieerd: het projectproces. Een project is echter niets anders dan een
wijziging die door een speciaal daarvoor samengesteld team wordt doorgevoerd. Daarmee is
ook voor projecten het proces change management onverkort van kracht.

ISM-procesmodel
Analyseren
DOEL Het opleveren van de gegevens die nodig zijn om een globaal plan te kunnen opstellen en te
kunnen beslissen over het uitvoeren van de change
INPUT Een gecategoriseerde RFC
OUTPUT Een geanalyseerde RFC
TOELICHTING Het doorvoeren van changes heeft vaak onverwachte gevolgen en is één van de
hoofdoorzaken van grote incidenten. Om verrassingen te voorkomen is de uitvoering van een
passende analyse gewenst.
Voor RFC’s van de categorie 2 en 3 is het uitvoeren van de analyse in de vorm van een
impactanalyse verplicht. Deze impactanalyse bevat alle informatie die nodig is om te kunnen
besluiten over het al dan niet accorderen van de aanvraag.
Er wordt een inschatting gemaakt van de middelen (geld, uren) die nodig zijn om de change
door te voeren, maar ook van de functionaliteit die (mogelijk) beïnvloed wordt en de
organisatieonderdelen die betrokken zijn bij de uitvoering of de gevolgen van de change. Ook
wordt geadviseerd of en in welke omvang testen nodig zijn voordat tot implementatie wordt
overgegaan.
Voor RFC’s van de categorie 1 wordt per RFC besloten of een impactanalyse nodig is.
In alle gevallen wordt gelet op het beïnvloeden van bestaande continuïteitsplannen.

ISM-procesmodel
Plannen & accorderen

DOEL Beslissen over de uitvoering en planning van de RFC
INPUT Een geanalyseerde RFC

OUTPUT Een geaccordeerde RFC
TOELICHTING Er wordt aan de hand van een globaal plan besloten of de RFC geaccordeerd kan worden en
welke (in- of externe) partijen betrokken zijn bij het accorderen van de RFC.

ISM-procesmodel
Bepalen betrokkenen
DOEL Bepalen welke functionarissen worden betrokken bij de planning en besluitvorming over de
RFC
INPUT Een geanalyseerde RFC
OUTPUT Een toegekende RFC
TOELICHTING Afhankelijk van de vastgestelde change-categorie wordt bepaald bij wie de besluitvorming
ligt.
Een veel toegepaste en goed werkende indeling is:
Categorie 0 - De uitvoerder beslist zelfstandig.
Categorie 1 - De changemanager (of coördinator) beslist.
Categorie 2 - De changemanager beslist na advies van de CAB. De samenstelling van
de CAB voor deze RFC wordt daartoe bepaald.
Categorie 3 - De changemanager raadpleegt eerst het management en beslist daarna
op advies van de CAB.
Afhankelijk van de specificaties van de change wordt bekeken wie bij het overleg over de
planning moet worden betrokken. De lijst met betrokkenen wordt vastgelegd. Onder
betrokkenen vallen bijvoorbeeld:
• een vertegenwoordiger van het team dat de change in productie neemt
• de servicemanager van de service die wordt gewijzigd; deze servicemanager
vertegenwoordigt de klant van de betrokken service; desgewenst kan de klant ook direct
worden betrokken
• de behandelaar van de change
• een vertegenwoordiger van het team dat de change zal realiseren
• een vertegenwoordiger van het team dat de gewijzigde service in productie zal nemen
• een vertegenwoordiger van een externe partij die een bijdrage moet leveren aan de
realisatie van de change
Opstellen afhandelingsvoorstel
DOEL Het opstellen van een RFC-afhandelingsvoorstel om goed onderbouwd te kunnen accorderen
INPUT Een toegekende RFC
OUTPUT Een globaal geplande change
TOELICHTING Om de change te kunnen accorderen, moet voldoende informatie beschikbaar zijn. Voor
categorie 2 en 3 changes wordt een onderbouwd voorstel opgesteld waarin de afhandeling
staat beschreven. Voor categorie 1 changes kan worden volstaan met een kort advies zonder
onderbouwing.
De eventueel opgestelde impactanalyse, de RFC-aanvraag, de gemaakte afspraken en de
informatie uit de CMDB dienen als basis voor het opstellen van het afhandelingsvoorstel.
Bij het opstellen van het voorstel wordt gebruik gemaakt van de kennis en inzichten van alle
betrokkenen.
Onderdeel van het voorstel is een tijdsplanning waarbij rekening wordt gehouden met reeds
geplande changes (de changekalender), maar ook met afgesproken onderhoudsvensters en
andere omstandigheden.
Bij grote changes zal vaak een formeel projectplan worden opgesteld met alle daartoe
vereiste elementen. Voor een eenvoudige change kan worden volstaan met een eenvoudig
plan. Het globaal plan bevat de keuze en planningselementen op hoofdlijnen: een globaal
tijdplan, een globaal resourceplan, de in te zetten techniek en methodiek, de mate en
omvang van testen, et cetera. Het globaal plan moet voldoende informatie bevatten om op
basis daarvan de besluitvorming verantwoord te laten plaatsvinden.
Indien de change een samengestelde change betreft (bijvoorbeeld een release), dan zal de
planning voorzien in de integrale afhandeling van alle gekoppelde RFC's.
Indien een gekoppelde RFC een andere prioriteit krijgt of aan een ander tijdschema moet
worden onderworpen dan de samengestelde change, dan wordt deze RFC alsnog
losgekoppeld van de samengestelde change en zelfstandig verder in het change-proces
afgehandeld.
In alle gevallen wordt gelet op het beïnvloeden van bestaande continuïteitsplannen.

ISM-procesmodel
Accorderen RFC
DOEL Beslissen of de aangevraagde change gerealiseerd gaat worden
INPUT Een globaal geplande change
OUTPUT Een geaccordeerde change
TOELICHTING Bij de besluitvorming worden de relevante betrokkenen uitgenodigd. Categorie 2 en 3
changes worden behandeld in het CAB. In die CAB wordt het afhandelingvoorstel beoordeeld
in samenhang met de overige informatie over de change.
Er kunnen redenen zijn om, in overleg met de aanvrager, af te wijken van het voorstel (of
het voorstel zelfs niet door te voeren):
• Het doorvoeren van de change brengt het servicelevel in gevaar.
• Er is onvoldoende budget voor de change.
• Er zijn onvoldoende resources beschikbaar (de resources zijn bijvoorbeeld te laat
aangevraagd).
Op basis van de gegevens uit de analyse wordt een afweging gemaakt of de RFC moet
worden:
• uitgevoerd in de vorm waarin deze is uitgewerkt of;
• aangepast voordat deze kan worden uitgevoerd of;
• geweigerd en definitief niet wordt uitgevoerd.
In alle gevallen wordt aangegeven of en hoe er getest moet worden en tegen welke
acceptatiecriteria.
De changemanager neemt de uiteindelijke beslissing. In het geval van de categorie 0 heeft

hij deze taak gedelegeerd aan de afhandelaar. In grotere organisaties zal de changemanager
taken delegeren aan een changecoördinator.
Indien de RFC is afgewezen wordt de aanvrager geïnformeerd en wordt vervolgd met de

evaluatie en afsluiting van de RFC.
Met het accorderen van de RFC is de tweede mijlpaal in de afhandeling van de change
bereikt.
Akkoord?
JA De RFC is geaccepteerd en zal gerealiseerd worden.
NEE De RFC is afgewezen, de aanvrager wordt hierover worden geïnformeerd en de RFC wordt
afgesloten.
DOEL De aanvrager informeren dat de RFC niet geaccordeerd is
INPUT De beslissing om de RFC niet te accorderen

ISM-procesmodel
Voorbereiden change
DOEL Het testgereed opleveren van een change
INPUT Een geaccordeerde change
OUTPUT Een voorbereide en beheerbare change
TOELICHTING Het uitvoeren van alle activiteiten die nodig zijn om de wijziging gereed te krijgen voor het
testen en implementeren. Hieronder vallen activiteiten zoals:
• construeren, bouwen, programmeren
• reviewen
• valideren
• het bestellen van middelen
• het maken van handleidingen
• het assembleren van onderdelen
• het opleiden en instrueren van betrokkenen
• het opstellen van het implementatieplan
Detailleren planning
DOEL Het uitwerken van de globale planning tot een gedetailleerd plan
INPUT Een geaccordeerde RFC
OUTPUT Een gedetailleerd geplande change
TOELICHTING Voor kleine changes zal in deze activiteit weinig of niets gebeuren, voor grotere changes
(soms in de vorm van projecten) zal een gedetailleerder implementatieplan worden opgesteld
waarin wordt beschreven welke producten, onder welke condities, door wie wanneer moeten
worden opgeleverd. Er moet ook een roll-backplan worden opgenomen in het gedetailleerde
implementatieplan. Daartoe wordt de uitgangssituatie van de change vastgelegd (baseline).
In alle gevallen wordt gelet op het beïnvloeden van bestaande continuïteitsplannen en
worden zo nodig vereiste acties gepland om ongewenste consequenties te vermijden.
Uitvoeren voorbereiding
DOEL Het uitvoeren van alle voorbereidende activiteiten om de change testgereed te kunnen
opleveren
INPUT Een gedetailleerd geplande change
OUTPUT Een voorbereide change
TOELICHTING Deze activiteit bevat alle handelingen die moeten worden uitgevoerd om de wijziging testen
implementatiegereed te kunnen opleveren. Deze activiteit wordt ook wel het 'bouwen van de
change' genoemd.
In deze activiteit wordt bijvoorbeeld een nieuwe versie van een toepassingsprogramma
ontwikkeld of aangeschaft, of wordt apparatuur besteld, gekocht en geassembleerd.
Als het voorbereiden van de change een grote doorlooptijd heeft, moet tussentijds
voortgangsinformatie teruggekoppeld worden aan de vastgestelde betrokkenen. Deze
terugkoppeling moet ook plaatsvinden zodra van de planning wordt afgeweken.

ISM-procesmodel
Voorbereiden beheer
DOEL Het voorbereiden van de beheerorganisatie om de te implementeren change te kunnen
beheren
INPUT Een voorbereide change
OUTPUT Een voorbereide en beheerbare change
TOELICHTING Deze activiteit moet ervoor zorgen dat de beheerorganisatie in staat is om na implementatie
de gewijzigde omgeving te kunnen beheren. Onder het voorbereiden van het beheer valt
bijvoorbeeld:
• het documenteren van de change
• het maken van werkinstructies
• het opleiden van medewerkers
• het aanpassen van openstellingtijden
• het aanpassen van de capaciteit
• het maken van afspraken met interne en externe partijen
• het maken van aangepaste continuïteitsplannen

ISM-procesmodel
Testen & vrijgeven

DOEL Het vaststellen van de kwaliteit van de voorbereide change, waarna de change wordt
vrijgegeven voor implementatie
INPUT Een voorbereide en beheerbare change
OUTPUT Een vrijgegeven of afgewezen change
TOELICHTING Voor verschillende opleveringen, in verschillende stadia, kunnen meerdere testvormen
bestaan die soms sequentieel en soms parallel plaatsvinden. Dit zijn testen die door de
leverancier worden uitgevoerd en testen die door de klant worden uitgevoerd.
Pas als alle controles zijn uitgevoerd en goedgekeurd wordt de change vrijgegeven.

ISM-procesmodel
Opstellen testplan
DOEL Bepalen op welke wijze het testen gaat plaatsvinden
INPUT Een voorbereide en beheerbare change
OUTPUT Een voorbereide change met testplan
TOELICHTING Bij het accepteren van de change is besloten of en in hoe er getest gaat worden. Testplannen
kunnen variëren van een paar regels tekst tot uitgebreide draaiboeken, afhankelijk van de
aard van de change. Indien geen test vereist is en de omstandigheden niet veranderd zijn
blijft het testplan beperkt tot het vaststellen van de verplichte controleactiviteiten.
Het is denkbaar dat er zelfs niet getest wordt, omdat de betrokkenen daartoe geen aanleiding
zien. In dat geval wordt dat ook vastgelegd. Testen heeft alles te maken met
risicomanagement: als er veel of ernstige risico's worden onderkend, zal er uitgebreider
getest worden dan wanneer beperkte risico's worden onderkend.
Uitvoeren interne test

DOEL Het intern testen van de voorbereide change
INPUT Een voorbereide change met testplan
OUTPUT Een intern geteste change
TOELICHTING Voordat de klant testen uitvoert, wordt intern getest of de change overeenkomt met de
specificaties.
Hieronder kunnen diverse vormen van testen vallen, zoals steekproef, functionaliteittest,
systeemtest, productie-acceptatietest, et cetera.
Gelukt?
JA De interne test is succesvol verlopen.
NEE De interne test is niet succesvol verlopen, het proces zal vanaf de activiteit "Detailleren
planning" (CHM4.1) opnieuw worden doorlopen.
Uitvoeren klanttest
DOEL Het door de aanvrager (klant of interne medewerker) laten testen of de voorbereide change
voldoet aan de wensen
INPUT Een intern geteste change
OUTPUT Een door de aanvrager geteste change
TOELICHTING Als de klant de aanvraag heeft ingediend, zal de klant ook een bijdrage moeten leveren aan
het testen. Maar ook als de wijziging door een interne medewerker is aangevraagd, is het
mogelijk dat de gewijzigde service aan de kant van de klant moet worden getest.
De klant zal op verschillende momenten moeten testen of de change voldoet aan de eisen.
Hieronder vallen bijvoorbeeld de functionele acceptatietest en de gebruikersacceptatietest.
Gelukt?
JA De klanttest is succesvol verlopen.
NEE De klanttest is niet succesvol verlopen, het proces zal vanaf de activiteit "Detailleren
planning" (CHM. 4.1) opnieuw worden doorlopen.

ISM-procesmodel
Vrijgeven voor implementatie

DOEL Besluiten of de gebouwde en geteste change geïmplementeerd mag worden
INPUT Een door de aanvrager geteste change
OUTPUT Een vrijgegeven of afgewezen change
TOELICHTING In deze activiteit wordt een beslissing genomen over het al of niet implementeren van de
geteste change, met inbegrip van de detailplanning, het implementatieplan. Dat
implementatieplan wordt dus mede getoetst. Als de change met inbegrip van het
implementatieplan wordt geaccepteerd weten alle betrokkenen precies wat van hen verwacht
wordt: er zijn geen verrassingen meer mogelijk bij de implementatie van de change.
Afhankelijk van de aard van de aanstaande implementatie wordt bepaald wie betrokken is bij
de besluitvorming over de implementatie. Bij categorie 2 en 3 changes loopt de
besluitvorming via het CAB. De betrokkenen nemen de testresultaten en alle overige
beschikbare informatie in ogenschouw en beoordelen of de change naar hun mening
verantwoord kan worden geïmplementeerd volgens het implementatieplan. De
changemanager neemt dan de uiteindelijke beslissing.
Er kunnen verschillende aanleidingen zijn om een change op een ander dan het voorgenomen
tijdstip te implementeren, aangepast te implementeren of zelfs af te wijzen:
• Als de serviceafspraken bedreigd worden door de implementatie. Actie: De change wordt
afgewezen of uitgesteld.
• Als de nieuwe situatie onvoldoende beheersbaar is. Actie: De change wordt aangepast of
afgewezen.
• Als de nieuwe situatie onvoldoende onderhoudbaar is door technisch applicatie- of
systeembeheer. Actie: De change wordt aangepast of afgewezen.
• Als er strijdigheden zijn met de actuele situatie of lopende activiteiten. Actie: De change
wordt aangepast of afgewezen.
• Als de testresultaten daar aanleiding toe geven. Actie: De change wordt afgewezen.
Als er besloten wordt om nog niet te implementeren, moet bepaald worden vanaf welke
processtap het proces opnieuw doorlopen moet worden.
Op basis van de testbevindingen kan besloten worden, om de geplande wijziging slechts

gedeeltelijk door te voeren. Daarbij moet ook besloten worden op welke wijze het niet
geïmplementeerde deel van het wijzigingsverzoek afgehandeld gaat worden.
Als er definitief besloten wordt om niet te implementeren, dan wordt de aanvrager van de
RFC hierover geïnformeerd.
Met het vrijgeven van de RFC is de derde mijlpaal in de afhandeling bereikt.
Vrijgeven?
JA De change is vrijgegeven voor implementatie en zal worden geïmplementeerd volgens het
implementatieplan.
NEE Nee, de change wordt:
• Uitgesteld - de change zal op een later (meer opportuun) tijdstip worden
geïmplementeerd. Het proces zal vanaf de processtap "Plannen en Accorderen" (CHM. 3)
opnieuw worden doorlopen.
• Aangepast - De change is nog niet vrijgegeven en zal opnieuw worden voorbereid. Het
proces zal vanaf de processtap "Voorbereiden Change" (CHM.4) opnieuw worden
doorlopen.
• Afgewezen - De change is afgewezen en zal niet worden geïmplementeerd. Alle
betrokkenen, inclusief de aanvrager van de RFC worden geïnformeerd. De change wordt
afgesloten (CHM.7).
DOEL De aanvrager informeren dat de RFC is afgewezen
INPUT De beslissing om de RFC niet te implementeren

ISM-procesmodel
Implementeren
DOEL Het implementeren en goedkeuren van een change
INPUT Een vrijgegeven change
OUTPUT Een goedgekeurde change
TOELICHTING Tijdens deze processtap wordt de gebouwde en geteste change geïmplementeerd volgens het
geaccepteerde implementatieplan. Daarna wordt getoetst of het resultaat overeenkomt met
de oorspronkelijke specificatie. Indien de change in de gewenste situatie resulteert, wordt
deze goedgekeurd.
Werkzaamheden aan de kant van de klant worden in het implementatieplan meegenomen.

Hieronder kunnen bijvoorbeeld gebruikerstrainingen vallen.
Informeren betrokkenen
DOEL Het voorafgaand aan de implementatie informeren van alle betrokkenen
INPUT Een vrijgegeven change
OUTPUT Een gecommuniceerde change
TOELICHTING Alle betrokkenen die activiteiten moeten uitvoeren of consequenties ondervinden van het
implementeren van de change moeten vooraf geïnformeerd worden. Dit kunnen medewerkers
van de servicedesk zijn, externe partijen, beheerders, gebruikers, et cetera.

ISM-procesmodel
Implementeren wijziging
DOEL Het (laten) implementeren van de gebouwde change in de productieomgeving
INPUT Een gecommuniceerde change
OUTPUT Een geïmplementeerde change
TOELICHTING Door het uitvoeren van de implementatie volgens het implementatieplan wordt de gebouwde
wijziging operationeel. Als er ernstige problemen ontstaan tijdens de implementatie moet
overwogen worden een roll-back uit te voeren.
Om alle aan handelingen aan de operationele omgeving op elkaar te kunnen afstemmen

vinden in het ISM-model alle acties op de operationele omgeving plaats via het proces
operations management. Dit betekent dat vanuit het change management-proces een
verzoek tot uitvoering wordt ingediend. Een eventueel opgesteld implementatieplan wordt als
instructie toegevoegd bij het implementatieverzoek. De uitvoerders van de implementatie
zijn al in het begin van de change-afhandeling onderkend als betrokkenen. Zij zijn waar nodig
betrokken bij het plannen, accorderen en vrijgeven van de change, en hebben ingestemd met
hun rol in het implementatieplan. In deze activiteit 'Implementeren wijziging' voeren zij
volgens dat implementatieplan hun taken uit.
Voor zover nodig worden gebruikerstrainingen in deze fase onder het implementatieplan
meegenomen. Ook andere niet-technisch-infrastructurele zaken zoals het uitgeven en borgen
van release notes worden in deze fase meegenomen.
Het operations management-proces koppelt na implementatie vervolgens terug of de
uitvoering goed is verlopen.
Toetsen gewenst resultaat

DOEL Het toetsen of het gewenste resultaat is gerealiseerd
INPUT Een geïmplementeerde change
OUTPUT Een getoetste change
TOELICHTING Direct na het doorvoeren wordt intern bekeken of het doorvoeren is gelukt of niet.
Gelukt?
JA De implementatie is gelukt.
NEE De implementatie is niet gelukt. Het proces wordt vanaf de activiteit CHM.1.4 Prioriteren
opnieuw doorlopen om alsnog tot een geslaagde implementatie te komen.
Registreren in de CMDB
DOEL Het initiëren van de vastlegging van de gewijzigde situatie in de CMDB
INPUT Een getoetste change
OUTPUT Een in de CMDB geregistreerde change
TOELICHTING Het registreren in de CMDB vindt plaats onder aansturing van het proces knwoledge
management.
Als de change betrekking heeft op een bestaand CI, zullen gedurende het changetraject
regelmatig aanpassingen worden ingevoerd in de CMDB.
Goedkeuren change
DOEL Het goedkeuren van de change door de aanvrager
INPUT Een in de CMDB geregistreerde change
OUTPUT Een goedgekeurde change
TOELICHTING Het goedkeuren van de change is een controleactiviteit van de aanvrager (meestal iemand uit
de gebruikersorganisatie). De change wordt goedgekeurd als de gewijzigde situatie goed
functioneert en voldoet aan de wensen.
Na goedkeuring door de aanvrager stopt de afhandeltijd van de change. Een change mag pas
worden afgesloten nadat de aanvrager de werking van de implementatie heeft kunnen
toetsen en heeft goedgekeurd. Door goed te keuren is de aanvrager ook geïnformeerd over
het feit dat zijn RFC is afgehandeld.
Ook gekoppelde RFC's worden op deze wijze hier finaal goedgekeurd.
Met het goedkeuren van de RFC is de vierde en laatste mijlpaal in de afhandeling bereikt.

ISM-procesmodel
Goedgekeurd?
JA De aanvrager is geïnformeerd en heeft het resultaat van de geïmplementeerde change
goedgekeurd.
NEE De aanvrager heeft het resultaat niet geaccepteerd, het proces wordt vanaf de activiteit
CHM.1.4 Prioriteren opnieuw doorlopen om tot een geslaagde implementatie te komen.
Afsluiten
DOEL Het correct afsluiten van een RFC
INPUT Een goedgekeurde change, of een afgewezen change
OUTPUT Een afgesloten change
TOELICHTING De registratie wordt bijgewerkt.
Ook de eventueel aan de hoofd-RFC gekoppelde RFC's worden hier bijgewerkt en afgesloten.
Evalueren RFC
DOEL Het verzamelen van informatie om changes in de toekomst beter te kunnen afhandelen en de
betrokkenen gelegenheid te bieden hun ervaringen en kritiek door te geven
INPUT Een goedgekeurde change of een afgewezen change
OUTPUT Een geëvalueerde change
TOELICHTING Het is niet nodig alle changes uitgebreid te evalueren. Wel moeten grote changes en changes
waarin gedurende de afhandeling fouten zijn geconstateerd in ieder geval geëvalueerd
worden.
Bij een goedgekeurde change wordt met de direct betrokkenen besproken of de wijze waarop
de RFC is afgehandeld correct is geweest, en of er aanleiding is om het proces, de procedure,
of de werkinstructies aan te passen.
Bij een afgewezen change wordt gekeken waar het mis is gegaan, en welke consequenties
daaraan kunnen worden gekoppeld.
Bijwerken change-record
DOEL Het change-record vullen met alle verplichte en relevante informatie
INPUT Een geëvalueerde change
OUTPUT Een bijgewerkt change-record
TOELICHTING Het volledig bijwerken van het change-record is van belang om te kunnen rapporteren over
de efficiency en zorgvuldigheid waarmee RFC's zijn afgehandeld.
Een volledig bijgewerkt change-record is ook van belang om bij later optredende incidenten
over informatie te beschikken die het traceren van oorzaken kan versnellen.

ISM-procesmodel
Toetsen implementatieplangeschiktheid
DOEL Bepalen of de wijze waarop de change is afgehandeld geschikt is voor herhaalde toepassing
(als standaard, template)
INPUT Een bijgewerkt change-record
OUTPUT Een op standaardisatie getoetste change
TOELICHTING Bepalen of de wijze waarop de RFC is uitgevoerd geschikt is om toe te voegen aan de
standaardchanges. Dit kan door het opstellen van een nieuwe RFC. Ook kan nuttige
informatie worden toegevoegd aan de knowledge base.
Afsluiten change
DOEL Het afsluiten van de RFC
INPUT Een op standaardisatie getoetste change
OUTPUT Een afgesloten RFC
TOELICHTING Door het afsluiten van de RFC stopt de doorlooptijd van de RFC. Eventuele gekoppelde
changes worden nu ook afgesloten.

ISM-procesmodel
Incident management
DOEL Het zo snel als nodig herstellen van de service conform de afspraken die daarover in de SLA
zijn gemaakt
INPUT Een incidentmelding
OUTPUT Een afgesloten incident
TOELICHTING In het proces incident management worden reactief de gevolgen van (dreigende) storingen in
services weggenomen of verminderd, en wordt ervoor gezorgd dat de gebruikers zo snel
mogelijk weer aan het werk kunnen, conform de afspraken die daarover zijn
overeengekomen. Daartoe worden incidenten geregistreerd, geclassificeerd, aan de juiste
specialisten toegewezen, geanalyseerd, op voortgang bewaakt, opgelost en weer afgesloten.
Incident management is van vitaal belang voor de overige ISM-processen, omdat het
waardevolle informatie verzamelt en vastlegt over storingen in de dienstverlening en de
onderliggende operationele omgeving.

ISM-procesmodel
Aannemen incident
DOEL Het registreren van een incidentmelding en deze aannemen en prioriteren, of afwijzen
OUTPUT Een geprioriteerd en teruggemeld incident, of een afgewezen incidentmelding
TOELICHTING Het is van belang om direct bij de aanmelding van het incident vast te stellen óf er wel
sprake is van een incident volgens de geldende afspraken. Het bepalen van de prioriteit is
van belang om vast te stellen hoe snel het incident moet worden opgelost. De snelheid is ook
afhankelijk van wat er is afgesproken in de SLA. Voor de aanmelder is het van groot belang
om te weten wanneer hij mag verwachten dat de service hersteld is.

ISM-procesmodel
Ontvangen en registreren
DOEL Het in ontvangst nemen van een incidentmelding en registreren van de basisgegevens van de
incidentmelding
OUTPUT Een geregistreerde incidentmelding
TOELICHTING Een incidentmelding kan door een gebruiker worden ingediend of kan via monitoring
afkomstig zijn uit het proces operations management. Meldingen uit operations management
zijn meldingen die door monitoringtools worden gegenereerd, of meldingen die worden
gedaan door medewerkers of door een leverancier.
De volgende gegevens moeten in ieder geval worden geregistreerd:

• De naam van de aanmelder.
• De service die door het incident verstoord wordt.
• De omschrijving van het incident.
Later in het proces vinden regelmatig aanvullingen op de registratie plaats. Deze

registratiemomenten zijn niet afzonderlijk in de procesbeschrijving opgenomen. Relevante
zaken worden zo spoedig mogelijk geregistreerd in het incidentrecord van het betreffende
incident.
Aanvullen informatie
DOEL Het verzamelen van ontbrekende informatie die voor de verdere afhandeling van de
incidentmelding relevant is
INPUT Een geregistreerde incidentmelding
OUTPUT Een volledige incidentmelding
TOELICHTING Het verzamelen van alle informatie die nodig is om de prioriteit en aard van de
incidentmelding te kunnen bepalen, om zo de verdere afhandeling mogelijk te maken.
Accepteren incident
DOEL Toetsen of de melding als incident moet worden behandeld
INPUT Een volledige incidentmelding
OUTPUT Een geaccepteerd incident of een afgewezen incidentmelding
TOELICHTING Het proces incident management is ingericht om gebruikers zo snel als nodig te helpen als
een service, waarover supportafspraken zijn gemaakt, niet (goed) functioneert.
Niet alle incidentmeldingen worden daadwerkelijk geaccepteerd. Een incidentmelding kan om

de volgende redenen worden afgewezen:
• De omgeving waar het incident zich afspeelt, is niet in beheer.
• Het incident valt niet binnen de overeengekomen serviceafspraken (openstelling,
functionaliteit).
• Er is geen sprake van een incident, maar een andersoortig verzoek
Wanneer er sprake is van een andersoortig verzoek, dan kan de call in het desbetreffende
proces worden afgehandeld:
• Wanneer een gebruiker iets anders wil dan is afgesproken, moet hij daarover via zijn
management aangepaste SLA-afspraken laten maken.
• Het kan ook zijn dat een gebruiker eigenlijk iets gewijzigd wil hebben (binnen de SLA-
afspraken); dan zal de melding als een RFC worden behandeld (en volgens de daarvoor
geldende voorschriften moeten worden ingediend).
• Vragen om gebruikersondersteuning bij de toepassing van een service zijn geen
incidenten maar service requests en worden afgehandeld door het proces operations
management.
Incident accepteren?
JA Het incident is geaccepteerd en de afhandeling wordt voortgezet.
NEE De incidentmelding is afgewezen en de aanmelder wordt hiervan op de hoogte gesteld.
DOEL De aanmelder van een incidentmelding informeren dat de incidentmelding is afgewezen
INPUT De beslissing dat de incidentmelding is afgewezen
OUTPUT De informatie dat de incidentmelding is afgewezen
TOELICHTING De aanmelder wordt geïnformeerd over het besluit dat het incident niet verder in behandeling
wordt genomen

ISM-procesmodel
Bepalen prioriteit
DOEL Het vaststellen van de prioriteit van het incident
INPUT Een geaccepteerd incident
OUTPUT Een geprioriteerd incident
TOELICHTING De prioriteit is afhankelijk van de impact (hoe ernstig is de verstoring) en urgentie (welke
tijdsdruk ligt er op de afhandeling van het incident) van het incident.
Incidenten met een gelijke impact en urgentie krijgen een gelijke prioriteit ongeacht de
service waar ze betrekking op hebben. In de SLA is per service vastgelegd welke maximale
oplostijd geldt voor alle mogelijke prioriteiten. De prioriteit wordt bepaald volgens een
vastgestelde prioriteitenmatrix.
De prioriteit in combinatie met de SLA bepaalt dus de maximale oplostijd en daarmee de
onderlinge volgorde waarin incidenten worden afgehandeld. Incidenten betreffen vrijwel altijd
situaties die overlast voor de gebruiker veroorzaken, het streven moet dan ook altijd zijn om
incidenten zo snel mogelijk op te lossen.
Indien tijdens de behandeling van het incident de omstandigheden veranderen, kan het
noodzakelijk zijn om de prioriteit aan te passen.
Koppelen
DOEL Beoordelen of een aangemeld incident onderdeel is van een 'major incident'
INPUT Een geprioriteerd incident
OUTPUT Een gekoppeld of niet-gekoppeld incident
TOELICHTING Door losse incidenten te koppelen aan een major incident of groepsincident kunnen deze in
één keer afgehandeld worden.
De afhandeling van het gekoppelde incident wordt in dit geval vervolgd in het incident waar
het nu aan gekoppeld is. Het gekoppelde incident kan op een passende status worden gezet.
Nadat het gekoppelde incident is afgesloten, worden ook de initiële incidenten afgesloten.
Gekoppeld?
JA Het incident is gekoppeld. De afhandeling verloopt verder via het incident waaraan het
gekoppeld is. De status van het incident wordt op bijv. 'gekoppeld' gezet en het incident
wordt afgesloten op het moment dat het gekoppelde incident wordt afgesloten.
NEE Het incident is niet gekoppeld, het incident wordt zelfstandig behandeld.
Informeren indiener
DOEL De aanmelder van een incidentmelding informeren dat het incident geaccepteerd is en
eventueel gekoppeld
INPUT Een geprioriteerd incident
OUTPUT Een teruggemeld incident
TOELICHTING De aanmelder wordt geïnformeerd over het in behandeling nemen van het incident.

ISM-procesmodel
Categoriseren & matchen

DOEL Het bepalen van de categorie en de complexiteit van het incident ten behoeve van verdere
afhandeling, en het vaststellen of een soortgelijk incident al eerder is voorgekomen en of er
al een oplossing beschikbaar is.
INPUT Een teruggemeld incident
OUTPUT Een toegekend (geclassificeerd) incident
TOELICHTING Het bepalen van het type en de complexiteit is van belang voor het kiezen van de
oplosgroep: afhankelijk van de aard en de complexiteit van het incident wordt de juiste
oplosgroep gekozen.
Door te matchen kunnen incidenten sneller, effectiever en goedkoper worden opgelost. Het
succes van het matchen is afhankelijk van een goed gevulde en toegankelijke knowledge-
base en een goede registratie van incidenten. Of er nu wel of niet een match gevonden is, er
wordt altijd een oplosgroep vastgelegd die verantwoordelijk is voor de verdere afhandeling.
Bepalen categorie & complexiteit

DOEL Het inschatten van de categorie en de complexiteit van het incident
INPUT Een teruggemeld incident, een gekoppeld incident
OUTPUT Een gecategoriseerd incident
TOELICHTING De categorie en de vastgestelde complexiteit dragen bij aan de selectie van de meest
geschikte oplosgroep. Zo kan een IT-incident bijvoorbeeld worden gecategoriseerd volgens
de volgende indeling, gebaseerd op de vermoede oorsprong van het incident of de benodigde
oplosgroep:
• Centrale verwerking - toegang, machine, server, applicatie.
• Netwerk - router, segment, hub, IP-adres.
• Werkstation & randapparatuur - beeldscherm, netwerkkaart, diskdrive, toetsenbord,
printer, scanner.
• Gebruik & functionaliteit - capaciteit, beschikbaarheid, back-up, handleiding.
• Organisatie & procedures - bestelling, aanvraag, ondersteuning, communicatie.
Op basis van de gewenste detaillering in het proces incident management, de specifieke

competenties en bevoegdheden binnen de organisatie, en de beheerde operationele
omgeving kan hier een eigen indeling voor worden gehanteerd. Zo zal bijvoorbeeld een
eenvoudig incident door een servicedesk kunnen/mogen worden afgehandeld, maar wordt
een complex incident door een specialistische backoffice afdeling afgehandeld.

ISM-procesmodel
Bepalen match
DOEL Bepalen of gelijke of vergelijkbare incidenten al eerder zijn voorgekomen
INPUT Een gecategoriseerd incident
OUTPUT Een wel of niet gematcht incident
TOELICHTING Door te onderzoeken of een gelijk of vergelijkbaar incident eerder is voorgekomen, kan uit de
records van die incidenten nuttige informatie worden gehaald ten behoeve van het bepalen
van de oplossing.
Ook in de kennisdatabase wordt gekeken of bij overeenkomende situaties
standaardoplossingen zijn gedefinieerd.
Sommige gevonden incidentoplossingen zijn zo duidelijk, eenvoudig en direct toepasbaar dat
deze oplossingen mogen worden overgenomen. Andere oplossingen vergen wellicht enige
aanpassing, maar kunnen op die manier wel bijdragen aan het vinden van de juiste
oplossing.
Oplosgroep bepalen
DOEL Het vaststellen van de oplosgroep
INPUT Een wel of niet gematcht incident
OUTPUT Een toegekend incident
TOELICHTING Op basis van de categorie en de complexiteit van het incident wordt de meest geschikte
oplosgroep bepaald. Dat kan degene zijn die het incident heeft aangenomen en tot nu toe in
behandeling heeft. Indien de kennis of bevoegdheid van de aannemer onvoldoende is om de
oplossing te kunnen bepalen kan de afhandeling van het incident worden gerouteerd naar
een groep of functionaris met meer kennis of bevoegdheden, bijvoorbeeld een groep
technisch specialisten of een operations-team. Voor zover een bijdrage vereist is door een
externe dienstverlener kan ook aan de externe partij een actie worden toegekend.
Als er een match is gevonden, dan wordt het incident naar de oplosgroep gerouteerd onder
vermelding van de gevonden match: de oplosgroep kan dan de herstelactie verder uitwerken.
Als er geen match is gevonden, dan wordt het incident naar de oplosgroep gerouteerd onder
vermelding van het ontbreken van een match: de oplosgroep zal het incident dan verder
moeten analyseren.
NB: De afhandeling van het incident kan op ieder moment (in iedere activiteit) worden
gerouteerd naar een nieuwe (in- of externe) oplosgroep. Mocht bijvoorbeeld een activiteit
niet tot een goed einde kunnen worden gebracht door de behandelende oplosgroep, dan kan
het proces worden vervolgd door de nieuwe oplosgroep, of terugvallen naar het punt waar
het fout ging (bepalen oplosgroep) om van daaruit alsnog tot een goed einde te worden
gebracht. Oorzaken voor het verder moeten routeren naar een andere oplosgroep zijn
bijvoorbeeld: te weinig skills, te weinig bevoegdheden, te weinig resources.
Match?
JA Er is een match: één of meerdere overeenkomende situaties zijn gevonden. Geen verdere
analyse vereist.
NEE Geen match: er zijn geen overeenkomende situaties gevonden. Verder analyseren.

ISM-procesmodel
Analyseren
DOEL Onderzoeken wat de beste oplossing is voor het incident
INPUT Een niet gematcht incident
OUTPUT Een geselecteerde oplossing of een RFC
TOELICHTING Uit de beschikbare oplossingen die in de analyse worden bepaald, moet die oplossing worden
geselecteerd die de juiste balans heeft tussen snelheid, kosten en kwaliteit. Indien deze
oplossing een wijziging is, vindt de afhandeling plaats via het change management-proces.
Analyseren incident
DOEL Het onderzoeken van het incident en het bepalen van mogelijke oplossingsrichtingen
INPUT Een niet gematcht incident
OUTPUT Een geanalyseerd incident
TOELICHTING Indien het matchen geen bruikbaar resultaat heeft opgeleverd, wordt het incident verder
onderzocht totdat één of meer oplossingsrichtingen zijn gevonden.
Daarmee wordt de feitelijke diagnose van het incident gesteld. Deze diagnose wordt
vastgelegd: hiermee is definitief bepaald wat er aan de hand was. Zodra dat bekend is, is het
ook mogelijk vast te stellen wat er moet worden gedaan om het incident te verhelpen.
Daarmee hoeft nog niet de oorzaak van het incident te zijn bepaald. Voor het oplossen van
een incident is het niet noodzakelijk die oorzaak te onderkennen en vast te leggen. Als echter
tijdens het oplossen de oorzaak wel wordt vastgesteld dan wordt deze meteen vastgelegd in
het incidentrecord.
Een vastgestelde diagnose (en eventuele oorzaak) helpt bij het selecteren van de
herstelactie. Ook helpt het vastleggen andere processen om gericht aan kwaliteitsverbetering
te werken.
Incidenten kunnen vaak op meerdere manieren worden opgelost. Er moet worden voorkomen
dat de eerstgevonden oplossing zonder verdere beschouwing wordt geïmplementeerd.
Selecteren oplossing
DOEL Het selecteren van de meest geschikte oplossing
INPUT Een geanalyseerd incident of een eerder gematcht incident
OUTPUT Een incident met een geselecteerde oplossing
TOELICHTING Als de diagnose van het incident definitief is gesteld, kan ook worden bepaald wat de beste
manier is om het incident op te lossen. Vaak bestaan er verschillende manieren om dat te
doen. Uit die verschillende oplossingsrichtingen moet nu één oplossing worden gekozen.
De oplossing van een incident kan op twee verschillende manieren plaatsvinden:

• herstellen van de oude (werkende) situatie - op de een of andere manier terug naar de
oude, werkende, situatie
• aanpassen van de operationele omgeving - het doorvoeren van een change
In het laatste geval moet de oplossing als een RFC worden geformuleerd en zal de aansturing
via het change management-proces verlopen. Incident management blijft wel de voortgang
bewaken en zal de afhandeling weer overnemen na invoering van de change.
Het kan voorkomen dat een incident moet worden opgelost door een combinatie van changes
en reset-acties. In dat geval worden één of meerdere RFC's ingediend terwijl tegelijkertijd
wordt gewerkt aan de reset-acties. Intensieve samenwerking met het operations en change
management-proces is dan noodzakelijk. Incident management is hierbij de initiërende en
coördinerende partij.

ISM-procesmodel
Voorbereiden herstel
DOEL Het implementatiegereed maken van de herstelactie
INPUT Een incident met een geselecteerde oplossing
OUTPUT Een (eventueel) geteste en gereedstaande herstelactie
TOELICHTING De activiteiten voor de herstelactie moeten op elkaar afgestemd uitgevoerd worden. Bij
complexere herstelacties moet intensieve coördinatie plaatsvinden. Bij riskantere
herstelacties moet daar waar mogelijk voorafgaand aan de implementatie getest worden.
Plannen herstelacties
DOEL Het plannen van alle noodzakelijke herstelacties
INPUT Een incident met een geselecteerde oplossing
OUTPUT Een incident met geplande herstelactiviteiten of een RFC
TOELICHTING Met name voor complexe herstelacties is het nodig de acties goed op elkaar af te stemmen.
Als de oplossing via een change moet worden gerealiseerd, wordt nu de RFC ingediend en
bewaakt.
Change nodig?
JA Het incident moet worden opgelost via een change.
NEE Het incident moet worden opgelost via een herstelactie.
Uitvoeren voorbereidende acties

DOEL Het uitvoeren van alle voorbereidende herstelactiviteiten
INPUT Een incident met geplande herstelactiviteiten
OUTPUT Een voor test gereedstaande herstelactie
TOELICHTING Onder het voorbereiden vallen de technische handelingen die nodig zijn om te kunnen
herstellen, zoals het opstellen van herstelscripts.
Communicatie valt ook onder de voorbereiding: moeten er mensen geïnformeerd worden
over de aanstaande uitvoering van een herstelactie? Moeten instructies aangepast worden?
Et cetera.

ISM-procesmodel
Testen voorbereide herstelactie

DOEL Het voorkomen van het mislukken van herstelacties
INPUT Een voor test gereedstaande herstelactie
OUTPUT Een gereedstaande herstelactie
TOELICHTING Voor zover mogelijk én gewenst moeten de voorbereide herstelacties getest worden. Of een
test gewenst is, is afhankelijk van de omvang van het risico dat de aanpassing met zich mee
brengt en van de schade die de herstelactie kan opleveren voor het te herstellen onderdeel of
de omgeving daarvan.
Of het mogelijk is te testen, wordt bepaald door fysieke factoren (is er een geschikte
testomgeving beschikbaar?) en de beschikbare tijd (kan er gewacht worden op een
testresultaat of moet het risico genomen worden zonder testen verder te gaan?). Ook moet
getoetst worden of het geplande hersteltijdstip geschikt is.
Indien besloten wordt om niet te testen is dat een bewust besluit.
Als de test niet het gewenste resultaat oplevert, moet worden teruggegaan tot waar het in
het proces fout is gegaan. Dat begint bij het vaststellen van aanvullende informatie.
Eventuele vervolgstappen worden waar nodig nogmaals uitgevoerd, opdat de gekozen
oplossing nu wel door de test komt.
Testen succesvol?
JA Het testresultaat is positief. Vervolgen met de uitvoering van de herstelactie.
NEE Het testresultaat is negatief. Het proces zal opnieuw worden doorlopen vanaf de activiteit
"Aanvullen informatie".

ISM-procesmodel
Herstellen
DOEL Het implementeren van de herstelactie en het laten accepteren van het resultaat door de
gebruiker
INPUT Een (eventueel) geteste en gereedstaande herstelactie
OUTPUT Een opgelost incident
TOELICHTING Een incident is opgelost als de gebruikers hun werk op acceptabele wijze kunnen voortzetten.
Voor het oplossen is het niet noodzakelijk dat de oorzaak is gevonden of weggenomen. Ook
een tijdelijke oplossing (workaround) kan leiden tot een opgelost incident.
Uitvoeren herstelactie
DOEL Het (laten) uitvoeren van de herstelactie
INPUT Een (eventueel) geteste en gereedstaande herstelactie
OUTPUT Een uitgevoerde herstelactie
TOELICHTING Operationele beheeracties op de operationele omgeving vinden plaats onder aansturing van
het proces operations management. Dit om te voorkomen dat de verschillende
beheeractiviteiten elkaar en de klant in de weg zitten. Vanuit deze activiteit wordt operations
management getriggerd. Vanuit operations management wordt het resultaat van de
uitgevoerde herstelactie gerapporteerd.
Toetsen gewenst resultaat

DOEL Het intern toetsen van het resultaat van de uitgevoerde herstelactie
INPUT Een uitgevoerde herstelactie
OUTPUT Een intern getoetst resultaat
TOELICHTING Voordat de aanmelder van het incident wordt gevraagd of hij tevreden is met het resultaat
van de herstelactie, wordt voor zover mogelijk eerst intern bekeken of het gewenste effect is
bereikt.
Gewenst resultaat?
JA Het incident is opgelost en de aanmelder zal hierover benaderd worden.
NEE Het incident is niet opgelost en het proces zal opnieuw worden doorlopen vanaf de activiteit
'Aanvullen informatie'.

ISM-procesmodel
Vragen akkoord aanmelder

DOEL Het accorderen van het resultaat van de doorgevoerde herstelactie door de aanmelder
INPUT Een intern getoetst resultaat
OUTPUT Een opgelost incident
TOELICHTING Na akkoord van de indiener stopt de downtime van het incident.
Ook van eventueel gekoppelde incidenten dienen de aanmelders te worden benaderd met
betrekking tot dit akkoord.
Aanmelder akkoord?
JA De aanmelder is akkoord met de oplossing en het incident kan worden gesloten.
NEE De aanmelder is niet akkoord. Het incident is dus niet opgelost en het proces zal opnieuw
worden doorlopen vanaf de activiteit "Aanvullen informatie".
Afsluiten
DOEL Het uitvoeren van afrondende activiteiten en het sluiten van de incidentmelding
INPUT Een opgelost incident
OUTPUT Een afgesloten incident
TOELICHTING Voordat de incidentmelding definitief wordt gesloten, moet deze correct zijn bijgewerkt (in
knowledge-base en incidentrecord) met alle relevante informatie en moet de eventuele
workaround verwijderd worden.

ISM-procesmodel
Workarounds verwijderen
DOEL Het verwijderen van eventueel ingezette workarounds
INPUT Een opgelost incident met een workaround (extern getoetst)
OUTPUT Een opgelost incident zonder workarounds
TOELICHTING Deze activiteit borgt dat een actie wordt geïnitieerd om eventueel ingezette workarounds weg
te nemen.
Voorbeeld: een pc is kapot gegaan en deze is tijdelijk vervangen door een pc van een ander
(duurder) type. Het incident is daarmee verholpen (de downtime is gestopt) want de
gebruiker kan weer werken. Het is echter van belang dat deze workaround weer wordt
verwijderd.
Ander voorbeeld: de verwarming is uitgevallen en er is tijdelijk een heater geplaatst. Deze
heater wordt na herstel weer weggehaald.
Dergelijke activiteiten kunnen steeds via een RFC of een operations-activiteit worden
uitgevoerd. Via die uitvoerende processen wordt ook steeds de CMDB onderhouden.
Deze activiteiten moeten zodanig gepland worden dat de betrokken gebruiker zo weinig
mogelijk overlast ervaart. Mocht de service voor deze laatste herstelactiviteit nogmaals down
moeten (buiten geplande onderhoudsuren en binnen de openstellinguren), dan kan die
downtijd alsnog als service-downtijd worden geregistreerd. Een goede afstemming met de
gebruiker kan dat in de meeste gevallen voorkomen.
Knowledge-base bijwerken
DOEL Het actualiseren van de knowledge-base
INPUT Een opgelost incident zonder workarounds
OUTPUT Een opgelost incident met bijgewerkte knowledge-base
TOELICHTING Tijdens deze activiteit moet bepaald worden of de toegepaste oplossing geschikt is om vaker
te gebruiken. Om te voorkomen dat een volgende keer weer onder hoge druk alle plannen
nog gemaakt moeten worden en dat de opgedane kennis en ervaring verloren, gaat moet een
actie geïnitieerd worden die leidt tot aanpassing van de knowledge-base.
Finaal bijwerken incidentrecord

DOEL Het volledig en correct vullen van het incidentrecord
INPUT Een opgelost incident met bijgewerkte knowledge-base
OUTPUT Een volledig bijgewerkt incidentrecord
TOELICHTING Er wordt gecontroleerd of alle informatie volledig en correct in het incidentrecord is
opgenomen. Het incidentrecord wordt namelijk geraadpleegd bij herhaling van gelijksoortige
incidenten, bij rapportages, en het biedt relevante informatie voor improvement
management.
Afsluiten incidentmelding
DOEL Het sluiten van de incidentmelding
INPUT Een volledig bijgewerkt incidentrecord
OUTPUT Een afgesloten incidentmelding
TOELICHTING Door het sluiten van de incidentmelding stopt de doorlooptijd van het incident. NB: de
downtijd was al eerder gestopt.
Eventueel gekoppelde incidenten worden nu ook gesloten. Indien het incident zelf was
gekoppeld aan een major incident of groepsincident heeft de afhandeling via dat incident
plaatsgevonden.

ISM-procesmodel
Knowledge management
DOEL Het leveren van accurate en actuele informatie over de operationele omgeving en m.b.t. voor
het beheer belangrijke documentatie
INPUT De behoefte aan informatie over CI’s en beheerinformatie
OUTPUT Beschikbare en betrouwbare informatie over CI’s en beheerinformatie
TOELICHTING Knowledge management (ook wel Configuration Management genoemd) levert de informatie
over de samenstelling van de operationele omgeving en over informatie die relevant is voor
het opveren en diensten zoals werkinstructies, service-afspraken, rapportages etc. en
ondersteunt daarmee alle andere processen. De informatie is afkomstig uit de configuration
management database (CMDB), die een beschrijving bevat van alle onderkende configuratie
items (CI's) alsmede van hun onderlinge relaties. Met deze informatie kunnen bijvoorbeeld
impactanalyses worden uitgevoerd en plannen van aanpak worden opgesteld.
Om deze informatie uit de CMDB te kunnen halen, richt knowledge management de CMDB in
en ziet toe op tijdige en correcte registratie.
Idealiter is de informatie in de CMDB gelinkt aan de records uit andere processen zoals
incident management en change management, zodat een groot inzicht ontstaat in de
samenhang van alle informatie in het ISM-procesmodel.

ISM-procesmodel
Inrichten CMDB
DOEL Het inrichten van de CMDB, zodat deze de informatie kan bevatten die de verschillende
belanghebbenden nodig hebben.
INPUT De (collectieve) informatiebehoefte
OUTPUT Een ingerichte CMDB
TOELICHTING Het onderhouden van de CMDB brengt veel kosten met zich mee. Het is dus van belang dat
alleen die informatie wordt bijgehouden die echt van belang is voor de organisatie. Om die
reden dient voor elk informatie-item een belanghebbende te zijn bepaald.
Inventariseren informatiebehoefte
DOEL Het inventariseren van de behoefte die er is om CI-types en relaties in de CMDB vast te
leggen
INPUT De informatiebehoefte
OUTPUT De geïnventariseerde informatiebehoefte
TOELICHTING Er zijn twee manieren waarop de informatiebehoefte kan worden vastgesteld:
• Reactieve inventarisatie: het wachten op een informatiebehoefte die vanuit één van
de andere processen of vanuit de lijnorganisatie wordt aangemeld bij de
knowledgemanager.
• Proactieve inventarisatie: het op regelmatige basis bevragen van de overige
processen en de lijnorganisatie of de huidige CMDB nog toereikend is voor hun
informatiebehoefte.
Het is aan te bevelen om beide methoden te gebruiken om de informatiebehoefte vast te
stellen.

ISM-procesmodel
Analyseren informatiebehoefte
DOEL Het analyseren van de informatiebehoefte om te bepalen of het realiseren daarvan haalbaar
is en meerwaarde oplevert
INPUT De geïnventariseerde informatiebehoefte
OUTPUT Een besluit om het CMDB–model wel of niet aan te passen
TOELICHTING Er wordt een analyse uitgevoerd om te bepalen of de geïnventariseerde informatiebehoefte
wel gerealiseerd kan worden. Er wordt bij de belanghebbenden informatie opgevraagd over
de relevantie van de informatiebehoefte en de waarde die men er aan toe kent. Relevant is
de vraag of de informatiebehoefte binnen de scope van knowledge management valt en of de
kosten van het registreren wel opwegen tegen de baten.
Als dit het geval is, dan kan dit ertoe leiden dat het CMDB-model moet worden aangepast. De
volgende wijzigingen kunnen plaatsvinden:
• Een attribuut van een bepaald type CI moet wordt aangepast, verwijderd of toegevoegd.
• Een type CI moet worden aangepast, verwijderd of toegevoegd.
• Een relatie tussen CI-types moet worden aangepast, verwijderd of toegevoegd.
• Een willekeurige combinatie van bovenstaande drie.
Onderdeel van deze activiteit is het opstellen van een advies over de mogelijke aanpassing
van de CMDB en het nemen van een beslissing.
Aanpassen CMDB-model?
JA Het CMDB-model zal worden aangepast om aan de informatiebehoefte te voldoen.
NEE Het CMDB-model zal niet worden aangepast.
Afwijzing meedelen
DOEL Afwijzing meedelen aan de belanghebbende
INPUT Het besluit om het CMDB-model niet aan te passen
OUTPUT Een geïnformeerde belanghebbende
TOELICHTING Bij de afwijzing wordt een onderbouwing meegeleverd. De belanghebbende kan, als hij van
mening is dat zijn informatieverzoek ten onrechte is afgewezen, escaleren in de hiërarchische
lijn.
Aanpassen CMDB-model
DOEL Het aanpassen van de structuur van de CMDB
INPUT De beslissing om het CMDB-model aan te passen
OUTPUT Een aangepast CMDB-model en een eventueel aangepaste CMDB
TOELICHTING Het CMDB-model moet worden aangepast conform de besluitvorming waarna de correcte
uitvoering van de aanpassing gecontroleerd moet worden.
De aanpassing van de CMDB is een change en wordt dus via het proces change management
beheerst doorgevoerd. Hierbij wordt o.a. de nieuwe CMDB getest op de juiste werking.
Eventuele consequenties van de regelwijziging worden in de change meegenomen. Denk aan
de wijziging van de CMDB-inhoud zodat deze weer in lijn is met het aangepaste CMDB-model.
Vanaf het moment dat het CMDB-model is aangepast kunnen de nieuwe of aangepaste CI-
types of attributen in de CMDB worden ingevoerd.
Afkondigen aangepast CMDB-model

DOEL Het implementeren van het aangepaste CMDB-model
INPUT Een aangepast CMDB-model en een eventueel aangepaste CMDB
OUTPUT Een geïmplementeerd CMDB-model
TOELICHTING De nieuwe structuur van het CMDB-model moet bekend worden gemaakt, zodat voortaan op
de juiste (aangepaste) wijze CI’s worden ingevoerd.
NB: het is vanzelfsprekend ook mogelijk elementen uit een CMDB-model te verwijderen: in
dat geval kunnen daarna minder gegevens worden geregistreerd.

ISM-procesmodel
Registreren CI's
DOEL Het registreren van CI's in de CMDB, aan de hand van de invulinstructies
INPUT Een verzoek tot registratie
OUTPUT Een bijgewerkte CMDB
TOELICHTING In dit deelproces wordt het daadwerkelijke vullen en onderhouden van de CMDB uitgevoerd.
Aannemen registratieverzoek
DOEL Het in behandeling nemen van registratieverzoeken
INPUT Een registratieverzoek
OUTPUT Een aangenomen registratieverzoek
TOELICHTING Verzoeken tot aanpassing mogen alleen uit het proces change management komen, of uit het
deelproces verifiëren CMDB.
Toetsen registratieverzoek
DOEL Het toetsen of de aangevraagde registratie past binnen de scope van de CMDB-inrichting
INPUT Een aangenomen registratieverzoek
OUTPUT Een getoetst registratieverzoek
TOELICHTING De aangevraagde registratie wordt vergeleken met het CMDB-model. Als het daarbinnen past
wordt de procedure vervolgd met het daadwerkelijk registreren.
Mocht de gevraagde registratie niet passen binnen het CMDB-model, dan wordt de aanvraag
afgewezen.
Binnen scope CMDB?

JA Het verzoek tot registratie valt binnen de scope van het CMDB-model.
NEE Het verzoek tot registratie valt niet binnen de scope van het CMDB-model.

ISM-procesmodel
Afwijzen registratieverzoek
DOEL Het registratieverzoek wordt afgewezen
INPUT Een afgewezen registratieverzoek
OUTPUT Een geïnformeerde aanvrager
TOELICHTING De aanvrager wordt geïnformeerd dat de aanvraag is afgewezen, onder vermelding van de
reden. De aanvrager kan besluiten een verzoek in te dienen om het CMDB-model aan te
passen.
Uitvoeren registratie
DOEL Het registreren van de CI in de CMDB
INPUT Een getoetst verzoek tot registratie
OUTPUT Een aangepaste registratie
TOELICHTING De nieuwe of aangepaste data wordt vastgelegd in de CMDB.
Tijdens het registreren moet de registrator bewaken dat alle bijbehorende attributen worden
ingevuld of aangepast, en dat de registratie correct heeft plaatsgevonden.
Bevestigen registratie
DOEL Het informeren van de aanvrager dat de CI in de CMDB is geregistreerd
INPUT Een geregistreerde CI
TOELICHTING De aanvrager wordt geïnformeerd dat de CMDB is bijgewerkt.

ISM-procesmodel
Verifiëren CMDB
DOEL Het borgen dat de informatie uit de CMDB actueel is
INPUT Een gevulde CMDB
OUTPUT Een betrouwbare CMDB
TOELICHTING In dit deelproces wordt nagegaan of de actuele situatie overeenkomt met de gegevens (CI's)
zoals deze in de CMDB zijn geregistreerd. Indien een verschil wordt vastgesteld, wordt actie
genomen om het verschil op zorgvuldige wijze te herstellen.
Verificatie vindt planmatig plaats maar vaak ook spontaan. Bij het afhandelen van een call
(incident, change, servicerequest) zullen regelmatig verschillen worden vastgesteld tussen de
feitelijke situatie en de inhoud van de CMDB. Indien een verschil wordt geconstateerd, moet
hiervan een melding worden gemaakt.

ISM-procesmodel
Opstellen verificatieplan
DOEL Borgen dat de inhoud van de CMDB regelmatig en zorgvuldig wordt gecontroleerd
INPUT De CMDB
OUTPUT Een verificatieplan
TOELICHTING Het verificatieplan beschrijft de wijze waarop de verificatie wordt uitgevoerd. In het plan
wordt onder andere vastgelegd:
• de scope van de verificatie
• het moment waarop de verificatie zal plaatsvinden: dit kan na verloop van een bepaalde
periode zijn maar kan ook getriggerd worden door een bepaalde situatie (bv. na een
grote vervanging)
• de wijze waarop (bijvoorbeeld: handmatige of automatische verificatie met tools)
Verificatie is kostbaar en moet daarom gericht worden uitgevoerd. Varianten van deze scope
zijn:
• een volledige controle op de gehele inhoud
• een controle op een willekeurig deel van de CMDB
• een controle op bepaalde delen van de CMDB
• een controle gerelateerd aan recent uitgevoerde wijzigingen
Bij het kiezen van de scope en de frequentie van de verificatie spelen onder andere de
volgende argumenten een rol:
• de relevantie van de informatie voor de correcte en efficiënte dienstverlening
• de mate waarin de informatie blijkt te vervuilen
• de schade die verkeerde informatie kan veroorzaken
• de mate waarin de informatie gebruikt wordt voor rapportage of facturatie
In het verificatieplan wordt ook beschreven hoe over de verificatie gerapporteerd wordt.
Uitvoeren verificatie
DOEL Het vaststellen van de betrouwbaarheid van (delen van) de CMDB.
INPUT Een verificatieplan
OUTPUT De verzamelde verificatiegegevens
TOELICHTING De geplande verificatie kan als volgt worden uitgevoerd:
• Er wordt gecontroleerd of de geregistreerde CI's wel als zodanig worden aangetroffen;
• Er wordt gecontroleerd of alle aangetroffen CI's wel correct geregistreerd zijn in de
CMDB.
Beheerders zullen bij de uitvoering van hun werkzaamheden regelmatig verschillen

vaststellen tussen de feitelijke situatie en de inhoud van de CMDB. Dit wordt beschouwd als
een spontane verificatie.
Opstellen verschillenlijst
DOEL Het vaststellen van een verschillenlijst waarin de verschillen tussen de aangetroffen en de
geregistreerde CI's worden aangegeven
INPUT De verzamelde verificatiegegevens
OUTPUT Een verschillenlijst
TOELICHTING Bij het opstellen van de verschillenlijst wordt onderscheid gemaakt naar:
• CI’s die geregistreerd zijn maar niet zijn aangetroffen
• CI's die aanwezig zijn maar niet (correct) zijn geregistreerd
Ook de uitkomst van een spontane verificatie wordt opgenomen op de verschillenlijst.

ISM-procesmodel
Analyseren verschillenlijst
DOEL Vaststellen hoe de verschillen tussen de aangetroffen CI's en de geregistreerde CI's tot stand
zijn gekomen
INPUT Een verschillenlijst
OUTPUT Een geanalyseerde verschillenlijst
TOELICHTING Om de verschillen op de juiste wijze te kunnen herstellen moet eerst worden vastgesteld
waardoor de verschillen zijn veroorzaakt. Dit kan zijn door:
1. een achterstand bij de verwerking van registratieverzoeken
2. een fout bij de registratie
3. het registratieverzoek is niet ingediend
4. een wijziging is buiten het change-proces om uitgevoerd.
Bij ieder geconstateerd verschil wordt in de verschillenlijst de oorzaak vastgelegd.
Initiëren herstelactie
DOEL Het initiëren van de herstelactie
INPUT Een geanalyseerde verschillenlijst
OUTPUT Een actielijst
TOELICHTING Door het vaststellen van de oorzaak is ook meteen de bijbehorende herstelactie vastgesteld.
Ad 1) Registratieachterstand -> Een verzoek aan de registrator om zo spoedig mogelijk te
registreren. Eventueel kan besloten worden extra registratiecapaciteit in te zetten.
Ad 2) Registratiefout -> Een verzoek aan de registrator om de fout te herstellen
Ad 3) Ontbrekend registratieverzoek -> Een verzoek aan change management om alsnog een
registratieverzoek in te laten dienen.
Ad 4) Illegale change -> Een RFC om de CI of de registratie alsnog te legaliseren.
De betreffende actie wordt gekoppeld aan de verschillenlijst.
Vervolgens wordt de actie aangemeld bij de betrokken uitvoerder of het change-proces.
Bewaken uitvoering actielijst

DOEL Het coördineren van de afhandeling van de uitgezette acties
INPUT Een actielijst
OUTPUT Een gecorrigeerde CMDB en/of een aangepaste infrastructuur
TOELICHTING Gecontroleerd moet worden of de geconstateerde verschillen tijdig en op correcte wijze zijn
hersteld.
Afsluiten verificatie
DOEL Het vaststellen van verbeteracties naar aanleiding van de geconstateerde verschillen
INPUT Gerealiseerde correcties
OUTPUT Verbeterplannen
TOELICHTING Op basis van de ernst van de aangetroffen verschillen wordt beoordeeld of er
verbeterplannen moeten worden opgesteld voor verschillende betrokken processen. Zo kan
bijvoorbeeld change management tekort zijn geschoten bij het besturen van changes, maar
ook knowledge management kan tekort zijn geschoten bij een correcte uitvoering van de
registraties.

ISM-procesmodel
Informeren
DOEL Het snel en eenvoudig toegankelijk maken van de informatie uit de CMDB
INPUT Verzoek tot informatie
OUTPUT Informatie of standaardquery
TOELICHTING Het leveren van betrouwbare en volledige informatie is de enige bestaansreden van
configuration management. De informatie moet niet alleen betrouwbaar en volledig zijn maar
ook eenvoudig en snel verkrijgbaar. Alleen dan heeft de CMDB meerwaarde boven het ad hoc
verzamelen van informatie over de samenstelling van de operationele omgeving.
Vaak kan informatie, door een logische structuur van de CMDB of de aanwezigheid van
geschikte queries, direct door de belanghebbende uit de CMDB worden verkregen. Het op
deze wijze verkrijgen van informatie vindt plaats als onderdeel van het normale werk en is
niet in aparte procesactiviteiten beschreven.
Soms is ondersteuning nodig bij complexe zoekacties of het realiseren van nieuwe queries.
Het deelproces informeren moet borgen dat de informatie snel en eenvoudig te verkrijgen is
en ondersteunt het opvragen van informatie.

ISM-procesmodel
Aannemen informatieverzoek
DOEL Het aannemen van een verzoek tot informatie
INPUT Een informatieverzoek
OUTPUT Een aangenomen informatieverzoek
TOELICHTING Een informatieverzoek wordt geregistreerd en waar nodig gespecificeerd
Analyseren informatieverzoek
DOEL Het vaststellen of de gevraagde informatie in de CMDB aanwezig is
INPUT Een aangenomen informatieverzoek
OUTPUT Een geanalyseerd informatieverzoek
TOELICHTING Onderzocht moet worden of de gevraagde informatie in de CMDB aanwezig is of daaruit kan
worden afgeleid. Zo nodig wordt in overleg met de aanvrager het informatieverzoek
aangepast aan de in de CMDB beschikbare informatie.
Info in CMDB?
JA De gevraagde informatie is opgenomen in de CMDB.
NEE De gevraagde informatie is niet opgenomen in de CMDB.
Afwijzen informatieverzoek
DOEL Het informeren van de aanvrager dat de gevraagde informatie niet uit de CMDB kan worden
gehaald
INPUT Geanalyseerd informatieverzoek (informatie niet aanwezig)
TOELICHTING De aanvrager moet gewezen worden op de mogelijkheid een verzoek in te dienen om het
CMDB-model aan te passen.
Verzamelen informatie
DOEL Het verzamelen van de informatie die is aangevraagd
INPUT Een geanalyseerd informatieverzoek
OUTPUT De verzamelde informatie
TOELICHTING Afhankelijk van de aanvraag kan de gevraagde informatie via handmatige acties uit de CMDB
worden gehaald of met behulp van een voor dit doel te realiseren query.
Beschikbaar stellen informatie

DOEL Het beschikbaar stellen van de informatie
INPUT De verzamelde informatie
OUTPUT De levering van de gevraagde informatie
TOELICHTING De informatie moet beschikbaar gesteld worden in een vorm die voor de aanvrager bruikbaar
is.
Evalueren informatieverzoek
DOEL Het actualiseren van de query-library
INPUT De afgehandelde informatievraag
OUTPUT Een geactualiseerde query-library
TOELICHTING Voor informatie die vaker zal worden opgevraagd wordt een query-library beschikbaar
gesteld.
Indien bij het verzamelen van de informatie al gebruik is gemaakt van een voor dit doel
gerealiseerde query kan besloten worden deze toe te voegen aan de query-library.
Indien de informatie door handmatige acties is verzameld en de verwachting bestaat dat de
informatie in deze vorm vaker zal worden gevraagd, kan besloten worden om voor dit doel
een query te bouwen die toegevoegd zal worden aan de query-library.
De registratie van de aanvraag wordt bijgewerkt en de aanvraag wordt afgesloten.

ISM-procesmodel
Operations management
DOEL Het realiseren van de overeengekomen dienstverlening door het plannen en uitvoeren van
alle werkzaamheden op de operationele omgeving, het monitoren van het gedrag van het
operationele omgeving en het signaleren van afwijkingen van de SLA.
Ook het ad hoc en planmatig ondersteunen van de gebruiker (user support) bij het gebruik
van de dienst valt onder dit proces
INPUT SLA's, interne normen en meldingen van alle reguliere en incidentele werkzaamheden
OUTPUT Een conform SLA's functionerende operationele omgeving, en meldingen van afwijkingen
TOELICHTING Dit proces zorgt ervoor dat de services worden geleverd zoals overeengekomen, en dat
herstel en aanpassingen goed gepland en onderling gecoördineerd worden doorgevoerd.
Door de coördinatie van alle ad hoc en repeterende uitvoerende werkzaamheden aan de
operationele omgeving vindt optimalisatie van werkzaamheden plaats en worden conflicten
vermeden
Dit impliceert dat er eisen worden gesteld aan de operationele omgevig, aan de beheerders,
aan de werkwijzen, en aan de gebruikers. Als aan deze eisen niet wordt voldaan, dan zijn de
prestaties en de beschikbaarheid van de operationele omgeving niet te garanderen. Het
proces operations management heeft de taak om te borgen dat aan de eisen wordt voldaan.
Het proces operations management bestaat uit het plannen en uitvoeren van de operations-
activiteiten, en het bewaken van de werking van de operationele omgeving. Het gaat daarbij
om:
• het plannen en uitvoeren van:
- alle repeterende operationele taken
- alle incidentele operationele taken
- alle repeterende monitoringsactiviteiten
- alle incidentele monitoringsactiviteiten
Centraal staat de planning van deze taken. De vraag van de klant moet vervuld worden, de
uitvoering van de handelingen mogen geen of zo weinig mogelijk hinder veroorzaken op de
operationele omgeving, en er mogen geen risico’s optreden voor de continuïteit van de
dienstverlening.
Alle activiteiten die niet direct (kunnen) worden uitgevoerd, worden opgenomen in het
operationsplan. Het operationsplan bevat een dynamisch deel voor eenmalige activiteiten en
een statischer deel voor de terugkerende of continue activiteiten. Het operationsplan
beschrijft in het uitvoeringsplan alle werkzaamheden op en aan het systeem en in het
monitoringplan alle bewakingsactiviteiten.
Operationsplan Statisch Dynamisch
- Uitvoeringsplan
- Monitoringplan
Eenmalige activiteiten die na toetsing onmiddellijk kunnen worden uitgevoerd, worden niet
opgenomen in het operationsplan.
Vanuit haar monitoringrol signaleert het proces operations management (vroegtijdig)

storingen en meldt dit aan het incident management-proces.
Steeds meer organisaties kiezen er voor om de uitvoerende en monitoringsactiviteiten in één

procesflow in te plannen en aan te sturen.

ISM-procesmodel
Uitvoeren
DOEL Het efficiënt plannen en uitvoeren van alle reguliere en incidentele werkzaamheden aan de
operationele omgeving (operations-activiteiten)
INPUT Meldingen van alle reguliere en incidentele werkzaamheden
OUTPUT Conform SLA's functionerend services
TOELICHTING Alle regelmatig terugkerende werkzaamheden die voortvloeien uit SLA’s en interne afspraken
moeten worden ingepland, rekening houdend met afgesproken onderhouds- en
servicewindows. Daarnaast moeten ook eenmalige werkzaamheden zoals change-
implementaties, incidentherstelacties, service requests en overige operations-activiteiten
worden ingepland in of getoetst aan het integrale planningssysteem.

ISM-procesmodel
Ontvangen & registreren operations-opdrachten

DOEL Het in ontvangst nemen van een operations-opdracht en registreren van de basisgegevens
van de operations-opdracht
INPUT Operations-opdrachten kunnen zijn:
• herstelacties (resets) uit het proces incident management
• implementatie acties uit het proces change management
• servicerequests van klanten/gebruikers
• aanvragen voor functionele of operationele ondersteuning
OUTPUT Een geregistreerde operations-opdracht
TOELICHTING Door het vastleggen van de operations-opdrachten wordt de besturing van de uit voeren
werkzaamheden mogelijk gemaakt. Dit is van belang om te voorkomen dat er gelijktijdig
conflicterende ingrepen op hetzelfde systeem worden uitgevoerd.
Beoordelen uitvoerbaarheid
DOEL Het prioriteren en beoordelen van de uitvoerbaarheid van de operations-opdracht
INPUT Een geregistreerde operations-opdracht
OUTPUT Een geaccepteerde of afgewezen operations-opdracht
TOELICHTING Operations-opdrachten die afkomstig zijn van het change of incident management proces zijn
al voorzien van een prioriteit en een daaraan gekoppelde oplostijd. Overige operations-
opdrachten moeten nog een prioriteit en/of oplostijd krijgen.
Op basis van de klantafspraken moeten de criteria voor de bepaling van impact, urgentie - en
daarvan afgeleid de prioriteit - vastgesteld en gebruikt worden.
De operations-opdrachten worden beoordeeld op uitvoerbaarheid.
Redenen voor de afwijzing kunnen zijn dat:
• het doorvoeren van de aanvraag bedreigend is voor de dienstverlening
• er onvoldoende resources zijn om de aanvraag uit te voeren of om de situatie na
uitvoering te kunnen beheren
• de bijbehorende beheerdocumentatie ontbreekt
• het niet mogelijk is de actie uit te voeren op het aangevraagde uitvoeringstijdstip
De beoordeling vindt bij voorkeur plaats aan de hand van vooraf opgestelde beheercriteria
die door het management zijn gefiatteerd. Voor veel operations-opdrachten is snel duidelijk
dat ze uitvoerbaar zijn binnen de geldende service-eisen. Dit geldt met name voor service
requests en supportvragen die geen grote impact hebben op de operationele omgeving of
objecten.
Uitvoerbaar?
JA De operations–opdracht kan worden uitgevoerd.
NEE De operations–opdracht kan niet worden uitgevoerd.
DOEL De aanvrager informeren dat de aangevraagde werkzaamheden niet kunnen worden
uitgevoerd
INPUT Een afgewezen operations-opdracht
OUTPUT Een afgesloten en afgewezen operations-opdracht
TOELICHTING Volgens de geldende afspraken wordt met de aanvrager gecommuniceerd. Het proces wordt
afgesloten. De documentatie wordt gearchiveerd.

ISM-procesmodel
Plannen operations-werkzaamheden
DOEL De aangevraagde werkzaamheden worden in de operations-planning ingevoerd en aan een
uitvoerder toegekend
INPUT • Een geaccepteerde operations-opdracht
• Het operationsplan
OUTPUT •
Een geplande operations-opdracht
•
Een aangepast operationsplan
TOELICHTING Het operationsplan bestaat uit twee delen:
• een statisch deel waarin alle vaste tijden en acties zijn ingepland zoals:
1. de in de SLA's overeengekomen servicewindows waarbinnen de operationele
omgeving voor de gebruikers beschikbaar moet zijn
2. de overeengekomen batchwindows
3. de ingeplande back-uptijden
4. de releasewindows
5. de onderhoudswindows
6. terugkerende acties zoals onderhoud en securitychecks et cetera
De in het statisch deel van het operationsplan opgenomen planning blijft van toepassing
totdat deze door een operations-opdracht wordt aangepast.
• een dynamisch deel waarin eenmalige acties worden opgenomen zoals:

1. reiniging
2. resetacties
3. implementatieverzoeken
4. servicerequests
Na succesvolle uitvoering van de actie vervallen deze uit het dynamische deel van het
operationsplan.
Het operationsplan wordt gebruikt om te bepalen wanneer aangevraagde operations-

activiteiten het best kunnen worden uitgevoerd. Eenmalige aanvragen worden toegevoegd
aan het dynamische deel van het operationsplan. Aanvragen die permanente invloed hebben
worden verwerkt in het statische deel van het operationsplan.
Sommige aanvragen zullen een statische en dynamische component hebben. Een dynamisch
deel om de operationele omgeving aan te passen, en een statisch deel om de nieuwe situatie
te beheren.
Uit het operationsplan kunnen verschillende deelplanningen worden afgeleid zoals;
• een operations dagplan, met een overzicht van de werkzaamheden van die dag; dit kan
tevens worden gebruikt als checklist om te controleren of alle geplande werkzaamheden
zijn uitgevoerd.
• een operations weekplan, met een overzicht van de werkzaamheden gedurende de
week;
• een operations-kalender, met alle werkzaamheden die verder vooruit zijn gepland.
Deze deelplanningen zijn niet alleen van belang om te borgen dat de activiteiten plaats
vinden op het geplande tijdstip, maar ook om de resources goed te kunnen inplannen.
Indien een geplande operations-activiteit invloed heeft op de monitoring moet ook het
monitoringplan worden aangepast.
Van veel operations-opdrachten, met name servicerequests en supportvragen, zal blijken dat
deze onmiddellijk kunnen worden uitgevoerd. Als dat ook daadwerkelijk gebeurt, worden
deze niet opgenomen in het operationsplan.
Uitzetten operations-werkzaamheden
DOEL Het routeren van de uit te voeren werkzaamheden naar de juiste uitvoerende partij
INPUT Een geplande operations-opdracht
OUTPUT Een uitgezette operations-opdracht
TOELICHTING De operations-werkzaamheden worden toegekend aan de daarvoor aangewezen
functionarissen.
Uitvoeren operations-werkzaamheden
DOEL Het uitvoeren van alle geplande operations-werkzaamheden
INPUT Een uitgezette operations-opdracht
OUTPUT Een uitgevoerde operations-opdracht
TOELICHTING De aangewezen functionaris voert de werkzaamheden uit conform planning en instructie.

ISM-procesmodel
Terugkoppelen aanvrager
DOEL Het terugkoppelen aan de aanvrager dat de aangevraagde operations-opdracht is uitgevoerd
INPUT Een uitgevoerde operations-opdracht
OUTPUT Een teruggekoppelde operations-opdracht
TOELICHTING Het is van belang zo snel mogelijk de uitvoering af te melden bij de aanvrager. De voortgang
van het initiërende proces wacht vaak op de afhandelingmelding om zelf verder te kunnen.
Monitoren
DOEL Het vroegtijdig signaleren van (dreigende) afwijkingen van serviceafspraken en interne
normen
INPUT SLA's, interne normen, werkplanningen
OUTPUT Afgeronde monitoringactiviteiten en eventueel incidentmeldingen
TOELICHTING Door de operationele omgeving nauwlettend in de gaten te houden, kan proactief worden
gezorgd voor het realiseren van de overeengekomen dienstverlening. Wanneer er een
overschrijding van een drempelwaarde wordt geconstateerd, dan wordt vanuit dit deelproces
het proces incident management opgestart.

ISM-procesmodel
Ontvangen en registreren monitoring-opdracht

DOEL Het in ontvangst nemen en registreren van monitoring-opdrachten
INPUT Een monitoring-opdracht
OUTPUT Een geregistreerde monitoring-opdracht
TOELICHTING Monitoring kan plaatsvinden om verschillende redenen zoals:
• servicebewaking – gedraagt de operationele omgeving zich conform SLA, het vroegtijdig
ontdekken van (dreigende) storingen.
• trendanalyse – hoe ontwikkelt zich het gebruik van (delen van) de operationele
omgeving
• facturering
• gebruiksanalyse – wie heeft wat wanneer gedaan op de operationele omgeving
Om de monitoring goed te kunnen laten plaatsvinden, moet duidelijk aangegeven en
vastgelegd worden:
• welke delen van de operationele omgeving en objecten gemonitord moeten worden.
• wanneer de monitoring moet plaatsvinden (continu, bepaalde tijden, bij bepaalde
activiteiten)
• welke informatie verzameld moet worden
• met welke frequentie en vorm de rapportage wordt geproduceerd
• of signalering van overschrijding van grenswaarden moet plaatsvinden
Beoordelen uitvoerbaarheid
DOEL Het beoordelen van de uitvoerbaarheid van de monitoring-opdracht
INPUT Een geregistreerde monitoring-opdracht
OUTPUT Een geaccepteerde of afgewezen monitoring-opdracht
TOELICHTING Bekeken moet worden of de gevraagde monitoring technisch en organisatorisch haalbaar is.
Ook moet bekeken worden of de monitoring past binnen de overeengekomen dienstverlening,
en of extra resources nodig zijn en beschikbaar worden gesteld.
Monitoring-opdrachten die niet uitvoerbaar zijn, worden afgewezen. De afwijzing wordt
teruggekoppeld aan de aanvrager.
Een uitvoerbare monitoring-opdracht kan nu worden gepland en vervolgens aan een

uitvoerend team worden toegekend.
Uitvoerbaar?
JA De aangevraagde monitoring-opdracht kan worden uitgevoerd.
NEE De aangevraagde monitoring-opdracht kan niet worden uitgevoerd.
DOEL De aanvrager informeren dat de monitoring-opdracht niet kan worden uitgevoerd
INPUT Een afgewezen monitoring-opdracht
OUTPUT Een afgesloten en afgewezen monitoring-opdracht
TOELICHTING Volgens de geldende afspraken wordt met de aanvrager gecommuniceerd. Het proces wordt
afgesloten. De documentatie wordt gearchiveerd.

ISM-procesmodel
Inplannen monitoring-werkzaamheden
DOEL De aangevraagde werkzaamheden worden in de operations-planning ingevoerd en aan een
uitvoerder toegekend
INPUT • Een geaccepteerde monitoring-opdracht
• Het monitoringplan
OUTPUT •
Een geplande monitoring-opdracht
•
Een aangepast monitoringplan
TOELICHTING Het monitoringplan wordt gebruikt om te bepalen wanneer aangevraagde monitoring-
werkzaamheden het beste kunnen worden uitgevoerd. Het uitvoeringstijdstip wordt
toegevoegd aan het monitoringplan. Hiermee ontstaat het actuele monitoringplan.
In het monitoringplan kan ver vooruit worden gepland. In de praktijk wordt het
monitoringplan wel in delen geknipt, analoog aan het uitvoeringsplan, bijvoorbeeld:
• een monitoring dagplan, met een overzicht van de werkzaamheden van die dag;
• een monitoring weekplan, met een overzicht van de werkzaamheden gedurende de
week;
• een monitoring-kalender, met alle werkzaamheden die verder vooruit zijn gepland.
Indien de aangevraagde werkzaamheden een regelmatig terugkerend karakter hebben of bij
bepaalde omstandigheden moeten worden uitgevoerd, dan worden ze aan het statische
monitoringplan toegevoegd. Met name in de monitoring-kalender worden ze dan herhaaldelijk
vermeld. Door alle terugkerende monitoring-werkzaamheden in één monitoring-kalender op
te nemen, kunnen deze werkzaamheden efficiënt gepland worden en wordt voorkomen dat ze
er bij inschieten.
In een monitoringplan is opgenomen welke werkzaamheden op welk tijdstip door welke groep
moeten worden uitgevoerd. Die groep kan een operations-team zijn, maar bijvoorbeeld ook
de servicedesk, een backoffice team of een specialistengroep.
Uitzetten monitoring-werkzaamheden
DOEL Het routeren van de uit te voeren werkzaamheden naar de juiste uitvoerende partij
INPUT Een geplande monitoring-opdracht
OUTPUT Een uitgezette monitoring-opdracht
TOELICHTING De monitoring-werkzaamheden worden toegekend aan de daarvoor aangewezen functionaris.
Uitvoeren monitoring-werkzaamheden
DOEL Het uitvoeren van alle geplande monitoring-werkzaamheden
INPUT Een uitgezette monitoring-opdracht
OUTPUT Een uitgevoerde monitoring-opdracht
TOELICHTING De aangewezen functionarissen voeren de werkzaamheden uit conform planning en
instructie.
Monitoring wordt voortdurend uitgevoerd conform het monitoringplan en heeft als doel om
het overschrijden van grenswaarden of het afwijken van planningen zo snel mogelijk vast te
stellen.
Zodra er grenswaarden worden overschreden, moet dit als een incident gemeld worden.
De monitoringgegevens worden vastgelegd ten behoeve van andere processen. Zo kunnen
gegevens vastgelegd worden ten behoeve van de servicerapportage in het deelproces
Aansturen dienstverlening uit SLM, of bijvoorbeeld ten behoeve van proactief
capaciteitsbeheer in quality management.
Beëindigen monitoring-werkzaamheden
DOEL Het beëindigen van monitoring-werkzaamheden die niet langer hoeven worden uitgevoerd
INPUT Een uitgevoerde monitoring-opdracht
OUTPUT Een beëindigde monitoring-opdracht
TOELICHTING Monitoring wordt uitgevoerd conform het monitoringplan, gedurende de daarin vastgelegde
looptijd. Daarna wordt de monitoring beëindigd en wordt het monitoringplan aangepast.
Indien de monitoringactiviteit op verzoek van een derde was uitgevoerd, wordt het resultaat
teruggekoppeld aan de aanvrager.

NL ISM Procesmodel 19082021 D

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NL ISM Procesmodel 19082021 D

Uploaded by

Copyright:

Available Formats

Het ISM-procesmodel

De ISM-methode helpt service-organisaties op

ISM wordt veel toegepast in de IT-dienstverlening,

De ISM-methode bestaat uit 3 kern-onderdelen:

Alles in de ISM-methode is gericht op het creëren van klantwaarde, Customer Value,

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 2 van 82

In slechts 6 processen, die elkaar versterken, zijn alle activiteiten op tactisch en

De ideeën en concepten van de ISM-methode, zoals deze procesmodel-beschrijving, zijn

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 3 van 82

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 4 van 82

Meer informatie: http://www.ismportal.nl

De positie van het ISM-procesmodel ................................................... 6

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 5 van 82

De positie van het ISM-procesmodel

De groeiende behoefte om de inzet van de klant, functioneel beheer en technisch beheer

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 6 van 82

belang is of deze inzet intern of extern wordt gerealiseerd. De serviceorganisatie is dus

“All models are wrong, some are useful”

De processen in het ISM-procesmodel kunnen algemeen in werkwoorden worden

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 7 van 82

In het procesmodel zijn voor de 6 basisprocessen een groot aantal activiteiten

Enterprise Service Management

In de uitwerking van het procesmodel is de procesbeschrijving zoveel mogelijk universeel

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 8 van 82

Het gehele Operatingmodel bestaat uit de productiemiddelen:

Het ISM-operatingmodel is beschreven in presentaties, webinars, artikelen en blogs en in

Het in dit artikel opgenomen ISM-procesmodel organiseert de acties in processen en in

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 9 van 82

Het ISM-besturingsmodel organiseert de aansturing van de operating door de

De eindverantwoordelijkheid voor de serviceprestatie, maar ook voor de teams met

Het ISM-besturingsmodel is beschreven in presentaties, webinars, artikelen en blogs en

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 10 van 82

Procescontrol informeert zich over de wijze waarop serviceaanvragen worden afgehandeld.

Indien nodig informeert procescontrol de call-eigenaars en verantwoordelijken over

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 11 van 82

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 12 van 82

Service Level Management

De klanttevredenheid wordt naast de kwaliteit van de functionaliteit en de wijze waarop deze

De feitelijke levering van de overeengekomen services wordt aangestuurd, bewaakt,

De dienstverlener is verantwoordelijk voor het bewaken van de afspraken met de

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 13 van 82

Maken & onderhouden serviceafspraken

De gemaakte afspraken worden via het proces change management geoperationaliseerd.

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 14 van 82

Verzamelen eisen & wensen

Specificeren gewenste service

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 15 van 82

Verifiëren impact en haalbaarheid

Bij het toetsen van de gevolgen wordt gelet op:

Hiermee wordt de impact, de haalbaarheid en de meetbaarheid van de aanvraag getoetst,

Beslissen over offerte

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 16 van 82

De onderhandeling kent drie mogelijke uitkomsten:

Het resultaat van de onderhandelingen wordt vastgelegd in een SLA of projectafspraak. De

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 17 van 82

Toetsen aanpassing servicecatalogus

INPUT De oplevering van een conform de nieuwe afspraak ingericht informatiesysteem

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 18 van 82

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 19 van 82

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 20 van 82

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 21 van 82

Op basis van de klantbehoefte en de eigen overwegingen bepaalt de leverancier de

Gepubliceerd: 30-08-2021 https://www.ismportal.nl Pagina 22 van 82