Comment mettre en œuvre un processus de qualité des données

La qualité des données (DQ) dans les systèmes d'entrepôt de données devient de plus en plus importante. L'augmentation des exigences réglementaires, mais aussi la complexité croissante des solutions d'entrepôt de données, obligent les entreprises à intensifier (ou démarrer) une démarche de qualité des données.

Cet article se concentrera principalement sur l'entreposage de données "traditionnel", mais la qualité des données est également un problème dans des concepts plus "modernes" tels que les lacs de données. Il montrera quelques points principaux à considérer ainsi que certains pièges courants à éviter lors de la mise en œuvre d'une stratégie de qualité des données. Il ne couvre pas la partie sur le choix de la bonne technologie/outil pour construire un framework DQ.

L'un des problèmes les plus gênants d'un projet DQ est le fait qu'à première vue, il crée beaucoup de travail pour les unités commerciales sans fournir de fonctionnalités supplémentaires. Une initiative de qualité des données n'a généralement de partisans sérieux que si :

• Il existe des problèmes de qualité des données qui ont un impact important sur l'entreprise.
• Les organismes de réglementation appliquent des normes de qualité des données (par exemple, BCBS 239 dans le secteur financier).

Le traitement de DQ est similaire à celui des tests dans le développement de logiciels - si un projet manque de temps et/ou de budget, cette partie a tendance à être réduite en premier.

Ceci, bien sûr, n'est pas toute la vérité. Un bon système de qualité des données aide à détecter les erreurs plus tôt, accélérant ainsi le processus de fourniture de données de qualité « suffisamment bonne » aux utilisateurs.

Définition des termes

Avant de discuter du sujet, une compréhension commune des termes utilisés est importante.

Entrepôt de données (DWH)

Un entrepôt de données (DWH) est un système non opérationnel principalement utilisé pour l'aide à la décision. Il consolide les données des systèmes opérationnels (tous ou un sous-ensemble plus petit) et fournit des données optimisées pour les requêtes aux utilisateurs du système DWH. L'entrepôt de données doit fournir "une version unique de la vérité" au sein de l'entreprise. Un entrepôt de données est généralement constitué d'étapes/couches :

Les données opérationnelles sont stockées pour la plupart inchangées dans une couche intermédiaire . La couche centrale contient des données consolidées et unifiées. L'étape facultative suivante est une zone de dérivation , fournissant des données dérivées (par exemple, un score client pour les ventes) et des agrégations. La couche data mart contient des données optimisées pour un groupe d'utilisateurs donné. Les magasins de données contiennent souvent des agrégations et de nombreuses mesures dérivées. Les utilisateurs de l'entrepôt de données travaillent souvent uniquement avec la couche du magasin de données.

Entre chaque étape, une sorte de transformation des données a lieu. Habituellement, un entrepôt de données est périodiquement chargé avec des extractions delta des données opérationnelles et contient des algorithmes pour conserver les données historiques.

Qualité des données

La qualité des données est généralement définie comme une mesure indiquant dans quelle mesure un produit répond aux besoins des utilisateurs. Différents utilisateurs peuvent avoir des exigences différentes pour un produit, la mise en œuvre dépend donc du point de vue de l'utilisateur, et il est important d'identifier ces besoins.

La qualité des données ne signifie pas que les données doivent être complètement ou presque exemptes d'erreurs, cela dépend des besoins des utilisateurs. Une approche "assez bonne" est un bon choix pour commencer. De nos jours, les grandes entreprises ont « une politique gouvernementale de données (ou d'informations) », et la qualité des données en fait partie. Une politique gouvernementale sur les données doit décrire comment votre entreprise traite les données et comment elle s'assure que les données ont la bonne qualité et que les règles de confidentialité des données ne sont pas violées.

La qualité des données est un sujet d'actualité. Une boucle de circuit DQ doit être implémentée (voir chapitre suivant). Les exigences réglementaires et les règles de conformité ont également un impact sur la qualité des données nécessaires, comme TCPA (US Telephone Consumer Protection Act) ou GDPR en Europe pour les questions de confidentialité, mais aussi des règles spécifiques à l'industrie comme Solvency II pour les assurances dans l'UE, BCBS 239 et d'autres pour la banque, etc.

