Winkelsystemen. Voorbeeld Service Level Agreement Winkelsystemen. Voorbeeld Service Level Agreement. Servicelevelnummer : < NAAM KLANT>

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

Datum : Klant : Behandeld door :


Contactpersonen Naam

Functie

Telefoon

Emailadres


Ondertekening

Voor akkoord

Voor akkoord

.

Naam:

Naam:

Functie:

Functie:

Datum:

Datum:

Handtekening:

Handtekening:


Document Control

Vastlegging van service levels betreffende de dienstverlening voor

Doel:

Bereik: Referentie naar:

Overeenkomst

Auteur:

Versiebeheer

Revisie:

reden:

Door:

Datum:


Inhoud 1 1.1 1.2 1.3 1.4 1.5 1.6

Algemeen ........................................................................................................................ 5 Documentstructuur ........................................................................................................... 5 Scope van de dienstverlening .......................................................................................... 7 Geheimhouding ................................................................................................................ 7 Duur van de overeenkomst .............................................................................................. 7 Overige bepalingen .......................................................................................................... 7 Algemene Leveringsvoorwaarden .................................................................................... 7

2 2.1 2.2 2.2.1 2.3 2.4 2.4.1 2.4.2 2.5

Incident management .................................................................................................... 8 Doel .................................................................................................................................. 8 Activiteiten ........................................................................................................................ 8 Prioriteitsbepaling ............................................................................................................. 9 Service levels .................................................................................................................10 Meldingsprocedure van incidenten ................................................................................10 Hoge prioriteit .................................................................................................................10 Incidenten buiten service window...................................................................................10 VIP regeling ....................................................................................................................11

3 3.1 3.2 3.2.1 3.2.2 3.3 3.4 3.5 3.6

Change management ...................................................................................................12 Doel ................................................................................................................................12 Soorten changes ............................................................................................................12 Projecten ........................................................................................................................13 Frequente changes ........................................................................................................13 Activiteiten ......................................................................................................................13 Service levels .................................................................................................................14 Change procedure ..........................................................................................................14 Offerte procedure ...........................................................................................................14

4 4.1 4.2 4.3

Problem management ..................................................................................................15 Doel ................................................................................................................................15 Activiteiten ......................................................................................................................15 Service levels .................................................................................................................16

5 5.1 5.2 5.3

Configuration management .........................................................................................17 Doel ................................................................................................................................17 Activiteiten ......................................................................................................................17 Service levels .................................................................................................................17

6 6.1 6.2 6.2.1 6.3 6.3.1 6.4 6.5 6.6 6.6.1 6.6.2 6.6.3

ICT infrastructure management ..................................................................................18 Doel ................................................................................................................................18 Operations ......................................................................................................................18 Service levels .................................................................................................................19 Availability management ................................................................................................19 Service levels .................................................................................................................19 Capacity management ...................................................................................................21 Release management ....................................................................................................21 Continuity management .................................................................................................22 Service levels .................................................................................................................23 Continuity plan ................................................................................................................23 Randvoorwaarden ..........................................................................................................23

3


6.7 Security management ....................................................................................................23 6.7.1 Service levels .................................................................................................................24 7 7.1 7.2 7.3 7.3.1 7.4 7.5 7.5.1 7.5.2 7.5.3 7.5.4

Service level management ..........................................................................................25 Doel ................................................................................................................................25 Activiteiten ......................................................................................................................25 Service Levels ................................................................................................................26 Service Level Agreement ...............................................................................................26 Rapportage .....................................................................................................................26 Overlegstructuur .............................................................................................................26 Operationeel ...................................................................................................................26 Change management Board (CMB) meeting .................................................................26 Management meeting .....................................................................................................27 Evaluatie meeting ...........................................................................................................27

4


1 Algemeen Dit document beschrijft de Service Level Agreement (SLA) zoals deze tussen (hierna <SLA-Nemer>) en <SLA-Klant>(hierna ) 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 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 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.2

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 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 . Behoudens schriftelijke toestemming van 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 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 maanden. Indien de overeenkomst niet wordt opgezegd, wordt deze stilzwijgend verlengd met telkens een periode van maanden. Gedurende de verlengde periode geldt eveneens een opzegtermijn van 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

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


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

<SLANemer>

Omschrijving

e

Aannemen en registreren

V

U

vult 1 lijns ondersteuning in. <SLA-Nemer> registreert alle incidenten in het <SLANemer> servicedesk tool die: - telefonisch of per e-mail gemeld worden bij de <SLA-Nemer> Servicedesk door de helpdesk van . - 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.

