Le processus de tickets IT comme modèle de calcul prêt à l’emploi

Entrée : 24 000 tickets par an, soit environ 96 par jour ouvré, avec une dispersion quotidienne de 28 % et un facteur de pointe de 1,35 pour 8 % des jours. Montage, déploiements, incidents.

La colonne « Part » est la raison pour laquelle ce modèle se lit différemment des autres : le deuxième niveau ne voit qu’un tiers des tickets. Si l’on rapporte sa charge à la totalité, on arrive à 155 % et l’on considère comme surchargée une étape qui affiche pourtant 57 %.

La constatation cruciale. Probabilité d’être le goulot par étape sur 20 000 exécutions :

La colonne se somme à 100 % : à chaque exécution on compte exactement une étape contraignante, celle ayant la charge la plus élevée ce jour-là.

Le deuxième niveau, que l’on tient en interne pour responsable des longs délais, l’est dans 14 % des exécutions. Le servicedesk, l’endroit où un ticket est seulement enregistré pendant cinq à dix minutes, l’est dans 75 %. Le processus perd du temps avant le travail, pas pendant.

Et c’est là qu’un tableau échoue : cinq minutes par ticket passent inaperçues. 96 fois cinq à dix minutes, non.

1. Tickets par jour ouvré. Tickets de l’année écoulée ÷ jours ouvrés. Figurant dans le rapport Helpdesk, au même endroit où sont comptés les doublons et les tickets groupés. Utilisez la même définition que celle que vous appliquerez ensuite pour le mesurage.
2. Facteur de pointe. Combien de tickets arrivent le jour le plus chargé par rapport à un jour normal ? Lundi, le jour suivant un déploiement, le jour d’un incident. Un facteur de 1,3 à 2 est courant. Sans cette valeur, vous modélisez un servicedesk qui n’est jamais sous charge, alors que la charge est l’état normal pour les tickets.
3. Personnes au servicedesk et leurs heures pour le triage. Pas l’effectif de l’équipe. Qui prend des appels par ailleurs n’a pas huit heures pour l’enregistrement.
4. Plage de traitement du triage. Extrémité basse et haute. Cinq minutes pour un mot de passe, vingt pour un signalement d’incident qui doit d’abord être reconstitué. C’est précisément cette plage qui génère le temps d’attente.
5. Part résolue immédiatement. Dans le modèle 65 contre 35. Ce chiffre figure dans chaque rapport Helpdesk sous « First Contact Resolution » et c’est le seul que vous puissiez réellement mesurer. Il déplace la charge entre les branches, pas en amont.
6. Taux de coût complet par rôle. Salaire brut × 1,5 à 1,8, divisé par environ 1 500 heures productives par an. À 24 000 tickets par an, chaque euro d’écart de taux pèse fortement ; un taux naïf calculé salaire ÷ 2 080 heures rendra l’énoncé en euros attaquable.

