Service Level Agreement (SLA) Concept

Dit document dient om meer inzicht te krijgen in de aangeboden dienstverlening van Amyyon en de afspraken hierover duidelijk vast te leggen. Daarbij gaat het om de diensten support en onderhoud en hosting.

In dit document gaan we in op deze onderdelen:

− Incident management

(wat kunt u van Amyyon verwachten als u onze servicedesk benadert met een vraag of probleem)

− Change management

(hoe gaat Amyyon om met wijzigingen en met verzoeken om wijzigingen aan te brengen)

− Releasemanagement

(hoe gaat Amyyon te werk bij het uitbrengen van een nieuwe release)

In deze SLA worden de kwalitatieve en kwantitatieve afspraken voor het te realiseren

dienstenniveau van het onderhoud en support ten behoeve van Xxxxxx XXX Web beschreven.

Waar mogelijk benoemen we indicatoren (de servicelevels) die voor <opdrachtgever> van belang zijn met het oog op (de kwaliteit van) haar informatievoorziening. Per indicator is de bijbehorende norm opgenomen. Deze normen zijn de meetbare criteria waaraan Amyyon inzake support en onderhoud dient te voldoen.

1.2 Gerelateerde documenten

Deze SLA is een onderdeel van de opdrachtverstrekking d.d. <datum> door de <opdrachtgever> aan Amyyon, met nummer XXXX.

Verder is de SLA gerelateerd aan:

- Offerte Xxxxxx XXX Web voor <opdrachtgever>, datum XX, kenmerk XX;

− de Nederland ICT voorwaarden.

Contractinformatie zoals bijvoorbeeld looptijd en tarieven is dan ook te vinden in deze documenten en is niet opgenomen in deze SLA.

1.3 Goedkeuring en beheer SLA

De goedkeuring van de SLA is de gezamenlijke verantwoordelijkheid van <opdrachtgever> en Amyyon.

Wijzigingen op de SLA worden tussen de beslissingsbevoegde vertegenwoordigers van de opdrachtgever en de opdrachtnemer afgestemd. In bijlage 1 zijn de namen van deze personen opgenomen.

Indien <opdrachtgever> en Amyyon akkoord zijn met de wijzigingen, wordt de goedkeuring vastgelegd middels het plaatsen van de handtekeningen van de vertegenwoordigers van beide partijen op de gewijzigde SLA. Amyyon is verantwoordelijk voor het (versie)beheer van deze SLA.

2 Commitment en randvoorwaarden

2.1 Commitment

Amyyon zorgt ervoor dat:

− kennis en kunde gewaarborgd worden in de organisatie;

− er een actief productbeleid wordt gevoerd;

− maximale inzet van mensen en middelen wordt geboden;

− optimale kwaliteit wordt geboden.

2.2 Randvoorwaarden

Deze randvoorwaarden zijn van toepassing:

− Incidenten met betrekking tot fouten in de software dienen zo volledig mogelijk door de Functioneel beheerder aangemeld te worden:

- waarop heeft de melding betrekking?

- welke omgeving (acceptatie / productie)?

- wat is er precies gedaan?

- wat werd verwacht aan resultaat?

- wat was het werkelijke resultaat?

- bij voorkeur met een schermafdruk;

− incidenten dienen in beginsel reproduceerbaar te zijn;

− indien door Amyyon om een nadere toelichting wordt gevraagd, zal dit zo snel mogelijk worden gegeven;

− wijzigingen in de sourcecode worden slechts door Amyyon uitgevoerd;

− incidenten dienen terug te voeren zijn op de software van Amyyon. Indien het incident samenhangt met het beheer van de hardware of software van derden vervalt de norm van de desbetreffende servicelevel.

− Amyyon heeft toegang tot die componenten van de IT infrastructuur welke benodigd zijn voor een juiste diagnose;

− de Functioneel beheerder van <opdrachtgever> is voldoende opgeleid om zijn/haar taken te kunnen uitvoeren.

