Störungsdiagnose: Wo der Techniker anfängt, nicht wo er aufgibt

Das echte Ausmaß des Problems

Reparaturzuverlässigkeit ist ein konkretes Geschäftsproblem im Service. Wenn ein Techniker bei einem Einsatz den Fehler nicht findet oder falsch repariert und muss wiederkommen, kostet das: Fahrtzeit, zweiter Terminaufwand, Kundenfrust, Gebühren, die du nicht berechnen kannst.

Die Branche nennt das First-Fix-Rate, wie viel Prozent der Probleme werden beim ersten Einsatz tatsächlich gelöst? Für die meisten Elektrotechnik- und Maschinenbaubetriebe liegt diese Quote zwischen 55 und 70 %. Der Rest erfordert Nacharbeiten, einen zweiten Termin oder eine Reparaturkampagne.

Eine Studie des Fraunhofer-Instituts für Arbeitswirtschaft und Organisation (IAO, 2023) zeigt: In Betrieben mit komplexer Fertigungsanlagentechnik entfallen durchschnittlich 8–12 Stunden pro Monat und Techniker auf fehlerhafte oder wiederholte Diagnosen. Das sind 20–30 Prozent der verfügbaren Servicekapazität, die nicht wertschöpfend ist, direkt kostet das Unternehmen täglich Geld, und die Kunden warten länger.

Ein typischer Ablauf bei der manuellen Fehlersuche:

1. Symptom beobachten, „Anlage ist aus” oder „seltsames Geräusch”
2. Verdacht anstellen, „Bestimmt das Netzteil”
3. Messen, 30 Minuten
4. Verdacht verwerfen, „Nicht das Netzteil”
5. Neuen Verdacht aufbauen, „Vielleicht die Stabilisierung”
6. Messen, 30 Minuten
7. Zurück auf Los, oft dreimal, bevor die Ursache gefunden wird

Mit Maschinellem Lernen auf Basis historischer Fehler lässt sich dieser Prozess auf Schritt 2 bis 3 reduzieren: Der Techniker sagt das Symptom, das System sagt mit 80–90 % Konfidenz „Wahrscheinlich der Sensor X”, und der Techniker testet gezielt, nicht blind.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Nach Trainingsphase mit 200+ realen Fällen, abhängig von Datenqualität und Fehlervielfalt.

Die Zeitersparnis ist gemessen an echten Servicedaten aus Unternehmen mit implementierter Fehlerdiagnose. Die First-Fix-Rate-Verbesserung ist konservativ geschätzt, einzelne Implementierungen berichten von Verbesserungen auf 92–95 %.

Einschätzung auf einen Blick

Zeitersparnis, hoch (4/5) Pro Einsatz sparen Techniker durchschnittlich 1–2 Stunden, das ist der Unterschied zwischen gezielter Messung und blindem Ausschlussverfahren. Eine Serviceorganisation mit zehn Technikern und fünfzig Einsätzen am Tag setzt so 50–100 Stunden Diagnosezeit frei, die entweder in schnellere Reparaturen oder in zusätzliche Einsätze fließen können. Keine Fünf, weil ein Teil der Einsparung an der Datenqualität hängt, mit lückenhaften Fehlerprotokollen schrumpft der Effekt auf 30–50 %.

Kosteneinsparung, mittel (3/5) Die Einrichtungskosten liegen bei 30.000–105.000 EUR, der Nutzen entsteht über zwei Kanäle: weniger Nacharbeiten bedeutet weniger verschenkte Servicekapazität, bessere First-Fix-Rate bedeutet zufriedenere Kunden und weniger Reklamationen. Bei einer Organisation mit 5+ Technikern amortisiert sich das System innerhalb von 12–18 Monaten, darunter lohnt es sich kaum.

Schnelle Umsetzung, niedrig (2/5) Das System ist nicht schnell einsatzbereit. Du brauchst 200–500 dokumentierte historische Fehler mit vollständiger Diagnose, bevor das Modell zuverlässig trainiert ist. Das sind typischerweise 4–6 Monate nur der Datensammlung, ohne dass das System produktiv ist. Danach noch 2–3 Monate Modelltraining und Tests. Schnelle Einstiege (wenige Wochen) gibt es nur mit vorgefertigten Modellen für Standard-Anlagentypen, die du in deine Umgebung adaptierst.

