Sprachbasierte Störmeldungen einführen: Von der Idee bis zum strukturierten SAP-PM-Ticket

Eine Störung tritt auf, die Produktion steht und der Techniker braucht schnell verwertbare Informationen. In vielen Betrieben beginnt an diesem Punkt jedoch ein umständlicher Prozess: Jemand sucht einen PC, meldet sich in SAP an, öffnet eine Maske und versucht, den Fehler zwischen Zeitdruck und laufender Produktion zu beschreiben. Häufig bleibt am Ende nur eine Meldung wie „Maschine kaputt“ oder „Pumpe defekt“.

Für die Instandhaltung reicht das nicht. Es fehlen Angaben zur betroffenen Anlage, zum Fehlerbild, zu bereits durchgeführten Prüfungen, zur Dringlichkeit oder zu Sicherheitsrisiken. Die Folge sind Rückfragen, unnötige Wege und längere Behebungszeiten.

Sprachbasierte Störmeldungen setzen genau hier an. Mitarbeitende beschreiben die Situation dort, wo sie entsteht. Ein digitaler Assistent führt durch die Meldung, fragt fehlende Informationen gezielt nach und übergibt das Ergebnis strukturiert an SAP PM oder ein anderes Instandhaltungssystem.

Dieser Leitfaden zeigt, wie Industriebetriebe einen solchen Voice-to-Ticket-Prozess praxisnah einführen – von der Hardwareauswahl über die Systemintegration bis zur Schulung der Mitarbeitenden.

Sprachbasiert bedeutet mehr als Diktieren

Eine reine Spracheingabe löst das Problem unvollständiger Störmeldungen noch nicht. Sie ersetzt lediglich die Tastatur durch ein Mikrofon. Wird aus „Maschine kaputt“ nur transkribierter Text, bleibt die Informationsqualität unverändert.

Ein wirksamer Meldungsassistent übernimmt deshalb drei Aufgaben:

1. Erfassen: Er wandelt die gesprochene Beschreibung in Text um.
2. Strukturieren: Er ordnet Inhalte den benötigten Feldern und Kategorien zu.
3. Qualität sichern: Er erkennt fehlende Angaben und stellt gezielte Rückfragen.

Das Ziel ist nicht eine längere Meldung, sondern eine Meldung, mit der die Instandhaltung unmittelbar arbeiten kann.

Schritt 1: Mit einem klaren Prozess beginnen

Die Einführung sollte nicht mit der Auswahl einer KI-Lösung beginnen, sondern mit der Frage:

An welcher Stelle verlieren wir heute Zeit oder Qualität bei der Störmeldung?

Dazu wird der bestehende Ablauf vom Auftreten der Störung bis zur fertigen Instandhaltungsmeldung aufgenommen. Relevant sind unter anderem:

• Wer erkennt und meldet die Störung?
• Auf welchem Weg wird sie heute erfasst?
• Welche Informationen fehlen regelmäßig?
• Wer muss Rückfragen stellen?
• In welchem System wird die Meldung gespeichert?
• Welche Felder sind technisch oder organisatorisch verpflichtend?
• Welche Unterschiede bestehen zwischen Schichten, Werken und Anlagentypen?

Für den Einstieg eignet sich ein klar abgegrenzter Anwendungsfall, beispielsweise Störmeldungen durch Produktionsmitarbeitende an einer ausgewählten Linie. Ein begrenzter Prozess lässt sich schneller testen und liefert belastbare Erkenntnisse für den späteren Rollout.

Geeignete Ausgangskennzahlen

Vor Beginn sollten wenige, messbare Kennzahlen erhoben werden:

• durchschnittliche Zeit zur Erstellung einer Meldung,
• Anteil unvollständiger Meldungen,
• Anzahl notwendiger Rückfragen,
• Zeit bis zur Annahme durch die Instandhaltung,
• Anteil der Meldungen mit korrekt zugeordnetem Equipment,
• Nutzung des vorgesehenen Meldewegs.

Ohne Ausgangswerte lässt sich später kaum beurteilen, ob die sprachbasierte Lösung tatsächlich einen Mehrwert erzeugt.

Schritt 2: Definieren, was eine gute Störmeldung enthalten muss

Bevor ein Sprachdialog entwickelt wird, muss das Zielbild feststehen. Welche Informationen benötigt ein Instandhalter, um die Situation zu bewerten und die nächsten Schritte einzuleiten?

Typische Bestandteile einer qualifizierten Störmeldung sind:

• Werk, Bereich oder Linie,
• technischer Platz beziehungsweise Equipment,
• betroffene Komponente,
• beobachtetes Fehlerbild,
• Zeitpunkt und Häufigkeit,
• Auswirkung auf Produktion oder Qualität,
• Dringlichkeit,
• mögliche Sicherheits- oder Umweltrisiken,
• bereits durchgeführte Prüfungen,
• Fotos, Videos oder Dokumente,
• meldende Person und Schicht.

Nicht jede Meldung benötigt jedes Feld. Der Dialog sollte sich dynamisch am Kontext orientieren. Wird beispielsweise eine Leckage gemeldet, sind Fragen zu Medium, Austrittsmenge und Sicherheitsrisiko wichtiger als bei einem defekten Sensor.

Stammdatenqualität nicht unterschätzen

Ein Sprachassistent kann nur dann zuverlässig zuordnen, wenn Anlagen, technische Plätze, Meldungsarten und Schadenscodes sinnvoll gepflegt sind. Vor dem Pilotprojekt sollte deshalb geprüft werden:

• Sind die relevanten Equipments eindeutig benannt?
• Gibt es mehrere Bezeichnungen für dieselbe Anlage?
• Verwenden Mitarbeitende Spitznamen oder lokale Begriffe?
• Sind Kataloge und Prioritäten verständlich aufgebaut?
• Welche Daten müssen aus SAP oder anderen Systemen bereitgestellt werden?

Lokale Begriffe sollten nicht einfach verboten werden. Besser ist es, sie als Synonyme zu hinterlegen und auf die korrekten Stammdaten abzubilden.

Schritt 3: Geeignete Hardware für den Einsatzort auswählen

Die beste Software scheitert, wenn die Eingabegeräte nicht zum Arbeitsumfeld passen. In der Produktion zählen andere Kriterien als im Büro.

Hardware immer am realen Arbeitsplatz testen

Ein Mikrofon, das im Besprechungsraum gut funktioniert, kann neben einer Presse oder einem Kompressor unbrauchbar sein. Tests sollten deshalb während des echten Betriebs stattfinden.

Zu prüfen sind:

• Erkennungsqualität bei typischem Hintergrundlärm,
• Verständlichkeit bei Dialekten und unterschiedlichen Sprachen,
• Bedienung mit Handschuhen,
• Stabilität des WLAN- oder Mobilfunkempfangs,
• sichere Nutzung während der Arbeit,
• Reinigung und gemeinsame Nutzung,
• Geräteverwaltung und Updates,
• Verhalten bei kurzfristiger Netzunterbrechung.

Häufig ist keine neue Spezialhardware erforderlich. Wenn geeignete Smartphones, Tablets oder Microsoft-Teams-Arbeitsplätze bereits vorhanden sind, können sie den Einstieg vereinfachen. Entscheidend ist nicht das modernste Gerät, sondern eine robuste und akzeptierte Nutzung im Alltag.

Schritt 4: Den Sprachdialog wie einen guten Kollegen gestalten

Ein guter Meldungsassistent verhält sich nicht wie ein Formular, das vorgelesen wird. Er lässt die Person zunächst frei beschreiben, was passiert ist, wertet die Angaben aus und fragt nur dort nach, wo Informationen fehlen.

Ein möglicher Ablauf:

„An der Kühlwasserpumpe P-204 tritt seit etwa zehn Minuten Wasser an der rechten Flanschverbindung aus. Die Pumpe läuft noch, aber die Leckage wird stärker. Wir haben den Bereich abgesperrt.“

Der Assistent kann daraus bereits erkennen:

• Equipment: P-204,
• Fehlerbild: Leckage,
• Ort: rechte Flanschverbindung,
• Beginn: vor etwa zehn Minuten,
• Zustand: Anlage läuft,
• Tendenz: Leckage nimmt zu,
• Maßnahme: Bereich abgesperrt.

Statt alle Standardfragen zu stellen, könnte der Assistent nur noch ergänzen:

• „Ist das austretende Medium ausschließlich Kühlwasser?“
• „Besteht eine unmittelbare Gefahr für Personen oder benachbarte Anlagen?“
• „Soll die Meldung mit hoher Priorität angelegt werden?“
• „Möchten Sie ein Foto hinzufügen?“

Gestaltungsregeln für verständliche Dialoge

