https://wordpress.org/
FranceBelgique
Data, Digital

Le suivi de projet en informatique décisionnelle

Publié le 06/05/2021
Partager sur :

La Business Intelligence (BI) ou informatique décisionnelle est un processus technologique donnant aux entreprises des outils de prise de décisions stratégiques et opérationnelles.

Ce processus s’appuie sur l’analyse des données, qui sont tout d’abord extraites, modifiées, et chargées à partir d’un outil spécifique : l’ETL (Extract, Transform, Load). Puis, elles sont stockées dans un Data Warehouse (entrepôt de données) afin d’en obtenir une intelligence que l’on présente via des outils de restitution. C’est ce que l’on appelle la chaîne d’information décisionnelle.

A partir des critères donnés par Ralph Kimball, considéré comme la référence dans le domaine, il est possible d’adapter des méthodes telles que le cycle en V ou même l’agilité, au suivi d’un projet d’informatique décisionnelle. L’enjeu ici est double : il concerne le choix de la méthode et son adaptation au cadre décisionnel.

Le cycle en V dans le suivi d’un projet d’informatique décisionnelle

Le cycle en V est constitué d’une phase descendante puis d’une phase ascendante et repose sur un développement de bout en bout potentiellement long. Il évite les retours en cas d’anomalie rencontrées car on délègue intégralement la fabrication de l’application jusqu’à la livraison finale.

Principe du cycle en V
Principe du cycle en V

Avantages :

  • Sécurité : chaque phase ne débute qu’à partir du moment où la phase précédente a été clôturée
  • Préparation : l’étude des spécifications est menée avant tout développement
  • Contrôle : un système de vérification est mis en place en face de chaque phase de spécification.

Inconvénients :

  • Gestion du changement : le cycle en V ne prévoit pas de nouvelles décisions dans un cycle. Il faut alors intégrer les changements entre deux cycles.
  • Flexibilité : du retard dans la phase de spécification impliquera une réduction du temps accordé aux tests, mettant en péril la qualité du produit livré.

La dépendance à une ou plusieurs sources de données externes est un point différenciant des projets décisionnels. Il peut avoir des conséquences importantes puisqu’il sera difficile d’avancer dans les phases et de proposer des dates de livrables lorsqu’un élément critique sort du périmètre de l’équipe projet.

Etape 1 : lancement du projet

On commence la réflexion en examinant le produit final et l’aide décisionnelle demandée. Puis, on remonte les phases pour déterminer comment la mettre en œuvre.

Microsoft Azure Cosmos DB : les leçons d’une faille majeure
Trending
Microsoft Azure Cosmos DB : les leçons d’une faille majeure

Pendant cette étape est produite la documentation indiquant les activités à mener pendant le projet.

Etape 2 : interviews utilisateurs

Cette étape est cruciale car elle permet d’être en adéquation avec le besoin utilisateur et de s’assurer de la valeur métier attendue. En effet, en décisionnel, les utilisateurs sont les seuls à définir le projet et les besoins.

Pour aider à la prise de décision, il faut réussir à penser comme l’utilisateur, être fonctionnel en utilisant les informations qu’il nous donne. On n’abordera donc pas l’aspect technique avant l’étape des spécifications détaillées.

Etape 3 : spécifications fonctionnelles

On répond ici à la question « quoi ? ». En décisionnel, cela consiste à :

  • Dresser la liste des indicateurs avec leur définition fonctionnelle, la liste des axes et leur hiérarchie avec précision. Cela constitue le dictionnaire de données
  • Définir les rapports constituant le(s) reporting(s) à livrer
  • Dresser la liste des sources de données
  • Définir l’architecture fonctionnelle. Celle-ci correspond aux blocs majeurs du système, pour commencer à rentrer dans le détail tout en gardant une vue du besoin et des problématiques métier.
  • Mettre en place le MCD (Modèle Conceptuel de Données) opérationnel : celui-ci est souvent négligé mais doit être validé par l’utilisateur. Il correspond à la structure fonctionnelle existante de l’activité considérée mais devra être dénormalisé en vue de l’étape suivante.
  • Mettre en place le MCD décisionnel. Il donne une vision transversale pour aider au pilotage et à la prise de décision. On l’intègre dans l’ETL pour l’alimentation. On cherche en général à avoir des requêtes simples qui répondent directement au besoin utilisateur.

Par exemple, si l’on cherche à connaitre le nombre de trains d’un pays à un autre à une date donnée, le MCD opérationnel peut ressembler au schéma suivant :

Exemple de MCD opérationnel
Exemple de MCD opérationnel

Une fois dénormalisé, on peut obtenir un MCD décisionnel comme suit. Ici, l’entité « Gare » apparait deux fois pour répondre au besoin décisionnel alors qu’opérationnellement elle ne doit apparaitre qu’une seule fois puisqu’elle représente un seul et même concept.

