Hoofd SLA

Voorbeeld Service Level Agreement Winkelsystemen
Winkelsystemen
Voorbeeld Service Level Agreement
Servicelevelnummer :
< NAAM KLANT>
Dit is een voorbeeld-Service Level Agreement met betrekking tot winkelsystemen en bijbehorende
infrasctuur voor winkelbedrijven. Het voorbeeld is vervaardigd in het kader van het project Naar
een Robuustere Pin-keten van de Stichting Bevorderen Efficint Betalen (SBEB) in mei/juli 2009.
Het staat winkelbedrijven vrij deze SLA te gebruiken en naar eigen inzicht aan te passen in geval van
een Pin-migratie.
De SBEB beoogt de toegang tot deze informatie te verbeteren. De SBEB kan echter geen enkele
verantwoordelijkheid of aansprakelijkheid voor de verstrekte informatie aanvaarden.
Datum :
Klant : <NAAM KLANT>
Behandeld door :
Adres gegevens
Contactpersonen
Naam Functie Telefoon Emailadres

Ondertekening
Voor akkoord Voor akkoord
<Opdrachtnemer>. <Opdrachtgever>
Naam: Naam:
Functie: Functie:
Datum: Datum:
Handtekening: Handtekening:
Document Control
Doel: Vastlegging van service levels betreffende de dienstverlening voor

<KLANT>
Bereik:
Referentie naar: Overeenkomst
Auteur: <Behandeld door>
Versiebeheer
Revisie: reden: Door: Datum:

Inhoud
1 Algemeen 5
1.1 Documentstructuur 5
1.2 Scope van de dienstverlening 7
1.3 Geheimhouding7
1.4 Duur van de overeenkomst 7
1.5 Overige bepalingen 7
1.6 Algemene Leveringsvoorwaarden 7
2 Incident management 8
2.1 Doel 8
2.2 Activiteiten 8
2.2.1 Prioriteitsbepaling 9
2.3 Service levels 10
2.4 Meldingsprocedure van incidenten 10
2.4.1 Hoge prioriteit 10
2.4.2 Incidenten buiten service window 10
2.5 VIP regeling 11
3 Change management 12
3.1 Doel 12
3.2 Soorten changes 12
3.2.1 Projecten 13
3.2.2 Frequente changes 13
3.3 Activiteiten 13
3.5 Change procedure 14
3.6 Offerte procedure 14
4 Problem management 15
4.1 Doel 15
4.2 Activiteiten 15
5 Configuration management 17
5.1 Doel 17
5.2 Activiteiten 17
6 ICT infrastructure management 18

6.1 Doel 18
6.2 Operations 18
6.2.1 Service levels 19
6.3 Availability management 19
6.4 Capacity management 21
6.5 Release management 21
6.6 Continuity management22
6.6.2 Continuity plan 23
6.6.3 Randvoorwaarden 23
6.7 Security management 23
3
7 Service level management 25

7.1 Doel 25
7.2 Activiteiten 25
7.3 Service Levels 26
7.3.1 Service Level Agreement 26
7.4 Rapportage 26
7.5 Overlegstructuur 26
7.5.1 Operationeel 26
7.5.2 Change management Board (CMB) meeting 26
7.5.3 Management meeting 27
7.5.4 Evaluatie meeting 27
4
Algemeen
Dit document beschrijft de Service Level Agreement (SLA) zoals deze tussen
<Opdrachtnemer>(hierna <SLA-Nemer>) en <SLA-Klant>(hierna <KLANT>) is afgesproken.
Deze SLA beschrijft de diensten (Services) die door <SLA-Nemer> geleverd worden en
definieert het niveau (Level) van deze diensten. Op deze manier kunnen de diensten
objectief worden gemeten en kunnen verslechteringen of verbeteringen in de
dienstverlening gemakkelijk worden geconstateerd.
De hier beschreven dienstverlening wordt georganiseerd en ingericht volgens ITIL richtlijnen.

Wijzigingen in deze richtlijnen en daarmee in de organisatie van de werkzaamheden, zullen
alleen in overleg met <KLANT> worden doorgevoerd.
Documentstructuur
Dit document is verdeeld in een aantal hoofdstukken dat elk, met uitzondering van dit eerste
hoofdstuk, een dienst beschrijft met de daarbij behorende serviceniveaus.
Dit document bevat de volgende bijlagen:
Bijlage A: Definities en afkortingen

Overzicht van definities en afkortingen die algemeen van toepassing zijn.
Bijlage B: Contactpersonen en rollen

Overzicht van de personen met de rol t.a.v. deze SLA.
Bijlage C: Communicatie en Escalatie

De beschrijving van de procedures die gebruikt worden bij de uitvoering van deze SLA.
Bijlage D: Wijzigingsblad
In deze bijlage worden de wijzigingen met betrekking tot deze SLA vastgelegd.
Bijlage E: Configuratie Items
In deze bijlage worden alle Configuratie Items genoemd waar deze SLA betrekking op heeft
5
Bijlage F: Matrix Software Ondersteuning

