MTTR reduzieren: Welche KPIs im Incident Management wirklich zählen

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 „R“ ist gemeint. Erst dann lässt sich beantworten, wo im Incident-Prozess die Zeit tatsächlich verloren geht. In den meisten IT-Organisationen ist das weder das Erkennen noch das Beheben, sondern der Schritt dazwischen.

Das Wichtigste in Kürze

• MTTR ist die Summe der Wiederherstellungszeit aller Incidents geteilt durch deren Anzahl; ohne festgelegte Lesart des „R“ sind Werte nicht vergleichbar.
• ITIL 4 steuert Incident Management über Teilzeiten wie Diagnosedauer, Neuzuweisungen und Wartezeitanteil, jeweils an einen Erfolgsfaktor gebunden.
• Ein Workaround senkt die MTTR sofort, kann aber technische Schulden aufbauen; deshalb gehört die Wiederkehrrate neben die MTTR.
• Die meiste Zeit geht in der Diagnosephase verloren. Sie lässt sich nicht automatisieren, aber mit rationalen Prozessen strukturieren.
• In einem viermonatigen Pilot mit Kepner-Tregoe sank die Mean-Time-to-Restore eines globalen Technologiekonzerns um 74 Prozent, die Streuung um 77 Prozent.

Was MTTR (Mean Time to Recovery) misst und welches „R“ Sie meinen

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ürzel, denn das „R“ wird in der Praxis unterschiedlich gelesen:

• Mean Time to Repair: reine Reparaturzeit an der Komponente.
• Mean Time to Recovery oder Mean Time to Restore (Service): vom Ausfallbeginn bis zur Wiederherstellung des Services.
• Mean Time to Resolve: bis zur endgültigen Lösung einschließlich Ursache.
• Mean Time to Respond: bis zur Annahme der Störung.

Zwei Teams können 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.

Wie folgenreich diese Unschärfe 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 „failed deployment recovery time“ umbenannt und enger gefasst, weil die alte Definition Störungen aus Produktionsänderungen nicht von externen Ausfällen unterschied. Die Lehre gilt über den Software-Delivery-Kontext hinaus: Eine Kennzahl, die ungleiche Dinge zusammenzählt, lässt sich nicht steuern.

Warum MTTR allein als Incident-Management-KPI in die Irre führt

Ein Mittelwert verbirgt, was ihn treibt. Ein einzelner langer Ausfall verschiebt die MTTR eines Monats stärker als ein Dutzend schneller Wiederherstellungen sie senken; umgekehrt verbessert das zügige Schließen vieler kleiner Incidents den Mittelwert, ohne dass sich an den kritischen Ausfällen etwas ändert. ITIL 4 verlangt deshalb, Kennzahlen nach Incident-Typ, Service, Team oder Zeitraum zu segmentieren, und stellt fest, dass es keine einzige beste Lösung gibt.

Die zweite Verzerrung ist der Workaround. ITIL 4 definiert ihn als Lösung, die die Auswirkung eines Incidents reduziert oder beseitigt, obwohl keine vollständige Lösung vorliegt. Workarounds stellen den Service schnell wieder her, können aber technische Schulden erhöhen und zu neuen Incidents führen. Ein Team kann seine MTTR also senken, indem es Symptome schneller überbrückt, und denselben Incident wenige Wochen später erneut bearbeiten. Ohne Wiederkehrrate neben der MTTR bleibt dieser Effekt unsichtbar. Kepner-Tregoe beschreibt diesen Mechanismus im Whitepaper „Am Limit und doch alles im Griff“ so: Durchschnittsbasiertes Reporting verbirgt die extremen Tickets, die Ressourcen verschlingen, und belohnt die Haltung „erst flicken, später Probleme lösen“. Der zugehörige Fallstrick heißt dort „Abschluss vor der Bestätigung“: Die MTTR-Metrik erzwingt das Schließen, bevor die Lösung dem Kunden gegenüber nachgewiesen ist.

Drittens ist „gelöst“ im Incident Management nicht dasselbe wie „verstanden“. ITIL 4 verortet die Untersuchung von Incident-Ursachen ausdrücklich im Problem Management, nicht im Incident Management. Die MTTR endet mit der Wiederherstellung. Ob die Ursache bekannt ist, sagt sie nicht.

ITIL 4 ordnet Kennzahlen des Incident Managements deshalb drei Practice Success Factors zu: Incidents früh erkennen, Incidents schnell und effizient lösen, die Ansätze kontinuierlich verbessern. Erst in diesem Rahmen taugen sie als KPIs. Eine MTTR ohne Bezug zu einem Erfolgsfaktor ist eine Zahl, kein Steuerungsinstrument.

Wo im Incident-Prozess die Zeit wirklich verloren geht

ITIL 4 beschreibt die Bearbeitung eines Incidents in sechs Aktivitäten: Erkennung, Registrierung, Klassifizierung, Diagnose, Lösung und Abschluss. Die Diagnose beginnt dort, wo die Klassifizierung keine bekannte Lösung liefert, und ist der Schritt, in dem Incidents zwischen Teams eskaliert oder gemeinsam per Swarming bearbeitet werden.

Erkennung und Registrierung lassen sich weitgehend automatisieren, und die Lösung selbst ist oft schnell, sobald klar ist, was zu tun ist. Die Zeit dazwischen ist die Diagnosephase. Sie ist der größte Zeitblock im Incident und zugleich der am seltensten gemessene.

ITIL 4 benennt dafür drei wiederkehrende Muster: Incidents werden zwischen Teams hin- und hergeschoben, Teammitglieder fühlen sich blockiert, und eine Kultur belohnt einzelne „Helden“. Die Folge sind Lösungen, die langsam kommen oder ausbleiben.

Die Datenspur bestätigt das Muster. Bei einer Diagnose des Incident Managements eines globalen Fintech-Konzerns analysierte Kepner-Tregoe per Process Mining über 80.000 Tickets und auditierte mehr als 100 Incidents. Das Mining zeigte eine Vielzahl von Nachbearbeitungsschleifen, Ticket-Neuzuweisungen und prozessinternen Verzögerungen. Abgeleitet wurde daraus der Bedarf an besserer Befragung zu Beginn und an einer Situationsbewertung, damit Tickets von vornherein richtig zugewiesen werden.

ITIL 4 macht den Zusammenhang explizit: Die Qualität der Incident-Daten von den ersten Schritten an beeinflusst die Richtigkeit der Entscheidungen, die Geschwindigkeit der Wiederherstellung, den Ressourceneinsatz und die Fähigkeit, die Ursache zu finden. Wer am Anfang ungenau erfasst, verliert die Zeit in jeder Schleife danach.

Welche KPIs Incident Management nach ITIL wirklich steuern

Ein tragfähiges KPI-Set koppelt die MTTR mit Kennzahlen, die zeigen, warum sie so hoch oder so niedrig ist. ITIL 4 liefert dafür eine Auswahl, die weit über die Gesamtdauer hinausgeht:

1. MTTR mit definierter Uhr, segmentiert nach Priorität und Service. Ohne Segmentierung ist der Mittelwert nicht interpretierbar.
2. Streuung der Restore-Zeit, etwa als Varianz oder 90. Perzentil. Ein Prozess, der mal in einer Stunde und mal in zwei Tagen wiederherstellt, ist nicht unter Kontrolle, auch wenn der Mittelwert stimmt. Kepner-Tregoe nutzt die Streuung als Prozesstest: Lösungszeiten nach Produkt und Mitarbeiter aufgetragen zeigen, ob ein vorhandener Prozess tatsächlich befolgt wird.
3. Zeit bis zur Annahme und Diagnosedauer. Beide Kennzahlen stehen in der ITIL-4-Beispielliste und machen die Phase sichtbar, in der die Zeit verloren geht.
4. Anzahl der Neuzuweisungen und Anteil der Wartezeit an der gesamten Bearbeitungszeit. Jede Weitergabe kostet Kontext; ITIL 4 führt beide als Kennzahlen.
5. First-Time-Resolution-Rate und Wiederkehrrate. Sie machen Workaround-Effekte sichtbar. Dass die Wiederkehrrate steuerbar ist, zeigt ein Support-Case aus der Software- und Cloud-Branche: Nach Integration eines einheitlichen Problemlösungsansatzes und einer konsistenten Fallstruktur in den Supportprozess sank die durchschnittliche Falldauer um 44 Prozent, und wiedereröffnete Fälle verschwanden vollständig.
6. Vollständigkeit der Incident-Spezifikation. ITIL 4 empfiehlt im Incident Record unter anderem den Zeitpunkt des ersten Symptoms, den Zeitpunkt der letzten normalen Funktion und Details vergleichbarer, nicht betroffener Objekte, weil letzteres die Ursachensuche eingrenzt. Nach Erfahrung von Kepner-Tregoe senkt eine saubere Problemformulierung („quality problem statement“) die MTTR für sich genommen um bis zu 18 Prozent.
7. Übergabequalität zwischen Support-Ebenen und an das Problem Management. Die Ursachenklärung liegt im Problem Management; die Datenqualität aus dem Incident entscheidet, ob der Fall danach bearbeitbar ist. Dasselbe gilt innerhalb des Incidents: Ein rational strukturiertes Ticket übergibt die Frontline so, wie die Backline es selbst aufgebaut hätte, und spart damit Rückfragen und Leerlauf. Ein Telekommunikationsanbieter berichtet nach Einführung von Quality Gates zwischen erster und zweiter Ebene, dass der Service Desk höherwertige Informationen liefert und weniger Tickets aus der zweiten Ebene zurückkommen.

ITIL 4 nennt ausdrücklich die Balance zwischen Geschwindigkeits- und Wirksamkeitsmetriken als eigene Kennzahl für die kontinuierliche Verbesserung. Genau diese Balance fehlt in Dashboards, die nur MTTR und SLA-Einhaltung zeigen.

Wie Ursachen nach der Wiederherstellung dauerhaft beseitigt werden, beschreibt unsere Seite zur Beratung Problem Management.

MTTR reduzieren: Wie rationale Prozesse die Diagnosephase verkürzen

Die Diagnosephase lässt sich nicht vollständig automatisieren, aber strukturieren. Die Methodik von Kepner-Tregoe, PSDM (Problem Solving & Decision Making), stellt dafür rationale Prozesse bereit, von denen drei im Incident direkt greifen. Für den Incident-Kontext bündelt sie der Workshop Major Incident Management, ein Derivat von PSDM.

Situationsanalyse: Erst ordnen, dann lösen. Ein Major Incident ist selten ein einzelnes Anliegen. Die Situationsanalyse klärt die Lage, bewertet jedes Anliegen nach gegenwärtigen Auswirkungen, zukünftigen Auswirkungen und Zeitrahmen und legt fest, welcher Analyseprozess und welche Beteiligten nötig sind. Die Frage „Wer muss hier dran?“ wird einmal zu Beginn beantwortet, nicht in jeder Eskalationsstufe neu.

Problemanalyse: Beschreiben, bevor erklärt wird. 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ücklich vorgesehen. Aus dem Vergleich von IST und IST-NICHT entstehen Hypothesen, die gegen die Spezifikation getestet werden, bevor jemand einen Neustart auslöst. Reicht ein Workaround, ist zumindest belegt, warum er greifen sollte.

Entscheidungsanalyse: Die Restore-Option mit vertretbarem Risiko wählen. Stehen mehrere Wege zur Wiederherstellung zur Wahl, macht die Entscheidungsanalyse die Kriterien explizit: Was muss die Option erfüllen (MUSS-Ziele), was wäre wünschenswert (WUNSCH-Ziele), welche Risiken birgt die bevorzugte Alternative? Ein Rollback, der die Störung behebt und dabei einen anderen Service beeinträchtigt, ist keine Wiederherstellung.

Der Workshop Major Incident Management zielt darauf, die Zeit in der Phase „Analyse und Diagnose“ bei größeren Ausfällen zu reduzieren und im Team eine gemeinsame, technologieunabhängige Problemlösungssprache zu etablieren. Im Bridge-Call ist das der entscheidende Punkt: Wenn alle Beteiligten dieselben Fragen stellen, entfällt die Abstimmung, die sonst als Wartezeit in der MTTR landet.

