Asset-Hierarchie im Field Service: Wie tief pro Maschine?

Ein Maschinenbauer sollte nur das als Asset abbilden, was eine eigene Seriennummer, eine eigene Wartung oder eine eigene Garantie hat. Für die meisten Maschinen heißt das zwei oder drei Ebenen: die Linie oder Maschine, ihre Hauptbaugruppen mit Seriennummer und vielleicht einige Zukaufteile mit eigener Garantie. Alles andere bleibt in der Stückliste im PLM. Salesforce Field Service erlaubt deutlich mehr: 2.000 untergeordnete Assets pro Asset, 50 Ebenen und 10.000 Assets pro Hierarchie. Die echten Grenzen kommen früher, von Wartungsplänen, Datenpflege und der Baumansicht, die Hierarchien bis 500 Assets zeigt.

Was erlaubt Salesforce?

Laut Trailhead1 steht ein Asset für ein bestimmtes gekauftes oder installiertes Produkt. Es kann mit Cases, Arbeitsaufträgen, Wartungsplänen, Entitlements und Serviceverträgen verknüpft werden, und jedes Asset muss an einem Account, einem Kontakt oder beidem hängen. Die Hierarchie entsteht über das Feld Parent Asset. Trailhead beschreibt Asset-Hierarchien als Weg, zusammengehörige Assets wie die Komponenten einer Maschine als Einheit zu führen, und zeigt sie in einer aufklappbaren Baumansicht.

Die Field-Service-Limits2 in der Salesforce-Hilfe:

Limit	Wert
Untergeordnete Assets pro Asset	2.000
Ebenen in einer Hierarchie	50
Assets in einer Hierarchie	10.000
Größe einer Hierarchie in der Baumansicht	500

Ersetzt eine Komponente eine andere, hält eine Asset-Beziehung das fest, zum Beispiel vom Typ Upgrade. Das alte Asset bleibt mit seiner Historie erhalten, das neue nimmt seinen Platz ein.

Welche Komponenten sollten Assets werden?

Meine Faustregel hat drei Fragen. Wird eine davon mit Ja beantwortet, wird die Komponente ein Asset:

• Hat sie eine eigene Seriennummer? Ein zugekauftes Getriebe, ein Roboter oder ein Schaltschrank mit Typenschild. Der Techniker muss festhalten, welches Exemplar eingebaut oder getauscht wurde.
• Hat sie eine eigene Wartung? Eine Spindel mit eigenem Intervall in Betriebsstunden, eine Filteranlage mit eigener Prüfung. Maintenance Work Rules hängen an Assets, also braucht die Komponente eines.
• Hat sie eine eigene Garantie? Ein Lieferantenteil, dessen Garantie an einem anderen Datum beginnt als die der Maschine. Ohne eigenes Asset kann niemand sagen, ob der Anspruch an den Lieferanten geht.

Alles andere bleibt in der Stückliste: Schrauben, Dichtungen, Kabel, Normteile. Der Techniker muss sie trotzdem finden, aber das ist eine Frage für PLM und Ersatzteilkatalog. In Ersatzteile per Seriennummer empfehle ich dieselbe Aufteilung: Salesforce führt die Maschine und ihre für den Service wichtigen Hauptbaugruppen, die vollständige As-built-Stückliste bleibt im PLM und wird live gelesen.

Felder oder Asset-Attribute für Maschinendaten?

Baureihen unterscheiden sich. Die eine hat eine Firmware-Version und einen Hubzähler, die nächste eine Laserquelle mit Stunden und eine Kühlmittelsorte. Bekommt jede Baureihe ihre eigenen Felder am Asset, wächst das Objekt mit jeder neuen Produktlinie.

Das Objekt AssetAttribute3, verfügbar seit API-Version 57.0, speichert laut Dokumentation Asset-Attribute, um den Zustand von Assets zu verfolgen und auszuwerten. Jeder Datensatz verbindet ein Asset mit einer Attributdefinition und speichert einen Wert, bei Auswahllisten mit den zugehörigen Werten. Neue Attribute brauchen eine neue Definition, kein neues Feld.

Ich nutze Attribute für beschreibende Werte, die je Baureihe verschieden sind. Für Zähler, die über alle Baureihen Wartungspläne und Berichte steuern, etwa Betriebsstunden, nehme ich lieber ein Zahlenfeld am Asset, weil Filterkriterien für Wartungsregeln nicht jeden Feldtyp nutzen können. Wie das im Detail funktioniert, steht in Wartung nach Betriebsstunden im Field Service einrichten.

Wer hält die Hierarchie aktuell?

Die installierte Basis kommt meist bei Auslieferung aus dem ERP: Maschine, Seriennummern der Hauptbaugruppen, Kunde, Standort, Lieferdatum. Dieser Import ist der einfache Teil. Der schwierige beginnt ein Jahr später, wenn ein Techniker ein Getriebe tauscht, ein Kunde einen zweiten Roboter nachrüstet oder ein Händler die Maschine in ein anderes Werk bringt.

