Cycle en V vs Agile sur un Projet: combinez! Voici la fusion du V model, de l’Agile et du Design Thinking. Définition, explication, exemple. Partie 8 (fin) !
Avant d'aller plus loin, je vous recommande la lecture des parties précédentes.
Dans cet article, nous allons traiter des étapes α à δ du chemin rouge sur le cycle en V représenté ci-dessus. Il s'agit du dernier article de cette série sur mon implémentation personnelle du cycle en V.
Tout au long du chemin bleu, nous nous sommes attachés à concevoir, développer et vérifier le Système : le Produit qu'on souhaitait réaliser. Attaquons nous maintenant au sujet du Support et de ses moyens, via le chemin rouge.
Notez que pour le Produit/Système du chemin bleu j'utilise une majuscule. Cela a son importance dans cet article.
"Le Support, on verra plus tard". Attention à ce piège ! La maintenance se joue dès la Spécification du Produit.
En effet, lors de l'étape α, l'équipe Support doit donner ses contraintes et ses besoins et ces derniers doivent être intégrés dans les exigences constituant la Spécification du Système. Le Support peut même donner des exigences de niveau Conception (Sous-Systèmes) si nécessaire, à prendre en compte dans l'étape 6.
Exemple d'exigences qui peuvent naître ici, appliqués à notre chère trottinette électrique :
Vous voyez que ces exigences peuvent être diverses. Elles peuvent même collisionner avec d'autres exigences (celles de la Production série, celles issues du Besoin client...). Qu'à cela ne tienne, une décision doit être prise. Mais au moins, elle est prise en connaissance de cause et on peut certainement à ce stade du Cycle en V faire un compromis pour résoudre la situation sans douleur.
Les domaines à couvrir sont :
Puisqu'on parle d'Apple : vous êtes-vous déjà rendus dans un Apple Store pour faire changer un composant de votre iPhone/Mac/etc. ? Vous voyez avec quelle facilité le personnel se connecte à votre produit pour faire l'analyse préalable au changement de pièce demandé ? C'est parce que toute cette Maintenabilité du produit a été pensée dès le début et s'intègre parfaitement au fonctionnement nominal du Produit. Il n'y a pas de secrets.
OK, l'équipe Support a donné ses prérequis sur le Produit. Ce n'en est cependant pas fini de l'étape α.
En parallèle du développement du Produit, l'équipe Support va devoir spécifier/approvisionner ses propres outils et moyens. Et si on spécifie un système... Il faut aussi planifier son intégration et sa vérification ! (cf. les autres articles de la série sur le Cycle en V)
Exemples d'outils et moyens Support/Logistique :
Ces outils/moyens seront certainement à utiliser selon une procédure. C'est le moment de s'y pencher : manuels de maintenance, PV de SAV, ... Cette documentation est à initier dès maintenant, en parallèle des outils à se définir, car elles vont peut-être influencer vos outils. Et inversement.
Exemple d'influence de la procédure sur l'outil à concevoir :
Si vous voulez encore aller plus loin, vous pouvez même penser dans la Spécification de vos moyens de Support... aux exigences de maintenabilité de ces mêmes moyens de Support !
Arrivés en étape 8 du chemin bleu, nous savons ce que sera le Système dans ses moindres détails. Nous savons aussi, puisque nous avons suivi le chemin rouge en parallèle (sur l'étape α), comment seront nos moyens de Support associés pour l'accompagnement de la vie du Système et sa Maintenance.
Si ces outils et moyens de Support sont dispos sur étagère, il suffit de les acheter dans le commerce.
Si ce sont des outils dédiés qu'on a inventé de toute pièce, alors en fin d'étape α c'est le moment de développer nos moyens et outils de Support, selon les spécifications et plans de vérifications que nous avons écrits pour eux.
Tout comme notre Produit principal, les moyens et outils de Support qu'on a développé doivent être intégrés et vérifiés selon le plan d'intégration et de vérification prévu à cet effet.
C'est l'objet de l'étape β.
Pour ce qui est de l'intégration et de la vérification d'un système, je vous renvoie vers les articles précédents de la série sur le Cycle en V.
En parallèle de l'étape 11, doit se dérouler l'étape γ. A ce moment-là, si les moyens sont prêts et qu'on a un Système quasi finalisé, il ne faut pas se priver de faire une "présérie".
La présérie de dérisquage à cette étape (la dernière du genre avant la sortie du Produit vers chez le Client) doit permettre de tester que vos procédures, outils et moyens de Support sont parfaitement adaptés à votre Produit.
Normalement, cela a été testé via les Plan d'Intégration et Vérification de ces moyens et outils. Cela dit, faire un test grandeur nature, sur plusieurs exemplaires, n'est jamais du luxe.
Exemple de questions à se poser à ce moment-là :
On s'intéresse ici à ce que j'ai nomme l'étape δ. Le Système peut sortir de l'usine et aller chez les Clients. Que faire ?
On retrouve tout d'abord l'équivalent d'une phase de Transfert ici aussi :
Pendant la vie du Système, il y aura certainement des réparations de SAV à faire certes, mais aussi des problèmes de définition du Produit qui vont apparaitre. Pas de panique. Si votre Système a été intégré, vérifié et validé de fond en comble, les problèmes que vous allez voir apparaitre ici seront mineurs. Toujours est-il qu'il va peut-être falloir les prendre en compte et les corriger.
Pour ce faire, l'Armée des USA a documenté un processus dans son MIL-STD-2155 : FRACAS (Failure Reporting, Analysis, and Corrective Action System). Vous pouvez largement vous en inspirer, c'est efficace et éprouvé. En gros, il s'agit de mettre en place un moyen de détecter, lister, traiter les défaillances de votre Produit et déployer les correctifs. Tout ceci de manière documentée, tracée et en vous assurant qu'en apportant la correction au problème vous n'en créiez pas un autre ailleurs. On parle de contrôle du changement.
On fait également du contrôle du changement lorsqu'on souhaite faire évoluer notre Produit pour gérer l'obsolescence (de ses composants) ou tout simplement l'améliorer. Ces idées d'amélioration peuvent provenir de nous, industriel, ou de nos clients directement.
NOTA : ne pas négliger la gestion d'obsolescence, il y en a toujours à faire si vous comptez vendre votre produit pendant plus de 2 ans.
Exemple de Change Control :
A noter : le Support a commercialement un positionnement intéressant. En plus de permettre aux clients d'avoir une continuité de service avec le Produit, c'est aussi cette équipe qui peut détecter les tendances d'utilisation et les améliorations possibles du produit. Il ne faut donc pas négliger le Support dans une étude marketing pour un nouveau produit...
Enfin, le Support a un rôle dans la fin de vie de notre Produit. Il peut leur revenir (si le Produit et le Business ont été pensés comme tels) de récupérer les Produits cassés ou que le client ne souhaite plus afin de les faire recycler dans la production Série.
FMDS : Fiabilité, Maintenabilité, Disponibilité, Sécurité.
Ces caractéristiques occupent une place importante dans la conception d'un Système. Elles ne sont certainement pas à négliger pour les aéronefs, les voitures, et même les petits produits qui fonctionnent sur batterie ! Je ferai certainement un article dédié pour chacune de ces caractéristiques. Pour l'heure, je vais me contenter de dire en quoi le Support de notre Produit joue sur celles-ci.
La capacité de Support intervient dans la Disponibilité du Système. Si votre Système est très défaillant et nécessite d'être changé/réparé régulièrement, mais que votre entreprise n'est pas capable de remplacer/réparer rapidement un produit, alors la Disponibilité du Produit chez votre client sera mauvaise : le temps de non fonctionnement + le temps de remplacement/réparation = un temps où le système n'est pas disponible pour son utilisation.
Si vous êtes capables d'agir à distance sur un Système défaillant, alors c'est toujours ça de pris. Les exigences du Support en début de cycle en V vont jouer sur la Maintenabilité de votre Système. Si vous avez développé le Système sans penser à comment il doit être réparable, alors vous n'avez plus qu'à faire des remplacements standards potentiellement très longs et couteux.
A noter : la Maintenabilité influe elle-même sur la Disponibilité...
Il ne faut pas négliger le Support et la Logistique du Produit. Il faut y penser dès le début !
On se retrouve avec les moyens et outils de Support dans le même cas de figure qu'avec les moyens et outils de Production série : on doit créer des outils adaptés à un Produit qui n'existe pas encore. Il ne faut pas en avoir peur, c'est justement l'occasion de faire les choses comme on le souhaite ! Voir cet article.
Cet article vient conclure la série de 8 sur la méthode hybride de Projet de Conception que je vous propose ! J'espère avoir apporté ma pierre à l'édifice des Process de Conception, avoir démystifié certains points et vous avoir donné envie de le considérer dans vos projets pro et persos. Si vous souhaitez avoir plus d'informations à ce sujet, n'hésitez pas à me contacter (cf. bas de page du site) !
Je tiens à préciser au passage que je ne possède pas de trottinette électrique, ni ne lui voue un culte obscur. C'était simplement un bon exemple fil rouge !
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 !
