Quid des termes décisionnels

1. De nombreux termes pour de nombreux concepts

S’attaquer au décisionnel, c’est faire face à de nombreux concepts et de nombreux termes, parfois mal utilisés, parfois évoquant la même chose et souvent associés à des concepts différents suivant la personne qui l’utilise.

Si certains des termes évoqués ci-dessous ne sont actuellement pas connus du lecteur, ils seront en revanche par la suite utilisés dans l’ouvrage.

2. Détails par catégorie

a. Le projet : décisionnel, aide à la décision ou la Business Intelligence

Ces expressions évoquent toutes les trois l’ensemble des méthodes et applications mises en œuvre pour répondre à un besoin analytique sur la base de données, non exploitable à ce but en l’état, pour cause de format non explicite ou de volumétrie importante, par exemple.

Si la "Business Intelligence", parfois traduite par "intelligence d’affaires, et son acronyme "BI" sont juste censés être l’équivalent de "aide à la décision" en anglais, ces termes sont parfois utilisés pour désigner la seule couche de restitution visuelle de la donnée, quand ce terme désigne en réalité l’ensemble des couches...

La justification du décisionnel

1. Des données et un besoin déjà présents

a. Un besoin analytique

Le système d’information décisionnel (noté SID par la suite) répond-il à un besoin existant ou bien le produit crée-t-il lui-même le besoin ? Les deux. Le SID répond à un besoin déjà existant, mais sa mise en place va appeler de nouveaux besoins.

Dans la réalité des faits, la mise en place d’un SID permet - souvent - uniquement de pérenniser, fiabiliser, simplifier un processus déjà existant. Un manager demande régulièrement un rapport d’activité ? Les analystes métier demandent des tableaux de données ? Il s’agit bien de "décisionnel", et pourtant, ces demandes existaient bien avant le SID. Sauf que ces données ne peuvent être fournies que par des informaticiens travaillant sur les bases de données de l’entreprise.

Les limites sont explicites :

Mauvaise réactivité : nécessite de demander l’information à une personne tierce.
Coût humain : temps consommé par les informaticiens pour produire ces rapports ou listings.
Coût matériel : impact de la génération de ces rapports et listings sur le système transactionnel.

Autre constat : si le besoin existe, les éléments de réponses aussi. En effet, puisque la DSI arrive à produire le rapport ou listing demandé, c’est que les données nécessaires existent bien quelque part dans l’entreprise : le décisionnel est donc une valorisation des données existantes ! Il n’est donc pas nécessaire (la plupart du temps) de créer de nouvelles données, c’est-à-dire une nouvelle application de saisie consommatrice de temps.

b. Bien qualifier ce besoin

Comme évoqué dans l’avant-propos, le décisionnel ne doit pas être réduit à la production de restitutions puisqu’il s’accompagne de la mise en place de nombreux concepts et technologies. Sa mise en œuvre est donc souvent lourde et coûteuse et il convient donc de s’assurer que le décisionnel répond bien au besoin.

La restitution des données...

Mise en œuvre du projet

1. Les étapes

Une fois le projet identifié comme projet décisionnel, la conception du SID se décompose en cinq étapes :

Identification du besoin client : spécification de maquettes de restitution ou d’indicateurs à fournir.
Spécification de la base de données décisionnelle.
Identification des données sources nécessaires.
Identification des données sources disponibles.
Spécification de l’alimentation de la base de données et des restitutions.

La base de données décisionnelle est la boîte noire qui se trouve entre les données sources et les restitutions utilisateurs. Il est donc primordial de bien avoir identifié l’entrée et la sortie de cette boîte noire avant de se lancer dans la base de données décisionnelle.

Idéalement, le modèle de données est censé être indépendant des technologies retenues, que ce soit pour l’intégration de données, mais surtout pour la couche multidimensionnelle et les restitutions. Mais, concrètement, certaines adaptations du modèle seront nécessaires suivant la solution applicative retenue. Ainsi, il est préférable - avant de se lancer dans la modélisation - d’arrêter ce choix et de se renseigner quant aux limites et préconisations...

Identification du besoin

1. Identifier les utilisateurs cibles

Les utilisateurs potentiels du décisionnel sont de deux catégories :

Décideurs : actuels demandeurs de chiffres.
Analystes métier : ceux qui consomment de la donnée ou transforment de la donnée brute en indicateurs métier.

Les deux demandes sont liées : les premiers vont utiliser des indicateurs agrégés pour piloter l’entreprise, mettre en perspective les performances de l’activité avec ses objectifs. L’analyste métier aura quant à lui à charge d’identifier avec précision les comportements à un niveau plus fin afin d’atteindre des objectifs macro, ou déceler des défaillances.

En plus d’être consommateurs de la donnée, les analystes métier ont un rôle primordial, car ce sont eux qui possèdent les règles métier et sont à même de fournir les règles de construction des axes d’analyse et des indicateurs.

Les ateliers devront donc être faits avec ces utilisateurs pour définir le besoin.

En revanche, ne sont pas supposés être clients du décisionnel :

DSI : même s’ils sont souvent liés à l’ancien processus de fabrication des reportings en fournissant la donnée issue des systèmes sources, les membres de la DSI ne sont pas consommateurs finaux de sa donnée, et sont à terme voués à disparaître du processus de fabrication des rapports. Attention : si la DSI désire piloter et suivre son activité via le décisionnel, alors elle est cliente du décisionnel mais au même titre que n’importe quel autre département, sans particularité liée au fait qu’elle eut produit des reportings.
SI sources : même s’ils sont propriétaires de la donnée source du SID, ils ne sont pas forcément consommateurs des résultats fournis par le décisionnel, notamment parce que les indicateurs sont multimétier et dépassent le périmètre métier du SI source.
Opérateurs...