CRM
Un CRM pour plusieurs ERP : doublons, données écrasées, et comment relancer le projet
par Paul Mantez, Co-fondateur & Développeur
Un groupe de plusieurs sociétés, chacune avec son ERP : Sage X3 ici, Infor là, un ERP sectoriel ou maison ailleurs. La direction commerciale veut un seul CRM, pour voir tous les clients au même endroit. Le projet démarre, les synchronisations se branchent, et quelques mois plus tard les commerciaux trouvent trois fiches pour le même client, un téléphone corrigé qui revient à l'ancienne valeur, une adresse de facturation qui change toute seule. Ils arrêtent d'ouvrir le CRM. Le projet n'a pas tenu.
Dans la plupart des cas, l'outil n'y est pour rien. Ce qui manquait, c'est une règle écrite avant le premier branchement. Cet article la détaille, explique comment relancer un projet qui a déjà échoué, et ce qu'il faut savoir quand un même CRM sert plusieurs sociétés. Les faits techniques sont ceux des éditeurs, avec leur source.
Un maître par donnée
Chaque donnée a un seul outil qui la crée et qui a le droit de la modifier. Les autres la lisent. Écrit comme ça, c'est une évidence ; dans un projet, c'est la décision qu'on oublie de prendre.
| Donnée | Qui la crée | Qui a le droit de la modifier | Sens du flux |
|---|---|---|---|
| Prospect, contact commercial | Le CRM | Le CRM | Du CRM vers l'ERP, au moment où il devient client |
| Client facturé, adresse de facturation, conditions de paiement | L'ERP de la société qui facture | Cet ERP seulement | De l'ERP vers le CRM |
| Tarifs, stocks, commandes, factures | L'ERP | L'ERP | De l'ERP vers le CRM, en lecture |
| Opportunités, visites, comptes rendus | Le CRM | Le CRM | Restent dans le CRM |
Salesforce décrit ce cas dans ses schémas d'intégration : l'ERP est maître de certaines données, le CRM en est le consommateur (Salesforce Architects). Avec plusieurs ERP, la règle s'applique société par société : le client de la division A est maître dans l'ERP de la division A.
Pour savoir quelles données de l'ERP servent vraiment à vendre, catalogue, prix applicable, disponibilité, historique d'achat, voir notre article sur le CRM du négoce et de l'industrie.
La question à vous poser : aujourd'hui, quand un nouveau client arrive, dans quel outil est-il créé, et par qui ?
« Dans les deux sens », c'est « le dernier qui écrit gagne »
Le réglage le plus demandé est aussi le plus risqué. Dans le connecteur HubSpot-Salesforce, la règle de synchronisation dans les deux sens est décrite ainsi : la valeur la plus récente écrase toujours les valeurs existantes (aide HubSpot). HubSpot précise aussi que la première synchronisation peut écraser une valeur plus récente, selon la règle choisie.
Ce mécanisme n'est pas propre à HubSpot : dès que deux outils peuvent modifier le même champ, celui qui écrit en dernier gagne, qu'il ait raison ou non. Un commercial corrige un téléphone dans le CRM, l'ERP renvoie l'ancien la nuit suivante, et la correction disparaît. C'est exactement ce que les équipes décrivent comme « le CRM qui écrase nos données ».
La parade tient en une règle : chaque champ se synchronise dans un seul sens, celui de son maître. Les exceptions existent, mais elles se décident une par une et s'écrivent. Chez Ingredia, les comptes prospects sont verrouillés pendant leur envoi vers l'ERP, pour que personne ne les modifie au moment où l'autre outil les prend (le cas Ingredia).
Relancer un projet CRM qui n'a pas tenu
Un CRM abandonné laisse des traces : des doublons, des fiches écrasées, et surtout des commerciaux qui ne croient plus à l'outil. Relancer le projet en changeant seulement de logiciel reproduit les mêmes causes. L'ordre qu'on suit :
- Geler les synchronisations qui tournent encore, pour arrêter d'abîmer les données.
- Lister ce qui a cassé : un export d'un échantillon de doublons et de fiches écrasées suffit à voir d'où vient le problème.
- Choisir le maître de chaque donnée, avec le tableau ci-dessus, et le faire valider par la direction commerciale et par ceux qui administrent les ERP.
- Nettoyer avant de rebrancher : fusionner les doublons, décider ce qu'on reprend. La méthode est dans notre article sur la reprise de données CRM.
- Rebrancher un flux après l'autre, en commençant par une seule société ou une seule division.
- Faire tester les commerciaux sur leurs propres comptes avant d'ouvrir à tous. Ils voient en dix minutes ce qu'aucun contrôle automatique ne voit.
Si votre projet en est là, c'est le sujet de nos trente minutes gratuites : on regarde ce qui a cassé, et ce qu'il faudrait décider avant de relancer.
Une fiche client, un identifiant par ERP
Un même client peut acheter à deux sociétés du groupe et exister dans deux ERP, avec deux numéros différents. Dans le CRM, il ne doit avoir qu'une fiche, qui garde les deux identifiants dans deux champs distincts. Chaque flux met à jour la fiche par son identifiant, jamais par le nom de la société. Salesforce comme HubSpot gardent plusieurs identifiants externes ou propriétés à valeur unique par objet, de quoi en prévoir un par ERP (aide Salesforce, aide HubSpot).
Rapprocher par le nom, c'est fabriquer des doublons et des fusions à tort. HubSpot documente deux pièges qui pèsent dans un groupe :
- ses entreprises créées par l'API ne sont pas dédoublonnées sur le domaine, y compris celles qu'apporte une application de synchronisation installée (aide HubSpot)
- dans sa synchronisation de données, deux entreprises de même nom mais de domaines différents sont rapprochées (aide HubSpot) : deux filiales homonymes risquent de n'en faire qu'une
Chez Deffrennes, la passerelle entre Sage X3 et Salesforce met à jour chaque enregistrement par sa clé externe : on peut rejouer le même fichier dix fois, le résultat est identique (le cas Deffrennes).
Plusieurs sociétés dans un seul CRM
Mettre plusieurs sociétés dans un même CRM, c'est décider de trois choses.
La société sur chaque fiche. Le compte porte la société qui facture, son SIREN et l'identifiant du client dans l'ERP de cette société. Un client commun à deux sociétés garde une seule fiche, avec ses deux identifiants. Pour la facture électronique, c'est la société qui émet qui compte, et chaque SIREN a ses obligations (notre article sur la facturation électronique multi-entités). Chez le Groupe PEC, un seul Salesforce sert les deux entités légales du groupe, jusqu'à la passerelle de facturation électronique (le cas Groupe PEC).
Les devises. Une filiale hors zone euro demande le multi-devises. Dans Salesforce, il n'existe pas en Professional, et son activation modifie l'org de façon permanente (aide Salesforce) : c'est une décision de cadrage. Pour un fabricant présent dans huit pays, l'absence de multi-devises empêchait de créer un devis depuis une filiale hors zone euro (le cas).
Les droits. Qui voit les clients de quelle société se règle par les rôles, le partage et, dans les éditions qui les ont, les territoires. Deux faux amis à écarter : les Divisions de Salesforce ne restreignent pas l'accès aux données, n'existent que dans l'ancienne interface Classic et sont réservées aux très gros volumes (aide Salesforce) ; les Brands de HubSpot sont une option de Marketing Hub Enterprise qui sert à gérer plusieurs marques en marketing, pas à séparer des sociétés (aide HubSpot).
Un seul CRM n'est pas toujours la bonne réponse. Ingredia a deux orgs Salesforce distinctes, l'une pour l'activité commerciale, l'autre pour la coopérative et ses adhérents : deux publics, deux modèles de données qui ne se recoupent pas. Le multi-ERP, c'est l'assemblage de ces briques, et le cadrage décide lesquelles vous concernent.
Des liaisons directes, ou une base intermédiaire ?
Avec deux ERP et quelques flux, relier chaque ERP au CRM reste lisible. Quand les ERP et les flux se multiplient, chaque liaison directe ajoute ses règles, ses horaires et ses erreurs, et personne ne sait plus quelle passerelle a écrit quoi.
Salesforce décrit le cas où les données viennent de plusieurs systèmes sources : il est courant qu'un entrepôt de données les rassemble avant leur import dans le CRM (Salesforce Architects). C'est là que se rapprochent les clients des différents ERP, une fois, avant d'arriver dans le CRM. Ce n'est pas un passage obligé : c'est le nombre de flux qui décide, pas un principe.
Brancher chaque ERP avec ce qu'il sait faire
Chaque ERP a ses portes de sortie, et la bonne n'est pas toujours la plus moderne. Sage X3 propose des API, et Sage recommande GraphQL pour les nouvelles intégrations (Sage). Elles demandent un chantier côté ERP, souvent avec le prestataire Sage. Quand une mise à jour par nuit suffit à vendre, des exports planifiés font le travail, comme on l'a détaillé dans notre article sur Sage X3 et Salesforce. Pour le fabricant présent dans huit pays, cinq flux avec l'ERP Infor ont été cadrés, produits et tarifs, comptes d'achat, commandes, parc installé, clients, avec un échange par fichiers plats.
Pour les connecteurs, Sage propose un connecteur entre Sage X3 et Salesforce, activé dans le paramétrage de Sage X3 (aide Sage X3). Côté HubSpot, nous n'avons pas trouvé de connecteur Sage X3 fait par HubSpot ; il existe une application tierce sur sa place de marché.
Enfin, tous les flux tirent sur le même quota d'API du CRM : la limite journalière de Salesforce et celle de HubSpot se comptent pour le compte entier, pas par passerelle (Salesforce, HubSpot). Trois ERP qui synchronisent toutes les cinq minutes se partagent la même enveloppe.
Le choix entre HubSpot et Salesforce dépend surtout du reste : objets propres à votre activité, multi-devises, nombre de commerciaux. On l'a comparé dans HubSpot ou Salesforce pour une PME.
Ce qu'il faut apporter à nos trente minutes
Pour savoir en trente minutes ce que demande votre CRM et par où commencer, venez avec :
- la liste des sociétés du groupe et l'ERP de chacune
- qui crée un client aujourd'hui, et dans quel outil
- ce qui a cassé dans le projet précédent, s'il y en a eu un
- un export d'un échantillon de doublons ou de fiches écrasées
- pour chaque ERP, qui l'administre, et s'il a des API ou des exports planifiés
- le CRM envisagé, s'il est déjà choisi
Si le projet se confirme, le cadrage dure un à deux jours selon le périmètre. Il est facturé, puis déduit du projet si vous nous le confiez. Il produit le tableau des maîtres de chaque donnée, la liste des flux et l'ordre dans lequel les brancher.
Questions fréquentes
Faut-il un CRM par société quand un groupe a plusieurs ERP ?
Pas forcément. Un seul CRM se justifie quand les sociétés vendent aux mêmes clients ou que la direction veut une vue commune : chaque fiche porte alors sa société et l'identifiant du client dans chaque ERP. Deux CRM distincts se justifient quand les métiers, les publics et les modèles de données n'ont rien en commun. C'est une décision de cadrage, pas une question d'outil.
Peut-on synchroniser le CRM et l'ERP dans les deux sens ?
Techniquement oui, mais c'est la première cause de données écrasées. En synchronisation dans les deux sens, la valeur la plus récente remplace l'autre, quel que soit l'outil qui avait raison. On décide donc, champ par champ, qui a le droit d'écrire, et on synchronise chaque champ dans un seul sens, sauf exception décidée et documentée.
Comment éviter les doublons quand un client est dans deux ERP ?
En gardant une seule fiche client dans le CRM, avec un identifiant par ERP : l'identifiant du client dans le premier ERP, celui du second dans un autre champ. Chaque flux met à jour la fiche par son identifiant, jamais par le nom de la société. Les fiches en double déjà présentes se fusionnent avant de rebrancher les flux.
HubSpot ou Salesforce se connectent-ils à Sage X3 ?
Sage propose un connecteur entre Sage X3 et Salesforce, activé dans le paramétrage de Sage X3. Côté HubSpot, nous n'avons pas trouvé de connecteur fait par HubSpot ; il existe une application tierce. Dans les deux cas, Sage X3 a ses propres API, et une synchronisation de nuit par exports planifiés suffit souvent.
Avec plusieurs ERP, faut-il relier chacun au CRM ou passer par une base commune ?
Avec deux ERP et peu de flux, des liaisons directes restent lisibles. Quand les ERP et les flux se multiplient, une base intermédiaire qui rapproche les données avant le CRM évite de démultiplier les règles. Salesforce décrit ce schéma comme courant quand les données viennent de plusieurs systèmes. Le choix dépend du nombre de flux, pas d'un principe.
Combien coûte l'intégration d'un CRM avec plusieurs ERP ?
Pour relier des outils qui ne se parlent pas, notre ordre de grandeur est de 4 à 12 k€ pour 3 à 5 flux, et de 8 à 25 k€ au-delà, hors licences, avec 2 à 4 semaines pour deux outils. Le déploiement du CRM lui-même est une autre ligne, de 8 à 40 k€ selon l'outil. Le détail est sur notre page tarifs.
Votre CRM a déjà échoué une fois, ou vous voulez éviter que ça arrive ? C'est la question de nos trente minutes gratuites. Pour le reste du projet, voir notre intégrateur CRM à Lille et notre offre Intégration & Données.