Diagrama de flujo de investigación de fallos de equipos (RCFA)

¿Qué es diagrama de flujo de investigación de fallos de equipos (rcfa)?

Una investigación de fallo de equipo se hace una pregunta distinta de la que se hace la reparación. La reparación devuelve el activo a producción; la investigación averigua por qué falló, para que el mismo modo de fallo no vuelva a pararlo dentro de tres meses. El diagrama de abajo sigue una investigación desde el fallo hasta el expediente cerrado: la decisión de umbral que determina si este fallo merece una investigación formal, las piezas averiadas etiquetadas y preservadas antes de que nadie las repare o las deseche, un equipo de investigación que reúne el historial de mantenimiento y las condiciones de operación, el modo de fallo identificado, un análisis de causas estructurado, acciones correctivas propuestas, financiadas e implantadas, y un periodo de seguimiento que hay que superar antes de cerrar.

Este diagrama arranca cuando el activo ya está en seguridad, y no es el procedimiento de reparación. Devolver la máquina al servicio, con las piezas y las horas que haga falta, es mantenimiento correctivo y pertenece a su propio proceso; este corre en paralelo y puede terminar más tarde. Tampoco es una investigación de accidente: si alguien resultó herido o estuvo a punto, el caso sigue un proceso de investigación de accidentes laborales con sus propios pasos de notificación a la autoridad y de entrevistas, ejecutado en paralelo donde ambos se solapan. Y tampoco es la investigación genérica de calidad. Un análisis de causa raíz de una reclamación de cliente o de un lote no conforme se hace las mismas preguntas analíticas, pero este diagrama está construido alrededor de un activo: un historial de mantenimiento, una ficha en el registro de activos, un modo de fallo y un plan de mantenimiento al que vuelven los hallazgos. Como toda plantilla de esta biblioteca, es un punto de partida que debes adaptar a los procedimientos de tu organización y a las reglas de clasificación o notificación que apliquen a tus equipos.

Tres decisiones sostienen el proceso, y son justo las que se salta un procedimiento centrado solo en reparar. «¿Cumple los criterios de investigación formal?» corresponde al ingeniero de fiabilidad y no al técnico que atendió la avería, porque la decisión de invertir horas de investigación se toma contra un umbral y no contra lo cargado que iba el turno. «¿La evidencia confirma la causa raíz?» es lo que impide que una teoría plausible acabe siendo la causa registrada: una hipótesis sin probar vuelve al análisis en lugar de escribirse como un hecho. Y «¿El fallo se repitió durante el seguimiento?» es la decisión que la mayoría de los procedimientos omite por completo, al cerrar el expediente en cuanto se implanta la acción y no cuando se ha demostrado que funciona. Juntas, esas tres decisiones son lo que separa un análisis de causa raíz de fallos de una reparación con un formulario grapado.

Qué cubre este diagrama de flujo

En esta plantilla

• Cinco carriles (Operación, Mantenimiento, Ingeniero de fiabilidad, Equipo de investigación y Dirección) repartidos en seis fases: Fallo del equipo, Filtrar y preservar, Investigar, Determinar la causa, Acción correctiva, y Verificar y cerrar
• Una decisión «¿Cumple los criterios de investigación formal?» posterior a la puesta en seguridad del activo, de modo que los fallos rutinarios salen hacia la reparación correctiva ordinaria y solo los que superan un umbral de seguridad, coste, parada o repetición abren una RCFA completa
• Las evidencias tratadas antes de empezar el análisis: las piezas averiadas etiquetadas y preservadas, y una decisión «¿Hay evidencias suficientes para analizar?» con un bucle hacia más recogida de datos cuando el historial de mantenimiento o las condiciones de operación registradas son demasiado pobres
• La secuencia de análisis en el carril del ingeniero de fiabilidad: el modo de fallo identificado, un método estructurado como los 5 porqués o un Ishikawa aplicado sobre él, y la causa raíz separada de los factores contribuyentes antes de redactar nada
• Una decisión «¿La evidencia confirma la causa raíz?» que solo avanza al informe de investigación con una causa realmente respaldada por la evidencia y, si no, vuelve sobre las hipótesis en lugar de registrar una suposición como hallazgo
• Financiación y prueba al final: una decisión «¿La dirección aprueba y financia las acciones?» con un bucle de controles provisionales cuando el presupuesto se aplaza, después la implantación, la actualización del plan de mantenimiento, un periodo de seguimiento y una decisión «¿El fallo se repitió durante el seguimiento?» que reabre el caso ante una repetición

