LOGEON VincentTSGERI 2011/2012

Documentation ITIL

1/27

Table des matières3.ITIL....................................................................................................................................................3Le centre de services............................................................................................................................3

1.les points de contact informatique/métier :...................................................................................32.les objectifs du centre de services.................................................................................................43.L'organisation du centre de service ..............................................................................................54.Technologies du centre de services ..............................................................................................65.L'intégration dans l'environnement ..............................................................................................76.Le pilotage du centre de services .................................................................................................7

La gestion des incidents .......................................................................................................................9Rôles et responsabilités :..................................................................................................................9Priorités :..........................................................................................................................................9Méthode et outils :...........................................................................................................................9La gestion des incidents :.................................................................................................................9L'objectif du processus « gestion des incidents » :........................................................................10La gestion des problèmes...............................................................................................................16La gestion des configurations........................................................................................................19

2/27

3.ITIL

Le centre de services(pdf : itil4)

Objectif : Être le point de contact unique des utilisateurs et une interface entre les processus.

Le centre de services ou service desk est le véritable cœur de la gestion des services informatiques.C'est le point de contact unique.

Le centre de service est l'espace de la relation client :-Il est la principale interface entre la DSI et les utilisateurs.-Il est le garant du respect des engagements pour la DSI

Mais il est également un outil de performance pour la DSI : -Il pilote la gestion des événements (incidents et demandes ) et fournit une interface avec les

processus de production.-Il est une plate-forme d'accueil de services destinés aux utilisateurs et fournit ainsi une

gamme de services (prestations) étendue, incluant nécessairement une approche « métier »

On peut dire qu'un bonne communication est le signe d'une organisation informatique mature et d'une relation utilisateur équilibrée.

N.B : le centre de services est une fonction au sens de l'organisation. C'est la seule unité organisationnelle décrite dans ITIL.

Lorsque l'on parle de centre de service cela sous-entend :-Écouter le client et le comprendre-Être orienté résultat-Se mettre dans à la place de l'utilisateur/client avant de prendre une décision-Être transparent sur sa capacité à faire ou à ne pas faire, en l'informant au plus tôt de toutes

dérives.

1.les points de contact informatique/métier :

-Stratégique : entre le DSI et les directions métiers, fonctionnelle et générale.-Tactique : entre l'organisation informatique et ses clients (définition des conventions de

service, reporting).-Opérationnel : au quotidien, entre l'organisation informatique et ses utilisateurs. C'est la

fonction du centre de services. La relation est bidirectionnelle.De l'utilisateur vers le centre service (appel et en sens inverse de l'organisation informatique vers les métiers (communication, information)

3/27

2.les objectifs du centre de services

Les bénéfices utilisateurs :-Facilité d'accès et lisibilité du support (point de contact unique ou SPOC, propriété de

l'incident).-Meilleur qualité des services (gain de temps par le guichet unique, pilotage par la qualité de

service).-Amélioration de la satisfaction (mesure et suivi de la qualité perçue).-Support et communication pour et sur le changement.-Approche métier.

Les bénéfices clients :-Haute qualité de support pour atteindre les objectifs métiers.-Réduction des impacts négatifs des incidents (rapidité de résolution et gestion proactive).-Aide pour identifier les coûts réels du support information.-Fourniture de données opérationnelles (incidents et demandes en cours,

volume, services, coûts).

Les bénéfices pour l'informatique :-Gestion de l'image (professionnalisme du point de contact) et amélioration de la perception

des services IT (prestations).-Perception directe des réactions positives ou négatives des utilisateurs.-Identification des opportunités métiers.-Meilleurs utilisation des ressources.-Travail en équipe, avec un objectif commun (la tenue des engagements).-Fourniture de données opérationnelles (gestion, prise de décision).

Les niveaux de maturité :

-Mode initiale : non structuré ou support couloir.-Mode réactif : hotlines, ou help desk-Mode proactif : Maîtrise (ne plus courir après les événements) ou help desk industrialisé.-Service : support fonctionnel, intègre la dimension du métier et mise en valeur de

l'utilisateur.

4/27

3.L'organisation du centre de service

Les différents types d'organisation sont :

-Centre de services local : proximité géographique rassurante mais coûteuse.

-Centre de services central : la plus performante en efficacité et efficience mais son éloignement peut provoquer certaines frustrations utilisateur telles que la barrière de la langue.

-Centre de services virtuel : il combine les avantages des deux organisations et s'adressent aux grandes organisations.

