Discussion :

[blackpea]

Bonjour,

Mon nouveau directeur commercial souhaite mettre en place un outil de CRM.
Même s'il est vrai que notre outil actuel a ses inconvénients, je souhaite auparavant rencontré d'autres sociétés de taille équivalente afin de partager avec eux cette expérience.

[Existant]
Ma société est basée est région Lyonnaise, et nous sommes entre 10 et 20 employés dans la technologie numérique.
Le CRM existant était basé sur un développement interne pour une base d'environ 350 clients actifs et plus de 800 prospects au cours de la dernière année.

[Attendu]
J'aimerais partagé l'expérience d'une autre société qui a mis en place un CRM:
- délai du projet
- principales contraintes rencontrées
- contentement du produit livré
Aujourd'hui, mon directeur pense que cet outil va structure son service.
Mais je souhaiterais avant ça pouvoir partager avec lui une vrai vision d'expérience d'installation équivalente d'un point de vue utilisateur. Ma volonté est de ne pas me contenter de la vision intégrateur qui me dira forcément pouvoir répondre à mon besoin.

N'hésitez pas à me contacter si vous pouvez m'apporter des éléments.

Blackpea

[StringBuilder]

Bonjour,

Mon entreprise est intégratrice de la solution Update.CRM (ex Update, racheté dernièrement par Aurea).
http://www.update.com/fr

Nous avons mis en place cette solution pour plusieurs clients de votre taille, avec une offre d'hébergement dans notre SaaS.

Selon vos besoins, la mise en place (cadrage/analyse/paramétrage/reprise des données) peut se faire en quelques semaines ou quelques mois.
Nous avons une référence qui a souhaité rester 100% standard, l'installation s'est faite en quelques jours (avec création d'une interface avec leur site web).

L'application propose en natif :
- Une version WEB
- Une version Offline
- Une version iPad

Elle est hautement paramétrable (création de nouvelles tables/écrans) et de nouveaux flux, règles de gestion.
Elle couvre la partie gestion client, synchro des mails, contacts et rendez-vous avec la plupart des outils de messagerie (Exchange, Notes, GMail et serveurs IMAP/ICAL), saisie de commande, relevés linéaires dans les surfaces de vente, gestion des tournées, géolocalisation, suivi des objectifs marketing, gestion des stocks de type "coffre", etc.

N'hésitez pas à me contacter pour plus d'information.

PS : On est de Lyon aussi

[blackpea]

Bonjour,

Votre retour ne répond pas à ma question puisque je souhaite un retour de la part des clients finaux et non pas de la part d'un intégrateur.
Du coup, je ne suis pas sûr de vous consulter lorsque nous lancerons l'appel d'offres... Sauf si vous êtes capable de me présenter des références équivalentes que je pourrais consulter.

Blackpea

[DotNetMatt]

Mon nouveau directeur commercial souhaite mettre en place un outil de CRM. [...] Aujourd'hui, mon directeur pense que cet outil va structure son service.

Il a raison, un outil CRM apportera de la plus-value. Je ne connais pas ton outil maison actuel, mais vu que tu mentionnes des faiblesses, j'ai peu de doutes quant à l'intérêt d'un CRM.

Peux-tu préciser si tu envisages un projet en interne ou externe ? Car ce ne sera pas la même histoire


Dans ma startup actuelle, on a environ 25 employés éparpillés dans plusieurs bureaux en Europe. Une dizaine d'entre eux utilisent le CRM. Nous avons récemment mis en place Dynamics CRM Online en interne (avec nos développeurs).

- délai du projet

Le projet a commencé début Juin 2015 et s'est terminé au début du mois de Décembre 2015 pour la phase 1, qui concernait juste la partie "Sales". On avait 3 développeurs dessus + 2 personnes du métier + moi pour le pilotage transverse (j'ai aussi participé à quelques développements).

- principales contraintes rencontrées