Overzicht met de gebruikte software en verantwoordelijkheden ten aanzien van de
ondersteuning.
Bijlage G: Standaardwijzigingen
Overzicht met wijzigingen die zonder autorisatie uitgevoerd kunnen worden.
Bijlage H: Scopebepaling
Definitie van de reikwijdte van de dienstverlening.
Bijlage I: Dossier Afspraken en Procedures (DAP)
Vastlegging van gemaakte afspraken en beschrijving van de procedures.
6
1.1 Scope van de dienstverlening

De in deze Service Level Agreement (SLA) beschreven dienstverlening beperkt zich tot de
apparatuur en programmatuur zoals beschreven in Bijlage E. De werkzaamheden staan
vermeld en zijn gespecificeerd onder de verschillende ITIL processen.
Wanneer door <KLANT> binnen de overeengekomen contractperiode wijzigingen worden

aangebracht in de toegepaste server systemen of generieke applicaties of in het gebruik
ervan die een substantile toename van de werkzaamheden veroorzaken zal tussen partijen
overleg worden gevoerd over een mogelijk noodzakelijke aanpassing van deze SLA. Zie ook
Bijlage H.
Geheimhouding
<SLA-Nemer> zal strikte vertrouwelijkheid in acht nemen ten aanzien van de informatie over
de organisatie, de werking van de apparatuur, de bestanden en de programmatuur van
<KLANT>. Behoudens schriftelijke toestemming van <KLANT> zal <SLA-Nemer>
gegevensdragers welke haar ter beschikking staan niet buiten het kader van deze Service
Level Agreement aan derden ter beschikking stellen. <SLA-Nemer> zal haar medewerkers
verplichten deze geheimhoudingsbepalingen na te leven.
Duur van de overeenkomst
Deze overeenkomst wordt aangegaan voor een periode van <AANTAL JAAR> jaar. Elk der
partijen is gerechtigd deze overeenkomst tegen het einde van de looptijd op te zeggen door
middel van een aangetekend schrijven met in acht neming van een opzegtermijn van
<AANTAL MAANDEN> maanden.
Indien de overeenkomst niet wordt opgezegd, wordt deze stilzwijgend verlengd met telkens
een periode van<AANTAL MAANDEN> maanden. Gedurende de verlengde periode geldt
eveneens een opzegtermijn van <AANTAL MAANDEN> maanden. Ook gedurende de
verlengde periode kan slechts opgezegd worden aan het einde van die periode. Deze
overeenkomst is tussentijds niet opzegbaar.
1.2 Overige bepalingen

<KLANT> zal aan de <SLA-Nemer>-medewerkers onbeperkt toegang verlenen aan de ruimte
op de co-locatie(s) waar de apparatuur staat opgesteld om hun werkzaamheden
voortkomende uit deze SLA uit te voeren.
1.3 Algemene Leveringsvoorwaarden
De beschreven dienstverlening geschiedt in overeenstemming met de in dit document

beschreven voorwaarden en de Algemene Leveringsvoorwaarden <SLA-Nemer>, waarbij de
voorwaarden van onderhavige overeenkomst prevaleren boven de Algemene
Leveringsvoorwaarden <Opdrachtnemer>
7
Incident management
Doel
Het doel van Incident management is het zo snel mogelijk verhelpen van storingen aan de
ICT infrastructuur en het beperken van de impact op de bedrijfsprocessen.
Activiteiten
Activiteiten <KLANT> <SLA- Omschrijving

Nemer>
Aannemen en registreren V U <KLANT> vult 1e lijns ondersteuning in.
<SLA-Nemer> registreert alle incidenten in het <SLA-

Nemer> servicedesk tool die:
- telefonisch of per e-mail gemeld worden bij

de <SLA-Nemer> Servicedesk door de helpdesk
van <KLANT>.
- buiten kantooruren gemeld worden.of door
monitoring door <SLA-Nemer> worden
geconstateerd.
Classificeren initile ondersteuning VU Incidenten worden voorzien van classificatie en

prioriteit. <SLA-Nemer> voorziet de melder van een
ticketnummer; per e-mail binnen 1 uur , telefonisch
direct
Matchen VU <SLA-Nemer> controleert of het een Known Error

betreft en of een Work-around van toepassing is.
Analyse en diagnose U VU <SLA-Nemer> bepaalt of het incident in 2e of 3e lijn

opgelost moet worden, dan wel tot probleem moet
worden verheven.
<KLANT> heeft een actieve rol bij het analyseren en

diagnosticeren van incidenten. De
eindverantwoording blijft bij <SLA-Nemer>.
Dispatchen VU <SLA-Nemer> zet indien nodig incidenten door naar

externe oplossingsinstanties.
Oplossen en herstellen U VU Storing wordt verholpen in overleg met de melder.

<KLANT> heeft een actieve rol bij het oplossen van
incidenten. De eindverantwoording blijft bij <SLA-
Nemer>.
Incident afsluiten V U Het incident wordt gesloten en zowel de melder als

