In vielen Maschinen läuft längst eine eigene Telemetrie-Plattform. Trotzdem ruft der Disponent jeden zweiten Servicefall noch beim erfahrenen Kollegen an, der „die Maschine kennt“. Das Problem ist selten der Sensor — sondern die Lücke zwischen Datenpunkt und Service-Entscheidung.
Sensordaten allein lösen keinen Servicefall. Erst wenn Vibration, Temperatur, Betriebsstunden und Fehlercodes in einem System landen, in dem auch Servicehistorie, Vertragsdaten und Diagnose-Wissen verfügbar sind, entsteht aus Telemetrie ein Servicekontext, mit dem Disponenten, Techniker und Kunden tatsächlich arbeiten können. Dieser Artikel zeigt, wie Maschinenbauer den Weg vom Sensor in das Serviceportal so gestalten, dass jede Rolle den Nutzen sieht — und wie sich die typischen Sicherheits-, Integrations- und Datenhoheitsfragen einordnen lassen.
Wenn Sensordaten ankommen – und im Service nicht ankommen
Ein typisches Bild: Ein Hersteller von Sondermaschinen mit rund 5.000 weltweit installierten Anlagen betreibt seit Jahren eine IoT-Plattform. Die Maschinen melden Status, Betriebsstunden und Fehlercodes; die Plattform zeigt Dashboards mit historischen Trends. Im Service kommt davon wenig an. Die Servicehistorie liegt im CRM, technische Dokumentationen liegen in PDFs auf einem Sharepoint, Konfigurationsänderungen stehen in einer Excel-Tabelle. Wenn eine Störung gemeldet wird, muss der Disponent zwischen drei Systemen wechseln — und ruft am Ende doch beim Senior-Kollegen an, der die Anlage aus dem Kopf kennt.
Die Folgen kennen Serviceleiter aus eigener Erfahrung:
- Triage dauert länger, weil Informationen aus mehreren Quellen zusammengetragen werden müssen.
- Techniker fahren mit unvollständigem Bild zum Einsatz und kommen ohne das richtige Ersatzteil zurück.
- Wissen erfahrener Mitarbeiter geht verloren, sobald sie das Unternehmen verlassen — neue Kollegen brauchen Monate, um vergleichbare Entscheidungen zu treffen.
- Kunden erwarten Self-Service-Zugriff auf den Status ihrer Anlagen, bekommen aber nur einen Link zum Ticketformular.
Das Problem ist selten der Sensor selbst. Die meisten Maschinen liefern heute genug Daten. Was fehlt, ist die Anschluss-Fähigkeit dieser Daten an die Prozesse, in denen über Servicefälle entschieden wird.
Vom Datenpunkt zur Service-Entscheidung: der Pfad durch die Schichten
Der Weg vom Sensor bis zur Disponenten-Konsole verläuft in vier Schichten — und an jeder dieser Schichten geht heute oft Kontext verloren.
Schicht 1 — Sensor und Edge. Smart-Sensoren messen Vibration, Temperatur, Stromaufnahme oder Druck. Edge-Geräte verarbeiten die Daten lokal vor: Sie filtern Rauschen, erkennen erste Anomalien und entscheiden, was überhaupt nach oben geschickt wird. Eine ausführliche Beschreibung dieses Datenflusses finden Sie in unserem Artikel So implementieren Sie Predictive Maintenance mit IoT.
Schicht 2 — IoT-Plattform. Hier laufen die gefilterten Daten zusammen. Die Plattform zeigt Trends, sendet Alarme und stellt Schnittstellen für andere Systeme bereit. An dieser Stelle ist die Qualität der Daten meist gut. Was fehlt, ist die Verknüpfung mit dem Geschäftskontext: Welche Maschine genau ist betroffen? Welcher Wartungsvertrag gilt? Welche Servicehistorie hat sie?
Schicht 3 — Service-Kontext. Diese Schicht ist die entscheidende und meist die schwächste. Im Salesforce-basierten Service-Backend wird das Asset-Objekt zur zentralen Bezugsgröße: Maschine, Komponenten, Standort, Kunde, Verträge, Tickets. Wenn IoT-Plattform und Service-Backend nicht direkt miteinander sprechen, muss der Disponent diese Brücke manuell schlagen — und genau dort entstehen die Verzögerungen.
Schicht 4 — Rollenoberflächen. Disposition, Außendienst und Kundenportal greifen auf denselben Service-Kontext zu, sehen aber jeweils nur, was für ihre Aufgabe relevant ist. Der Techniker bekommt nicht das Disponenten-Dashboard, der Kunde nicht die internen Notizen.
Die zentrale Übergangsstelle liegt zwischen Schicht 2 und Schicht 3. Wer hier eine saubere, bidirektionale Brücke baut, gewinnt nicht nur Zeit in der Triage — er schafft die Voraussetzung für jede weitere Stufe der Service-Digitalisierung.
Drei Nutzungs-Perspektiven im Serviceportal
Sobald IoT-Daten und Service-Kontext zusammenfließen, ändert sich die Arbeit für drei Rollen konkret.
Für die Disposition: schneller und fundierter triagieren. Der Disponent sieht in einer Ansicht den aktuellen Maschinenstatus, die letzten Service-Einsätze, offene Verträge und vorgeschlagene nächste Schritte. Statt drei Systeme zu öffnen, entsteht die Triage-Entscheidung in der Service Cloud — mit Bezug zur konkreten Anlage, nicht zur abstrakten Plattform-ID.
Für den Techniker: vorbereitet vor Ort. Der Techniker erhält die Service-Konsole auf dem mobilen Gerät: Live-Sensorwerte, vollständige Servicehistorie der Maschine, Diagnose-Empfehlungen und kontextbezogene Anleitungen. logicline hat die Salesforce-Integration von Empolis Service Express mitentwickelt, sodass Diagnose-Wissen kontextbezogen zur konkreten Maschine erscheint und nicht als unstrukturierte Dokumentensuche endet. Reicht die Vor-Ort-Diagnose nicht aus, eskaliert der Techniker per Klick aus derselben Konsole an einen Remote-Spezialisten — logicline hat dafür auch die Salesforce-Integration von TeamViewer mitentwickelt.
Für den Kunden: Transparenz im Self-Service. Im Kundenportal sehen Betreiber den Status ihrer Anlagen, offene Wartungstermine und können Tickets oder Ersatzteile selbst auslösen. Predictive-Hinweise — etwa „Wartung in 21 Tagen empfohlen“ — werden hier direkt sichtbar, statt im Dashboard einer separaten IoT-Plattform zu versanden.
Diese drei Sichten brauchen kein eigenes Datenmodell. Sie greifen auf dieselbe digitale Maschinenakte zu — und unterscheiden sich nur darin, was für die jeweilige Rolle sichtbar gemacht wird.
Voraussetzungen: Integration, Sicherheit, Datenhoheit
Die drei Themen, die jedes IoT-im-Service-Vorhaben am häufigsten ausbremsen, lassen sich pragmatisch einordnen.
Integration in Bestand. Selten beginnt man auf der grünen Wiese. Maschinen unterschiedlicher Generationen, ERP-Systeme mit gewachsenen Schnittstellen, ältere Steuerungen ohne moderne Konnektivität — all das gehört zur Realität. Eine bewährte Reihenfolge: Bestandsaufnahme der vorhandenen Sensoren und Schnittstellen, schrittweise Modernisierung über Pilotanlagen, Standard-Protokolle wie MQTT oder OPC UA für die Maschinenseite, eine zentrale Integrationsschicht zur Service Cloud. Eine ausführlichere Checkliste mit acht Schritten finden Sie in 8 Best Practices für IoT Asset Management.
Sicherheit. Vernetzte Maschinen erweitern die Angriffsfläche. Drei Maßnahmen tragen den größten Teil der Last: Verschlüsselung der Datenübertragung, Mehr-Faktor-Authentifizierung an allen Zugängen und eine konsequente Trennung von OT- und IT-Netzen. Hinzu kommt eine Update-Disziplin, die Firmware-Stände aktiv pflegt statt sie laufen zu lassen. Wer diesen Aspekt vertiefen möchte, findet die Details in unserem Artikel IoT-Daten in Serviceportalen: Sicherheitsrisiken minimieren.
Datenhoheit. Servicedaten enthalten Kundenkontext und technisches IP. Beides sollte den Kontrollbereich des Herstellers nicht ungewollt verlassen. Praktisch heißt das: regional gehostete Plattformen (etwa Salesforce Hyperforce EU), klare Rollen für Datenexporte, und bei KI-Einsatz die Möglichkeit, das Modell auf eigener Infrastruktur oder mit europäischen Anbietern zu betreiben. Datenhoheit ist keine reine Compliance-Frage, sondern eine Architektur-Entscheidung, die früh getroffen werden sollte.
Diese drei Voraussetzungen sind keine Endpunkte, sondern dauerhafte Disziplinen. Wer sie pragmatisch einplant, vermeidet die häufigste Sackgasse: ein erfolgreiches IoT-Pilotprojekt, das in der Skalierung an einer dieser drei Hürden scheitert.
Reifegrad: Vom Datensilo zur entscheidungsfähigen Service-Plattform
Wo IoT-Daten im Serviceportal landen, lässt sich an einem einfachen Reifegradmodell ablesen. logicline arbeitet mit einem Vier-Stufen-Modell, das die typische Entwicklung im Maschinenbau abbildet.
Stufe 1 — Digitalisieren. Die installierte Basis ist strukturiert abgebildet: Maschinen, Komponenten, Konfigurationen, Verträge. Eine digitale Maschinenakte ersetzt verteilte Excel-Tabellen und PDF-Ablagen.
Stufe 2 — Vernetzen. Sensordaten, Servicehistorie und technisches Wissen sind durchgängig verbunden. IoT-Plattform und Service Cloud arbeiten bidirektional zusammen, Wissensquellen wie Empolis sind kontextbezogen integriert. Auf dieser Stufe setzt der vorliegende Artikel an.
Stufe 3 — Entscheiden. Eine Intelligenzschicht über den vernetzten Daten liefert nachvollziehbare Empfehlungen für Triage, Diagnose und Eskalation. Bei logicline ist das Service Decision Intelligence (SDI) — eine Schicht, die fragmentierte Servicedaten aus ERP, Salesforce, IoT und Dokumenten verbindet, mit Quellennachweis bei jeder Empfehlung und betrieben auf der Infrastruktur des Kunden. Ein eigener Magazinartikel zu SDI als Schritt von Stufe 2 zu Stufe 3 folgt in den nächsten Wochen.
Stufe 4 — Automatisieren. Definierte Servicearbeit wird software-artig erledigt: Routinen laufen autonom, Menschen greifen nur noch in Eskalations- und Ausnahmefällen ein.
Jede Stufe setzt die vorherige voraus. Ohne strukturierte Daten gibt es nichts zu vernetzen; ohne vernetzte Daten kann keine Intelligenz über Silos hinweg entstehen; ohne Entscheidungsintelligenz ist Automatisierung nur eine technische Hülle. Die Frage „Wo stehen wir heute?“ beantwortet sich für die meisten Maschinenbauer mit „zwischen Stufe 1 und Stufe 2″ — und genau dort entscheidet sich, ob aus IoT-Investitionen Servicewert wird.
Fazit: Der Wert liegt in der Anschluss-Fähigkeit
IoT im Service ist keine Frage der Sensorik mehr. Die Plattformen sind ausgereift, die Protokolle etabliert, die Maschinen liefern die Daten. Was den Unterschied zwischen einem teuren Telemetrie-Projekt und einem Service ausmacht, in dem Triage-Zeiten sinken und Techniker mit dem richtigen Ersatzteil zum Einsatz fahren, ist die Anschluss-Fähigkeit der Daten an Service-Kontext, Rollen und Entscheidungen.
Drei Punkte tragen den Großteil des Werts:
- Eine digitale Maschinenakte als Bezugsobjekt für jeden Datenpunkt — sonst landen Telemetrie-Werte im Vakuum.
- Eine vernetzte Service Cloud, in der Disposition, Techniker und Kunde dieselbe Wahrheit sehen, gefiltert nach Rolle.
- Eine pragmatische Architekturentscheidung zu Sicherheit und Datenhoheit, die früh getroffen wird und nicht nachträglich in jeder Eskalation neu verhandelt werden muss.
Wer diese drei Bausteine setzt, schafft die Grundlage, auf der spätere Stufen — Entscheidungsintelligenz und Servicearbeit, die software-artig skaliert — überhaupt erst möglich werden. Ohne sie bleibt jede KI-Diskussion ein Add-on auf instabiler Basis.
Der naheliegende erste Schritt ist nicht das nächste Sensor-Pilotprojekt, sondern eine ehrliche Bestandsaufnahme: Wie strukturiert ist die installierte Basis heute, und welche Datenquellen sprechen welchen Service-Prozess an? Das Installed Base Assessment liefert genau dafür die Grundlage. Auf dieser Basis lassen sich die nächsten Schritte planen, statt sie zu hoffen.
FAQs
Welche IoT-Daten gehören eigentlich ins Serviceportal?
Nicht alle Sensordaten sind im Service nutzbar. Sinnvoll sind Werte, die einen direkten Bezug zu Service-Entscheidungen haben: Betriebsstunden für Wartungsintervalle, Fehlercodes für Triage-Logik, Verschleißindikatoren wie Vibration oder Temperatur für vorausschauende Wartung. Reine Produktionskennzahlen, die nichts über den Anlagenzustand aussagen, gehören nicht in den Servicekontext — sie überfrachten die Oberfläche, ohne den Service zu unterstützen.
Wie schließt man ältere Anlagen ohne moderne Konnektivität an?
Pragmatisch und schrittweise. Häufig reicht eine Nachrüstung einzelner Sensoren, kombiniert mit einem Edge-Gateway, das Daten an die zentrale Plattform liefert. Eine vollständige Modernisierung des Maschinenparks ist selten realistisch. Wichtiger ist eine Datenstruktur in der Service Cloud, die heterogene Anlagen sinnvoll repräsentiert — neue Maschinen mit voller Telemetrie und ältere Anlagen mit reduziertem Datenbild im selben Modell.
Was passiert mit der Datenhoheit, wenn KI ins Spiel kommt?
KI-Funktionen sollten so gewählt werden, dass Servicedaten den Kontrollbereich des Herstellers nicht unkontrolliert verlassen. Bei logicline läuft die Service Decision Intelligence auf der Infrastruktur des Kunden — auf Salesforce Hyperforce EU, Azure EU, AWS Frankfurt oder im eigenen Rechenzentrum. Die Wahl des zugrundeliegenden Sprachmodells bleibt offen und kann je nach Compliance-Anforderung getroffen werden. Datenhoheit ist damit eine Architektur-Entscheidung, keine Frage der Modellgüte.
Welche Rolle spielt Salesforce in dieser Architektur?
Salesforce ist die Plattform, auf der die Service-Cloud-Schicht aufsetzt — Asset-Objekte, Tickets, Verträge, Field Service. IoT-Plattform, Wissensquellen wie Empolis und Remote-Support-Werkzeuge wie TeamViewer sind über mitentwickelte Integrationen angebunden. Das Serviceportal ist also keine eigenständige Anwendung, sondern die rollenspezifische Sicht auf eine vernetzte Plattform.
