SLAs, Fristen und Aussetzungen

Auf dieser Seite erläutern wir, wie das ITSM-System metis vertraglich vereinbarte Grenzwerte für Service-Levels umsetzt. Außerdem werden die in diesem Kontext relevanten Begriffe kurz erläutert und abgegrenzt. 

Service-Level-Agreement und Fristen

Im Rahmen von sogenannten Service-Level-Agreements – oft abgekürzt als SLAs – hat Ihr Unternehmen vertragliche Vereinbarungen über die Dienstgüte der zu erbringenden Leistungen getroffen. Dafür werden messbare Kennzahlen aus der Serviceerbringung, die sogenannten Service-Levels, mit passenden Grenzwerten versehen und deren Einhaltung kontinuierlich überwacht.

Üblicherweise gibt es bei der Ticketbearbeitung zwei besonders häufig gewählte Service-Levels:

• Reaktionszeit
• Lösungzeit bzw. Umsetzungszeit

Wie lang diese Zeiten sind, hängt davon ab, welche Relevanz einem System oder einer Dienstleistung vorab im Vertrag zugemessen wird und welche Auswirkungen eine aktuell auftretende Störung auf den Kunden und seine Geschäftsprozesse hat. Sie unterscheiden sich daher typischerweise pro Service und Kunde. Üblicherweise wird auch innerhalb eines Service noch anhand der Priorität einer Störungsmeldung abgestuft, um die Lösungszeit für besonders dringliche Störungen deutlich kürzer zu definieren als für unwesentliche Störungen.

Weitere Service-Levels sind denkbar, z. B. hinsichtlich der Genauigkeit von Aufwandsschätzungen, Performance-Kennzahlen für IT-Services oder auch – ganz klassisch – Mindestverfügbarkeiten für IT-Services.  Diese Service-Levels werden ebenfalls häufig vereinbart, aber in anderen Systemen überwacht. Sie sind daher für das ITSM-System metis nicht unmittelbar relevant. 

Die Reaktionszeit ist die Zeitspanne, die ausgehend von der Meldung des Incidents verstreichen darf, bis der Kunde eine erste Antwort über die voraussichtliche Dauer bis zur Beseitigung des Incidents vom zuständigen Bearbeiter erhält. Sie beschreibt also inhaltich die Zeit vom Bekanntwerden der Störungsmeldung beim Dienstleister bis zur ersten qualifizierten Einschätzung der Bearbeitungsdauer.

Die Lösungszeit beschreibt die Zeitspanne, die bis zur Bereitstellung einer Lösung für einen Incident vergehen darf. Wichtig ist hierbei, dass eine Lösung auch in einem Workaround – also einer Umgehungslösung, die den eigentlichen Fehler nicht behebt, sondern auf anderem Wege zum Ziel führt – bestehen kann. Übertragen auf eine Serviceanforderung spricht man von der Umsetzungszeit, weil dort keine Lösung einer Störung bereitgestellt, sondern eine Anforderung umgesetzt wird; strukturell ist diese Zeit aber identisch. Eine Umsetzungszeit kann allerdings nur für klar abgegrenzte Standard-Anforderungen vereinbart werden. Viele Serviceanforderungen in unserem System sind zu individuell, als dass eine SLA-Vereinbarung zur Bearbeitungsdauer möglich wäre.

Diese Zeiten beschreiben jeweils die vertraglich vereinbarte Dauer. Für ein konkretes Ticket ermittelt das ITSM-System daher auf dieser Basis entsprechende Fristen. Inhaltlich geht es dabei um dasselbe, die Unterscheidung ist nur, ob man von der Dauer (z. B. der Lösungszeit) oder dem konkreten Zeitpunkt (z. B. der Lösungsfrist) spricht.

Abbildung von SLAs im ITSM-System metis

