taskfield

Confiabilidad

5 porqués en mantenimiento: análisis de causa raíz de una falla

Cómo aplicar los 5 porqués en mantenimiento con un ejemplo completo, los errores más comunes y cómo registrar la causa raíz para que la falla no vuelva.

Cambiar la pieza rota resuelve la parada de hoy. Descubrir por qué se rompió es lo que evita la parada del mes que viene, y los 5 porqués son la forma más simple de empezar.

Qué son los 5 porqués

El método consiste en preguntar "¿por qué?" a partir del problema observado y, para cada respuesta, preguntar de nuevo. En cada nivel te alejas del síntoma y te acercas a la causa que, si se elimina, impide que la falla se repita.

El número cinco es una referencia, no una regla. A veces la causa raíz aparece en el tercer porqué; a veces en el séptimo. El criterio para detenerse es otro: llegaste a algo sobre lo que el equipo puede actuar y que, una vez corregido, rompe toda la cadena.

Tres condiciones hacen útil el análisis:

  • Un problema bien descrito. "La bomba se paró" es vago. "La bomba B-02 se disparó por sobrecorriente a las 14:10, con 40 minutos de operación" es un punto de partida.
  • Gente de campo en la conversación. Quien hizo la atención sabe lo que vio. El análisis hecho solo en la oficina tiende a quedarse en hipótesis.
  • Cada respuesta con evidencia. Medición, foto, historial de OT, registro de operación. Si la respuesta es una suposición, hay que verificarla antes del siguiente porqué.

Ejemplo completo: la bomba que se disparaba

El caso siguiente es ficticio, armado para ilustrar el método.

En un edificio comercial, la bomba centrífuga de impulsión de agua B-02 se disparó tres veces en dos semanas. En todas, el técnico rearmó el relé térmico y la bomba volvió a funcionar. A la tercera, la supervisión abrió un análisis.

PreguntaRespuestaEvidencia
1. ¿Por qué se paró la bomba?El relé térmico se disparó por sobrecorriente.Relé encontrado disparado; corriente medida por encima de la nominal después del rearme.
2. ¿Por qué subió la corriente?El motor hacía más fuerza de lo normal para girar.Eje con giro pesado a mano, con el motor desenergizado.
3. ¿Por qué el giro estaba pesado?El rodamiento del lado acoplado estaba dañado.Ruido y temperatura alta en el soporte; holgura visible al desarmar.
4. ¿Por qué se dañó el rodamiento?Tenía grasa insuficiente y reseca.Grasa oscura y endurecida al desarmar.
5. ¿Por qué no tenía una lubricación adecuada?La lubricación no estaba en ningún plan preventivo; dependía de que alguien se acordara.Ninguna OT de lubricación para la B-02 en el historial de los últimos doce meses.

Fíjate en la diferencia entre los niveles. El primer porqué lleva a rearmar el relé, algo que se hizo tres veces sin resolver nada. El tercero lleva a cambiar el rodamiento, que resuelve por un tiempo. Solo el quinto explica por qué el rodamiento va a volver a fallar si nada cambia.

La causa raíz casi nunca es una pieza. Es la ausencia de una rutina, un estándar mal definido o una información que no llegó a quien la necesitaba. La pieza es solo donde el problema se hizo visible.

Del diagnóstico a la acción: contención, correctiva y sistémica

Un análisis que termina sin acciones con dueño y plazo no sirvió para nada. Separa las acciones en tres niveles:

  1. Contención. Lo que frena el problema ahora. En el ejemplo: poner en marcha la bomba de reserva y vigilar la temperatura del soporte de la B-02 hasta la reparación.
  2. Correctiva. Lo que elimina el defecto encontrado. Cambiar el rodamiento, verificar la alineación del acoplamiento y lubricar según la especificación del fabricante.
  3. Preventiva o sistémica. Lo que impide que la causa raíz vuelva, en este y en otros activos. Crear el plan de lubricación de la B-02 con una frecuencia definida, revisar si las demás bombas del edificio están en la misma situación e incluir la verificación del soporte en el checklist de inspección.

