« J’ai l’impression d’avoir compris votre besoin, je suis en mesure d’extraire toutes les données dont vous avez besoin et voilà comment j’imagine le rapport final » … Tel pourrait être le titre de ce chapitre. La spécification des restitutions est une phase importante dans le développement logiciel et peut être à plus forte raison encore dans un projet d’informatique décisionnelle ; la restitution en elle-même étant centrale dans ce type de projets.  Compte tenu de l’aspect quelque peu répétitif des différents rapports qui ont été maquettés nous n’allons pas détailler le contenu des différentes maquettes, contenu qui a déjà été abordé dans les phases précédentes. L’objectif est ici surtout de d’évoquer brièvement…

Dans leur Atelier-Données du 5 juillet 2021 (Rivet & Valeins, 2021) mettent en évidence le coût de la non-qualité des données en ces termes :  « Harvard Business Review estimait en 2017 qu’une tâche effectuée avec une donnée erronée engageait un coût 100 fois supérieur à celui d’une tâche réalisée à partir d’une donnée initialement vérifiée et correcte. » puis nous alarment sur l’étendue de la problématique « Selon l’analyse Gartner 2020 sur les solutions de gestion de qualité des données, plus de 25 % des données critiques des plus grandes entreprises sont erronées, au point que le coût moyen d’une mauvaise qualité des données pourrait s’élever à 11M€ par an pour les organisations.…

Cette première analyse globale qui permet d’obtenir une vue d’ensemble, et qui a été esquissée ci-dessus, doit ensuite être complétée par une analyse détaillée du besoin. Cette analyse détaillée reposera sur une revue des différents indicateurs et des axes d’analyse présents dans les différents rapports demandés. Cette partie présente un aperçu de ce travail. Dans les faits, c’est une longue et minutieuse phase d’exploration de la base de données. Axes d’analyse ou dimensions ? : A ce stade nous n’évoquerons pas la notion de dimensions car aucune modélisation dimensionnelle n’intervient pour l’heure. Aucun entrepôt de données n’est envisagé dans l’immédiat et rien ne nous garantit d’ailleurs que celui-ci répondrait aux exigences de…

Maintenant que nous connaissons « les grandes lignes » des rapports qu’il conviendra de produire et dans la mesure où aucun cahier des charges n’a été établi, ni aucune analyse détaillée faite, l’enjeu pour la maitrise d’œuvre est de  « sécuriser » la base de la conception en élaborant des prémaquettes pour vérifier l’adéquation entre ce qui a été compris par la MOE et ce qu’a voulu exprimer le « client » (le MO). Pour chacun des rapports la DSI produit un tableau Excel (voir les figures ci-dessous) basé sur les différentes explications successives et complémentaires formulées par les salariés impliqués dans ce projet lors des différents échanges qui ont suivi la…

« Ok, on y va ! » Certes, mais à vrai dire on va vers quoi, on va où ? Au-delà de l’esquisse de l’architecture logicielle et du potentiel avéré de restitution qui ont été présentés, au fond, quels sont les besoins précis, que devons-nous retrouver dans chaque rapport ?  Tel est l’enjeu de la collecte des besoins. Cette phase qui consiste à interroger les parties prenantes du projet (salariés, managers, direction) doit, en toute logique, permettre d’évaluer les besoins des utilisateurs et se solder par un « bilan d’interview » (Corbillé & Dumas, 2006). Disons les choses simplement : Si nous abordons le sujet selon la méthodologie en cascade ou un cycle de développement en…

L’étude préalable consiste à définir le cadre général du projet, les fonctionnalités attendues, les contraintes techniques et budgétaires, les risques, ainsi que les différentes solutions possibles pour répondre aux exigences du projet. À la fin de l’étude préalable, dans un cadre théorique idéal, une proposition de solution est présentée aux parties prenantes du projet. Cette proposition inclut une description détaillée du projet, une estimation des coûts et des délais, ainsi qu’un plan d’action pour la réalisation du projet. En réalité les choses sont parfois quelque peu différentes, nous le verrons plus loin. Mais revenons donc pour l’instant aux fondations de ce projet décisionnel, à savoir sur le besoin exprimé initialement…

Tout projet peut être caractérisé par 3 dimensions : Coût, Délai et Qualité.  La qualité porte ici le sens défini par l’ISO 9000 : “L’aptitude d’un ensemble de caractéristiques intrinsèques à satisfaire des exigences”. Cette triple dimension du projet est généralement représentée par ce que nous nommons le triangle d’or du projet. Cependant en matière de gestion de projet cette mise en œuvre du Portail de Restitution de données au sein de l’entreprise Pythagore Immobilier est caractérisée par un schéma singulier, celui d’un projet qui devait être réalisé :  –      En Interne –        Sans aucun budget spécifique alloué –        En temps masqué –        En fonction du temps disponible mais, tout de même,…

Une étude[1] réalisée, pour le compte de l’éditeur Report One, en 2013, soit il y a plus de dix ans, posait le cadre de l’usage de l’informatique décisionnelle en PME. L’étude en question mettait en évidence un marché en progression de 30% par an entre 2008 et 2013. Une appétence forte donc pour ce domaine mais, comme le souligne l’enquête « le phénomène [restait] nouveau et il [fallait] encore démocratiser l’outil ». Par ailleurs, et c’est peut-être le point qui nous intéressera le plus dans cette série d’articles, car il explique, en partie du moins, l’origine du projet décisionnel sur lequel nous allons nous attarder, « Les solutions historiques comme…