Por qué el calendario para llegar al mercado no es igual al calendario de introducción de nuevos productos (y qué significa esto para los equipos de ingeniería de pruebas) 

Los expertos promocionan el tiempo para llegar al mercado como un indicador de empresas innovadoras y en rápido movimiento. En NI, escuchamos de nuestra comunidad de gerentes de pruebas que metas agresivas para llegar al mercado pueden ejercer una presión intensa sobre ellos y sus equipos. Le pedimos a nuestro especialista en pruebas de producción de productos electrónicos, Graham Green, que nos explicara qué está pasando y las mejores prácticas que pueden aliviar un poco esta presión.

NI: Graham, antes de que entremos en los efectos de la presión en el tiempo para llegar al mercado, ¿puede explicar por qué existe y por qué es más fuerte que nunca?

GG: En pocas palabras, existe porque todos queremos cosas nuevas y las queremos ahora. La Ley de Moore está bien documentada en cuanto a acelerar el rendimiento del procesador y, en consecuencia, impulsar nuevos dispositivos al mercado, pero no es la única. Los nuevos estándares inalámbricos, los asistentes de audio integrados y la tecnología de pantalla y batería se están convirtiendo en elementos diferenciadores con los cuales ser el primero en llegar al mercado ofrece un beneficio significativo. Veo que los dispositivos se vuelven más complejos aunque los intervalos entre lanzamientos se acortan, presionando significativamente a los equipos de ingeniería y fabricación.

NI: Si aceptamos que los calendarios de diseño se están acortando, ¿por qué esto tiene un efecto particularmente adverso en las pruebas?


Figura 1. Acortar calendarios a lo largo de un proyecto

GG: Este es una gráfica que he mostrado durante años, y es tan cierto hoy como lo era cuando me uní a la industria. Muestra que cuanto más avanzada está la etapa del proceso de la que usted es responsable, mayor es el riesgo de que su calendario se apriete injustamente. Es raro que hable con un ingeniero de pruebas que no sienta la presión de cumplir con calendarios agresivos de desarrollo. Esto se ve agravado por dos diferencias importantes entre el tiempo para llegar al mercado y el calendario de desarrollo de las pruebas:

  1. Las estaciones de pruebas deben implementarse mucho antes del lanzamiento de un producto.
    Idealmente, los probadores están listos para las ejecuciones de pre-producción a medida que se desarrolla una línea de fabricación. Esto ayuda a identificar las fallas de ensamblaje con anticipación para maximizar el rendimiento, y pueden pasar semanas o incluso meses antes del lanzamiento del producto. A veces, los planificadores pasan por alto este paso.
  2. Incrementar el volumen de la producción requiere no una estación de prueba, sino muchas.
    Usted logra un impacto no al llevar una sola unidad al mercado, sino al fabricar un volumen suficiente para satisfacer la demanda del mercado. El éxito depende de la capacidad del equipo de pruebas para replicar e implementar múltiples probadores de manera rápida y eficiente.

NI: Analicemos uno a la vez. Hacer que la primera estación de prueba esté en funcionamiento a tiempo parece fundamental: ¿qué pueden hacer los equipos de ingeniería de pruebas para generar confianza en que lograrán esto de manera confiable?

GG:  La respuesta del libro de texto es hablar sobre herramientas de software de alta productividad o desarrollar las habilidades del equipo de trabajo para lograr un desarrollo eficiente en grupo. Si esto le interesa, consulte estos recursos de LabVIEW y del Centro de Excelencia. Pero hay un factor menos difundido que tiene un gran efecto en cumplir con los calendarios: Planificación de pruebas eficaz.

El primer obstáculo de planificación es garantizar que sus casos de prueba cubran todos los requisitos de la especificación de la prueba. Descubrir que un caso de uso no está cubierto y agregarlo más tarde resulta significativamente ineficiente. Todos hemos sentido el efecto de los cambios de última hora, especialmente en líneas de prueba altamente distribuidas, en las que equilibrar el tiempo de ciclo es fundamental.

