Técnicas para generar, levantar y retener ideas, conocimiento y experiencia operativa en las empresas

Gran problema tiene una empresa  si no tiene un plan acerca de cómo generar, levantar y retener el conocimiento. Por suerte o por desgracia, el esfuerzo que tienen que hacer las organizaciones y las personas para construir y monetizar el know-how requiere mucho tiempo (lustros, decenios) y dinero, y sin embargo perderlo es cuestión de, como mucho tres años, en ocasiones meses. En otras palabras, no podemos permitirnos el lujo de tirar por la borda tanto esfuerzo.

Porque no es lo mismo talento (asociado a personas) que conocimiento (que debe ser compartido entre empresa y empleado), el presente post pretende dar a conocer una serie de herramientas para ideas, prototipos, pilotos, productos y sus procesos asociados en sus diferentes momentos de vida, para trabajadores y empresarios, y asegurar que todo queda en casa. 

Este enfoque bebe de tres pilares principales:

• Los sistemas con los que interactúa el objeto alcance del estudio, que se declaran en el Diagrama de Límites (Boundary Diagram) y el Análisis de Interferencias con el resto de sistemas (Interface Analysis).
• Una Ingeniería Robusta, que se define a través del Parameter Diagram y el Robustness Checklist.
• Un Histórico de Calidad, que nos indica qué ha pasado en los últimos meses /años y qué hemos aprendido.

A todo este proceso se le llama FMA (Failure Mode Avoidance Process) - Proceso de Evitación de Modos de Fallos, y debe concluir, 

• Primero, con un AMFE de Diseño (dirigido a atacar los modos de fallo del producto y su diseño) y un AMFE de Proceso (dirigido a atacar los modos de fallo que aparecerán durante la fabricación del producto en una línea de producción).
• Más tarde y como conclusión del primer paso, en un Plan de Control con sus Instrucciones de Trabajo correspondientes.

Nota: si bien este enfoque ha surgido inicialmente y está orientado a la fabricación de componentes y piezas de producción, se puede reformular y adaptar, también, a cualquier tipo de servicio o incluso desarrollo de Software. 

¿Y todo esto por qué lo hacemos?

Pues por ahorrar tiempo y dinero, básicamente. Y por hacer las cosas bien a la primera, también. El gráfico muestra como, 

1. En etapas muy tempranas del producto la generación de modos de fallos es fácil y sencilla: en muchas ocasiones es obvia y fácil de provocar, y el coste es mínimo.
2. Conforme vamos evolucionándolo y lo testeamos frente a normativa y especificaciones correspondientes, aparecen nuevas oleadas de modos de fallos que deben ser eliminados en nuevas versiones del producto. Similarmente sucede conforme vamos desarrollando la línea de producción y la industrialización del producto.
3. Si bien hasta ahora el coste de las actividades y medidas que se toman es relativamente pequeño, sobre todo cuando esperamos producir decenas de miles de piezas, al acercamos a los hitos de fabricación masiva de un producto, los costes por errores y por tanto cambios de ingeniería se van incrementando incesantemente y casi de manera casi exponencial
4. Si, ya en fabricación masiva, no hemos llegado a un producto y un proceso de producción robusto, los costes asociados por garantías se nos pueden ir de las manos.

Es por ello que una identificación temprana de modos de fallo nos ayudará a tener un diseño robusto del producto y por ende lograr una mayor satisfacción del cliente. Pero el camino es largo y tedioso (hablamos de años), si bien la recompensa también es grande y gratificante. Empezaremos a explicarlo de lo "sencillo" a lo "complicado", de lo "entendible" a lo "complejo". 

Pilar I. Quality History - Histórico de Calidad

Tiene dos vertientes:

• un Plan de FMA
• Tener un registro de problemas de calidad

El Plan de FMA tiene el propósito de describir de manera pictográfica qué herramientas (por qué, cuando y cómo) vamos a emplear para levantar, capturar y retener conocimiento: más vale ser selectivo y no dispararle a todo.  A través de un Plan de FMA podremos: 

