Par 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.
Il faudrait définir un ratio d’impact qui serait appliqué sur le RUN:
Ce calcul fait toutefois abstraction de toute considération d’optimisation indépendante du Run.
Cette première réponse pourra d’ailleurs être assez difficile à entendre pour les personnes en charge des services RUN.
Le gestionnaire de services ou « service owner », (quand il existe) se voit souvent confier un budget de fonctionnement que ne tient pas compte de l’ensemble des coûts.
Les coûts liés aux dotations aux amortissements ne sont que très rarement connus, pilotés, et encore moins souvent intégrés dans le coût des services RUN.
Il faudra donc que les travaux amonts soient réalisés pour permettre d’allouer le montant des dotations aux services auxquels les immobilisations ont contribué. On parle bien dans ce cas du pilotage des investissements et de la gestion des actifs.
Cette gestion est indispensable au pilotage économique de l’entreprise, et peut parfois être compliquée par le fait que certains des actifs ne sont pas propriété de l’entreprise mais génèrent par contre des coûts de fonctionnement. Dans le cadre d’établissement publics dont les budgets d’investissements (crédits d’ouvrage, crédits d’inventaires) sont supportés par des organismes étatiques, mais les charges de fonctionnement sont supportées par l’entreprise qui les « utilisent ».
Une seconde réponse – la simulation :
Pour aller plus loin dans l’aide que nous voulons apporter aux DSI qui souhaitent connaitre l’impact du BUILD sur le RUN, nous proposons de travailler sur une approche complémentaire : la simulation.
Cette approche n’est en rien nouvelle, elle n’en reste pas moins innovante si on regarde la façon dont les DSI travaillent aujourd’hui.
Il s’agit non plus de calculer les coûts passés, ce que nous aurons fait en mettant en place un modèle de calcul des coûts complets, mais bien de construire un modèle de simulation qui va permettre de travailler selon des scénarios et des hypothèses.
Il va s’agir d’obtenir des responsables des projets / project Owner – manager un certain nombre d’informations dans le cadre du dossier projet / business case.
Chaque projet devra ainsi faire l’objet d’une analyse détaillée pour apporter des éléments utiles à la construction des hypothèses. Il sera nécessaire de produire des données chiffrées (volumes / quantités) pour alimenter les scénarios :
Puissance machine
Nombre de CPU
Espace disque
Nombre d’environnements de pré production / production
Nombre de licences
Type de licences
Nombres d’utilisateurs
Montée en puissance dans le temps
…
Toutes ces informations serviront à alimenter le modèle de simulation. Les projets sont à l’origine des besoins, ils impactent les services et les activités, ce qui entrainera alors un effet sur les ressources dont il faudra disposer en fonction de chacune des hypothèses.
On parle alors de modèle « ABB » pour « Activity Based Budgeting ».
Comme le modèle de calcul des coûts complets est construit sur le principe de calcul des coûts des activités qui contribuent ensuite aux services, le modèle de simulation ABB sera construit selon des hypothèses de volumes sur les services et activités, éventuellement associées à des règles (paliers, seuils…) qui permettront ensuite, un fois paramétrées dans l’outil de simulation, de définir le niveau des ressources, et de calculer le coût récurrent d’un service à l’issue du projet qui y contribue : l’impact du Build sur le Run.
Une telle approche nécessitera d’impliquer les responsables projets le plus tôt possible dans le processus de cadrage. Cette dimension ira bien au-delà du cadrage budgétaire habituel puisqu’il devra être détaillé et argumenté, validé par les équipes techniques, au-delà la partie fonctionnelle et métier.
Les données de base pourront bien entendu être issues du modèle économique et du calcul des coûts complets (ABC).
Les deux démarches étant complémentaires, une simulation n’impose pourtant pas de disposer d’un modèle ABC complet au préalable. Il sera de toute façon nécessaire de construire le modèle de simulation.
Une telle approche, si elle est innovante, n’est en rien réservée à certains types de DSI. Nous avons entendu maintes fois les objections qui servaient de justification pour ne rien faire.
Mais la crise est passée par là. Nous savons aujourd’hui que nous allons devoir changer nos approches budgétaires. Nous ne pouvons plus agir comme si rien ne s’était passé. Personne ne sait dire quel scénario sera le bon, alors autant travailler sur des hypothèses et se préparer à l’imprévu.
N’est-ce pas là le principe même de l’agilité dont toutes les DSI parlent aujourd’hui ?
Pour plus d'informations, contactez-nous ici ou via l'adresse mail contact@cost-house.com