Un seuil d'alerte est une règle qui dit : si cette valeur sort de cette plage, alors il y a quelque chose que quelqu'un doit examiner. Cela paraît simple, mais la question se décompose en trois parties qui doivent être traitées séparément. Qu'est-ce qu'une valeur valide. Qu'est-ce qu'un écart par rapport à cette valeur. Et qui en a la visibilité. Sans ces trois éléments, un signal n'est rien de plus qu'un nombre inscrit quelque part.
Vous ne pouvez pas définir un écart sans savoir au préalable ce qui est normal. Pour une consommation d'énergie par établissement, il s'agit d'une plage qui dépend de la surface, des horaires d'ouverture et de la saison. Pour un effectif, il s'agit d'une plage qui dépend de la taille de l'unité. Cette fourchette doit être établie par point de données avant qu'un signal n'ait un sens. La manière de déterminer et de fixer cette fourchette est décrite sur qu'est-ce qu'une valeur valide et qui le remarque quand cela va mal. Sans cette étape, vous configurez un signal sur une valeur qui n'a elle-même jamais été vérifiée, et dans ce cas vous ne signalez en réalité rien.
Un signal peut réagir à différentes choses. Il y a la limite absolue : une valeur qui sort d'une plage physiquement ou logiquement possible, comme un nombre négatif de collaborateurs. Il y a la limite relative : une valeur qui se situe dans le possible mais qui diffère fortement des périodes précédentes, comme un doublement de la consommation d'eau sans cause apparente. Et il y a l'écart comparatif : une valeur qui diffère d'une unité comparable, comme un établissement qui déclare trois fois plus de déchets qu'un établissement de taille équivalente. Chacun de ces trois types requiert une règle différente et un type différent de données source auquel se comparer. Un intermédiaire qui ne regarde que la valeur la plus récente ne voit souvent que le premier type. Le deuxième et le troisième exigent que vous disposiez de données historiques ou comparables, ce qui est une raison de le prendre en compte dès la conception du registre de points de données.
Un écart qui n'atterrit nulle part n'est pas un signal mais une ligne de journal. Pour chaque signal, il doit être établi qui est le premier destinataire : c'est généralement celui qui fournit le point de données, pas celui qui compile le rapport. Le service qui fournit les données peut vérifier une cause au moment où le rappel est encore frais. À l'échéance du rapport, ce contexte a souvent disparu. Il faut également établir ce qui se passe si le premier destinataire ne réagit pas : le signal passe-t-il, après un certain délai, à une deuxième personne, ou reste-t-il en suspens. Cette question est directement liée à la propriété que vous avez préalablement établie par point de données, et aux contrôles qui s'appliquent à ce point de données — voir quels contrôles se rattachent à un point de données et qui le remarque quand pour savoir comment signalisation et contrôle s'articulent.
Un écart peut être une erreur, mais peut aussi être un changement réel : une fusion, un nouvel établissement, un exercice de reporting modifié. Une règle de signalisation qui ne permet pas cette distinction conduit à deux problèmes. Les utilisateurs qui reçoivent trop de faux signaux finissent par ignorer tous les signaux. Les utilisateurs qui reçoivent trop peu de signaux passent à côté justement de l'écart qui compte réellement. Les deux sont une forme de précision illusoire : il semble que le système surveille, alors qu'en pratique il ne filtre plus rien. La manière d'éviter cela lors de la définition des seuils est décrite sur comment éviter la précision illusoire. Une partie de la solution consiste à exiger une justification lors de la fermeture d'un signal : non pour vérifier qui a commis une erreur, mais pour voir si le seuil lui-même doit être ajusté.
Une règle de signalisation identique pour toute l'organisation néglige le fait que les entités travaillent parfois avec des définitions différentes de ce qu'elles mesurent, même si le point de données porte partout le même nom. Un établissement qui délimite les émissions de scope 3 plus largement qu'un autre affichera des valeurs différentes sans qu'il y ait un problème. Une règle de signalisation qui n'en tient pas compte génère de fausses alertes à chaque comparaison entre entités. Sur que faire des définitions qui diffèrent selon l'entité, vous trouverez comment consigner cette différence afin que la règle de signalisation puisse en tenir compte plutôt que de la confondre avec une erreur.
Configurer un seuil d'alerte ne nécessite pas de logiciel ; cela nécessite de savoir, par point de données, ce qui est valide, ce qu'est un écart, et qui le voit. C'est précisément le type de travail que le Data Readiness Scan cartographie : le registre de points de données, les règles de qualité associées et la propriété, afin qu'un signal puisse s'appuyer sur quelque chose plutôt que sur une formule isolée dans une feuille de calcul. Le scan lui-même est en cours de développement ; celui qui souhaite déjà s'y engager peut s'inscrire sur la liste d'attente.
Une fois cette structure en place, une question suivante se pose : qui doit examiner ces signaux quotidiennement, et quelle partie de ce travail de contrôle est suffisamment répétitive pour être confiée à une machine. Cette question ne relève pas de cette page, mais du scan de travail de FTE TO AI, qui calcule par tâche quelle part du travail peut être reprise par l'IA. Pour l'examen d'écarts routiniers, la vérification d'une cause auprès d'un groupe fixe de fournisseurs de données et la tenue d'un journal des signaux, c'est souvent une question pertinente.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.