• kurze und eindeutige Rückfragen,
• möglichst eine Frage pro Dialogschritt,
• Fachbegriffe der Belegschaft verwenden,
• erkannte Angaben vor dem Absenden zusammenfassen,
• Korrekturen einfach ermöglichen,
• bei Unsicherheit nicht raten, sondern nachfragen,
• Sicherheitsfragen eindeutig priorisieren,
• Abbruch und manuelle Übergabe ermöglichen.

Der Assistent soll die Mitarbeitenden unterstützen, nicht prüfen oder belehren.

Schritt 5: SAP PM als führendes System beibehalten

Eine sprachbasierte Lösung sollte in der Regel kein neues paralleles Ticketsystem aufbauen. SAP PM beziehungsweise SAP EAM bleibt das führende System für Meldungen, Aufträge, technische Objekte und Historien.

Der Sprachassistent übernimmt die benutzerfreundliche Erfassung und Qualitätssicherung vor der Übergabe.

Ein typischer Datenfluss sieht so aus:

Spracheingabe
→ Transkription
→ Erkennung von Equipment, Fehlerbild und Kontext
→ gezielte Rückfragen
→ strukturierte Meldungsdaten
→ technische Validierung
→ Übergabe an SAP PM/EAM
→ Rückmeldung der SAP-Meldungsnummer

Für die Integration müssen unter anderem folgende Punkte geklärt werden:

• Welche SAP-Version und welche Schnittstellen stehen zur Verfügung?
• Welche Meldungsarten sollen unterstützt werden?
• Wie werden technische Plätze und Equipments synchronisiert?
• Welche Felder sind verpflichtend?
• Wie werden Prioritäten, Kataloge und Schadenscodes abgebildet?
• Können Bilder und weitere Anhänge übertragen werden?
• Wie erhält der Nutzer die angelegte Meldungsnummer?
• Was geschieht, wenn SAP kurzfristig nicht erreichbar ist?
• Wie werden Fehler und doppelte Meldungen behandelt?

Die Integration sollte API-basiert und nachvollziehbar erfolgen. Je nach Systemlandschaft kommen beispielsweise REST-, OData-, SOAP- oder vorhandene Integrationsdienste infrage. Die genaue technische Ausprägung hängt von der SAP-Architektur und den Unternehmensvorgaben ab.

Der entscheidende Grundsatz

Der Assistent ersetzt SAP PM nicht. Er verbessert die Qualität und Zugänglichkeit des Prozesses, bevor die Daten im führenden System gespeichert werden.

Damit bleibt die vorhandene Instandhaltungsarchitektur erhalten, während die Mitarbeitenden eine deutlich einfachere Oberfläche erhalten.

Schritt 6: Sicherheit, Datenschutz und Mitbestimmung früh klären

Sprachverarbeitung betrifft Betriebsdaten und kann personenbezogene Informationen enthalten. Deshalb sollten IT-Sicherheit, Datenschutz und Arbeitnehmervertretung nicht erst kurz vor dem Rollout eingebunden werden.

Zu klären sind insbesondere:

• Wird die ursprüngliche Audiodatei gespeichert oder nach der Transkription gelöscht?
• Wo findet die Transkription statt – auf dem Gerät, im eigenen Rechenzentrum oder in einer Cloud?
• In welcher Region werden Daten verarbeitet?
• Welche Rollen dürfen Meldungen sehen, korrigieren oder freigeben?
• Wie erfolgt die Anmeldung?
• Werden bestehende Identitätsanbieter genutzt?
• Welche Protokoll- und Auditdaten werden erzeugt?
• Wie lange werden Inhalte gespeichert?
• Wie werden sensible Produktionsinformationen geschützt?
• Welche Betriebsvereinbarungen sind notwendig?

Für viele Industriebetriebe sind EU-Hosting, Private-Cloud- oder On-Premises-Optionen wichtige Auswahlkriterien. Ebenso wichtig ist eine transparente Kommunikation: Die Lösung dient der besseren Dokumentation und Unterstützung – nicht der Leistungs- oder Verhaltenskontrolle einzelner Mitarbeitender.

Schritt 7: Mit einem begrenzten Pilotprojekt starten

Ein Pilot sollte groß genug sein, um reale Bedingungen abzubilden, aber klein genug, um Dialoge und Prozesse schnell anzupassen.

Ein sinnvoller Pilot umfasst beispielsweise:

• einen klar abgegrenzten Produktionsbereich,
• ausgewählte Störungsarten,
• eine überschaubare Nutzergruppe aus Produktion und Instandhaltung,
• reale SAP-Stammdaten,
• definierte Erfolgskennzahlen,
• einen direkten Feedbackkanal,
• regelmäßige kurze Auswertungs- und Anpassungstermine.

