Théorie et Pratique du Système d’Information Cinquième Chapitre: Economie du SI

(1)

1/35

Théorie et Pratique du Système d’Information Cinquième Chapitre: Economie du SI

Janvier 2009

Ecole Polytechnique

Yves Caseau

(2)

2/35

Plan du Cours – Architecture du Système d’Information

• Première partie:

Comprendre le budget d’une DSI

• Deuxième partie:

Maitrise du socle

• Troisième partie:

Coût des projets

• Quatrième partie:

Analyse de la Valeur

(3)

Yves Caseau – Cours Polytechnique - 2009 3/35

Introduction : Pourquoi le SI coûte si cher ?

• Dans la lignée d’une longue tradition:

o Peter Keen,

o J.-F. Paucelle,

o M. Volle,

o T. De Marco …

• Représenter/mesurer le SI par:

o Quelques grandeurs caractéristiques (le parc applicatif !)

o Valeurs de marché (unités d’œuvre)

• Le SI coûte cher … parce qu’il est « gros »

o La responsabilité patrimoniale du système d’information repose sur l’ensemble des directions de l’entreprise.

o Il est fondamental de mesurer le parc applicatif, de façon régulière, objective et partagée. Cette mesure peut s’appuyer sur la notion de point de fonction, qui permet de s’affranchir des technologies et de faire des comparaisons, dans le temps et d’une entreprise à l’autre.

Première Partie: le budget de la DSI

(4)

Le coût du « socle » et les projets

• Equation du socle

o Socle = exploitation, maintenance & nettoyage (projets passés)

o équilibre = croissance absorbée par la productivité

o Productivité = structurelle (faible) + technologique (Loi de Moore, pondérée par le taux de remplacement)

• Rapport projet/total typique = 30%

o Varie considérablement (cf. plus loin)

• Facteurs:

o Age moyen des applications

 ratio nouveau périmètre /amélioration existant

o Mutualisation et consolidation (stratégie)

• Mesure

socle projets

• prix achat (€ /TPMC)

• prix hébergement (k€/TMPC)

• exploitation (€ /FP)

• prix achat (€ / FP)

• taux progiciel (%)

• coût maintenance (fonction de l’age)

(5)

Modèle: l’Usine à Services

Portefeuille Projets

Parc Applicatif

Données Calcul

Puissance de calcul

purge remplacement

Production

Alimentation

Capacité de stockage

Nettoyage

Services Informatiques - coût

- qualité de service

(6)

Modèle: l’Usine à Services (zoom)

projets

Parc SW (pf)

Parc HW (TPMC) Parc Progiciel (€)

utilise utilise

achat

utilise utilise

nouveau améliore

refonte Nettoyage applicatif

Réorganisation SW

Mise au rebut Maintenance Licences progiciel

Maintenance SW

Licences progiciel

Achat

serveurs Exploitation

applicative Exploitation

hébergement croissance

croissance Dépenses

projet

(7)

Modélisation des coûts

Un modèle de coût est défini à partir

• De grandeurs mesurables

• D’équations de dimensionnements

passé futur

Données Concrètes

(mesures parc ; budget)

Analyse : ratios

KBI (3YP)

A partir des KBI, des

paramètres économiques et des paramètres stratégiques

Les paramètres

économiques sont obtenus par extrapolation

Mesures

Analyse Extrapolation Prévisions Hypothèses

Information

Cf. TD

(8)

Typologie projets selon impact sur le parc applicatif

• Pour comprendre les coûts du SI, il faut comprendre l’histoire du parc applicatif

(ex: age moyen et taux moyen de renouvellement)

• Les projets sont décomposés en quatre types :

1. nouveaux : une augmentation des points de fonction (neufs). Les projets « nouveaux » accroissent le périmètre informatique.

2. amélioration : il s’agit d’entretenir et améliorer un applicatif existant (un

« applicatif » est l’abréviation de système applicatif, qui correspond à un logiciel associé à une ou plusieurs applications).

3. refonte : il s’agit de remplacer un applicatif ancien par un neuf. Le

nombre de points de fonction n’augmente pas (si la refonte est à « iso- périmètre ») mais le parc est « rajeuni ».

4. nettoyage : le projet est un projet de nettoyage applicatif, c’est-à-dire la suppression d’une application..

(9)

Modèle du parc logiciel

• Attention la mesure est difficile (cf. chapitre précédent)