ROI-Sicherheit, mittel (3/5) Der Nutzen ist messbar, aber latent: Weniger Zeitverschwendung ist nicht dasselbe wie neue Umsätze, es ist Effizienzgewinn. Die ROI-Rechnung funktioniert nur, wenn die eingesparte Diagnosezeit in tatsächlich weniger Kosten oder mehr Servicekapazität für neue Aufträge übersetzt wird. Unternehmen, die Servicetechniker freigeben, weil die Diagnosen schneller gehen, sehen ROI. Unternehmen, die die gleiche Mannschaft einfach mehr Einsätze machen lassen, sehen weniger direkt.

Skalierbarkeit, hoch (4/5) Das System skaliert gut mit neuen Anlagentypen, aber nicht automatisch. Jeder neue Anlagentyp braucht sein eigenes Trainings-Dataset. Ein Hersteller, der zehn verschiedene Schaltanlagentypen repariert, braucht zehn separate Modelle oder ein Meta-Modell, das über Anlagen generalisiert, das ist Zusatzaufwand. Mit zunehmend mehr dokumentierten Fällen wird das System genauer und robuster, ohne dass die Lizenzkosten steigen.

Richtwerte, stark abhängig von Fehlervielfalt, Datenqualität und Komplexität der Anlagen.

Was ML-gestützte Fehlerdiagnose konkret macht

Das System analysiert Messwertverläufe, Fehlerprotokolle und Betriebsdaten einer Anlage und vergleicht diese mit tausenden dokumentierten historischen Fällen. Ein Machine-Learning-Modell, typischerweise auf Basis von Random Forest, Gradient Boosting oder neuronalen Netzen, lernt dabei Muster: „Wenn die Spannung im Moment des Ausfalls unter 150V liegt UND die Stabilisierungslatenz über 2ms ist, dann ist es zu 87 % der Sensor-X-Fehler, nicht der Trafo.”

Wichtig: Das System macht keine Vorhersagen aus erfundenen Daten, es vergleicht das aktuelle Symptom mit dokumentierten Ähnlichkeiten aus der Vergangenheit. Das funktioniert nur, wenn die Fehler sauber dokumentiert sind: Was war das Symptom? Welche Messwerte? Was war die tatsächliche Ursache?

So funktioniert der praktische Ablauf

1. Techniker erfasst das Symptom, über ein Tablet oder Sprachnotiz: „Schaltanlage springt aus, LED-Code 0x14, Spannungsmessung zeigt 210V statt 230V steady-state.”
2. System sucht ähnliche historische Fälle, und findet die zehn ähnlichsten Fehlerfälle der letzten drei Jahre.
3. System schlägt Diagnoseweg vor, mit Konfidenzwerten: „91 % Match mit historischem Fall [2024-03-15]: Spannungssensor defekt. Teste erst Sensorausgang (Pin 3 sollte 5V sein), dann Sensor selbst.”
4. Techniker testet gezielt, statt blind durchzuprobieren.
5. Diagnose bestätigt oder falsifiziert, und das neue Ergebnis wird sofort ins System zurückfließen, zur Verbesserung des Modells.

Das ist Retrieval-Augmented Diagnosis, das System erinnert sich an ähnliche Probleme, statt neue Diagnosen zu erfinden.

Konkrete Werkzeuge, was wann passt

Für ML-gestützte Fehlerdiagnose brauchst du typischerweise drei Komponenten:

• Eine Plattform zur Fehler-Datenerfassung, strukturiertes Logging historischer Fehler
• Ein ML-Framework zum Modelltraining, oder ein vorgefertigtes Diagnose-Tool
• Ein Frontend für den Techniker, einfach genug für den Serviceeinsatz, nicht kompliziert wie ein Datenwissenschaftler-Notebook

ServiceNow, Wenn ihr bereits ServiceNow für Incident Management nutzt, hat die Plattform ein integriertes Predictive Intelligence-Modul, das aus historischen Tickets Muster lernt. Das funktioniert eher für IT-Incidents als für Elektrotechnik-Spezialfehler, aber als Startpunkt praktisch.

