Pourquoi la planification de mise sur le marché n’est pas la même que la planification de NPI (et ce que cela signifie pour les équipes d’ingénierie de test) 

Les experts vantent le temps de mise sur le marché comme un indicateur d'entreprises innovantes et en évolution rapide. Chez NI, notre communauté de gestionnaires de test nous dit que des objectifs de délai de mise sur le marché agressifs peuvent exercer une pression intense sur eux et leurs équipes. Nous avons demandé à notre spécialiste des tests de production électronique, Graham Green, de nous expliquer ce qui se passe et quelles pratiques exemplaires peuvent atténuer cette pression.

NI : Graham, avant d'aborder les effets de la pression sur les délais de mise sur le marché, pouvez-vous expliquer pourquoi elle existe et pourquoi elle est plus forte que jamais ?

GG : En bref, elle existe parce que nous voulons tous de nouvelles choses, et nous les voulons maintenant. La loi de Moore documente bien l’accélération des performances du processeur, qui entraîne la mise de nouveaux appareils sur le marché, mais ce n'est pas la seule raison. Les nouvelles normes sans fil, les assistants audio intégrés et la technologie d'écran et de batterie deviennent tous des facteurs de différenciation dans lesquels le fait d'être le premier sur le marché offre un avantage significatif. Je vois les appareils devenir plus complexes tandis que les intervalles entre les versions se raccourcissent, ce qui fait pression sur les équipes d'ingénierie et de fabrication.

NI : Si nous acceptons que les calendriers de conception deviennent plus courts, pourquoi cela a-t-il un effet particulièrement négatif sur les tests ?


Figure 1. Planifier la compression tout au long d'un projet

GG : Voici un graphique que j'ai montré pendant des années, et c'est aussi vrai aujourd'hui que cela l'était lorsque j'ai rejoint l'industrie. Cela montre que plus l'étape du processus dont vous êtes responsable est tardive, plus le risque que votre calendrier soit injustement compressé est élevé. Il est rare que je parle à un ingénieur de test qui ne ressent pas la pression de respecter des plannings de développement agressifs. Ceci est aggravé par deux différences importantes entre le délai de mise sur le marché et le calendrier de développement des tests :

  1. Les stations de test doivent être déployées bien avant le lancement d'un produit.
    Idéalement, les testeurs sont prêts pour les lancements de pré-production au fur et à mesure du développement d'une ligne de fabrication. Cela permet d'identifier les défauts de fabrication tôt pour maximiser le rendement, et cela peut prendre des semaines voire des mois avant le lancement du produit. Parfois, les planificateurs négligent cette étape.
  2. Augmenter le volume de production ne nécessite pas une station de test, mais plusieurs.
    Vous faites la différence non pas en mettant une seule unité sur le marché, mais en fabriquant en volume suffisant pour répondre à la demande du marché. Le succès dépend de la capacité de l'équipe de test à répliquer et déployer plusieurs testeurs rapidement et efficacement.

NI : Prenons-les l’un après l’autre. Il semble essentiel de rendre cette première station de test opérationnelle à temps. Que peuvent faire les équipes d'ingénieurs de test pour s'assurer qu'elles y parviendront de manière fiable ?

GG :  La réponse théorique est de parler d'outils logiciels à haute productivité ou de renforcer les compétences d'équipe pour un développement de groupe efficace. Si cela vous intéresse, consultez ces ressources LabVIEW et Centre d'excellence. Mais il y a un facteur moins connu qui a un effet énorme sur les plannings : La planification efficace des tests.

Le premier obstacle à la planification consiste à s'assurer que vos scénarios de test couvrent toutes les exigences des spécifications de test. Trouver qu'une condition d'utilisation n'est pas couverte, et l'ajouter plus tard, est considérablement inefficace. Nous avons tous souffert des changements de dernière minute, en particulier dans les lignes de test hautement distribuées, dans lesquelles l'équilibrage du temps de cycle est essentiel.

Vous pouvez éviter cela en collaborant étroitement avec les équipes de conception pour effectuer une analyse de couverture, en « reliant » les cas de test de vos spécifications de test aux exigences du produit. Bien sûr, il est facile de dire « collaborer étroitement » et plus difficile d'en faire une réalité organisationnelle.

