Gartner estime que près de 70 à 80% des nouveaux les projets de business intelligence échouent . Cela est dû à une myriade de raisons, du mauvais choix d'outil au manque de communication entre les parties prenantes informatiques et commerciales. Ayant mis en œuvre avec succès des projets de BI dans tous les secteurs, j'espère partager mes expériences dans ce billet de blog et souligner les principales raisons pour lesquelles les projets de Business Intelligence échouent. Cet article présentera des contre-mesures à l'échec basées sur trois principes qui devraient régir la construction des entrepôts de données. Suivre ces concepts d'entrepôt de données devrait vous aider en tant que développeur d'entrepôt de données à naviguer dans le processus de développement en évitant les nids-de-poule courants ou même les gouffres des implémentations de BI.
Bien que les critères d'un entrepôt de données décisionnel réussi varient selon le projet, certains minimums sont attendus et requis pour tous les projets. Voici une liste des principaux attributs généralement trouvés dans un entrepôt de données de Business Intelligence performant:
Grâce à mon expérience dans la création de solutions réussies, et peut-être plus important encore, à mon implication dans des projets qui ont échoué, je suis arrivé à la conclusion que trois principes clés sont primordiaux pour augmenter les chances de réussite de la mise en œuvre d'un système de veille stratégique. Cependant, avant de les aborder en détail, commençons par un peu de contexte.
Avant de plonger dans différents concepts d'entrepôt de données, il est important de comprendre ce qu'est réellement un entrepôt de données.
Les entrepôts de données sont souvent considérés comme des systèmes de veille stratégique créés pour répondre aux besoins quotidiens de reporting d'une entité commerciale. Ils n'ont pas les mêmes exigences de performances en temps réel (dans les implémentations standard) que les systèmes de données OLTP, et alors que les systèmes OLTP ne contiendront que les données relatives à un petit sous-ensemble de l'entreprise, les entrepôts de données cherchent à englober toutes les données relatives à l'entreprise .
Les modèles d'entrepôt de données n'offrent des avantages à une entreprise que lorsque l'entrepôt est considéré comme le hub central de «toutes les données» et pas seulement comme un outil grâce auquel vos rapports opérationnels sont produits. Tous les systèmes opérationnels doivent avoir une communication bidirectionnelle avec l'entrepôt de données pour alimenter les données et recevoir des commentaires sur la manière d'améliorer l'efficacité opérationnelle. Tout changement commercial, tel qu'une augmentation des prix ou une réduction de l'offre / de l'inventaire, doit d'abord être prototypé et prévu dans votre environnement d'entrepôt de données afin que votre entreprise puisse prévoir et quantifier de manière fiable le résultat. Dans ce contexte, tous science des données et analyse de données les fonctions seraient centrées autour de l'entrepôt de données.
Il existe de nombreux composants d'un entrepôt de données, et ce n'est pas simplement une base de données:
Voici une représentation plus visuelle de la différence entre une base de données et une structure d'entrepôt de base de données. Les bases de données ou les nouveaux méta-magasins de données logiques tels que Hive forment l'étoile centrale du système stellaire d'un entrepôt de données, avec tous les autres composants en tant que planètes en rotation. Cependant, contrairement à un système en étoile, un entrepôt de données peut avoir une ou plusieurs bases de données et ces bases de données doivent être interchangeables avec les nouvelles technologies, comme nous le verrons plus loin dans l'article.
Les entrepôts de données ne sont utiles et précieux que dans la mesure où les données qu'elles contiennent sont approuvées par les parties prenantes de l'entreprise. Pour garantir cela, des cadres qui capturent automatiquement et corrigent (si possible) les problèmes de qualité des données doivent être construits. Le nettoyage des données doit faire partie du processus d'intégration des données avec des audits de données réguliers ou un profilage des données est effectué pour identifier tout problème de données. Bien que ces mesures proactives soient mises en œuvre, vous devez également envisager des mesures réactives lorsque de mauvaises données glissent ces portes et sont signalées par l'utilisateur.
Pour garantir la confiance des utilisateurs dans le système d'entrepôt de données, toutes les mauvaises données mises en évidence par les utilisateurs professionnels doivent être examinées en priorité. Pour contribuer à ces efforts, des cadres de lignage et de contrôle des données doivent être intégrés à la plate-forme pour garantir que tout problème de données puisse être identifié et résolu rapidement par le personnel d'assistance. La plupart des plates-formes d'intégration de données intègrent un certain degré de solutions de qualité des données, telles que DQS dans MS SQL Server ou IDQ dans Informatica.
Tirez parti de ces plates-formes intégrées si vous utilisez un outil commercial dans vos pipelines d'intégration de données, mais en plus ou autrement, assurez-vous de créer les mécanismes qui vous aideraient à maintenir la qualité de vos données. Par exemple, la plupart des outils d'intégration de données ne disposent pas de bonnes fonctionnalités pour suivre le lignage des données. Pour surmonter cette limitation, une infrastructure de contrôle par lots personnalisée peut être créée à l'aide d'une série de tables de contrôle pour suivre chaque flux de données qui se produit dans le système.
Il est très difficile de regagner la confiance des parties prenantes de votre entreprise si elles rencontrent une mauvaise qualité au sein de votre plate-forme, de sorte que l'investissement initial dans les cadres de qualité des données devrait en valoir le coût.
Cette figure illustre la division des efforts dans la mise en œuvre et l'utilisation de la plupart des entrepôts de données.
La plupart des efforts sont investis dans la construction et la maintenance de l'entrepôt, tandis que la valeur ajoutée d'un entrepôt pour l'analyse commerciale représente une part beaucoup plus petite de l'effort. C'est une autre raison pour laquelle les projets de Business Intelligence échouent souvent. Parfois, il faut trop de temps dans le cycle du projet pour montrer une valeur significative au client, et lorsque le système est enfin en place, il faut encore beaucoup d'efforts informatiques pour en tirer une valeur commerciale. Comme nous l'avons dit dans l'introduction, la conception et le déploiement de systèmes de veille stratégique peuvent être un processus long et coûteux. Par conséquent, les parties prenantes s'attendront à juste titre à commencer rapidement à récolter la valeur ajoutée de leurs efforts d'intelligence d'affaires et d'entreposage de données. Si aucune valeur ajoutée ne se matérialise, ou si les résultats sont tout simplement trop tardifs pour avoir une valeur réelle, rien ne les empêche de tirer le bouchon.
Le deuxième principe du développement de l'entrepôt de données est de retourner le triangle comme illustré ici.
Votre choix d'outils de veille économique et les cadres que vous mettez en place doivent garantir qu'une plus grande partie des efforts consacrés à l'entrepôt consiste à extraire de la valeur commerciale plutôt qu'à la créer et à la maintenir. Cela garantira des niveaux élevés d'engagement de la part des parties prenantes de votre entreprise, car elles verront immédiatement la valeur d'investir dans le projet. Plus important encore, vous permettez à l'entreprise d'être autonome extraction de valeur sans avoir une si forte dépendance à l’informatique.
Vous pouvez adhérer à ce principe en suivant des méthodologies de développement incrémentielles lors de la construction de l'entrepôt pour vous assurer de fournir les fonctionnalités de production le plus rapidement possible. Suivre la stratégie de data mart de Kimball ou Data Vault de Linstedt Les méthodologies de conception d'entrepôt de données vous aideront à développer des systèmes qui se construisent progressivement tout en tenant compte du changement en douceur. Utilisez une couche sémantique dans votre plate-forme telle qu'un cube MS SSAS ou même un univers Business Objects pour fournir une interface métier facile à comprendre à vos données. Dans le cas du premier, vous offrirez également un mécanisme simple permettant aux utilisateurs d'interroger des données à partir d'Excel, toujours l'outil d'analyse de données le plus populaire.
Incorporer des outils BI qui défendent la BI en libre-service tels que Tableau ou PowerBI ne fera qu'améliorer l'engagement des utilisateurs, car l'interface pour interroger les données est désormais considérablement simplifiée par opposition à l'écriture de SQL.
Stockage des données source dans un lac de données avant de remplir une base de données, cela aidera à exposer les données sources aux utilisateurs très tôt dans le processus d'intégration. Au moins les utilisateurs avancés tels que les utilisateurs professionnels pourront désormais digérer les données source (via les fichiers bruts) en connectant des outils tels que Hive / Impala au-dessus des fichiers. Cela aidera à réduire le temps nécessaire à l'entreprise pour analyser un nouveau point de données de plusieurs semaines à plusieurs jours, voire des heures.
barrières dans la communication interculturelle
Les données sont sur le point de devenir l'équivalent numérique du pétrole. Ces dernières années, nous avons assisté à une explosion du nombre d’outils pouvant être utilisés dans le cadre d’une plate-forme d’entrepôt de données et du taux d’innovation. Les myriades d'outils de visualisation disponibles à l'heure actuelle, avec des options avancées pour les back-ends, sont en tête. Compte tenu de cet environnement et de la propension des exigences commerciales à changer constamment, il est important de garder à l'esprit que vous auriez besoin d'échanger des composants de votre pile technologique ou même d'en introduire / supprimer d'autres avec le temps, selon les changements commerciaux et technologiques.
Sur la base de l'expérience personnelle, il serait chanceux qu'une plate-forme puisse durer 12 mois sans une sorte de changement significatif. Un effort raisonnable est inévitable dans ces situations; cependant, il devrait toujours être possible de changer de technologie ou de conception, et votre plate-forme devrait être conçue pour répondre à ce besoin éventuel. Si le coût de migration d'un entrepôt est trop élevé, l'entreprise pourrait simplement décider que le coût n'est pas justifié et abandonner ce que vous avez construit au lieu de chercher à migrer la solution existante vers de nouveaux outils.
Construire un système qui répondrait à tout les besoins futurs imaginables sont impossibles. Par conséquent, un certain niveau d'appréciation du fait que tout ce que vous concevez et construisez maintenant pourrait être remplacé avec le temps est nécessaire lors de la construction d'entrepôts de données. À cette fin, je recommanderais l’utilisation d’outils et de conceptions génériques lorsque cela est possible, plutôt que de coupler étroitement votre plate-forme aux outils sur lesquels elle fonctionne. Bien sûr, cela doit être fait après une planification et une considération minutieuses, car la puissance de nombreux outils, en particulier les bases de données, réside dans leur individualité et leur complémentarité.
Par exemple, les performances ETL sont considérablement améliorées lors de l'utilisation de procédures stockées dans une base de données pour créer de nouvelles données d'analyse commerciale, par opposition à l'extraction et au traitement des données en dehors de la base de données à l'aide de Python ou SSIS. En ce qui concerne la couche de rapport, les outils de visualisation offriraient certaines fonctionnalités qui ne sont pas facilement disponibles dans d'autres. Par exemple, Power BI prend en charge les requêtes MDX personnalisées, mais pas Tableau. Mon propos n’est pas de préconiser l’abandon des procédures stockées ou l’évitement des cubes SSAS ou de Tableau dans vos systèmes. Mon intention est simplement de promouvoir l'importance d'être conscient pour justifier toute décision de coupler étroitement votre plate-forme à ses outils.
Un autre gouffre potentiel est dans la couche d'intégration. Il est très facile d’utiliser un outil tel que SSIS pour votre intégration de données en raison de ses capacités de débogage ou de sa facilité d’utilisation avec la plate-forme SQL Server. Cependant, la migration de centaines de packages SSIS vers un autre outil deviendrait un projet très coûteux. Dans les cas où vous faites principalement «EL», cherchez à utiliser un outil générique pour faire votre traitement. L'utilisation d'un langage de programmation comme Python ou Java pour écrire un chargeur générique pour charger votre couche intermédiaire vous aidera à réduire le nombre de packages SSIS individuels dont vous auriez besoin autrement. Cette approche permet non seulement de réduire les coûts de maintenance et de migration future, mais aussi d'automatiser davantage d'aspects du processus d'intégration des données sans avoir à écrire de nouveaux packages individuels (en lien avec le principe 2).
Dans tous ces cas, vous devez décider d'un compromis pratique entre les bénéfices immédiats et les futurs coûts de migration pour garantir que l'entrepôt ne sera pas mis au rebut parce qu'il ne peut pas gérer le changement ou parce que le changement aurait nécessité trop de temps, d'efforts ou d'investissements.
Il existe de nombreuses raisons pour lesquelles un système de veille stratégique peut échouer, et il existe également des oublis courants qui peuvent conduire à une défaillance éventuelle. Le paysage technologique en constante évolution, le budget limité pour les systèmes de données en raison de la priorité secondaire erronée des systèmes opérationnels, et la complexité et la difficulté de travailler avec des données signifient qu'un examen attentif non seulement des objectifs immédiats mais également des plans futurs doit être effectué lors de la conception et construire les composants d'un entrepôt de données.
Les principes fondamentaux de l'entreposage de données décrits dans cet article sont destinés à vous guider lors de ces considérations importantes. Bien sûr, la prise en compte de ces principes ne garantit pas le succès, mais ils vous aideront certainement à éviter l'échec.
Les développeurs d'entrepôt de données ou plus communément appelés maintenant ingénieurs de données sont responsables du développement global et de la maintenance de l'entrepôt de données. Ce serait à eux de décider de la pile technologique ainsi que des cadres et du traitement personnalisés et de préparer les données pour les consommateurs.
L'utilisation de diverses technologies signifie que la plupart des entrepôts de données sont très différents les uns des autres. Un exemple de base consisterait en une base de données de serveur SQL, avec SSIS formant la couche d'intégration de données, et Power BI et SSRS se trouvant au-dessus de la base de données pour répondre aux exigences de visualisation et de création de rapports.
Un entrepôt de données est constitué d'une myriade d'outils et de cadres fonctionnant de manière holistique pour préparer les données à obtenir des informations. Au cœur d'un entrepôt de données se trouve une base de données ou un méta-stockage logique de données avec un cadre d'intégration de données constituant l'épine dorsale.
Les entrepôts de données fournissent le mécanisme permettant à une organisation de stocker et de modéliser toutes ses données provenant de différents départements dans une structure cohérente. À partir de là, divers consommateurs des données de votre entreprise peuvent être servis, à la fois internes et externes. Un entrepôt de données est capable d'être la seule source de vérité.