SLA - Service Level Agreement

Alte Version

Dieses Dokument wird durch folgende zwei Dokumente abgelöst:

Version des Dokuments: Mai 2020

1. Präambel

Dieses Service Level Agreement ("SLA") regelt die standardmässigen Service Levels für Support und Services von VSHN und findet Anwendung, wenn und soweit der Vertrag zwischen dem Kunden und VSHN auf dieses SLA verweist.

2. SLA Laufzeit und Vergütung

Thema Beschreibung

Laufzeit

Ein SLA gilt grundsätzlich für die Dauer einer Bestellung, kann jedoch jederzeit von einer der Parteien schriftlich mit einer Frist von 30 Tagen per Monatsende geändert werden. Das SLA endet automatisch bei Ende der entsprechenden Bestellung.

Service Levels

Der Kunde kann zwischen den folgenden SLA wählen:

  • SLA Standard

  • SLA Professional

  • SLA Premium

Soweit im Vertrag nicht anderweitig geregelt, gilt das "SLA Standard". Die Vergütung für das SLA richtet sich nach dem Vertrag mit dem Kunden.

Upgrade und Downgrade

Ein SLA-Upgrade kann, soweit verfügbar, jederzeit durchgeführt werden und ein SLA-Downgrade unter Einhaltung der Kündigungsfrist.

3. Übersicht & Leistungen von VSHN

Dieses SLA enthält Regelungen in Bezug auf die folgenden Leistungen von VSHN:

VSHN bietet die folgenden drei Optionen für Kunden in Bezug auf SLA:

  • SLA Standard: Verfügbarkeit des Service Desks und selbstständiges Reagieren auf Incidents der Services durch VSHN während Geschäftszeiten;

  • SLA Professional: "SLA Standard" und zusätzlich Verfügbarkeit des Service Desks während 24/7;

  • SLA Premium: "SLA Professional" und zusätzlich selbstständiges Reagieren auf Incidents der Services durch VSHN 24/7.

Weitergehende Services sind nicht Gegenstand dieser SLAs, insbesondere auch nicht:

  • Services von Drittanbietern und Infrastrukturen (Cloud- und Hardware-Infrastruktur, Netzwerk etc.).

  • Software von Drittanbietern

  • Alle Services, die sich nicht auf den bestehenden produktiven Betrieb beziehen;

  • Consulting, Schulungen und andere Requests als unten unter Service Desk Kategorien definiert;

  • Support von sonstigen Anfragen z.B. Hardware der Anwender, Konfiguration des Betriebssystems, des Netzwerks und des Internet der Anwender sowie sonstiger Software, die nicht von VSHN geliefert wurden;

4. Support

4.1. Nutzung durch den Kunden

Für die vertragsgemässe Erbringung der Service Desk Dienstleistungen durch VSHN hat der Kunde zusätzlich zu den Mitwirkungspflichten gem. AGB folgendes zu erfüllen:

  • Nutzung des elektronischen Ticketsystems

  • Registrierung auf der Statusseite status.vshn.net.

4.2. Kategorisierung

Für Kundenanfragen an den Service Desk unterscheidet VSHN zwischen Incidents, Change Requests und Support Requests:

Kategorie Beschreibung SLA

Incident

Eine nicht geplante Unterbrechung oder eine Qualitätsminderung eines VSHN IT-Services.

Gemäss nachfolgender Beschreibung.

Change Request

Ein Change Request behandelt jede Art von Änderung an einer IT-Infrastruktur oder eines IT-Services, die nicht im ursprünglichen Setup definiert wurde. Major Updates bzw. Upgrades gelten ebenfalls als Change Request.

Antwort mit Kostenschätzung für den Change innerhalb von 10 Arbeitstagen.

Support Request

Ein Support Request steht für generelle Support-Anfrage wie Informationen zu Aufbau/Setup/Design der Infrastruktur und Services, Verbesserungsmöglichkeiten, Consulting & Schulungen etc.

Antwort mit Kostenschätzung für den Support Request innerhalb von 10 Arbeitstagen.

4.3. Kontakt & Erreichbarkeit Support

Der Support ist wie folgt erreichbar:

Erreichbarkeit Support Ticketsystem E-Mail Telefon

SLA Standard

Mo. - Fr. von 9:00 Uhr bis 18:00 Uhr CET / CEST (exklusive Feiertage im Kanton Zürich, Schweiz)

control.vshn.net

support@vshn.ch

+41 44 545 53 53

SLA 24/7

Mo. - So. von 00:00 Uhr bis 24:00 Uhr

Spezielle Nummer gemäss Vertrag

