Les projets de datawarehousing sont parmi les initiatives les plus visibles et les plus coûteuses qu’une organisation peut entreprendre.

Malheureusement, ils sont aussi parmi les plus susceptibles d’échouer. En raison de la taille de l’investissement (temps et argent) nécessaire, le succès d’un tel projet peut faire le succès ou l’échec d’une carrière. Par conséquent, il est important de comprendre pourquoi les projets datawarehousing échouent.

Alors pourquoi les projets datawarehousing échouent ?

Dans mes années en tant que consultant d’entrepôt de données, j’ai été appelé dans différents contextes difficiles, voir des projets en échecs, bien que le contexte ne soit jamais identique, je trouve qu’il y a des thèmes communs dans ces projets qui ne dépassent rarement la ligne d’arrivée. Comprendre pourquoi les projets d’entrepôt de données échouent est essentiel afin d’éviter ces erreurs courantes.

Ci-dessous, j’ai rassemblé neuf des attributs les plus courants que j’ai trouvés dans des initiatives infructueuses de datawarehousing.

Ne pas répondre à la grande question : pourquoi ?

Pourquoi mettons nous en place un datawarehouse ? , la réponse à la question du « pourquoi ?» devrait être connue de toutes les personnes concernées, pas seulement les décideurs et ceux qui signent les chèques pour les payer. J’ai vu beaucoup trop de cas où des membres du personnel – en particulier des techniciens – sont chargés de faire quelque chose sans comprendre comment cela s’inscrit dans l’objectif globale. Chaque participant, de l’architecte à l’analyste commercial, du chef de projet au testeur, doit comprendre les objectifs les enjeux, et les grandes lignes du projet.

Utiliser l’approche du tout ou rien :

Un entrepôt de données est beaucoup plus qu’une base de données et un processus ETL qui l’alimente. Il s’agit d’une intersection complexe de différentes unités d’affaires, de données de formes différentes provenant de nombreuses sources à des rythmes différents, et de nombreuses mesures et mesures au-dessus de chacune d’entre elles. En bref, un entrepôt de données est une collection de petits projets connexes qui seront développés et testés à différents moments.

Les implémentations les plus réussies que j’ai vues ont toutes impliqué le développement incrémentiel de datamarts. Bien que cette approche prenne une planification plus soignée et une bonne communication, diviser le projet en morceaux plus petits qui peuvent être développés, déployés et testés, a un taux de réussite plus élevé que d’essayer de tout faire en même temps. Le développement incrémental signifie que vos actifs de base sont complétés en premier, ce qui permet de corriger toute erreur ou omission dans la conception avec un impact minimal.

Se faire conseiller par les mauvaises personnes :

Avec l’émergence des nouvelles technologies big data, beaucoup hésitent à choisir la bonne approche et la bonne technologie, et ont peur de s’engager dans un projet de datawarehousing « traditionnel » car de nouvelles technologies sont en train de le remplacer, ils sont également peur de s’engager dans des projets de type Big Data car ils pensent que c’est surdimensionner par rapport à leurs besoins

Une différence essentielle entre l’entrepôt de données et le big data est qu’un entrepôt de données est généralement implémenté dans une seule base de données relationnelle qui sert de magasin central. En revanche, Hadoop et le système de fichiers Hadoop sont conçus pour couvrir plusieurs machines et gérer d’énormes volumes de données qui dépassent les capacités d’une seule machine.

L’écosystème Hadoop ou NoSQL évolue toujours. De nombreux environnements Big Data choisissent des approches hybrides qui couvrent NoSQL, SQL et même les magasins de données NewSQL. De plus, il y a des changements et des améliorations potentielles au moteur de traitement parallèle de MapReduce à l’horizon comme le projet Spark d’Apache. Donc, même si cette histoire est loin d’être terminée, il est sûr de dire que les bases de données relationnelles traditionnelles à serveur unique ou les Appliance de base de données ne sont pas l’avenir des grands volumes données. Mais à partir de quel moment pouvons-nous considérer que nous avons un grand volume et que les bases transactionnelles ne sont pas suffisantes ?

Le principe clé semble être que toutes les données ne sont pas égales, les responsables informatiques doivent donc choisir le stockage des données et le mécanisme d’accès le mieux adapté à l’utilisation des données. Les environnements hybrides peuvent inclure des magasins de valeurs-clés, des bases de données relationnelles, des magasins de graphes, des magasins de documents, des magasins colonnaires, des bases de données XML, des catalogues de métadonnées et autres.

Comme vous pouvez le voir, ce n’est pas vraiment une question simple et ne se prête donc pas bien à une réponse simple. Néanmoins, en général, il faut se faire conseiller par des experts qui ont utilisé les différents uses case afin de vous donner la meilleure approche et que votre projet ne soit pas obsolète ou en répondent plus à vos besoins sur le cours terme.

Commencer directement par coder :