VU

<SLA-Nemer> bepaalt of het incident in 2 of 3 lijn opgelost moet worden, dan wel tot probleem moet worden verheven.

e

Analyse en diagnose

U

e

heeft een actieve rol bij het analyseren en diagnosticeren van incidenten. De eindverantwoording blijft bij <SLA-Nemer>. Dispatchen

Oplossen en herstellen

U

VU

<SLA-Nemer> zet indien nodig incidenten door naar externe oplossingsinstanties.

VU

Storing wordt verholpen in overleg met de melder. heeft een actieve rol bij het oplossen van incidenten. De eindverantwoording blijft bij <SLANemer>.

Incident afsluiten

V

U

Het incident wordt gesloten en zowel de melder als de helpdesk van 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 zelf heeft afgesloten met een leverancier. Dit betreft dus niet de leveranciers waar <SLA-Nemer> werkzaamheden naar heeft uitbesteed. <SLANemer> 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 met leveranciers afsluit blijft 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

3

3

3

- 1 medewerker (Indien hij/zij de enige gebruiker is zie “Enkele medewerkers”) - 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 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 prioriteit Incidenten met een hoge prioriteit dienen tenminste telefonisch te worden gemeld indien ervan verzekerd wil zijn dat de melding op het service level van prioriteit 1 wordt afgehandeld. 2.4.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 bepaalt dat de oplossing niet tot de volgende werkdag kan wachten. 10


2.5

VIP regeling

Een beperkte groep gebruikers, maximaal , 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


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.

Geen

Voorbeeld: reset password of unlock userid. 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.

Geen

Voorbeeld: aanmaken user 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 op een additionele offerte en goedkeuring op een PID indien nodig. Het opstellen van een PID geschiedt na instemming van door <SLANemer>, valt buiten de scope van deze SLA en zal additioneel worden gefactureerd. Als richtlijn voor autorisatie geldt dat een wijziging die meer dan uur inspanning vergt altijd geautoriseerd dient te worden door de 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 hierover overleggen.

3.2.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. 3.2.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 en <SLA-Nemer> worden afgesproken.

3.3

Activiteiten

Activiteiten

<SLANemer >

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

VU

Change wordt uitgevoerd en getest binnen de SLA tijd.

VU

De change wordt geëvalueerd tegen het beoogde resultaat, gereed gemeld bij aanvrager en de helpdesk van en na goedkeuring afgesloten in het <SLA-Nemer> servicedesk tool.

Uitvoering

afsluiting en evaluatie

V


13


3.4

Service levels

KPI

Omschrijving

Uitvoeren minor change

80% binnen 8 werkuren 100% binnen 24 werkuren

Uitvoeren urgente minor change


Uitvoeren standard change


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 ). Inclusief oplevertijd offerte (actie <SLA-Nemer> na input van ) Deze paragraaf wordt opgenomen in bijlage I (DAP).

14


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

Activiteiten

Identificatie en registratie

<SLANemer > VU

Omschrijving

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

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.

Afsluiting

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


15


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 .

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 <SLANemer> besteedde uren aan problem management.

16


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

Activiteiten

Planning

Identificatie

V

<SLANemer > U

VU

Omschrijving

In overleg tussen 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. Ter identificatie worden alle CI’s voorzien van stickers met een CI-nummer. 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. zal periodiek audits (laten) uitvoeren om de correctheid van de CMDB te toetsen.


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

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


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

Event afhandeling

<SLANemer> VU

Description

<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 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>. 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 security policy.


18


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.

Activiteiten

<SLANemer >

Omschrijving

Bepalen van beschikbaarheidbehoeften

VU

bepaalt de beschikbaarheidsbehoeften voor de verschillende ICT componenten.

Ontwerpen van beschikbaarheid

VU

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 security policy.

Managen van onderhoudsactiviteiten

V

VU

Indien onderhoud noodzakelijk is zullen <SLANemer> en dit in overleg plannen.

VU

Indien garanties over beschikbaarheid zijn afgegeven zal <SLA-Nemer> hierover rapporteren.

Meten en rapporteren

Opstellen beschikbaarheidplan

VU

V = Verantwoordelijk U = Uitvoerend 6.3.1 Service levels KPI

Description

Beschikbaarheid van de door <SLA-Nemer> beheerde infrastructuur