de helpdesk van <KLANT> wordt op de hoogte
gesteld.
V = Verantwoordelijk U = Uitvoerend
8
Incidenten die worden opgelost door een andere partij dan <SLA-Nemer> vallen buiten de
door <SLA-Nemer> gegarandeerde oplostijden. Indien "onderliggende " contracten van
toepassing zijn zal <SLA-Nemer> de voortgang van de incidenten bewaken met kennisneming
van de afspraken in deze contracten. Met onderliggende contracten worden contracten
bedoeld die <KLANT> zelf heeft afgesloten met een leverancier. Dit betreft dus niet de
leveranciers waar <SLA-Nemer> werkzaamheden naar heeft uitbesteed. <SLA-Nemer> is
eindverantwoordelijk voor de dienstverlening die in deze SLA is beschreven met een
resultaatsverplichting.
Uit hoofde van deze SLA is <SLA-Nemer> altijd hoofdaannemer en verantwoordelijk voor de
aansturing van eventuele onderaannemers die door <SLA-Nemer> zijn ingeschakeld om (een
deel van) de beschreven dienstverlening in te vullen.
Voor contracten die <KLANT> met leveranciers afsluit blijft <KLANT> verantwoordelijk voor
de aansturing tenzij daar expliciete afspraken met <SLA-Nemer> over gemaakt zijn of,
gedurende de contractperiode, gemaakt worden. Een en ander zal formeel vastgelegd
worden indien dit aan de orde komt.
Prioriteitsbepaling
Elk incident wordt volgens onderstaande tabel op prioriteit geclassificeerd:
Urgentie Primaire Kan bepaalde

Ondervindt hinder
applicatie is niet primaire functies
maar kan verder
of beperkt niet meer
werken.
beschikbaar gebruiken
Impact
- Vip Gebruikers
- Een belangrijke groep medewerkers (winkel,
1 1 3
kantoor, DC of afdeling)
- Alle medewerkers of alle pcs
- Enkele Medewerkers of enkele pcs

- 50% Afdeling medewerkers of pcs
1 2 3
- Enige gebruiker van een systeem
- Bijzondere situatie zoals verloning.
- 1 medewerker
(Indien hij/zij de enige gebruiker is zie Enkele

medewerkers) 3 3 3
- 1 PC (indien dit de enige pc is met belangrijke

software zie Enkele medewerkers)
9
In bijzondere gevallen bijvoorbeeld verloningsweek, geldt dat incidenten met een hoge
prioriteit (1) worden afgehandeld indien de urgentie duidelijk wordt aangegeven door de
<KLANT> helpdesk.
Service levels
KPI Omschrijving
Telefonische bereikbaarheid 100% gedurende het standaard service window (zie bijlage H)
servicedesk
Telefonische responsetijd 80% binnen 60 seconden

100% binnen 120 seconden
Oplossen hoge prioriteit (1) 80% binnen 4 werkuren

incidenten 100% binnen 8 werkuren
Oplossen midden prioriteit (2) 80% binnen 12 werkuren

Oplossen lage prioriteit (3) 80% binnen 24 werkuren

Start met oplossen van prioriteit 80% binnen 1 werkuur

1 incidenten 100% binnen 2 werkuren
De genoemde tijden gelden binnen afgesproken standaard service window (zie ook bijlage
H). Voor de genoemde oplostijden worden de service windows als aaneengesloten
beschouwd.
Indien een incident met prioriteit 1 wordt aangemeld vlak voor de eindtijd van het standaard
service window en de oplossing kan niet wachten tot de volgende werkdag, zal <SLA-Nemer>
doorwerken om het incident op te lossen. Dit in acht nemende de verantwoordelijkheden van
<SLA-Nemer> bepaald in bijlage F en in deze SLA.
Meldingsprocedure van incidenten
Incidenten kunnen telefonisch en/of per e-mail worden gemeld aan de Servicedesk van <SLA-
Nemer>. Zie bijlage B voor de contactinformatie.
1.3.1 Hoge prioriteit

Incidenten met een hoge prioriteit dienen tenminste telefonisch te worden gemeld indien
<KLANT> ervan verzekerd wil zijn dat de melding op het service level van prioriteit 1 wordt
afgehandeld.
1.3.2 Incidenten buiten service window

Urgente incidenten kunnen buiten het afgesproken service window worden gemeld volgens
de procedure beschreven in bijlage C.
Urgente incidenten zijn incidenten met prioriteit 1 en waarvan <KLANT> bepaalt dat de
oplossing niet tot de volgende werkdag kan wachten.
10
1.4 VIP regeling
Een beperkte groep gebruikers, maximaal <AANTAL> , kan worden aangemerkt als VIP. De
namen van deze VIP's worden opgenomen in bijlage B.
Als een VIP een incident meldt of een request for change indient geldt de volgende regeling:
het incident krijgt een hoge prioriteit als de gebruiker dat wenst en aangeeft
het request for change krijgt de status urgent als de gebruiker dat wenst en aangeeft
11
Change management
Doel
Change management moet zeker stellen dat gestandaardiseerde methoden en procedures

