L’art subtil de construire un budget IT

Comparaison de 4 processus budgétaires : quand simplicité ne rime pas forcément avec agilité

Dans les grands groupes internationaux, la période d’élaboration budgétaire est toujours un moment de tension :

• Comment retranscrire les priorités de l’entreprise en poches budgétaires?
• Quel budget faut-il allouer à cette initiative? à cette équipe? à cette application?
• Comment distinguer la part de budget allouée aux nouveaux projets? aux projets stratégiques? aux activités récurrentes?
• Quelle marge de sécurité se laisser pour les besoins qui apparaîtront en cours d’année?
• Comment s’assurer que le budget alloué permettra de maintenir le niveau de service souhaité?

Chaque année, de longs mois sont nécessaires aux CIO et leurs équipes pour répondre à ces questions. Peu d’entreprises peuvent se vanter d’avoir un processus budgétaire qui satisfasse le top management, les responsables métiers et les managers IT. Et nombreuses sont les entreprises qui souhaitent revoir et simplifier leur processus budgétaire.

Dans cet article nous verrons les 4 grandes manières de structurer un budget IT, le processus pour le construire, ainsi que les points forts et les points faibles associés.

Avant de rentrer dans le détail des différentes structures de budgets, revenons à une question plus fondamentale:

Un budget, mais pourquoi?

Par définition, un budget représente une autorisation de dépense pour un périmètre donné, pour une période donnée. Il permet ainsi à l’entreprise de cadrer l’utilisation de ses ressources et de limiter les dépenses excessives.

En choisissant comment allouer son budget, le CIO et ses partenaires matérialisent les priorités de l’organisation. Mais il y a souvent un délai incompréhensible entre les priorités budgétaires et les adaptations dans la taille et les activités des équipes.

Construire un budget revient donc à cadrer les moyens d’aujourd’hui pour répondre aux besoins de demain.

Pour mieux comprendre la différence entre les différentes structures de budget, prenons l’exemple d’une entreprise fictive: Mega Corporation.

Elle est constituée de:

• 2 périmètres A et B (chaînes, tribus, départements…)
• 5 équipes, 3 dans le périmètres A et 2 dans le périmètre B

Et pour l’année 2023, 4 projets ont été identifiés, et ils nécessitent potentiellement chacun la contribution de ces 5 équipes.

L’option par défaut: Cadrer les contributions détaillées par projet

Dans les grands groupes, la structure budgétaire la plus répandue est souvent de détailler l’ensemble des contributions attendues des équipes aux projets à venir. Chaque ligne budgétaire correspond donc à un couple “projet x équipe”.

Dans notre cas, la structure budgétaire comporte au plus 4 x 5 lignes de la manière suivante :

Le processus budgétaire:

Pour arriver à ce niveau de détail, les responsables de projets doivent échanger avec chacun des responsables d’équipes pour estimer les contributions de l’année suivante. La complexité budgétaire est donc directement proportionnelle au nombre de couple “projet x équipe” : plus les projets sont multi-contributeurs, plus l’exercice budgétaire sera long.

Les points forts

Un résultat simple — Par simple filtre, le responsable de projet, d’équipe ou de périmètre peut savoir quel est son budget pour l’année à venir. Il peut ainsi adapter la taille de son équipe en fonction (embauches, ruptures de contrats…).

Un cadre précis — Chacun des acteurs a une vision précise de qui va travailler sur quoi et pour quel montant. Une fois le cadre posé, l’exécution s’en retrouve simplifiée.

Les points faibles

Le suivi de l’exécution — En multipliant le nombre de lignes, cette structure budgétaire multiplie aussi le travail de comparaison entre le budget et le réalisé. De plus, la taille réduite des lignes pousse les managers à challenger des écarts souvent peu significatifs.

Un cadre contraignant — En cas de changement des priorités, il est plus difficile de faire pivoter les équipes. Si une partie du budget du projet 1 doit être alloué au projet 2, de nombreuses lignes sont à modifier (potentiellement 10 !!) et tout le cadre d’exécution est à reconstruire.

1e option de simplification: Cadrer les contributions consolidées par projet

Pour limiter la multiplication des lignes budgétaires, il peut être décidé de ne plus considérer individuellement chaque équipe, mais plutôt de remonter la construction budgétaire au niveau du périmètre (= tribu, chaine, stream…).

Dans notre exemple, nous aurions alors 4 x 2 lignes:

Le processus budgétaire

Cette simplification apparente de la structure budgétaire ne simplifie pas toujours le processus d’élaboration. 2 approches sont souvent observées:

Option 1 — continuer à collecter les besoins à la maille fine des équipes, mais renseigner les outils financiers à une maille périmètre

