Wartungsberichte mit KI auswerten: Was in Ihren Freitextfeldern steckt
- Veröffentlicht:
- Lesezeit
- 15 Min. Lesezeit
- Autor:
- Abbas Mohammadi
Wartungsberichte mit KI auswerten heißt in der Praxis: den Freitext aus Störmeldungen, Auftragsrückmeldungen und Schichtbüchern so aufbereiten, dass daraus abfragbare Zeilen werden – welche Anlage, welches Bauteil, welches Symptom, welche Maßnahme. Der Großteil der Arbeit steckt nicht im Sprachmodell, sondern in der Zuordnung uneinheitlicher Anlagenbezeichnungen, im Auflösen von Abkürzungen und in einem stabilen Klassenschema. Wer das sauber macht, kann seine Störungshistorie auswerten, ohne einen einzigen neuen Sensor zu installieren.
Was in Ihren Freitextfeldern tatsächlich steht
In den Freitextfeldern stehen Symptome, Ursachen und Maßnahmen – im Telegrammstil, mit Abkürzungen und in der Sprache der jeweiligen Schicht. Wer Instandhaltungsdaten im Freitext analysieren oder gezielt CMMS-Freitextfelder auswerten will, sollte zuerst wissen, aus welchen Systemen sie stammen, denn der Aufbereitungsaufwand unterscheidet sich je Quelle erheblich. Die wertvollste Quelle ist selten die am besten gepflegte.
Diese Einschätzung ist nicht neu. Forscher des US-amerikanischen National Institute of Standards and Technology (NIST) hielten 2019 fest, dass trotz günstiger Sensorik der Großteil des Wissens über einen Instandhaltungsprozess in historischen Arbeitsaufträgen steckt – und dass es für deren Erfassung, Bereinigung und Auswertung kaum Standards gibt:
Despite a surge in availability for low-cost sensing and data processing generally, the bulk of available knowledge on any given maintenance workflow will currently exist within historical records, via Maintenance Work-Orders (MWOs).
| Quelle | Typischer Inhalt | Typische Störfaktoren | Aufwand |
|---|---|---|---|
| Störmeldung (CMMS/EAM) | Symptom, grobe Ortsangabe, Dringlichkeit | Telegrammstil, Anlage als Spitzname, Copy-Paste aus der Vormeldung | mittel |
| Auftragsrückmeldung | Maßnahme, Ersatzteil, Zeitaufwand | Pflichtfeld mit „erledigt“ gefüllt, Ursache fehlt, Personalnummer im Text | hoch |
| Schichtbuch | Beobachtungen, Provisorien, Hinweise an die Folgeschicht | Keine Anlagenreferenz, mehrere Themen pro Eintrag, Umgangssprache | hoch |
| Serviceprotokoll des Herstellers | Befund, getauschte Teile, Firmware | Fremdes Vokabular, Seriennummer statt Anlagennummer, Englisch | hoch |
Wie solche Einträge aussehen, zeigt Tabelle 02. Die Beispiele sind frei konstruiert und stammen nicht aus realen Beständen; sie bündeln nur die Muster, die in fast jedem Schichtbuch auftauchen: Abkürzungen ohne Lexikon, Sprachmischung, fehlende Anlagenreferenz, Übernahme des Vorgängertextes.
| Konstruierter Eintrag | Eigenheit | Was die Auswertung daraus braucht |
|---|---|---|
| „L3 stopper klemmt wieder, kurz gängig gemacht“ | Spitzname der Anlage, „wieder“ verweist auf Vorgeschichte, Provisorium | Anlage = Stopper an Linie 3, Symptom = klemmt, Maßnahme = provisorisch |
| „Mot. Förderb. 2 zu heiß, Lgr. getauscht, s. Auftr. 4711“ | Abkürzungen, Auftragsverweis, Ersatzteil nur implizit | Bauteil = Lager Motor Förderband 2, Maßnahme = Tausch, Verknüpfung Auftrag 4711 |
| „Same as yesterday, reset done“ | Englisch, ohne Anlage, nur mit dem Vortag lesbar | Verknüpfung über Zeitstempel und Meldeort, sonst nicht auswertbar |
Warum die Auswertung an den Stammdaten scheitert, nicht am Modell
Die Auswertung scheitert in der Regel daran, dass ein Text keiner Anlage zugeordnet werden kann – nicht daran, dass ein Modell den Text nicht versteht. Dieselbe Verpackungslinie heißt im ERP AN-4711, im CMMS Linie 3, im Schichtbuch „die Dreier“, im Serviceprotokoll nach der Seriennummer und in der SPS nach dem Stationsnamen. Jede Häufigkeitsauswertung, die diese fünf Namen als fünf Anlagen zählt, ist wertlos – unabhängig von der Qualität des Sprachmodells.
Wie stark solche Datenqualitätsprobleme durchschlagen, untersucht eine NIST-Fallstudie von 2021 an historischen Arbeitsaufträgen aus der Gebäudetechnik: Typische menschliche Eingabefehler in Textfeldern sind nach Schätzung der Autoren stark nicht zufällig verteilt und verursachen selbst bei großen Stichproben große Fehler in der Kennzahlenberechnung. Mehr Daten heilen das Problem also nicht; nur Bereinigung tut es, und die beginnt bei der Anlagenreferenz.
Das Werkzeug dafür ist eine Normalisierungstabelle: pro Quellsystem der Rohwert, wie er tatsächlich vorkommt, und die Zielbezeichnung in der Anlagenhierarchie. Diese Tabelle pflegt die Instandhaltung, nicht die IT, denn nur dort ist bekannt, dass „Presse alt“ seit dem Umbau die Station 220 bezeichnet. Rechnen Sie mit einigen hundert Zeilen je Anlagengruppe; der Aufbau dauert Tage, nicht Wochen.
| Quellsystem | Rohwert (wie er vorkommt) | Zielbezeichnung | Ebene |
|---|---|---|---|
| CMMS | Linie 3 | PL-03 | Linie |
| Schichtbuch | die Dreier / L3 / Dreierlinie | PL-03 | Linie |
| Schichtbuch | L3 stopper | PL-03-ST-04 | Station |
| ERP | AN-4711 | PL-03-ST-04 | Station |
| Serviceprotokoll | SN 88213-B | PL-03-ST-04-M1 | Bauteil |
Für die Zielseite empfiehlt sich ein gemeinsames Vokabular. DIN EN 13306:2018-02 („Instandhaltung – Begriffe der Instandhaltung“) definiert die Begriffe der Instandhaltung dreisprachig auf 97 Seiten und ist die naheliegende Referenz, wenn Betreiber, Dienstleister und Auswertung dieselben Wörter für dieselben Dinge verwenden sollen. Die Norm ist kostenpflichtig; entscheidend ist, dass ein genormtes Begriffsgerüst existiert und Sie Ihr Klassenschema nicht von Null erfinden müssen. Für die Hierarchieebene gilt: immer auf die feinste sicher belegbare Ebene abbilden und die gröberen daraus ableiten – eine Meldung, die nur „Linie 3“ nennt, bleibt auf Linienebene und wird nicht geraten.
Die Verarbeitungskette: von der Störmeldung zur auswertbaren Zeile
Von der Störmeldung zur auswertbaren Zeile führen fünf Schritte, und für jeden gibt es ein Verfahren, das gerade ausreicht. Die Faustregel: Regeln, wo der Input stabil ist; ein kleines trainiertes Modell, wo es viele ähnliche Sätze und ein festes Zielschema gibt; ein Large Language Model (LLM) nur dort, wo Formulierungen unvorhersehbar sind und der Kontext den Ausschlag gibt. Forscher des NIST fassen diese domänenspezifische Aufbereitung technischer Freitexte unter dem Begriff Technical Language Processing (TLP): Brundage et al. beschreiben ihn 2020 in Manufacturing Letters als ganzheitlichen, domänengetriebenen Ansatz und halten fest, dass Standard-NLP-Pipelines für die Anforderungen der Ingenieurpraxis neu gedacht werden müssen.
Bereinigung
Signaturen, Kopfzeilen, Dubletten und Copy-Paste-Blöcke aus der Vormeldung entfernen; Zeitstempel und Auftragsnummern in eigene Felder ziehen. Verfahren: Regeln und reguläre Ausdrücke – der Input ist formal stabil.
Sprach- und Abkürzungsauflösung
Ein Abkürzungslexikon je Werk („Lgr.“ = Lager, „FU“ = Frequenzumrichter) plus Ähnlichkeitssuche für die häufigsten Fachwörter. Ein kleines Modell nur, wenn dieselbe Abkürzung je Kontext Verschiedenes bedeutet („WT“ als Wärmetauscher oder Werkzeugträger).
Entitätserkennung
Anlage, Bauteil, Symptom, Maßnahme und Ersatzteil aus dem Text herauslösen (Named Entity Recognition, NER). Bei stabilem Vokabular ein kleines, auf einigen hundert markierten Meldungen trainiertes Modell; ein LLM bei offenem Vokabular oder gemischten Sprachen.
Klassifikation nach Fehlerbild
Jede Meldung einer Klasse aus einem festen Schema zuordnen (mechanisch – Verschleiß, elektrisch – Sensorik, Bedienung, Fremdeinwirkung), mit Konfidenz; alles unter der Schwelle geht in die manuelle Prüfung. Verfahren: siehe Entscheidungstabelle.
Verknüpfung
Die klassifizierte Zeile mit Auftragsdaten (Dauer, Kosten, gebuchtes Ersatzteil) und Stillstandsdaten aus BDE oder MDE verbinden – ein Datenbank-Join über normalisierte Anlagen-ID und Zeitstempel. Erst dieser Schritt macht aus Text eine Kennzahl.
Am Ende steht pro Meldung eine Zeile mit festen Spalten: Anlage (normalisiert), Bauteil, Symptom, Maßnahme, Ersatzteil, Fehlerklasse, Auftragsnummer, Stillstandsdauer, Datum, Konfidenz und Originaltext. Die letzte Spalte ist keine Nebensache: Jede Auswertung muss auf den Originaltext zurückführen, sonst kann niemand eine falsche Klassifikation erkennen.
Störmeldungen klassifizieren: Regeln, kleines Modell oder LLM?
Ob Regeln, ein kleines Modell oder ein LLM die Störmeldungen mit KI klassifizieren sollen, entscheiden vier Größen: die Zahl der Klassen, die Zahl der vorhandenen Meldungen, die Stabilität des Klassenschemas und die Prüfpflicht – also ob jede Zuordnung für einen Menschen nachvollziehbar sein muss, etwa weil sie in eine Verfügbarkeitsabrechnung mit dem Maschinenlieferanten eingeht.
| Kriterium | Regeln / Schlagwortlisten | Kleines, trainiertes Modell | LLM (Zero- oder Few-Shot) |
|---|---|---|---|
| Zahl der Klassen | bis etwa 10, klar trennbar | 10–50, mit Beispielen belegbar | beliebig, auch offene Klassen |
| Vorhandene Meldungen | beliebig | einige hundert markierte je Klasse | auch sehr wenige |
| Stabilität des Schemas | muss fest sein | fest; Nachtraining bei Änderung | Änderung per Anweisung |
| Formulierungsvielfalt | gering | mittel, werksinternes Vokabular | hoch, gemischte Sprachen |
| Nachvollziehbarkeit | vollständig, Regel ist lesbar | über Konfidenz und Beispiele | nur über Begründungstext |
| Kosten und Betrieb | vernachlässigbar, überall | gering nach Training, gewöhnlicher Server | je Meldung erneut, GPU oder externer Dienst |
Für den mittleren Fall – viele Meldungen, festes Schema – spricht auch die Forschungsdiskussion. Belcak et al. (NVIDIA Research, 2025) argumentieren, dass kleine Sprachmodelle für spezialisierte Aufgaben, die wiederholt und mit geringer Variation ausgeführt werden, hinreichend leistungsfähig, besser geeignet und wirtschaftlicher seien als Allzweck-LLMs; wo Konversation nötig ist, empfehlen sie heterogene Systeme aus mehreren Modellen. Genau das beschreibt eine Störmeldungsklassifikation. Was der Betrieb solcher Modelle im eigenen Haus erfordert, steht in LLM on premise im Industriebetrieb.
Ein LLM bleibt trotzdem nützlich – als Erstklassifizierer in der Aufbauphase. Ein bewährtes Muster: Das LLM labelt einige tausend historische Meldungen, ein Fachmann korrigiert eine Stichprobe, und mit den korrigierten Labels wird das kleine Modell trainiert, das dauerhaft läuft. So fallen die LLM-Kosten einmal an, und das Ergebnis bleibt reproduzierbar, auch wenn der externe Dienst sein Modell wechselt.
Wartungsberichte mit KI auswerten: Welche Fragen sich danach beantworten lassen
Wer Wartungsberichte mit KI auswerten lässt, bekommt vor allem Antworten auf rückblickende Fragen – und die sind für die Instandhaltungsplanung wertvoller, als es klingt: die häufigsten Fehlerbilder je Anlagengruppe, Maßnahmen ohne dauerhafte Wirkung, Ersatzteile mit auffälliger Wechselhäufigkeit, Symptome vor größeren Ausfällen und die Suche nach „schon mal dagewesen“. Die vollständige Liste von zehn Fragen steht im Pilotabschnitt.
Verknüpft mit den Stillstandsdaten wird daraus eine Verfügbarkeitsanalyse nach Ursache statt nach Bauchgefühl – vorausgesetzt, Stillstand und Verfügbarkeit sind im Haus einheitlich definiert; wie das gelingt, erklärt Anlagenverfügbarkeit berechnen nach VDI 3423. Die „Schon mal dagewesen“-Suche ist technisch dieselbe Aufgabe wie die Suche in Handbüchern und Zeichnungen; wie sich beide Bestände in einem System zusammenführen lassen, beschreibt KI für technische Dokumentation.
Datenschutz und Mitbestimmung: Freitext enthält Personen
Freitext enthält Personenbezug: Namen („Müller hat das Lager getauscht“), Personalnummern in der Rückmeldung, Schichtkürzel – und über die Verknüpfung mit Auftragsdaten auch einen Leistungsbezug. Das ist einzuordnen, bevor die erste Zeile indexiert wird. Dieser Abschnitt ist eine technische Einordnung, keine Rechtsberatung; die Bewertung im Einzelfall gehört zu Datenschutzbeauftragtem, Betriebsrat und gegebenenfalls Rechtsbeistand.
Die Datenschutzkonferenz (DSK) hat im Oktober 2025 eine Orientierungshilfe zu generativen KI-Systemen mit RAG-Methode veröffentlicht. Sie betrifft den Dokumenten-Index, ihre Regel für die Aufbereitung der Referenzdokumente gilt für Störmeldungen aber genauso:
Soweit personenbezogene Daten nicht erforderlich sind, sind personenbezogene Daten zu entfernen oder zu anonymisieren.
Die DSK nennt außerdem Mandantentrennung und ein Rechte- und Rollenkonzept als technische Mittel für die Zweckbindung und weist darauf hin, dass ein kleines Sprachmodell unter Umständen weniger personenbezogene Daten memoriert – bei unverändert geltenden Anforderungen. Was das für einen Dokumenten-Index bedeutet, steht in RAG auf eigenen Dokumenten und die DSK-Orientierungshilfe.
Neben dem Datenschutz steht die Mitbestimmung. § 87 Abs. 1 Nr. 6 BetrVG nennt als mitbestimmungspflichtig die „Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen“. Ob und wie das eine Textauswertung erfasst, ist eine arbeitsrechtliche Frage, die hier nicht beantwortet wird. Bewährt hat sich, den Betriebsrat vor dem Pilot mit einer schriftlichen Zweckbeschreibung einzubinden und Auswertungen auf Personenebene von vornherein auszuschließen.
Technische Maßnahmen vor der ersten Auswertung
- Namen, Personalnummern und Schichtkürzel vor der Indexierung durch Rollen ersetzen („Instandhalter“, „Schichtführer“); die Zuordnungstabelle getrennt und zugriffsbeschränkt halten.
- Auswertungen nur auf Anlagen-, Bauteil- und Fehlerklassenebene – keine Gruppierung nach Person, Schicht oder Team.
- Zweck schriftlich festhalten: Störungsanalyse und Wissenssuche, nicht Leistungsbeurteilung.
- Rechte- und Rollenkonzept sowie Löschkonzept für Originaltexte und Index, abgestimmt auf bestehende Aufbewahrungsfristen.
- Betriebsrat und Datenschutzbeauftragten vor dem Pilot einbinden, nicht nach dem ersten Dashboard.
Wissenssicherung vor dem Renteneintritt
Der größte Nutzen liegt nicht in der Auswertung des Bestands, sondern darin, dass die Wissenssicherung in der Instandhaltung überhaupt eine Struktur bekommt. Was ein Instandhalter nach 30 Jahren an einer Anlage weiß – welches Geräusch welchem Lager vorausgeht, welche Einstellung nach dem Werkzeugwechsel nachgezogen werden muss – steht selten im System. Es steht, wenn überhaupt, verkürzt in seinen Meldungen. Geht er, bleiben die Meldungen, aber ihr Kontext geht mit.
Die Textauswertung macht sichtbar, wo dieser Kontext fehlt: Anlagen mit vielen Meldungen und wenigen erkannten Ursachen, Maßnahmen ohne Begründung, Symptome, die nur eine Person je gemeldet hat. Dort lohnt sich gezielte Nacherfassung, solange die Person noch im Haus ist:
Nacherfassung ausgewählter Störungsfälle
Die 20 teuersten oder häufigsten Störungen je Anlagengruppe mit dem erfahrenen Instandhalter in je 15 Minuten durchgehen: tatsächliche Ursache, woran er sie erkannt hat, was sie verhindert hätte. Die Antworten werden strukturiert an die Originalmeldung gehängt.
Geführte Freitextfelder
Ein Feld „Beschreibung“ wird zu drei Feldern: Symptom (was wurde beobachtet), Ursache (was war es), Maßnahme (was wurde getan). Die Trennung zwingt zur Unterscheidung von Beobachtung und Diagnose – der häufigsten Verwechslung im Bestand.
Pflichtfelder mit Auswahlliste
Ursache und Maßnahme werden beim Auftragsabschluss Pflicht, mit Auswahlliste aus dem Klassenschema und Freitext für „Sonstiges“. Damit verbessert sich jede künftige Auswertung, und das Modell bekommt laufend korrekt markierte Trainingsdaten.
Dasselbe gilt für das Schichtbuch. Wer Schichtnotizen digital auswerten will, braucht dort mindestens eine Anlagenreferenz pro Eintrag und eine Trennung von Beobachtung und Auftrag an die Folgeschicht. Welche Felder ein Schichtbuch dafür braucht, steht in Digitale Schichtübergabe: Welche Felder ein Schichtbuch braucht.
Ein Pilot, der sich in vier Wochen bewerten lässt
Ein Pilot lässt sich in vier Wochen bewerten, wenn er eng zugeschnitten ist: eine Anlagengruppe, 24 Monate Historie, zehn vorab definierte Auswertungsfragen. Woche 1 gehört Export, Normalisierungstabelle, Abkürzungslexikon und Pseudonymisierung; Woche 2 dem Klassenschema und 300 manuell markierten Meldungen; Woche 3 der Verknüpfung und den zehn Fragen; Woche 4 der Prüfung. Abnahmekriterium ist nicht die Modellgüte, sondern ob die Instandhaltung die Ergebnisse ohne Nacharbeit benutzen würde.
- Welche fünf Fehlerklassen verursachen die meisten Meldungen je Anlage der Gruppe?
- Welche fünf verursachen die meisten Stillstandsminuten – und weichen sie von Frage 1 ab?
- An welchen Anlagen tritt dasselbe Symptom innerhalb von 30 Tagen erneut auf?
- Welche Maßnahmen wurden am häufigsten ohne dokumentierte Ursache abgeschlossen?
- Welche Ersatzteile wurden je Anlage häufiger getauscht als im Mittel der baugleichen Anlagen?
- Welche Symptome wurden in den 14 Tagen vor den fünf längsten Stillständen gemeldet?
- Welcher Anteil der Meldungen ließ sich keiner Anlage unterhalb der Linienebene zuordnen?
- Welcher Anteil der Meldungen liegt mit der Konfidenz unter der Prüfschwelle?
- Welche Meldungen der letzten 30 Tage haben eine ähnliche Vorgeschichte in der Historie?
- Welche Anlagen haben viele Meldungen, aber kaum dokumentierte Ursachen – wo fehlt Wissen?
Zur Prüfung zieht ein erfahrener Instandhalter 100 zufällige klassifizierte Meldungen und vergleicht sie mit dem Originaltext. Zählen Sie nicht nur Treffer, sondern die Fehlerart: Eine falsche Anlage ist ein Stammdatenproblem und billig zu beheben, eine falsche Klasse ein Schemaproblem und teurer. Ob danach ein eigenes Werkzeug entsteht oder das CMMS erweitert wird, entscheidet diese Verteilung; welche Aufgaben in der Instandhaltung typischerweise eine eigene Lösung rechtfertigen, zeigt Individualsoftware: 12 Anwendungsfälle in Fertigung und Instandhaltung.
Fazit: Der Textbestand ist der günstigere Einstieg
Wer Wartungsberichte mit KI auswerten will, sollte drei Viertel des Aufwands in Stammdaten, Abkürzungslexikon und Klassenschema stecken und ein Viertel in das Modell. Das Ergebnis ist eine Störungshistorie, die sich nach Anlage, Bauteil, Symptom und Maßnahme abfragen lässt – rückblickend, nachvollziehbar, ohne neue Sensorik. Es ist keine Ausfallvorhersage, aber die Grundlage, um zu entscheiden, wo sich Sensorik später lohnt, und der einzige Weg, das Wissen der erfahrenen Kollegen zu sichern, bevor es das Haus verlässt.
Beginnen Sie mit einer Anlagengruppe, 24 Monaten Historie und zehn Fragen, und lassen Sie das Ergebnis von der Instandhaltung abnehmen, nicht von der IT. Wenn Sie den Zuschnitt eines solchen Pilots mit jemandem durchsprechen möchten, der die Aufbereitung technischer Freitexte kennt, finden Sie unter KI-Lösungen für technische Dokumente, wie ralwo dabei unterstützt.
Häufige Fragen
Quellen
- DIN EN 13306:2018-02 – Instandhaltung – Begriffe der Instandhaltung; Dreisprachige Fassung EN 13306:2017 — DIN Media
- Standards Needs for Maintenance Work Order Analysis in Manufacturing — National Institute of Standards and Technology (NIST)
- Technical Language Processing: Unlocking Maintenance Knowledge — National Institute of Standards and Technology (NIST) / Manufacturing Letters
- The Impact of Data Quality on Maintenance Work Order Analysis: A Case Study in Historical HVAC Maintenance Work Orders — National Institute of Standards and Technology (NIST)
- Small Language Models are the Future of Agentic AI — arXiv (Belcak et al., NVIDIA Research)
- Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode, Version 1.0 — Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK)
- § 87 BetrVG – Mitbestimmungsrechte — Bundesministerium der Justiz / gesetze-im-internet.de