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

Kurze Antwort: Salesforce Asset Service Lifecycle Management (ASLM) ist das gepackte Funktionspaket von Salesforce, um ein physisches Asset von der Installation bis zur Stilllegung zu betreuen: interaktive Asset-Hierarchie, Abdeckungsansicht für Entitlements, Aufwandsschätzung für Arbeitsaufträge, Rückruf- und Upgrade-Kampagnen, Austausch, Depotreparatur und Serviceinventar, alles auf dem Standardobjekt Asset. Es funktioniert, wenn jede installierte Einheit ein einziger Asset-Datensatz ist, den Service, Garantie und Verlängerungen gemeinsam lesen. Bei vernetzten Geräten ist die Telemetrie der schwierige Teil, denn Geräteereignisse dürfen nicht Zeile für Zeile in der Org landen.

Was ist Salesforce Asset Service Lifecycle Management?

Salesforce beschreibt ASLM als Weg, „den gesamten Lebenszyklus von Asset-Serviceprozessen zu verwalten" (Salesforce Hilfe). In der Praxis gliedert es sich in fünf Funktionsbereiche:

• Asset-Transparenz. Die Asset Interactive Hierarchy zeigt übergeordnete und untergeordnete Assets, und die Asset Coverage View legt dem Agenten die Entitlements des Kunden vor.
• Serviceausführung. Work Order Estimation bepreist Arbeit vor dem Start, Book Service Appointment übernimmt die Terminplanung und Product Service Campaign steuert Rückrufe und Upgrades im großen Maßstab.
• Rücksendung und Reparatur. Advanced Exchange erzeugt Rücksende- und Austauschanfragen, Depot Repair bearbeitet zur Reparatur eingesandte Einheiten und Service Parts Return deckt beschädigte Teile ab, die an Arbeitsaufträge gebunden sind.
• Serviceinventar. Bestandszuordnung, Chargenverwaltung, Suche und Umlagerung, Zählungen und Nachschub.
• Arbeitszeit und KI. Zeiterfassung und Labor Cost Optimization sowie Agentforce for ASLM, das Agentenvorlagen für Bestandsaufgaben und Serviceschätzungen liefert.

Kurz gesagt: Standard-Salesforce liefert das Asset und seine Abdeckung, ASLM ergänzt die Serviceabläufe drumherum.

Welche Clouds und Lizenzen braucht ASLM?

Laut demselben Hilfeartikel ist ASLM in Lightning Experience in Service Cloud, Manufacturing Cloud, Automotive Cloud, Communications Cloud, Consumer Goods Cloud, Energy and Utilities Cloud und Media Cloud verfügbar. Einige Funktionen benötigen Zusatzlizenzen, die über Salesforce Go gekauft werden. Prüfen Sie daher die Editionstabelle jeder Funktion, bevor Sie darauf planen.

Zwei verwandte Produkte werden leicht damit verwechselt. Als Salesforce ASLM im Juni 2024 als eigenes Add-on ankündigte, kündigte es auch Connected Assets an, ein separates Add-on, um auf bidirektionale Telematik-Ereignisse zu reagieren, etwa Firmware-Updates, das Anlegen von Arbeitsaufträgen oder Sicherheitsmeldungen, sowie einen Asset Health Score für Field Service (Futurum Group). ASLM ist die Serviceschicht. Connected Assets und Ihre eigene Integration bilden die Telemetrieschicht.

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. Der Integrationsbenutzer, der sie veröffentlicht, authentifiziert sich meist über eine Connected App. Lassen Sie diese vor dem Go-live prüfen, anhand unseres Leitfadens zu den Sicherheitsänderungen bei Salesforce Connected Apps.
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. Die vollständige Aufschlüsselung steht in wie Teams mit vernetzten Geräten ihre Support-Cases auf Salesforce um 93 Prozent senken.

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.
• Rückrufe und Upgrades erreichen die richtigen Einheiten, weil eine Product Service Campaign nur Assets erreichen kann, die ein echtes Modell, eine Seriennummer und einen Firmwarestand tragen.
• 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 ASLM-Funktionen wie Schätzung, Kampagnen und Austausch aktivieren, zusammen mit Serviceverträgen, Verlängerungsprognosen und Agenten.

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, lesen Sie, wie Tekunda Asset Lifecycle Management auf Salesforce zusammen mit Field Service und vernetzten Geräten umsetzt.

FAQ

Was ist Salesforce Asset Service Lifecycle Management in einem Satz?

Ein Satz von Salesforce-Funktionen, um installierte Assets durchgängig zu betreuen, von Hierarchie und Abdeckung bis zu Schätzungen, Rückrufen, Austausch, Reparatur und Serviceinventar.

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.