De avería a reparación: convirtiendo el tiempo de inactividad detectado en una orden de trabajo cerrada.

Puntos clave

• Fault-to-fix es el recorrido completo desde el momento en que una máquina se detiene hasta el momento en que una orden de trabajo verificada cierra el problema. La mayoría de las plantas disponen de ambos extremos (datos de tiempo de inactividad y un CMMS), pero no cuentan con nada automático que los conecte.
• El ciclo suele romperse en la transferencia: se registra una parada, pero una persona tiene que notarla, decidir que importa, adivinar una causa y abrir una orden de trabajo manualmente. Ese retraso es donde se ocultan las fallas repetidas.
• Un ciclo automatizado detecta la parada, captura la causa real y despacha una orden de trabajo con el contexto adjunto, de modo que el técnico llega sabiendo lo que ocurrió en lugar de comenzar desde un ticket en blanco.
• La parte difícil no es la alerta, sino la causa. Un ciclo que genera una alerta genérica de «línea caída» sigue dejando el diagnóstico en manos de una persona; el valor proviene de adjuntar una razón precisa a cada parada.

Qué significa realmente "fault-to-fix"

Fault-to-fix describe la ruta completa que recorre un solo evento de tiempo de inactividad: detección, diagnóstico, envío, reparación y verificación. En un ciclo sano, cada paso entrega datos limpios al siguiente sin que nadie los vuelva a introducir. En la mayoría de las plantas la ruta está dividida entre sistemas desconectados, y las lagunas entre ellos se llenan con personas que recuerdan actuar.

El síntoma es familiar. El panel de OEE muestra una parada. El equipo de mantenimiento se entera en la reunión matutina, o cuando un operador se acerca.

Para cuando existe una orden de trabajo, la máquina ya está en funcionamiento y la causa real es una conjetura. El evento se registra como una parada menor y el mismo fallo vuelve la semana siguiente.

Por qué se rompe el ciclo

La ruptura casi siempre ocurre en la transferencia de detección a diagnóstico. Detectar que una máquina se detuvo es fácil; los sensores y contadores lo hacen automáticamente. Saber por qué se detuvo es la parte difícil, y ese es el paso que la mayoría de los sistemas deja en manos de una persona junto a la línea.

• La causa falta o es incorrecta. Un operador elige el código de causa más cercano bajo presión de tiempo, por lo que los datos que deberían guiar la reparación son poco fiables desde el principio.
• La orden de trabajo es manual. Alguien tiene que decidir que una parada merece un ticket y abrirlo, lo que significa que las paradas breves y repetidas nunca generan un registro.
• Se pierde el contexto. El técnico recibe un ticket que dice «Línea 3 caída» sin ninguno de los datos contextuales, por lo que el diagnóstico empieza de nuevo desde cero.

Para ver cómo se clasifican las paradas en primer lugar, consulte inactividad frente a actividad.

El flujo de trabajo automatizado "fault-to-fix"

1. Detectar. La parada se captura automáticamente a partir de la señal del equipo o del sistema OEE, con una marca de tiempo y una duración exactas.
2. Diagnosticar. Se adjunta una causa real a la parada en lugar de un código de motivo adivinado. Aquí es donde la visión por computadora y el contexto del evento hacen el trabajo que un operador apresurado no puede hacer.
3. Despachar. Se abre automáticamente una orden de trabajo, rellenada previamente con el activo, la causa y el contexto de producción.
4. Reparar. El técnico llega con el diagnóstico ya en mano y registra lo que realmente se hizo.
5. Verificar. La orden de trabajo cerrada se vincula al evento original de inactividad, de modo que la recurrencia del mismo fallo se vuelve visible de inmediato.

El sistema de gestión de órdenes de trabajo es la columna vertebral de los pasos tres a cinco, y el programa de mantenimiento preventivo es donde se eliminan los fallos recurrentes mediante diseño.

Fault-to-fix manual frente a automatizado

Qué buscar en una plataforma fault-to-fix

• Captura precisa de la causa, no solo alertas. Una alarma que diga «caída» no es suficiente. Mire cómo la plataforma determina la razón sin depender de una entrada manual hecha con prisa.
• Un modelo de datos único para OEE y mantenimiento. Si el tiempo de inactividad vive en un sistema y las órdenes de trabajo en otro, el ciclo tiene una costura donde se pierden datos. Una única fuente de verdad la elimina.
• Creación automática de órdenes de trabajo con contexto. El ticket debe llevar el activo, la causa y el estado de producción sin reintroducción de datos.
• Verificación del resultado medido. La orden de trabajo cerrada debería vincularse al evento de inactividad para que la recurrencia sea medible.
• Funciona en líneas mixtas y antiguas. El ciclo debe aportar valor antes de que cada activo sea nuevo o esté totalmente instrumentado.

Cómo Fabrico cierra el ciclo

Fabrico está construido como una sola plataforma para OEE y CMMS, por lo que una parada detectada y la orden de trabajo resultante comparten la misma base de datos en lugar de cruzar un punto de integración.

Cuando una línea se detiene, Fabrico utiliza visión por computadora para capturar la causa real del tiempo de inactividad en lugar de dejarlo a un código de motivo, y luego abre una orden de trabajo con esa causa y el contexto de producción ya adjuntos.

La orden de trabajo cerrada se vincula al evento original, de modo que un fallo que vuelve a repetirse es visible en lugar de quedar oculto. Fabrico está desarrollado y alojado en la UE con la residencia de datos en mente y cuenta con la certificación ISO 27001.

Para ver el ciclo funcionar en sus líneas, reserve una demo.

Lecturas relacionadas

• Mejor software para análisis de causa raíz
• OEE para la fabricación
• Sistemas de gestión de órdenes de trabajo
• Inactividad frente a actividad
• Programa de mantenimiento preventivo

Para convertir esto en una decisión de herramienta, vea nuestra visión general de los mejores sistemas de monitorización de producción.

Preguntas frecuentes

¿Fault-to-fix es lo mismo que mantenimiento predictivo?

No. El mantenimiento predictivo intenta actuar antes de que ocurra una falla. Fault-to-fix trata de lo que sucede después de que ocurre una parada: capturar la causa real y convertirla rápidamente en una orden de trabajo cerrada y verificada. Ambos son complementarios, pero fault-to-fix aporta valor incluso en activos sin un modelo predictivo.

¿Necesitamos nuevos sensores en cada máquina?

No. El ciclo debería aportar valor en líneas mixtas y antiguas utilizando señales existentes y el flujo de eventos OEE. La instrumentación completa puede venir más tarde; no es una precondición.

¿Qué hace que el ciclo se rompa con más frecuencia?

La transferencia de detección a diagnóstico. Detectar una parada es fácil; adjuntar una causa precisa es la parte difícil, y una alerta genérica aún deja el diagnóstico en manos de una persona. Un ciclo solo es tan bueno como los datos de causa que captura.

¿En qué se diferencia esto de un CMMS independiente?

Un CMMS independiente gestiona órdenes de trabajo pero normalmente depende de que alguien las abra manualmente. Fault-to-fix conecta automáticamente el evento de inactividad con la orden de trabajo, por lo que las paradas breves y repetidas que nunca recibirían un ticket manual aún generan un registro.