Les escalades d'incidents et la matrice des priorités
Les escalades d'incidents sont des mécanismes permettant de résoudre les incidents à temps. Les escalades utilisent la priorité de l'incident qui a été calculée à l'aide de la matrice des priorités. En ITSM, il existe deux types d'escalade pour les incidents :
L'escalade fonctionnelle
L'escalade fonctionnelle se produit lorsqu'un incident est assigné à un nouveau groupe de support parce que le groupe travaillant sur l'incident n'a pas les compétences nécessaires requises pour le résoudre. Certaines organisations choisissent de réassigner les incidents à un groupe de support plus expérimenté après un intervalle de temps prédéfini, en accord avec le niveau de service. Le délai varie généralement en fonction de la priorité de l'incident provenant de la matrice des priorités, l'intervalle étant plus court pour les incidents présentant une priorité plus élevée.
L'escalade hiérarchique
L'escalade hiérarchique se produit lorsqu'un membre du personnel alerte une autorité supérieure au sujet d'un incident, généralement son supérieur hiérarchique et le propriétaire du service affecté par l'incident. Le déclenchement de l'escalade hiérarchique dépend de la priorité définie sur la matrice des priorités, et du niveau de service pour l'incident. Si le niveau de service est susceptible d'être enfreint, le supérieur hiérarchique et le propriétaire du service doivent en être informés afin de pouvoir préserver la réussite de l'objectif du niveau de service pour cette priorité d'incident, et de prendre des mesures proactives pour maintenir la satisfaction client. Calculer la bonne priorité à partir la matrice est une étape importante, car cela permet d'éviter de faire des escalades hiérarchiques inutiles. C'est particulièrement vrai pour les incidents à priorité élevée, car beaucoup d'organisations veulent souhaitent leur direction et les propriétaires de services rapidement après qu'ils aient été identifiés, à l'aide de la matrice des priorités.
Par exemple, une organisation peut disposer d’un niveau de service pour répondre à un incident de type P1 dans les 30 minutes, mais si non résolu, de l'escalader à la direction au bout de 20 minutes. Cela garantit que la direction soit au courant du problème de priorité 1 avant que le SLA soit enfreint. Par contre, pour un incident P2 avec un temps de résolution de 4 heures, l'escalade peut ne pas se produire avant 3 heures. Un incident P3 avec un délai de résolution d'une journée peut ne pas être escaladé tant que le niveau de service n'est pas enfreint, et un P4 et un P5 peut ne jamais être escaladé à la direction.
Lorsque les escalades hiérarchiques sont en place, il est important de les mettre à l’essai lors des tests de scénarios de la matrice des priorités. Les escalades qui se sont produites devraient être revues régulièrement, en incluant le personnel du support et la direction afin d’identifier s'il existe le moindre problème avec la matrice des priorités ou avec les directives de priorité associées, problème qui doit être traité.
Utiliser une matrice des priorités pour les incidents
La gestion des incidents est le processus le plus courant d’utilisation d’une matrice des priorités. Presque toutes les organisations possèdent une forme de gestion des incidents, car même les organisations qui n'ont pas de service desk doivent gérer des incidents. La création et l'utilisation d'une matrice des priorités afin de déterminer la priorité de tous les incidents qui sont signalés par les utilisateurs sont essentielles pour bâtir et maintenir la satisfaction des utilisateurs. La plupart du temps, vos équipes de support auront plus d'incidents ouverts qu'ils ne peuvent en traiter. Une matrice des priorités leur permet d’organiser leurs activités, et de travailler sur les incidents les plus importants en premier. Pour la gestion des incidents, la matrice des priorités utilise une évaluation de la façon dont l'incident affecte les utilisateurs, à la fois en termes d'impact et d'urgence, pour ainsi définir la priorité. En utilisant la matrice des priorités de cette manière, les équipes peuvent vérifier que les incidents affectant l'entreprise deviennent prioritaires, et que le personnel du support ne fasse pas de suppositions, ni ne 'sélectionne' les tâches qu'ils préfèrent effectuer en premier.
La plupart des outils permettent l'attribution automatique d'une priorité à un incident en utilisant une fonction de priorité intégrée. Cela peut permettre d'accélérer le processus de gestion des incidents ; malgré tout, il est recommandé que le personnel du service desk vérifie la priorité qui a été automatiquement assignée à l'aide de la matrice, car les équipes peuvent avoir mal saisi l'impact et l'urgence.
Certains outils permettent à certains utilisateurs, comme par exemple les dirigeants de l'entreprise et les utilisateurs essentiels, d'être identifiés en tant que VIP (personnes très importantes). Lorsque ces utilisateurs signalent un incident, l'outil peut automatiquement relever le niveau d'urgence et/ou d'impact utilisé dans la matrice des priorités, ce qui permet l'allocation de priorités plus élevées que la normale pour ce type d'incident.
Les outils possèdent également des fonctionnalités pouvant évaluer l'impact d'un incident en fonction de facteurs incluant le caractère essentiel de certains systèmes ou de services en particulier, de moments de la journée, et de groupes d'utilisateurs, qui sont ensuite pris en compte dans la recherche effectuée sur la matrice des priorités afin de déterminer la priorité adéquate pour l'incident. L'outil enregistre ces facteurs en regard de l'incident, facteurs qui peuvent être utilisé pour étayer la priorité calculée à partir de la matrice dans le cas d'un éventuel conflit ultérieur.
Il est recommandé de développer une procédure pour résoudre les conflits des priorités d'incident. Une matrice des priorités simplifie l'attribution des priorités pour les incidents ; toutefois, la priorité choisie dépendra toujours des informations recueillies par les utilisateurs et les systèmes de supervision, et les attentes des utilisateurs peuvent varier. Par conséquent, dans certaines situations, la matrice des priorités donne une priorité différente à l'incident que la priorité attendue par l'utilisateur. Lorsque cela se produit, l'utilisateur doit être capable de contester la priorité qui lui a été assignée à partir de la matrice, et le service desk doit être capable de modifier la priorité si la contestation est maintenue.
Il doit également être possible de changer la priorité d'un incident au cours de son cycle de vie. Pour un grand nombre d'incidents, l'impact complet n'est pas connu lorsqu'il est d'abord reporté par un seul utilisateur. Une faible priorité est attribuée à l'incident car la matrice des priorités utilise un faible impact. À mesure que les utilisateurs signalent le même problème, ou des problèmes semblables, l'impact augmente, et la matrice des priorités donne alors une priorité plus élevée. Pour ce type d'incident, où l'impact connu augmente au fil du temps, il est important de continuer à utiliser la matrice des priorités afin de déterminer la nouvelle priorité. Parfois, les service desks réagissent à la pression des utilisateurs qui leur demandent d'augmenter les priorités sans utiliser la matrice. Cela peut occasionner des incohérences, et encourager des comportements utilisateurs non bénéfiques.
Utiliser une matrice des priorités pour les incidents majeurs
Un incident majeur est un incident présentant un impact désastreux pour l'entreprise. Il peut s'agir d'une perturbation excessive des services, ou d’un risque de défaillance ultérieure suite à des événements comme par exemple une attaque de virus. Une pratique standard consiste à avoir une variante séparée du processus de gestion des incidents pour ces incidents majeurs. Cette variante reconnaît la nécessité urgente de résoudre l'incident. Votre matrice de priorités doit être capable d'identifier clairement quels incidents sont majeurs en fonction de l'impact et de l'urgence. Par définition, les incidents majeurs ont la priorité la plus élevée. Il est important de vérifier au moyen des tests de scénarios que votre matrice des priorités soit bien capable d'identifier clairement quels sont les incidents majeurs et quels sont ceux qui ont juste une priorité élevée.
Les priorités qui sont définies comme incidents majeurs dépendant du nombre de priorités différentes inclues sur votre matrice des priorités. Dans le cas où vous n'avez que trois priorités, les incidents majeurs seront toujours des P1. Toutefois, avec trois niveaux de priorité seulement, vous risquez d'utiliser votre processus des incidents majeurs sur une base régulière. Il est préférable d'avoir un plus grand nombre de priorités sur votre matrice de priorités, et de réserver P1 pour les véritables incidents majeurs qui ont un impact extrême et catastrophique pour l'entreprise. Les différents niveaux d'impact et d'urgence de votre matrice des priorités doit être soigneusement conçue pour que la priorité P1 ressorte pour tous les incidents majeurs véritables. Cela nécessite une analyse soignée de vos services, notamment l'évaluation de leur caractère essentiel pour l'entreprise, ainsi que de connaître la façon dont les utilisateurs utilisent ces services.