Insights

Préparation à l'implémentation d'un logiciel SFA : guide manager

Rédigé par
Linkedin

Présentation

L'adoption par une organisation d'un système d'automatisation de la force de vente, ou d'un système similaire, également appelé gestion de la relation client (CRM), système de gestion de la distribution (DMS), etc. représente généralement un investissement et un engagement importants qui doivent être gérés avec soin. La réussite de la mise en œuvre dépend de la qualité des entrées et de la base de données qui seront ensuite exploitées pour créer des analyses puissantes et obtenir les gains de productivité souhaités.

Dans cet article, nous souhaitons mettre en évidence quelques aspects qui, selon nous, devraient être pris en compte lors de la préparation d'un tel changement. Il vient compléter les autres articles que nous avons écrits, sur les dimensions à prendre en compte lors de l'achat d'une solution d'automatisation des forces de terrain et comment garantir l'adoption de vos utilisateurs sur le terrain.

1. Mettre en place une structure de gouvernance claire

La première étape d'un déploiement réussi d'un système SFA consiste à confier à certains propriétaires clés la responsabilité de faire avancer le projet. Cela dépend de l'organisation et des compétences, mais il doit généralement être dirigé par les responsables du service informatique et de l'équipe commerciale.

Il est essentiel que les deux travaillent ensemble, car l'équipe commerciale n'a peut-être pas le temps et l'expérience nécessaires pour rédiger des spécifications techniques claires et détaillées. Il existe donc un risque d'avoir des exigences vagues conduisant à des implémentations non pertinentes. La structure devrait être chargée de valider les spécifications sous forme de témoignages d'utilisateurs. Les autres parties prenantes qui doivent être associées à l'initiative pourraient être :

  • Achats. Structurer le processus d'appel d'offres, le cas échéant
  • Juridique et financier. S'assurer que le paiement et les contrats sont conformes à ce que l'entreprise traite, en termes de devises, de gestion des données, etc.

Ce qui compte, en fin de compte, c'est qu'il y ait un alignement entre toutes les parties prenantes au moment de décider du déploiement.

2. Tenez compte de tous les personnages des utilisateurs, pour le bénéfice de toutes les personnes impliquées

Lorsque vous listez ce que vous devez obtenir du système, il est important de répertorier tous les profils d'utilisateurs qui seront concernés et qui devraient bénéficier du nouvel outil. Pour rappel, un user persona est un profil utilisateur typique, tel que le livreur, l'administrateur des ventes, etc. Selon le framework agile, un user persona a certains besoins qui sont exprimés sous forme de user stories, comme

« En tant que représentant commercial, je dois être capable de localiser les clients autour de moi ».

Une erreur courante que nous observons est d'ignorer les utilisateurs sur le terrain ou de ne pas prêter suffisamment attention à leur fonctionnement réel et de concevoir le système uniquement dans l'intérêt des utilisateurs de la direction et du bureau. Il en résulte qu'un système est considéré comme imposé du haut vers le bas. Le succès est entre les mains des principaux utilisateurs, les utilisateurs sur le terrain, et devrait les aider à gagner du temps, à ne pas perdre de données, à visiter plus de clients et, au final, à obtenir des commissions plus élevées. S'ils ne voient pas leur intérêt, il est fort probable qu'ils hésiteront à utiliser l'outil, perçu uniquement comme une perte de temps qui ne profite qu'à la direction. Les symptômes typiques de cette situation sont les suivants : les utilisateurs essaient de reprocher à l'outil la présence de bogues ou de ne pas fonctionner, et essaient de ne pas obtenir les résultats escomptés.

3. Assurez-vous que l'outil est suffisamment flexible pour s'adapter à vos processus, et non l'inverse

Lorsque vous évaluez les différents outils disponibles sur le marché, essayez de comprendre comment ils ont été conçus, leur architecture. Si vous examinez leurs contrats d'API et les concepts utilisés, vous comprendrez bien comment ils peuvent être adaptés à vos besoins. Gardez à l'esprit qu'il est fort probable qu'il y ait des changements à l'avenir et que, par conséquent, toutes les exigences ne peuvent pas être capturées dès le premier jour, avec une précision de 100 %.

En outre, vous devez vous renseigner sur la mesure dans laquelle les modifications sont effectuées en libre-service ou nécessitent l'intervention du fournisseur. Vous pourriez préférer investir du temps et des ressources dans une solution permettant de partager les connaissances et de former votre équipe à « s'approprier » l'outil pour apporter des modifications, plutôt que de dépendre du fournisseur.

4. Priorisez, pour commencer petit et itérer

Une fois que vous avez dressé la liste des besoins que vous souhaitez satisfaire avec ce nouvel outil, l'un des pièges les plus courants est de désirer tout en même temps.

Nous sommes de fervents partisans de l'approche agile, nous pensons qu'il vaut mieux commencer petit sur un périmètre limité pour commencer à récolter les bénéfices d'une première expérience concrète avec les utilisateurs, plutôt que d'attendre trop longtemps pour que tout soit parfait, puis de se rendre compte que cela ne correspond pas à vos exigences. En particulier pour une première adoption, de nombreuses inconnues seront découvertes lors du déploiement.

5. Intégrez-le à la culture

L'adoption d'un tel outil ne fonctionne que si la direction en fait une priorité, si tout le monde comprend comment l'organisation va en bénéficier à long terme, cela améliorera la relation entre les utilisateurs sur le terrain et les utilisateurs des bureaux, ainsi qu'avec les autres partenaires, etc.

La politique commerciale doit être mise à jour afin que la rémunération de l'utilisateur de l'application, comme les travailleurs de terrain, ou des agents qui l'utilisent soit liée aux performances enregistrées sur l'application. Les rapports devraient être partagés régulièrement avec toutes les parties prenantes internes et externes afin de suivre l'adoption et les performances.

6. Préparer le budget pour les mises à jour

Avec le temps, il est probable que vous vous rendiez compte que vous avez besoin de fonctionnalités supplémentaires ou de modifications de la structure hiérarchique. Ces coûts sont généralement considérés comme des demandes de modification impliquant des journées de travail et nécessitent un budget supplémentaire.

Assurez-vous qu'ils sont pris en compte dans l'analyse de rentabilisation en faveur d'une mise à niveau constante de la solution et clarifiez avec le fournisseur sa politique en matière de demandes de modification.

Conclusion

Le déploiement d'une solution d'automatisation des forces de terrain n'est pas une mince affaire. Il s'agit d'une véritable transformation numérique pour une organisation qui doit être réalisée en étroite coordination entre toutes les parties prenantes.

Gardez à l'esprit toutes les dimensions énumérées ci-dessus pour maximiser les chances de succès et obtenir les gains souhaités.

Plus d'articles

Check - Elements Webflow Library - BRIX Templates
Merci de vous être inscrit à notre newsletter
Oups ! Une erreur s'est produite lors de l'envoi du formulaire.