• Priorizar los sistemas a trabajar, en base a su complejidad, impacto de una nueva tecnología, o criticidad del sistema.
• Priorizar los problemas a solucionar, en base a su severidad e impacto.
• Priorizar las herramientas a utilizar: como decíamos antes, no siempre es necesario hacer uso de todas ellas. La experiencia y el olfato nos ayudarán a elegir la mejor herramientas para acabar con nuestros problemas.
• Identificar en qué momento hay que emplear cada una de las herramientas seleccionadas

Al final del día, el FMA Plan ayudará a la Dirección de la Empresa y también a cualquier recién llegado a conocer, mediante un mapa y a alto nivel, qué herramientas se han empleado. Es un documento vivo, que cobra especial relevancia sobre todo al inicio y al final del proceso.  

En cuanto al Histórico de Calidad, tiene el siguiente propósito: 

• Entender y explicar los fallos, tanto durante el proceso de producción como las garantías que lleguen del mercado.
• Se trata de reconocer la voz de las diferentes partes de interés. 
• Esto incluye aprender las necesidades del cliente, tanto externo como interno, incluso aunque no las verbalice o no las sepa explicar. Para ello recurriremos al análisis y se usará la herramienta 8D.
• Entender el tipo de retroalimentación (feedback) de estas partes de interés: 
• ¿Se trata de una insatisfacción o un fallo?
• ¿Cómo de grave es? (severidad)

Con la ayuda del Histórico de Calidad alcanzaremos los siguientes objetivos:

• Validar asunciones mediante el diseño de experimentos y otras herramientas de análisis
• Conocer la causa raíz y los puntos de escape de los problemas que hemos tenido:
• ¿Cuál ha sido el mecanismo de fallo?
• ¿Ha sido el fallo una gap en la Especificación, en los ensayos que se han realizado?
• ¿Ha sido un fallo de producto, o de proceso?
• ¿Dónde, en el proceso de ingeniería, se ha producido el fallo? ¿En qué fase?
• Contra medidas: 
• ¿Qué características de diseño / especificaciones han cambiado antes o después de que ocurriera el problema?
• Mejoras en ensayos:
• ¿Cuál ha sido el contenido de los ensayos?
• ¿Algún ensayo ha cambiado su procedimiento?

Pilar II. System Definition - Definición del Sistema

Mediante la Definición del Sistema conseguiremos definir el alcance de lo que queremos analizar (sus límites), hacer zoom y poder visualizarlo con vista de halcón o a nivel de detalle (en función de las necesidades que tengamos) y entender su complejidad, así como de qué manera interactúa con sus elementos vecinos limítrofes importantes.

La definición del sistema se compone de dos documentos fundamentalmente:

• El Diagrama de Bloques & Límites (Block & Boundary Diagram)
• La Matriz o Tabla de Interferencias (Interface Matrix or Interface Table)

El proceso es el siguiente: Boundary Diagram > Interface Matrix > DFMEA

No olvidar:

• Es importante identificar los elementos principales, comprender cómo interactúan entre sí y cómo pueden interactuar con los sistemas externos.
• Dado que las interferencias pueden contener hasta el cincuenta por ciento o más del total de modos de fallo, es esencial que cualquier AMFE considere cuidadosamente las interferencias entre subsistemas y componentes, además del contenido de los subsistemas y componentes mismos.

Boundary Diagram

Un Diagrama de Límites es una ilustración gráfica de relaciones que existen entre los subsistemas, montajes, subconjuntos y componentes dentro del objeto en estudio, así como las interferencias con los sistemas y entornos vecinos.

Características principales de un Boundary Diagram (BD):