Vérification avant de calculer : Comptez les tickets ouverts dans le système et divisez-les par les tickets que vous clôturez en une journée (Little's Law). Si votre délai connu en ressort, le modèle est utilisable. S’il en diffère fortement, il manque une file d’attente, souvent le statut « en attente de retour de l’utilisateur » pour les tickets.

Ce que le modèle n’inclut pas. Le temps de passage comprend le traitement plus la file d’attente, en jours ouvrés. La priorisation n’est pas modélisée : le modèle fonctionne selon l’ordre d’arrivée. Qui a une priorisation réelle doit la représenter comme une deuxième branche avec sa propre capacité ; sinon le modèle calcule trop lentement pour les tickets urgents et trop vite pour le reste. Non inclus non plus : les temps de repos, pendant lesquels un ticket est en attente de l’utilisateur.

Levier 1. Un formulaire à l'entrée. Champs obligatoires pour l’appareil, l’application, le symptôme et l’urgence. La triage passe de 5–10 à 3–6 minutes, car il n’y a plus de reconstitution. Effet : P90 du délai de traitement de 4,9 à 0,22 jour ouvré, charge au jour de pointe de 129 % à 77 %. Le levier le moins coûteux sur le terrain, et le seul qui ne nécessite pas de personnel.

Levier 2. Une troisième personne au service desk. A également un effet net important (0,38 jour), mais coûte un poste. Le rapport avec le levier 1 est la véritable information de ce tableau.

Levier 3. Base de connaissances qui capte 20 % des tickets en amont. Moins de tickets, c’est toujours mieux, mais cela ne résout pas le goulot : la triage reste l’étape contraignante dans 75 % des simulations, sa charge ne baisse que de 129 % à 103 % au jour de pointe. Une réduction d’un cinquième de la charge soulève à peine une étape au-dessus du seuil, pas plus.

Levier 4. Plus de tickets résolus au premier niveau. Le constat nul le plus intéressant. Porter le taux de résolution au premier contact de 65 à 75 % est la recommandation standard en support, et cela a un effet : le coût en temps par ticket passe de 28,82 € à 25,34 €, car des minutes coûteuses de second niveau sont remplacées par des minutes moins chères de premier niveau. Le délai de traitement ne diminue pas, il augmente même légèrement à 5,0 jours. Le levier économise de l’argent, pas du temps. Le présenter comme une mesure de réduction de délai, c’est vendre mal la même bonne mesure.

Calculez les quatre séparément et classez-les par effet par effort. Levier 1 est un formulaire, levier 2 un poste, et dans le modèle ils sont séparés de 0,16 jour.

Comment, à partir de 20 000 simulations, on obtient un pourcentage par étape est expliqué dans l’article Monte-Carlo-Simulation für Prozesse ; pourquoi 85 % d’utilisation est déjà trop, dans Engpass berechnen.

Après l’état initial, un levier modifié et une seconde exécution, la comparaison donne :

• Délai de traitement avant/après en P50 et P90. Un engagement de service se donne contre le P90, pas contre la médiane. C’est là que la déclaration SLA diffère d’une affirmation sur la moyenne : la médiane indique 0,08 jour, et pourtant l’engagement est manqué un jour sur dix.
• Charge par étape au jour de pointe et le nouveau goulot après la mesure. Dans ce modèle, il migre vers le premier niveau pour deux des quatre leviers.
• Débit en tickets par semaine par rapport aux arrivées : 455 sur 480 à l’état initial. La différence est l’arriéré que le service desk reconstitue chaque semaine.
• Coûts en temps de travail par ticket et par an, calculés à partir des volumes, des temps et des taux de coûts complets. À 24 000 opérations, chaque centime compte ; le modèle utilise 28,82 € par ticket.
• La liste des hypothèses avec chaque saisie estimée. La phrase « La priorisation et les temps de repos ne sont pas modélisés » enlève l’objection la plus sévère avant qu’elle ne soit formulée.

Le tout est émis en deux PDF : offre pour le décideur, documentation pour la traçabilité, avec votre en-tête si vous en avez fourni un.

Le même modèle, deux questions. Cette page répond à la question de calcul : d’où viennent les 75 % et pourquoi une réduction d’un cinquième des tickets ne résout pas le goulot. L’autre question (que recommander et quel est le coût d’un ticket laissé en suspens) appartient à la méthode et non à l’outil. Elle se trouve dans l’archive d’analyses de Flowrefy, avec la méthode à l’origine de ces modèles. Un jeu de données, deux questions, deux publics.

• Le traitement des commandes s’étend de la commande à la confirmation de commande. Le cas avec un rôle partagé : deux étapes qui paraissent simples individuellement constituent l’après-midi de la même personne.
• Le processus d’offre est le cas où le temps de passage affecte le chiffre d’affaires plutôt que les coûts.
• La validation des factures est le cas de volatilité : en moyenne sous la capacité, mais au-delà en fin de mois.
• Pour la réclamation, le goulot d’étranglement se trouve hors de l’entreprise, et la recommandation honnête n’est donc pas « automatiser ».
• Le onboarding des employés a peu de volume et de nombreux acteurs, et une étape mobilise 86 % des parcours.
• Le ticket informatique est cette page.

Chaque modèle s’ouvre dans la fenêtre d’accueil via Voir les modèles. La première fois, il vaut la peine d’en ouvrir un avant de commencer votre propre modèle. Sinon on modélise trop finement.