L’un de mes associés est en train d’effectuer des recherches concernant les outils de gestion d’anomalies qui existent sur le marché du SaaS (Software as a Service). En discutant avec lui, il a très bien résumé la situation : d’un côté, il échange avec l’un des grands éditeurs américains du marché qui répond par « oui c’est possible » à toutes ses questions et demandes. De l’autre un tout petit éditeur SaaS en phase d’acquisition de parts de marché qui lui répond la plupart du temps « non ça on fait pas ».
Pour autant, son choix est loin d’être arrêté pour les raisons suivantes.
Est-ce que « tout » c’est mieux ?
Pouvoir tout faire avec son logiciel c’est super, mais encore faut-il avoir le temps de le paramétrer…. Il n’y a que deux méthodes : payer un prestataire pour qu’il paramètre le logiciel de façon à répondre exactement à nos besoins, au risque que le projet dure 500 jours et coûte 2 millions d’euros. Ou bien paramétrer soi-même l’outil, si tant est que l’on en soit capable et que ce soit possible, ce qui prendra également un temps considérable et mobilisera forcément beaucoup de ressources en interne.
A l’inverse, être très limité dans ce que l’on peut faire avec le logiciel peut sembler contraignant à première vue, mais cela présente l’avantage de pouvoir démarrer rapidement. Et on peut au moins se concentrer sur le métier plutôt que sur le logiciel utilisé…. Bien sûr, cette remarque ne vaut que si les « besoins vitaux » sont couverts.
Cette réflexion doit également être prise en compte à la lueur du plan produit de l’éditeur. Si l’on sait que l’éditeur a une bonne vision du métier et fait évoluer son logiciel régulièrement, il peut être intéressant de démarrer sur une version simplifiée du logiciel et de la faire évoluer au fur et à mesure.
Bonnes pratiques versus process internes
Pouvoir tout faire, c’est aussi l’assurance de supporter les processus internes à l’entreprise tels qu’ils sont mis en oeuvre aujourd’hui. Même quand ces processus sont un peu « bizarres » (validation d’une demande de formation en 17 étapes par exemple)…. L’acquisition d’un logiciel fournit souvent l’opportunité de réviser certains processus, certaines habitudes, voire de bénéficier de bonnes pratiques du marché proposées par le logiciel. Mais à trop vouloir faire en sorte que le logiciel ne perturbe rien ni personne, on se prive d’une bonne occasion de revoir certains processus et d’améliorer l’organisation.
Un logiciel bien conçu doit nécessairement intégrer les bonnes pratiques de son secteur. Avec le temps, il inclut de plus en plus de fonctionnalités afin de répondre aux demandes récurrentes de ses clients. L’enjeu est de trouver le bon équilibre entre un logiciel qui serait la somme des besoins de tous ses clients et un logiciel qui ne présenterait au contraire que les fonctionnalités minimales. Là encore, je pense que la notion de vision que l’éditeur porte sur le marché est essentielle, car c’est la seule assurance que l’on ait en tant que client d’avoir un logiciel qui répond à nos besoins essentiels.
De quoi a-t-on vraiment besoin ?
En tant qu’éditeur SIRH, lorsque l’on regarde l’utilisation que nos clients font de notre logiciel, on constate que les fonctionnalités utilisées ne sont pas toujours celles sur lesquelles on a échangé durant des heures lors de la phase avant-vente. Est-ce à dire que les client sont volatiles et qu’ils décident en cours de route de faire autrement ? En réalité, ce n’est pas le cas. L’explication est très simple : ceux qui achètent le logiciel ne sont pas forcément ceux qui l’utilisent tous les jours. Chacun se fait une idée de ce dont un utilisateur pourrait avoir besoin, mais finalement l’utilisateur lui-même reste le mieux placé pour répondre à cette question. D’où l’intérêt d’impliquer des utilisateurs finaux lors des phases de choix.
Toutes ces réflexions s’appliquent parfaitement au marché des SIRH. En l’occurrence, le choix que mon associé fera du logiciel s’appuiera sur ces différentes réflexions, mais aussi et surtout sur le choix de l’équipe qui est derrière et sa capacité à nous aider sur notre projet. Car on en revient toujours et heureusement aux interactions humaines 😉
« Les fonctionnalités utilisées ne sont pas toujours celles sur lesquelles on a échangé durant des heures lors de la phase avant-vente ».
Oui, il y a des décideurs, des prescripteurs et des utilisateurs. Leurs attentes et besoins sont différents quand ils ne sont pas parfois divergents (DSI/DRH, DAF/DRH, etc.).
Une explication complémentaire pourrait être la subjectivité de l’acte d’achat. Achète-t-on toujours que ce dont on a besoin ? Ou ce dont on a envie ?
En matière de SIRH comme ailleurs, les fonctionnalités « goodies » et les innovations « poudre aux yeux », les signes d’appartenance, la valorisation perçue, le caractère potentiellement émotionnel du produit, etc. sont autant d’atouts commerciaux qui permettent de déclencher une vente. L’acte d’achat d’un SIRH n’est pas aussi objectif que son utilisation au quotidien.
Salut Thomas. Tout à fait d’accord sur le fait qu’il en va du domaine SIRH comme du reste : l’objectif et l’irrationnel ne sont pas toujours de mise….
D’où l’importance de faire l’effort de se ramener à ses besoins initiaux, sans se laisser entraîner sur des terrains tout aussi séduisants qu’inutiles, parce que d’autres y vont, parce que c’est à la mode…. Mais cela n’est-il pas applicable à notre vie entière au fait ? 😉
++
alex