Wartung nach Betriebsstunden im Field Service einrichten

In Salesforce Field Service lösen Sie Wartung nach Betriebsstunden mit Maintenance Work Rules aus, die einen Zähler am Asset lesen statt eines Kalenderdatums. Es gibt zwei Varianten. Eine nutzungsbasierte Regel liest ein Nutzungsfeld am Asset, das auch eine Formel sein darf, und das System pflegt ein Feld für das nächste Auftreten. Eine kriterienbasierte Regel arbeitet mit Filterkriterien, etwa „kumulierte Stillstandszeit ab 1.000 Stunden“, und erzeugt einen Arbeitsauftrag, sobald sie zutreffen. Der Zähler kommt einmal am Tag aus dem ERP oder der IoT-Plattform. Rohdaten der Sensoren bleiben außerhalb von Salesforce.

Kalender, Nutzung oder Kriterien: Welcher Auslöser passt?

Die meisten Wartungspläne beginnen mit dem Kalender: Inspektion alle sechs Monate. Für Maschinen, die beim einen Kunden einschichtig und beim anderen dreischichtig laufen, ist das gleich doppelt falsch. Der Wenignutzer bekommt Einsätze, die er nicht braucht, der Vielnutzer wartet zu lange.

Field Service kennt drei Arten von Maintenance Work Rules, beschrieben auf der Hilfeseite zur vorbeugenden Wartung1:

Regeltyp	Liest	Typischer Einsatz
Kalenderbasiert	Intervall in Tagen, Wochen, Monaten	Gesetzliche Prüfungen, feste Vertragstermine
Nutzungsbasiert	Ein Nutzungsfeld am Asset und ein Feld für das nächste Auftreten	Betriebsstunden, Zyklen, Hübe
Kriterienbasiert	Recordset Filter Criteria auf Asset-Feldern	Schwellen, kombinierte Bedingungen, „was zuerst eintritt“

Recordset Filter Criteria sind gespeicherte Bedingungen auf Asset-Feldern, etwa „Betriebsstunden seit letzter Wartung größer oder gleich 2.000“. Die Grundlagen zu Wartungsplänen, Serviceverträgen und Entitlements stehen in Field Service: Wie bildet man Wartungsverträge ab?.

Wie funktioniert eine nutzungsbasierte Regel?

Die Regel zeigt auf zwei Felder am Asset. Das Nutzungsfeld enthält den Zähler, zum Beispiel die Betriebsstunden. Laut Hilfe darf es eine Formel sein, Sie können es also aus anderen Asset-Feldern berechnen. Das Feld für das nächste Auftreten enthält den Stand, bei dem die nächste Wartung fällig ist. Eine Formel darf es nicht sein, weil das System es selbst aktualisiert.

Pro Zählerart brauchen Sie also ein Zahlenfeld am Asset, das von außen gefüllt wird, und pro Regel ein Feld, das das System pflegt. Die Übersichtsseite nennt die Felder, beschreibt aber nicht jeden Schritt der Berechnung. Ich teste das deshalb in einer Sandbox mit ein paar echten Zählerständen, bevor der erste Plan live geht.

Kriterienbasierte Regeln erzeugen keinen zweiten offenen Auftrag

Sie legen Recordset Filter Criteria mit Bedingungen auf Standard- oder eigenen Asset-Feldern an, wählen, ob alle oder mindestens eine zutreffen müssen, und hängen sie an eine Maintenance Work Rule vom Typ kriterienbasiert. Das Beispiel der Hilfe kombiniert 60.000 Schaltspiele oder sechs Monate seit der letzten Überholung mit ODER. Genau dieses Muster „was zuerst eintritt“ schreiben Maschinenbauer in ihre Serviceverträge.

Drei Regeln aus der Hilfe bestimmen das Design:

• Immer nur ein offener Arbeitsauftrag. Solange ein erzeugter Arbeitsauftrag nicht abgeschlossen ist, erzeugt die Regel keinen neuen. Als abgeschlossen gelten Cannot Complete, Canceled, Completed und Closed.
• Die Bedingung muss zurückgesetzt werden. Trifft die Bedingung nach dem Abschluss noch zu, erzeugt der nächste Lauf den nächsten Arbeitsauftrag. Das Beispiel der Hilfe: Die kumulierte Stillstandszeit steigt von 982 auf 1.024 Stunden, ein Arbeitsauftrag entsteht, und weil der Wert über 1.000 bleibt, folgt der nächste. Vergleichen Sie deshalb gegen „Stunden seit letzter Wartung“ und speichern Sie den Zählerstand beim Abschluss, etwa per Flow, wenn der Arbeitsauftrag geschlossen wird. Die Hilfe schlägt dasselbe vor: ein eigenes Feld aktualisieren, wenn Arbeitsaufträge abgeschlossen werden.
• Feldtypen. URL-, Mehrfachauswahl-, verschlüsselte und Textbereichsfelder gehen nicht, Währungsfelder können keine Filterkriterien bilden. Zähler gehören in Zahlenfelder.

Die Hilfe nennt außerdem Asset-Attribute als Weg, Werte wie Schaltspiele seit der letzten Überholung zu führen. Das Objekt AssetAttribute2 gibt es seit API-Version 57.0. Wann ich Attribute und wann Felder nutze, beschreibe ich in Asset-Hierarchie im Field Service: Wie tief pro Maschine?.

