Au cours de mes activités en tant qu’intégrateur de solutions PLM au sein de Minerva France, on m’a demandé (et on continue à me demander) de réaliser des estimations de coûts de projets de déploiement de solutions. Beaucoup de paramètres entrent en compte et en général le demandeur se retrouve avec une fourchette de coût trop large sans pouvoir vraiment ressentir l’effort d’implémentation, par un manque de compréhension de la solution à mettre en place.
Quel découpage?
Le problème du découpage est un des points les plus importants. Je l’avais déjà eu lorsqu’on a déployé un premier projet chez Airbus et je le retrouve encore chez des clients récents. Comme il y a un besoin de traçabilité important vis à vis du client final, le cycle en V classique de développement est encore très largement utilisé, pour pouvoir justifier du coût de chaque fonctionnalité mise en place. On se retrouve alors avec un découpage du projet en requis/besoins fonctionnels. Lorsque vous chiffrez votre projet, vous le découpez en activités, et non en requis.
Analogie d’une maison
Ma compagne étant complètement étrangère au monde de l’IT, je passe mon temps à faire des analogies avec le monde médical pour imager mes problématiques. Pour simplifier les choses je vais le transposer à la fabrication d’une maison. Quels sont les requis fonctionnels pour une maison? La porte d’entrée doit s’ouvrir vers l’intérieur, il ne doit pas y avoir de fuite lorsqu’il pleut, les chambres doivent avoir telle taille… L’artisan qui construira la maison ne va pas vous détailler ses activités par rapport au sens d’ouverture d’une porte ou pire par rapport à l’étanchéité de la maison, il va détailler les activités: couler une dalle, monter les murs, monter la charpente,… D’où le problème en IT, de trop vouloir tout tracer.
Quelles garanties ?
Ensuite on le sait bien, le déploiement d’une solution ne dépend pas que de la solution elle-même. Elle dépend très largement de l’intégrateur et du clients, qui vont devoir retravailler leurs requis. J’ai vu ces dernières années des projets gagner ou perdre de dizaines de milliers d’euros en remplaçant un responsable de projet qui comprenait ou non le besoin utilisateur et était capable de le challenger. Lorsqu’on me demande un macro-chiffrage préliminaire aujourd’hui, cela doit être indépendant de l’intégrateur (qui ne sera pas moi). On sait tous qu’il faut parfois avoir la ou les quelques perles dans une équipe de déploiement pour que le projet se passe bien. Je ne peux pas miser sur le fait que chaque intégrateur aura ces perles. Donc la garantie d’un chiffrage est difficile à mesurer et doit être précisée dans le chiffrage, en indiquant les activités qui seraient les plus sujettes à un risque dépendant des compétences de l’intégrateur.
Conseil pour les clients finaux
- Assurez-vous que votre interlocuteur direct connaisse la solution qu’il vous propose (il est bon d’évaluer vos partenaires IT sur leur veille technologique)
- Comprenez la problématique de traçabilité entre un requis client et une tâche d’intégrateur.
- Méfiez vous des budgets, et échangez avec les clients existants (en France et à l’étranger) pour mieux appréhender le budget que vous pourriez avoir à engager.
Partager :