Les conséquences de la gestion
du SI en centre de coûts

Le pilotage comptable du SI entraine du désinvestissement sur le fond technique et les hommes. Ce désinvestissement crée une situation incompatible avec les projets de digitalisation. Cela se traduit par des surcoûts très importants et surtout, des délais qui hypothèquent les objectifs business.

Gérer les conséquences du pilotage comptable

Les coûts informatiques des compagnies sont élevés mais, pour les grandes compagnies, restent une part assez faible du coût total – autour de 2 à 4%. Ils peuvent être à mon sens très fortement réduits, sans doute d’un facteur trois à dix, dans le cadre d’une transformation globale de l’IT. Néanmoins, cela ne changerait pas la face du monde en termes de compétitivité de l’entreprise.

L’importance de la contribution IT à la création de valeur

Le problème réel me parait plutôt être la contribution IT à la création de valeur avec un fort facteur multiplicatif par rapport aux enjeux coûts. L’ensemble des innovations métiers repose en grande partie sur la qualité de l’IT et sa réactivité. C’est là que le bât blesse.

Je décris maintenant de façon simplifiée et un peu caricaturale le phénomène et sa dynamique. Bien entendu, il s’agit du cumul des problèmes et comportements que je constate. Cela n’entend pas dire que la situation est homogène et universelle. Néanmoins, vous devriez retrouver des éléments qui vous parlent.

Les budgets sont généralement réduits à marche forcée, comme je le constate dans les compagnies, et ils appellent de futurs surcoûts. Ces surcoûts sont le symptôme de la mauvaise qualité d’organisation et technologique issus du sous-investissement sur l’IT et de la gestion comptable et non économique.

Le cercle vicieux de la réduction de budget

• je contrains des réductions budgétaires informatiques à court terme et brutales.
• je les obtiens par une baisse du service et une réduction des investissements humains et techniques. Je suis obligé de cibler particulièrement les investissements de long terme nécessaires à la qualité du système et de l’organisation, mais peu impactant directement sur les métiers et comptablement difficiles à justifier ; c’est l’origine de ce qu’il est convenu de nommer « la dette applicative », écart entre les coûts actuels et les coûts théoriques atteignables à niveau de service équivalent.
• cela rend mon système moins adaptable et moins maintenable. Je dois faire du « quick & dirty ». Cela diminue sa contribution à la valeur créée, et au « time to market ». Cela augmente mes coûts dans le temps ;
• des coûts « cachés » ont par ailleurs été générés au sein des métiers (crypto-informatique dans les métiers sur des outils Bureautiques par manque de fonctionnalités, baisse de productivité, baisse de fiabilité nécessitant de nouveaux contrôles métier, voire ruptures de service) ;
• quand on constate finalement cette augmentation différée des coûts IT, on réclame de nouvelles réductions budgétaires qui vont amplifier le phénomène.

Je passe donc mon temps à « pousser le tas de sable » qui ne cesse de grossir année après année. Cela explique le niveau des coûts informatiques atteint par les compagnies et le facteur de réduction potentiel. Cela explique aussi qu’un THELEM, ayant remis à plat son système, gère avec moins de 15M€ par an, un excellent niveau de service et une grande réactivité, ce qui nécessite 100 ou 150 M€ tous les ans dans d’autres structures avec une réactivité bien moindre.

L’espérance de vie des DSI

Généralement, les effets du cercle vicieux deviennent sensibles dans les deux ans. Si la culture d’entreprise le permet, le DSI est remercié généralement au bout de deux tours, donc, dans les trois à quatre ans. C’est en ligne avec les estimations de l’espérance de vie des DSI du CIGREF.

En effet, non content de la baisse de la qualité de service, il laisse les coûts dériver continûment. Le seul motif rationnel à mon sens pour virer le DSI à ce stade : sauvegarder sa santé mentale et éviter le burn-out après trois ans à ce régime.

Dans ces conditions, tout projet d’ampleur devient difficilement maîtrisable en termes de coûts, délais et qualité.

Une situation de terrain dégradée par la gestion comptable

• mes moyens humains internes ont été sous-dimensionnés, déqualifiés et souvent démotivés ;
• cela a accentué la rigidité du corps social IT et réduit le dialogue social ;
• la confiance entre les métiers et l’informatique est réduite comme peau de chagrin et prépare les futurs tensions, voire conflits ;
• l’existant est une usine à gaz difficilement maintenable et rigide, mal connue ;
• cela me contraint à faire appel massivement à de la prestation externe en régie pour gagner en réactivité face à la rigidité et aux limites de mes équipes ; mais, cela augmente d’autant mes coûts ;
• il m’est très compliqué de mettre en place de véritables centres de services du fait de la faible industrialisation et urbanisation du système ;
• mon parc applicatif est un échantillon quasiment exhaustif de toutes les technologies venues s’empiler au fil des ans. Je n’ai pas eu les moyens de le rationaliser car le ROI n’est pas aisément chiffrable dans une logique comptable et tous les projets techniques « purs » ont été arbitrés. J’essaie néanmoins de le faire en douce en saupoudrant ces projets techniques sur les projets métiers, quitte à avoir des dérives importantes.

Il est courant de rencontrer des portefeuilles applicatifs de plusieurs milliers d’unités dans l’assurance. Je vous laisse imaginer la taille de l’équipe nécessaire pour gérer cela et la réactivité aux demandes.

Au mieux, la croissance de la charge de gestion d’un objet complexe en fonction du nombre d’éléments intégrés N peut être évalué en NxLOG(N), au pire comme N² mais, j’ai vu, une seule fois, un N!. Cela fixe une idée de l’évolution des coûts avec l’épaisseur du « mille-feuilles ».

La tendance consistant à faire passer « en douce » les projets de mises à niveau techniques et de « nettoyage » de l’IT explique en grande partie les surcoûts invraisemblables des projets An 2000 et Euros dans les banques. Les projets S2 pilier 2 peuvent également être l’occasion d’embarquer ces « crypto-projets », notamment en termes de fiabilisation des données, de mise à plat des référentiels, de rationalisation des bases et du parc applicatif, etc. J’allais naturellement oublier le nec plus ultra : l’intégration d’un progiciel cœur métier comme grande lessiveuse. C’est un sujet très intéressant sur lequel j’aurai l’occasion de revenir par ailleurs.

Origine importante des surcoûts

Quand arrive le projet « Digital », je ne suis pas prêt, ni en termes technologiques, ni même et surtout en termes d’équipe au sens large (utilisateurs, MOA, MOE). Je vais devoir nettoyer l’infrastructure et construire les conditions de réussite, souvent sans le dire, en me servant des moyens prévus pour le projet. Les dérives seront constatées sur les délais, les coûts et la qualité. Fatalitas !

Il faut rechercher là une origine importante des surcoûts, d’un facteur trois à plus de dix, des grands projets technologiques. Nous sommes bien sur des projets dont l’unité de compte est au minium le M€, mais généralement la dizaine de M€. Le sujet des projets de transformation fait l’objet d’une autre note car les causes et phénomènes détaillés sont un peu plus complexes et méritent une analyse plus large.

Il est certain qu’un acteur partant d’une page blanche possède un avantage non négligeable dans ces conditions en termes de « time to market ». La gestion de l’IT n’est donc pas LA cause mais peut être un amplificateur significatif des risques d’Uberisation du fait du manque de réactivité. Les mois des start-ups ou des IT bien maintenus se transforment en années dans les IT décrits.

Certains disent que ce ne sont pas les plus gros qui mangeront les plus petits, mais les plus rapides qui mangeront les plus lents.