--- Processus existants : il y a 2 options, soit on garde les processus existants tels quels et on adapte l'outil ; soit on adapte tout ou partie des processus à l'outil. Nous avons choisi l'option 2, car l'outil est concu par rapport aux standards établis. Donc il faisait plus sens pour nous d'adapter une grande majorité de nos processus pour qu'ils deviennent aussi standards que possible, et de personnaliser l'outil là où on avait besoin de choses particulières. Cela a donc eu l'avantage de nous permettre de rationaliser nos processus liés au CRM, mais aussi des processus qui y sont liés. Notre reporting s'est également amélioré, plus complet et avec peu voire plus d'erreurs.

--- Formation des utilisateurs : on l'avait sous estimée. La prise en main d'un nouvel outil et de nouveaux processus n'est pas chose aisée pour tout le monde. Nous avons donc dû étendre et renforcer la période de formation.

--- Résistance au changement : tous les utilisateurs n'ont pas vu d'un bon oeil le nouvel outil et les nouveaux process. La formation a donc joué un grand rôle pour pouvoir expliquer le pourquoi du comment et quels seraient les gains obtenus.

--- Qualité des données : pendant les migrations des données on s'est rendu compte que la qualité n'était pas toujours au rendez-vous. Il a donc fallu gérer de la déduplication, des suppression d'orphelins, de la consolidation, etc. avec les utilisateurs métiers et ce n'était pas totalement prévu au départ.

- contentement du produit livré

Globalement tout le monde est aujourd'hui satisfait de cette migration. Il n'y a pas eu de grosse surprise à la livraison notamment car le projet a été suivi de très près avec de nombreuses phases de test intermédiaires.

[StringBuilder]

Bonjour,

Votre retour ne répond pas à ma question puisque je souhaite un retour de la part des clients finaux et non pas de la part d'un intégrateur.
Du coup, je ne suis pas sûr de vous consulter lorsque nous lancerons l'appel d'offres... Sauf si vous êtes capable de me présenter des références équivalentes que je pourrais consulter.

Blackpea

Comme je vous ai dis, je vous invite à me contacter par MP afin d'échanger ce genre d'informations.
Nos clients n'ont pas forcément envie d'avoir leur noms exposés sur un forum.

[blackpea]

Merci DotNetMatt.
Ce retour répond particulièrement aux types d'interrogations que je peux avoir. Cela m'a permis d'affiner mon expression de besoin fonctionnel.

Concernant ta question concernant le développement interne ou l'utilisation d'un outil externe, les 2 solutions sont encore possibles.
Soit on fait évoluer la solution existante, soit on prend un nouvel outil. La décision reviendra à mon président sur la base des éléments que les différentes parties pourront lui apporter (La direction commerciale prône un outil externe, la direction technique la solution interne).

Aujourd'hui, je ne pense pas avoir ta capacité de développement en interne sans que le projet dure trop dans le temps, ce qui risque de peser fortement la balance en faveur de la mise en place de la solution avec un intégrateur.

DUREE DU PROJET
J'avais plus une durée de projet sur 10 mois, comprenant
- l'envoi de l'expression de besoin à des intégrateurs (dont en interne côté service developpement)
- le shortlistage
- le choix du partenaire
- l'installation
- la mise en place des spécificités métiers
- la formation des utilisateurs

QUALITÉ DE DONNÉES SOURCES
J'avais déjà identifié un risque de notre côté sur la qualité des données. Je pense que la problématique va être la même chez nous et je pensais donc recommander d'affecter les ressources internes sur ce point.

RÉSISTANCE AU CHANGEMENT
J'ai identifié ce point mais avait prévu une forte dose de formation (sur le Front Office mais aussi sur la Back Office) et de documentation avec le partenaire pour essayer de faire passer la pilule.

PROCESSUS EXISTANT
Ma direction a les même cas de conscience que toi sur les processus. La direction commerciale souhaiterait mettre en place l'outil et construire les processus autour et la direction technique veut qu'on rédige les processus puis qu'on adapte les outils en conséquence.
Dans le cas de mon expérience, j'ai déjà effectué les 2 cas. Les 2 peuvent répondre aux attentes.

