Comme je le disais ici une des choses que j’ai retenu de la dernière édition d’UNLEASH Conference & Expo est l’importance donnée à l’adoption des outils RH. Ca n’est pas que le sujet soit neuf, il a toujours été dans l’air du temps, mais il finit par vraiment occuper le devant de la scène. Et si je trouve le sujet légitime j’ai bien peur qu’on le prenne du mauvais côté.
Self-Service RH et nouveaux services mettent l’adoption au centre des préoccupations
Sujet toujours légitime et encore plus aujourd’hui. Toujours légitime car le moins qu’on attende lorsqu’un outil est déployé est que les utilisateur l’utilisent. Mais c’était moins un problème en RH que dans d’autres domaines auxquels j’ai été confronté au sujet. Lorsqu’un outil est bien calé sur un process métier en général il n’y a pas de problème d’adoption : à la limite que les gens l’aiment ou pas ils doivent bien l’utiliser. La différence entre une bonne et une mauvaise adoption est alors plutôt de savoir s’ils l’utilisent avec plaisir ou à contre-cœur en pestant contre lui.
A l’inverse sur des sujets comme le collaboratif et notamment les réseaux sociaux d’entreprise et tout ce qu’on appelait la « collaboration sociale » c’était un sujet majeur dans le mesure où les entreprises essayaient de diffuser une sorte de collaboration hors sol, totalement détachée des process métier, ce qui faisait que n’utilisaient les outils que ceux qui y croyaient vraiment.
Maintenant la donne change coté RH. Nous sommes à une époque charnière où nombre d’entreprises remettent à niveau un SIRH ancien, avec deux conséquences :
– des outils nouveaux et plus modernes qu’il faut s’approprier
– une modification du rôle des RH qui demande l’appropriation de nouveaux rôles, de nouvelles tâches pour la mise en œuvre de nouveaux services aux collaborateurs.
A côté de cela l’utilisateur type des applications RH change. Avant le SIRH était utilisé par les professionnels des RH, aujourd’hui avec le développement du « self-service » qui permet au collaborateur de faire beaucoup plus de choses par lui-même sans passer par un intermédiaire ça n’est pas un département mais toute l’entreprise qui est concernée. Et si le self-service comporte des avantages pour le collaborateur il faut quand même lui « vendre » l’outil et l’idée de faire au lieu de faire faire. Si on a une vision « consumériste » des services et outils RH il faut voir le collaborateur comme un client et on ne peut plus se dire « ils n’ont qu’à l’utiliser que ça leur plaise ou non ».
Autant de définitions de l’adoption des outils RH que de parties prenantes
Ce qui est, au choix, amusant et inquiétant, c’est que la définition de l’adoption des outils peut largement varier selon la personne à qui on en parle.
Pour l’éditeur du logiciel adoption signifie utilisation. « Ils l’utilisent, c’est ok, peu importe pour quoi ». Pas forcément satisfaisant mais beaucoup mieux qu’à l’époque où une fois la licence vendue ils se moquaient bien de ce qu’il en advenait. Le passage au cloud et au modèle Saas a forcé les éditeurs à revoir leurs critères de succès et c’est une bonne chose.
Pour l’entreprise la définition est assez similaire mais avec en plus une démarche ROIste et une prise en compte croissante du niveau de satisfaction des utilisateurs.. On attend derrière que les nouveaux process/services mises en place créent de la valeur d’une manière ou d’une autre, génèrent des économies, ou permettent de ré-allouer des ressources sur des sujets nouveaux.
Côté utilisateur final, adoption rime avec satisfaction d’un besoin. En tant que client vous utiliseriez quelque chose qui ne vous apporte rien, voire vous complique la vie ? Non. Logique.
Pour les cabinets de conseil qui accompagnent ces projets, adoption signifie communication, formation et conduite du changement. Normal ils en vivent.
Vient enfin un type d’acteur un peu nouveau : des éditeurs qui ne vendent pas de SIRH proprement dit mais des outils qui se pluggent sur le SIRH pour favoriser son adoption : formation et aide en ligne, gamification, mesure des usages…
L’adoption des outils RH : une question de quand autant que de quoi
Je vais repartir du parallèle que j’effectuais avec les outils collaboratifs et vous expliquer pourquoi j’ai toujours eu un soucis avec le concept d’adoption.
Je disais que le gros problème en matière de collaboration et, surtout, en termes de collaboration sociale, informelle, non structurée, émergente telle qu’on la voulait portée par les réseaux d’entreprise était qu’elle fonctionnait en parallèle de process qu’elle était supposée supporter mais de manière déconnectée. On ne voulait pas toucher aux process métier mais on espérait que, par magie, un truc allait se passer à côté qui allait améliorer leur exécution.
Comme cela n’avait aucun sens pour le collaborateur on mettait le paquet sur l’adoption : communication et marketing projet à outrance, animation à grand renfort de community management car les collaborateurs étaient inactifs etc. L’entreprise ne voulant pas s’adapter à ce que permettait l’outil, on déportait la charge du changement vers le collaborateur. On mettait le paquet sur l’accompagnement des utilisateurs une fois l’outil mis en service faute d’avoir fait le travail nécessaire sur le management, sur le design des process collaboratifs métier.
Pour étendre cette réflexion aux outils RH (et autres autres outils d’ailleurs) je continue à penser que lorsqu’on voit qu’on a un problème d’adoption c’est qu’on a raté quelque chose dans la phase de design en amont. Le problème peut être directement lié à la conception de l’outil, où à la conception des process métier, au design de l’organisation, au delivery model, au modèle managérial… Mais normalement un projet bien pensé doit régler en amont 75 à 90% des problèmes d’adoption.
Vers l' »adoption by design »
Alors là certains vont me dire que justement les professionnels du changement et l’adoption n’ont aucun intérêt à ce qu’un projet de transformation, de mise en place d’un outil nouveau soit bien conçu sinon cela tue leur business. Et ils ont raison. Pour avoir œuvré de l’autre coté de la barrière je confirme que moins un client ne prenait la mesure de ce qu’il voulait faire et moins il avait le courage d’assumer les conséquences de son ambition plus cela faisait des projets longs et chers pour l’aider à sortir de l’ornière. Ma préférence allait plutôt à la réalisation d’une phase de cadrage et préparation musclée et profonde mais la vérité est que la plupart du temps l’entreprise préfère un projet qui sort vite avec un minimum de turbulences en amont, quitte à corriger les nombreux effets de bord en aval (lorsque c’est possible). Tant qu’on peut essayer de repousser les sujet qui fachent aux calendes grecques on le fait, ça n’est pas nouveau et ça n’est pas prêt de s’arrêter.
Il n’en reste pas moins que selon moi l’adoption ne devrait pas être un sujet majeur pour peu que le travail de design, de conception, de l’outil, des services, des process etc soit fait convenablement. En effet que signifie un déficit d’adoption d’un outil et de la démarche plus large qu’il incarne et supporte ?
- l’utilisateur ne voit pas l’utilité de l’outil
- l’outil n’a pas de sens au regard du management, de l’organisation, de la culture dans l’entreprise.
- l’outil rend les choses plus compliquées
- l’outil ne répond pas à un besoin du collaborateur (même s’il correspond à un besoin de l’organisation)
Essentiellement un problème de conception, de design.
L’adoption ne devrait d’être qu’un travail de facilitation, d’explication, et ne devrait pas consister à imposer des pratiques contre-nature, à combler le manque de sens ou d’utilité qui sont des défauts rédhibitoires.
L’adoption doit se penser en amont du projet et être intégrée dans les outils et la refonte des process pour ne pas avoir à être un sujet une fois les outils mis dans les mains des collaborateurs.