Logo ANAP
Ce site requiert l'activation de javascript pour être utilisé, merci de l'activer.
S'abonner

Méthode

Ressources associées

Personne ressource

Etienne MAUGET

 1165 vues

 Cette section correspond au chapitre 4.5 de la production originale.

Préalable : on cherche à évaluer le coût de remplacement de l’organisation existante (automatisée ou non) par l’organisation cible automatisée. Généralement et au premier abord, le coût de la solution cible est en apparence plus élevé car on sous-estime le coût d’exploitation, de maintenance voire les coûts utilisateurs « cachés » de l’existant.

Fiche 4 - Etude des coûts

Objectifs

  • Obtenir un écart de coût entre le fonctionnement de l’existant (exploitation et maintenance, vie courante chez les utilisateurs) et le coût de possession de la cible (mise en œuvre, exploitation, maintenance et vie courante). On cherche à évaluer le coût de remplacement de la solution existante.

Pré-requis

  • Le budget du projet et un accès au budget d’exploitation de la DSI et des directions utilisatrices de la solution en place.
  • Valider le mode de présentation des coûts : préférer la mise en évidence année par année à un cumul sur la durée du projet.
  • Si le projet comporte des livraisons de modules intermédiaires, faire le parallèle pour les coûts.

Moyens

  • Documentation source : le budget du projet (document de cadrage du projet); tableau des charges d’exploitation détaillées ; …
  • Reconstituer le coût complet de l’existant.
  • Projeter les éléments du projet pour en déduire les coûts complets de la cible.
  • Voir tableaux des coûts en annexe 3 (§6.3) :
    • Cas des applications partageant des ressources communes d’exploitation : en cas de refacturation, prendre le coût réel, sinon trouver un ratio rapporté au nombre d’utilisateurs ou d’U.O. produites ;
    • Pour le personnel interne, prendre les coûts standards fournis par la DHOS, la MEAH, etc.;
    • Pour les autres coûts, prendre les coûts réels.

Contenu de l’étape

  • Prendre les coûts d’investissement et d’exploitation du SI sur le même périmètre fonctionnel que la cible.
  • Identifier les coûts d’utilisation (exploitation, développement, formation et maintenance) de l’application existante.
  • Identifier, au cours de la première réunion avec les gestionnaires de l’application existante (maîtrise d’ouvrage, responsable du domaine,…) les sources à utiliser. Se poser la question de savoir s’il existe :
    • Des tableaux de bord sur l’application étudiée ?
    • Une comptabilité analytique ? (ex : le coût du jour-homme (ou de l’année-homme) pour pouvoir chiffrer le temps passé par les ressources internes
  • ...ainsi que les éléments et les personnes qui permettront de reconstituer les coûts informatiques :
    • Responsables utilisateurs ;
    • Responsables systèmes d’information ;
    • Direction du personnel ;
    • Direction des affaires générales ;
    • Centre de traitement ;
    • Gestionnaire de l’application ;
    • Responsable des études ;
    • Responsable de l’exploitation.
  • Identifier les personnes impliquées dans le projet et le temps qu’elles y consacrent (les prestataires, les différentes équipes de la DSIO, les équipes métier, l’équipe de communication projet ?).
  • Formaliser le plan de collecte des informations de coûts :
    • Informations existantes ;
    • Informations à constituer à partir d’informations existantes.
  • Recueil des données par entretiens successifs,
  • Validation et synthèse des coûts totaux de possession de la solution existante et de la solution cible.

Recommandation : si des coûts de formation de base en informatique sont mutualisés pour d’autres projets, on peut les « sortir » des coûts du projet. De même, si des coûts de formation « métier » sont nécessaires (mise à jour pour les métiers comptables, par exemple), on peut les éliminer du total dans la mesure où cette formation aurait dû intervenir de toute façon, le système d'information agissant uniquement comme un révélateur d’une évolution nécessaire des compétences.

Le coût de la formation peut se révéler particulièrement élevé dans certains cas. Il est nécessaire de l’analyser, afin de faire la part entre ce qui est une conséquence directe du projet, et ce qui relève d’une formation continue, nécessaire, indépendante du projet. On pourra par exemple sortir la formation de base à la bureautique (formation continue à l’informatique de bureau), et conserver la part liée à l’utilisation d’un outil – bureautique – de gestion des rendez-vous.

Résultats de l’étape

Livrables :

  • Tableau des coûts de l’existant et de la cible (différence avant/après):
    • Coûts d’investissement et d’exploitation des applications sur le périmètre fonctionnel;
    • Coûts utilisateurs ;
    • Coûts structurels (matériels, etc.) induits par l’évolution de l’organisation et de son mode de fonctionnement..
  • Un tableau de synthèse présentant une évaluation des coûts totaux de possession de la solution actuelle et de la solution cible année par année.

Interlocuteurs

  • le chef de projet ;
  • l’équipe projet, éventuellement les services techniques de la DSIO (pour connaître le nombre de postes de travail, de serveurs,…, et les budgets d’exploitation) ;
  • le directeur financier (ou le DAF) et son équipe ;
  • le directeur des ressources humaines et son équipe.

Facteurs clés de succès

  • Commencer l’étude de coûts le plus tôt possible (dès la définition du périmètre), car les données sont parfois délicates à obtenir (coûts utilisateurs à reconstituer, ou ratios d’exploitation en cas de partage de ressources communes, par exemple).
  • Le calcul des coûts est très dépendant du paramètre temps. Éventuellement envisager des scénarios à durée variable.
  • Les coûts utilisateurs sont souvent négligés, notamment ceux qui permettent de fiabiliser les données, ou de créer les nouveaux référentiels et protocoles indispensable au bon fonctionnement des nouveaux systèmes d'information.
  • Le risque est de cumuler trop longtemps les coûts de l’existant et de la solution cible faute de pouvoir abandonner les applications actuelles : retard dans les déploiements, modules fonctionnels résiduels non traités par la nouvelle application, migration de données incomplète…
Cette réponse vous paraît-elle utile ?
Date de parution : 19/11/2015

Commentaires - Soyez le premier à déposer un commentaire

Pour ajouter un commentaire vous devez vous identifier

Vous êtes actuellement sur la page consacrée à Evaluer le retour sur investissement du SI (Méthode).

Vous êtes perdu ?

Haut de page

Vous êtes actuellement sur la page consacrée à Evaluer le retour sur investissement du SI (Méthode).

Vous êtes perdu ?