Un registre commence généralement comme une liste. Quelqu'un met en ligne tous les points de données de la norme de reporting, leur trouve un responsable et appelle cela un registre. C'est le point de départ, pas le point d'arrivée. La question « quand est-ce terminé » a une réponse concrète, et cette réponse ne porte pas sur le nombre de lignes que compte la liste.
Un registre de points de données est complet lorsque quatre éléments ont été consignés pour chaque point de données. Premièrement, la définition : ce que le point de données mesure exactement, dans quelle unité, sur quelle période et selon quel périmètre. Deuxièmement, la source : le système, le document ou la personne d'où provient le chiffre. Troisièmement, le propriétaire : qui est responsable de l'exactitude de ce point de données spécifique, et non du reporting dans son ensemble. Quatrièmement, une règle de qualité : un contrôle permettant de vérifier si la valeur est plausible, par exemple une fourchette, une comparaison avec une année précédente, ou une addition qui doit être correcte.
Si l'un de ces quatre éléments manque pour un point de données, le registre n'est pas terminé sur ce point. Cela vaut également si le point de données lui-même est rapporté depuis des années. Un chiffre qui figure dans le rapport depuis trois ans peut encore n'avoir ni source ni propriétaire consignés.
L'ordre dans lequel vous remplissez le registre déterminera la quantité de travail nécessaire et sa fiabilité. Commencer par la norme de reporting est logique, mais la norme ne dit pas ce que votre organisation est réellement capable de mesurer. C'est pourquoi la première étape consiste souvent à distinguer ce qui est obligatoire de ce que vous consignez déjà quelque part : quels points de données vous sont réellement nécessaires lorsque vous travaillez avec plusieurs unités opérationnelles détermine l'ampleur du registre avant même que vous n'en abordiez le contenu.
Vient ensuite la question de savoir où chaque point de données existe déjà. Dans les organisations comptant plusieurs implantations ou unités opérationnelles, le même point de données se trouve parfois à plusieurs endroits, sous une forme légèrement différente. Où un point de données existe-t-il déjà lorsque vous travaillez avec plusieurs unités opérationnelles est l'étape qui évite de collecter deux fois les mêmes données sous deux noms différents.
Pour la structure du registre lui-même, y compris l'ordre de travail et la répartition des rôles entre celui qui le remplit et celui qui le contrôle, une page distincte décrit étape par étape comment établir un registre de points de données lorsque vous travaillez avec plusieurs unités opérationnelles.
Dans presque tous les registres apparaît un point de données pour lequel aucune source claire n'est identifiable. Le chiffre figure dans le rapport précédent, mais personne ne peut indiquer d'où il provient. Ce n'est pas une raison pour rejeter le registre ou en interrompre l'élaboration. Il s'agit d'une catégorie à traiter séparément : les points de données sans source reçoivent un statut et un plan, pas une estimation notée comme s'il s'agissait d'une source. Ce qu'il convient de consigner dans cette situation est décrit sur la page consacrée à ce qu'il faut faire d'un point de données sans source lorsque vous travaillez avec plusieurs unités opérationnelles. Un registre comportant dix points de données au statut « source manquante, action assignée » est plus avancé qu'un registre dans lequel ces dix points de données se sont vu attribuer silencieusement une source que personne ne peut vérifier.
Identifier une source ne revient pas à savoir comment le chiffre de cette source parvient jusqu'au rapport. Entre les deux se trouve souvent une série d'opérations : additionner, convertir, corriger les doubles comptages, agréger par unité. Si personne n'a consigné ces étapes, les mêmes données source peuvent conduire deux personnes à deux chiffres de rapport différents, sans que quiconque ne s'en rende compte. Ce lien entre la source et la ligne du rapport s'appelle le source-to-report mapping, et la logique sous-jacente est détaillée dans ce qu'implique le source-to-report mapping. Pour les points de données plus complexes, il est utile de savoir également quelles opérations se situent exactement entre la source et le rapport, afin qu'un contrôle ne vérifie pas seulement le chiffre final mais aussi les étapes intermédiaires.
Un registre peut être entièrement rempli sans pour autant être terminé, si les règles de qualité n'ont jamais été testées. Ce n'est que lorsque quelqu'un a réellement appliqué une règle de qualité à une valeur, et que cette valeur a été validée ou rejetée sur cette base, que vous savez si la règle fonctionne. Un registre n'est donc véritablement terminé qu'après au moins un cycle durant lequel les règles ont été utilisées, et non simplement rédigées. C'est également à ce moment que l'on découvre quels propriétaires sont réellement capables de répondre aux questions concernant leur point de données, et lesquels ne le sont que sur le papier.
Dès que le registre, les sources et les règles de qualité sont établis, une autre question se pose : qui effectue les contrôles, qui complète les sources manquantes, et quelle part de ce travail est suffisamment répétitive pour être automatisée. C'est une question de capacité, pas de structure, et c'est précisément à cela que sert le scan de travail de FTE TO AI : il calcule, pour chaque tâche, quelle part du travail peut être reprise par l'IA, afin que vous sachiez où les personnes restent nécessaires et où elles ne le sont pas.
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.