worden gebruikt bij het aanbrengen van wijzigingen aan de ICT infrastructuur. Het
belangrijkste doel hierbij is dat de kans op storingen als gevolg van de wijzigingen wordt
geminimaliseerd.
1.5 Soorten changes
Soort wijziging Omschrijving Autorisatie change mgr.
Minor change wijziging met zeer beperkte impact en risico Geen

waarvan de uitvoering minimale inspanning vergt.
Voorbeeld: reset password of unlock userid.
Standard change voorgedefinieerde veelvoorkomende wijziging met Geen

een beperkt risico en impact, waarvan de
noodzakelijke inspanning om de wijziging te
implementeren bekend en gelimiteerd is. Standard
changes worden uitgevoerd zonder toestemming
van de change manager mits aan de gestelde
voorwaarden is voldaan.
Voorbeeld: aanmaken user
Medium change wijziging met een gemiddelde impact en risico, Change manager middels
waarvan de noodzakelijke inspanning om de goedkeuring op RFC
wijziging te implementeren gelimiteerd is.
Major change omvangrijke wijzigingen met een grote impact en CAB en <SLA-Nemer>
risico. Een major change wordt ter beoordeling servicemanager
voorgelegd aan de Change Advisory Board (CAB).
Welke wijzigingen als minor en standard change worden beschouwd wordt beschreven in
bijlage G Standaard Wijzigingen. Minor en standard changes vallen binnen de scope van
deze SLA, de overige changes (medium en major) vallen buiten de scope en worden
uitgevoerd na akkoord door <KLANT> op een additionele offerte en goedkeuring op een PID
indien nodig. Het opstellen van een PID geschiedt na instemming van <KLANT> door <SLA-
Nemer>, valt buiten de scope van deze SLA en zal additioneel worden gefactureerd.
Als richtlijn voor autorisatie geldt dat een wijziging die meer dan <AANTAL> uur inspanning
vergt altijd geautoriseerd dient te worden door de <KLANT> change manager.
12
De scheidslijn tussen beperkte impact en gemiddelde impact is niet altijd even duidelijk. In
geval van twijfel zullen de servicemanager van <SLA-Nemer> en de change manager van
<KLANT> hierover overleggen.
1.5.1 Projecten
Projecten zijn wijzigingen met grote omvang en een grote impact op de resourceplanning van
<SLA-Nemer>, ze vallen derhalve buiten de scope van de SLA.
1.5.2 Frequente changes

Indien bepaalde medium of major changes frequent voorkomen kunnen daarover vaste
afspraken worden gemaakt ten aanzien van werkwijze, autorisatie en prijs. Een en ander zal
gedurende de SLA periode tussen <KLANT> en <SLA-Nemer> worden afgesproken.
Activiteiten

Nemer
>
registratie en classificatie V VU De RFC wordt geregistreerd in het <SLA-Nemer>

servicedesk tool. Het type change en de impact
worden bepaald door <KLANT> aan de hand van
scenarios; minor, standard, medium of major
change.
Urgentie en impact wordt bepaald.
beoordeling en planning V VU Minor en standard changes worden ingepland.
Uitvoering VU Change wordt uitgevoerd en getest binnen de SLA

tijd.
afsluiting en evaluatie V VU De change wordt gevalueerd tegen het beoogde

resultaat, gereed gemeld bij aanvrager en de
helpdesk van <KLANT> en na goedkeuring
<KLANT> afgesloten in het <SLA-Nemer>
servicedesk tool.
V = Verantwoordelijk
U = Uitvoerend
Service levels
KPI Omschrijving
13
Uitvoeren minor change 80% binnen 8 werkuren

100% binnen 24 werkuren
Uitvoeren urgente minor change 80% binnen 4 werkuren

Uitvoeren standard change 90% binnen 48 werkuren

Uitvoeren urgente standard 90% binnen 24 werkuren

change 100% binnen 48 werkuren
Uitvoeren medium change In overleg (buiten SLA)
Uitvoeren major change In overleg (buiten SLA)
1.6 Change procedure
Nader in te vullen inclusief urgent change procedure
Deze paragraaf wordt opgenomen in bijlage I (DAP).
1.7 Offerte procedure
Nader in te vullen (actie <KLANT>). Inclusief oplevertijd offerte (actie <SLA-Nemer> na input
van <KLANT>)
Deze paragraaf wordt opgenomen in bijlage I (DAP).
14
Problem management
Doel
Problem management heeft als doel de kwaliteit van de dienstverlening te verbeteren door
de onderliggende oorzaak van incidenten op te sporen en weg te nemen en zo te voorkomen
dat zij nog eens optreden.
Activiteiten

Nemer
>
Identificatie en registratie VU De incidentendatabase wordt geanalyseerd. Voor

incidenten met onbekende oorzaak wordt een
probleem aangemaakt in het Servicemanagement
tool met de juiste (organisatorische) impact.
Tevens kan de problemmanager van <KLANT> een

problem initiren aan de hand van incidenten of
impact.
Classificatie en allocatie. VU Aan de hand van de impact en urgentie wordt de

correcte prioriteit toegekend en de juiste mensen en
middelen gealloceerd om het probleem op te lossen.
Onderzoek en diagnose. VU Het probleem wordt onderzocht en de oorzaak

