En matière de gestion budgétaire, la tentation est grande de céder à la facilité, par exemple en privilégiant une vision annuelle, en ne prenant pas en compte les composantes métiers ou encore en confondant budget d’exploitation et budget de projet. Revue des douze mauvaises pratiques les plus courantes. À éviter…
1. Oublier la stratégie
Le budget n’est pas une fin en soi, mais la conséquence d’un processus de planification stratégique tant pour les activités récurrentes que pour les nouveaux projets. Aussi, fixer arbitrairement un montant du budget informatique indépendamment des objectifs fixés, c’est ignorer, voire renier, la stratégie de l’entreprise et celle de la fonction informatique.
2. Privilégier une vision seulement annuelle
Découlant de la stratégie, forcément à moyen ou long terme, les budgets, qu’ils soient de fonctionnement ou d’investissement, ne peuvent pas être appréhendés sans une vision pluriannuelle.
3. Ne pas calculer les bénéfices
Tout budget doit être en général équilibré avec une colonne de charges et une colonne de produits. Après la stratégie, les gains ou recettes attendus sont les plus importants à considérer car ils permettent bien souvent de justifier les charges ou dépenses pour l’exercice à venir. Ne pas le faire génère inéluctablement une logique de gestion de la fonction informatique en centre de coûts peu pertinente.
4. Reconduire automatiquement les budgets
Bien souvent, le budget informatique de l’année n+1 est identique à celui de l’année n, à quelques modifications près correspondant à l’évolution des coûts unitaires et à la croissance de l’organisation. Cela éclipse largement les aspects stratégiques et économiques, et entraîne bien souvent une cécité managériale sur les vrais enjeux informatiques. D’autres techniques telles que le BBZ (Budget à Base Zéro) existent. En outre, il a été démontré que la reconduction budgétaire avait une forte tendance à diminuer la part des projets par rapport aux activités de fonctionnement (maintenance, exploitation, service, etc.).
5. Ne pas corréler budget informatique et budget métier
Les activités et projets informatiques introduisent des changements dans l’organisation et les processus métiers, et donc modifient le budget et les ressources nécessaires à ces processus. Leurs impacts sont en général de deux natures : revenus supplémentaires, coûts de gestion inférieurs et/ou apports qualitatifs.
Ainsi, une nouvelle application ou un nouveau service va augmenter les coûts au niveau de l’informatique, qu’il s’agisse de coûts des infrastructures, des licences logicielles ou des services associés. Or, cette hausse des coûts est rarement mise en perspective avec les bénéfices apportés au métier. Il n’y a que rarement une vision transversale avec une logique de « vases communicants », ce qui devrait être le propre d’une fonction de support.
6. Amputer le périmètre du budget informatique
Celui-ci est souvent réduit au périmètre de la fonction informatique, ce qui est particulièrement réducteur. En particulier dans les moyennes et grandes structures, le budget du département informatique ne représente qu’une partie de la dépense variant de 20 à 80 % selon les cas. N’avoir qu’une vision partielle est souvent la cause d’une gestion hétérogène avec des logiques de gestion non cohérentes globalement au niveau de l’entreprise.
7. Ne pas tenir compte d’hypothèses d’évolution
Au départ, un budget est par définition prévisionnel. Particulièrement dans le cadre de la fonction informatique, avec l’évolution des technologies, mais aussi des besoins, il se trouve qu’entre le moment où le budget est préparé, plus d’un an à l’avance en moyenne, et le moment où les ressources sont consommées, le cadre peut changer. Ceci peut engendrer des problèmes au niveau du dimensionnement et de l’adéquation des ressources existantes.
8. Confondre budget d’exploitation et budget de projet
La notion « exploitation-projet » distingue les activités récurrentes de l’entreprise de l’ensemble des charges affectées aux projets. C’est une bonne chose. Ce sont à la fois des enjeux (récurrent vs nouveau), des périmètres (informatique vs métier) et des responsabilités (DSI, métiers, voire DG) différents. Ne pas les distinguer peut s’avérer dangereux. De même, les budgets de projet sont dans une vision pluriannuelle forcément liés aux budgets de fonctionnement. Ainsi, un projet doit être corrélé dans le temps à une augmentation du budget de fonctionnement informatique.
9. Confondre budget de fonctionnement et budget d’investissement
La notion « fonctionnement-investissement » est une vision comptable, limitant la part des projets à la partie amortissable. On en exclut les préétudes, la formation, l’installation ou la mise en exploitation, qui sont intégrées de manière comptable dans le budget de fonctionnement. La logique comptable et la logique gestion ne font pas forcément bon ménage.
10. Diminuer arbitrairement le budget
Dans le cas de restriction budgétaire, ce sont souvent les projets qui en font les frais. Or, n’oublions pas que les projets représentent l’avenir. Arrêter les projets, c’est geler son processus de modernisation. Quand il s’agit de réduire les activités de fonctionnement, et donc la qualité du service rendu à l’utilisateur, il faut se poser la question de savoir si l’improductivité générée au sein de l’organisation (coûts cachés) n’est pas bien supérieure aux économies réalisées (coûts visibles). C’est bien souvent le cas.
11. Déresponsabiliser les budgets informatiques
Pour ce qui est des infrastructures et autres services, le DSI est forcément responsable et redevable des dépenses. Pour ce qui est des nouveaux projets, à moins qu’il soit explicitement nommé maître d’ouvrage, ce n’est pas à lui d’en assumer la responsabilité globale, et de défendre ces budgets. On pourrait même étendre cette réflexion aux applications si l’on considère qu’elles sont la propriété des métiers.
12. Utiliser des comparatifs ou benchmarks erronés
Ce sujet sensible amène bien souvent des difficultés et des décisions faussées en l’absence de pratiques rigoureuses et partagées.
Cet article a été écrit par Christophe Legrenzi, PDG du cabinet de conseil Acadys (www.acadys.com).
Les principaux indicateurs à privilégier pour identifier et imputer les coûts
- % d’utilisateurs métiers impliqués dans la définition des modèles de coûts
- Fréquence des revues des modèles d’affectation des coûts
- % des coûts qui sont imputés automatiquement/manuellement
- % des écarts entre les coûts budgétés, prévisionnels et réels
- % des coûts informatiques globaux qui sont affectés conformément aux modèles de coûts agréés
- % des coûts contestés par le métier
- % de factures de services informatiques acceptées/payées par la direction métier
- Coût unitaire, par service, du dépassement de temps
- Satisfaction métier (sondage) du modèle de coûts des services informatiques
Que penser des ratios sectoriels ?
Les indicateurs agrégés sont souvent les plus tentants à aborder, mais aussi de loin les plus dangereux à manipuler sans un œil averti. à part donner des proportions de dépenses informatiques par rapport au chiffre d’affaires ou au budget de fonctionnement, ils n’apportent rien de pertinent.
Néanmoins, si l’on veut les utiliser, il faut absolument s’assurer que les prestations réalisées ainsi que les ressources employées soient comparables. D’autres facteurs comme les effets de taille et l’historique d’informatisation de l’organisation ont un impact significatif sur les résultats. Il faut donc être très vigilant.
Quelle méthode de benchmarking : interne ou externe ?
Si toutefois l’entreprise possède une taille conséquente avec différentes filiales en France ou à l’étranger, le benchmarking interne à l’entreprise est à favoriser. Il peut se faire entre différents sites, entre fonctions et/ou départements. L’avantage principal du benchmarking interne est qu’il permet de maîtriser l’ensemble des phases de la méthode. Le seul risque est que le benchmarking soit réutilisé à des fins de pouvoir, et que la philosophie de vouloir s’améliorer continuellement soit obérée par l’impact négatif et psychologique d’une évaluation.
Le benchmarking externe peut être réalisé avec des entreprises soigneusement sélectionnées et acceptant de jouer le jeu à livre ouvert. Il faut que le choix des sociétés choisies soit équilibré afin que tout le monde soit gagnant dans l’opération. Tous les secteurs peuvent potentiellement être candidats, des domaines privés ou publics. Il faut juste avoir présent à l’esprit qu’il n’existe pas de société de référence, sur tous les domaines de la fonction informatique.
Une alternative consisterait à utiliser les sociétés de services et autres infogérants comme partenaires du benchmarking. Susceptibles d’être candidats à la reprise de votre informatique, ces sociétés sont forcément motivées pour évaluer votre niveau de performance afin d’identifier la valeur ajoutée qu’elles pourraient vous apporter. Toutes ces sociétés possèdent des bases de benchmarking et de niveaux de service plus ou moins étoffées, en fonction de leur propre niveau d’industralisation.