• La réalité est complexe (stratification du code)

o Le code inutile n’est pas nécessairement nettoyé

o La plupart des projets sont mixtes

• L’objectif principal est de mesurer et comprendre la croissance du parc applicatif total

Année N Année N +1

Code spécifique : Parc SW

(FP) @ N

nettoyage

nouveau

Amélioration/

adaptation refonte

Parc SW

@ N+1

rebut

nouveau Progiciel :

Parc (FP) @ N

accumulation

(10)

10/35

Modèle du budget

• Facteurs clés

o Age moyen, périmètre du parc

o Parc HW = f(SW x volume x activité)

o Les gains technologiques font que le budget est majoritairement fonction du parc logiciel

facteurs commentaires

projets nouveaux paramètre Lié à croissance + stratégie

refonte Age moyen Coût refonte = f(urbanisation) amélioration différence Enveloppe projet = choix DG

« socle » récurrent

SW licences Parc SW:

Points de fonction

Linéaire (coût)

maintenance Linéaire + vétusté + complexité

exploitation UO du contrat infogérance

HW location Parc HW:

TPMC, Go,

# serveurs

… ou amortissement

maintenance Linéaire + vétusté

exploitation Linéaire + productivité

(11)

11/35

Yves Caseau – Cours Polytechnique - 2009

Modèle des coûts (I)

• Le besoin en TPMC est extrapolé à partir du produit nombre_de_clients × taille_du_parcSW

• Le nombre de serveurs à acheter est le ratio du besoin nouveau en TPMC (le chiffre précédent, moins le parc HW actuel diminué par

l’application du facteur de renouvellement) sur la puissance moyenne d’un serveur.

• On en déduit la puissance du parc HW installé, le nombre de serveurs, ainsi que l’âge moyen.

• Le budget projet permet de déduire le nombre total de points de fonction représenté par l’ensemble des projets, en partant du coût d’achat en €/PF.

(12)

12/35

Modèle des coûts (II)

• Ce nombre brut de nouveaux points de fonction est ventilé en

nouveaux projets, refontes et amélioration. Le taux de refonte permet également de calculer l’âge moyen des applicatifs.

• Les achats en progiciels sont extrapolés à partir des montants des projets (en tant que fraction des dépenses).

• La maintenance logicielle (corrective & maintenance progicielle) est obtenue comme le produit de la taille du parc par un taux de

maintenance qui varie en fonction de l’âge (: 7% × (1 + 15% × âge)).

• Les coûts d’exploitation sont séparés en deux parties : l’exploitation des logiciels et celle des serveurs (l’hébergement).

o Les 15% indiqués dans le chapitre 1 se répartissent approximativement en 10% et 5%.

o Les coûts de production liés aux logiciels sont proportionnels au

parc applicatif, en incorporant une hypothèse de gain de 2% par an.

• Les coûts d’hébergement sont proportionnels au nombre de serveurs.

(13)

13/35

Exemple Bouygues Telecom

• L’augmentation du parc applicatif est importante

o Périmètre

o Complexité des logiciels (exemple Microsoft Office)

• Le modèle est assez précis

o Régression (échelle log)

o Un travail qui a débuté en 98

(14)

14/35

Unités d’Œuvre et Ratios

• Coût achat d’un projet : 200€ / PF

o Fourchette de 100-300€ (fonction de la complexité)

• Coût achat TPMC: 2,4€ / TPMC (2006)

[de 2 à 8 selon taille serveur]

o TPMC/serveur : 32K (Windows)

o Hébergement/serveur: 5K€

• Coût complet exploitation: 20€ / PF

o 10% du coût projet pour l’exploitation

o 15% pour la maintenance (MEF/MET)

o MET = 5% à 10% en fonction de l’âge

14 Première Partie: le budget de la DSI

(15)

15/35

Deuxième partie

• Comprendre le budget d’une DSI

• Maitrise du socle

• Coût des projets

• Analyse de la valeur

(16)

16/35

Coûts du Socle et Facteurs

Décomposition

• l’exploitation des applications,

• la maintenance corrective des applications,

• le maintien en condition du parc matériel (hébergement des applications).

• Coût acquisition des serveurs

Quatre leviers :

• Le volume global des investissements informatiques dans les projets, qui conditionne la taille globale du système d’information..

• A volume financier donné, la taille du parc en fonction de l’allocation vers les nouveaux projets.