Boucle de circuit de qualité des données

Comme pour tous les sujets de qualité, le DQ est une activité continue conçue pour maintenir une qualité satisfaisante. À la suite d'un projet DQ, une boucle de circuit similaire à celle ci-dessous doit être implémentée :

Les étapes de cette boucle seront décrites dans les chapitres suivants.

Rôles de qualité des données

Pour mettre en œuvre une initiative DQ réussie, les rôles suivants sont nécessaires :

• Propriétaire des données. Un propriétaire de données est responsable de la qualité des données, mais aussi de la protection de la confidentialité des données. Le propriétaire des données « possède » un domaine de données, contrôle l'accès et est chargé d'assurer la qualité des données et de prendre des mesures pour corriger les résultats. Dans les grandes organisations, il est courant de trouver plusieurs propriétaires de données. Les domaines de données peuvent être, par exemple, des données marketing, des données de contrôle, etc. S'il existe plusieurs propriétaires de données dans une entreprise, il devrait y avoir une personne (un propriétaire de données ou quelqu'un d'autre) responsable du processus global de qualité des données. Un propriétaire de données doit disposer d'une autorité forte pour faire respecter la qualité des données et soutenir le processus DQ ; par conséquent, les propriétaires de données sont souvent des parties prenantes de haut niveau. Une bonne compréhension du domaine des affaires ainsi que de bonnes compétences en communication sont importantes.
• Intendant des données. Un arbitre de données aide à mettre en œuvre la qualité des données au sein d'une entreprise, en aidant les utilisateurs de données sur les questions d'interprétation des données/du modèle de données, les problèmes de qualité des données, etc. Les arbitres de données font souvent partie du personnel du propriétaire des données ou peuvent être organisés dans un centre de compétences sur la qualité des données ou une équipe DQ. Les gestionnaires de données peuvent avoir une formation en informatique ou en affaires, mais doivent connaître les deux côtés. Des compétences analytiques ainsi qu'une bonne compréhension du domaine d'activité qu'ils prennent en charge, combinées à de solides compétences en communication, sont les principales conditions préalables à la réussite d'un gestionnaire de données.
• Utilisateur de données. Ce sont des utilisateurs d'entrepôt de données qui travaillent avec des données. Les utilisateurs de données travaillent généralement avec la couche data mart et sont responsables des résultats du travail avec les données. Les utilisateurs de données s'assurent qu'il existe des contrôles de qualité des données adéquats pour le niveau de qualité dont ils ont besoin. Les utilisateurs de données ont besoin d'une solide compréhension de leurs données, de leur domaine d'activité et des compétences analytiques requises pour interpréter les données. Il est raisonnable de trouver quelques personnes parmi les utilisateurs de données dans chaque unité d'affaires qui seront responsables des problèmes de qualité des données.

Pour garantir le succès, il est important que ces rôles soient clairement définis et largement acceptés au sein de votre organisation dès les premières étapes de votre projet DQ. Il est tout aussi important de trouver des spécialistes des données compétents pour ces rôles qui soutiennent le projet.

Définir les règles

Trouver et mettre en œuvre des vérifications/règles DQ utiles . La définition des règles DQ nécessite une bonne compréhension de votre entrepôt de données et de son utilisation.

Comment trouver les règles DQ ?

Comme indiqué précédemment, les utilisateurs de données (et le propriétaire des données) sont responsables de l'utilisation des données et donc également du niveau nécessaire de qualité des données. Les utilisateurs de données doivent avoir une bonne compréhension de leurs données afin qu'ils puissent donner la meilleure entrée pour les règles de qualité des données utiles.

Ce sont également eux qui analysent les résultats des règles de qualité des données, c'est donc toujours une bonne idée de les laisser définir leurs propres règles. Cela améliore encore l'acceptation de vérifier et d'évaluer le résultat des règles DQ attribuées à une unité d'utilisateur de données (voir le chapitre « Analyser »).

L'inconvénient de cette approche est que les utilisateurs de données ne connaissent normalement que la couche du magasin de données, pas les couches antérieures de l'entrepôt de données. Si des données ont été corrompues dans les étapes "inférieures", cela ne sera pas détecté en vérifiant uniquement la couche "supérieure" de votre entrepôt de données.