Cuándo usar esta plantilla

• Estás escribiendo o revisando un procedimiento de RCFA y necesitas una sola imagen de las entregas entre operación, mantenimiento, fiabilidad y dirección
• El mismo modo de fallo reaparece una y otra vez en un activo y se siguen registrando reparaciones sin que nadie establezca por qué empezó el fallo
• Estás decidiendo qué fallos merecen una investigación formal y quieres la decisión de umbral y la salida hacia la reparación de rutina dibujadas de forma explícita
• Las acciones correctivas de investigaciones anteriores se acordaron pero nunca se comprobaron, y necesitas un paso de seguimiento antes de poder cerrar el expediente
• Un auditor, una aseguradora o una revisión de fiabilidad ha preguntado cómo investiga tu organización los fallos de equipos y cómo demuestra que la solución funcionó

Cómo funciona

1. Renombra los carriles con tus roles

   Sustituye Operación, Mantenimiento, Ingeniero de fiabilidad, Equipo de investigación y Dirección por las funciones que realmente existen. En una planta pequeña el papel del ingeniero de fiabilidad suele recaer en un técnico veterano o en el planificador de mantenimiento: fusiona carriles en lugar de dibujar una entrega que nadie hace.

2. Escribe tu umbral de investigación en la primera decisión

   Indica qué envía un fallo a una RCFA formal en vez de a una reparación de rutina: una consecuencia de seguridad, una cifra de coste o de tiempo de parada, o un fallo repetido en el mismo activo o con el mismo modo de fallo dentro de un periodo definido. Pon en el nodo las cifras que tu organización usa de verdad y revísalas periódicamente, porque un umbral fijado una vez y nunca revisado dispara de menos a medida que cambia la producción.

3. Fija la regla de preservación de evidencias

   Nombra qué se etiqueta y se retiene antes de empezar la reparación: el componente averiado en sí, fotografías del estado tal como se encontró y los datos de proceso alrededor del momento del fallo. Indica cuánto tiempo se guardan las piezas y quién autoriza su liberación, para que nadie se deshaga de una evidencia antes de que el equipo de investigación la haya visto.

4. Elige tus métodos de análisis

   Sustituye «Análisis estructurado» por los métodos que tu equipo va a usar de verdad y por cuándo aplica cada uno: los 5 porqués para una única cadena causal, un Ishikawa para un fallo con varias categorías plausibles, un árbol de fallos cuando varias condiciones se combinan para provocarlo. Nombrar el método en el nodo evita que la elección acabe siendo por defecto la que usó el último investigador.

5. Define qué significa «confirmada»

   Fija el listón detrás de «¿La evidencia confirma la causa raíz?»: la causa propuesta tiene que explicar el modo de fallo y las condiciones de operación encontradas, y su eliminación habría evitado el fallo de forma plausible. Indica quién tiene autoridad para devolver una hipótesis a más trabajo en lugar de dar por buena una teoría que solo suena bien.

6. Jerarquiza las opciones de acción correctiva

   Decide el orden que aplica tu organización al proponer acciones: primero cambios de diseño o de especificación, después un cambio de procedimiento o de intervalo de mantenimiento, y la formación adicional o un cartel de aviso tratados como la opción más débil y no como la habitual. Indica quién aprueba cada nivel y a partir de qué cifra de coste o de parada hace falta la firma de la dirección.

7. Fija el periodo de seguimiento y recorre un caso cerrado

   Decide cuánto tiempo se vigila un activo después de la solución antes de poder cerrar el expediente, y qué cuenta como recurrencia frente a una avería sin relación. Después toma una investigación terminada, mejor si la primera solución no aguantó, y recórrela sobre el diagrama. Cualquier paso que la gente describa de memoria y no esté dibujado, o que esté dibujado y en la práctica se salte, es el hallazgo que conviene atender antes de publicarlo.

Preguntas frecuentes

