Le monitoring et la signalisation, c'est la promesse qu'un système surveille et donne l'alerte à temps : une facture anormale, un client qui menace de partir, un processus qui se bloque. Sous la fenêtre de chat ou le tableau de bord où apparaît ce signal, se trouve une chaîne de choix que l'organisation doit faire elle-même. C'est cette chaîne qui déterminera si la signalisation apporte quelque chose ou ajoute surtout du bruit.
Un signal est un écart par rapport à un schéma. Pour reconnaître un schéma, il faut d'abord une ligne de base : des données sur la manière dont les choses se déroulent normalement, collectées d'une façon comparable dans le temps. Cela demande des données saisies de façon cohérente, dans les mêmes champs, avec les mêmes définitions. Une organisation où trois services ont trois façons différentes d'enregistrer une plainte n'a pas encore de ligne de base — elle a trois lignes de base qui ne s'accordent pas entre elles.
Cela implique aussi de savoir qui est responsable de la qualité de ces données. Une signalisation qui repose sur des données que personne ne contrôle finira, à un moment donné, par signaler quelque chose d'inexact, et la question sera alors de savoir qui le remarque et le corrige. Sans appropriation de la source des données, un signal n'est qu'un pari horodaté.
Tout système de signalisation fonctionne avec des seuils : à partir de quel écart quelque chose devient une alerte. Ce seuil n'est pas un détail technique mais un choix de fond. Fixé trop bas, tout le monde reçoit en permanence des alertes qui ne signifient rien, et personne ne les lit plus. Fixé trop haut, le système reste silencieux alors que quelque chose se dégrade déjà.
Fixer ce seuil demande quelqu'un qui connaît le processus sous-jacent — pas un réglage général identique pour chaque équipe. Un seuil pour la signalisation de stock dans un entrepôt n'est pas la même question qu'un seuil pour la signalisation du turnover du personnel. C'est là une des dimensions fondamentales : sans une organisation qui fait ces choix explicitement et les consigne, c'est la technique qui fixe le seuil à votre place, généralement à une valeur par défaut qui ne convient précisément à personne.
Un signal qui n'atterrit nulle part n'est pas un signal. Cela demande un parcours établi : qui reçoit l'alerte, dans quel délai elle est examinée, et quelle est l'étape suivante si l'alerte est fondée. Sans ce parcours, l'alerte finit dans une boîte de réception que personne ne considère comme sa tâche prioritaire, et l'avantage d'une signalisation précoce se dissout dans la lenteur du suivi.
Cela touche à la manière dont les services travaillent ensemble : un signal concernant un client naît souvent dans une équipe et doit être suivi par une autre. La façon dont la coordination entre services se déroule dans votre organisation déterminera si ce transfert se fait sans accroc ou se bloque à la frontière entre deux équipes qui n'ont pas l'habitude de partager la même information.
La signalisation ne fonctionne souvent pas sur un seul flux de données structurées, mais sur une combinaison : des chiffres issus d'un système, et du texte provenant d'e-mails, de comptes rendus ou de rapports. Un système censé signaler à partir de lettres de plainte ou de comptes rendus de réunion doit d'abord être capable de lire et d'interpréter ces documents. La façon dont votre organisation gère la lecture et le résumé de documents déterminera donc en partie si la signalisation à partir de sources textuelles est réalisable, ou si elle demande d'abord un travail au niveau de la gestion documentaire.
Il en va de même pour les échanges oraux. Un signal issu de quelque chose qui a été dit lors d'un entretien client n'existe que si cet entretien a été consigné d'une manière qu'un système peut interroger. Sans une structure pour consigner et suivre les échanges, cette information reste dans la tête de la personne qui a mené l'entretien, et là, aucun système ne peut la signaler.
La signalisation n'est pas une action. Le système signale que quelque chose se passe ; il n'intervient pas lui-même. Celui qui s'attend à ce qu'un signal mène automatiquement à une solution confond la signalisation avec un autre type de travail : un travail qui est repris et exécuté. Ce qui est possible dans ce domaine est décrit à la page consacrée aux agents qui exécutent des tâches — un niveau différent de celui abordé ici.
Le monitoring est souvent la première chose que l'on essaie, précisément parce qu'il paraît petit et bien délimité : un tableau de bord, une équipe, un processus. Ce caractère délimité est aussi le piège. Un système de signalisation qui fonctionne à un seul endroit, mais qui n'est pas relié au reste de l'organisation, reste une curiosité plutôt qu'un instrument. La raison pour laquelle un projet pilote qui ne fonctionne que dans son coin n'apporte rien est directement liée à ce schéma : un signal sans lien avec un processus qui en fait quelque chose reste une démonstration. Et une démonstration sans personne qui considère le suivi comme sa propre tâche disparaît d'elle-même ; c'est aussi la raison pour laquelle une démo sans responsable n'apporte rien.
Que votre organisation soit prête ou non pour le monitoring et la signalisation ne dépend pas de la technique disponible, mais du fait que la ligne de base, les seuils, le parcours de suivi et l'appropriation existent déjà. C'est précisément ce que la mesure de maturité de hybridresourcing examine : non pas si c'est possible, mais ce qui doit d'abord être en place.
Le monitoring et la signalisation vous indiquent que quelque chose se passe. Ils ne vous disent pas quelle partie du travail sous-jacent — l'évaluation, le reporting, le suivi — peut réellement être reprise par l'IA. Cette question relève du scan de travail de FTE TO AI, qui calcule, tâche par tâche, quelle part du travail s'y prête, indépendamment de la question de savoir si l'organisation y est déjà prête.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.