Conclusiones clave
Un registro de falla de equipo es el registro estructurado de un único evento de avería en un único activo. Captura el activo, el modo de falla, la causa, el método de detección, el inicio y fin del tiempo de inactividad, el tiempo de reparación y las piezas utilizadas. Registros consistentes y codificados son los datos crudos detrás de MTBF, MTTR, la disponibilidad de OEE y los análisis de confiabilidad como el FMEA.
Un registro de falla de equipo es la documentación estructurada de un único evento de falla en un único activo. Responde qué falló, cómo falló, por qué falló, cuánto tiempo estuvo inactivo, qué se hizo para arreglarlo y qué piezas se consumieron. Un registro equivale a una avería, con marca temporal y códigos para que pueda ser contado, ordenado y analizado después.
Un registro de falla no es lo mismo que una orden de trabajo. La orden de trabajo es la instrucción para realizar la reparación. El registro de falla es la evidencia de confiabilidad que deja la reparación. Como dice Reliabilityweb, sin datos de fallas precisos "todo lo que tienes es un sistema de tickets de órdenes de trabajo", y la misma fuente señala que "sin modos de falla, todo lo que tienes es un montón de códigos". El registro es lo que convierte un ticket cerrado en datos de los que se puede aprender.
Esto importa porque casi todas las métricas de confiabilidad que reporta tu planta se construyen sobre estos registros. Si los registros son vagos, adivinados o codificados de forma inconsistente, entonces MTBF, MTTR y el componente de disponibilidad del OEE están todos construidos sobre arena.
Un registro de falla completo captura el activo, la falla en sí, el tiempo, la respuesta y los recursos. Faltar cualquiera de estos rompe un cálculo posterior. La tabla siguiente muestra los campos principales, qué captura cada uno y el fallo común de ese campo.
| Campo | Lo que captura | A qué alimenta | Problema común de calidad de datos |
|---|---|---|---|
| ID del activo | El equipo exacto, hasta el nivel de componente | Pareto por activo, clasificación de criticidad | Registrado contra una línea padre, no contra la unidad que falla |
| Modo de falla | El síntoma observado (p. ej., cojinete agarrotado, motor sobrecalentado) | FMEA, análisis de patrones de falla | Texto libre en lugar de un valor codificado |
| Causa | La razón subyacente (p. ej., desalineación, contaminación) | Causa raíz, prevención de fallas recurrentes | Adivinada, en blanco o confundida con el modo |
| Método de detección | Cómo se detectó la falla (operario, alarma, inspección) | Puntuación de detectabilidad en FMEA | No registrada en absoluto |
| Inicio / fin del tiempo de inactividad | Cuándo el activo se detuvo y reanudó la producción | Disponibilidad OEE, tiempo total de inactividad | Redondeados o completados a posteriori desde la memoria |
| Tiempo de reparación | Tiempo de trabajo activo para restaurar la función | MTTR | Confundido con el tiempo total de inactividad |
| Piezas consumidas | Componentes y cantidades utilizadas | Análisis de costes, planificación de repuestos | Registradas después de los hechos, incompletas |
| Acción tomada | El trabajo correctivo realizado | Biblioteca de remedios, reutilización del conocimiento | Fusionada en el campo causa |
Un punto sutil pero crítico: el tiempo de inactividad y el tiempo de reparación son campos diferentes. El tiempo de inactividad es el reloj completo desde la parada hasta el reinicio, incluyendo la espera por un técnico y la espera de piezas. El tiempo de reparación es solo el trabajo activo de reparación. Almacenarlos por separado es lo que luego te permite distinguir un problema de respuesta lenta de un problema difícil de reparar.
Porque el modo de falla es lo que un técnico observa y la causa es lo que infiere. El modo suele ser correcto. La causa a menudo es una conjetura. Si los fusionas en una sola casilla, nunca podrás distinguir una observación fiable de una suposición esperanzada, y la calidad de tus datos se degrada silenciosamente.
Mantenerlos separados también posibilita la pregunta de confiabilidad más valiosa de todas: ¿aparece el mismo modo repetidamente por la misma causa? Reliabilityweb describe la trampa directamente, advirtiendo que "el nuevo cojinete que acabas de instalar podría fallar 2-3 meses después porque la verdadera causa no se resolvió." Los campos separados son los que hacen aflorar ese patrón.
Un código de falla es un valor estandarizado seleccionable desde un desplegable que clasifica una falla en lugar de describirla en texto libre. Una taxonomía codificada convierte miles de averías en un conjunto de datos contable. El texto libre las convierte en un montón de notas inbuscables.
El estándar de referencia aquí es ISO 14224, la norma internacional para la recopilación e intercambio de datos de confiabilidad y mantenimiento de equipos. Define un lenguaje común de confiabilidad: una taxonomía de equipos en capas más categorías estandarizadas de datos de fallas que cubren datos del equipo, datos de falla como causa y consecuencia, y datos de mantenimiento como acción de mantenimiento y tiempo de inactividad. Incluso fuera del sector del petróleo y gas, donde se originó, ISO 14224 es el referente sobre cómo estructurar los registros de falla para que confluyan en un único conjunto de datos estadísticamente válido (ISO 14224:2016).
La lección práctica para cualquier planta: construye un vocabulario controlado de modos de falla y causas por clase de equipo, aplícalo con desplegables y haz obligatorio el campo de modo de falla antes de que pueda cerrarse una orden de trabajo correctiva. Esa única regla hace más por la calidad de los datos que cualquier herramienta analítica.
Los registros de falla son los datos de entrada para las métricas de confiabilidad principales. Cada métrica es una razón simple, pero cada término en esa razón proviene directamente de tus registros, y por eso la calidad del registro determina la calidad de la métrica.
| Métrica | Fórmula | Campos del registro que consume |
|---|---|---|
| MTBF (Tiempo Medio Entre Fallos) | Tiempo total de actividad / número de fallas | Recuento de fallas, tiempo de operación entre registros |
| MTTR (Tiempo Medio de Reparación) | Tiempo total de reparación / número de reparaciones | Campo tiempo de reparación, recuento de fallas |
| Disponibilidad OEE | Tiempo en marcha / tiempo de producción planificado | Inicio y fin del tiempo de inactividad en cada registro |
Las fórmulas son deliberadamente simples. MTBF es el tiempo total de actividad dividido por el número de fallas, y MTTR es el tiempo total de reparación dividido por el número de reparaciones (LogicMonitor). Observa que ambos dependen de un conteo de fallas preciso. Si las paradas pequeñas no se registran, tu recuento de fallas es demasiado bajo y el MTBF parece artificialmente bueno. Si las marcas temporales de inactividad son imprecisas, la disponibilidad es incorrecta. Para un tratamiento más profundo, consulta nuestras guías sobre MTBF y MTTR y sobre tiempos de inactividad no planificados.
Un Análisis de Modos de Falla y Efectos (FMEA) solo es tan bueno como el historial de fallas en el que se basa. FMEA ordena los riesgos usando severidad, ocurrencia y detectabilidad. Tus registros de falla suministran los datos del mundo real sobre la ocurrencia (con qué frecuencia ocurre realmente cada modo) y la detección (cómo se encontró la falla). Sin registros codificados, esas puntuaciones son opiniones. Con ellos, son evidencia.
Los registros limpios también impulsan la clasificación de criticidad de activos y te permiten construir un programa de mantenimiento preventivo guiado por datos en lugar de una suposición basada en calendario. Un modo de falla recurrente en un activo crítico es el desencadenante típico para convertir una reparación reactiva en una tarea PM planificada.
El problema más común es la causa adivinada: un técnico cierra el trabajo, elige una causa plausible del desplegable y continúa. El segundo es la falta total de registros, donde las paradas cortas nunca se registran. Juntos corrompen tanto los datos de causa como el recuento de fallas, por lo que Reliabilityweb informa que "el 70 por ciento de todas las instalaciones de CMMS nunca han realizado con éxito un análisis básico de fallas."
Usa esta lista de verificación para auditar la disciplina de tus registros de falla:
La mayoría de los registros de falla en CMMS se escriben después por un técnico que reconstruye lo que pasó. Fabrico cambia la fuente de los datos. Como Fabrico se conecta directamente a los PLC de la máquina, las marcas temporales de inicio y fin del tiempo de inactividad se capturan automáticamente desde la línea, no se introducen a mano, por lo que los datos de disponibilidad que alimentan el OEE son precisos en lugar de redondeados.
Para el campo más difícil de todos, la causa, Fabrico utiliza visión por computador para capturar la causa verdadera del tiempo de inactividad en el momento en que ocurre una parada. Eso elimina el mayor riesgo de calidad de datos en cualquier modelo de datos de confiabilidad: una causa adivinada registrada horas después. La falla se convierte entonces en una orden de trabajo digital priorizada y lista con piezas en el teléfono del técnico, con listas de verificación obligatorias por QR, de modo que la acción correctiva y las piezas consumidas se capturan mientras se realiza el trabajo, no recordadas después.
El resultado es un bucle cerrado de falla a solución donde el registro de falla es un subproducto del trabajo, preciso por construcción. Como plataforma construida en la UE con residencia de datos en la UE, Fabrico mantiene esos datos de confiabilidad dentro de un límite de gobernanza claro. [INSERTAR PUNTO DE PRUEBA VERIFICADO - el operador debe confirmar]
Si tus registros de falla están llenos de causas adivinadas y marcas temporales redondeadas, tus números de MTBF y OEE también son conjeturas. Ve cómo Fabrico captura la causa verdadera y convierte cada avería en datos limpios y listos para análisis.
Una orden de trabajo es la instrucción para realizar una reparación. Un registro de falla de equipo es la evidencia estructurada de confiabilidad que deja la reparación: el activo, el modo de falla, la causa, el tiempo de inactividad, el tiempo de reparación y las piezas. Una registra qué hacer, la otra registra lo que sucedió y por qué, para que pueda ser contado y analizado después.
Como mínimo: ID del activo, modo de falla (el síntoma observado), causa (la razón subyacente), método de detección, inicio y fin del tiempo de inactividad, tiempo de reparación, piezas consumidas y acción tomada. El modo de falla y la causa deben ser campos separados y codificados, y el tiempo de inactividad debe almacenarse por separado del tiempo activo de reparación.
Porque el modo de falla es lo que un técnico observa y suele ser correcto, mientras que la causa es lo que infiere y a menudo es una conjetura. Mantenerlos separados te permite distinguir observaciones fiables de suposiciones y detectar si el mismo modo sigue repitiéndose por la misma causa no resuelta.
MTBF equivale al tiempo total de actividad dividido por el número de fallas, y MTTR equivale al tiempo total de reparación dividido por el número de reparaciones. Ambos extraen directamente los registros de falla: el recuento de fallas, el tiempo de operación entre fallas y el campo tiempo de reparación. Registros inexactos o faltantes hacen que ambas métricas sean incorrectas.
ISO 14224 es la norma internacional para la recopilación e intercambio de datos de confiabilidad y mantenimiento de equipos. Define una taxonomía común de equipos y categorías estandarizadas de datos de fallas, incluidas la causa de la falla, la consecuencia y el tiempo de inactividad, de modo que los registros confluyan en un único conjunto de datos estadísticamente válido. Es el referente para estructurar los registros de falla de forma consistente.
El problema más común es una causa adivinada: el técnico elige un valor plausible del desplegable después de los hechos en lugar de capturar la causa verdadera. Combinado con paradas cortas no registradas, esto corrompe tanto los datos de causa como el recuento de fallas, por lo que la mayoría de las instalaciones CMMS nunca realizan con éxito un análisis básico de fallas.
Iniciar sesión
Blog