CRM, ERP ou DMS pour concessionnaire TP : où vit l’action commerciale ?

CRM, ERP ou DMS pour un concessionnaire de matériel TP : la mauvaise question consiste à chercher un logiciel unique qui déciderait de tout. Une machine devient disponible dans le système métier, un ancien devis se trouve dans le CRM et l’atelier détient la dernière information technique. Pourtant, aucune action n’arrive au commercial, ou trois alertes concurrentes lui demandent de traiter le même compte.

La décision utile est plus simple : désigner le système qui fait foi pour chaque donnée, puis choisir un seul endroit où le commercial accepte, exécute et clôt l’action. L’ERP ou le DMS conserve généralement la vérité opérationnelle. Le CRM porte la relation et le pipeline. Une couche d’intelligence commerciale peut rapprocher les événements et préparer une suggestion expliquée. Le commercial reste propriétaire de la qualification et de la prochaine étape.

Les étiquettes ERP, DMS et CRM ne suffisent pas

Les périmètres réels se chevauchent. Un éditeur métier peut appeler ERP ou DMS une suite couvrant le stock, l’atelier, les achats, les ventes et la facturation, puis lui associer un module CRM. IRIUM présente par exemple son ERP concessionnaire comme l’outil qui suit réparations, locations, livraisons et stock, tandis que son CRM couvre notamment le portefeuille commercial, les offres, l’agenda, les projets et les campagnes. Sources consultées : ERP concessionnaire IRIUM et CRM concessionnaire IRIUM.

Il serait donc fragile d’écrire « l’ERP fait toujours ceci » ou « le CRM ne sait jamais cela ». Classez plutôt vos outils selon deux critères : la donnée dont ils sont la référence et la décision que les utilisateurs y prennent réellement. Une fonction présente dans une brochure n’est pas nécessairement la source fiable de votre organisation.

Attribuez un propriétaire à chaque type de donnée

ERP ou DMS : la vérité opérationnelle

Le système métier est le meilleur candidat pour les faits qui engagent l’exploitation ou la comptabilité : identifiant machine, statut physique, coût, préparation, ordre de réparation, disponibilité à la location, commande, livraison et facture. Il doit répondre à la question « que peut-on réellement vendre ou livrer, et sous quelles contraintes ? ».

Une extraction commerciale ne doit pas réécrire ces faits avec une copie plus ancienne. Si la disponibilité, le coût ou le statut atelier sont contestés, la correction revient au propriétaire du système métier.

CRM : la vérité de la relation et du pipeline

Le CRM est le candidat naturel pour les comptes, contacts, propriétaires commerciaux, interactions, opportunités, prochaines actions et motifs de perte. Microsoft recommande de créer une opportunité lorsqu’un prospect est presque prêt à acheter, puis d’y suivre les produits, le revenu estimé, la date de clôture et les étapes de vente. Source : Microsoft Learn, mise à jour du 13 août 2026.

Cette frontière est importante. Une correspondance entre une machine et un ancien client ne mérite pas encore une opportunité. Avant qu’un besoin soit confirmé, elle reste une suggestion à examiner. Sinon, le prévisionnel mélange ventes probables, hypothèses de compatibilité et simples tâches de recherche.

Intelligence commerciale : une décision préparée, pas une nouvelle vérité

Une couche d’intelligence commerciale peut lire un événement du système métier, chercher l’historique pertinent et proposer une prochaine action. Elle ne doit pas devenir une quatrième copie autonome du stock ou du client. Son rôle est de rendre le rapprochement explicable : événement observé, données utilisées, critères satisfaits, inconnues, doublons possibles et propriétaire suggéré.

La sortie n’est pas nécessairement une opportunité. Elle peut être une demande de correction, une revue produit, une tâche de qualification ou une proposition de contact. Le statut dépend du niveau de preuve.

Faites circuler une décision, pas toutes les données

Copier l’intégralité de chaque base dans chaque outil multiplie les conflits. Pour un événement commercial, définissez plutôt un contrat d’échange minimal.

• Identifiants : machine, compte, établissement, commercial et document d’origine.

• Événement : type, date, source et ancienne puis nouvelle valeur lorsque le changement compte.

• Preuve produit : famille de machine, configuration bloquante, statut de préparation et fenêtre de disponibilité.

• Preuve client : achat, devis, demande ou interaction qui explique pourquoi le compte est considéré.

• Décision : vérifier, soumettre, accepter, rejeter ou convertir en opportunité.

• Responsabilité : propriétaire de la prochaine action, échéance et motif d’escalade.

Chaque valeur conserve sa source et sa date. Si le CRM indique « disponible » mais que le DMS indique « préparation en cours », le système métier doit primer pour la promesse de livraison. Si le DMS possède une ancienne adresse client mais que le CRM contient un établissement validé récemment, il faut résoudre l’identité au lieu de choisir automatiquement la dernière synchronisation.

Utilisez six états entre l’événement et l’opportunité

Un circuit court permet d’éviter les créations prématurées dans le pipeline.

• 1. Événement reçu : un fait daté change dans le système source.

• 2. Données contrôlées : les identifiants et champs bloquants sont présents.

• 3. Suggestion préparée : le rapprochement avec le compte et l’historique est expliqué.

• 4. Suggestion soumise : le bon propriétaire commercial peut l’accepter ou la rejeter.

• 5. Besoin qualifié : compatibilité, timing et intention ont été vérifiés séparément.

• 6. Opportunité créée : le client accepte une prochaine étape commerciale datée.

