InfleXsys Créer une application mobile professionnelle : à quel prix et quel ...
Jaspersoft les 5 niveaux du décisionnel intégré
1. 5 Les cinq niveaux du décisionnel intégré
Des applications statiques aux applications analytiques
2. 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
3. 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 1
Reporting statique
4. 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 2
Rapports interactifs gérés
5. Niveau 3
Rapports 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 ManagingYour 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.
6. Niveau 4
Reporting 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
7. Niveau 5
Analyse 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.
