
Fehlerhistorie an der Maschine, bevor der Techniker eintrifft
Artikel teilen
Kurze Antwort: Fehlerhistorie an der Maschine vor dem Techniker bedeutet, die Reparaturhistorie, die OEM-Dokumentation und den relevantesten früheren Fix direkt an den Alarm zu binden, sodass die Information mit dem Einsatzauftrag mitreist, statt erst gesucht werden zu müssen. Das Gerät des Technikers zeigt sie in dem Moment, in dem die Aufgabe zugewiesen wird, noch bevor er die Maschine berührt hat.
Eine Maschine steht still. Jemand wird losgeschickt. Bis die Person an der Station ankommt, hat die Uhr schon mehr gekostet als nur den Weg dorthin. Das Instandhaltungsmanagement von Workerbase schließt diese Lücke, indem die Historie direkt am Alarm hängt, statt an einer Suche, die der Techniker erst nach der Ankunft startet.
In den meisten Werken ist die Fehlerhistorie etwas, das der Techniker selbst nachschlägt. Das ist der falsche Moment. Findet die Suche erst nach dem Einsatzauftrag statt, ist der Techniker bereits zur Maschine gelaufen, hat den Fehler eingeschätzt und angefangen zu raten, bevor die richtige Information vorliegt. Dieser Beitrag zeigt, was nötig ist, um diese Historie früher bereitzustellen, sodass sie schon an der Aufgabe hängt, bevor überhaupt ein Werkzeug in die Hand genommen wird.
Was bedeutet es, Fehlerhistorie an der Maschine bereitzustellen, bevor der Techniker eintrifft?
Es bedeutet, dass der Alarm, der die Instandhaltungsaufgabe auslöst, bereits die Reparaturhistorie des Assets, die OEM-Dokumentation und den relevantesten früheren Fix trägt, zusammengestellt und angehängt in dem Moment, in dem die Aufgabe geroutet wird. Der Techniker öffnet dafür kein zweites System. Die Information steht schon auf dem Gerät, das ihm gesagt hat, wohin er muss.
Das ist eine Änderung der Reihenfolge, kein neues Werkzeug. Die Dokumentation und die Reparaturhistorie existieren meist schon irgendwo: in einem CMMS, auf einem gemeinsamen Laufwerk, im Gedächtnis eines Technikers. Was fehlt, ist der Schritt, der den passenden Ausschnitt dieses Datensatzes zieht und ihn an genau diesen Alarm, an genau diesem Asset anhängt, bevor die Aufgabe einen Menschen erreicht.
Warum passiert das heute nicht automatisch?
Das passiert standardmäßig nicht, weil das System, das den Alarm auslöst, und das System, das die Dokumentation hält, meist zwei getrennte Tools ohne Verbindung sind. Eine Alarmmeldung teilt jemandem mit, dass eine Maschine stillsteht; ein CMMS oder Asset-Register hält fest, was zuvor mit ihr passiert ist. Nichts leitet das Zweite in das Erste.
Ein Asset-Register nach ISO-55089-Standard definiert, was ein Instandhaltungsdatensatz enthalten soll und wie er verwaltet wird, aber der Standard endet beim Inhalt des Datensatzes. Er sagt nichts darüber aus, wie dieser Datensatz die Person erreicht, die gerade losgeschickt wird, in genau diesem Moment. Diese Zustelllücke ist ein Problem der Umsetzung, kein Dokumentationsproblem, und deshalb schicken auch Werke mit gepflegtem CMMS ihre Techniker noch blind los.
Was muss stimmen, damit Fehlerhistorie den Techniker automatisch erreicht?
Drei Dinge müssen zusammenspielen: der Alarm, die Historie des Assets und die Person, die eingeteilt wird. Der Alarm muss die Asset-Identität tragen, die Historie muss strukturiert genug sein, um nach dieser Identität abgefragt zu werden, und der Routing-Schritt muss das Ergebnis an die Aufgabe anhängen, statt es in einem separaten System liegen zu lassen.
| Manuelle Reaktion | Historie beim Einsatzauftrag angehängt | |
|---|---|---|
| Wer wird benachrichtigt | Wer gerade in der Nähe oder im Bereitschaftsdienst ist | Der für dieses Asset zertifizierte Techniker |
| Was die Person bei Ankunft dabei hat | Nichts; die Suche beginnt erst vor Ort | Reparaturhistorie, OEM-Dokumente, letzter Fix |
| Zeit bis zur ersten informierten Handlung | Erst nach einer Suche an der Maschine | In dem Moment, in dem die Aufgabe ankommt |
Die Asset-Identität ist der Teil, den die meisten Setups überspringen. Ohne eine durchgängige ID, die Alarm, Dokumentation und Reparaturprotokoll verbindet, hat das System nichts, wonach es abfragen kann, und der Techniker stellt die Verbindung am Ende manuell her, wie schon immer.
Was unterscheidet das von einer KI-Assistenz-Abfrage direkt an der Maschine?
Es ist dieselbe Wissensbasis, nur zu einem anderen Zeitpunkt genutzt. KI-gestützte Maschinenfehlersuche beantwortet eine Frage, die der Techniker stellt, nachdem er angekommen ist und sich bereits eine erste Meinung gebildet hat. Fehlerhistorie beim Einsatzauftrag überspringt diese erste Vermutung: Der relevante Datensatz ist schon auf dem Gerät geöffnet, bevor der Techniker ein Wort gesagt hat.
Beide ergänzen sich, statt zu konkurrieren. Die Historie beim Einsatzauftrag grenzt schon vor der Ankunft ein, worauf der Techniker schaut; die Frage-Antwort-Assistenz übernimmt, was diese Historie nicht vollständig beantwortet, sobald er vor der Maschine steht. Keines von beidem ersetzt das Urteilsvermögen des Technikers. Beide verkürzen nur, wie lange es dauert, bis dieses Urteil entsteht.
Was ändert sich, wenn Fehlerhistorie mit dem Einsatzauftrag ankommt?
Die Reaktionsgeschwindigkeit steigt, weil der Techniker nicht mehr die ersten Minuten an der Maschine damit verbringt, zu rekonstruieren, was anderswo längst bekannt ist, und diese Minuten sind teuer: Die Stillstandsforschung von Siemens aus 2024 beziffert die Kosten ungeplanter Stillstände in der Automobilindustrie auf bis zu 2,3 Mio. USD pro Stunde. Workerbase-Kunden haben 1,2 Mio. Euro pro Jahr an vermiedenen Stillstandskosten aus einem einzigen Anwendungsfall in einem Werk gemessen, und die McKinsey-Studie zur Digitalisierung von Instandhaltung und Zuverlässigkeit benennt genau diese Lücke: Der Großteil der Digitalisierungsarbeit in der Instandhaltung fließt in Planung und Arbeitsaufträge, während der Moment, in dem ein Techniker Information benötigt, manuell bleibt.
Die Kennzahl, die sich zu messen lohnt, ist die Zeit von Alarm bis Handlung, die Minuten zwischen dem Stillstand und dem ersten qualifizierten, informierten Eingriff, statt allein die MTTR. Werke, die Historie beim Einsatzauftrag anhängen, verkürzen diese Lücke direkt, weil die Suche, die früher an der Maschine stattfand, jetzt automatisch passiert, noch bevor der Techniker überhaupt losgegangen ist.
Was sind die häufigsten Fehler beim Aufbau?
Das Handbuch anhängen, aber nicht die Reparaturhistorie. OEM-Dokumentation ist statisch und leicht zu verlinken. Die letzten drei Reparaturen an genau diesem Asset sagen einem Techniker, was wahrscheinlich nicht stimmt, aber dieser Datensatz ist schwerer zu strukturieren und fällt deshalb als Erstes weg.
Nach Verfügbarkeit statt nach Qualifikationsanforderung des Assets routen. Den nächstgelegenen Techniker zu schicken, bringt nichts, wenn er für diese Maschine nicht zertifiziert ist. Das Routing muss an derselben Asset-Identität ansetzen wie die Historie, sonst verbinden sich die beiden Systeme nie.
Keine Rückmeldung nach dem Fix. Wird die Lösung nicht in den Asset-Datensatz zurückgeschrieben, startet der nächste Alarm an dieser Maschine wieder bei null. Der Nutzen summiert sich nur, wenn jede Reparatur das ergänzt, was der nächste Techniker sieht.
Die Historie zum Techniker zu bringen, ist nur die eine Hälfte des Programms. Für die Praktiken, die geführte Fehlersuche auch im großen Maßstab zuverlässig halten, siehe Best Practices für geführte Fehlersuche, die die MTTR senkt.
Häufig gestellte Fragen
Müssen wir dafür unser CMMS ersetzen?
Nein. Das CMMS oder Asset-Register, das Sie bereits betreiben, bleibt das führende System. Was sich ändert, ist der Schritt zwischen dem Auslösen des Alarms und dem Erreichen des Technikers: Dieser Schritt fragt jetzt den bestehenden Datensatz nach Asset-ID ab und hängt an, was er findet, statt den Techniker das CMMS erst vor Ort separat öffnen zu lassen.
Was, wenn ein Asset noch kaum digitale Historie hat?
Sie fängt dünn an und wächst mit jeder erfassten Reparatur. Der erste Alarm an einem neu erfassten Asset hängt nur die vorhandene OEM-Dokumentation an, sonst nichts; ab dem fünften oder sechsten Alarm steht eine echte Reparaturhistorie zur Verfügung. Die Lücke schließt sich am schnellsten bei den Assets, die am häufigsten ausfallen, und genau dort zählt sie am meisten.
Was unterscheidet das von einem Predictive-Maintenance-Alarm?
Ein Predictive-Alarm versucht, einen Ausfall zu erkennen, bevor er eintritt, basierend auf Sensortrends. Fehlerhistorie beim Einsatzauftrag geht davon aus, dass der Ausfall bereits eingetreten ist, und sorgt dafür, dass die richtige Information so schnell wie möglich bei der richtigen Person ankommt. Beide lösen verwandte, aber unterschiedliche Probleme, und die meisten Werke benötigen beides.
Muss der Techniker nach dem Einsatzauftrag noch selbst etwas suchen?
Bei routinemäßigen, bereits bekannten Fehlern nein: Die relevante Historie steht schon auf dem Gerät. Bei einem Fehlerbild, das das System noch nicht kennt, gibt es noch nichts anzuhängen, und der Techniker geht wie gewohnt vor, wobei die Lösung danach erfasst wird, damit auch der nächste Fall nicht bei null beginnt.
Lässt sich das parallel zu SAP PM oder Maximo betreiben?
Ja. Der Asset-Datensatz und der Arbeitsauftrag können in SAP PM oder Maximo bleiben; Workerbase sitzt vor dem Einsatzauftrags-Schritt, zieht die Daten aus diesem System per Asset-ID, hängt das Ergebnis an die Aufgabe auf dem Gerät des Technikers an und schreibt die Lösung anschließend automatisch zurück.
Möchten Sie sehen, wie schnell Fehlerhistorie Ihre Techniker heute erreicht? Fordern Sie eine Workerbase-Demo an und bringen Sie Ihr unzuverlässigstes Asset mit.