Voorbeeld Service Level Agreement

Voorbeeld Service Level Agreement Winkelsystemen

Winkelsystemen

Voorbeeld Service Level Agreement

Servicelevelnummer :

< NAAM KLANT>

Datum :

Klant : <NAAM KLANT>

Behandeld door :

Adres gegevens

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 Efficiënt 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.


Contactpersonen

Naam Functie Telefoon Emailadres


Ondertekening

Voor akkoord

<Opdrachtnemer>.

Voor akkoord

<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 51.1 Documentstructuur 51.2 Scope van de dienstverlening 71.3 Geheimhouding71.4 Duur van de overeenkomst 71.5 Overige bepalingen 71.6 Algemene Leveringsvoorwaarden 7

2 Incident management 82.1 Doel 82.2 Activiteiten 8

2.2.1 Prioriteitsbepaling 92.3 Service levels 102.4 Meldingsprocedure van incidenten 10

2.4.1 Hoge prioriteit 10

2.4.2 Incidenten buiten service window 102.5 VIP regeling 11

3 Change management 123.1 Doel 123.2 Soorten changes 12

3.2.1 Projecten 13

3.2.2 Frequente changes 133.3 Activiteiten 133.4 Service levels 143.5 Change procedure 143.6 Offerte procedure 14

4 Problem management 154.1 Doel 154.2 Activiteiten 154.3 Service levels 16

5 Configuration management 175.1 Doel 175.2 Activiteiten 175.3 Service levels 17

6 ICT infrastructure management 186.1 Doel 186.2 Operations 18

6.2.1 Service levels 196.3 Availability management 19

6.3.1 Service levels 196.4 Capacity management 216.5 Release management 216.6 Continuity management22

6.6.1 Service levels 23

6.6.2 Continuity plan 23

6.6.3 Randvoorwaarden 236.7 Security management 23

3


6.7.1 Service levels 24

7 Service level management 257.1 Doel 257.2 Activiteiten 257.3 Service Levels 26

7.3.1 Service Level Agreement 267.4 Rapportage 267.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


1 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.

1.1 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 afkortingenOverzicht van definities en afkortingen die algemeen van toepassing zijn.

Bijlage B: Contactpersonen en rollenOverzicht van de personen met de rol t.a.v. deze SLA.

Bijlage C: Communicatie en EscalatieDe beschrijving van de procedures die gebruikt worden bij de uitvoering van deze SLA.

Bijlage D: WijzigingsbladIn 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 OndersteuningOverzicht 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: ScopebepalingDefinitie van de reikwijdte van de dienstverlening.

Bijlage I: Dossier Afspraken en Procedures (DAP)

Vastlegging van gemaakte afspraken en beschrijving van de procedures.

6


1.2 Scope van de dienstverleningDe 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 substantiële toename van de werkzaamheden veroorzaken zal tussen partijen overleg worden gevoerd over een mogelijk noodzakelijke aanpassing van deze SLA. Zie ook Bijlage H.

1.3 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.

1.4 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.5 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.

7


1.6 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>

8


2 Incident management

2.1 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.

2.2 Activiteiten

Activiteiten <KLANT> <SLA-Nemer>

Omschrijving

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 initiële 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.

9


V = Verantwoordelijk U = UitvoerendIncidenten 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.

2.2.1 Prioriteitsbepaling

Elk incident wordt volgens onderstaande tabel op prioriteit geclassificeerd:

Urgentie

Impact

Primaire applicatie is niet of beperkt beschikbaar

Kan bepaalde primaire functies niet meer gebruiken

Ondervindt hinder maar kan verder werken.

- Vip Gebruikers - Een belangrijke groep medewerkers (winkel, kantoor, DC of afdeling)- Alle medewerkers of alle pc’s

1 1 3

- Enkele Medewerkers of enkele pc’s- 50% Afdeling medewerkers of pc’s- Enige gebruiker van een systeem - Bijzondere situatie zoals verloning.

1 2 3

- 1 medewerker

(Indien hij/zij de enige gebruiker is zie “Enkele medewerkers”)

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

3 3 3

10


