Service Management
Priorität ist keine Meinungsfrage: Impact, Dringlichkeit und die SLA-Uhr
Warum wir die Priorität eines Incidents aus einer Matrix berechnen statt sie diskutieren zu lassen, wie die SLA-Fristen in Geschäftszeiten entstehen und wann die Uhr stehen bleiben darf.
Jeder Service Desk kennt den Satz „Das ist aber wirklich dringend.“ Er wird am Telefon gesagt, in Tickets geschrieben und gelegentlich vom Chef persönlich vorbeigebracht. Das Problem ist nicht, dass er falsch wäre. Das Problem ist, dass er nicht vergleichbar ist. Wenn drei Anrufer „wirklich dringend“ sagen, muss trotzdem jemand entscheiden, wer zuerst drankommt.
Deshalb rechnet OpsCloud365 die Priorität aus, statt sie zu erfragen.
Zwei Fragen statt einer Meinung
Beim Anlegen eines Incidents beantwortet der Agent zwei Fragen: Wie groß ist die Auswirkung, also wie viele Personen oder welche Services sind betroffen? Und wie dringend ist die Behebung, also wie lange kann die Situation so bleiben? Aus beiden Antworten ergibt sich über die Prioritätsmatrix die Priorität P1 bis P4.
Der Trick ist nicht die Matrix selbst, die kennt jedes ITIL-Buch. Der Trick ist, dass die Diskussion an eine andere Stelle wandert. Man streitet nicht mehr über „P1 oder P2“, sondern über „betrifft das den ganzen Standort oder eine Person“. Diese Frage kann man beantworten. Und wenn die Matrix nicht zu Ihrer Organisation passt, ändern Sie die Matrix, nicht die Antworten.
Die Uhr läuft in Geschäftszeiten
Aus der Priorität folgen die Fristen. Jeder Service in OpsCloud365 kann ein eigenes SLA haben; Incidents ohne Service-SLA nutzen das Standard-SLA. Ein SLA definiert je Priorität eine Reaktions- und eine Lösungszeit in Minuten, und ob diese Zeiten nur innerhalb der Geschäftszeiten laufen. Ein P3 mit acht Stunden Lösungszeit, gemeldet am Freitag um 16 Uhr, ist bei Geschäftszeiten bis 17 Uhr am Montag um 16 Uhr fällig, nicht am Samstagmorgen.
Das Incident zeigt beide Fristen in einem eigenen Panel: Reaktion bis, reagiert am, Lösung bis, gelöst am, dazu ein Balken, wie viel der Lösungszeit schon verbraucht ist. Wer die Liste nach „SLA verletzt“ filtert, sieht sofort, wo es brennt. Ein Hintergrundjob aktualisiert die Verletzungskennzeichen alle 15 Minuten, damit die Anzeige nicht davon abhängt, ob jemand das Ticket zufällig öffnet.
Wann die Uhr stehen bleiben darf
Es gibt einen legitimen Grund, die Uhr anzuhalten: Wenn die Bearbeitung nicht beim Service Desk liegt. Der Melder hat noch nicht geantwortet, ein Ersatzteil ist bestellt, ein externer Dienstleister ist dran. Dafür gibt es den Status „Wartend“. Er verlangt einen Grund und pausiert die SLA-Uhr. Die Zeit im Wartezustand wird am Incident in Minuten ausgewiesen.
Was es bewusst nicht gibt: das stillschweigende Zurücksetzen der Frist. Ein Incident, der wiedereröffnet wird, bekommt einen Zähler, keinen neuen Start. Wenn ein Ticket dreimal wiedereröffnet wurde, ist das eine Information, keine Statistik-Kosmetik.
Major Incidents: laut sein, wenn es nötig ist
Manchmal ist ein P1 mehr als ein P1. Wenn das ERP-System für alle Standorte steht, hilft es niemandem, wenn hundert Personen einzeln anrufen. Deshalb kann ein P1 als Major Incident gekennzeichnet werden. Er erscheint dann im Self-Service-Portal als aktuelle Störung, mit Beginn und betroffenem Service.
Was am Ende zählt
Am Ende einer Woche interessiert nicht das einzelne Ticket, sondern das Muster. Das ITSM-Dashboard zeigt Incidents nach Status, offene Incidents nach Priorität und Gruppe, das Aufkommen pro Woche und die Liste der SLA-Verletzungen. Wer dort jede Woche dieselbe Gruppe bei P2 sieht, weiß, wo ein Gespräch fällig ist.
Ein letzter Gedanke: Das alles ersetzt kein Urteilsvermögen. Ein erfahrener Agent erkennt, wenn eine Matrix im Einzelfall danebenliegt, und darf die Priorität ändern. Aber er tut es sichtbar, mit Historie, und nicht, weil jemand lauter war als die anderen.
Alle Abbildungen zeigen die tatsächliche Anwendung mit fiktiven Demodaten.