SLAs und darin definierte Reaktions-, Lösungs- und Umsetzungszeiten werden den im items-Serviceportal hinterlegten Services, Servicemodulen und Anliegen des Kunden zugeordnet. Wenn nun eine neue Anfrage erstellt wird, wird der passende SLA inklusive der dazugehörigen Zeiten über die getätigte Auswahl von Service, Servicemodul und Anliegen herangezogen.

Bei Incidents beeinflusst zusätzlich die Priorisierung des akuten Störungsfalls, wie die SLA-Zeiten genau ausfallen, sodass z. B. Reaktion und Lösung für einen „hoch“ priorisierten Incident deutlicher schneller erfolgen müssen als für einen „niedrig“ priorisierten. Bei der Erfassung eines neuen Incidents haben Sie die Möglichkeit, eine Priorität für diesen vorzuschlagen. Die für die SLA-Zeiten wirksame Priorität wir aber durch den zuständigen Bearbeiter festgelegt. Hierbei ist das Vorgehen dasselbe wie bei Ihrem Vorschlag und basiert auf einer Matrix aus Auswirkung und Dringlichkeit der Störung:

Die Dimension Auswirkung gibt an, wie viele Anwender von einer Störung betroffen sind bzw. wie kritisch eine Störung für den Geschäftsablauf des Kunden ist. Die beiden Teilaspekte (betroffene Anwender und Kritikalität) sind dabei unabhängig voneinander, und es wird bei der Einstufung einer Störung der jeweils schwerwiegendere Auswirkungsgrad zugrunde gelegt.

• Unternehmensweit / geschäftskritisch: Die Störung hat sehr negative Auswirkungen auf das gesamte Unternehmen bzw. die Geschäftstätigkeit des Kunden.
• Abteilungsweit / bedingt geschäftskritisch: Die Störung hat negative Auswirkungen auf einzelne Geschäftsprozesse bzw. Unternehmensbereiche oder Abteilungen des Kunden.
• Arbeitsplatzbezogen / nicht geschäftskritisch: Die Störung hat negative Auswirkungen auf einzelne Arbeitsplätze oder Mitarbeiter des Kunden.

Die Dringlichkeit beschreibt, wie stark die betroffenen Personen in ihrer Arbeit eingeschränkt sind. Diese zweite Dimension gibt also an, wie schnell die Störung unter Berücksichtigung fachlicher Aspekte zu beheben ist.

• Arbeiten nicht möglich: Die Störung blockiert normale Geschäftsabläufe, da eine Weiterarbeit (auch unter Zuhilfenahme alternativer Ressourcen o. Ä.) für die betroffene(n) Person(en) nicht möglich ist.
• Eingeschränktes Arbeiten möglich: Die Störung behindert normale Geschäftsabläufe, eine Weiterarbeit (z. B. ein Arbeiten in anderen Modulen oder Anwendungen oder ein Ausweichen auf alternative Ressourcen) ist für die betroffene(n) Person(en) aber möglich.
• Weiterarbeit möglich: Die Störung beeinflusst zwar die Nutzung der items-Services durch die betroffenen Person(en), die Geschäftsabläufe des Kunden werden aber nicht behindert.

Aus der Kombination der beiden Dimensionen ergibt sich eine von fünf Prioritätsstufen. Die Beurteilung erfolgt durch items auf Basis der vom Kunden bereitgestellten Informationen. In Abstimmung zwischen dem Kunden und dem zuständigen Key-Account-Manager von items kann in Ausnahmefällen eine Störung abweichend priorisiert werden.

Direkt nach Erfassung einer Störungsmeldung im Serviceportal steht meistens die Priorität noch nicht fest. Daher unterstellt das System eine Default-Priorität, die für ca. 80% der Störungsmeldungen angemessen ist.

In einem Ticket werden die SLA-Zeiten im Normalfall als Fristen - also als Zeitpunkte mit Datum und Uhrzeit - dargestellt. Die Fristen werden berechnet, indem die vereinbarten SLA-Zeiten zum Zeitpunkt der Erstellung des Tickets hinzuaddiert werden. Bis zu diesen Fristen hat der zuständige Bearbeiter Zeit, auf die Anfrage zu reagieren und diese zu lösen.

