Après quelques projets, tout consultant CRM découvre que le vocabulaire est très fluctuant : les mots n'ont pas toujours le même sens d'une entreprise à l'autre. Ici, l'application CRM traite des contacts. Là, elle traite des demandes, des affaires ou des opportunités ... Pour autant, il ne faut pas les prendre à la légère : les mots sont hérités du métier de l'entreprise, de sa culture et des projets informatiques précédents. Ne pas les respecter, c'est déjà prendre le risque de se heurter à une forte résistance au changement.
1. Reprendre certains éléments du passé.
La première tâche du consultant est donc de s'imprégner du vocabulaire de l'entreprise. La cartographie des parties prenantes du projet CRM (via des use case) puis la formalisation des processus permettent de construire un vocabulaire de référence qui sera utilisé de manière définitive (le vocabulaire n'est pas forcément repris à l'identique).
Si les mots sont des points d'ancrage pour l'utilisateur face à l'application informatique, d'autres éléments peuvent l'être aussi :
- les couleurs ;
- les icônes et images ;
- la police de caractère et le style ;
- la mise en page.
L'un de mes premiers projets consistait à remplacer la solution CRM par une autre. J'ai alors consacré quelques minutes de mes entretiens avec les utilisateurs à déceler les éléments significativement forts pour évaluer ensuite dans quelle mesure je pouvais les reproduire. J'ai ajouté ces contraintes à mes spécifications dans le but de faciliter le changement.
2. Ergonomie nouvelle et choix d'une solution CRM
La plupart des applications CRM doivent permettre à la fois de présenter un maximum d'informations à l'utilisateur ("le moins de clic possible") tout en proposant une IHM claire et lisible. Jusqu'à la mise en production, on croit souvent que cette contrainte est respectée parce que les interlocuteurs du projets (MOA, AMOA, recetteurs ...) ont vu l'interface se construire et s'y sont habitués.
Mais quelques jours après la mise en production, des critiques remontent parfois de la part des utilisateurs qui devront travailler au quotidien avec l'application. En général, les critiques portent sur la taille des caractères, le contraste des couleurs et la présence des ascenseurs. En clair, on a voulu mettre trop d'informations sur un seul écran. Pour éviter cela, il convient de formaliser quelques contraintes dès la rédaction des spécifications pour que MOA et MOE connaissent les limites. On peut alors s'en affranchir dans certains cas précis, en accord avec les utilisateurs (tests).
Comme les délais de mise en oeuvre d'une application CRM sont toujours courts, j'ai tendance à recommander le choix d'une solution dont l'ergonomie initiale et le paramétrage des interfaces sont réellement satisfaisants : simples, rapides et efficaces. C'est d'ailleurs l'un des arguments de la solution Salesforce.com.
De plus, les interfaces riches (RIA, RDA) présentent aujourd'hui de réelle opportunités ergonomiques, ce qu'indique Julien dans son billet sur les RIA : "ll est vrai que l’on imagine le gain apporté par de telles interfaces par rapport aux 12 écrans successifs des anciens "devis en ligne" des compagnies d’assurances". La future solution CRM devrait donc pouvoir disposer de telles options comme par exemple l'ajax qui permet de ne modifier qu'une partie de l'écran visible par l'utilisateur (dom) via une fonction javascript faisant directement appel au serveur via l'objet XMLHttpRequest. L'avantage de l'usage du javascript est qu'il réduit sensiblement les temps de réponse, malheureusement il faut aussi adapter le script aux différents navigateurs ce qui implique un surcoût en développement et maintenance. Certains éditeurs préfèrent donc l'emploi d'autres technologies telles que le flash, flex, silverlight, openlazlo ...
Sélection de livres cités dans ce blog ...