3 Dienstverlening

In dit hoofdstuk wordt nader ingegaan op de scope van dienstverlening.

3.1 Binnen scope van de dienstverlening

De SLA heeft betrekking op het support en onderhoud voor zowel de productie als de acceptatie omgeving van Amyyon CRM Web.

Xxxxxx XXX Web wordt hierbij als gehoste oplossing afgenomen.

De gedefinieerde servicelevels en normen gelden echter alleen voor de productie omgeving.

3.2 Buiten scope van de dienstverlening

De volgende activiteiten vallen buiten de scope van de dienstverlening:

− Technische infrastructuur

Het beheer van de technische infrastructuur (o.a. hardware, netwerken, systeemsoftware en software van derden).

Waar de software wordt afgenomen op basis van SaaS of Hosting dan valt het beheer van de hardware en infrastructuur componenten die daarvoor nodig zijn, wel binnen de grenzen van de SLA.

− Functioneel Beheer

Het functioneel (applicatie-)beheer wordt door de Functioneel beheerder(s) van de opdrachtgever uitgevoerd. Hieronder wordt onder meer verstaan:

− het uitvoeren van eerstelijns ondersteuning binnen de organisatie;

− het maken, beheren en aanpassen van documentatie (naast de gebruikershandleiding) die klant specifiek zijn zoals werkinstructies en procesbeschrijvingen;

− het (laten) uitvoeren van de functionele acceptatietest;

− het onderhouden van de inrichting en/of stambestanden.

4 Services en Servicelevels

In dit hoofdstuk worden de kwalitatieve en kwantitatieve servicelevels vastgelegd voor de

behandeling van een incident. Een incident kan de melding zijn van een probleem of storing, maar kan ook een vraag betreffen.

Op basis van deze servicelevels vindt monitoring plaats van het geleverde dienstenniveau in relatie met het afgesproken niveau.

4.1 Incidentmanagement

De incidenten of vragen die niet door de Functioneel beheerder van <opdrachtgever>

beantwoord kunnen worden en die betrekking hebben op het functioneren van Xxxxxx XXX web, worden door de Functioneel beheerder doorgegeven aan de servicedesk van Amyyon.

Indien meldingen onterecht zijn doorverwezen naar de servicedesk van Amyyon vindt zo snel mogelijk hiervan terugkoppeling plaats.

Prioriteitstelling

Aangemelde incidenten of vragen kunnen worden opgelost door de servicedesk (in overleg met de aanmelder) geprioriteerd en gecategoriseerd. Aan incidenten en vragen kan prioriteit 1, 2, 3, 4 of 5 worden toegekend.

Prioriteit	Prioriteitscode	Omschrijving
Urgent	1	Die incidenten waarbij de software in het geheel niet meer functioneert of waardoor de functionaliteit zodanig is afgenomen dat dit als zodanig wordt ervaren. Workaround is niet mogelijk
Hoog	2	Die incidenten waarbij de software gedeeltelijk niet meer functioneert maar waarbij het bij de overgebleven functionaliteit toch redelijk mogelijk blijft om te kunnen functioneren. Workaround is mogelijk.
Normaal	3	Problemen die opgelost dienen te worden. De software werkt, echter deze problemen hebben tot gevolg dat gebruikers minder efficiënt kunnen werken.
Laag	4	Alle incidenten die niet onder de prioriteitscode 1 t/m 3 vallen.
RFC	5	Request for Change. Een RfC is een verzoek om wijziging in de functionaliteit van de software.

4.1.1 Servicelevels

In het volgende schema zijn de diensten en de bijbehorende servicelevels opgenomen voor het incidentmanagement.

Meldingen ten aanzien van de acceptatieomgeving vallen hier buiten. Deze meldingen worden wel aangenomen, opgevolgd en uitgevoerd, maar vallen buiten deze normen.

Processen/ Diensten

Indicator

Omschrijving

