Causa raíz de una avería: del porqué a la acción

Un equipo se para, alguien lo repara y el trabajo se cierra. Tres semanas después se para por lo mismo. Lo que falló la primera vez no fue la reparación: fue que se trató el síntoma y la causa se quedó donde estaba.

El análisis de causa raíz es la disciplina de no cerrar la avería hasta saber por qué ocurrió. No hace falta un equipo de fiabilidad ni un software caro. Hace falta una hora, una pregunta repetida y datos de verdad.

Qué es y qué no es

Una causa raíz es la más profunda de las que puedes corregir. Si la eliminas, el fallo no vuelve; si solo eliminas una causa intermedia, vuelve con otra forma.

Dos precisiones que evitan malos usos:

No busca culpables. Una avería que acaba en «el técnico se equivocó» es un análisis parado a mitad. La pregunta siguiente es qué permitió ese error: un procedimiento ambiguo, una pieza mal identificada, un turno sin relevo.

No se hace para todas las averías. Analizar cada fallo es inviable y, además, innecesario. Se reserva para las que cumplen alguna de estas condiciones: se repiten, paran un equipo crítico, tienen riesgo de seguridad o cuestan mucho más de lo habitual.

Los cinco porqués (5 porqués), con un ejemplo

El método más sencillo consiste en preguntar «¿por qué?» sobre cada respuesta hasta llegar a algo sobre lo que se pueda actuar. Cinco es una referencia, no un mandato: a veces bastan tres y a veces hacen falta siete.

Un caso típico en una cámara frigorífica:

1. ¿Por qué se paró la cámara? Porque saltó la protección del compresor.
2. ¿Por qué saltó? Porque trabajaba con sobrecalentamiento.
3. ¿Por qué se sobrecalentaba? Porque el condensador estaba obstruido.
4. ¿Por qué estaba obstruido? Porque no se limpió en la última revisión.
5. ¿Por qué no se limpió? Porque el punto no figuraba en el checklist de esa familia de equipos.

La causa raíz no es el compresor, ni siquiera la suciedad: es un checklist incompleto. Y eso es lo que se corrige, en todas las cámaras a la vez, no solo en la que falló.

El peligro del método es el atajo. Si en el segundo «por qué» respondes «mala suerte», has dejado de analizar. Cada respuesta tiene que poder comprobarse con un dato, una foto o una lectura.

Cuando una cadena no basta: causa-efecto

Algunas averías no tienen una causa, sino varias que coinciden. Para esas sirve el diagrama de causa-efecto, también llamado de espina de pescado o de Ishikawa.

Se escribe el fallo a la derecha y se agrupan las posibles causas en familias. La clasificación clásica son las seis emes:

• Mano de obra: formación, carga de trabajo, relevos.
• Método: procedimiento, frecuencia de revisión, instrucciones.
• Máquina: diseño, desgaste, estado.
• Material: calidad del repuesto, lubricante, consumible.
• Medición: instrumentos descalibrados, lecturas que nadie registra.
• Medio: temperatura, humedad, polvo, vibraciones del entorno.

No es un listado para rellenar entero. Sirve para obligarse a mirar familias que la intuición descarta, y para que el equipo, y no una sola persona, aporte hipótesis. Después se comprueban una a una y se descartan las que no resisten los datos.

Elegir bien qué analizar: Pareto

Antes de analizar nada conviene saber dónde analizar. En casi toda instalación, una minoría de equipos o de tipos de fallo concentra la mayor parte de las horas de correctivo.

Ordenar las averías por tiempo perdido o por coste, y mirar cuáles acumulan el grueso, dice por dónde empezar. Es mejor resolver a fondo tres causas que dejar treinta análisis a medias.

El método necesita datos, y los datos salen de la orden

Este es el punto donde la mayoría de los análisis fracasa: no por el método, sino porque no hay con qué alimentarlo.

