Last update: 02/06/2016 13:53

L'établissement du budget d'un département informatique IT au sein d'une entreprise est un exercice ardu. Pourtant les principes mêmes de la ligne budgétaire sont simples.

Les services IT doivent être séparés en deux catégories:

  1. Le Project Delivery
  2. Le Service Delivery

Pour faire simple, le "Project Delivery" vise à organiser les nouveaux projets. Le "Service Delivery", quant à lui, vise à s'occuper de l'existant. Quand un projet a été mené à bien, il quitte le monde du "Project Delivery" et entre dans le monde du "Service Delivery", et ce, selon des modalités à définir (critères d'acceptation, ...). Donnons corps à l'argumentation en parlant d'un exemple concret : une banque met sur pied un projet de "Online banking". Le projet suit son cours jusqu'à ce que la mise en production soit effectuée. L'application a été délivrée. Il faut maintenant en assurer la parftie "Service", la maintenance si vous voulez (bien que le "Service Delivery" ne se réduise pas à la maintenance).

Il découle de ce qui est dit précédemment que le budget IT doive tenir compte de ces deux sortes d'activité : le "Project Delivery" d'une part, le "Service Delivery" d'autre part.

Budget du Service Delivery

Il s'agit ici de rassembler l'ensemble des coûts, humains et matériels, auquel cette activité est exposée. On compte le coût de l'infrastructure (prise au sens large) et le coût humain pour la faire fonctionner.

Budget du Project Delivery

Il s'agit de rassembler l'ensemble des coûts, humains et matériels, auquel l'activité "Projets" est exposée. Or, on compte deux types de projets : les projets purement IT et les projets Business. Les projets IT sont les projets initiés par le département IT lui-même. Exemple : le suivi des projets implique l'utilisation d'un logiciel de gestion de projet et ce logiciel doit être adapté. Voilà typiquement un projet purement IT. À côté des projets IT il y a les projets Business. Ces projets-là sont initiés par le Business qui a détecté un bénéfice possible à mettre en oeuvre le projet X, ou qui doit simplement s'adapter à une nouvelle réglementation.

Formule budgétaire

BIT[1]  = BPDIT [2]  + BSD [3] 

Comme le démontre la formule, on n'inclut pas dans le calcul budgétaire de l'IT le budget nécessaire pour la réalisation des projets "Business" (BPDBU[4] ). Seuls les projets purement IT doivent être intégrés dans le budget du département IT[5] . Ces projets — les projets Business donc — doivent être pris en charge par le "Business" qui doit donc les financer, les mettre en concurrence, les prioritiser, évaluer les bénéfices escomptés, etc. D'un point de vue budgétaire, ces projets émargent donc à un autre budget que celui de l'IT.

C'est donc simplissime comme on peut le constater. Correction : le principe est simplissime. La mise en oeuvre est, elle, souvent plus complexe. Voyons donc de quoi peut provenir cette complexité.

Complexité inattendue

Dans le BSD, il faut compter les coûts de l'infrastructure. Or ces coûts d'infrastructure sont issus de projets passés, tant IT que Business mais aussi purement opérationnels [6] . Pensons, en la matière, au coût d'entretien des serveurs, des PCs, de la câblerie, des routeurs, des switchs, des firewalls, des systèmes d'exploitation, etc. Par ailleurs, une infrastructure informatique, même particulièrement bien entretenue, est appelée à être renouvellée. Ainsi, les PCs devront être remplacés une fois leur durée de vie atteinte. Cela fait partie du BSD mais, d'une manière ou d'une autre, proviennent de diféfrents projets. Le Service Delivery est donc fondé à exiger que le budget nécessaire provienne (au moins en partie) du Project Delivery. Le principe est encore simple mais sa mise en oeuvre est plus compliquée car elle nécessite des accords sur des clefs de répartition, sur des ratios de financement, entre différents départements, voire différents pays.

C'est exactement ici que se situe la complexité de l'établissement des budgets. Rien qu'ici. C'est donc précisément ici qu'il faut faire l'effort de clarification.

Révision budgétaire et planification des projets

Armé des principes exposés ci-avant, on comprend que les révisions budgétaires ne peuvent - ne doivent - pas se faire de manière globale. Il est indécent de connaître des surprises budgétaires en matière de "Service Delivery". Même l'inattendu peut être anticipé par le jeu de la contingence. Il s'agit de faire fonctionner ce qui fonctionnait : on doit être capable de chiffrer précisément les besoins, en matériel et en ressources humaines. Pour faire face à l'inopiné, on appliquera un pourcentage de contingence. Si ce budget de contingence est entamé, il doit être dûment justifié. Rien de plus, rien de moins.

Là où les surprises budgétaires sont légion — on a presque tendance à trouver cela normal — c'est essentiellement dans la partie "Project Delivery". Nous savons que nous avons essentiellement deux types de projets, les projets purement IT et les projets Business. Si les surprises budgétaires proviennent des projets purement IT, c'est que - soyons clairs — l'équipe IT n'est pas à la hauteur de sa tâche. Vous remarquerez une absence totale de langue de bois? Un effort plus ou moins important doit être fait pour obtenir une plus grande maturité (cfr. CMMI) et une plus grande maîtrise. Si les surprises budgétaires proviennent des projets Business … le problème ne se manifeste JAMAIS dans un budget IT : le problème se situe dans un budget Business (ce qui ne saurait signifier que l'IT n'est pas concerné par ce genre de dérapage, qu'il est dédouané, non pas, mais il s'agit-là d'une autre discussion[7] .).

La conclusion cingle donc : si des révisions budgétaires IT sont nécessaires, c'est soit un problème de "Service Delivery", soit un problème de "Project Delivery" (partie "Projets purement IT"), soit dans les deux à la fois. Quel que soit le cas de figure, des refontes importantes des "Deliveries" (Service ou Project) doivent être entamées.

Le glissement budgétaire issu des projets Business NE DOIT PAS impliquer une revue du budget IT (puisque fondamentalement il n'en fait pas partie). C'est inepte ! Or nous voyons cette pratique émerger de plus en plus souvent, avec pour conséquence une replanification de l'ensemble des projets : les moyens ne sont plus au rendez-vous, on postpose un lot de projets. Cet exercice de planification se tient le plus souvent sans consulter les bénéfices attendus des projets que l'on décide de postposer, ni même les obligations qu'il faut respecter (c'est ainsi que des projets "forced" — ou légaux — sont embarqués eux aussi). Vous nous excuserez de noircir volontairement le tableau, ce qui n'a d'autre but de de mieux faire ressortir les lignes directrices de nos conclusions.

Notes de bas de page

[1] … Budget de l'IT

[2] … Budget des projets IT dans le Project Delivery

[3] … Budget du Service Delivery

[4] … Budget des projets Business dans le Project Delivery

[5] … Cas spécial : sociétés IT dont le métier est de vendre des services/produits IT. Dans ce cas particulier, les projets Business sont effectivement des projets IT (par exemple, la cas d'une société qui crée un logiciel de comptabilité, ou un compilateur, ou des outils de développpements, …)

[6] … projets opérationnels et/ou organisationnels: plus personne n'utilise une machine à écrire. Un(e) réceptionniste, un(e) secrétaire, un(e) juriste, … utilisent tous un PC, font appel au support technique, etc. tous services organisés par le 'Service Delivery'

[7] … Fera peut-être l'objet d'un article ultérieur.

Our website uses cookies to save your preferences. We kindly ask you to consent to our use of cookies when you first visit our website. If you do not consent, the sole recourse is to stop visiting our website. X