Bonjour,

Nous aurions un cas concret à démontrer concernant la mesure de la satisfaction client dans le domaine de l’assurance. Des sondages à chaud couplés à la connaissance client et internaute permettent de comprendre l’impact de la satisfaction client.
Démarche de “conseil outillé” (utilisation de l’outil FeedBack Report de TELEMETRIS) avec des résultats percutants.
Seriez-vous intéressés par une présentation?
Merci d’avance
F. Bourgognon
AmbiCio
Associé

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

100% d’accord avec toi.
Exceptionnellement mon commentaire sera graphique :
http://www.gotchac.net/Didier_Serrant.png

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.

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

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

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

L’intérêt pour l’utilisateur, s’il existe, est finalement assez limité : oui c’est vrai il n’a pas à retaper des informations de connexion. Notons qu’en contrepartie :

1. il donne gratuitement à facebook toutes les informations sur son parcours sur la toile.

2. En cas de perte ou de vos de son id facebook c’est tout ses comptes qui deviennent accessible

3. Si pour une raison ou une autre facebook ne délivre pas l’autorisation d’accès (bug, indisponibilité du système, décision unilatérale, …) ce sont tous les accès de l’internaute qui lui sont refusés. L’histoire récente à montré que Facebook avait un sens de l’éthique pour le moins discutable …

http://www.infos-du-net.com/actualite/15209-Facebook-vie-privee.html

http://www.numerama.com/magazine/5770-Facebook-fait-marche-arriere-pour-Beacon-et-presente-ses-excuses.html

4. Quand on pense au remous qu’a provoqué il y a 6 mois encore le fichier Edvige … ou plus récemment, PERICLES http://www.lemonde.fr/technologies/article/2009/06/29/le-fichier-pericles-grand-mix-de-donnees-personnelles_1213151_651865.html on reste perplexe.

L’intérêt pour l’entreprise opérateur du site internet est bien décrit dans l’article

En revanche l’intérêt pour Facebook qui peut ainsi suivre à la trace chaque internaute est ENNNOOOOOOOOOOOOOORME.

Merci pour ce billet auquel je souscris totalement.
Je pense néanmoins que l’adhésion des utilisateurs est intimement liée à l’implication du management et à l’impulsion qu’il doit donner sur un tel projet complexe.

Malheureusement, l’Outil n’est pas encore en mesure de pallier aux insuffisances des qualités humaines…

Salutations,