Un point de données en double se remarque rarement par son nom. Deux lignes du registre portent en général un nom différent — « consommation d'énergie bureau » et « consommation d'électricité site NL » — alors qu'elles renvoient au même compteur, à la même facture ou à la même source. Le doublon ne se trouve pas dans le texte, mais dans l'origine. Qui ne cherche que par nom ne trouvera pas les doublons.
Un registre des points de données n'est pas une liste de lignes de rapport, mais un registre des données sous-jacentes : pour chaque point de données, la définition, la source, le propriétaire et le chemin parcouru de la source au rapport. Chaque point de données obtient une place fixe avec quatre champs fixes : ce qu'il est, d'où il vient, qui en est responsable et quelles transformations lui ont été appliquées avant d'aboutir dans un rapport. Sans ces quatre champs, un registre n'est qu'un lexique, pas un instrument de contrôle.
La question qu'est-ce que le source-to-report mapping décrit en détail cette troisième étape : le trajet qu'un chiffre parcourt du système source jusqu'à la ligne de rapport. Ce même trajet est l'instrument qui rend les doublons visibles. Deux points de données portant un nom différent mais une ligne source-vers-rapport identique sont un seul et même point de données, enregistré deux fois.
Les points de données en double ne résultent généralement pas d'un manque de rigueur, mais de la structure de l'organisation. Une équipe facilities enregistre la consommation d'énergie pour la gestion du bâtiment, une équipe développement durable enregistre la même consommation pour le rapport CSRD. Les deux équipes travaillent à partir de leur propre feuille de calcul, avec leur propre nomenclature, sans visibilité sur l'enregistrement de l'autre. Avec plusieurs sites ou unités opérationnelles, ce schéma se multiplie : chaque unité consigne des données comparables sous son propre libellé.
La page où un point de données existe-t-il déjà auprès de plusieurs unités opérationnelles traite précisément de ce mécanisme : avant d'ajouter un point de données au registre, la première question est de savoir s'il existe déjà quelque part dans l'organisation, uniquement sous un autre nom ou dans un autre service. Poser cette question avant l'enregistrement évite une grande partie des doublons qu'il faudrait sinon détecter après coup.
La manière fiable de reconnaître un doublon n'est pas de comparer les descriptions, mais de comparer les sources. Deux points de données provenant du même système, de la même table ou du même fichier d'export, avec la même date de référence et la même unité, sont candidats à une fusion — même si la nomenclature n'en laisse rien paraître. À l'inverse : deux points de données au nom similaire mais issus d'une source différente ne constituent pas nécessairement un doublon, mais peuvent être deux mesures distinctes qui se ressemblent par coïncidence.
Cette distinction n'est possible que si le registre consigne la source de chaque point de données, et pas seulement la valeur finale. Un registre qui ne fait que collecter des chiffres sans origine ne peut pas détecter les doublons — il peut, au mieux, les soupçonner.
Outre la source, la propriété constitue un second indice. Lorsque deux points de données partagent la même source mais sont enregistrés auprès de propriétaires différents, cela ne constitue pas en soi un problème — cela peut indiquer un point de données utilisé par plusieurs services. Cela devient un signal lorsque les deux propriétaires effectuent indépendamment les mêmes transformations, sans avoir connaissance du travail de l'autre. Dans ce cas, ce n'est pas le point de données qui est en double, mais le processus qui l'entoure.
La question quelles transformations se situent entre la source et le rapport est pertinente ici : deux points de données ayant la même source mais des transformations différentes peuvent produire des chiffres différents, tout en figurant dans le rapport sous la même rubrique. C'est une situation plus risquée qu'un simple doublon, car les chiffres peuvent diverger sans que personne ne le remarque.
Détecter les points de données en double n'est pas un exercice ponctuel qui se termine à un moment fixe. Avec une organisation en croissance, de nouveaux systèmes ou des périmètres de rapport modifiés, de nouveaux candidats au doublon apparaissent. La page quand un registre est-il achevé décrit qu'un registre n'est pas complet à une date fixe, mais au moment où chaque point de données possède une source, un propriétaire et un chemin vérifiable vers le rapport — y compris la vérification de son existence éventuelle ailleurs.
Dans les organisations comptant plusieurs unités opérationnelles, la question quels points de données vous faut-il réellement avec plusieurs unités opérationnelles constitue un bon point de départ, car elle détermine l'ampleur du registre avant même que ne commence la recherche des doublons. Un registre plus restreint et mieux délimité contient naturellement moins de place pour le chevauchement.
Parcourir manuellement les sources, les propriétaires et les transformations pour trouver des doublons est précisément le type de travail qui se laisse découper en étapes reproductibles : mettre des données en regard, signaler des correspondances, formuler une proposition de fusion à soumettre à évaluation. Pour les organisations qui souhaitent savoir quelle part de ce travail de comparaison est transférable à une application d'IA, et quelle part reste soumise à l'évaluation humaine, le werkscan de FTE TO AI le calcule au niveau des tâches. Le scan ne porte pas de jugement sur votre registre, mais fournit une répartition des tâches qui s'y trouvent — un point de départ avant de choisir comment organiser la détection des doublons.
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.