Un point de données sans contrôle est un chiffre que personne ne contredit. Il figure dans le rapport, il provient d'un système ou d'une feuille de calcul, et il est accepté parce qu'il n'y a aucune raison de le remettre en question. Ce n'est que lorsqu'une partie externe pose une question, ou qu'un chiffre change soudainement d'un facteur dix par rapport à l'année précédente, qu'on remarque que personne ne l'a jamais examiné. Il est alors trop tard pour reconstituer où les choses ont dérapé.
La question qui permet d'éviter cela est simple à poser mais difficile à répondre sans structure : quel contrôle correspond à ce point de données, et qui remarque quand quelque chose ne va pas. Ce sont deux questions, et elles devraient toutes deux avoir une réponse avant qu'un chiffre n'entre dans un rapport.
Chaque point de données a des limites. Une consommation d'énergie ne peut pas être négative. Un nombre d'ETP n'est pas une décimale. Un pourcentage ne dépasse pas cent. Cela semble évident, mais en pratique, ce type de limites n'est nulle part consigné — elles se trouvent dans la tête de la personne qui traite ces données depuis des années, et disparaissent dès que cette personne change de fonction.
Consigner une valeur valide ne signifie pas seulement noter une limite inférieure et une limite supérieure. Cela signifie aussi préciser dans quelle unité un point de données est fourni, quels formats de date sont autorisés, et si un champ vide est un résultat valide ou un signe que quelque chose manque. Sans cet accord, chaque exception est réévaluée par celui qui, à ce moment-là, se trouve l'examiner. Ce qui compte exactement comme valide, et à partir de quand une valeur limite est plutôt une hypothèse qu'une règle, est détaillé sur la page consacrée à ce qu'est une valeur valide.
Tout écart n'est pas une erreur. Un point de données peut se situer entièrement dans les limites valides et être malgré tout un signal — une consommation qui baisse soudainement, un nombre trois fois plus élevé qu'au trimestre précédent, un fournisseur qui, pour la première fois en deux ans, ne fournit aucune donnée. Ce ne sont pas des valeurs invalides. Ce sont des valeurs qui appellent le regard de quelqu'un qui connaît le contexte.
Une règle de signal est donc différente d'une règle de validation. La validation détermine si une valeur peut exister. Un signal détermine si une valeur, même valide, constitue malgré tout une raison de vérifier. La manière de fixer ce seuil — pourcentage d'écart fixe, comparaison avec une série historique, ou une combinaison des deux — dépend du point de données et de la stabilité habituelle de l'activité sous-jacente. La mise en place d'une telle règle, y compris l'équilibre entre trop et trop peu de signaux, est décrite sur la page consacrée à la configuration d'un écart de signal.
Une règle que personne ne voit n'est pas une règle. Lorsqu'un contrôle de validation ou de signal se déclenche quelque part dans un système, il doit être clair qui reçoit l'alerte et ce que cette personne en fait. Est-ce la personne qui saisit les données, le propriétaire du point de données, ou quelqu'un qui a une vue d'ensemble avant que le rapport ne soit établi ? Sans destinataire désigné, un signal disparaît dans un journal que personne ne consulte.
Ceci touche à la propriété des données, et la propriété des données touche à un problème qui reste non résolu dans de nombreuses organisations : différentes entités utilisent des définitions différentes pour ce qui, sur papier, est le même point de données. Un établissement compte les ETP en incluant l'intérim, l'autre non. Lorsqu'un signal se déclenche indiquant qu'une valeur dévie, la première question n'est souvent pas de savoir si la valeur est correcte, mais si tout le monde utilise la même définition. La manière de gérer cela est expliquée sur la page consacrée aux définitions qui diffèrent selon les entités.
Il est tentant de chercher ces contrôles dans un logiciel : quelque chose qui alerte, valide et rapporte automatiquement. Mais un outil qui exécute des contrôles sur des données pour lesquelles personne n'a défini ce qu'est une valeur valide n'exécute aucun contrôle — il donne seulement un résultat qui a l'air correct sur un processus qui n'a toujours pas été pensé. Les règles doivent exister d'abord, indépendamment du système qui les appliquera finalement. Cet ordre, et pourquoi l'inverser mène généralement à une déception, est expliqué sur la page consacrée à acheter d'abord un outil ou d'abord organiser le processus.
Lorsque, pour chaque point de données, ce qu'est une valeur valide, quand un signal se déclenche, et qui reçoit ce signal sont établis, un registre se forme qui non seulement documente, mais est aussi utilisable comme cahier des charges. Ce registre est précisément ce qui est nécessaire pour déterminer ce qu'un système — construit en interne ou acheté — devra pouvoir faire. Sans ce cahier des charges, tout achat devient un pari. La manière de traduire cela en exigences fonctionnelles issues de votre propre processus, plutôt que d'un fournisseur, est expliquée sur la page consacrée aux exigences fonctionnelles issues de votre propre processus.
Les contrôles sur les points de données révèlent aussi à quel point une grande partie du travail environnant est répétitive : faire la même comparaison, transmettre la même alerte, réévaluer la même exception. Quelle part de cette répétition se prête à une reprise par l'IA, et quelle part exige au contraire une évaluation qui ne peut être automatisée, est une question qui se répond tâche par tâche. Le scan de travail de FTE TO AI calcule cela par tâche.
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.