Wenn Maschinendaten nur Alarme erzeugen, aber keinen Serviceauftrag

Um 02:14 Uhr meldet eine Anlage im Feld eine Temperaturspitze. Der Wert läuft in eine IoT-Anwendung, dort erscheint eine rote Kachel. Niemand hat Bereitschaft für diese Kachel, weil sie kein Serviceprozess ist. Am Morgen ist der Wert wieder im grünen Bereich, die Kachel verschwindet, und niemand weiß, ob das eine Vorwarnung war oder ein Messrauschen.

Drei Wochen später fällt dieselbe Baugruppe aus, diesmal im laufenden Betrieb beim Kunden. Der Einsatz wird zum Notfall, der Techniker fährt ohne das passende Ersatzteil los, und in der Nachbetrachtung stellt jemand fest, dass das Signal längst da war. Genau an dieser Stelle scheitern Predictive-Maintenance-Vorhaben im Alltag: Der Engpass ist selten der Sensor und oft nicht das Vorhersagemodell, sondern die Strecke dazwischen.

Kurz vorab, worauf es ankommt:

• Ein Grenzwert allein ist kein Vorfall. Erst eine Bedingung, die über einen definierten Zeitraum anhält, trennt das echte Ereignis vom Ausschlag.
• Ein Alarm braucht einen Empfänger mit Verantwortung. Solange er in einer separaten Anwendung endet, gibt es keinen Auftrag, keinen Termin und keine SLA-Uhr.
• Ohne Maschinenkontext bleibt der Alarm eine Zahl. Servicehistorie, Konfiguration, Vertragsstand und Ersatzteilbezug entscheiden, ob der Einsatz beim ersten Mal sitzt.
• Der Einstieg braucht keine Sensorik-Offensive. Betriebsstunden und Zykluszähler liefern belastbare Auslöser, bevor irgendein Retrofit beginnt.

Drei Lücken zwischen Messwert und Serviceauftrag

Viele Hersteller haben die Datenanbindung längst hinter sich. Die Maschinen senden, ein Dashboard zeigt Kurven, und trotzdem ändert sich am Serviceverlauf wenig. Der Grund liegt in drei Lücken, die nacheinander auftreten.

Relevanz: Was ist überhaupt ein Vorfall?

Ein Schwellwert ist schnell definiert und erzeugt genauso schnell Rauschen. Anfahrvorgänge, Lastwechsel und Umgebungstemperaturen produzieren Ausschläge, die keinerlei Servicebedarf anzeigen. Wird jeder davon zum Ticket, lernt das Team innerhalb weniger Wochen, Alarme zu ignorieren, und der teuerste Effekt tritt ein: Das echte Signal geht im Rauschen unter.

Belastbar wird die Auswertung erst mit einer Persistenzbedingung. Nicht „Temperatur über 85 Grad“, sondern „Temperatur über 85 Grad, ununterbrochen länger als zehn Minuten, bei laufender Anlage“. Diese eine Ergänzung entscheidet darüber, ob Ihr Serviceteam den Kanal ernst nimmt.

Handlung: Wer übernimmt, und bis wann?

Die zweite Lücke ist organisatorisch. Ein Alarm in einer IoT-Anwendung hat keinen Verantwortlichen, keine Frist und keinen Status. Er ist eine Anzeige, kein Vorgang. Damit fehlt alles, was eine Serviceorganisation zum Arbeiten braucht: Zuweisung, Terminierung, Eskalationspfad und eine Uhr, die gegen die vertraglich zugesagte Reaktionszeit läuft.

Kontext: Was weiß der Techniker beim Öffnen?

Die dritte Lücke kostet Zweitbesuche. Ein Alarm mit Fehlercode und Zeitstempel sagt nichts über die Vorgeschichte der Anlage. Ob dieselbe Baugruppe vor acht Monaten schon einmal getauscht wurde, welcher Softwarestand läuft, ob ein Servicevertrag mit vierstündiger Reaktionszeit greift und welches Ersatzteil zu dieser Konfiguration passt, steht in anderen Systemen. Fehlt diese Zusammenführung, fährt der Techniker mit einer Zahl los.