• Pour un parc donné, le taux de renouvellement (ou, de façon duale, l’âge moyen du parc).

• Le nettoyage des applications devenues inutiles.

Deuxième Partie: Maîtrise du Socle

(17)

17/35

Le poids du parc applicatif

• La taille du parc applicatif est le premier driver de coût de la DSI

• Le second driver est l’age: un parc ancien coûte plus cher

o Effets induits sur le parc matériel !

• Comparaisons de scénarios iso-budget

(différent taux renouvellement)

(18)

18/35

Refonte et Nettoyage Applicatif

Le nettoyage applicatif est un levier clé:

• intra-applicatif : éviter l’accumulation de code

• Inter-applicatif : débrancher les applications mort inutilisées

Paramètres:

• Taux de nettoyage applicatif: 60% / 80% / 90%

• Taux d’accumulation: 70%, 50%, 30%

(19)

19/35

Impact du taux de renouvellement matériel

• La loi de Moore n’est utile que si l’on s’en sert ☺

o Concept de « Loi de Moore Pondérée »

• Le ROI (mutualisation/consolidation) est sensible : à calculer pour chaque contexte

• « Gros » impacts induits (m2, maintenance, hébergement) Deuxième Partie: Maîtrise du Socle

(20)

20/35

Coûts du Socle : Facteurs explicatifs

Les prix des unités d’œuvre (UO) peuvent être comparés mais ils dépendent de facteurs propres à chaque entreprise

• Exigences de performance (Chapitre 9)

• Exigences de Qualité de Service (Chapitre 8)

o Disponibilité

o Plan de secours

o Réelle et Perçue

Les choix logiciels ont également des conséquences technologiques sur le parc matériel

• Commodity computing vs. High-performance computing

• Taux de renouvellement

• Capacité à utiliser des architecture modernes (ex: GRID)

(21)

21/35

Troisième Partie

• Comprendre le budget d’une DSI

• Maitrise du socle

• Coût des projets

• Analyse de la valeur

(22)

22/35

Coût Complet d’un projet

• Phases (cf. cycle en V)

• Répartition (moyenne / forte variabilité):

 26% conception,

 36% développement (y.c. tests unitaires),

 26% tests,

 12% déploiement

 Management: (inclus dans les 4 phases)

 Très variable, de l’ordre de 10%

Conception développement Test

intégration déploiement

Management

Spécifications

Tests unitaires

Troisième Partie: Coût des Projets

(23)

23/35

COCOMO (Constructive Cost Model)

• Cocomo I

o En ligne : http://cost.jsc.nasa.gov/COCOMO.html

o Facile à utiliser

• Cocomo II : LE livre - une « bible » pour trouver une référence sur l’impact des facteurs de coûts:

o QoS désirée (Chapitre 8 et 9) - RELY cost factor (2.17) de 0.82 à 1.26 : facteur correcteur

o Complexité Technique - CPLX (2.19) : +30%

o Réutilisation - RUSE (2.21)

o Volume manipulé (en fonction de D/P = taille de la BD sur taille du programme)

Complexité Effort (en mois homme)

Temps de développement (en mois)

Organic 2,4 * KLS1,05 2,5 * Effort0,38

Semi-detached 3 * KLS1,12 2,5 * Effort0,35

Embedded 3,6 * KLS^1,2 2,5 * Effort^0,32 Troisième Partie: Coût des Projets

(24)

24/35

Les refontes nécessaires

• Problème de la compatibilité

o OS, middleware, autres applications

• Courbe de coût en fonction age

o Les entreprises matures définissent des ages limites

• Chaque M€ de projet génère

(très approximativement)

o 15% exploitation

o 15% en maintenance (+ vétusté)

o 15% de provision pour refonte

 À 3 ans, palier 30%

 À 6 ans refonte 60%

• Conclusion: les coûts complets sont toujours sous-estimés dans les calculs de ROI

(25)

25/35

Impact de la taille de l’entreprise & sa culture

• La DSI vs la start-up, vs. Le stagiaire …

• Une multiplicité de causes:

o Le travail d’intégration est plus lourd, proportionnellement, à

l’échelle du système d’information que pour un composant logiciel, parce que le premier est plus complexe et plus hétérogène que le dernier.

o Le pilotage industriel des projets est nécessaire dans une DSI,

même s’il peut sembler lourd, pour réduire les risques et augmenter la régularité des performances.

