Un journal enregistre qui a ouvert un fichier et quand. C'est utile, mais cela ne répond pas à la question qui revient le plus souvent avec les données de durabilité : comment ce chiffre a-t-il été obtenu. Lorsque la source est un tableur, cette différence est plus marquée que pour un système, car un tableur n'impose aucune structure fixe. N'importe qui peut modifier une formule, ajouter une ligne ou changer une unité sans laisser de trace allant plus loin qu'un nom de fichier avec une date.
Un journal vous indique que le fichier « Scope1_2023_v4.xlsx » a été enregistré à une certaine date. Il ne vous indique pas quelle cellule a été modifiée, pour quelle raison, ni si cette modification était une correction ou une nouvelle hypothèse. Pour les données de durabilité, cette distinction est pertinente, car un chiffre passe souvent par plusieurs mains avant d'atterrir dans un rapport. Celui qui peut démontrer ce qui s'est passé entre la source et le rapport peut aussi démontrer pourquoi un chiffre est ce qu'il est. Celui qui ne peut pas le démontrer n'a qu'un résultat, sans le chemin qui y mène.
Entre les données brutes d'un tableur et le chiffre figurant dans un rapport se trouvent généralement plusieurs opérations : une unité est convertie, une période est regroupée, une valeur aberrante est corrigée, un résultat d'un onglet est ajouté à un résultat d'un autre onglet. Chaque étape est un moment où une hypothèse est posée. Les opérations entre la source et le rapport qui ont lieu précisément varient selon le point de données et l'organisation, mais les étapes elles-mêmes sont rarement uniques. Elles se retrouvent dans presque tous les chiffres composés à partir de plusieurs sources.
Une piste d'audit qui ne montre que le résultat final et la dernière date de modification passe entièrement à côté de ces étapes intermédiaires. Pour pouvoir retracer un chiffre, il faut avoir enregistré quelle opération a été appliquée à quel moment, avec quelles données d'entrée, et par qui. C'est une autre forme d'enregistrement que celle qu'offre un journal : c'est le mapping source-to-report, où le point de départ n'est pas le fichier mais le point de données.
Une des opérations qui reste le plus souvent dans l'ombre est l'agrégation : l'addition de chiffres provenant de différentes sources, départements ou périodes en un seul nombre. L'agrégation ressemble à une étape technique, mais elle contient souvent des choix de fond : quelles unités sont harmonisées, quelles périodes sont prises en compte, quelles exceptions sont traitées à part. La façon dont vous documentez l'agrégation détermine si quelqu'un peut par la suite retracer pourquoi le total est ce qu'il est, ou si le total reste une boîte noire que seul son créateur peut expliquer, une explication qui ne tient plus dès que cette personne n'est plus disponible.
Une piste d'audit sans propriété clairement établie enregistre ce qui s'est passé, mais pas qui en est responsable. Pour les tableurs, c'est un risque, car un fichier peut être modifié par plusieurs personnes sans qu'il soit clair qui a fait le choix de fond. Enregistrer qui a exécuté une opération est différent d'enregistrer qui détient la définition d'un point de données : l'un enregistre une action, l'autre établit qui peut expliquer pourquoi un point de données est défini comme il l'est. Les deux sont nécessaires pour qu'une piste d'audit soit utile à quelqu'un qui n'a pas participé au processus.
Par ailleurs, il est pertinent de distinguer qui exécute une opération et qui détient le processus sous-jacent. Un collaborateur peut être responsable du remplissage d'un tableur, tandis qu'une autre personne est responsable du processus dans lequel ce tableur est utilisé. Une piste d'audit qui ne fait pas cette distinction renvoie, en cas de question, vers la dernière personne ayant touché quelque chose, et non vers celui qui peut réellement expliquer pourquoi le processus est organisé ainsi.
Il est possible de commencer cet enregistrement sans acquérir de système pour cela. Cela commence par nommer les opérations appliquées à un point de données, enregistrer qui exécute quelle étape, et décrire la raison d'une correction au moment où elle est effectuée. La façon dont vous construisez la lignée sans outil lorsque la source est un tableur est avant tout une question de discipline dans l'enregistrement, pas de logiciel. Un outil peut ensuite soutenir ce processus, mais un outil placé au-dessus d'un processus qui n'enregistre rien ne produit qu'un tableur plus soigné, avec les mêmes hypothèses invisibles à l'intérieur.
Dès que les étapes entre la source et le rapport sont nommées et enregistrées, une deuxième question se pose : qui exécute réellement ces étapes, et quelle part de ce travail est suffisamment répétable pour être transférée. Beaucoup des opérations décrites ici, comme convertir des unités ou regrouper des données provenant de sources fixes, sont des tâches qui se décomposent en étapes. Le [scan de travail de FTE TO AI](https://fte-to-ai.com) calcule, par tâche, quelle part de ce travail peut être reprise par l'IA, en se basant sur la nature de la tâche plutôt que sur une hypothèse générale sur ce que l'automatisation peut faire.
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.