IT Management: que peut-on mesurer au juste?

Les entreprises développent leurs propres « métriques », dont la disponibilité des données, la fréquence des anomalies dans les applications… Néanmoins, il n’est pas toujours facile de choisir les bonnes mesures. Voici quelques conseils, proposés par Forrester Research dans une récente étude. A méditer…

Quoi mesurer? , mais quoi ? Car le choix des indicateurs est fondamental pour que le reporting des incidents et des alarmes déclenchées sur le système d’information serve à quelque> chose. Il ne suffit pas d’assurer peu ou prou l’équilibre entre des mesures au niveau opérationnel et d’autres empruntées à niveau plus stratégique. Il faut que ces deux catégories coopèrent et surtout ne s’ignorent pas. Or c’est loin d’être le cas. En témoigne cet exemple classique d’un indice de satisfaction client absolument pas mis en rapport avec le niveau de réduction des stocks. Or, un stock zéro est peut-être parfait lorsqu’on s’appelle Dell, mais c’est moins drôle quand on se surnomme Shell ! D’ailleurs, un récent rapport du Data Warehousing Institute démontre que sur 360 directeurs informatiques interrogés à propos des problèmes touchant à leurs données, pas un ne s’intéressait vraiment à l’équilibre entre poursuite des objectifs stratégiques et impératifs informatiques du terrain ! Tout cet art délicat vise pourtant à poubelliser une prospective trop envahissante (qui ne passe pas des heures et des heures devant ses feuilles Excel ?!). Bref, il convient de tout mettre en oeuvre pour que les éléments de prospective ne soient pas les mieux lotis. Au hit parade des techniques pour choisir les bonnes mesures, Forrester classe au premier rang l’analyse des objectifs de l’entreprise, suivie du réexamen des rapports existants (mille fois sur le métier?). Viennent ensuite les entretiens individuels avec les utilisateurs du système d’information, la cartographie des processus métier, des sessions de définition des processus clé, des entretiens des groupes de travail, la cartographie de l’information, puis celle des stratégies que l’on y appliquera et enfin des enquêtes pour vérifier si tout est en bonne voie. Une approche très SMART Forrester propose dans ce cadre d’adopter l’approche SMART, acronyme de Spécifique, Mesurable, Actionnable, Réaliste et en Temps voulu. La spécificité va de pair avec la pertinence de la mesure. On ne mesure pas des choux avec un mètre mais avec une balance. Idem en matière de système d’information et de fonctions métier. Ainsi, par exemple, du nombre de transactions effectuées par minute sur le serveur d’une salle de marché, ou du nombre d’accès à une base de données d’informations en une journée. La mesurabilité montre qu’en fait certaines mesures ne sont pas faciles à obtenir. C’est le cas notamment de tout ce qui touche au degré de satisfaction client et à toute mesure qualitative. Quelle part donner aux données qualitatives est une réflexion importante à mener pour bien départager dans les rapports ce qui est important de ce qui est surtout sensible pour l’utilisateur. Dans certains cas, cette sensibilité sera d’ailleurs le facteur clé, le ratio temps d’accès qualité de l’information en étant un bon exemple. La possibilité de pouvoir mettre en action la mesure relevée est également un aspect très important de cette métrique. Elle a notamment une influence sur l’altération éventuelle des résultats obtenus. En bref, une métrique que l’on ne peut pas contrôler et affiner n’est pas une bonne métrique. Réaliste veut dire que la mesure relevée doit avoir une valeur stratégique (ou tactique) pour influer sur une politique particulière (migration, mise à jour des systèmes, augmentation de la bande passante, intégration des applications métier dans un portail, les cas ne manquent pas). De ce fait, on doit pouvoir exploiter cette mesure pour connaître grâce à elle le pourcentage de projets menés à bien, ceux dont les résultats dépassent les espérances (bref, pas de la VoIP !), ceux qui ont été ajournés, etc. En temps et heure. Une mesure relevée inopportunément ne sert à rien. Il faut imputer les cycles découverts selon les métiers aux relevés concernant les activités informatiques qui y sont liées. D’ailleurs, il faut souvent faire en sorte que les données obtenues soient immédiatement disponibles dans l’outil d’analyse qui permet à l’administrateur de prendre des décisions. Une bonne métrique servira par exemple à comparer l’impact d’une réduction du temps d’accès aux données sur les affaires réalisées par rapport au temps d’accès précédemment obtenu et au niveau d’affaires qui lui était imputable. Trois « ingrédients » à surveiller Mais, pour que tout cela marche, il faut encore trois ingrédients : – la responsabilisation du créateur des mesures. Dans ce cadre, plus le responsable est spécifique (autrement plus on peut s’en reporter à des individus et non à un groupe), mieux cela marche. – le ciblage. Pas question de créer des métriques pour le plaisir. Celles-ci doivent répondre à des buts précis (par exemple, dégager du temps pour l’équipe informatique, réduire le nombre d’interventions sur les postes de travail, diminuer le recours au call center, etc.). – l’esprit d’initiative. Une mesure n’est pas figée une fois pour toutes. Il y a souvent moyen de l’améliorer ou de la corréler avec une autre situation au sein du système d’information, ce qui permet d’affiner la mesure et de ne pas avoir à réinventer la roue. Exemple : le taux d’indisponibilité est une mesure qui, mise en place pour un accès serveur, peut être étendue à l’accès aux applications? En résumé, on retiendra qu’il vaut mieux ne pas avoir de métriques plutôt que d’employer les mauvaises mesures. C’est bien connu, les mauvais ouvriers ont de mauvais outils. Bref, pour mesurer les paramètres de son système d’information et en tirer un peu de pertinence, il va falloir une fois de plus réfléchir avant d’agir.