Wichtig ist, nicht nur technisch einfache Meldungen zu testen. Der Pilot sollte auch unklare Situationen, Dialekte, Hintergrundlärm, fehlende Stammdaten und Unterbrechungen berücksichtigen.

Erst Shadow Mode, dann produktive Übergabe

Zu Beginn kann der Assistent Meldungen erzeugen, ohne sie automatisch in SAP zu speichern. Die strukturierte Ausgabe wird mit der bisherigen Meldung verglichen und von einem Verantwortlichen geprüft.

Erst wenn Zuordnung, Pflichtfelder und Dialoglogik zuverlässig funktionieren, wird die direkte Übergabe aktiviert. Dieses Vorgehen reduziert Risiken und schafft Vertrauen bei IT und Fachbereich.

Schritt 8: Mitarbeitende praxisnah schulen

Die Schulung sollte nicht als klassische Softwareeinweisung aufgebaut sein. Entscheidend ist, dass die Mitarbeitenden verstehen, wann und wie sie eine gute Störmeldung sprechen.

Eine wirksame Einführung enthält:

• kurze Übungen direkt am Arbeitsplatz,
• typische Beispiele aus dem eigenen Werk,
• bewusst unvollständige Meldungen zum Testen der Rückfragen,
• Hinweise zu klarer, natürlicher Sprache,
• Übungen zum Korrigieren erkannter Angaben,
• Erklärung, was mit den Daten geschieht,
• feste Ansprechpartner für die Startphase.

Multiplikatoren aus dem Shopfloor einbeziehen

Erfahrene Mitarbeitende sollten bereits bei der Gestaltung der Dialoge beteiligt sein. Sie kennen lokale Begriffe, typische Fehlerbilder und die tatsächlichen Arbeitsabläufe. Als Multiplikatoren können sie später Fragen beantworten und die Akzeptanz im Team erhöhen.

Die Einführung funktioniert besser, wenn sie als gemeinsames Verbesserungsprojekt wahrgenommen wird – nicht als von oben verordnetes IT-System.

Schritt 9: Wirkung messen und schrittweise ausrollen

Nach dem Pilot sollten nicht nur Nutzungszahlen betrachtet werden. Eine hohe Anzahl erzeugter Meldungen sagt noch nichts über deren Qualität aus.

Relevante Kennzahlen sind:

• durchschnittliche Erfassungszeit,
• Vollständigkeit der Meldungen,
• Anteil korrekt zugeordneter Equipments,
• Anzahl der Rückfragen durch die Instandhaltung,
• Anteil nachträglich korrigierter Meldungen,
• Nutzung nach Schicht oder Bereich,
• Zeit bis zur qualifizierten Bearbeitung,
• Qualität der Fehler- und Schadenscodes,
• Akzeptanz bei meldenden und bearbeitenden Mitarbeitenden.

Erst nach einer stabilen Pilotphase sollte der Prozess auf weitere Linien, Werke oder Anwendungsfälle übertragen werden. Dabei müssen lokale Unterschiede berücksichtigt werden. Eine zentrale Grundlogik ist sinnvoll, aber Dialoge und Stammdaten benötigen häufig standortspezifische Anpassungen.

Häufige Fehler bei der Einführung

1. Sprache nur als Ersatz für die Tastatur betrachten

Ohne Rückfragen und Strukturierung entstehen dieselben unvollständigen Meldungen wie zuvor – nur gesprochen.

2. Zu viele Fragen stellen

Ein Dialog, der jedes mögliche Feld abfragt, wird schnell genauso unbeliebt wie ein langes Formular. Der Assistent sollte bekannte Informationen nutzen und nur relevante Lücken schließen.

3. Schlechte Stammdaten ignorieren

Unklare Equipment-Bezeichnungen und doppelte technische Objekte lassen sich nicht allein durch KI beheben. Die Einführung macht solche Probleme häufig erst sichtbar.

4. Die Instandhaltung zu spät einbinden

Produktion und Instandhaltung müssen gemeinsam definieren, welche Informationen wirklich benötigt werden.

5. Sofort das gesamte Werk ausrollen

Ohne Pilot entstehen zu viele gleichzeitige Fehlerquellen. Ein begrenzter Anwendungsfall ermöglicht schnelle Verbesserungen.

6. Datenschutz und Betriebsrat als Abschlussaufgabe behandeln

Späte Einbindung kann ein technisch funktionierendes Projekt unnötig verzögern oder stoppen.