o La qualité de service, et en particulier la haute disponibilité, est une propriété logicielle qui a un coût, qui se combine avec celui de la qualité du logiciel (le faible taux d’anomalies).

o Garantir la pérennité des solutions conduit à une grande exigence en terme de gestion des fournisseurs, ainsi que de gestion des compétences internes.

25 Troisième Partie: Coût des Projets

(26)

26/35

Illustration

26

besoin

Normes développement (pérennité) Sécurité accès, gestion utilisateurs Archivage, restauration, secours

….

Préparation intégration Traçabilité impact

….

Développement C2O (PME)

DSI Monep

développement développement

tests

intégration

Mise en service intégration

Tests

unitaires Tests système

Continuité des compétences Documentation

Gestion des risques

….

Automatisation exploitation

Exigences disponibilités + secours

….

architecture développement

Intégration modulaire

Interfaces normalisées et pilotées (changement)

Mise en service

30 jh 50 jh

400 jh

• Gros travail de pédagogie (multiples causes)

• Il existe des références (ex: COCOMO II) Troisième Partie: Coût des Projets

(27)

27/35

Gains de productivité

• Gains en terme de logiciel

o Technologie : « facteur 2 » en 20 ans (à partir des sources ☺, de 1 à 2 PF/jh)

o Industrie : Mondialisation

o Architecture : composants/ urbanisation/ SOA

• « Effet rebond » : le SW consomme ses propres gains – ex: Word™

o Augmentation des exigences (sécurité, …)

o Interopérabilité

o Abstraction des fonctions (maîtrise complexité)

• Gains en terme d’opérations:

o Technologie : Loi de Moore, Automatisation

o Infogérance

o Professionnalisation: ITIL

• Les gains de productivité en terme d’opération permettent la croissance des parcs applicatifs

27

Références: Keene, Jones, Brooks, De Marco, …

(28)

28/35

Quatrième Partie

• Comprendre le budget d’une DSI

• Maitrise du socle

• Coût des projets

• Analyse de la valeur

(29)

29/35

Valeur Matérielle et Valeur Immatérielle

• Valeur incrémentale / globale

• Valeur financière

o Différentes méthodes

o Le calcul du « pay-back », c’est-à-dire le moment où les gains cumulés dépassent les dépenses cumulées.

o Le calcul du ROI, du retour sur investissement, qui se fait sur une période donnée, et synthétise l’ensemble des gains par rapport aux dépenses en tant que taux de

rentabilité de l’argent investi sur cette période.

o Le ROCE (Return on Capital Employed), rentabilité économique en français, évalue la rentabilité du projet en tant que fraction du résultat d’exploitation du projet par rapport aux capitaux employés pour le projet.

o La VAN (Valeur Actuelle Nette) ou DCF (Discounted Cash Flow), consiste à

introduire le coût du capital sous forme de dépréciation qui est appliquée à la série temporelle des gains du compte d’exploitation du projet.

o L’EVA (Economic Value Added), est obtenue à partir du ROCE en prenant en compte le coût du capital pour l’entreprise (WACC : Weighted Average Cost of Capital)

• Valeur immatérielle

o Capital humain, Capital intellectuel, Capital de connaissances

o Capital client: image, marque, satisfaction & confiance client,…

o Capital structurel: agilité, flexibilité, organisation,capital processus, …

o Goodwill = Purchase Price - Fair Market Value of Net Assets

Quatrième Partie: Analyse de la Valeur

(30)

30/35

Outils pour mesurer la création de valeur

Quatre familles:

• L’analyse de la valeur de marché de la DSI : comment mesurer de façon objective la valeur créée par la DSI par rapport au marché de la prestation en système

d’information.

Il s’agit d’une approche très intéressante, mais qui relève plus du benchmarking que dans la mesure de création de valeur propre au système d’information..

• Les méthodes « financières » qui s’appuient sur le patrimoine des analyses de valeur d’entreprise pour étendre les méthodes d’évaluation de projet. Elles font appel aux concepts préalablement cités de ROCE, DCF ou EVA. Elles s’appuient également sur des techniques de valorisation du risque (en particulier dans des méthodes de

gestion de portefeuille de projets), qu’il s’agisse de risque positif) ou de risque négatif.

• Les méthodes de scoring de projet, qui cherchent à réintroduire des éléments

