Plus l’entreprise se numérise, plus la qualité du support informatique devient clé. En effet, il y a toujours des incidents à gérer (ou, idéalement, à anticiper) et des utilisateurs à assister. Nous avons conduit des missions chez différents clients pour rendre la gestion des incidents et des problèmes plus « lean ». Retour d’expérience.

Les attentes des utilisateurs sont toujours les mêmes vis-à-vis de leur support informatique

Les utilisateurs comprennent qu’il peut y avoir des incidents. Ils veulent :

  • Qu’ils soient résolus le plus rapidement possible
  • Qu’ils ne se reproduisent pas (rien de plus agaçant que de retrouver toujours les mêmes blocages)
  • Dépendre le moins possible des informaticiens pour débloquer leur travail (toujours dans une optique de réactivité)
  • Être informés de l’avancement de leur affaire et avoir de la visibilité sur la date de résolution prévisionnelle

Comme les clients des trains lorsque ceux-ci tombent en panne.

Parfois, la chaîne de support informatique peut se retrouver débordée

Une inflation de tickets de demande de résolution d’incidents peut mettre les équipes de support en crise. Les causes de telles situations sont souvent similaires :

  • Une chaîne trop complexe, mal conçue, qui engendre de plus en plus d’erreurs techniques et humaines
  • En corollaire, des données mal saisies ou de mauvaise qualité dans une application à un bout de la chaîne qui entrainent des problèmes d’intégration à l’autre bout
  • Des évolutions du système nombreuses et insuffisamment testées et recettées. Les chefs de projet poussent pour mettre en production quoi qu’il en coûte, en sacrifiant ces étapes cruciales de sécurisation
  • Des pertes de compétences au sein de la DSI (à cause de turn-over ou de changements de prestataires) qui limitent sa capacité à garder un bon niveau de qualité sur les systèmes et à résoudre les incidents lorsqu’ils surviennent
  • Des manques de compétences côté métier (recrutements, turn-over) qui entrainent une méconnaissance des processus et qui reportent vers l’informatique des problèmes qui sont en réalité des problèmes métiers

Un point clé pour progresser : comprendre la différence entre incidents et problèmes, et gérer les problèmes.

Depuis la diffusion des bonnes pratiques du référentiel ITIL au sein du monde informatique, on distingue usuellement les processus de « gestion des incidents » et de « gestion des problèmes ».

Un incident est un événement entraînant une interruption ou une diminution de la qualité du service. Le but de la gestion des incidents est de rétablir le service nominal aussi rapidement que possible, le plus souvent par une solution de contournement (exemple : « redémarrez votre PC »).

Le problème est la cause profonde d’un ou de plusieurs incidents. Le but de la gestion des problèmes est d’éradiquer les causes profondes afin qu’il y ait moins d’incidents. C’est une forme d’amélioration continue du service informatique.

Or mettre en place une véritable gestion des problèmes nécessite une maturité que toutes les équipes informatiques n’ont pas. Une prise de conscience est d’abord nécessaire. Puis la mise en place de rôles et responsabilités pour tracer, prioriser, et résoudre les problèmes.

Concernant le processus de gestion des incidents, on trouve toujours des améliorations à mettre en œuvre.

  • Opérer le « Shift-to-left » : rapprocher la résolution le plus possible de l’utilisateur. Fournir des clés d’auto-dépannage aux utilisateurs, faire monter en compétence le niveau 1 de la chaîne support pour qu’il traite plus de 70% des incidents à son niveau (plus on est obligé de remonter aux experts, plus la résolution risque de prendre du temps et d’être coûteuse)
  • Fluidifier les échanges et la communication entre les acteurs de la chaîne. Dans de grosses organisations, il n’est pas rare de voir les tickets errer de boîtes aux lettres génériques en boîtes aux lettres génériques. Les acteurs des différentes équipes ne se connaissent pas et communiquent mal. Comme toujours, plus on remet de liant et de communication, plus on s’aperçoit que certaines difficultés s’aplanissent d’elles-mêmes
  • Supprimer tous les allers-retours inutiles (par exemple, quand un incident remonte à un expert, permettre à celui-ci de s’adresser directement à l’utilisateur. Eviter le « téléphone arabe »)
  • Traiter les incidents en mode « first-in-first out » et arrêter de perdre du temps à les prioriser et à procrastiner
  • Dimensionner correctement les niveaux experts et leurs donner des objectifs de délais comme aux niveau 1
  • Fiabiliser les outils de suivi pour mieux mesurer le flux et anticiper / mieux traiter les pics de charge
  • Travailler sur la communication avec les utilisateurs
  • Faire progresser aussi les utilisateurs si certains incidents sont liés à leurs gestes

Quelle que soit la criticité du système, le support informatique fonctionne bien s’il est fluide, si la plupart des incidents sont traités dans la journée, et, surtout, s’il y a de la transparence et de la confiance entre les différents acteurs de la chaîne.

 

Sur un thème similaire : Qu’est-ce qu’une bonne gouvernance SI ?