Exemple de MCD décisionnel
Exemple de MCD décisionnel

Etape 4 : maquette

Lors de cette étape, on répond à la question « comment ? ». On se focalise sur l’ergonomie de l’application et le rendu final qui, en décisionnel, est le plus souvent de deux types :

  • Reporting : tableaux de bords (2 dimensions)
  • Cube (n dimensions)

Il s’agit ici de mettre en place rapidement des masques de navigation avec des rapports prédéfinis en local pour montrer aux utilisateurs ce qui leur sera livré visuellement. Il faut montrer une image dynamique des futurs livrables. On rédige pour cela des scénarios que l’on va dérouler devant l’interlocuteur, lui permettant ainsi de valider l’intérêt du projet. Cette étape se conclut par la rédaction d’un compte-rendu de maquette rapportant les remarques remontées lors des présentations utilisateurs.

Etape 5 : spécifications détaillées

En continuité avec l’étape de maquette, on répond ici à la question « Comment ? ». L’aspect technique est abordé. A titre informatif, les éléments constitutifs des spécifications détaillées en décisionnel sont :

  • Pour préparer l’implémentation dans un SGBDR, il faut prévoir le MPD (Modèle Physique de Données) du Data Warehouse car ce modèle se rapproche des contraintes des logiciels de base de données. On définit les tables, les champs, les identifiants (clés primaires et étrangères). On étudie aussi la performance (index, dénormalisation, etc.).
  • Dossier d’architecture technique
  • Définitions : Indicateurs, Axes (dimensions), Rapports, Gestion des droits
  • Procédures :
    • alimentation du Datawarehouse : incrémentielle, annuler/remplacer
    • reprise en cas d’échec
    • gestion des rejets
  • Spécifications de l’interface graphique (IHM)

Etape 6 : développement

Cette phase correspond à l’implémentation des éléments tels que définis dans les spécifications détaillées. Dans le cas du décisionnel, il s’agit le plus souvent de manipulation d’outils et d’écriture de requêtes SQL. On divise les développements en deux équipes :

  • L’une se charge de l’ETL pour l’alimentation du Data Warehouse
  • L’autre se charge de la restitution

On réalise des tests unitaires de chaque côté que l’on documente en considérant qu’à ce niveau, l’utilisateur connait l’outil.

Etape 7 : intégration et Recette

L’intégration consiste à mettre en commun les modules développés séparément : ETL et restitution. Puis démarre la phase de recette durant laquelle il faut tester l’outil, rechercher les défaillances, les corriger et alimenter un cahier de recette. Il peut exister plusieurs niveaux de recette selon l’utilité et le besoin auquel répond l’outil.

Erreurs à éviter dans la conduite du changement

La conduite du changement est menée en parallèle du cycle projet. Elle permet d’aider à l’acceptation des changements par les utilisateurs.

Dans le cas du cycle en V, il faut surtout éviter l’effet tunnel, lorsqu’un projet affiche du retard sur le plan initial et surtout donne peu de perspectives de progression et d’achèvement. Pour cela, il faut s’assurer de donner de la visibilité au client tout au long du projet et prendre en compte les contraintes qui peuvent s’ajouter.

Concernant les intervenants extérieurs au projet, il est nécessaire d’avoir de bons sponsors avant de débuter et ne pas hésiter à challenger ce que promettent les éditeurs des logiciels utilisés.

Comme pour tout projet, on ne doit s’engager que sur ce qui peut être réalisé. Il ne faut pas non plus susciter des espérances naïves grâce au décisionnel, comme « le décideur décidera mieux » ou « le chiffre d’affaire va augmenter ».

Enfin, concernant l’usage des données, une erreur courante est de proposer un MCD opérationnel plutôt que décisionnel et finalement de ne pas répondre au besoin utilisateur. Privilégier les chiffres en oubliant les données textuelles, orienter technique plutôt qu’utilisateur, mettre des données dans l’entrepôt rapidement pour qu’elles soient disponibles, sont des erreurs courantes en décisionnel.

L’agilité dans le suivi d’un projet d’informatique décisionnelle

Présentation des méthodes agiles

L’utilisation des méthodes agiles pour le suivi d’un projet d’informatique décisionnelle correspond à un processus continu. Ici, on ne mettra pas en place une solution BI complète “One Shot” mais plutôt via une succession d’itérations de taille et durée identique afin de permettre au projet de s’adapter aux besoins des utilisateurs. Les méthodes agiles proposent d’impliquer davantage le client durant la construction du produit. Le besoin n’est pas figé et peut évoluer tout au long du projet, s’adaptant aux contraintes et aux compréhensions progressives de celui-ci.