• Al comenzar un nuevo diseño: un diagrama de límites podemos pintarlo con unos pocos bloques que representarán las funciones principales y sus relaciones a nivel del sistema.
• A medida que madura el diseño: se pueden revisar los diagramas de límites o desarrollar otros adicionales para ilustrar un nivel de detalle más bajo, hasta el nivel de los componentes.
• ¡Ojo! El Boundary Diagram es un documento obligatorio del DMFEA puesto que, a posteriori, el primero definirá el alcance del segundo. Además, el BD divide los DFMEA del Sistema en otros DFMEA más manejables.
• Al fin y al cabo, lo que viene a hacer un BD es proporcionar fuentes de información al FMEA:
• Salidas, previstas como funciones
• Las interacciones del sistema pueden ayudar a identificar la (s) causa (s) de fallo

Pasos para construirlo:

1. Identificar los elementos principales.
2. Dibujar un diagrama de bloques que incluya todas las piezas, subconjuntos o sistemas que se conectan directamente.
3. Considerar las relaciones entre todos los elementos del diagrama de bloques e ilustrar cómo interactúan entre sí. Resp: equipo de FMEA
4. Ilustrar cómo interactúan los bloques entre sí - y aquí ya incorporamos la Matriz de Interferencias, que explicamos a continuación. Éstas pueden ser:

• Conexión física (por ejemplo: soportes, pernos, abrazaderas y varios tipos de conectores).
• Intercambio de material (por ejemplo: aire comprimido, fluidos hidráulicos o cualquier otro fluido o intercambio de material).
• Transferencia de energía (por ejemplo, transferencia de calor, fricción o transferencia de movimiento mediante eslabones de cadena o engranajes).
• Intercambio de datos (por ejemplo, entradas o salidas de computadora, bundles de cables, señales eléctricas o cualquier otro tipo de intercambio de información).
• 5. Ilustrar cómo pueden interactuar con los sistemas externos:
• El propósito es tener una imagen holística del sistema en estudio.

Comentarios de interés y Q&A relacionados con el Diagrama de Bloques:

• Si somos capaces de llegar al Paso 4, entonces podemos decir que hemos conseguido un pequeño éxito.
• Relacionado con los elementos a mostrar:
• Se han de mostrar todas las piezas necesarias para que el sistema funcione.
• También se considerarán los componentes cercanos.
• Jerarquía:
• Se ha de visualizar siempre un subsistema superior y uno inferior.
• Debemos incluir la interfaz con el cliente.
• Interferencias: cada persona, lugar y cosa deben ser considerados

Análisis de Interferencias

Una Matriz de Interferencias de un sistema ilustra las relaciones entre los subsistemas, montajes, submontajes y componentes dentro del objeto en estudio, así como las interfaces con los sistemas y entornos vecinos.

Respecto al Análisis de Interferencias, podemos decir lo siguiente:

• Se han de mostrar todos los componentes del sistema y los componentes de interfaz.
• De la misma manera, todos los flujos de energía / señales o transferencias de fuerza.
• Se han de cuantificar las interfaces en términos medibles de ingeniería.
• Como recomendación, programar valores específicos específicos de tecnologías / hardware.
• Es preciso identificar a los propietarios de interfaces transfronterizas.
• Las interfaces deben tener una magnitud y unidades de medida acordadas.
• El alcance de cada bloque debe estar claramente identificado.

Pilar III. Robust Engineering - Una Ingeniería Robusta

Este tercer y último pilar se centra principalmente en:

• La(s) función(es) y cómo conseguirla(s)
• Identificar claramente todo lo que influye sobre esa función
• Qué se puede controlar (factores de control)
• Qué no se puede controlar razonablemente (factores de ruido)

Este pilar es particularmente importante porque las funciones que se identifiquen serán entradas clave para un DFMEA robusto. Se divide en:

• P-Diagram, o Parameter Diagram
• Robustness Cheklist

P-Diagram o Parameter Diagram

La manera de encarar este documento es la siguiente: para cada función específica, podemos:

• Analizar fallos de robustez
• Conocer el impacto de las nuevas tecnologías
• Estudiar las relaciones entre entradas y salidas
• Contemplar los ruidos:
• Podremos identificarlos, si bien su origen se estudia en el Análisis de Interferencias y Diagrama de Límites
• En la medida de los posible, podemos describirlos en unidades físicas, medirlos y rastrearlos

