** 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 » !
14 Comments
Je te rassure Charly, ce problème n’est pas que dans le décisionnel mais dans beaucoup de projets.
Tu as bien identifié quelques « pistes » mais personnellement, je pointerai le problème des compétences comme un point important.
En BI, on trouve énormément de « techniciens ». Rien de péjoratif là dedans mais on a des ressources qui savent faire exactement ce qu’on leur dit…et pas plus. Il est difficile donc de sortir du cadre, anticiper, gérer, amender, etc. correctement un « projet » BI.
PS : oublie la « tendance idéale » à-la SCRUM dans un projet BI; l’important c’est les utilisateurs et leur adoption (à combiner avec le wow-effect)
Ca rejoint ce que tu dis sur l’architecture et la gestion de projet mais ma conviction est que ce ne sont pas des rôles réservés… Une personne bien câblée saura prendre ces activités naturellement car il faut juste être pragmatique, organisé, ingénieux et savoir traiter (parler, comprendre, convaincre) avec des utilisateurs.
Re-PS : On se fait un Afterwork sur le sujet ?
Hello Djeepy,
Tu dis ça parce que tu projettes ton cas personnel de warior de la B.I. sur toutes ses facettes (Dev, Gestion de projet, R&D, …), Hors parfois des personnes tout à fait bien cablées n’ont juste pas envie de prendre en charge ces tâches qui ne les interessent tout simplement pas, ne penses-tu pas ?
Un afterwork sur ce sujet me semble une excellente idée !
Ah tu me fais un papier de gestion de projet, tu t’assumes mon petit PM rouquin 🙂
Héhé :'( Mwé
On ne fait pas toujours ce qu’on veut dans la vie et l’inverse est vrai.
S’il n’y a pas de leadership sur le projet, il doit être pris par quelqu’un et comme il y a pénurie en la matière, ce sera peut-être la personne qui est « en capacité de » mais qui n’aura pas forcément envie.
Tu as tout à fait raison JP, car comme le chantaient si bien les Tranxen 200
Et vice et versa, et vice et versa
Charly je ne suis pas certain de bien cerner ton argument.
Tu dis qu’en BI on a besoin de plus de gestion de projet que pour les autres domaines du développement, et que ça manque? Mais ça manque parce que les clients ne veulent pas acheter ce genre de prestation, ou parce que les consultants ne sont pas formés, ou pour une autre raison?
Un savant mélange de tous ça, les clients qui pensent que le projet peut se gérer tout seul, le manque de compétences sur ce domaine chez les prestataires, l’absence de méthodologie clef en main …
Alors je suis un peu comme JP sur le fait que cela ne soit spécifique au décisionnel. Ok nos clients sont en général plus exigeants (métiers, VIP), mais en dehors de ça ce sont les mêmes débats pour tous les projets informatiques.
Et si je peux me permettre, méfie du toi du filtre d’être dans une société reconnue sur son expertise technique, dans une équipe constituée des meilleurs experts techniques, alimentée par un pipeline où très souvent les problèmatiques sont techniques, pour ensuite venir dire que tu constates des lacunes dans la gestion de projet autour de toi 😉
Là où par contre je te rejoins à 100%, c’est sur le fait qu’en décisionnel, et en particulier en décisionnel Microsoft, on en est vraiment à l’age de pierre en terme de méthodologie clef en main. On est des tanches en patterns et industrialisation des développements, livraison continue ou tests automatisés. A nous de nous améliorer sur le sujet: on se fait une session Agilité aux prochains JSS? 🙂
Hé hé oui une session agilité aux prochains JSS 🙂
[…] J’exprime plus en détails mon point de vue sur ce sujet ici => http://blog.sauget-ch.fr/2013/03/problematiques-de-la-gestion-de-projet-decisionnel/ […]
Je rejoins tout à fait Florian sur le constat suivant :
Côté méthodologie et testing, en BI nous en sommes encore à l’age de pierre sur la stack MS…
Alors évidement les consultants doivent se remettre en cause, sur la partie gestion de projet…. mais comment parler d’agilité si le tooling n’existe pas? Et c’est la que le bas blesse :
Qui peut me citer un serveur d’intégration continue qui permet de déployer des DTSX, du XMLA?
Y a-t-il un framework qui permet de faire des tests unitaires sur les règles métiers implémentées dans vos proc strock (c’est le mal), vos dtsx, votre MDX????
Connaissez vous des outils de test d’intégrations qui valident un dev de bout en bout (ex : de la lecture d’un fichier csv au browsing d’une dimension procésée).
Alors comment en vouloir aux consultants ou aux chefs de projet, s’il n’existe pas de tooling qui permet de les accompagner sur les aspects d’agilité ??? Tout faire à la main par script sql, commandlet powershell etc…., c’est faisable…. mais c’est long, et donc non applicable sur de petit projet.
Charles Henri parlait également de volumétrie ralentissant les cycles de dev en BI; Effectivement si l’on est obligé de traiter à chaque petite évolution des gigas de données, on a tendance à passer notre temps a attendre que la machine ai finit de travailler…. on l’a tous vécu; ça à l’avantage de nous laisser le temps d’aller prendre des cafés ou fumer des clopes…. mais bon niveau productivité, une nouvelle feature par jour quand tout va bien, c’est pas le top…
Et pourtant la solution existe, adaptons le concept des mock [ http://fr.wikipedia.org/wiki/Mock_(programmation_orient%C3%A9e_objet) ] pour abstraire les dépendances de chaque composant que l’on développé. Ex : Pour constituer, une dimension nous avons besoin d’un table dans le DataWarehouse. Un Mock de table de dimension peut-être, tout simplement une autre table, une fonction, une vue qui ne ramène que 10 lignes. Amélioration du temps de process garanti.
Vous l’aurez compris, je défend ardemment l’idée que l’amélioration de la qualité de notre travaille, que notre agilité ne peut venir que par l’émergence d’un toolset intégré à notre IDE Visual Studio; Et je viendrais la défendre lors de l’afterwork du 17.
Absolument d’accord avec toi, j’ai pas détaillé ce point (certainement à tord) mais c’est en effet très important d’avancer aussi sur les méthodes de tests !
[…] Un article de 2013, plutôt orienté gestion de projet. Problématiques de la Gestion de Projet Décisionnelle […]