La tercera acción es la que suele olvidarse, y es la que da retorno. Si el mismo error de registro dejó otras bombas sin lubricación, el próximo disparo ya está en camino en otro lugar.

Errores comunes en el análisis

Quedarse en el síntoma

"El relé se disparó" o "el rodamiento se rompió" son descripciones de lo que pasó, no causas. Si la acción propuesta es cambiar o rearmar algo, probablemente el análisis se detuvo demasiado pronto.

Culpar a la persona

"El técnico se olvidó de lubricar" cierra la conversación sin resolver nada. Pregunta una vez más: ¿por qué dependía de su memoria? La respuesta casi siempre apunta a un proceso que falló, y los procesos se corrigen.

Forzar una sola cadena

Algunas fallas tienen más de una causa que contribuye. En el ejemplo, una desalineación también podría estar acelerando el desgaste del rodamiento. Cuando dos respuestas distintas son verdaderas para el mismo porqué, abre dos ramas y sigue ambas.

No verificar con datos

Una cadena lógica puede ser convincente y estar equivocada. Cada respuesta necesita algo que la confirme: medición, inspección, historial. Sin eso, el análisis solo formaliza la primera hipótesis de quien habló más fuerte.

Cómo registrar la causa raíz en la OT

Un análisis que queda en un papel o en una planilla suelta no se encuentra la próxima vez. Su lugar es la orden de trabajo, con la falla codificada en tres campos:

  • Síntoma: lo que se observó. Ej.: disparo por sobrecorriente.
  • Causa: por qué ocurrió. Ej.: falta de lubricación.
  • Acción: lo que se hizo. Ej.: cambio de rodamiento.

Con listas cerradas en lugar de texto libre, la misma falla recibe el mismo nombre en cualquier OT, de cualquier técnico. Entonces el historial se vuelve consultable: ¿cuántas fallas por falta de lubricación tuvimos en el año? ¿En qué activos? ¿La causa cambia después de crear el plan?

Este registro también alimenta los indicadores. Una falla que se repite hace caer el MTBF del activo, y una causa recurrente bien identificada suele reducir el tiempo de diagnóstico, uno de los cinco tiempos del MTTR.

El texto libre cuenta una historia. El código permite contar cuántas veces se repitió.

Cuándo usar otras herramientas

Los 5 porqués funcionan bien para fallas de causa relativamente lineal, analizadas por un grupo pequeño. En algunos casos conviene escalar:

  • Diagrama de Ishikawa cuando hay muchas causas posibles y necesitas organizarlas antes de investigar (método, máquina, material, mano de obra, medio ambiente, medición). Después, cada rama prometedora se puede profundizar con los porqués.
  • AMEF (FMEA) cuando el objetivo es anticipar las fallas de un equipo o sistema crítico, evaluando modos de falla, efectos, frecuencia y detección antes de que ocurran.

No hace falta empezar por lo más sofisticado. Un equipo que aplica bien los 5 porqués en las fallas repetidas ya está por delante de quien solo cambia piezas.

En taskfield, la OT tiene síntoma, causa y acción codificados, y la IA señala las fallas que se repiten en el mismo activo o en la misma familia de equipos para indicar dónde conviene abrir un análisis. La IA sugiere, el equipo decide.

Resumen

  • Pregunta "¿por qué?" hasta llegar a una causa sobre la que el equipo puede actuar y que rompe toda la cadena.
  • Cada respuesta necesita evidencia; una hipótesis no verificada no sostiene el siguiente porqué.
  • Separa las acciones en contención, correctiva y sistémica, y no te saltes la sistémica.
  • Evita quedarte en el síntoma, culpar a las personas e ignorar las causas múltiples.
  • Registra síntoma, causa y acción con códigos en la OT para que el análisis se pueda buscar.

Calcula ahora. Haz la cuenta con tus propios números en las calculadoras gratuitas:

% Sick units · MTBF

Lee también

Recibe el aviso del lanzamiento

Déjanos tu correo y cuéntanos cómo es tu operación. Te responde una persona, no un robot.

Te avisamos en el lanzamiento. Sin spam.