Les niveaux de support :

-Niveau 0 à 1 : il correspond à un premier contact effectué par les personnels chargés d'accueillir les appels (guichet unique). Un niveau 0 n'effectue qu'un enregistrement, un routage à la supervision technique comme un centre d'appel.

Un niveau 1 est plus technique et effectue en plus d'un qualification, une résolution en ligne dans un nombre déterminé de cas, le suivi et clôture des dossiers.

-Niveau 2 : il correspond à des interventions de personnels spécialisés par domaine. Le traitement est effectué dans le centre de services ou avec un déplacement sur site.

-Niveau 3 : il correspond à un niveau d'expertise élevé du domaine et nécessite souvent une relation directe avec le constructeur, l'éditeur ou la personne responsable de l'application ( niveau 4).

5/27

4.Technologies du centre de services

Elles concernent aussi bien l'informatique que les télécommunications. L'évolution du marché a facilité son évolution.Les principales :

-Progiciel, pour le support des processus de gestion des services.

-Outil pour faciliter les diagnostics en ligne.

-Prise de Main à Distance.

-Base de connaissances.

-Moteurs de recherche des bases indépendantes.

-Informatique décisionnelle, pour les analyses et le reporting.

Outils télécoms.

-Serveur vocal interactif (scripts vocaux, dialogue DTMF)