Je nach Severity Level gilt zur Kontaktaufnahme folgender Prozess:

  • Severity 1-5: Ticket erstellen (per Ticketsystem oder E-Mail)

  • Severity 1-2: zusätzlich Telefon

Für Eskalationen, kommerzielle Belange, Setup und grössere Change Requests stehen dem Kunden die Ansprechpartner gemäss Vertrag zu Verfügung.

5. Incident Management

5.1. Severity Levels

Incidents werden wie folgt priorisiert:

Severity Level Beschreibung

1 (Emergency)

Das Problem verhindert die Weiterführung des Geschäftes an mehreren Arbeitsplätzen. Beispiele:

  • Zugriff auf businesskritische Kernapplikationen sind in zentralen Funktionen nicht möglich (direkte Auswirkung auf die Geschäftstätigkeit)

  • Businesskritische Abläufe können nicht ausgeführt werden, wie z.B. Bestellvorgang in einem Online-Shop (Umsatzverlust)

2 (Blocker)

Das Problem des Vertragspartners verhindert die Weiterführung einer wichtigen Tätigkeit an mehreren Arbeitsplätzen. Beispiele:

  • Funktionen in der Kernapplikationen können in zentralen Teilbereichen nicht ausgeführt werden.

  • Eine unmittelbare Umgehungslösung (Workaround) ist nicht möglich oder absehbar.

3 (High)

Das Problem behindert die Weiterführung einer wichtigen Tätigkeit. Beispiele:

  • Funktionen in der Kernapplikationen können in Teilbereichen nicht oder nur stark verlangsamt ausgeführt werden.

4 (Normal)

Das Anliegen behindert die Arbeit in einem weniger wichtigen Bereich. Beispiele:

  • Kleine Teile von Applikation oder Entwicklungsumgebung sind nicht erreichbar oder verzögert / langsam

  • Zugriff auf die Kernapplikationen gemäss Definition ist in geschäftsunkritischen Funktionen nicht möglich

  • Eine Umgehungslösung ist vorhanden oder kann eingerichtet werden / verursacht keinen signifikanten Mehraufwand

5 (Minor)

Der Kunde ist nicht in seiner Arbeit behindert. (Für Anfragen, Vorschläge, etc.)

5.2. Reaktions- und Interventionszeiten

Die Reaktionszeiten auf eine Incident-Meldung bestimmen sich auf Basis der Severity Levels und den Verfügbarkeitszeiten des Supports des gewählten Service Levels gemäss folgender Tabelle.

SLA Standard SLA Professional SLA Premium

Kunden- priorität

3 (niedrig)

2

1 (hoch)

VSHN Monitoring

Bürozeiten

Bürozeiten

24/7

Ticket/Telefon

Bürozeiten

24/7

24/7

Severity Level

Reaktion

Intervention

Reaktion

Intervention

Reaktion

Intervention

1

4h

8h

2h

4h

1h

2h

2

8h

16h

4h

8h

2h

4h

3

12h

24h

8h

16h

4h

8h

Eingang der Störungsmeldung bedeutet:

  • Erstellen des Tickets bei Severity 3 - 5

  • Telefonanruf bei Severity 1 & 2

  • Alarmierung des VSHN Monitoringsystems

Die Reaktionszeit ist die Zeitspanne zwischen dem Eingang einer Störungsmeldung bei VSHN bis zum Beginn der Störungsanalyse.

Die Interventionszeit ist die Zeitspanne zwischen dem Eingang einer Störungsmeldung bei VSHN und der Aufnahme der Arbeiten für die Störungsbehebung.

Für die Berechnung der Zeitspannen gelten die Arbeitszeiten gemäss der Verfügbarkeit des Supports. Stunden ausserhalb der Verfügbarkeit werden für die Berechnung nicht berücksichtigt.

Wird ein Workaround bereitgestellt, so ist VSHN berechtigt, die Priorität der Fehler- bzw. Störungsmeldung entsprechend zu ändern.

Nach Entgegennahme der Incident-Meldung wird der Kunde über die definierten Kanäle informiert. Wo nötig wird der Kunde mit regelmässigen Updates über den Status informiert.

Nach Lösung des Incidents wird der Kunde abschliessend informiert. Wo möglich werden seitens VSHN bzw. in Zusammenarbeit mit dem Kunden Massnahmen getroffen, um solche Incidents künftig unterbinden bzw. minimieren zu können.

Die Bearbeitung von Anliegen der Priorität 4 und 5 erfolgt im gewöhnlichen Arbeitsgang des Supports, ohne dass hierfür eine bestimmte Reaktionszeit vereinbart ist. Anliegen der Priorität 4 fliessen in der Regel in das nächste Maintenance-Release ein und Anliegen der Priorität 5, welche Änderungsvorschläge im Sinne obiger Ziffer 5.2 enthalten, werden bei der Planung für das nächste Maintenance-Release mit in Betracht gezogen.