Si vous avez d'autres témoignages orientés utilisateurs, je suis preneur.
Merci à vous

Blackpea

[StringBuilder]

Concervez un point en tête tout au long de votre analyse avant de retenir projet interne ou outils externe :

Identifier formellement tout ce qui chez vous n'est pas "standard" par rapport aux outils présentés.
Le moindre écart, aussi annodin soit-il, peut s'avérer un point de blocage complet lors de la mise en place de l'outil externe (aussi paramétrable soit-il, chaque produit a ses limites, et les éditeurs ne sont pas prêt à faire évoluer leur produit pour un unique client, surtout quand ce dernier ne réprésente que quelques dizaines de licences).

Si vous constatez de gros écarts, ou en nombre important, alors la solution en interne (quitte à devoir vous faire assister par une SSII pour avoir de la chaire à coder) est à privilégier.
Sinon, vous économiserez beaucoup de temps avec une solution externe.

Quant à la résistance au changement, pensez à privilégier le look & fell de l'application. Si d'aspect elle ne donne pas envie, même les plus ouverts au changement vont vite se braquer.

[DotNetMatt]

DUREE DU PROJET
J'avais plus une durée de projet sur 10 mois, comprenant
- l'envoi de l'expression de besoin à des intégrateurs (dont en interne côté service developpement)
- le shortlistage
- le choix du partenaire
- l'installation
- la mise en place des spécificités métiers
- la formation des utilisateurs

Je pense que c'est jouable sur 10 mois. Tu peux démarrer la formation très tôt, même avant d'avoir eu le premier prototype en main pour faire des screenshots. Au début on peut avoir des modules très génériques auxquels tout le monde participe, comme par exemple pourquoi passer sur un CRM, quels en seront les bénéfices, quels sont les objectifs/périodes/efforts requis ... pour ce projet. Ensuite plus tu vas avancer dans le temps, plus tu pourras te consacrer à des formations spécifiques avec peu voire 1 seul utilisateur à la fois selon la capacité.

QUALITÉ DE DONNÉES SOURCES
J'avais déjà identifié un risque de notre côté sur la qualité des données. Je pense que la problématique va être la même chez nous et je pensais donc recommander d'affecter les ressources internes sur ce point.

Avant de monter cette startup et de passer CTO, j'ai pu travailler en tant que développeur dans de grandes entreprises Francaises (banques, conseil...) et entre autre sur des projets CRM. Au départ tout le monde pense que les données sont nickels, mais ca déchante vite. Je pense qu'il faut des ressources internes côté métier mais aussi côté technique pour pouvoir trouver des solutions adaptées. Le côté métier seul n'arrivera probablement pas à s'en sortir. Il faut que le côté technique se renseigne sur le nouveau produit pour être efficace sur ce point. Il faut aussi penser à l'import des données assez tôt pour avoir le temps de préparer les données une fois nettoyées.

Ce qu'il faut aussi prendre en compte, ce sont les impacts sur le SI. Par exemple si tu as un data warehouse (entrepôt de données) alimenté par un ETL, il faudra peut-être s'attendre à ce que les données issues du nouveau CRM posent certains problèmes de compatibilité, donc prévoir les impacts pour les process ETL, reporting, autres applis, etc.

Je pense à ca car sur un précédent projet nous avions migré d'Oracle vers Dynamics. Sur Oracle les ID des enregistrements étaient sous forme numérique (1, 2, 3...). Mais sous Dynamics, les ID utilisés sont des GUID (5ffbfd10-e524-4b47-93ac-7aabe0c56115). Si cela se produit, il faudra faire bien attention à ne pas se retrouver dans une situation où l'on n'est plus capable de relier un nouvel enregistrement avec un ancien, car en cas de problème sur les données il sera très compliqué et pénible de retrouver ses petits. Résultat pour ce projet, le reporting était indisponible durant 1 mois, et notamment car l'ETL ne fonctionnait plus... Ce genre d'impact peut se prévoir avec une bonne analyse.

