5 Les cinq niveaux du décisionnel intégréDes applications statiques aux applications analytiques

Introduction

L’expansion des données dans la gestion de l’entreprise promet l’apparition d’applications opérationnelles plus intelligentes capables de mieux gérer et automatiser les processus. Cette nouvelle génération d’applications intelligentes, appelées applications analytiques, transfor-me la manière dont les entreprises et les autres applications consom-ment les informations afin de générer de meilleures performances et un avantage concurrentiel.

La plupart des entreprises valorisent leurs données sous la forme de rapports, de tableaux de bord et d’analyses à l’aide d’outils décisionnels (BI) autonomes et d’outils d’entrepôt de données. Pourtant, en réalité, seul un faible pourcentage d’utilisateurs a effectivement recours à ce type de décisionnel en raison de la complexité de l’interface, du manque d’informations à jour et des problèmes d’inexactitude des données.

Souvent, ce sont des applications opérationnelles déjà en place qui offrent la possibilité d’exploiter les données pour optimiser la prise de décision. Ces applications métier évoluent en migrant leurs données opérationnelles statiques vers des applications analytiques interactives, lesquelles favorisent une prise de décision plus efficace..

Au regard du grand nombre d’éditeurs de logiciels et de choix de déve-loppements, le processus de transition d’une application opérationnelle statique vers une application analytique peut sembler une vraie gageure. Les développeurs d’applications doivent choisir entre créer leurs propres fonctionnalités analytiques dans leur application ou s’en remettre à un outil existant, prêt à l’emploi.

Cet e-book présente les cinq niveaux d’engagement les plus courants qu’il est possible d’atteindre par l’intégration du décisionnel. En suivant cette progression en termes de complexité et de valeur, vous pouvez transformer une application opérationnelle statique en application analytique interactive motivante. Dans la présente discussion, une application métier fictive et ses utilisateurs illustrent les fonctionnalités offertes aux utilisateurs finaux à chaque niveau.

Avec le décisionnel intégré, il est possible d’atteindre ces cinq niveaux d’engagement :

Notre exemple d’application avec décisionnel intégré est un système de gestion des stocks appelé IMS2. Ce système organise les informations produits, les unités en stock, les données de localisation, l’historique des mouvements et les informations de nomenclature. Il est utilisé par une grande diversité d’employés, notamment responsables d’inventaire, gestionnaires d’entrepôts, agents de détail, responsables d’atelier et équipes dirigeantes.

Niveau 1 : reporting statique à l’aide d’une bibliothèque de rapports intégrée

Niveau 2 : reporting géré avec interactivité, planification, sécurité et distribution simplifiées via un serveur de reporting

Niveau 3 : rapports et tableaux de bord hautement interactifs via un serveur de reporting

Niveau 4 : rapports et analyse de données ad hoc en libre-service via un serveur décisionnel

Niveau 5 : analyse avancée avec mini-entrepôt de données via un serveur décisionnel

Joel est responsable d’inventaire au magasin Buck’s Electro-nics de Phoenix. Il veut savoir combien de batteries lui ont été fournies par son distributeur le mois dernier et combien sont prévues pour le reste de l’année, le tout présenté par semaine dans un tableau ou un histogramme. Il veut générer le rapport à partir des données les plus récentes. L’administratrice de l’application, Kelly, a implémenté le rapport en tant qu’option de menu dans l’application IMS2 ; il sera généré au format PDF.

Les utilisateurs finaux veulent uniquement un rapport

Lorsque les utilisateurs veulent visualiser des données depuis leur application opérationnelle, ils consultent géné-ralement un rapport statique issu de l’application. Certains rapports sont mis en forme et prêts pour l’impression, tandis que d’autres sont disponibles en téléchargement sous la forme d’une feuille de calcul Microsoft Excel. Les rapports fournissent une vue statique dans le temps, qui provient en principe de la base de données opérationnelles dynamique de l’application.

Les développeurs d’applications veulent une solution architecturale simple

Pour déterminer la meilleure façon d’obtenir un rapport statique dans leur application opérationnelle, les dévelo-ppeurs d’applications disposent de plusieurs options. Ils peuvent concevoir leur propre outil, intégrer un moteur de reporting open source ou faire l’acquisition d’une solution commerciale. Ils peuvent examiner plusieurs options architecturales pour implémenter de manière transparente la requête de rapport, sans incidence sur l’architecture de l’application opérationnelle. En réduisant l’impact sur l’architecture de l’application, on obtient généralement une solution de reporting limitée pour les utilisateurs finaux.

