Parmi les questions les plus pressantes que les PDG posent à leur DSI, la palme revient sans doute à celle-ci : « Si vous me dites que l'informatique est un investissement, pourquoi les coûts augmentent-ils toujours ? »

Lorsqu'on leur demande de défendre les investissements informatiques, la plupart des DSI ont du mal à dormir. Mais c'est une question à laquelle tous les DSI doivent s'attendre, étant donné que les dépenses informatiques peuvent représenter de 1 % à plus de 50 % du chiffre d'affaires total d'une entreprise. Pour la plupart des départements IT, il est très difficile d'y répondre, car les systèmes qu'ils développent ne sont pas utilisés par l'informatique, mais par d'autres départements pour augmenter leurs ventes, réduire leurs dépenses ou être plus compétitifs sur le marché. La réponse habituelle d'un responsable informatique à cette question est une déclaration générale sur la manière dont l'informatique a mis en oeuvre des projets dans l'ensemble de l'entreprise qui ont permis d'atteindre les objectifs stratégiques de celle-ci. Nous disposons rarement de données empiriques pour étayer nos affirmations. Que doit donc faire le DSI ?

Considérer la DSI en tant qu'entreprise

Il y a deux façons d'aborder cette question. La première consiste à passer d'un environnement sans facturation, dans lequel l'informatique absorbe tous les coûts de développement, à un environnement avec facturation, dans lequel tous les coûts IT sont attribués aux départements utilisateurs en fonction de l'utilisation qu'ils font des ressources. Dans ce cas, l'informatique fonctionne comme un département à coût zéro et il n'y a pas de problème de budget annuel. Tout ce que l'IT a à faire, c'est de dire aux services utilisateurs combien ils doivent budgétiser pour l'informatique.

Mais cette approche présente des inconvénients majeurs, qui dépassent de loin sa facilité d'utilisation pour la DSI. Tout d'abord, ce processus tend à placer la feuille de route numérique entre les mains des différents départements ou centres de profit plutôt que de considérer l'informatique et la transformation digitale comme une nécessité pour l'ensemble de l'entreprise. Le développement de systèmes d'intelligence artificielle en est un exemple. Les ramifications de ce type de système affectent tous les départements.

Deuxièmement, avec un système de facturation, les services informatiques envoient à chaque département une facture mensuelle facturant leur P&L pour une série de services, y compris les coûts de développement, les coûts d'utilisation de l'infrastructure informatique et les redoutables frais généraux. Cette facture représente un énorme défi pour l'IT, surtout lorsqu'elle est plus élevée que les estimations budgétaires, car il faut maintenir des relations cordiales avec les métiers.

Pire encore, le passage à une approche de facturation ou de rétro-facturation traite le département IT comme une entreprise - un système qui peut sembler bon à première vue, mais qui signifie que le département utilisateur peut commencer à se tourner vers des organisations informatiques externes pour développer des systèmes informatiques parallèles, qui sont vendus comme une alternative moins coûteuse. Ces systèmes ne peuvent que compliquer la maintenance des systèmes internes et éloigner l'entreprise de sa feuille de route digitale.

Trouver les bons leviers de valorisation 

Une seconde et meilleure façon d'aborder le problème de la valeur des technologies de l'information consiste à mesurer l'efficacité des opérations IT. Pourquoi l'informatique devrait-elle être le seul département à échapper à la surveillance de l'entreprise ? Les équipes chargées de la publicité sont régulièrement évaluées pour savoir si elles augmentent les ventes de l'entreprise. La direction des ressources humaines est constamment interrogée sur la manière dont son échelle salariale se compare à celle du secteur. La fabrication est toujours remise en question en ce qui concerne ses coûts et l'existence de méthodes et de sites de production alternatifs. Le marketing doit assurer à la direction générale que le positionnement de sa marque est le meilleur pour l'entreprise.

La seule façon de mesurer les technologies de l'information est d'exiger que tous les projets de systèmes nouveaux ou de modifications à grande échelle soient analysés après leur achèvement, afin de vérifier que les objectifs ont été atteints et que le retour sur investissement a été prouvé. Dans mon livre « Les 9 secrets et demi d'une grande organisation informatique », le demi-secret est l'audit post-implémentation. Je l'ai qualifié de demi-secret parce que peu d'entreprises le font. Il devrait pourtant être traité comme un secret à part entière, car il garantit un département beaucoup plus efficace et performant. Mais ce n'est généralement pas le cas, pour un certain nombre de raisons.

Tout d'abord, la réalisation d'un audit post-implémentation nécessite une quantité importante d'analyses très détaillées qui peuvent s'étaler sur plusieurs années. La simple collecte des données peut prendre beaucoup de temps, d'autant plus qu'une grande partie des membres de l'équipe projet est amené aussi à changer d'emploi ou même d'entreprise depuis son achèvement. Ensuite, cette analyse'est effectuée au moins un an après la mise en service du système, car aucun système n'est pleinement fonctionnel dès le premier jour. Il est parfois difficile de convaincre la DSI et les utilisateurs qu'il vaut la peine de consacrer du temps à l'analyse d'un système achevé, parce qu'il y a des projets plus importants à mener à bien.

En outre, le département utilisateur n'est souvent pas intéressé par la démonstration du retour sur investissement, et ce pour plusieurs raisons. Il a peut-être gonflé le ROI initial pour attirer l'attention du comité de pilotage IT. Une analyse approfondie peut révéler cette pratique. En outre, le retour sur investissement peut avoir comporté des réductions d'effectifs significatives qui ont été utilisées pour générer une meilleure rentabilité. Le département peut souhaiter oublier ces mouvements une fois le projet achevé. Bien entendu, la faute ne revient pas toujours aux utilisateurs. Le service IT peut également ne pas souhaiter la réalisation d'un tel audit, parce qu'il a peut-être sous-estimé le coût ou la date d'achèvement du projet dans l'estimation initiale.

La méthode recommandée pour réaliser cet audit consiste à en retirer la responsabilité au département utilisateur et à la DSI. Une organisation indépendante, de préférence sous les auspices de la direction financière de l'entreprise, devrait effectuer l'audit post-implémentation. Cet acteur devrait avoir été impliqué au départ dans l'élaboration du retour sur investissement du projet et être le mieux placé pour garantir l'objectivité du résultat. Si l'on procède ainsi, le département utilisateur sera tenu de respecter son engagement en matière de retour sur investissement, l'informatique sera tenue de respecter ses objectifs de performance et le DSI pourra répondre à la question posée par le PDG sur les investissements informatiques en disant, par exemple, « Nous avons mis en oeuvre 17 projets cette année qui ont permis d'augmenter les ventes de 35 % et de réduire les dépenses de 14 %. » Ne serait-ce pas là une excellente conversation à avoir, non seulement avec le PDG, mais aussi avec l'ensemble de l'entreprise ?