Bitte beachten Sie, dass anfänglich mitgeteilte SLA-Fristen sich nochmal verändern können, falls die Auswahl von Service, Servicemodul oder Anliegen inhaltlich für Ihre Anfrage falsch war oder die Priorität durch den zuständigen Bearbeiter verändert wird.

Falls für Ihren Störungsfall ein SLA und dazugehörige Zeiten zugeordnet sind, erhalten Sie direkt nach dem Speichern des Tickets im items-Serviceportal eine Mitteilung zu den Fristen für die Reaktion und Lösung. Zudem werden der Name des SLAs und die Fristen auch im Informationsbereich des Tickets angezeigt.

Es ist auch möglich, dass nur eine Reaktions- oder Lösungszeit im betroffenen SLA definiert sind. Dies wird ebenfalls im Informationsbereich dargestellt.

Falls eine Anfrage durch eine andere Person für Sie aufgenommen wurde, erhalten Sie eine E-Mail zu dem neu erstellten Ticket, in welcher Sie ebenfalls darüber informiert werden, ob und welche SLA-Zeiten für Ihre Anfrage vorliegen.

Ob die Reaktions- und Lösungsfristen im weiteren Bearbeitungsverlauf eingehalten wurden, wird im Bereich SLA-Informationen farblich grün oder rot akzentuiert dargestellt. 

            

Die Entscheidung, ob die SLA-Fristen eingehalten wurden, und die entsprechende farbliche Akzentuierung geschehen erst, wenn der zuständige Bearbeiter die Reaktion bzw. Lösung für das Ticket durchführt (also das voraussichtliche Wiederherstellungsdatum mitteilt bzw. das Ticket löst). Somit kann es auch vorkommen, dass bei einer bereits erreichten SLA-Frist noch keine Entscheidung zur Einhaltung angezeigt wird.

Aussetzung der Bearbeitung

Bestimmte Ereignisse im Ticket-Workflow haben zur Folge, dass das Ticket ausgesetzt und die „SLA-Uhr“ währenddessen angehalten wird. Die Fristen werden also entsprechend der Dauer der Aussetzung nach hinten verschoben.  Für eine solche Aussetzung können unterschiedliche Gründe vorliegen:

• Warten auf Kunden-Feedback: Es wird auf eine angeforderte Rückmeldung vom Kunden gewartet, weil noch wichtige Informationen fehlen oder konkretisiert werden müssen.
• Warten auf Third-Party: Es wird auf eine dritte Partei (die nicht Bestandteil der SLA-Vereinbarungen ist) zur Bearbeitung des Tickets gewartet.
• Warten auf Transport: Es wird auf einen erforderlichen Transport gewartet. 
• Warten auf Kundentest: Innerhalb einer Anfrage wurde für den Kunden ein Test vorbereitet und es wird auf die Ergebnismeldung des Kunden dazu gewartet.
• Warten auf Kundengenehmigung: Es wird auf eine Genehmigung des Kunden zur Bearbeitung einer Anfrage gewartet.
• Abnahme nicht erteilt: Wenn eine Anfrage nach Fertigstellung durch den zuständigen Bearbeiter vom Kunden nicht abgenommen wird, wird das Ticket ausgesetzt, bis der Bearbeiter dies mitbekommt. 

Die Aussetzung an sich und der genaue Aussetzungsgrund werden ebenfalls im Informationsbereich rechts im Ticket dargestellt. Die Aussetzung hat auch Einfluss auf die Anzeige der SLA-Informationen: Es werden nun keine Fristen mehr angezeigt, sondern die noch verbleibenden Zeiten, aus denen sich dann bei Wiederaufnahme des Tickets neue Fristen berechnen, die die Aussetzungsdauer beachten.

Ob ein Ticket ausgesetzt ist, können Sie auch auf der Startseite in der Tabelle Meine offenen Tickets einsehen, wenn in der Spalte Aussetzungsgrund ein Eintrag vorhanden ist.