Eigenentwicklung mit Python + scikit-learn oder TensorFlow, Für spezialisierte Elektrotechnik-Fehlerdiagnose: Du sammelst deine historischen Fehler in einer Datenbank, trainierst ein Modell lokal oder in der Cloud (Azure ML, AWS SageMaker), und baust ein einfaches Web-Frontend mit Flask oder FastAPI, das deine Techniker auf dem Tablet nutzen können. Das ist der flexible Weg, kostet Entwicklerzeit, ist aber vollständig anpassbar an deine Fehlertypen und Anlagentypen.

Augury oder ähnliche spezialisierte Predictive-Maintenance-Lösungen, konzipiert für Rotationsmaschinen und Pumpen, lassen sich aber auf Elektrotechnik erweitern. Kosten typischerweise 5.000–20.000 Euro pro Jahr. Weniger Einrichtungsaufwand als eine Eigenentwicklung, dafür weniger anpassbar auf eure spezifischen Fehlertypen.

Wichtig: Ohne strukturierte historische Fehler funktioniert kein System. Der größte Aufwand liegt in der Datenvorbereitung, Fehler zusammentragen, dokumentieren, labeln. Erst danach kommt das Modelltraining.

Datenschutz und Datenhaltung

Fehlerprotokolle können sensible Anlagendaten enthalten, Betriebsparameter, die Konkurrenten nicht sehen sollen, oder Kundendaten, wenn die Anlage beim Kunden steht. Wichtig:

• Cloud-Training: Wenn das Modell in der Cloud trainiert wird (Azure Machine Learning, AWS SageMaker), müssen die Daten über einen AVV vertraglich abgesichert sein. Für regulierte Kundenbranchen (Energie, Pharma, Medizintechnik) ist EU-Hosting Pflicht.
• On-Premise-Training: Bei einer Eigenentwicklung könnt ihr das Modell auf eigenen Servern trainieren und betreiben, keine Cloud, keine AVV-Frage. Das ist konservativer, kostet aber eigene Infrastruktur.
• Pseudonymisierung: Fehlerdaten gehören vor dem Training von Anlagen-IDs und Kundenangaben bereinigt. Die Ursache ist die relevante Information, die Kundennummer nicht.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten:

• Datenerfassung & Bereinigung: 5.000–15.000 EUR (2–4 Wochen Aufwand, intern oder extern)
• Modelltraining & Validierung: 10.000–40.000 EUR (abhängig von ML-Framework und Anlagenkomplexität)
• Frontend-Entwicklung (Tablet-App, Web-Interface): 15.000–50.000 EUR für produktionsreife Lösung
• Summe: 30.000–105.000 EUR, typischer Mittelwert 50.000–70.000 EUR

Laufende Kosten (monatlich):

• Cloudkosten für Modellhosting & Inferenz: 500–2.000 EUR/Monat (AWS, Azure)
• Oder: On-Premise-Server mit Wartung: 1.000–3.000 EUR/Monat
• Modell-Retraining (monatlich oder quartalsweise mit neuen Fehler-Daten): 2.000–5.000 EUR pro Retraining

Wie du den Nutzen tatsächlich misst:

• First-Fix-Rate vorher-nachher: Zähle vor und nach, wie viele Einsätze ohne Nacharbeiten erfolgen. Verbesserung von 65 % auf 85 % = 20 Prozentpunkte × durchschn. Servicegebühr pro Nacharbeit.
• Diagnosezeit reduziert: Durchschnittliche Diagnosezeit Monat davor vs. danach. Bei 10 Stunden Ersparnis pro Techniker und Monat × Bruttostundensatz = direkte Einsparung.
• Beispiel: 5 Techniker, Durchschnitt 8 Einsätze/Monat. Wenn First-Fix-Rate von 65 % auf 85 % steigt, das sind 20 Nacharbeiten/Monat weniger × 250 EUR Servicegebühr = 5.000 EUR/Monat Nutzen. Nach ca. 10–15 Monaten ist das System rentabel.

Drei typische Einstiegsfehler

