La maturité des données est un terme souvent utilisé pour placer une organisation sur une échelle : du niveau 1 au niveau 5, d'ad hoc à optimisé. Ces échelles ne sont pas sans valeur, mais elles suggèrent une précision qui n'existe généralement pas pour les données de durabilité. Une organisation n'est pas mature ou immature. Certains points de données sont bien étayés, d'autres tiennent à une seule feuille de calcul qu'une seule personne comprend. Mesurer la maturité des données signifie en pratique : déterminer, par point de données, d'où il vient, qui en assume la responsabilité et ce qui se passe si cette personne est absente.
Un score de maturité établi par un tiers donne une impression, mais pas une liste d'actions. Si la réponse est « niveau 2 sur 5 », vous ne savez toujours pas quel point de données est peu fiable, quelle source manque ou quel collaborateur est le seul à savoir comment un chiffre est construit. La maturité des données n'est utile comme instrument de mesure que lorsqu'elle est ventilée au niveau des points de données individuels. Pas : « l'organisation obtient un score moyen », mais : « ce point de données n'a pas de source documentée, ce point de données en a trois qui se contredisent. »
Il y a trois questions qui méritent une réponse par point de données, et qui donnent ensemble une image plus réaliste qu'un score global.
La première est la provenance : d'où vient ce chiffre, par quels systèmes et traitements, et ce parcours est-il documenté ou seulement connu de la personne qui le fait depuis des années. C'est précisément là que la lignée d'un point de données change ce qu'une organisation peut démontrer : pas le chiffre lui-même, mais le chemin qui y conduit.
La deuxième est la propriété : qui est responsable de ce point de données, et est-ce documenté indépendamment de la personne qui s'en occupe actuellement par hasard. Sans cette documentation, la question de savoir qui consulte votre registre de points de données lorsque le propriétaire actuel n'est plus là n'est pas rhétorique, mais un risque réel pour la continuité.
La troisième est la qualité : existe-t-il des règles qui signalent une erreur avant que le chiffre n'atteigne le rapport, ou une anomalie n'est-elle découverte que lorsqu'un tiers pose la question. Cette troisième question touche directement à la mesure dans laquelle les données sont contrôlables pour l'assurance : un auditeur ne vérifie pas si le chiffre paraît plausible, mais si la justification résiste à l'examen.
Cette manière de mesurer ne donne pas un chiffre permettant de vous comparer à une autre organisation. Elle ne dit rien sur le pourcentage de vos données qui sont « matures », car ce seuil est arbitraire et varie selon le secteur, le point de données et l'évaluateur. Elle ne prédit pas non plus combien de temps il faudra pour passer de la situation actuelle à une situation meilleure ; cela dépend du nombre de points de données, du nombre de systèmes impliqués et du nombre de personnes qui détiennent actuellement ce savoir uniquement dans leur tête.
Ce que la mesure fait, en revanche, c'est fournir un aperçu concret : ce point de données est en ordre, celui-là ne l'est pas, et voici exactement pourquoi. Cet aperçu est moins impressionnant qu'un score sur une échelle de cinq, mais c'est le seul qui offre une perspective d'action.
L'hypothèse selon laquelle les feuilles de calcul sont le problème conduit souvent à la conclusion qu'un nouvel outil augmente automatiquement la maturité. Ce n'est pas le cas. Comme décrit dans l'analyse de pourquoi les feuilles de calcul ne sont pas le cœur du problème, la vulnérabilité ne réside souvent pas dans le format de fichier mais dans l'absence de provenance et de propriété documentées. Un outil appliqué à un processus désorganisé produit des aperçus plus soignés des mêmes chiffres peu fiables. L'ordre est le suivant : d'abord déterminer ce qui existe et d'où cela vient, puis seulement choisir quel système le soutient.
Mesurer la maturité ne commence pas par toutes les données qu'une organisation pourrait un jour rapporter, mais par la question de savoir quels points de données sont réellement nécessaires pour les obligations de reporting en vigueur. Cette délimitation évite qu'une mesure ne se transforme en un inventaire de tout ce qui est documenté quelque part, alors que la distinction entre les points de données dont vous avez réellement besoin et ceux que vous collectez par hasard déjà détermine précisément sur quoi la mesure doit se concentrer. Ceux qui préfèrent parcourir cette approche d'abord lors d'une session collective plutôt que de simplement la lire trouveront son organisation décrite dans ce qu'est un bootcamp données et ce qu'il apporte.
Cette manière de mesurer est la première étape, pas le point final. Dès qu'il est clair quels points de données sont faiblement étayés, qui manque en tant que propriétaire et quelles règles de qualité n'existent pas encore, se pose la question de la façon de le documenter structurellement : dans un registre, avec une lignée par point de données et avec des règles qui signalent les anomalies avant qu'un rapport ne parte. C'est le travail auquel est destiné le Data Readiness Scan de csrdready.net. Le scan est en cours de développement ; celui qui souhaite déjà s'y engager peut s'inscrire sur la liste d'attente.
Une fois que vous savez quels points de données nécessitent de l'attention et qui en est responsable, la question suivante s'impose naturellement : quelle part du travail environnant — la retranscription, le contrôle, la fusion des sources — est un travail qu'une machine peut reprendre, et quelle part exige un jugement humain. Le scan de travail de FTE TO AI calcule, par tâche, quelle proportion peut être reprise par l'IA, afin que vous ne deviniez pas mais que vous comptiez.
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.