-Distribution automatique des appels ou ACD (gestion des files d'attente et des groupes de techniciens).

-Couplage téléphonie-informatique : identification de l'appelant et montée de page écran.

-IVR : réponse automatique personnalisable.

-Mobilité sans fil

-Voix et téléphonie sur IP

-Gestion multi-sites

-Outils de libre service, pour les incidents habituels (mots de passe oubliés).

-Workflow, pour la gestion des demandes standards.

Activité du centre de service :

-Recevoir et distribuer les appels

-Gérer les incidents et les demandes

-Informer les utilisateurs

-Analyser la satisfaction utilisateur.

-Effectuer le reporting.

Ressources Humaines :

-Turnover interne pour faire évoluer le personnel vers de nouvelles responsabilités.

-Le maintien et développement des compétences grâce à un effort de formation continue.

6/27

5.L'intégration dans l'environnement

L'accessibilité du centre de services :

-Respecter l'accessibilité convenue dans le convention de service.

-Veiller à la bonne qualité d'accueil (SBAM)

-Multiplier les canaux d'accès (téléphone, messagerie, accès web, portail internet …)

-Intégrer un support métier (organisationnel, fonctionnel).

-Informer l'utilisateur sur l'état d'avancement de l'incident ou de sa demande.

Promotion du centre de services :

-Portail utilisateurs (catalogue, indicateurs de performance...)

-Matériel marketing de présentation du centre de services (brochure)

-Évolution de la satisfaction utilisateur.

6.Le pilotage du centre de services

Supervision de l'activité :

-Suivi du niveau de service offert aux utilisateurs (traitement des incidents, ordonnancement et traitement des demandes, escalades...)

-Gestion et animation des ressources humaines.

-Gestion des situations de crise (arrêt d'un serveur, arrêt d'une application...)

-Gestion journalière des encours par domaine.

-Gestion des tableaux de bord (reporting jour, semaine, mois, an.)

-Optimisation des procédures.

-Suivi de la satisfaction des utilisateurs.

7/27

Indicateurs clés de performance d'un centre de services :

-Contrôle et résolution des incidents.

-Interface quotidienne entre la DSI et les utilisateurs.

-Support à l'utilisation du SI du point de vue des métiers.

-Information pour la gestion de la qualité de service.

-Réduction du nombre des incidents.

-Élimination des appels perdus ou mal orientés.

-Meilleur utilisation des équipes informatiques.

-Qualité de résolution.

-Réduction du coût d'appel.

-Identification des besoins en formation.

-Identification pour la gestion de la qualité de services.

-Fourniture des informations sur la qualité de service.

-Production d'un base d'informations sur le fonctionnement du SI

-Qualité de l'interface entre la DSI et les utilisateurs.

-Satisfaction des utilisateurs.

8/27

La gestion des incidents

(pdf : itil5)

Objectif : Restaurer le niveau de service avec le client-utilisateur, aussi vite que possible.Un incident est un événement qui n'épargne personne. L'éradiquer complètement de

l'entreprise est une utopie.

Il est désagréable au quotidien mais est souvent la source d'une richesse inestimable sur le comportement et la connaissance de nos systèmes.

Rôles et responsabilités :-le centre de service est propriétaire de tous les incidents

-la résolution d'un incident est sous la tutelle d'un responsable. Ne faites pas de votre client, ou utilisateur, votre meilleur superviseur d'incidents. Faites de votre client un allié en l'informant au plus tôt.

Priorités :-pilotez par la priorité car il vaut mieux un joint qui fuit qu'une rupture de canalisation. Il

faut réparer dans un premier temps et ensuite durablement une fois le dépannage fait et la solution trouvée. Le but est de préserver la production.

Méthode et outils :-traçabilité est synonyme d'efficacité. Si tous les incidents sont enregistrés, ils peuvent

faciliter la compréhension des suivants.

-historisation des erreurs connues et des problèmes est un réel plus pour la gestion des incidents et le centre des services. Se créer un point de départ si aucun précédent.

-mesurer préalablement l'applicabilité des processus ITIL, afin de faire évoluer une organisation

La gestion des incidents :-Caractériser le motif

-Réparer en utilisant une solution provisoire

-Identifier la cause et trouver une solution pérenne

9/27

-Mise en œuvre de la solution retenue

-Evaluer la qualité de la solution mise en place après utilisation.

N.B : technique mnémotechnique, utiliser le mot CRIME

L'objectif du processus « gestion des incidents » :

objectif principal : restaurer le niveau de service avec le client-utilisateur, aussi vite que possible et ce en accord avec ce qui a été convenu (convention de service-SLA)

-restaurer ne veut pas dire la cause. Ceci est l'objet du processus de gestion des problèmes

-si nous devions caractériser à cet instant l'état d'esprit d'un producteur soumis à un incident, nous retiendrions un seul terme : contournement

-nous sommes dans le cas d'un processus réactif (niveau 2 de maturité).

N.B : ITIL considère qu'une demande utilisateur peut se traiter de la même manière qu'un incident. Il faut cependant reconnaître que, en particulier dans le secteur industriel, il donne très

souvent lieu à l'implémentation de deux processus distincts où les demandes sont souvent incluses dans le processus de gestion.

Le quoi ? Ou la définition d'un incident :

Tout événement, qui ne fait pas partie des opérations standards, pouvant provoquer une interruption de service ou altérer sa qualité.

-la littérature technique et le métier des entreprises ont apporté d'autres termes pouvant être à priori des synonymes. On trouve par exemple : non-conformité, erreurs, défauts, anomalies, vices de forme, problèmes, etc.

ITIL simplifie la multiplication des termes par incident et problème.

Le où ? Ou domaine d'application :

Le domaine d'application comprend donc l'ensemble des services catalogués ainsi que les moyens, organisation et infrastructures mis en œuvre pour en assurer leur fourniture à des niveaux de service préalablement acceptés.

Le comment ? Ou caractérisation d'un incident :

Un incident doit être standardisé et donner lieu à une description détaillée :

-il doit être décrit (traçabilité des événements)

-et décrit toujours de la même manière (lisibilité et standardisation)

10/27

L'incident enregistré ou le « ticket d'incident » :

-information de gestion : identifiant unique, dates et heures d'ouverture et fermeture, responsable de l'incident, déclarant, coordonnées des contacts, coût de traitement, planning prévisionnel de rétablissement...

-informations descriptives : services affectés, date et heure de détection, symptôme et phénomènes constatés, modalités précises d'exécution (contexte), température, lieux, enregistrements.

-information de traitement : priorité, état d'avancement ressources et moyens alloués, description des actions réalisées, nom des acteurs, date et heure de début, date et heure de fin, affectation.

Priorité d'un incident :

Impact définit selon trois classes fonction du volume et de l'ampleur de l'incident et de son effet sur l'organisation

-bloquant pour plus de 10 personnes ou V.I.P

-bloquant pour une personne

-non bloquant

L'urgence est fonction de la criticité de l'incident par rapport à l'activité de l'utilisateur :

-critique

-faible

-forte

La priorité se traduit par un délai de résolution :

- <1 heure

- <8 heures

– <sous 3 jours

–

11/27

État d'un incident :

-doit être connu de tous les acteurs (clients, utilisateurs, producteurs)

-une fois détecté, l'incident passe par des états successifs

-il portent une information de gestion pertinent sur l'ordonnancement du traitement

Les différentes phases successives :

-nouveau, ouvert : détecté, sa description détaillée donne lieu à un enregistrement

-qualifié, accepté : donne lieu à une analyse préalable pour s'assurer que sa description est suffisante

-programmé, planifié : ordonné selon sa priorité dans une file d'attente (une date de fin prévisionnelle est positionnée, c'est le délai maximum de traitement).