99,9% op jaarbasis

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 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 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 herconfigureren van apparatuur en tijdens normaal gepland onderhoud.



Tijdens wachttijd als gevolg van het niet kunnen uitvoeren van een interventie in opdracht van 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


6.4



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 ) van door <SLA-Nemer> geadviseerde kritische firmware en/of software updates en patches.

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.

Activiteiten

Business capacity management

Omschrijving

Opstellen capaciteitsplan

VU

Meten en rapporteren Service en resource capacity management

<SLANemer>

VU

Periodiek rapporteren over capacity <SLA-Nemer> monitoort de beschikbaarheid van de gewenste capaciteit en adviseert pro-actief.

VU

Indien grenswaarden worden overschreden wordt hiervan een incident gemaakt.


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.

Activiteiten

<SLANemer>

Omschrijving

Release beleid en planning

VU

Bepalen op welke wijze releases worden samengesteld en gedistribueerd

Ontwerpen, bouwen en samenstellen

VU

Het release ontwerpen, bouwen en samenstellen

21


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.


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.

Activiteiten

Bepalen van de scope

VU

Business-impactanalyse

VU

Risicoanalyse

VU

Business continuity strategie

VU

Planning van organisatie en implementatie

VU

Voorzorgsmaatregelen en herstelopties Ontwikkel plannen en procedures voor herstel

VU

Initieel testen

VU

Opleiding, training en bekendheid

VU

Review en audit

VU

<SLANemer >

Omschrijving

VU

Zorgen voor een correcte back-up

U

<SLA-Nemer> participeert in het door opgestelde continuity plan.

22


Testing

VU

Change management

VU

Controle

VU

U

<SLA-Nemer> voert in opdracht van en in samenwerking met continuity tests uit.

V = Verantwoordelijk U = Uitvoerend 6.6.1 Service levels KPI

Description

Uitwijktesten

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

6.6.2 Continuity plan

De exacte werkzaamheden en verplichtingen van <SLA-Nemer> ten aanzien van continuity management, worden beschreven in het door 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 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.

Activiteiten

Sturing en beleid

VU

Planning

VU

Implementatie

<SLANemer>

Omschrijving

stelt de security policy op met beveiligingsregels U

formaliseert de security policy in contracten

VU

<SLA-Nemer> conformeert zich aan de

23


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 securityincidenten en –problemen. <SLA-Nemer> registreert de uitgevoerde handelingen in de worklog van het incident in het <SLA-Nemer> servicedesktool. Zie ook hoofdstuk "Incident management". <SLA-Nemer> is ISO9001:2000 gecertificeerd (KEMA nr. 45790). In het kwaliteitssysteem is de informatiebeveiliging opgenomen.

Personeel en informatiebeveiliging

Audit en evaluatie

VU

voert audits uit op de dienstverlening van <SLA-Nemer> ten aanzien van security.

Onderhouden

VU

past de security policy aan bij veranderingen in de ICT infrastructuur.


6.7.1 Service levels KPI

Description

Melding security incident

Security incidenten met een hoge severity worden binnen 1 uur na detectie gemeld aan de incident manager.

Rapporteren security incidenten

Tijdens het maandelijkse management overleg.

24


7

Service level management

7.1

Doel

Deze Service Level Agreement (SLA) is het eindproduct van een proces waarin de eisen en wensen van 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

Activiteiten

<SLANemer>

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


25


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 op een prijsopgave van <SLA-Nemer>.

7.5

Overlegstructuur

7.5.1 Operationeel

Wekelijks wordt een operationeel overleg gehouden waarin de volgende personen participeren. :

Proceseigenaren

<SLA-Nemer>:

Servicedesk engineer

7.5.2 Change management Board (CMB) meeting

Wekelijks wordt CMB overleg gehouden waarbij de volgende personen aanwezig zijn: :

Change manager

<SLA-Nemer>:

Servicedesk engineer / service manager. 26


7.5.3 Management meeting

Maandelijks wordt de management meeting gehouden waarbij de volgende personen aanwezig zijn: :

Service manager

<SLA-Nemer>:

Service manager

7.5.4 Evaluatie meeting

Eenmaal per jaar wordt een evaluatie meeting gehouden waarbij de volgende personen aanwezig zijn: :

Manager ICT

<SLA-Nemer>:

Delivery manager

27

Winkelsystemen. Voorbeeld Service Level Agreement Winkelsystemen. Voorbeeld Service Level Agreement. Servicelevelnummer : < NAAM KLANT>

Recommend Documents