Il est parfois utile de revenir aux fondamentaux. Par exemple, en nous rappelant l'utilité de la réponse aux incidents (RI). La réponse est simple : faire tourner l'entreprise. Mais cette simplicité est trompeuse. Il s'agit d'une responsabilité incroyablement lourde, comme vous le savez si quelque chose a déjà mal tourné dans votre capacité à répondre à un incident majeur. Selon le GartnerChaque minute d'indisponibilité de vos systèmes coûte en moyenne $5,600, soit plus de $300,000 par heure. C'est beaucoup d'argent, et beaucoup de pression.
Chez KT, nous avons rassemblé nos têtes et avons trouvé sept meilleures pratiques pour assurer le succès de votre programme de RI. Il s'agit de suggestions opérationnelles, techniques et organisationnelles, mais toutes contribuent à la création d'une équipe de RI de premier ordre.
Pourquoi la réponse aux incidents ?
ITIL décrit un incident comme toute interruption ou perturbation des services informatiques normaux. Nous pouvons le rendre plus personnel pour votre entreprise, et dire qu'un incident est toute circonstance dans laquelle un système agit d'une manière qui a un impact négatif sur vos clients. Il ne doit pas nécessairement s'agir d'une défaillance totale du système. Prenez un système de messagerie électronique qui fonctionne lentement. Est-ce que cela constitue un incident ? En utilisant notre définition, vous pouvez être sûr que oui, car des e-mails lents signifient une réponse plus lente aux demandes du service client, des réactions retardées aux demandes de propositions (RFP), un développement de produit ralenti, et à peu près toutes les activités que votre entreprise entreprend pour faire du profit.
La RI est votre processus de réponse à ces incidents (et les incidents sont différents des problèmes, dont nous parlerons plus tard). Une RI réussie - ce qui signifie qu'elle est à la fois rapide et efficace - permet d'améliorer l'efficacité des travailleurs et des processus, d'accroître la productivité et, en fin de compte, d'augmenter les revenus de l'entreprise. Il s'agit vraiment d'une opération essentielle à la mission.
7 meilleures pratiques pour une réponse superbe aux incidents
Voici huit bonnes pratiques qui vous permettront d'affiner votre équipe de RI et de la rendre très performante.
1. Communiquer, communiquer, communiquer
Il existe depuis toujours un gouffre de communication entre l'informatique et le reste de l'organisation, et plus particulièrement entre l'informatique et les utilisateurs. Cela pose des problèmes lorsque l'on tente de fournir une excellente RI, car la plupart, sinon la totalité, de vos incidents seront signalés par vos utilisateurs. Ils doivent disposer d'un moyen facile de faire ce signalement, afin que vous soyez informé des incidents le plus rapidement possible. Ensuite, vous devez les tenir informés en temps réel de la résolution de l'incident. Tout cela est nécessaire pour gagner leur confiance afin qu'ils collaborent plus étroitement avec vous - une collaboration essentielle - lors de futurs incidents. Pour commencer, ouvrez plusieurs canaux pour permettre aux utilisateurs de créer facilement des tickets. Par exemple, ils doivent pouvoir alerter l'équipe de RI par e-mail, par chat, par un portail ou par un réseau social d'entreprise comme Yammer. Vous devez également créer des mécanismes de libre-service pour que les utilisateurs puissent résoudre les incidents faciles. Rendez le libre-service facilement accessible et informez les utilisateurs des avantages de l'auto-assistance et de l'utilisation de la base de connaissances pour résoudre les problèmes par eux-mêmes.
Ensuite, pendant que l'équipe de RI travaille à la résolution de l'incident, il est essentiel de tenir tout le monde au courant de la progression en temps réel. Deux informations doivent être affichées en permanence : le statut de l'incident (l'état actuel de la résolution, y compris le temps estimé d'achèvement) et la priorité de l'incident (l'importance de la résolution de l'incident par rapport aux autres incidents).
L'automatisation peut aider, en envoyant des mises à jour automatiques tout au long du cycle de vie des incidents majeurs. Des notifications claires et visibles empêcheront également les utilisateurs de créer des tickets en double et de surcharger le service d'assistance. Même s'il n'y a rien à signaler, dites-le à vos parties prenantes, toutes les heures ou toutes les demi-heures. Et disposez d'une ligne dédiée pour répondre immédiatement aux incidents majeurs et offrir un soutien à toutes les personnes concernées.
2. Adopter les processus DevOps
Avant que DevOps ne devienne un courant dominant, l'équipe RI était essentiellement là pour elle-même. Ce sont eux, plutôt que les personnes qui avaient réellement construit les systèmes, qui étaient responsables de tous les incidents. Il n'y avait pas de boucle de rétroaction vers les développeurs sur la façon de résoudre les interruptions répétitives d'une application particulière, par exemple. Il y avait très peu de communication entre les personnes qui construisaient les systèmes et celles qui étaient chargées de les réparer lorsque les choses allaient mal. En effet, l'une des raisons de la création de DevOps était d'éliminer ces silos organisationnels. C'est essentiel en raison de la complexité des systèmes d'aujourd'hui : ils sont tous interconnectés et ce qui affecte l'un d'entre eux est susceptible d'en affecter d'autres.
Avec une structure DevOps en place, les développeurs font un meilleur travail dans la construction de leurs systèmes, parce qu'ils savent maintenant qu'ils doivent également les soutenir - plus besoin de jeter les problèmes par-dessus le mur pour qu'un autre groupe s'en occupe. Les équipes de RI disposent d'un soutien et, généralement - si DevOps est bien fait - d'une documentation claire sur la manière de maintenir des systèmes complexes en état de marche.
3. Sentir quand il faut "essaimer"
Bien que la plupart des entreprises disposent d'une structure "à plusieurs niveaux" pour traiter les incidents - le niveau 1 est le service d'assistance, le niveau 2 implique des spécialistes des applications et le niveau 3 est généralement constitué d'experts en systèmes et de développeurs - vous ne voulez pas appliquer universellement cette structure pour résoudre les incidents majeurs. Vous voulez donner à votre équipe la liberté de "fourmiller" si nécessaire.
Cela s'avère généralement nécessaire lorsqu'un problème a un impact commercial considérable. Dans ce cas, vous souhaitez vous écarter des processus normaux de RI à plusieurs niveaux. Le Swarming remplace cette structure par un modèle de collaboration en réseau. Il est né chez Cisco, qui en a parlé dans son livre blanc de 2008 intitulé "Essaimage numérique." Ce concept a ensuite été adopté par le Consortium pour l'innovation dans les services, et développé dans une vision intitulée "Essaimage intelligent.."
L'idée générale de l'essaimage est qu'au lieu de recourir à l'escalade, vous faites venir en même temps dans l'équipe de RI toutes les personnes susceptibles d'aider à résoudre un incident. Les membres de l'équipe se livrent à des séances de remue-méninges et se renvoient mutuellement des idées. Ils utilisent généralement la dynamique de groupe pour trouver des solutions nouvelles et innovantes à des problèmes de RI difficiles.
Les principes fondamentaux de l'essaimage sont les suivants :
- Les "niveaux" de soutien sont éliminés
- Il n'y a pas d'escalade d'un groupe à l'autre - toutes les personnes qui doivent faire partie de l'équipe sont présentes dès le début.
- L'affaire doit être confiée directement à la ou les personnes les plus à même de la résoudre.
- La personne qui prend l'affaire est celle qui la mène jusqu'à sa résolution.
4. Mettez en place une politique "Ne laissez pas cela se reproduire".
Vous devez également veiller à ne pas éteindre les mêmes feux, encore et encore. Cela implique de connaître la différence entre la RI et la gestion des problèmes. La RI consiste à ramener les choses à la normale, même s'il ne s'agit que d'une solution temporaire. La gestion des problèmes consiste à trouver la cause profonde de l'incident et à la résoudre.
Notez que vous ne pourrez jamais empêcher les incidents de se produire, ce n'est pas réaliste. Cependant, vous pouvez éviter d'avoir à fournir des solutions au même problème de manière répétée grâce à une gestion efficace des problèmes.
5. Définir correctement l'énoncé du problème et les priorités
La chose la plus importante que vous puissiez faire est probablement de comprendre et de formuler ce que l'incident implique. C'est ce que l'on appelle la classification des incidents, mais vous devez aller au-delà de la classification de l'incident dans une catégorie de base pour spécifier l'énoncé du problème de manière extrêmement précise et exacte. Cela doit inclure des paramètres tels que le(s) système(s) touché(s), l'emplacement géographique, le nombre d'utilisateurs internes touchés et l'impact spécifique sur les opérations commerciales.
Ce n'est que lorsque vous avez un énoncé clair du problème que vous pouvez fixer des priorités. Une classification appropriée permet de mieux dépanner et d'améliorer le temps de résolution. Ensuite, la hiérarchisation des priorités permet de s'assurer que les problèmes les plus critiques pour l'entreprise sont traités en premier.
6. Encourager une culture sans reproche
C'est essentiel. Plutôt que de chercher à pointer du doigt si quelque chose ne va pas, que ce soit dans la réponse aux RI elle-même ou dans le problème sous-jacent d'un système, concentrez-vous simplement sur le problème et sur la recherche de la véritable cause profonde, quelle qu'elle soit. Une culture du "blâme et de la honte" n'est d'aucune utilité et peut même ralentir la réponse aux RI parce que les gens ont peur de faire des erreurs.
7. Définir les bons indicateurs clés de performance et les améliorer
Les indicateurs clés de performance (ICP) sont extrêmement importants, car ils permettent de mesurer vos résultats et vous donnent un critère quantitatif à utiliser pour voir si vous vous améliorez. Cependant, faites attention à vos KPI. Certains donnent une fausse idée de la performance de votre équipe de RI et peuvent vous amener à donner la priorité aux mauvaises choses. Par exemple, la résolution au premier appel (FCR), une mesure courante, évalue combien d'incidents peuvent être résolus au premier appel. Mais cela entraîne parfois des décisions et des actions hâtives alors que la qualité du service est plus importante.
Par conséquent, établissez des paramètres réalistes et mesurez-les pour une amélioration constante. Voici quelques suggestions d'indicateurs clés de performance à suivre :
- Volume d'incidents (par catégorie de problème, priorité, statut, demandeur, etc.)
- Temps moyen de résolution
- Délai moyen de réponse
- SLA %
- Incidents résolus sans escalade
- Coût moyen par incident
- Taux de réouverture des incidents
Conclusion : Avantages d'une gestion efficace des incidents
Nous connaissons tous les conséquences d'une mauvaise RI - l'entreprise en souffre. En revanche, les avantages d'une bonne gestion des RI sont multiples. Vous bénéficiez d'opérations commerciales fluides. Vous obtenez une meilleure efficacité et productivité au sein de l'équipe informatique ainsi que de l'organisation. Vous avez une plus grande satisfaction des utilisateurs car vous maintenez vos SLAs. Et, à mesure que vous vous améliorez dans le domaine de la RI, vous pouvez commencer à identifier et à prévenir de manière proactive les incidents majeurs en repérant les incidents majeurs potentiels avant qu'ils ne soient signalés par les utilisateurs ou les clients. C'est un grand gagnant-gagnant-gagnant.
À propos de Kepner-Tregoe
Depuis plus de 60 ans, Kepner-Tregoe est le leader du secteur en matière de processus de résolution de problèmes et d'excellence du service. Les experts de KT ont aidé les entreprises à améliorer leur niveau de performance en matière de gestion des incidents et des problèmes grâce à des outils, des formations et des conseils, ce qui a permis de mettre en place des équipes de gestion des services très efficaces, prêtes à répondre aux problèmes les plus critiques de votre entreprise.
