J’accompagne aussi bien des équipes de développement – pratiquant ou non des techniques agiles – que des équipes dites de support (N1 à N3). Plusieurs fois, j’ai entendu au sein de celles-ci – y compris dans celles qui géraient à la fois du dev et des tickets d’incidents – des personnes exprimer leur refus de faire du support.
Les messages étaient parfois forts :
- «Ce n’est pas intéressant et on perd notre temps alors qu’on a plein d’autres choses à faire !»
- «Je fais du dev, il est hors de question que je fasse du support.»
- «On devrait prendre des boîtes externes pour faire le support.»
- «On fait tout le temps la même chose. Ça fait cinq ans que ça dure !»
- «On devrait embaucher des jeunes pour faire du support ; pour apprendre.»
- …
Essayons de comprendre pourquoi.
Le travail routinier de traitement des incidents peut vite devenir rébarbatif. Les problèmes, très souvent les mêmes, vont revenir sans cesse et les opérateurs vont lire, encore et encore, les mêmes procédures et expliquer des centaines de fois les mêmes instructions. Parfois, certainement plus fréquemment qu’on ne le pense, ces mêmes opérateurs découvrent par l’intermédiaire des clients / utilisateurs qui les sollicitent que des nouvelles fonctionnalités ont été mises en production, sans qu’ils n’en soient informés.
Les clients / utilisateurs plus agacés que jamais vont exprimer au téléphone ou dans leurs communications leur désarroi d’une manière irritante. En lisant les titres des tickets «Urgent !» ou «Urgent, urgent !», voire «Urgent, urgent, urgent !» et le texte descriptif, les opérateurs du support s’irritent de ce sujet qui n’a aucun caractère d’urgence. Il sera traité après les «vrais» urgents. Certains utilisateurs, agacés par les délais de réponse et la répétition des incidents, utilisent tous les canaux de communication possibles pour faire avancer plus rapidement le traitement de leur problème.
Comme l’indique Jonathan Lefevre dans L’obsession du service client, ces messages «qui commencent par URGENT, bourrés de majuscules et de point d’exclamation […] sont rarement les plus urgents, en réalité. Ils sont plutôt une réaction à l’attitude des services clients traditionnels, dont les délais de réponse – quand il y en a une – peuvent faire peur.»
Mais pourquoi des membres de certaines équipes ne veulent pas / plus faire de support ? Quelques éléments de réponse :
- Il est toujours difficile de se confronter à des clients / utilisateurs qui ne sont pas contents du service qui leur est rendu. Encore plus quand l’opérateur n’a pas les moyens d’agir sur les occurrences (comme les N1).
- Nombre de services support client s’inquiètent du taux de décroché et de la mise à jour de la base de connaissance au lieu de réduire les occurrences.
En deux mots : il n’y a pas ou peu de résolution de problème pour supprimer les occurrences. De ce fait, il est tout à fait normal que les opérateurs du support aient du mal à trouver un intérêt et du sens dans cette activité répétitive. Encore plus pour les équipes de support N1 qui – avec le plus grand respect pour leur travail – sont le parent pauvre du customer service. J’aurais tendance à les comparer aux vélites, ces fantassins légers – issus des citoyens romains pauvres et peu équipés – de l’armée romaine antique envoyés en première ligne.
Pourquoi faire de la résolution de problème ? (point numéro 3 de la définition du lean management) Tout «simplement» pour supprimer progressivement les occurrences des incidents que rencontrent les clients / utilisateurs. En travaillant ainsi, avec l’objectif de passer moins de temps à traiter des tickets d’incident, les équipes passeront lentement mais sûrement d’une activité de correction / réparation (traiter des tickets d’incident) à une activité de création de valeur (réaliser des produits et services pour répondre aux attentes des clients / utilisateurs).
Une équipe support N2 a réussi ce pari en 3 mois. Initialement, les 2 personnes en charge du traitement des incidents étaient à 100 % de leur temps sur cette activité. Après plusieurs résolutions de problème visant à réduire les temps de traitement et le stock MAIS également à supprimer des incidents, le temps d’activité de support de ces 2 mêmes personnes a été divisé par 2 ! Ainsi, c’est l’équivalent d’1 personne à temps plein qui a pu basculer vers de la création de valeur. Si elles n’avaient pas fait cela, elles seraient encore à temps complet sur du traitement d’incident.
Bien entendu, il est difficile pour une équipe de support N1, voire N2, de résoudre les incidents (supprimer les occurrences), car elle n’est pas en charge de la solution applicative ou du matériel utilisé par les clients. Il est donc impératif que les équipes de réalisation (N3 ou N4) viennent aider les équipes support pour résoudre définitivement les incidents.
Les équipes en charge des développements des applications sont rarement au contact des clients / utilisateurs et finalement ne s’intéressent que peu à eux. De fait, le premier réflexe de ces équipes quand il y a un incident dû à un problème de code ou de fonctionnalité, c’est de rédiger une procédure pour l’équipe support de niveau 1, voire de niveau 2. Ainsi, l’incident est d’une certaine manière «masqué» et l’équipe de développement continue comme si de rien n’était. Le client est oublié !
«Personne n’est responsable du début à la fin. Au niveau du customer service on est orientés vers les processus, c’est-à-dire vers l’interne.» comme l’écrit François Dupuy dans Lost in Management.
Pour aller plus loin :
Better, faster, together 