Description du processus

Flux du processus

Comme l’illustrent les figures 6-2 et 6-3, après détection ou déclaration de l’incident, le centre de services débute son action par l’enregistrement du contexte de l’événement (symptômes, premier diagnostic, information sur l’utilisateur et la configuration). Ces premiers éléments permettent entre autres de déterminer si cet incident s’est déjà produit et s’il s’agit d’une erreur connue avec une solution palliative, ou éventuellement une solution au sein de la CMDB. Dans ce cas, l’utilisation de cette solution permet de gagner un temps considérable.L’étape suivante consiste à évaluer la priorité qui va être associée à l’incident en fonction de l’urgence de la situation et de l’impact sur le système d’information. Celle-ci va déterminer les ressources qui seront attribuées à la résolution. La résolution de l’incident peut très bien se faire dès les premiers instants par le premier niveau en utilisant la base de connaissances et de configuration (CMDB) dans laquelle se trouvent des informations sur les incidents du même type, les erreurs connues et leurs solutions palliatives ou encore des solutions définitives. En l’absence de solution, une priorité de traitement est déterminée et on détermine les compétences nécessaires pour résoudre le dysfonctionnement. Ensuite, si nécessaire, un technicien se voit attribuer le traitement de l’incident sur le site incriminé.La classification est certainement la phase la plus importante de la gestion des incidents. Elle permet de déterminer quel est le service, l’application ou le matériel impliqué, les personnes touchées et ainsi d’appréhender l’ampleur, donc l’impact de l’incident. En disposant des informations du contrat de service, la classification permet de préciser les délais de restitution garantis et les fonctions prioritaires. La classification permet également de préciser les ressources nécessaires lors de l’investigation en vue de résoudre cet incident, et en particulier les spécialistes qu’il convient de mobiliser.Lorsqu’un problème sans solution est identifié par le technicien, le centre de services communique l’information à l’équipe de gestion des problèmes. Même si la responsabilité de la résolution à été transférée à un autre groupe de spécialistes, le centre de services garde la responsabilité de l’incident et doit le gérer jusqu’à sa clôture et la satisfaction du client. Après avoir identifié une solution à l’incident, celle-ci est appliquée en vue de résoudre le dysfonctionnement, puis une éventuelle restauration des données est démarrée afin de rendre le service de nouveau disponible. Lorsque l’incident est résolu, avec l’accord de l’utilisateur, le centre de services doit clôturer l’intervention et s’assurer que le rapport d’incident est correctement rempli avec le détail des actions et de la solution mise en œuvre, le temps passé et les coûts associés. Cet événement est sensible puisqu’il détermine l’instant où l’utilisateur est censé être satisfait. Dans les faits, il arrive que celui-ci ne perçoive pas la situation de la même façon. S’ensuit alors une négociation entre l’utilisateur et le centre de services avec une éventuelle réouverture de l’incident. Le centre de services assume la responsabilité de la gestion des incidents et doit en conséquence contrôler le déroulement de leurs résolutions tout en informant l’utilisateur. Ce contrôle doit s’effectuer en surveillant le statut et la progression de chaque incident ouvert, et en particulier ceux qui transitent entre plusieurs groupes de spécialistes afin d’éviter l’effet « ping-pong ». Comme on a pu le voir précédemment, deux modes de gestion peuvent coexister dans le traitement des incidents. Le premier correspond aux principe d’escalade. Si un incident ne parvient pas à être réglé rapidement, et lorsque l’on craint de dépasser le délai négocié du SLA, il est indispensable de changer le statut de cet incident afin de lancer la procédure d’escalade (fonctionnelle ou hiérarchique). Ce type de traitement ne doit pas être confondu avec la gestion des problèmes qui prend en compte le coté récurrent d’un incident. Dans ce cas, lorsque la résolution d’un dysfonctionnement impose un changement dans la configuration, il peut être nécessaire d’imaginer une solution de contournement. Cette solution de contournement doit alors être examinée par le processus de gestion des problèmes, puis approuvée avant sa mise en œuvre, sans oublier de mettre à jour la base CMDB afin que tous les techniciens aient connaissance de cette nouvelle solution, même s’il ne s’agit que d’un palliatif. Si aucune solution n’est trouvée pour un incident, il se peut qu’il soit nécessaire de rencontrer plusieurs fois ce dysfonctionnement avant d’identifier un problème.

Planification et mise en œuvre

La mise en place d’un processus de gestion des incidents ne peut se faire sans la présence d’un centre de services. Mais au-delà de ce centre, la mise en place des autres processus de support, comme la gestion des problèmes, la gestion du changement et la gestion des configurations, est indispensable. Cependant, la gestion des incidents est le processus qui offre le meilleur retour sur investissement, ce qui est loin d’être négligeable lorsque son implantation donne lieu à quelques grincements de dents. La mise en place d’un centre de services et de la gestion des incidents peut prendre plusieurs mois. Aussi on aura tout intérêt à prévoir la création de ce centre dès le début d’un gros projet informatique, afin que l’importance du centre croisse avec celle du projet, avant de revenir à un équilibre raisonnable.

Améliorations

Des améliorations peuvent être obtenues par la formation des techniciens « classiques » dans le but de leur faire prendre conscience de leur rôle auprès des utilisateurs. Des améliorations peuvent également provenir de la mise à jour régulière de la base de gestion des configurations (CMDB), et de la base de données des connaissances, permettant de recouper les informations concernant les erreurs connues, leurs résolutions et les solutions de contournement. Une application informatique de gestion des incidents est indispensable. Il existe désormais des outils de support automatiques et efficaces disposant de systèmes experts pour la classification des incidents, mais également de procédure d’escalade automatique, de base de connaissances sur les incidents et leurs solutions.

Mesures et contrôles

Les métriques que l’on peut mettre en place pour valider l’efficacité du processus proviennent essentiellement du centre de services et concernent le nombre et la durée des incidents, leurs impacts sur le système d’information, et le ratio entre incidents résolus au premier niveau et ceux qui ont été transférés vers les supports de niveaux 2 et 3.

Documents et rapports de gestion

À l’instar des rapports du centre de services dont ils proviennent, les rapports de gestion doivent s’adresser à plusieurs publics tels que les responsables des directions fonctionnelles, les membres de la direction générale, les responsables de l’informatique, mais également les représentants des utilisateurs eux-mêmes..