Choisir un RSE : la philosophie prime sur la fonctionnalité

J’ai eu dernièrement une longue discussion sur la manière de choisir un RSE (réseau social d’entreprise). Naturellement nombre des participants à  la conversation sont partis sur des pistes bien connues et maitrisées : cahier des charges fonctionnels, scorecards etc. Rationnel, exhaustif, rassurant. Quand mon tour vint de donner mon avis au regard de ma petite expérience dans ce secteur, je n’ai pu totalement abonder dans cette direction. Non que ces approches ne mènent nulle part mais parce que l’endroit où elles vous mèneront ne sera en général jamais celui où vous auriez du aller.

Un RSE ne fait rien, il permet à  l’utilisateur de faire.

Un RSE et de manière générale une solution faisant partie de la grande famille de l' »enterprise social software » se distingue des outils auxquels on a été habitué sur différents points. L’un d’entre eux (et non des moindres) est qu’en général on choisissait de outils qui « faisaient », qui produisaient, qui transformaient un « input » en « output ». Un RSE ne transforme rien, un RSE ne fait rien. Il permet à  ses utilisateurs de faire. C’est une petite nuance mais une nuance qui change tout. On ne peut pas évaluer un RSE en faisant la liste de ses fonctionnalités mais à  la manière dont elles sont mises en œuvre dans le parcours utilisateur et surtout à  la facilité avec laquelle on atteint un objectif, le « job-to-be-done« .

Alors parfois je vois des listes de centaines de fonctionnalités dont il faut vérifier l’existence. Cela ne sert à  rien. Déjà  parce que cela ne présume en rien de la manière dont elles se combinent et s’enchainent dans le parcours utilisateur. Ensuite parce qu’elles correspondent souvent à  un transcription fonctionnelle d’un besoin opérationnel fait par des personnes ayant une faible connaissance du sujet et en procédant à  des approximations souvent coupables. Tel besoin = blog. Tel autre besoin = wiki. Et le blog il doit en plus faire ci ou ça. Et au final on disqualifie un outil qui correspond parfaitement au besoin, au(x) job(s)-to-be-done parce qu’il met les choses en œuvre différemment, d’une manière qui n’était pas envisagée par le rédacteur du cahier des charges, souvent plus simple ou plus innovante et celui qui est choisi car remplissant bien toutes les cases ne suscite pas l’adhésion des utilisateurs.

C’est un peu comme Ford qui disait « si j’avais demandé à  mes clients ce qu’ils voulaient ils auraient demandé des chevaux plus rapides ». Très souvent c’est ce qui se passe : on demande des chevaux plus rapide et on ne comprend pas celui qui vient proposer une voiture.

Bref, choisir un outil « social » sur de telles bases, aussi rassurant que cela soit, permet d’avoir un outil qui fait a peu peu près ce qu’il doit faire mais ne garantit jamais qu’il le fasse de la bonne manière, de celle qui a du sens et simplifie vraiment les choses.

Une approche purement fonctionnelle du RSE ne mène nulle part

A mon humble avis les seules questions à  poser à  un éditeur sont sur le modèle du « montrez moi comment on fait ça ». Enchainement d’actions en lien avec un objectif, cinématique, cohérence des enchainements etc. Bien sur l’Excel de 1450 lignes ça en jette davantage et montre à  son patron qu’on a vraiment bien travaillé mais ça consomme énormément de temps sans garantie aucune de résultat. Pratique pour se couvrir le postérieur, pas pour arriver à  un objectif.

Et à  la fin on rejouera une pièce bien connu : celle des utilisateurs qui disaient « ça ne correspond pas à  nos use-cases » et l’autre qui répond « si si, je vous ai donné toutes les fonctionnalités ».

Bon ceci dit tous les produits finissent par se ressembler. Au début chaque éditeur avait sa voie, sa vision, mais avec l’expérience il y a eu une forte convergence et tous proposent peu ou prou la même chose. Ce qui maque à  l’un est compensé par quelque chose que l’autre n’a pas et de toute manière ce qui manque arrivera d’ici un an, le temps pour les concurrents de s’être observés, copiés, et entendu les demandes de leurs utilisateurs. Et au final ça n’est toujours pas différenciant : la fonctionnalité n’est rien hors du parcours utilisateur, en relation avec le « job-to-be-done ».

Il est un chose qui par contre est en général unique : la philosophie de l’outil. Ce qui a prévalu à  sa création et sa mise sur le marché. C’est ce qui a justifié les divergences au départ, c’est ce qui fait que tel use-case ou telle fonctionnalité est mise en œuvre différemment de chez le voisin, ce qui explique qu’une nouvelle fonction sera ou non implémentée dans le futur. Et, de mon point de vue, au regard d’un besoin et d’un contexte d’entreprise, c’est ce qui permet d’arriver à  une short list crédible et aller loin dans le processus de décision sans passer 6 mois à  remplir des tableaux Excel qui au final diront pas grand chose.

La philosophie c’est ce qui fait d’un outil sera toujours plus ouvert et intégré qu’un autre, sera plus orienté process, document ou conversation, permettra plus ou moins de structuration, donnera des outils de pilotage et mesure avancés de l’activité ou pas, que la roadmap ira dans un sens qui vous convient…ou pas.

L’ADN d’un produit compte plus que ses fonctionnalités

Ce qui distingue les forces en présence sur le marché aujourd’hui n’est pas tellement fonctionnel : c’est la conviction qui était la leur au départ et continuera à  marquer profondément l’ADN de l’outil à  l’avenir. Pour certains on avait un CMS qui s’est paré de fonctionnalités sociales pour rester dans l’ère du temps mais ne sera jamais q’un CMS dans son ADN. D’autres sont partis d’espaces de travail et librairies avec arborescence et gestion de droit strictes et n’arriveront jamais à  devenir vraiment souples et transversaux parce que c’est codé dans leur ADN dès le premier jour. D’autres ne croyaient qu’en la conversation et auront du mal à  revenir vers les outils métier, d’autres n’étaient que communautaires et, génétiquement, ont du mal d’aller vers des approches orientées productivité individuelle.

Aucun n’est meilleur que l’autre dans l’absolu (à  part quelques errements réellement coupables). Par contre en fonction d’un besoin, d’un contexte, d’une priorité, la philosophie de l’un conviendra davantage que celle de l’autre.

Quelque part le travail sur la fameuse « adoption » commence déjà  peut être même ici : à  s’assurer de la cohérence des philosophies plutôt que remplir des lignes et des lignes de demandes fonctionnelles. D’ailleurs on le voit a posteriori : inconsciemment le choix de telle ou telle solution montre à  quel point on mise sur la collaboration sociale, sur la capacité ou l’incapacité à  lcher prise et permettre le développement de certaines formes de travail.

On ne compare pas deux produits sans connaissance de leur historique

Choisir un outil c’est choisir une philosophie d’usage et de management et même au sein d’une famille de produit comme l' »Enterprise Social Software » il y a des écarts énormes entre les différentes offres, une différence qu’une approche purement fonctionnelle ne permet pas de saisir, voire montre sous un jour qui induit en erreur.

Comme je le disais à  propos du rapport du Real Story Group, on ne peut comparer les outils sans prendre en compte leur ADN, leur histoire, leur paradigme sauf à  vouloir comparer des pommes et des bananes. CQFD.

 

Bertrand DUPERRINhttps://www.duperrin.com
Head of Employee and Client Experience @Emakina / Ex Directeur Consulting / Au croisement de l'humain, de la technologie et du business / Conférencier / Voyageur compulsif.

Derniers articles

Vous avez aimé ce billet ? Suivez moi sur les réseaux sociaux :