Réflexions

Une bibliothèque de reporting intégrée permet à l’ utilisateur d’exécuter un rapport à la demande ou de demander à l’application d’exécuter ce rapport en arrière-plan puis de le stocker. Ces rapports préintégrés sont conçus par un développeur d’applications et nécessitent de définir la mise en page du rapport et son format d’exportation (par ex. PDF, XLS, HTML). Chaque rapport doit être conçu de manière à éviter tout impact significatif sur les perfor-mances de l’application opérationnelle. La bibliothèque de reporting est souvent créée au sein de l’environnement applicatif, partageant ainsi son répertoire racine. Les développeurs d’applications écrivent généralement du code supplémentaire associé à la bibliothèque de reporting pour gérer l’accès, la sécurité, la planification et le stockage des rapports.

Composants décisionnels intégrés requis

• Bibliothèque de reporting pour disposer de services tels que compilation de rapports, mise en page et format d’exportation

• Concepteur de rapports de bureau pour la création des rapports

Limites

• Informations statiques instantanées : les rapports intégrés limitent généralement les informations dans le temps en raison d’un manque de données historiques stockées dans la base de données de l’application opérationnelle. Par conséquent, les rapports ne peuvent révéler aucune tendance à leurs utilisateurs. En outre, le rapport est habituellement statique et ne permet pas aux utilisateurs d’effectuer des zooms depuis les données de synthèse vers les détails sous-jacents, afin d’en avoir une vision approfondie.

• Requêtes de rapport sans réponse : chaque rapport intégré est conçu par un développeur d’applications, ce qui implique des hypothèses sur ce qu’il convient de présenter à l’utilisateur final et la manière dont les données lui sont présentées. Les nouvelles requêtes de rapport peuvent uniquement être émises par le développeur, ce qui signifie que les requêtes personnalisées restent sans réponse ou ne sont pas fournies au bon moment.

• Impact sur les performances de l’application : si l’application opérationnelle n’offre ni planification ni référentiel de rapports, la même requête de rapport peut être exécutée plusieurs fois, de manière simultanée par différents utilisateurs, ce qui influera sur les performances de l’application opérationnelle. Par ailleurs, la compilation et la mise en page de chaque rapport mobilisent des ressources de calcul.

• Travail de développement : pour chaque nouveau rapport, le développeur doit tenir compte de l’impact en termes de performance sur l’application opérationnelle ainsi que de tous les aspects liés à la sécurité. Lorsque les utilisateurs finaux demandent de nouvelles vues des données, le développeur doit mettre en balance nouvelles requêtes de rapport et améliorations des fonctionnalités.

Niveau 1Reporting statique

Exemple

Janet est responsable des magasins Buck’s Electronics de la région Ouest. Elle veut savoir combien de livraisons au total ont été effectuées le mois précédent par distributeur, combien d’unités se trouvent en stock et combien seront expédiées le mois suivant pour chaque magasin. Elle veut ensuite que tous les rapports soient exécutés chaque nuit puis envoyés par e-mail au responsable de chaque magasin. Paul, le responsable du magasin de Santa Fe, a demandé un champ de vieillissement des stocks dans le rapport de son magasin. Kelly, toujours responsable de la maintenance et de l’extension d’IMS2, sait que le niveau actuel d’intégration n’est pas suffisant pour cette tâche..

Reporting applicatif géré pour de meilleures performances de l’entreprise

Le succès d’une application opérationnelle fait souvent apparaître de nouvelles exigences professionnelles et de nouveaux défis pour les administrateurs de l’application. Les rapports gérés aident l’entreprise à être performante grâce au partage d’informations prévisibles et aux indicateurs clés de performance prédéfinis (KPI).

Pour ce qui concerne les besoins de Janet et de Paul, Kelly ne peut pas y apporter de réponse avec la fonctionnalité prête à l’emploi d’une solution de reporting Niveau 1. Kelly devrait sinon créer des outils personnalisés pour la planification et le service de distribution de rapports. En outre, elle doit créer plusieurs nouveaux rapports personnalisés, soit en extrayant les données depuis l’application puis en créant les rapports avec un autre outil, soit en demandant une amélioration auprès de l’éditeur d’IMS2. Comme cela est souvent le cas, Kelly a également la charge d’autres tâches, notamment la maintenance d’autres applications, ce qui génère des délais dans la réponse aux requêtes de Paul et Janet.

