Un chiffre d'émissions avec deux décimales inspire confiance. Mais la précision de la présentation ne dit rien sur la fiabilité de la source. Une feuille de calcul qui se trouve trois retranscriptions manuelles plus loin peut tout aussi bien afficher deux décimales qu'un chiffre provenant directement d'un système validé. La différence ne réside pas dans l'apparence du chiffre, mais dans ce qui a été consigné sur son origine et sur ce qui constitue une valeur valide.
La fausse précision apparaît lorsqu'un nombre dégage plus de certitude que ne le justifient les données sous-jacentes. Cela ne résulte pas d'une intention malveillante. Cela se produit parce que personne n'a établi les limites d'un point de données : quelles valeurs sont plausibles, quels écarts sont normaux et lesquels doivent déclencher un signal. Sans ces limites, chaque chiffre paraît tout aussi crédible, y compris celui qui résulte d'une erreur de saisie ou d'une unité erronée.
La question qu'est-ce qu'une valeur valide devrait donc trouver une réponse pour chaque point de données, non pas après coup lors d'un contrôle par échantillonnage, mais au préalable, au moment où le point de données est enregistré. Une valeur valide n'est pas seulement un chiffre situé dans une fourchette. C'est aussi une unité correcte, une période cohérente et une source connue.
Une règle de qualité fait plus qu'approuver ou rejeter une valeur. Elle détermine aussi à quel moment un écart doit devenir un signal. Une consommation d'énergie supérieure de vingt pour cent à celle de l'année précédente peut être une erreur, mais peut aussi correspondre à une expansion réelle. La règle elle-même ne détermine pas ce qui s'est passé ; elle établit que ce type d'écart mérite une évaluation avant de poursuivre son parcours.
Comment définissez-vous un écart signalétique constitue donc une question différente de celle de savoir ce qu'est une valeur valide. L'une porte sur la limite de l'acceptable, l'autre sur la limite du remarquable. Ces deux limites sont nécessaires, et toutes deux doivent être établies par point de données, et non comme une règle générale valable pour l'ensemble du rapport.
Un signal que personne ne voit n'est pas un signal. C'est le point où de nombreuses structures de données s'arrêtent : la règle existe, l'écart est détecté, mais il n'a pas été établi qui reçoit la notification et ce que cette personne doit en faire. Sans attribution de responsabilité par point de données, un signal disparaît dans une liste que personne ne consulte, ou parvient à quelqu'un qui ne connaît pas le point de données et ne peut donc pas l'évaluer.
Quels contrôles accompagnent un point de données comprend donc non seulement la règle elle-même, mais aussi le parcours : qui en est le responsable, quand cette personne reçoit une notification, et ce qui se passe si elle ne réagit pas. Un point de données sans responsable est un point de données dont personne, à l'exception de l'utilisateur final du rapport, ne remarquera jamais qu'il a posé problème, et il sera alors trop tard pour remédier à la cause sous-jacente.
Il existe des outils qui détectent les écarts et affichent des tableaux de bord. Ces outils sont utiles une fois que les règles sont établies. Mais un outil fonctionnant sur un registre de points de données sans valeurs valides établies, sans définitions de signaux et sans responsables désignés, produit surtout des notifications que personne ne peut interpréter. La question faut-il d'abord acheter un outil ou d'abord organiser le processus s'applique ici directement : un outil superposé à un processus désorganisé change la forme du problème, pas son contenu.
Il en va de même pour les définitions. Si deux parties de l'organisation ont une compréhension différente du même point de données, une règle de qualité valable pour l'une produira un faux signal pour l'autre. Que faites-vous des définitions qui diffèrent selon les entités et quel choix consignez-vous devrait donc trouver une réponse au préalable, sans quoi chaque règle devient un compromis qui ne convient nulle part.
Les valeurs valides, les signaux et les responsabilités ne sont pas des éléments définis de manière générale puis appliqués partout de la même façon. Ils découlent de la manière dont une organisation enregistre effectivement le point de données, de qui y a accès en pratique et des erreurs survenues dans le passé. Quelles exigences fonctionnelles découlent de votre propre processus décrit comment ces règles sont déduites du processus existant plutôt que d'une liste de contrôle générique.
Dès qu'il est clair quelles valeurs sont valides, quels écarts constituent un signal et qui évalue ce signal, on obtient aussi une vue sur le travail qui se cache derrière ce contrôle : qui recherche les données, qui compare avec les périodes précédentes, qui transmet la notification. Ce travail se compose de tâches qui peuvent être décomposées, et pour une partie d'entre elles, il est possible de déterminer si un logiciel peut les reprendre. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, sur la base des mêmes règles et parcours consignés qui étayent la qualité des données.
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.