• Tener en cuenta cambios de salida específicos, tanto de magnitud como de rendimiento
• Llegar a entender las transformaciones que deban de ocurrir

No debemos olvidar que el Robust Engineering se centra en la ingeniería, y da respuesta a las decisiones de diseño necesarias para optimizar la producción.

Buenas prácticas del documento

• Ir función a función
• Dibujar un diagrama por función
• En principio, analizar sólo las funciones clave, para luego pasar a las secundarias.
• Respecto a las pruebas y ensayos que se hagan, conviene:
• Identificar contramedidas e influencias requeridas en las pruebas
• Confirmar que las pruebas que se hagan representan situaciones "reales"
• Asegurar que las pruebas incluyan las características adecuadas

Ventajas del documento

Con este documento ganamos las siguientes habilidades:

• Permite identificar las entradas y salidas
• Permite ver de qué manera se transforma el material, la energía o la información
• Permite dividir y trocear los fallos y las pérdidas
• Las fallos de funcionamiento se pueden medir en función de la salida elegida
• El desvío o las pérdidas se pueden describir como salidas independientes
• Permite conocer qué influencias impactan en el rendimiento

Robustness Checklist (RCL)

Este documento tiene un objetivo doble:

• Por un lado, comprender las interacciones entre los factores de ruido y los modos de fallo
• Por el otro, identificar y mejorar la definición de los ensayos a realizar y así garantizar la cobertura de las interacciones del modo de fallo

¿Con qué mentalidad debemos encarar este documento?

• Para algunas funciones importantes, el RCL permite, de manera sistemática, evaluar la utilidad de los ensayos y métodos de evaluación.
• Simplificando: esto es, para cada periodo de tiempo debemos centrarnos en aquellas funciones que van experimentando problemas de solidez o están en riesgo debido a cambios en la aplicación / el entorno operativo. Para ello debemos usar trend charts (dinámicos), no pie charts (estáticos).

No debemos olvidar que el RCL se puede utilizar para justificar las calificaciones de los controles de detección en DFMEA

Buenas prácticas

• El RCL nos ayudará a centrarnos en algunas funciones y modos de fallo cuando lo justifique el historial de calidad o la evaluación de riesgos.
• Los RCL simples son más fáciles de entender y permiten a los equipos concentrarse en el análisis y no en administrar la herramienta.
• Los valores de Ruido aplicados en los ensayos se confirman aquí.
• El RCL debe ser usado como una oportunidad para mejorar los tests.
• Las mejoras que se encuentren para los ensayos deberán ser incluidos como Acción recomendada en DFMEA y confirmarse en Revisiones de diseño.

Pilar IV. El DFMEA o AMFE de Diseño

Un DFMEA o Análisis de Modos de Fallo y Errores del Diseño es una formalización, un "acuerdo legal" entre las partes, acerca del diseño y la revisiones que se han llevado a cabo. Es un documento muy útil para comunicar y justificar mejoras en ingeniería, pruebas y fabricación.

¿Por qué hace falta un DFMEA o un AMFE de Diseño? Por que nos ayuda a gestionar el riesgo desde el punto de vista del producto. Y es que el DFMEA permite:

• Evaluar los controles implantados para un diseño robusto.
• Identificar acciones para reducir el riesgo.
• Establecer controles tanto de detección como de prevención, para toda la vida útil del producto.
• Establecer la acciones pertinentes:

• Priorizado en función del riesgo
• Reduciendo la gravedad, ocurrencia o detección mediante planes de acción
• Mejorando el diseño y mejorando los tests.

• Documentar el análisis.

¿Con qué mentalidad debe afrontarse el documento?

• Con la idea de hacer un análisis exhaustivo, en el que se deben considerar todas las funciones listadas en los documentos anteriores.
• Con la idea de definir todos los elementos: componentes, aspectos de ingeniería, funciones, causas y controles.
• Con el propósito de documentar el conocimiento existente & identificar lo desconocido.