Si vous souhaitez obtenir un siège à la table des discussions, vous devez démontrer comment la participation de l'ingénierie de test profite aux autres équipes. Les changements de spécifications (en particulier aux étapes ultérieures) causent généralement le plus de friction, c'est donc un excellent point de départ. En définissant ensemble un processus de gestion du changement pour les exigences et les spécifications de test, vous êtes tous gagnants, ce qui peut conduire à une collaboration plus poussée. NI a beaucoup d'expérience dans ce domaine et nos équipes se feront un plaisir de vous conseiller.  

NI : OK, donc une fois que vous vous êtes mis d'accord sur les spécifications des tests, comment pouvez-vous planifier un développement efficace ?

GG : Avant d’aller de l’avant, nous devons être confiants dans notre position de départ. Nous voulons minimiser la probabilité que les informations sur les ressources ou capacités existantes soient inexactes. Les ingénieurs de test adorent réinventer la roue – nous nous sommes lancés dans l'ingénierie parce que nous aimons fabriquer des choses. Et quelle meilleure excuse pour écrire un nouveau code qu'un manque de confiance quant à l'exactitude ou à l’actualité de l'actif de test ou de la bibliothèque de codes ?

J'ai vu cela maintes fois avec des ingénieurs qui refusent d'utiliser des bibliothèques standard parce qu'ils sont convaincus que leur approche est la meilleure. Il suffit de quelques tentatives infructueuses pour perdre confiance dans le nouveau système et revenir aux anciennes méthodes. Une fois ce comportement ancré, il est difficile d’apporter des changements dans une organisation, même si c’est nécessaire.

Les pratiques exemplaires dictent une fois encore une administration diligente des processus. Votre organisation convient-elle des personnes qui doivent être informées/approuver avant de changer de matériel sur une station de test ou sur un logiciel réutilisable ? Toutes les parties savent-elles où ces informations sont stockées et comment ces informations sont mises à jour ? Bien qu'il existe des produits logiciels qui gardent une trace de tout cela, vous avez besoin d'élan et d'adoption active par les parties prenantes pour réussir. Ensuite, il est essentiel que vous mainteniez cette bibliothèque pour vous assurer que les actifs qu'elle contient sont à jour et de haute qualité.

NI : Pouvez-vous nous donner un exemple de ce genre de stratégie en action ?

GG : Bien sûr. Neil Evans a fait exactement cela avec son équipe tout en travaillant sur des produits à ultrasons pour Philips. Ils ont construit une bibliothèque de modules logiciels de code bien écrit et vérifié. Leur architecture a été conçue dès le départ pour encourager la réutilisation.

L'investissement le plus important dans la normalisation réside dans une équipe centrale qui met en place le cadre initial. Une fois que cela est terminé, l'ajout de mises à jour et la maintenance des bases de code sont plus faciles car, à ce stade, les équipes de différentes organisations peuvent participer en tant que contributeurs locaux.

-Neil Evans, Senior Manager, Philips

