La gestion d’un projet industriel de conception d’un Système/Produit implique l’estimation des Coûts et des Délais pour un niveau de Qualité associé. Quelques chiffres pour vous aider à budgétiser.
Dans une série d’articles, je vous présente mon processus personnel de conception d’un Système/Produit. Ce process se base sur le Cycle en V, et y intègre le meilleur du Design Thinking et de l’Agile. On peut parler de Cycle en V hybride, Hybrid Vee, ...
Je vous recommande la lecture de cette série avant d’attaquer cet article, car il va se baser sur le même découpage en phases pour le Projet qu’on va chercher à chiffrer.
Dans le schéma en entête de l'article, je propose un budget de charges de travail (C) et de durées (D) pour chaque phase.
Tout est quantifié selon 2 "unités" de charge et délais que sont C et D. Un exemple à la fin viendra montrer ce que cela donne de manière pratique sur un projet en mettant des nombres de jours derrière C et D.
Hypothèses permettant de construire ce cycle en V chiffré :
Comprenant analyse préliminaire et consolidée, hors Faisabilité :
On n’oublie pas la rédaction du plan de Validation en face (tests, qualifications, phase de tests longue durée chez client…)
Exemple : 3 mois de travaux d'une personne à temps plein donne 66j~ de charge (C=66j) et pareil pour la durée D.
Le Cout en charge et en durée d'une étude de Faisabilité (maquettages, simulations, etc.) est très variable selon ce qu’on veut faire et à quel point on veut défricher. Je ne me risque donc pas à quantifier cette partie.
Pour cette phase, j'estime que :
En effet, les activités vont être de calquer le Besoin établi sur un Système, un Produit, une Solution. On ne part pas de 0 mais pour chaque exigence de Besoin on va devoir écrire une (ou plusieurs) exigences Système. Et cela va demander de la réflexion.
Exemple : « Avec le Système, la partie prenante A doit pouvoir réaliser l’action B en conditions C et avec un niveau de performance D »
--> cela va pousser à se demander par exemple ce que représentent la partie prenante A (une interface spécifique ?), l’action B (une fonction ?), les conditions C (un environnement vibratoire ? à quelle fréquence et quel niveau ?) et la performance D (une vitesse de rotation minimum pour X moteurs ?) du point du vue du Système.
J’estime que cette réflexion va demander autant de temps (délais) et de temps de cerveau (charge) que la phase de Besoin où on part de 0 et où on creuse le Besoin exhaustif avec son client. Et de plus, on rédige le plan d’intégration et Vérification qui va en face.
Pour cette phase, j'estime que :
Chaque exigence Système va se décliner en, a priori et en moyenne, 2 exigences filles au niveau sous-système (carte électronique n°1, carter n°3, …). Donc l’effort est ici multiplié par a peu près 2 par rapport à l’étape précédente. Et on n’oublie toujours pas le plan de d’intégation et vérification qui va en face !
Pour cette phase, j'estime que :
Et oui, c’est là qu’on développe, que les métiers font opérer leurs savoirs. Les électroniciens schématisent, font les empreintes, le routage, créent les dossiers pour les fabricants, approvisionnent, testent les cartes reçues, les retouchent, revoient la spécification et l'architecture éventuellement etc.
Les développeurs créent l’architecture du code, distingue les fonctions du reste, codent le tout, testent, retouchent…
Les mécaniciens définissent les CAO, les plans cotés, les affinent, établissent les types de liaisons (boulonnées…) etc.
C’est aussi là que sont définis les plans de tests bas niveau et qu’ils sont déroulés, par chaque métier « dans son coin ». Cela demande du temps et de la sueur.
Pour ces phases ensemble, j'estime que :
Vous aurez la même quantité de travail à fournir dans la remontée du V que dans la descente. En effet, passer un test sur votre Produit prend du temps, et il est fort probable pour que vous découvriez des dysfonctionnements désagréables qu’il va falloir régler sur le champs.
En terme de durée, cela peut (hypothétique, dépendant du nombre de surprises que vous allez découvrir...) être moins long que la partie de la descente du V en regard car l’équipe Projet est efficace à ce moment là (elle connaît le Système par cœur et sauf problème majeur peut intervenir efficacement pour le régler).
Pour cette phase, j'estime que :
La durée est doublée car les tests de Validation et de Qualification sont longs (tests du Système chez le client, en immersion avec utilisateur sur une durée de temps assez longue pour se rendre compte si tout est bien OK) et potentiellement fastidieux (tests en laboratoires : vibrations du produit 9h/jours pendant X jours…).
Pour ce qui est de l’effort (charge de travail) il sera identique à celui à fournir pour faire sortir le Besoin.
Pour cette phase, j'estime que :
Ne comptez pas moins de temps pour déployer + «roder» le Système chez votre client avec ses équipes que celui que vous avez pris pour le valider avec lui. Il va falloir former ses équipes, réaliser l’installation, répondre aux sollicitations des personnes qui vont le découvrir, corriger des problèmes de jeunesse du produit, faire éventuellement du reporting au client pour lui apporter la preuve que tout est OK, mettre en place votre démarche de change control etc.
La charge associée au Chef de Projet n'est pas à négliger. Elle est de l'ordre de 15-25% de la charge totale, si le Chef de Projet a également une casquette Système forte.
Je démarre un Projet de Conception pour un Client.
Si je passe 3 mois à 1 personne pour creuser le besoin avec mon client, alors C = 63j.
Charge totale = C + C + 2C + 4,5C + 3C + C + C + Management + marge (15%)
Le projet coûtera alors : 891j+CdP+15% = ~1230j.
Durée totale : D + D + 2D + 4,5D+ 1,5D + 2D + 2D + marge (15%)
Si D = 3 mois, le projet durera 42mois +15%= ~4 ans.
Rappel : on ne compte pas la Faisabilité car non chiffrée et on compte pas non plus l'Industrialisation et le Support au Produit.
Et si on veut aussi voir ce qu’il se passe du côté des Projets d’Industrialisation et de Support (chemins blanc et rouge sur le cycle de développement général proposé), pour adopter une vision Programme ?
En effet, les efforts pour préparer la Production série sont moins conséquents que pour faire naître le Produit lui-même (la moitié tout de même), mais ils s’étalent et se coordonnent tout au long du Projet de conception du Produit.
Attention : Je ne chiffre pas non plus ici les coûts liés aux achats de matériel pour constituer des outils spécifiques de production (PC, câblages, logiciels, ...)
En effet, les efforts pour préparer le Support et la maintenance sont moins conséquents que pour faire naître le Produit lui-même, mais ils s’étalent et se coordonnent tout au long du Projet de conception du Produit.
Tout ceci n’est qu’une estimation, débattable, basée sur du bon sens et une connaissance des projets de conception de produits via Ingénierie Systèmes. Ces chiffres phase par phase permettent de donner un point de départ si vous n’avez pas d’idée de comment budgétiser votre projet, ou bien donnent un point de comparaison pour vous assurer de la cohérence de votre propre chiffrage.
C’est un framework de gestion de projet que je vous invite à utiliser.
Et n’oubliez pas les marges ! Personne n'est devin alors quelques petites sécurités ne sont pas du luxe.
Aurélien NARDINI
Un Système Sans Problème est une ressource de connaissances et de savoir-faire pratiques, avec exemples concrets.
Que vous soyez Chef de Programme, Chef de Projet, Architecte Système, Ingénieur, Manager dans l'Industrie, Etudiant ou Curieux de l'Ingénierie, vous êtes au bon endroit.
Au travers d'articles publiés régulièrement, découvrez ou révisez les Processus, Méthodes, Outils et Astuces utiles pour concevoir et piloter dans les domaines du Software, Firmware, de l’Électronique, et de la Mécanique.
Parce-qu'un produit fiable et industrialisable ne s'improvise pas !
