Comment gérer l’impact du Build sur le Run ?

Par Hubert TESTE, Associé Cost House Suisse


Hubert Teste, Associé Cost House Suisse


Avant-propos :


En 2010, nous lancions le groupe de benchmark IT Cost House. Ce sont nos clients qui nous ont demandé de partager les données issues de leurs modèles économiques et systèmes de pilotage respectifs.

Les directeurs des systèmes d’information, et leurs équipes en charge du pilotage économique, de la gouvernance, souhaitaient pouvoir échanger, partager et surtout tirer un bénéfice des analyses comparatives pour agir.


Basé sur un référentiel commun (CIGREF 2006-2018), ainsi que sur la méthode ABC (Activity Based Costing) le modèle économique de la DSI permet d’analyser et de comparer les coûts à tous les niveaux :

  • Ressources : dans une dimension plutôt budgétaire, par rubrique comptable, famille ou typologie d’achat. Les plans comptables ont été rapidement écartés compte tenu du déploiement des modèles dans plusieurs pays européens

  • Activités : véritable colonne vertébrale du modèle de calcul et d’analyse, le niveau activités (une soixantaine dans le référentiel) apporte un nombre important d’axes d’analyses

- Par typologie (Run / Build / Transverse)

- Par type de répartition des coûts (direct / indirect / prorata)

- Par nature (activité humaines, activité d’achats)

- Et bien d’autres encore

  • Services : ce dernier niveau, plus spécifique à chaque DSI permet néanmoins de regrouper les services en grands groupes

- Les projets (qu’ils soient techniques ou métiers)

- Les services « récurrents »

- Les environnements de travail utilisateurs



De quelques dizaines d’indicateurs en 2010 nous en sommes arrivés à plus d’une centaine en 2020.


Même si le référentiel apporte un cadre structurant, le débat existe toujours pour savoir ce qu’on doit considérer comme une activité « BUILD » d’une activité « RUN ».


Mais l’objet aujourd’hui n’est pas d’engager cette discussion. Plaçons-nous au niveau des « services ». Car à ce niveau, il n’y aura pas de débat :

  • Les projets (ou les évolutions) sont dans la catégorie du BUILD

  • Les services récurrents et les environnements de travail utilisateurs sont dans la catégorie du RUN


Nous pourrions d’ailleurs compléter en disant que les services RUN sont issus des projets réalisés en amont.


Les premiers indicateurs attendus du benchmark consistaient donc à mesurer la part du BUILD et du RUN (ratio).


Comme tout indicateur de benchmark, après avoir produit le ratio, la question qui se pose « est ce grave docteur » ?


En fait, même si nous savons que nous allons créer une certaine frustration, la réponse serait plutôt « cela dépend ». Certes le ratio (moyen) est calculé, publié depuis 10 ans, et chaque membre peut se comparer (c’est bien l’objectif) mais l’analyse la plus pertinente n’est pas de se comparer une année N mais de regarder la tendance sur plusieurs années.


L’analyse doit être fait en prenant en compte la stratégie de l’entreprise et sa déclinaison par la DSI en termes de projets numériques et digitaux, et donc de services.


Je ne peux que vous reporter aux différents articles que nous avons déjà publiés sur le pilotage du portefeuille de projets ou la gouvernance du RUN.


Par contre, il est une question que toutes les DSI se posent :

« Comment gérer l’impact du BUILD sur le RUN » ?



L’approche budgétaire :


Lorsque nous déployons des systèmes de pilotage économique au sein des DSI, quelle que soit leur taille, le secteur d’activité de l’entreprise, le pays, nous savons que la première confusion provient du pilotage budgétaire.


A la question « quel est le montant de votre budget », ce ne sont pas une mais bien deux réponses qui doivent être données :

  • Le budget de fonctionnement

  • Le budget d’investissement


Mais avec ces deux informations, il n’est malheureusement pas possible de connaitre l’impact du BUILD sur le RUN.


En effet, contrairement à ce que beaucoup pensent, si RUN = fonctionnement, BUILD ne veut pas forcément dire investissement !


Finesse comptable direz-vous ?


En tout cas, erreur classique. Car que vous soyez contraints par les règles IFRS, IPSAS ou autres, voire que vous n’ayez aucune contrainte de ce type, il n’en reste pas moins que les choix qui sont faits par les directions financières ne permettent pas de connaitre directement l’impact du BUILD sur le RUN.

De plus, le développement des solutions « cloud » impactent fortement les structures budgétaires. Les dépenses d’investissements deviennent ainsi des dépenses de fonctionnement.


Les cas que nous rencontrons sont donc multiples et différents :

  • Les achats matériels sont très souvent amortis selon des règles « homogènes » pour les durées

  • Les achats logiciels de même

  • Mais les solutions cloud remettent en cause ces options (Saas / PaaS / IaaS …)

  • Les charges liées aux dépenses de prestations de services de type mandat / engagement de résultat au forfait sont généralement, pour partie, activées. (cf impact des règles IFRS/IPSAS)

  • Les autres prestations (location de services, engagements de moyens) sont plutôt considérées comme des charges courantes

  • Enfin, les salaires des équipes internes sont plus généralement considérés comme des charges courantes (donc de fonctionnement) mais il arrive qu’ils soient considérés comme des charges activables (donc d’investissements). Pourtant il n’y a pas de raison de traiter les salaires internes de façon différente des prestations externes.


Autant dire que choisir l’angle budgétaire pour analyser l’impact du BUILD sur le RUN ne semble pas être le plus évident.


Et pourtant, nous savons tous que les projets ont un impact direct sur les coûts des services qui sont ensuite délivrés.


Les budgets alloués aux projets permettent le développement de nouveaux services, l’amélioration de services existants. Il est cependant difficile d’estimer l’éventuelle augmentation des coûts récurrents.

Mais il est très rare que les budgets alloués aux projets prennent en compte l’impact sur les services RUN qui en découlent.


Cette question revient donc :


« Comment gérer l’impact du BUILD sur le RUN » ?


Nous allons essayer de vous présenter notre approche pour vous aider à trouver la réponse à cette question.



Une première réponse – la mesure :


Pour apporter une première réponse sur l’impact du BUILD sur le RUN, il est possible d’utiliser la mesure des coûts complets.

Ils peuvent être calculés grâce à un modèle économique ad hoc.

Selon les bonnes pratiques et l’état de l’art, les DSI disposent de tous les moyens nécessaires pour construire leur modèle économique.

En utilisant un référentiel métier (celui du CIGREF par exemple) et une méthode de calcul des coûts complets (Activity Based Costing), elles pourront calculer et analyser leurs coûts :

  • Par projet

  • Par service

  • Par activité


Et même se comparer selon tous les indicateurs de benchmark disponibles.


Mais on parle là des coûts « passés »


Mais cette approche présente deux limites :

- Elle est basée sur les coûts « passés »

- Le calcul des coûts BUILD et RUN ne donne pas « directement » l’impact du premier sur le second.