Analyse des besoins.


L’analyse des besoins est l’étape initiale qui va aboutir à un projet.

Souvent on raisonne en terme de solutions, car les SSII ont souvent une solution miracle toute faite ( un progiciel ) à nous proposer.

Les plaquettes commerciales , sont bien faites.. Le logiciel s’adapte un peu à tous les besoins, même ceux qu ‘on a pas prévus, aussi on a un peu tendance à « bâcler » cette analyse de besoin .. Le commercial va essayer de vous fourguer l’appli qu’ils connaissent le mieux..

Il ne faut pas écarter l’approche « solutions », qui coutera moins cher. mais comment trouver la bonne solution, parmi les nombreux progiciels, et VALIDER son choix , si on a pas écrit ses besoins.

Idem pour le choix du prestataire dans le domaine des SI, leurs pages internet sont pleine de promesses, avec un jargon informatico commercial , qui ne veut pas dire grand chose, si je compare à l’inginiérie de l’industrie qui décrit ses méthodes de travail et les outils employés..

Comparez les pages des prestataires qui sont intervenus sur Chorus et le résultat. ( voir Analyse de risques d’un projet informatique ). certes ce n’est pas totalement de leur faute, mais il faut accorder une confiance limitée à ce baratin publicitaire.

Dans cette phase d’analyse des besoins , on ne devrait pas non plus parler de technique, c’est trop tôt ! Et pourtant il y a tellement de différences entre deux SGBD, qui soulèvent des questions en matière de besoins qu ‘on aura pas exprimés ou pas avec la précision qu ‘il faudrait, et que se gardera bien d’évoquer le technico commercial pour vous vendre sa solution préférée. Quand on découvrira le problème il sera trop tard..

Enfin comme souvent il faut aboutir à une solution d’un progiciel existant, car le risque d’avoir une appli originale , une sorte de mouton à cinq pattes, qui en plus de nous coûter très cher, sera difficile à faire évoluer si elle n’est connue que d’un seul développeur.. c’est ce qui fausse un peu la démarche analyse des besoins..

Si le progiciel choisi couvre plus de besoins qu’on le prévoyait au départ, pour un supplément de prix modique, il faut redéfinir ses besoins. car ça peut avoir aussi un impact sur l’organisation interne, qu ‘il faudra évaluer en terme de coûts et de gains et intégrer au projet…

Besoin des utilisateurs : Il est souhaitable ( voire impératif selon l’application ) de recueillir l’avis des utlisateurs assez tôt.

Si on les a oubliés, lors de la formation , ca risque d’être une pluie de critiques.

Si c’est un projet structurant, qui nécessite une réorganisation, ça risque de générer des inquiétudes, comment avoir leur adhésion au projet , essentielle pour la mise en oeuvre.

Exemple si on doit leur annoncer que ce nouveau projet va supprimer 50 emplois d’ici deux ou trois ans, ils ne vont pas nous aider…..

J’en parle dans ce sujet, car bien souvent le besoin initial est de faire des économies en supprimant du personnel, souvent c’est un objectif donné aux managers et c’est URGENT !!! Le reste on s’en tape ..

Un classique des SI est de décentraliser les saisies, vers les opérationnels, créant une surcharge de travail, occultée dans les pertes du projet, pour supprimer des postes administratifs, comptabilisés dans les gains du projet..

Enfin on nous l’a vendu comme ça , nous expliquant que ça nous aiderait à gérer nos budgets en temps réel.. au lieu de recevoir des restitutions paier tous les mois.. Avec des délais d’ une semaine pour les validations , il a fallu garder chacun nos méthodes avec Excel ou à la mano..

La phase de déploiement est souvent une charge de travail supplémentaire conséquente, souvent sous estimée , surtout au niveau de la durée.. Là on peut aussi perdre définitivement l’adhésion des responsables de service qui n’arrivent plus à remplir leur mission…

Mais je condamne vivement ce style de management imbécile, le management par le stress et purement comptable ( version gripe-sous ), qui aboutit à la situation que connaît la France aujourd’hui.. et aboutit à des surcoûts faramineux. Si encore on en tirait des leçons, mais on les enchaîne les unes derrière les autres..

Exemple Chorus : après le fiasco Accord, les gains espérés avec Chorus ne commenceront que dans dix ans. Dans dix ans le projet Chorus sera à la poubelle car d’ici là il y aura eu des élections et on aura eu, je l’espère l’occasion de revoir toute la gestion financière de l’ Etat pour la simplifier et faire de réelles économies.. idem pour la carte Vitale et le DMP.

Déjà pour supprimer quelques postes de petits fonctionnaires on recrute des équipes de 30 personnes ou plus, incapables d ‘évaluer et de maîtriser les coûts et les délais.. Au point qu’on ferait mieux de ne rien faire, on ferait des économies. L’ Etat a accumulé une montagne de factures impayées alors qu’il voulait avoir une meilleure visibilité des dépenses.. ( besoin exprimé ).

Et en décembre 2010 l’ Etat est obligé d’emprunter pour payer ses employés..

On nous prend vraiment pour des jambons..

J’ai un exemple concret où on a supprimé grace à l’informatisation des dizaines de postes de chefs de quart en 3×8. Des gens d’un certain âge, qui ont été reclassés, ne se sont pas sentis menacés et ont collaboré à fond à ce projet.

Il n’ y a pas eu de surcoût. Les gains de ce projet n’étant pas principalement basés sur ces suppressions de postes en 3×8, mais sur une optimisation de l’exploitation du processus industriel, qui nécessitait un ordinateur pour faire ces calculs en temps réel. Gains économiques parfaitement mesurables..

Puis on a gardé une équipe de chefs de quart, la cinquantaine, qui sont passés du vieux tableau de commande centralisé avec des boutons et des indicateurs à aiguille qui dataient de Mathusalem, au Barco avec boule roulante et clavier numérique ( le Commodore 64 n’existait pas encore..) Mais ces gens détenteurs du savoir faire d’exploitant ont été associés au projet, leur savoir faire et leur expérience étaient indispensables. Pour ces gens d’une autre génération c’était un changement de métier énorme. Bien sûr ils ont été reclassés en conséquence. Puis ils ont formé la génération suivante..

Si on compare à l’aviation avec le passage au pilotage à deux, au lieu de trois avec le mécanicien

Alors qu’aujourd’hui on ne raisonne plus en gain de productivité, mais en nombre d’emplois supprimés, et en plus de démotiver les gens on fait des conneries énormes.. On a lâché la proie pour l’ombre.

Ceci m’amène à penser qu’avant la définition des besoins , il ya deux choses importantes..

– La définition des OBJECTIFS du projet.

– Le calcul de la RENTABILITE ECONOMIQUE du projet.

Ce sont les deux domaines où il y a le plus de mensonges et à la sortie on paye cash !

C’est comme lorsqu ‘on nous a dit que l’informatique supprimerait le papier ! On a jamais autant consommé de papier que depuis l’arrivée des micro ordinateurs..

On pourrait résumer les écueils de cette démarche :

– analyse des besoins sommaire : l’application risque de ne pas couvrir des besoins non exprimés

– analyse des besoins trop poussée : on risque d’aboutir au mouton à cinq pattes

– analyse des besoins des utilisateurs pas faite : on risque un refus de l’application ou de passer à coté du problème

– a contrario si on demande l’avis de tout le monde ca peut devenir inextricable..

Publicités
Cet article a été publié dans Gestion de Projets. Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s