L'équipe d'Evans a documenté efficacement la fonctionnalité et le cas d'utilisation de chaque module, a encouragé les ingénieurs à les utiliser correctement. Le succès initial a rapidement alimenté l'adoption du bio et la collaboration, et le projet a pris de l'ampleur. Dans l'ensemble, leur équipe a ainsi réussi à réduire de 80 % l'effort et le calendrier de développement des tests d'introduction de nouveaux produits (NPI) par rapport à des projets précédents comparables (calculés en heures d'ingénierie enregistrées par projet).

NI : Jusqu'à présent, nous avons discuté de la finalisation de cette première station de test. Qu'en est-il de la mise à l'échelle des systèmes pour répondre aux exigences de volume de fabrication – comment pouvons-nous réduire le temps de mise sur le marché ici ?

GG : Traditionnellement, il y a un compromis entre le temps passé à consolider une conception avant la réplication et le temps passé à mettre à jour les stations de test répliquées avec de nouvelles révisions introduites tard dans le processus. À moins que vous ne travailliez dans un secteur hautement réglementé (tel que celui des appareils médicaux), où la certification oblige les conceptions à être verrouillées en amont, l'adoption d'une approche de test plus agile signifie que vous n'avez pas besoin de faire ce compromis.  

À quoi ressemble cette agilité ? Tout d'abord, concevez une station de test viable minimale autour d'une instrumentation modulaire basée sur un châssis afin de pouvoir étendre vos E/S sans modifier l'encombrement ou la structure du rack. Ensuite, connectez par logiciel vos stations de test pour gérer la configuration du système, la gestion des versions du logiciel et les données. De cette façon, vous pouvez effectuer des mises à jour à distance, réduisant ainsi le déploiement et la maintenance des logiciels en personne.

Combler l’écart entre la technologie opérationnelle des stations de test et l'infrastructure informatique est depuis longtemps considéré comme la responsabilité des ingénieurs de test, et il s’agit d’une plainte courante. Dans la plupart des cas, les ingénieurs de test ne sont pas des experts en communication réseau, en bases de données et en technologies de visualisation, ce qui conduit à une pression sur les équipes pour les parties développement et maintenance, et les éloigne du travail d'ingénierie des tests de valeur. À mesure que de plus en plus de solutions commerciales prêtes à l’emploi, telles que le logiciel NI SystemLink, pénètrent sur ce marché, non seulement les ingénieurs peuvent déployer en toute confiance une itération après l'itération du code de test, mais en plus ils bénéficient d'autres avantages tels qu’une surveillance de l'état du système, des données d'utilisation des actifs de test, et une analyse plus holistique des données de test.

NI : Le développement et le déploiement de stations de test agiles semblent valables, mais pouvez-vous donner un exemple où cela se produit en pratique ?

GG : Bien sûr. Parlons de l'équipe d'un fabricant d'électroménagers de premier plan. Leur capacité à déployer et à gérer à distance les révisions de tests a justifié leur investissement dans un logiciel de gestion de stations de test à l'échelle de l'entreprise. En plus de cela, leur accès élargi aux visualisations de données engendre chaque jour de nombreuses nouvelles améliorations de processus, accélérant encore le développement et améliorant les indicateurs opérationnels. Leur équipe entretient plus de 170 stations de test et selon leur responsable de groupe :

En utilisant SystemLink pour réaliser un arrêt, une installation ou un redémarrage en douceur, nous avons pu réduire le temps de déploiement de 30 minutes par système à 3 minutes pour toute une ligne de production.

-Responsable d’ingénierie de test

 

NI : Alors, quelle est la prochaine étape pour l'amélioration du planning de mise sur le marché et du calendrier NPI ?

GG : Je suis ravi d'utiliser le machine learning pour mieux définir ce que nous testons et comment, ainsi que pour automatiser nos workflows. Une analyse des données qui étudie chaque testeur peut identifier les zones critiques qui nécessitent des tests rigoureux, ainsi que les zones trop desservies que nous pouvons optimiser. Nous acquérons plus de valeur lorsque nous utilisons l'analyse pour automatiser les processus de tous les testeurs et actifs connectés. Par exemple, je prédis que les futurs programmes de test seront automatiquement générés grâce à un système intelligent piloté par les données. Une fois que cela est une réalité, les ingénieurs de test peuvent rapidement parcourir et optimiser les conceptions, et les programmes NPI manqués n'existeront que dans l'histoire.

Apprenez-en davantage sur les solutions NI pour les tests fonctionnels ou téléchargez la brochure de solutions pour une lecture plus approfondie concernant les composants et les produits. Vous avez des questions spécifiques sur votre stratégie de test ou un projet de station de test à venir ? Parlez-nous aujourd'hui.

 

©2020 National Instruments. Tous droits réservés. National Instruments, NI, ni.com et LabVIEW sont des marques de National Instruments Corporation. Les autres noms de produits et de sociétés mentionnés sont les marques déposées ou les noms de leurs propriétaires respectifs. Un partenaire NI est une entité professionnelle indépendante avec laquelle il n’existe aucune relation d’agence, de partenariat ou de « joint-venture » entre ces entités et NI.