Rentabilité des projets informatiques

dossier :
Conduite de projet
Rentabilité des projets informatiques
beaucoup de domaines, plus on
pratique l’analyse de rentabilité,
mieux on la maîtrise.
1. Nature de la rentabilité
Analyser la rentabilité, c’est avant
tout rapporter des dépenses à des
gains et ce sous la forme la plus
naturelle possible, c’est-à-dire en
termes de flux de trésorerie nette,
donc d’impact sur le compte d’exploitation de l’entreprise.
Catherine Leloup
Ingénieur Conseil
• La revue n° 80 - Septembre 2005
On observe depuis quelques années,
une volonté de mieux maîtriser la rentabilité des projets,tant lors de la décision d’investissement que pendant la
conduite du projet ou à l’issue de sa
réalisation, puisqu’en 2005, 60 % des
entreprises effectuent une étude de
rentabilité en préalable au lancement
d’un projet, … même si seulement
25 % d’entre elles évaluent la rentabilité obtenue à l’issue de la réalisation
du projet.
4
Ce qui semble révéler une maturité
plus grande et une réelle volonté de
comprendre l’impact de l’informatique sur la performance de l’entreprise et la valorisation des investissements effectués. La variété sans
cesse croissante des applications
informatiques est sans doute un
point positif pour développer ces
pratiques. En effet, les projets visant
l’aide à la décision, l’échange ou le
partage d’informations, la capitalisation de savoir ou de savoir-faire sont,
par rapport aux projets plus traditionnels d’automatisation, plus intimement liés au fonctionnement de
l’entreprise ainsi qu’aux moyens mis
en œuvre pour réaliser la stratégie
de l’entreprise. Et comme dans
Le terme projet concerne toute évolution du système d’information requérant une décision d’investissement
informatique. Y compris en interne à
une DSI. Il peut s’agir aussi bien :
• d’une application nouvelle quelle
qu’en soit la nature : gestion de
connaissances, workflow, application métier, application interne à
la DSI comme la gestion d’un
centre d’appels, etc. ;
• de la rationalisation d’un existant : migration de plate-forme
matérielle ou logicielle, refonte
logicielle, mutualisation de ressources logicielles ou applicatives , etc. ;
• de projets internes DSI mais
structurants pour l’entreprise :
gestion d’annuaire par exemple,
gestion centralisée des habilitations, etc. ;
• de projets « partenaires » : extranet, EDI, etc.
La rentabilité s’évalue en comparant
des situations possibles futures et en
les analysant au niveau des coûts
générés et des bénéfices escomptés.
Le calcul des coûts n’est pas indépendant de l’infrastructure informatique existante – par exemple, selon
qu’il faut acquérir des matériels et
logiciels ou qu’il suffit d’obtenir une
extension de licences logicielles – ni
des applications opérationnelles –
en particulier lorsqu’il s’agit de les
intégrer ou de les interfacer avec le
futur système. Au niveau des bénéfices attendus également, l’environnement de l’entreprise joue :
méthodes de travail, motivation des
personnels, gestion du changement,
évolution requise des compétences
notamment. Deux projets identiques n’auront pas le même impact
dans deux entreprises distinctes.
2. La démarche d’analyse
de rentabilité
2.1. Les objectifs
Les objectifs de l’analyse de la rentabilité d’un projet visent à comparer les
coûts supportés et les avantages
apportés. Il y a toujours deux alternatives possibles au moins : faire le projet
ou non. Néanmoins, dans l’option de
réaliser le projet, il y a souvent de multiples alternatives reposant sur des
scenarii de solutions ou de mise en
œuvre, qui doivent toutes être étudiées de façon à permettre le choix de
la meilleure solution possible. C’est
donc en comparant des situations
futures entre elles que l’on peut
mesurer la rentabilité attendue, voire
comparer éventuellement les projets
entre eux. En outre, l’étude de rentabilité permet de définir une feuille de
route du projet (délais, conditions,
risques, etc.) et donc de piloter sa réalisation en toute connaissance de
cause.
2.2. Le périmètre concerné
Il résulte des multiples dimensions
d’un projet ou d’un système existant, comme indiqué ci-après :
(voir figure 1)
Conduite de projet dossier
Niveau de maturité
Évolution
Environnement
informatique
existant
Processus
Projet /
Système informatique
Organisation :
– Ressources
– Activités
Compétences
Efficacité
Réactivité
Valorisation
Conduite du changement
Figure 1 – Les dimensions d’un projet ou système informatique.
En effet, la rentabilité d’un projet
dépend très largement de son
contexte d’utilisation, dans la mesure
où les bénéfices apportés se situent
le plus souvent hors du périmètre de
la DSI. Par exemple, mettre en place
un intranet d’entreprise n’a potentiellement aucun gain possible au
niveau de la DSI, sauf pour la part
marginale relative à ses propres
employés, en tant que personnel de
l’entreprise.
Évaluer la rentabilité passe donc au
préalable par la définition des évolutions de chacune des dimensions, en
particulier :
• Processus : la dématérialisation
d’informations induit des bouleversements des processus existants. Ainsi, la dématérialisation
des titres a totalement modifié
le travail des back-offices bancaires, tout comme plus récemment le traitement de l’image
chèque électronique. La mise en
œuvre d’un annuaire centralisé
va rejaillir de manière significative
sur les processus de gestion des
utilisateurs et des autorisations
d’accès par une DSI.
• Environnement existant : selon
l’ouverture du système d’information et des applications existantes
et les besoins d’interface ou d’in-
tégration avec un nouveau projet
informatique, l’impact sur l’existant peut être quasi-nul – lorsqu’il
s’agit d’une simple juxtaposition
d’application – ou au contraire
très profond et aller jusqu’à la suppression de toute ou partie d’applications existantes. Ainsi, la mise
en œuvre d’un CRM – Gestion de
la relation client – rend souvent
caduques des applications préexistantes comme la gestion des
portefeuilles commerciaux ou des
réclamations clientèle.
• Compétences : la mise en œuvre
d’un projet s’accompagne souvent d’un accroissement des
compétences, facteur clé de la
rentabilité. Ainsi, lors de la mise
en œuvre d’une gestion de catalogue de produits industriels, les
rédacteurs qui préalablement
raisonnaient « forme du document final » vont devoir réfléchir
en termes de gestion de contenu ;
ainsi, au lieu d’écrire « 12 A » en
gras, car c’est une caractéristique
technique, ils devront penser
« insérer une caractéristique
technique, de type ampérage »
puisque l’application se chargera
d’importer la bonne donnée au
moment de la publication du
catalogue en lui appliquant la
forme définie par la charte graphique, fonction du média de
communication – papier, internet, wap, etc.
• Organisation : sauf en cas d’automatisation pure, il est rare
que l’organisation en place
avant le projet perdure en l’état.
Lorsqu’il s’agit de nouvelles
technologies, en tirer la quintessence – et donc la rentabilité –
suppose de revoir les méthodes
de travail et les ressources. Ne
serait-ce que parce que certaines tâches disparaissent,
d’autres évoluent, d’autres
encore sont ajoutées. L’exemple
de la gestion électronique de
documents est assez flagrant :
les charges de recherche d’information sont réduites à zéro
ou à peu près, alors que celles
d’entrée des documents –
numérisation, indexation – sont
sensiblement alourdies et la
rentabilité est alors directement
fonction du taux d’utilisation
des documents concernés.
Il faut donc avoir défini, au moins à
grande maille, comment le système
va fonctionner avant de réaliser
l’étude de rentabilité. C’est en tout
état de cause le rôle de l’étude préalable qui détermine les enjeux, les
risques, les points forts et faibles du
projet. C’est aussi à ce moment-là
qu’il faut étudier la rentabilité du
projet.
2.3. Les principes de l’étude
de rentabilité
Ce sont les suivants :
• définir les alternatives possibles,
• calculer les coûts complets,
• définir et argumenter les hypothèses de gains,
• estimer les gains,
• utiliser des méthodes éprouvées de calcul de rentabilité,
• évaluer la sensibilité de la rentabilité aux hypothèses de gains,
• évaluer les risques,
• optimiser la rentabilité,
• mesurer la rentabilité effective.
L’étude de rentabilité compare toujours des situations futures définies
selon les composantes du projet. De
• La revue n° 80 - Septembre 2005
Intégration
Développements
5
dossier :Conduite de projet
ce fait, la transparence est de mise
en ce qui concerne les hypothèses
de gains ; celles-ci doivent être
étayées par des éléments factuels –
des chiffres – dont la collecte est
souvent relativement lourde. Mais,
c’est à ce prix, que l’étude peut être
crédible.
2.3.1. Analyse des coûts
Le principe général est de raisonner
en coût complet. Il faut donc
prendre en compte l’ensemble des
coûts afférents au projet, en distinguant investissement, fonctionnement, amortissements. Ces coûts
comprennent :
• les coûts non récurrents : les
matériels, logiciels, prestations
de toutes natures et les charges
internes valorisées – salaires et
charges – tant pour les coûts
informatiques – formation, développement, tests, gestion de projet, etc. – que ceux supportés par
la maîtrise d’ouvrage – gestion
de projet, formation, accompagnement des utilisateurs, reprise
d’existant éventuelle, etc. ;
• La revue n° 80 - Septembre 2005
• les coûts récurrents de fonctionnement : administration, exploitation, maintenance, support et
accompagnement.
6
Il convient de préciser aussi les
sources des données : contrôle de
gestion, DSI, maîtrise d’ouvrage. Tous
ces coûts doivent aussi pouvoir être
expliqués et justifiés. Les travers classiques en la matière sont :
• la sous-estimation des charges
de travail des maîtrises d’ouvrage
pour les aspects relatifs aux évolutions des processus, au
déploiement, aux formations et
à l’accompagnement des utilisateurs,
• de manière générale, une sousestimation
fréquente
des
charges internes à l’entreprise,
• la non-prise en compte des aléas
– techniques ou technologiques
en particulier – par les maîtrises
d’œuvre,
• des calendriers de réalisation
des projets souvent trop serrés,
qui minimisent notamment tous
les coûts de fonctionnement et
lissent les coûts d’investissements.
Les projets informatiques ont pour
particularité de demander en général un investissement massif en
début de projet, et une pratique
répandue, mais fort contestable, est
trop souvent de vouloir les étaler
dans le temps, ce qui ne se fait qu’au
détriment des gains.
2.3.2. Sources de gains et valeur
Globalement les sources de gains
sont de trois natures :
• Action sur les processus : l’optimisation des processus se traduit
par des gains de productivité ou
d’efficacité. Ces gains sont en
grande majorité des gains de
personnel. Certes, pour beaucoup de dirigeants, il y a loin de
l’évaluation des gains à leur réalisation effective. Mais c’est bien
l’enjeu de la conduite de projet
que de garder constamment à
l’esprit les conditions de réalisation effective de ces gains. Si sur
un processus donné, on réduit
les charges de travail de 20 %, il
est indispensable de revoir la
répartition des tâches des différents intervenants, les circuits
d’information, les responsabilités de chacun pour que le processus soit réellement optimisé.
Les critères d’optimisation sont
toujours un peu les mêmes :
paralléliser les tâches, éviter les
goulets d’étranglement, responsabiliser les personnels, accroître
les niveaux de compétence,
rendre les processus transparents et communiquer. Il est vrai
que la sous-estimation de ces
travaux, souvent du fait des maîtrises d’ouvrage, ont par le passé
conduit à trop rarement réaliser
ces gains.
• Action sur les coûts : c’est le plus
souvent la réduction des coûts –
d’achats, de production d’informations, de support aux clients,
etc. – qui sont dûs au projet ou à
l’application. Ces gains sont
notamment visibles dans tous
les projets de rationalisation
d’un existant informatique.
Ainsi, la mise en place d’un
annuaire centralisé, la migration
d’une application obsolète vers
un nouvel environnement, la
mutualisation d’outils, par
exemple, sont générateurs de
gains significatifs en exploitation et maintenance.
• Action sur la valeur : il s’agit des
actions sur la valeur de l’entreprise, selon trois axes : augmentation du chiffre d’affaires, augmentation de la valeur ajoutée,
augmentation de la valeur boursière. Ainsi, la mise en place
d’une base de connaissances
dans un département de R&D
doit logiquement apporter des
gains sur l’innovation – traduite
en dépôt de brevets par
exemple.
Les difficultés de calcul des gains
sont multiples. Trois points méritent
une vigilance particulière :
• L’expression des gains selon des
indicateurs fiables. Puisqu’on
compare des situations futures, il
convient de disposer d’une base
d’indicateurs reconnus : par
exemple, la charge de travail
pour effectuer telle ou telle
tâche ou le coût unitaire de telle
opération. Ces indicateurs
dépendent du projet étudié,
mais aussi de l’entreprise. Ainsi,
les délais de réponse à une
demande client n’ont pas les
mêmes enjeux pour une banque
que pour une compagnie d’assistance internationale, qui gère
le plus souvent des situations de
crise. La difficulté consiste avant
tout à rapprocher ces indicateurs des critères de performance
de l’entreprise et à démontrer le
lien entre système informatique
et évolution de ces indicateurs.
• Le périmètre à prendre en
compte : il faut se garder de
comptabiliser les mêmes gains
sous plusieurs formes. Ainsi
l’évolution de la productivité du
personnel commercial peut se
traduire soit en gain de productivité soit en augmentation des
ventes – le temps ainsi gagné
étant réutilisé pour vendre
davantage. Il est toujours préférable de présenter les gains sous
la forme d’accroissement de
valeur plutôt que de gains de
productivité, même s’il ne faut
pas oublier de préciser les condi-
Conduite de projet dossier
• Les hypothèses utilisées et leur
sensibilité : lorsqu’on effectue les
études de rentabilité, il faut s’efforcer de chiffrer les « mieux »,
« plus vite », « plus fiable »,
« meilleure qualité ». Ainsi, si par
exemple, on souhaite réduire un
taux de réclamation, il faut probablement effectuer le calcul de
rentabilité en faisant varier ce
taux (de – 5 % à – 20 % par
exemple). Cet exercice est riche
d’enseignement, car il permet
de mieux comprendre sur quoi
repose la rentabilité. C’est aussi
une façon de présenter le projet
ou le système avec des objectifs
simples : « le projet est rentable
à 2 ans si le taux de réclamation
baisse de10 % », les 10 % devenant alors l’objectif clé du projet.
2.3.3. Les risques
Tout projet informatique comporte
des risques informatiques bien sûr –
techniques et technologiques – mais
aussi relatifs à la mise en œuvre :
délai, refonte des processus, appropriation des outils par les utilisateurs, évolution des postes et des
méthodes de travail. Il est fréquent
que les gains les plus importants
soient aussi ceux entachés d’un
maximum de risques. Ainsi, si on
décide par exemple de dématérialiser les échanges avec les clients –
dans une application de CRM – il est
indispensable que les utilisateurs
accordent pleine confiance aux
informations gérées dans le nouveau système. Si les pratiques initiales étaient de renseigner peu d’informations dans le système d’information et de conserver des dossiers
« personnels » sur support papier, le
risque du non-partage d’informations est réel. Au-delà de ce risque,
c’est le principe même de la mise en
commun des informations clients
par l’ensemble du personnel appelé
à communiquer avec lui qui est
remis en question. L’analyse des
risques éclaire bien souvent les
conditions effectives de réalisation
des gains et à ce titre, fait partie intégrante de l’étude de rentabilité.
2.3.4. Calculs de rentabilité
Tous les calculs de rentabilité sont
fondés sur l’évolution du compte
d’exploitation de l’entreprise et
donc sur les flux nets de trésorerie,
c’est-à-dire, la différence entre les
gains et les coûts, majorés des investissements, le tout étant minoré des
impôts et taxes. De multiples indicateurs existent, qui résultent d’approches différentes :
• Le délai de recouvrement – payback period – est le délai au-delà
duquel les gains dépassent les
coûts, c’est-à-dire que le flux net
de trésorerie est nul. C’est le
meilleur indicateur pour les projets informatiques, qui trop souvent dérapent en délais et coûts.
• La valeur nette actualisée (VAN) :
c’est sur une période donnée, le
cumul des flux nets actualisé en
tenant compte d’un taux de l’argent. Ce chiffre indique la valeur
du système mis en place à l’horizon donné. Une VAN négative
est la démonstration d’un projet
non rentable.
• Le taux interne de rentabilité :
c’est le taux qui rend nul la VAN,
soit le taux maximum auquel il
est possible d’emprunter pour
que le projet soit rentable. Ce
taux est très souvent très élevé
dans les projets informatiques,
mais pas très significatif, les
investissements
s’effectuant
massivement au démarrage du
projet.
Toutefois, la rentabilité ne s’exprime
pas uniquement par un chiffre. Elle
traduit aussi les conditions de réalisation effective des gains, surtout
lorsqu’il s’agit de gains de personnel
– qui comptent souvent pour près
de 50 % des gains apportés par les
technologies –, conditions qui relèvent du management de l’entreprise
et pas des technologies en tant que
telles.
2.3.5. Optimisation de la rentabilité
Lors de l’étude de rentabilité – qui
s’effectue, pour les projets, au
moment de l’étude préalable – il est
fréquent que l’organisation même
du projet fournisse selon les
variantes possibles, des niveaux de
rentabilité différents. Par exemple, si
le projet suppose des gains en
matière d’accès à l’information et
qu’une reprise d’existant est nécessaire, il est souhaitable que le sousprojet de reprise d’existant soit initié
dès le démarrage du projet, afin que
lors du déploiement, ces gains puissent effectivement être réalisés ; en
effet, si la reprise de l’existant est
effectuée après le déploiement des
outils, ces gains ne se feront que plus
tard, grevant ainsi la rentabilité du
projet. En matière de processus, dès
lors qu’une évolution est requise, la
stratégie du « big bang » est souvent
la plus rentable, surtout lorsqu’elle
exploite au mieux les apports des
technologies ; toutefois, ceci doit
être nuancé en fonction des changements induits, notamment au niveau
des compétences et des transferts
de tâches. Ainsi, la lecture automatique de formulaires sur support
papier dans une administration, si
elle apporte des gains évidents en
matière de saisie de données, a
comme impact de changer radicalement le métier des personnels du
Service Courrier, lequel devient producteur d’information et non plus
routeur de documents. Ce qui ne se
fait pas en un jour…
Optimiser la rentabilité, c’est donc
trouver le meilleur compromis possible entre un maximum de gains et
un minimum de risques. En pratique,
ces deux objectifs sont contradictoires. Néanmoins, l’optimisation de
la rentabilité doit être la préoccupation des responsables de projet, tant
au niveau de l’étude de rentabilité
qu’au niveau du pilotage du projet.
2.3.6. Mesurer la rentabilité effective
Une fois le projet déployé, la mesure
de la rentabilité effective, après une
courte période de quelques mois
pendant lesquels les ajustements
peuvent être possibles, est indispensable. Elle est souvent riche d’enseignements, ne serait ce que pour
chiffrer des éléments difficiles à estimer avant le projet ou pour mettre
en évidence des indicateurs de performance additionnelle. Ainsi, il est
des éléments difficiles à mesurer, ce
• La revue n° 80 - Septembre 2005
tions effectives de réalisation de
ces gains.
7
dossier :Conduite de projet
qu’on appelle dans la littérature les
gains « intangibles » : impact des
délais de réponse aux clients sur leur
fidélité, impact d’une fourniture d’informations fiabilisée sur la prise de
décision, etc.
3. En conclusion
La littérature regorge de chiffres
alarmants montrant que 50 à 80 %
des projets d’introduction de nouvelles technologies (E-business,
CRM, GED, KM, entre autres) sont des
échecs. Mais les motifs sont toujours
les mêmes :
• défaut
gique,
d’alignement
straté-
scénariste, le réalisateur et ses
équipes, et les acteurs.
• trop faible implication du management,
• ignorance des évolutions nécessaires des processus,
• insuffisance
d’accompagnement du changement,
• absence d’indicateurs de performance pertinents et de leur suivi.
L’informatique, c’est un peu comme
l’industrie cinématographique. Un
film a très gros budget peut parfaitement aboutir au pire navet. Cela
ne dépend pas du budget, mais
aussi et surtout de l’alchimie entre le
Bibliographie
AFAI – Rentabilité des projets informatiques : méthode, outils, cas pratiques.
Paris, 2004. Collection Pratiques
Professionnelles
Ghenassia Bruno, Fustec Alan : Votre
informatique est-elle rentable ? Paris,
Édition d’Organisation, 2004.
Peaucelle Jean-Louis. Informatique
rentable et mesure des gains. – Paris,
Hermès. 1997.
LES OUVRAGES PARUS
■ La rentabilité des projets informatiques
L’étude de la rentabilité des projets informatiques, c’est un piège : « si on ne le fait pas, on vous le reproche ; et si on le fait,
personne n’y croit. » Voilà le décor planté. Pourtant, cela n’est pas si difficile. Pour une direction générale ou un DSI, le pilotage
des projets par leur retour sur investissement devrait être la règle. Force est de constater que ce n’est que trop rarement le cas,
au mépris des saines règles de l’IT Governance.
Réhabiliter de saines pratiques en matière d’analyse de rentabilité, détailler une méthodologie, fournir des points de repère, illustrer la démarche par des cas concrets, et surtout mettre en filigrane de tout projet les critères de sa rentabilité pour établir des
jalons, mesurer les points de contrôle, et décider au cours de la vie du projet, s’il passe l’examen de la décision, de continuer, de
réorienter ou d’arrêter le projet sont les objectifs de cet ouvrage. Ambitieux, probablement, mais utile sans doute.
■ Le livre blanc sur l’enquête ERP
À l’occasion du séminaire du 18 janvier 2005, l’AFAI publiera un livre blanc qui résulte de l’enquête menée par ASK Conseil sur
les bonnes pratiques observées en matière de mise en place d’ERP. Cette enquête a permis de mettre en évidence des typologies de comportement entre Groupes d’origine diverses (USA, UK, RFA, FR) sur deux grands ERP du marché, SAP et ORACLE.
• La revue n° 80 - Septembre 2005
Les auteurs en ont dégagé une voie de progrès concrétisée par un modèle de maturité pour réussir la transformation de l’entreprise en alignant la performance à la stratégie ERP.
8
LES OUVRAGES À PARAÎTRE
■ Le support client
L’ouvrage qui sortira au dernier semestre 2005 est destiné à mettre en exergue le rôle déterminant de la fonction support dans le
pilotage de la performance de l’informatique. En effet, les travaux sur le thème de la performance se polarisent sur les projets là où
les budgets sont de plus en plus absorbés par les tâches récurrentes. Cet ouvrage permettra de :
– comprendre le rôle central du support dans une approche de gouvernance basée sur IT Scorecard ;
– réussir la greffe d’un contrat externalisé dans les processus internes et auprès des acteurs concernés ;
– passer en revue les méthodes (ITIL, CoBIT) et se situer vis-à-vis des bonnes pratiques (modèle de maturité, modèle d’évolution).
Son résultat sera une boîte à outils recensant les principales pratiques, les pistes possibles d’amélioration et les interrogations
ouvertes.