2. Sommaire
» Introduction
» Quelle démarche d'évaluation financière adopter ?
» Quand évaluer les coûts ?
» Sur quelle(s) durée(s) ?
» Quels postes évaluer ?
» Conclusion
2 Solutions Linux – 31 janvier 2008
3. Introduction
» Idées reçues sur le coût de l'open source :
» Le classique “free as in freedom not as in 'free beer'”
» Un projet de déploiement, même sans coûts de licences, reste un projet avec
des coûts associés
» La réduction des coûts pousse souvent à considérer l'open source
» Il faut cependant vérifier les éventuels gains et économies
» Ceci dès les phases amont afin d'éviter les surprises
» Ne pas confondre réduction et déplacement de coûts
» Il est nécessaire d'intégrer l'axe financier dans toute réflexion sur l'open source
3 Solutions Linux – 31 janvier 2008
4. Quelle démarche d'évaluation adopter ?
Evaluation totale ou différentielle
» Estimation du coût total de possession (TCO)
» On cherche l'exhaustivité
» Permet de considérer l'évaluation du retour sur investissement (ROI)
» Estimation comparative
» Evaluer des scénarios libres et propriétaires par exemple
» Permet de raisonner en delta
4 Solutions Linux – 31 janvier 2008
5. Quelle démarche d'évaluation adopter ?
Dans les deux cas
» Ne pas se limiter au budget projet
» Pour ne pas oublier de coûts ou de gains
» Même si l'on évalue de manière comparative
» Tracer les hypothèses
» Hypothèses de non calcul
- postes non intégrés au TCO (éviter le phénomène de “Cost Avoidance”)
- postes considérés comme égaux dans deux scénarios
» Hypothèses de calcul
- justification : elle peuvent être remises en cause
- modification : elles doivent pouvoir être révisées
» Hypothèses globales
- taux d'actualisation
- nombre de jours ouvrés par an
- coûts journaliers moyens par profils
5 Solutions Linux – 31 janvier 2008
6. Quand évaluer les coûts ?
» Avant
» Besoin d'éléments pour la prise de décision
- Migrer/Adopter l'open source ou ne rien faire
- Choisir entre plusieurs cibles
- Choisir entre plusieurs chemins de migration
» Etudes d'opportunités
- Intégrent généralement également d'autres axes
» Pendant
» Reporting financier
- Suivi des écarts
- Révision/Affinage des hypothèses de départ
» Identification des bifurcations économiquement intéressantes
» Après
» Bilan projet
» Validation des hypothèses
» Communication externe
6 Solutions Linux – 31 janvier 2008
7. Sur quelles durées évaluer les coûts ?
» Quelle projection temporelle pour quels niveaux d'information et de décision ?
» Durée sur lequelle on comptabilise les gains
» Les investissements informatiques sont a priori décroissants
» Laisser le temps aux bénéfices d'apparaître
- temps de déploiement/migration de la nouvelle solution
- temps d'adoption de la part des utilisateurs
- éventuelle croissance attendue du nombre d'utilisateurs
» Délais maximal de rentabilité
» Un délais trop court rend souvent les investissements informatiques difficiles
7 Solutions Linux – 31 janvier 2008
8. Sur quelles durées évaluer les coûts ?
Projection tactique
» Projection sur 1 à 3 ans
» La démarche TCO/ROI classique semble adaptée
» Risques
» focalisation sur les coûts au détriment des gains et opportunités
- amélioration de la productivité
- amélioration de la qualité de service
- emergence de nouveaux services
» les gains attendus ne sont pas comptabilisés
» perte de visibilité stratégique
» Contre-exemple : le ministère fédéral allemand des finances recommande des
périodes de 8 ans
8 Solutions Linux – 31 janvier 2008
9. Sur quelles durées évaluer les coûts ?
Projection stratégique
» Projection au delà de 3 ans
» Nécessité d'intégrer les aspects stratégiques
» liens et dépendances entre projets (technologies, calendriers)
» stratégie logicielle globale
» relations avec les fournisseurs
» flexibilité, ouverture du système d'information
» De quel degré de liberté disposera t'on ?
» évaluer le coût de sortie en plus du coût d'entrée (exemple : Lotus)
» intégrer des critères a priori plus qualitatifs à l'évaluation (exemple : formats
ouverts)
» Exemples :
» dépendance stratégique vis-à-vis d'un fournisseur : risques d'augmentation des
coûts de licences, de diminution de la durée de vie des versions
» étude de la marie de Münich sur le poste de travail
9 Solutions Linux – 31 janvier 2008
10. Quels postes évaluer ?
Coûts logiciels
» Coûts de licences
» Licences d'aquisition de logiciels propriétaires
- Nécessitées dans le cadre d'intégration, d'interopérabilité (exemple :
CrossOver)
- Dans le cas de l'évaluation d'un scénario de référence
- Rester dans la continuité de la situation actuelle
- Comparer des alternatives de migration propriétaire et libres
» Cas des solutions open source commerciales
» Ne pas négliger les possibilités de négotiations qu'une étude permet
- Cela rend parfois l'étude très rentable ;)
- Cela a alors un impact sur les hypothèses initiales
» Intégrer l'éventuel renouvelllement de licences en fonction de la période étudiée
» Coût de gestion et de suivi de licences
10 Solutions Linux – 31 janvier 2008
11. Quels postes évaluer ?
Services externes
» Personnel externe
» Expertise
» Renforcement temporaire d'équipes internes
» Support
» Dans le cas d'évaluation comparative, penser à comparer les scénarios à
niveaux de service constant
» Autre services
» Location de logiciels (exemple : pour une campagne de test)
» Location de matériels
11 Solutions Linux – 31 janvier 2008
12. Quels postes évaluer ?
Coûts d'infrastructure
» Achat de nouveau matériels
» Mise à jour de matériels existants
» Matériels concernés
» Serveurs et baies de stockage
» Postes de travail
» Périphériques
» Eléménts de reseau et câblage
» Besoins supplémentaires en énergie
» Intégrer les impacts sur les services transverses du SI
» Mises à jour de serveurs/services
» Augmentation de la criticité d'un service (coût de sécurisation)
12 Solutions Linux – 31 janvier 2008
13. Quels postes évaluer ?
Effort de migration
» Outre les coûts en ressources humaines évalués sur un autre poste
» Reprise des données :
» Inventaires de données et documents à reprendre
» Développement ou achat d'outils spécifiques pour la reprise des données
- Reprise automatisée ou manuelle
- Conversion de formats
» Exemple : documents, modèles de documents et macros bureautiques
13 Solutions Linux – 31 janvier 2008
14. Quels postes évaluer ?
Aspects organisationnels et humains
» Organisation des équipes
» Besoins de ressources supplémentaires ou réaffectations
» Affectations de tâches (administration, support, migration, reversement)
» Coût des équipes techniques
» A ramener en ETP par profil
» Si possible se baser sur des hypothèses globales (maintenabilité de
l'estimation)
» Eventuels coûts de déplacement
» Coût de formation
» Formations
- se baser sur les offres du marché
- intégrer la contrainte de roulement des équipes
» Auto-formations : cela à un impact sur la disponibilité des équipes
14 Solutions Linux – 31 janvier 2008
15. Quels postes évaluer ?
Conduite du changement
» Actions de communication
» Préparation des supports
» Impression/fabrication des supports
» Diffusion des supports
» Formation des utilisateurs
» Mini-formation individuelle (exemple : lors du déploiement)
» Auto-formation
» Formation de groupe : prévoir un markup dû à la disponibilité des utilisateurs
» Mesures d'accompagnement temporaires
» Surcharge au niveau du support
» Prévoir une plus forte sollicitation directe des équipes techniques
» Effort de valorisation
» Maintenance de FAQ, wiki, forums, ...
15 Solutions Linux – 31 janvier 2008
16. Quels postes évaluer ?
Estimation des opportunités
» Opportunités directement liées à l'informatique
» Augmentation de la productivité des utilisateurs
» Réduction du temps d'indisponibilité des services
» Auto-configuration par les utilisateurs
» Auto-formation par les utilisateurs
» Réduction des temps de diagnostic
» Auto-diagnostic par les utilisateurs
» Réutilisation de matériel informatique
» Cela peut à l'inverse constituer des postes de coûts
» Opportunités au niveau de l'entreprise
» Nouveaux produits/services générés par la solution
» “Time-to-market”
» Equipe Informatique plus disponible pour des projets toujours repoussés
16 Solutions Linux – 31 janvier 2008
17. Méthodes existantes
» Mareva (Methode d’Analyse et de REmontee de la VAleur)
» Conçue par le SDAE (ex-ADAE)
» Prévue pour les administrations publiques
» Intègre deux axes :
- Rentabilité : analyse TCO avec actualisation
- Valeur : prise en compte de critères plus qualitatifs (nécessité, risques, ...)
» Outillée sous forme de feuilles Excel
» Sous license MPL
» https://www.ateliers.modernisation.gouv.fr/ministeres/domaines_d_expertise/budget_et_controle_d/public/view
» WiBe (Economic Efficiency Assessment)
» Conçue par le Ministère Fédéral Allemand de l'intérieur
» Prévue pour les administrations et collectivités publiques
» Intègre également deux axes :
- éfficacité économique au sens monétaire
- éfficacité économique dans un sens plus large (urgence, importance
stratégique, ...)
» http://www.wibe.de (allemand) http://www.epractice.eu/document/2949 (anglais)
17 Solutions Linux – 31 janvier 2008
18. Conclusion
» Nous avons tous
» besoin de convaincre des décideurs
» notre “cheklist” (ou feuille de calcul) de poste de coûts
» notre démarche d'évaluation
» Nous manquons souvent
» d'une démarche réellement formalisée
» d'éléments de comparaison pour fiabiliser nos estimations
» de visibilité sur ce que font les autres
18 Solutions Linux – 31 janvier 2008
19. Initiative eCOS
» Annonce de l'initiative eCOS (evaluation des Côuts de l'Open Source)
» Objectifs
- réunir les personnes intéressées par le sujet
- partager nos bonnes pratiques
- créer un projet libre et communautaire sur le même modèle que QSOS
» Idées
- formaliser une démarche sans réinventer la roue (cf. Mareva, ...)
- partager (certains de nos résultats) :
- communications interne et externe plus faciles
- aide lors des estimations (statistiques, métriques)
19 Solutions Linux – 31 janvier 2008