Modèle d’analyse des coûts et portefeuille de projet

Pour faire face aux nombreuses demandes des métiers, les DSI se dotent d’une gouvernance de gestion de portefeuille de projet. Les cadres de gestion de projet définissent les activités et livrables pour le bon déroulement d’un projet alors que la gestion de portefeuille de projet s’attache à cibler et suivre les projets à exécuter dans un cadre budgétaire donné.
Conformément aux objectifs de VAL IT qui est un des principaux cadres de gouvernance des investissements informatiques, « la gestion de portefeuille vise à optimiser la création de valeur à travers la construction du portefeuille d'investissement. Il faut, notamment, identifier les ressources nécessaires à chaque projet, définir les seuils d'investissement, évaluer, classer puis sélectionner (ou rejeter) les projets à lancer, gérer globalement le portefeuille d'investissements en termes de risques et rentabilité, surveiller les performances et en rendre-compte. ».
Les projets représentent l’effort à faire pour adapter le SI aux nouvelles exigences, pour contrer son obsolescence. Nous distinguons 2 types de projets :

• Les projets métier : les demandeurs sont les métiers. Ce sont les projets discrétionnaires ou non (ex : projets réglementaires) sponsorisés par les métiers. L’objectif est d’aligner le SI avec les besoins des métiers.
• Les projets techniques : les demandeurs sont les acteurs des directions informatiques. Ce sont les projets qui permettent de mettre à l’état de l’art les infrastructures informatiques.

Il est important de souligner que ces 2 typologies de projets doivent apparaître dans une gestion de portefeuille de projet. Or, fort est de constater que les projets techniques y sont rarement présents. Pourtant tous les projets doivent être évalués d’un point de vue global dans un but de sélection et d'arbitrage, les projets techniques au même titre que les projets métiers car les 2 typologies constituent la partie la plus arbitrable de l’ensemble des couts d’une DSI.

Val IT décline la stratégie IT en processus et en activités d’investissement. Voici ci-dessous quelques rappels du cadre VAL IT, et nous montrerons en quoi un modèle économique pour les DSI est essentiel pour l’atteinte de ces objectifs :

• PM1 : établir une stratégie claire et définir la structure de la cible en termes d'investissements
• PM2 : déterminer les sources et la disponibilité des budgets,
• PM4 : évaluer et sélectionner les programmes à financer,
• …
• IM4 : préparer le budget sur le cycle de vie complet
• IM5 : construire le business case complet, détaillé

Outre les projets réglementaires pour lesquels la justification économique n’a pas réellement de sens, cibler les bons investissements nécessite d’évaluer avec une fiabilité suffisante les projets qui seront les plus rentables. En clair, il faut être capable de mesurer à partir de quand les gains obtenus par les économies ou les flux générés par la solution sont supérieurs aux immobilisations de capitaux et aux charges consommées. On utilise pour cela des méthodes de type Retour Sur Investissement (RSI ou ROI en français), VAN ou TRI.
Cependant, même en supposant disposer des meilleures estimations de charges prévisionnelles de réalisation, faire une bonne hypothèse financière exige certains prérequis qui ne sont pas encore systématiques dans bon nombre de DSI :

1. Evaluer les coûts en cash pour les budgets et en PL pour l’analyse économique : le montant des dépenses doit s’évaluer selon différents critères en fonction de l’analyse recherchée. Il n’y a malheureusement pas qu’une façon de valoriser les dépenses.
2. Evaluer les couts projets en coût complet : certaines activités transverses sont nécessaires au projet. Il convient de réintégrer une quotepart de ces charges dans les coûts des projets afin d’approcher le coût réels des projets, sous peine de sur estimée la rentabilité supposée.
3. Evaluer correctement les coûts récurrents : l’analyse de rentabilité d’un projet n’a de sens que si on n’oublie pas d’incorporer les couts récurrents de(s) application(s) qui en résultent - le Run.
4. Evaluer les couts informatiques au regard des gains métiers : il ne suffit pas de regarder que les seuls coûts informatiques. Il convient d’intégrer les dépenses informatiques au regard des gains métiers.

