Avant tout était simple. A la question “quel ROI ?” on répondait ainsi :”aujourd’hui vous traitez ce type d’opération avec 100 personnes armées d’une calculatrice et d’un bloc de papier, cela prend une semaine et le risque d’erreur est important. Grâce à notre solution une seule personne entre les données et les calculs sont opérés en une poignée de secondes”. Démonstration imparable même si elle n’a pas toujours tenu ses promesses.
Aujourd’hui, dans le contexte des outils sociaux, même si un consensus existe sur le principe, trouver la formule qui transforme l’apport d’un outil en modèle mathématique est loin d’être évident. La difficulté est évidente à exprimer : on ne parle pas d’outils qui font des choses préétablies mais d’outils qui permettent aux collaborateurs d’être efficaces dès lors que leurs tâches les amènent à sortir d’un schéma d’actions définies et répétées à l’infini dans un périmètre humain lui aussi défini.
Bref on sait très bien définir le ROI d’une application qui fait des choses définies et prévisibles, pas de celles qui permettent aux individus d’être performants face à des situations qui ne sont ni définies ni prévisibles. On doit faire évoluer notre modèle de raisonnement d’une “doer application” à une “enabler application”.
Avant d’aller plus loin regardez cette vidéo. Le ROI de la machine et la performance de l’individu y sont facilement calculables. Et demandez vous si cela ressemble à votre quotidien.
Ceci fait, il importe donc de se poser la question de mesurer ce qui compte.
On suit par habitude une logique qui veut que tout soit évalué individuellement : chaque individu, chaque machine, chaque outil. Mode de pensée hérité d’une époque où c’était logique, cohérent de procéder ainsi comme nous l’a montré la vidéo. Mais ayons bien en tête que cela suppose qu’aucun des éléments mesurés n’intéragisse avec aucun autre, ce qui ne correspond plus trop à la réalité du travail aujourd’hui. Cela n’est pas facile à admettre, est relativement inconfortable par rapport à ce que nous avons appris tout au long de nos études et de notre carrière mais nous raisonnons d’une manière peu appropriée à ce que l’on mesure. En effet une grande quantité d’éléments qui intéragissent entre eux, parfois de manière non prévisible, ne se mesure pas en additionnant les éléments les uns aux autres mais est sont système qu’il s’agit d’appréhender en tant que tel.
Le logiciel étant une partie du système il est à la fois vain et trompeur de chercher à évaluer son ROI hors du système. D’autant plus que, et j’ai maintes fois abordé la question ici, qu’il a été démontré par l’exemple que l’outil de délivre pas les mêmes résultats selon le contexte dans lequel il est utilisé, le mode de management en vigueur.
Bref, si on admet qu’un système est composé d’individus, d’informations, d’un mode opératoire et d’outils, aucun de ces éléments seuls ne peut être mesuré ou évalué en tant que tel : c’est la performance du système qu’il faut mesurer.
Votre système doit il produire des idées ? Mesurez le nombre d’idées, leur pertinence, le temps d’incubation. Et la valeur créée par leur mise en oeuvre.
Votre système doit il produire de la performance commerciale ? Mesurez l’augmentation des ventes, la rétention des clients, le cross-selling et l’upselling.
Et ainsi de suite.
Il faut bien garder en tête que le calcul ne soit plus porter sur tel individu, tel mode opératoire, tel outil pris indépendamment. Il s’agit du ROI d’un système impliquant des individus, avec tel mode opératoire et utilisant tels outils. Considérez le comme une boite noire si vous voulez, mais l’idée est de prendre en compte ce qui y rentre (coûts globaux) et ce qui en sort. Et pas de mesurer ce qui se passe à l’intérieur car l’exercice sera soit impossible soit amènera un résultat erroné pour les raisons que nous avons évoqué plus haut.
Sachant que nous entrons dans l’ère de l’organisation reconfigurable, orientée service, il est donc essentiel d’adopter des modes de raisonnent dynamiques, adaptés à la réalité de ce qu’on mesure.
Un dernier point. Lorsque vous chercherez à optimiser votre système, ne faites pas l’erreur de vous y attaquer point par point, acteur par acteur. En voulant optimiser l’action d’un des éléments du système vous risquez fort de détruire ce que vous avez construit : dans une telle approche l’amélioration de la performance du système passe par la suppression de ses contraintes, pas par l’ajout de contraintes nouvelles. Supprimer les barrières à l’efficacité (qui ne peut être que collective et plus individuelle) plutôt qu’ajouter des règles à n’en plus finir.
Le ROI des outils 2.0 n’est pas une notion pertinente. Le ROI de systèmes les utilisant oui. Ne pensez donc pas les outils indépendamment de leur contexte et cadre d’utilisation. Mesurez le système plutôt que l’application qui le supporte.
Related posts:
- Où l’on se rend compte du fossé entre management 2.0 et entreprise 2.0
- Le 2.0 vers une évolution systémique plus réaliste
- Plateformes 2.0 : La taille compte…mais l’ouverture aussi
- Quelle est la place future de votre système d’information pour votre performance ?
- Entreprise 2.0 : retour sur l’expérience de CISCO
If you don't read french, 
