|
Faire évoluer le système d'information
15 décembre 2002
Comme tous les autres actifs de l'entreprise, le
SI doit évoluer : d'abord pour répondre à l'évolution de l'entreprise,
notamment pour outiller la production et la commercialisation de ses nouveaux produits ;
puis pour
se maintenir au niveau de l'état de l'art dans un contexte fortement évolutif
(que l'on pense aux nouveautés apportées par le Web, par les plateaux
téléphoniques, par l'Intranet etc.) ; enfin, pour remplacer les applications
devenues obsolètes en raison de la croissance du coût de leur maintenance.
Le SI existant constitue un "stock", le
stock des produits en cours d'utilisation ; l'évolution du SI sera le "flux" qui modifiera et renouvellera
ce "stock". Pour
définir convenablement le flux, il faut donc s'appuyer sur une bonne
connaissance du "stock". L'élaboration et l'appropriation d'un plan
d'urbanisme, qui permet aux dirigeants et à leurs conseillers (MOAS et
MOAD)
de partager une même représentation de l'état du SI, est donc un préalable
nécessaire à la décision.
Les décisions relatives à l'investissement en matière
de SI, c'est-à-dire aux projets informatiques, peuvent en principe être prises
à tout moment en fonction des urgences ; en pratique, elles sont scandées par
la préparation du budget annuel lors du dernier trimestre de
l'année précédente, puis par la préparation de la révision budgétaire lors
du deuxième trimestre de l'année en cours. Elles obéissent donc, sauf
exception, à un rythme semestriel.
La perspective annuelle est trop courte
pour se représenter l'évolution d'un SI : un enchaînement complexe
d'opérations, reliant divers investissements importants, les études qui les
préparent et les déploiements qui les installent, demande
quelques années. Il est donc nécessaire de situer le budget annuel dans une
perspective de trois à cinq ans, perspective qui sera bien sûr d'autant plus
floue que l'on considérera un futur plus lointain, mais qui devra être
cohérente avec le choix budgétaire de la première année. On peut, pour
désigner cette perspective, utiliser les termes "schéma directeur"
ou mieux "schéma d'évolution", moins autoritaire. Le schéma
d'évolution s'articule au plan d'urbanisme, dont il constitue la partie
"plan d'action".
Le schéma d'évolution ne doit pas être un plan
quinquennal à réaliser tel quel sur la durée de cinq ans. Il fournit une "portée de phares" à réviser et renouveler chaque
année, qui donne de la profondeur à la discussion sur le budget de la
première année. Il permet aussi d'évaluer approximativement les dépenses à
consacrer au SI dans les années qui viennent et les efforts de conception que son
évolution va demander aux MOA, ce qui conduira souvent à réviser les
ambitions en faisant apparaître l'écart qui sépare la velléité, le rêve,
d'une volonté effective et réaliste.
- *
- * *
- Le cadre logique et chronologique ainsi
préparé accueille les projets formulés par les diverses directions. Leur
première formulation est inévitablement désordonnée, même
si l'on a pris le soin d'exprimer les besoins
de façon méthodique. Les besoins, à l'état brut, sont en effet un "tas"
sans ordre où se mélangent l'essentiel et l'accessoire, le
réalisme et le fantasme. Certains services dynamiques, actifs,
proposent des évolutions utiles ; d'autres veulent faire reconnaître leur
importance
et vont pratiquer l'activisme. Certains chefs de service, certains MOAO,
attachent leur amour-propre à des demandes qu'ils défendront bec
et ongles ; d'autres, plus timides ou plus insouciants, seront plus
détachés : mais l'utilité réelle d'une demande n'est pas exactement
proportionnelle à l'éloquence de ses avocats.
Il faut d'ailleurs distinguer la
"demande", explicite, du "besoin" implicite
qu'il faut dégager. Il faut, pour passer de la
demande à l'évaluation du besoin, une méthode rigoureuse. Les "clubs
d'utilisateurs", par exemple, expriment toujours une demande inflationniste
(le simple fait de se trouver rassemblé "donne des idées") qui peut
être manipulée par des services désireux de prendre de
l'importance. S'il est donc indispensable d'écouter la demande, il faut
savoir ensuite trier et élaguer (voir "La maîtrise
d'ouvrage du système d'information et ses utilisateurs").
Le "tas" des projets se présente
d'abord sous
la forme d'une longue liste. Il faut la classer pour réduire
l'éparpillement des projets :
- si le projet A conditionne l'exécution du projet B, il serait absurde de
lancer B alors que l'on a refusé A : il faut donc regrouper ces deux projets,
ou tout au moins présenter B comme une option au sein de A.
- si deux projets sont fortement corrélés (conditions de succès ou
d'échec analogues, utilisation d'outils identiques), il
convient de les regrouper ;
- si plusieurs projets sont en fait les déclinaisons d'un même projet dans des
domaines divers, il faut faire apparaître leur unité en les regroupant,
etc.
Puis il faut évaluer les priorités, selon une
classification qui peut être du type suivant :
- priorité 0 : projet indispensable pour que l'entreprise puisse continuer à
fonctionner (par exemple : application d'une nouvelle réglementation)
- priorité 1 : projet nécessaire (si on ne le réalise pas, l'entreprise va
rencontrer de grandes difficultés)
- priorité 2 : projet utile (il serait dommage, voire stupide, de ne pas le réaliser)
- priorité 3 : projet raisonnable (il serait logique, efficace de réaliser le
projet)
- priorité 4 : projet de confort (ce serait bien, ce serait mieux si l'on
réalisait ce projet).
L'évaluation des priorités n'est jamais facile
: un chef de service impérieux prétendra que tous ses projets sont
indispensables ou nécessaires ; un autre, plus timide, les qualifiera d'utiles
ou de raisonnables. Le MOAD doit user de son bon sens, de sa connaissance des
perspectives du SI pour préparer le classement qui sera présenté au MOAS.
Ce classement s'appuie sur les études
OFR : pour chaque projet non seulement on connaît le besoin auquel il
s'agit de répondre, mais on dispose aussi d'une évaluation approximative du
coût et du délai de réalisation, sachant que l'effort consacré à l'étude
OFR (et donc la précision de celle-ci) est fonction de l'importance que l'on
accorde au projet.
On peut donc présenter au MOAS les projets
classés selon l'ordre de leur priorité, puis de leur coût (ou de leur
rentabilité, si on l'a estimée). Idéalement, on devrait pouvoir classer les
projets de même priorité selon leur rentabilité sur un diagramme à deux axes
: en abscisse, le coût du projet ; en ordonnée, le résultat annuel attendu.
Si les projets sont rangés selon l'ordre des rentabilités, il en résulte une
courbe concave (puisque la rentabilité est le quotient du résultat annuel par
le coût de l'investissement) :
Si le MOAS décide de consacrer au SI le budget
C, il devra en principe retenir les quatre projets représentés à gauche de la
droite bleue (NB : il est rare en fait que l'on puisse présenter les choix sous
une forme aussi simple, mais en fait le classement des projets équivaut bien à
une telle présentation).
Le travail du MOAD s'achève avec la
présentation du classement des projets au MOAS. Il se peut que celui-ci révise
les évaluations de priorité, qu'il décide de "repêcher" un projet
ou d'en "tuer" un autre : c'est son droit et c'est sa fonction, son
arbitrage résultant d'une réflexion stratégique où réside la valeur
ajoutée propre du dirigeant. Il faut que le MOAD sache s'en tenir à son rôle
d'expert, et accepte de n'être parfois pas écouté.
Enfin, le MOAS présente au CSSI les projets de
sa direction, et les soumet à l'arbitrage du directeur général, qui lui-même
peut réviser les classements proposés par les directions.
- *
- * *
- On peut estimer que la méthode que nous
venons de décrire est un peu lourde. Elle est préférable toutefois à une
autre méthode que l'on voit parfois pratiquer :
- une liste de projets qui ne sont ni triés, ni classés par ordre de priorités
;
- un manque de mise en perspective par rapport à l'état actuel du SI et
aux évolutions prévisibles ;
- un arbitrage en fonction des rapports de force entre dirigeants, etc.
|