Option 2 — construire le budget projet par périmètre en “top down” par décision des chefs de projets, sans consulter explicitement les équipes opérationnelles sur les contributions fines

Les points forts

Simplification du suivi — en limitant le nombre de lignes budgétaires, les comparaisons entre le budget et l’exécution s’en trouvent simplifiées. Les équipes de controls de gestion peuvent se concentrer sur les écarts significatifs

Réallocation en cours d’année — Il est de même plus facile de re prioriser et de modifier les allocations budgétaire en cours d’année. On peut adapter localement l’exécution des équipes sans modifier les lignes budgétaires. Seules les modifications des budgets projets eux-mêmes ou les modifications entre périmètres nécessiteront une revue budgétaire.

Les points faibles

Des contributions flous — En remontant la maille budgétaire d’un cran, les responsables d’équipes perdent la capacité à voir simplement les contributions que l’on attend d’eux. Les contributions fines peuvent être enregistrées dans un autre outil. Des problématiques importantes de synchronisation entre la vision budgétaire opérationnelle et la vision officielle apparaissent alors. La DSI gère alors dans les faits 2 budgets en parallèle.

La lourdeur du processus d’élaboration — Quelque soit l’option retenue, les allers retours nécessaires entre la vision équipe et la vision périmètre par projet créent une vraie complexité. Il est ainsi souvent nécessaire de refaire l’exercice de collecte plusieurs fois en fonction des nouvelles consignes budgétaires. Et en cas d’arbitrage sur un projet, il est relativement difficile de voir sur quelles équipes cet arbitrage s’applique.

2e option de simplification: Cadrer uniquement les projets

Un autre axe de simplification est possible. Pour les structures plus petites, et avec peu de projets à contributions multiples, il est possible d’uniquement construire son budget à la maille projet. On considère alors que le détail de qui va travailler sur chaque projet n’est pas nécessaire lors de l’élaboration budgétaire. C’est lors de l’exécution budgétaire que les équipes viendront piocher dans les poches budgétaires au fur et à mesure de l’année.

NB: cette approche fonctionne de manière très similaire si, au lieu de la notion de projet, on retient la notion de produit. Le processus budgétaire, les points forts et les points d’amélioration restent identiques.

Le processus budgétaire

Les responsables de projets ont dans cette situation un rôle structurant. Lors de chaque période budgétaire, en fonction des priorités de la direction, les chefs de projet estiment leurs besoins pour l’année suivante et se voient confier des enveloppes budgétaires. Ils deviennent ainsi les garants de la bonne consommation budgétaire. A chaque fois qu’une équipe doit contribuer sur leur projet, ils leur ouvrent une ligne de dépense dédiée. Et ils s’assurent ensuite que l’équipe n’a pas plus dépensé que demandé.

Les points forts

Simplification de suivi — En concentrant l’essentiel du suivi sur la maille projet, le suivi de l’exécution s’en trouve simplifié. Il devient très simple d’obtenir un statut projet par projet de l’avancement, de la consommation budgétaire, des nouvelles estimations des besoins…

Renforcement de la culture projet — Ce mode de fonctionnement permet d’aligner petit à petit l’organisation sur l’axe projet. Les Business Analysts, les développeurs, et les testeurs auront tendance à se regrouper dans des équipes communes pour répondre au mieux aux besoins des chefs de projet..

Les points faibles

Gestion de la capacité des équipes — Avec ce mode de fonctionnement, les responsables d’équipes ne reçoivent plus d’indications précises sur les contributions que l’on attend d’eux. Un risque important de paralysie apparaît : si une équipe avec des compétences rares doit contribuer à plusieurs projets de manière significative, elle peut se retrouver à court de ressource. En ne précisant pas à l’avance les contributions attendues, les chefs de projets ne permettent pas au responsable d’équipe de recruter et former à temps davantage de personnes.
Dans l’autre sens, une équipe peut se retrouver sans projet et donc dépenser son énergie sur des activités secondaires. Les équipes auront donc souvent un temps de retard pour adapter leur capacité à la demande des métiers.

Un arbitrage complexe des priorités — Avec sa vision centrée sur son projet, le chef de projet peut perdre de vue les objectifs plus globaux de l’entreprise. Cet effet est particulièrement visible quand deux projets entrent en concurrence pour obtenir les contributions limitées d’une équipe. Des processus d’arbitrage et de priorisation très robustes sont alors nécessaires pour éviter les conflits entre projets, d’autant plus si les projets répondent aux besoins de 2 métiers différents, difficilement arbitrables.

3e option de simplification: Cadrer uniquement la capacité des périmètres