Praxisbeleg: 74 Prozent kürzere Restore-Zeit in vier Monaten

Ein globaler Technologiekonzern wollte die Lücken in seinem Prozess für High-Severity-Incidents schließen. Die Ausgangslage war typisch: komplexere Incidents mit höherem Ausfallrisiko, geografisch verteilte Fachexperten mit hohem Koordinationsaufwand, kein konsistenter Ansatz, uneinheitliche Datenerhebung, die das spätere Problem Management schwächte, und gefährdete SLAs. Zielmetriken waren Time-to-Restore, deren Streuung und die Vermeidung von Incidents der höchsten Stufe.

In einem viermonatigen Pilot mit Kepner-Tregoe wurde zunächst eine Baseline der Incident-Management-Funktion erhoben, anschließend der Prozess in Reihenfolge und Ausführung der Schritte gestrafft. Ergebnis: eine Reduktion der Mean-Time-to-Restore um 74 Prozent und der Streuung um 77 Prozent, bei höherem Anteil vermiedener Incidents der höchsten Stufe. Die vollständige Fallstudie zur Incident-Management-Performance ist auf unserer Website dokumentiert.

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ück hatte, und einer, die sinkt, weil es anders arbeitet.

Ein Hinweis zur Vergleichbarkeit, der zum ersten Abschnitt zurückführt: In diesem Case war die Uhr „Time-to-Restore“. In anderen Kepner-Tregoe-Projekten wurde mit den Kunden „Mean Time to Resolve“ vereinbart. Die Prozentwerte sind deshalb innerhalb eines Projekts aussagekräftig, nicht zwischen Projekten. Genau so sollten Sie auch Ihre eigene MTTR behandeln.

MTTR-Reduktion verankern: Vom KPI-Dashboard zur Fähigkeit im Team

Ein besseres Dashboard senkt keine MTTR. Es zeigt nur genauer, wo sie entsteht. Damit die Diagnosephase dauerhaft kürzer wird, muss der Prozess bei den Menschen ankommen, die im Bridge-Call sitzen:

1. Uhr und KPI-Set definieren. Welches „R“, welcher Start- und Endpunkt, welche Segmentierung. Ohne diesen Schritt misst jede Verbesserung ins Leere.
2. Baseline erheben und ein Ziel setzen. Streuung, Diagnosedauer, Neuzuweisungen und Wiederkehrrate vor der Veränderung dokumentieren. Der Case oben begann genau damit. Die europäische Tochter eines globalen Telekommunikationsanbieters setzte auf Basis ihrer MTTR-Baseline für geschäftskritische Anwendungen ein Verbesserungsziel von 15 Prozent und erreichte nach neun Monaten 64 Prozent; das Programm lief 2016.
3. Prozess trainieren, nicht Einzelne. Service Desk, Fachexperten und Major Incident Manager lernen dieselbe Systematik, sonst zerbricht die gemeinsame Sprache an der ersten Übergabe. Im Telekom-Programm wurden rund 500 Mitarbeitende an drei Standorten geschult und sechs interne Trainer ausgebildet, damit der Prozess auch neue Teams erreicht.
4. Reale Incidents coachen. Die ersten Analysen nach dem Training begleitet ein Coach. Das ist der Moment, in dem aus Wissen Routine wird.
5. Periodic Incident Review mit Prozessfragen führen. ITIL 4 führt die kontinuierliche Verbesserung als eigenen Erfolgsfaktor. Der Review fragt nicht nur, wie lange es gedauert hat, sondern ob die Spezifikation vollständig und die Restore-Entscheidung begründet war.

Wenn Sie die Diagnosephase in Ihrem Incident Management systematisch verkürzen wollen, ist der Workshop Major Incident Management von Kepner-Tregoe der etablierte Einstieg: Ihr Team lernt die rationalen Prozesse aus PSDM und wendet sie auf eigene Major Incidents an. Für eine Standortbestimmung Ihrer Incident-Management-Funktion, von der Baseline bis zum Roll-out, steht unsere Beratung Incident Management zur Verfügung.

Häufige Fragen zu MTTR und Incident-Management-KPIs (FAQ)