Solutions Linux 2008 - ECOS

Evaluer le coût du choix du libre
ou de l'open source

Raphaël Semeteys (raphael.semeteys@atosorigin.com)
Consultant Open Source
Solutions Linux 2008

© 2008 Atos Origin. Document exclusivement réservé à usage commercial. Tout ou partie de ce document ne peut être copié, modifié, diffusé ou annoté sans accord écrit d'Atos Origin ou du client.

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

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


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


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


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


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


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


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

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


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


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)


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


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


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, ...


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


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)


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


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)


Questions / Réponses
raphael.semeteys@atosorigin.com

© 2008 Atos Origin. Document exclusivement réservé à usage commercial. Tout ou partie de ce document ne peut être copié, modifié, diffusé ou annoté sans accord écrit d'Atos Origin ou du client.

Solutions Linux 2008 - ECOS

Contenu connexe

Similaire à Solutions Linux 2008 - ECOS

Plus de Raphaël Semeteys

Solutions Linux 2008 - ECOS