Le décisionnel : trop de fonctionnalités méconnues

Depuis de nombreuses années, les analyses d’activité en entreprise sont réalisées dans le tableur. Quel intérêt les personnes qui utilisent le tableur ont-elles à passer sur un environnement décisionnel ? Qu’est-ce que cela va leur apporter de plus ?

Usage sous-dimensionné des solutions décisionnelles

Comme déjà énoncé dans un précédent article (« Le projet décisionnel : pour les utilisateurs, mais surtout avec les utilisateurs »), le projet décisionnel s’appuie sur une analyse des besoins des utilisateurs.

Mais comment un utilisateur peut-il exprimer ses besoins s’il ne connait pas le « champ des possibles » ?

Il va simplement indiquer ce qu’il fait aujourd’hui, donc faire un état des lieux, ou livrer des expressions très générales, donc très vagues, telles que « analyse des retours clients sur 3 mois », ce qui ne donne aucune indication sur le mode d’analyse (forme du tableau, usage de couleurs, utilisation d’un graphe, type de graphe, …).

De plus, lors des formations sur les outils de restitution, j’ai pris conscience que l’usage des outils décisionnels est le plus souvent bien loin du potentiel mis à la disposition des utilisateurs, ce qui représente un gaspillage pour l’entreprise : pourquoi dépenser autant pour un usage aussi restreint ?

Il est bien sûr impossible, dans un article, de balayer les fonctionnalités très nombreuses présentes dans ces solutions.

En voici une parmi d’autres, dont l’intérêt est lié aux réactions des stagiaires lorsque je leur présente en formation.

Simplification des analyses avec le « drill » et le formatage conditionnel

Le « drill » est un mot anglais qui est devenu un barbarisme informatique dans la langue française.

Cela correspond au fait de pouvoir naviguer dans les couches de données d’un document qui se présentera toujours de manière synthétique.

Cette fonctionnalité est très souvent méconnue des utilisateurs. Lorsqu’ils la découvrent, ils regrettent de ne pas l’avoir connue plus tôt, ce qui leur aurait permis de demander sa mise en œuvre lors du projet.

Présentation du « drill »

Prenons l’exemple ci-dessous.

Il s’agit d’un tableau croisé synthétique présentant l’activité par année et par pays.

Constatez la présence d’un message près de la souris, indiquant qu’il est possible de descendre d’un niveau en cliquant sur la cellule visée.

Le « drill down » permet de descendre d’un étage dans les données pour atteindre les trimestres d’une année, les lieux de séjour d’un pays, ou tous les couples « trimestres/lieux de séjour » d’un couple « année/pays » (exemple présenté ci-dessous).

Cela permet de rester dans un tableau synthétique, tout en « naviguant » dans les données.

A l’inverse, le « drill up » permet de remonter.

Couplage avec le formatage conditionnel

Le tableau du 1er niveau présente un inconvénient. Comme il est synthétique, les valeurs qui s’affichent au niveau « année/pays » masquent d’éventuelles anomalies liées à des valeurs situées plusieurs niveaux en dessous. En effet, les valeurs particulièrement hautes compensent les valeurs trop basses, ce qui fait apparaître un montant « normal » au niveau le plus haut.

Si on ajoute un formatage conditionnel dans ce tableau, il devient alors possible d’attirer l’attention sur ce type de situation.

Dans le tableau ci-dessous, vous constatez que la valeur qui se trouve à l’intersection du couple 2000/US est rouge alors qu’il n’y a apparemment rien à signaler.

Cela est dû au fait que l’un des couples mois/type de service situé 2 niveaux plus bas n’a pas atteint le seuil qui a été fixé. Il ne reste plus qu’à descendre dans les niveaux en « pistant » la couleur rouge.

Tableau obtenu en descendant d’un étage dans les données :

Tableau obtenu en descendant à nouveau d’un étage dans les données :