Réflexions

Les entreprises attendent de la plupart des applications opérationnelles qu’elles fournissent de manière automatisée des rapports et des requêtes de rapport personnalisés. L’engagement des utilisateurs finaux d’une application augmente lorsque les données du système s’inscrivent dans des processus de planification et de prise de décision quotidiens. Au fil de la progression de l’application, il est possible qu’apparaissent de nouvelles solutions ou de nouveaux concurrents. Pour répondre aux besoins de reporting Niveau 2, il est possible de compléter la bibliothèque de reporting avec un planificateur et un référentiel de rapports, un service de distribution de rapports, des mesures de sécurité par rôle et un concepteur de rapports pour les nouvelles requêtes de rapport. Ces fonctionnalités supplémentaires ajoutent à la complexité de la solution de bibliothèque de reporting. Ces services peuvent être fournis par l’application en natif via un travail de développement assez conséquent, ou par une solution décisionnelle intégrée prête à l’emploi. Une fois ces services mis en place, la solution décisionnelle intégrée peut fournir des rapports plus nombreux à davantage d’utilisateurs, avec une plus grande interactivité, grâce à l’outil de conception de rapports et à la configuration du serveur. A partir de ce stade, un serveur de reporting devient essentiel pour fournir une solution décisionnelle intégrée complète.

Composants décisionnels intégrés requis

• Serveur décisionnel pour la sécurité des données et les services de reporting (planification, distribution et organisation)

• Concepteur de rapports de bureau pour rapports très complexes

Limites

Un serveur de reporting permet d’améliorer le niveau d’engagement des informations au sein de l’entreprise grâce à des rapports interactifs planifiés, tout en améliorant les performances de l’application opérationnelle en transférant la compilation des rapports vers un serveur de reporting distinct. Mais certaines restrictions limitent la capacité de l’application à s’adapter à la dynamique variable d’ une entreprise :

• Simplicité de la sécurité des données : un modèle objet de rapport simple tel que la solution de reporting Niveau 2 ne fournit pas de sécurité de niveau requête (SQL). Un référentiel de rapports n’examine pas les requêtes du rapport, de sorte que le développeur ou l’administrateur des rapports doit créer les attributs de sécurité dans le rapport lui-même et affecter manuelle-ment ces attributs à l’objet de rapport.

• Disponibilité des rapports personnalisés : la création de nouveaux rapports personnalisés requiert l’expertise d’un développeur spécialisé en raison de la complexité de la source de données sous-jacente, des modèles de sécurité et des exigences de mise en forme des rapports. Pour la plupart, les entreprises possèdent peu de développeurs de rapports spécialisés ; il est donc plus difficile dans ce cas de fournir de nouveaux rapports aux utilisateurs professionnels.

• Pas de tableaux de bord : une fois que les utilisateurs de l’application ont trouvé réponse à leurs besoins de base en reporting, ils deviennent rapidement demandeurs de fonctionnalités plus complexes, comme par exemple des vues de contrôle. Ce type de reporting est possible via des tableaux de bord, qui fournissent des synthèses instantanées sur les indicateurs de performance stra-tégiques. La plupart des tableaux de bord permettent d’effectuer des zooms avant sur les détails sous-jacents d’une vue de synthèse, afin de procéder à un examen plus approfondi.

Niveau 2Rapports interactifs gérés

Niveau 3Rapports et tableaux de bord hautement interactifs

Exemple :

Steve est responsable des opérations d’inventaire pour tous les magasins de vente au détail des produits électroniques. Il veut pouvoir instantanément disposer de métriques sur les indicateurs de performance clés pour les stocks et les points de vente, présentés dans un tableau de bord unique, facile à consulter. Il veut que ses rapports soient interactifs et permettent de réaliser des zooms avant sur des données détaillées et des opérations de filtrage, et qu’ils fournissent des indicateurs faciles à identifier, associés aux données métriques aberrantes. Ces métriques sont obtenues de manière combinée à partir du système d’inventaire IMS2 et d’une autre application point de vente afin de constituer un tableau de bord central sur les performances de l’entreprise. De nouveau, Kelly réalise que la solution actuelle ne va pas convenir à ce nouveau niveau d’engagement. Pour que Steve soit réellement satisfait, elle va devoir passer au niveau supérieur.

