par D. GOTCHAC
E-DEAL
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 appels à 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 :
- On travaille à produire un document de spécifications détaillées qui est validé,
- On réalise conformément au dossier de spécification,
- 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é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 :
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 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.
David GOTCHAC
Marina Costes
Nicole BERGER
Eric Stevens
Didier Serrant
Eric Dos Santos
Jérôme Pouponnot
Bonjour,
Cette démarche parait efficace dans le cadre d’un projet CRM.
Mais comment la décliner sur une TMA ( forfaitisée) ou le socle principal est déja existant ?
Cordialement,
Simon CHARLES
Nous avons déjà mis en place cette démarche dans le cadre de TMA. le fait de partir d’un socle existant n’est pas un problème en soi à condition toutefois de bénéficier d’un environnement de développement distinct de l’environnement de production.
Il faut néanmoins noter qu’en phase de TMA les utilisateurs connaissent l’environnement. On pense donc souvent qu’il est moins nécessaire pour des process simples de passer par le prototypage. C’est réellement une erreur et on gagne beaucoup de temps in fine à respecter un formalisme plus structurant.
Dernier point : Souvent, les TMA sont des “forfaits de jour” et on doit travailler en design to cost. Pour autant les grands principes de la méthodo restent valables.
Bien cordialement,
David GOTCHAC
Une nouvelle méthode pour gérer un projet de Relation Client ? Ne partageant pas la totalité de votre vision et de vos préconisations, je souhaitais y apporter quelques remarques :
• Réduire un projet CRM sur les seuls aspects mentionnés dans votre article : cadre réglementaire, typologie d’utilisateurs, nature de l’information ou modélisation de l’activité client ne serait-il pas évoquer un projet de gestion de contact améliorée et non un projet CRM ? Vous n’évoquez pas les processus métier transversaux, le flux de données entrant, circulant et sortant de la solution CRM, les différents référentiels, les règles de gestion qui, si elles ne sont pas réfléchies sur le papier et globalement avant tout prototypage, pourraient à elles seules remettre en cause tout un modèle ?
• Réduire la méthodologie “traditionnelle” d’un projet CRM aux seules trois étapes que vous mentionnez n’est-elle pas une perception limitée d’une méthodologie projet ? Car, au-delà de l’adaptation de l’outil CRM, quel qu’il soit, et du simple déploiement de la solution, la réussite d’un projet, particulièrement dans le domaine du CRM, n’est-elle pas basée surtout sur les aspects humains et organisationnels ?
Cela fait bien longtemps que les acteurs sérieux du CRM ont intégré, durant les phases de spécifications des besoins, des maquettes, ou autre prototype, avant de valider définitivement “l’épais document” que vous évoquez. Celui-ci restera néanmoins la mémoire de tout ce qui se sera dit et l’assurance qu’aucun point ne sera oublié par l’intégrateur durant la phase de développement. Il est toujours plus “facile” de faire et défaire sur le papier que de “reconstruire” tout un système parce qu’un point structurant aura été oublié en cours de réflexion. Prototyper des processus métier ne peut, à mon avis, s’imaginer “en live” dès le lendemain d’un atelier. L’expression des besoins doit être réfléchie et partagée avec les différents profils représentatifs des futurs utilisateurs, voire de différentes Directions, sa faisabilité ou son contournement identifié et proposé aux utilisateurs avant toute tentative de maquettage. Malgré toute la flexibilité des solutions de CRM, il restera toujours des contraintes et elles sont différentes en fonction des outils disponibles sur le marché. Enfin, construire “en live” avec un groupe projet et un groupe de travail représentatif des utilisateurs finaux de la solution ferait perdre beaucoup plus de temps car tant qu’ils n’ont pas une vision globale des fonctionnalités, ils n’auront pas la possibilité de “murir” leur réflexion sur leur future solution, nous avons testé pour vous …
La méthode projet que vous évoquez serait certainement pertinente si le projet est envisagé en un seul lot, mais nous le savons bien : la réalisation de la solution idéale pour toutes les Directions concernées, en une seule phase, est un risque majeur d’échec, voire une utopie. La pression interne et les objectifs de chacun, voire des seules ressources présentes pendant les phases de définition ne doivent pas être les principales contraintes du projet. La mise en production de fonctionnalités complémentaires est souvent inévitable car les besoins peuvent évoluer au fur et à mesure de la maturité des utilisateurs et de la maîtrise de l’outil. Il faudra découper le projet en plusieurs lots afin de garantir une première mise en œuvre rapide. Cela implique aussi, avant la réalisation de tout prototype au lendemain des ateliers, de pouvoir identifier les fonctionnalités qui pourront faire l’objet d’un lot ultérieur.
Mais aussi, comment gérer les nouveaux besoins qui apparaissent systématiquement pendant la phase de spécification fonctionnelle et comment savoir que le projet cible sera bien atteint, sans consommer au final un budget abyssal et non maitrisable, si on construit pas à pas le prototype ? Comment maitriser le planning et le réadapter en fonction de nouvelles priorités si on ne maitrise pas le contexte global ?
D’autres questions aussi peuvent se poser dans un contexte de prototypage permanent :
• Comment s’assurer des automatismes en fonction de critères dans un écran si on ne maitrise pas le flux circulant de la donnée ? Comment faciliter la saisie, éviter les incohérences et spécifier les informations importantes en fonction des cas de figure ?
• Comment optimiser l’efficacité d’un fichier si on ne maitrise pas les données qui seront importées, leur format, leur fréquence, avant même de définir le champ dans la base de données et bien sûr les profils de sécurités associées ?
• Si les reportings n’ont pas été spécifiés en amont et que certaines données ont été oubliées que faire ? Restructurer les bases à la fin du prototypage pour les rajouter dans la base de données et recommencer tous les processus et les formats d’import pour les intégrer ?
Enfin, je pense que dans le cadre de la méthodologie projet évoquée dans votre article, deux phases essentielles semblent avoir été oubliées : le Site Pilote et l’accompagnement au changement. Comment conduire le changement auprès des utilisateurs, adapter une communication et anticiper sur les risques si l’on ne maitrise les changements qui vont être opérés ?
Quelque soit la méthode utilisée, à mon sens, si le projet “vit” une phase tunnel, c’est qu’il n’aura pas été appréhendé, phasé, planifié et anticipé. Une phase de spécification des besoins “formalisée” en amont peut éviter de perdre du temps sur des points sans importance et surtout le risque de s’éloigner des principaux impératifs de spécification et arriver dans une impasse.
Je conclurai mes remarques en disant que ma perception de la méthodologie projet que vous présentez me laisse penser qu’il s’agit d’une vision éditeur. L’objectif de cette méthodologie ne serait-il pas de minimiser quelque peu les impacts budgétaires de l’intégration d’un projet au moment du choix de la solution quitte à additionner les avenants contractuels pendant toute la durée du projet en fonction des besoins spécifiés au fur et à mesure de la réflexion ?
Nicole Berger – Directeur de projets CRM – Cabinet Accoval
Nicole,
Un blog n’est pas un dossier et ce format est intrinsèquement réducteur.
Mon propos, vous l’avez bien compris, n’était pas de décrire par le menu tous les aspects d’un projet de CRM – ce que vous avez fort bien fait – mais plutôt de présenter les atouts et les faiblesses des 3 grandes familles de méthodologies de projet.
Depuis des années on utilise en France des méthodologies de projet qui sont toutes plus ou moins issues des travaux de SEMA dans les années 80. MERISE et ses descendantes s’attachent d’abord aux objets et à leur relations et prend comme principe que les utilisateurs savent modéliser leur besoin sur ce schéma. Nous avons tous vu des échecs de projets CRM liés à ce cadre méthodologique mal adapté.
En parallèle se sont développées outre atlantique ces dernières années des méthodologies issues de l’école “Xtrem programming”. Nous voyons là aussi les difficultés de mise en œuvre.
Les méthodologies “progressives” nous semblent réaliser un bonne synthèse, en tous les cas pour un projet CRM. Mon propos est plus celui d’un chef de projet informatique que d’un éditeur. Il ne minimise pas la composante humaine, la conduite du changement etc.. il ne traite que de l’organisation de la composante “informatique” d’un projet CRM.
Bonjour,
Nous avons développé de nombreux logiciels de “gestion” (base de données) destinées en général à la gestion des PME, mais également des applications industrielles, embarquées ou temps réel. Je souhaiterais apporter notre point de vue à votre article non pas sous l’angle du CRM, qui n’est pas notre spécialité, mais sur le plan de la conduite de projet pour le développement d’applications logicielles. Comme vous le soulignez dans votre dernière réponse, Monsieur GOTCHAC, votre article traite “de l’organisation de la composante “informatique” d’un projet CRM”. Je pense que votre réflexion peut être étendue à tout projet informatique se rapportant aux systèmes d’information. Nous avons réfléchi, comme vous et certainement comme bien d’autres entreprises qui développent des applications, à la meilleure approche qui permettrait de répondre de manière optimum aux besoins (et non pas seulement aux souhaits) de nos clients, afin d’éviter de tomber dans le travers très bien illustré par l’image de la balançoire que vous avez utilisée. Il serait trop long de développer dans notre réponse le cheminement que nous avons suivi depuis près de 20 ans pour tenter d’évoluer dans notre approche, mais j’essaierai de le résumer comme suit : Nous avons longuement expérimenté les méthodologies traditionnelles de développement, et nous avons abouti aux même conclusions que vous. Nous nous intéressons aux nouvelles “méthodes agiles”, mais nous émettons les mêmes réserves que vous. Nous avons donc essayé de définir une méthode “intermédiaire”. Nous l’avons baptisée “Conception objet orientée Client”. Elle présente des similitudes avec la “démarche progressive” que vous présentez. Elle est en cours d’expérimentation.
Voici les principales étapes de notre méthode:
1 Définition des besoins. Cette première étape – cruciale – doit être menée en prenant en compte le point de vue de la Direction, des experts du domaine des utilisateurs et si possible de tous les acteurs concernés, ou de leurs représentants. Après analyse (et éventuellement confrontation) des différents points de vue, le résultat est présenté sous la forme d’un document écrit en langage clair (pas en langage informatique) illustré par les principales interfaces (écrans, états, requêtes, …) afin d’offrir aux lecteurs, le client, une compréhension optimale du produit qui va être réalisé. Il peut ainsi réagir très en amont. Chacun sait qu’il est bien moins coûteux d’apporter des modifications dès cette phase : mieux vaut plus tôt que plus tard, voir jamais! Notre démarche s’inspire en partie de l’approche ergonomique, où la compréhension des attentes et des comportements des utilisateurs est l’élément central.
2 traduire ce document en une liste d’objets – les métadonnées :
- Les objets “ressources” : fiche client, fiche contact, fiche produit, ….
- Les objets “actions” : prise de rendez-vous, campagne marketing, devis, commande, facture, …
Chaque objet contient l’ensemble des informations qui le caractérise (par ex pour une facture : nom et adresse client, contenu des lignes de facture, totaux, conditions de paiement, ….)
Chaque objet de type “action” contient le(s) lien(s) qui le lie(nt) à/aux “actions” qui ont précédé (lien d’une facture vers le devis, du devis vers une campagne, …)
Chaque objet contient la liste exhaustive des données qu’il contient, et les règles métier qui s’appliquent à l’objet tout entier et/ou aux données (par exemple, une facture doit mentionner la référence de la commande du client, le total ht est la somme du total de chaque ligne de facture, …). Ces informations sont exprimées dans le vocabulaire du client.
Les informations techniques (nom de balise, de variable, type, …) sont ensuite définies pour chaque donnée.
Le résultat est un tableau détaillé de tous les objets, comprenant un volet “métier” validé avec le client, et un volet “technique” associé, défini par les informaticiens. C’est le tableau des métadonnées.
3 Développer les différents actions sous forme de services (web ou propriétaires), chaque action utilisant une ou plusieurs ressources.
A ce niveau, chaque action ou fonction élémentaire de base pour le client, peut être testée indépendamment, au fur et à mesure de leur développement, ou en les regroupant par “thème”.
4 Intégration et déploiement. Notre approche nous permet d’utiliser les technologies modernes, standard et éprouvées : au niveau des interfaces (Windows, navigateurs, Pocket PC, …), du middleware (serveurs, réseaux, …) et des bases de données (portage sur différents SGBDR open source ou propriétaires).
Quels outils avons-nous développé pour optimiser cette démarche?
La performance de cette méthodologie repose en grande partie sur une approche originale dans l’organisation des données. Nous avons défini une organisation logique des données recensées dans le tableau des métadonnées. Cette organisation logique nous a permis de développer un “SGBDP”, signifiant “Système de Gestion de Base de Données Polyvalente” (en interne, “Système Gérard BALAT, Diana, Pascal”, du nom des principaux protagonistes!). Cet outil est fondamental : il permet de “mapper” les objets définis ci-dessus dans une base relationnelle traditionnelle, de manière automatisée. Cela signifie que toutes les requêtes de la base sont génériques et automatisées. Elles sont indépendantes de la structure des données manipulées. Nous faisons donc appel à un “jeu” de requêtes prédéfinies (créer, modifier, lire un objet, rechercher une liste d’objets, supprimer des objets, …) disponibles pour tous les objets indépendamment de leur structure (d’où le terme “Polyvalent”).
Quels bénéfices tirer de la démarche “Conception objet orientée Client”?
Selon nous, cette approche présente parmi les principaux avantages :
1 Performance de la réponse par rapport aux besoins : Le travail “approfondi” sur la compréhension des besoins et la validation de cette étape avec le client permet un gain de temps important lors du développement, et garanti le succès du produit.
2 Séparation de la définition du travail à réaliser (les objets et leurs règles) des contraintes techniques associées. Pas de confusion entre la définition de ce qu’il faut faire, et du comment le faire. Les professionnels de l’informatique savent combien le “comment le faire” peut influer négativement s’il interfère trop tôt avec l’analyse de “ce qu’il faut faire” (revoir les images de la balançoire).
3 Le travail de développement technique est simplifié par l’organisation “modulaire” (ou objet) des fonctions à réaliser. D’où une qualité accrue, sans nécessiter un niveau de compétences exceptionnel” (une équipe “normalement constituée” suffit pour garantir le succès).
4 Un coût de réalisation optimisé, par la réduction du temps de développement et de mise au point, ainsi qu’une réduction des incidents en exploitation. En effet, les principales fonctions critiques sont automatisées (SGBDP).
5 Des possibilités d’évolution faciles à intégrer dans le produit à toutes les étapes (en point d’orgue une meilleure réactivité par rapport à l’évolution des processus de l’entreprise).
6 Un point de rencontre entre les experts du BPM (définition des processus de l’entreprise) et les professionnels des ERP (par la structure orientée services des modules développés). En effet, les objets “actions” permettent d’automatiser les “tâches” qui sont les grains élémentaires des processus.
Enfin je tiens à vous remercier si vous avez eu le courage de lire cet article jusqu’au bout. Je vous adresse mes plus cordiales salutations, et je suis à votre disposition si vous souhaitez poursuivre la discussion.
Gérard BALAT