Caractéristiques
Caractéristique de la BI : « Un système décisionnel n’est pas tout le système d’information »
Où se place le système décisionnel ?
Soyons bien clairs : un système d’information va regrouper toutes les données qui permettent à l’entreprise de « mémoriser » et suivre son business. Des bases de données applicatives (CRM (Customer Relationship Management), paie, RH, …) on passe à l’infocentre (vue « micro ») puis au datawarehouse et éventuellement au datamart. Le système décisionnel est une composante bien distincte, qui va permettre d’étudier le business : on est alors dans une vue « macro ».
Ainsi, on comprend immédiatement la relation : le début de la chaine est une source du datawarehouse.
Mais pourtant, il arrive que ce ne soit pas le cas. Dans certaines sociétés, le système décisionnel s’est construit comme s’il était tout le système d’information et l’ensemble devient une « grosse boucle » : le décisionnel devenant source de l’applicatif, qui devient source du décisionnel, qui devient source du… Et à ce niveau là, c’est perdu.
C’est perdu. Ou tout du moins mal parti. Tout se mixe, tout se mélange, tout s’entrecroise et il devient très difficile de faire la part des choses dans les outils ou plutôt dans ce qui est devenu UN outil.
Comment le décisionnel se mélange au transactionnel ?
Entre SI et BI...un jeu !
Comment en arrive t-on là ? En ne prenant pas soin de bien séparer les éléments, les projets. En développant au fil de l’eau. Au final, on ajoute au décisionnel une brique de gestion des objectifs, puis une brique de calcul des primes, puis une brique de gestion des employés… Et rapidement, tout se mélange.
A ce moment, transactionnel et décisionnel ne font plus qu’un. Le système décisionnel n’est donc plus une finalité : on commence à y entrer directement des données.
Indicateur : les rôles des utilisateurs
Et là, c’est grave. Grave au sens décisionnel bien sûr. Car, dans la théorie, on ne doit jamais venir modifier le datawarehouse de manière « manuelle ». Ne doivent se trouver à cet endroit que des données validées, testées et consolidées.
Et pourtant, il m’arrive de voir des système dits « décisionnels » dans lesquels les utilisateurs (ou tout du moins certains « power users ») peuvent modifier directement le contenu des dimensions (clients, produits). Si vous voyez ceci arriver : prenez garde ! Posez vous la question de savoir si ce que les gens appellent système décisionnel en est un réellement !
Les erreurs (humaines) peuvent être nombreuses avec cette méthode (les utilisateurs ne seront sans doute pas conscient de l’impact d’une « petite » modification) et surtout, le système décisionnel n’est plus un système automatique. Risquant d’être corrompu, les utilisateurs peuvent alors potentiellement voir des chiffres faux et perdre confiance dans le système.
Décisionnel n’est pas CRM ni applicatif
Gardez en mémoire qu’un datawarehouse doit être alimenté par des sources identifiées et traitées en amont, non par des modifications « en direct » faites par des utilisateurs.
Souvenez vous que ce n’est pas un CRM, ce n’est pas un infocentre, ce n’est pas une juste base de données transactionnelle de suivi d’activité. Cela doit rester un lieu de stockage dimensionnel, d’historisation et de référence pour des analyses.
Et pour vous ? Comment cela se passe t-il sur vos projets ? Avez vous vu des systèmes décisionnel qui n’en étaient pas ?
Tags: Discussion
8 commentaires pour “Caractéristique de la BI : « Un système décisionnel n’est pas tout le système d’information »”
Poster un commentaire
Bonjour Thomas,
De ma modeste expérience, je peux dire qu’il arrive souvent que les utilisateurs (ou power users) ne prennent pas le temps de corriger la donnée en amont mais plutôt en direct pour des raisons plutôt peu valables : « c’est urgent », « c’est ponctuel » donc pas le temps ou le besoin de modifier le processus de traitement de la données…).
Parfois, ils préfèrent s’astreindre à corriger la donnée avant intégration par habitude « car ce n’est pas grand chose » (!)
Mais je dois dire que ce n’est pas la faute exclusive des utilisateurs : il arrive souvent que cette « résignation » à passer en mode manuel soit dûe à la faible réactivité des équipes en charge de la maintenance et peut-être aussi au peu de documents d’exploitation permettant un support efficace.
Paradoxalement, la déviance du système décisionnel vers un mix SI/BI provient en fait d’un atout phare d’un système décisionnel : la concentration au sein d’un même système d’informations hétérogènes !
De là à l’enrichir directement, il n’y a qu’un pas (allègrement franchi) : l’architecture existe déjà, pas besoin de phase d’intégration…. malheureusement quid de la fiabilité et la cohérence des données ?
Mais je ne me plains pas trop, sinon nous n’aurions plus de rôle de conseil et d’expertise à faire valoir.
Le plus frustrant étant de ne pas avoir toute latitude pour amener un changement car cela implique des processus de gouvernance qui ne sont pas du ressort de la BI : nous ne pouvons que les conseiller fortement et non les impulser.
Bonjour Kitine et merci pour ce commentaire.
Effectivement, le moment où doivent être corrigées les données est souvent difficile à identifier et, de plus, dépend de l’appréciation de chacun. Faire un système entièrement automatisé n’est pas une chose aisée !
Je suis d’accord avec le coté « c’est parfois la fautes aux équipes », « manque de docs », « c’est pas bien pensé », « tout n’est pas prévu »…
Pour autant, il faut aussi reconnaitre que les clients n’ont pas toujours la bonne implication (oui oui, je sais, c’est à nous de les motiver et leur expliquer !), le bon choix ou tout simplement les possibilités. En effet, certains clients estiment parfois qu’il est plus simple de continuer à faire des petites modifications « a la mano » de temps en temps plutôt que définir une super règle compliquée et tout et tout (syndrome du « On va pas faire tout ça pour juste ce petit truc ?? »). Il n’y aurait pas un coup de Pareto (80/20) à trouver là dedans ?
Concernant le fait que les problèmes proviennent de ce qui est originellement un avantage, c’est certains ! Je pense que c’est justement à ce stade que nous devons intervenir et correctement lister les avantages/inconvénients d’un système décisionnel bien distint !
Enfin, tout cela nous apporte du travail : bonne remarque. Bon attention, c’est pas une raison pour faire du mauvais boulot hein ! 😉
De toute manière, c’est effectivement souvent le client qui décide : reste à bien ficeler nos argumentaires pour leur faire comprendre (et imaginer) la situation catastrophique vers laquelle ils peuvent se diriger s’il y a trop de « mix » SI/BI !
Thomas.
PS : désolé pour le temps de réponse.
Hello,
Je me permets d’ajouter 2 remarques à cet article (et aux commentaires qui suivent).
La première concerne l’aspect « développement au fil de l’eau ». Pour moi, ce n’est pas une mauvais chose, j’irais même jusqu’à dire au contraire ! L’approche « big bang » prônée il y a quelques années à fait long feu. Ceci dit, je suis d’accord pour dire que si cette construction progressive ne se fait pas de manière réfléchie, on aboutie bien souvent à un SID « inagile » et très cher à maintenir. Au point que certaines évolutions se transforment finalement en nouveau départ pour le SID.
La deuxième concerne la gestion de la qualité de la donnée. Je crois que nous n’abordons qu’une partie du problème. En effet, quand il s’agit de qualité de la donnée – et en particulier sur la correction – on doit adresser :
– un volet fonctionnel : définition des règles de gestion, un seuil d’acceptation d’un montant, par exemple
– un volet technique : mise en place de ces règles ainsi que de règle de gestion de la qualité technique de la donnée. Cohérence des types de champs, par exemple
mais bien souvent, on omet le troisième, qui me semble majeur dans les exemples proposés :
– un volet organisationnel : en particulier répondre à la question « qui fait quoi lorsqu’une correction de donnée est nécessaire ? ».
D’expérience, il me semble que nous n’avons pas toujours la capacité (pour ne pas dire le pouvoir politique au sein de l’entreprise) pour adresser ce dernier aspect… mais ça vaut peut-être le coup de ne pas l’oublier 😉
Bonjour Vincent et merci pour vos remarques !
Tout à fait d’accord avec le commentaire concernant le développement au fil de l’eau. Mais je me suis sans doute mal exprimé dans l’article : je ne voulais pas critiquer le fait qu’on ne développe plus, de nos jours, des projets en mode « big bang » (nous reviendrons d’ailleurs sur ce point dans un futur article). Dans le cas présent, j’entendais que les développements ont été fait « à la chaine », sans concertations et un peu « chacun dans son coin », sans reprendre véritablement les apports des autres projets. Sans comprendre non plus que certaines choses doivent être réservées au décisionnel (par exemple, la dimension « Produit » dans un existant BI à destination du marketing ne doit pas être completée (voir modifiée en profondeur) pour être utilisée (directement, sans faire de copie-synchro, mais en utilisant la même table) dans un projet transactionnel de CRM donc l’administration des ventes a exprimé un besoin !
Du coup, je trouve la remarque « certaines évolutions se transforment finalement en nouveau départ pour le SID » tout à fait pertinente !
Concernant la qualité de données, je trouve votre classification très juste.
Le volet « organisationnel » peut même être étendu : le client a souvent du mal à comprendre (ou à vouloir prendre le temps de définir) le processus de gestion de la donnée source, surtout manuelle, pas uniquement lors des corrections mais dans toute la phase d’alimentation.
Le seul « pouvoir » que nous ayons sur ce point est de mettre des alertes, de jouer notre rôle de conseil et d’identifier, tôt dans le projet, les personnes clés et qui seront mises à contribution tout au long de la vie du projet et du système.
[…] Caractéristique de la BI : « Un système décisionnel n’est pas tout le système d’information» : http://www.cogoobi.com/blog/2009/02/15/caracteristique-bi-systeme-decisionnel-pas-tout-le-systeme-in… […]
je prone pour ma part un certain pragmatisme.
L’essentiel est que l’utilisateur puisse faire ce qui lui plait à nous de stocker les données intelligemment. La seule contrainte est le coût mais aussi l’agilité des interfaces entre systèmes de production et système décisionnels. Soyons franc, tout cet agencement complexe sert à masquer la coexistence d’un système normé avec un système dénormalisé mais est-ce aux utilisateurs à en subir les contraintes ? La seule réserve est au demeurant sécuritaire et il s’agit dans ce cas de conserver la piste de transformation des données ce qui effectivement n’est pas une mince affaire. Quant aux performances : il faut reconnaître qu’avec des masses de données conséquentes : les calculs et intégrations préalables sont bien les seuls remèdes pour des temps de restitution acceptables : un jour viendra… mais viendra t il ?
Article très intéressant.
Merci pour ces infos.
Merci pour votre sympathique remarque 🙂