Gestion des incidents et des problèmes ITIL

En tant que professionnels du service desk IT, nous souhaitons offrir à nos utilisateurs une expérience de service tout simplement extraordinaire. Nous pouvons gérer les incidents et restaurer le service aussi rapidement que possible grâce au processus d'Incident Management, mais l'objectif ultime est de ne pas avoir d'incidents du tout. C'est pourquoi nous vous présentons le Problem Management, pour vous aider, vous et votre organisation, à atteindre ces résultats.

L'objectif principal du Problem Management est de prévenir la survenue d'incidents et, si des incidents se produisent, d'empêcher qu'ils ne se reproduisent. Imaginez un prestataire de services qui ne ferait que réagir à des incidents se répétant continuellement, sans jamais être véritablement résolus. Imaginez qu'un tel scénario devienne « la normalité » : résoudre encore et encore les mêmes incidents. Avec le temps, le nombre d'incidents augmentera, le coût de leur gestion s'accroîtra, la satisfaction des clients et des utilisateurs chutera, la réputation du service desk en pâtira, les initiatives de Shadow IT deviendront la norme, et le résultat collectif sera un impact néfaste sur la capacité à mener l'activité.

De nombreuses organisations souffrent inutilement parce qu'elles ne disposent pas d'un processus de Problem Management efficace. Bien souvent, cela s'explique par le fait que les équipes IT confondent le Problem Management avec l'Incident Management et ne comprennent pas pleinement sa relation avec le Change Management. Bien que ces processus fonctionnent de pair, l'objectif du Problem Management est de soutenir l'Incident Management en empêchant les incidents de se produire dès le départ — grâce au processus de Change Management !

En parcourant ce guide, gardez à l'esprit la valeur pour l'entreprise de faire ce qui est essentiel pour votre organisation, et de le faire correctement en mobilisant les personnes, les processus, la technologie et les fournisseurs pour atteindre vos objectifs. L'excellence de service est un parcours qui ne s'arrête jamais et qui doit être continuellement pratiqué. Et par-dessus tout, lorsque vous commencerez à observer des améliorations dans votre délivrance de services globale, célébrez vos succès !

Qu'est-ce que le Problem Management ITIL ?

Le Problem Management est un processus d'IT service management chargé de gérer le cycle de vie des « Problèmes » sous-jacents. Le succès est atteint en détectant rapidement les Problèmes et en apportant des solutions ou des contournements afin de minimiser l'impact sur l'organisation et d'éviter toute récurrence. Le Problem Management cherche également à identifier l'erreur dans l'infrastructure IT à l'origine du problème et contribuant aux Incidents que les utilisateurs peuvent rencontrer. L'IT Infrastructure Library (ITIL) fournit les définitions suivantes pour ce processus :

• Problème : « La cause d'un ou plusieurs Incidents. La cause n'est généralement pas connue au moment de la création d'un Enregistrement de Problème »
• Erreur : « Un défaut de conception ou un dysfonctionnement qui provoque la défaillance d'un ou plusieurs services IT ou d'autres éléments de configuration »
• Erreur connue : « Un Problème dont la cause racine et le contournement sont documentés »
• Cause racine : « La cause sous-jacente ou initiale d'un incident ou d'un problème »

Problem Management proactif vs. réactif

Le Problem Management peut être soit réactif, soit proactif.

• Le Problem Management réactif est la réaction de résolution de problèmes qui survient lorsqu'un ou plusieurs Incidents se produisent.
• Le Problem Management proactif consiste à identifier et résoudre les problèmes avant que des incidents ne se soient produits. Cette activité est associée au Continual Service Improvement (CSI).

La valeur du Problem Management pour l'entreprise

Le processus de Problem Management fonctionne en conjonction avec l'Incident Management et le Change Management pour créer de la valeur pour l'entreprise de diverses façons. L'objectif principal du Problem Management est de minimiser l'impact des Problèmes sur l'entreprise et d'éviter leur récurrence. Lorsqu'il est mis en œuvre avec succès, les temps d'arrêt et les perturbations sont réduits. Les bénéfices supplémentaires comprennent :