Ein Detail bei den Berechtigungen: Die Objekte Maintenance Work Rule und Recordset Filter Criteria brauchen denselben Zugriff und dieselbe Freigabe, sonst greifen die Regeln für manche Nutzer nicht.

Woher kommt der Zähler?

Die Hilfe nennt drei Quellen: von Hand gepflegt, von einer IoT-Plattform aktualisiert oder über eine Integration vom AppExchange. Beim Maschinenbauer heißt das meist:

• Die IoT-Plattform schreibt einmal am Tag die Betriebsstunden der vernetzten Maschinen.
• Das ERP, zum Beispiel SAP, schickt Zählerstände, die es ohnehin vom Kunden oder aus Serviceberichten bekommt.
• Der Techniker liest den Zähler vor Ort ab und trägt ihn in der mobilen App ein. Für nicht vernetzte Maschinen ist das die einzige Quelle.

Ein Wert pro Tag reicht. Ein Intervall von 2.000 Stunden braucht keine Minutenwerte, und 1.200 Zählerstände am Tag sind eine kleine Schnittstelle. Die Zeitreihen bleiben in der IoT-Plattform oder im Historian, wie in Predictive Maintenance in Salesforce: die Datenbasis beschrieben. Legen Sie fest, welche Quelle gewinnt, wenn zwei sich widersprechen, etwa wenn der Techniker 2.140 Stunden abliest und das ERP noch 1.980 zeigt. Wie bei allen Stammdaten braucht es pro Feld ein führendes System, siehe welche Daten die Terminplanung braucht. Die Schnittstelle selbst gehört auf die Liste der Salesforce-Schnittstellen.

Die Limits: 2.600 Aufträge pro Lauf, 2.000 Assets pro Plan

Die Limits von Field Service3, die nutzungsbasierte Pläne zuerst treffen:

2.600

Arbeitsaufträge und Positionen zusammen, höchstens pro Wartungsplan und Generierungslauf

2.000

Wartungs-Assets, höchstens in einem Plan mit einer Regel vom Typ Count

5

Maintenance Work Rules pro Plan oder Asset, höchstens (Empfehlung von Salesforce)

365 Tage

Generation Horizon, höchstens

Als praktische Grenze nennt die Hilfe 2.600 Assets pro Plan, weniger als 1.300 bei zwei Regeln pro Asset und weniger als 650 bei vier. Der Generation Timeframe beträgt höchstens 20 Jahre.

In der Praxis teile ich Pläne nach Baureihe oder Serviceregion. So bleibt jeder Plan unter den Grenzen, und jeder hat einen Verantwortlichen.

Rechenbeispiel: 1.200 Kompressoren

Die Zahlen sind angenommen. Ein Hersteller von Kompressoren betreut 1.200 Anlagen im Feld unter Vertrag. Im Vertrag steht: Wartung alle 2.000 Betriebsstunden oder alle 12 Monate, je nachdem, was zuerst eintritt. 800 Anlagen sind vernetzt, 400 nicht.

Daten. Jedes Asset bekommt ein Zahlenfeld für die Betriebsstunden, ein Feld für den Stand bei der letzten Wartung und das Datum der letzten Wartung. Eine Formel berechnet die Stunden seit der letzten Wartung, eine zweite die Monate. Die IoT-Plattform schreibt jede Nacht die Stunden der vernetzten Anlagen. Bei den übrigen 400 tragen Techniker den Stand bei jedem Einsatz ein, dort greift die 12-Monats-Bedingung.

Regel. Eine kriterienbasierte Regel mit zwei Bedingungen, verknüpft mit ODER. Ein Flow schreibt Zählerstand und Datum ans Asset, wenn der Arbeitsauftrag abgeschlossen wird, und setzt damit beide Bedingungen zurück.

Pläne. Drei Pläne nach Region mit je etwa 400 Assets, weit unter 2.600 Arbeitsaufträgen pro Lauf.

Wirkung. Angenommen, die Hälfte der vernetzten Anlagen läuft zweischichtig mit etwa 4.000 Stunden im Jahr: Sie bekommen zwei Wartungen im Jahr statt einer. Einschichtige Anlagen mit 1.800 Stunden im Jahr fallen auf die 12-Monats-Bedingung zurück. Verglichen mit einem festen Halbjahresrhythmus für alle 1.200 Anlagen sind das 1.600 statt 2.400 Einsätze im Jahr, und die stark genutzten Kompressoren werden trotzdem rechtzeitig gewartet.

Erster Schritt: eine Baureihe mit zehn Assets in der Sandbox

Nehmen Sie eine Baureihe und schreiben Sie das Intervall aus dem Vertrag in einem Satz auf. Prüfen Sie, wo der Zähler heute liegt und wie oft er aktualisiert wird. Dann bauen Sie Felder, eine kriterienbasierte Regel und den Flow zum Zurücksetzen in einer Sandbox und testen mit zehn echten Assets, bevor Sie die ganze Baureihe umstellen. Das Masterclass-Kapitel zu Assets, Wartung und Teilen zeigt, wo das neben Verträgen, Ersatzteilen und Servicepartnern steht.

Quellen3

1. 1vorbeugenden Wartung (öffnet in einem neuen Tab)help.salesforce.com
2. 2Objekt AssetAttribute (öffnet in einem neuen Tab)developer.salesforce.com
3. 3Limits von Field Service (öffnet in einem neuen Tab)help.salesforce.com