Anticipando actividades (uploading) en el Desarrollo de Productos
Todos los que participan en el proceso de desarrollo de productos están familiarizados, de alguna forma, con la agonía del cambio en las últimas etapas, llamada loopbacks (retrabajos). Ya sea una falla inesperada en la prueba de prototipos, un problema de manufactura que aparece durante el inicio de la producción o un problema de garantía, hacer cambios tardíos en el diseño o en la ingeniería produce una cantidad asombrosa de desperdicio. Los equipos de desarrollo se esfuerzan mucho por evitarlos, pero, aun así, casi todos los profesionales consideran los loopbacks inevitables y, de hecho, hasta planifican contando con ellos. Pero, desde una perspectiva lean, esto es lamentable, porque un loopback no es nada más que retrabajo con otro nombre. Los desarrolladores diseñan, analizan y prueban su producto o proceso solo para tener que repetir esas mismas actividades más adelante.
Al igual que en la planta, los retrabajos pueden ser extremadamente costosos. Es ampliamente reconocido que el costo de hacer cambios aumenta a medida que se avanza en la línea de tiempo del proyecto de desarrollo del producto. Como se muestra en la figura anterior, para la mayoría de los productos fabricados, hacer un cambio durante la fase de diseño es más barato que durante la fase de prototipo, que a su vez es más barato que cuando el producto ya está en producción. Y la mayoría de las personas estaría de acuerdo en que la curva de costo es geométrica. De hecho, algunos han dicho que el costo de hacer un cambio en cualquier etapa es diez veces mayor que en la etapa inmediatamente anterior. Así, podemos ver que los cambios tardíos pueden, de hecho, ser costosos.
El consejo habitual para eliminar el problema de los loopbacks es anticipar algunas actividades en el proceso de desarrollo del producto. Pero ¿qué significa anticipar?
Algunos han sugerido que es inteligente comenzar un proyecto de desarrollo de productos acumulando lo que ya sabemos. Por ejemplo, los ingenieros de producción pueden proporcionar al equipo, al inicio del proyecto, información sobre la capacidad de sus equipos de fabricación actuales. Así, los diseñadores del producto pueden (eso esperamos) diseñar dentro de esas restricciones para minimizar los problemas en la planta, a la vez que mejoran la calidad y la eficiencia. El desafío de esta sugerencia es, obviamente, acumular conocimiento. Pero también lo es traducir ese conocimiento de términos de proceso a términos que los diseñadores de productos puedan entender. Las empresas lean dedican un gran esfuerzo a catalogar su capacidad de procesos de manera continua, para que el conocimiento esté listo para implementarse en cualquier nuevo proyecto de desarrollo de productos.
Otros han recomendado anticipar los proyectos de desarrollo reuniendo equipos interfuncionales desde el comienzo del proyecto. Los equipos están formados por representantes capaces de todas las funciones necesarias para llevar un producto al mercado: ventas/marketing, ingeniería de producto, diseño industrial, ingeniería de producción, compras y finanzas, por ejemplo. La idea es garantizar que todos los puntos de vista se consideren desde las primeras etapas para evitar “descubrimientos” inesperados más adelante. Pero una pregunta suele inquietar a estos equipos: ¿qué deben hacer en estas primeras fases?
Stefan Thomke recomienda la experimentación rápida para aprender sobre las posibilidades del producto y del proceso de producción. Podemos ampliar la idea de Thomke con las nociones de Allen Ward sobre el diseño basado en alternativas, lo que ahora llamamos innovación basada en alternativas.
En un enfoque de desarrollo basado en alternativas, los equipos se involucran de una forma muy diferente con los desafíos de desarrollo que enfrentan, en comparación con los enfoques convencionales. Las principales prácticas de la innovación basada en alternativas son:
- Generar múltiples soluciones alternativas para cada subproblema de diseño identificado.
- Comprender estas soluciones frente a los requisitos del proyecto, generando datos mediante análisis, modelos y prototipos de bajo costo. Prestar atención a la granularidad de los datos necesarios – usar modelos de baja fidelidad cuando se necesitan respuestas rápidas y aproximadas, por ejemplo.
- Eliminar una alternativa cuando los datos muestren que no puede cumplir con los requisitos o que es claramente inferior a otra alternativa. Evitar elegir un ganador anticipadamente – utilizar un proceso de eliminación.
- A medida que avanza, intente generar conocimiento reutilizable en forma de límites de diseño y curvas de trade-off. Si usted comprende los límites físicos de un concepto de diseño, y esos límites quedan fuera de los requisitos, puede eliminar esa alternativa con seguridad.
- Permita cierta flexibilidad en los requisitos del proyecto para poder utilizar el conocimiento adquirido y definir los requisitos finales en un punto en el que comprenda más profundamente los trade-offs en juego.
¿Qué está haciendo usted para evitar los loopbacks? ¿Qué otras formas ha utilizado para eliminar el retrabajo en el desarrollo? ¿Tiene ejemplos de alguno de los enfoques anteriores? Comparta sus pensamientos e ideas para que todos podamos aprender más.