software zie “Enkele medewerkers”)

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.

2.3 Service levels

KPI Omschrijving

Telefonische bereikbaarheid servicedesk

100% gedurende het standaard service window (zie bijlage H)

Telefonische responsetijd 80% binnen 60 seconden

100% binnen 120 seconden

Oplossen hoge prioriteit (1) incidenten

80% binnen 4 werkuren


Oplossen midden prioriteit (2) incidenten



Oplossen lage prioriteit (3) incidenten



Start met oplossen van prioriteit 1 incidenten

80% binnen 1 werkuur


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.

2.4 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.

2.4.1 Hoge prioriteitIncidenten 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.

2.4.2 Incidenten buiten service windowUrgente incidenten kunnen buiten het afgesproken service window worden gemeld volgens de procedure beschreven in bijlage C.

11


Urgente incidenten zijn incidenten met prioriteit 1 en waarvan <KLANT> bepaalt dat de oplossing niet tot de volgende werkdag kan wachten.

2.5 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

12


3 Change management

3.1 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.

3.2 Soorten changes

Soort wijziging Omschrijving Autorisatie change mgr.

Minor change wijziging met zeer beperkte impact en risico waarvan de uitvoering minimale inspanning vergt.

Voorbeeld: reset password of unlock userid.

Geen

Standard change voorgedefinieerde veelvoorkomende wijziging met 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

Geen

Medium change wijziging met een gemiddelde impact en risico, waarvan de noodzakelijke inspanning om de wijziging te implementeren gelimiteerd is.

Change manager middels goedkeuring op RFC

Major change omvangrijke wijzigingen met een grote impact en risico. Een major change wordt ter beoordeling voorgelegd aan de Change Advisory Board (CAB).

CAB en <SLA-Nemer> servicemanager

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.

13


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.

3.2.1 ProjectenProjecten zijn wijzigingen met grote omvang en een grote impact op de resourceplanning van <SLA-Nemer>, ze vallen derhalve buiten de scope van de SLA.

3.2.2 Frequente changesIndien 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.

3.3 Activiteiten


Omschrijving

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 scenario’s; 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 geëvalueerd 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

14


3.4 Service levels

KPI Omschrijving

Uitvoeren minor change 80% binnen 8 werkuren


Uitvoeren urgente minor change 80% binnen 4 werkuren


Uitvoeren standard change 90% binnen 48 werkuren


Uitvoeren urgente standard change



Uitvoeren medium change In overleg (buiten SLA)

Uitvoeren major change In overleg (buiten SLA)

3.5 Change procedure

Nader in te vullen inclusief urgent change procedure

Deze paragraaf wordt opgenomen in bijlage I (DAP).

3.6 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).

15


4 Problem management

4.1 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.

4.2 Activiteiten


Omschrijving

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 initiëren 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

Afsluiting

VU Nadat de RFC door Change mgt is afgehandeld wordt door de Problem owner een Post Implementation Review (PIR) gedaan; controleer of de wijziging het probleem heeft opgelost.

Het probleem wordt afgesloten, de gekoppelde incidenten worden afgehandeld en gebruiker(s) geïnformeerd.


U = Uitvoerend

16


4.3 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 problemen.

<SLA-Nemer> rapporteert de status van openstaande problemen in het operationeel overleg. Tevens rapporteert <SLA-Nemer> over de door <SLA-Nemer> besteedde uren aan problem management.

17


5 Configuration management

5.1 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.

5.2 Activiteiten


Omschrijving

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 CI’s 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

5.3 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.

18


6 ICT infrastructure management

6.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.

6.2 Operations

Activities <KLANT> <SLA-Nemer>

Description

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

19


6.2.1 Service levels

KPI Description

Installeren Server OS patches Eens per (X) maanden

Installeren Server emergency patches Binnen (X) werkdagen

Controleren back-up Elke dag

6.3 Availability management

Het doel van availability management is het zorgen voor de gewenste beschikbaarheid van de ICT dienstverlening opdat de bedrijfsdoelstelling wordt behaald.


Omschrijving

Bepalen van beschikbaarheidbehoeften

