Les outils
Les dangers du reporting ad hoc
Selon l’étude du Magic Quadrant for BI plateforms du Gartner, le reporting ad hoc est un moyen de visualisation essentiel que chaque suite décisionnelle doit posséder. Je vous propose de découvrir dans un premier temps l’intérêt de ce type de visualisation des données puis nous verrons quels peuvent être les dangers liés à une utilisation non maitrisée de l’outil.
Desktop Intelligence (SAP), Report Builder (Microsoft) ou JasperReports (Jasper Soft) sont tous les trois des représentants de ce type d’outil. Leur intérêt est de laisser la main à l’utilisateur final pour lui permettre de construire ses propres interrogations. Ainsi l’utilisateur est libre de croiser les informations comme bon lui semble afin de mener ses analyses. Finalement l’outil de reporting ad hoc peut être considéré comme un générateur de SQL graphique qui permet de construire des requêtes de façon intuitive. L’avantage de ces outils est qu’en plus de proposer une interrogation accessible aux utilisateurs fonctionnels il leur laisse le loisir de mettre en forme les données obtenues afin de générer un document exploitable : graphiques, tableaux, jauges, couleurs, alerteurs, police … tout est fait pour que les informations obtenues puissent être correctement analysées. Cet outil décisionnel donne donc une grande liberté à l’utilisateur qui n’est plus obligé de passer par le service informatique pour construire ses interrogations. L’intérêt est évident pour ce dernier puisque ses ressources sont moins sollicités lorsqu’il faut extraire des données du système d’informations. Mais a-t-il vraiment tout à y gagner ?
Construction d’un rapport simple Desktop Intelligence (SAP)
La première source d’erreur pour la prise de décision de l’utilisateur est la qualité des données. En effet, l’informatique ne contrôle pas le moment auquel les personnes accèdent aux informations : potentiellement un document peut être rafraîchi – comprenez que les données seront extraites de la base de données puis mises en forme dans le document – à toute heure du jour ou de la nuit. Il n’est donc pas évident de garantir l’état dans lequel seront les informations récoltées : erreur de saisie dans l’applicatif non détectée par une règle d’alimentation, bases de données non mises à jour ou blocage d’un processus d’alimentations peuvent être sources d’incohérences. L’utilisateur peut alors être confronté selon moi à deux types de problèmes : données fonctionnellement erronées ou état des bases de données incohérent. La première situation me semble impossible à résoudre sans intervention humaine. En effet seul l’œil de l’expert est capable de détecter un problème dans la donnée issu d’une règle de gestion mal ou pas appliquée. En revanche on peut plus facilement bloquer le système au niveau de la base de données ou de l’application pour éviter que les utilisateurs n’y accèdent durant les phases de maintenance : ainsi tant que des alimentations sont en cours, pas d’accès aux données. Méfiance tout de même, je suis actuellement dans cette situation dans le cadre d’un déploiement BO XI 3.1 et on ne peut pas dire que l’éditeur ai facilité les choses avec la disparition du “File Watcher” présent dans les versions antérieur (BO 6.5 et v5).
Laisser le soin à l’utilisateur de construire lui même ces propres requêtes est en soit source potentielle d’erreurs liées à la compréhension de la donnée. En effet ces outils proposent de manipuler des objets qui peuvent correspondre à différentes notions, parfois incompatibles entre elles ou provoquant à cause de leur représentation physique des doublons. Il est donc nécessaire que l’utilisateur final prenne connaissance des données disponibles avant de les manipuler. En effet il faut garder à l’esprit la manière dont fonctionne l’outil : grossièrement un générateur de SQL. Je vous propose de prendre un exemple pour illustrer mes propos. Imaginez que vous avez à disposition les objets Nom client, Ville et Chiffre d’affaire. Vous décidez donc de créer un document représentant le chiffre d’affaire réalisé par ville avec un détail pour chaque client. Facile me direz vous ! Sauf si l’objet ville que vous avez utilisé est en fait la ville de naissance du client et non son adresse ! Élémentaire, mais il faut penser que les utilisateurs résonneront en fonction de ce qu’ils connaissent et non pas de ce que peut contenir la base de données. Il est donc primordial de s’appuyer sur les utilisateurs finaux pour que chaque objet soit correctement décrit dans la couche sémantique et compris par chacune des parties (concepteur côté informatique et utilisateur côté fonctionnel).
Filtre des données rapatriées avec Desktop Intelligence (SAP)
Comme vous l’avez compris la liberté laissée par un requetteur ad-hoc permet a chaque utilisateur de construire ses propres interrogations suivant ses besoins. Vous imaginez bien que cela peut se traduire par une requête sélectionnant le chiffre d’affaire réalisé depuis le début de l’année tout comme celui-réalisé, chaque semaine depuis 10ans, pour chaque magasin d’un secteur. Pour peut que les données utilisées soient détaillées à la ligne de produit par ticket de caisse (on ne sait jamais des modélisations non-adaptées ça existe !) on se rend vite compte que cette seconde interrogation pourra prendre un temps non négligeable. Si bien que non seulement l’utilisateur ne pourra pas accéder à ses données mais en plus il aura de fortes chance de perturber les interrogations de ces collègues. Face à cette situation je vois deux solutions. La première, plus pérenne, consiste à mener une action pour sensibiliser les utilisateurs aux contraintes techniques liées au rapatriement d’un nombre important d’informations. Cette communication pouvant éventuellement aboutir sur des modélisations complémentaires afin de mieux répondre aux besoins des utilisateurs. La seconde nécessite elle un budget important permettant de bénéficier des dernières innovations technologiques hardware du marché afin de gonfler les performances des plateformes en fonction des besoins des utilisateurs. Cette technique semble aujourd’hui tout à fait possible, même en considérant des volumes de données traités au dessus des dizaines de teraoctets avec des plateforme comme Netezza, Terradata ou plus communément Oracle … Attention néanmoins à la facture salée, qui ne fera qu’augmenter au fil des années et des besoins !
En conclusion il me semble important d’identifier les besoins qui amènent à utiliser un outil de reporting ad-hoc : navigateurs OLAP (comme Voyager chez SAP), outils de reporting ou outils d’analyse in-memory (SAP Explorer, QlikView …) sont peut être des outils plus adaptés aux demandes de vos utilisateurs. La vrai question est “ont ils réellement besoin de manipuler régulièrement leurs données/documents ?”. Si la réponse est oui, effectivement le reporting ad-hoc sera adapté car il fournira à l’utilisateur la couche d’abstraction nécessaire à une consultation facile et orientée métier. En revanche, si les utilisateurs consultent régulièrement les mêmes documents ou sont incapables de créer eux même leurs propres rapports il faut peut être reconsidérer le choix de l’outil. En effet les outils de reporting dédiés permettent d’être nettement plus précis en terme de mise en page ou proposent plus de supports de diffusion des informations. Dans le même sens il sera plus facile de naviguer dans des données à l’aide d’un outil d’analyse in-memory ou OLAP. Deux conditions pour effectuer ces changements : avoir le budget et les compétences en interne sur les nouveaux outils. En effet deux opération seront nécessaires : la migration (allez n’ayons pas peur la re-création) des différents documents puis la réponse aux nouveaux besoins des utilisateurs. Inconvénient évident : l’informatique se voit régulièrement sollicité par les utilisateurs ; A l’opposé, l’informatique retrouve la maîtrise de son SI.
Et vous ? Qu’en pensez vous ? Avez vous déjà rencontré des problèmes de qualité des données ou performance des outils de reporting ad hoc ? Quels moyens de contrôle avez-vous mis en place ?
Tags: ad hoc, couche sémantique, meta-données, performances, qualité des données, reporting, si, SQL, utilisateurDiscussion
5 commentaires pour “Les dangers du reporting ad hoc”
Poster un commentaire
Et oui, comme toujours, c’est le besoin qui doit définir le moyen (l’outil) et non l’inverse ! Il est important de procéder à la cartographie des utilisateurs pour leur donner le (ou les) outils le plus adapté. D’où l’intérêt d’une plate-forme BI intégrée pouvant couvrir tous les besoins en matière de restitutions utilisateurs.
Bonjour Brice,
Je partage ton point de vue sur les risques que peut présenter un outil de reporting ad hoc. Pour compléter la panoplie de solutions, on peut ajouter une réponse moins glamour mais assez efficace : la limitation du nombre de lignes ramenées ou (non exclusif) du temps de traitement de la requête. BO (pour ne pas le citer) propose ce mode de limitation, par exemple.
En revanche, je pense que le reporting ad hoc et l’Olap/Analyse in memory sont deux briques distinctes. Et je dirais même que cette distinction se tient sur deux axes :
– Tous les domaines métier ne se prêtent pas au multi-dimensionnel. Cas concret : le suivi d’une population (problématique récurrente en suivi de campagnes marketing) pour lequel le multi-dim n’apporte pas vraiment de réponse.
– En corollaire, les utilisateurs n’ont pas tous une approche organisée par hiérarchies. La modélisation répondant à leur besoin est parfois assez loin d’un joli modèle en étoile :'(
Heureusement, l’utilisateur ad hoc se contente bien souvent de faire évoluer un rapport existant !
J’en conclue que je partage aussi l’avis d’Olivier : la diversité des besoins des utilisateurs doit trouver une réponse dans la panoplie d’accès aux informations proposée par le SID.
Bonjour Vincent,
Effectivement on peut bloquer l’utilisateur pour éviter qu’il ne s’attaque à un historique de 10 ans pour remonter le CA du mois courant. C’est plutôt efficace, mais aussi source d’erreur : le discret point d’exclamation « Résultats partiels » présenté par BO est régulièrement oublié par les utilisateurs. On peut aussi limiter les temps d’exécution lors des planification (toujours dans BO avec l’agent BCA ou jobserver pour les versions >= XI) mais j’ai l’impression que finalement ces limites sont bien souvent repoussées à la demande des utilisateurs (l’intérêt de bloquer un temps d’exécution à 10h, il faudra m’expliquer!) si bien qu’elles deviennent inefficaces.
Bonjour,
tout ceci releve du design et de la possibilité de nos outils à identifier si certaines requetes sont cohérentes ou non.
Les problèmes de qualité de données peuvent être adressés dans la conception de nos traitement d’alimentation. Certains outils determinent les différents aggrégats à construire et ceci indépendamment des utilisateurs, d’un business analyste, ou d’un administrateur de base de données. D’autres sont capable d’interdire des agrégations suivant certaines dimensions.. Je regrete simplement que peu d’éditeur travaillent sur ces sujets … Quelles sont les evolutions que nous avons connues sur Business Objects Webi/Deski ces 10 dernieres années !!! Il est toujours possible de cumuler des pommes et des poires et bloquer l’execution d’une requête sur Oracle au bout de 10 h n’est toujours pas possible si elle contient une clause group by….
les utilisateurs n’ont pas à comprendre nos contraintes techniques ce sont aux outils de s’adapter …
Bonjour, je viens à peine de découvrir votre blog que je suis déjà deçu par votre décision de l’arreter (temporairement?)même si je comprends les raisons qui vous poussent à le faire. Donc revenons à votre article sur le reporting Ad-Hoc, j’aimerais connaitre votre opinion sur le reporting Ad-Hoc temps réel? les données ont moins de chance d’être erronées, je me trompe ?
Amicalement
Marc