Je vous propose de revenir plus longuement sur chacun de ces 4 points ci-dessous.

Evaluation en cash et en PL

Une direction financière s’attache à évaluer les demandes de la DSI afin de se forger une opinion sur ce qu’il convient d’allouer en investissement (Capex) et/ou en fonctionnement (Opex). En effet, un projet qui vise à développer un logiciel peut être une alternative à l’acquisition d’un progiciel. Si on considère qu’un progiciel est un actif inscrit donc au bilan (il enrichit le capital de l’entreprise), alors le même raisonnement s’applique à un logiciel développé maison.
Par conséquent, si un projet est immobilisé alors ses dépenses seront étalées sur plusieurs années via les amortissements avec un impact différé sur les résultats futurs. Si au contraire le projet n’est pas considéré comme actif alors l’ensemble des dépenses de la période sont en charges et ont donc un impact immédiat sur le résultat d’exploitation.
Il convient donc de structurer les dépenses projets (métiers et techniques) selon une vue axée budget et une vue axée finance.

Vue axée budget de moyens

Cette vue permet de mesurer les moyens financiers alloués à une ou plusieurs structures (les départements études par ex.). Ici, les dépenses doivent être évalués en cash-out car les responsables études raisonnent souvent en nombre de jour hommes valorisés et donc en effort de décaissement. Ils ne soucient pas de savoir quels sont les projets passés en production immobilisé. Ce n’est pas leur préoccupation !
Un budget de moyen permet de responsabiliser un chef de département vis-à-vis des moyens financiers alloués pour une période donnée. Le suivi budgétaire aura pour mission de mesurer la consommation de ces moyens au regard de ce qui a été consommé et du reste à faire.

Vue axée finance

Cette vue comptabilise les dépenses des projets selon la dichotomie actif / charge. En effet, un projet immobilisé en année N et amorti à partir de N+1, ne génère aucune charge en N et que des amortissements en N+1.
Elle permet de mettre en évidence sur un axe temporel l’ensemble des charges et produits estimées et répond donc aux exigences d’analyse financière.
Cette vue est rarement utilisé pour les arbitrages budgétaires (la vue cash-out est privilégiée) car il est souvent compliqué d’expliquer à un chef de projet qui a transpiré toute l’année pour respecter les délais que son projet extourné en production immobilisé, n’a rien couté ! En effet, dans les charges du compte d’exploitation, seuls les amortissements du projet au prorata temporis à partir de la date de mise en exploitation sont comptabilisés.

Evaluation des projets en couts complets

L’effort projet se mesure souvent en nombre de JH, les budgets étant ensuite valorisés en € à partir d’un ou plusieurs tarifs journalier moyen construit à partir de critères comme le profil, l’expérience, ….
Le taux journaliers englobe un périmètre de charges qui diffère selon les entreprises. Certaines incluent les charges immobilières et mobilières (parfois on y retrouve les coûts des Datacenters lorsqu’ils sont gérés en dehors de la DSI), d’autres y ajoutent les coûts des postes de travail, les couts des prestations sociales annexes, etc. Cependant, même si le périmètre fluctue, ils ne prennent que rarement en compte l’ensemble des dépenses qui permettent d’en évaluer le coût complet, ce qui devrait être pourtant la règle pour justifier des investissements. En effet, tous les projets bénéficient du support d’activités transverses à la DSI voire à l’entreprise telles que l’architecture SI, l’urbanisme, la sécurité, les méthodes, la qualité, les RH, les achats, le juridiques, et … le PMO. Bénéficiant de ces services, il convient de les inclure dans le coût des projets même si je vous l’accorde ce poids ira diminuant unitairement par projet au fur et à mesure de l’accroissement du nombre de projets (caractéristiques des charges fixes).
L’ensemble de ces activités existent parce que la DSI existe et que des projets y sont menés. Par exemple, la qualité contribue au bon déroulement des projets, les RH sont au service des internes (sic !), les projets bénéficient de la sécurité du SI, etc.
Il convient donc de réintégrer une quote-part de ces activités transverses dans le coût des projets. Ce point est important car l’écart de coût entre un projet en TJM et en un coût complet peut varier entre 10 et 20% selon les structures. Réintégrer les fonctions supports dans le coût des projets donne une vision plus réaliste des coûts des projets et par conséquent de meilleures estimations de coûts pour les futurs projets.