Ohne festen Prozess zeigt die Hierarchie in Salesforce dann die Maschine im Auslieferungszustand, und niemand vertraut ihr mehr. Diese Punkte gehören vor dem Go-live geklärt:

1. Wer erfasst eine getauschte Baugruppe? Aus meiner Sicht der Techniker in der mobilen App, mit der Seriennummer des neuen Teils, denn er hat es in der Hand.
2. Welches System führt danach? Bleibt das ERP führend für die installierte Basis, muss die Änderung aus der App zurück ins ERP. Führt Salesforce nach der Auslieferung, bekommt das ERP eine Kopie. Beides funktioniert, eine Mischung nicht. Das ist dieselbe Frage nach dem führenden System wie bei den Stammdaten für die Planung, und sie gehört in das Schnittstellendesign, siehe Salesforce-Schnittstellen.
3. Was ist mit Umbauten durch Händler oder Kunden? Tauscht ein Händler eine Komponente und meldet nur Garantiefälle, hat die Hierarchie Lücken. Das schadet auch jeder späteren Auswertung, wie in Predictive Maintenance in Salesforce: die Datenbasis beschrieben.

Garantieansprüche auf die installierte Basis gehören zu Manufacturing Cloud und stehen im Kapitel Garantie und After-Sales dieser Masterclass.

Eine tiefe Hierarchie kostet später

Jede Ebene wirkt billig, wenn die Daten einmal geladen werden. Teuer wird sie später, an drei Stellen:

2.600

Assets pro Wartungsplan als praktische Grenze

1.300

Assets pro Plan bei zwei Maintenance Work Rules je Asset

500

Assets, ab denen die Baumansicht die Hierarchie nicht mehr zeigt

• Wartungspläne. Die Hilfe nennt 2.600 Assets pro Plan als praktische Grenze, weniger als 1.300 bei zwei Maintenance Work Rules pro Asset. Ist jede Komponente ein Wartungs-Asset, laufen Pläne schnell voll.
• Die Baumansicht. Über 500 Assets lässt sich die Hierarchie nicht mehr in der Baumansicht darstellen. Eine Linie mit 900 Teilen als Assets ist für den Innendienst dann nicht mehr lesbar.
• Die mobile App. Das Gerät des Technikers lädt die Datensätze zu seinen Aufträgen. Aus meiner Sicht verlängert jeder zusätzliche Datensatz pro Maschine die Ladezeit und vergrößert die Datenmenge, die offline aktuell bleiben muss. Ich lasse ein Teil deshalb lieber im PLM, als es auf jedes Tablet zu tragen.

Dasselbe gilt für Händlerportale: Jedes Asset, das ein Händler sehen darf, muss richtig freigegeben sein, wie beim Ersatzteilshop pro Maschine.

Rechenbeispiel: eine Verpackungslinie

Alle Zahlen sind Annahmen. Ein Hersteller von Verpackungsmaschinen liefert eine Linie mit 6 Maschinen. Darin stecken 40 Baugruppen mit Seriennummer, etwa Servoantriebe, Roboter und Etikettierer, und rund 900 weitere Teile.

Vollständige Kopie. Linie, Maschinen, Baugruppen und Teile als Assets: etwa 947 Datensätze pro Linie. Das liegt weit unter dem Limit von 10.000, aber über den 500, die die Baumansicht zeigt, und 900 Datensätze pro Linie müssen mit dem PLM übereinstimmen.

Empfohlene Tiefe. Die Linie als oberstes Asset, weil der Servicevertrag sie als Ganzes abdeckt. Darunter die 6 Maschinen, darunter die 40 Baugruppen mit Seriennummer: 47 Assets in drei Ebenen. Zwölf Baugruppen mit eigenem Intervall bekommen Maintenance Work Rules. Die 900 Teile bleiben im PLM und erscheinen auf der Maschinenseite oder im Agenten, wenn jemand sie braucht.

Bei 50 Linien im Feld sind das 2.350 Assets statt rund 47.000, und jedes davon trägt eine Information, die der Service nutzt.

Einen Maschinentyp mit der Faustregel durchgehen

Nehmen Sie einen Maschinentyp und gehen Sie seine Stückliste mit der Faustregel durch: Seriennummer, eigene Wartung, eigene Garantie. Schreiben Sie die Ebenen auf, die dabei herauskommen, und zählen Sie die Assets pro Maschine. Dann entscheiden Sie, wer eine getauschte Baugruppe erfasst und welches System nach der Auslieferung führt, und zwar vor dem ersten Import aus dem ERP. Das Masterclass-Kapitel zu Assets, Wartung und Teilen zeigt, wie die Hierarchie mit Wartungsplänen, Ersatzteilen und Servicepartnern zusammenhängt.

Quellen3

1. 1Trailhead (öffnet in einem neuen Tab)trailhead.salesforce.com
2. 2Field-Service-Limits (öffnet in einem neuen Tab)help.salesforce.com
3. 3Objekt AssetAttribute (öffnet in einem neuen Tab)developer.salesforce.com