Asset Lifecycle Management für vernetzte Geräte auf Salesforce

Kurze Antwort: Asset Lifecycle Management auf Salesforce funktioniert, wenn die installierte Einheit ein einziger Asset-Datensatz ist, den Service, Garantie und Verlängerungen gemeinsam lesen, statt drei Datensätzen in drei Teams. Die Objekte dafür liefert Salesforce bereits: Asset mit Eltern-Hierarchie, WarrantyTerm und AssetWarranty für die Abdeckung sowie Entitlement oder ServiceContract für das, was der Kunde gekauft hat. Schwierig wird es bei der Telemetrie, denn Geräteereignisse dürfen nicht Zeile für Zeile in der Org landen.

Was bedeutet Asset Lifecycle Management auf Salesforce?

Es bedeutet, eine physische Einheit von der Auslieferung über Installation, Service, Garantiefälle und Upgrades bis zum Austausch auf einem Datensatz zu verfolgen, der seine eigene Historie trägt. Salesforce bündelt das als Asset Service Lifecycle Management, mit interaktiver Asset-Hierarchie, Abdeckungsansicht für Entitlements, Aufwandsschätzung für Arbeitsaufträge und Product Service Campaigns für Rückrufe und Upgrades (Salesforce Hilfe).

Die Funktionen sind der leichte Teil. Über Erfolg entscheidet das Datenmodell, auf das Sie sich in Woche eins festlegen.

Welches Objekt soll was halten?

Die meisten gescheiterten Programme für vernetzte Anlagen, zu denen wir gerufen werden, sind hier gescheitert, nicht an der Integration. Eine saubere Aufteilung sieht so aus.

• Product2 ist das Modell. Es ist, was Sie verkaufen, nicht was der Kunde besitzt.
• Asset ist die einzelne Einheit: Seriennummer, Installationsdatum, Status, Account, Kontakt und Standort. Nutzen Sie die Felder für übergeordnete und Wurzel-Assets für ein Gerät, das in einem Gateway, einem Schaltschrank oder einem Gebäude sitzt, damit ein Bauteilfehler auf etwas hochrollt, wohin man einen Techniker schicken kann.
• WarrantyTerm legt fest, was abgedeckt ist, also Arbeit, Teile und Kosten, und AssetWarranty hängt diesen Term mit eigenen Datumsangaben an eine konkrete Einheit (Objektreferenz).
• Entitlement und ServiceContract tragen, was der Kunde gekauft hat und bis wann. Entitlements können am Account, am Asset, am Case oder am Vertrag hängen, und genau deshalb steht dieselbe Abdeckung am Ende an drei Stellen.
• Case und WorkOrder verweisen auf das Asset, nie auf das Produkt. Ein Case ohne Asset-Id lässt sich weder abrechnen noch abdecken noch auswerten.

Eine Regel hält das Modell ehrlich: Abdeckung wird an genau einer Stelle festgeschrieben, alles andere liest sie. Kann der Vertrieb ein Verlängerungsdatum ändern, das der Service nicht sieht, haben Sie kein Asset Lifecycle Management, sondern drei getarnte Tabellen.

Wie bekommt man Telemetrie herein, ohne die Org zu ertränken?

Salesforce hat IoT Explorer eingestellt und Kunden auf Plattformereignisse und Flows verwiesen (Einstellungshinweis). Der Instinkt stimmt, braucht aber eine Regel: Salesforce speichert Zustand und Entscheidungen, nicht den Rohstrom.

In der Praxis betreiben wir drei Schichten.

1. Außerhalb der Org einlesen und verdichten. Heartbeats, Messwerte und doppelte Alarme werden zu bedeutsamen Übergängen zusammengefasst, bevor irgendetwas die API-Grenze passiert.
2. Übergänge als Plattformereignisse veröffentlichen. Ein Ereignis pro Zustandswechsel, mit Seriennummer, Zustand und Zeitstempel, aufgelöst auf das Asset über die Seriennummer statt über die Datensatz-Id.
3. Abgeleiteten Zustand auf das Asset schreiben und die Automatisierung entscheiden lassen. Aktueller Zustand, zuletzt gesehen, Firmwarestand, offener Fehler. Ein Flow oder Apex-Handler entscheidet dann über Case, Arbeitsauftrag oder gar nichts.

