Análisis de fallos

El análisis de fallos en KF comienza seleccionando un elemento y anotando eventos en su pestaña Evento. Los eventos pueden ser modos de fallo, problemas, etc. Los eventos se anotan directamente en el elemento afectado. En este caso, lo hicimos con la batería, un componente del modelo de bicicleta A.

Añadir eventos es sencillo. Haga clic en el icono indicado arriba y se abrirá el siguiente formulario:

Solo necesita completar el Título; el resto de los campos son opcionales, pero, como con cualquier elemento, puede usar el campo Texto para profundizar en el modo de fallo o el problema y generar un informe completo si es necesario. Los campos Gravedad, Probabilidad y Detección/Controlabilidad se utilizan para establecer el nivel de riesgo del evento, que se explica en detalle aquí.

Una vez que haya anotado algunos eventos en algunos elementos, puede mostrar el informe de fallos []:

En la imagen anterior, puede ver que los eventos relacionados con el elemento investigado y sus componentes se muestran en el informe de Análisis de Fallas. En este ejemplo, elegimos ver el informe del Modelo de Bicicleta A, que incluye eventos relacionados con sus componentes Batería y Cadena. El formato del informe es una versión simplificada de los informes FMEA (Análisis de Modos y Efectos de Fallas) que se utilizan comúnmente en la industria automotriz y otras industrias.

Puede optar por mostrar el árbol de fallo [] en cualquier momento. A medida que agregues componentes y eventos a tu elemento, estos se mostrarán automáticamente en el árbol:


Un formato FMEA simplificado

El Análisis de Modos y Efectos de Fallos (FMEA) es un método estructurado que se utiliza para identificar posibles puntos de fallo en un sistema, evaluar sus efectos y priorizar las acciones para mitigar los riesgos asociados. Tradicionalmente utilizado en ingeniería, fabricación y áreas críticas para la seguridad, el FMEA ayuda a los equipos a centrarse en la prevención de problemas antes de que ocurran, examinando cómo podrían fallar los componentes, procesos o sistemas, por qué podrían fallar y cuáles serían las consecuencias.

Truke KF ofrece una implementación simplificada del FMEA con un formato de 4 columnas, que conserva la esencia del método y evita la complejidad burocrática de muchos formularios relacionados con la calidad. Este formato cumple con las normas y metodologías fundamentales (como IEC 60812, DRBFM, DRBTR, Manual VDA/AIAG 2019, etc.).

Las cuatro columnas del FMEA de KF son:

  • Elemento: el elemento que se analiza. Puede ser un componente, un subsistema, un paso del proceso o una unidad funcional. En KF, cada elemento es un objeto de conocimiento estructurado, potencialmente vinculado a una jerarquía (como una lista de materiales) u otros documentos.
  • Evento: Una pila de elementos relacionados con fallos, incluyendo modos de fallo, causas y efectos. Estos se organizan verticalmente bajo el mismo elemento para mantener la coherencia contextual. Esta agrupación vertical permite a los usuarios comprender la cadena de razonamiento del fallo de un vistazo, en lugar de dispersarla en tablas extensas.
  • Acción: Acciones preventivas, correctivas y de detección asociadas con las entradas de fallo. Cada acción es también un elemento de KF con sus propios atributos (incluyendo programación, estado y valores S-O-D), lo que permite una trazabilidad completa, el seguimiento del progreso y la integración con vistas de Gantt si se desea.
  • Riesgo: Una síntesis dinámica de los valores de gravedad (S), ocurrencia (O) y detección o controlabilidad (D/C). Estos indicadores de riesgo pueden seguir interpretaciones clásicas o modernas, incluyendo la aplicación automática del sistema de Prioridad de Acción (PA), según se define en el Manual de FMEA de VDA/AIAG de 2019, y la matriz ASIL de la norma ISO 26262 al aplicar etiquetas relevantes para la seguridad.

