Si queremos mejores resultados en el desarrollo de productos, tenemos que romper con los medios tradicionales de practicar ingeniería y adoptar nuevas metodologías y herramientas. El DFSS (Design for Six Sigma) es una buena alternativa para eso (si la sigla le incomoda, otra posibilidad es el CSS: “Cualquier Sigla Sirve”, desde que se haga lo correcto). Así como en Seis Sigma para procesos se usa la metodología DMAIC (Define, Measure, Analyze, Improve, Control), igualmente en el DFSS es necesario seguir etapas analíticas bien definidas. Pero acaban aquí las semejanzas entre Seis Sigma versión Procesos y Seis Sigma versión Productos, una vez que el ambiente de desarrollo de productos es radicalmente diferente del ambiente de procesos repetitivos.
Actualmente existen abordajes distintos para el DFSS y su metodología central. La que proponemos aquí es la metodología DICOV (Define, Innovate, Configure, Optimize, Validate), cuyas etapas están resumidas en la Figura 1. Vale observar que el DICOV se aplica tanto para desarrollo de productos cuanto para (más proactivamente) desarrollo de tecnologías a ser usadas en los futuros productos. |
| Fig.1 - Haga click para ampliar. |
Por si sólo, el DICOV ya es un medio superior de desarrollar tecnología/ productos en relación a la forma como típicamente se hace por ahí, mismo en multinacionales de gran porte (inclusive en el exterior). Si observamos atentamente la Figura 1 veremos que algunas actividades especificadas por el DICOV no son realizadas en el tradicional abordaje de Ingeniería (lea “TIRO” – la “Técnica Intuitiva para Remoción de Obstáculos”). Por ejemplo: en el estilo TIRO no hacemos un esfuerzo serio para establecer “benchmarks”, pero si partimos de la premisa de que ya sabemos exactamente lo que los clientes quieren, como estamos en relación a los competidores y lo que debemos hacer para mantener la competitividad (lo que corresponde a la fase “Define” del DICOV). Similarmente, en la práctica del TIRO no atacamos con ahínco la cuestión de la innovación: en lugar de primero generar varias alternativas conceptuales para el proyecto y solamente entonces elegir el mejor concepto (fase Innovate), aplicamos mal un “brainstorming” y luego nos “casamos” con la primera idea que surge, la cual normalmente está lejos de ser la mejor. Otro ejemplo: en lugar de explorar sistemáticamente el “design space” (las numerosas combinaciones posibles de los parámetros de ingeniería involucrados en el proyecto) y buscar la configuración óptima en términos de desempeño y costo (fase Optimize), el estilo TIRO ya parte directo para la especificación de tolerancias, lo que además de aumentar el costo no resuelve fundamentalmente la cuestión de la variabilidad funcional durante el uso del producto. Por esas y otras podemos entender que el DICOV representa un salto de calidad sobre las prácticas tradicionales que normalmente se usan para introducir productos en el mercado.
Recordando lo que afirmamos en el artículo anterior, el DFSS no sustituye un proceso estructurado de desarrollo, pero si presta un apoyo valioso al mismo. La Figura 2 ilustra cómo la metodología DICOV se encaja a lo largo de las fases típicas de un proceso de desarrollo de productos. Podemos entonces concluir que la simple adopción del DICOV constituye un progreso considerable. Incluso, para aumentar aun más la eficacia en la realización de cada etapa del ciclo de desarrollo, será necesario hacer uso de herramientas analíticas de apoyo - y eso de manera sistemática - caso contrario corremos el riesgo de regresar al viejo estilo “TIRO”.
 |
| Fig.2 - Haga click para ampliar. |
Por hablar de herramientas de apoyo que mejor contribuyan para cada etapa del DICOV, cabe aquí una alerta. El abordaje Seis Sigma para procesos se fundamenta ampliamente en el uso de herramientas estadísticas. Aunque la Estadística no resuelva todas las preguntas enfrentadas por aquellos que se involucran en un proyecto de mejoramiento de procesos, el abordaje estadístico para procesos tiene sentido y es necesario, dado el gran volumen disponible de datos, la eterna presencia de variación en los mismos y la necesidad de tomar decisiones con base en la interpretación correcta de aquella masa de datos. Pero sea por inercia o por falta de opción, algunos han dado el mismo énfasis estadístico para DFSS, lo que llaman de “proyecto probabilístico”, en contrapuesta a lo tradicional “proyecto determinístico”. Por ejemplo: se dan gran énfasis a la caracterización estadística del comportamiento del producto (después de definido el diseño), se estudian modelos que sirvan para previsión de la confiabilidad o de su complemento, la probabilidad de falla. Pero después de haber militado durante más de una década en esta Seara, afirmo con convicción que un abordaje esencialmente estadístico para desarrollo de productos es al mismo tiempo reactiva e ineficaz, a más de otros males. Porque solamente después de la observación de fallas en ensayos (lo que es posible apenas en fases más adelantadas del desarrollo) es que se inicia el proceso de mejoramiento o “depuración” del proyecto. Eso es demasiado tarde, a más de costar caro. Muchas cosas más eficaces pueden y deben ser realizadas mucho antes, ya desde la concepción inicial del producto.
El ambiente típico de desarrollo de productos tiene varias particularidades que hacen a la Estadística poco aplicable:
- Pocos prototipos disponibles, debido al alto costo de obtenerlos
- Poco tiempo disponible para ensayos, debido a la necesidad de lanzar el producto cuanto antes para ganar mercado
- Falta de datos históricos confiables sobre el desempeño de las nuevas tecnologías que son introducidas cada vez más en los productos
- El hecho de ser virtualmente imposible simular en ensayos el ambiente exacto que el producto va a encontrar durante las fases de manufactura y uso
En tal contexto, la Estadística no es útil. Lo peor: si aquellas limitaciones no fueran reconocidas y si los métodos estadísticos fueran ingenuamente aplicados a partir de premisas inválidas, los profesionales de desarrollo pueden convertirse en víctimas de un juego desleal de números, revestido de una falsa apariencia de análisis científico pero que en general lleva a decisiones equivocadas y de serias consecuencias. Por lo tanto, necesitamos herramientas de otra naturaleza. La Figura 3 muestra nuestra particular elección de las herramientas analíticas que más pueden contribuir para el objetivo del DFSS de generar productos orientados para el cliente, innovadores y robustos contra las causas de variación.
 |
