Un ticket clos n’est pas une cause corrigée.
Toute exploitation de support en connaît : la variante de paie qui échoue le dernier jour ouvré, l’interface qu’il faut relancer chaque lundi, le verrou à libérer chaque fois qu’un traitement déborde. Chaque occurrence est résolue vite, poliment et dans les délais du SLA — et chacune revient à l’heure dite.
Sur le papier, cette exploitation paraît saine. Les délais de réponse tiennent, les scores de satisfaction tiennent, la file se vide. Les indicateurs mesurent la vitesse du tapis roulant, pas le fait que quelqu’un en descende.
Clore des tickets n’équivaut pas à corriger des causes. Mesurez votre support à ce qui cesse de revenir.
Pourquoi le même incident revient
La correction colle au ticket, pas à la cause
Un ticket décrit un symptôme : une écriture en échec, un IDoc bloqué, un résultat erroné. La résolution la plus rapide traite exactement ce symptôme — recomptabiliser, retraiter, corriger — et la condition qui l’a produit ne figure jamais sur le ticket.
La cause vit hors de la juridiction de la file
Les incidents récurrents renvoient de façon disproportionnée à la qualité des données de référence, au comportement des processus en amont, à la synchronisation des intégrations ou à du code spécifique vieillissant. Tout cela appartient à quelqu’un — et rarement à la personne qui tient le ticket.
Personne ne lit les tickets en travers
Prise isolément, chaque occurrence est mineure. Le motif n’existe qu’à travers les tickets — même transaction, même position dans le calendrier, même demandeur — et la plupart des exploitations n’ont aucune routine où quelqu’un regarde l’historique transversalement.
Les incitations récompensent le tapis roulant
Les régimes de SLA paient la clôture rapide, et une récurrence est, paradoxalement, une occasion de plus de clore vite un ticket. Rien dans le jeu d’indicateurs habituel ne retire de points quand le même incident revient pour la neuvième fois.
Ce que cherche une revue d’incidents récurrents
- Des regroupements — des incidents qui se concentrent par module, transaction, interface ou chaîne de traitements au lieu de se répartir uniformément.
- Des formes calendaires — des pannes qui suivent la clôture mensuelle, les cycles de paie ou certains jours de la semaine ; un horaire est une signature.
- Des demandeurs récurrents — les mêmes utilisateurs ou services signalant la même classe de problème, ce qui marque en général une lacune de processus ou d’accompagnement, pas un problème d’utilisateur.
- Des correctifs appliqués plus de deux fois — toute note de résolution déjà collée auparavant est une cause qui tourne sans correction.
De la file de tickets à l’amélioration du run
Le mécanisme n’a rien de sophistiqué ; c’est simplement une autre unité de travail. Au lieu de demander “la file est-elle vide ?”, l’exploitation se demande périodiquement “quelles sont nos principales récurrences, et lesquelles avons-nous supprimées ?” — et consacre à cette question une part de capacité petite et constante.
Regrouper l’historique→Nommer les principales récurrences→Corriger la cause, où qu’elle soit→Supprimer le ticket pour de bon
L’économie se cumule en silence. Chaque récurrence supprimée rend sa capacité au pool pour toujours — c’est pourquoi les contrats AMS matures coûtent moins cher à exploiter avec le temps, tandis que les immatures ne font que se remplir.
Le point de vue de VISCAP
La file vous dit ce qui s’est passé aujourd’hui. L’historique vous dit ce qui se passera le mois prochain.
Quand nous reprenons un paysage SAP en exploitation, l’historique des tickets est la première chose que nous lisons — non pour auditer l’équipe précédente, mais parce que six mois de tickets constituent un aveu involontaire de l’endroit où se trouvent les vrais problèmes. Les cinq principales récurrences sont généralement visibles en une journée, et les supprimer est la confiance la plus rapide que nous puissions bâtir.
Posez une autre question à votre support
Pas “sommes-nous dans les clous du SLA ?” — vous l’êtes presque certainement. Demandez plutôt : quel incident qui revenait autrefois n’existe plus ? Si la réponse est une liste, vous avez une amélioration du run. Si la réponse est un silence, vous avez un tapis roulant avec d’excellents temps de réponse.