Réponse aux nouveaux profils utilisateur avec tableaux de bord applicatifs

Si le type de rapports évoqué dans les deux premières phases fournit des informations détaillées utiles chaque jour pour les décisions stratégiques des responsables produits et des utilisateurs dans l’atelier, il ne conviendra peut-être pas aux dirigeants ou aux responsables sectoriels. Les dirigeants n’utilisent probablement pas l’application pour des tâches opérationnelles journalières, mais s’appuient en revanche sur des données instantanées, sur une base hebdomadaire, quotidienne ou horaire, pour suivre les performances de leur entreprise. Ces informations sont habituellement présentées dans un tableau de bord interactif facile à appréhender.

« Un tableau de bord décisionnel est un outil de visualisation de données qui permet de contrôler les processus métier et ac-tivités stratégiques, à l’aide de métriques sur les performances de l’entreprise, et qui déclenche des alertes en cas de problèmes potentiels. Ils analysent la cause principale des problèmes en explorant les informations pertinentes et opportunes, selon plusieurs perspectives et à différents niveaux de détail. Ils gèrent également les personnes et les processus pour optimiser la prise de décision, les performances et orienter l’entreprise dans la direction appropriée. »– Tableaux de bord de performance :Measuring, Monitoring, and Managing Your Business, Wayne Eckerson

Un tableau de bord de performance mesure les tendances à court et long terme, avec accès rapide aux détails sous-jacents, afin d’aider les équipes dirigeantes à réagir de manière tactique ou stratégique en fonction des besoins de leur entreprise. Les tableaux de bord peuvent également être alimentés par plusieurs sources dans l’application, afin de présenter une vue holistique de l’entreprise.

Réflexions

Les deux niveaux précédents de reporting intégré ne permet-tent pas, en réalité, de présenter un tableau de bord interactif. Les tableaux de bord sont un ensemble de rapports ou « reportlets » assemblés sur une trame unique, souvent avec des contrôles interactifs qui permettent à l’utilisateur de modifier la vue des données selon l’heure, le lieu ou autre catégorie de paramètres. La structure de contrôle de ces reportlets intégrés nécessite une couche d’orchestration généralement gérée par une couche de métadonnées au sein de l’environnement du serveur de reporting. Pour améliorer l’engagement et attirer les décideurs vers le tableau de bord, la mise en page et la conception globales doivent inclure des éléments convaincants tels que des graphiques animés et des tables avec fonction de zoom, de sorte que les utilisateurs puissent rapidement localiser et explorer leurs activités métier.

Composants décisionnels intégrés requis

• Serveur décisionnel pour la sécurité des données, couche de métadonnées, structure de tableau de bord et services de reporting (planification, distribution, organisation)

• Concepteur de rapports de bureau pour rapports très complexes

• Framework d’interface personnalisable pour stratégie de marque transparente et intégration dans l’application opérationnelle

Limites

Le décisionnel intégré Niveau 3 permet aux nouveaux profils utilisateur d’exploiter les données stockées dans l’application  IMS2. Les tableaux de bord peuvent permettre de mettre en place de nouvelles stratégies, de meilleures décisions et des mesures de planification. Le Niveau 3 ne fait toutefois pas diminuer le nombre de demandes de rapports personnalisés émises par d’autres types d’utilisateurs. La réussite à ce niveau fait souvent apparaître de nouveaux besoins :

• Manque de rapports personnalisés : la création de nouveaux rapports personnalisés requiert l’expertise d’un développeur spécialisé en raison de la complexité de la source de données sous-jacente, des modèles de sécurité et des exigences de mise en forme des rapports. Pour la plupart, les entreprises possèdent peu de développeurs de rapports spécialisés ; il est donc plus difficile d’assurer une réactivité auprès des utili-sateurs professionnels en termes d’approvisionnement en nouveaux rapports. La solution idéale consiste à fournir des outils de conception de rapports que les utilisateurs possédant peu de compétences techniques peuvent utiliser pour créer leurs propres rapports sans faire appel au service informatique ni aux développeurs spécifiquement qualifiés.

