Étude de cas
Dix fiches pour un hôpital, et la table intermédiaire qui a tout résolu
Les fiches clients d’AliMed se multipliaient. Un hôpital pouvait exister dix fois dans Microsoft Dynamics AX, tandis que tout son groupe comptait pour un seul client, si bien que personne ne savait quel site commandait vraiment. Rapidi a relié AX à Salesforce par une table de correspondance qui a fait tomber les doublons sans toucher à l’ERP.
AliMed conçoit et distribue du matériel de santé, surtout connu pour ses cales de positionnement sur mesure, qui maintiennent aussi bien un membre isolé qu’un patient entier. Après l’échec d’une première tentative d’intégration, la fonction de mirroring de Rapidi a poussé dans Salesforce une liste commerciale de tous les établissements de santé américains, alors même que la source n’avait aucun horodatage, et une table SQL sur mesure a relié plusieurs comptes AX à une seule fiche Salesforce. Le regroupement par code postal de livraison a transformé un bloc corporate en comptes par établissement.
Parler à un expert en intégration
L’entreprise
AliMed conçoit et fournit du matériel de santé depuis 1970, quand Julian et Barbara Cherubini ont commencé à vendre depuis leur domicile de Boston, non loin du siège actuel à Dedham, dans le Massachusetts. Les premiers produits maison, semelles et attelles, sont sortis en 1974.
Un modèle de vente par correspondance a fait le reste. Les catalogues sont devenus assez épais pour faire partie du décor dans les hôpitaux, les établissements de long séjour, les centres chirurgicaux, les blocs opératoires et les soins à domicile. Le catalogue est en ligne aujourd’hui, et continue de grossir, comme la base de clients.
L’entreprise est surtout connue pour ses cales de positionnement fabriquées sur mesure, qui contrôlent la position de tout, d’une partie du corps au patient entier, et dont beaucoup se commandent en dimensions spécifiques. Plus d’informations sur l’entreprise sur alimed.com.
Des fiches qui se multipliaient
Pour mieux soutenir l’équipe commerciale que ne le faisait Microsoft Dynamics AX seul, AliMed avait acheté Microsoft CRM 2013 et confié à un tiers la construction d’une intégration maison avec AX. Jimmy Mathew a été recruté pour faire monter le CRM de version et traiter les problèmes d’intégrité des données qui allaient avec.
Le plus gros de ces problèmes était la duplication. Un client existant visitait le site et créait un nouveau compte, qui atterrissait dans AX au lieu d’être rattaché au compte déjà présent. Ou bien il téléphonait, le service client ne trouvait pas sa fiche, et une nouvelle était créée sur-le-champ.
Nous avions un problème de qualité des données dans notre système, et nous n’avions pas les outils pour le résoudre.
L’intégration d’origine aggravait la situation. « Le CRM Microsoft se contentait de tirer les fiches d’AX, si bien que nous nous retrouvions avec tous les doublons là aussi », dit Mathew. « Mon objectif en arrivant était d’avoir à la fois un CRM et une intégration qui répondent mieux à nos besoins. Tout était sur la table. » Il a trouvé dans Salesforce la meilleure réponse pour gérer les données clients, et AliMed a changé. Le problème d’intégration, lui, est resté exactement où il était.
La tentative qui a échoué
Cette partie mérite d’être racontée honnêtement, car elle explique pourquoi les exigences finales étaient si précises.
L’équipe de Mathew a d’abord évalué Jitterbit. L’outil ne tenait pas compte des particularités d’AX et n’aidait en rien sur l’intégrité des données ; il voulait synchroniser fiche par fiche, ce qui est précisément ce qui produit des doublons à l’arrivée. « Dès le début de la mise en œuvre, nous avons découvert toutes ces restrictions, et cela s’est simplement révélé infaisable, dit Mathew. Pire encore, lors de notre premier test, après sept ou huit mois de conception et de développement, il a lamentablement échoué. »
L’équipe savait alors qu’elle ne voulait pas de toutes les fiches clients d’AX dans Salesforce, trop d’entre elles étant des doublons. Le plan était plutôt d’importer « Definitive Data », une liste commerciale de tous les établissements de santé des États-Unis, et de faire correspondre les fiches AX en double à une seule fiche par lieu réel. C’était au-dessus des capacités de l’outil.
La solution
Rapidi est apparu dans les recherches de Mathew, et sa fonction de mirroring a fait ce qui bloquait tout le reste : pousser les fiches Definitive Data dans Salesforce alors que la source n’avait aucun horodatage sur lequel se caler.
Autour de cela, l’équipe a défini une table SQL intermédiaire. « Nous pouvons avoir 10 comptes dans AX, et nous pouvions les relier à une seule fiche de la table intermédiaire », explique Mathew. Rapidi a accepté la configuration sur mesure sans broncher, et l’exploitation est restée simple : « Il nous suffit de mettre à jour une fiche dans la table intermédiaire et de laisser Rapidi exécuter son travail, et la modification arrive dans Salesforce sans problème. »
La table intermédiaire a aussi résolu un héritage de l’ERP. AX traitait un groupe de santé entier comme un seul client, même une grande chaîne d’hôpitaux. Regrouper les fiches de la table intermédiaire par code postal de livraison a produit des comptes Salesforce ayant du sens au niveau de chaque établissement, avec l’historique des commandes rattaché au site plutôt qu’à la maison mère.
Cette distinction compte commercialement. La plupart des décisions d’achat se prennent sur place, et savoir quel hôpital commande quoi sépare un effort commercial ciblé d’une devinette. Avant, un rapport ne pouvait nommer que le groupe propriétaire du système de santé, quel que soit le nombre de sites qu’il contenait.
Un dernier goulot est tombé en chemin. Faire remonter l’historique des ventes dans Salesforce via une vue liste AX fonctionnait, mais « prenait une éternité ». Les consultants Rapidi ont travaillé avec l’équipe sur l’indexation des tables et trouvé une meilleure route pour pousser les données ; le chargement historique est alors devenu rapide.
Regard en arrière
Mathew dit sans détour ce qu’il conseillerait à quelqu’un qui démarre.
Au départ, nous étions focalisés sur la solution d’intégration la moins chère, n’importe quoi qui puisse relier AX à Salesforce. Mais parfois, le moins cher n’est pas le meilleur. Il faut un partenaire d’intégration qui comprenne les particularités de l’ERP, comme les horodatages d’AX. Avec Rapidi, nous échangeons enfin des données exactes.
Il apprécie aussi la partie ingrate : pouvoir signaler un problème et le voir résolu. « Nous pouvions soumettre un problème l’après-midi, et souvent, en arrivant le lendemain matin, nous avions une solution. »
Quand on lui demande ce qu’il ferait sans, il rit. « Je ne peux pas l’imaginer. Avant Rapidi, nous ne voyions pas les erreurs et ne pouvions donc pas corriger les problèmes nous-mêmes. Nous avons tellement de visibilité maintenant. Nous voyons les tâches s’exécuter, nous pouvons les piloter, et nous avons tout le détail des activités, erreurs comprises, dans les journaux. Nous ne pouvons pas revenir en arrière, seulement avancer. »
Des doublons clients que vous n’arrivez pas à nettoyer ?
Dites-nous ce que contient votre ERP et d’où viennent les doublons, et nous vous dirons si un modèle standard Rapidi vous couvre.