Le reporting hebdomadaire se fabrique à partir de l'extraction
La supervision d'un réseau fixe. Quatre semaines de tickets d'incidents, un classeur de reporting en cinq secondes.
Chaque lundi, un superviseur reçoit l'extraction des tickets d'incidents et en tire le reporting de la semaine. Nous avons automatisé le trajet entre les deux : le fichier est lu, les doublons partent, les durées sont calculées, la garantie de temps de rétablissement est contrôlée d'après la procédure de l'entreprise, et le classeur sort avec son commentaire. Vous pouvez manipuler la chaîne plus bas. Les données sont inventées : la chaîne est réelle, le centre de supervision ne l'est pas.
Un fichier qui arrive complet, et tout à refaire à la main
L'extraction contient déjà tout : le numéro du ticket, la priorité, l'heure d'ouverture, l'heure de rétablissement, l'agent, le site, la région. L'information est là. Le travail du lundi, c'est de la remettre en forme, toujours de la même façon.
Le nettoyage
Un incident repris par un deuxième agent ressort deux fois de l'outil de ticketing. Ces doublons se repèrent à l'œil, ligne par ligne, et faussent tous les totaux tant qu'ils sont là.
Les durées
La durée de rétablissement se calcule ticket par ticket, puis se compare à la GTR de la priorité. Une date de rétablissement antérieure à l'ouverture, un statut en retard sur les faits : ces cas se traitent à la main.
Les tableaux
Par agent, par région, par semaine, par type d'incident. Quatre tableaux croisés à refaire à chaque extraction, et autant d'occasions de décaler une plage de cellules.
Le commentaire
Le reporting commence par lui. Il demande de relire les chiffres, de retrouver le paragraphe de la procédure qui s'applique, et de le citer. C'est aussi la première chose qu'on coupe quand le lundi est chargé.
Aucune de ces quatre étapes ne demande un jugement. Elles demandent de l'attention, et la même attention chaque semaine. Ce sont les gestes que nous automatisons en premier : ceux que personne ne discute, et que tout le monde refait.
La chaîne complète, dans votre navigateur
Cinq étapes : l'extraction, les documents de référence, l'automatisation, le reporting, les questions. Lancez l'automatisation, le journal montre ce qui se passe à chaque étape. Vous pouvez télécharger l'extraction, la modifier dans Excel, la réimporter, et relancer.
Sur téléphone, le cadre est étroit pour une grille de tableur : ouvrez plutôt la démonstration en plein écran.
Ouvrir la démonstration en plein écran
Les tickets, les agents, les sites et la procédure sont inventés. Sur cette page publique, le commentaire et les réponses aux questions sortent de gabarits appliqués aux chiffres calculés. Chez le client, c'est Claude qui lit la base documentaire et qui écrit. La démonstration le dit en haut de l'écran. Tout le reste est le code livré : lecture du fichier, doublons, durées, contrôle de la GTR, classeur Excel.
Quatre étapes, sans reprise à la main
Elle lit l'extraction telle qu'elle sort
Le fichier hebdomadaire de l'outil de ticketing, sans colonne à renommer ni ligne d'en-tête à déplacer. Les lignes inexploitables sont écartées et comptées, pas devinées.
Elle prend ses règles dans vos documents
Les GTR par priorité, l'objectif de respect et le seuil d'alerte sont lus dans votre procédure, pas écrits dans le code. Quand une règle manque ou paraît incohérente, la valeur par défaut s'applique et le reporting indique laquelle.
Elle calcule et regroupe
Doublons retirés, durées de rétablissement, contrôle de la GTR, puis les totaux par agent, par région, par semaine et par type d'incident. Les tickets encore ouverts qui ont déjà dépassé leur GTR sont sortis à part.
Elle rédige et produit le classeur
Le bloc « À retenir » énonce un constat chiffré, l'action prévue par la procédure et le paragraphe d'où elle vient. Le tout part dans un classeur de cinq onglets, prêt à diffuser après relecture.
Quatre semaines de tickets d'incidents, dont cinq doublons retirés au passage.
Synthèse avec le bloc « À retenir », par agent, par région, hors GTR, données.
Du clic au classeur téléchargeable. Relevé sur le jeu de démonstration ci-dessus.
Ce que cet outil ne fait pas.
Nous préférons le dire ici plutôt que de le découvrir ensemble à la livraison.
- Il ne diffuse rien tout seul. Il produit un classeur. L'envoi au responsable de production et aux pilotes régionaux reste un geste humain, après relecture.
- Il n'invente pas une règle absente. Si la procédure ne dit rien sur un constat, le reporting écrit qu'aucune règle ne le couvre, au lieu de proposer une action.
- Il ne touche pas à l'outil de ticketing. Il lit une extraction et écrit un classeur. Rien n'est modifié dans le système d'origine.
- Il ne juge pas un agent. Il applique le seuil écrit dans la procédure et nomme qui passe dessous. Ce que le superviseur en fait relève du management, pas de l'outil.
Pourquoi les règles sont dans vos documents plutôt que dans le code
Un objectif de GTR se resserre d'une année sur l'autre. Quand la valeur est écrite dans le code, le changement passe par nous. Quand elle est lue dans la procédure, il suffit de mettre la procédure à jour, et le reporting suit dès l'extraction suivante.
Nous avons construit cette démonstration sur un métier précis, la supervision du réseau fixe, parce qu'un reporting ne se montre bien que sur des chiffres qui veulent dire quelque chose. La chaîne, elle, est la même pour un autre métier : un fichier qui arrive chaque semaine, des règles écrites quelque part, et un document à produire.
Une intégration de ce type se facture à la demande, sans abonnement imposé. Nous la chiffrons après l'appel, sur le périmètre convenu avec vous.
Parlons de votre projet.
Trente minutes au téléphone pour situer votre organisation et dire ce qui nous paraît prioritaire. Si le sujet ne relève pas de nous, nous vous le dirons pendant l'appel.