10 Jul 2013

10 Jul 2013

Meilleurs pratiques : Gouvernance et Qualité de données dans les projets BI

By:

Category: Uncategorized

Meilleurs pratiques : Gouvernance et Qualité de données dans les projets BI

Il y a quelques jours, l’un de nos utilisateurs  avouait ressentir “le syndrome de la page blanche”, phénomène généralement connu des auteurs mais tendant à s”étendre de plus en plus à la gouvernance des données.

Nous allons, via ce post, vous proposer un certain nombre de tests à réaliser dans un environnement décisionnel.

 

Les bonnes pratiques QualityGates dans les projets BI:

L’illustration suivante démontre les 9 étapes implémentées dans chacun de nos projets. Ces étapes sont plus ou moins complètes selon l’installation effectuée.

BestPractice

Voici les explications pour chacune des étapes:

Etape 1: Obtenir une table de statistiques (“Table Statistic”)

Cette étape permet d’obtenir les tables de statistiques donnant une rapide vue d’ensemble des valeurs, sans effectuer de requêtes. Elle est utile lors de l’exploration de nouvelle table à charger ou après le chargement d’une table dans l’entrepôt de données. Il s’agit de répondre aux questions suivantes:

  • Quel candidat possible pour une clé fonctionnelle ?
  • Existe-t-il des valeurs nulles ou vides ?
  • Combien de valeurs différentes contient une colonne? Il n’est pas utile de charger s’il existe une valeur unique.

 

Etape 2: Entités dupliquées (“Duplicate Entities”)

La plupart des tables contiennent une clé primaire; ce qui n’exclue cependant pas la présence d’entités dupliquées. Un client peut être enregistré plusieurs fois dans le système, sous différentes clés techniques.

Avec QualityGates, vous pourrez:

  • Identifier les clés fonctionnelles dupliquées
  • Valider les clés primaires présentes dans les tables, qui ne représentent pas une contrainte (généralement le cas dans les installations Big Data).
  • Aider à identifier une relation “Parent Enfant” valide (et non 2 parents pour un seul enfant).

 

Etape 3: Existence des données (“Data Existence”)

Ce test permet de vérifier que la donnée source chargée contient bien des valeurs.

Ex: “Je m’attends à avoir au moins une donnée ou plus toute les heures dans le système opérationnel. Dans le cas contraire, je souhaite pouvoir vérifier si le système source fonctionne correctement ou si ma connexion est toujours présente”.

 

Etape 4: Validation des données (“Data Validation”)

Dans de nombreux cas, le système source contient des données erronées (valeurs vides, mauvais format, etc.). Afin de détecter ces anomalies et d’en informer le propriétaire du système source, je vais lancer un test QualityGates. Il permettra ainsi de découvrir:

  • Les valeurs nulles ou vides
  • Les valeurs en dehors de la plage définie (i.e. valeurs négatives)
  • Les valeurs au mauvais format (i.e. Email, code postal)
  • Les valeurs par défaut
  • Les relations entre 2 colonnes différentes. (i.e. lorsque la colonne X possède une certaine valeur, la colonne Y devra avoir une valeur corrélée)

 

Etape 5: Cohérence entre les sources (“Consistency between source”)

Certaines plateformes BI et Entrepôt de données contiennent différentes couches (i.e. Opérationnelle – ERP – ODS – Staging – Entrepôt de données “DataWarehouse” – Datamarts – Cube – etc.). Dans de nombreux cas, les chiffres sont différents selon ces couches pour des raisons variées (la liste est disponible ci-dessous). Ces écarts ne se relèvent souvent qu’au bout de quelques semaines ou mois après la naissance du projet. Afin d’être proactif sur cette problématique, la cohérence entre chaque source doit être validée ainsi que la mise en place d’une alerte toutes les heures, journalière ou hebdomadaire (être alerté lorsque les couches ne sont pas alignées).

Voici les raisons pouvant expliquer ces écarts:

  • Le type de données, différents entre les sources provoquent des différences de valeurs,
  • Le chargement incrémental ou delta n’a pas utilisé la bonne clé – certaines données n’ont pas été chargées,
  • Une mauvaise configuration d’une requête lors du chargement vers une nouvelle source,
  • Une requête ou un cube a un problème d’intégrité référentiel entrainant des pertes de données,
  • Une donnée n’a pas était actualisée dans l’une des sources.

 

Etape 6: Validation des valeurs référentes (“Validating Reference values”)

Comme mentionné plus haut, certaines données présentes dans les tables ont une valeur sans référence dans la table de dimension (i.e. une valeur “Client Id” dans “Sales” n’existe pas dans la dimension “Client”!).

Certains projets disposent de mécanismes pour compléter les valeurs manquantes de référence, mais il existe des cas de valeurs incomplètes pour différentes raisons techniques.

Ces étapes apportent une prise de conscience du problème de l’intégrité référentielle dans les projets et permettent ainsi une action immédiate sans attendre une erreur du Cube ou des valeurs  manquantes dans les rapports.

 

Etape 7: Rejets et Table de Logs

Lorsque je demande aux responsables BI s’ils utilisent des tables de rejets, certains d’entre eux répondent fièrement que oui. Puis je pose habituellement ma deuxième question: “combien de fois contrôlez-vous ces tables ?”. C’est à ce moment que les yeux s’interrogent dans la salle…

C’est le cas aussi pour la table de log qui suppose surveiller différents processus dans le système BI.

La meilleure pratique que nous connaissons est de contrôler ces tables “log” et “rejets” et d’obtenir une alerte lorsque de nouvelles problématiques sont détectées.

nous pouvons aussi contrôler des seuils afin d’obtenir une alerte uniquement s’il dépasse un nombre défini (plus de 10, 20, 100 enregistrements problématiques).
 

Etape 8: Validation des rapports

Cette étape permet de valider les rapports afin que l’utilisateur obtienne les bons chiffres.

Les réunions matinales sont idéales pour connaitre l’état de satisfaction des utilisateurs sur leurs reportings et tableaux de bord.

Les deux principaux retours sont : 1) l’utilisateur a immédiatement identifié les chiffres incorrects (définis en dehors des plages de données attribuées) 2) Une zone ou un produit a soudainement disparu du rapport!

Afin d’éviter ces situations, il est préférable d’utiliser les connaissances de l’utilisateur pour exécuter au moins quelques tests de validation fonctionnelle.

 

Etape 9: Les alertes !

C’est l’étape la plus importante.

Il est primordial que les gestionnaires et développeurs des projets concernés reçoivent les alertes à temps, afin de régler les anomalies avant les utilisateurs Métier.

Ces derniers peuvent également définir des alertes afin d’être informé de la situation en temps réel – cela permet de maintenir les utilisateurs Métier dans le processus et d’accroître leur confiance.
Essayez QualityGates dans votre environnement gratuitement ici