wordt vastgesteld. De Known Error wordt
gedocumenteerd. Wanneer de oplossing bekend is
wordt deze via een Request For Change (RFC) aan
Change management doorgegeven.
Oplossing en VU Nadat de RFC door Change mgt is afgehandeld wordt

door de Problem owner een Post Implementation
Afsluiting Review (PIR) gedaan; controleer of de wijziging het
probleem heeft opgelost.
Het probleem wordt afgesloten, de gekoppelde

incidenten worden afgehandeld en gebruiker(s)
genformeerd.
U = Uitvoerend
15
Service levels
Service level Omschrijving
Work-arounds Wanneer een work-around van een of meerdere incidenten bekend is,
wordt dat afgestemd met de servicedesk die dit communiceert met de
gebruiker en de problemmanager van <KLANT>.
Wijzigingsvoorstellen Minimaal X keer per jaar maar verder zo vaak als noodzakelijk, zal problem
management met verbetervoorstellen komen die het resultaat zijn van
incident trendanalyse en het monitoren van de infrastructuur.
Verbetervoorstellen zijn afhankelijk van hoeveelheid en complexiteit

problemen.
Rapportage openstaande <SLA-Nemer> rapporteert de status van openstaande problemen in het

problemen. operationeel overleg. Tevens rapporteert <SLA-Nemer> over de door <SLA-
Nemer> besteedde uren aan problem management.
16
Configuration management
Doel
Het doel van Configuration management is het bijhouden van een betrouwbare registratie van
gegevens over de ICT infrastructuur en het verschaffen van accurate informatie over deze
gegevens ter ondersteuning van de overige processen.
Activiteiten

Nemer
>
Planning V U In overleg tussen <KLANT> en <SLA-Nemer>

wordt de scope en de detaillering van de
Configuration Management DataBase (CMDB)
bepaald. Onder andere worden de attributen per
Configuration Items (CI) bepaald.
Identificatie VU Ter identificatie worden alle CIs voorzien van

stickers met een CI-nummer. <KLANT> zal deze
stickers verstekken.
Beheer V VU <SLA-Nemer> zorgt ervoor dat geautoriseerde

wijzigingen op de CMDB worden geregistreerd.
Verificatie en Statusbewaking V U <SLA-Nemer> zorgt voor de opslag van actuele

gegevens over de status van een CI.
<KLANT> zal periodiek audits (laten) uitvoeren
om de correctheid van de CMDB te toetsen.
U = Uitvoerend
Service levels
KPI Omschrijving
Registratiesnelheid <SLA-Nemer> registreert mutaties op de CMDB binnen (X) werkdagen na

geautoriseerde wijziging in 90% van alle gevallen.
Correctheid CMDB <SLA-Nemer> garandeert een correctheid van 90% op elk gewenst
meetmoment.
Verificatie Steekproefsgewijs zal <SLA-Nemer> de CMDB 1 keer per kwartaal

controleren
<KLANT> is verantwoordelijk voor het doorgeven van wijzigingen in de ICT infrastructuur aan
<SLA-Nemer>.Indien <SLA-Nemer> zelf wijzigingen aanbrengt in de infrastructuur, zorgen zij
voor een aanpassing in de CMDB.
17
2 ICT infrastructure management
2.1 Doel
ICT infrastructure management is verantwoordelijk voor het waarborgen van een stabiele
infrastructuur. Technische en operationele processen worden bewaakt zodat de
beschikbaarheid optimaal is en eventuele dreigende verstoringen worden voorkomen. De
operationele activiteiten van availability management, capacity management en continuity
management worden binnen ICT infrastructure management uitgevoerd.
2.2 Operations
Activities <KLANT> <SLA- Description

Nemer>
Event afhandeling VU <SLA-Nemer> controleert de event logs en

behandelt voorkomende events.
<SLA-Nemer> registreert in voorkomende

gevallen een incident.
Backup en restore VU VU <SLA-Nemer> richt het back-up proces in volgens

richtlijnen van <KLANT> en beschrijft de
procedure in het site manual.
<SLA-Nemer> controleert het back-up process en

neemt maatregelen indien fouten worden
geconstateerd.
Restoren van user data wordt als standaard

change uitgevoerd door <SLA-Nemer>.
<KLANT> stelt benodigde tapes beschikbaar.
Server monitoring VU VU <SLA-Nemer> monitoort dagelijks de servers

genoemd in Appendix E.
Patch management V VU <SLA-Nemer> beheert en installeert de

benodigde OS patches volgens een nader af te
spreken procedure.
Security policy V U <SLA-Nemer> conformeert zich aan de

<KLANT> security policy.
U = Uitvoerend
18
Service levels
KPI Description
Installeren Server OS patches Eens per (X) maanden
Installeren Server emergency patches Binnen (X) werkdagen
Controleren back-up Elke dag
2.3 Availability management
Het doel van availability management is het zorgen voor de gewenste beschikbaarheid van
de ICT dienstverlening opdat de bedrijfsdoelstelling wordt behaald.

Nemer
>
Bepalen van VU <KLANT> bepaalt de