Ainsi, les méthodes agiles s’éloignent du modèle traditionnel en V dans lequel la communication entre développeurs et utilisateurs métier n’est pas une priorité. De plus, les développeurs se concentrent davantage sur les données et la technologie que sur le besoin de trouver des réponses aux questions importantes.

Concrètement, la BI Agile met en lien le Technique et le Fonctionnel, au lieu de se concentrer sur la réalisation complète d’une des trois étapes de la gestion de projet BI (ETL / DWH / Reporting). Ce dernier sera scindé en plusieurs fonctionnalités, elles même scindées suivant les étapes de gestion de projet BI. Ainsi lorsque chaque fonctionnalité sera achevée, elle sera intégrée à la précédente.

Gestion agile d'un projet d'informatique décisionnelle
Suivi agile d’un projet d’informatique décisionnelle

Etape 1 : le concept

La réussite du projet BI nécessite d’avoir des objectifs réalistes et clairs, associés à une phase d’étude de l’existant. Cette maîtrise stratégique va permettre d’anticiper et d’encadrer les délais.

Il est également important à ce stade de bien identifier les types d’informations dont les décideurs auront besoin pour améliorer leur pilotage par la data. Des indicateurs précis doivent donc être déterminés en gardant en tête le cadre stratégique du projet : un KPI (Key Performance Indicator) très global ou au contraire très spécifique ne sera pas nécessairement pertinent.

Etape 2 : l’initialisation

Au cours de cette étape, les parties prenantes vont prendre part au processus pour la première fois. On retrouve ici le premier point de Kimball puisque c’est l’occasion de mettre en avant les valeurs ajoutées de l’agilité pour le métier (meilleur suivi, transparence sur l’évolution, adaptation à un nouveau besoin). Par exemple, on peut ici définir les différentes priorités :

  • Former les acteurs du projet aux fondamentaux de l’approche agile ;
  • Identifier les principaux besoins et exigences de l’entreprise ;
  • Découvrir les sources de données disponibles ;
  • Comprendre les voies de diffusion de l’information : rapports, tableaux de bord ;
  • Établir l’ordre de priorité des exigences et des besoins opérationnels clés en tenant compte des contraintes de temps et de budget ;
  • Choisir le logiciel de Business Intelligence à utiliser.

Le plan d’action doit également préciser la hiérarchie et les tâches de chacun (RACI) en matière de suivi et d’implémentation du projet BI.

Etape 3 : la construction du projet

Il faut fournir un système fonctionnel répondant à l’évolution des besoins des intervenants. Il faut pour cela passer par cette étape en continu et à des intervalles fixes, généralement d’une à trois semaines. Plusieurs méthodes sont alors utilisées en fonction de leur compatibilité avec le projet et l’organisation de l’entreprise.

Pendant la construction, il est donc primordial de :

  • Élaborer des rapports collaboratifs ;
  • Utiliser la modélisation « juste à temps » (JAT) : identifier un problème à résoudre, faire appel à des sachants et explorer ensemble le problème, puis reprendre le travail ;
  • Finaliser les tests ;
  • Finaliser la documentation ;
  • Lancer le projet pilote dans un petit sous-groupe : le projet est testé en production sur une petite portion de son périmètre afin d’avoir une vision de ce que sera le Go Live et repérer les dernières lacunes ;
  • Former les utilisateurs finaux ;
  • Former le personnel de production ;
  • Déployer en production.

Etape 4 : la production

L’étape de Production est la phase finale de déploiement du projet (également appelée Go Live, ou Roll-Out). Pendant cette étape, il sera question de :

  • Exploiter et prendre en charge le système, les tableaux de bord et les rapports ;
  • Identifier les défauts et les améliorations. Tous ces changements doivent commencer à l’étape de la construction et se poursuivre jusqu’à la production.

Enfin, une fois en production, l’agilité permettra de faire évoluer le produit itérativement.

Conclusion

Ralph Kimball, dans son ouvrage The Data Warehouse Lifecycle Toolkit (1998), a donné 3 concepts pour le cycle de vie du Data Warehouse et du projet décisionnel. Ces concepts peuvent alors être mis en perspective des deux types de méthodologies évoquées dans cet article :

Suivi d'un projet d'informatique décisionnelle
Suivi d’un projet d’informatique décisionnelle – Synthèse

L’offre conseil « Data Solution » de HeadMind Partners permet d’accompagner ses clients dans leur transformation digitale autour de la Business Intelligence :

  • choix de la méthode de suivi de projet BI en fonction de l’environnement et des capacités de production de l’entreprise ;
  • implémentation de l’outil d’aide à la décision suivant la chaine d’information décisionnelle.

Article écrit par Anjana LARUE (Senior Consultant), Clody CORDETTE (Consultant) et Marc CHATELLIER (Supervising Associate) chez HeadMind Partners Digital

Sources

Derniers articles

Catégories

Veuillez saisir votre adresse email pour vous abonner. Envoyer