S'attaquer aux erreurs

Quel type d'erreurs connues peut se produire dans un entrepôt de données ?

• Mauvaise logique de transformation dans l'entrepôt de données
  • Plus votre paysage informatique est complexe, plus la logique de transformation a tendance à être complexe. Ce sont les problèmes de DQ les plus courants, et l'effet de telles erreurs peut être des données « perdues », des doublons, des valeurs incorrectes, etc.
• Processus de charge instable ou mauvaise manipulation des charges
  • Le chargement d'un entrepôt de données peut être un processus complexe pouvant inclure des erreurs dans la définition de l'orchestration des jobs (jobs commençant trop tôt ou trop tard, jobs non exécutés, etc.). Les erreurs dues à une intervention manuelle (par exemple, certaines tâches sont ignorées, certaines tâches sont démarrées avec une date d'échéance erronée ou avec les fichiers de données d'hier) se produisent souvent lorsque le processus de chargement est exécuté hors bande en raison d'une interruption.
• Mauvais transfert de données des sources de données
  • Le transfert de données est souvent mis en œuvre en tant que tâche du système source. Des anomalies ou des perturbations dans les flux de travail peuvent entraîner la livraison de données vides ou incomplètes.
• Données opérationnelles erronées
  • Les données du système opérationnel contiennent des erreurs non reconnues jusqu'à présent. Cela peut sembler étrange, mais c'est une platitude dans les projets d'entrepôt de données que la qualité des données opérationnelles n'est souvent pas vue tant que les données ne sont pas incluses dans un DWH.
• Mauvaise interprétation des données
  • Les données sont correctes, mais les utilisateurs ne savent pas comment les interpréter correctement. Il s'agit d'une « erreur » très courante qui n'est pas strictement un problème de qualité des données, mais quelque chose qui a à voir avec la gouvernance des données et qui incombe aux gestionnaires de données.

Ces problèmes sont souvent causés par des personnes qui n'ont pas le savoir-faire et les compétences nécessaires pour définir, mettre en œuvre, exécuter et utiliser une solution d'entrepôt de données.

Dimensions de la qualité des données

Les dimensions DQ sont un moyen courant d'identifier et de regrouper les vérifications DQ. Il existe de nombreuses définitions et le nombre de dimensions varie considérablement : vous pouvez trouver 16 dimensions, voire plus. D'un point de vue pratique, il est moins déroutant de commencer par quelques dimensions et d'en trouver une compréhension générale parmi vos utilisateurs.