beschikbaarheidbehoeften beschikbaarheidsbehoeften voor de
verschillende ICT componenten.
Ontwerpen van beschikbaarheid VU <KLANT> is verantwoordelijk voor het (laten)

ontwerpen van de ICT infrastructuur die voldoet
aan de gewenste beschikbaarheid.
Aandachtspunten voor beveiliging V VU <SLA-Nemer> conformeert zich aan de

<KLANT> security policy.
Managen van V VU Indien onderhoud noodzakelijk is zullen <SLA-

onderhoudsactiviteiten Nemer> en <KLANT> dit in overleg plannen.
Meten en rapporteren VU Indien garanties over beschikbaarheid zijn

afgegeven zal <SLA-Nemer> hierover
rapporteren.
Opstellen beschikbaarheidplan VU
U = Uitvoerend
Service levels
KPI Description
Beschikbaarheid van de door <SLA-Nemer> 99,9% op jaarbasis

beheerde infrastructuur
Rapportage beschikbaarheid van de afgelopen Elke maand in de management rapportage
19
maand
Beschikbaarheid wordt gemeten over 7 dagen per week, 24 uur per dag en berekend over
een jaargemiddelde. Geplande downtime geldt niet als onbeschikbare tijd.
De beschikbaarheid wordt als volgens de volgende formule:
beschikbare tijd (ongeplande) downtime

% beschikbaarheid = X 100%
beschikbare tijd
De totale jaarlijkse tijd dat een systeem niet beschikbaarheid is, wordt getotaliseerd op basis
van de maandelijkse rapportages.
Elk incident dat de beschikbaarheid van een systeem benvloed (systeem stop -
systeem herstart) wordt automatisch vastgelegd in de foutlogging van het
betreffende systeem.
Systeem onbeschikbaarheid wordt berekend op basis van ongeplande niet
beschikbaarheid die het gevolg is van een hardware en/of OS fout die een
interventie door <SLA-Nemer> vereist.
De niet beschikbaarheid van apparatuur wordt gemeten vanaf het tijdstip waarop
het probleem door <SLA-Nemer> gedetecteerd of gemeld is.
De apparatuur is beschikbaar vanaf het moment dat de Operating System prompt
beschikbaar komt voor het herstellen van de data. Met andere woorden, tot het punt
waarop de apparatuur terug is in werkende conditie. In geval van een geclusterde
omgeving is deze beschikbaar indien een van de nodes beschikbaar is.
Onbeschikbaarheid wordt niet geregistreerd:
Indien <KLANT> in overleg aangeeft dat herstel van het incident op een later
moment kan plaatsvinden. De meting van de beschikbaarheid start dan wanneer het
herstel aanvangt.
Indien <SLA-Nemer> niet de noodzakelijke toegang tot de systemen wordt verleend.
Tijdens geplande werkzaamheden ter uitbreiding, opwaardering of het her-
configureren van apparatuur en tijdens normaal gepland onderhoud.
Tijdens wachttijd als gevolg van het niet kunnen uitvoeren van een interventie in
opdracht van <KLANT> of een derde partij.
Indien de onbeschikbaarheid wordt veroorzaakt door applicaties, het netwerk of de
omgevingsomstandigheden
Tijdens een overmachtsituatie: Indien het voor <SLA-Nemer> onmogelijk is om
toegang te krijgen tot de apparatuur of service te verlenen door een oorzaak die
buiten de controle van <SLA-Nemer> valt.
20
Indien de apparatuur beschikbaar is in een beperkte mode. Hierbij geldt als minimale
vereiste dat de applicatie op 50% van de normale capaciteit beschikbaar is.
Tijdens downtijd die het gevolg is van het niet implementeren (op verzoek van
<KLANT>) van door <SLA-Nemer> geadviseerde kritische firmware en/of software
updates en patches.
2.4 Capacity management
De taak van capacity management is het pro-actief beschikbaar stellen van de juiste
capaciteit aan ICT resources ten einde aan de behoefte van de klant tegemoet te komen
tegen aanvaardbare kosten.

Nemer>
Business capacity management VU Opstellen capaciteitsplan
Meten en rapporteren VU Periodiek rapporteren over capacity
Service en resource capacity VU <SLA-Nemer> monitoort de beschikbaarheid van

management de gewenste capaciteit en adviseert <KLANT>
pro-actief.
Indien grenswaarden worden overschreden

wordt hiervan een incident gemaakt.
U = Uitvoerend
2.5 Release management
Het doel van release management is het beheren en distribueren van hardware- en
softwareversies die door ICT worden ondersteund, teneinde te voldoen aan het vereiste
niveau van de dienstverlening.

Nemer>
Release beleid en planning VU Bepalen op welke wijze releases worden

samengesteld en gedistribueerd
Ontwerpen, bouwen en VU Het release ontwerpen, bouwen en samenstellen

samenstellen
Testen en acceptatie VU Functioneel testen en accepteren van het release
21
Audit en evaluatie VU Toetsen en evalueren van de toegepaste