• Disponibilité accrue des services
• Amélioration de la qualité de service
• Réduction du temps de résolution des Problèmes
• Diminution du nombre d'Incidents
• Productivité accrue
• Réduction des coûts
• Amélioration de la satisfaction client

L'adoption et la mise en œuvre des processus et technologies ITIL permettront de minimiser le chaos auquel les organisations IT peuvent faire face dans un paysage technologique en constante évolution. Bien que le Problem Management soit un processus à part entière, il dépend d'un processus d'Incident Management efficace et des outils appropriés ; des outils qui incluent une interface commune, l'accès aux connaissances disponibles, les informations de Configuration Management et l'interaction avec d'autres processus ITIL connexes. Cela garantit que les Problèmes sont identifiés, contiennent les détails pertinents et sont traités aussi rapidement que possible. ITIL ne fournit pas aux organisations une méthode exacte d'adoption du Problem Management, mais plutôt un framework structuré qui nécessite des ajustements pour s'adapter aux besoins et contraintes propres à chaque entreprise. Des ajustements réguliers de ces processus ITIL internes soutiendront en définitive l'agilité, démontreront la valeur pour l'entreprise et aideront les organisations à être compétitives dans leur marché.

Flux du processus de Problem Management

Comment le Problem Management fonctionne-t-il ? Le Problem Management ITIL va bien au-delà de la simple résolution des Incidents ; il prend en compte l'intégralité du cycle de vie d'un Problème. Le flux du processus du cycle de vie du Problem Management peut être structuré pour gérer des Problèmes initialement signalés comme Incidents par des utilisateurs ou des techniciens du service desk via un portail self-service, par téléphone, par e-mail, en personne, ou des Problèmes potentiels détectés automatiquement par le personnel ou les technologies ITSM avant qu'aucun Incident ne se produise. Le périmètre du flux du processus de Problem Management comprend :

1) Détection du Problème

Les Problèmes peuvent être détectés de diverses manières, notamment à la suite d'un signalement d'Incident, d'une analyse continue des Incidents, d'une détection automatisée par un outil de gestion des événements, ou d'une notification d'un fournisseur. Un Problème est généralement détecté lorsque la cause d'un ou plusieurs Incidents signalés au service desk est inconnue. Il est possible que le service desk ait résolu l'Incident et qu'il puisse se reproduire, mais sans certitude sur la cause racine sous-jacente, une fiche de Problème est alors créée. Dans d'autres cas, il peut être évident pour le service desk qu'un Incident signalé est associé à un Problème. Ce Problème peut avoir déjà été enregistré — Problème connu — et l'Incident peut être lié à la fiche de Problème existante. Si le Problème n'a pas encore été enregistré, une fiche de Problème doit être créée immédiatement pour contribuer à garantir les performances du service.

2) Enregistrement du Problème

Afin de conserver un historique complet, tous les Problèmes, quelle que soit la méthode utilisée pour les identifier et les signaler au service desk, doivent être enregistrés avec tous les détails pertinents, notamment la date/heure, les informations sur l'utilisateur, la description, l'élément de configuration concerné issu de la CMDB, les Incidents associés, les détails de résolution et les informations de clôture.

• Catégorisation - Une fois enregistré, toutes les catégories appropriées doivent être sélectionnées afin d'assigner, d'escalader et de surveiller correctement les fréquences et les tendances des Problèmes.
• Priorisation - L'attribution d'une priorité est déterminante pour définir comment et quand le Problème sera traité par les équipes. Elle est déterminée par l'impact — le nombre d'Incidents associés, qui peut renseigner sur le nombre d'utilisateurs affectés ou son impact sur l'entreprise. L'urgence du Problème — la rapidité avec laquelle une résolution est requise — est également prise en compte pour définir la priorité.

3) Investigation et diagnostic

