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 : <NAAM KLANT> Behandeld door :
Contactpersonen Naam Functie Telefoon Emailadres
Ondertekening Voor akkoord <Opdrachtnemer>. Naam: Functie: Datum: Handtekening: Voor akkoord <Opdrachtgever> Naam: Functie: Datum: Handtekening:
Document Control Doel: Vastlegging van service levels betreffende de dienstverlening voor <KLANT> Bereik: Referentie naar: Auteur: Overeenkomst <Behandeld door> Versiebeheer Revisie: reden: Door: Datum:
Inhoud 1 Algemeen... 5 1.1 Documentstructuur... 5 1.2 Scope van de dienstverlening... 7 1.3 Geheimhouding... 7 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.4 Service levels... 14 3.5 Change procedure... 14 3.6 Offerte procedure... 14 4 Problem management... 15 4.1 Doel... 15 4.2 Activiteiten... 15 4.3 Service levels... 16 5 Configuration management... 17 5.1 Doel... 17 5.2 Activiteiten... 17 5.3 Service levels... 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.3.1 Service levels... 19 6.4 Capacity management... 21 6.5 Release management... 21 6.6 Continuity management... 22 6.6.1 Service levels... 23 6.6.2 Continuity plan... 23 6.6.3 Randvoorwaarden... 23 3
6.7 Security management... 23 6.7.1 Service levels... 24 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
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 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 <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. 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> 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 <KLANT> <SLA- Nemer> Aannemen en registreren V U <KLANT> vult 1 e lijns ondersteuning in. Classificeren initiële ondersteuning <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. Incidenten worden voorzien van classificatie en prioriteit. <SLA-Nemer> voorziet de melder van een ticketnummer; per e-mail binnen 1 uur, telefonisch direct Matchen <SLA-Nemer> controleert of het een Known Error betreft en of een Work-around van toepassing is. Analyse en diagnose U <SLA-Nemer> bepaalt of het incident in 2 e of 3 e 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 <SLA-Nemer> zet indien nodig incidenten door naar externe oplossingsinstanties. Oplossen en herstellen U 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. 2.2.1 Prioriteitsbepaling Elk incident wordt volgens onderstaande tabel op prioriteit geclassificeerd: Impact Urgentie 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 - Enkele Medewerkers of enkele pc s - 50% Afdeling medewerkers of pc s - Enige gebruiker van een systeem - Bijzondere situatie zoals verloning. 1 1 3 1 2 3-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. 2.3 Service levels KPI Telefonische bereikbaarheid servicedesk Telefonische responsetijd Oplossen hoge prioriteit (1) incidenten Oplossen midden prioriteit (2) incidenten Oplossen lage prioriteit (3) incidenten Start met oplossen van prioriteit 1 incidenten 100% gedurende het standaard service window (zie bijlage H) 80% binnen 60 seconden 100% binnen 120 seconden 80% binnen 4 werkuren 100% binnen 8 werkuren 80% binnen 12 werkuren 100% binnen 24 werkuren 80% binnen 24 werkuren 100% binnen 48 werkuren 80% binnen 1 werkuur 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. 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 <KLANT> 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 <KLANT> bepaalt dat de oplossing niet tot de volgende werkdag kan wachten. 10
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 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 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. 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. 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 <KLANT> en <SLA-Nemer> worden afgesproken. 3.3 Activiteiten Activiteiten <KLANT> <SLA- Nemer > registratie en classificatie V 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 Minor en standard changes worden ingepland. Uitvoering Change wordt uitgevoerd en getest binnen de SLA tijd. afsluiting en evaluatie V 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 13
3.4 Service levels KPI Uitvoeren minor change Uitvoeren urgente minor change Uitvoeren standard change Uitvoeren urgente standard change Uitvoeren medium change 80% binnen 8 werkuren 100% binnen 24 werkuren 80% binnen 4 werkuren 100% binnen 8 werkuren 90% binnen 48 werkuren 100% binnen 60 werkuren 90% binnen 24 werkuren 100% binnen 48 werkuren 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). 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 <KLANT> <SLA- Nemer > Identificatie en registratie 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. Onderzoek en diagnose. Oplossing en Afsluiting 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. 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. 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. V = Verantwoordelijk U = Uitvoerend 15
4.3 Service levels Service level Work-arounds Wijzigingsvoorstellen 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>. 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. 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 <KLANT> <SLA- 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 Ter identificatie worden alle CI s voorzien van stickers met een CI-nummer. <KLANT> zal deze stickers verstekken. Beheer V <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. V = Verantwoordelijk U = Uitvoerend 5.3 Service levels KPI Registratiesnelheid Correctheid CMDB Verificatie <SLA-Nemer> registreert mutaties op de CMDB binnen (X) werkdagen na geautoriseerde wijziging in 90% van alle gevallen. <SLA-Nemer> garandeert een correctheid van 90% op elk gewenst meetmoment. 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
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 <SLA-Nemer> controleert de event logs en behandelt voorkomende events. <SLA-Nemer> registreert in voorkomende gevallen een incident. Backup en restore <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 Patch management V Security policy V U <SLA-Nemer> monitoort dagelijks de servers genoemd in Appendix E. <SLA-Nemer> beheert en installeert de benodigde OS patches volgens een nader af te spreken procedure. <SLA-Nemer> conformeert zich aan de <KLANT> security policy. V = Verantwoordelijk U = Uitvoerend 18
6.2.1 Service levels KPI Description Installeren Server OS patches Installeren Server emergency patches Controleren back-up Eens per (X) maanden Binnen (X) werkdagen 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 <KLANT> <SLA- Nemer > Bepalen van beschikbaarheidbehoeften Ontwerpen van beschikbaarheid <KLANT> bepaalt de beschikbaarheidsbehoeften voor de verschillende ICT componenten. <KLANT> is verantwoordelijk voor het (laten) ontwerpen van de ICT infrastructuur die voldoet aan de gewenste beschikbaarheid. Aandachtspunten voor beveiliging V <SLA-Nemer> conformeert zich aan de <KLANT> security policy. Managen van onderhoudsactiviteiten V Indien onderhoud noodzakelijk is zullen <SLA- Nemer> en <KLANT> dit in overleg plannen. Meten en rapporteren Indien garanties over beschikbaarheid zijn afgegeven zal <SLA-Nemer> hierover rapporteren. Opstellen beschikbaarheidplan V = Verantwoordelijk U = Uitvoerend 6.3.1 Service levels KPI Description Beschikbaarheid van de door <SLA-Nemer> beheerde infrastructuur Rapportage beschikbaarheid van de afgelopen 99,9% op jaarbasis 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 <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 herconfigureren 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. 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. Activiteiten <KLANT> <SLA- Nemer> Business capacity management Opstellen capaciteitsplan Meten en rapporteren Periodiek rapporteren over capacity Service en resource capacity management <SLA-Nemer> monitoort de beschikbaarheid van de gewenste capaciteit en adviseert <KLANT> pro-actief. Indien grenswaarden worden overschreden wordt hiervan een incident gemaakt. V = Verantwoordelijk 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. Activiteiten <KLANT> <SLA- Nemer> Release beleid en planning Ontwerpen, bouwen en samenstellen Bepalen op welke wijze releases worden samengesteld en gedistribueerd Het release ontwerpen, bouwen en samenstellen 21
Testen en acceptatie Audit en evaluatie Roll-out planning Communicatie en training Rapporteren Functioneel testen en accepteren van het release Toetsen en evalueren van de toegepaste beveiligingsregels De wijze van uitrol bepalen. Informeren en trainen van belanghebbenden. Periodiek rapporteren over releases Installatie en distributie Uitol van het release. Binnen Configuration management wijzigingen aan de CMDB doorvoeren. V = Verantwoordelijk 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. Activiteiten <KLANT> <SLA- Nemer > Bepalen van de scope Business-impactanalyse Risicoanalyse Business continuity strategie Planning van organisatie en implementatie Voorzorgsmaatregelen en herstelopties Zorgen voor een correcte back-up Ontwikkel plannen en procedures voor herstel Initieel testen U <SLA-Nemer> participeert in het door <KLANT> opgestelde continuity plan. Opleiding, training en bekendheid Review en audit 22
Testing U <SLA-Nemer> voert in opdracht van en in samenwerking met <KLANT> continuity tests uit. Change management Controle 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 <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. Activiteiten <KLANT> <SLA- Nemer> Sturing en beleid <KLANT> stelt de security policy op met beveiligingsregels Planning U <KLANT> formaliseert de security policy in contracten Implementatie <SLA-Nemer> conformeert zich aan de <KLANT> 23
security policy met betrekking tot de in deze SLA beschreven beheerdiensten. Afhandelen security incidenten <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". Personeel en informatiebeveiliging <SLA-Nemer> is ISO9001:2000 gecertificeerd (KEMA nr. 45790). In het kwaliteitssysteem is de informatiebeveiliging opgenomen. Audit en evaluatie Onderhouden <KLANT> voert audits uit op de dienstverlening van <SLA-Nemer> ten aanzien van security. <KLANT> past de security policy aan bij veranderingen in de ICT infrastructuur. V = Verantwoordelijk U = Uitvoerend 6.7.1 Service levels KPI Description Melding security incident Rapporteren security incidenten Security incidenten met een hoge severity worden binnen 1 uur na detectie gemeld aan de <KLANT> incident manager. Tijdens het maandelijkse management overleg. 24