-affecté ou alloué : alloué à une organisation ou une ressource pour son traitement

-en-cours : fait l'objet d'une action opérationnelle pour le traiter, il est en-cours de traitement

-suspendu, en attente : le traitement de l'incident nécessite une ressource qui demande un délai de mise à disposition (l'attente d'une pièce provenant d'un fournisseur)

-résolu : l'incident est éradiqué techniquement. Une solution a été trouvée et la correction a été déployée.

-clos, fermé : l'incident est résolu, le ticket est administrativement fermé (la personne qui a déclaré l'incident doit en autoriser la fermeture, elle seule est habilitée à le faire)

N.B : en principe, tout incident doit impérativement donner lieux à un enregistrement, il faut être réaliste et pragmatique. Ainsi un événement qui apparaît et disparaît sous un laps de temps très court peut ne pas être enregistré sauf si le phénomène se réitère.

Les relations incident, problème, erreur connue et demande de changement :

-L'incident a un impact direct sur la qualité du service délivré à un client ou un utilisateur.

-La préoccupation majeur du producteur de service va donc être de le faire disparaître au plus vite.

-C'est une action synchrone.

-Le contournement, pour un remise rapide du service, est une préoccupation voire une obsession.

A voir le cheminement :

12/27

Une résolution n'est pas la preuve que la cause première est identifiée et éliminée (ex : un reboot)6.Le traitement d'un incident : objectif principal : rendre le service au client le plus rapidement possibleLe processus de gestion des incidents est au centre d'un « écosystème » composé de ;

-d'autres processus et d'une fonction : gestion des problèmes, gestion des changements et centre de services

-d'informations : problèmes, erreurs connues, conventions de service, changements, procédures

-d'outils opérationnels : superviseurs, indicateurs applicatifs, outils de diagnostics, outils de gestion des incidents

-d'acteurs (au sens du rôle) : le gestionnaire des incidents, les experts, les fournisseurs, les opérationnels

Basé sur la communication, ITIL insiste sur ce point mais il est un élément clés qui fait souvent défaut dans nos organisations.

Cycle de vie d'un incident :

Un incident, de l'instant où il se déclare (point de vue technique) jusqu'au moment où il est résolu, est soumis à un nombre limité d'activités ou actions afin de rétablir au plus vite le service au client.

Activités du processus de gestion des incidents :

objectif principal : de traiter l'ensemble des demandes et incidents qui lui sont affectés. Pour ce faire, il s'appuie sur six activités principales

-détecter et enregistrer l'incident et/ou la demande

-classer les incidents et/ou demandes et apporter une première assistance.

-investiguer et faire un diagnostic

-résoudre et rétablir le service (ou exécuter la commande)

-clôturer l'incident (ou la demande)

-communiquer, suivre, piloter et affecter les incidents (escalade)

Escalade fonctionnelle et hiérarchique :

13/27

-fonctionnelle : qui suit le processus normal, du niveau 0 à 4

-hiérarchique : en cas de dysfonctionnement, le responsable de service se charge de l'incident.

Activités détaillées du processus ou « meilleurs pratiques » :

-détecter et enregistrer l'incident et/ou la demande ;