Il faut aussi penser à des plans B et C, au cas où.

RÉSISTANCE AU CHANGEMENT
J'ai identifié ce point mais avait prévu une forte dose de formation (sur le Front Office mais aussi sur la Back Office) et de documentation avec le partenaire pour essayer de faire passer la pilule.

Là il n'y a pas de recette miracle, c'est à toi de "sentir" tes utilisateurs pour le coup. Comme le conseille StringBuilder, le look & feel du nouvel outil est aussi un important facteur. La documentation du partenaire, ca peut servir mais selon ton audience, des guides maisons sont plutôt recommandés, car il faut que tes utilisateurs aient de la doc adaptée à ce qu'ils ont à faire, et qui tiennent compte des process surtout s'ils ne sont pas standards. Si tu te standardises à 100% alors la doc du partenaire sera sûrement suffisante.

Mais bon voilà, à toi de voir en fonction de ton contexte.

PROCESSUS EXISTANT
Ma direction a les même cas de conscience que toi sur les processus. La direction commerciale souhaiterait mettre en place l'outil et construire les processus autour et la direction technique veut qu'on rédige les processus puis qu'on adapte les outils en conséquence.
Dans le cas de mon expérience, j'ai déjà effectué les 2 cas. Les 2 peuvent répondre aux attentes.

Je pense que la Direction Commerciale a raison. Quand on fait appel à des solutions externes, elles sont souvent construites en fonction des standards d'une industrie ou d'un domaine particulier. Ces standards n'ont pas été inventés pour rien, et donc plus on arrive à s'en rapprocher, mieux c'est. Il faut aussi penser aux mises à jour du produit dans le futur.

Par exemple, si tu personnalises le nouvel outil à hauteur de 75% - ce qui est énorme - et que l'éditeur sort une mise à jour dans quelques mois, il y a de très fortes chances pour qu'une bonne partie des personnalisations doivent être revues. Donc soit tu vas te retrouver avec un outil pas à jour (bugs non fixés, failles de sécurité, etc.), soit tu vas devoir repartir en mode projet pour adapter les paramétrages/développements à la nouvelle version... Et ce, pour chaque nouvelle mise à jour.

En général sur les ERP il est recommandé d'éviter de personnaliser plus de 20% de l'outil. C'est juste une recommandation, mais je pense personnellement qu'elle n'est pas à prendre à la légère. Bien souvent, il suffit de changer peu de choses dans un process pour qu'il puisse être géré par l'outil. Et si en plus ta direction commerciale est ouverte sur le sujet, il faut en profiter

[blackpea]

Au départ tout le monde pense que les données sont nickels, mais ca déchante vite.

Je sais déjà que les données ne sont pas nickels car j'ai effectué un projet KPI auparavant avec les différents services. J'ai eu la confirmation que des données ne sont pas à jour, voir pas saisie.

Je pense qu'il faut des ressources internes côté métier mais aussi côté technique pour pouvoir trouver des solutions adaptées. Le côté métier seul n'arrivera probablement pas à s'en sortir. Il faut que le côté technique se renseigne sur le nouveau produit pour être efficace sur ce point. Il faut aussi penser à l'import des données assez tôt pour avoir le temps de préparer les données une fois nettoyées.

On est d'accord.

Ce qu'il faut aussi prendre en compte, ce sont les impacts sur le SI. Par exemple si tu as un data warehouse (entrepôt de données) alimenté par un ETL, il faudra peut-être s'attendre à ce que les données issues du nouveau CRM posent certains problèmes de compatibilité, donc prévoir les impacts pour les process ETL, reporting, autres applis, etc.

Je n'avais pas pris en compte ce risque. Je note donc d'être vigilant sur ce point dans le cadre du cahier des charges.

