Facteur de succès pour les utilisateurs : Entrepôt de données déployé à l'ensemble du Québec

 

Le comptoir des ressources financières (basé sur des données de SAGIR) de l'entrepôt de données d'un organisme public est déployé dans l'ensemble du Québec. Les données des ressources financières sont disponibles aux employés en mode exploitation libre. Cette réussite confirme la tendance à maximiser l'apport des utilisateurs. Cette tendance est d'ailleurs soulignée par Gartner depuis les dernières années dans l'acquisition d'outils BI.

Grâce au comptoir de données des ressources financières, de l'entrepôt de données, les utilisateurs peuvent consulter des rapports paramétrables selon leur propre direction, leur unité administrative et les années financières qui leur conviennent.

Les utilisateurs peuvent en plus créer leurs propres rapports sans intervention de programmeurs avec les données financières du PGI de SAGIR (ERP EBS Oracle). Tous les segments de la charte comptable sont disponibles. En plus, plusieurs mesures disponibles comme les dépenses réelles, les engagements et le budget ce qui permet de calculer rapidement en un temps donné les montants disponibles pour tous les segments de la charte comptable (Entité, Unité administrative, PSA, Projets, Programme et Type de budget).

Les rapports peuvent être partagés par les utilisateurs en respectant la sécurité de la base de données Oracle sans intervention de programmeur.

Le forage permet aux utilisateurs d'obtenir les détails d'un rapport.

Le comptoir peut avoir un nombre d'enregistrements relativement important variant de 10 à 500 millions d'enregistrements et plus d'une douzaine de dimensions. Les rapports sont lancés directement sur le schéma étoile (ROLAP) avec un délai de réponse de quelques secondes pour les plus lourds ou instantané pour la majorité des cas. Il n'est pas nécessaire d'ajouter une couche de cube (MOLAP) qui a pour effet de créer des silos de données. Ceci permet d'utiliser toutes les dimensions disponibles et d'obtenir le détail directement sur le même comptoir par simple forage sans autres artifices de programmations.

Le comptoir a été construit avec un schéma étoile et des dimensions conformes (plus de détails). L'architecture de données a été critique pour l'acceptation du comptoir par les utilisateurs. Des comptoirs étaient déjà disponibles pour les utilisateurs, mais ils n'étaient pas utilisés. Les anciens comptoirs n'étaient pas intégrés, il y en avait plusieurs qui séparaient les mesures de budget, le réel et l'engagement en Silo. Ils souffraient aussi de problèmes de performance due à l'indexation. Les anciens comptoirs ne permettaient pas de répondre à de simples questions. Par exemple, quel est l'argent disponible (budget - réel - engagement) pour les projets de la région administrative de Montréal à une date précise.

L'interface pour la construction des rapports est orientée pour les utilisateurs et non les programmeurs. Dans le cas présent, le client utilisait encore Oracle Discoverer, bien que cet outil n'est pas le plus moderne son avantage est de permettre aux utilisateurs de développer leurs rapports sans intervention de programmeur et d'utiliser le serveur de base de données sans importer les données sur le poste de travail. Ceci permet d'augmenter considérablement le nombre de rapports disponibles tout en libérant les TI de la pression de construire des rapports qui sont en constantes évolutions. La performance est aussi au rendez-vous et ce peu importe le niveau de détail choisi.

Technologies utilisées: Le logiciel utilisé n'est pas si important, ce qui l'est vraiment est l'architecture de données choisie. L'outil d'exploitation des données pourrait être Cognos, Microstrategy,  ou OBIEE qui sont des outils BI orientés utilisateurs et pouvant exploiter la puissance du ROLAP sur la base de données.

Facteur de succès:
Implication des utilisateurs appuyés par des spécialistes BI d'expérience
Solution orientée utilisateur pour maximiser leur apport
Architecture des données et schéma étoile (Kimball)
Utilisation d'un outil BI orienté utilisateur

Vous désirez en savoir plus sur ce succès et comment le réaliser dans votre entreprise ou votre ministère ? Contactez-nous.

François Bouffard
Architecte d'affaires et architecte BI
francoisbouffard@panoramatechnologies.com
panoramatechnologies.com

Qu'est ce qu'un modèle étoile et les dimensions conformes

Votre directeur veut analyser les ventes de l'entreprise par produit et par mois. Le comptable veut analyser le budget et le comparer aux dépenses réelles par mois et selon les comptes de la charte comptables. En plus, ils veulent ajouter d'autres axes d'analyses comme la ville, le département sans devoir le demander aux informaticiens.

Afin de permettre aux utilisateurs d'exploiter leurs données de façon autonome, Kimball a cré une modélisation des données très simple d'utilisation: le modèle étoile. Le modèle étoile est destiné à l'utilisateur et a deux buts principaux : la simplicité et la performance. Un modèle étoile est une forme de modélisation des données orientée pour les utilisateurs non informaticiens contrairement aux autres formes de modélisations. Elle repose aussi directement sur les bases de données (ROLAP) apportant des avantages comme la récupération de la sécurité, la performance et le nombre illimité d'axes d'analyses et de volume de données.

Le modèle étoile contient deux types de tables : la table de faits centrale et les tables de dimensions qui l'entourent.

La table de faits contient des mesures, par exemple, des montants d'argent comme les ventes, les achats, des nombres de transactions, des quantités. Elle contient toutes les mesures qui peuvent être d'intérêt pour l'utilisateur et son organisation.



Les axes d'analyses qui entourent la table de faits s'appellent des dimensions. Les dimensions sont les " Par " de la table de faits. L'utilisateur veut analyser les mesures  comme les ventes de la table de faits " Par " : par dates, par localisations ( pays, provinces, villes), par segments de la charte comptable, par projets, par produits, par types d'assurances, par employés, par clients et ainsi de suite. Certaines tables de faits peuvent avoir des dizaines de dimensions " Par " lesquelles l'utilisateur désire analyser, croiser, forer et explorer les données.

Les dimensions ne se répètent pas dans l'organisation. Par exemple, la dimension client contient toutes les informations relatives aux clients dans une seule table qui est réutilisée pour tous les faits. Ces dimensions sont des dimensions conformes pour l'ensemble de l'organisation.

D'autres types d'organisation de données comme les cubes (MOLAP) peuvent convenir à votre organisation. Ce type convient bien pour les organisations qui ont peu de volume de données et peu d'axes d'analyses (les dimensions). Le volume d'un cube augmente de façon exponentielle en fonction des axes d'analyses. Ainsi un cube qui a 5 dimensions de 1000 enregistrements aura 1000 x 1000  x 1000 x 1000 x 1000 =  1 000 000 000 000 000 = 1 x 10 ¹⁵ possibilités produites pour ces mesures et dimensions, créant un cube qui n'est pas performant ou pire l'impossibilité de créer le cube. S'il est impossible de créer le cube, il faudra diminuer le nombre de dimensions et ainsi diminuer les possibilités d'analyse de ce cube et perdre la possibilité de forer jusqu'au détail. Toutes sortes d'artifices sont utilisés avec plus ou moins de succès pour contrer cet inconvénient. Le pire étant de créer plusieurs cubes créant ainsi des silos qui ne permettent plus l'analyse croisée des données.

En résumé un schéma étoiles contient les axes d'analyse: les dimensions conformes, par lesquelles vous désirez consulter vos données: les faits. C'est une solution simple et performante adaptée au monde des entrepôts de données.

François Bouffard
Architecte BI
Panoramatechnologies.com