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

Réponse courte : la gestion du cycle de vie des actifs sur Salesforce fonctionne quand l'unité installée est un seul enregistrement Asset que le service, la garantie et les renouvellements lisent tous, au lieu de trois enregistrements dans trois équipes. Salesforce fournit déjà les objets : Asset avec sa hiérarchie parent, WarrantyTerm et AssetWarranty pour la couverture, Entitlement ou ServiceContract pour ce que le client a acheté. Le point dur, c'est la télémétrie, car les événements des appareils ne doivent pas entrer ligne par ligne dans l'org.

Que veut dire gestion du cycle de vie des actifs sur Salesforce ?

Cela veut dire suivre une unité physique de l'expédition à l'installation, au service, aux demandes de garantie, aux mises à niveau et au remplacement, sur un enregistrement qui porte son propre historique. Salesforce regroupe cela sous Asset Service Lifecycle Management : hiérarchie d'actifs interactive, vue de couverture pour les entitlements, estimation des ordres de travail et campagnes de service produit pour les rappels et les mises à niveau (aide Salesforce).

Les fonctionnalités sont la partie facile. Ce qui décide du résultat, c'est le modèle de données choisi dès la première semaine.

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.
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.

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 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. Ajoutez seulement ensuite ordres de travail, contrats de service, prévision des renouvellements et 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, Tekunda mène des projets de cycle de vie des actifs sur Salesforce, aux côtés de Field Service et de la livraison d'appareils connectés.

FAQ

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.