Là il n'y a pas de recette miracle, c'est à toi de "sentir" tes utilisateurs pour le coup. Comme le conseille StringBuilder, le look & feel du nouvel outil est aussi un important facteur. La documentation du partenaire, ca peut servir mais selon ton audience, des guides maisons sont plutôt recommandés, car il faut que tes utilisateurs aient de la doc adaptée à ce qu'ils ont à faire, et qui tiennent compte des process surtout s'ils ne sont pas standards. Si tu te standardises à 100% alors la doc du partenaire sera sûrement suffisante.

Je prévois une phase d'adaptation sur 1 mois avec mise à jour de la documentation par le partenaire (interne ou externe) en fonction des remontés utilisateurs une fois par semaine. Mais je suis d'accord sur le fait que le ressenti sur l'outil est important. Il pourrait être intéressant de bien communiquer sur son arrivé et dès que possible, mettre à disposition une maquette pour les usagers puisse s'initier à l'outil et surtout, remonter les défauts d'ergonomie constaté. Mais notre outil actuel était simplissime (trop), certains utilisateurs se braqueront quoi qu'il arrive. Je suis préparé à ça.

Par exemple, si tu personnalises le nouvel outil à hauteur de 75% - ce qui est énorme - et que l'éditeur sort une mise à jour dans quelques mois, il y a de très fortes chances pour qu'une bonne partie des personnalisations doivent être revues. Donc soit tu vas te retrouver avec un outil pas à jour (bugs non fixés, failles de sécurité, etc.), soit tu vas devoir repartir en mode projet pour adapter les paramétrages/développements à la nouvelle version... Et ce, pour chaque nouvelle mise à jour.
En général sur les ERP il est recommandé d'éviter de personnaliser plus de 20% de l'outil. C'est juste une recommandation, mais je pense personnellement qu'elle n'est pas à prendre à la légère. Bien souvent, il suffit de changer peu de choses dans un process pour qu'il puisse être géré par l'outil. Et si en plus ta direction commerciale est ouverte sur le sujet, il faut en profiter

Je rajoute ce point dans l'étude de risque.

[StringBuilder]

Attention sur le point "remonter les défauts d'ergonomie".

Pour le vivre au quotidien, c'est un élément qui semble "évident" pour un client, mais dans le monte de la distribution/intégration, c'est loin d'être aussi simple.

Quand on a un outil spécifique "sur mesure", on peut demander toutes les modifications qu'on veut d'un point de vue ergonomie, et 2 heures après, c'est fait.

Quand on passe par un produit éditeur, potentiellement adressé à des dizaines de milliers d'utilisateurs à travers des milliers de clients, c'est bien moins simple.
Car ce que vous trouvez ergonomique ne le sera pas forcément pour votre voisin, et vice-versa.

"L'aspect" d'un produit éditeur est généralement le premier élément de frustration du client, avant même d'arriver aux problèmes des limites au niveau du paramétrage.

Attention donc à ne pas faire une liste au Père Noël au moment du choix de l'outil : 90% des défauts visuels que vous aurez noté en démo/analyse seront des défaut pour lesquels l'intégrateur ne pourra rien faire, et pour lesquels l'éditeur restera à coup sûr totalement sourd.

C'est du vécu au quotidien, sur plusieurs produits.
=> Oui, on peut customiser/paramétrer, parfois même développer. Mais non, on ne peut pas tout faire, et on bute souvent sur des détails très frustrants.

[blackpea]

Attention sur le point "remonter les défauts d'ergonomie".
Quand on a un outil spécifique "sur mesure", on peut demander toutes les modifications qu'on veut d'un point de vue ergonomie, et 2 heures après, c'est fait.

Je souhaiterais justement limité si possible cette fonctionnalité. Aujourd'hui la plupart des outils sont développer en interne et les équipes de développement passent trop de temps à customiser ceux-ci pour les utilisateurs au dépend de projets plus structurant.