Par Steve GORDON, Associé Cost House France
Généralités
Communément en informatique, le Run fait référence au récurrent (ce qui permet à une DSI de fonctionner), et le Build aux projets (ce qui permet d'améliorer la valeur du patrimoine de l'entreprise).
Dans une logique CIGREF, le run, souvent résumé à la notion de "maintien en conditions opérationnelles", regroupe donc tous les coûts d'exploitation, de licence, d'infrastructure, mais également les coûts liés au cloud, au support, à l'hébergement...
Le build quant à lui se compose de deux grands blocs d'activités :
D'un côté les activités projets, que ceux-ci soient réalisés en cycle en V (pré étude, étude, dévs, tests, recette, mise en production, pilotage de projet, gestion des changements) ou selon des méthodes agiles (initialisation / gestion du backlog, sprints évolutif, etc.)
Et de l'autre les activités transverses au build, comme le pilotage du portefeuille de projets ou encore les études et conseils réalisés en dehors des projets du portefeuille
Les 4 problématiques principales
Une fois cela dit, on devrait aisément pouvoir calculer un ratio Run/Build et en tirer diverses conclusions et analyses. Sauf que ce n'est pas si simple, et ceci pour 4 raisons principalement.
1. L'existence d'activités transverses
La première raison : les activités transverses ! En effet, il existe également des activités qui ne sont ni run, ni build; citons par exemple les activités de gestion administrative de la DSI (contrôle de gestion, RH, achats, juridique) ou encore les activités relatives à la gouvernance du SI, au management d'équipe, à la qualité/méthode, à l'architecture, etc.
Certaines sociétés proposant du benchmark considèrent ces activités comme du Run
D'autres sociétés (comme la nôtre) ne calculent pas le ratio Run/Build au niveau des activités, mais attendent que celles-ci soient réparties sur les services délivrés par la DSI, dans une logique ABC.
Il faut juste le savoir, mais le choix qui aura été pris a nécessairement un impact sur le ratio Run/Build.
2. Le classement des services selon leur destination
La deuxième raison est relative au classement des services. En effet, les activités (tâches opérationnelles des équipes) permettent de fournir des services aux métiers et là, il n'y a pas de débat, un service est :
Soit Run, typiquement les services de types bureautiques, les services applicatifs ou encore tous les services dits "techniques" (SI de la DSI, plateformes de développement, de tests, de recette, de formation, de validation, de PRA, etc.)
Soit Build, et là on parle de l'ensemble du portefeuille de projets, qu'ils soient métiers ou techniques.
Mais à nouveau, ce n'est pas si simple... Prenons par exemple le service "Plateforme de développements, tests ou recettes" :
Il s'agit bien d'un service Run, la plateforme en question est en production et elle nécessite tout un tas d'activités run pour fonctionner... et toutes les activités en question sont run (les serveurs, les licences, les jours-hommes d'exploitation, etc.).
Sauf qu'une plateforme de dév/tests/recettes est utile à la fois pour des services run (pour corriger des bugs applicatifs), mais également, et probablement surtout, pour les projets (pour faire les dévs et les tests)
Nous sommes donc face à un service Run... mais qui sert à la fois au Run et au Build. Du coup, ce service n'est-il finalement "que run" ? Dans une logique CIGREF, oui, nous le considérons comme run uniquement, mais à nouveau, c'est essentiellement par "convention".
3. La vue financière dans laquelle on se place
La troisième raison concerne la vision financière dans laquelle on se place. De notre point de vue, le calcul du ratio Run/Build a principalement du sens dans une vision P&L (ou compte de résultat en français), car elle donne une vue lissée des coûts dans le temps. Nous parlons même d'une vision P&L dite "retraitée", dans laquelle nous neutralisons l'impact de la production immobilisée; ce qui revient, dans cette vision à considérer que l'on n'immobilise pas les jours- homme projet.
En effet, calculer ce ratio en vision Cash Out rendrait difficile les comparaisons d'une année sur l'autre; imaginons par exemple que nous calculions ce ratio en 2022 pour une entreprise, et que c'est l'année pendant laquelle l'entreprise en question a renouvelé l'ensemble de ses infrastructures serveur...
Le build serait alors très prépondérant en 2022... et très très faible en 2023.
4. Les conclusions que l'on tire du ratio calculé
Enfin, la dernière limite que nous voyons à ce ratio est relative à l'utilisation qui en est faite, et principalement aux conclusions qui en sont très souvent "trop rapidement" tirées.
L'année dernière, dans le cadre d'une mission de conseil, un DSI nous expliquait qu'il était fortement challengé par sa Direction générale car le ratio Run/Build était très en faveur du Run; la Direction générale concluant à des dysfonctionnements structurels au sein de la DSI...
Notre benchmark sur les coûts unitaires des activités, les TJMs, le poids des infrastructures ou des logiciels au sein du run, etc. a prouvé du contraire! Les coûts du run étaient très compétitifs!
En revanche, le budget global alloué par la Direction générale à cette DSI était tellement faible qu'une fois le run "payé" (les amortissements sont dûs, les maintenances logicielles également), il ne restait plus aucun fond disponible pour faire des projets. "Mathématiquement" donc, le ratio était structurellement en faveur du Run...
Conclusion
Au travers de ces 4 exemples, nous voyons toutes les limites qui peuvent peser sur le ratio Run/Build, mais surtout tous les impacts que ces limites peuvent avoir sur le calcul du ratio en question !
Malgré tout, le ratio Run/Build est un bon indicateur à suivre dans le temps ; il convient juste de s'accorder sur ses modalités de calcul d'une part... et de les garder dans la durée pour les comparaisons d'une année sur l'autre d'autre part...
Dans le même esprit, si l'on souhaite en plus se comparer avec d'autres acteurs DSI, il conviendra alors de s'appuyer sur une méthodologie "standard". C'est typiquement ce que nous proposons dans notre groupe de benchmark, en nous appuyant depuis près de 15 ans sur les versions itératives du référentiel proposé par le CIGREF.
Pour plus d'informations, contactez-nous ici ou via l'adresse mail contact@cost-house.com