beveiligingsregels
Roll-out planning VU De wijze van uitrol bepalen.
Communicatie en training VU Informeren en trainen van belanghebbenden.
Rapporteren VU Periodiek rapporteren over releases
Installatie en distributie VU Uitol van het release. Binnen Configuration

management wijzigingen aan de CMDB doorvoeren.
U = Uitvoerend
2.6 Continuity management
Het doel van continuity management is het ondersteunen van de primaire bedrijfsprocessen
door zeker te stellen dat de ICT dienstverlening na een calamiteit zo snel mogelijk weer
wordt hersteld.

Nemer
>
Bepalen van de scope VU
Business-impactanalyse VU
Risicoanalyse VU
Business continuity strategie VU
Planning van organisatie en VU

implementatie
Voorzorgsmaatregelen en VU Zorgen voor een correcte back-up

herstelopties
Ontwikkel plannen en procedures VU

voor herstel
Initieel testen VU U <SLA-Nemer> participeert in het door <KLANT>

opgestelde continuity plan.
Opleiding, training en bekendheid VU
Review en audit VU
Testing VU U <SLA-Nemer> voert in opdracht van en in
22
samenwerking met <KLANT> continuity tests

uit.
Change management VU
Controle VU
U = Uitvoerend
Service levels
KPI Description
Uitwijktesten Elk jaar dient van elk systeem een uitwijktest gedaan te worden.
Continuity plan
De exacte werkzaamheden en verplichtingen van <SLA-Nemer> ten aanzien van continuity
management, worden beschreven in het door <KLANT> opgestelde continuity plan. Dit
document wordt opgenomen in het site manual van <SLA-Nemer>.
Randvoorwaarden
Indien de uitvoering van de continuity tests buiten het service window van deze SLA vallen zal
<SLA-Nemer> de extra kosten in rekening brengen.
2.7 Security management
Het doel van security management is enerzijds het realiseren van de <KLANT> specifieke
beveiligingseisen of door wetgeving opgelegde vereisten. Anderzijds het realiseren van een
zeker basisniveau aan beveiliging mede om de continuteit van de beheerorganisatie te
waarborgen. Deze beveiliging heeft betrekking op vertrouwelijkheid, de integriteit en de
beschikbaarheid van informatie.

Nemer>
Sturing en beleid VU <KLANT> stelt de security policy op met

beveiligingsregels
Planning VU U <KLANT> formaliseert de security policy in

contracten
Implementatie VU <SLA-Nemer> conformeert zich aan de <KLANT>

security policy met betrekking tot de in deze SLA
23
beschreven beheerdiensten.
Afhandelen security incidenten VU <SLA-Nemer> registreert en communiceert over

security incidenten volgens de security policy.
<SLA-Nemer> rapporteert over de security-

incidenten en problemen.
<SLA-Nemer> registreert de uitgevoerde

handelingen in de worklog van het incident in het
<SLA-Nemer> servicedesktool.
Zie ook hoofdstuk "Incident management".
Personeel en informatiebeveiliging <SLA-Nemer> is ISO9001:2000 gecertificeerd

(KEMA nr. 45790). In het kwaliteitssysteem is de
informatiebeveiliging opgenomen.
Audit en evaluatie VU <KLANT> voert audits uit op de dienstverlening

van <SLA-Nemer> ten aanzien van security.
Onderhouden VU <KLANT> past de security policy aan bij

veranderingen in de ICT infrastructuur.
U = Uitvoerend
Service levels
KPI Description
Melding security incident Security incidenten met een hoge severity worden binnen 1 uur na detectie gemeld
aan de <KLANT> incident manager.
Rapporteren security Tijdens het maandelijkse management overleg.

incidenten
24
Service level management
Doel
Deze Service Level Agreement (SLA) is het eindproduct van een proces waarin de eisen en
wensen van <KLANT> en de leveringsmogelijkheden van <SLA-Nemer> op elkaar zijn
afgestemd. <SLA-Nemer> verplicht zicht tot het continu onderhouden en verbeteren van de in
deze Service Level Agreement (SLA) afgesproken dienstverlening.
2.8 Activiteiten

Nemer>
Monitoren VU <SLA-Nemer> meet aan de hand van de Key