• Exploration et analyse des données insuffisantes : les tableaux de bord permettent de visualiser des proces-sus complexes dans des termes faciles à consulter et à comprendre. Toutefois, un tableau de bord convaincant éveille la curiosité de l’utilisateur, qui veut en savoir plus sur ses données et comprendre pourquoi telle métrique révèle un résultat insuffisant ou excessif. Les réponses à ces questions se trouvent souvent en dehors de la portée du tableau de bord et de ses rapports détaillés sous-jacents. Pour pouvoir répondre à ces questions plus profondes et plus immédiates, il convient d’exposer les données via une interface avec laquelle l’utilisateur puisse interagir. L’exploration des données nécessite souvent des requêtes comparant divers paramètres de produit, de lieu et de temps. Les utilisateurs veulent pouvoir consulter les données dans différentes dimensions afin d’identifier les tendances ou les données aberrantes.

Niveau 4Reporting et analyse en libre-service pour applications opérationnelles

chaque rapport manuellement, ainsi que dans les délais que cela induit. Il existe un risque accru pour les performances de l’application en raison des requêtes non contrôlées que cette approche introduit dans l’environnement. Pour les implémen-tations à plus grande échelle, il existe un risque de sécurité accru si un accès général est fourni à la base de données, auquel s’ajoutent des coûts de formation supplémentaires en fonction de la taille du groupe.

Option 2 :

Fournir à Paul un environnement de conception de rapports facile à utiliser pour ses besoins de reporting et d’analyse ad hoc. Kelly peut définir une couche sémantique facile à compren-dre qui se superpose à la base de données de l’application. Cette couche permet aux utilisateurs sans compétences techniques de comprendre le nom des colonnes et les données tout en fournissant un modèle d’accès de sécurité pour la base de don-nées sous-jacente. Les métadonnées peuvent être conçues avec la base de données opérationnelle ou avec un mini-entrepôt de données spécifique. Avec ces éléments, et avec un concepteur de rapports graphique par glisser-déplacer, les travailleurs du savoir comme Paul peuvent alors créer leurs propres rapports à la demande, sans solliciter Kelly. Enfin, un moteur d’interrogation en mémoire peut réduire davantage encore l’impact des requêtes sur la base de données de l’application, autorisant ainsi des rapports personnalisés et des analyses légères qui n’affectent pas les performances de l’application. Lors de l’intégration d’un environnement décisionnel en libre-service dans une autre application, il existe un risque assez important que l’apparence de l’application originale perde en cohérence. Il convient de choisir des outils décisionnels capables de personnaliser l’interface afin qu’elle puisse se fondre de manière transparente dans votre application.

Limites

• Cohérence de l’apparence de l’application : l’apparence d’une application est importante pour les éditeurs de logiciels et les utilisateurs finaux. Les développeurs d’applications qui intègrent une plateforme décisionnelle prête à l’emploi existante doivent rechercher des outils facilitant les personna-

lisations afin de proposer une apparence cohérente pour les utilisateurs finaux.

• Simplicité des analyses : l’analyse de données ad hoc à l’aide d’un moteur d’analyse en mémoire ne fournit pas obligatoirement toutes les requêtes avancées requises par un analyste de données. Cette restriction peut résider dans la structure de la base de données de l’application ou dans les fonctions analytiques disponibles dans l’outil en mémoire. Les requêtes plus évoluées peuvent nécessiter un outil OLAP (Online Analytical Processing) permettant d’exécuter des requêtes analytiques plus puissantes et plus perfectionnées.

• Connaissance des tendances et taille des données limitées pour l’analyse : si l’environnement d’analyse utilise un moteur en mémoire avec un système transactionnel, la quantité de données historiques peut être un facteur restrictif. En outre, si la base de données de l’application contient beaucoup de données, la quantité stockée dans un moteur en mémoire est limitée à la quantité de mémoire disponible sur l’ordinateur hébergeant le serveur décisionnel. Si la base de données de l’application est volumineuse, il est souvent préférable de configurer une base de données analytique spécifique qui s’appuie sur le stockage en colonnes et sur la compression des données.

Composants décisionnels intégrés requis

• Serveur décisionnel pour la sécurité des données, couche de métadonnées, concepteur de rapports Web facile à utiliser, structure de tableau de bord, services de reporting (planification, distribution, organisation)

• Concepteur de rapports de bureau pour rapports avec mise en forme avancée

• Framework d’interface personnalisable pour stratégie de marque transparente et intégration dans l’application opérationnelle

Exemple :