1. Mit unvollständigen Fehlerprotokollen starten. Viele Unternehmen haben 10 Jahre historische Fehler, aber die Daten sind inkonsistent: Mal ist die Ursache dokumentiert, mal nicht. Mal sind Messwerte dabei, mal nicht. Das System lernt gut, aber braucht mindestens 60–70 % vollständig dokumentierte Fälle pro Fehlertyp. Lösung: Nicht warten, bis alles perfekt ist, ausmisten, dann mit den besten 70 % starten.

2. Zu viele Anlagentypen gleichzeitig trainieren. Der Versuch, alle Service-Anlagentypen in ein einziges Modell zu packen, Schaltanlagen, Stromverteiler, Frequenzumrichter, Steuerungen zusammen, führt zu einem Modell, das für keinen Typ wirklich gut ist, weil die Fehlerlogik fundamental unterschiedlich ist. Was hilft: Mit dem häufigsten Anlagentyp starten (der über 50 % der Einsätze abdeckt), dort trainieren, validieren, produktiv nehmen. Erst danach die nächsten Anlagentypen nachziehen.

3. Modell trainiert, aber nicht gepflegt, und ohne Rückmeldung. Zwei Fehler, die meistens zusammen auftreten: Nach dem Start wird das Modell nicht regelmäßig mit frischen Fehlerdaten aktualisiert, und parallel gibt es keine Schleife, über die Techniker falsche Vorhersagen korrigieren. Nach zwölf Monaten empfiehlt das System noch die Ursachen von gestern, neue Anlagenrevisionen und neue Fehlertypen sind nicht abgebildet. Was hilft: Retraining mindestens monatlich, mit Versionierung (v1 Januar, v2 März). Und in der Techniker-App ein simpler Button “Diagnose war falsch, tatsächliche Ursache war …”, diese Rückmeldungen fließen beim nächsten Training direkt ein.

Was mit der Einführung wirklich passiert, und was nicht

Das System geht live, und dann passiert zunächst wenig. Nicht weil die Technik schlecht ist, sondern weil Techniker neuen Werkzeugen misstrauen, die ihnen sagen, was sie tun sollen. Das Muster ist vorhersehbar:

Widerstand Pattern 1, „Ich weiß das eh schon.” Erfahrene Techniker mit 10+ Jahren Berufserfahrung klicken das System durch, ignorieren den Vorschlag und machen es so, wie sie es immer gemacht haben. Das ist kein Sabotage, das ist berechtigtes Vertrauen in die eigene Erfahrung. Gegenmittel: Das System nicht als Ersatz für Erfahrung positionieren, sondern als schnelle Gedächtnisstütze für seltene Fehlertypen. Die meisten erfahrenen Techniker kennen die häufigen 80 %, das System hilft bei den anderen 20 %.

Widerstand Pattern 2, „Das hat wieder falsch gelegen.” Die ersten Wochen produziert das System Vorhersagen mit 60–70 % Genauigkeit. Das reicht für Ablehnung. Techniker berichten dem Teamleiter, das System tauge nichts. Was tatsächlich passiert: Das Modell ist noch nicht ausreichend kalibriert. Das Frühwarnsystem dafür ist der Konfidenzwert, Vorhersagen unter 70 % Konfidenz sollten in dieser Phase nicht als definitive Empfehlung, sondern als Hinweis präsentiert werden. Im UI-Design macht das einen erheblichen Unterschied.

Was nicht passiert: Die Technikermannschaft löst sich nicht auf. Erfahrene Techniker werden nicht redundant, ihre Expertise fließt ins Modell ein. Was sich ändert: Neue Techniker werden schneller produktiv, weil sie vom expliziten Wissen der Erfahrenen profitieren, ohne jahrelang danebenstehen zu müssen.

Das System ändert nichts an der Arbeit. Es ändert, wo man anfängt.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Unsere Fehler sind alle unterschiedlich, Muster gibt es nicht.” Das stimmt nie. Auch bei scheinbar zufälligen Ausfällen gibt es 80–90 Prozent Redundanz, die gleichen fünf bis zehn Fehlertypen dominieren. Die scheinbare Varianz kommt aus schlechter Dokumentation, nicht aus echter Komplexität.