Une investigation sur la cause racine du Problème sera menée en fonction de l'impact, de la sévérité et de l'urgence du Problème en question. Les techniques d'investigation courantes incluent la consultation de la base de données des erreurs connues (KEDB) pour trouver des Problèmes et des résolutions correspondants, et/ou la reproduction de la défaillance pour en déterminer la cause.

4) Contournement

Dans certaines situations, il est possible de fournir un correctif temporaire ou un contournement à l'utilisateur confronté à l'Incident lié au Problème. Il est cependant essentiel de rechercher une résolution permanente du changement à l'erreur sous-jacente détectée par le Problem Management.

5) Création d'une fiche d'erreur connue

Une fois l'investigation et le diagnostic terminés, il est important de créer une fiche d'erreur connue. Si de futurs Incidents ou Problèmes surviennent, le technicien du service desk chargé de l'investigation identifiera et fournira une résolution plus rapidement en s'appuyant sur la base de données des erreurs connues (KEDB) et le(s) contournement(s) associé(s).

6) Résolution

Une fois résolu, la solution peut être mise en œuvre selon la procédure de changement standard et testée pour confirmer le rétablissement du service. Toutefois, si un changement normal était nécessaire, une Demande de Changement (RFC) associée sera émise et approuvée avant qu'une résolution ne soit appliquée au Problème.

7) Clôture

Après confirmation que l'Erreur a été résolue, le Problème et tous les Incidents associés peuvent être clôturés. Le technicien du service desk doit s'assurer que les détails de classification initiaux sont exacts pour référence et reporting futurs.

• Revue des Problèmes majeurs - Les Problèmes majeurs sont définis par l'analyse d'impact sur l'activité (BIA) et l'évaluation des risques (RA) d'une organisation pour déterminer la réponse et la priorité (impact, urgence et sévérité du Problème). L'objectif d'une revue de Problème majeur est d'améliorer continuellement le processus de Problem Management pour répondre aux problèmes métier majeurs. Un processus de revue peut identifier les actions réalisées correctement, celles réalisées incorrectement, ce qui peut être amélioré, les risques supplémentaires, la façon de prévenir la récurrence et la nature de la responsabilité éventuelle d'un tiers. Cette revue ne doit pas rester en vase clos ; elle doit être partagée avec les membres de l'équipe dans le cadre de sessions de formation et de sensibilisation.
• Problem Control et Error Control - Dans certaines situations, les termes Problem Control et Error Control peuvent être utilisés au cours du cycle de vie du Problem Management. Le Problem Control peut être intégré à la phase d'investigation, avec pour objectif de trouver la cause racine du problème et de le transformer en erreur connue. Cela aide le technicien du service desk à fournir des contournements temporaires à l'utilisateur. L'Error Control, quant à lui, fait partie de la phase de résolution, avec pour objectif de convertir les erreurs connues en solutions et de les supprimer de la base de données des erreurs connues (KEDB) lorsque cela est nécessaire.

Processus ITIL interdépendants : Incident et Change Management

Les processus ITIL s'interfacent les uns avec les autres tout au long du cycle de vie de la délivrance de services. Le Problem Management et l'Incident Management sont étroitement liés au Problem Management, mais ils ne sont pas identiques. Bien que ces deux processus soient mis en œuvre par le département IT, ils ont chacun des objectifs différents. Le Problem Management se concentre sur la prévention ou la minimisation de l'impact d'un ou plusieurs Incidents en identifiant la cause racine. L'Incident Management cherche à résoudre rapidement un Incident et à rétablir le service auprès des utilisateurs en temps opportun. Le rétablissement du service dans l'Incident Management ne signifie pas nécessairement que l'incident ne se reproduira pas. La majorité des Problèmes sera déclenchée en réaction à un ou plusieurs Incidents, mais dans certaines situations, des Problèmes sont créés lorsque des testeurs testent une version, par exemple lors de l'utilisation du processus de Service Validation and Testing, ou lorsque des fournisseurs détectent des défauts dans leurs produits ou services.