Paul est planificateur d’inventaire au siège de Buck’s Electronics. Il veut créer ses propres rapports personnalisés pour ses distributeurs en gros. Ces distributeurs changent tous les quelques mois et les rapports doivent donc également suivre cette fréquence. Certains rapports sont créés par gamme de produits, tandis que d’autres sont basés sur des métriques spécifiques à chaque magasin. Les rapports statiques actuels fournis par le système IMS2 ne procure pas la flexibilité requise pour générer ces rapports, ce qui oblige Paul à demander à Kelly de nouveaux rapports presque tous les mois. Kelly reçoit des demandes similaires de rapports personnalisés de la part d’autres employés et ne parvient pas à suivre ce rythme.

Questions à examiner :

1. Vos clients ont-ils plusieurs interlocuteurs pour lesquels ils doivent disposer de rapports avancés ?

2. Ces personnes veulent-elles créer leurs propres rapports ?

3. Ces personnes possèdent-elles les connaissances suffisantes et veulent-elles créer leurs propres rapports sans faire appel au service informatique ou autres ressources techniques ?

Réflexions

Lorsque les travailleurs du savoir veulent des rapports personnalisés, qui ne sont donc pas inclus dans l’application opérationnelle standard, Buck’s a le choix entre deux options :

Option 1 :

Fournir à Paul ou à Kelly un accès direct à la base de données vers le schéma de l’application opérationnelle afin de pouvoir vider les données CSV vers leur machine locale, ou leur fournir un outil de conception de rapports pour les besoins plus exigeants.

L’inconvénient de cette option réside dans les coûts de forma-tion et l’étendue des ressources nécessaires pour apprendre aux utilisateurs sans compétences techniques à manier des outils de conception de rapports puissants et complets pour créer

Niveau 5Analyse avancée pour une perception approfondie

Exemple :

Susan est responsable d’une gamme de produits au siège de Buck’s Electronics. Elle veut comprendre pourquoi les marges chutent pour les claviers et les moniteurs dans les magasins de la zone Nord-Ouest, par rapport à ceux de la zone Sud-Ouest. Elle voudrait explorer diverses données et dimensions, notamment coûts unitaires en gros, prix de détail, vieillissement des stocks, frais d’expédition et promotions sur les produits. Elle prévoit de comparer les pro-duits selon les dimensions magasin et date (mois et année), en incluant les données de leur système de promotion des produits. Elle va examiner les tendances dans le temps, éventuellement dues à des schémas saisonniers selon les magasins et aux dépenses supplémentaires associées à l’approvisionnement. Pour répondre à ce nouveau besoin, Kelly envisage les options suivantes :

• Créer des rapports personnalisés qui recueillent les données dont Susan a besoin

• Donner à Susan les outils d’exploration qui lui permettent de trouver intuitivement les données dont elle a besoin

Réflexions

Kelly peut par exemple obtenir des réponses aux questions de Susan en créant plusieurs rapports personnalisés. Cette solution nécessite toutefois du temps pour développer, exécuter et examiner chaque rapport manuellement. Il est également inefficace d’accéder aux données de cette manière, car cela peut dégrader les performances de l’application opérationnelle elle-même.

Différentes options peuvent permettre de résoudre ce pro-blème. Une vue préintégrée dans les données sous-jacentes,

simplement structurée à des fins d’analyse, permet aux analystes de données d’inspecter rapidement des ensem-bles de données volumineux et d’effectuer des requêtes complexes sur des périodes définies, ce qui est difficile à réaliser avec une base de données transactionnelle.

Le modèle de traitement de données OLAP (Online Analytical Processing) permet aux analystes d’effectuer aisément des extractions sélectives et de visualiser les données selon plusieurs points de vue. Tandis que les modèles de données transactionnels sont conçus pour stocker les données selon une ou deux dimensions (par ex. ventes par région), une base de données multidimension-nelle, par ex. OLAP, considère chaque attribut de données en tant que dimension distincte (par ex. produit, région, intervalle de temps). En intégrant une approche OLAP ou multidimensionnelle, l’application peut faciliter les analyses comparatives et temporelles (par ex. zoom avant, zoom arrière, permutation d’axes, rotation et filtrage) selon ces différents points de vue. La plupart des moteurs OLAP prennent en charge un langage de requête plus expressif appelé MDX (expressions multidimensionnelles) qui assure aux analystes puissance et simplicité pour exécuter des requêtes avancées, tout en évitant les problèmes liés à l’analyse classique des requêtes SQL.