• Exhaustivité : toutes les données requises sont-elles disponibles et accessibles ? Toutes les sources nécessaires sont-elles disponibles et chargées ? Des données ont-elles été perdues entre les étapes ?
• Cohérence : y a-t-il des données erronées/conflictuelles/incohérentes ? Par exemple, la date de résiliation d'un contrat à l'état "Résilié" doit contenir une date valide supérieure ou égale à la date de début du contrat.
• Unicité : y a-t-il des doublons ?
• Intégrité : toutes les données sont-elles correctement liées ? Par exemple, y a-t-il des commandes liées à des identifiants clients inexistants (problème classique d'intégrité référentielle) ?
• Actualité : les données sont-elles à jour ? Par exemple, dans un entrepôt de données avec des mises à jour quotidiennes, je m'attendrais à ce que les données d'hier soient disponibles aujourd'hui.

Les données générées par le processus de chargement de l'entrepôt de données peuvent également être utiles.

• Tables avec des données ignorées. Votre entrepôt de données peut avoir des processus pour ignorer/retarder les données qui ne peuvent pas être chargées en raison de problèmes techniques (par exemple, conversion de format, valeurs obligatoires manquantes, etc.).
• Informations de journalisation. Des problèmes notables peuvent être écrits dans des tables de journalisation ou des fichiers journaux.
• Bon de livraison. Certains systèmes utilisent des « bordereaux de livraison » pour les données fournies par les systèmes opérationnels (par exemple, le nombre d'enregistrements, le nombre de clés distinctes, les sommes de valeurs). Ceux-ci peuvent être utilisés pour des contrôles de rapprochement (voir ci-dessous) entre l'entrepôt de données et les systèmes opérationnels.

Gardez à l'esprit que chaque contrôle de la qualité des données doit être analysé par au moins un utilisateur de données (voir le chapitre "Analyser") au cas où des erreurs seraient trouvées, pour lesquelles vous aurez besoin d'une personne responsable et disponible pour s'occuper de chaque contrôle mis en œuvre.

Dans un entrepôt de données complexe, vous pouvez vous retrouver avec de nombreuses (parfois des milliers) règles DQ. Le processus d'exécution des règles de qualité des données doit être suffisamment robuste et rapide pour gérer cela.

Ne vérifiez pas les faits qui sont garantis par la mise en œuvre technique. Par exemple, si les données sont stockées dans un SGBD relationnel, il n'est pas nécessaire de vérifier si :

• Les colonnes définies comme obligatoires contiennent des valeurs NULL.
• Les valeurs des champs de clé primaire sont uniques dans une table.
• Il n'y a pas de clés étrangères existantes dans une table avec les contrôles d'intégrité relationnelle activés.

Cela dit, gardez toujours à l'esprit qu'un entrepôt de données est en constante évolution et que la définition des données des champs et des tables peut changer au fil du temps.

Le ménage est très important. Les règles définies par différentes unités utilisatrices de données peuvent se chevaucher et doivent être consolidées. Plus votre organisation est complexe, plus le ménage sera nécessaire. Les propriétaires de données doivent mettre en œuvre un processus de consolidation des règles comme une sorte de « qualité des données pour les règles de qualité des données ». De plus, les contrôles de la qualité des données peuvent devenir inutiles si les données ne sont plus utilisées ou si leur définition a changé.

Classes de règles de qualité des données

Les règles de qualité des données peuvent être classées en fonction du type de test.

• Contrôle de la qualité des données. Le cas "normal", la vérification des données dans une couche d'entrepôt de données (voir Figure 1) soit dans une table, soit dans un ensemble de tables.
• Réconciliation. Règles qui vérifient si les données ont été correctement transportées entre les couches de l'entrepôt de données (voir Figure 1). Ces règles sont principalement utilisées pour vérifier la dimension DQ de "Complétude". Le rapprochement peut utiliser une seule ligne ou une approche résumée. La vérification des lignes individuelles est beaucoup plus granulaire, mais vous devrez reproduire les étapes de transformation (filtrage des données, modifications des valeurs des champs, dénormalisation, jointures, etc.) entre les couches comparées. Plus vous ignorez de couches, plus la logique de transformation doit être implémentée. Par conséquent, il est judicieux d'effectuer un rapprochement entre chaque couche et son prédécesseur au lieu de comparer la mise en scène à la couche du magasin de données. Si des transformations doivent être implémentées dans les règles de réconciliation, utilisez la spécification, pas le code de l'entrepôt de données ! Pour un rapprochement résumé, recherchez des champs significatifs (par exemple, résumé, nombre de valeurs distinctes, etc.).
• Surveillance. Un entrepôt de données contient généralement des données historiques et est chargé avec des extraits delta de données opérationnelles. Il y a le danger d'un écart qui se creuse lentement entre l'entrepôt de données et les données opérationnelles. La construction de séries chronologiques résumées de données permet d'identifier des problèmes comme celui-ci (par exemple, comparer les données du mois dernier avec les données du mois en cours). Les utilisateurs de données ayant une bonne connaissance de leurs données peuvent fournir des mesures et des seuils utiles pour les règles de surveillance.

Comment quantifier un problème de qualité des données

Une fois que vous avez défini ce qu'il faut vérifier, vous devrez spécifier comment quantifier les problèmes identifiés. Des informations telles que "cinq lignes de données violent la règle DQ avec l'ID 15" n'ont guère de sens pour la qualité des données.

Les pièces suivantes sont manquantes :

• Comment quantifier/compter les erreurs détectées. Vous pouvez compter le « nombre de lignes », mais vous pouvez également utiliser une échelle monétaire (par exemple, l'exposition). Gardez à l'esprit que les valeurs monétaires peuvent avoir des signes différents, vous devrez donc rechercher comment les résumer de manière significative. Vous pouvez envisager d'utiliser les deux unités de quantification (nombre de lignes et synthèse) pour une règle de qualité des données.
• Population. Quel est le nombre d'unités contrôlées par la règle de qualité des données ? "Cinq lignes de données sur cinq" a une qualité différente de "cinq sur 5 millions". La population doit être mesurée en utilisant la ou les mêmes quantifications que pour les erreurs. Il est courant d'afficher le résultat d'une règle de qualité des données sous forme de pourcentage. La population ne doit pas être identique au nombre de lignes d'une table. Si une règle DQ ne vérifie qu'un sous-ensemble des données (par exemple, uniquement les contrats résiliés dans la table des contrats), le même filtre doit être appliqué pour mesurer la population.
• Définition du résultat. Même si une vérification de la qualité des données détecte des problèmes, cela ne doit pas toujours provoquer une erreur. Pour la qualité des données, un système de feux de signalisation (rouge, jaune, vert) utilisant des valeurs seuils pour évaluer les résultats est très utile. Par exemple, vert : 0-2 %, jaune : 2-5 %, rouge : supérieur à 5 %. Gardez à l'esprit que si les unités utilisateur de données partagent les mêmes règles, elles peuvent avoir des seuils très différents pour une règle donnée. Une unité commerciale de marketing peut ne pas se soucier de la perte de quelques commandes, alors qu'une unité de comptabilité peut se soucier même de quelques centimes. Il devrait être possible de définir des seuils en pourcentage ou en chiffres absolus.
• Collectez des exemples de lignes d'erreur. Il est utile qu'une règle de qualité des données fournisse un échantillon des erreurs détectées. Normalement, les clés (métier !) et les valeurs de données vérifiées sont suffisantes pour permettre d'examiner l'erreur. Il est judicieux de limiter le nombre de lignes d'erreur écrites pour une règle de qualité des données.
• Parfois, vous pouvez trouver des « erreurs connues » dans les données qui ne seront pas corrigées, mais qui sont détectées par des contrôles utiles de la qualité des données. Dans ces cas, l'utilisation de listes blanches (clés d'enregistrements qui doivent être ignorées lors d'un contrôle de la qualité des données) est recommandée.

Autres métadonnées

Les métadonnées sont importantes pour acheminer « l'analyse » et surveiller les phases de la boucle de contrôle de la qualité des données.

• Articles cochés. Il est utile d'affecter les tables et champs cochés à une règle de qualité des données. Si vous disposez d'un système de métadonnées amélioré, cela peut aider à affecter automatiquement des utilisateurs de données et un propriétaire de données à cette règle. Pour des raisons réglementaires (telles que BCBS 239), il est également nécessaire de prouver comment les données sont vérifiées par DQ. Cependant, l'attribution automatique de règles aux utilisateurs/propriétaires de données via le lignage des données (*) peut être une épée à double tranchant (voir ci-dessous).
• Utilisateur de données. Chaque règle DQ doit avoir au moins un utilisateur de données/unité d'utilisateur de données assigné pour vérifier le résultat pendant la phase "Analyser" et décider si et comment une découverte influence leur travail avec les données.
• Propriétaire des données. Chaque règle DQ doit avoir un propriétaire de données assigné.

(*) Le lignage des données montre le flux de données entre deux points. Avec le lignage des données, vous pouvez trouver tous les éléments de données influençant un champ cible donné au sein de votre entrepôt.

L'utilisation du lignage des données pour affecter des utilisateurs à des règles peut être problématique. Comme mentionné précédemment, les utilisateurs professionnels ne connaissent généralement que la couche data mart (et le système d'exploitation), mais pas les niveaux inférieurs de l'entrepôt de données. En mappant via la lignée des données, les utilisateurs de données se verront attribuer des règles avec lesquelles ils ne sont pas familiers. Pour les niveaux inférieurs, le personnel informatique peut être nécessaire pour évaluer une constatation de qualité des données. Dans de nombreux cas, un mappage manuel ou une approche mixte (cartographie via le lignage des données uniquement dans le magasin de données) peut aider.

Mesurer la qualité des données

Mesurer la qualité des données signifie exécuter les règles de qualité des données disponibles, ce qui devrait être fait automatiquement , déclenché par les processus de chargement de l'entrepôt de données. Comme nous l'avons vu précédemment, il peut y avoir un nombre remarquable de règles de qualité des données, de sorte que les vérifications prendront du temps.

Dans un monde parfait, un entrepôt de données ne serait chargé que si toutes les données sont sans erreur. Dans le monde réel, c'est rarement le cas (en réalité, ce n'est presque jamais le cas). Selon la stratégie de chargement globale de votre entrepôt de données, le processus de qualité des données doit ou non (ce dernier est beaucoup plus probable) régir le processus de chargement. C'est une bonne conception d'avoir des processus de qualité des données (réseaux de travail) parallèles et liés aux processus de chargement de l'entrepôt de données "réguliers".

S'il existe des accords de niveau de service définis, veillez à ne pas contrecarrer les charges de l'entrepôt de données avec les contrôles de qualité des données. Les erreurs/abends dans les processus de qualité des données ne doivent pas arrêter le processus de chargement normal. Les erreurs inattendues dans les processus de qualité des données doivent être signalées et affichées pour la phase « Analyse » (voir le chapitre suivant).

Gardez à l'esprit qu'une règle de qualité des données peut se bloquer en raison d'erreurs inattendues (peut-être que la règle elle-même a été mal implémentée ou que la structure de données sous-jacente a changé au fil du temps). Il serait utile que votre système de qualité des données fournisse un mécanisme pour désactiver ces règles, surtout si votre entreprise a peu de versions par an.

Les processus DQ doivent être exécutés et signalés le plus tôt possible , idéalement juste après le chargement des données vérifiées. Cela permet de détecter les erreurs le plus tôt possible lors du chargement de l'entrepôt de données (certains chargements complexes du système d'entrepôt ont une durée de plusieurs jours).

