Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter

Abonnez-vous maintenant et nous vous tiendrons au courant.
Nous respectons votre vie privée. Vous pouvez vous désabonner à tout moment.

Le mal être des projets décisionnels

En 1996, en tant que prestataire de services sur un projet dans le cadre de l’hôtellerie, j’ai eu à mettre en place des tableaux de bord à l’aide d’un infocentre. Cet exercice s’est révélé assez compliqué. En effet, créer des tableaux de bord avec des dizaines de données comparatives sur plusieurs critères, le tout basé sur un modèle de données opérationnel, était loin d’être une partie de plaisir !
Depuis, techniques d’implémentation, méthodologie et définition des besoins ont largement progressé. Pourtant plusieurs années plus tard, la manière dont sont menés la plupart des projets décisionnels continue de poser nombre de questions.
Il y a quelques mois, j’ai dû dans le cadre d’un de mes projets décisionnels, récupérer des données dans un entrepôt qui était modélisé en étoile et ce, afin d’alimenter mes propres modèles en étoile ! J’ai alors analysé le contenu de cet entrepôt « décisionnel » afin de vérifier si sa structure ne pouvait pas être utilisé telle quelle (note : l’entrepôt appartenait à une autre instance externe à mon client et était notre seul source de données).
Quelle ne fût pas ma surprise quand j’ai constaté que la modélisation mise en place était générique et non orientée information : que les attributs définissant une information étaient présentes en lignes et non en colonnes.
L’information si importante aux décideurs était bien présente et la « généricité » mise en place permettait une évolution aisée du périmètre fonctionnel.
Pourquoi pas ?
Mais avec une telle modélisation, comment peut-on répondre aux besoins libres d’utilisation de ces informations par un utilisateur ? Comment faire avec un outil de restitution, pour présenter dans un même tableau, des informations en colonnes ?
Une modélisation générique implique la mise en place de tableaux de bords statiques et difficiles à mettre en œuvre (développement spécifique pour chaque information) et donc non évolutifs face aux besoins toujours changeants des utilisateurs.
J’ai donc utilisé cet entrepôt comme réservoir de données et mis en place un processus d’alimentation complexe de mon modèle : la récupération de chaque information (caractéristiques et valeurs) pour une date donnée, impliquait une requête spécifique. Chaque processus d’alimentation devait effectuer un « pivotage » des données extraites en lignes pour les insérer dans autant de colonnes :

En bref et c’est l’objet de cet article, ce n’est pas parce qu’un modèle est en étoile que nous sommes en présence d’un modèle décisionnel répondant aux besoins des utilisateurs.
Nous ne répèterons jamais assez qu’un Système d’Information Décisionnel se conçoit et repose entièrement sur son contenu fonctionnel qui doit porter sur le métier de l’utilisateur afin de lui permettre d’effectuer des rapprochements et des consolidations non prédéfinis afin d’analyser des phénomènes évoluant dans le temps.
Dans un prochain article, j’expliquerai l’architecture de référence d’un projet décisionnel et comment doit être conçu les modèles.
Patience ….

1 réflexion sur “Le mal être des projets décisionnels”

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *