Shopfloor-Mitarbeiter eskaliert eine Maschinenstörung an den richtigen Techniker
Fertigung

MTTR senken, ohne neue Techniker einzustellen

Panagiotis Mavridis

Kurze Antwort: Wer die MTTR senken will, ohne neue Techniker einzustellen, muss Alarmweiterleitung und Wissenszugriff verbessern, nicht die Personaldecke. Leiten Sie Alarme direkt an den richtigen zertifizierten Techniker weiter, hinterlegen Sie Reparaturhistorie und OEM-Dokumentation am Asset, und standardisieren Sie die Fehlersuche, damit jeder Techniker denselben geprüften Ablauf befolgt, statt sich auf die eigene Erinnerung zu verlassen.

Mean Time to Repair (MTTR) misst die durchschnittliche Zeit zwischen einem Maschinenstillstand und der korrekt wiederhergestellten Produktion. Plant Manager greifen zu dieser Kennzahl, wenn eine Linie steht und niemand erklären kann, warum die Reparatur so lange gedauert hat. Workerbase schließt die Lücke zwischen dem Auslösen des Alarms und dem Eingreifen der richtigen Person, ohne dass dafür ein einziger zusätzlicher Techniker eingestellt werden muss.

Im Instandhaltungsmanagement ist der erste Reflex bei zu hoher MTTR meist, einen weiteren Techniker anzufordern. Das ändert an der Kennzahl selten etwas. Wenn eine zweite Person auf dieselben fehlenden Informationen an derselben undokumentierten Maschine wartet, sind am Ende zwei Personen langsam statt einer.

Was ist MTTR, und warum löst Einstellen das Problem nicht?

MTTR misst die durchschnittliche Zeit von einem Ausfall bis zur wiederhergestellten Produktion über einen definierten Zeitraum, in der Regel die gesamte Reparaturzeit geteilt durch die Anzahl der Reparaturen. Das unterscheidet sich von MTBF (Mean Time Between Failures), das misst, wie oft eine Maschine ausfällt, nicht wie schnell sie repariert wird. Ein Werk kann eine hervorragende MTBF haben und trotzdem bei der MTTR Geld verlieren, wenn jeder Ausfall, so selten er auch vorkommt, Stunden bis zur Behebung braucht.

Mehr Techniker einzustellen behandelt die Personaldecke als Engpass. In den meisten Werken liegt der eigentliche Engpass jedoch bei Informationen: welcher Techniker qualifiziert und verfügbar ist, was diesen Fehler bei den letzten drei Vorfällen behoben hat, und wo die aktuelle OEM-Anleitung liegt. Wer in dieser Situation eine weitere Person einstellt, verdoppelt nur die Anzahl der Techniker vor denselben ungelösten Fragen, ändert aber nichts an der Reparaturgeschwindigkeit.

Wie berechnet man die MTTR korrekt?

Die gesamte ungeplante Reparaturzeit geteilt durch die Anzahl der Reparaturvorfälle, über einen einheitlichen Zeitraum hinweg (eine Schicht, eine Woche, ein Quartal). Ein häufiger Fehler ist, die Zeit vom Alarm bis zum Eintreffen des Technikers zu messen statt vom Alarm bis zur tatsächlich wiederhergestellten Produktion. Dadurch fallen Diagnose- und Verifikationszeit unbemerkt heraus, und die Kennzahl sieht besser aus, als die Linie es erlebt.

Was einzubeziehen istWas fehlt, wenn Sie es nicht tun
Zeit bis zur Erkennung des AusfallsMaschinen stehen still, bevor es jemand bemerkt
Zeit bis zur Weiterleitung an einen qualifizierten TechnikerFalsche Zuweisung, Verzögerung durch erneutes Weiterleiten
Diagnose- und ReparaturzeitDer Teil, den alle für die gesamte Kennzahl halten
Verifikation und WiederanlaufFehler, die eine Stunde später erneut auftreten, unerfasst

Der richtige Vergleichswert hängt vom Asset, vom Fehlerbild und von den Kosten einer stehenden Linie ab. Die Kennzahl bedeutet erst dann etwas, wenn sie jedes Mal auf dieselbe Weise gemessen wird.

Warum bleibt die MTTR hoch, selbst mit einem voll besetzten Instandhaltungsteam?

Drei Ursachen wiederholen sich über Werke hinweg, und keine davon lässt sich durch eine weitere Einstellung lösen.

Verzögerte Erkennung. Eine Maschine kann zwanzig Minuten stillstehen, bevor jemand physisch vorbeikommt und das rote Licht bemerkt. Diese Verzögerung geht in die MTTR ein, bevor überhaupt ein Techniker beteiligt ist.

Zuweisung nach Nähe statt Qualifikation. Die nächste verfügbare Person erhält den Auftrag, unabhängig davon, ob sie für diese Maschine oder diesen Fehlertyp zertifiziert ist. Sie beginnt die Diagnose bei null, eskaliert dann, sobald ihr Wissen an seine Grenze stößt, und die Uhr läuft während beider Versuche weiter.

Keine Reparaturhistorie am Ort des Ausfalls. Ein Techniker, der zu einem wiederkehrenden Fehler kommt, kann nicht sehen, was ihn bei den letzten drei Vorfällen behoben hat. Das Werk löst dasselbe Problem also immer wieder neu. Ein Plant Manager beschreibt es so: „Die MTTR ist zu lang – wir verlieren 40 Minuten damit, die richtige Person zu finden und zu hoffen, dass sie sich an die Lösung erinnert.“

Wie senkt man die MTTR, ohne neue Techniker einzustellen?

Vier Veränderungen setzen am eigentlichen Engpass an, in der Reihenfolge, in der ihre Wirkung sich am schnellsten summiert.

Alarm an eine Person weiterleiten, nicht an eine Warteschlange

Verbinden Sie Maschinenalarme oder Sensorsignale direkt mit automatischer Auftragserstellung, die an den Techniker geht, der für dieses Asset zertifiziert und verfügbar ist, nicht an die nächstgelegene Person. Das entfernt die falsche Zuweisung und den erneuten Eskalationszyklus, bevor die Diagnose überhaupt beginnt.

Reparaturhistorie am Asset hinterlegen, nicht im Gedächtnis einer Person

Wenn ein Techniker die Maschine öffnet, sollte er die Alarmhistorie, frühere Reparaturen und die OEM-Dokumentation für genau dieses Asset sehen, nicht ein generisches Handbuch, das irgendwo auf einem gemeinsamen Laufwerk liegt. Kontextbezogene Fehlersuche direkt an der Maschine macht aus einem kalten Start eine Fünf-Minuten-Recherche, weil die Antwort bereits an der Sache hängt, die vor ihm steht.

Den Reparaturablauf standardisieren, nicht nur die Checkliste

Ein strukturierter Fehlersuchablauf, einmal aus der eigenen Root-Cause-Analyse des Werks aufgebaut, sorgt dafür, dass jeder Techniker dieselben Schritte in derselben Reihenfolge befolgt, statt der Version, an die er sich aus einer zwei Jahre zurückliegenden Schulung erinnert. Übersprungene Schritte werden sichtbar statt unbemerkt zu bleiben.

Die Rückmeldeschleife mit Daten schließen, damit sich derselbe Fehler nicht wiederholt

Jeder abgeschlossene Alarm sollte in einen strukturierten Datensatz einfließen: was ausgefallen ist, was es behoben hat, wie lange es gedauert hat. Wiederkehrende Fehler über Maschinen, Schichten oder Werke hinweg werden so als Daten sichtbar statt als Geschichte, die jemand in der Pause erzählt. Genau das ist die Grundlage, auf der Total Productive Maintenance-Programme tatsächlich laufen.

Bei Porsche läuft diese Rückmeldeschleife bereits live auf dem Shopfloor: „Für uns auf dem Shopfloor ist das ein echter Game-Changer. Wenn etwas passiert, kann ich mit einem einzigen Klick Unterstützung anfordern, und Hilfe kommt sofort. Das reduziert die Ausfallzeit deutlich und spart Zeit“, sagt Martin Rosenlöcher, Produktionsleiter bei Porsche AG. Kein zusätzlicher Techniker, nur der Alarm, der die richtige Person sofort erreicht.

Welche KPIs belegen, dass sich die MTTR wirklich verbessert hat?

Verfolgen Sie diese Kennzahlen zusätzlich zur MTTR, nicht anstelle von ihr:

  • First-Time-Fix-Rate: der Anteil an Reparaturen, die innerhalb von 24 Stunden nicht erneut auftreten. Eine sinkende MTTR bei gleichzeitig sinkender First-Time-Fix-Rate bedeutet, dass Fehler schneller, aber nicht korrekt geschlossen werden.
  • Eskalationsrate: wie oft der zuerst zugewiesene Techniker den Fehler an eine andere Person übergeben muss. Sie sinkt am schnellsten, sobald die Zuweisung auf Zertifizierung statt auf Nähe basiert.
  • Wiederholungsfehlerrate: wie oft derselbe Fehler am selben Asset innerhalb eines definierten Zeitraums erneut auftritt. Diese Kennzahl zeigt, ob Reparaturen die Rückmeldeschleife tatsächlich schließen oder nur die Uhr neu starten.
  • MTBF neben MTTR: eine sinkende MTTR bei gleichzeitig sinkender MTBF bedeutet, dass Maschinen häufiger ausfallen, selbst wenn jeder einzelne Ausfall schneller behoben wird – ein anderes Problem.

Workerbase-Implementierungen gehen auf einer Produktionslinie innerhalb von zwei Wochen live, wobei 85 % der Konfiguration vom Ops-Team statt von der IT übernommen werden. So sieht ein Werk, ob Änderungen an Zuweisung und Reparaturhistorie diese Kennzahlen bewegen, bevor es sich weiter festlegt.

