Gestion du cycle de vie des actifs connectés sur Salesforce

Réponse courte : Salesforce Asset Service Lifecycle Management (ASLM) est l'ensemble de fonctionnalités packagées de Salesforce pour assurer le service d'un actif physique de l'installation à la mise hors service : hiérarchie d'actifs interactive, vue de couverture des entitlements, estimation des ordres de travail, campagnes de rappel et de mise à niveau, échanges, réparation en atelier et stock de service, le tout sur l'objet Asset standard. Cela fonctionne quand chaque unité installée est un seul enregistrement Asset que le service, la garantie et les renouvellements lisent tous. Pour les appareils connectés, le point dur est la télémétrie, car les événements des appareils ne doivent pas entrer ligne par ligne dans l'org.

Qu'est-ce que Salesforce Asset Service Lifecycle Management ?

Salesforce le décrit comme un moyen de « gérer tout le cycle de vie des opérations de service sur les actifs » (aide Salesforce). En pratique, il se range en cinq domaines :

• Visibilité des actifs. Asset Interactive Hierarchy montre les actifs parents et enfants, et Asset Coverage View place les entitlements du client sous les yeux de l'agent.
• Exécution du service. Work Order Estimation chiffre le travail avant son démarrage, Book Service Appointment gère la planification et Product Service Campaign pilote les rappels et mises à niveau à grande échelle.
• Retours et réparation. Advanced Exchange crée les demandes de retour et de remplacement, Depot Repair traite les unités renvoyées en réparation et Service Parts Return couvre les pièces endommagées liées aux ordres de travail.
• Stock de service. Allocation du stock, gestion des lots, recherche et transfert, inventaires et réapprovisionnement.
• Main-d'oeuvre et IA. Feuilles de temps et Labor Cost Optimization, plus Agentforce for ASLM, qui fournit des modèles d'agents pour les tâches de stock et l'estimation de service.

En bref : Salesforce standard vous donne l'actif et sa couverture, et ASLM ajoute les opérations de service qui tournent autour.

Quels clouds et quelles licences pour ASLM ?

Selon le même article d'aide, ASLM est disponible dans Lightning Experience pour Service Cloud, Manufacturing Cloud, Automotive Cloud, Communications Cloud, Consumer Goods Cloud, Energy and Utilities Cloud et Media Cloud. Certaines fonctionnalités exigent des licences complémentaires, achetées via Salesforce Go : vérifiez le tableau des éditions de chaque fonctionnalité avant de bâtir un plan dessus.

Deux produits voisins se confondent facilement avec lui. Lorsque Salesforce a annoncé ASLM en juin 2024 comme module complémentaire distinct, il a aussi annoncé Connected Assets, un autre module pour agir sur les événements télématiques bidirectionnels (mises à jour de firmware, création d'ordres de travail, alertes de sécurité), et un Asset Health Score pour Field Service (Futurum Group). ASLM est la couche de service. Connected Assets et votre propre intégration sont la couche de télémétrie.

Quel objet doit porter quoi ?

La plupart des programmes d'actifs connectés sur lesquels on nous appelle ont échoué ici, pas sur l'intégration. Une répartition propre ressemble à ceci.

• Product2 est le modèle. C'est ce que vous vendez, pas ce que le client possède.
• Asset est l'unité individuelle : numéro de série, date d'installation, statut, compte, contact et emplacement. Servez-vous des champs d'actif parent et racine pour un appareil loge dans une passerelle, un panneau ou un bâtiment, afin qu'une panne de composant remonte vers quelque chose où l'on peut envoyer un technicien.
• WarrantyTerm définit ce qui est couvert, main-d'oeuvre, pièces et frais, et AssetWarranty rattache ce terme à une unité précise avec ses propres dates (référence d'objet).
• Entitlement et ServiceContract portent ce que le client a acheté et jusqu'à quand. Les entitlements peuvent se rattacher au compte, à l'actif, à la requête ou au contrat, et c'est exactement pour cela que la même couverture finit consignée à trois endroits.
• Case et WorkOrder référencent l'actif, jamais le produit. Une requête sans identifiant d'actif ne peut être ni facturée, ni couverte, ni analysée.

Une règle garde le modèle honnête : la couverture est affirmée à un seul endroit et tout le reste la lit. Si le commerce peut modifier une date de renouvellement que le service ne voit pas, vous n'avez pas de gestion du cycle de vie, vous avez trois tableurs déguisés.

Comment faire entrer la télémétrie sans noyer l'org ?

Salesforce a retiré IoT Explorer et a orienté les clients vers les événements de plateforme et les flows (avis de retrait). L'instinct est bon, à condition d'y ajouter une règle : Salesforce stocke l'état et les décisions, pas le flux brut.

En pratique, nous exploitons trois couches.