Praktisch entscheidet sich hier die Erstlösungsquote. Der Unterschied zwischen einem Auftrag, der nur den Fehlercode trägt, und einem, der die letzten drei Einsätze an dieser Anlage, den verbauten Softwarestand und den passenden Ersatzteilsatz mitbringt, ist ein zweiter Anfahrtsweg. Bei einer Flotte im dreistelligen oder vierstelligen Bereich summiert sich das zu einer Größe, die in der Serviceplanung sichtbar wird.

Welche Regeln im Maschinenbau tatsächlich tragen

Die Diskussion um Predictive Maintenance dreht sich meist um Prognosemodelle. In der Praxis deckt eine überschaubare Zahl regelbasierter Auslöser den Großteil der Fälle ab, und sie hat einen entscheidenden Vorteil: Sie ist nachvollziehbar. Ein Serviceleiter kann einem Kunden erklären, warum ein Auftrag entstanden ist. Bei einem Modell, das ein Risiko von 0,73 ausgibt, wird das schwierig.

Vier Kategorien decken die Bandbreite ab, die Serienfertiger im Feld brauchen:

Regelkategorie	Auslöser	Typischer Einsatz	Was entsteht
Schwellwert	Messwert überschreitet eine Grenze	klar definierte Grenzen, etwa Druck oder Füllstand	Hinweis oder Serviceauftrag, je nach Kritikalität
Anhaltende Bedingung	Zustand besteht über ein Zeitfenster fort	Temperatur, Vibration, Stromaufnahme	Serviceauftrag ohne Blind-Ticket bei kurzen Ausschlägen
Stillstand und Verfügbarkeit	Anlage meldet sich nicht oder steht ungeplant	Verfügbarkeitszusagen im Vertrag	Serviceauftrag mit sofort laufender SLA-Uhr
Betriebsstunden und Zyklen	Zählerstand erreicht einen Wartungspunkt	Verschleißteile, planbare Wartung	terminierbarer Einsatz plus Ersatzteilbedarf

Die vierte Kategorie wird regelmäßig unterschätzt. Betriebsstunden und Zyklen liegen in vielen Steuerungen längst vor und lassen sich ohne Sensorik-Projekt auslesen. Sie erzeugen planbare Einsätze statt Notfälle, und sie sind der Einstieg für Hersteller, deren Flotte technisch heterogen ist. Wer zusätzlich nutzungsabhängige Modelle prüft, findet in unserem Beitrag zu Pay-per-Use und Equipment-as-a-Service die kommerzielle Seite derselben Zählerstände.

Der Aufwand skaliert dabei nicht mit der Zahl der Maschinen, sondern mit der Zahl der Maschinentypen. Eine Regel je Baureihe wirkt über die gesamte Flotte, was diesen Ansatz für Serienfertiger mit großer installierter Basis wirtschaftlich macht.

Wer die Regeln definiert und pflegt

Regeln entstehen selten am Schreibtisch der IT. Die Grenzwerte kennt die Entwicklung, die Fehlerbilder kennt der Service, und die vertraglichen Zusagen kennt der Innendienst. Bewährt hat sich ein kleines gemischtes Team, das je Baureihe eine Handvoll Auslöser festlegt und in Betrieb nimmt, statt einen Katalog über alle Anlagen hinweg zu entwerfen.

Dazu gehört ein fester Prüfrhythmus. Nach den ersten Wochen zeigt sich, welche Regel zu oft auslöst und welche zu spät greift, und beides lässt sich nur anpassen, wenn jemand die ausgelösten Aufträge gegen ihren tatsächlichen Befund hält. Deshalb sollte der Techniker im Auftrag kurz vermerken können, ob der Auslöser berechtigt war. Diese Rückmeldung ist die einzige belastbare Grundlage, um Schwellen und Zeitfenster nachzuschärfen, und sie ist später auch das Trainingsmaterial, falls Prognosemodelle dazukommen.

Was im Serviceprozess passieren muss

Sobald eine Regel greift, beginnt der Teil, der über den Nutzen entscheidet. Der Vorfall muss als Serviceauftrag in dem System entstehen, in dem Ihre Serviceorganisation ohnehin arbeitet, mit allem, was daran hängt: Zuweisung an eine Ressource mit passender Qualifikation, Terminierung im Einsatzplan, laufende SLA-Uhr gegen die vertragliche Zusage und ein Eskalationspfad, wenn die Frist reißt.