Coûts récurrents des services

La rentabilité d'un projet impose de prendre en compte des coûts qui naîtront après la fin de vie des projets. Ce sont en autres des coûts de Run des applications qui sur leurs durée de vie peuvent être très largement supérieur aux coûts des projets, d'où l'importance de les estimer au mieux.

Coûts récurrents des projets

Concernant les projets pluriannuels, il faut évidemment cumuler les dépenses qui s’étalent sur plusieurs exercices, ceci pour disposer d’une vue globale des moyens financiers consommés depuis le début. Il ne faut oublier d’évaluer la part du budget étude déjà alloué aux projets pluriannuels, qui sans arbitrages supplémentaires, amputent la capacité à mener de nouveaux projets.
Dans le cas d’un programme, où cohabitent des projets immobilisés et en charges, il faut rester vigilant à bien distinguer les coûts globaux en cash et en P/L.

Coût récurrent des applications

Concernant les applications, il ne faut pas oublier d’évaluer les coûts récurrents de la production (le Run) et de les introduire dans l’équation financière pour un meilleur ciblage des projets. Si on se projette sur la durée de vie d’une application, les coûts récurrents d’exploitation des applications sont bien souvent supérieurs au total des dépenses des projets. Il est par conséquent important de les intégrer dans l’analyse financière pour plus de pertinence.
Cependant, ces dépenses sont souvent mal évaluées car sans modèle d’analyse de coût, il est très difficile d’en estimer correctement le coût complet. Il est fréquent d’intégrer que les seuls dépenses liées aux acquisitions de serveurs, de logiciels ou de stockage spécifique aux projets mais beaucoup plus rarement l’ensemble de coûts des activités d’une production informatique. Afin de rendre un service compatible avec les niveaux de services exigés, une application nécessite l’accomplissement de nombreuses activités humaines récurrentes (exploitation, supervision, sauvegarde, administration réseau, des SGBD, …). Les activités humaines pèsent largement plus que les coûts visibles d’acquisition d’infrastructure (un rapport de 70 /30 en moyenne) et sont cependant largement sous estimées, voir ignorées alors qu’elle constitue la part prépondérante des coûts récurrents d’une application.
Une évaluation plus juste des coûts des applications doit reposer sur un modèle économique qui permet d’appréhender l’ensemble des dépenses y compris la part la plus importante des activités humaines. A l’aide d’un modèle économique et au bout de 3 à 4 ans d’historique, il est possible d’avoir quelques abaques précis par gabarit d’application (nombre de serveur, type d’OS ; type d’architecture ; volumétrie des bases, volumétrie du stockage, …). Ces abaques mettent en relief les coûts moyens des activités pour un profil d’application donné. De là il est plus facile d’avoir des hypothèses de coûts en fonction de l’architecture, de la volumétrie des applications par extrapolation des coûts complets déjà constatés et de réintroduire ses hypothèses dans les analyses financières.

Evaluer les coûts informatiques au regard des gains métiers