Performance Indicators (KPI's) het niveau van de
geleverde diensten.
Rapporteren VU Periodiek zal <SLA-Nemer> rapporteren over de

geleverde prestaties. De rapportages zullen in de
vorm van een Business Balanced Scorecard
worden gepresenteerd.
Escalaties zullen worden gerapporteerd.
Evalueren VU De opgeleverde rapportages worden periodiek

besproken in een management overleg.
SLA.Nemer zal zorgen voor de verslaglegging van
deze vergaderingen.
Wijzigen VU Indien <KLANT> de inhoud van deze SLA wenst

te wijzingen dient dit verzoek schriftelijk te
worden ingediend bij de servicemanager. De
consequenties van de wijziging alsmede
eventuele prijsveranderingen zullen in het
managementoverleg worden besproken.
U = Uitvoerend
25
Service Levels
Service Level Agreement
KPI Omschrijving
Wijzigen van afgenomen diensten Eens per half jaar.

en hun niveaus
Nieuwe versie van SLA waarin Maximaal eens per jaar (als er wijzigingen zijn).
wijzigingen zijn verwerkt
Bespreken van geleverde Eens per maand.

diensten
Rapportage
KPI Omschrijving
Rapportage over geleverde Eens per maand zal <SLA-Nemer> over alle in deze SLA gedefinieerde
diensten service levels rapporteren.
Escalatie rapportage en evaluatie Wanneer nodig
Additionele rapportages kunnen worden opgeleverd na akkoord van <KLANT> op een

prijsopgave van <SLA-Nemer>.
Overlegstructuur
2.8.1 Operationeel
Wekelijks wordt een operationeel overleg gehouden waarin de volgende personen
participeren.
<KLANT>: Proceseigenaren
<SLA-Nemer>: Servicedesk engineer
2.8.2 Change management Board (CMB) meeting

Wekelijks wordt CMB overleg gehouden waarbij de volgende personen aanwezig zijn:
<KLANT>: Change manager
<SLA-Nemer>: Servicedesk engineer / service manager.
26
2.8.3 Management meeting

Maandelijks wordt de management meeting gehouden waarbij de volgende personen
aanwezig zijn:
<KLANT>: Service manager
<SLA-Nemer>: Service manager
2.8.4 Evaluatie meeting

Eenmaal per jaar wordt een evaluatie meeting gehouden waarbij de volgende personen
aanwezig zijn:
<KLANT>: Manager ICT
<SLA-Nemer>: Delivery manager
27

Hoofd SLA

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

Hoofd SLA

Uploaded by

Copyright:

Available Formats

Voorbeeld Service Level Agreement Winkelsystemen

Voorbeeld Service Level Agreement

< NAAM KLANT>

Klant : <NAAM KLANT>

Naam Functie Telefoon Emailadres

Voor akkoord Voor akkoord

Doel: Vastlegging van service levels betreffende de dienstverlening voor

Referentie naar: Overeenkomst

Auteur: <Behandeld door>

Revisie: reden: Door: Datum:

6 ICT infrastructure management 18

6.7.1 Service levels 24

7 Service level management 25

De hier beschreven dienstverlening wordt georganiseerd en ingericht volgens ITIL richtlijnen.

Dit document bevat de volgende bijlagen:

Bijlage A: Definities en afkortingen

Bijlage B: Contactpersonen en rollen

Bijlage C: Communicatie en Escalatie

Bijlage E: Configuratie Items

Bijlage F: Matrix Software Ondersteuning

Bijlage I: Dossier Afspraken en Procedures (DAP)

Vastlegging van gemaakte afspraken en beschrijving van de procedures.

1.1 Scope van de dienstverlening

Wanneer door <KLANT> binnen de overeengekomen contractperiode wijzigingen worden

Duur van de overeenkomst

1.2 Overige bepalingen

1.3 Algemene Leveringsvoorwaarden

De beschreven dienstverlening geschiedt in overeenstemming met de in dit document

Activiteiten <KLANT> <SLA- Omschrijving

Aannemen en registreren V U <KLANT> vult 1e lijns ondersteuning in.

<SLA-Nemer> registreert alle incidenten in het <SLA-

- telefonisch of per e-mail gemeld worden bij

Classificeren initile ondersteuning VU Incidenten worden voorzien van classificatie en

Matchen VU <SLA-Nemer> controleert of het een Known Error

Analyse en diagnose U VU <SLA-Nemer> bepaalt of het incident in 2e of 3e lijn

<KLANT> heeft een actieve rol bij het analyseren en

Dispatchen VU <SLA-Nemer> zet indien nodig incidenten door naar

Oplossen en herstellen U VU Storing wordt verholpen in overleg met de melder.

Incident afsluiten V U Het incident wordt gesloten en zowel de melder als

Urgentie Primaire Kan bepaalde

- Enkele Medewerkers of enkele pcs

(Indien hij/zij de enige gebruiker is zie Enkele

- 1 PC (indien dit de enige pc is met belangrijke

Telefonische responsetijd 80% binnen 60 seconden

Oplossen hoge prioriteit (1) 80% binnen 4 werkuren

Oplossen midden prioriteit (2) 80% binnen 12 werkuren

Oplossen lage prioriteit (3) 80% binnen 24 werkuren

Start met oplossen van prioriteit 80% binnen 1 werkuur

Meldingsprocedure van incidenten

1.3.1 Hoge prioriteit

1.3.2 Incidenten buiten service window

1.4 VIP regeling

Change management moet zeker stellen dat gestandaardiseerde methoden en procedures

1.5 Soorten changes

Soort wijziging Omschrijving Autorisatie change mgr.

Minor change wijziging met zeer beperkte impact en risico Geen

Voorbeeld: reset password of unlock userid.

Standard change voorgedefinieerde veelvoorkomende wijziging met Geen

Voorbeeld: aanmaken user

1.5.2 Frequente changes

Activiteiten <KLANT> <SLA- Omschrijving

registratie en classificatie V VU De RFC wordt geregistreerd in het <SLA-Nemer>

beoordeling en planning V VU Minor en standard changes worden ingepland.