VU <KLANT> bepaalt de 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 onderhoudsactiviteiten

V VU Indien onderhoud noodzakelijk is zullen <SLA-

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


KPI Description

Beschikbaarheid van de door <SLA-Nemer> beheerde infrastructuur

99,9% op jaarbasis

20


Rapportage beschikbaarheid van de afgelopen maand

Elke maand in de management rapportage

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 beïnvloed (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

21


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.

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.

6.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.


Omschrijving

Business capacity management VU Opstellen capaciteitsplan

Meten en rapporteren VU Periodiek rapporteren over capacity

Service en resource capacity management

VU <SLA-Nemer> monitoort de beschikbaarheid van

de gewenste capaciteit en adviseert <KLANT> pro-actief.

Indien grenswaarden worden overschreden wordt hiervan een incident gemaakt.


U = Uitvoerend

6.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.


Omschrijving

Release beleid en planning VU Bepalen op welke wijze releases worden

22


samengesteld en gedistribueerd

Ontwerpen, bouwen en samenstellen

VU Het release ontwerpen, bouwen en samenstellen

Testen en acceptatie VU Functioneel testen en accepteren van het release

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

6.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.


Omschrijving

Bepalen van de scope VU

Business-impactanalyse VU

Risicoanalyse VU

Business continuity strategie VU

Planning van organisatie en implementatie

VU

Voorzorgsmaatregelen en herstelopties

VU Zorgen voor een correcte back-up

Ontwikkel plannen en procedures voor herstel

VU

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

23


opgestelde continuity plan.

Opleiding, training en bekendheid VU

Review en audit VU

Testing VU U <SLA-Nemer> voert in opdracht van en in

samenwerking met <KLANT> continuity tests uit.

Change management VU

Controle VU


U = Uitvoerend


KPI Description

Uitwijktesten Elk jaar dient van elk systeem een uitwijktest gedaan te worden.

6.6.2 Continuity planDe 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>.

6.6.3 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.

6.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 continuïteit van de beheerorganisatie te waarborgen. Deze beveiliging heeft betrekking op vertrouwelijkheid, de integriteit en de beschikbaarheid van informatie.


Omschrijving

24


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 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


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 incidenten

Tijdens het maandelijkse management overleg.

25


7 Service level management

7.1 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.

7.2 Activiteiten


Omschrijving

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

26


7.3 Service Levels

7.3.1 Service Level Agreement

KPI Omschrijving

Wijzigen van afgenomen diensten en hun niveaus

Eens per half jaar.

Nieuwe versie van SLA waarin wijzigingen zijn verwerkt

Maximaal eens per jaar (als er wijzigingen zijn).

Bespreken van geleverde diensten

Eens per maand.

7.4 Rapportage

KPI Omschrijving

Rapportage over geleverde diensten

Eens per maand zal <SLA-Nemer> over alle in deze SLA gedefinieerde service levels rapporteren.

Escalatie rapportage en evaluatie Wanneer nodig

Additionele rapportages kunnen worden opgeleverd na akkoord van <KLANT> op een prijsopgave van <SLA-Nemer>.

7.5 Overlegstructuur

7.5.1 OperationeelWekelijks wordt een operationeel overleg gehouden waarin de volgende personen participeren.

<KLANT>: Proceseigenaren

<SLA-Nemer>: Servicedesk engineer

7.5.2 Change management Board (CMB) meetingWekelijks wordt CMB overleg gehouden waarbij de volgende personen aanwezig zijn:

<KLANT>: Change manager

<SLA-Nemer>: Servicedesk engineer / service manager.

27


7.5.3 Management meetingMaandelijks wordt de management meeting gehouden waarbij de volgende personen aanwezig zijn:

<KLANT>: Service manager

<SLA-Nemer>: Service manager

7.5.4 Evaluatie meetingEenmaal per jaar wordt een evaluatie meeting gehouden waarbij de volgende personen aanwezig zijn:

<KLANT>: Manager ICT

<SLA-Nemer>: Delivery manager

28

Voorbeeld Service Level Agreement

Technology

Transcript of Voorbeeld Service Level Agreement