¿Cuáles son los pasos de una investigación de fallo de equipo?

Una vez puesto el activo en seguridad, el fallo se contrasta con el umbral de investigación; los que quedan por debajo van a reparación correctiva de rutina y el resto abre una investigación formal. Las piezas averiadas se etiquetan y se preservan, se forma un equipo de investigación y este reúne el historial de mantenimiento y las condiciones de operación en el momento del fallo. Se identifica el modo de fallo y se trabaja con un método estructurado como los 5 porqués o un Ishikawa, con una comprobación de evidencias por el camino que puede devolver al equipo a buscar más datos. La causa raíz se separa de los factores contribuyentes y, una vez confirmada por la evidencia, se redacta en un informe de investigación. Se proponen acciones correctivas, ordenadas desde una solución de diseño hasta la formación, y se llevan a la dirección para su aprobación y financiación, con controles provisionales cubriendo el hueco mientras se acuerda. Se implantan las acciones, se actualizan el registro de activos y el plan de mantenimiento, y se vigila el activo durante un periodo definido antes de cerrar la investigación y difundir los hallazgos.

¿Qué diferencia hay entre una investigación de fallo y el mantenimiento correctivo?

El mantenimiento correctivo es la reparación: diagnosticar la avería inmediata y devolver el activo al servicio, tarde lo que tarde. Una investigación de fallo de equipo es un proceso aparte y paralelo que pregunta por qué se produjo el fallo, usando el análisis de causa raíz de fallos para encontrar el mecanismo que hay detrás y no solo el síntoma que paró la máquina. Una planta puede llevar ambas cosas a la vez: el técnico devuelve el activo a producción mientras el ingeniero de fiabilidad y el equipo de investigación trabajan la causa en segundo plano. No toda reparación merece una investigación, y por eso este diagrama pone una decisión de umbral al principio; los fallos rutinarios y de baja consecuencia suelen tratarse solo como mantenimiento correctivo.

¿Qué diferencia hay entre el RCFA y un proceso general de análisis de causa raíz?

Los pasos analíticos se solapan: definir el problema, reunir evidencias, generar y contrastar hipótesis, confirmar la causa, proponer acciones. El RCFA es ese mismo método aplicado específicamente a un activo físico, y eso es lo que incorpora entradas propias del equipo que una investigación genérica no tiene: un historial de mantenimiento y de fallos del CMMS, las condiciones de operación registradas en el momento del fallo, un modo de fallo con nombre, y un registro de activos y un plan de mantenimiento a los que vuelven los hallazgos, de modo que la solución cambie cómo se mantiene el activo en adelante y no solo describa lo que pasó una vez. Un análisis de causa raíz genérico para una reclamación de cliente o un lote no conforme hace las mismas preguntas sobre un proceso o un producto en lugar de sobre una máquina.

¿Cómo se decide qué fallos de equipo llevan investigación formal?

Fija el umbral antes de que ocurra el fallo, no mientras la gente está delante de la máquina decidiéndolo. Los criterios habituales son una consecuencia de seguridad o ambiental, el coste o el tiempo de parada que causó el fallo, y si se trata de una repetición del mismo modo de fallo en el mismo activo dentro de un periodo definido. La criticidad del propio activo también cuenta: un fallo en un punto único del que depende toda la línea merece un listón más bajo que la misma avería en una unidad redundante. Escribe los criterios y aplícalos de forma coherente, porque un umbral que solo se usa con los fallos que alguien recuerda produce un histórico de investigaciones que no representa lo que realmente está fallando.

¿Por qué este diagrama incluye un periodo de seguimiento antes de cerrar?

Porque una acción correctiva sin verificar es una hipótesis, no una solución. Un cambio de diseño, una tarea de mantenimiento revisada o formación adicional pueden parecer correctos sobre el papel y aun así no atacar el mecanismo real, y la única manera de saberlo es vigilar el activo durante un periodo definido después y comprobar que el modo de fallo no ha reaparecido. Esta plantilla convierte esa comprobación en una decisión propia, con una vía de reapertura si falla, precisamente porque cerrar el expediente en cuanto se implanta la acción es la forma más habitual de que una investigación acabe registrando una solución que nunca funcionó.