5 SI …politique

En tant que chef adjoint du département SI, je découvrais donc que le SI n’est pas qu’une simple affaire technique mais aussi une affaire économique et politique.

Avoir des vues stratégiques, bien fondées, sur le développement du SI ne suffit pas ! Il faut en convaincre toutes les parties prenantes : la Direction de l’entreprise, certes, mais aussi ce qu’il est convenu d’appeler les « métiers » et en tout premier lieu, leurs responsables. Le développement du SI en entreprise n’a de sens que si l’entreprise y voit son intérêt, sur le plan économique, à l’évidence, mais aussi sur les plans organisation et politique interne.

Au premier abord, le plan économique paraît facile à aborder : après tout, comme pour tout projet, on peut chercher le BiKet (Business Case !) d’un projet informatique.

On calcule son coût de réalisation - l’investissement initial -, ses coûts récurrents une fois le projet réalisé, et on compare aux recettes attendues. Si le ROI est au rendez-vous (Return on Investment), on y va…

De fait, progressivement, nous avons été amenés à formaliser la façon des monter les BK selon les types de projets informatiques.

Deux types de projet informatiques ont été pris en compte : les projets applicatifs dits métiers, et les projets dits d’infrastructure.

Les services d’infrastructure sont en fait des services mutualisés pour les applications ; serveurs, stockages mutualisés, réseaux…
Je ne détaillerai pas la façon de calculer les coûts d’investissement et les coûts récurrents d’un projet. Même si ce n’est pas toujours simple, c’est en général connu.

Mais les recettes ? En théorie, ce n’est pas compliqué, et il ne manque pas de bons auteurs pour gloser sur le sujet. On peut représenter la chose sur le schéma comme ceci :.

Pour évaluer les recettes d’une application métier, on va d’abord prendre en compte les gains (éventuels) sur l’exploitation de l’application. Si, si ça arrive, car les vieux bouzins finissent par coûter très cher et leur remplacement peut faire gagner de l’argent.

Mais le poste principal de recette réside en générale dans ce qu’il est convenu d’appeler les « gains métier ». J’en reparlerai.

Pour tout ce qui sert de support mutualisé aux applications métier, c’est un peu pareil.

L’exploitation d’une nouvelle infrastructure en remplacement d’une ancienne peut être très rentable, du fait des progrès continus de l’informatique qui conduisent à des matériels et des services plus performants pour des coûts inférieurs. Là aussi, ce sont surtout les gains pour les services supportés qui vont en général être les plus importants : les coûts récurrents des applications baissent. Mais il peut y avoir aussi des gains métier, plus difficiles à appréhender, du fait d’une meilleure disponibilité et d’une meilleure efficacité des applications.

Tout ça semble simple. C’est quand on commence à essayer de calculer tout ça que ça se complique.

D’abord, il y des applications qui sont difficiles à classer, et à vrai dire elles sont un peu intermédiaires entre les deux types précédents. Ce sont les applications qui sont transverses à l’entreprise, qui servent souvent aux applications, mais qui sont aussi tournées vers l’utilisateur dit final. Exemples : la messagerie d’entreprise, le poste de travail (quelle qu’en soit la forme : PC, tablette, smartphone), les RSE (réseaux sociaux d’entreprise). Et là, commencent les problèmes : si les gains d’exploitation pour une renouvellement d’application sont évaluables, c’est un acte de foi que d’évaluer les gains de productivité pour l’entreprise d’un RSE, ou d’une amélioration des postes de travail. Quelques minutes par jour gagnées, même multiplié par le nombre de salariés, ne convainc généralement pas les financiers. La disponibilité de salariés équipés de postes mobiles, tablettes ou smartphones, idem en général. Quant au RSE, les gains de créativité ou nés d’un travail plus transverse …

Mais en fait les gains métier, ne sont pas si faciles à évaluer non plus. Et le ROI sujet à caution. D’abord, il convient de rappeler ce qui devrait être une évidence : il n’y a pas de projet informatique métier. Il y a des projets métier avec une composante informatique et obligatoirement une composante métier : en général les processus métier sont impactés, et il y a des coûts de transition à prendre en compte. Insertion métier est un mot faible à cet égard (formations, reclassements, réorganisations…).

Et pour un projet métier identifié, il n’y a pas qu’une solution informatique : avec différents curseurs comme le degré d’automatisation, la facilité d’utilisation…

Le BiKet ne peut être que global au niveau du projet métier et les différentes alternatives se doivent d’être étudiées dans ce contexte global.

Cela signifie aussi que la maîtrise d’ouvrage d’un projet informatique métier ne peut être que subordonnée à la maîtrise d’ouvrage du projet métier : le projet informatique est un lot, qui peut très important, du projet métier. Faute d’avoir compris cela, combien de luttes intestines à l’entreprise ont lieu entre « l’informatique » et « le métier ».

Encore faut-il que le « métier », souvent très éloigné de la sphère informatique soit structurée pour décider et conduire ces projets à composante informatique.

Une des choses dont je suis fier, lors de mon passage à RTE, a été l’institution de programmes métiers, présidés par des décideurs du métier ; les commanditaires. Ces programmes géraient les projets, mais suivaient aussi l’ensemble des dépenses induites par l’utilisation de l’informatique. Ils avaient dont en principe tous les éléments pour optimiser les dépenses informatiques au sein du budget global métier.

Tout irait pour le mieux si cette logique n’était pas régulièrement battue en brèche par les financiers. Dans un contexte économique tendu, ceux-ci n’acceptent pas en général la hausse continue des dépenses informatiques … pourtant quasi inéluctables, du fait de la substitution croissante de la puissance informatique au travail surtout tertiaire. A production équivalente, la part du travail baisse dans le produit final, ce qui ne se voit que sur la durée et à condition de raisonner à production équivalente.

Nos financiers, donc, souvent court-termistes, imposent des contraintes budgétaires sur l’informatique prise dans son ensemble. Croissance zéro, voire baisse importante.

De fait, les coûts unitaires de l’informatique baissent régulièrement (5 à 10%) ce qui permet des développement informatiques même avec une croissance zéro des budgets.

Malheureusement, la pression est souvent beaucoup plus forte, à tels que l’on assiste à des paradoxes : le métier a le budget pour faire le projet métier, mais la contrainte sur les dépenses SI fait qu’il est impossible de le mener ! Souvent d’ailleurs le métier se débrouille pour que des dépenses SI ne soient pas comptabilisées en SI. De ce point de vue le développement (inéluctable)  du BAAS (ni Syrien, ni Irakien : Business As A Service) est une aubaine car il masque les dépenses informatiques sous-jacentes qui sont réalisées par le fournisseur du service.

Mais ça j’en reparlerai certainement dans la suite de ma chronique.