Servicelevel per prioriteit

(Streeftijden) 1

Niveau 2

Intake

Incidenten

Bereikbaar- heid /

Reactietijd

Het doen van een terugkoppeling op basis van een door de Functioneel beheerder aangemeld incident met daarbij:

- een (eerste) controle op compleetheid van het aangemelde incident

- een (eerste) controle op juistheid en doorverwijzing.

P1: 1 uur

P2: 1 uur

P3: 8 uur

P4: 16 uur

90%

Terugkoppeling Incidenten

Responsetijd

Het doen van een opgave op basis van een aangemeld

incident door de Functioneel beheerder

met daarbij:

- een korte impactanalyse met daaraan gekoppeld een voorgestelde oplossingsrichting en een urenschatting voor de te nemen acties.

P1: 2 uur

P2: 4 uur

P3: 8 uur

P4: 16 uur

90%

Oplossing Incidenten

Streeftijd Oplossing

Aandragen oplossing

incident en de terugkoppeling

ervan aan de Functioneel beheerder.

P1: 4 uur

P2: 8 uur

P3: 40 uur

P4: 80 uur

90%

1 - Tijd die ligt tussen de aanmelding van een incident of vraag en de desbetreffende servicelevels. 2 - Percentage waarin voldaan moet worden aan de servicelevels.

Bij de genoemde servicelevels gaat het om uren tijdens kantoortijd. De servicelevels zijn exclusief de tijd die benodigd is voor een eventuele uitlevering van een patch, testen van de aanpassing en het accepteren daarvan door de opdrachtgever.

Prioriteit 1 incidenten:

Bij prioriteit 1 incidenten zal Amyyon zich maximaal inspannen om het incident zo snel

mogelijk op te lossen. Mocht het probleem niet binnen de gestelde termijn kunnen worden opgelost, dan zal Amyyon aangegeven aan de Functioneel beheerder wat de vervolgstappen zijn.

Prioriteit 1 meldingen worden altijd door Amyyon geëvalueerd om te onderzoeken wat er kan worden gedaan om herhaling in de toekomst te voorkomen.

4.2 Change Management

Het kan nodig zijn de software aan te passen om het probleem op te lossen. Hierbij maken we onderscheid tussen:

− spoedeisend correctief onderhoud (spoed patch);

− projectmatig onderhoud (adaptief, perfectief).

4.2.1 Spoedeisend correctief onderhoud (spoed patch)

Als voor het oplossen van een Incident van prioriteit 1 een wijziging in de programmatuur

noodzakelijk is, dan zal deze, in de vorm van een patch op de bestaande productie omgeving worden aangeboden.

Over het moment van installeren van deze patch en de wijze waarop zal overleg met de Functioneel beheerder plaatsvinden.

Deze aanpassing zal ook in de eerstvolgende reguliere release worden meegenomen.

4.2.2 Projectmatig Onderhoud

Volgt uit de beoordeling van een incident dat een programma aanpassing noodzakelijk is, maar het gaat niet om een spoedeisende aanpassing, dan wordt een wijzigingsverzoek opgesteld. Deze wordt als Request for Change geregistreerd en behandeld. Zie hiervoor het volgend hoofdstuk.

4.3 Servicetijden

De beschikbaarheid van de dienstverlening is op te delen in een aantal gebieden.

4.3.1 Reguliere servicetijden

De servicedesk is bereikbaar van 8.30 tot 17.00 uur tijdens werkdagen. Er wordt

gebruikersondersteuning geleverd en de beschreven prestatie-indicatoren (servicelevels) zijn van toepassing.

Op deze feestdagen is de servicedesk niet bereikbaar:

Feestdagen
Nieuwjaarsdag	Hemelvaartsdag
Pasen	Pinksteren
Koningsdag	Kerst
5 mei (eens in de 5 jaar)

4.3.2 Ondersteuning buiten de reguliere servicetijden

