Asset Lifecycle Management fur vernetzte Gerate auf Salesforce

Kurze Antwort: Asset Lifecycle Management auf Salesforce funktioniert, wenn die installierte Einheit ein einziger Asset-Datensatz ist, den Service, Garantie und Verlangerungen gemeinsam lesen, statt drei Datensatzen in drei Teams. Die Objekte dafur liefert Salesforce bereits: Asset mit Eltern-Hierarchie, WarrantyTerm und AssetWarranty fur die Abdeckung sowie Entitlement oder ServiceContract fur das, was der Kunde gekauft hat. Schwierig wird es bei der Telemetrie, denn Gerateereignisse durfen nicht Zeile fur Zeile in der Org landen.

Was bedeutet Asset Lifecycle Management auf Salesforce?

Es bedeutet, eine physische Einheit von der Auslieferung uber Installation, Service, Garantiefalle und Upgrades bis zum Austausch auf einem Datensatz zu verfolgen, der seine eigene Historie tragt. Salesforce bundelt das als Asset Service Lifecycle Management, mit interaktiver Asset-Hierarchie, Abdeckungsansicht fur Entitlements, Aufwandsschatzung fur Arbeitsauftrage und Product Service Campaigns fur Ruckrufe und Upgrades (Salesforce Hilfe).

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

Welches Objekt soll was halten?

Die meisten gescheiterten Programme fur 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 fur ubergeordnete und Wurzel-Assets fur ein Gerat, das in einem Gateway, einem Schaltschrank oder einem Gebaude 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 hangt diesen Term mit eigenen Datumsangaben an eine konkrete Einheit (Objektreferenz).
• Entitlement und ServiceContract tragen, was der Kunde gekauft hat und bis wann. Entitlements konnen am Account, am Asset, am Case oder am Vertrag hangen, 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 lasst sich weder abrechnen noch abdecken noch auswerten.

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

Wie bekommt man Telemetrie herein, ohne die Org zu ertranken?

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. Ausserhalb der Org einlesen und verdichten. Heartbeats, Messwerte und doppelte Alarme werden zu bedeutsamen Ubergangen zusammengefasst, bevor irgendetwas die API-Grenze passiert.
2. Ubergange als Plattformereignisse veroffentlichen. Ein Ereignis pro Zustandswechsel, mit Seriennummer, Zustand und Zeitstempel, aufgelost auf das Asset uber die Seriennummer statt uber 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 uber Case, Arbeitsauftrag oder gar nichts.

Die letzte Option wiegt am schwersten. Die Triage-Regel, nicht die Datenaufnahme, halt eine vernetzte Flotte wartbar. Fur ASSA ABLOY betreiben wir bei FocusCura und Phoniro 11.000 vernetzte Gerate mit bis zu 2,5 Millionen Ereignissen pro Woche und haben die wochentlichen Falle von 3.000 auf 350 gesenkt, also um 93%, in drei Markten und ohne zusatzliches Supportpersonal. Die Gerate wurden nicht leiser. Das Modell horte auf, fur 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.
• Garantiefalle werden gegen den Term dieser Einheit entschieden, nicht gegen eine Police, an die sich jemand erinnert.
• Verlangerungen werden aus Installations- und Garantieenddaten prognostiziert, die ohnehin im System stehen, sodass Ablaufe 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 spater moglich, denn ein Agent kann nur uber einen Bestand urteilen, der tatsachlich modelliert ist.

In welcher Reihenfolge bauen?

1. Bestand mit echten Seriennummern und Installationsdaten laden, auch unvollstandig. Assets ohne Seriennummer lassen sich spater nicht abgleichen.
2. Hierarchie modellieren, bevor irgendetwas automatisiert wird, denn Nacharbeit hier trifft jeden nachgelagerten Datensatz.
3. Garantieterme und Entitlements anhangen und das eine Objekt bestimmen, dem die Abdeckung gehort.
4. Telemetrie als Zustandsubergange verdrahten, mit einer schriftlichen Triage-Regel je Zustand.
5. Erst danach Arbeitsauftrage, Servicevertrage, Verlangerungsprognosen und Agenten erganzen.

Teams, die Schritt eins und vier vertauschen, behalten eine schone Integration, die Ereignisse auf Assets schreibt, denen niemand traut. Wenn Sie das gegen Ihre eigene Org prufen lassen wollen: Tekunda liefert Asset-Lifecycle-Projekte auf Salesforce, zusammen mit Field Service und vernetzten Geraten.

FAQ

Soll jedes Gerat ein Asset oder ein benutzerdefiniertes Objekt sein?

Fast immer ein Asset. Entitlements, Garantien, Arbeitsauftrage und Field Service sind bereits damit verknupft, ein eigenes Objekt bedeutet, diese Beziehungen von Hand nachzubauen.

Wo gehort Rohtelemetrie hin?

Ausserhalb der transaktionalen Org, in einen Speicher fur Zeitreihen. Salesforce halt den aktuellen Zustand, die Ereignisse, die ihn geandert 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 notig, sobald Sie Techniker disponieren, Ersatzteile verwalten und Wartungsbesuche planen.