Vous avez industrialisé votre produit. Vous êtes arrivé au bout de cette phase et vous avez pu assister à la mise sur le marché de votre produit. On vous félicite ! Mais maintenant, que se passe-t-il pour votre produit ?
Vous avez industrialisé votre produit. Vous êtes arrivé au bout de cette phase et vous avez pu assister à la mise sur le marché de votre produit. On vous félicite ! Mais maintenant, que se passe-t-il pour votre produit ?
Vous avez industrialisé votre produit. Vous êtes arrivé au bout de cette phase et vous avez pu assister à la mise sur le marché de votre produit. On vous félicite !
Mais maintenant, que se passe-t-il pour votre produit ?
L’idée c’est de ne pas le laisser vivre sans suivi, ni surveillance.
Que se passe-t-il si un composant devient obsolète ? Si on constate qu’on reçoit de plus en plus de produits en SAV ?
Voilà des points de vigilance à continuer à suivre après l’industrialisation, une fois la production stabilisé et le produit mis sur le marché.
Allez, c’est parti !
La vie série, c’est ce qu’il se passe une fois que la production est stabilisée.
Elle peut être gérée par le prestataire qui accompagne le porteur de projet sur la thématique d’industrialisation mais cela peut aussi être géré par le porteur de projet lui-même.
Dans les deux cas la gestion de vie série est intimement lié à l’industrialisation.
L’industrialisation est une phase déterminante pour la mise sur le marché de votre produit. C’est à anticiper et intégrer le plus en amont possible. Pourquoi ?
Pour vous permettre d’anticiper le planning de sortie de votre produit et d’intégrer tous les coûts et investissements nécessaires à la réalisation de votre projet.
Par ailleurs, chez Rtone, on applique l’industrialisation comme un fil rouge. C’est-à-dire qu’elle est décomposée et qu’elle intervient à chaque phase de développement du produit.
> Pour creuser ce sujet en détail, vous pouvez consulter cet article.
La vie série, c’est le fait de s’assurer :
La vie série intervient principalement sur les parties mécaniques, hardware et software du produit.
Voici les différents aspects de la vie série :
La vie série commence avec l’instauration d’indicateurs. Afin d’être en mesure d’identifier et d’éviter certains … les indicateurs vont pouvoir ici permettre de lever des alertes en cas de besoin.
On considère que les non-conformités peuvent survenir dans 2 cas :
Il faut donc pouvoir gérer et corriger ces pannes. Dans la plupart des cas, cela signifie :
L’amélioration continue de la production requiert d’intégrer les retours clients.
Cela peut être en mettant en place un service après-vente auquel on doit se former et pouvoir former d’autres membre qui seraient amenés à rejoindre l’équipe. Bref, plus c’est documenté, mieux c’est !
Le suivi qualité permettra aussi d’être capable d’identifier des problèmes de conception ou de fabrication.
Tout au long de la production, il peut arriver divers changements. Il faut pouvoir s’y préparer pour y faire face :
A un moment donné, il va falloir décider quand on va devoir ou vouloir arrêter de fabriquer le produit.
Nous pouvons conseiller le client sur cette stratégie là. Il peut y avoir plusieurs options :
Les équipes Rtone ont accompagné Lunii sur l’étude électronique et logicielle de la vie série de leur produit Ma Fabrique à Histoires, c’est-à-dire qu’elles ont proposé du redesign et les évolutions logicielles associées, en fonction des différentes optimisations à mener. Le pilotage de l’industrialisation, la mise en production et la gestion de la vie série ont été opéré par leur EMS français BMS Circuits.
Rtone et Lunii ont donc travaillé sur 3 axes de l’industrialisation et de la gestion de vie série :
Dans l’optique de limiter le taux de défaillance et d’augmenter la fiabilité du produit, certaines actions ont été menées par les équipes :
Afin de réduire les coûts :
Pour faire face à la pénurie actuelle des composants, des solutions ont dû être trouvées :
Les équipes Rtone ont piloté les phases amont jusqu’au banc de tests fonctionnels, la fin de la fabrication des cartes.
BMS Circuits a en plus géré le remplacement de composants identiques pour pouvoir continuer à produire dans plusieurs cas de figure.
Ma Fabrique à Histoires de Lunii
Les mêmes principes s’appliquent aussi au Cloud. On va parler de maintenance du produit ou de la plateforme.
Que le produit soit stabilisé ou continue à évoluer, il y a toujours une équipe de développement qui connaît le produit et qui va suivre les bugs et les mises à jour.
Et même si des cycles de tests ont été précédemment réalisés, il peut toujours y avoir :
En règle générale, un service Cloud évolue en permanence.
C’est souvent l’équipe de développement qui travaille sur les évolutions car c’est elle qui connaît le mieux le produit et qui sera capable de le corriger rapidement.
Pour un software qui n’évolue pas, cependant, vient un moment où les bugs se font de plus en plus rares et finissent par disparaître.
Pour respecter un process qualité dans les différents développements, il est primordial d’avoir un cahier de tests.
C’est une procédure qui va décrire toutes les fonctionnalités et les situations à tester à chaque mise en production du software. Même les plus basiques. Pour n’en oublier aucune :
Car chaque ajout de fonctionnalités entraîne des des boucles de bugs récurrentes.
Il y a d’abord une phase de développement, lors de laquelle on va justement chercher les bugs pour les corriger au fur et à mesure, dans les sprints suivants.
Puis, il y a une première phase de mise en production. Des utilisateurs non experts vont commencer à utiliser la plateforme et souvent leur travail en dépend. Deux choses sont essentielles :
Puis vient le cycle naturel d’évolution du service.
Différentes versions sont utilisées pour suivre un process de développement qui intègre les mises à jour, les corrections de bugs et les nouvelles fonctionnalités en essayant de limiter les risques.
La version « dev », qui est une version qui va évoluer tous les jours, avec tous les ajouts des développeurs. Cette version est uniquement testée par un petit groupe spécifique : le chef de projet chez le client, par exemple.
Puis on construit une version staging. C’est une pré version de production, qui ressemble fortement à la version de production : on va utiliser des données réelles autant que possible, avec les mêmes performances, dans les mêmes conditions.
Puis c’est enfin la version de production qui est utilisée. On parle d’une version figée, versionnée. On sait quelle version du code source est déployée.
Il en existe 2 versions :
Puis va entrer en ligne de compte la stratégie de mise à jour avec ou sans interruption de service. Deux serveurs peuvent être utilisés en parallèle pour assurer un service continu 24/24 et 7/7 et éviter toute interruption de service, ou décider d’une heure de connexion pour redémarrer le service.
> Pour en savoir plus sur la maintenance, on vous conseille cette vidéo.
Un peu de lecture
Des articles, des podcasts, des webinars… et surtout des conseils pratiques ! En bref, une collection de ressources pour mener à bien votre projet.