Puede evitar esto colaborando de cerca con los equipos de diseño para realizar análisis de cobertura, "vinculando" los casos de prueba desde la especificación de su prueba hasta los requisitos del producto. Por supuesto, es fácil decir "colaborar de cerca" y más difícil convertirlo en una realidad organizacional.

Si desea asegurar un asiento igual en la mesa, debe demostrar cómo la participación de la ingeniería de pruebas beneficia a otros equipos. Los cambios de especificación (especialmente en etapas posteriores) suelen causar la mayor fricción, por lo que este es un gran lugar para comenzar. Al definir un proceso de gestión de cambios para los requisitos y las especificaciones de las pruebas, todos tienen éxito, lo que puede resultar en una mayor colaboración. NI tiene mucha experiencia en esto y nuestros equipos estarán encantados de asesorarle.  

NI: Bien, una vez que haya acordado la especificación de la prueba, ¿cómo puede planificar un desarrollo eficiente?

GG: Antes de avanzar, tenemos que tener confianza en nuestra posición inicial. Queremos minimizar la probabilidad de que la información sobre recursos o capacidades existentes sea inexacta. A los ingenieros de pruebas les encanta reinventar la rueda; nos dedicamos a la ingeniería porque nos encanta hacer cosas. ¿Y qué mejor excusa para escribir código nuevo que la falta de confianza en que el equipo de prueba o la biblioteca de código sea correcto y esté actualizado?

He visto esto una y otra vez con ingenieros que se niegan a usar bibliotecas estándares porque están convencidos de que su camino es mejor. Solamente se necesitan unos pocos intentos fallidos para perder la confianza en el nuevo sistema y volver a las viejas formas. Una vez que se establece este comportamiento, es difícil impulsar el cambio en una organización, sin importar que tan necesario sea.

Una vez más, las mejores prácticas decretan una administración de procesos diligente. ¿Su organización está de acuerdo con quién debe ser informado/autorizado antes de cambiar el hardware en una estación de prueba o una pieza de software reutilizable? ¿Todas las partes saben dónde se almacena esta información y cómo se actualiza esta información? Si bien existen productos de software que realizan un seguimiento de todo esto, usted necesita un impulso y la adopción activa de las partes interesadas para lograr el éxito. Entonces, es fundamental que mantenga esta biblioteca para generar confianza en que los equipos están actualizados y son alta calidad.

NI: ¿Puede darnos un ejemplo de este tipo de estrategia puesto en marcha?

GG: Claro. Neil Evans hizo exactamente esto con su equipo mientras trabajaba en productos de ultrasonido para Philips. Construyeron una biblioteca de módulos de software de código verificado y bien escrito. Su arquitectura fue diseñada desde cero para fomentar la reutilización.

La inversión más significativa en estandarización va de la mano con un equipo principal que configura el framework inicial. Una vez que esto se completa, agregar actualizaciones y mantener las bases de código es un paso más liviano porque, en esta etapa, los equipos de diferentes organizaciones pueden participar como colaboradores locales.

-Neil Evans, gerente sénior de Philips

El equipo de Evans documentó de manera efectiva la funcionalidad y el caso de uso de cada módulo, y alentó a los ingenieros a usarlos correctamente. El éxito inicial pronto impulsó la adopción y la colaboración y el proyecto cobró fuerza. En general, su equipo logró una reducción del 80% en esfuerzos y el calendario de desarrollo de pruebas de introducción de nuevos productos (NPI) de proyectos anteriores comparables (calculado en horas de ingeniería registradas por proyecto).

NI: Hasta ahora, hemos hablado de lanzar esa primera estación de prueba. ¿Qué pasa cuando se trata de escalar sistemas para cumplir con el volumen de fabricación? ¿Cómo podemos mejorar el tiempo de para llegar al mercado?