On l’a vue, cibler les bons projets requière une bonne estimation des coûts projets et d’exploitation. Mais les meilleures estimations ont bien peu d’intérêt sans une mise en perspective des gains métiers. En regardant plus largement,un système d’information au niveau de l’entreprise s’articule autour de :
 l’usage du SI par les métiers : les métiers déroulent des processus dont tout ou partie s’appuient sur des outils informatiques. L’ensemble que l’on nomme « mise à disposition des services » dans un modèle type CIGREF forme la partie des outils informatiques qui supportent les processus métiers. Le bon fonctionnement de ces services est de la responsabilité de la DSI. Leurs coûts incarnent la partie des coûts récurrents : c’est le coût du Run.
 la transformation du système d’information : L’adaptation des processus métiers engendre l’adaptation des outils informatiques qui doivent être achetés (cas de progiciel) ou développés au sein de projets. Les coûts projets incarnent la partie des coûts discrétionnaires : c’est le coût du Build.
Comme pour une DSI, le budget des métiers devrait s’articuler à minima autour de 2 blocs, un pour les coûts récurrents d’exploitation, un pour les coûts discrétionnaires liés à des projets d’adaptation. En séparant ces 2 natures de dépenses au niveau des métiers, il serait ainsi plus facile de remonter les coûts projets informatiques dans les coûts projets métiers dont ils sont sponsors et les coûts d’exploitation des applications dans les coûts d’exploitation des métiers. Ca faciliterait également les analyses financières des demandes métiers en regardant l’impact de leur demande sur les coûts d’exploitation.
En effet, en règle générale on cherche à moderniser les processus métiers pour en accroître l’efficacité, le rendement donc l’efficience et ce en utilisant au mieux les nouvelles technologies. On peut penser que :
plus un métier est informatisé et plus ses coûts informatiques augmentent (plus de logiciel, plus d’infrastructure, plus de moyens humains pour l’exploitation, …)
plus un métier s’informatise, donc à priori s’automatise, est plus ses coûts d’exploitation hors informatique baissent.
la modernisation des processus par l’apport des nouvelles technologies numériques opère un transfert des coûts des métiers vers les coûts informatiques.
La rentabilité des projets doit donc s’analyser sur le périmètre des coûts informatiques mais aussi sur celui des coûts métiers : la hausse des coûts informatiques devant compenser à terme une baisse plus importante des coûts métiers dans l’optique d’un gain global.
Si on se polarise sur les seuls coûts récurrents, on peut en déduire que plus un métier est performant, plus la part des couts informatiques dans les couts métiers est importante :

0 < (Cout Opex Run / Cout Opex métier) < 1

Avec 1 signifiant qu’il n’y a plus rien côté métier et que tous est entièrement informatisé, ce qui n’est heureusement jamais le cas et ce qui n’est pas souhaitable, gardons un peu d’humanité dans tout ça !
En clair il faut évaluer les gains métiers occasionnés par les dépenses informatiques : Une dépense informatique supplémentaire n’est intéressante que si le métier progresse (plus rentable, plus efficace, plus qualitatif, plus productif, …). Or quand le ratio « cout informatique / cout métier » est utilisé, c’est en général pour vérifier que le ratio est le plus proche de 0, c’est-à-dire pour s’assurer que les couts informatiques restent les plus bas, ce qui est absurde et contraire aux objectifs initiaux recherchés. En effet, si on ne surveille que la seule partie des couts informatiques sans soucier du niveau de performance des processus métiers procurés par les dépenses informatiques, alors on freine toute velléité de modernisation du SI, et on ne voit la DSI que comme un facteur de dépenses, pas comme une agent créateur de valeur.
Il est donc logique d’étayer les prévisions de rentabilités économiques des projets inscrit au portefeuille de projet au regard des gains métiers induit par les dépenses informatiques.

Conclusion

Si la mise en place de cellule PMO tend à se démocratiser, les outils d’évaluation des coûts complets des services restent encore plus rares. ils permettent de comprendre la construction des coûts et en conséquence ils permettent de faire de meilleures évaluations des futures dépenses notamment des coûts récurrents consécutifs aux mises en production des applications issues des projets. Les modèles de coûts permettent d’avoir une vision plus réaliste de la trajectoire économique du plan projet et plus globalement de la DSI.
C’est donc sans conteste un atout capital pour une bonne gouvernance du SI.