L’outil que vous devriez utiliser le plus au cours des premiers jours d’un projet d’entrepôt de données est un tableau blanc. Tout projet DW commençant par “Construisons des tables !” Ou “Je vais écrire le code ETL !” Est piloté par la mauvaise entité. Il doit être clairement compris que c’est avant tout un projet d’entreprise, pas un projet technique.

Comprendre les besoins de l’entreprise est la première priorité. Ensuite, il s’agit de comprendre les types de questions que l’entreprise va poser sur les données. Coder une solution, même un prototype, est à plusieurs étapes. L’écriture de code ne devrait jamais être la première étape d’un projet d’entrepôt de données.

Déconnexion entre le personnel technique et les parties prenantes

Très souvent, il y a des langues très différentes parlées dans chaque groupe représenté dans un projet d’entrepôt de données. Les techniciens parlent en termes analytiques et fonctionnels. Les analystes parlent de comportements et de flux de travail. Les cadres comprennent les résultats et les résultats de haut niveau. Obtenir ces groupes sur la même page est une tâche essentielle dans ces projets, et c’est aussi l’une des choses les plus difficiles à faire.

La gestion des communications entre les groupes est une constante tout au long du cycle de vie de l’entrepôt de données. Parmi les raisons pour lesquelles les projets d’entrepôt de données échouent, celui-ci est un facteur dans la plupart de ces initiatives échouées. De la collecte des exigences initiales à la définition des attentes, du déploiement à la formation, ceux qui gèrent le projet DW doivent constamment s’assurer que chacun de ces groupes comprend les autres. Des résultats et des livrables au jargon utilisé, il est essentiel de s’assurer que chaque groupe se dirige vers la même ligne d’arrivée.

Raccourcir (ou sauter complètement) les tests et la validation

Lors de mauvais chiffrage d’un projet d’entrepôt de données, les tests et la validation en sont souvent victimes. Un chef de projet inexpérimenté ou un architecte pourrait être attiré par les économies de temps, il va donc couper ou carrément éliminer les tests de validation. Inversement, quelqu’un qui a sauvé un projet qui a échoué en raison de tests inadéquats sait bien que cette partie du projet est aussi critique que toutes les autres.

Il y a des problèmes qui ne peuvent être découverts que par des tests et des validations appropriés. Ceux-ci prennent du temps, mais sont essentiels au succès de l’initiative du datawarehouse.

Passer trop peu de temps sur ETL

La conception, la construction et le test de la logique ETL est la partie la plus longue de chaque projet de datawarehouse. Il est également souvent sous-estimé lors de la planification du projet. Souvent, c’est très complexe la partie transformation de l’ETL est facilement la partie la plus techniquement difficile et laborieuse du projet.

Sauter la formation et la conduite du changement

Lorsque vous déployez un datawarehouse, vous allez changer beaucoup d’habitudes chez les utilisateurs. Vous allez changer la façon dont les utilisateurs professionnels interagissent avec les données depuis des années – voire des décennies ! Bien que la construction d’entrepôts de données demande beaucoup de travail à des techniciens comme nous, apprendre à utiliser le nouvel entrepôt de données demande beaucoup de travail. Une bonne formation peut grandement faciliter cette transition.

Il faut prendre le temps de penser au projet de conduite du changement, dans les grandes entreprises, souvent ce point est négligé ou il se limite à deux ou trois journées de formation pour des personnes clés, Investissez le temps de former le personnel est essentiel. Ne pas simplement livrer une tonne de documentation ; travailler avec les utilisateurs pour s’assurer qu’ils peuvent passer à la nouvelle façon d’accéder aux données. Formez-les en termes qu’ils comprennent, en utilisant n’importe quel moyen (livre de course, vidéo, formation en personne) qui fonctionne pour eux.

L’un des pires résultats potentiels d’un tel projet est que personne n’utilise le nouvel entrepôt de données. Sans une formation adéquate, les consommateurs de données pourraient continuer à faire les choses manuellement. Si l’entrepôt de données n’est pas utilisé, est-ce important que le projet soit un succès technique ?

Négliger la maintenance

Un projet d’entrepôt de données, comme tout projet à vocation évolutive, n’a pas de date de fin. Il y aura certainement une date à laquelle la solution sera mise en service et les ressources consacrées à son développement seront considérablement réduites. Cependant, un entrepôt de données est une chose vivante, nécessitant des soins et une alimentation continue à mesure que les données et les besoins de l’entreprise changent. Ne pas prêter trop d’attention aux besoins continus de l’entrepôt de données peut entraîner un succès à court terme mais un échec à long terme du projet. En moyenne un entrepôt de donnée qui a connu le succès sur le court terme vivra entre 15 et 20 ans, c’est pour dire à quel point la partie maintenance applicative est très importante.

Conclusion

Bien qu’il existe une myriade de raisons pour lesquelles les projets d’entrepôt de données échouent, il existe des thèmes communs dans de nombreuses initiatives de ce type qui échouent. Evitez ces pièges pour avoir une meilleure chance de succès !