GG: Tradicionalmente, existe una compensación entre el tiempo dedicado a reafirmar un diseño antes de la réplica y el tiempo dedicado a actualizar las estaciones de prueba replicadas con nuevas revisiones introducidas posteriormente en el proceso. A menos que trabaje en una industria altamente regulada (como los dispositivos médicos), donde la certificación obliga a que los diseños se bloqueen, adoptar un enfoque de prueba más ágil significa que no necesita hacer esta compensación.  

¿Cómo se ve esta agilidad? Primero, diseñe una estación de prueba viable en base a instrumentación modular basada en chasis para que pueda expandir su E/S sin cambiar el espacio ocupado o el diseño del rack. Luego, conecte el software a sus estaciones de prueba para administrar la configuración del sistema, las versiones del software y los datos. De esta manera, puede actualizar de forma remota, reduciendo la implementación y el mantenimiento de software en persona.

Cerrar la brecha entre la tecnología operativa de la estación de prueba y la infraestructura de TI ha recaído durante mucho tiempo sobre los hombros de los ingenieros de pruebas y es una queja común. En la mayoría de los casos, los ingenieros de pruebas no son expertos en comunicaciones de red, bases de datos y tecnología de visualización, lo que supone una carga de desarrollo y mantenimiento para los equipos de trabajo y los aleja del trabajo de ingeniería de pruebas de valor. A medida que más soluciones comerciales, como el software NI SystemLink, ingresan a este espacio de mercado, los ingenieros no solo pueden implementar con confianza iteración tras iteración del código de prueba, sino que reciben otros beneficios como monitoreo del estado del sistema, datos de utilización de activos de prueba, y análisis de datos de prueba más holístico.

NI: Un desarrollo y una implementación ágiles de estaciones de prueba suenan bien, pero ¿puede dar un ejemplo de dónde está sucediendo esto realmente?

GG: Por supuesto. Hablemos del equipo de un fabricante líder de electrodomésticos. Su capacidad para implementar y administrar de forma remota las revisiones de las pruebas justificó su inversión en software de administración de estaciones de prueba para toda la empresa. Además de esto, su amplio acceso a las visualizaciones de datos está generando muchas mejoras en nuevos procesos todos los días, acortando aún más el desarrollo y mejorando las métricas operativas. Su equipo mantiene más de 170 estaciones de prueba y, según su gerente:

Al utilizar SystemLink para lograr un proceso ágil de apagado, instalación y reinicio, pudimos reducir el tiempo de implementación de 30 minutos por sistema a 3 minutos para una línea de producción completa.

-Gerente de ingeniería de pruebas

 

NI: Entonces, ¿qué sigue para mejorar el tiempo para llegar al mercado y el calendario de NPI?

GG: Me entusiasma utilizar el aprendizaje de máquinas para definir mejor qué y cómo probamos, así como para automatizar nuestros flujos de trabajo. El análisis de datos que estudia a cada probador puede identificar áreas críticas que necesitan pruebas rigurosas, así como áreas que podemos optimizar. Obtenemos más valor cuando utilizamos análisis para automatizar procesos en todos los probadores y activos conectados. Por ejemplo, predigo que los futuros programas de prueba se generarán automáticamente a través de un sistema inteligente basado en datos. Una vez que esto sea una realidad, los ingenieros de pruebas pueden iterar rápidamente y optimizar los diseños, y los calendarios de NPI no cumplidos solo existirán en la historia.

Aprenda más sobre las soluciones de NI para pruebas funcionales o descargue el folleto de soluciones para obtener una lectura más detallada sobre las partes y los productos que las constituyen. ¿Tiene preguntas específicas sobre su estrategia de prueba o sobre un próximo proyecto de estación de prueba? Hable con nosotros hoy.

 

©2020 National Instruments. Todos los derechos reservados. National Instruments, NI, ni.com y LabVIEW son marcas registradas de National Instruments Corporation. Otros productos y compañías nombradas son marca registrada o nombres comerciales de sus respectivas compañías. Un partner de NI es una entidad comercial independiente de NI, sin relación de representación, asociación ni participación con NI.