Analyser

Dans ce contexte, « analyser » signifie réagir aux résultats de la qualité des données. Il s'agit d'une tâche pour les utilisateurs de données affectés et le propriétaire des données.

La manière de réagir doit être clairement définie par votre projet de qualité des données. Les utilisateurs de données devraient être obligés de commenter une règle avec des résultats (au moins des règles avec un feu rouge), expliquant quelles mesures sont prises pour gérer le résultat. Le propriétaire des données doit être informé et doit décider avec le ou les utilisateurs des données.

Les actions suivantes sont possibles :

• Problème sérieux : le problème doit être résolu et le chargement des données répété.
• Le problème est acceptable : essayez de le résoudre pour les futurs chargements de données et gérez le problème dans l'entrepôt de données ou le reporting.
• Règle DQ défectueuse : corrigez la règle DQ problématique.

Dans un monde parfait, tous les problèmes de qualité des données seraient résolus. Cependant, le manque de ressources et/ou de temps entraîne souvent des solutions de contournement.

Pour pouvoir réagir à temps, le système DQ doit informer les utilisateurs de données de « leurs » règles avec des résultats. L'utilisation d'un tableau de bord de qualité des données (peut-être avec l'envoi de messages indiquant que quelque chose est arrivé) est une bonne idée. Plus tôt les utilisateurs sont informés des résultats, mieux c'est.

Le tableau de bord de la qualité des données doit contenir :

• Toutes les règles affectées à un rôle donné
• Les résultats des règles (feux de signalisation, mesures et exemples de lignes) avec la possibilité de filtrer les règles par résultat et domaine de données
• Un commentaire obligatoire que les utilisateurs de données doivent entrer pour les résultats
• Une fonctionnalité pour éventuellement "annuler" le résultat (si la règle de qualité des données signale des erreurs dues à une implémentation défectueuse, par exemple). Si plusieurs unités commerciales se voient attribuer la même règle de qualité des données, la « dérogation » n'est valable que pour l'unité commerciale de l'utilisateur des données (et non pour l'ensemble de l'entreprise).
• Affichage des règles qui n'ont pas été exécutées ou qui ont été abandonnées

Le tableau de bord doit également afficher l'état actuel du processus de chargement récent de l'entrepôt de données, offrant aux utilisateurs une vue à 360 degrés du processus de chargement de l'entrepôt de données.

Le propriétaire des données est chargé de s'assurer que chaque résultat a été commenté et que l'état de la qualité des données (original ou annulé) est au moins jaune pour tous les utilisateurs de données.

Pour un aperçu rapide, il serait utile de créer une sorte de KPI (indicateurs clés de performance) simples pour les utilisateurs/propriétaires de données. Avoir un feu de circulation global pour les résultats de toutes les règles associées est assez facile si chaque règle a le même poids.

Personnellement, je pense que le calcul d'une valeur globale de la qualité des données pour un domaine de données donné est plutôt complexe et a tendance à être cabalistique, mais vous pouvez au moins montrer le nombre de règles globales regroupées par résultat pour un domaine de données (par exemple, "100 règles DQ avec 90 % de vert, 5 % de jaune et 5 % de rouge »).

Il incombe au propriétaire des données de s'assurer que les résultats seront corrigés et que la qualité des données sera améliorée.

Amélioration des processus

Comme les processus d'entrepôt de données changent souvent, le mécanisme de qualité des données doit également être entretenu.

Un propriétaire de données doit toujours veiller aux points suivants :

• Tenez-le à jour. Les modifications apportées à l'entrepôt de données doivent être saisies dans le système de qualité des données.
• Améliorer. Implémentez de nouvelles règles pour les erreurs qui ne sont pas encore couvertes par les règles de qualité des données.
• Rationaliser. Désactivez les règles de qualité des données qui ne sont plus nécessaires. Consolidez les règles qui se chevauchent.

Surveillance des processus de qualité des données

Le suivi de l'ensemble du processus de qualité des données permet de l'améliorer au fil du temps.

Les choses à regarder seraient :

• La couverture de vos données avec des règles de qualité des données
• Le pourcentage de résultats de qualité des données dans les règles actives au fil du temps
• Le nombre de règles de qualité des données actives (Gardez un œil dessus, j'ai vu des utilisateurs de données résoudre leurs problèmes en désactivant simplement de plus en plus de règles de qualité des données.)
• Le temps nécessaire dans un chargement de données pour que tous les résultats soient notés et corrigés

Conclusion

Bon nombre des points suivants sont importants dans tout type de projet.

Anticipez la résistance. Comme nous l'avons vu, s'il n'y a pas de problème de qualité urgent, la qualité des données est souvent considérée comme une charge supplémentaire sans offrir de nouvelles fonctionnalités. Gardez à l'esprit que cela peut créer une charge de travail supplémentaire pour les utilisateurs de données. Dans de nombreux cas, la conformité et les exigences réglementaires peuvent vous aider à convaincre les utilisateurs de la considérer comme une exigence incontournable.

Trouvez un parrain. Comme indiqué ci-dessus, DQ n'est pas un article qui se vend rapidement, donc un sponsor/partie prenante puissant est nécessaire - plus haut dans la direction, mieux c'est.

Trouvez des alliés. Comme pour le sponsor, toute personne partageant l'idée d'une qualité de données solide serait très utile. La boucle de circuit DQ est un processus continu et a besoin de personnes pour maintenir la boucle de circuit en vie.

Commencer petit. S'il n'y a pas eu de stratégie DQ jusqu'à présent, recherchez une unité commerciale qui a besoin d'une meilleure qualité de données. Construisez un prototype pour leur montrer l'avantage de meilleures données. Si votre tâche est d'améliorer ou même de remplacer une stratégie de qualité des données donnée, regardez ce qui fonctionne bien/est accepté dans l'organisation et conservez-le.

Ne perdez pas de vue l'ensemble du tableau. Bien que commençant petit, gardez à l'esprit que certains points, en particulier les rôles, sont des conditions préalables à une stratégie DQ réussie.

Une fois mis en place, ne lâchez rien. Le processus de qualité des données doit faire partie de l'utilisation de l'entrepôt de données. Au fil du temps, l'accent mis sur la qualité des données a tendance à se perdre un peu, et c'est à vous de le maintenir.