Die mittlere Lösungszeit (MTTR) bleibt weiterhin relevant, genügt heute aber nicht mehr als alleiniger Indikator.
Jahrzehntelang haben IT‑Teams ihren Erfolg an der mittleren Lösungszeit (MTTR) gemessen. Die Logik dahinter war einfach: Ausfälle gelten als unvermeidbar, und der Erfolg zeigt sich daran, wie schnell Menschen sie beheben können. Doch dieser Ansatz hat einen entscheidenden Haken. Er bewertet ausschließlich, wie gut Unternehmen auf Fehler reagieren und nicht, ob sich diese Probleme von vornherein hätten vermeiden lassen.
„Auf jede Person, die ein Ticket einreicht, kommen neun oder zehn weitere mit demselben Problem, die es nicht tun“, sagt Jason Keogh, Vice President Solutions bei TeamViewer. Diese nicht gemeldeten Probleme führen zu unsichtbaren Verlusten bei der Produktivität. Die MTTR kann das nicht abbilden, weil User oft stundenlang selbst nach Lösungen suchen statt ihre eigentlichen Aufgaben zu erledigen.
Die Frage, die sich IT-Teams stellen müssen, lautet daher nicht mehr, „Wie rasch können wir diese Störung beheben?“, sondern vielmehr, „Wie schnell können wir aus Mustern lernen und verhindern, das dieses Problem erneut auftritt?"
Der Nachteil der mittleren Lösungszeit (MTTR) besteht darin, dass sie die Geschwindigkeit misst, nicht das Risiko. Ein Ticket, das innerhalb von zwei Stunden gelöst werden konnte, erscheint im Dashboard als Erfolg. Diese Kennzahl sagt nichts darüber aus, was passiert ist, bevor das Ticket erstellt wurde oder welcher Schaden während dieser zwei Stunden entstanden ist.
Keogh hat das selbst erlebt. Insgesamt drei Stunden, über zwei Tage verteilt, verbrachte er mit dem Versuch, ein fehlgeschlagenes Windows-Update auf seinem Rechner zu beheben. „Am Ende des zweiten Tages, also am Dienstag, habe ich ein Ticket eingereicht, und am Mittwochmorgen wurde es bearbeitet“, erklärt er.
Das System zeigte eine Lösungszeit von etwa zwei Stunden an, von Dienstagabend bis Mittwochmorgen. Die drei verlorenen Stunden wurden jedoch in keinem Bericht erfasst und blieben unsichtbar.
Diese Diskrepanz zwischen der Realität und den Kennzahlen zeigt sich auch im großen Maßstab. Als Keogh einen Kunden bat, dessen Ticketsystem auf Automatisierungspotenziale zu überprüfen, fiel es ihm schwer, sich darauf vorzubereiten. Dafür gab es zwei Gründe: Der Support dokumentiert häufig nicht, auf welche Weise er ein Problem behebt. Es wird schlicht auf „gelöst“ gesetzt. Und selbst wenn gründlich dokumentiert wird, ist es nahezu unmöglich, aus Tickets verschiedener Personen konsistente und verwertbare Daten zu extrahieren.
„Die meisten Ticketsysteme liefern keine Informationen darüber, welche Maßnahmen ergriffen werden“, merkt Keogh an. Fehlen diese Hinweise, lassen sich weder Muster erkennen noch Automatisierungen entwickeln. Tritt das Problem in der folgenden Woche erneut auf, kann das Support‑Team es daher nicht verhindern.
Wenn Tickets nicht die Realität widerspiegeln, liegt das Problem nicht in der Lösungszeit, sondern in der fehlenden Sichtbarkeit. Herkömmliches Monitoring schließt diese Lücke nicht, weil es auf vordefinierten Schwellenwerten und bekannten Fehlermodi basiert. Es kann nur Probleme erkennen, die Sie bereits erwarten.
„Selbst wenn ein Tool etwas in Ihren Systemen überwacht – was genau wird überwacht?“, fragt Keogh. „Damit wird nicht zwangsläufig das tatsächliche Problem erfasst.“ Entwickeln sich neue Muster außerhalb dieser Definitionen, bleiben sie unsichtbar, bis die User bereits betroffen sind.
Der eigentliche Engpass ist der menschliche Faktor. Kein Team kann kontinuierlich Tausende von Endgeräten überwachen, Signale systemübergreifend verknüpfen und schnell genug entscheiden, was wirklich zählt, um rechtzeitig eingreifen zu können. „Monitoring bedeutet im Grunde, Probleme zu betrachten“, sagt Keogh. „Aber wir sind nicht hier, um uns Probleme einfach nur anzuschauen. Wir sind hier, um sie zu lösen.“
Reaktionen auf bekannte Störungen lassen sich automatisieren. Vorgänge, deren Ursache oder Entstehung jedoch nicht erkannt wird, können nicht verhindert werden. „Sie haben vielleicht ein Automatisierungs‑Tool“, erklärt Keogh, „oder ein Monitoring‑Tool, aber es erfasst nicht einmal die richtigen Signale. Automatisierung kann einen echten Mehrwert bieten – aber nur, wenn die richtigen Dinge automatisiert werden. Die Herausforderung besteht darin, zu wissen, welche das sind."
Die Lösung sind Systeme, die aus dem tatsächlichen Verlauf der Störungsbehebung lernen, nicht nur aus definierten Überwachungsregeln. Herkömmliche Tools sind darauf ausgelegt, zu reagieren: Überschreitet ein Messwert einen Schwellenwert, wird ein Ticket erstellt und ein Mitarbeitender muss eingreifen.
Agentic AI arbeitet anders.
Agentische KI-Systeme reagieren nicht einfach auf Warnmeldungen oder führen vordefinierte Workflows aus. Sie beobachten kontinuierlich, wie sich die IT-Infrastruktur verhält, wo Menschen eingreifen und wie sich Probleme im Laufe der Zeit entwickeln. Statt auf ein Ticket oder eine Übergabe zu warten, bauen diese Systeme ihr eigenes Verständnis von Risiko auf, basierend auf dem, was im täglichen Betrieb tatsächlich passiert.
Dadurch verschiebt sich die Frage von „Ist etwas kaputt?“ zu „Entwickeln sich die Bedingungen in eine Richtung, die typischerweise zu einem Ausfall führt?“ Risiko wird zu etwas, das frühzeitig erkennbar ist. Und es bleibt noch genug Zeit zum Handeln.
In der Praxis bedeutet das: Das System erkennt Muster, die in Ticketprotokollen niemals sichtbar wären. TeamViewer Session Insights nutzt beispielsweise KI, um die konkreten Schritte während einer Remote-Session zu beobachten. So wird jede manuelle Fehlerbehebung zu einem Signal. Wenn mehrere Teammitglieder ähnliche Probleme lösen, entstehen Muster, die zeigen, was automatisiert werden sollte und welche Risiken sich abzeichnen.
„Wenn mehrere Leute mehrmals das dasselbe Problem auf mehreren Geräten beheben müssen, erfahren wir, welche manuellen Aufgaben das Team übernimmt“, erklärt Keogh. „Das zeigt uns, was wir automatisieren sollten.“
Das Ergebnis ist ein kontinuierlicher Feedback-Kreislauf. Bekannte Probleme werden automatisiert behoben und neue Probleme früher sichtbar. So müssen IT-Teams nicht mehr im Nachhinein auf Störungen reagieren, sondern können verhindern, dass sie sich überhaupt auf die User auswirken.
Können IT-Teams Vorfälle vorhersagen und verhindern, statt sie nur schnell zu beheben, verliert die MTTR an Bedeutung. Die mittlere Betriebsdauer zwischen Ausfällen (MTBF) wird zum entscheidenden Indikator: Sie zeigt, wie lange Systeme stabil laufen. Eine verbesserte MTBF belegt, dass die vorausschauende Strategie wirkt. Die MTTR bleibt relevant, wenn Probleme tatsächlich auftreten, ist aber nicht mehr der wichtigste Faktor.
„Die mittlere Lösungszeit verliert bei dieser Arbeitsweise an Bedeutung, weil wir verhindern, dass Tickets überhaupt erst entstehen“, sagt Keogh. „Wichtiger ist zu beobachten, wie viele Probleme wir autonom lösen. Wie viele Tickets vermeiden wir? Wie viel Zeit geben wir unseren Usern zurück?“
Dieser Wandel erfordert mehr als nur neue Tools. Entscheidend ist es, vier miteinander vernetzte Kompetenzen zu entwickeln, die sich gegenseitig verstärken und ein System formen, das mit der Zeit immer intelligenter wird.
So gelingt Ihnen der Umstieg auf eine vorausschauend arbeitende IT.
Auch bei einer vorausschauenden Strategie gilt: Wenn etwas ausfällt, muss das Problem zuverlässig behoben werden. Die Reaktion auf Vorfälle sollte standardisiert ablaufen. Sie benötigen außerdem die passenden Tools, um Störungen schnell zu diagnostizieren und Systeme aus der Ferne wiederherzustellen. Dadurch lassen sich Auswirkungen minimieren und wertvolle IT-Ressourcen schonen. Probleme schnell zu lösen, ist wichtig. Doch ebenso entscheidend ist es, darüber hinaus systematische Verbesserungen voranzutreiben.
Jeder schwerwiegende Vorfall ist ein Chance zu lernen. Etablieren Sie einen obligatorischen, ergebnisoffenen Analyseprozess, um die systematische Schwachstelle zu identifizieren, die den Vorfall überhaupt ermöglicht hat. Die zentrale Frage lautet nicht „Was ist kaputtgegangen?“, sondern „Warum war das möglich und wie lässt sich sicherstellen, dass es nicht wieder passiert?“
Bauen Sie ein formales, hoch priorisiertes Backlog für bereits identifizierte Ursachen auf. So stellen Sie sicher, dass Wartungs- und Automatisierungsaufgaben wie Aktualisierungen, Patches und die Standardisierung von Konfigurationen Vorrang vor neuen, nicht essenziellen Feature-Anfragen erhalten. Wenn ständig neue Funktionen entwickelt werden, während die Basis weiterhin instabil bleibt, lässt sich der reaktive Kreislauf nicht durchbrechen.
Messen Sie Ihren Erfolg anhand der mittleren Betriebsdauer zwischen Ausfällen (Mean Time Between Failures, MTBF), nicht mehr anhand der Lösungszeit (MTTR). Wird Zuverlässigkeit zur zentralen Kennzahl, rückt die Fähigkeit zur Prognose in den Mittelpunkt.
Wenn Systeme seltener ausfallen, zeigt sich der Mehrwert in der Zeit, die Menschen gar nicht erst verlieren. Gerade in Umgebungen, in denen jede Minute zählt, summiert sich dieser Unterschied schnell.
In einer Gesundheitseinrichtung meldet sich das medizinische Personal beispielsweise im Laufe des Tages an PCs in Patientenzimmern an, wobei jeweils ein User-Profil erstellt wird. Mit der Zeit sammeln sich Dutzende von Profilen auf jedem Rechner, wodurch die Startzeit von 10 Sekunden auf 2 bis 3 Minuten steigt.
„Jedes Mal, wenn eine weitere Person diesen Raum betritt, gehen zwei Minuten verloren“, erklärt Keogh. „Über mehrere Tage hinweg summiert sich das auf ein bis zwei Stunden pro Tag.“ Durch die automatische Identifizierung und Eliminierung dieser Profile erhält das medizinische Personal wertvolle Zeit zurück. „Das ist, als würde man dem Krankenhaus Dutzende zusätzlicher Pflegekräfte und ärztliches Personal zur Verfügung stellen. Mehr Produktivität bedeutet also auch einen Zuwachs an effektiv geleisteten Arbeitsstunden, so als hätte man mehr Mitarbeitende eingestellt.“
So werden nicht einfach Störungen schneller behoben. Das ist vorausschauendes Handeln, das messbaren Geschäftswert schafft.
Die MTTR bleibt zwar relevant, bildet jedoch die Realität moderner IT‑Umgebungen nicht mehr vollständig ab. Wenn die meisten Probleme nie erfasst werden und gelöste Vorfälle nicht erkennen lassen, wodurch sie tatsächlich behoben wurden, greift eine reine Optimierung der Reaktionsgeschwindigkeit zu kurz und übersieht, wo die eigentlichen Verluste entstehen.
Agentic AI versetzt die IT in die Lage, vorausschauend zu handeln. Sie bietet Transparenz, Mustererkennung und Autonomie in einem Umfang, der für Menschen unerreichbar wäre. Mit einer steigenden mittleren Betriebsdauer zwischen Ausfällen (MTBF) und weniger Vorfällen, die bei den Usern überhaupt ankommen, bemisst sich der Erfolg zunehmend nicht mehr an der Reaktionsgeschwindigkeit des Teams, sondern vielmehr daran, wie selten dessen Eingreifen überhaupt noch erforderlich ist.
Product Marketing Manager bei TeamViewer
—
Linda Madisone ist Product Marketing Managerin für KI und Remote bei TeamViewer. Ihr Schwerpunkt liegt darin, leistungsstarke Technologie in klaren Kundennutzen zu übersetzen. Mit Begeisterung entwickelt sie Botschaften und Narrative, die komplexe technische Sachverhalte verständlich, relevant und wertstiftend vermitteln.
Entdecken Sie, wie TeamViewer KI Session Insights, musterbasierte Lernprozesse und intelligentere Automatisierung nutzt, um die Zahl der Vorfälle langfristig zu reduzieren.