Composants décisionnels intégrés requis

• Outils d’intégration de données pour extraire, transformer et charger les données depuis la base de données de l’application opérationnelle vers un (mini-)entrepôt de données

• (Mini-)entrepôt de données pour traitement efficace des données à des fins d’analyse

• Moteur OLAP pour performance et traitement analytique

• Serveur décisionnel pour la sécurité des données, couche de métadonnées, visualisation de données, concepteur de rapports Web facile à utiliser, structure de tableau de bord et services de reporting

• Concepteur de rapports de bureau pour rapports avec mise en forme avancée

• Framework d’interface personnalisable pour stratégie de marque transparente et intégration dans l’application opérationnelle

Limites

Proposer un meilleur accès aux données présente de nombreux avantages pour les entreprises, notamment une meilleure connaissance des nouvelles catégories de revenus, des améliorations des processus opérationnels, des avantages concurrentiels, etc. ; le coût de cette démarche peut toutefois s’avérer élevé pour les développeurs et les administrateurs. Voici quelques défis spécifiques à une solution d’analyse intégrée :

• Complexité de l’architecture : pour pouvoir correctement fournir des analyses avancées, puissantes et réactives, l’environnement doit inclure des services supplémentaires, notamment une base de données pour les requêtes analyti-ques, un logiciel d’intégration de données et des métadonnées pour les définitions d’agrégation.

• Maintenance de l’application : pour les adminis-trateurs, l’ajout de logiciels implique un travail de maintenance plus important. Les analystes de données demandent fréquemment de pouvoir disposer d’une nouvelle vue sur l’entrepôt de données, ce qui nécessite une nouvelle tâche d’intégration des données et de nouvelles définitions de requêtes.

ConclusionIl existe de nombreuses options permettant d’améliorer une application à l’aide de fonctionnalités décisionnelles. Il est important de comprendre les avantages et les besoins des utilisateurs qui correspondent à chaque niveau de fonctionnalité. Dans l’exemple ci-dessus, Buck’s Electronics a franchi les cinq niveaux de décisionnel intégré. Consciente de la valeur des données dans l’application IMS2, Kelly peut désormais donner à Steve, Janet, Paul et Susan les données et les outils dont ils ont besoin pour prendre des décisions au moment opportun et de la manière appropriée. A chaque niveau décisionnel, l’équipe Buck’s a pu préciser la valeur des données et mieux comprendre leur rôle dans l’entreprise. Grâce au décisionnel intégré, applications et utilisateurs peuvent atteindre un niveau d’intelligence supérieur, ce qui permet aux applications opérationnelles d’assurer à l’utilisateur final un meilleur engagement et une valeur ajoutée plus importante.

Une fois que vous avez déterminé comment procéder, choisissez si vous voulez créer votre propre structure déci-sionnelle ou acheter une solution prête à l’emploi. Avant de prendre votre décision, réfléchissez à ces questions :

1. Disposez-vous du temps et des ressources nécessaires pour créer et assurer la maintenance d’une solution décisionnelle intégrée ?

2. Possédez-vous l’expertise requise en matière de décision-nel pour gérer les tendances émergentes telles que les fonctionnalités mobiles et sociales ?

3. Voulez-vous que votre solution décisionnelle intégrée soit disponible dans une interface unifiée transparente ?

4. Votre application sera-t-elle créée sur une base SaaS et/ou sur site ?

En savoir plusLa suite décisionnelle open source de Jaspersoft compte 14 millions de téléchargements dans le monde, 175 000 déploiements en production et 14 000 clients professionnels dans 100 pays. Ces logiciels sont régulièrement améliorés par une communauté de développeurs fédérant plus de 250 000 membres. Pour plus d’informations, consultez les pages :http://www.jaspersoft.com et http://www.jasperforge.org

Copyright© 2011 Jaspersoft Corporation. Tous droits réservés. Avis de marque déposéeLes marques, logos et marques de service (« Marques ») présentées sont la propriété de Jaspersoft ou de tiers. Vous n’êtes pas autorisé à utiliser les Marques sans le consentement écrit préalable de Jaspersoft ou de ces tiers, éventuels propriétaires des Marques. Les marques de Jaspersoft incluent, sans toutefois s’y limiter, « Jaspersoft » et le logo Jaspersoft.