Disons le !
BI is not BO
Les anglophobes excuserons ce titre tapageur, je vais commencer par vous expliquer le fil de ma pensée.
Le constat est simple. Ce n’est pas l’outil qui permet de faire du décisionnel, mais l’utilisation qui en est faite qui doit se baser sur des méthodes spécifiques qui permettront la création d’un système décisionnel.
En effet, on peut très facilement détourner les outils décisionnels afin de les utiliser pour des problématiques de restitution d’informations qui sont courantes dans les entreprises.
Comme vous le savez les ETL permettent de faire de façon graphique un ensemble de transformations plus ou moins complexes afin de réaliser l’alimentation d’un entrepôt de données. On utilisera alors des composants permettant de faire agrégations, calculs d’intervalles ou éclatement de données pour alimenter faits et dimensions. On peut aussi y voir une autre utilisation : transporter facilement des données d’une application à une autre, effectuer la migration d’un historique d’informations vers une nouvelle application, récupération de données depuis un ftp voir plus exotique découpage de flux rss ! … Dès lors, pour la personne en charge de la réalisation, il n’est plus indispensable de développer des procédures sql complexes ou de manipuler des traitements batch qui sont bien souvent difficiles à analyser à postériori pour peut que vous n’en soyez pas le concepteur ou qu’ils soient mal documentés ! Les équipes commerciales ne s’y trompent d’ailleurs pas et vantent les bénéfices de leurs solution. (Parmis eux Talend ou Informatica)
De la même façon, on peut aussi utiliser des applications à vocation décisionnelle afin d’effectuer la restitutions de données sous forme de tableaux ou graphiques. Pour cela, en quelques clics de souris on fait appel soit directement aux tables applicatives si elles le permettent (attention à la dégradation des performances !) ou on réalise une copie – plus ou moins complète/enrichie – afin de restituer les informations. QlikView permet par exemple d’explorer très vite les données grâce à des listes de sélection. Mais cela peut être aussi valable pour Business Objects qui permet de créer un univers très rapidement en se basant sur les tables, liens et noms de champs. On donne alors très rapidement la main à l’utilisateur qui peut alors manipuler les données, réaliser sommes ou diagrammes pour par exemple afficher les factures du mois, visualiser une répartition simple de chiffre d’affaire par produit …
Dans les deux exemples précédents il n’est pas nécessaire de penser une modélisation spécifique : pas – ou peu – de création d’indicateurs, pas de notion d’historisation, pas d’agrégations suivant des dimensions… La modélisation de la base dans un schéma dénormalisé pourra faire gagner en performance ou permettre une consultation des informations facilitée, mais en aucun cas ne sera un passage obligé. Ainsi on peut en l’espace de quelques semaines, en profitant d’outils pointus, se permettre de développer flux ou outils de restitutions adaptés aux problématiques des utilisateurs.
Finalement, pour moi ce n’est pas parcequ’on travaille sur un ETL ou à l’aide d’un outil de restitution pensé pour le décisionnel qu’on peut mettre ce qualificatif sur la fonction exercée.
Et vous ? quel limites fixez vous au domaine décisionnel ?
Tags: Discussion
2 commentaires pour “BI is not BO”
Poster un commentaire
Bonjour,
Il est vrai que la définition de la limite d’application du décisionnel est difficile à percevoir.
Pour ma part, je considère qu’un SI est décisionnel du moment où il permet la prise de décision avec une architecture de données spécifique (DWH et toute la définition qui va avec : historique, agrégation, intégration, non volatile…) qui contient des informations extraites des sources opérationnelles (via un ETL) pour la mise en place de solution de Reporting. Bien au delà de ces considérations, un SI décisionnel doit être à la base d’une analyse poussée des données (type datamining). Il doit permettre au moment présent la projection dans le futur à partir des données du passé.
La constitution d’un simple entrepôt de données avec son process d’alimentation n’est donc pas une condition suffisante à mon goût.
Les outils comme BO sont performants pour de l’analyse à court terme s’ils se basent sur une architecture de donnée dite relationnelle. Ils trouveront très vite leur limite avec de gros volumes de données.
Et enfin, une dernière remarque (en complément du titre), le décisionnel ne se résume pas aux base OLAP (comme beaucoup de client le pense).
Bonjour Patrice,
Avant tout merci d’avoir ouvert le débat avec ton commentaire.
Je suis plutôt d’accord avec ta définition du SI Décisionnel par contre je pense que la vision analyse poussée au travers de datamining est discutable. En effet la fouille de donnée a pour objectif de découvrir des liens entre des données existantes pour faire ressortir de l’information qui est cachée. Cela peut en effet être très utile, mais encore faut il savoir ce que l’on cherche! Il me semble qu’un dwh simple, avec des indicateurs qui correspondent à l’activité et dont les datamarts proposent des vues métiers peut permettre de prendre déjà un nombre important de décisions : évolution du CA, effectifs, parts de marchés sont des indicateurs simple mais qui sont essentiels au pilotage de l’activité.
Ce que je souhaitais mettre en évidence dans cet article c’est que ce n’est pas l’outil qui est important mais les méthodes et l’analyse !
Finalement je te rejoint tout à fait dans ta dernière remarque. Le décisionnel c’est pour moi tout ce qui peut toucher à la gestion des connaissances de l’entreprise. Nous avions d’ailleurs déjà essayé d’en parler ici puis là suite à une remarque d’Amine pour nous apercevoir que dans bien des cas la réalité du terrain était bien différente des théories de gestion de la connaissance !