Para que una avería se pueda analizar, su orden de trabajo tiene que recoger, al menos, la causa del paro, el tiempo real de intervención, el material consumido y las lecturas relevantes. Si de la avería solo queda «se arregló», el análisis se reduce a opiniones.

En GMAO CLOUD eso se registra en campo desde la app de técnicos, que funciona sin cobertura, y queda en el histórico del activo. Los informes permiten luego agrupar por equipo y por causa para encontrar el fallo repetido. El detalle de cómo mirar ese conjunto está en analizar las averías para que no se repitan.

De la conclusión a la acción

Un análisis que acaba en un informe y no en un cambio ha sido un ejercicio. La conclusión tiene valor cuando se convierte en una de estas cuatro cosas:

Un cambio en el checklist. Como en el ejemplo de la cámara: se añade el punto que faltaba, y se despliega sobre toda la familia de equipos, no solo sobre el que falló. Es la salida más frecuente y la más barata.

Un cambio de frecuencia o de criterio. Si el equipo falla entre revisiones, la periodicidad está mal. Si el desgaste depende del uso, la revisión por tiempo es la herramienta equivocada y conviene pasar a una por contador.

Un cambio de procedimiento o de formación. Cuando la causa es humana pero sistémica: instrucciones poco claras, una tarea que se hace distinto en cada turno.

Una decisión de sustitución o de compra. Cuando el fallo es de diseño o de modelo y no hay mantenimiento que lo compense.

Y todas llevan responsable y fecha. Sin eso, la acción es un deseo. Darla de alta como una tarea más en el calendario, con su plazo, garantiza que se revisa si se hizo.

Cómo saber si ha funcionado

La prueba de una buena causa raíz es que el fallo deja de aparecer en los siguientes ciclos. Se comprueba con el mismo informe que lo detectó, sobre la misma familia de equipos y dejando pasar al menos uno o dos periodos completos de revisión.

Si vuelve a aparecer, no se ha llegado a la raíz. Es una información útil: se reabre el análisis con un dato más, en lugar de dar el problema por resuelto.

Los errores que más se repiten

Parar en la primera causa plausible. La respuesta rápida suele ser la intermedia. Tiene que haber un dato detrás de cada «por qué».

Analizar solo cuando hay una parada grande. Las averías pequeñas y repetidas suman más horas que el incidente espectacular, y son más fáciles de resolver.

Hacerlo en solitario. Quien lo repara conoce lo que no está escrito en ninguna parte. Una reunión de veinte minutos con el técnico que lo vio vale más que una hora de informes.

No cerrar el círculo. Se identifica la causa, se redacta la conclusión y nadie vuelve a mirarla. La revisión del resultado tiene que estar en la agenda desde el primer día.

Cuándo no merece la pena

Hay fallos súbitos sin degradación previa y equipos donde reparar cuesta menos que analizar. Para esos, el correctivo es la estrategia correcta. La criticidad del equipo es lo que ayuda a decidirlo una vez por familia, en lugar de volver a discutirlo en cada avería.

Sigue leyendo

• MTBF y MTTR: fórmulas y ejemplos
• Analizar las averías para que no se repitan

Preguntas frecuentes

¿Qué es el análisis de causa raíz? Es un método para encontrar la causa más profunda de una avería que se pueda corregir, de modo que no vuelva a ocurrir. Se diferencia de reparar el síntoma, que solo devuelve el equipo a servicio.

¿Cuántos porqués hay que preguntar? Cinco es una referencia, no un mandato. A veces bastan tres y a veces hacen falta siete: se para cuando la respuesta es algo sobre lo que se puede actuar y que se puede comprobar con un dato.

¿Qué diferencia hay entre los cinco porqués y el diagrama de Ishikawa? Los cinco porqués siguen una cadena de causas una tras otra. El diagrama de Ishikawa, o de causa-efecto, agrupa varias causas posibles por familias y sirve cuando el fallo tiene más de un origen.

Si quieres ver qué saldría de tu propio histórico, solicita una demo.