VSHN erstellt auf Anfrage des Kunden einen Rapport über die Einhaltung der Service Levels.

6. Support und Change Requests

6.1. Change Request Management

Ein Change Request behandelt jede Art von Änderung an einer IT-Infrastruktur oder eines IT-Services, die nicht im ursprünglichen Setup definiert wurde. Benötigt der Kunde Anpassungen bestehender Funktionen und/oder des Systems werden diese im Rahmen der vereinbarten Konditionen zur Ausführung entgegengenommen. Bei einem Change Request wird dem Kunden der voraussichtliche Zeitbedarf für die Umsetzung vorab mitgeteilt und die voraussichtlich zu verrechnenden Arbeitsstunden in einem formalen Angebot dem Kunden zur Genehmigung und Beauftragung vorgelegt. Ein Change Request muss über control.vshn.net erteilt werden.

Change Request Annahme und Priorisierung

Der Kunde kann einen Change Request per Ticket über control.vshn.net übermitteln und mit Severity Level priorisieren.

Change Request Antwort

VSHN beantwortet Change Requests in der Regel innerhalb von 10 Arbeitstagen und priorisiert die Change Requests gemäss dem Severity Level des Kunden. Die Antwort enthält:

  • Übersicht der Machbarkeit und des Nutzens des Change Requests;

  • Geschätzter Aufwand und Kosten für die Umsetzung;

  • Gegebenenfalls Rückfragen und weitere Schritte zu deren Klärung.

Der Kunde kann basierend auf der Antwort den Change Request annehmen oder ablehnen.

6.2. Support Request Management

Ein Support Request steht für generelle Support-Anfrage wie Informationen zu Aufbau/Setup/Design der Infrastruktur und Services, Verbesserungsmöglichkeiten, Consulting & Schulungen etc. und kann während der Verfügbarkeitszeiten des Supports per control.vshn.net oder Telefon übermittelt werden. VSHN beantwortet Support Requests in der Regel innerhalb von 10 Arbeitstagen.

7. Services

Die genauen Inhalte eines Service sind in der allgemeinen oder produktspezifischen Servicebeschreibung definiert.

7.1. Service-Verfügbarkeit

Die Verfügbarkeit von spezifischen Services von VSHN ist im Regelfall in der entsprechenden Leistungsbeschreibung geregelt. Soweit nichts geregelt ist, gilt bei fortlaufend zur Verfügung gestellten Services, bei denen eine Verfügbarkeit relevant und messbar ist, eine Verfügbarkeit von 99% pro Monat.

Ein Service gilt als verfügbar, wenn er von VSHN erreicht werden kann. Die Verfügbarkeit berechnet sich auf Basis eines 24/7 Betriebs. Bei der Berechnung der effektiven Verfügbarkeit werden Ausfälle von unter 5 Minuten und aufgrund folgender Ausnahmen nicht berücksichtigt:

  • Verfügbarkeit der Infrastruktur und der Services von Drittanbietern und des Kunden (inkl. Cloud und Netzwerk Provider)

  • Eine vom Kunden beauftragte oder von ihm selbst vorgenommene und nicht durch den Anbieter genehmigte Änderung, die zum Ausfall des Service führt.

  • Zeiträume, in denen vorher angekündigte Wartungsarbeiten durchgeführt werden.

  • Ein Fehler, der nicht auf die durch den Anbieter bereitgestellte Dienstleistung zurückzuführen ist (etwa mangelnde Verfügbarkeit eines Drittanbieters).

  • Ein Fehler, der auf das allgemeine Betriebsrisiko einer Internetanbindung zurückzuführen ist (z.B. Beeinträchtigungen durch DoS-Angriffe, etc.).

  • Veränderungen an durch den Anbieter im Auftrag des Kunden betriebenen Geräten, Anschlüssen, Netzwerkplänen, Applikationen, die nicht vom Anbieter durchgeführt wurden.

  • Der Kunde hat einen Fehler gemeldet, obwohl keiner vorlag.

  • Fehler der Software, sofern sich diese nicht auf die grundlegenden Eigenschaften, die zur Bereitstellung der Dienstleistung notwendig sind, auswirken.

  • Fehler innerhalb der Software, die sich auf einzelne Funktionseigenschaften der Software beziehen, nicht aber die Verfügbarkeit der vertraglich vereinbarten Dienstleistung beeinträchtigen, mindern nicht die Verfügbarkeit und werden nicht als Fehlerkategorie Critical eingestuft

  • Ausfälle, die durch vom Kunden vorgenommene Konfigurationen entstehen.