Die Mean Time to Recovery (MTTR) ist die meistzitierte Kennzahl im Incident Management und zugleich die am schlechtesten definierte. Wer sie senken will, braucht zuerst eine klare Uhr: Wann startet die Messung, wann endet sie, und welches \u201eR“ ist gemeint. Erst dann l\u00e4sst sich beantworten, wo im Incident-Prozess die Zeit tats\u00e4chlich verloren geht. In den meisten IT-Organisationen ist das weder das Erkennen noch das Beheben, sondern der Schritt dazwischen.<\/p>\n\n\n\n
MTTR berechnet sich als Summe der Wiederherstellungszeit aller Incidents in einem Zeitraum, geteilt durch die Anzahl dieser Incidents. Die Formel ist einfach. Schwierig ist das K\u00fcrzel, denn das \u201eR“ wird in der Praxis unterschiedlich gelesen:<\/p>\n\n\n\n
Zwei Teams k\u00f6nnen denselben Incident mit derselben Formel messen und zu verschiedenen Werten kommen, weil ihre Uhren an unterschiedlichen Punkten starten und stoppen. MTTR ist erst dann eine Kennzahl, wenn Startpunkt, Endpunkt und Bezugsmenge festgelegt sind.<\/p>\n\n\n\n
Wie folgenreich diese Unsch\u00e4rfe ist, zeigt das DevOps-Forschungsprogramm DORA, das MTTR seit 2014 als eine von vier Kennzahlen der Software-Delivery-Performance erhebt. 2023 wurde die Kennzahl in \u201efailed deployment recovery time“ umbenannt und enger gefasst, weil die alte Definition St\u00f6rungen aus Produktions\u00e4nderungen nicht von externen Ausf\u00e4llen unterschied. Die Lehre gilt \u00fcber den Software-Delivery-Kontext hinaus: Eine Kennzahl, die ungleiche Dinge zusammenz\u00e4hlt, l\u00e4sst sich nicht steuern.<\/p>\n\n\n\n
Ein Mittelwert verbirgt, was ihn treibt. Ein einzelner langer Ausfall verschiebt die MTTR eines Monats st\u00e4rker als ein Dutzend schneller Wiederherstellungen sie senken; umgekehrt verbessert das z\u00fcgige Schlie\u00dfen vieler kleiner Incidents den Mittelwert, ohne dass sich an den kritischen Ausf\u00e4llen etwas \u00e4ndert. ITIL 4 verlangt deshalb, Kennzahlen nach Incident-Typ, Service, Team oder Zeitraum zu segmentieren, und stellt fest, dass es keine einzige beste L\u00f6sung gibt.<\/p>\n\n\n\n
Die zweite Verzerrung ist der Workaround. ITIL 4 definiert ihn als L\u00f6sung, die die Auswirkung eines Incidents reduziert oder beseitigt, obwohl keine vollst\u00e4ndige L\u00f6sung vorliegt. Workarounds stellen den Service schnell wieder her, k\u00f6nnen aber technische Schulden erh\u00f6hen und zu neuen Incidents f\u00fchren. Ein Team kann seine MTTR also senken, indem es Symptome schneller \u00fcberbr\u00fcckt, und denselben Incident wenige Wochen sp\u00e4ter erneut bearbeiten. Ohne Wiederkehrrate neben der MTTR bleibt dieser Effekt unsichtbar. Kepner-Tregoe beschreibt diesen Mechanismus im Whitepaper \u201eAm Limit und doch alles im Griff“<\/u><\/a> so: Durchschnittsbasiertes Reporting verbirgt die extremen Tickets, die Ressourcen verschlingen, und belohnt die Haltung \u201eerst flicken, sp\u00e4ter Probleme l\u00f6sen“. Der zugeh\u00f6rige Fallstrick hei\u00dft dort \u201eAbschluss vor der Best\u00e4tigung“: Die MTTR-Metrik erzwingt das Schlie\u00dfen, bevor die L\u00f6sung dem Kunden gegen\u00fcber nachgewiesen ist.<\/p>\n\n\n\n Drittens ist \u201egel\u00f6st“ im Incident Management nicht dasselbe wie \u201everstanden“. ITIL 4 verortet die Untersuchung von Incident-Ursachen ausdr\u00fccklich im Problem Management, nicht im Incident Management. Die MTTR endet mit der Wiederherstellung. Ob die Ursache bekannt ist, sagt sie nicht.<\/p>\n\n\n\n ITIL 4 ordnet Kennzahlen des Incident Managements deshalb drei Practice Success Factors zu: Incidents fr\u00fch erkennen, Incidents schnell und effizient l\u00f6sen, die Ans\u00e4tze kontinuierlich verbessern. Erst in diesem Rahmen taugen sie als KPIs. Eine MTTR ohne Bezug zu einem Erfolgsfaktor ist eine Zahl, kein Steuerungsinstrument.<\/p>\n\n\n\n ITIL 4 beschreibt die Bearbeitung eines Incidents in sechs Aktivit\u00e4ten: Erkennung, Registrierung, Klassifizierung, Diagnose, L\u00f6sung und Abschluss. Die Diagnose beginnt dort, wo die Klassifizierung keine bekannte L\u00f6sung liefert, und ist der Schritt, in dem Incidents zwischen Teams eskaliert oder gemeinsam per Swarming bearbeitet werden.<\/p>\n\n\n\n Erkennung und Registrierung lassen sich weitgehend automatisieren, und die L\u00f6sung selbst ist oft schnell, sobald klar ist, was zu tun ist. Die Zeit dazwischen ist die Diagnosephase. Sie ist der gr\u00f6\u00dfte Zeitblock im Incident und zugleich der am seltensten gemessene.<\/p>\n\n\n\n ITIL 4 benennt daf\u00fcr drei wiederkehrende Muster: Incidents werden zwischen Teams hin- und hergeschoben, Teammitglieder f\u00fchlen sich blockiert, und eine Kultur belohnt einzelne \u201eHelden“. Die Folge sind L\u00f6sungen, die langsam kommen oder ausbleiben.<\/p>\n\n\n\n Die Datenspur best\u00e4tigt das Muster. Bei einer Diagnose des Incident Managements eines globalen Fintech-Konzerns analysierte Kepner-Tregoe per Process Mining \u00fcber 80.000 Tickets und auditierte mehr als 100 Incidents. Das Mining zeigte eine Vielzahl von Nachbearbeitungsschleifen, Ticket-Neuzuweisungen und prozessinternen Verz\u00f6gerungen. Abgeleitet wurde daraus der Bedarf an besserer Befragung zu Beginn und an einer Situationsbewertung, damit Tickets von vornherein richtig zugewiesen werden.<\/p>\n\n\n\n ITIL 4 macht den Zusammenhang explizit: Die Qualit\u00e4t der Incident-Daten von den ersten Schritten an beeinflusst die Richtigkeit der Entscheidungen, die Geschwindigkeit der Wiederherstellung, den Ressourceneinsatz und die F\u00e4higkeit, die Ursache zu finden. Wer am Anfang ungenau erfasst, verliert die Zeit in jeder Schleife danach.<\/p>\n\n\n\n Ein tragf\u00e4higes KPI-Set koppelt die MTTR mit Kennzahlen, die zeigen, warum<\/em> sie so hoch oder so niedrig ist. ITIL 4 liefert daf\u00fcr eine Auswahl, die weit \u00fcber die Gesamtdauer hinausgeht:<\/p>\n\n\n\n ITIL 4 nennt ausdr\u00fccklich die Balance zwischen Geschwindigkeits- und Wirksamkeitsmetriken als eigene Kennzahl f\u00fcr die kontinuierliche Verbesserung. Genau diese Balance fehlt in Dashboards, die nur MTTR und SLA-Einhaltung zeigen.<\/p>\n\n\n\n Wie Ursachen nach der Wiederherstellung dauerhaft beseitigt werden, beschreibt unsere Seite zur Beratung Problem Management<\/u><\/a>.<\/p>\n\n\n\n Die Diagnosephase l\u00e4sst sich nicht vollst\u00e4ndig automatisieren, aber strukturieren. Die Methodik von Kepner-Tregoe, PSDM (Problem Solving & Decision Making)<\/u><\/a>, stellt daf\u00fcr rationale Prozesse bereit, von denen drei im Incident direkt greifen. F\u00fcr den Incident-Kontext b\u00fcndelt sie der Workshop Major Incident Management<\/a>, ein Derivat von PSDM.<\/p>\n\n\n\n Situationsanalyse: Erst ordnen, dann l\u00f6sen.<\/strong> Ein Major Incident ist selten ein einzelnes Anliegen. Die Situationsanalyse kl\u00e4rt die Lage, bewertet jedes Anliegen nach gegenw\u00e4rtigen Auswirkungen, zuk\u00fcnftigen Auswirkungen und Zeitrahmen und legt fest, welcher Analyseprozess und welche Beteiligten n\u00f6tig sind. Die Frage \u201eWer muss hier dran?“ wird einmal zu Beginn beantwortet, nicht in jeder Eskalationsstufe neu.<\/p>\n\n\n\n Problemanalyse: Beschreiben, bevor erkl\u00e4rt wird.<\/strong> Die Problemanalyse benennt Objekt und Abweichung und spezifiziert dann, was der Fall IST und was er gerade NICHT IST: Welche Systeme sind betroffen, welche vergleichbaren nicht? Wo tritt die Abweichung auf, wo nicht? Seit wann, und wann lief es zuletzt normal? Der ITIL-4-Incident-Record folgt derselben Logik: Zeitpunkt der letzten normalen Funktion und vergleichbare, nicht betroffene Objekte sind dort ausdr\u00fccklich vorgesehen. Aus dem Vergleich von IST und IST-NICHT entstehen Hypothesen, die gegen die Spezifikation getestet werden, bevor jemand einen Neustart ausl\u00f6st. Reicht ein Workaround, ist zumindest belegt, warum er greifen sollte.<\/p>\n\n\n\n Entscheidungsanalyse: Die Restore-Option mit vertretbarem Risiko w\u00e4hlen.<\/strong> Stehen mehrere Wege zur Wiederherstellung zur Wahl, macht die Entscheidungsanalyse die Kriterien explizit: Was muss die Option erf\u00fcllen (MUSS-Ziele), was w\u00e4re w\u00fcnschenswert (WUNSCH-Ziele), welche Risiken birgt die bevorzugte Alternative? Ein Rollback, der die St\u00f6rung behebt und dabei einen anderen Service beeintr\u00e4chtigt, ist keine Wiederherstellung.<\/p>\n\n\n\n Der Workshop Major Incident Management zielt darauf, die Zeit in der Phase \u201eAnalyse und Diagnose“ bei gr\u00f6\u00dferen Ausf\u00e4llen zu reduzieren und im Team eine gemeinsame, technologieunabh\u00e4ngige Probleml\u00f6sungssprache zu etablieren. Im Bridge-Call ist das der entscheidende Punkt: Wenn alle Beteiligten dieselben Fragen stellen, entf\u00e4llt die Abstimmung, die sonst als Wartezeit in der MTTR landet.<\/p>\n\n\n\n Ein globaler Technologiekonzern wollte die L\u00fccken in seinem Prozess f\u00fcr High-Severity-Incidents schlie\u00dfen. Die Ausgangslage war typisch: komplexere Incidents mit h\u00f6herem Ausfallrisiko, geografisch verteilte Fachexperten mit hohem Koordinationsaufwand, kein konsistenter Ansatz, uneinheitliche Datenerhebung, die das sp\u00e4tere Problem Management schw\u00e4chte, und gef\u00e4hrdete SLAs. Zielmetriken waren Time-to-Restore, deren Streuung und die Vermeidung von Incidents der h\u00f6chsten Stufe.<\/p>\n\n\n\n In einem viermonatigen Pilot mit Kepner-Tregoe wurde zun\u00e4chst eine Baseline der Incident-Management-Funktion erhoben, anschlie\u00dfend der Prozess in Reihenfolge und Ausf\u00fchrung der Schritte gestrafft. Ergebnis: eine Reduktion der Mean-Time-to-Restore um 74 Prozent und der Streuung um 77 Prozent, bei h\u00f6herem Anteil vermiedener Incidents der h\u00f6chsten Stufe. Die vollst\u00e4ndige Fallstudie zur Incident-Management-Performance<\/u><\/a> ist auf unserer Website dokumentiert.<\/p>\n\n\n\n Die zweite Zahl ist die wichtigere. Eine um drei Viertel geringere Streuung zeigt, dass der Prozess stabil geworden ist, nicht nur im Mittel schneller. Das ist der Unterschied zwischen einer MTTR, die sinkt, weil ein Team Gl\u00fcck hatte, und einer, die sinkt, weil es anders arbeitet.<\/p>\n\n\n\n Ein Hinweis zur Vergleichbarkeit, der zum ersten Abschnitt zur\u00fcckf\u00fchrt: In diesem Case war die Uhr \u201eTime-to-Restore“. In anderen Kepner-Tregoe-Projekten wurde mit den Kunden \u201eMean Time to Resolve“ vereinbart. Die Prozentwerte sind deshalb innerhalb eines Projekts aussagekr\u00e4ftig, nicht zwischen Projekten. Genau so sollten Sie auch Ihre eigene MTTR behandeln.<\/p>\n\n\n\n Ein besseres Dashboard senkt keine MTTR. Es zeigt nur genauer, wo sie entsteht. Damit die Diagnosephase dauerhaft k\u00fcrzer wird, muss der Prozess bei den Menschen ankommen, die im Bridge-Call sitzen:<\/p>\n\n\n\n Wenn Sie die Diagnosephase in Ihrem Incident Management systematisch verk\u00fcrzen wollen, ist der Workshop Major Incident Management<\/u><\/a> von Kepner-Tregoe der etablierte Einstieg: Ihr Team lernt die rationalen Prozesse aus PSDM und wendet sie auf eigene Major Incidents an. F\u00fcr eine Standortbestimmung Ihrer Incident-Management-Funktion, von der Baseline bis zum Roll-out, steht unsere Beratung Incident Management<\/u><\/a> zur Verf\u00fcgung.<\/p>\n\n\n\n Ja, aber nur mit definierter Lesart, festem Start- und Endpunkt und Bezug zu einem Erfolgsfaktor. ITIL 4 ordnet Kennzahlen des Incident Managements den Practice Success Factors zu und nutzt sie erst in diesem Kontext als KPIs.<\/p> <\/div> Eine allgemeing\u00fcltige Zielzahl gibt es nicht. ITIL 4 verlangt, Kennzahlen auf Incident-Typ, Service, Team und Zeitraum zu beziehen. Ein guter Wert ist einer, der gegen\u00fcber der eigenen Baseline sinkt, innerhalb des SLA liegt und dessen Streuung gleichzeitig abnimmt.<\/p> <\/div> MTBF (Mean Time Between Failures) misst den Abstand zwischen zwei Ausf\u00e4llen und damit Zuverl\u00e4ssigkeit; MTTR misst die Dauer der Wiederherstellung. Zusammen beschreiben sie die Verf\u00fcgbarkeit.<\/p> <\/div> Restore und Recovery meinen in der Regel dieselbe Strecke vom Ausfallbeginn bis zur Wiederherstellung des Services; Resolve reicht bis zur endg\u00fcltigen L\u00f6sung einschlie\u00dflich Ursache. Da ITIL die Ursachenkl\u00e4rung im Problem Management verortet, ist f\u00fcr das Incident Management die Restore-Uhr die passende.<\/p> <\/div> Summe der Wiederherstellungszeiten aller Incidents eines Zeitraums geteilt durch deren Anzahl. Belastbar wird die Rechnung durch einheitliche Start- und Endpunkte, Segmentierung nach Priorit\u00e4t oder Service und einen Blick auf die Streuung, weil der Mittelwert Ausrei\u00dfer verdeckt.<\/p> <\/div> <\/div>\n","protected":false},"excerpt":{"rendered":" Die Mean Time to Recovery (MTTR) ist die meistzitierte Kennzahl im Incident Management und zugleich die am schlechtesten definierte. Wer sie senken will, braucht zuerst eine klare Uhr: Wann startet die Messung, wann endet sie, und welches \u201eR“ ist gemeint. Erst dann l\u00e4sst sich beantworten, wo im Incident-Prozess die Zeit tats\u00e4chlich verloren geht. In den […]<\/p>\n","protected":false},"author":38928,"featured_media":37446,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":"","_ppma_block_editor_authors":""},"categories":[216],"tags":[],"ppma_author":[64],"class_list":["post-68272","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-service-operations-itsm"],"acf":[],"yoast_head":"\nWo im Incident-Prozess die Zeit wirklich verloren geht<\/h2>\n\n\n\n
Welche KPIs Incident Management nach ITIL wirklich steuern<\/h2>\n\n\n\n
\n
MTTR reduzieren: Wie rationale Prozesse die Diagnosephase verk\u00fcrzen<\/h2>\n\n\n\n
Praxisbeleg: 74 Prozent k\u00fcrzere Restore-Zeit in vier Monaten<\/h2>\n\n\n\n
MTTR-Reduktion verankern: Vom KPI-Dashboard zur F\u00e4higkeit im Team<\/h2>\n\n\n\n
\n
H\u00e4ufige Fragen zu MTTR und Incident-Management-KPIs (FAQ)<\/h2>\n\n\n\n
Ist MTTR ein KPI?<\/h2>
Was ist ein guter MTTR-Wert?<\/h2>
Was ist der Unterschied zwischen MTTR und MTBF?<\/h2>
Mean Time to Restore, Mean Time to Recovery, Mean Time to Resolve: Was ist der Unterschied?<\/h2>
Wie berechne ich MTTR korrekt?<\/h2>