Bien que la Service Operation s'efforce d'atteindre la stabilité, il existe des situations où le changement est nécessaire. C'est pourquoi le Change Management est également étroitement lié au Problem Management. Les changements peuvent être pré-approuvés ou nécessiter une approbation ; dans les deux cas, une RFC est créée pour documenter le changement requis. Une Demande de Changement (RFC) est souvent déclenchée au cours du cycle de vie du Problem Management lorsque du nouveau matériel, des logiciels, des processus ou une infrastructure améliorés ou mis à niveau sont nécessaires pour résoudre un problème.

Autres relations clés entre processus ITIL :

• Configuration Management
• Service Level Management
• Availability Management
• Capacity Management
• Event Management
• Service Validation and Testing

Rôles et responsabilités du Problem Management

Des rôles et responsabilités bien définis sont essentiels à l'exécution efficace d'un processus de Problem Management réussi. L'équipe de Problem Management est composée des éléments suivants :

1) Problem Manager

Un Problem Manager est une personne désignée qui peut, ou non, être responsable d'autres rôles organisationnels. Ce process owner du processus de Problem Management est responsable de tous les aspects de sa coordination, notamment :

• Agir en tant qu'interlocuteur auprès du personnel responsable de la résolution des Problèmes
• S'assurer que les Problèmes sont résolus dans les délais définis par leur SLA
• La propriété et la gestion de la base de données des erreurs connues (KEDB)
• La clôture des Problèmes
• La coordination de la revue des Problèmes majeurs

Note : Le Problem Manager et l'Incident Manager ne doivent pas être la même personne en raison de possibles conflits dans la priorité d'exécution.

2) Équipe de résolution des Problèmes

La résolution des Problèmes peut être prise en charge par des membres internes de l'équipe de support technique ou par des fournisseurs et prestataires externes. Dans les situations où un Problème grave ou majeur survient, le Problem Manager peut constituer une équipe dédiée au Problem Management composée de ressources disposant d'une expertise spécifique.

Checklist des fonctionnalités d'un logiciel de Problem Management

Pour les organisations IT qui évaluent des logiciels de Problem Management et/ou des suites d'IT service management proposant des fonctionnalités de Problem Management, les fonctionnalités suivantes sont importantes, voire essentielles, pour soutenir efficacement les processus clés.

Au minimum, un logiciel de Problem Management doit permettre aux administrateurs de :

• Configurer les processus de gestion des problèmes
• Configurer la catégorisation des incidents
• Créer, modifier, résoudre et clôturer des fiches de problème
• Mettre en œuvre ITIL ou d'autres frameworks de meilleures pratiques sectorielles
• Mettre à jour automatiquement le statut ou clôturer tous les incidents associés lors de la mise à jour ou de la clôture d'un problème
• Lier les problèmes aux CIs, aux incidents et aux demandes de changement
• Attribuer un impact et une urgence à un problème
• Différencier les problèmes des erreurs connues
• Assigner automatiquement ou manuellement des tâches à des personnes ou des équipes
• Automatiser l'enregistrement des données historiques dans un journal d'audit
• Générer des numéros de fiche uniques associés à chaque fiche de problème
• S'intégrer avec l'Incident Management, le Change Management, le Configuration Management et le Knowledge Management
• Automatiser la création de problèmes en fonction des règles métier et des SLAs
• Documenter et gérer les artefacts de connaissance associés aux problèmes et aux erreurs connues
• Visualiser les CIs impactés depuis une fiche de problème
• Suivre le temps de travail
• Se connecter à une base de connaissances tierce
• Utiliser des configurations de champs flexibles incluant texte libre, listes déroulantes, date/heure, pièces jointes, captures d'écran
• Créer des modèles pour les problèmes récurrents
• Rechercher des solutions, des contournements et des erreurs connues
• Documenter l'analyse des causes racines
• Disposer de fonctionnalités de recherche et de reporting sur les problèmes