La 3e option de simplification est la plus ambitieuse et la plus impactante. Elle part du principe qu’il est impossible de savoir 12 mois à l’avance quelles seront les demandes et les besoins des business. Donner un cadre budgétaire par périmètre (= tribu, chaîne ou stream…) suffit. On compte ensuite sur les responsables de chacun des périmètres, ainsi que les responsables projets pour se mettre d’accord en continu sur les priorités et favoriser l’exécution la plus pertinente.

On parle alors de pilotage capacitaire: les activités sont ajustées et priorisées pour rentrer dans la capacité fixée du périmètre. Dans les approches précédentes, c’était la capacité des équipes (ou des périmètres) qui était adaptée pour correspondre aux activités souhaitées. Ce changement de paradigme pousse à repenser toute l’articulation entre les équipes métiers, la finance et l’IT. Dans ce nouveau cadre, les principes agiles s’appliquent plus naturellement à l’ensemble de l’organisation. Nous constatons cependant que ce mode de fonctionnement reste trop rare, compte tenu des gains d’efficacité qu’il permet.

Le processus budgétaire

Relativement simple, le processus budgétaire a pour unique objectif de définir la capacité des différents périmètres. L’approche la plus simple est de reprendre la capacité de l’année précédente, d’évaluer les priorités de développement pour l’année à venir et d’adapter les poches budgétaires en conséquence. Pour rendre l’exercice de priorisation plus concret, les entreprises adoptent souvent la méthode des Objectives and Key Results (cf article précédent).

Les points forts

Concentration sur la valeur — en retirant l’axe projet, ce mode de fonctionnement pousse à se concentrer sur les résultats plutôt que sur l’avancement des projets. Les différents acteurs considèrent régulièrement l’ensemble des demandes d’exécution du périmètre (= le backlog) et repriorisent l’exécution en conséquence.
Terminer un jalon projet ne fait plus de sens, la priorité est maintenant d’identifier la fonctionnalité supplémentaire qui apportera le plus de valeur aux métiers et aux utilisateurs.

Décentralisation du pilotage — chaque périmètre devient donc responsable de l’exécution de ses activités. Il n’y a plus d’entité centrale ou de grands chefs à plume qui unilatéralement décident depuis tout en haut de l’exécution tout en bas. La décentralisation du pilotage permet de s’assurer que les décisions sont prises au bon moment, au plus proche du terrain et avec l’ensemble des parties prenantes.

Simplicité pour adapter les budgets — il est très simple de faire varier le budget des différents périmètres. Pour une diminution, il n’est en effet plus nécessaire de décliner précisément quels projets ou quelles équipes devront réduire leur ambition ou se séparer d’une partie de leurs effectifs. Le périmètre concerné adapte naturellement son dispositif pour rentrer dans les nouvelles consignes budgétaire. Les mécanismes de priorisation permettront ensuite de se concentrer sur la sous partie des activités les plus importantes.

Les points faibles

Gestion des projets transverses — Par construction, les grands projets et programmes transverses (qui touchent plusieurs périmètres) n’ont plus de budget attribué. Ils doivent donc réussir à convaincre chacun des périmètres pour prioriser leur sujet et ainsi obtenir une capacité d’exécution. Cela peut devenir particulièrement problématique lorsque les développements des différents périmètres présentent des interdépendances. Des mécanisme dédiés tels que Scale Agile Framework (SAFe), sont lors souvent nécessaires (cf article précédent).

Importance de la gouvernance — tout le succès du budget capacitaire repose sur la collaboration des acteurs sur chacun des périmètres. Sans vision commune et sans transparence entre les acteurs, ce cadre ouvert et cette décentralisation peuvent paralyser la structure. Il est donc indispensable d’en faire un projet d’entreprise et de donner des outils avancés de pilotage et de reporting à chacun des périmètres.

Conclusion

Via un exemple simplifié, on comprend vite que la structure d’un budget est loin d’être une question anodine. Elle influence directement l’ensemble des mécanismes de pilotage d’une organisation, les relations entre les différentes parties prenantes et donc plus largement sa culture.

Les 4 catégories proposées sont elles-mêmes des visions simplifiées. Certaines entreprises peuvent mettre en place 2 processus budgétaires l’un à la suite de l’autre pour limiter les effets négatifs, ou adopter des démarches différenciées en fonction du type de budget (Change vs Run, Moyens Humains vs Moyens Techniques, Holding vs International…).

Un CIO ne peut plus se contenter de challenger le processus budgétaire sans repenser plus structurellement la structure de son budget. Les difficultés de construction d’un budget, de pilotage et de priorisation ne sont jamais des fatalités. Le CIO doit devenir proactif et adapter sa structure budgétaire et le processus d’élaboration associé pour construire une organisation capable de répondre aux enjeux de demain.

=== Chaque semaine, je partage les meilleurs passages de mes lectures dans une newsletter. Venez me retrouver ici: https://readwise.io/@bfabien ===