Il y a un moment fixe dans presque toute conversation sur les données de durabilité : quelqu'un pointe le tableur. Trop d'onglets, trop de travail manuel, trop de risques d'erreurs. La conclusion semble évidente : remplacer le tableur par un système et le problème est résolu. Cette conclusion est généralement tirée trop tôt.
Un tableur est une surface. Il affiche des chiffres, les additionne, les relie entre eux. Ce qu'il ne fait pas, c'est expliquer d'où vient un chiffre, qui en est responsable, ou s'il correspond encore à la définition établie il y a deux ans. Ces questions n'ont pas été posées au tableur — elles n'ont jamais été consignées nulle part. Le tableur est accusé de quelque chose qui a déjà mal tourné avant : lors de la collecte, de la retranscription, en présumant qu'un collègue savait bien quel chiffre était visé.
Remplacez le tableur par un logiciel et ces questions restent sans réponse. Le système affiche alors un aperçu plus soigné de la même incertitude. Le rapport paraît plus professionnel ; les données sous-jacentes ne sont pas devenues plus fiables. C'est le piège : acheter un outil avant de savoir clairement ce que cet outil doit organiser.
Il s'agit généralement de trois éléments qui se sont développés indépendamment les uns des autres. Il n'existe pas d'aperçu actualisé des points de données dont une organisation a besoin — cet aperçu a été établi à l'époque pour une ancienne norme de reporting et n'a pas été mis à jour. Il n'existe pas de filiation établie entre la source et le chiffre du rapport, ce qui fait que personne ne peut affirmer avec certitude si un chiffre provient d'un système ou d'un autre, ou d'une estimation que quelqu'un a un jour renseignée parce que les données réelles n'étaient pas disponibles. Et il n'y a pas de propriétaire par point de données — la personne qui fournit le chiffre n'est pas automatiquement celle qui peut expliquer d'où il provient ou quelle en est la qualité.
Ces trois éléments n'ont rien à voir avec les tableurs. Ils causeraient le même problème dans n'importe quel système. Un tableur les rend simplement plus visibles, car il n'y a pas de couche par-dessus qui dissimule le désordre.
Un registre de points de données avec une filiation source-to-report consigne d'où provient un point de données, qui en est responsable et quelles règles de qualité s'y appliquent. C'est utile, et c'est aussi limité. Le registre ne montre pas de jugement sur le fond quant à l'exactitude d'un chiffre — il montre si le chemin menant à ce chiffre est traçable. Deux organisations disposant du même registre peuvent tout de même obtenir des scores différents en matière de qualité des données, car l'une dispose d'une source elle-même imprécise et l'autre non. Le registre rend cette différence visible ; il ne la résout pas.
Il est également important de noter que tous les points de données n'ont pas besoin du même niveau de filiation. Pour certains chiffres, une source simple et bien documentée suffit ; pour d'autres, davantage de détails sont nécessaires car il y a plus d'étapes entre la source et le rapport. Les points de données dont une organisation a réellement besoin dépendent de l'obligation de reporting et du secteur, ce qui est différent de présumer que tout mérite la même attention. La proportion de points de données existants disposant déjà d'une source varie fortement selon l'organisation — chez l'une, cela est consigné dans une interface ERP, chez l'autre, dans la mémoire d'un seul collaborateur.
Mettre en place un registre et une filiation n'est pas une question d'activer un système. Il s'agit de vérifier, sujet par sujet, où un chiffre naît, qui le contrôle avant qu'il n'atteigne le rapport, et ce qui se passe si cette personne n'est plus là. Ce travail varie selon le sujet : pour certains, la source est déjà disponible, pour d'autres, elle doit encore être trouvée ou reconstituée. Qui se demande combien de temps cela prend par sujet trouvera une réponse plus réaliste dans l'indication du délai par sujet que dans une démonstration d'outil promettant que tout se fait automatiquement.
Cette approche ne produit pas de rapport — cela relève d'un autre outil, sur la base de ces données. Ce qu'elle produit, c'est une structure qui subsiste même lorsque le tableur est remplacé, même lorsque le collaborateur qui savait tout s'en va. Ce que cela signifie concrètement pour celui qui consultera le registre à l'avenir est décrit dans qui consulte votre registre de points de données lorsque son créateur n'est plus là, et ce qui change une fois la filiation établie est expliqué dans les conséquences d'une filiation une fois établie.
Les tableurs ne sont pas le problème, mais ils en sont bien le premier symptôme visible. Qui remplace le tableur sans savoir au préalable quels points de données comptent réellement, quelle source y correspond et qui en est responsable, déplace le problème vers un système plus coûteux. Ce qui reste alors est la question qui précède ce travail : quels points de données sont réellement nécessaires pour l'obligation de reporting, et si une partie d'entre eux existe peut-être déjà quelque part dans l'organisation sans que personne ne le sache, comme expliqué dans où un point de données existe peut-être déjà.
C'est un travail que les gens effectuent aujourd'hui en grande partie manuellement : rechercher des sources, comparer des définitions, se renseigner sur la propriété. Une partie de ce travail de recherche peut être structurée et accélérée par l'IA, une autre non — cette différence est précisément ce que la werkscan de FTE TO AI examine. La werkscan calcule, par tâche, quelle part du travail peut être reprise par l'IA, offrant ainsi une image plus réaliste que l'hypothèse selon laquelle un outil résoudrait le problème dans son intégralité.
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.