„Das kostet 50.000 EUR und wir sind klein. Für uns lohnt sich das nicht.” Richtig für Unternehmen mit 1–2 Technikern. Falsch ab 3+ Technikern mit regelmäßiger Diagnosearbeit. Bei 5 Technikern, 20 Einsätze/Monat, 2 Stunden Zeitersparnis pro Einsatz, Bruttostundensatz 35 EUR = 100 × 2 × 35 = 7.000 EUR/Monat Nutzen. Das amortisiert sich in ~8 Monaten, danach reiner Gewinn. Investiere früh genug.

„Aber was, wenn die KI eine falsche Diagnose vorschlägt?” Das passiert, bei schlechtem Modelltraining. Aber das ist kein Grund, das System nicht zu bauen. Die schlechte Diagnose des Systems ist meist besser als das blinde Raten des Technikers. Und eine falsche Vorhersage mit Konfidenzwert („Zu 52 % Fehler X”) ist transparenter als keine Unterstützung.

Woran du merkst, dass das zu dir passt

• Du hast ein Serviceteam mit 3+ Technikern und bekommst regelmäßig Einsätze, die nicht beim ersten Mal gelöst werden.
• Deine Fehlerquellen sind dokumentiert, du weißt, welche Fehler in den letzten 2 Jahren am häufigsten auftraten.
• Diagnosezeit ist ein echtes Kostenproblem, entweder zu lange Einsätze pro Kunde, oder zu viele Techniker-Stunden auf Diagnose statt Reparatur.
• Du hast mehrere Kunden mit ähnlichen Anlagen, damit sich die Trainings-Datenbasis schneller aufbaut.
• Dein Team ist grundsätzlich digital-affin, das System funktioniert nur, wenn Techniker die Tablet-App akzeptieren und Fehler damit dokumentieren.

Wann es sich (noch) nicht lohnt, drei harte Ausschlusskriterien:

1. Weniger als 100 dokumentierte Fehler in den letzten 2 Jahren. Dann ist die Fehler-Vielfalt zu klein und das System kann keine sicheren Muster lernen. Erst Fehlererfassung professionalisieren, dann KI.

2. Die Fehler sind dokumentiert, aber chaotisch, verschiedene Formate, verschiedene Klassifikationen, keine Messwerte dabei. Der Aufräumaufwand übersteigt dann den Nutzen.

3. Keine dedizierte Person, die sich um das Modell kümmert, Retraining, Monitoring auf sinkende Accuracy, Feedback-Integration. Ein vernachlässigtes System wird mit der Zeit schlechter, nicht besser.

Das kannst du heute noch tun

Öffne eine Tabelle und sammele deine letzten 20 Service-Einsätze auf. Schreibe auf: Was war das Symptom? Was waren die Messwerte? Was war die tatsächliche Fehlerursache? Was hat der Techniker zuerst getestet, bevor er die richtige Ursache fand?

Das sind 15–20 Minuten. Was du danach weißt: Ist dein Fehler-Dokumentationslevel gut genug, um mit einem System zu starten? Wenn jeder Fehler 3+ Sätze hat, mit Messwerten und Ursache, dann ja. Wenn viele Einträge „Fehler behoben” heißen, ohne Details, dann musst du erst dokumentieren.

Danach kannst du ein einfaches KI-System selbst bauen. Hier ist ein Prompt, der deine ersten Trainingsdaten analysiert:

Quellen & Methodik

• First-Fix-Rate & Diagnosezeit: Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Erhebung „Serviceeffektivität in der Industrie” (2023); Fokus auf Elektrotechnik und Maschinenbau (Deutschland).
• Machine Learning für Fehlerdiagnose: MDPI Sensors Journal, „A Review of Artificial Intelligence Techniques in Fault Diagnosis of Electric Machines” (2024), Übersicht über praktische Implementierungen mit Random Forest, Gradient Boosting, neuronalen Netzen.
• Techniker-Erfahrungsjahre: Eigene Erhebungen bei Unternehmen mit implementierter ML-Fehlerdiagnose (April 2026), Vergleich neuer vs. erfahrener Techniker mit Systemunterstützung.
• Kostenangaben: Marktstandards für Azure Machine Learning, AWS SageMaker und Eigenentwicklung (Stand 2026); basierend auf realen Projektbudgets aus der Branche.