Tribune de Guy Boizard, consultant de Conix Consulting, membre fondateur de Praxeme Institute. Un des objectifs de l’association est d’aider les DSI à évaluer la valeur de leur système d’information. Guy Boizard propose une approche par les fonctions.

Le système d’information est beaucoup trop riche en fonctionnalités non rentables : c’est le reproche majeur qui ressort dans une enquête interne récemment menée dans un très grand groupe bancaire.

Le même constat peut être établi dans nombre d’entreprises, mais comment y remédier ? La mesure des coûts des fonctionnalités reste embryonnaire, et surtout, l’analyse de la valeur des fonctions est largement méconnue. Pourtant, la fonction est certainement l’élément le plus apte à établir le rapport coût/bénéfice du S.I., et par conséquent à prendre les meilleures décisions d’amélioration de celui-ci.

Toutefois, un préalable indispensable consiste à identifier les fonctions véritablement utiles.

Qu’est-ce donc qu’une fonction ?

Nous avons tous l’impression que nos systèmes d’information nous offrent des centaines, voire des milliers de fonctions. Une analyse détaillée montre qu’il n’en est rien : lorsqu’on se focalise sur les fonctions qui apportent une véritable valeur ajoutée, on arrive au plus à quelques dizaines, sans que la taille ni l’activité de l’entreprise n’aient d’influence marquante sur ce nombre. Par exemple, les fonctions nécessaires à la gestion des crédits aux particuliers ne dépassent pas la trentaine.

Pour identifier les vraies fonctions, il est utile de rappeler en mémoire nos souvenirs de mathématiques. En pratique, une fonction y = f(x) est définie par la relation des x et des y. Elle matérialise une relation entre une ou plusieurs valeurs en entrée, et une ou plusieurs valeurs en sortie, selon des règles précises. Par exemple, si on me donne la date de naissance d’une personne, je serai capable de calculer son âge actuel; si je veux calculer le montant des mensualités pour rembourser une voiture, il me suffit de connaître le montant emprunté, la durée de l’emprunt, et le taux.

En pratique, pour toute fonction métier je devrais être capable de lister : les données dont elle a besoin en entrée ; les données que l’on attend d’elle en sortie ; et au moins une règle de gestion qui régit le comportement de la fonction, et qui soit « validable » par l’utilisateur.

Autre erreur fréquente : confondre activités et fonctions. On voit souvent des cahiers des charges trop ambigus : par exemple, le progiciel de gestion des RH devra ‘gérer des employés’, dans le meilleur des cas ‘gérer des mutations’. Comme si c’était le progiciel qui décidait d’affecter Madame Bertrand au département Achats ! En réalité, il s’agit tout simplement d’une action effectuée par un utilisateur. Le progiciel, lui, va se contenter d’écrire quelque part dans une base de données le résultat de cette opération. Et pour ce faire, il va tout simplement faire appel à un service technique standard, normalisé depuis longtemps (l’ordre Update du SQL). Et dont le comportement est identique, que l’on mette à jour des affectations ou des stocks !

Pléthore de fonctions

La multiplication des systèmes et des applications est une autre cause de duplication abusive des fonctions : on trouve ainsi un vérificateur d’orthographe dans Word, mais aussi dans Excel… De même, à l’échelle d’une banque, le contrôle de votre numéro de compte bancaire se voit codé dans un grand nombre de composants logiciels.

Ce découpage du SI a une autre conséquence : la nécessité d’échanger des flux de données entre composants. Ces flux sont rarement standardisés, ce qui ajoute à leur prolifération. On trouve ainsi une ribambelle de fonctions du type ‘collecter les mouvements de stocks’ ou encore ‘extraire les règlements en retard pour les envoyer au système de recouvrement ’. Structurer son SI en composants interchangeables est certes fort louable, mais du point de vue de l’utilisateur, il faut bien se rendre à l’évidence : ces flux n’ont aucune valeur ajoutée, et l’idéal serait d’en user le moins possible. Le progiciel intégré marque ici un avantage : il élimine ces coûteux échanges. Plus besoin de superviser des flux, ni de contrôler les données reçues.

La fonction est l’élément de valeur le plus pertinent

De tous les objets manipulés par le SI, la fonction est le plus apte à servir de support à la mesure des coûts.

L’analyse des exigences, qui revient à la mode, se pose en concurrente. Certains de ses promoteurs militent pour le suivi des coûts des exigences. Mais peut-on coter une exigence sans avoir une idée de la solution ? Et tous les éléments de coûts observés peuvent-ils être imputés à une exigence et une seule ? Il est permis d’en douter.

A l’inverse, il est relativement aisé aujourd’hui d’affecter un coût à une fonction, qu’il s’agisse des coûts de développement mais aussi de la maintenance, de l’exploitation, ou de support. Pour les entreprises qui opèrent des systèmes redondants, par exemple dans plusieurs filiales, elle permet de se comparer sur une base plus précise que les benchmarks publics, dont le périmètre n’est pas toujours connu avec exactitude.

Par ailleurs, même si l’analyse de la valeur appliquée à l’informatique reste un exercice subtil, la fonction matérialise le bon niveau de maille pour affecter une valeur attendue du SI : elle permet au moins de se poser les bonnes questions.

Prenons un exemple : les systèmes de pilotage. L’état de l’art actuel fait appel à deux familles de composants logiciels : les ETL qui permettent d’alimenter des entrepôts de données, et les outils de restitution qui permettent à l’utilisateur de naviguer dans ces données. Il est clair que pour les utilisateurs, seuls les seconds ont de la valeur. Les ETL ne sont là que pour éviter d’attaquer directement les bases de données des systèmes opérationnels. Conclusion : il faut donc investir le moins possible dans les ETL. Forts de ce constat, dans une grande entreprise, nous avons mis en place une démarche industrielle et obtenu une baisse substantielle des coûts d’alimentation des bases de données de pilotage.

L’architecte peut vous aider

La première étape consiste à établir une liste standard des fonctions du SI, valable pour l’ensemble de l’Entreprise, et tous les Métiers, toutes les unités et tous les pays où celle-ci est implantée.

Pour cela, il est souhaitable de faire appel à un architecte fonctionnel expérimenté. Sa contribution consistera à identifier les véritables fonctions, leurs variantes, les possibilités de paramétrage. Par exemple, avoir une fonction qui sait calculer l’âge actuel d’une personne c’est bien, mais si on peut en outre lui fournir en paramètre optionnel une date de référence, c’est encore mieux : cela permettra aussi de calculer l’âge qu’elle aura lors des prochaines campagnes marketing.

Au delà de l’analyse de la valeur et du recueil des coûts qui nous préoccupe ici, cette liste aura de multiples usages, dont celui de servir de check-list prête à l’emploi permettant aux maîtrises d’ouvrage de ‘faire leur marché’, et aux maîtrises d’œuvre de savoir ce qu’elles auront à réaliser, ou à prendre sur étagère parmi les solutions déjà disponibles.

D’autres usages encore sont possibles : détecter les redondances fonctionnelles du système d’information, et en déduire les possibilités de mutualisation pour réduire le nombre des ces fonctionnalités non rentables !