Er kan buiten de reguliere servicetijden ondersteuning worden geleverd indien hierover afspraken zijn gemaakt.

Deze ondersteuning kan incidenteel zijn. Werkzaamheden buiten normale werktijden vinden dan plaats na overleg tussen de opdrachtmanagers van <opdrachtgever> en Amyyon. Hierbij wordt ook een afspraak gemaakt over de kosten. Na opdrachtverstrekking door <opdrachtgever> zullen de

werkzaamheden worden uitgevoerd.

Deze ondersteuning kan structureel zijn. In dat geval worden de afspraken die hierover worden gemaakt toegevoegd in dit document.

5 Request for Change (RfC)

5.1 Inleiding

Een Request for Change (verder te noemen RfC) is een verzoek om de functionaliteit zoals die in de applicatie aanwezig is te wijzigen. Het gaat hierbij niet om foutherstel, maar om een gewenste andere functionaliteit.

Een RfC kan van allerlei kanten en om uiteenlopende redenen op de servicedesk binnenkomen, zoals bijvoorbeeld:

- als wens door <opdrachtgever> ingebracht;

- als verbetersuggestie door een interne medewerker;

- als verbetersuggestie van de servicedesk;

- als resultaat van de werkzaamheden in het kader van Problem Management.

De afhandeling van een RfC kent een aantal stappen. Het is daarbij mogelijk dat een RFC al deze stappen doorloopt, maar dat geldt niet voor alle RfC’s. We kennen deze stappen:

- registratie;

- validatie;

- communicatie;

- impact analyse.

5.1.1 Registratie

Elke RfC die bij de servicedesk binnenkomt wordt vastgelegd in het call-systeem van Amyyon. Daarbij wordt ook de bron vastgelegd.

5.1.2 Validatie

Periodiek (eens per maand) worden aangemelde RfC’s gevalideerd. Dat wil in deze context zeggen dat de RfC voldoet aan bepaalde criteria, zoals:

- past het in de opzet en architectuur van de standaard applicatie;

- is het technisch realiseerbaar;

- leidt het tot een verbetering in de functionaliteit van de standaard applicatie;

- is het generiek van karakter: is het voor elke gebruiker (of een belangrijk deel ervan) van belang.

Voldoet de RfC aan deze criteria dan kan het verder in behandeling genomen worden. Bij elke gevalideerde RfC wordt ook een prioriteit bepaald.

5.1.3 Communicatie

Voor iedere RfC zal de indiener bericht krijgen of de RfC wel of niet gevalideerd is.

Indien de RfC niet gevalideerd is, kan de indiener zelf bepalen wat er gebeuren moet. Bijvoorbeeld: het kan zijn dat een RfC wordt afgewezen omdat het door Amyyon niet als generiek van karakter

wordt beschouwd, terwijl het voor de indiener van strategisch belang is. De indiener weet nu dat zijn RfC niet zal worden gehonoreerd en de gewenste aanpassing zal geen onderdeel worden van de standaard applicatie.

5.1.4 Impactanalyse

Amyyon zal op de gevalideerde RfC’s een globale impactanalyse uitvoeren. Hierbij wordt onder andere gekeken naar de gevolgen voor andere applicatie onderdelen en een globale begroting gemaakt.

6 Release Management

6.1 Inleiding

Periodiek wordt door Amyyon van haar applicaties een nieuwe release uitgebracht. Daarin wordt nieuwe functionaliteit opgeleverd. Het proces om te bepalen wat de inhoud wordt van een nieuwe release noemen we Release Management.

Release Management kent een aantal stappen. Hierbij horen onder meer:

- bepalen concept release inhoud;

- software ontwikkeling;

- vaststellen definitieve release inhoud

- interne procedures / vrijgave;

- communicatie.

6.1.1 Concept release inhoud

Amyyon onderzoekt wat de mogelijke inhoud kan worden van een komende release. Hierbij wordt gekeken naar de gevalideerde RfC’s. Daarnaast kan de inhoud door andere factoren worden bepaald, zoals bijvoorbeeld:

- technologische ontwikkelingen;

- gedane toezeggingen in het kader van een project;

- strategische ontwikkeling;

- aanpassingen in het kader van wet- en regelgeving.

Op basis van deze input kan voor een komende release een voorlopige afbakening van de inhoud worden gemaakt. Het gaat nog om een concept: in deze fase kan het, bijvoorbeeld al wel duidelijk zijn dat er aanpassingen nodig zijn in het kader van een wetswijziging, maar is nog niet duidelijk op welke manier dat moet plaatsvinden en evenmin is er een begroting.

6.1.2 Software ontwikkeling

De aanpassingen en uitbreidingen van de software worden verder uitgewerkt, ontwikkeld en getest.

6.1.3 Definitieve release inhoud

Eén maand voor de releasedatum wordt de inhoud definitief vastgesteld. Op grond van nadere

inzichten tijdens de ontwikkeling kunnen onderdelen worden toegevoegd of komen te vervallen. Een onderdeel wordt slechts meegenomen in de definitieve release als in redelijkheid te verwachten is dat de functionaliteit volledig beschikbaar en grondig getest is op de releasedatum.

6.1.4 Interne procedures

Om de release gereed te maken voor de uitlevering worden er door Amyyon procedures doorlopen waarbij nog activiteiten worden uitgevoerd. Voorbeelden hiervan zijn:

- uitvoeren release test;

- bijwerken technische documentatie;

- bijwerken handleidingen van de standaard applicatie;

- release documentatie opstellen;

- een uitlever-set maken.

Als de procedures zijn doorlopen en als voldoende beoordeeld, dan volgt een formele vrijgave van de release.

6.1.5 Communicatie

Bij een nieuwe release wordt een release document opgeleverd. Hierin staan alle wijzigingen in de nieuwe release beschreven.

De beschrijving van de inhoud van de nieuwe release is circa 3 weken voor de releasedatum beschikbaar en op te vragen via de servicedesk of te lezen op onze ondersteuningssite.

6.2 Maatwerk

De indiener van een RfC kan besluiten om het als maatwerk te laten ontwikkelen. In de praktijk zijn hiervoor twee belangrijke redenen:

- Organisatie specifiek: bij de validatie is de RfC beoordeeld als ‘niet generiek’ maar voor de indienende organisatie is het van groot belang. Door de terugmelding weet de indiener dat de RfC niet in de standaardfunctionaliteit zal worden opgenomen.

- Planning: de indiener wil niet wachten op het verloop van het traject, maar invloed hebben op het moment van oplevering. Door het als maatwerk te laten ontwikkelen kan de indiener met Amyyon afspraken maken over het moment van oplevering

7 Hosting

Indien Xxxxxx XXX Web op basis van hosting is afgenomen geldt:

- een beschikbaarheid (uptime) van 99,5%.

- het monitoren van het platform op basis van 24/7.

De werkzaamheden die hiervoor nodig zijn omvatten:

− Infrastructuur

Het ter beschikking stellen van de benodigde technische infrastructuur zoals hardware, monitoringsoftware en systeemsoftware (op basis van shared cloud) en het beheer daarvan.

− Databasebeheer

Het beheren van de database, het dagelijks maken van een back-up (retentie 14 dagen), controles op de aanwezigheid van juiste back-up’s.

− Technisch Beheer

Het zorg dragen van de juiste versie van geautoriseerde programmatuur dat beschikbaar wordt gesteld voor de eindgebruikers. Het installeren van nieuwe versies en/of patches in de acceptatie- en productieomgeving.

8 Communicatie in geval van escalatie

Onderdeel van de SLA is een escalatiemodel. Hiermee wordt geregeld hoe de organisaties overleg zullen voeren als er zich bij de uitvoering van de SLA zich problemen voordoen.