=>rapprochement avec la base des problèmes et erreurs connues (si répertorié, la correction associée est appliquée et l'incident fermé),

=>dans le cas d'une demande, il est d'usage qu'elle fasse partie d'un catalogue de services standards (des demandes hors catalogue doivent rester possibles)

-classer les incidents et/ou demandes et apporter une première assistance (support niveau 1) ;

=>l'incident précédemment enregistré fait l'objet d'une analyse pour en découvrir les causes. La qualité d'analyse en découle la rapidité d'exécution.

=>au niveau de la demande de service, une catégorisation et une priorisation sont effectuées. Le changement d'un mot de passe sera prioritaire à l'achat d'un écran externe pour un portable. La demande peut faire l'objet d'un refus.

-investiguer et faire un diagnostic ;

=>aucune solution n'a été trouvée par le premier niveau de support. L'objectif de cette activité est de proposer au plus vite une ou plusieurs solutions (contournement inclus) pour rétablir le service au client. Toute solution de contournement permet de laisser du temps pour le diagnostic et ainsi favoriser la qualité de la future solution proposée. C'est au cours de cette activité que l'escalade fonctionnelle est mise en œuvre.

=>en terme d'organisation opérationnelle, il est conseillé que l'affectation du ticket d'incident et la coordination des travaux se fassent sous la tutelle du centre de services, propriétaire de tous les incidents. Le ticket est enrichi des informations générées par le ticket.

-résoudre et rétablir le service (ou exécuter la commande) ;

=>est de rétablir le service en mettant en place soit la solution de l'incident soit la solution de contournement, en émettant une demande de changement (RFC) pour la mise en place de la future solution.

=>l'incident ne peut-être clôturé que lorsque le service a été restauré. Pour la demande, les travaux sont exécutés.

-clôturer l'incident ;

=>ne se résume pas juste au passage de l'état d'acte de gestion à la clôture du ticket.

=>il se fait avec l'aval du client sous la responsabilité du centre de service, propriétaire des incidents.

=>on ne ré-ouvre pas un incident fermé, il faut ouvrir un nouveau ticket. (idem pour la demande)

14/27

-Communiquer, suivre, piloter et affecter les incidents (escalade) :

=> la communication au centre de la relation des différents acteurs.

=>c'est le centre de service qui communique avec le client.

=>le pilotage et l'affectation des incidents sont des opérations essentielles. (efficacité)

Traitement des incidents majeurs :

-significatif (touche beaucoup de client ou préjudiciable pour le business)

-caractère stratégique (vers la hiérarchie avec l'information opérationnelle et vers le clients avec la nature du service défectueux et sur le délai probable de remise en service)

Le pilotage de processus (le gestionnaire d'incident) :

Le rôle du gestionnaire d'incident est d'assurer la gestion et d'être garant de son institutionnalisation.Il a la responsabilité de :

-vérifier l'efficacité du processus dans l'atteinte des objectis définis

-mesurer et optimiser l'efficience (productivité) des activités

-mettre en place les plans d'amélioration

-développer et compléter les besoins fonctionnels liés à la gestion du processus

-apporter assistance aux opérationnels

-assurer le reporting des incidents

Indicateurs clés de performance :

les 4 classes de facteurs critiques de succès ;

-résoudre rapidement les incidents

-maintenir des services de qualité

-améliorer le business et la productivité

-garantir la satisfaction utilisateur

15/27

La gestion des problèmes

(pdf:itil6)

Objectif principal : rechercher la cause première des incidents, apporter des solutions pour prévenir de nouveaux incidents et ainsi minimiser l'impact négatif sur le business.

On parle de problème en production de service lorsque l'on ne connaît pas la cause d'un phénomène ou d'un comportement (identifiable et caractérisable), qu'il ait ou non donné lieu à un incident. De manière générale, un problème est un événement qui provient des incidents, essayer de le traiter c'est :

-avoir la volonté d'éradiquer ou prévenir un incident

-se poser la question du « pourquoi », voir encore plus précisément du « quoi »

Une gestion des problèmes performante est la preuve que l'apprentissage des expériences passées par l'organisation est efficace (maturité de niveau 3) :

-Tout problème n'a pas forcément une cause parfaitement identifiable

-Un problème contrairement aux incidents ne peut pas ouvrir d'autres problèmes.

-aborder un problème c'est vouloir entrer dans un processus d'amélioration

-si l'incident doit être traité en temps réel et en parfait synchronisme avec les actes des clients et/ou des utilisateurs pour minimiser l'impact sur le business, le problème, lui , doit essentiellement être traité selon une modalité asynchrone

-la gestion des problèmes est un processus proactif, mais certaines situations peuvent vous amener à l'utiliser à un niveau réactif

1.Ce qu'il faut avoir en tête pour parler « problème » :

Quand ouvrir un problème :

-il est urgent de solliciter la gestion des problèmes pour identifier rapidement les cause réelles et trouver au minimum une solution de contournement

-un incident dont la cause n'est pas connue ne donne pas systématiquement lieu à la déclaration d'un problème. Car le traitement d'un problème requiert des ressources qualifiées, et donc rares et coûteuses

-ne pas connaître ou trouver la cause d'un problème ne remet pas en cause l'intégrité ni les compétences d'une personne

-si lors de l'analyse d'un incident, il est possible de faire référence à une erreur connue, et à son traitement pour l'éradiquer, il est alors inutile de faire appel au processus de gestion des problèmes (gain de temps)

Toujours bien décrire le problème :

16/27

-le résultat des diagnostics montrent que, bien souvent, les causes d'un problème ne sont pas liées aux composants d'infrastructure, mais à la mauvaise application des procédures

-cependant, pour faciliter la traçabilité opérationnelle, le problème est rattaché à un élément de configuration

-ne jamais sous-estimer que l'efficacité de la résolution d'un problème est très souvent fonction de la qualité de sa description initiale

Rôles et responsabilités :

-comme le centre de services est propriétaire des incidents, il en est de même des problèmes qui ont été ouverts à leur suites

-le traitement d'un problème est sous la tutelle d'un responsables

-faire du client son allié en l'informant au plus tôt

-management des ressources ne doit pas être systématiquement affectées aux tâches réactives aux actions proactives

-si les ressources sont rares, il faut investir quand même dans la gestion proactive des problèmes

Priorités :

-toujours piloter par la priorité

-aller à l'essentiel et être pragmatique

-l'implémentation de la gestion des problèmes suit celle de la gestion des incidents

Méthode et outils :

-traçabilité est synonyme d'efficacité, la gestion des problèmes en fait prendre conscience.

-une historisation des erreurs connues et des problèmes est un réel plus pour la gestion des incidents et le centre de services.(comme pour la gestion des configurations)

-la gestion des problèmes ne nécessite pas un outillage complexe

2.L'objectif du processus « gestion des problèmes » :

L'objectif principal du processus de gestion des problèmes est d'analyser et trouver les causes premières des incidents, apporter des solutions pour prévenir de nouveaux incidents et ainsi minimiser l'impact négatif sur le business

Contrairement à la gestion des incidents qui a pour premier objectif de trouver un contournement,le processus de gestion des problèmes, lui, se préoccupe des causes profondes et particulièrement celles qui affectent directement le client et/ou l'utilisateur.

17/27

Ce processus peut être activé selon deux modalités : synchrone et asynchrone.

-La modalité synchrone signifie que le processus est activé dans un cadre réactif.(niveau de maturité 2)

-La modalité asynchrone signifie que le processus est activé dans un cadre proactif.(niveau de maturité 3)

Le quoi ? Ou la définition d'un problème et d'une erreur connue :

Un problème est la cause inconnue d'un incident significatif ou de plusieurs incidents présentant les mêmes symptômes.

Un problème devient une erreur connue lorsque la causse du (ou des) incident(s) est trouvée, mais la solution n'est pas encore implémentée.(il n'existe peut être aucune solution curative ou corrective)

Le où ? Ou le domaine d'application :

-peut porter sur le service vu du client

-ensemble des services catalogués mis en œuvre pour en assurer leur fourniture à des niveaux de service préalablement acceptés

-s'appuyer sur la cartographie des services

Le comment ? Ou la caractérisation d'un problème :

-traçabilité des problèmes

-décrit toujours de la même manière

Description d'un problème :

-n'est pas la même qu'un incident (contrairement à ce que pense certaines entreprises)

-informations de gestion (décrite dans les incidents)

-informations de traitement (décrite dans les incidents)

La priorité de traitement = fonction (impact sur le business et urgence du problème vis à vis du client)

La détermination des priorités :

L'impact est définit selon 3 classes ; l'urgence

-majeur critique

-significatif forte

-mineur faible

2.Etat d'un problème (et d'une erreur connue)

18/27

Un problème passe par les même états que l'incident et se traduit physiquement par un ticket.

-Le traitement d'un problème, son écosystème, son cycle de vie, l'activité de son processus et enfin ses « meilleur pratiques » suivent la même logique que l'incident. -Idem pour le pilotage du processus

La gestion des configurations

Objectif principal est de maîtriser tous les composants de l'infrastructure nécessaire à la fourniture des services.

-le SI est un ensemble de briques (applications, poste de travail, documentations, procédures, etc) nécessaires à la fourniture des services

-Le SI est complexe du à sa nature hétérogène (multiplicité des composants)

-la gestion des configurations dénombre le nombre de composants

-il faut se résoudre à maîtriser sa complexité (règles et méthodes)

conseils à retenir concernant la gestion des configurations :-limiter le niveau descriptif des éléments

-ne pas se fier à de simples dires, vérifier la véracité et l'exactitude des actes et des informations

-se fier à l'historique et la notion de « configuration référence »

-faire preuve de bon sens

la gestion des configurations apporte un grand nombre d'informations sur l'état du patrimoine :

-quels composants contribuent à la fourniture d'un service particulier ?

-à quels services contribue un composant donné ?

-quel est le nombre et l'échéance de validité des licences achetées ?

-quel événements ont porté sur un élément de configuration (incident, problème, changement, etc)

-quels composants informatiques ne sont plus utilisés ?

19/27

La connaissance de son infrastructure permet de mieux appréhender :

-les données financières (patrimoine, coût d'exploitation, efficience, hébergement,...)

-les données opérationnelles (réparation, maintenance, évolution, incident,...)

-les données juridiques (licences, contrats,...)

-les données business (continuité, facturation, impacts,...)

-les données sur les services (QoS, cartographie,...)

-les données d'urbanisation (cartographie technique, fonctionnelle, métier)

Rôle et responsabilités :-sous tutelle d'un gestionnaire, il se doit d'être pragmatique.

Priorités :

-description statique et dynamique de l'outil

-aller à l'essentiel

Méthodes et outils :-la qualité et la pertinence de la gestion des configurations dépendent des règles de

découpage.

-les exigences de production prennent en compte ces règles dès le départ

-gérer par des moyens de type opérationnels

La base de données de gestion des configurations – CMDB Configuration Management Data Base :

-le CMDB : son niveau de description doit être à l'image du niveau de maturité

-plus le niveau de maturité est faible et plus sa description l'est aussi

20/27

Le contenu d'un CMDB (Configuration Management Data Base) doit être l'image parfaite et réelle du système IT à un instant donné.

Les bibliothèques :

Ensemble contrôlé d'éléments de configuration logiciels, de même catégorie et dans le même état.-ou DSL est l'acronyme pour définir cet espace où sont entreposées et sauvegardées toutes

les versions définitives autorisées de tous les CI logiciels en production.

-est considéré comme le référentiel des logiciels en production

-cette zone est tenue à l'écart de toutes actions opérationnelles pouvant corrompre l'intégrité de son contenu.

-la configuration de la DSL est définie dans le plan de gestion des configurations (la gestion de ses capacités est à prendre en compte)

-toute mise en production doit trouver copie dans la DSL

-d'un point de vue opérationnelle la DSL est assez facile à mettre en place.(elle doit exister même si la CMDB n'est pas encore une réalité)

La relation configuration – changement – mise en production :

-émettre une demande changement

-réaliser une mise en production

-(après autorisation), enregistrer dans la base de gestion des configurations

Ce schéma correspond à la réalité opérationnelle.

21/27

Les objectifs du processus « gestion des configurations » :

-Objectif principal est de maîtriser tous les composants autorisés de l'infrastructure nécessaire à la fourniture des services.

Il se traduit par :

-maîtriser tous les composants de l'infrastructure nécessaire à la fourniture des services IT (référentiel)

-assurer la précision et la fiabilité de l'ensemble des informations liées aux composants

-vérifier l'adéquation entre le référentiel et la réalité (audit)

-fournie une base solide pour la gestion des incidents et pour la traçabilité des changements,

assurer la traçabilité de toutes les mises en production

Des informations fiables, pérennes et stables sont des composantes très importantes.

La mise en place de la gestion des configurations est caractérisée par :

-planifier

-identifier

-enregistrer

-maîtriser

-vérifier

Ce processus peut-être activé de manière synchrone et asynchrone.

Le quoi ? Ou la définition d'une configuration :

-c'est le résultat d'une mise en relation structurée et cohérente d'éléments (composants)

-un composé peut être le composant d'un composé de niveau supérieur et ainsi de suite

Le CI ou élément de configuration :

-élément de configuration logiciel appelé aussi SCI (Software Component Item)

-élément de configuration matériel appelé aussi HCI (Hardware Component Item)

Pour ITIL, CI ou Component Item est un composant de l'infrastructure du système IT, nécessaire pour fournir un service, unique et identifiable, modifiable, gérable et documenté (matériel, logiciel, procédures, organisation, SLA,...)

22/27

Le où ? Ou le domaine d'application :

le domaine d'application peut dans certains cas porter sur des centaines de milliers de composants catégorisés comme :

-l'infrastructure matérielle et logicielle

-les applications métiers

-la documentation

-les environnements

-les services

-les personnes

-les lieux

Le comment ? Ou la caractérisation d'une configuration ou d'un élément de configuration :

-description : en priorité un composant doit être décrit

-lisibilité : et être décrit toujours de la même manière

-référence : et être associable à un état de configuration

-version : être associable à un changement

La description d'un élément de configuration :

-informations de gestion : identifiant de configuration unique, nom, licence,...

-informations descriptives : catégories, version services, caractéristiques techniques,...

-informations de traitement : état, date prévue de changement de l'état,...

Catégorisation d'un élément de configuration – Component Item – CI :

-l'infrastructure matérielle (IT et télécom) et logicielle,

-les applications métiers,

-les packages de livraison (MEP)

-les bases de données (physique, scripts de création...)

-la documentation (spécifications, licences, contrats fournisseurs, dérogations)

-les procédures

-les plans de configuration, de capacité, de continuité de service, etc

-les enregistrements, les environnements, les services, les utilisateurs

-les sites

-les acteurs de production

États d'un élément de configuration :

23/27

N.B : il est à noter qu'un état n'a d'existence opérationnelle que s'il peut donner lieu à une mesure et être la preuve de la bonne exécution de l'activité antérieur.

Gestion des configurations : (idem à incident et problèmes)

Écosystème : (idem à incident et problèmes)

Le cycle de vie d'un élément de configuration :

24/27

N.B : le cycle de vie d'un élément de configuration peut ne pas être le même selon la catégorie de ce dernier. Ainsi l'état d'un CI (Component Item) peut être « installé », mais pour une documentation, cet état n'a pas de sens pratique. Le document lui serait à la rigueur « applicable ».

Notion de configuration de référence (baseline) Le métier de la production a la particularité d'être soumis, de manière continue, à une multitude de changements.

A partir d'une baseline :

-comparer deux baseline en cas d'audit

-avoir la possibilité de revenir à une base stable

-pouvoir détecter les logiciels et matériels non-autorisés

-apport d'une référence

-construire une version logicielle en partant d'une version antérieure (stable)

-réaliser une mesure d'impact en cas de changement

On note donc différents états de la baseline :

-en production

-de référence

-archivée

Activité du processus de gestion de configuration : (idem à incident et problème)

25/27

Activités détaillées du processus ou « meilleur pratiques » : (ici résumé, à relire)

-planifier la gestion des configurations : construction de plan de gestion des configurations, ordonner et planifier les actions et travaux qui en découlent pour ensuite les mettre en œuvre, en sachant que la vie opérationnelle ne peut s'arrêter

-identifier les configurations : a pour objectif de sélectionner des structures de configuration et d'identifier tous les CI (Component Item) de ces dernières, en indiquant les propriétaires, leurs relations et la documentation associée

-contrôler les éléments de configuration : enregistrer les nouveaux CI, MAJ des CI existants

-mettre au rebut et archiver un CI avec tout son contexte (enregistrements)

réaligner le contenu de la CMDB (Configuration Management Data Base) au regard du terrain

-lors d'une demande de changement, ouvrir un enregistrement (journal) où seront conservées toutes informations relatives aux actions

-effectuer un reporting sur le statut d'étapes ou de phases qui modifien l'état du composant : chaque CI a un cycle de vie jalonné d'étapes ou de phases qui modifient l'état du composant

-vérifier et auditer les configurations : réaliser des revues et des audits afin de vérifier le degré d'exactitude entre les CI réels et les enregistrements de la base de gestion des configurations (CMDB)

-fournir un service de gestion des configurations : informer et transmettre les rapports de configurations, former et assister les équipes pour prévenir des écarts potentiels, maintenir l'intégrité de la CMDB, ...

Pilotage du processus

un acteur : le gestionnaire des configurations :

-vérifier l'efficacité du processus dans l'atteinte des objectifs définis

-mesurer et optimiser l'efficience (productivité) des activités

-mettre en place les plans d'améliorations (CMDB)

-développer et compléter les besoins fonctionnels liés à la gestion du processus

-assister le travail des opérationnels

-assurer le reporting

N.B : ce rôle requiert une connaissance parfaite des services. Il pilote la connaissance patrimoniale de l'entreprise. Son expérience et son sens de l'organisation sont des prérequis obligatoires.

Les indicateur clés de performance (KPI)Les indicateurs mis en place ont pour objectif de répondre à quatre classes de facteurs critiques de succès en terme de service, à savoir :

-contrôler les actifs

-maintenir la qualité des services IT

-disposer de services économiques

-fournir assistance, s'intégrer et s'interfacer à tous les autres processus de gestion de service.

26/27

Les outils :

-la base de données des configurations (CMDB)

-les outils d'inventaire automatiques

-la composition dans laquelle la vie des éléments est liée à celle de l’agréât.

-l'héritage, qui dans une relation type généralisation/spécialisation permet à un élément spécifique de profiter de la description de l'élément générique.

27/27