On obtient ainsi un tableau pratique à utiliser, permettant de « suivre la piste » d’une anomalie signalée par la mise en œuvre d’une règle de gestion.

Pour réaliser ce type de document, il est nécessaire d’avoir exprimé ce type de besoin pendant la phase d’analyse afin que l’environnement décisionnel ait été développé dans ce sens.

Cela nécessite donc bien que les utilisateurs sachent que cela existe pour en déclarer le besoin.

Comme nous l’avons découvert dans la partie 1 le fait que les utilisateurs ne connaissent pas les fonctionnalités présentes dans les solutions décisionnelles ne leur permet pas d’exprimer leurs besoins en ce sens.

Vous trouverez ci-après d’autres exemples correspondant à cette situation, et qui séduisent particulièrement les participants des formations, mais donnent trop souvent lieu à la conclusion « Ah, si j’avais su ! ».

Les fonctions MDX

Les fonctions MDX sont des fonctions de calcul qui peuvent être utilisées dans des environnements multi-dimensionnels. Elles permettent de naviguer dans des hiérarchies de données.

Beaucoup d’entre elles, tout comme la fonction SI proposée dans Excel, ont besoin d’un nombre limité d’arguments pour être mises en œuvre. Pour des usages courants, elles sont donc à la portée de nombreux utilisateurs.

Lorsque le choix a été fait de déployer un logiciel de cette famille, pas de surprise, mais surtout pas de déception, de la part des utilisateurs : le projet a été réalisé dans ce sens.

Par contre, lorsque la solution retenue n’est pas exclusivement multidimensionnelle, comme par exemple Cognos BI, il faut que le projet ait tenu compte de cette spécificité, ce qui conduit les développeurs à créer des hiérarchies.

Prenons l’exemple de la hiérarchie Temps, partiellement représentée ci-dessous.

 

Les fonctions MDX permettent donc de naviguer dans cette hiérarchie, et de trouver les indicateurs souhaités. Elles permettent par exemple, à partir d’un membre d’une hiérarchie, de trouver le membre équivalant en se déplaçant dans celle-ci.

Ainsi ParallelPeriod( semestre ; 1 ; nov ) = 130k€.

En effet, nov étant l’avant dernier membre du 2ème semestre, la fonction ainsi renseignée permet de pointer sur l’avant dernier membre du semestre précédent.

De même, ParallelPeriod( trimestre ; 3 ; déc ) = 150k€, soit les revenus du mois de mars.

D’autres fonctions permettent d’atteindre les enfants, les parents, la fratrie du membre déclaré dans la fonction.

Cela permet donc de construire des tableaux de bord de manière rapide.

Vous trouverez ci-dessous 2 documents réalisés avec des fonctions MDX.

1er exemple :

À l’exécution de ce document, l’utilisateur doit choisir une période..

Le tableau fait apparaître les revenus de ce mois, ainsi que ceux du même mois de l’année d’avant, avec l’évolution entre ces 2 mois.

Les 3 colonnes suivantes correspondent aux revenus cumulés depuis le début de l’année pour chacun de ces mois, ainsi que l’évolution entre ces périodes.

 

2ᵉ exemple

Cette fois encore l’utilisateur choisit un mois, en l’occurrence Sept 2011.

Le tableau affiche les revenus des 3 meilleurs produits du même mois de l’année précédente et leurs revenus pour le mois demandé, ainsi que l’évolution entre les 2 mois.

En dessous, même chose pour les 3 meilleurs cumulés, pour les Autres produits, et enfin pour l’ensemble des produits.

 

Dans ces 2 exemples, l’intervalle aurait pu être laissé au choix de l’utilisateur afin de lui permettre d’analyser l’évolution annuelle, semestrielle, trimestrielle, …

Il est bien sûr possible de réaliser ces documents sans avoir recours aux fonctions MDX. Cela prendrait beaucoup plus de temps, en raison de la nécessité de créer des formules de calculs beaucoup plus longues et bien plus complexes.