Dat kan zich voordoen als een van beide organisaties van mening is dat de afspraken niet (correct) worden uitgevoerd of dat er klachten zijn over de manier waarop dat gebeurd.

Voorbeelden kunnen zijn:

- de Functioneel beheerder vindt dat de prioriteitstelling verkeerd bepaald wordt, maar hij/zij komt met de servicedesk niet tot overeenstemming;

- Amyyon voldoet niet aan de afgesproken normen;

- de servicedesk vraagt om nadere informatie, maar die wordt niet geleverd;

- de servicedesk wordt benaderd om uitleg te geven over (nog) niet geïmplementeerde onderdelen van de software.

In het model maken we onderscheid tussen contacten op diverse niveaus:

- operationeel;

- management;

- opdrachtgever/directie.

Een eindgebruiker die een probleem of een vraag heeft neemt contact op met de interne helpdesk (indien aanwezig) van <opdrachtgever> of met de Functioneel beheerder. Deze lost het op of neemt contact op met de servicedesk van Amyyon.

Indien de afhandeling niet correct verloopt, kan het naar een ander niveau getild worden. Er wordt dan op managementniveau contact gezocht tussen de manager aan de zijde van opdrachtgever en de manager van de servicedesk van Amyyon om een passende oplossing te vinden.

Komen zij er in onderling overleg niet uit dan wordt het neergelegd op het hoogste niveau: de formele opdrachtgever neemt contact op met de directie van Amyyon, of andersom.

De namen van de personen die bij dit schema horen zijn opgenomen in bijlage 1.

9 Financiële aspecten

9.1 Tarieven onderhoud en support

Dit SLA is een uitwerking van een afgesloten onderhoudsovereenkomst. Daarin zijn de geldende tarieven vastgelegd.

9.2 Toeslagen op tarieven buiten reguliere werktijden

Voor incidentele werkzaamheden die op verzoek van de opdrachtgever worden uitgevoerd buiten de reguliere werktijden van de servicedesk (vermeerderd met een half uur) geldt het standaard

consultancytarief met de volgende opslagpercentages:

van 8.30 tot 17.30

voor 8.30 of na 17.30

werkdagen zaterdag

zon- en feestdagen

50%

100%

50%

100%

Hieronder valt bijvoorbeeld het uitvoeren van een installatie van een nieuwe versie in de avond of in het weekend.

Is er sprake van structurele (afgesproken) werkzaamheden buiten de reguliere werktijden dan worden deze vastgelegd in dit SLA.

10 Ondertekening

De hieronder genoemde partijen verklaren hierbij akkoord te gaan met dit SLA.

Opdrachtgever Opdrachtnemer

<opdrachtgever> Amyyon

Naam De heer P.E. Xxxxxxxxx

Functie directeur

Datum: ................................... Datum: …………………………

11 Bijlage: Relevante Gegevens

Namen behorend bij het Escalatiemodel

Amyyon	naam	gegevens
Servicedesk CRM	Xxx Xxxxxxxx	050 – 305 15 25 xxxxxxxxxxxxxxx@xxxxxx.xx
Manager	Xxxx Xxxxxx	050 – 311 56 86 06 - 524 36 102 x.xxxxxx@xxxxxx.xx
Directie	Xxxx Xxxxxxxxx	050 – 311 56 86 06 - 524 36 109 x.xxxxxxxxx@xxxxxx.xx

<opdrachtgever>	naam	gegevens
Functioneel beheerder	*)
Manager
Opdrachtgever

*) Voor het uitvoeren van het Functioneel Beheer is aan Amyyon de opdracht verstrekt. Na het

verlopen van deze opdracht (DATUM) kan de opdracht worden verlengd of alsnog een naam worden toegevoegd.

Personen die bevoegd zijn tot het geven van een opdracht namens opdrachtgever:

- Bovengenoemde Manager

- Bovengenoemde Opdrachtgever

Document Metadata

Table of Contents

Service Level Agreement (SLA) Concept

Document Metadata