Contrôle des problèmes

5. Activité : le contrôle des problèmes

5.1. Activités du contrôle des problèmes



5.2. Identification et enregistrement du problème

Les différentes sources sont :

  • enregistrement de nouveaux incidents

  • analyse des incidents

  • analyse de l’infrastructure informatique (problèmes pouvant potentiellement générer des incidents)

  • incident majeur ou significatif nécessitant une solution structurelle

D'autres sources en dehors de la gestion opérationnelle des services (Service Support) existent :

  • gestion de la capacité

  • gestion de la disponibilité

A noter :

  • L’organisation peut décider de ne pas lancer d’analyse sur certains problèmes (coût non justifié et classement sans suite)

  • L’enregistrement du problème est similaire à celui d’un incident (différence principale : pas de reprise des données utilisateurs dans l'enregistrement du problème).

5.3. Classification du problème

Elle est similaire à la classification d’un incident :

  • catégorie : groupes de domaines techniques (calqué sur l’organisation)

  • impact : effet sur les activités métiers (utiliser les liens dans la CMDB et codification en relation avec les métiers)

  • urgence : délai maximum que peut supporter la résolution d’un problème

  • priorité : ordre de traitement d’un élément dans une liste d’attente

Quelques rappels :

  • Priorité : il s'agit principalement d'une combinaison impact & urgence mais aussi de risques de défaillance et de disponibilité des ressources ; la priorité est à modifier en utilisant le bon sens et en ayant à l’esprit les activités métiers (ne pas appliquer systématiquement à la lettre ce que donne la combinaison impact & urgence)

  • Impact : l'une des difficultés est qu'il s'agit d'une classification à un instant donné (elle peut évoluer dans le temps). Par exemple, l'un des facteurs est l'évolution du nombre d'incidents associés au problème en cours de résolution (ce nombre peut devenir préoccupant au fil du temps et peut nécessiter d'augmenter la priorité pour que le problème soit résolu plus rapidement). C'est pour cela qu'il est intéressant de définir un compteur d’incidents associés à un problème et de définir des seuils de dépassement de ce compteur afin d'alerter automatiquement en cas de dépassement du seuil.

5.4. Investigation et diagnostic sur le problème

Passage d'un problème en Erreur Connue :

  • la cause identifiée d’un problème est une défaillance d’un élément de configuration (matériel, logiciel, documentation, procédure)

  • si aucun élément est en cause, il faut créer un élément de configuration factice pour fermer le problème

  • exemple : incidents/problèmes liés à un manque général et connu de formation des utilisateurs : créer un élément « problème de formation » et passer le problème en erreur connue sur cet élément

La préconisation de la démarche ITIL® est que toutes les documentations sur l’infrastructure doivent être disponibles :

  • applications

  • système d’exploitation et socle logiciel

  • réseaux

Attention : les spécialistes travaillent souvent sur la résolution des incidents (prioritaire) et la résolution des problèmes et il est nécessaire de bien équilibrer le temps passé sur ces deux processus.

Précédent : Bénéfices