Al fin y al cabo, un DFMEA es como la columna vertebral del FMA Plan. Y esto es así porque un DFMEA reune todas las demás herramientas descritas anteriormente para evitar modos de fallo, y documenta los resultados clave en un solo análisis.

Como podemos observar, de las herramienta analizadas hasta ahora:

• El Histórico de Calidad, Parameter Diagram y Robustness Checklist harán aportaciones al DFMEA. 
• El Diagrama de Bloques y la Matriz de Interferencias son herramientas de apoyo durante la ejecución de DFMEA.
• El Parameter Diagram y Robustness Checklist serán también resultados del DFMEA.

El DFMEA se puede dividir en dos partes: una primera parte en la que se han de describir de manera tácita y precisa las funciones esperadas, y por tanto:

• Describir el desempeño esperado
• Incluya requisitos "tácitos"
• Describir los modos de fallo
• Cuantificar la magnitud del incumplimiento a través de tablas pre establecidas, en cuanto a gravedad y ocurrencia
• Identificar las causas detalladas
• Explicar los mecanismos específicos del modo de fallo
• Confirmar las contramedidas a adoptar

Una segunda parte en la que se analizan los fallos y se tratan de evitar los errores:

• Descripción de los fallos que pueden ocurrir y que ya han ocurrido 
• Análisis de estos fallos, y cómo prevenirlos
• Evaluar las consecuencias 
• Explicar por qué el diseño o los tests previstos no permitirán que los fallos se escapen de los Quality Gates previstos

Y llegados a este punto... ¿Cómo termina todo?

Pilar V. El DVPV Plan

Toda la historia para acabar, al fin, con una batería de ensayos analíticos y físicos que nos permitirán:

• Verificar el desempeño
• Verificar la ausencia de modos de fallo

Los DVPVs no son más que ensayos que nos tienen que permitir asegurar:

• Verificar el diseño (DV): Análisis o pruebas ejecutados para demostrar que los diseños nuevos o modificados, o las nuevas aplicaciones de diseños existentes, cumplirán con las expectativas del cliente, en el entorno previsto, durante la vida útil del producto.
• Verificar el producto en el proceso de producción (PV): Análisis o pruebas ejecutados para validar que los productos elaborados en líneas y procesos de producción, a partir de herramientas, cumplirán con las expectativas del cliente, en el entorno previsto, durante la vida útil del producto.

Así pues, el DVPV Plan deberá asegurarnos: 

• que todos los modos y causas de fallo estén cubiertos
• que los ruidos representen correctamente la realidad y están, en la medida de lo posible, controlados
• que el diseño cumpla con los requisitos en presencia de todos los factores de ruido significativos.
• Verificar que las piezas de producción cumplan con los requisitos en presencia de todos los factores de ruido significativos.

El DVPV es un documento vivo que se alimenta de las herramientas FMA descritas en este post, y que por tanto también debe ser objeto de refinamiento y mejora, como el resto de documentos descritos.

Buenas prácticas a tener en cuenta son:

• Asegurar que se incluyen los factores de ruido, durante toda la vida útil del producto
• Ojo con el tamaño de la muestra, pues debe ser estadísticamente significativo.
• Los criterios de aceptación deben ser acordados entre todas las partes, y deben ser medibles (fundamental).
• Merece la pena poner el foco en las pruebas de componentes críticos identificados

Conclusiones

Si has llegado hasta aquí, felicidades. Si además has implantado todas y cada una de estas herramientas, la enhorabuena es doble. Porque no es fácil, y porque requieren muchos recursos y mucho conocimiento.

Dicho esto y volviendo al inicio del documento, ganar la habilidad de generar, levantar y retener talento (no entendido como personas, sino como ideas), es un factor de competitividad que no está resuelto a fecha de hoy, más estos documentos, convenientemente estructurados, ayudan sin duda a aterrizar el tremendo reto.