Das setzt eine Verbindung zwischen drei Welten voraus, die in vielen Häusern getrennt sind: der Maschinendaten, der Stammdaten zur installierten Basis und der Serviceprozesse selbst. Genau hier arbeitet logicline: Die Signalauswertung, die Maschinenakte und die Serviceabwicklung entstehen als ein durchgängiger Ablauf in Salesforce, statt als drei Werkzeuge mit Schnittstellen dazwischen. Wie die Datenseite dieser Kette aussieht, beschreibt der Beitrag zu IoT-Daten im Serviceportal.

Wichtig ist dabei eine Abstufung. Nicht jeder Auslöser rechtfertigt einen Einsatz. Ein Teil der Signale gehört als Hinweis an die Anlage, sichtbar beim nächsten ohnehin geplanten Termin, ein anderer Teil erzeugt einen Auftrag mit Frist. Wer diese Unterscheidung nicht trifft, produziert entweder Alarm-Rauschen oder verpasst den kritischen Fall.

Das Gegenbild zum Eingangsszenario sieht dann so aus: Dieselbe Temperaturspitze löst nichts aus. Hält die Bedingung zehn Minuten an, entsteht automatisch ein Serviceauftrag, der bereits die Servicehistorie der Anlage, den Vertragsstand und einen Ersatzteilvorschlag enthält. Die Disposition sieht ihn morgens im Einsatzplan, nicht als Kachel, die über Nacht verschwunden ist.

Was die Voraussetzung dafür ist

Eine Regel kann nur so präzise sein wie die Stammdaten darunter. Wenn nicht eindeutig ist, welche Maschine mit welcher Konfiguration bei welchem Kunden unter welchem Vertrag läuft, lässt sich kein Auslöser sauber zuordnen und kein SLA korrekt starten. Deshalb ist die strukturierte installierte Basis der erste Schritt, nicht der zweite. Diese Ebene behandelt der Beitrag zur Datengrundlage für Predictive Maintenance; hier geht es um die Ebene danach.

Einordnung: erst vernetzen, dann entscheiden

Im Modell Digitalisieren → Vernetzen → Entscheiden → Automatisieren sitzt die regelbasierte Signalverarbeitung auf Stufe zwei. Stufe eins liefert die strukturierten Stammdaten, ohne die kein Auslöser eindeutig adressierbar ist. Ein Alarm ist immer nur so viel wert wie der Prozess, in den er einläuft.

Auf Stufe drei verschiebt sich die Frage. Aus dem ausgelösten Vorfall wird ein triagierter Fall: Wie dringend ist er im Vergleich zu den anderen offenen Aufträgen, welche Ursache ist angesichts der Historie dieser Anlage wahrscheinlich, welches Teil sollte mitfahren. Diese Bewertung leistet Service Decision Intelligence (SDI) als Intelligenzschicht über Maschinen-, Auftrags- und Dokumentendaten.

Zwei Eigenschaften sind dabei für Maschinenbauer entscheidend. Erstens der Quellennachweis: Jede Empfehlung zeigt, auf welchen Daten und welchen Dokumenten sie beruht, was gegenüber Kunden und im Gewährleistungsfall belegbar bleibt. Zweitens die Datenhoheit: SDI läuft auf der Infrastruktur des Kunden, EU-konform und unabhängig vom eingesetzten Sprachmodell. Betriebsdaten der installierten Basis gehören zum Kerngeschäft und verlassen das Haus nicht.

Nächster Schritt

Wenn Ihre Maschinen Daten liefern und der Service davon bisher wenig hat, liegt die Ursache selten in der Sensorik. Sie liegt in der fehlenden Regel-Logik und in der Trennung zwischen Alarmkanal und Serviceprozess. Beides lässt sich schrittweise schließen, beginnend bei einer Baureihe und einer Handvoll Auslöser.

Zwei pragmatische Einstiege:

• Installed Base Assessment – wenn unklar ist, welche Maschine in welcher Konfiguration unter welchem Vertrag läuft. Ohne diese Zuordnung trägt keine Regel.
• Erstgespräch – wenn die Stammdaten stehen und Sie die ersten Auslöser definieren wollen, inklusive der Frage, welche Baureihe den Anfang macht.

Nehmen Sie für den Anfang die Baureihe mit den meisten ungeplanten Einsätzen im letzten Jahr. Dort ist der Unterschied zwischen Notfall und geplantem Termin am schnellsten messbar.