Modèle de couts complets
Un modèle économique a pour objectifs d’expliquer la consommation des ressources financières requises pour produire les services. L’informatique étant une activité de service, il convient de mettre sous contrôle les activités et les services. A ce titre un modèle économique éclaire le procédé d’agrégation des couts à travers les activités jusqu’aux services. C’est donc un formidable outil de gouvernance car il met en évidence des liens de causes à effets entre le niveau des dépenses, le cout des activités et le cout de services au regard de leurs valeurs ajoutées aux utilisateurs.
Rappelons en préambule que les services informatiques sont classés en 2 familles distinctes : d’une part le Build pour les projets et d’autre part le Run pour la délivrance récurrente des services. Pour calculer un cout de revient, il faut imputer les dépenses sur les objets de couts. Nous nommons objets de coût ce que l’on cherche à valoriser, ici ce sont donc les services du Build (les projets) et du Run (les applications).
La détermination d'un cout de revient en cout complet signifie que la totalité du budget de la DSI est imputé sur les objets de couts, ce qui inclut les charges directes et indirectes. La part de plus en plus importante des charges indirectes rend difficile l’évaluation précise des couts. Ceci est particulièrement vrai pour le Run car la mutualisation des infrastructures informatiques constituent de ce fait une proportion majoritaire de charges indirectes. Cette mutualisation permet de faire des économies d’échelle, mais induit une plus grande difficulté pour la répartition équitable de ces charges.
Activity Based Costing
Parmi les méthodes d’évaluation en coûts complets, l’Activity Based Costing (ABC) est celle la plus abouti mais aussi parfois la plus décriée pour sa mise en œuvre.
Cette méthode introduit une notion d’activité entre les ressources financières et les services. Les activités et plus globalement les processus incarnent le facteur explicatif de la consommation de moyens financiers: une DSI doit dérouler des processus et donc des activités qui consomment des ressources afin de produire des services. Dans le cadre d’une DSI, on va donc définir des activités qui permettent de mener des projets et d’exploiter des applications.
L’introduction des activités dans un modèle de couts permet de mieux appréhender les charges indirectes. Une dépense qui est indirect vis-à-vis d’un service devient direct vis-à-vis d’une activité. Les activités sont répartis à l’aide d’inducteur. On parle d’inducteur et non d’unité d’œuvre car ils induisent le niveau de consommation. C’est un lien causal entre la dépense et le niveau de consommation de cette dépense. On distingue :
- Les inducteurs de ressources : ils servent à éclater une ressource sur plusieurs activités. Ceci peut se produire lorsqu’on a une facture d’une même société mais concernant plusieurs projets par exemple.
- Les inducteurs d’activité : ils permettent de répartir le cout des activités sur les services du catalogue de service. Les inducteurs d’activités jouent un rôle très important dans la détermination des coûts de revient des services du Run de part la forte présence des charges inditrectes. Le choix des inducteurs et leur disponibilité sont de ce fait des facteurs clés de succès d’une démarche ABC au sein d’une DSI.
La démarche ABC se structure autour de 3 étages (ressources, activités et services). La richesse du pilotage financier viendra de la capacité à analyser chaque étage et surtout à combiner les analyses sur les 3 étages i.e. le croisement de tout ou partie des ressources par les activités et par les services.
Les ressources
Au niveau des ressources, il est possible de voir l’intensité des dépenses selon les natures comptables, selon des centres budgétaires ou plus largement selon les sections analytiques ad-hoc à chaque organisation. L’analyse à ce stade permet de savoir si on achète bien, au bon prix, les prestations intellectuelles, les matériels et logiciels.
En règle générale, les analyses à ce niveau sont déjà largement présentes car naturellement disponibles à partir de la comptabilité : il suffit d’avoir une répartition par nature comptable et par centre budgétaire. Les analyses à ce stade sont souvent le matériau utilisé en autre par les achats pour l’optimisation du « sourcing ».
Les activités
Le niveau activité permet de savoir si les activités sont menées à niveau acceptable de coûts. Il existe beaucoup de référentiel centré sur les processus et les activités, comme CMMI pour les projets ou ITIL pour la production. Ce sont des référentiels de bonnes pratiques qui visent à renforcer l’efficacité des processus. La valorisation des activités permet d’aller plus loin puisqu’elle permet d’en connaitre le coût. Il est ainsi possible de déterminer le cout de l’efficacité : c’est la mesure de l'efficience.
Le niveau « activité » est propice pour déterminer si ce que l’on doit faire est fait correctement (mesure de l’efficacité) et au juste cout (mesure de l’efficience).
C’est par ce moyen qu’il est possible d’identifier des activités en sur-qualité. La valorisation des activités permet de suivre l’évolution des couts dans le temps. Cela permet surtout d’établir un cout unitaire pour chaque activité, qui est calculé en divisant le montant total de l’activité par le nombre d’output de cette même activité. A titre d’illustration voici quelques exemples de métriques pour la mesure des niveaux d’activité :
- Le cout complet des infrastructures de stockage par le nombre total de To brut acquis.
- Le cout complet des architectures X86 divisé par la puissance total des serveurs (puissance mesuré par exemple en nombre de cœur et de Ram ; voir les Uwin dans le livre blanc du CRIP)
- Le cout complet d’administration et d’exploitation des mainframes divisé par le nombre de partitions administrés ; Ici on cherche à mesurer l’efficience humaine pour le mainframe en proposant un inducteur basé sur l’existence d’un lien causal entre le nombre de partition et le nombre de JH (plus il y a de partition Z/os et plus il faut de JH)
- Le cout complet d’administration et d’exploitation des serveurs X86 divisé par le nombre d’instance de système d’exploitation. Ici aussi on propose un inducteur qui s’appuie sur l’existence d’un lien causal entre le nombre de système d’exploitation à exploiter et le nombre de JH.
N.B : Pour information concernant le dernier exemple, les mesures constatées parmi ceux ayant adopté un modèle économique de type CIGREF est de 0.8 / 0.9 jours hommes par an par OS Windows.
La mesure de l’efficience des activités incarne un réel levier d’optimisation organisationnelle encore trop rarement exploité au sein des DSI. Il permet de prendre conscience du niveau de performance actuel des activités, de mesurer dans le temps les gains opérationnels (les gains de productivité) et permet d’ajuster le niveau des dépenses au regard du volume d’activité. Par exemple, en étant capable de mesurer le nombre d’OS exploité par ETP, on est en mesure de chiffrer l’effort nécessaire en ETP et donc en K€ (selon le mix de sourcing) au regard d’une augmentation (ou baisse) prévisionnelle du nombre d’OS. Cette démarche à l’avantage d’identifier la part fixe / variable de sa structure de cout et d’en optimiser sa composition pour la rendre plus adaptable aux fluctuations du business (renforcement de la variabilité des charges).
Le cout unitaire des activités s’établit en choisissant un facteur explicatif du niveau de l’activité, ce qui permet l’imputation du cout des activités sur les services. Pour ce qui concerne le domaine de l’IT, le choix des activités et des inducteurs est grandement facilité par la présence de modèles de référence qui seront présentés ci-après.
Les services
Les limites de la démarche ABC
La difficulté d’une démarche ABC tient pour l’essentiel dans le choix des activités : pas trop nombreuses pour être en mesure de toutes les suivre mais pas trop macroscopiques non plus pour rester représentative du métier. Il est donc parfois délicat d’établir la bonne maille. L’autre aspect délicat d’une démarche ABC, c’est la définition des inducteurs. Ils doivent être disponibles durablement, être fiables, facilement mesurable et surtout être un bon indicateur du niveau de consommation de l’activité par les services (ex : le Go consommé par service pour le stockage). Ce dernier point exhibe l’importance du terme inducteur (au sens qui induit) : ce ne doit pas être de vulgaire unité d’œuvre n’ayant aucun lien avec le niveau de l’activité. On évitera donc de prendre le nombre d’utilisateur comme inducteur si ce dernier n’explique pas le niveau de l’activité.
Pour éviter cet écueil, des modèles d’activités propres à l’informatique, aux études et à la production ont été introduit. Ils reposent sur des cadres reconnus tels que CMMI pour les études ou ITIL pour la production informatique. Les modèles de couts informatiques proposent donc des activités qui sont largement adoptées au sein des entreprises quelle que soit leur taille et leur modèle organisationnel.
Actuellement, il existe 2 référentiels d’analyse et de benchmarking des coûts informatiques :
- La méthode de benchmarking des couts informatiques du Cigref
- La méthode d’analyse des coûts de la production informatique du CRIP
Le référentiel du CIGREF propose un cadre générale d’activité couvrant le Build, le Run et les processus de soutient. Le référentiel du CRIP complète celui du CIGREF en faisant un découpage plus fin des activités de la production informatique. Ce dernier est donc spécifique aux productions informatiques mais reste entièrement compatible avec celui du CIGREF.
Particularisme français
Une grande majorité des méthodes de détermination de cout et de rentabilité ont une origine anglo-saxonne (Target Costing, Direct costing, ABC, …). Ces méthodes restent très généralistes et peuvent être adaptées à tous les domaines de l’économie (industrie, finances, banques, …). Rien n’est dit quant aux spécificités des métiers des systèmes d’information. Il était donc nécessaire de proposer une déclinaison de ces méthodes pour les métiers de l’informatique afin d’avoir un modèle de costing de référence partageable. C’est précisément le but de ces 2 modèles de coûts. Cependant, avant de se lancer dans leur élaboration, nous avons cherché des démarches similaires à l’étranger afin d’éviter autant que possible de réinventer la roue mais rien de semblable ne fut trouvé. C’est à partir de ce constat que les travaux du CRIP et du CIGREF furent menés.
Nous pouvons donc affirmer que pour une fois, les français ont une longueur d’avance.
Présentation du modèle du Cigref
Le Cigref vient de publier sa dernière version en Novembre 2014. C’est la 3ième version depuis son origine en 2006.
Le Cigref identifie deux familles de processus :
- les processus liés à l’évolution, à la transformation du SI, dits « Build »,
- les processus liés à l’exécution des services, dits « Run ».
Processus du Build
Le Build regroupe les projets métiers et techniques. Ces 2 natures de projets ont pour objectifs de contrer l’obsolescence du SI.
- Les projets métiers (Business Projects - BPR) englobent les projets issus des demandes métiers et retenus dans le portefeuille de projet. Ces projets visent à améliorer les processus existants ou à développer innover de nouvelles fonctionnalités par conséquent à enrichir le patrimoine de l’entreprise.
- Les projets techniques (Technical Projects – TPR) doivent permettre de maintenir le SI à l’état de l’art des technologies d’en accroitre l’efficacité et l’efficience. Le sponsor de ces projets est donc bien la DSI elle-même et non les métiers.
Il est important de structurer les projets techniques comme les projets métiers au sein d’une démarche PPM (Project Porfolio Management) car les 2 natures de projets s’assimilent à des investissements dont il faut suivre les aspects, couts, délai, risque (à faire ou ne pas faire).
Processus Run
Le Run, quant à lui, regroupe les services récurrents comme la mise à disposition des applications et des environnements de travail à proximité immédiate des utilisateurs.
- La mise à disposition des services (Recurring services –REC) se comprend comme la part des services exploités sur un Datacenter et accessibles à distance à travers un réseau.
- Les environnements de travail utilisateurs (End User Services - EUS) se composent de l’ensemble des ressources physiques à proximité des utilisateurs tel que les PC, les téléphones fixes et portables, les imprimantes, les smartphones, les tablettes,…
Séparation du Build et du Run
Etant donné que c’est avant tout un outil de pilotage financier, le découpage est motivé par un point de vue financier. Il différencie les dépenses selon une double vision arbitrable /récurrent.
Les coûts de Run sont dit récurrents car si on veut assurer la continuité des services, il est nécessaire d’avoir des ressources et des activités liés aux opérations. Les couts du Build sont dits arbitrables car il est toujours possible de faire ou de ne pas faire un projet.On assimilera les charges du Run à des charges fixes et celle du Build à des charges variables mêmes si dans les faits c’est un peu trop simpliste.
Référentiel d’activité
Indépendance vis-à-vis des organisations
L’indépendance du modèle d’activités vis à vis de l’organisation prend ici toute son importance. En effet, on a souvent tendance à assimiler les coûts de Run aux coûts de la Production informatique et les coûts de Build aux coûts des départements Études. Même si à grosse maille, c’est une analogie acceptable dans le détail ce n’est pas complétement exact. En effet certaines activités pouvant être de la responsabilité de la Production sont étroitement liées aux projets et, à l’inverse, d’autres activités relevant typiquement de la responsabilité des Études se trouvent incluses dans les coûts Run. Voici ci-dessous quelques exemples qui illustrent le clivage entre le découpage organisationnel et processus.
Cas des activités de recettes et intégrations (PROTST : Project Test dans le modèle du Cigref): Les activités qui concourent in-fine à garantir l’aptitude fonctionnelle et technique d’une application (Qualification, recette, intégration, …) et qui se trouvent souvent dans le périmètre de responsabilité de la Production informatique sont, en fait, des activités liées à un projet : Il n’y a pas d’intégration ni de recettes s’il n’y a pas de projet. Par conséquent, même si l’activité dite de Qualification/ Recette est assurée par des ressources de la Production, il convient d’associer cette activité à un projet. Un projet est une succession d’activités (avant-projet, développement, pilotage, etc.) et l’activité recette / intégration constitue bien une étape du projet. C’est donc bien une activité du Build !
Cas des activités études: A contrario, certaines activités assurées par des ressources venues des départements Études sont positionnées dans le RUN. Á ce titre toutes les activités qui concourent au maintien en conditions opérationnelles des applications assurées par des départements Études ne sont pas des coûts de Build mais bien des coûts de Run. On y trouve pour l’essentiel la maintenance corrective, mais aussi les activités de soutien fonctionnel aux utilisateurs, les travaux de suivi d’exploitation, de diagnostics et d’analyse des incidents applicatifs (TP et batch).
Cas du Run Etudes : Les activités de MCO assurées par les départements Études sont comprises dans les coûts récurrents du « RUN » ! Pour obtenir le coût complet d’une application, il convient donc de ne pas oublier les charges liées à ces activités, charges pourtant externes à la Production informatique.
Pour ne pas considérer les coûts de la Production comme un ensemble monolithique difficilement compressible, il est recommandé d’isoler les projets techniques (installations d’infrastructures, montées de versions,…). On introduit ainsi un levier d’arbitrage dans les coûts de Production en isolant et en priorisant les projets techniques en fonction de l’urgence et des contraintes budgétaires. Un seuil de « significativité financière » sera défini (en K€ et/ou en JH) et laissé à la discrétion de chaque organisation pour distinguer ce qui relève de l’exploitation courante de ce qui constitue un projet.
Les projets techniques de la production informatique appartiennent bien au Build !
Ces exemples montrent précisément que les frontières entre Build et Run ne sont pas calquées toujours et forcément sur les organisations ni sur les périmètres de responsabilité des Études et de la Production. Le point de vue adopté pour le modèle économique n’est pas toujours exactement superposable au modèle organisationnel d’une DSI !
Le modèle du Cigref pose donc les fondations d’un modèle de costing des services informatiques avec 3 strates essentiels pour la détermination du niveau de performance économique d’une DSI :
- Les ressources
- Les activités
- Les services
Pricing et Marketing de la DSI
Bien qu’adossé à un modèle ABC où 3 niveaux sont définis, Il convient d’en d’ajouter un 4ième pour la vue client. Cette étage adresse l’aspect refacturation des services alors qu’un modèle ABC se « cantonne » à la détermination des coûts de revient.
Cette étage mis en évidence dans le livre blanc du CRIP (voir clients métiers et clients DSI) permet de positionner la DSI comme un fournisseur de services avec une tarification propre à l’usage (Service Gold, Silver, Bronze, PC VIP, etc.…). Cette approche permet de bien discerner 2 aspects souvent confondus au sein des DSI à savoir le Costing d’une part et le Pricing d’autre part.
Un modèle de « pricing » permet de s’affranchir des variations de couts des services liés par exemple au poids unitaire des charges fixes ou à la forte variabilité de certaines activités (par exemple la maintenance corrective).
En définissant un prix standard, il est possible de construire une logique de facturation plus simple, plus compréhensible pour les clients car décorrélée des inducteurs techniques d’activités.
Le modèle économique procure une aide précieuse pour la construction du modèle de facturation car il est possible de mettre en relief les marges (ou pertes) service par service ou en global.
L’écart entre le cout de revient et le prix de facturation est ajusté en fonction des stratégies de facturation (facturation à l’€ / l’€ pour un GIE ; facturation avec marge ; facturation avec perte globalement ou service par service) et en procédant à des révisions tarifaires périodiques pour effacer les bonis ou malis.
L’étage Client permet d’assoir le mix marketing de la DSI. Si on définit le mix marketing comme les 4P pour :
- Product – Quels services et produits délivrés aux clients ?
- Promotion – Comment la DSI communique la plus-value de ses services
- Price –La valeur du service est-elle en adéquation avec son prix ?
- Placement – Où les produits et services rencontrent-ils les clients?
Alors la disponibilité d’un modèle économique avec la vue Clients vous permet de répondre à l’axe Product (c’est le rôle du catalogue de service) et à l’axe Price. Déjà 50% de la démarche faite !
Présentation du modèle du Crip
Le modèle du CRIP prolonge le modèle du Cigref. Le CRIP (Club des Responsables d’infrastructure et de production) aborde toutes les problématiques propres aux opérations, au Run. Le CRIP a poursuivi le modèle du Cigref en réalisant un focus sur les activités propres à une production informatique.
Il propose un modèle d’activité qui couvre l’ensemble des tâches requises pour exploiter et administrer les diverses technologies que l’on peut rencontrer sur un Datacenter. Le modèle regroupe les activités au sein de centres technologiques. Le modèle du CRIP est complété par les activités transverses aux centres technologiques qui sont pour l’essentiel les activités ITIL qui sont financièrement significatives (incidents, problèmes, changements, gestion des configurations, …). On parle de seuil de significativité financière pour distinguer les activités prépondérantes dans un modèle financier de celles prépondérante dans une démarche qualité : Toutes les activités importantes dans une approche qualité (comme ITIL) ne le sont pas forcément dans une approche financière (type ABC). En faisant l’analogie avec le pilotage d’un avion, les quelques minutes prises avant le décollage pour faire le checklist de contrôle sont certainement très importante pour la sécurité du vol mais vis-à-vis du cout du vol reste certainement très marginales et donc surement peu intéressantes. Il faut donc incorporer les seules activités ITIL qui sont significatives d’un point de vue financier !
Centres technologiques
Un centre technologique a pour vocation de regrouper l’ensemble des dépenses liées à une technologie. Le CRIP distingue 2 natures de ressources financières qui ensemble composent le cout d’une technologie :
- Les couts du capital technique : C’est le total des dépenses d’acquisition liées aux infrastructures.
- Le cout du capital humain : C’est l’ensemble des ressources humaines (interne et externe) requis pour le bon fonctionnement de la technologie.
Les activités du modèle liées aux acquisitions d’infrastructure ont un code qui débute par « INF », exemple INFSTO pour les infrastructures de stockage, INFETU pour les environnements de travail utilisateurs.
Le capital humain est évalué à l’aide d’activités d’exploitation et d’administration. Le sigle de ces activités débute par « EXP » pour exploitation.
Les 3 derniers caractères identifient le centre technologique. La somme des couts d’activité « INF » et « EXP » compose le cout complet d’un centre technologique. Le poids relatif de la matière grise versus du matériel dans le total d’un centre technologique (ou plus globalement au sein d’une production) permet déjà de mettre le curseur sur les zones où les enjeux financiers sont les plus importants. Et en règle général pour une production informatique la répartition entre matière grise et infrastructure est respectivement 70% / 30% !
Le modèle du CTIP propose un découpage en 21 centres technologiques.
Code |
N° |
Intitulé |
HEB |
1 |
Hébergement |
RDL |
2 |
Réseau Data LAN |
RDM |
3 |
Réseau Data MAN |
TEL |
4 |
Téléphonie |
STO |
5 |
Stockage/SAN |
SAU |
6 |
Sauvegarde/Archivage |
MAI |
7 |
Mainframe |
UNI |
8 |
Unix propriétaires |
WLI |
9 |
Windows Linux Virtualisation |
MIN |
10 |
Mini-informatique et autres
plates-formes (AS400, DEC, VMS, etc.) |
BDD |
11 |
Bases de données |
EDI |
12 |
Éditique |
SEC |
13 |
Sécurité |
ETU |
14 |
Environnement de Travail
Utilisateur |
MID |
15 |
Middlewares applicatifs et
échanges en mode message |
FLU |
16 |
Echanges en mode flux |
PIL |
17 |
Supervision, pilotage,
monitoring |
DEC |
18 |
Décisionnel/BI |
DTR |
19 |
Environnements logiciels de
développement, tests et recettes |
OPM |
20 |
Outils de partage mutualisés,
outils collaboratifs, workflows, BPM, |
vidéoconférence d’entreprise |
||
GED |
21 |
GED/Dématérialisation
(intègre archivage légal) |
Le catalogue de service CRIP
Le modèle du CRIP reprend à l’identique le structure du catalogue de service du CIGREF. On retrouve donc pour le périmètre de la production informatique :
- Les environnements de travail utilisateurs (EUS)
- Les services récurrents (REC)
Lors de la publication du livre blanc, le CRIP a identifié des services techniques (voir Notion de « services techniques ») au sein des services récurrents comme étant une famille de services distincts des services métiers. Le Cigref a repris cette notion dans sa version 2014, en parlant de services techniques intermédiaires.
Nous ferons un focus particulier sur ces différentes familles de services plus bas dans un chapitre consacré aux catalogues de service des 2 modèles. On parlera notamment :
- Des services génériques
- Des services techniques intermédiaires
- Des services techniques finaux
Les familles de services du catalogue CRIP et CIGREF
Services techniques
Les 2 modèles adoptent une structure similaire pour le catalogue de service. Dans son livre blanc le CRIP a identifié des services un peu particulier, nommés services techniques afin d’éviter des déversements d’activité à activité et pour souligner le cout complet de certains services transverses utiles aux services métiers. Par exemple, pour obtenir le cout de la sécurisation du SI, on crée un service technique qui tire l’ensemble des consommations des activités liés à la sécurité mais aussi des autres activités. Ceci permet d’obtenir le cout total de la sécurisation du SI (avec les serveurs, le stockage, le réseau, etc.) et ensuite de pouvoir en répartir le cout sur les applications métiers qui en bénéficient. Cette notion est reprise dans la dernière version du modèle du CIGREF sous le terme de « service technique intermédiaire ».
Afin d’être complétement clair sur ce point, voici ci-dessous les familles de services identifiés.
Services génériques :
Les services métiers sont par définition propres à chaque entreprise, cependant il existe un ensemble commun de services. On les trouve dans REC et EUS. Pour la famille EUS, nous pouvons identifier les postes de travail, les portables, les smartphones, les tablettes, les imprimantes, etc. Pour la famille REC, nous pouvons citer : la messagerie d’entreprise, les serveurs d’impressions, les partages bureautiques, les infrastructures pour les postes virtuels (type VDI), etc.
Les coûts de ces services peuvent être consolidé avec les couts des services EUS pour obtenir un TCO du poste de travail (cout des services EUS et cout des services REC). Les services génériques sont définis dans le modèle du CRIP.
Services techniques intermédiaires :
Ces services permettent de mettre en exergue les couts de certains services transverses nécessaires au bon fonctionnement des services visibles par les clients. Le tableau ci-dessous récapitule les différents services techniques identifie par le modèle du CIGREF et du CRIP.
Libellé
CRIP |
Libellé
CIGREF |
Remarques |
Mise à disposition d’un centre de secours informatique |
Plate-forme de
sécurisation du SI |
Attention au
libellé Sécurisation du SI pour CIGREF = PSI pour CRIP |
Inexistant |
Plate-forme
de virtualisation |
Consommé
directement par les VMs dans le modèle CRIP |
Mise à disposition des
environnements hors
production |
Plate-forme Hors production |
|
SI du SI |
SI
du SI |
|
Sécurisation du SI |
Inexistant |
Service lié à la sécurité logique du SI. A ne confondre
avec Sécurisation du SI du Cigref! |
Mise à disposition du
Décisionnel & BI |
Inexistant |
|
Mise à disposition de
l’éditique de masse |
Inexistant |
|
Mise à disposition de la
GED/ Dématérialisation |
Inexistant |
|
Mise à disposition des
outils collaboratifs |
Inexistant |
|
Mise à disposition de
poste de travail virtuel |
Inexistant |
|
Mise à disposition de
services techniques de
gestion de flux |
Inexistant |
|
Mise à disposition de
services Middleware |
Inexistant |
N.B : Il est possible d’identifier un (des) service(s) de réserve de capacité par centre technologique si l’on souhaite valoriser les dépenses non encore consommées (par exemple les Go libres).
Services techniques « informatiques :
Ce terme désigne les services qui agrègent des infrastructures pour en faire un produit « informatique » qui intéresse donc des clients de type DSI. Nous identifions 3 types de services techniques :
- Le SAAS : c’est l’équivalent des services REC car les applications métiers sont bien assimilables à du « software as a service ».
- Le PAAS : un service de type PAAS agrège tout ou partie des activités d’infrastructures (serveurs, réseau, stockage, pilotage, etc…). Le périmètre d’activité dans le cout du service PAAS est laissé à la discrétion de chacun.
- L’IASS : Idem pour la mise à disposition d’infrastructure.
ll est important de noter que le total des dépenses aux niveaux activités se réparti t sur le total des couts de tous les services de toutes les familles. Par exemple, le cout total des serveurs X86 se déversent sur le prorata de consommation serveur des applications métiers, des serveurs utilisés pour le PASS et des serveurs utilisés pour l’IAAS.
N.B : Il ne faut pas confondre les services techniques informatiques avec les activités « External Services » (EXTSRV) qui sont des activités utilisées pour imputer les achats par la DSI de type « as a service ».
Similitudes et différences entre modèle Cigref et CRIP
Similitudes
Clivage entre récurrents et arbitrable
Valorisation des activités et des services identiques
Les 2 modèles partagent les mêmes modalités d’affectation des charges et des investissements. Les activités et les services doivent être valorisés selon à minima 2 vues :
- Une vue Cash out plus propice pour la gestion des flux de trésorerie
- Une vue P/L plus en phase avec une vision de type compte de résultat
Périmètre de charge
Les 2 modèles insistent sur la prise en compte de toutes les charges du périmètre à analyser notamment les charges de structures propres à la DSI (RH, Comm., Achat, juridique, …).
Cependant, pour des raisons des benchmarking cohérent, le CIGREF souligne que les charges à intégrer concernent celles de la DSI hors MOA et AMOA. Il est toujours possible d’avoir un périmètre plus large lors de la construction du modèle économique mais il faut être vigilant à pouvoir facilement isoler les charges exclues du périmètre CIGREF. Etant polarisé sur la production, les charges MOA et AMOA ne sont pas dans le périmètre du modèle du CRIP, à priori !
Séparation entre dépenses de matière grise et autres dépenses
Depuis la version 2014 du modèle du CIGREF, la nature des dépenses de chaque activité est homogène. Une activité ne peut contenir que des dépenses :
- soit liés à des activités humaines
- soit liés à l’acquisition des matériels et logiciels.
Ce principe de séparation est identique à celle que l’on trouve dans les centres technologiques du modèle du CRIP.
Différences
Les macro-activités
Une macro activité est le regroupement de plusieurs activités. Elles sont généralement utilisées comme niveau pivot pour la réalisation des benchmarks ou pour la communication. A la notion de macro-activité du CIGREF correspond la notion de centres technologiques du CIGREF. Cependant, le niveau macro-activité n’est pas homogène entre le CIGREF et le CRIP.
Pour le CRIP, l’unité d’agrégation est le centre technologique composé d’une activité acquisition d’infrastructure et d’une activité humaine d’exploitation. Ce découpage facilite le pilotage des dépenses autour des technologies communément trouvées dans une production (Unix, X86, Virtualisation, Stockage, …), en y affichant le cout des infrastructures, le cout humain et le cout total.
Sur le périmètre commun aux 2 modèles à savoir le RUN, on observe des différences sur les axes d’agrégation des activités. Le CIGREF définit des macros activités qui sont centrées sur :
- des technologies au nombre de 6 (Server, Storage, Network, Telecom, Security, DataCenter)
- des activités spécifiques aux acquisitions logicielles : Macro activité Software (MIDWAR).
- des activités humaines : Macro activité « Operations » (OPERAT)
Le modèle du CRIP ne propose pas d’isoler les couts matériels des couts logiciels, même s’il est toujours possible de le faire en créant les activités ad-hoc au sein du « INF » d’un centre technologique. Cette séparation n’existe pas globalement dans le modèle du CIGREF excepté pour 2 macro-activités : SERVER et MIDWAR.
MIDWAR est déclinée en activité par architecture de server (SOFX86, SOFUNI, SOFMAI, …). Le CRIP ne fait pas de distinction entre les plateformes (sauf pour Mini et Mainframe) mais par contre décline les middlewares en différentes technologies (SGBD, Middleware applicatif, Décisionnel & BI, Flux asynchrones, …). Il est toujours possible d’affiner les centres technologiques en ajoutant des activités par type de plate-forme pour différencier les couts par plate-forme comme à l’image du découpage MIDWAR du CIGREF.
Dans le modèle CIGREF, les activités humaines sont assemblées dans la macro-activité OPERAT. Le découpage en activité des opérations n’est pas systématiquement aligné sur le découpage des activités liées aux technologies. Par exemple, les activités de STORAG (INFSTO et INFARC) n’ont pas d’équivalent dans les activités OPERAT (elles sont fondues dans OPEINF, on ne trouve pas de OPESTO par exemple) contrairement aux réseaux ou aux environnements utilisateurs (INFEUS et OPEEUS).
La granularité des activités du modèle du Cigref est plus macro et est idéal pour un premier niveau de pilotage d’ensemble d’une DSI (Build et Run) alors que le modèle du CRIP permet d’avoir un pilotage plus pointu sur les seules activités de la production. Ainsi il est possible d’avoir le cout total de possession du mainframe en agrégeant les activités INFMAI et EXPMAI, ce qui n’est pas possible avec le modèle du CIGREF, le cout humain d’exploitation du mainframe étant disséminé dans OPEINF. Vous ne pourrez pas savoir si le mainframe coute réellement plus cher que le distribué avec le modèle du Cigref alors que c’est possible avec le modèle du CRIP.
N.B : Pour information et pour un même périmètre, le poids du mainframe vis-à-vis du distribué au sein d’une production n’est pas toujours en défaveur du mainframe : le cout humain du distribué compensant les coûts matériels et logiciels du mainframe.
Pour vous aider à vous y retrouver voici une matrice de correspondance entre les activités Cigref 2014 et CRIP 2013 :
Macro activité CRIP - Centre technologique |
Activité CRIP |
Activité CIGREF |
Macro - activité CIGREF |
Commentaires |
CT 01 HEB : Hébergement |
INFHEB |
INFDAT |
DATCEN |
|
EXPHEB |
OPEDAT |
OPERAT |
||
CT 02 RDL : Réseau Data LAN DataCenter |
INFLDC |
INFDNW |
NETWOR |
|
EXPLDC |
OPENET |
OPERAT |
||
CT 03 RDM : Réseau Data MAN et WAN |
INFWAB |
INFDNW |
NETWOR |
|
EXPWAN |
OPENET |
OPERAT |
||
CT 04 TEL : Téléphonie |
-- |
|||
Téléphonie Fixe |
INFTEF |
INFVNW |
NETWOR |
CIGREF : INFVNW concerne INF Voix |
INFVDB |
TELECO |
CIGREF : INFVDB concerne
Abonnements et consommations |
||
EXPTEF |
OPENET |
OPERAT |
||
Téléphonie Mobile |
INFTEM |
INFVNW |
NETWOR |
CRIP : Distinction entre Tel fixe
et tel Mobile |
INFVDB |
TELECO |
|||
EXPTEM |
OPENET |
OPERAT |
||
CT 05 STO
: Stockage SAN et NAS |
INFSTO |
INFSTO |
STORAG |
|
EXPSTO |
OPEINF |
OPERAT |
||
CT 06 SAU : Sauvegarde et Archivage |
INFSAU |
INFARC |
STORAG |
|
EXPSAU |
OPEINF |
OPERAT |
||
CT 07 MAI : Mainframe |
INFMAI (INFMHD) |
INFMAI |
SERVER |
CIGREF : Distinction du Soft et du
hard |
INFMAI (INFMSW) |
SOFMAI |
MIDWAR |
CRIP : distinction possible au
niveau sous activité |
|
EXPMAI |
OPEINF |
OPERAT |
||
CT 08 UNI : Unix propriétaires |
INFUNI |
INFUNI |
SERVER |
|
EXPUNI |
OPEINF |
OPERAT |
||
CT 09 WLI
: Windows, Linux, Virtualisation x86 & x64 |
INFWLI |
INFX86 |
SERVER |
|
INFVIR |
SOFVIR |
MIDWAR |
||
EXPWIN |
OPEINF |
OPERAT |
CRIP : distinction des activités
humaines par techno |
|
EXPLIN |
OPEINF |
OPERAT |
||
EXPVIR |
OPEINF |
OPERAT |
||
CT 10 MIN : Mini-informatique et autres
plates-formes (AS400, DEC, VMS, etc.) |
INFMIN |
INFMIN |
SERVER |
CIGREF : Distinction du Soft et du
hard |
SOFMIN |
MIDWAR |
|||
EXPMIN |
OPEINF |
OPERAT |
||
CT 11 BDD : Bases de données |
INFBDD |
SOFMIN |
MIDWAR |
le C.T du CRIP est éclaté dans
plusieurs macro-activité du CIGREF |
SOFUNI |
MIDWAR |
|||
SOFX86 |
MIDWAR |
|||
EXPBDD |
OPEINF |
OPERAT |
||
CT 12 EDI : Éditique |
INFEDI |
Hors périmètre |
-- |
CIGREF : l'éditique de masse est
hors périmètre |
EXPEDI |
Hors périmètre |
-- |
||
CT 13 SEC : Sécurité |
INFSEC |
INFSEC |
SECURI |
CIGREF : Distinction du Soft et du
hard |
SOFSEC |
SECURI |
|||
EXPSEC |
OPESEC |
OPERAT |
||
CT 14 ETU : Environnement de Travail Utilisateur |
INFETU |
INFEUS |
EUSDEV |
CIGREF : Distinction du Soft et du
hard |
SOFEUS |
EUSDEV |
|||
INFBUR |
INFDNW |
NETWOR |
||
EXPETU |
OPEEUS |
OPERAT |
||
CT 15 MID : Middlewares applicatifs et échanges en
mode message |
INFMID |
SOFUNI |
MIDWAR |
|
SOFX86 |
MIDWAR |
|||
EXPMID |
OPEINF |
OPERAT |
||
CT 16 FLU : Echanges en mode flux |
INFFLU |
SOFMIN |
MIDWAR |
CIGREF : Distinction du Soft et du
hard |
SOFUNI |
MIDWAR |
|||
SOFX86 |
MIDWAR |
|||
EXPFLU |
OPEINF |
OPERAT |
||
CT 17 PIL : Supervision, pilotage, monitoring |
INFPIL |
SOFTEC |
DEDSOF |
|
EXPPIL |
OPEMON |
OPERAT |
||
CT 18 DEC : Décisionnel/BI |
INFDEC |
SOFMIN |
MIDWAR |
le C.T du CRIP est éclaté dans
plusieurs macro-activité du CIGREF |
SOFUNI |
MIDWAR |
|||
SOFX86 |
MIDWAR |
|||
EXPDEC |
OPEINF |
OPERAT |
||
OPEANA |
OPERAT |
|||
CT 19 DTR : Environnements logiciels de
développement, tests et recette |
INFENV |
SOFDTA |
DEDSOF |
|
EXPENV |
OPEDTA |
OPERAT |
CRIP: Pas de dstinction entre prod
et Hors Prod car considéré comme même activité. |
|
DEVSUP |
PROENA |
|||
CT 20 OPM : Outils de partage mutualisés, outils
collaboratifs, workflows, BPM, |
INFOPM |
SOFENA |
DEDSOF |
|
EXPOPM |
OPEINF |
OPERAT |
||
CT 21 GED : GED/Dématérialisation (intègre archivage
légal) |
INFGED |
?? |
-- |
|
EXPGED |
OPEINF |
OPERAT |
||
Autres |
ACQRO |
SOFBUS |
DEDSOF |
|
Pas définie |
INFAPP |
SERVER |
CIGREF : Regroupement des
appliances dans une activité même s’il concerne un centre techno |
|
ACQPRO/ SI du SI |
SOFTEC |
DEDSOF |
||
Pas définie |
EXIAAS |
EXTSRV |
||
Pas définie |
EXPAAS |
EXTSRV |
||
Pas définie |
EXSAAS |
EXTSRV |
||
Pas définie |
OPEDRP |
OPERAT |
Activité non définis
explicitement, seul le service l'est |
|
Pas définie |
OPEAPP |
OPERAT |
Hors périmètre CRIP |
|
Activités ITSM |
REFOPE |
OPEENA |
Gerstion des configurations, des
changements, … |
|
Activités ITSM |
SLAMGT |
OPEENA |
Gestion de la relation client |
|
SUPLE1 |
SUPLE1 |
INCDEM |
Activité transverse aux CT. |
|
SUPL23 |
SUPL23 |
INCDEM |
Activité transverse aux CT. |
|
Pas définie |
CORMAI |
CORMAI |
Hors périmètre CRIP |
|
Pas définie |
PRODEP |
DEDSOF |
Activité transverse aux CT. |
Compatibilité des axes des 2 modèles
Il est possible d’aligner les 2 modèles en :
- éclatant les activités de type INF dans le modèle CRIP pour séparer le logiciel (SOF) du matériel (INF). Ceci concerne les centres technologiques qui sont dans la macro-activité MIDWAR
- en ajoutant un attribut sur chaque activité du modèle le plus fin, celui du CRIP, pour les relier aux macro-activités du modèle CIGREF conformément à la matrice ci-dessus.
Il ainsi possible d’agréger les couts d’activités selon les axes qui convient soit par centre technologique, soit par macro-activité CIGREF et de rendre ainsi compatible les 2 modèles.
Conclusions
En se basant sur ces référentiels, il est possible de construire un système de pilotage économique de la DSI. Au-delà de l’application stricte d’une démarche de cout complet de type ABC, il est important de noter qu’un pilotage efficace passe par un renforcement de l’analyse au niveau :
- Des dépenses : en dégageant les profils de dépenses par technologie, par nature (infra ou humain) par type de contrat (interne, régie, forfait, …), par pole budgétaire, etc.
- Des activités : Au-delà de l’organisation, mesurer les moyens financiers consommés par les processus permet d’accroitre la mesure de l’efficacité en mesurant l’efficience et ainsi être sûr que l’intensité financière est proportionnelle aux objectifs de l’activité.
- Des services : L’estimation des couts de revient des applications et des projets permet de responsabilité les métiers. Les conséquences financières de leur choix sont traçables jusqu’au niveau des services délivrés.
Il est important d’avoir une vision de la consommation des dépenses par activité et des activités par les services. Même à grosse maille, un tel dispositif permet d’avoir une compréhension de la mécanique de consommation de dépenses. Ceci permet de réduire les surconsommations qui sans cela resteraient inconnues et permet de mieux anticiper les besoins futures de dépenses en se dotant d’abaque de consommation tant au niveau des activités qu’au niveau des services.
Aucun commentaire:
Enregistrer un commentaire