Gestion des Incidents
Le centre de services (Service Desk) ainsi que cinq processus :
Face à la pression des utilisateurs, beaucoup de directions informatiques ont tendance à travailler en mode réactif avec intervention des différentes entités de façon non suffisamment structurée.
Dans de nombreuses entreprises, la situation actuelle est la suivante :
Les avantages que l’on tire de la mise en place d’une telle organisation support sont les suivants :
La définition ITIL d'un Incident est la suivante :
« Tout événement qui ne fait pas partie du fonctionnement standard d’un service et qui cause, ou peut causer, une interruption ou une diminution de la qualité de ce service. »
Quelques exemples :
- application : application non disponible, erreur programme empêchant l’Utilisateur de travailler, nombre d'E/S disques excessifs
- matériel : système HS, remontée d’alerte automatique, sortie imprimante bloquée
- demandes de services : demande d’information, de conseil ou de documentation, oubli d’un mot de passe
==== Extensions de la définition ====
Le terme Incident est généralement compris comme un dysfonctionnement signalé par un Utilisateur. Cependant, deux extensions à cette définition sont généralement utilisées car elles vont suivre le même processus de traitement que les dysfonctionnements proprement dits et sont donc assimilés à des Incidents :
- Les demandes pour un nouveau service (ou l’extension d’un service existant) sont considérées comme des Demandes de Changement (RFCs) mais assimilées à des Incidents en pratique (traitement identique) et traitées dans le cadre de la Gestion des Incidents
- Les Remontées d’alertes automatiques (espace-disque saturé par exemple) : elles sont souvent considérées comme faisant partie de l’exploitation courante ; ces événements sont traités dans le cadre de la Gestion des Incidents même si le service délivré aux Utilisateurs n’est pas affecté
==== Processus de Gestion des Incidents ====
En entrée du processus, nous retrouvons :
- Détails des Incidents (du Centre de Services et des différentes sources automatiques)
- Détails des Configurations (de la CMDB)
- Recherche correspondances (matching) entre Incidents et Problèmes & Erreurs connues (de la base de données Problèmes/Erreurs Connues)
- Détails de la résolution de l’Incident de nature similaire (de la même base)
- Retour des Demandes de Changement en correction d’un Incident (du processus Gestion des Changements)
En sortie du processus, nous avons :
- Routage des demandes de services
- Demandes de Changement pour résoudre certains Incidents
- Mise à jour de la base des Problèmes/Erreurs Connues
- Communication aux Utilisateurs (pendant l’avancement et à la fermeture)
- Rapports à la hiérarchie
Dans le processus, les activités de la Gestion des Incidents sont les suivantes :
- Détection et enregistrement des Incidents
- Support initial et classification
- Investigation et diagnostic
- Suivi global des Incidents
- Résolution et rétablissement
- Fermeture des Incidents
===== Concepts de base =====
==== Cycle de vie d’un Incident ====
Le cycle de vie d'un Incident est le suivant :
Quelques remarques :
- Le Centre de Services est responsable de l’aboutissement de tous les Incidents enregistrés (propriétaire des Incidents).
- Le processus de traitement est essentiellement réactif .
- Les Incidents ne pouvant pas être résolus immédiatement doivent être assignés aux groupes de spécialistes.
- La résolution ou une solution de contournement doit intervenir le plus vite possible pour rétablir le service impacté
==== Cycle de vie d’un Incident : Préconisations ====
Tout au long du cycle de vie de l’Incident, l’enregistrement doit être à jour pour permettre à n’importe quelle personne de l’équipe du Centre de Services de communiquer sur l’Incident simplement en consultant l'enregistrement. Il est nécessaire de conserver la description originelle de l’Incident même si la description en cours évolue. Par exemple, un Utilisateur signale un Incident avec son imprimante (son édition ne s'imprime pas). Après investigation, il s'agit en réalité d'un problème réseau mais, lorsque l'Incident est clos, il est préférable que le Centre de Services prévienne l'Utilisateur simplement en lui précisant que son problème imprimante est réglé plutôt que de lui expliquer le problème réseau et sa résolution. Il faut aussi conserver un historique des modifications sur l’enregistrement de l’Incident. Tous les changements d'état doivent être tracés (date/heure, personne qui a provoqué le changement, etc.) Si l’une des équipes n’a pas accès à l’outil de Gestion des Incidents, il est impératif de bien mettre en place une procédure de mise à jour de ces enregistrements à faire lors des interventions de ces équipes(par exemple: maintenance tierce ou support de nuit n’ayant pas accès à l’outil durant la nuit)
==== Premier, deuxième et troisième niveaux de support ====
Voici un schéma (classique) d'escalade d'un Incident sur les différents niveaux de support, à commencer par le Centre de Services :
Il est à noter que certains niveaux de support peuvent être des sociétés extérieures (externalisation du support ou appel aux constructeur/éditeurs dans le cadre de contrats de support passés entre l'entreprise et ces sociétés extérieures).
==== Escalade fonctionnelle et escalade hiérarchique ====
=== Escalade fonctionnelle ===
C'est l'escalade traditionnelle et prévue dans le processus pour transférer un Incident d’un niveau au niveau supérieur . 7
Cette escalade peut intervenir dans deux cas :
- par manque de connaissance ou d’expertise du niveau en cours.
- par dépassement d’un délai (à définir avec précaution et ne pas dépasser les délais des Contrats de Niveaux de Service)
=== Escalade hiérarchique ===
Ce type d'escalade n'est pas réellement prévue dans le processus. Cependant, en pratique, on constate que cette escalade existe et est nécessaire au bon fonctionnement du service dans certains cas. L'escalade hiérarchique peut intervenir à n’importe quel moment dans le cycle de Gestion de l'Incident lorsqu'il est évident que la résolution interviendra hors-délai ou sera insatisfaisante. Ceci demande un certain recul vis-à-vis du processus qui, s'il est suivi à la lettre, peut aboutir dans certains cas à des situations critiques.
Dans l’idéal , l'escalade hiérarchique devrait intervenir avant la fin du délai pour que la hiérarchie ait le temps de réagir. En pratique, on constate que l'escalade hiérarchique est utilisée lorsque les temps de résolution de l'Incident sont hors délai.
==== Enregistrement d'un Incident ====
Le Centre de Services est propriétaire de l'Incident et en est responsable jusqu'à la résolution et sa fermeture.
L'élément important de l'enregistrement d'un Incident (que l'on peut aussi appeler fiche Incident) est sa priorité de traitement
par rapport aux autres Incidents en cours.
=== Fixer la priorité ===
La priorité d'un Incident est déterminée par :
- L'impact sur l’activité de l’entreprise . L'impact représente la criticité sur l’activité métier (Incident ou Problème). Certaines définitions de la criticité (ou niveau de risque) précisent qu'il y a 3 facteurs : fréquence, gravité, probabilité de non-détection. L'impact est souvent mesuré au nombre de personnes ou de systémes affectés.
- L’urgence à mettre en place une solution définitive ou de contournement (urgence: effort attendu et vitesse nécessaire pour résoudre l’Incident)
Pour fixer correctement le niveau de priorité sans perdre trop de temps, il est nécessaire d'avoir un cadre de travail. Ce cadre est fixé par les différents Contrats de Niveaux de Service. En pratique , on retrouvera une codification déjà définie (impact/urgence) dans ces Contrats de Niveaux de Service.
=== Rôles du Centre de Services dans la Gestion des Incidents ===
Les points importants à prendre en considération sont les suivants :
- tous les Incidents sont remontés vers le Centre de Services et doivent être enregistrés par celui-ci (y compris les remontées automatiques dans l’idéal)
- la majorité des Incidents (jusqu’à 85%) pourront être résolus par le Centre de Services (constaté lorsqu'une Gestion effective des Incidents est en place)
- le Centre de Services est la fonction « indépendante » de suivi de l’ensemble des Incidents jusqu’à leur résolution
- le Centre de Services effectue la coordination des équipes de support intervenant dans la résolution des Incidents.
=== Actions principales à l’enregistrement ===
- enregistrement du détail (symptôme, etc.)
- s’il s’agit d’une Demande de Service, utilisation de la procédure associée l’Elément de Configuration (CMDB) à l’origine probable de l’Incident est associé à la fiche
- assignation de la priorité adéquate et communication à l’Utilisateur d’un identifiant d’Incident
- l’Incident est évalué et, si possible, la solution est donnée (Incident fréquent ou Erreur Connue)
- l’Incident est assigné au support de niveau deux si besoin ou la fiche est complétée et fermée si la solution a été donnée
=== Actions principales à la fermeture ===
confirmer la résolution avec l’Utilisateur ou l’émetteur
définir la catégorie de la solution apportée8
compléter l’enregistrement de l’Incident
fermer l’Incident en vérifiant que :
les détails de la solution sont clairs et lisibles
les codes de refacturation sont renseignés (cost-centre)
les temps passés sur l’Incident sont renseignés
Ceci est indispensable pour éviter les conflits entre équipes de support et Clients sur la validité de la fermeture
Il est nécessaire d'avoir un accès restreint à l’option de fermeture des Incidents (typiquement le responsable du Centre de
Services gère ces accès)
==== Incidents, Problèmes, Erreurs Connues et Demandes de Changement ====
Un Incident est la conséquence d’échecs ou d’erreurs de traitements dans l’infrastructure informatique
La cause d’un Incident peut être évidente et peut être éradiquée directement par le Centre de Services sans investigation
complémentaire en :
réparation immédiate
solution de contournement
Demande de Changement
Quand la cause sous-jacente d’un Incident n’est pas connue, il est nécessaire d'initialiser un Problème dans le processus de Gestion des Problèmes.
Un Problème est ainsi le signe d’une erreur inconnue dans l’infrastructure.
Plusieurs Incidents peuvent sembler partager la même origine donnant lieu à la définition d’un Problème unique
Un Problème est indépendant des Incidents associés. L’analyse du Problème peut continuer même si les Incidents ont été
résolus et fermés.
Résolution d’un Problème :
1. Identification de l’erreur sous-jacente
2. Mise au point d’une solution de contournement ou émission d’une Demande de Changement
Le Problème devient alors une Erreur Connue.
==== Définitions ====
Problème : La cause inconnue d’un ou de plusieurs Incidents
Erreur connue : Problème diagnostiqué correctement et pour lequel il existe une solution de contournement ou une Demande de Changement a été émise
Demande de Changement : Une demande d’ajout, de modification, d’évolution, de suppression de composant(s) de
l’infrastructure informatique ou pour tout autre aspect de la Production Informatique
==== Incidents, Problèmes, Erreurs Connues et Demandes de Changement ====
Les interactions entre les processus Gestion des Incidents et Gestion des Problèmes sont complexes mais il est nécessaire de les maîtriser afin de bien séparer ces deux processus dont les finalités sont très différentes.9
Dans le processus de résolution d’un Incident, les actions suivantes doivent être entreprises :
si l'Incident semble avoir une cause inconnue, il faut initialiser un Problème dans le processus de Gestion des Problèmes.
étudier une correspondance avec les Problèmes référencés et les Erreurs Connues
étudier une correspondance avec les Incidents référencés (similaires résolus ou en cours)
si pas de solution, la Gestion des Incidents a la responsabilité d’en trouver une (définitive ou de contournement) avec
l’impact minimum sur l’activité de l’entreprise
Les flux entre la Gestion des Incidents et la Gestion des Problèmes sont croisés :
lors de l'analyse de l'Incident par la Gestion des Incidents pour redémarrer le plus vite possible le service impacté, si une solution de contournement est trouvée, l’information doit être transmise à la Gestion des Problèmes pour analyse
lors de l'analyse du Problème par la Gestion des Problèmes, une solution définitive ou de contournement à un ou plusieurs Incidents a été trouvée, la Gestion des Problèmes met à jour la base des Problèmes/Erreurs Connues et transmet l’information à la Gestion des Incidents pour action sur les Incidents associés (passage des Incidents en Erreur Connue ou Résolu)
===== Bénéfices =====
- La gestion des incidents (Incident Management)
- La gestion des problèmes (Problem Management)
- La gestion des changements (Change Management)
- La gestion des mises en production (Release Management)
- La gestion des configurations (Configuration Management)
La Gestion des Incidents
La définition ITIL de l'objectif de la Gestion des Incidents est la suivante :Restaurer aussi vite que possible le fonctionnement normal des services et minimiser l’impact négatif sur les activités métiers et s’assurer ainsi que les meilleurs niveaux de qualité de service et de disponibilité sont maintenus.Le « fonctionnement normal des services » s’entend ici comme le fonctionnement des services dans les limites des Contrats de Niveaux de Service (SLAs).
Face à la pression des utilisateurs, beaucoup de directions informatiques ont tendance à travailler en mode réactif avec intervention des différentes entités de façon non suffisamment structurée.
Dans de nombreuses entreprises, la situation actuelle est la suivante :
- Pas de mécanisme structuré mis en place pour le support du client : plusieurs Help Desks dans l’entreprise impliquent plusieurs points de contacts pouvant entrainer des appels directs vers le mauvais support.
- Faible perception de la notion de client (DSI très orientée technique, plus DI que DSI).
- Des équipes de support non suffisamment managées (fonction support dévalorisée).
- Travail en mode réactif.
- Les incidents reviennent en boucles faute d’un processus de gestion des problèmes digne de ce nom.
- Forte dépendance sur certaines personnes (du fait d’une organisation floue, les utilisateurs appellent en direct.
- Manque d’objectifs (SLA).
- Absence ou mauvaise gestion des changements (analyse d’impact insuffisante. Les aspects techniques prennent le pas sur les exigences des métiers).
- Mauvaise qualité des réponses et des temps de réponses des équipes de support.
Les avantages que l’on tire de la mise en place d’une telle organisation support sont les suivants :
- Point de contact unique pour les utilisateurs pour toutes les questions, problèmes ou remarques. Cela permet au Help Desk ou Service Desk d’avoir une vue globale de la situation.
- Meilleure identification des besoins en formation par les utilisateurs.
- * Définition du Service Desk en tant que noeud de communication, car intégré dans tous les rocessus, ce qui permettra d’identifier les impacts d’un changement avant qu’ils n’affectent les utilisateurs.
- Accès central aux connaissances, gestion des connaissances, ce qui permettra au Service Desk de résoudre plus d’incidents et plus facilement, voire aux utilisateurs de le faire par eux-mêmes.
- Meilleure utilisation des ressources informatiques via une meilleure définition des rôles et responsabilités (limitation du nombre d’appels en direct à un ingénieur technique).
- Meilleure perception de l’informatique par les utilisateurs grâce à une approche plus professionnelle (par une meilleure communication, un meilleur reporting).
- Amélioration du contrôle des performances vis-à-vis des engagements pris (SLA).
- Elimination des pertes d’informations, d’incidents et des demandes des utilisateurs.
Périmètre
Définition d’un Incident et extensions ====La définition ITIL d'un Incident est la suivante :
« Tout événement qui ne fait pas partie du fonctionnement standard d’un service et qui cause, ou peut causer, une interruption ou une diminution de la qualité de ce service. »
Quelques exemples :
- application : application non disponible, erreur programme empêchant l’Utilisateur de travailler, nombre d'E/S disques excessifs
- matériel : système HS, remontée d’alerte automatique, sortie imprimante bloquée
- demandes de services : demande d’information, de conseil ou de documentation, oubli d’un mot de passe
==== Extensions de la définition ====
Le terme Incident est généralement compris comme un dysfonctionnement signalé par un Utilisateur. Cependant, deux extensions à cette définition sont généralement utilisées car elles vont suivre le même processus de traitement que les dysfonctionnements proprement dits et sont donc assimilés à des Incidents :
- Les demandes pour un nouveau service (ou l’extension d’un service existant) sont considérées comme des Demandes de Changement (RFCs) mais assimilées à des Incidents en pratique (traitement identique) et traitées dans le cadre de la Gestion des Incidents
- Les Remontées d’alertes automatiques (espace-disque saturé par exemple) : elles sont souvent considérées comme faisant partie de l’exploitation courante ; ces événements sont traités dans le cadre de la Gestion des Incidents même si le service délivré aux Utilisateurs n’est pas affecté
==== Processus de Gestion des Incidents ====
En entrée du processus, nous retrouvons :
- Détails des Incidents (du Centre de Services et des différentes sources automatiques)
- Détails des Configurations (de la CMDB)
- Recherche correspondances (matching) entre Incidents et Problèmes & Erreurs connues (de la base de données Problèmes/Erreurs Connues)
- Détails de la résolution de l’Incident de nature similaire (de la même base)
- Retour des Demandes de Changement en correction d’un Incident (du processus Gestion des Changements)
En sortie du processus, nous avons :
- Routage des demandes de services
- Demandes de Changement pour résoudre certains Incidents
- Mise à jour de la base des Problèmes/Erreurs Connues
- Communication aux Utilisateurs (pendant l’avancement et à la fermeture)
- Rapports à la hiérarchie
Dans le processus, les activités de la Gestion des Incidents sont les suivantes :
- Détection et enregistrement des Incidents
- Support initial et classification
- Investigation et diagnostic
- Suivi global des Incidents
- Résolution et rétablissement
- Fermeture des Incidents
===== Concepts de base =====
==== Cycle de vie d’un Incident ====
Le cycle de vie d'un Incident est le suivant :
Quelques remarques :
- Le Centre de Services est responsable de l’aboutissement de tous les Incidents enregistrés (propriétaire des Incidents).
- Le processus de traitement est essentiellement réactif .
- Les Incidents ne pouvant pas être résolus immédiatement doivent être assignés aux groupes de spécialistes.
- La résolution ou une solution de contournement doit intervenir le plus vite possible pour rétablir le service impacté
==== Cycle de vie d’un Incident : Préconisations ====
Tout au long du cycle de vie de l’Incident, l’enregistrement doit être à jour pour permettre à n’importe quelle personne de l’équipe du Centre de Services de communiquer sur l’Incident simplement en consultant l'enregistrement. Il est nécessaire de conserver la description originelle de l’Incident même si la description en cours évolue. Par exemple, un Utilisateur signale un Incident avec son imprimante (son édition ne s'imprime pas). Après investigation, il s'agit en réalité d'un problème réseau mais, lorsque l'Incident est clos, il est préférable que le Centre de Services prévienne l'Utilisateur simplement en lui précisant que son problème imprimante est réglé plutôt que de lui expliquer le problème réseau et sa résolution. Il faut aussi conserver un historique des modifications sur l’enregistrement de l’Incident. Tous les changements d'état doivent être tracés (date/heure, personne qui a provoqué le changement, etc.) Si l’une des équipes n’a pas accès à l’outil de Gestion des Incidents, il est impératif de bien mettre en place une procédure de mise à jour de ces enregistrements à faire lors des interventions de ces équipes(par exemple: maintenance tierce ou support de nuit n’ayant pas accès à l’outil durant la nuit)
==== Premier, deuxième et troisième niveaux de support ====
Voici un schéma (classique) d'escalade d'un Incident sur les différents niveaux de support, à commencer par le Centre de Services :
Il est à noter que certains niveaux de support peuvent être des sociétés extérieures (externalisation du support ou appel aux constructeur/éditeurs dans le cadre de contrats de support passés entre l'entreprise et ces sociétés extérieures).
==== Escalade fonctionnelle et escalade hiérarchique ====
=== Escalade fonctionnelle ===
C'est l'escalade traditionnelle et prévue dans le processus pour transférer un Incident d’un niveau au niveau supérieur . 7
Cette escalade peut intervenir dans deux cas :
- par manque de connaissance ou d’expertise du niveau en cours.
- par dépassement d’un délai (à définir avec précaution et ne pas dépasser les délais des Contrats de Niveaux de Service)
=== Escalade hiérarchique ===
Ce type d'escalade n'est pas réellement prévue dans le processus. Cependant, en pratique, on constate que cette escalade existe et est nécessaire au bon fonctionnement du service dans certains cas. L'escalade hiérarchique peut intervenir à n’importe quel moment dans le cycle de Gestion de l'Incident lorsqu'il est évident que la résolution interviendra hors-délai ou sera insatisfaisante. Ceci demande un certain recul vis-à-vis du processus qui, s'il est suivi à la lettre, peut aboutir dans certains cas à des situations critiques.
Dans l’idéal , l'escalade hiérarchique devrait intervenir avant la fin du délai pour que la hiérarchie ait le temps de réagir. En pratique, on constate que l'escalade hiérarchique est utilisée lorsque les temps de résolution de l'Incident sont hors délai.
==== Enregistrement d'un Incident ====
Le Centre de Services est propriétaire de l'Incident et en est responsable jusqu'à la résolution et sa fermeture.
L'élément important de l'enregistrement d'un Incident (que l'on peut aussi appeler fiche Incident) est sa priorité de traitement
par rapport aux autres Incidents en cours.
=== Fixer la priorité ===
La priorité d'un Incident est déterminée par :
- L'impact sur l’activité de l’entreprise . L'impact représente la criticité sur l’activité métier (Incident ou Problème). Certaines définitions de la criticité (ou niveau de risque) précisent qu'il y a 3 facteurs : fréquence, gravité, probabilité de non-détection. L'impact est souvent mesuré au nombre de personnes ou de systémes affectés.
- L’urgence à mettre en place une solution définitive ou de contournement (urgence: effort attendu et vitesse nécessaire pour résoudre l’Incident)
Pour fixer correctement le niveau de priorité sans perdre trop de temps, il est nécessaire d'avoir un cadre de travail. Ce cadre est fixé par les différents Contrats de Niveaux de Service. En pratique , on retrouvera une codification déjà définie (impact/urgence) dans ces Contrats de Niveaux de Service.
=== Rôles du Centre de Services dans la Gestion des Incidents ===
Les points importants à prendre en considération sont les suivants :
- tous les Incidents sont remontés vers le Centre de Services et doivent être enregistrés par celui-ci (y compris les remontées automatiques dans l’idéal)
- la majorité des Incidents (jusqu’à 85%) pourront être résolus par le Centre de Services (constaté lorsqu'une Gestion effective des Incidents est en place)
- le Centre de Services est la fonction « indépendante » de suivi de l’ensemble des Incidents jusqu’à leur résolution
- le Centre de Services effectue la coordination des équipes de support intervenant dans la résolution des Incidents.
=== Actions principales à l’enregistrement ===
- enregistrement du détail (symptôme, etc.)
- s’il s’agit d’une Demande de Service, utilisation de la procédure associée l’Elément de Configuration (CMDB) à l’origine probable de l’Incident est associé à la fiche
- assignation de la priorité adéquate et communication à l’Utilisateur d’un identifiant d’Incident
- l’Incident est évalué et, si possible, la solution est donnée (Incident fréquent ou Erreur Connue)
- l’Incident est assigné au support de niveau deux si besoin ou la fiche est complétée et fermée si la solution a été donnée
=== Actions principales à la fermeture ===
confirmer la résolution avec l’Utilisateur ou l’émetteur
définir la catégorie de la solution apportée8
compléter l’enregistrement de l’Incident
fermer l’Incident en vérifiant que :
les détails de la solution sont clairs et lisibles
les codes de refacturation sont renseignés (cost-centre)
les temps passés sur l’Incident sont renseignés
Ceci est indispensable pour éviter les conflits entre équipes de support et Clients sur la validité de la fermeture
Il est nécessaire d'avoir un accès restreint à l’option de fermeture des Incidents (typiquement le responsable du Centre de
Services gère ces accès)
==== Incidents, Problèmes, Erreurs Connues et Demandes de Changement ====
Un Incident est la conséquence d’échecs ou d’erreurs de traitements dans l’infrastructure informatique
La cause d’un Incident peut être évidente et peut être éradiquée directement par le Centre de Services sans investigation
complémentaire en :
réparation immédiate
solution de contournement
Demande de Changement
Quand la cause sous-jacente d’un Incident n’est pas connue, il est nécessaire d'initialiser un Problème dans le processus de Gestion des Problèmes.
Un Problème est ainsi le signe d’une erreur inconnue dans l’infrastructure.
Plusieurs Incidents peuvent sembler partager la même origine donnant lieu à la définition d’un Problème unique
Un Problème est indépendant des Incidents associés. L’analyse du Problème peut continuer même si les Incidents ont été
résolus et fermés.
Résolution d’un Problème :
1. Identification de l’erreur sous-jacente
2. Mise au point d’une solution de contournement ou émission d’une Demande de Changement
Le Problème devient alors une Erreur Connue.
==== Définitions ====
Problème : La cause inconnue d’un ou de plusieurs Incidents
Erreur connue : Problème diagnostiqué correctement et pour lequel il existe une solution de contournement ou une Demande de Changement a été émise
Demande de Changement : Une demande d’ajout, de modification, d’évolution, de suppression de composant(s) de
l’infrastructure informatique ou pour tout autre aspect de la Production Informatique
==== Incidents, Problèmes, Erreurs Connues et Demandes de Changement ====
Les interactions entre les processus Gestion des Incidents et Gestion des Problèmes sont complexes mais il est nécessaire de les maîtriser afin de bien séparer ces deux processus dont les finalités sont très différentes.9
Dans le processus de résolution d’un Incident, les actions suivantes doivent être entreprises :
si l'Incident semble avoir une cause inconnue, il faut initialiser un Problème dans le processus de Gestion des Problèmes.
étudier une correspondance avec les Problèmes référencés et les Erreurs Connues
étudier une correspondance avec les Incidents référencés (similaires résolus ou en cours)
si pas de solution, la Gestion des Incidents a la responsabilité d’en trouver une (définitive ou de contournement) avec
l’impact minimum sur l’activité de l’entreprise
Les flux entre la Gestion des Incidents et la Gestion des Problèmes sont croisés :
lors de l'analyse de l'Incident par la Gestion des Incidents pour redémarrer le plus vite possible le service impacté, si une solution de contournement est trouvée, l’information doit être transmise à la Gestion des Problèmes pour analyse
lors de l'analyse du Problème par la Gestion des Problèmes, une solution définitive ou de contournement à un ou plusieurs Incidents a été trouvée, la Gestion des Problèmes met à jour la base des Problèmes/Erreurs Connues et transmet l’information à la Gestion des Incidents pour action sur les Incidents associés (passage des Incidents en Erreur Connue ou Résolu)
===== Bénéfices =====
4.1 Pour l’entreprise :
Réduction de l’impact des Incidents sur les activités métiers augmentant ainsi leur efficacité
4.2 Pour la Production Informatique :
Surveillance améliorée des Incidents permettant une réelle mesure des performances vis-à-vis des Contrats de
Niveaux de Services
Gestion de la qualité améliorée
Meilleure utilisation des ressources
Disparition des Incidents et Demandes de Services perdues ou erronées
Mise à jour de la CMDB à l’enregistrement d’un Incident
Augmentation de la satisfaction des Utilisateurs et des Clients
4.3 A contrario, la non-implémentation d’une Gestion des Incidents entraîne :
Pas de gestion, pas d’escalade des Incidents : ils deviennent plus graves qu’il ne le devraient, ils dégénèrent
Les équipes de spécialistes sont sujets à de constantes interruptions, les rendant moins efficaces
Les utilisateurs sont dérangés par des collègues demandant des conseils au lieu d’appeler le Centre de Services
Résolution fréquente à partir de zéro d’un Incident plutôt que d’utiliser une solution déjà référencée
Absence d’informations de synthèse pour la hiérarchie
Incidents perdus ou gérés de manière incorrecte
===== Mise en oeuvre et planification =====
5.1 Séquencement et calendrier
Ne pas mettre en place de manière isolée des autres processus et fonctions (Centre de Services, Gestion des
Problèmes, des Configurations, des Changements, Gestion des Nouvelles Versions)
Si cela n'est pas possible, il est nécessaire d'implémenter au moins en même temps Centre de Services & Gestion des
Incidents (objectifs rapides à atteindre)10
Profiter des démarrages de services importants pour les intégrer tout de suite dans une Gestion des Incidents (même
si le nombre d'Utilisateurs ou le nombre d'appels ne justifient pas dans ce cas la mise en place d'un Centre de
Services et d'une Gestion des Incidents)
Planification de la mise en place du processus : 3 à 6 mois
Mise en place du processus : 3 mois à 1 an
Choix des outils logiciels : prendre les logiciels conformes à ITIL
CMDB inexistante ou pas mise en place en même temps : intégrer les informations de configuration dans la base de Gestion des Incidents
5.2 Difficultés à prévoir :
pas d’engagement de la hiérarchie
manque de clarté des besoins métiers
méthodes de travail non révisées
pas d’informations sur les niveaux de services
manque de connaissances des Incidents résolus
manque d’intégration avec les autres processus
résistance au changement
===== Traitement des Incidents majeurs =====
Il est à noter que le chapitre sur les Incidents majeurs dans le document ITIL Service Support est léger et que tout le chapitre est mis au conditionnel.
Les Incidents majeurs sont ceux pour lesquels le degré d’impact sur l’ensemble des Utilisateurs est extrême.
Devraient être considérés comme Incidents majeurs les Incidents pour lesquels l’échelle de temps des perturbations devient
excessif au regard des temps de résolution (SLAs) (même si cela impacte un petit nombre d’Utilisateurs)
Le Gestionnaire de Problèmes devrait être averti (s’il ne l’est pas déjà) afin d’organiser une réunion (ou une série de réunions) avec toutes les parties concernées :
équipes de support internes
équipes de support des matériels/logiciels (et/ou mainteneur)
équipes de gestion des services de la Production
Le Centre de Services devrait participer à ces réunions et enregistrer dans la base d’Incidents toutes les actions prises et les décisions.
Nous pouvons considérer qu'il s'agit là d'une période de crise qui ne peut pas être décrite de manière exhaustive dans une méthode car l'important est d'agir vite malgré le nombre peut-être important d'intervenants. Cependant, on peut en déduire en pratique deux points à avoir en mémoire :
1. le traitement des Incidents majeurs est sous la responsabilité du Gestionnaire de Problèmes
2. une information à jour et une communication cohérente sont importantes (évolution très rapide des informations et un besoin très fort en informations des équipes de la Production impliqués et des Clients et Utilisateurs impactés).
Ce rôle est rempli par le Centre de Services qui doit collecter ces informations et les enregistrer au niveau de ou
des Incidents associés au Problème.
===== Indicateurs clés de performances (KPI : Key Performance Indicators) =====
Juger de la performance du processus : les KPIs (Key Performance Indicators)
==== Métriques couramment utilisées : ====
nombre total d’Incidents
temps moyen de résolution par code d’impact11
pourcentage d’Incidents résolus dans les temps contractuels (à définir dans les Contrats par code d’impact par exemple)
coût moyen de traitement d’un Incident
pourcentage d’Incidents fermés par le Centre de Services sans support extérieur (la satisfaction Clients est fortement influencée par le fait que le Centre de Services puissent apporter une solution immédiate à l'Incident)
nombre et pourcentage d’Incidents résolus sans déplacement sur site
==== Diffusion des informations ====
La diffusion se fait par le responsable de l’équipe Gestion des Incidents. Il est nécessaire de définir la périodicité et les listes de diffusion en accord avec le Centre de Services et les différentes équipes de support.
La diffusion doit inclure au minimum l’équipe chargée des Contrats de Niveaux de Services et les équipes de support. Il faut aussi considérer aussi une diffusion vers les Clients et Utilisateurs (par le biais des rapports sur les Contrats de Niveaux de Service par exemple)
===== Les 9 Bonnes Pratiques ITIL a retenir =====
==== Mettre en place un point d’entrée unique ====
ITIL préconise de créer une fonction Service Desk (centre de services), point de contact unique (SPOC : Single Point Of Contact) entre l’utilisateur et la gestion des services informatiques : le rôle principal du centre de services est de prendre en charge les incidents qui surviennent au sein du système d’informations afin d’en assurer le traitement rapide et efficace dans le but de restaurer le service le plus rapidement possible pour l’utilisateur. Ceci consiste à ouvrir un « ticket d’incident », à le renseigner, l’enregistrer, le qualifier puis l’affecter à l’entité la mieux adaptée pour le traiter. Le centre de services doit également proposer une interface aux autres processus ITIL (gestion des problèmes, des changements,...).
Notons bien que pour ITIL, une demande de support SAP est considérée comme un incident dès lors que l’utilisateur a des difficultés avec SAP, même si l’application n’est pas remise en cause quand, par exemple l’utilisateur n’a pas la formation requise.
Enfin le centre de service est le fournisseur principal des statistiques permettant d’établir les tableaux de bord destinés aussi bien aux services informatiques qu’aux directions métiers. Ces statistiques sont indispensables à une maîtrise progressive des services informatiques. Les bénéfices du point d’entrée unique sont un gain en coût opérationnel direct (infrastructure téléphonique, salles, matériels, personnels,…), en consolidation des informations de support et en mise en place d’une base de données centralisée. Dans l’esprit d’ITIL, cette fonction est assurée par le Help Desk informatique, y compris pour les incidents applicatifs.
Le centre de support doit associer au mieux la complexité d’une demande au profil de la ressource nécessaire pour la traiter. Il s’agit d’économiser les experts en les déchargeant des tâches simples ou répétitives, au profit des améliorations qu’ils peuvent apporter sur les systèmes. A l’inverse, il s’agit aussi d’éviter de soumettre des demandes à des acteurs qui n’ont ni la connaissance ni les outils pour les traiter.
L’adéquation entre le type de la demande et le profil sollicité constitue un levier pour améliorer la productivité du support et optimiser la capacité de résolution à chaque niveau de la chaine de traitement des demandes d’assistance.
Nous définissons 3 niveaux de support possibles :
==== Surveiller la charge de travail ====
ITIL préconise de mettre en place un suivi du volume des demandes adressées au support afin de déterminer les ressources, et en particulier les équipes à mettre en place pour répondre à un éventuel pic de charge. Ce volume de demandes doit être rapproché du nombre d’utilisateurs afin d’établir des ratios, dont l’analyse permet de détecter les évolutions dans l’activité du centre. On peut ainsi découvrir un problème cyclique ou localisé appelant des mesures palliatives ou correctives :
* Augmenter le personnel sur une certaine période.
* Mener des actions de formation.
* Déclencher une action de maintenance corrective…
Dans l’esprit d’ITIL, qui est de mettre l’utilisateur au centre du dispositif, nous proposons de définir la criticité selon la segmentation suivante des utilisateurs :
* Fréquence d’usage : Utilisateur régulier ou occasionnel de la solution.
* Fonction occupée : coeur de métier ou back office.
* Appartenance : interne ou externe (client, fournisseur)
L’impact concerne plus le volume et l’ampleur de l’incident sur l’entreprise. Toujours conformément à ITIL, on le mesure en exprimant le nombre d’utilisateurs concernés.
==== Organiser le cycle Incident/Problème/Changement ====
La bonne pratique est de constituer une base permettant de tracer ces dysfonctionnements (fichiers log) et de définir les procédures de traitement associées, voire des traitements de reprise automatisés si le volume le justifie. Nous sommes là au coeur de la gestion des problèmes ITIL (constituer une base des erreurs connues).
Le contrôle des problèmes correspond à l’étape d’identification et d’enregistrement du problème, à sa classification (type, priorité,…) puis à la recherche de la cause de dysfonctionnement. Il s’agit de l’évolution du problème en erreur connue.
Le contrôle des erreurs correspond, pour sa part, à l’étape d’identification et d’enregistrement, d’évaluation, puis de résolution de cette erreur, résolution effectuée par un changement de type maintenance corrective. Une communication de la solution vers le centre de services est engagée afin de pouvoir renseigner les détails dans la base de connaissance CMDB (Configuration Management Data Base).
==== Gérer les mises en production par lot ====
ITIL définit le concept de déploiement comme un ensemble de changements autorisés au même instant sur le système (corrections de problèmes techniques et fonctionnels, nouvelle version).
Ces déploiements sont de 3 types :
* Mineur : il s’agit de quelques ajouts ou modifications fonctionnelles légères tant logicielles que matérielles. Souvent, ce type de déploiement annule et remplace les correctifs urgents passés depuis le dernier déploiement majeur ou mineur. Le but de ce déploiement est de consolider une situation qui a pu être corrigée dans l’urgence.
* Majeur : ajouts fonctionnels importants ou des correctifs qui modifient le comportement du système d’informations. A l’instar des déploiements mineurs, ce type de mise en production écrase toutes les modifications antérieures.
* Urgent : traitement d’une situation d’urgence qui peut être résolue par la mise en production d’un correctif. Ce déploiement contient en général, la correction d’un problème connu très localisé ou d’un très petit nombre de problèmes.
Il s’ensuit deux façons de procéder aux mises en production SAP :
* Au fil de l’eau pour les déploiements mineurs ou urgents.
* Par lot pour les déploiements majeurs.
La CMDB est au coeur des processus ITIL, elle est le pendant outil du SPOC. Son objectif est d’accroître les bénéfices des processus. Son rôle est de les soutenir en produisant une information
fiable, permettant d’obtenir des analyses précises, de prendre des décisions pertinentes et
économiquement justifiées. Pour mener à bien son rôle, elle se nourrit des contrôles traçant
les modifications effectuées sur tous les composants de l’infrastructure. Cette information ainsi
capturée est restituée, partagée, voire enrichie, pour développer de nouveaux potentiels de
productivité et d’économies.
Réduction de l’impact des Incidents sur les activités métiers augmentant ainsi leur efficacité
4.2 Pour la Production Informatique :
Surveillance améliorée des Incidents permettant une réelle mesure des performances vis-à-vis des Contrats de
Niveaux de Services
Gestion de la qualité améliorée
Meilleure utilisation des ressources
Disparition des Incidents et Demandes de Services perdues ou erronées
Mise à jour de la CMDB à l’enregistrement d’un Incident
Augmentation de la satisfaction des Utilisateurs et des Clients
4.3 A contrario, la non-implémentation d’une Gestion des Incidents entraîne :
Pas de gestion, pas d’escalade des Incidents : ils deviennent plus graves qu’il ne le devraient, ils dégénèrent
Les équipes de spécialistes sont sujets à de constantes interruptions, les rendant moins efficaces
Les utilisateurs sont dérangés par des collègues demandant des conseils au lieu d’appeler le Centre de Services
Résolution fréquente à partir de zéro d’un Incident plutôt que d’utiliser une solution déjà référencée
Absence d’informations de synthèse pour la hiérarchie
Incidents perdus ou gérés de manière incorrecte
===== Mise en oeuvre et planification =====
5.1 Séquencement et calendrier
Ne pas mettre en place de manière isolée des autres processus et fonctions (Centre de Services, Gestion des
Problèmes, des Configurations, des Changements, Gestion des Nouvelles Versions)
Si cela n'est pas possible, il est nécessaire d'implémenter au moins en même temps Centre de Services & Gestion des
Incidents (objectifs rapides à atteindre)10
Profiter des démarrages de services importants pour les intégrer tout de suite dans une Gestion des Incidents (même
si le nombre d'Utilisateurs ou le nombre d'appels ne justifient pas dans ce cas la mise en place d'un Centre de
Services et d'une Gestion des Incidents)
Planification de la mise en place du processus : 3 à 6 mois
Mise en place du processus : 3 mois à 1 an
Choix des outils logiciels : prendre les logiciels conformes à ITIL
CMDB inexistante ou pas mise en place en même temps : intégrer les informations de configuration dans la base de Gestion des Incidents
5.2 Difficultés à prévoir :
pas d’engagement de la hiérarchie
manque de clarté des besoins métiers
méthodes de travail non révisées
pas d’informations sur les niveaux de services
manque de connaissances des Incidents résolus
manque d’intégration avec les autres processus
résistance au changement
===== Traitement des Incidents majeurs =====
Il est à noter que le chapitre sur les Incidents majeurs dans le document ITIL Service Support est léger et que tout le chapitre est mis au conditionnel.
Les Incidents majeurs sont ceux pour lesquels le degré d’impact sur l’ensemble des Utilisateurs est extrême.
Devraient être considérés comme Incidents majeurs les Incidents pour lesquels l’échelle de temps des perturbations devient
excessif au regard des temps de résolution (SLAs) (même si cela impacte un petit nombre d’Utilisateurs)
Le Gestionnaire de Problèmes devrait être averti (s’il ne l’est pas déjà) afin d’organiser une réunion (ou une série de réunions) avec toutes les parties concernées :
équipes de support internes
équipes de support des matériels/logiciels (et/ou mainteneur)
équipes de gestion des services de la Production
Le Centre de Services devrait participer à ces réunions et enregistrer dans la base d’Incidents toutes les actions prises et les décisions.
Nous pouvons considérer qu'il s'agit là d'une période de crise qui ne peut pas être décrite de manière exhaustive dans une méthode car l'important est d'agir vite malgré le nombre peut-être important d'intervenants. Cependant, on peut en déduire en pratique deux points à avoir en mémoire :
1. le traitement des Incidents majeurs est sous la responsabilité du Gestionnaire de Problèmes
2. une information à jour et une communication cohérente sont importantes (évolution très rapide des informations et un besoin très fort en informations des équipes de la Production impliqués et des Clients et Utilisateurs impactés).
Ce rôle est rempli par le Centre de Services qui doit collecter ces informations et les enregistrer au niveau de ou
des Incidents associés au Problème.
===== Indicateurs clés de performances (KPI : Key Performance Indicators) =====
Juger de la performance du processus : les KPIs (Key Performance Indicators)
==== Métriques couramment utilisées : ====
nombre total d’Incidents
temps moyen de résolution par code d’impact11
pourcentage d’Incidents résolus dans les temps contractuels (à définir dans les Contrats par code d’impact par exemple)
coût moyen de traitement d’un Incident
pourcentage d’Incidents fermés par le Centre de Services sans support extérieur (la satisfaction Clients est fortement influencée par le fait que le Centre de Services puissent apporter une solution immédiate à l'Incident)
nombre et pourcentage d’Incidents résolus sans déplacement sur site
==== Diffusion des informations ====
La diffusion se fait par le responsable de l’équipe Gestion des Incidents. Il est nécessaire de définir la périodicité et les listes de diffusion en accord avec le Centre de Services et les différentes équipes de support.
La diffusion doit inclure au minimum l’équipe chargée des Contrats de Niveaux de Services et les équipes de support. Il faut aussi considérer aussi une diffusion vers les Clients et Utilisateurs (par le biais des rapports sur les Contrats de Niveaux de Service par exemple)
===== Les 9 Bonnes Pratiques ITIL a retenir =====
==== Mettre en place un point d’entrée unique ====
ITIL préconise de créer une fonction Service Desk (centre de services), point de contact unique (SPOC : Single Point Of Contact) entre l’utilisateur et la gestion des services informatiques : le rôle principal du centre de services est de prendre en charge les incidents qui surviennent au sein du système d’informations afin d’en assurer le traitement rapide et efficace dans le but de restaurer le service le plus rapidement possible pour l’utilisateur. Ceci consiste à ouvrir un « ticket d’incident », à le renseigner, l’enregistrer, le qualifier puis l’affecter à l’entité la mieux adaptée pour le traiter. Le centre de services doit également proposer une interface aux autres processus ITIL (gestion des problèmes, des changements,...).
Notons bien que pour ITIL, une demande de support SAP est considérée comme un incident dès lors que l’utilisateur a des difficultés avec SAP, même si l’application n’est pas remise en cause quand, par exemple l’utilisateur n’a pas la formation requise.
Enfin le centre de service est le fournisseur principal des statistiques permettant d’établir les tableaux de bord destinés aussi bien aux services informatiques qu’aux directions métiers. Ces statistiques sont indispensables à une maîtrise progressive des services informatiques. Les bénéfices du point d’entrée unique sont un gain en coût opérationnel direct (infrastructure téléphonique, salles, matériels, personnels,…), en consolidation des informations de support et en mise en place d’une base de données centralisée. Dans l’esprit d’ITIL, cette fonction est assurée par le Help Desk informatique, y compris pour les incidents applicatifs.
Définir une Procédure d'Escalade
ITIL préconise de définir une « procédure d’escalade », en fonction de l’importance de l’incident dès que la durée de l’appel dépasse un certain seuil. Cette opération consiste à transmettre l’ensemble du dossier à un niveau technique ou hiérarchique supérieur lorsque le problème posé ne peut trouver de réponse à l’échelon inférieur dans les délais requis. Au sein d’un même niveau d’escalade, on peut spécialiser les compétences. La procédure d’escalade, qui définit quand affecter un incident à un niveau supérieur est donc assortie d’une table de routage permettant d’identifier vers qui escalader quoi. Le but est de fournir de l’assistance aux utilisateurs à des conditions économiques satisfaisantes. Les demandes soumises au support, de par leurs natures, font appel à des niveaux de connaissance différents. Pour les demandes les plus simples, la solution consiste à appliquer l’action identifiée comme répondant à un événement explicite. Les demandes les plus complexes font appel à des connaissances approfondies ou à une expérience plus large. Fréquemment, leur résolution passe par la mise en oeuvre de méthodes au cas par cas (itératives ou collaboratives entre plusieurs experts).Le centre de support doit associer au mieux la complexité d’une demande au profil de la ressource nécessaire pour la traiter. Il s’agit d’économiser les experts en les déchargeant des tâches simples ou répétitives, au profit des améliorations qu’ils peuvent apporter sur les systèmes. A l’inverse, il s’agit aussi d’éviter de soumettre des demandes à des acteurs qui n’ont ni la connaissance ni les outils pour les traiter.
L’adéquation entre le type de la demande et le profil sollicité constitue un levier pour améliorer la productivité du support et optimiser la capacité de résolution à chaque niveau de la chaine de traitement des demandes d’assistance.
Nous définissons 3 niveaux de support possibles :
- - N0:E nregistrement, qualification et routage des demandes de support.
- - N1 : résolution simple ou décrite dans une procédure (laquelle aura été élaborée par un niveau plus expérimenté).
- - N2 : résolution complexe.
- - N3 : Constructeurs, Développeurs
==== Surveiller la charge de travail ====
ITIL préconise de mettre en place un suivi du volume des demandes adressées au support afin de déterminer les ressources, et en particulier les équipes à mettre en place pour répondre à un éventuel pic de charge. Ce volume de demandes doit être rapproché du nombre d’utilisateurs afin d’établir des ratios, dont l’analyse permet de détecter les évolutions dans l’activité du centre. On peut ainsi découvrir un problème cyclique ou localisé appelant des mesures palliatives ou correctives :
* Augmenter le personnel sur une certaine période.
* Mener des actions de formation.
* Déclencher une action de maintenance corrective…
Etablir des règles de priorité
ITIL recommande la mise en place d’un système d’ordonnancement basé sur un critère de priorité. Celui-ci est calculé en fonction de deux éléments qui sont l’urgence et l’impact. L’urgence est une évaluation de la criticité de l’incident et reflète la rapidité nécessaire à la résolution d’un incident.Dans l’esprit d’ITIL, qui est de mettre l’utilisateur au centre du dispositif, nous proposons de définir la criticité selon la segmentation suivante des utilisateurs :
* Fréquence d’usage : Utilisateur régulier ou occasionnel de la solution.
* Fonction occupée : coeur de métier ou back office.
* Appartenance : interne ou externe (client, fournisseur)
L’impact concerne plus le volume et l’ampleur de l’incident sur l’entreprise. Toujours conformément à ITIL, on le mesure en exprimant le nombre d’utilisateurs concernés.
==== Organiser le cycle Incident/Problème/Changement ====
La bonne pratique est de constituer une base permettant de tracer ces dysfonctionnements (fichiers log) et de définir les procédures de traitement associées, voire des traitements de reprise automatisés si le volume le justifie. Nous sommes là au coeur de la gestion des problèmes ITIL (constituer une base des erreurs connues).
Le contrôle des problèmes correspond à l’étape d’identification et d’enregistrement du problème, à sa classification (type, priorité,…) puis à la recherche de la cause de dysfonctionnement. Il s’agit de l’évolution du problème en erreur connue.
Le contrôle des erreurs correspond, pour sa part, à l’étape d’identification et d’enregistrement, d’évaluation, puis de résolution de cette erreur, résolution effectuée par un changement de type maintenance corrective. Une communication de la solution vers le centre de services est engagée afin de pouvoir renseigner les détails dans la base de connaissance CMDB (Configuration Management Data Base).
==== Gérer les mises en production par lot ====
ITIL définit le concept de déploiement comme un ensemble de changements autorisés au même instant sur le système (corrections de problèmes techniques et fonctionnels, nouvelle version).
Ces déploiements sont de 3 types :
* Mineur : il s’agit de quelques ajouts ou modifications fonctionnelles légères tant logicielles que matérielles. Souvent, ce type de déploiement annule et remplace les correctifs urgents passés depuis le dernier déploiement majeur ou mineur. Le but de ce déploiement est de consolider une situation qui a pu être corrigée dans l’urgence.
* Majeur : ajouts fonctionnels importants ou des correctifs qui modifient le comportement du système d’informations. A l’instar des déploiements mineurs, ce type de mise en production écrase toutes les modifications antérieures.
* Urgent : traitement d’une situation d’urgence qui peut être résolue par la mise en production d’un correctif. Ce déploiement contient en général, la correction d’un problème connu très localisé ou d’un très petit nombre de problèmes.
Il s’ensuit deux façons de procéder aux mises en production SAP :
* Au fil de l’eau pour les déploiements mineurs ou urgents.
* Par lot pour les déploiements majeurs.
Mettre en oeuvre une CMBD
La CMDB (Configuration Management Data Base) est la base de données contenant l’image complète des composants du système d’informations contribuant à la livraison des Services Informatiques.La CMDB est au coeur des processus ITIL, elle est le pendant outil du SPOC. Son objectif est d’accroître les bénéfices des processus. Son rôle est de les soutenir en produisant une information
fiable, permettant d’obtenir des analyses précises, de prendre des décisions pertinentes et
économiquement justifiées. Pour mener à bien son rôle, elle se nourrit des contrôles traçant
les modifications effectuées sur tous les composants de l’infrastructure. Cette information ainsi
capturée est restituée, partagée, voire enrichie, pour développer de nouveaux potentiels de
productivité et d’économies.
Deux types de CMDB peuvent être implantés :
La CMDB centralisée : c’est la base d’information unique de tous les processus. Il n’existe pas d’autres bases d’informations. Cela signifie en particulier que le même outil permet de gérer les tickets d’incidents et les informations de configuration.
La CMDB étendue ne centralise qu’une partie des informations. Elle sert de référentiel pour les composants, stocke les attributs essentiels et toutes les autres informations disponibles appartenant aux bases de données propres aux processus.
La gestion des demandes de support est effectuée par un outil d’enregistrement intégré à la CMDB. La multiplicité des outils reste un risque de dispersion et d’hétérogénéité des données saisies. Pour le limiter, on préfère une CMDB centralisée avec son propre outil mais ceci n’est pas toujours possible (en particulier dans les relations avec les tiers, on a affaire à plusieurs outils de saisie).L’outil doit être capable de gérer le multi-canal dans le cas où le centre de support peut accepter des demandes par téléphone, mail, site Web,…
La CMDB, qu’elle soit étendue ou centralisée, permet d’une part d’établir des liens entre constats et demandes, et d’autre part d’établir des liens entre incidents, changements et composants du système SAP, facilitant ainsi l’exploitation et la publication. Cela permet alors de publier des statistiques sur la globalité des appels et des incidents, sur les incidents ayant entrainé le plus d’appels au support (top 10) et sur les changements ayant entrainé le plus d’incidents et/ou le plus d’appels.
==== SLA vue client ====
Le niveau de service (Service Level Agreement) a pour objectif de mettre en cohérence la satisfaction
de l’utilisateur avec le fonctionnement du système d’informations de l’entreprise. L’enjeu est donc de « placer le curseur » au bon niveau entre l’excès de confort très coûteux et la minimisation des risques pouvant remettre en cause certaines enjeux stratégiques de l’entreprise.
Ces niveaux de service sont regroupés dans une charte de service qui comprend des engagements (contrats de services entre la maitrise d’ouvrage et le Centre de compétences SAP) :
• Mesurables.
• Atteignables.
• Limités à un périmètre défini.
• Intéressant pour les utilisateurs et les métiers.
• Négociés avec les bénéficiaires des services.
L’engagement peut prendre la forme d’un taux, par exemple, le nombre de demandes réalisées dans les délais convenus.
==== SLA vue interne ====
Les niveaux de service doivent, pour être respectés, se répercuter sous forme d’engagements
tout au long de la chaine de service, que cette chaine reste ou non interne à l’entreprise. Pour les
engagements de prestation en interne à l’informatique, nous parlerons d’OLA (Operational Level
Agreement). Pour les prestataires externes, les contrats de sous-traitance, nous emploierons UC
(Underpinning Contract), ce qui équivaut à des objectifs contractuels.
La CMDB centralisée : c’est la base d’information unique de tous les processus. Il n’existe pas d’autres bases d’informations. Cela signifie en particulier que le même outil permet de gérer les tickets d’incidents et les informations de configuration.
La CMDB étendue ne centralise qu’une partie des informations. Elle sert de référentiel pour les composants, stocke les attributs essentiels et toutes les autres informations disponibles appartenant aux bases de données propres aux processus.
La gestion des demandes de support est effectuée par un outil d’enregistrement intégré à la CMDB. La multiplicité des outils reste un risque de dispersion et d’hétérogénéité des données saisies. Pour le limiter, on préfère une CMDB centralisée avec son propre outil mais ceci n’est pas toujours possible (en particulier dans les relations avec les tiers, on a affaire à plusieurs outils de saisie).L’outil doit être capable de gérer le multi-canal dans le cas où le centre de support peut accepter des demandes par téléphone, mail, site Web,…
La CMDB, qu’elle soit étendue ou centralisée, permet d’une part d’établir des liens entre constats et demandes, et d’autre part d’établir des liens entre incidents, changements et composants du système SAP, facilitant ainsi l’exploitation et la publication. Cela permet alors de publier des statistiques sur la globalité des appels et des incidents, sur les incidents ayant entrainé le plus d’appels au support (top 10) et sur les changements ayant entrainé le plus d’incidents et/ou le plus d’appels.
==== SLA vue client ====
Le niveau de service (Service Level Agreement) a pour objectif de mettre en cohérence la satisfaction
de l’utilisateur avec le fonctionnement du système d’informations de l’entreprise. L’enjeu est donc de « placer le curseur » au bon niveau entre l’excès de confort très coûteux et la minimisation des risques pouvant remettre en cause certaines enjeux stratégiques de l’entreprise.
Ces niveaux de service sont regroupés dans une charte de service qui comprend des engagements (contrats de services entre la maitrise d’ouvrage et le Centre de compétences SAP) :
• Mesurables.
• Atteignables.
• Limités à un périmètre défini.
• Intéressant pour les utilisateurs et les métiers.
• Négociés avec les bénéficiaires des services.
L’engagement peut prendre la forme d’un taux, par exemple, le nombre de demandes réalisées dans les délais convenus.
==== SLA vue interne ====
Les niveaux de service doivent, pour être respectés, se répercuter sous forme d’engagements
tout au long de la chaine de service, que cette chaine reste ou non interne à l’entreprise. Pour les
engagements de prestation en interne à l’informatique, nous parlerons d’OLA (Operational Level
Agreement). Pour les prestataires externes, les contrats de sous-traitance, nous emploierons UC
(Underpinning Contract), ce qui équivaut à des objectifs contractuels.
Commentaires
Enregistrer un commentaire