Service Level Agreement
Voorstel
Service Level Agreement
<klant>en Sanders Maatsoftware
Technisch Applicatiebeheer
<applicatie>
Datum document: Versie:
Auteur:
<datum> 1.0
Xxxxxx Xxxxxxx
Inhoudsopgave
AKKOORDVERKLARING 3
PARTIJEN 4
1. DOEL 5
1.1. Scope 5
1.2. Geldigheid 5
1.3. Beheer en duur van de overeenkomst 5
1.4. AFSPRAKEN SLA 5
2. ONDERWERP VAN DIENSTVERLENING 6
2.1. Onderhoud 6
2.1.1. Instandhoudingonderhoud 6
2.1.2. Perfectief onderhoud 6
2.1.3. Adaptief onderhoud 6
2.2. Service Levels 6
2.3. Uitsluitingen 7
3. KWALITEIT EN OMVANG VAN DE DIENSTVERLENING 8
3.1. Verantwoordelijkheden Opdrachtnemer 8
3.2. Verantwoordelijkheden Opdrachtgever 8
3.3. Contact 8
3.4. Calamiteiten en Incidentenbeheer 8
3.5. Escalatie 8
4. OVERLEG EN INFORMATIEVERSTREKKING 9
4.1. Overleg 9
4.2. Rapportage 9
5. FINANCIËN EN BRONCODE 9
5.1. Financiële opbouw 9
5.2. Verrekenmethodiek en verrekening 10
5.3. Broncode en intellectueel eigendom 10
BIJLAGE A: CALAMITEITEN EN INCIDENTEN 11
BIJLAGE B: PRIJZEN OPDRACHTNEMER 12
Tarieven 12
BIJLAGE C: FUNCTIONALITEIT (PROGRAMMATUUR) 13
BIJLAGE D: COMMUNICATIE EN ESCALATIE 14
BIJLAGE E: DEFINITIES EN BEGRIPPEN 15
BIJLAGE F: SECURITY 17
Akkoordverklaring
Namens <klant>
<plaats>, dd.
Handtekening
<contactpersoon klant>
<functie contactpersoon klant>
Namens Sanders Maatsoftware Groningen, dd.
Handtekening
Xxxxxx Xxxxxxx Directeur
Partijen
A. <klant> gevestigd te <plaats klant> hierna te noemen “Opdrachtgever” rechtsgeldig vertegenwoordigd door <contactersoon klant>, <functie contactpersoon klant>
en
X. Xxxxxxx Maatsoftware B.V., gevestigd te Groningen, hierna te noemen “Opdrachtnemer” rechtsgeldig vertegenwoordigd door Xxxxxx Xxxxxxx, directeur;
hierna gezamenlijk aan te duiden als “partijen”;
Verklaren te zijn overeengekomen als volgt:
1. Doel
Deze Service Level Agreement (hierna: ‘SLA’ heeft tot doel de afspraken tussen Opdrachtgever en Opdrachtnemer over de kwaliteit en de omvang van de dienstverlening vast te leggen. Deze SLA is een integraal onderdeel van de Overeenkomst levering Software <applicatie> en aanverwante dienstverlening.
1.1. Scope
De scope van deze SLA is het uitvoeren van opdrachten voor applicaties, zoals gespecificeerd in bijlage C. De opdrachten hebben betrekking op het uitvoeren van het technische applicatiebeheer (TAB) en worden gedefinieerd als 3e lijns ondersteuning.
1.2. Geldigheid
De Service Level Agreement is afgesloten voor een periode van 1 jaar ingaand op 1 maart 2015. In het algemeen geldt dat de overeenkomst stilzwijgend wordt verlengd met een periode van telkens 12 kalendermaanden tenzij één der partijen met inachtneming van een opzegtermijn van twee (2) kalendermaanden voor de vervaldatum schriftelijk en aangetekend deze overeenkomst beëindigt.
1.3. Beheer en duur van de overeenkomst
Eigenaarschap van de SLA ligt bij de Opdrachtnemer. De SLA wordt door beide partijen gezamenlijk beheerd. Bij de Opdrachtgever is daarvoor de Servicemanager ICT aangewezen, bij de Opdrachtnemer de Servicemanager (bijlage D). Maatgevend is het door beide partijen ondertekende exemplaar van deze overeenkomst. Startdatum van deze overeenkomst is 1 maart 2015, Dienstverlening wordt vastgesteld voor een jaar, met een evaluatie uiterlijk 1 maand voor de einddatum van deze overeenkomst. Evaluatie vindt plaats op uitnodiging van Opdrachtgever. Hierin zal worden gekeken of de dienstverlening gecontinueerd moet worden, al dan niet met wijzigingen. Wijzigingen de gevolgen daarvan worden in het tactisch overleg tussen Opdrachtgever en Opdrachtnemer schriftelijk vastgesteld en in de bijlagen als addendum toegevoegd aan de SLA. In de jaarlijkse review van de SLA worden vastgestelde wijzigingen opgenomen in de SLA, en wordt de SLA opnieuw vastgesteld en ondertekend door beide partijen.
1.4. Afspraken SLA
In deze SLA zijn afspraken gemaakt over:
• Duur en geldigheid van de overeengekomen dienstverlening (hoofdstuk 1);
• Het beheer van deze SLA (hoofdstuk 1);
• Onderwerp dienstverlening, definities applicatiebeheer en standaard serviceopties (hoofdstuk2)
• Verantwoordelijkheden voor Opdrachtgever en Opdrachtnemer (hoofdstuk 3);
• De kwaliteit van de dienstverlening (hoofdstuk 3);
• Calamiteiten, incidenten en escalatieprocedure (hoofdstuk 3);
• Overleg en informatieverstrekking (hoofdstuk 4);
• Financiële opbouw en bemensing (hoofdstuk 5);
• De contactpersonen met hun bereikbaarheid en rol (bijlage D);
• Verklarende woordenlijst (bijlage E);
2. Onderwerp van dienstverlening
In dit hoofdstuk wordt het onderwerp van dienstverlening beschreven.
2.1. Onderhoud
De SLA heeft betrekking op het technisch applicatiebeheer van de applicatie die beschreven is in bijlage C.
Technisch applicatiebeheer wordt gedefinieerd middels de navolgende definities van:
• Instandhoudingonderhoud (correctief en preventief);
• Perfectief onderhoud;
• Adaptief onderhoud (klein en groot).
2.1.1. Instandhoudingonderhoud
Instandhoudingonderhoud heeft als doel de applicatie te laten functioneren conform de van kracht zijnde functionele specificaties, voor zover nu aanwezig, en de overeengekomen Service Levels. Instandhoudingonderhoud bestaat uit:
• Correctief onderhoud: het aanpassen van de applicatie om afwijkingen te herstellen tussen de gespecificeerde functionaliteit en/of de overeengekomen service levels en de geboden functionaliteit en/of service levels;
• Preventief onderhoud: het toetsen en zo nodig aanpassen van de applicatie om potentiële foutoorzaken weg te nemen.
2.1.2. Perfectief onderhoud
Het na goedkeuring van de Opdrachtgever aanbrengen van wijzigingen in de applicatie met als doel:
• Het gebruik van de ter beschikking zijnde systeemresources te optimaliseren en/of de programmatuur beter onderhoudbaar te maken;
• De door de Opdrachtgever gewenste hogere service levels te realiseren.
2.1.3. Adaptief onderhoud
Adaptief onderhoud omvat alle werkzaamheden die uitgevoerd moeten worden om de applicatie aan te passen als gevolg van functionele wijzigingen en/of wijzigingen in systeemomgeving van betrokken applicatie. Adaptief onderhoud kent twee vormen waarbij de vorm wordt vastgesteld middels een impactanalyse:
• Klein adaptief onderhoud: omvat kleinere functionele wijzigingen. Hiervoor geldt een gegarandeerde afname van <uren> uur per maand tegen het geldende uurtarief (zie bijlage B). Opdrachtverstrekking vindt plaats via mail door Functioneel Beheer.
• Groot adaptief onderhoud: omvat grotere wijzigingen die zoveel mogelijk worden opgenomen in een release of project, waarbij de nieuwe / gewijzigde / vervallen functionele specificaties schriftelijk worden vastgelegd en door Opdrachtgever goedgekeurd. Voor deze vorm van onderhoud wordt een offerte uitgebracht conform de in bijlage B opgenomen uurtarieven.
Er geldt een afnameverplichting voor service requests (verzoeken) en klein adaptief onderhoud t/m 8 uur per maand; overig adaptief onderhoud (ongeacht klein / groot) vindt plaats op basis van een offerte.
2.2. Service Levels
Openstellingtijd
Op werkdagen van 09.00 – 18.00 uur kunnen verzoeken en incidenten via de portal van Xxxxxxx worden aangemeld. In geval van spoed kan ook worden gebeld.
De contactgegevens zijn opgenomen in bijlage D.
Waakdienst
Geen
Reactie-, herstel- en oplossingstijden
In bijlage A zijn t.b.v. incidenten de standaard tijden weergegeven. Voor wijzigingen geldt uitvoering conform paragraaf 2.2.3.
Onderhoudswindow
Planmatig onderhoud gebeurt buiten openstellingtijd, op een tijdstip in overleg met Opdrachtgever
Continuïteit
Uitwijk bij Calamiteiten is vastgelegd in de afspraken met de partij waarbij de applicatie wordt gehost.
Security
Gezien het informatieclassificatieniveau van de gegevens die door de applicatie worden verwerkt, (GEHEIM) zijn er aparte eisen gesteld aan toegang, inzage en opslag van deze gegevens. Deze voorwaarden zijn in de vorm van een Bewerkersovereenkomst - <APPLICATIE> ondertekend opgenomen in bijlage G.
Rapportages
Via portaal van Opdrachtnemer
2.3. Uitsluitingen
De volgende onderdelen maken geen deel uit van deze overeenkomst:
• Het 1e en 2e lijns beheer;
• Het beschikbaar stellen, exploiteren, tunen en operationeel houden van de (voor de applicatie benodigde systeemomgevingen en netwerken
• Gebreken in de kwaliteit van de gegevensverzameling voor zover veroorzaakt door fouten van de kant de Opdrachtgever.
3. Kwaliteit en omvang van de dienstverlening
3.1. Verantwoordelijkheden Opdrachtnemer
• Accepteren van de toegeleverde opdrachten op voorwaarde dat er:
o een volledig door Opdrachtgever ingevuld formulier / mailtje is met daarin de volgende zaken: opdrachtomschrijving incl. resultaat (opsomming gewenste wijzigingen / specificaties…), planning / mijlpalen en impact / kosten;
o een overeengekomen realiseerbare planning is.
• Leveren van de dienstverlening conform overeengekomen Service Levels;
• Volledig en tijdig uitvoeren van toegeleverde opdrachten van Opdrachtgever;
• Bijwerken en onderhouden technische documentatie (broncode) en technische specificaties;
• Voeren van overleg met Opdrachtgever;
• Deponeren van de broncode bij <klant> (na iedere release opnieuw);
• Continu monitoren van de kwaliteit van de op te leveren producten;
• Leveren van een functionele architectuur beschrijving;
• Zorg dragen voor de integriteit van de database bij incidenten en wijzigingen, en de integriteit van data bij incidenten;
• Laten aansluiten van de eigen beheerprocessen op die van Opdrachtgever.
3.2. Verantwoordelijkheden Opdrachtgever
Opdrachtgever is verantwoordelijk voor het/de:
• Volledig en tijdig verlenen/toeleveren van opdrachten aan Opdrachtnemer;
• Volledig en tijdig accepteren van opdrachten uitgevoerd door Opdrachtnemer;
• Volledig en tijdig doorgeven van wijzigingen in de hardware- en netwerkcomponenten;
• Oplevering functionele requirements;
• Bijwerken functionele documentatie;
• Leveren van een technische architectuur beschrijving.;
• Zorgen dragen voor een representatieve testomgeving, inclusief licenties en actuele data;
• Structurele toegang tot deze testomgeving en incidentele toegang, op door <klant> aangegeven periodes, tot de productieomgeving (updates plaatsen);
• Aanleveren van de acceptatie methodiek (testmethode, testverslag met geconstateerde gebreken en goedgekeurde zaken, wie doet wat en hoe loopt die communicatie);
• Doorgeven van veranderingen op het vlak van security en gebruikspatronen van de applicatie;
• Zorg dragen voor de integriteit van data bij wijzigingen;
• Voeren van overleg met Opdrachtnemer;
• Leveren van de vastgestelde beheerprocessen.
• Zorgen voor een juiste routing van incidenten naar de betreffende leverancier(s).
3.3. Contact
Voor de overeengekomen dienstverlening worden door beide partijen contactpersonen aangewezen. Per contactpersoon wordt aangegeven voor welke onderwerpen de contactpersoon aanspreekbaar is. De contactpersonen en hun rol zijn vastgelegd in Bijlage D.
3.4. Calamiteiten en Incidentenbeheer
Voor de afwikkeling van Calamiteiten en Incidenten zijn 4 niveaus van afhandeling geformuleerd. Deze staan beschreven in Bijlage A. De prioriteit van een incident/melding wordt bepaald door de Functioneel beheerder van de applicatie zoals opgenomen in Bijlage D.
3.5. Escalatie
Er is sprake van een geschil als een van beide partijen deze mening is toegedaan en dit schriftelijk aan de andere partij heeft gecommuniceerd. Een geschil dat binnen één van de werkgebieden ontstaat wordt binnen Opdrachtgever en Opdrachtnemer geëscaleerd volgens bijlage D.
4. Overleg en informatieverstrekking
4.1. Overleg
Een keer per 3 maanden is er overleg tussen vertegenwoordigers van Opdrachtgever en Opdrachtnemer over de volgende onderwerpen:
• Afstemmen kwaliteit dienstverlening;
• Afstemmen voortgang verbeteracties;
• Voortgang op gemaakte afspraken;
• Afstemmen van de gemaakte kosten;
• Afstemmen opdrachten en prioritering;
• Afstemming invulling beheer;
• Kennisoverdracht;
• Afstemmen vraag en capaciteit middels een door Opdrachtgever op te stellen Forecast (komende Releases, ontwikkelingen);
• Review en herijking van deze overeenkomst.
De scope van dit overleg is verantwoording van en sturing op gemaakte afspraken, geleverde zaken en bepalen capaciteit van het dienstenpakket.
Deelnemers in het overleg zijn in ieder geval:
Opdrachtgever: <contactpersoon klant> Opdrachtnemer: Servicemanager
Indien wenselijk / nodig kan elk van beide partijen uiteraard een ad-hoc overleg initiëren. De functionarissen zijn vermeld in bijlage D van de overeenkomst.
4.2. Rapportage
InOpdrachtnemer kan ten alle tijde de actuele stand van issue zien in de issuetracker .Indien nodig communiceert opdrachtnemer informatie die niet in de issuetracker saat per e-,mail aan Xxxxxxxxxxxx
5. Financiën en Broncode
5.1. Financiële opbouw
De financiële opbouw heeft betrekking op de dienstverlening zoals genoemd is in hoofdstuk 2 en wordt per applicatie uitgewerkt .
5.2. Verrekenmethodiek en verrekening
▪ Releases en vernieuwingsinvesteringen horende bij groot adaptief onderhoud worden op offertebasis aangeboden en eventueel als project aangestuurd. Opdrachtgever draagt er zorg voor dat bij het verstrekken van de opdracht duidelijk is aangegeven dat het een release of een investeringsproject betreft. De kosten van de releases en investeringen worden verrekend op basis van werkelijk bestede uren tot een maximum van het afgesproken offertebedrag. Zowel planning als overschrijdingen dienen hierbij te worden geaccordeerd door Opdrachtgever.
▪ De maandelijkse vaste kosten worden per maand achteraf gefactureerd.
▪ De kosten van aanvullende overeengekomen werkzaamheden worden achteraf verrekend op basis van werkelijk bestede uren tegen een uurtarief (bijlage B) dat is overeengekomen.
▪ Alle genoemde bedragen zijn exclusief BTW. Reistijd wordt niet in rekening gebracht.
▪ Betalingen dienen binnen 30 dagen na factuurdatum plaats te vinden.
▪ Het kostenoverzicht is geldig voor de in dit contract genoemde dienstverlening.
▪ Jaarlijks worden de genoemde bedragen voor de flexibele component en de basisorganisatie met het maandprijsindexcijfer volgens het indexcijfer zakelijke dienstverlening CAO-lonen per uur inclusief bijzondere beloningen zoals gepubliceerd door het CBS in september gecorrigeerd.
5.3. Broncode en intellectueel eigendom
Ten aanzien van de broncode geeft Xxxxxxxxxxxxx de volgende informatie:
• Indien van toepassing staat technische documentatie in de broncode.
• Broncode en database staan bij de provider en zijn door Opdrachtgever op ieder moment in te zien met een teksteditor voor de broncode en Microsoft enterprise-manager voor de database. Opdrachtgever is in het bezit van de toegangscodes om deze acties te kunnen uitvoeren.
• Intellectueel eigendom van <APPLICATIE> voor het gedeelte dat kenmerkend is voor
<APPLICATIE>, is en blijft in handen van Opdrachtgever.
• Intellectueel eigendom van <APPLICATIE> voor het gedeelte dat niet kenmerkend is voor
<APPLICATIE>, is en blijft in handen van Opdrachtnemer.
• De broncode wordt initieel en na iedere release gedeponeerd bij Opdrachtgever
• Partijen mogen <APPLICATIE> niet zonder goedkeuring van elkaar aan derden verkopen.
• Opdrachtnemer zorgt voor implementatie van het product op een omgeving die losstaat van die van <APPLICATIE> voor Opdrachtgever.
Bijlage A: Calamiteiten en Incidenten
1. Prioriteiten incidenten
Prioriteit | Incidenttype |
1 HIGH | Verstoring van een kritische business proces (geaccepteerde functionaliteiten) door het verminken van informatie, het verloren gaan van informatie of niet correcte uitvoer hetgeen leidt tot een ernstige vertraging in het bedrijfsproces Opdrachtgever. |
2 MEDIUM | Verstoring van de interne dienstverlening van Opdrachtgever, waardoor de productiviteit van haar gebruikers wordt beperkt door het niet voor 100% functioneren van het door Opdrachtgever geaccepteerde systeem. |
3 LOW | ALLE ANDERE INCIDENTEN WAARONDER Xxxxxxxxx, verwijdering of toevoeging van functionaliteit, indien niet opgenomen in een gedefinieerd release of update. |
Voor 90% van de gevallen:
Reactietijd | Hersteltijd | Oplossingstijd | |
High | Max 2 uur | Max 4 uur | Max 1 werkdagen |
Medium | Max 1 werkdag | Xxx 3 werkdagen | Max 3 werkdagen |
Low | Max 1 werkdag | onbepaald | onbepaald |
Voor overige 10%:
Reactietijd | Hersteltijd | Oplossingstijd | |
High | Max 1 werkdag | Xxx 2 werkdagen | Max 2 werkdagen |
Medium | Max 1 werkdag | Xxx 3 werkdagen | Max 3 werkdagen |
Low | Max 1 werkdag | onbepaald | Onbepaald |
Bijlage B: Prijzen Opdrachtnemer
Tarieven
Jaarlijks zullen de prijzen voor de verschillende diensten die door Opdrachtnemer worden vervuld worden vastgesteld uiterlijk in november van het voorgaande jaar.
De diensten die Opdrachtnemer voor Opdrachtgever zal kunnen vervullen zijn:
Vast bedrag p.m. | Tarief p.u. | |
Gebruiksrecht en Implementatie Programmatuur | n.v.t. | |
Instandhoudingsonderhoud | n.v.t. | |
Perfectief onderhoud | n.v.t. | |
Klein adaptief onderhoud t/m <uren> uur p.m. | ||
Klein adaptief onderhoud > <uren> uur p.m. | ||
Groot adaptief onderhoud | ||
Genoemde prijzen zijn exclusief BTW.
Bijlage C: Functionaliteit (Programmatuur)
<Invoegen: plaatje functioneel landschap / functioneel ontwerp>
Bijlage D: Communicatie en Escalatie
Door Opdrachtgever is de volgende contactpersoon aangewezen:
• <contactpersoon klant>
Tel.: <telefoon contactpersoon klant> E-mail: <email contactpersoon klant>
Problemen / storingen worden aangemeld door:
Door Opdrachtnemer is de volgende contactpersoon aangewezen :
• Xxx. Xxxxxx Xxxxxxx Tel.: 000-000 0000
Problemen / storingen / klachten worden aangemeld bij
• Xxx. Xxxxxx Xxxxxxx Tel.: 000-0000000
• Portal Sanders: xxxx://xxx.xxxxxxx-xxxxxxxxxxxx.xx/xxxxx
Escalaties lopen via <escalator klant> en Xxxxxx Xxxxxxx.
Bijlage E: Definities en begrippen
Acceptatie:
Schriftelijke aanvaarding door Opdrachtgever, dat aan de specificaties voor de applicaties is voldaan;
Applicatie:
Een verzameling werkende programma’s inclusief de bijbehorende gegevensverzameling(en), interfaces en de bijbehorende documentatie.
a. Versie:
Een versienummer identificeert eenduidig de status van de applicatie op een bepaald tijdstip. Een nieuw Release of een Upgrade van een Release leidt tot een nieuwe versie.
b. Release:
Een bundeling van wijzigingen in de functionaliteit worden als pakket (Release) op een afgesproken moment in productie genomen hetgeen leidt tot een nieuwe versie.
c. Update:
Het uitvoeren van onderhoud op een bepaalde Release van de applicatie, waarbij de functionaliteit van de applicatie wordt gewijzigd. Implementatie kan niet wachten tot de volgende Release. Binnen een Update kunnen optionele Fix-identificaties worden opgenomen. Een Fix op een Update kan uitsluitend ontstaan door correctief onderhoud dat direct wordt uitgevoerd.
d. Fix:
Een Fix is het gevolg van correctief onderhoud welke zo spoedig mogelijk, maar gecontroleerd wordt uitgevoerd.
e. Patch:
Een patch is het gevolg van een productieverstoring welke direct verholpen moet worden. De gewijzigde software wordt op productie ingedraaid, waarbij de wijziging achteraf goedgekeurd wordt.
Calamiteit:
Een verstoring in de systeemomgeving(en), waardoor de applicatie gedurende een periode van een werkdag niet beschikbaar is. Vaststelling van een Calamiteit gebeurt door Opdrachtgever en Opdrachtnemer.
Escalatie:
Naar een hoger organisatorisch niveau brengen, omdat de bevoegdheid tot beslissen niet op het huidige niveau aanwezig is en/of omdat de afgesproken Service Levels in gevaar zijn of dreigen te worden overschreden.
Hersteltijd:
Het tijdvenster waarin een incident tijdelijk hersteld wordt dan wel een work-around wordt geboden.
Incident:
Elke reproduceerbare gebeurtenis waarbij de applicatie niet functioneert conform de functionele en technische specificaties, zoals overeengekomen tussen Opdrachtgever en Opdrachtnemer
Oplossingstijd:
Het tijdvenster waarin een incident tijdelijk hersteld wordt of definitief hersteld wordt of waarin een tijdelijk hersteld incident definitief wordt opgelost.
Openstellingtijd:
Dit is de tijdsperiode waarbinnen de afgesproken dienstverlening geldig is.
Prioriteit:
De relatieve waardering van een activiteit (in dit geval de Incident/Probleemafhandeling) t.o.v. andere activiteiten.
Probleem:
Onderliggende oorzaak van een opeenstapeling van Incidenten.
Reactietijd:
Het tijdvenster waarbinnen Opdrachtnemer moet hebben gereageerd op een door Opdrachtgever aangemeld Incident.
SLA:
Service Level Agreement. Overeenkomst waarin de omvang en de kwaliteit van de service die Opdrachtnemer aan Opdrachtgever zal leveren is vastgelegd.
TAB:
Technisch ApplicatieBeheer.: analyseren en oplossen van verstoringen in de applicatiesoftware en de bijbehorende database; realiseren, testen en implementeren van wijzigingen (test- en productieomgeving).
Uur: Klokuur / Openstellingsuur Werkdag:
Maandag tot en met vrijdag met uitzondering van de algemeen erkende feestdagen en overige
werkdagen die door Opdrachtgever als verplichte vrije dagen zijn aangewezen.