Die letzte Option wiegt am schwersten. Die Triage-Regel, nicht die Datenaufnahme, hält eine vernetzte Flotte wartbar. Für ASSA ABLOY betreiben wir bei FocusCura und Phoniro 11.000 vernetzte Geräte mit bis zu 2,5 Millionen Ereignissen pro Woche und haben die wöchentlichen Fälle von 3.000 auf 350 gesenkt, also um 93%, in drei Märkten und ohne zusätzliches Supportpersonal. Die Geräte wurden nicht leiser. Das Modell hörte auf, für jedes Symptom einen Fall anzulegen.

Was bringt ein einziger Asset-Datensatz wirklich?

• Der Service sieht die Abdeckung vor der Disposition, niemand schickt also einen kostenpflichtigen Techniker zu einer Einheit mit Garantie.
• Garantiefälle werden gegen den Term dieser Einheit entschieden, nicht gegen eine Police, an die sich jemand erinnert.
• Verlängerungen werden aus Installations- und Garantieenddaten prognostiziert, die ohnehin im System stehen, sodass Abläufe nicht mehr vom Kunden entdeckt werden.
• Produktteams erhalten Ausfallraten je Modell und Firmwarestand, weil jeder Fall auf eine reale Einheit zeigt.

Nichts davon braucht eine KI-Schicht, um sich zu lohnen. Es macht sie aber später möglich, denn ein Agent kann nur über einen Bestand urteilen, der tatsächlich modelliert ist.

In welcher Reihenfolge bauen?

1. Bestand mit echten Seriennummern und Installationsdaten laden, auch unvollständig. Assets ohne Seriennummer lassen sich später nicht abgleichen.
2. Hierarchie modellieren, bevor irgendetwas automatisiert wird, denn Nacharbeit hier trifft jeden nachgelagerten Datensatz.
3. Garantieterme und Entitlements anhängen und das eine Objekt bestimmen, dem die Abdeckung gehört.
4. Telemetrie als Zustandsübergänge verdrahten, mit einer schriftlichen Triage-Regel je Zustand.
5. Erst danach Arbeitsaufträge, Serviceverträge, Verlängerungsprognosen und Agenten ergänzen.

Teams, die Schritt eins und vier vertauschen, behalten eine schöne Integration, die Ereignisse auf Assets schreibt, denen niemand traut. Wenn Sie das gegen Ihre eigene Org prüfen lassen wollen: Tekunda liefert Asset-Lifecycle-Projekte auf Salesforce, zusammen mit Field Service und vernetzten Geräten.

FAQ

Soll jedes Gerät ein Asset oder ein benutzerdefiniertes Objekt sein?

Fast immer ein Asset. Entitlements, Garantien, Arbeitsaufträge und Field Service sind bereits damit verknüpft, ein eigenes Objekt bedeutet, diese Beziehungen von Hand nachzubauen.

Wo gehört Rohtelemetrie hin?

Außerhalb der transaktionalen Org, in einen Speicher für Zeitreihen. Salesforce hält den aktuellen Zustand, die Ereignisse, die ihn geändert haben, und die getroffenen Entscheidungen, nicht jeden Messwert.

Worin unterscheiden sich Garantie und Entitlement?

Ein Garantieterm beschreibt, was an einer Einheit abgedeckt ist, etwa Teile, Arbeit und Kosten. Ein Entitlement oder Servicevertrag beschreibt, was der Kunde gekauft hat, inklusive Supportstufen und Fristen. Die meisten Organisationen brauchen beides.

Geht das ohne Field Service?

Ja. Asset-, Garantie- und Entitlement-Modellierung funktioniert allein in der Service Cloud. Field Service wird nötig, sobald Sie Techniker disponieren, Ersatzteile verwalten und Wartungsbesuche planen.