Es ist an der Zeit, dass wir uns unterhalten... ein Gespräch über Time to Resolve und MTTR! Time to Resolve ist eine Metrik, die es schon so lange gibt, wie ich mich erinnern kann. Die Lösungszeit (oder MTTR) ist zwar nicht neu, aber es ist an der Zeit, dass wir sie uns genauer ansehen und herausfinden, was Lösungszeit wirklich bedeutet.
Warum jetzt? Weil die Zeit bis zur Problemlösung wichtig ist... sehr wichtig! Und die Lösungszeit ist im Grunde ein Indikator für Benutzerfreundlichkeit und Benutzererfahrung. Außerdem ist sie eine der Kennzahlen, die häufig missverstanden und falsch interpretiert wird. Also, nichts wie ran an den Speck!
In diesem Leitfaden "Zeit zum Lösen
Was bedeutet "Zeit zum Auflösen"?
Was meinen Sie mit "Zeit zur Lösung"?
Time To Resolve (MTTR) gibt an, wie lange es durchschnittlich dauert, bis ein Fall oder Vorfall mit demselben Symptom während eines Ausfalls oder Problemlösungsszenarios gelöst ist:
Time To Resolve = Zeit von der Störung bis zur Behebung während des Ausfalls
Im Wesentlichen ist die Zeit bis zur Problemlösung ein Indikator, der uns sagt, wie lange die Nutzer auf einen bestimmten Fehler warten. Dabei spielt es keine Rolle, ob es sich um dasselbe oder ein anderes Problem handelt, sondern vielmehr, ob sie schon einmal auf ein ähnliches Problem gestoßen sind und wie lange sie brauchen, um eine Lösung zu finden und wieder zum Laufen zu kommen.
MTTD und MTTR: Was ist der Unterschied?
MTTD und MTTR sind aus dem gleichen Holz geschnitzt. Aber sie sind nicht dasselbe! MTTR gibt die Zeit an, die benötigt wird, um ein System wieder zum Laufen zu bringen, während MTTD die Zeit angibt, die vom Auftreten eines Vorfalls bis zu dessen Behebung vergeht. Der Einfachheit halber werden wir uns in diesem Beitrag auf die Zeit bis zur Lösung des Problems konzentrieren, aber ich möchte, dass Sie sich des kleinen Unterschieds zwischen MTTD und MTTR bewusst sind.
MTTD bezieht sich auf die Zeit vom Vorfall bis zum Zeitpunkt der Lösung.
MTTR bezieht sich auf die Zeit vom Vorfall bis zum Zeitpunkt der Lösung.
Beispiel: Zeitpunkt des Vorfalls (TOI) und Zeitpunkt der Lösung (TOR)
Es ist hilfreich, sich die MTTR wie folgt vorzustellen: Das Problem tritt zum Zeitpunkt X auf, Benutzer A braucht im Durchschnitt Y Zeit, um eine Lösung zu finden, und zum Zeitpunkt Z ist das Problem gelöst.
Denken Sie auch daran, dass MTTD die Zeit vom Auftreten eines Vorfalls bis zu seiner Lösung bedeutet, während MTTR die Zeit vom Auftreten des Problems bis zur Lösung des Problems bedeutet. Das mag trivial erscheinen, aber ich denke, dass wir alle mehr als einmal in diese Verwirrung geraten sind, also wollte ich sicherstellen, dass wir uns kristallklar sind.
Wann sollte ich die Zeit bis zur Lösung messen?
Time To Resolve" liefert uns hervorragende Daten, wenn wir die Zufriedenheit der Nutzer bei wiederkehrenden Fehlern - also solchen mit ähnlichen Symptomen - verstehen müssen. Zum Beispiel:
- Warum war meine Website wieder nicht erreichbar? Das ist erst letzte Woche passiert! Ich kann nicht glauben, dass ihr nicht verhindern könnt, dass so etwas immer wieder passiert...
- Nach der Aktualisierung meines Browsers erhalte ich immer wieder diese Meldung. Könnten Sie bitte jemanden bitten, einen Blick darauf zu werfen?
- Die von Ihnen übermittelten Anweisungen waren nicht eindeutig. Kann jemand noch einmal einen Blick auf sie werfen?
Wenn die Zeit bis zur Behebung des Problems etwas ist, das Sie messen können (und die Zeit bis zur Behebung des Problems ist für jeden möglich), dann hilft Ihnen die Zeit bis zur Behebung des Problems dabei, die Zeit zu verstehen, die Ihre Benutzer benötigen, um nach einem Ausfall wieder zum Laufen zu kommen. Wie lange haben die Benutzer gebraucht, bis sie nach dem Problem wieder arbeiten konnten?
Schließlich ist "Zeit" Geld! Sehen wir uns also an, wie wir sicherstellen können, dass die Zeit zur Lösung immer zur Verfügung steht ...
Mit der Zeitspanne bis zur Problemlösung können wir die Zeit berechnen, die Ihre Benutzer auf die Lösung eines Problems warten. Diese Daten können wir dann im Laufe der Zeit und zwischen verschiedenen Teams vergleichen. Es gibt mehrere andere wichtige Leistungsindikatoren (KPIs), die verwendet werden, um festzustellen, ob es in diesem Bereich Probleme gibt - die Zeit bis zur Lösung ist einer davon!
Wie kann ich die Zeit bis zur Lösung messen?
Zunächst einmal muss die Zeit bis zur Lösung gemessen werden, damit sie verwendet werden kann. Die Zeit bis zur Lösung kann auf drei Arten gemessen werden: (1) Zeit vom Vorfall bis zur Lösung, (2) Zeit während des Ausfalls, (3) Zeit vom Vorfall bis zur Schließung. Jede Methode hat ihre Vor- und Nachteile, und auch die Art und Weise, wie sie gemeldet wird, sollte bei der Auswahl einer Methode für Ihr Team berücksichtigt werden. Schauen wir uns diese drei unten an.
1.) Zeit vom Vorfall bis zur Lösung: Dies ist eine großartige Kennzahl für Teams, die schnell reagieren wollen, weil sie nach einem Ausfall schnell Daten abrufen können. Ein Nachteil ist, dass Sie einige historische Daten verlieren, wenn etwas noch nicht innerhalb von 72 Stunden behoben wurde (was früher als gute Praxis galt), aber dies führt zu einer Beschleunigung über längere Zeiträume, was bei der Zeit bis zur Meldung helfen könnte. Die Zeit bis zur Lösung des Problems während des Ausfalls ist eine unserer beliebtesten Zeitangaben für die Lösung von Problemen!
2.) Zeit von der Störung bis zum Zeitpunkt der Schließung: Hier sehen Sie ein Beispiel für die Zeit von der Störung bis zur Schließung, bei dem 100 Minuten zwischen dem Beginn des Problems und der Wiederherstellung des Betriebs durch den Benutzer in diesem speziellen Ticket liegen. Diese Methode dauert zwar länger als das Abrufen von Daten direkt nach einem Ausfall, aber sie liefert uns viel mehr historische Daten über einen längeren Zeitraum. Diese Daten können teamübergreifend analysiert werden, um genau herauszufinden, was am längsten dauert (und warum).
3.) Zeit von der Problemerkennung bis zum Abschluss: Hier ist ein weiteres Beispiel für die Zeit von der Problemerkennung bis zum Abschluss. Dieses Mal sehen Sie, dass es 50 Minuten gedauert hat, bis das Problem gelöst war, und es ist auch klar, dass dieses Mal Daten von mehreren Tagen und nicht nur von einem Tag herangezogen werden. Denken Sie daran, dass dies schwieriger ist als die anderen Methoden, da Probleme in der Regel aktualisiert werden, während sie Ihren Workflow durchlaufen. Denken Sie also daran, dass zwischen den Aktualisierungen mindestens 24 Stunden liegen müssen, bevor wir Daten über die Zeit bis zur Lösung erfassen können.
Normalerweise fällt die Zeit bis zur Auflösung (Messung) in eine dieser drei Kategorien:
- während der Ausfallzeit (die erfassten Daten beinhalten die Ausfallzeit und die Zeit, die das Personal zur Behebung des Problems benötigt)
- nach der Ausfallzeit (Tage oder Wochen nach der Datenerfassung)
- Zeit in der Warteschlange (Startzeit im System bis zum Zeitpunkt der Schließung im System).
Ihre Benutzer warten, was nun?
Hier wird es knifflig: die Zeit bis zur Auflösung! Denken Sie daran, dass "Zeit" Geld ist. Deshalb ist es wichtig, dass Sie sich die Zeit nehmen, um die Daten aufzulösen und sie in etwas Nützliches zu verwandeln. Einige Fragen für Sie könnten sein:
- Wie groß ist dieses Problem wirklich?
- Wie sieht dieses Problem im Laufe der Zeit aus? Erkennen Sie irgendwelche Trends?
- Verbessert oder verschlechtert sich mein Team bei der schnellen Lösung von Problemen?
Es kann schwierig sein, die Daten zur Lösungszeit in etwas Nützliches umzuwandeln - manchmal haben Teams so viele Informationen, aber sie wissen, dass sie ohne Daten zur Lösungszeit keine Änderungen vornehmen können. Durch die Erhebung von Daten über die Zeit bis zur Problemlösung können Sie sich nicht nur mit Ihren Branchenkollegen vergleichen, sondern auch sehen, wie effizient Ihre Zeit in diesem Bereich genutzt wird!
Tipps zur Verringerung der Zeit bis zur Lösung und der MTTR
Sie wissen also, was die Zeit bis zur Auflösung ist, wie man sie misst und verfolgt. Jetzt wollen Sie diese wichtige Kennzahl verringern. Hier sind unsere besten Tipps!
- Scheuen Sie sich nicht, etwas aufzugeben, das zwar zeitaufwendig, aber unwichtig ist. Wenn Sie Ihre Zeit mit vielen Dingen verbringen, die einfach nur Zeit kosten, aber keinen Mehrwert bringen, ist es vielleicht an der Zeit, diese Aktivitäten zu überdenken.
- Verwenden Sie eine Beobachtungsplattform oder ein Störungsmanagementsystem wie Pagerduty oder andere Alternativen, bei denen es weniger Raum für Fehler gibt als bei E-Mails oder Tabellenkalkulationen, wenn Sie diese Art der Störungserfassung derzeit nutzen. E-Mails können verloren gehen oder vergessen werden, Tabellenkalkulationen werden unübersichtlich und verwirrend, und letztendlich vergeht die Zeit immer schneller, wenn Sie hin- und hergehen, um Probleme zu lösen.
- Setzen Sie immer Prioritäten - beginnen Sie mit den wichtigsten Aufgaben, da diese die meiste Zeit in Anspruch nehmen, und ordnen Sie dann die Zeit, die für die Erledigung einer Aufgabe benötigt wird, nach Prioritäten, um Zeit zu sparen.
- Weitere Möglichkeiten, die Zeit bis zur Problemlösung zu verkürzen, sind: ein klarer Prozess, der einfach zu befolgen ist, die Sicherstellung, dass Ihr Team auf allen Ebenen angemessen geschult ist, und die ständige Kenntnis der Tickets in der Warteschlange - so wissen Sie genau, wie viele Benutzer auf Sie warten!
Abschließende Überlegungen zu Zeit bis zur Auflösung und MTTR
Die Zeit bis zur Lösung ist ein guter Indikator für die Qualität der IT-Arbeit. Sie wird als Indikator dafür verwendet, dass Probleme korrekt und unter Berücksichtigung des Zeitmanagements gelöst werden. Eine effiziente Zeit bis zur Lösung bedeutet, dass Probleme schnell genug gelöst werden, damit sich die Teams mit ihnen befassen können, aber nicht so schnell, dass man sie als "Brandbekämpfung" betrachtet, anstatt sich wirklich mit der Ursachenanalyse des Problems zu befassen. Ein guter KPI für die Zeit bis zur Problemlösung hilft den Teams bei der Beantwortung von Fragen zum Kundenservice, zur Effizienz und zur für Aufgaben aufgewendeten Zeit. Es ist also wichtig, sich nicht nur auf die Zeit bis zur Problemlösung zu konzentrieren, sondern auch zu verstehen, was sie für Ihr Team bedeutet!
