Les composantes du processus de production du service informatique
Service Level Management ou gestion du niveau de service
Ce sous-processus est dédié à la définition du contrat de service (ou contrat d’engagement réciproque – CER – ou encore service layer agreement -SLA -). Tout SLA doit être explicitement lié à des OLA (Operation Level Agreement) qui décrivent les engagements pris en interne de la production pour gérer les incidents (les « SLA internes », en résumé : quels sont les fournisseurs de la production ?).
Il contrôle également le niveau de service effectivement rendu. Le contrat est établit entre les utilisateurs (souvent une maîtrise d’ouvrage représentant ces utilisateurs) et le(s) producteurs du service. La tendance actuelle des entreprises est d’avoir une négociation tri-partite Client / Responsable Client (appartenant à la DSI) / Service de production.
ITIL utilise les notions de :
- catalogue des services (quels sont les services standard proposés par la DSI – hélas pas les éléments standard pour gérer l’exploitation d’un ou plusieurs composants techniques nécessaires à la production du service final à l’utilisateur)
- expression de besoins utilisateur,
- validation des niveaux de service requis (Service Level Requirement – SLR),
- contrats de service (Service Level Agreements – SLA),
- engagements de prestations en interne (Operational Level Agreements – OLA) ou en externe avec les contrats de sous-traitance (Underpinning Contract – UC)
- Plan Qualité (Service Quality Plan – SQP)
Etablir un contrat de service est un gros travail, surtout si on veut vraiment en faire un outil pertinent ; trop d’entreprises ont encore une approche de « mal nécessaire pour avoir bonne conscience ». Ce contrat est un outil indispensable pour faire le lien entre le client final du service, la production de ce service et la gouvernance générale du SI. C’est à travers ce contrat que l’on peut mesurer si la DSI propose autre chose qu’en ensemble de machines et de logiciels qui font « un truc ».
Capacity Management ou gestion des capacités du SI
Cet élément a pour objet de prendre en compte :
- les objectifs généraux de l’entreprise : ce que l’on souhaite délivrer dans le futur (Business Capacity Management).
- l’organisation de la production : la façon dont les services sont actuellement fournis (Service Capacity management).
- l’infrastructure : les moyens à mettre en œuvre pour pouvoir fournir les services (Resource Capacity Management).
Le capacity management inclut donc à la fois la technique (capacity planning) et le business ; il cherche à évaluer si les moyens disponibles permettent de rendre le service demandé par la société. C’est sans doute dans ce sous-processus que les premiers impacts métier d’un schéma directeur se feront sentir : hélas c’est dans la réalité plus un élément de constat que de prévision pertinent.
Financial Management for IT Services ou gestion financière du SI
Cet élément non technique est essentiel lorsqu’il s’agit de justifier le budget de la DSI. ITIL insiste sur les aspects de rentabilité de l’existant et le détail de l’attribution des moyens financiers. On constate en entreprise que les coûts immédiats investissement et fonctionnement sont en général bien compris (à défaut d’être bien acceptés !), mais que la notion de coût du risque (lié à l’interruption de service) n’est souvent prise en compte que dans les entreprises naturellement sensibles aux risques à fort impact (placements financiers par exemple). Cet écueil doit impérativement être évité si le DSI veut disposer d’arguments pérennes lors de la prise de décision sur les investissements.
C’est ici que l’on retrouve les outils comme le calcul de ROI (Return Of Investment), de TCO (Total Cost of Ownership), de NPV – Net Present Value (coûts/gains/bénéfices année par année et si les bénéfices arrivent beaucoup plus lentement que les dépenses c’est qu’il y a un problème) ou encore le TEI (Total Economic Impact) qui lui essaie de tenir compte des risques. Le passage en SaaS semble remettre profondément en cause les outils de gestion financière du SI dans le sens où l’investissement disparaît progressivement au profit du fonctionnement.
Availability Management ou gestion de l’efficience du service
La gestion de la disponibilité est le sous-processus qui met en place une méthode (que c’est rare en production informatique !) et des outils qui permettent de mesurer et de piloter la production pour s’assurer de la conformité de ce qui est produit par rapport au SLA. Il cherche également à établir les raisons des dysfonctionnements.
IT Service Continuity Management ou gestion de la continuité du service
Le but est ici de définir, receter et mettre à jour les plans et/ou procédures de sauvegarde, de haute disponibilité et de reprise d’activité (PRA). La prévention doit également être prise en compte.
On notera de manière générale qu’il est nécessaire de distinguer Plan de reprise d’activité et Plan de Reprise d’Architecture : j’ai pu constater trop souvent que l’un est « vendu » à la place de l’autre.
Configuration Management ou gestion des configurations
Ce processus a besoin d’un outil particulier, le Configuration Management Database (CMDB) qui trace les changements et leurs différentes étapes. Le but est non seulement de garder la trace des configurations, mais au-delà de comprendre les relations au sein de l’architecture technique.
On notera que ce problème de dépendance n’est pas seulement technique : combien de service informatique sont-ils confrontés aux palabres d’experts dégageant leur responsabilité lorsqu’un autre composant intervient dans l’analyse d’un problème. La mise à jour de la CMDB est un véritable écueil : idéalement, l’information ne devrait jamais être stockée dans une base, mais l’information devrait être captable en temps réels, ce qui est envisageable avec un haut niveau d’industrialisation.
