** Les éléments qui suivent sont l’image d’un point de vue subjectif, issus de mon expérience professionnel et des nombreuses conversations que je peux avoir avec mes collègues et amis présents dans l’écosystème du décisionnel, si vous ne vous y retrouvez pas, n’hésitez pas à le remonter dans les commentaires **
Ces derniers temps, un constat me saute aux yeux, une partie non négligeable des projets décisionnels périclitent, glissent, dérivent non pas par manque de compétences des consultants mais par absence totale de gestion de projet.
Pourquoi ce constat est plus frappant en décisionnel qu’en développement par exemple?
- Les projets B.I. peuvent être commandités directement par les équipes fonctionnelles (Contrôle de gestion, Pôle marketing, Direction …) et ne passent pas toujours par la case DSI.
- La mise en place d’applications répond à un besoin opérationnel qui est souvent plus facile à spécifier que les besoins analytiques qui sont par nature assez conjoncturels et sont amener à évoluer de manière rapide.
- Le manque de support sur la gestion de projet de la part du client, associé aux points ci-dessus, implique lors des régies une prise en charge de cette tâche par la MOA, la gestion de projet devient alors “gestion de planning”. Et là c’est le drame.
- Les 3 points ci-dessus sont d’autant plus cruciaux qu’en France le statut d’Architecte Décisionnel est soit délégué aux développeurs soit au Chef de projet et n’apparait que très rarement en tant que poste à part entière. Hors un développeur n’aura pas la latitude d’imposer une cohérence au système d’information décisionnel global de l’entreprise (Matrice de bus) tout comme la partie MOA ne saura pas forcément jauger de l’impact des solutions techniques mises en place par les équipes de développement.
Je suis intimement convaincu qu’aujourd’hui le décisionnel (En mode conseil) a le cul entre deux chaises, une DSI qui n’a pas les compétences pour gérer les projets de ce type, et des fonctionnels très demandeurs (quitte à passer outre la DSI depuis des années avec Access / Excel …) mais incapables de mesurer les problématiques techniques inhérentes à la mise en place d’un projet décisionnel d’entreprise (Historisation, Stockage, Sécurité).
Ajoutez à tout cela un autre challenge qui serait mettre en place une méthodologie Agile au sein de votre projet décisionnel et vous voilà partie vers l’inconnu le plus total. As tu essayé toi lecteur de faire passer dans une itération de deux semaines les éléments d’un projet B.I. ? J’en ai fait l’expérience récemment et voici le résultat sur une partie d’ETL :

Pourquoi les choses se sont passées comme cela ? Je vois deux raisons :
- Nous avons souvent la chance dans notre domaine de découvrir les données en même temps que nos clients, et nous ne sommes donc pas à l’abri de surprises qui nous obligent à attendre des retours de leur part (règle de gestion …)
- Faire un découpage assez fin pour réussir à livrer un élément en deux semaines c’est difficile, surtout lorsque rien n’est spécifié et que la qualité des données s’en mêle.
En conclusion, vous l’aurez compris, la gestion de projet B.I. nécessite un effort considérable car il est nécessaire d’allier :
- Architecture du système d’information (Modélisation dimensionnelle, cohérence des données …)
- Compréhension suffisante du fonctionnel pour pouvoir effectuer un découpage très fin des différents besoins (Et donc nécessité de récolter ces besoins)
- Gestion de planning
- Compréhension technique des solutions mises en place afin de s’assurer que le curseur “Maintenabilité” => “Performance” => “Rapidité de mise en place” ne soit pas déconnant (Éviter de finir par livrer un système qui fonctionne mais impossible à maintenir / faire évoluer)
Bon je râle, je râle mais quelle solution je préconise pour que cela se passe bien ? et bien une approche qui serait un mixe du DataWareHouse Lifecycle ToolKit 2nd Edition de Ralph Kimball, de SCRUM et d’outils tel que TFS et MSPROJECT
Je vais faire un papier plus long sur l’approche que j’envisage à l’avenir donc “Stay Tuned” !