7. Ein paralleles Meldungssystem aufbauen

Wenn Daten später manuell nach SAP übertragen werden müssen, entsteht ein zusätzlicher Prozess statt einer Vereinfachung.

Praxisbeispiel: Hahn PRO ADAM als Voice-to-Ticket-Assistent

Hahn PRO ADAM wurde als intelligenter Meldungsassistent für industrielle Instandhaltungsprozesse entwickelt. Mitarbeitende können eine Störung per Sprache beschreiben. ADAM strukturiert die Angaben, prüft die Meldung auf Vollständigkeit und stellt bei fehlenden Informationen gezielte Rückfragen.

Technisch wird ADAM nicht als Ersatz für SAP PM oder ein anderes CMMS positioniert. Die Plattform arbeitet als prozessorientierte Bedien- und Qualitätsschicht vor dem führenden System. Über Schnittstellen können die strukturierten Daten an SAP PM/EAM übergeben und dort als Instandhaltungsmeldung gespeichert werden. Die konkrete Feldzuordnung, Meldungsart und Integrationslogik werden auf die vorhandene Systemlandschaft abgestimmt.

Ein typischer Ablauf mit ADAM:

1. Ein Produktionsmitarbeiter öffnet ADAM beispielsweise über ein mobiles Gerät oder einen integrierten Kommunikationskanal.
2. Er beschreibt die Störung in natürlicher Sprache.
3. ADAM erkennt technische Objekte, Symptome, Auswirkungen und bereits durchgeführte Maßnahmen.
4. Fehlende Informationen werden im Dialog ergänzt.
5. Der Nutzer prüft eine kurze Zusammenfassung.
6. ADAM übergibt die strukturierte Meldung an SAP PM/EAM.
7. Die erzeugte Meldungsnummer wird zurückgegeben.

Gemeinsam mit Axalta Coating Systems wurde ADAM als KI-gestützter Meldungsassistent in der Praxis erprobt. Ausgangspunkt waren unvollständige Meldungen und ein hoher Aufwand für Rückfragen. In der Beta-Phase wurden eine verbesserte Meldungsqualität und eine spürbare Zeitersparnis berichtet. Das gemeinsame Projekt erreichte das Finale des Instandhaltungspreises 2025.

Der entscheidende Nutzen liegt nicht allein in der Spracherkennung. Er entsteht durch die Kombination aus geführtem Dialog, Kontextwissen, Qualitätsprüfung und Integration in die vorhandenen Prozesse.

Checkliste für den Projektstart

Vor einem Pilotprojekt sollten folgende Fragen beantwortet sein:

• Welcher konkrete Meldeprozess wird zuerst verbessert?
• Welche Nutzergruppen sind beteiligt?
• Was muss eine vollständige Meldung enthalten?
• Welche Stammdaten werden aus SAP benötigt?
• Welche Hardware ist am Arbeitsplatz geeignet?
• Wie laut ist die reale Umgebung?
• Welche Schnittstellen stehen zur Verfügung?
• Welche Authentifizierung wird verwendet?
• Wie werden Audiodaten und Transkripte behandelt?
• Welche Kennzahlen bilden den Ausgangszustand ab?
• Wer prüft die Ergebnisse während des Piloten?
• Wie werden Mitarbeitende und Arbeitnehmervertretung eingebunden?
• Nach welchen Kriterien wird über den Rollout entschieden?

Fazit: Erst den Prozess qualifizieren, dann automatisieren

Sprachbasierte Störmeldungen können die Hürde zur Dokumentation deutlich senken. Der eigentliche Mehrwert entsteht jedoch erst, wenn aus einer freien Beschreibung eine vollständige, strukturierte und direkt nutzbare Instandhaltungsmeldung wird.

Dafür müssen Prozess, Stammdaten, Dialogführung, Hardware, Sicherheit, Integration und Veränderungsmanagement gemeinsam betrachtet werden. Wer lediglich ein Mikrofon vor eine bestehende Eingabemaske setzt, digitalisiert den alten Aufwand. Wer den Meldeprozess neu gestaltet, schafft dagegen bessere Daten für schnellere Entscheidungen und eine belastbare Instandhaltungshistorie.

Hahn PRO ADAM verbindet die einfache Spracheingabe mit geführter Qualitätssicherung und der Übergabe an bestehende Systeme wie SAP PM/EAM. So entsteht kein zusätzlicher Datenkanal, sondern ein direkter Weg von der Beobachtung im Shopfloor zur qualifizierten Meldung im führenden System.