| Fig.3 - Haga click para ampliar. |
En este conjunto existen herramientas nuevas y de alta relevancia, pero el lector ciertamente notará otras que son viejas conocidas. Algunas ya han sido usadas por muchas empresas, sin embargo, típicamente a través de iniciativas aisladas que a lo largo del tiempo acaban formando una verdadera “colcha de retazos”, sin el debido vínculo. El desafío que las empresas enfrentan hoy es promover el uso integrado y coherente de las varias herramientas, en etapas bien definidas a lo largo del ciclo de desarrollo. Este es justamente el mérito de la metodología DICOV, conforme muestra la Figura 4.
La selección de tales herramientas es justificada por algunas características comunes que las vuelven particularmente útiles en el ambiente de desarrollo de productos:
- Su uso no depende de datos numéricos masivos
- Son verdaderamente preventivas, pues pueden ser usadas: a) antes de que ocurran los problemas por la primera vez, e b) cuando todavía estamos desarrollando tecnología, es decir, antes de ser especificados los requisitos de tolerancia para el producto
- Ellas enfocan las necesidades de los clientes y las funciones técnicas que las satisfacen
- Ellas direccionan la efectiva aplicación del know-how de ingeniería
- Estimulan la creatividad y la innovación
- Permiten una revisión más pulida del proyecto
- Son mucho, mucho más eficaces que el “TIRO” tradicionalmente practicado
Además de esto, cada herramienta trae una contribución única, que ninguna otra puede proveer:
 |
| Fig.4 - Haga click para ampliar. |
VOC (Voz del Cliente):
- Sintetiza, detalla y estructura los parámetros de satisfacción de los clientes
- Realiza un benchmarking competitivo, bajo la óptica del cliente
- Prioriza los esfuerzos de mejoramiento e innovación, a partir de la visión del mercado
QFD (Desdoblamiento de la Función Calidad):
- Asegura que la Voz del Cliente (y no la Voz del Ingeniero o la Voz del Ejecutivo) sea priorizada y desdoblada consistentemente, desde el concepto hasta la manufactura
VA (Análisis del Valor) / “Trimming”:
- Estructura todas las funciones técnicas realizadas por el producto
- Cuantifica la relación beneficio/costo (valor) para cada función
- Prioriza acciones para innovación y aumento del valor, además de reducir costo sin perjuicio de la funcionalidad
TRIZ (Teoría de la Resolución de Problemas Inventivos – Innovación Sistemática):
- Multiplica la creatividad técnica de los ingenieros, con base en la ciencia y tecnología
- Usa principios y métodos para innovación, sintetizados a partir de la investigación de millones de patentes de invención
- Pone a disposición una base de conocimiento de más de 1500 efectos físicos, químicos y geométricos
Pugh / Matriz de Priorización (selección de conceptos):
- Asegura juicio criterioso al comparar y priorizar diferentes conceptos alternativos para el producto
- Permite combinar en un único concepto vencedor los aspectos positivos de los mejores conceptos
FMEA (Análisis de los Modos de Falla):
- Con base en el know-how actual, anticipa problemas potenciales conocidos y prioriza el riesgo asociado a los mismos
- Direcciona esfuerzos preventivos para mejoramiento del proyecto
RE (Ingeniería Robusta – Método Taguchi):
- Optimiza el desempeño de la función básica del producto, reduciendo la variabilidad en torno del valor ideal, al mismo tiempo en que reduce costo
- Aumenta la eficiencia en la transformación de energía realizada por el producto, al mismo tiempo que elimina por la raíz diferentes tipos de problema (hasta los desconocidos, que nunca pasaron antes!)
TD (Proyecto de Tolerancias – Método Taguchi):
- Usada (cuando necesario) después de la Ingeniería Robusta, permite identificar cuáles tolerancias críticas deben ser controladas con mínimo aumento de costo, al mismo tiempo en que identifica cuáles tolerancias pueden ser aflojadas, sin perjuicio de la calidad
Una vez convencida de la necesidad de adoptar el DFSS, la empresa deberá encarar con seriedad una estrategia para implementación del mismo, caso contrario estará comprando frustración para los involucrados. Algunos errores comunes a evitar desde el inicio:
- Adoptar DFSS como uno más entre muchos “programas del año”
- Pensar que basta entrenar las personas para usar las herramientas, y todo pasará
- Asumir que DFSS puede funcionar bien dentro de la “cultura técnica” tradicional, sin señalizar claramente a los profesionales que el “TIRO” necesita ser eliminado
- Falta de involucramiento, acompañamiento y cobranza por parte de la alta dirección
Y para asegurar el éxito, basta que las personas involucradas en el liderazgo del DFSS hagan uso de tres pequeños ingredientes: intelecto, corazón y agenda.
Hasta la próxima edición!
Eduardo C. Moura
Comparta este artículo con tus amigos.