Le passage entre les états doit avoir des conditions visibles. Une suggestion ne passe pas à « soumise » si la machine n’est pas commercialement disponible, si le compte reste ambigu ou si une affaire équivalente est déjà ouverte. Elle ne devient pas une opportunité parce qu’un score dépasse un seuil interne.

Trois portes avant d’ouvrir le pipeline

Compatibilité

La machine ou la solution envisagée répond-elle aux contraintes connues ? Vérifiez au minimum la famille, le gabarit, les accessoires indispensables, l’état de préparation et les conditions de livraison. Un ancien achat de la même marque ne suffit pas.

Timing

Un événement rend-il la discussion pertinente maintenant ? L’entrée physique d’une machine n’est pas toujours sa date de disponibilité commerciale. Un devis ancien peut concerner un chantier terminé. La date de l’événement, la fenêtre du besoin et la date de dernière vérification doivent rester séparées.

Intention

Le client a-t-il confirmé qu’il souhaite examiner une solution ? Une demande de prix, une demande de délai, une comparaison de reprise ou une prochaine réunion constituent des preuves plus fortes qu’une simple similitude historique. Tant que l’intention manque, conservez une tâche de qualification hors prévisionnel.

Cette règle complète l’article sur le rôle du CRM dans l’activation du stock. Le CRM organise l’exécution, mais la qualité de l’action dépend de données qui vivent souvent ailleurs.

Exemple fictif : une machine prête, un devis ancien et deux systèmes

Exemple entièrement fictif. Une pelle compacte passe de « préparation atelier » à « disponible à la vente » dans le DMS. Le CRM contient un devis perdu six mois plus tôt pour une machine de même catégorie, avec le motif « délai incompatible ». Le compte possède déjà un commercial attitré et aucune opportunité équivalente n’est ouverte.

Le changement de statut déclenche une suggestion, pas une opportunité. Le système métier fournit l’identifiant, la configuration et la date de disponibilité. Le CRM fournit le devis, le contact, le motif de perte et le propriétaire du compte. La suggestion explique que le blocage de disponibilité pourrait avoir changé, mais signale que la date du chantier et deux accessoires restent à confirmer.

Le responsable occasions vérifie la compatibilité. Le commercial décide ensuite si le timing mérite un appel. Si le client confirme un besoin et accepte une prochaine étape, une nouvelle opportunité est créée dans le CRM et reliée au devis initial. Le devis perdu n’est pas rouvert avec son ancien prix. Si le projet est terminé, la suggestion est rejetée avec ce motif afin qu’elle ne réapparaisse pas au prochain import.

Répartissez les responsabilités avant d’automatiser

• Responsable ERP ou DMS : garantit les statuts opérationnels, les identifiants machines et la qualité des événements sources.

• Sales Ops ou référent CRM : garantit l’identité des comptes, les propriétaires, les doublons et les règles du pipeline.

• Responsable occasions ou produit : arbitre la compatibilité, la disponibilité commerciale et les exceptions de marge.

• Commercial propriétaire : accepte ou rejette la suggestion, confirme l’intention et conduit l’action.

• Directeur commercial : décide quelles suggestions méritent du temps et arbitre les conflits de compte ou de territoire.

L’autonomie doit s’arrêter dès qu’une donnée bloquante manque, que deux comptes sont possibles, qu’une affaire active existe ou que la marge minimale exige un arbitrage. Le handoff contient alors le conflit et les preuves, pas seulement une alerte générique.

Mesurez le passage entre les systèmes

Le nombre de synchronisations réussies ne dit pas si l’équipe reçoit de meilleures décisions. Utilisez des indicateurs avec leurs dénominateurs :

• Taux de données exploitables = événements avec machine, compte et date vérifiables / événements reçus.

• Taux d’acceptation = suggestions acceptées par les commerciaux / suggestions soumises.

• Taux de besoin confirmé = comptes confirmant un besoin / comptes effectivement joints après acceptation.

• Délai événement vers décision = date d’acceptation ou de rejet moins date de disponibilité de l’événement.

Analysez aussi les rejets : incompatibilité, timing dépassé, intention absente, donnée incorrecte, doublon ou affaire déjà ouverte. Ces motifs indiquent quel système, quelle règle ou quel handoff doit être amélioré. Ils ne doivent pas être masqués dans un score moyen.

Commencez sans refondre le système d’information

Un test manuel peut partir de deux exports et d’une revue hebdomadaire. Choisissez un événement précis, par exemple le passage d’une machine à « disponible commercialement ». Définissez les champs nécessaires, examinez les suggestions avec les commerciaux et conservez leurs motifs d’acceptation ou de rejet.

La limite apparaît quand les exports n’utilisent pas les mêmes identifiants, que les statuts changent entre deux extractions ou que les décisions restent dans des e-mails. Le tableau ne sait plus quelle valeur fait foi, ni si une suggestion a déjà été traitée. C’est un problème de continuité de décision, pas seulement de transfert de données.

Relier les systèmes sans remplacer leur rôle

Ironwise est conçu pour rapprocher les données de stock, l’historique clients et des signaux utiles afin de préparer des opportunités commerciales expliquées. L’objectif n’est pas de remplacer l’ERP, le DMS ou le CRM. Il consiste à réduire la rupture entre un événement opérationnel et une action que le bon commercial peut comprendre, accepter et exécuter.

Pour évaluer ce besoin, prenez un événement, dix machines et les comptes associés. Notez où vivent la donnée source, la preuve client, la décision et le résultat. Si aucune équipe ne peut reconstituer le circuit sans exporter plusieurs fichiers, vous disposez d’un cas concret à discuter avec Ironwise et à présenter lors d’une démonstration, si elle est disponible.