Service Level Agreement (SLA)
Service Level Agreement (SLA)
versie 1.4 (2024)
ã Shinto Labs B.V. Alle rechten voorbehouden. 23-02-2024
Herdruk of uitgave aan derden op welke wijze dan ook is niet toegestaan zonder voorafgaande schriftelijke toestemming van de copyrighthouder.
INHOUDSOPGAVE
1. DOELSTELLING SLA 1
1.1 Doelstelling 1
1.2 Innovatief onderhoud 1
1.3 Contractuele context 2
2. SERVICENIVEAU 3
2.1 Werktijden 3
2.2 Windows 3
2.3 Performance 5
2.4 Storingsbeheer en afhandeling vragen 6
2.5 Wijzigingsbeheer 7
2.6 Betrouwbaarheids- en integriteitsbeheer 8
3. SERVICE NIVEAU ‘ON-PREMISES’ COMPONENTEN 9
3.1 Inleiding 9
3.2 Werktijden 9
3.3 Windows 9
3.4 Performance 10
3.5 Storingsbeheer en afhandeling vragen 10
3.6 Wijzigingsbeheer 10
3.7 Betrouwbaarheids- en integriteitsbeheer 10
Bijlage 1 Begrippenlijst 11
Bijlage 2 Escalatiematrix 13
i
1. DOELSTELLING SLA
1.1 Doelstelling
Het doel van deze Service Level Agreement (SLA) is het in kaart brengen van afspraken over de dienstverlening in relatie tot Onderhoud en het niveau ervan door Shintō Labs aan de klant.
Deze SLA geeft de klant inzicht in de dienstverlening op het gebied van onderhoud van Shintō Labs en stelt zowel Shintō Labs als de klant in staat beter te sturen op de kwaliteit van de dienstverlening daaromtrent. De concrete afspraken die over de aard, omvang, niveau en kwaliteit van de dienstverlening worden gemaakt, zijn vastgelegd in deze SLA.
De dienstverlening bestaat uit de volgende elementen:
• Beschikbaarheid van de SaaS-Dienst;
• Dienstverlening Shintō Labs supportorganisatie;
• Onderhoud van de software;
• Technisch en operationeel beheer van de Shintō Labs Cloud Infrastructuur.
Na ingebruikname van de SaaS Dienst zal Shintō Labs de SaaS-Dienst zo goed mogelijk onderhouden conform de service levels zoals in dit document beschreven. Onderhoud omvat uitsluitend Correctief onderhoud en Preventief Onderhoud. Preventief Onderhoud bestaat uit het van tijd tot tijd uitbrengen van verbeterde versies waarin de werking van de SaaS-Dienst kan worden verbeterd en bestaande functionaliteit kan worden aangepast.
Daar waar in dit document begrippen zijn aangeduid met een hoofdletter wordt verwezen naar Bijlage 1 Begrippenlijst waarin deze nader worden geduid.
1.2 Innovatief onderhoud
Innovatief onderhoud maakt geen onderdeel uit van het service level in die zin dat Shintō Labs eventuele vernieuwingen tegen een meerprijs aan kan bieden aan de klant. Dit laat onverlet de verplichting van Shintō Labs om de bestaande SaaS Dienst beschikbaar en toegankelijk te houden voor de klant gedurende de looptijd van de overeenkomst.
Echter, op basis van marktvalidatie kunnen applicaties worden ‘geproductized’ en als standaardproduct aan de markt aangeboden. Op het moment dat een applicatie wordt geproductized ontwikkelen we een roadmap voor doorontwikkeling.
Er zijn hierbij twee vormen van doorontwikkeling mogelijk:
• Een nieuwe feature wordt betaald door 1 klant en kosteloos aangeboden aan de andere klanten;
• Een nieuwe feature wordt betaald door Shintō Labs en (mogelijk maar niet altijd) tegen een meerprijs op de softwarefee (als module) aangeboden aan de klanten.
Op die manier profiteren overheden van elkaars investeringen en kan gezamenlijk een applicatie/product naar een hoger niveau worden gebracht. Mogelijk dat in sommige gevallen ook een scenario denkbaar is waarin beide vormen van doorontwikkeling tegelijk worden toegepast.
De afname van nieuwe features of functionaliteiten met een meerprijs zullen nooit een verplichting zijn voor bestaande klanten.
N.B. indien voor een nieuwe feature of functionaliteit aanvullende componenten van het Microsoft Azure platform nodig zijn dan is het mogelijk dat deze tegen meerprijs worden aangeboden.
1.3 Contractuele context
Deze SLA vormt een integraal onderdeel van de Algemene Voorwaarden van Shintō Labs.
Deze voorwaarden zijn van toepassing op alle aanbiedingen en/of (af/op)leveringen van Shintō Labs en overeenkomsten en/of overige rechtsbetrekkingen tussen Shintō Labs en haar klanten tenzij anders is overeengekomen.
Deze voorwaarden kunt u downloaden als PDF-bestand via onderstaande link: xxxxx://xxx.xxxxxxxxxx.xx/xxxxxxxx-xxxxxxxxxxx/
2. SERVICENIVEAU
2.1 Werktijden
Werktijden zijn binnen SLA Basis en SLA Plus als volgt gedefinieerd:
Omschrijving SLA Basis SLA Plus
Werktijden Werkdagen op maandag tot en met vrijdag van 09:00 – 17:00 uur.
Nog niet beschikbaar.
2.2 Windows
2.2.1 Servicewindow
Het Servicewindow is de tijd waarbinnen de klant toegang heeft tot de SaaS-Dienst en Shintō Labs onderbrekingen als Storingen zoveel mogelijk probeert te beperken en/of te voorkomen.
Performance indicator van het Servicewindow
Soort Norm Minimaal te realiseren
Beschikbaarheid van de SaaS- tijdens Werktijden Dienst.
98% beschikbaarheid per maand
Buiten het Servicewindow wordt een beschikbaarheid van de Saas-Dienst van ten minste 95% nagestreefd. Voor het berekenen van voornoemde beschikbaarheid wordt niet meegerekend onbereikbaarheid tijdens gepland Onderhoud en beheer tijdens het Onderhoudswindow. Het betreft hier een inspanningsverplichting van Shintō Labs en geen resultaatsverplichting.
2.2.2 Onderhoudswindow
Het Onderhoudswindow is de tijd waarbinnen het Onderhoud en het beheer op de SaaS-Dienst plaatsvindt. Dit kan bestaan uit Onderhoud aan en (technisch en operationeel) beheer van de Shintō Cloud Infrastructuur, software en automatiseringsomgeving van de klant.
Om op een juiste wijze om te gaan met de verschillen in de aard en xxxxx xxx Xxxxxxxxx voor het verrichten van Onderhoud worden Storingen als volgt geclassificeerd.
Impactclassificatie
Hoog
Merkbare invloed op de SaaS-Dienst en merkbare onderbreking (downtime) van de SaaS-dienst (onbeschikbaarheid) van de koppeling tussen de SaaS-Dienst en de Publieke Infrastructuur.
Middel Gedeeltelijk merkbare invloed op SaaS-Dienst en geen invloed op de beschikbaarheid.
Laag Geen merkbare invloed op de dienst, overige omstandigheden.
Performance indicator van het Onderhoudswindow
Soort Norm
Onderhoud en beheer van de SaaS dienst met impact Hoog of Middel
Na aankondiging, op werkdagen op maandag tot en met vrijdag van 22:00 uur – 06:00 uur en/of in weekenden van zaterdag 13:00 tot zondag 24:00 uur.
De aankondiging van een Onderhoudswindow vindt plaats via e-mail t.a.v. de contact perso(o)n(en) van de klant en bevat de volgende informatie:
• Datum en tijdstip van het Onderhoudswindow;
• Begin- en eindtijd van de werkzaamheden;
• Omschrijving van de werkzaamheden;
• De impact op de SaaS dienstverlening.
Na afronding van het geplande Onderhoudswindow zal een mail gestuurd worden, aangaande het verloop van het onderhoud. Indien er sprake is van (dreigende) uitloop, zal hierover zo vroeg als mogelijk gecommuniceerd worden.
Onderhoud met lage impact is continue mogelijk. Dit wordt niet aangekondigd en hier wordt niet over gerapporteerd.
2.2.3 Spoed onderhoud
Shintō Labs kan besluiten om ongeplande wijzigingen door te voeren buiten het reguliere Onderhoudswindow, bijvoorbeeld bij een Storing, waardoor onmiddellijke actie vereist is. Indien dit impact heeft op de beschikbaarheid van De SaaS-Dienst tijdens het Service Window, kan dit mogelijk ten koste gaan van de beschikbaarheidsgaranties.
2.2.4 Beschikbaarheid Shintō Support
Dit is de tijd waarbinnen de Shintō Support van Shintō Labs bereikbaar is voor de klant en meldingen met betrekking tot de dienstverlening (Storingen, vragen en beheerverzoeken).
Aanmelden van een Storing via email of webformulier
Tijdens Werktijden
Performance indicator voor beschikbaarheid van Shintō Support: Soort Norm
Telefonische bereikbaarheid Niet beschikbaar
Shintō Support is als volgt bereikbaar voor contactpersonen van de klant:
• E-mail via xxxxxxx@xxxxxxxxxx.xx
• Support webportal via xxxxx://xxx.xxxxxxxxxx.xx/xxxxxxx
2.3 Performance
Hieronder wordt verstaan de reactietijd van de applicatie(s) van request tot aan antwoord (van enter tot nieuw scherm). De reactietijd wordt bepaald door de Infrastructuur, bestaande uit een drietal domeinen:
⬤ Klant Infrastructuur: Het netwerk, internetfaciliteiten van de klant, de devices, de firewalls, routers, switches, WAN/LAN, WiFi en de instellingen die hierbij horen, maar ook koppelingen met derden applicaties.
⬤ Shintō Cloud Infrastructuur: De omgeving waarin de SaaS-Dienst draait, inclusief firewalls, webservers, applicatieservers, database servers en SAN’s.
⬤ Publieke Infrastructuur: Het domein dat de beide bovengenoemde domeinen verbindt via publieke c.q. dedicated (internet)verbindingen.
Xxxxxx Support heeft als doelstelling om voor al haar klanten een acceptabele reactietijd te leveren. Daarom bewaakt Shintō Support de reactietijd van de applicaties in de Shintō Cloud Infrastructuur op regelmatige basis.
2.4 Storingsbeheer en afhandeling vragen
Bij de registratie van meldingen wordt bepaald wat de typering van een melding is:
• Storing;
• Vraag.
In de volgende paragrafen wordt de afhandeling van Storingen en vragen beschreven.
2.4.1 Afhandeling van storingen
Om een Storing te melden, moet minimaal de volgende informatie door de Opdrachtgever aan de Shintō Support worden doorgegeven:
• klantnaam
• de naam en telefoonnummer van de aanmelder;
• een korte omschrijving van de Storing;
• indien aanwezig, alle documenten en/of rapporten die kunnen helpen bij de identificatie en het oplossen van de Storing.
• stappenplan waarmee de Storing te reproduceren valt.
Als de door de klant doorgegeven initiële informatie naar oordeel van Xxxxxx onvoldoende is om de Storing adequaat te kunnen analyseren, zal er een aanvraag voor additionele informatie naar de klant worden verstuurd. Responstijd wordt gerekend vanaf het moment dat Xxxxxx beschikt over een volledige en begrijpelijke melding van een Storing en/of verzoek om Onderhoud.
Om op een juiste wijze om te gaan met de verschillen in aard en aantal bij de afhandeling van Storingen zijn de Storingen als volgt geclassificeerd en geprioriteerd.
Prioriteit | Betekenis | Omschrijving |
1 | Showstopper | De Storing heeft een vergaande en onmiddellijke invloed op de |
werkzaamheden binnen de klantorganisatie, de werkzaamheden | ||
kunnen geen doorgang vinden. Er bestaat geen alternatieve | ||
oplossing die vergelijkbare mogelijkheden en prestaties biedt. | ||
2 | Hoog | De Storing heeft een aanzienlijke invloed op de werkzaamheden |
binnen de klantorganisatie. Een alternatieve oplossing is | ||
beschikbaar, al dan niet met enige beperkingen. | ||
3 | Xxxxxx | Xx Xxxxxxx heeft een beperkte invloed op de werkzaamheden |
binnen de klantorganisatie. | ||
4 | Laag | De Storing heeft geen nadelige invloed op de werkzaamheden |
binnen de klantorganisatie. |
Performance indicator voor oplossing Storingen
Soort | Norm | Minimaal te realiseren |
1 | Showstopper | Oplossing door middel van workaround of oplossing: • 90% binnen 24 uur • 100% binnen 48 uur |
Structurele oplossing: | ||
• Binnen 30 kalenderdagen | ||
2 | Hoog | Structurele oplossing: • Tussen 30-90 kalenderdagen |
3/4 | Middel/Laag | Oplossing wordt in de releasekalender opgenomen en naar inzicht van Shintō Labs meegenomen bij een Verbeterde Versie. |
Het betreft hier een inspanningsverplichting van Shintō Labs en geen resultaatsverplichting.
2.4.2 Beantwoording vragen (ondersteuning)
Ondersteuning (support) wordt gedefinieerd als het beantwoorden van de vraag aan de klant of het melden dat de vraag in behandeling is genomen omdat beantwoording op korte termijn niet mogelijk is. Het inspreken van een antwoord op de vraag op voicemail van de melder wordt ook als beantwoording beschouwd. Dit gebeurt eveneens als een vraag een Storing blijkt te zijn en dit opgelost moet worden. De vraag zal dan conform de procedures van Storingbeheer afgehandeld worden.
Performance indicator voor beantwoording van vragen
Soort Norm Minimaal te realiseren
Beantwoording van vragen
Vragen worden binnen 48 uur beantwoord
90%
2.5 Wijzigingsbeheer
Wijzigingen van de diensten kunnen voortvloeien uit:
• Oplossen van Storingen (problemen) door wijziging op de dienst;
• Implementatie van Verbeterde Versies met daarin wijzigingen van de SaaS Dienst als gevolg van bijvoorbeeld marktontwikkelingen of technologische ontwikkelingen.
Aanpassingen op de dienstverlening worden naar inzicht van tijd tot tijd opgesteld door Shintō Labs. Bij het doorvoeren van wijzigingen op bestaande diensten dienen deze wijzigingen beheerst en gecontroleerd doorgevoerd te worden, bij voorkeur tijdens een Onderhoudswindow zodat dat de continuïteit van het bedrijfsproces zo min mogelijk wordt verstoord. Shintō Labs streeft bij installatie van Verbeterde Versies de continuïteit van de bestaande diensten zo min mogelijk aan te tasten door deze op planmatige en gecontroleerde wijze door te voeren.
2.6 Betrouwbaarheids- en integriteitsbeheer
2.6.1 Escalatie
Indien processen of communicatie tussen de partijen niet naar tevredenheid verloopt, en verbetering niet via het reguliere overleg te verkrijgen is, kan gebruik gemaakt worden van de escalatieprocedure en de escalatiematrix zoals opgenomen in de bijlage bij dit SLA.
Bijzondere vormen van escalatie zijn de opschaling van communicatie bij het niet halen van de servicetijden bij het Storingenproces en bij het constateren van calamiteiten.
2.6.2 Gegevensverlies
Ondanks alle voorzorgsmaatregelen kan het voorkomen dat door technische problemen gegevens verloren gaan. Voor alle windows geldt dat de afspraken niet kunnen worden gegarandeerd indien de dienstverlening wordt verstoord:
• door toedoen van de klant;
• door calamiteiten bij Shintō of Shintō Cloud Infrastructuur;
• door calamiteiten op Publieke Infrastructuur of Klant Infrastructuur.
Shintō Labs verplicht zich tot het nemen van maatregelen om gegevensverlies schade zoveel mogelijk te beperken.
2.6.3 Beveiliging
Shintō verplicht zich tot het nemen van maatregelen om ongeautoriseerde toegang tot gegevens binnen de Shintō Cloud Infrastructuur te voorkomen en schade daardoor zoveel mogelijk te beperken. Zie ook de Verwerkersovereenkomst voor een overzicht van de maatregelen.
3. SERVICE NIVEAU ‘ON-PREMISES’ COMPONENTEN
3.1 Inleiding
Waar de SaaS-Dienst een (native) cloudoplossing is, zijn er ook sommige componenten ontwikkeld die ‘on-premises’ (binnen de Klant Infrastructuur) functioneren en dus worden geïnstalleerd. Denk bijvoorbeeld aan de oplossing voor pseudonimiseren van data die is ontwikkeld. Voor deze componenten gelden aangepaste service levels.
3.2 Werktijden
De werktijden zijn zoals gemeld in Hoofdstuk 2.
3.3 Windows
3.3.1 Servicewindow
Het Servicewindow is de tijd waarbinnen de klant toegang heeft tot de On-Premises Component.
De On-Premises Component draait in de Klant Infrastructuur. Shintō Labs heeft geen invloed op de beschikbaarheidsniveaus van de Klant Infrastructuur en geeft daarom geen Service Window af.
3.3.2 Onderhoudswindow
Het Onderhoudswindow is de tijd waarbinnen het Onderhoud en het beheer op de On-premises com-Dienst plaatsvindt. Het Onderhoud vindt plaats tijdens kantooruren van de klant (9:00 uur – 17:00 uur). Indien er sprake is van Spoed Onderhoud kan in overleg met de klant hiervan worden afgeweken.
3.3.3 Beschikbaarheid Shintō Support
Dit is de tijd waarbinnen de Shintō Support van Shintō Labs bereikbaar is voor de klant en meldingen met betrekking tot de dienstverlening (Storingen, vragen en beheerverzoeken).
Aanmelden van een Storing via email of webformulier
Tijdens Werktijden
Performance indicator voor beschikbaarheid van Shintō Support: Soort Norm
Telefonische bereikbaarheid Niet beschikbaar
Shintō Support is als volgt bereikbaar voor contactpersonen van de klant:
• E-mail via xxxxxxx@xxxxxxxxxx.xx
• Support webportal via xxxxx://xxx.xxxxxxxxxx.xx/xxxxxxx
3.4 Performance
Xxxxxx Support zal zich inspannen om voor al haar klanten een acceptabele reactietijd te leveren. Aangezien de On-Premises Componenten in de Klant Infrastructuur draaien kunnen we geen garanties geven over de performance.
3.5 Storingsbeheer en afhandeling vragen
De Serviceniveaus voor Storingsbeheer en afhandeling van vragen is gelijk aan de beschrijving in Hoofdstuk 2.
3.6 Wijzigingsbeheer
De Serviceniveaus voor Wijzigingsbeheer is gelijk aan de beschrijving in Hoofdstuk 2.
3.7 Betrouwbaarheids- en integriteitsbeheer
De Serviceniveaus voor Betrouwbaarheids- en intergriteitsbeheer is gelijk aan de beschrijving in Hoofdstuk 2.
3.7.1 Escalatie
De escalatie procedure is gelijk aan de beschrijving in Hoofdstuk 2.
3.7.2 Gegevensverlies
De service niveaus op het gebied van gegevensverlies zijn gelijk aan de beschrijving in Hoofdstuk 2.
3.7.3 Beveiliging
Het nemen van maatregelen om ongeautoriseerde toegang tot gegevens binnen de Klant Infrastructuur te voorkomen en schade daardoor zoveel mogelijk te beperken is volledig de verantwoordelijkheid van de klant.
Bijlage 1 Begrippenlijst
Begrip Uitleg
SaaS-Dienst
De dienst waarbij Shintō Labs aan de klant via hosting online software beschikbaar stelt vanuit de Shintō Cloud Infrastructuur, inclusief het Gebruiksrecht daarvoor en het Onderhoud daarop.
Onderhoud Onderhoud: door Shintō Labs uit te voeren werkzaamheden gericht op het herstellen en/of verbeteren van de Prestatie
Shintō Cloud Infrastructuur Dat deel van de Infrastructuur dat door of onder regie van
Shintō Labs wordt beheerd in datacenter(s) van Shintō Labs of door Shintō Labs ingeschakelde derden waar Shintō Labs het gebruik van bedongen heeft.
Publieke Infrastructuur Dat deel van de Infrastructuur dat door anderen dan Xxxxxx
Labs wordt beheerd en/of geleverd en waar Shintō Labs geen controle op kan uitvoeren. Het internet valt hieronder.
Klant Infrastructuur
Het netwerk, internetfaciliteiten van de klant, de devices, de firewalls, routers, switches, WAN/LAN, WiFi en de instellingen die hierbij horen, maar ook koppelingen met derden applicaties.
Storing Een storing in de programmatuur of de Shintō Cloud Infrastructuur ten gevolge waarvan de Prestatie niet of niet deugdelijk kan worden geleverd.
Performance Indicator
Een meetbare waarde waarmee het niveau van dienstverlening wordt vastgelegd en kan worden geëvalueerd.
Correctief onderhoud Het opsporen en herstellen door Shintō Labs van Storingen, die
Klant hem heeft gemeld of die Shintō Labs anderszins bekend zijn geworden.
Preventief onderhoud
Het treffen van maatregelen door Shintō Labs ter voorkoming van Storingen en andere daarmee verband houdende vormen van dienstverlening.
Innovatief Onderhoud Het beschikbaar stellen door Shintō Labs aan Klant van Nieuwe
versies c.q. nieuw ontwikkelde onderdelen van Producten en/of nieuwe Documentatie.
Verbeterde versie
Een opvolgende versie van de Standaardprogrammatuur waarin Xxxxxxxx zijn hersteld en/of de werking daarvan anderszins is verbeterd.
Bijlage 2 Escalatiematrix
Contactpersonen en escalatie
Onderstaande personen hebben contact over uitvoering van de SLA. Indien een incident op het niveau van het operationele werkveld niet naar tevredenheid van de klant of Shintō Labs wordt afgehandeld, kunnen beide partijen conform het onderstaande schema escaleren:
Aandachtsgebied | Klant | Shintō Labs | Escalatieniveau |
Onderhoud op SaaS | Applicatiebeheerder(s): | Shintō Support | 1 |
Dienst | <NAMEN> | (xxxxxxx@xxxxxxxxxx.xx) | |
Levering van Diensten | Projectleider: | Customer Development: | 1 |
<NAAM> | Xxxxxxxx Xxxxx | ||
(xxxxxxxx@xxxxxxxxxx.xx) | |||
Tel. 00-00000000 | |||
Contract | Contractmanager | Directeur | 2 |
Klant: | Xxxx Xxxxxxxx | ||
<NAAM> | (xxxx@xxxxxxxxxx.xx) | ||
Tel. 00-00000000 | |||
Directeur | Directeur | 3 | |
(ondertekenaar | Xxxx Xxxxxxxx | ||
contract): | (xxxx@xxxxxxxxxx.xx) | ||
<NAAM> | Tel. 00-00000000 |
Escalatieprocedure
Het doel van deze procedure is het aangeven wanneer een melding functioneel en hiërarchisch geëscaleerd moet worden en wie de betrokkenen informeert. Met de uitvoering van de escalatieprocedure wordt gezorgd voor de continuïteit in de Prestatie door een zo spoedig mogelijk herstel van het afgesproken serviceniveau en het zo snel en volledig mogelijk informeren van de belanghebbenden.
Afhankelijk van de classificatie van een melding en/of Storing (Prioriteit 1) dient deze escalatieprocedure gevolgd te worden. Escalatie en communicatie zullen vervolgens in afwachting van een oplossing telkens op een hoger niveau worden uitgevoerd zowel intern als extern. Bij uitblijven van een oplossing wordt tussentijds een statusupdate gestuurd aan de relevante interne medewerkers, klanten en/of management niveaus. Storingen die gemeld worden bij de Shintō Support met prioriteit 2 en 3 worden afgehandeld via het reguliere afhandelingstraject van Shintō Support.