Un de nos clients qui gère plusieurs milliards de dollars de budget et de projet par ans a transformé son entrepôt de données de simple indicateurs fixes construits par les programmeurs à un environnement d'exploitation libre exploité par les utilisateurs comme les comptables, les responsables des budgets, les agents etc. L'entrepôt de données du client contient une masse de données intéressantes mais sous-exploitées. Trois problèmes majeures causaient son sous-utilisation: l'architecture de données, l'absence de couche sémantique en langage d'affaires et l'outil d'exploitation qui était orienté programmeur.
L'architecture de données ouverte et simple
L'architecture de données est primordiale dans un entrepôt de données. Elle permet l'accès aux données de façon simple et performante. L'apport le plus important de l'architecture de données est le résultat de l'extraction des données des systèmes opérationnels pour les rendre disponibles à l'utilisateur en schéma étoile (Article: Qu'est-ce qu'un modèle étoilé) . Même si le modèle de données obtenu dans un entrepôt de données est simple, des schémas en étoile, la façon d'y arriver nécessite des connaissances qui sont très différentes de celles utilisées pour la construction de systèmes transactionnels. Il est donc important de vous adjoindre une équipe qui maîtrise les techniques et les meilleures pratiques propres aux entrepôts de données.
Bien que notre client ait une masse de données intéressantes les données n'étaient pas structurées pour en faciliter l'accès. Les données étaient regroupées en cubes isolés (silo). Plusieurs de ces cubes étaient très similaires et répliquaient les données sans apporter d'avantage aux utilisateurs. La sous exploitation des données était due aux limitations des cubes (et non de l'outil BI). Les cubes étaient d'abord limités par le volume de données et limités par le nombre d'axes d'analyse disponibles dans un même cube. En plus d'une architecture d'entrepôt de données déficiente, le moindre changement organisationnel (réorganisation ministériel) devenait un casse-tête et devait être répercuté dans cette multitude de cubes rendant les rapports caduques et augmentant considérablement les délais de livraisons et les coûts d'entretien.
La première tâche a été de redresser l'architecture de données et de la corriger afin d'utiliser les dimensions conformes et des tables de faits, d'un schéma étoile, performantes et facilement compréhensibles pour l'utilisateur. Par exemple, la structure ministérielle est définie dans une table commune qui est utilisée pour tous les produits informationnels. Les cubes (silo MOLAP) ont été éliminés et regroupés dans des schémas étoiles intégrés (ROLAP) décuplant ainsi la force d'analyse et les possibilités de construction de produits informationnels pour les utilisateurs. En quelques semaines l'équipe d'affaires a élaboré des dizaines de produits informationnels qui auraient été livrés en plusieurs mois par une équipe de programmeurs. Par exemple, la livraison d'un nouveau rapport était évaluée à 180 jours par l'équipe de développement a été réalisé en une journée par l'équipe d'affaires avec l'outil d'exploitation libre basé sur le modèle étoilé. Ceci étant dit, l'apport de l'équipe de développement demeure primordial entre autre pour la construction de l'ETL performant et l'obtention du schéma étoile qui demande des connaissances en programmation et en intelligence d'affaires ( BI : business Intelligence). L'utilisateur connaît ses besoins qui sont en perpétuels évolutions sans compter les demandes ad-hoc c'est donc dans la construction des rapports avec des outils conçus pour l'utilisateur que son apport est maximal.
La couche logique intégrée en langage d'affaires
Le second problème qui causait la sous exploitation de l'entrepôt de données de notre client était l'absence de couche sémantique intégré en langage d'affaires. Les définitions d'affaires étaient éparpillées et dupliquées dans les cubes et autres outils. Pour créer de nouveaux rapports ou répondre à des demandes ad-hoc les utilisateurs devaient utiliser des cubes partiels construits en silo, ou construire des requêtes de programmation SQL ou demander la programmation des rapports dans des outils comme MS-Excel. Ce que très peu d'utilisateur pouvaient réaliser. Il était donc obligatoire de présenter toutes les nouvelles demandes de produits informationnels ou demande ad-hoc à une équipe de développeur. Étant donné que le temps pour réaliser les produits informationnels par le programmeur était long, l'utilisateur avait déjà utilisé des solutions alternatives et avait répondu à ses questions... et en avait de nouvelles...
La couche logique intégrée en langage d'affaires est primordiale dans un environnement maximisant l'apport de l'utilisateur. Cette couche permet de traduire les éléments du langage informatique au langage utilisateur d'affaires. Sans cette couche l'utilisateur doit avoir des connaissances informatiques pour construire ses rapports et produits informationnels. Tous les produits BI orientés utilisateurs possèdent une couche logique intégrée en langage d'affaires par exemple OBIEE d'Oracle avec sa couche sémantique ou Oracle Discoverer avec son EUL, Business Object avec ses univers, Microstrategy et même IBM Cognos qui a ajouté ses paquetages dans ses plus récentes versions. Pour les grandes organisations qui ont des volumes de données important, il est important que cette couche ne soit pas seulement basée sur des cubes épars (MOLAP) mais sur les schémas étoiles de la base de données (ROLAP). Les plus petites organisation pourront baser leur solution sur des cubes MOLAP à condition qu'ils ne doivent pas scinder les cubes à cause du volume de données. Les produits qui n'ont pas de couche sémantique intégrée ou qui utilise seulement des cubes peuvent être un bon choix lorsque les produits informationnels sont peu nombreux et sont élaborés seulement par des programmeurs ou pour d'autres circonstances spécifiques.
La couche logique intégrée en langage d'affaires offre un environnement de données structurées et intégrée pour l'ensemble de l'organisation. Elle permet en plus d'ajouter une couche supplémentaire de sécurité à la base de données mais cette fois-ci géré par l'utilisateur.
Nous avons donc implanté une couche logique en langage d'affaires qui permet à l'utilisateur de créer ses produits informationnels.
Outil de construction de rapports orienté pour les utilisateurs
Le troisième problème qui causait la sous exploitation de l'entrepôt de données de notre client était l'outil d'exploitation des rapports et produits informationnels. L'outil choisi par notre client était un bon outil dans le contexte où l'organisation qui l'acquiert dispose d'un grand nombre de programmeurs en permanence. Les démonstrations de l'outil des représentants et disponibles sur internet frisait le maquillage. Mais lorsqu'on gratte un peu les limitations apparaissent rapidement pour les utilisateurs. L'outil permettait de belle présentation mais n'était pas orienté utilisateur.
Un outil de développement de rapports orienté utilisateur permet à l'utilisateur de créer ses rapports, indicateurs et autres produits informationnels sans avoir de notion de programmation. Il permet aussi de les déployer lui-même sur son portail ou sur sa plateforme mobile.
L'utilisation d'outil d'exploitation libre est aussi avantageuse pour les TI. Elle permet de libérer les ressources des directions informatiques (TI). L'apport des utilisateurs est maximisé leur assurant une grande autonomie dans l'exploitation de l'entrepôt de données et dans la construction des dizaines de rapports ministériels ou corporatifs, des centaines demandes ad-hoc, tableaux de bord et autres produits informationnels.
Nous avons donc installé un outil d'exploitation libre orienté utilisateur. Cet outil est basé sur la couche logique intégrée en langage affaires et non directement sur les bases de données ou des cubes construit en silo. Ceci a permis la contribution maximale des spécialistes de domaines et des utilisateurs. Ils ont rapidement créés des rapports ministériels standards. Ces rapports ont pu être distribués au niveau provincial, dans les directions territorial et les directions générales. Ces directions ont pu les personnaliser et les paramétrer eux même selon les besoins de leurs utilisateurs. Ces rapports standards permettent aux directions régionales d'échanger une information standardisée à l'ensemble de la province et pour les directions générale du ministère.
Selon l'expérience de PanoramaTechnologies avec ses clients et une étude exhaustive de plusieurs produits BI nous avons constaté que les spécifications suivantes sont des atouts majeurs d'un outil BI afin de permettre l'exploitation maximale par les utilisateurs:
- La couche sémantique en langage d'affaires intégrés orienté utilisateur;
- Outil de développement de rapports, indicateur orienté utilisateur
- Outil de construction de portails orienté utilisateur
Gartner confirme la prise en charge des environnements BI par les utilisateurs dans ses rapports annuels sur les plateformes BI de 2011 et de 2012.
Grâce aux outils orientés utilisateurs disponibles sur le marché, les utilisateurs peuvent devenir les maîtres de l'exploitation libre de l'entrepôt de données. Il libère ainsi les TI de la tâche sans fin de développer des rapports ad hoc et urgents qui sont en constante évolution.
François Bouffard
Architecte BI et analyste d'affaires BI
Panoramatechnologies.com
Aucun commentaire:
Enregistrer un commentaire