1. Ingérer et réduire hors de l'org. Battements, relevés et alarmes en double sont repliés en transitions significatives avant de franchir la frontière de l'API.
2. Publier les transitions comme événements de plateforme. Un événement par changement d'état, portant numéro de série, condition et horodatage, résolu vers l'Asset par numéro de série et non par identifiant d'enregistrement. Le compte d'intégration qui les publie s'authentifie en général via une connected app : faites-la relire avant la mise en production, en vous appuyant sur notre guide sur les changements de sécurité des connected apps Salesforce.
3. Écrire l'état dérivé sur l'Asset et laisser l'automatisation décider. Santé actuelle, dernière vue, version de firmware, panne ouverte. Un flow ou un gestionnaire Apex tranche ensuite : requête, ordre de travail, ou rien.

Cette dernière option compte le plus. C'est la règle de triage, pas l'ingestion, qui garde un parc connecté réparable. Pour ASSA ABLOY, chez FocusCura et Phoniro, nous exploitons 11 000 appareils connectés produisant jusqu'à 2,5 millions d'événements par semaine et avons ramené les requêtes hebdomadaires de 3 000 à 350, soit 93% de moins, sur trois marchés et sans renfort au support. Les appareils ne se sont pas tus. Le modèle a cessé de créer une requête par symptôme. Le détail complet est dans comment les équipes d'appareils connectés réduisent leurs requêtes de 93 % sur Salesforce.

Qu'apporte réellement un enregistrement d'actif unique ?

• Le service voit la couverture avant l'envoi, donc personne ne facture un déplacement sur une unité sous garantie.
• Les demandes de garantie se résolvent contre le terme attaché à cette unité, pas contre une police dont quelqu'un se souvient.
• Les rappels et mises à niveau ciblent les bonnes unités, car une campagne de service produit ne peut atteindre que des actifs portant un vrai modèle, un numéro de série et une version de firmware.
• Les renouvellements se prévoient à partir de dates d'installation et de fin de garantie déjà présentes, si bien que les expirations ne sont plus découvertes par le client.
• Les équipes produit obtiennent des taux de panne par modèle et par version de firmware, parce que chaque requête désigne une unité réelle.

Rien de tout cela n'exige une couche d'IA pour valoir le détour. En revanche cela la rend possible ensuite, car un agent ne peut raisonner que sur un parc installé réellement modélisé.

Dans quel ordre construire ?

1. Chargez le parc installé avec de vrais numéros de série et dates d'installation, même partiellement. Un actif sans numéro de série ne se réconcilie pas plus tard.
2. Modélisez la hiérarchie avant toute automatisation, car reprendre ce point touche chaque enregistrement en aval.
3. Attachez les termes de garantie et les entitlements, et désignez l'objet unique qui détient la couverture.
4. Câblez la télémétrie en transitions d'état, avec une règle de triage écrite par condition.
5. N'activez qu'ensuite les fonctionnalités ASLM comme l'estimation, les campagnes et les échanges, avec les contrats de service, la prévision des renouvellements et les agents.

Les équipes qui inversent les étapes une et quatre se retrouvent avec une intégration superbe qui écrit des événements sur des actifs auxquels personne ne se fie. Pour faire relire tout cela sur votre propre org, découvrez comment Tekunda mène la gestion du cycle de vie des actifs sur Salesforce aux côtés de Field Service et de la livraison d'appareils connectés.

FAQ

Qu'est-ce que Salesforce Asset Service Lifecycle Management en une phrase ?

C'est un ensemble de fonctionnalités Salesforce pour assurer le service des actifs installés de bout en bout, de la hiérarchie et la couverture jusqu'aux estimations, rappels, échanges, réparations et stock de service.

Chaque appareil doit-il être un Asset ou un objet personnalisé ?

Un Asset, dans presque tous les cas. Entitlements, garanties, ordres de travail et Field Service lui sont déjà reliés, alors qu'un objet personnalisé oblige à refaire ces relations à la main.

Où doit vivre la télémétrie brute ?

Hors de l'org transactionnelle, dans un stockage conçu pour les séries temporelles. Salesforce garde l'état courant, les événements qui l'ont changé et les décisions prises, pas chaque relevé.

Quelle différence entre garantie et entitlement ?

Un terme de garantie décrit ce qui est couvert sur une unité : pièces, main-d'oeuvre, frais. Un entitlement ou contrat de service décrit ce que le client a acheté, niveaux de support et dates compris. La plupart des organisations ont besoin des deux.

Peut-on faire cela sans Field Service ?

Oui. La modélisation des actifs, garanties et entitlements fonctionne dans Service Cloud seul. Field Service devient nécessaire dès que vous envoyez des techniciens, gérez des pièces et planifiez des visites de maintenance.