Häufige Fehler beim Versuch, die MTTR zu senken

Messung ab Zuweisung statt ab Ausfall. Wenn die Uhr erst mit der Zuweisung eines Technikers startet und nicht mit dem tatsächlichen Maschinenstillstand, unterschätzt die gemeldete Kennzahl das, was die Linie tatsächlich erlebt hat.

Personal aufstocken, bevor die Zuweisung stimmt. Ein zweiter oder dritter Techniker, der vor derselben fehlenden Reparaturhistorie und derselben nähebasierten Zuweisung steht, erzeugt dieselbe Verzögerung, nur mit mehr Personen im Leerlauf.

Jeden Fehler gleich behandeln. Ein Fehler, den ein Techniker schon fünfzig Mal gesehen hat, und ein Fehler, den noch niemand gesehen hat, brauchen unterschiedliche Reaktionen. Werden beide gleich zugewiesen, verschwendet das die Zeit des zertifizierten Technikers an einem Fehler, den eine weniger erfahrene Person allein anhand der Reparaturhistorie hätte lösen können.

Die Lösung erfassen, aber nie wiederverwenden. Eine dokumentierte Reparatur, die beim nächsten Auftreten desselben Fehlers niemand wiederfindet, bleibt ein Archiv statt einer nutzbaren Wissensbasis. Der Wert liegt darin, dass die Lösung genau im Moment des nächsten Ausfalls auftaucht, nicht darin, dass der Datensatz irgendwo existiert.

Häufig gestellte Fragen

Was ist eine gute MTTR für ein Fertigungswerk?

Es gibt keinen einzelnen Vergleichswert, der für jedes Asset und jede Branche gilt – was als gut gilt, hängt stark vom Asset, vom Fehlerbild und von den Kosten einer stehenden Linie ab. Aussagekräftiger ist der Vergleich der eigenen MTTR über die Zeit, durchgängig gemessen vom Ausfall bis zum verifizierten Wiederanlauf, nicht von der Zuweisung bis zum Eintreffen.

Ist MTTR dasselbe wie Stillstandszeit?

Nein. Die MTTR ist die durchschnittliche Reparaturzeit pro Ausfallereignis. Die Stillstandszeit ist die gesamte Zeit, in der eine Maschine oder Linie nicht verfügbar ist, einschließlich geplanter Stopps, Rüstvorgänge und jeder Wartezeit, bevor eine Reparatur überhaupt beginnt. Ein Werk kann seine MTTR verbessern, während die gesamte Stillstandszeit gleich bleibt, wenn verzögerte Erkennung oder Terminierungsprobleme den größeren Anteil ausmachen.

Senkt mehr Instandhaltungspersonal immer die MTTR?

Nicht von allein. Wenn die eigentliche Verzögerung dadurch entsteht, dass Alarme nicht schnell genug einen qualifizierten Techniker erreichen, oder dass am Ort des Ausfalls die Reparaturhistorie fehlt, verteilt zusätzliches Personal dieselbe Verzögerung nur auf mehr Personen, statt sie zu beseitigen. Zuweisung und Wissenszugriff zu verbessern bewegt die Kennzahl in der Regel schneller als zusätzliches Personal.

Wie hilft KI, die MTTR ohne zusätzliches Personal zu senken?

KI kann die relevante Reparaturhistorie, OEM-Dokumentation und frühere Lösungen für genau das Asset und den Fehler, vor dem ein Techniker steht, in einfacher Sprache im Moment des Ausfalls anzeigen. Das macht aus einem kalten Diagnosestart eine gezielte Recherche. Die Ausgabe muss auf einer laufenden Produktionslinie deterministisch und nachvollziehbar bleiben, statt generativer Vermutungen, die ein Techniker erst von Grund auf prüfen müsste.

Was ist der Unterschied zwischen MTTR und MTBF?

Die MTTR misst, wie lange eine Reparatur dauert, sobald ein Ausfall eintritt. Die MTBF (Mean Time Between Failures) misst, wie oft Ausfälle überhaupt auftreten. Verbessert man die eine Kennzahl, ohne die andere zu beobachten, kann das ein verzerrtes Bild ergeben: Ein Werk kann Ausfälle schneller beheben, während die Ausfälle selbst häufiger werden.

Funktioniert eine MTTR-Senkung auch ohne neue IoT-Hardware oder Sensoren?

Ja, für die Hälfte des Problems, die Zuweisung und Wissenszugriff betrifft. Bestehende Alarmsignale mit automatischer Auftragserstellung zu verbinden und dokumentierte Reparaturhistorie an einem Asset zu hinterlegen, erfordert keine neuen Sensoren, sondern nur ein System, das bereits mit der Alarmquelle spricht. Neue Sensordaten bringen zusätzlich eine frühere Erkennung, sind aber keine Voraussetzung dafür, die Verzögerung bei Diagnose und Wissenszugriff zu verkürzen.