« immatériels » pour ajouter une dimension « stratégique » à l’analyse purement

« comptable ». Ces méthodes sont toutes basées sur des questionnaires, avec un jeu subtil de coefficient et d’évaluation qualitative.

• L’analyse de valeur par processus, en calculant la contribution informatique à la chaîne de valeur. L’analyse de la valeur consiste à décortiquer le processus étape par étape, et à assigner une partie de la valeur globale à chaque étape.

Il est possible d’attribuer un ordre de grandeur de la valeur produite, processus par processus, par le système d’information, mais cette évaluation ne peut être qu’un élément de réflexion, elle est difficile à justifier de façon indiscutable.

(31)

31/35

Pilotage de la valeur du SI

• Idées principales

o L’utilisation de méthodes sophistiquées pour évaluer la valeur créée par le système d’information doit être réservée à des spécialistes.

o La maintenance d’une application fait partie de la vie naturelle d’une application (intégrée en coût complet).

o Il faut construire un ROI:

 sur plusieurs années (renouvellement),

 simple pour être partagé,

 fondé sur les KPI, pour être suivi

• Le « contrat de valeur »

o La valeur se pilote sur un domaine fonctionnel (sédimentation des projets => pas de traçabilité)

o Un « business case » n’est pas une prévision, c’est un engagement :

 la direction opérationnelle s’engage sur ses « hypothèses métiers »,

 la DSI qui s’engage sur les coûts opérationnels et la qualité de service,

 la Direction Générale valide l’attribution de valeur (arbitraire).

o Le pilotage consiste à suivre les éléments clés du « dossier ROI »: coûts, KPI des facteurs de création de valeur => les hypothèses peuvent changer !

31 Quatrième Partie: Analyse de la Valeur

(32)

32/35

Mesurer la valeur de la flexibilité

• La valeur associée à la flexibilité du système d’information, c’est- à-dire sa capacité à exploiter des opportunités futures, peut être mise en évidence par une analyse de scénarios (2.5.3)

o La flexibilité est (presque toujours) un investissement

• Citation CSC «

Using IT Portfolio Management to Improve the IT Contribution to the Business

» ☺ :

la valeur de la flexibilité n’existe que si le futur est incertain.

• Exemples :

o Urbanisation et programme de refonte

 Exemple Bouygues Telecom (seul le cycle de vie justifie la démarche)

o Architecture SOA

 Coût de la mutualisation des services

 Un service réutilisable coûte plus cher (classique)

(33)

33/35

Benchmarking

Conditions pour que le benchmark soit intéressant:

• Iso-périmètre

o Taille du parc applicatif

o Parc HW (puissance)

o Qualité de service exigée

• Iso-processus

o Age des applications

o Réactivité (time to market)

o Organisation

(qui est dans la DSI ?)

(34)

34/35

Pourquoi modéliser ?

• Expliquer

o Faire partager les facteurs dimensionnants pour

dépassionner les débats sur les coûts

• Faire du

« Benchmarking »

o Comparer avec d’autres : difficile

• Prévoir

o Dimensionnement à long terme

• Rassurer

o Passer de la boîte noire à la boîte blanche

Usage / client

Nettoy age

Services - coût - QoS

Pf. Projets (pf)

Renouvellement =>

Age moyen Parc Applicatif (pf)

Données (Go)

Calcul (TPMC) Go

TPM C

#clients

(35)

35/35

Quelques conclusions sur le coût du SI

• Les coûts récurrents représentent 25% des coûts de réalisation d’un projet applicatif. Cet ordre de grandeur approché permet de

comprendre implicitement que les coûts récurrents d’une DSI sont proportionnels à la taille du parc applicatif.

• Le premier levier de réduction des coûts d’une DSI est la suppression des applicatifs faiblement utiles. Le nettoyage applicatif est une

responsabilité partagée dans l’entreprise.

• L’informatique consomme une partie des gains de productivité qu’elle engendre. Cela se traduit par des gains « non fonctionnels » (en terme d’ergonomie, d’interopérabilité, de gestion) mais qui ont un impact réel.

• Le développement durable du système d’information consiste à piloter l’accroissement du parc applicatif de telle sorte que les coûts complets, en tenant compte des gains de productivité, évoluent en harmonie avec les fondamentaux économiques de l’entreprise (par exemple, pour

conserver un ratio « dépenses informatiques / chiffre d’affaire » constant).