Gestion du cycle de vie des actifs connectes sur Salesforce

Reponse courte : la gestion du cycle de vie des actifs sur Salesforce fonctionne quand l'unite installee est un seul enregistrement Asset que le service, la garantie et les renouvellements lisent tous, au lieu de trois enregistrements dans trois equipes. Salesforce fournit deja les objets : Asset avec sa hierarchie parent, WarrantyTerm et AssetWarranty pour la couverture, Entitlement ou ServiceContract pour ce que le client a achete. Le point dur, c'est la telemetrie, car les evenements 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 unite physique de l'expedition a l'installation, au service, aux demandes de garantie, aux mises a niveau et au remplacement, sur un enregistrement qui porte son propre historique. Salesforce regroupe cela sous Asset Service Lifecycle Management : hierarchie 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 a niveau (aide Salesforce).

Les fonctionnalites sont la partie facile. Ce qui decide du resultat, c'est le modele de donnees choisi des la premiere semaine.

Quel objet doit porter quoi ?

La plupart des programmes d'actifs connectes sur lesquels on nous appelle ont echoue ici, pas sur l'integration. Une repartition propre ressemble a ceci.

• Product2 est le modele. C'est ce que vous vendez, pas ce que le client possede.
• Asset est l'unite individuelle : numero de serie, 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 batiment, afin qu'une panne de composant remonte vers quelque chose ou l'on peut envoyer un technicien.
• WarrantyTerm definit ce qui est couvert, main-d'oeuvre, pieces et frais, et AssetWarranty rattache ce terme a une unite precise avec ses propres dates (reference d'objet).
• Entitlement et ServiceContract portent ce que le client a achete et jusqu'a quand. Les entitlements peuvent se rattacher au compte, a l'actif, a la requete ou au contrat, et c'est exactement pour cela que la meme couverture finit consignee a trois endroits.
• Case et WorkOrder referencent l'actif, jamais le produit. Une requete sans identifiant d'actif ne peut etre ni facturee, ni couverte, ni analysee.

Une regle garde le modele honnete : la couverture est affirmee a 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 deguises.

Comment faire entrer la telemetrie sans noyer l'org ?

Salesforce a retire IoT Explorer et a oriente les clients vers les evenements de plateforme et les flows (avis de retrait). L'instinct est bon, a condition d'y ajouter une regle : Salesforce stocke l'etat et les decisions, pas le flux brut.

En pratique, nous exploitons trois couches.

1. Ingerer et reduire hors de l'org. Battements, releves et alarmes en double sont replies en transitions significatives avant de franchir la frontiere de l'API.
2. Publier les transitions comme evenements de plateforme. Un evenement par changement d'etat, portant numero de serie, condition et horodatage, resolu vers l'Asset par numero de serie et non par identifiant d'enregistrement.
3. Ecrire l'etat derive sur l'Asset et laisser l'automatisation decider. Sante actuelle, derniere vue, version de firmware, panne ouverte. Un flow ou un gestionnaire Apex tranche ensuite : requete, ordre de travail, ou rien.

Cette derniere option compte le plus. C'est la regle de triage, pas l'ingestion, qui garde un parc connecte reparable. Pour ASSA ABLOY, chez FocusCura et Phoniro, nous exploitons 11 000 appareils connectes produisant jusqu'a 2,5 millions d'evenements par semaine et avons ramene les requetes hebdomadaires de 3 000 a 350, soit 93% de moins, sur trois marches et sans renfort au support. Les appareils ne se sont pas tus. Le modele a cesse de creer une requete par symptome.

Qu'apporte reellement un enregistrement d'actif unique ?

• Le service voit la couverture avant l'envoi, donc personne ne facture un deplacement sur une unite sous garantie.
• Les demandes de garantie se resolvent contre le terme attache a cette unite, pas contre une police dont quelqu'un se souvient.
• Les renouvellements se prevoient a partir de dates d'installation et de fin de garantie deja presentes, si bien que les expirations ne sont plus decouvertes par le client.
• Les equipes produit obtiennent des taux de panne par modele et par version de firmware, parce que chaque requete designe une unite reelle.

Rien de tout cela n'exige une couche d'IA pour valoir le detour. En revanche cela la rend possible ensuite, car un agent ne peut raisonner que sur un parc installe reellement modelise.

Dans quel ordre construire ?

1. Chargez le parc installe avec de vrais numeros de serie et dates d'installation, meme partiellement. Un actif sans numero de serie ne se reconcilie pas plus tard.
2. Modelisez la hierarchie avant toute automatisation, car reprendre ce point touche chaque enregistrement en aval.
3. Attachez les termes de garantie et les entitlements, et designez l'objet unique qui detient la couverture.
4. Cablez la telemetrie en transitions d'etat, avec une regle de triage ecrite par condition.
5. Ajoutez seulement ensuite ordres de travail, contrats de service, prevision des renouvellements et agents.

Les equipes qui inversent les etapes une et quatre se retrouvent avec une integration superbe qui ecrit des evenements sur des actifs auxquels personne ne se fie. Pour faire relire tout cela sur votre propre org, Tekunda mene des projets de cycle de vie des actifs sur Salesforce, aux cotes de Field Service et de la livraison d'appareils connectes.

FAQ

Chaque appareil doit-il etre un Asset ou un objet personnalise ?

Un Asset, dans presque tous les cas. Entitlements, garanties, ordres de travail et Field Service lui sont deja relies, alors qu'un objet personnalise oblige a refaire ces relations a la main.

Ou doit vivre la telemetrie brute ?

Hors de l'org transactionnelle, dans un stockage concu pour les series temporelles. Salesforce garde l'etat courant, les evenements qui l'ont change et les decisions prises, pas chaque releve.

Quelle difference entre garantie et entitlement ?

Un terme de garantie decrit ce qui est couvert sur une unite : pieces, main-d'oeuvre, frais. Un entitlement ou contrat de service decrit ce que le client a achete, niveaux de support et dates compris. La plupart des organisations ont besoin des deux.

Peut-on faire cela sans Field Service ?

Oui. La modelisation des actifs, garanties et entitlements fonctionne dans Service Cloud seul. Field Service devient necessaire des que vous envoyez des techniciens, gerez des pieces et planifiez des visites de maintenance.