La fortaleza del FMEA de 4 columnas de KF reside en su simplicidad y flexibilidad. En lugar de dispersar la información en numerosos campos inconexos, la estructura se mantiene intencionadamente concisa y legible. Al mismo tiempo, el modelo subyacente conserva su eficacia: KF admite la herencia, la progresión del riesgo (efectos de la acción «antes y después»), la vinculación modular de los mecanismos de detección y la integración con documentos de diseño u operativos más amplios.

Al evitar la complejidad excesiva y unificar diversos enfoques de análisis bajo una estructura coherente, el formato FMEA de KF permite a los equipos centrarse en lo realmente importante: comprender los fallos, planificar acciones significativas y mejorar los diseños con confianza y claridad.

DRBFM y DRBTR

Ambos métodos tienen su origen en Toyota y responden a una limitación del FMEA clásico: un análisis completo es costoso, y la mayor parte del tiempo solo una fracción del diseño ha cambiado realmente. En lugar de repetir el análisis completo, ambos métodos concentran la atención exactamente donde se ha introducido nuevo riesgo.

DRBFM — Design Review Based on Failure Mode

El DRBFM pregunta: ¿qué ha cambiado respecto al diseño de referencia y qué nuevos modos de fallo podrían introducir esos cambios? El concepto central es la preocupación — no una enumeración sistemática de todos los modos de fallo, sino las inquietudes concretas que un ingeniero experimentado tiene sobre un punto de cambio específico. El diseño de referencia (lo que funcionaba antes) se da por válido; la revisión se concentra únicamente en las desviaciones respecto a él.

Correspondencia con KF

El diseño de referencia se representa como un tipo. El diseño nuevo o modificado es una instancia de ese tipo. Esto divide inmediatamente el análisis de fallos en dos capas:

  • Eventos heredados (con flecha de origen apuntando al tipo) — modos de fallo procedentes del diseño de referencia. Ya son conocidos y están tratados. Aparecen en el informe FMEA pero no requieren nueva revisión a menos que el cambio los afecte.
  • Eventos propios de la instancia (sin flecha de origen, añadidos directamente a la instancia o a sus componentes modificados) — las preocupaciones del DRBFM. Son los modos de fallo que el cambio podría introducir y que no tienen precedente en el diseño de referencia.

El informe FMEA de la instancia produce así, de forma natural, la vista DRBFM: el cuadro completo está disponible para la trazabilidad, pero las nuevas preocupaciones se distinguen visualmente por la ausencia de referencia de origen. Filtrar o centrarse en esos eventos proporciona la revisión orientada al cambio que requiere el DRBFM.

Una vez que una preocupación ha sido revisada y resuelta, puede promoverse al tipo (mediante el checklist invertido) para que futuros cambios de diseño del mismo tipo hereden automáticamente la lección.

DRBTR — Design Review Based on Test Results

El DRBTR pregunta: ¿qué ha revelado el ensayo y qué preocupaciones suscita? Mientras que el DRBFM se desencadena por un cambio de diseño, el DRBTR se desencadena por datos de ensayo. El ciclo es: ejecutar el ensayo → documentar el resultado → identificar cualquier preocupación que el resultado ponga de manifiesto → adjuntar acciones para tratarla.

Correspondencia con KF

Los resultados de ensayo se representan como resultados (outcomes) — ítems vinculados a una acción o directamente a un componente. Cuando un resultado de ensayo revela un problema o un comportamiento inesperado, esa observación se convierte en un evento sobre el ítem correspondiente, con el resultado del ensayo referenciado en la descripción del evento o adjunto como documento.

El evento sigue entonces el flujo estándar del análisis de fallos: se establecen la gravedad, la probabilidad y la detección; se adjuntan acciones; se hace seguimiento del riesgo. El informe FMEA recoge los eventos derivados de ensayos junto con los derivados del análisis de diseño, ofreciendo una visión unificada de todos los modos de fallo conocidos, independientemente de si se identificaron analíticamente o empíricamente.

Las preocupaciones que se repiten en varias campañas de ensayo, o en varios productos del mismo tipo, son candidatas a ser promovidas al tipo — cerrando el ciclo de vuelta al DRBFM y garantizando que la lección llegue a los diseños futuros antes de que comiencen los ensayos.