Méthode progressive pour un CRM
Publié le : 15/07/2009 dans Gestion de projet, Logiciel CRM Par : David Gotchac Tags :

Quelle méthode pour un projet de Relation Client ?

Les méthodologies traditionnelles ont fait long feu

Les méthodologies traditionnelles de gestion de projet s’appliquent mal aux projets Front Office en général et aux projets de CRM en particulier. Plusieurs raisons à cela :

  • Il n’existe pas de cadre réglementaire à l’activité « Client » de l’entreprise,
  • Ces projets sont transverses et font appel à des typologies d’utilisateurs variés dans :
    • Leur fréquence d’utilisation (intensive pour un télévendeur, quotidienne pour un vendeur itinérant, plus occasionnelle pour une Direction Commerciale),
    • Leurs attentes par rapport au système.
  • La nature de l’information manipulée :
    • Imprécise (un effectif est donné « à peu près », de même qu’un CA ou une prévision de vente),
    • Périssable (une donnée saisie est bien vite obsolète),
    • Invérifiable (Il n’existe pas de règle de vérification de cohérence).
  • La difficulté souvent rencontrée pour modéliser l’activité client de l’entreprise avec les utilisateurs, sans tomber dans les deux écueils que sont :
    • Une trop grande simplification de la réalité en général synonyme de faible valeur ajoutée du logiciel,
    • Une trop faible simplification de la réalité pour prendre en compte l’ensemble des « cas particuliers » et chercher à les automatiser. Cela produit en général des paramétrages connus sous le nom « d’usines à gaz » vite rejetés par les utilisateurs.

En effet, les méthodologies traditionnelles découpent le projet en 3 étapes :

  1. On travaille à produire un document de spécifications détaillées qui est validé,
  2. On réalise conformément au dossier de spécification,
  3. On valide la conformité de la réalisation et enfin, on met en œuvre les tâches de déploiement (reprise des données, formation, etc..).

Si, sur le papier, ces étapes sont tout à fait logiques, en pratique, la plupart du temps, le projet vit une phase tunnel longue et la réalisation a beau être conforme aux spécifications, le résultat ne correspond pas aux attentes réelles.

De plus il y a toujours des marges d’interprétation qui induisent un écart souvent significatif entre ce que l’utilisateur a imaginé et ce que l’intégrateur a compris.

Tous les écarts sont découverts au moment de la livraison : Trop tard !

Face à cette situation, plusieurs méthodologies alternatives ont vu le jour.

Les méthodes agiles

Les méthodologies agiles (scrum, xtrem programming, …)  partent du principe que le projet se monte en totale collaboration entre les équipes d’intégration et le groupe de projet. Il n’existe pas ou peu d’étapes de validation formelles et c’est le contact permanent des équipes qui garantit l’adéquation entre le résultat et les attentes. Ces méthodologies utilisent la méthode des « petits pas ». Pas de grandes étapes, pas de phase d’étude, on prend les sujets les uns après les autres – au risque de défaire aujourd’hui ce qui a été fait hier.

Si ces méthodologies produisent parfois de très bons résultats, elles nécessitent des délais plus longs et une implication plus forte des équipes du client. Il est à noter qu’une formation des équipes client à ces méthodes est vivement conseillée afin de s’assurer que tout le monde partage bien le même paradigme.

Enfin et surtout, le risque majeur de ces méthodes est de ne jamais pouvoir garantir un coût ou un délai puisqu’à chaque instant on redéfinit la cible. Cela se traduit souvent dans les contrats « agiles » qui mettent en avant transparence, collaboration et adaptabilité, qui sont en soi souhaitables, mais pas délai, charge et planning, qui ne le sont pas moins.

Confrontés à ces 2 écueils, nous avons tracé sur une voie médiane.

L’archer, le cadavre exquis et le sculpteur

Un projet classique peut être comparé à un archer prenant son temps pour viser la cible mais, une fois la flèche partie, rien ne pourra la faire dévier ou l’arrêter. 5 degrés d’écart au lancement et, avec une cible à quelques dizaines de mètres, la flèche est hors cible. Plus la cible est loin, plus l’angle d’erreur tolérable est faible. 5% d’imprécision au démarrage d’un projet et deux mois après vous manquez l’objectif. Il faut alors tirer une seconde flèche de plus près puis une troisième d’encore plus près, jusqu’à ce que le tir soit parfait.

Un projet dans une démarche « agile » ressemble davantage à un cadavre exquis. Ce jeu collectif popularisé par les surréalistes, consistant à composer des phrases à partir de mots que chacun écrit tour à tour en ignorant la collaboration des autres joueurs (le nom provient d’une des premières phrases générée par les surréalistes quand ils inventèrent le jeu : Le cadavre exquis a bu le vin nouveau.)A l’arrivée on déplie la feuille et on découvre que le résultat est souvent plus drôle que signifiant.

A cette vision, nous opposons celle du sculpteur qui esquisse la statue à produire en quelques dessins, cadre les dimensions du bloc de pierre puis dégrossit la pierre et affine son œuvre par passages successifs. Toute erreur d’appréciation, toute imperfection du matériau peut être rapidement rectifiée. A chaque passage, il peut encore modifier les spécifications des étapes ultérieures mais plus des étapes précédentes.

La démarche progressive

La méthodologie de mise en place d’un outil de CRM que nous défendons peut être qualifiée de Méthodologie progressive. Elle allie les apports de la formalisation des méthodologies traditionnelles à la flexibilité des méthodes agiles. Elle associe les équipes client au projet sans pour autant leur faire porter le poids du projet. Elle permet de concilier vision long terme et progression par étape.

En quelques mots, une phase de cadrage / prototypage permet de définir les spécifications de la solution qui devront être validées formellement. En ce sens, elle est plus contraignante que les méthodologies agiles. En revanche le résultat de chaque atelier est immédiatement maquetté sur le logiciel et, réunion après réunion le prototype est construit. Ce que le groupe de projet (et les utilisateurs pilotes) vont valider n’est pas un épais document papier mais un logiciel opérationnel avec ses écrans et sa cinématique. La maquette est « vivante ».  Le prototype se construit progressivement, non pas dans une approche darwinienne laissant une large part au hasard et à l’expérimentation mais à l’intérieur de guides garants des délais et du budget.

L’étape suivante, « Intégration » se réduit alors à l’implémentation des flux de données et des règles de gestion. Après un « test grandeur réelle » ou « field test », une étape supplémentaire « Ajustement » est réservée pour réaliser les ajustements essentiels. L’étape de déploiement est identique aux autres méthodologies.

Depuis le début du projet jusqu’à la mise en production un blog projet et la maquette du logiciel sont disponibles en ligne dans un espace privatif. Ces outils permettent de garder une relation constante et permanente entre les équipes.

Cette démarche possède de nombreux atouts pour des projets CRM. Elle implique le groupe de projet client sans le surcharger et elle permet d’aborder le projet avec davantage de flexibilité sans pour autant l’affranchir des contraintes budgétaires et de délai. La seule contrainte de cette démarche et elle est de taille : il faut bénéficier d’un logiciel facile et rapide à prototyper.

Partager cet article
Lire également
Leave a comment