Sistematización de la Codificación y Registro de Fallas de Mantenimiento
Articulo27 de abril de 2026
El registro de fallas mediante un sistema de codificación es la estructura que permite clasificar y documentar los eventos de averías de manera sistemática dentro del CMMS (por sus siglas en inglés, Computerized Maintenance Management System, también conocido en español como GMAO que es la Gestión de Mantenimiento Asistida por Ordenador), facilitando la identificación de patrones y la toma de decisiones estratégicas.
Este sistema organiza la información en categorías precisas;
En primer lugar, el modo de falla describe cómo se manifiesta la irregularidad en el equipo, mientras que la causa de falla identifica los factores que la originaron, desde errores humanos hasta defectos de fabricación. Por su parte, el mecanismo de falla explica el fenómeno físico subyacente (como desgaste, fatiga mecánica o corrosión). Para pasar finalmente, a el método de detección cual registra cómo fue identificada la anomalía y las consecuencias que evalúan su impacto sobre varios factores como la operación, la seguridad, el ambiente y los costos.
Todo esto debe estar referenciado al componente específico donde ocurrió el daño, ya que, sin esa estructura, cada falla queda como un evento sin contexto. Por el contrario, con ella, el histórico de averías se convierte en la base estadística que alimenta los análisis de confiabilidad y justifica las políticas de mantenimiento, y en un sistema que suele apoyarse en normas como la ISO 14224, la cual establece los criterios para la recopilación y el análisis de datos de fallas en la industria.
El motivo por el que este proceso es importante va mucho más allá de lo que es la administración del mantenimiento por sí misma; se trata de la cultura organizacional, veamos la siguiente premisa y su porque;
Un registro de fallas de calidad debe de buscar siempre ser claro y preciso en el CMMS.
Esto resulta fundamental, ya que define la capacidad de todas las organizaciones para transitar de un modelo reactivo a uno proactivo, lo que se traduce en una organización que aprende de sus fallas en lugar de una que se limita únicamente a repararlas.
Cuando los datos de avería están bien codificados, el equipo de confiabilidad puede empezar a construir las principales métricas y análisis iniciales, tales como los diagramas de Pareto, y calcular el Tiempo Promedio Para Falla y el Tiempo Promedio Para Reparar; permitiendo así identificar a los malos actores y los modos de falla que son crónicos para la operación, cumpliendo así con el objetivo de sustentar cada decisión sobre tareas de mantenimiento en evidencias.
¿Cómo es la ejecución del proceso, y cuál es el flujo que sigue?
El operador observa una anomalía y genera un aviso de avería en el sistema; el equipo de mantenimiento interviene, diagnostica y repara; al cerrar el aviso, y el técnico completa los campos que capturan lo que falló, qué daño tenía el componente, por qué ocurrió y qué acción se tomó.
Ese ciclo, que se va repitiendo una y otra vez sistemáticamente con los campos correctamente completados, construye el historial que los ingenieros de confiabilidad necesitan para hacer análisis estructurados
El propósito final no es la burocracia del registro sino la capacidad que otorga.
Cuando el historial es confiable, la planta puede gestionar por excepción, priorizando los activos que generan el mayor impacto, asignando recursos donde el riesgo es real y reduciendo el mantenimiento reactivo que consume presupuesto sin mejorar la disponibilidad.
¿Qué significa realmente documentar una falla?
Documentar una falla no es simplemente lo mismo que registrar que algo dejó de funcionar.
La diferencia entre ambas acciones determina si el historial del CMMS será útil para análisis futuros o solo para contabilidad reactiva.
El nivel más básico, y el más común en la industria, es aquel en que el sistema de gestión funciona como una plataforma de tickets. Alguien escribe bomba vibra o motor no arranca, el técnico la repara y el aviso se cierra con una línea de descripción. Ese registro informa que algo ocurrió y que alguien lo resolvió; sin embargo, no dice qué componente específico falló, bajo qué mecanismo se deterioró ni cuál fue la causa.
A partir de esa información, no es posible calcular indicadores confiables ni identificar patrones de falla repetitiva. El personal depende entonces del intercambio verbal con operadores y mantenedores para reconstruir la causa raíz, lo que resulta valioso como complemento, pero nunca como sustituto del dato estructurado.
Existe un segundo nivel, en el que se realiza una búsqueda por palabras clave en múltiples órdenes de trabajo y, si coincide con algún registro, se revisan una a la vez. Los datos existen, pero no pueden agregarse para análisis estadístico porque dependen del texto libre que cada técnico escribió.
Un tercer nivel consiste en consultar el historial completo de un activo problemático, lo que permite revisar el trabajo previo, aunque el evento ya haya ocurrido.
El cuarto nivel, y el único que realmente aporta valor analítico, es el análisis estructurado de fallas. Aquí, los datos del CMMS se utilizan para definir dónde enfocarse, identificando los problemas más críticos mediante alguna técnica como un análisis de Pareto. A partir de ahí, se elige un activo específico y se profundiza desde los modos de falla hasta llegar a las causas. Todo este proceso, llamado como el análisis de fallas crónicas, requiere que el personal de campo complete correctamente los campos cada vez que cierre un aviso de avería. Sin esa información, el análisis más detallado no tiene base sólida.
Los elementos del registro estructurado de fallas
Un registro completo captura seis dimensiones del evento:
Desde la jerarquía del equipo afectado y la falla funcional observada, hasta la parte objeto o componente donde ocurrió el daño. Asimismo, integra el código de daño que describe el mecanismo físico, el código de causa que explica el origen y el código de actividad que registra qué se hizo para resolverlo; donde cada campo cumple una función crucial en los análisis posteriores.
La falla funcional como punto de entrada del aviso
Cuando el operador abre un aviso en el sistema (digamos en SAP, la transacción IW21), lo primero que selecciona es el código de falla funcional.
Este campo categoriza la forma en que el activo dejó de cumplir su función, utilizando una lista estandarizada que incluye opciones como fuga interna, fuga externa de bajo riesgo, fuga externa de alto riesgo, falla en la operación, vibración o ruido, falla en el arranque, alarma inesperada, operación inesperada, entre otras.
Veamos el caso de la siguiente Bomba Centrífuga TB2 AKC2 lo ilustra con claridad.
El 1 de febrero de 2007 a las 8:00 pm se detectó vibración y ruido anormal durante el recorrido de la planta; el equipo fue sacado de operación y se generó el aviso.
En ese momento se selecciona el equipo, se describe brevemente la situación, se elige el código de falla funcional correspondiente al modo "vibración o ruido", y se completan la fecha y hora de inicio de la avería junto con el indicador de paro.
Este primer registro es el de observación: la información disponible es la anomalía operacional, pero el componente afectado y la causa se conocerán al cierre del aviso.
La parte objeto y el código de daño
Al completar la intervención, el aviso se cierra con información mucho más precisa (en SAP, la transacción IW22).
El campo "parte objeto" es donde el técnico registra específicamente qué componente dentro del activo presentó el daño.
Por ejemplo, para la bomba centrífuga, el catálogo despliega los subensambles como parte del equipo: sistema de lubricación, bomba centrífuga propiamente, carcasa, impulsor, empaquetadura, manga del eje, colador.
El técnico selecciona el componente intervenido, que en este caso es el impulsor.
-1780243505248.png%3Falt%3Dmedia%26token%3D6bc32f92-4470-45e6-bef6-9f2c6ff089ff&w=2048&q=75)
A continuación, se registra el código de daño, que describe el síntoma físico encontrado al realizar el diagnóstico.
Dentro de la categoría mecánica aparecen opciones como desbalanceado, deformado, holguras, roto, pegado, rayado, desgaste abrasivo, acumulación de líquido, falta de lubricación, entre otros. En la bomba en cuestión, la inspección reveló que el impulsor estaba desbalanceado, y ese es el código de daño que queda registrado.
La relación entre parte objeto y código de daño es la que hace analíticamente útil el historial.
Registrar el daño sin asociarlo al componente nos impide construir un Análisis de Pareto por subsistema.
Por otro lado, al registrar el componente sin detallar el daño dificulta identificar si dicho componente falla siempre por el mismo mecanismo o por causas distintas que requieren estrategias diferentes.
El código de causa y el código de actividad
El objetivo de los datos sobre causas de falla es identificar el evento desencadenante (causa raíz) en la secuencia que lleva a la falla de un equipo. En consecuencia, el código de causas registra el origen del problema.
Según la ISO 14224, su categorización puede incluir:
Causas relacionadas al diseño.
Causas relacionadas a la fabricación/instalación.
Causas relacionadas a la operación/mantenimiento.
Fallas relacionadas a la gestión.
Otros.
Al desglosar el nivel de mantenimiento aparecen subcategorías como Capacidades/Materiales inapropiados, Servicios no provistos/diseñados, Errores de operación/mantenimiento, Desgastes esperados, y varios más.
Hablando precisamente de "otros" existe una de estas categorías con ese nombre que permite registrar que la causa fue imposible de determinar, que existió capacitación inadecuada o que se trató de un daño accidental.
En el ejemplo de la bomba, el departamento de mantenimiento reportó que no fue posible determinar la causa del daño. Eso se convierte en el código correspondiente a "imposible de determinar".
Un historial que refleja honestamente los límites del diagnóstico resulta más útil que uno que asigna causas sin sustento, porque al menos preserva la veracidad del dato para análisis estadísticos posteriores.
El código de actividad completa el ciclo registrando lo que se hizo con el componente.
Entre esas opciones se pueden incluir una diversidad de verbos como; ajustado, inspeccionado, modificado, servicio, reparado, verificado y otro, con subcategorías que especifican acciones como limpiar, desmontar e inspeccionar, restaurar según especificaciones del fabricante o reemplazar.
Al completar estos cuatro campos de cierre, la parte objeto, el código de daño, el código de causa y el código de actividad quedan documentados con suficiente detalle para contribuir al análisis de fallas crónicas. Además, el sistema también recoge la fecha de terminación del aviso, dato que, combinado con el inicio de la avería, permite calcular el MTTR directamente desde la plataforma.
Cursos recomendados
Por qué los datos en el CMMS suelen ser deficientes
La realidad en la mayoría de las plantas industriales es que el historial de fallas no está en condiciones de sustentar un análisis de confiabilidad robusto. Eso no es un juicio sobre el personal; refleja un problema sistémico con causas identificables. En una encuesta realizada por Predictiva21, se arrojó lo siguiente:
La causa más frecuente, presente en el 31.6% de los casos según datos relevados en la industria, es la ausencia de un equipo responsable del CMMS. Cuando nadie tiene a cargo asegurar que los campos se completen correctamente y que la estructura taxonómica del sistema esté bien configurada, los registros degradan gradualmente.
El segundo factor más común, con el 20.2%, es que el proceso de registro no está formalizado ni documentado, de manera que el técnico que cierra una orden de trabajo no sabe con exactitud qué campos son obligatorios ni qué nivel de detalle se espera.
Otros factores agravan el cuadro. El 14% de los casos refleja que el CMMS no está configurado para registrar modos de falla detallados, lo que impide capturar la información al nivel de granularidad que requieren los análisis.
Un 8.8% corresponde a falta de diseño adecuado en el sistema, con catálogos de fallas mal construidos o jerarquías de activos incompletas.
La confusión sobre qué constituye un modo de falla, esta presente en el 7% de los casos, y refleja una deficiencia de formación, donde el personal no tiene claridad suficiente sobre la diferencia entre falla funcional, modo de falla, mecanismo de daño y causa, y por tanto no puede seleccionar los códigos correctos aunque el catálogo esté bien diseñado.
Otro 7% corresponde a registros que solo capturan datos a nivel de activo sin desagregar por componente, lo que hace imposible cualquier análisis por subsistema.
Un 5.3% de los casos refleja la ausencia de un equipo que analice los fallos.
El 3.5% restante evidencia que los análisis quedan limitados a reuniones informales.
Por último, un 2.6% se debe a la falta de ingenieros de confiabilidad que lideren el proceso.
Lo que ese panorama muestra es que mejorar la calidad del dato requiere intervenir en varios frentes simultáneamente diseñar el CMMS con los catálogos correctos, asignar un equipo responsable de su gestión, definir un proceso documentado de registro y capacitar al personal técnico para que comprenda el propósito de cada campo y la diferencia entre las categorías disponibles.
Del registro individual al análisis de Pareto
Cuando el registro se ejecuta correctamente durante al menos uno o dos años de operación, el historial acumulado permite construir los análisis del comportamiento estadístico que no son posibles a partir de eventos individuales.
El más directo es el diagrama de Pareto de causas de falla, que ordena los modos de falla de un activo o familia de activos por frecuencia o por impacto acumulado en costo o tiempo de parada.
En el caso de un motor eléctrico, un análisis de historial bien estructurado puede mostrar el comportamiento de su deterioro, veamos el siguiente ejemplo:
El análisis de los eventos registrados durante el período evaluado arroja los siguientes resultados destacados:
Desgaste y degradación de rodamientos: Representa el 20% de los eventos, con 15 fallas registradas, un TPPF de 19,960 horas y un TPPR promedio de 20 horas.
Lubricación deficiente o contaminada: Corresponde al 15% de los casos, con 12 fallas registradas y un TPPF de 14,960 horas.
Bajo aislamiento por contaminación o humedad: Representa el 10% de los eventos.
Sobrecargas eléctricas: Constituyen el 8% del total de fallas.
Desalineación del conjunto motor-bomba: Representa el 7% de los eventos.
Cortocircuitos en bobinados: Representan el 7% de los casos.
Otros modos de falla de baja frecuencia: Completan el 33% restante para totalizar el 100% del período analizado.
Esa tabla no es posible realizarla si los avisos de avería no tienen el campo de "parte objeto" completo ni el código de daño, porque ambos son los que permiten distinguir si el daño fue en rodamientos, bobinados o carcasa.
Cada uno de esos modos requiere una estrategia diferente:
Por ejemplo, el desgaste de rodamientos es detectable mediante análisis de vibraciones antes de que sea funcional; la lubricación deficiente se gestiona con procedimientos de lubricación y monitoreo del estado del lubricante; y los cortocircuitos requieren pruebas de aislamiento periódicas.
Si el historial los agrupa bajo un código genérico como un "problema mecánico", el Pareto no puede diferenciarlos y el plan de mantenimiento resultante sigue siendo genérico. Pero, la idea es hacer un plan de mantenimiento con una selección de tareas con criterios competentes y justificadas.
Si el historial agrupa los eventos bajo un código genérico como "problema mecánico", el Pareto no puede diferenciarlos y el plan de mantenimiento resultante carece de precisión. Por el contrario, la idea es construir un plan basado en una selección de tareas criteriosas y justificadas.
El TPPF y el TPPR que produce ese historial también alimentan directamente el cálculo del intervalo P-F para las tareas predictivas.
Conocer que el modo de falla por lubricación deficiente tiene un TPPF de 14.960 horas, con 12 eventos registrados, permite estimar la vida útil esperada entre intervenciones y comparar ese dato con el intervalo P-F de la técnica de detección propuesta.
La taxonomía ISO 14224 como lenguaje común
Para que el registro sea consistente y los datos puedan compararse entre distintas plantas o regiones de una misma corporación, hace falta un marco taxonómico compartido.
El estándar de la ISO 14224 establece ese marco, definiendo una jerarquía de activos que va desde la industria hasta el componente mantenible individual y estableciendo criterios para las categorías de modo de falla, código de daño y causa.
La taxonomía organiza los activos en nueve niveles. Para un análisis de confiabilidad como el RCM, el foco suele ubicarse en los niveles cinco y seis, que corresponden al sistema y a la unidad de equipo respectivamente.
Esa ubicación permite identificar funciones claras sin descender al detalle de los subcomponentes (a menos que sea necesario), y al mismo tiempo mantiene la trazabilidad necesaria para que las órdenes de trabajo puedan asociarse a los elementos correctos dentro de la jerarquía.
Cuando todos los sitios de una corporación registran las fallas bajo el mismo esquema de clasificación, se puede comparar el desempeño entre plantas, identificar qué sitio tiene los mejores indicadores en un tipo de activo específico y transferir las estrategias de mantenimiento que han demostrado ser más efectivas.
Sin toda esa estandarización, los datos son localmente útiles, pero corporativamente incomparables.
Construir la cultura del dato en la planta
El sistema de codificación no produce resultados por sí solo.
Su valor depende enteramente de la disciplina con que se use; y esa disciplina no surge de la instalación de un software, sino de un proceso de formación y de una cultura organizacional que valore el registro técnico como parte del trabajo.
El técnico que cierra un aviso de avería debe saber por qué cada campo es importante. Si no entiende la diferencia entre parte objeto y código de causa, podría rellenar los campos al azar o dejar en blanco los que no conoce. Y si no distingue entre un modo de falla y una falla funcional, no podrá elegir los catálogos correctos aunque estén bien configurados.
Esa comprensión se construye con formación técnica específica, con catálogos bien diseñados que minimicen la ambigüedad al seleccionar y con el respaldo de un equipo que gestione activamente la calidad de los registros.
A mediano plazo, el resultado de esa inversión es un historial que funciona como insumo real para los análisis de confiabilidad, permite calcular indicadores con fundamento estadístico e identifica dónde están los activos más problemáticos. Eso convierte al CMMS de una herramienta de gestión de órdenes de trabajo en una herramienta de inteligencia operativa.
Conclusión
El registro estructurado de fallas es la condición técnica que hace posible cualquier programa de confiabilidad serio. Un registro preciso no ocurre solo por tener un sistema instalado; ocurre cuando el personal entiende qué capturar, el CMMS está diseñado para permitirlo y hay alguien responsable de mantener la coherencia del proceso.
La práctica industrial muestra que la mayoría de las organizaciones registra los eventos, pero no los documenta en un sentido de trazabilidad para las investigaciones. Completar los campos indicados del CMMS, se convierte en el acto que conecta cada evento con la base de conocimiento que sostiene la gestión del activo a lo largo de su ciclo de vida. Cuando ese ciclo se cierra correctamente de forma consistente, el historial acumulado se convierte en el argumento más sólido para cualquier decisión de mantenimiento, desde la selección de una tarea predictiva hasta la justificación de un rediseño.
Dinos qué te ha parecido el artículo
Sistematización de la Codificación y Registro de Fallas de Mantenimiento
Articulo 27 de abril de 2026
El registro de fallas mediante un sistema de codificación es la estructura que permite clasificar y documentar los eventos de averías de manera sistemática dentro del CMMS (por sus siglas en inglés, Computerized Maintenance Management System, también conocido en español como GMAO que es la Gestión de Mantenimiento Asistida por Ordenador), facilitando la identificación de patrones y la toma de decisiones estratégicas.
Este sistema organiza la información en categorías precisas;
En primer lugar, el modo de falla describe cómo se manifiesta la irregularidad en el equipo, mientras que la causa de falla identifica los factores que la originaron, desde errores humanos hasta defectos de fabricación. Por su parte, el mecanismo de falla explica el fenómeno físico subyacente (como desgaste, fatiga mecánica o corrosión). Para pasar finalmente, a el método de detección cual registra cómo fue identificada la anomalía y las consecuencias que evalúan su impacto sobre varios factores como la operación, la seguridad, el ambiente y los costos.
Todo esto debe estar referenciado al componente específico donde ocurrió el daño, ya que, sin esa estructura, cada falla queda como un evento sin contexto. Por el contrario, con ella, el histórico de averías se convierte en la base estadística que alimenta los análisis de confiabilidad y justifica las políticas de mantenimiento, y en un sistema que suele apoyarse en normas como la ISO 14224, la cual establece los criterios para la recopilación y el análisis de datos de fallas en la industria.
El motivo por el que este proceso es importante va mucho más allá de lo que es la administración del mantenimiento por sí misma; se trata de la cultura organizacional, veamos la siguiente premisa y su porque;
Un registro de fallas de calidad debe de buscar siempre ser claro y preciso en el CMMS.
Esto resulta fundamental, ya que define la capacidad de todas las organizaciones para transitar de un modelo reactivo a uno proactivo, lo que se traduce en una organización que aprende de sus fallas en lugar de una que se limita únicamente a repararlas.
Cuando los datos de avería están bien codificados, el equipo de confiabilidad puede empezar a construir las principales métricas y análisis iniciales, tales como los diagramas de Pareto, y calcular el Tiempo Promedio Para Falla y el Tiempo Promedio Para Reparar; permitiendo así identificar a los malos actores y los modos de falla que son crónicos para la operación, cumpliendo así con el objetivo de sustentar cada decisión sobre tareas de mantenimiento en evidencias.
¿Cómo es la ejecución del proceso, y cuál es el flujo que sigue?
El operador observa una anomalía y genera un aviso de avería en el sistema; el equipo de mantenimiento interviene, diagnostica y repara; al cerrar el aviso, y el técnico completa los campos que capturan lo que falló, qué daño tenía el componente, por qué ocurrió y qué acción se tomó.
Ese ciclo, que se va repitiendo una y otra vez sistemáticamente con los campos correctamente completados, construye el historial que los ingenieros de confiabilidad necesitan para hacer análisis estructurados
El propósito final no es la burocracia del registro sino la capacidad que otorga.
Cuando el historial es confiable, la planta puede gestionar por excepción, priorizando los activos que generan el mayor impacto, asignando recursos donde el riesgo es real y reduciendo el mantenimiento reactivo que consume presupuesto sin mejorar la disponibilidad.
¿Qué significa realmente documentar una falla?
Documentar una falla no es simplemente lo mismo que registrar que algo dejó de funcionar.
La diferencia entre ambas acciones determina si el historial del CMMS será útil para análisis futuros o solo para contabilidad reactiva.
El nivel más básico, y el más común en la industria, es aquel en que el sistema de gestión funciona como una plataforma de tickets. Alguien escribe bomba vibra o motor no arranca, el técnico la repara y el aviso se cierra con una línea de descripción. Ese registro informa que algo ocurrió y que alguien lo resolvió; sin embargo, no dice qué componente específico falló, bajo qué mecanismo se deterioró ni cuál fue la causa.
A partir de esa información, no es posible calcular indicadores confiables ni identificar patrones de falla repetitiva. El personal depende entonces del intercambio verbal con operadores y mantenedores para reconstruir la causa raíz, lo que resulta valioso como complemento, pero nunca como sustituto del dato estructurado.
Existe un segundo nivel, en el que se realiza una búsqueda por palabras clave en múltiples órdenes de trabajo y, si coincide con algún registro, se revisan una a la vez. Los datos existen, pero no pueden agregarse para análisis estadístico porque dependen del texto libre que cada técnico escribió.
Un tercer nivel consiste en consultar el historial completo de un activo problemático, lo que permite revisar el trabajo previo, aunque el evento ya haya ocurrido.
El cuarto nivel, y el único que realmente aporta valor analítico, es el análisis estructurado de fallas. Aquí, los datos del CMMS se utilizan para definir dónde enfocarse, identificando los problemas más críticos mediante alguna técnica como un análisis de Pareto. A partir de ahí, se elige un activo específico y se profundiza desde los modos de falla hasta llegar a las causas. Todo este proceso, llamado como el análisis de fallas crónicas, requiere que el personal de campo complete correctamente los campos cada vez que cierre un aviso de avería. Sin esa información, el análisis más detallado no tiene base sólida.
Los elementos del registro estructurado de fallas
Un registro completo captura seis dimensiones del evento:
Desde la jerarquía del equipo afectado y la falla funcional observada, hasta la parte objeto o componente donde ocurrió el daño. Asimismo, integra el código de daño que describe el mecanismo físico, el código de causa que explica el origen y el código de actividad que registra qué se hizo para resolverlo; donde cada campo cumple una función crucial en los análisis posteriores.
La falla funcional como punto de entrada del aviso
Cuando el operador abre un aviso en el sistema (digamos en SAP, la transacción IW21), lo primero que selecciona es el código de falla funcional.
Este campo categoriza la forma en que el activo dejó de cumplir su función, utilizando una lista estandarizada que incluye opciones como fuga interna, fuga externa de bajo riesgo, fuga externa de alto riesgo, falla en la operación, vibración o ruido, falla en el arranque, alarma inesperada, operación inesperada, entre otras.
Veamos el caso de la siguiente Bomba Centrífuga TB2 AKC2 lo ilustra con claridad.
El 1 de febrero de 2007 a las 8:00 pm se detectó vibración y ruido anormal durante el recorrido de la planta; el equipo fue sacado de operación y se generó el aviso.
En ese momento se selecciona el equipo, se describe brevemente la situación, se elige el código de falla funcional correspondiente al modo "vibración o ruido", y se completan la fecha y hora de inicio de la avería junto con el indicador de paro.
Este primer registro es el de observación: la información disponible es la anomalía operacional, pero el componente afectado y la causa se conocerán al cierre del aviso.
La parte objeto y el código de daño
Al completar la intervención, el aviso se cierra con información mucho más precisa (en SAP, la transacción IW22).
El campo "parte objeto" es donde el técnico registra específicamente qué componente dentro del activo presentó el daño.
Por ejemplo, para la bomba centrífuga, el catálogo despliega los subensambles como parte del equipo: sistema de lubricación, bomba centrífuga propiamente, carcasa, impulsor, empaquetadura, manga del eje, colador.
El técnico selecciona el componente intervenido, que en este caso es el impulsor.
A continuación, se registra el código de daño, que describe el síntoma físico encontrado al realizar el diagnóstico.
Dentro de la categoría mecánica aparecen opciones como desbalanceado, deformado, holguras, roto, pegado, rayado, desgaste abrasivo, acumulación de líquido, falta de lubricación, entre otros. En la bomba en cuestión, la inspección reveló que el impulsor estaba desbalanceado, y ese es el código de daño que queda registrado.
La relación entre parte objeto y código de daño es la que hace analíticamente útil el historial.
Registrar el daño sin asociarlo al componente nos impide construir un Análisis de Pareto por subsistema.
Por otro lado, al registrar el componente sin detallar el daño dificulta identificar si dicho componente falla siempre por el mismo mecanismo o por causas distintas que requieren estrategias diferentes.
El código de causa y el código de actividad
El objetivo de los datos sobre causas de falla es identificar el evento desencadenante (causa raíz) en la secuencia que lleva a la falla de un equipo. En consecuencia, el código de causas registra el origen del problema.
Según la ISO 14224, su categorización puede incluir:
Causas relacionadas al diseño.
Causas relacionadas a la fabricación/instalación.
Causas relacionadas a la operación/mantenimiento.
Fallas relacionadas a la gestión.
Otros.
Al desglosar el nivel de mantenimiento aparecen subcategorías como Capacidades/Materiales inapropiados, Servicios no provistos/diseñados, Errores de operación/mantenimiento, Desgastes esperados, y varios más.
Hablando precisamente de "otros" existe una de estas categorías con ese nombre que permite registrar que la causa fue imposible de determinar, que existió capacitación inadecuada o que se trató de un daño accidental.
En el ejemplo de la bomba, el departamento de mantenimiento reportó que no fue posible determinar la causa del daño. Eso se convierte en el código correspondiente a "imposible de determinar".
Un historial que refleja honestamente los límites del diagnóstico resulta más útil que uno que asigna causas sin sustento, porque al menos preserva la veracidad del dato para análisis estadísticos posteriores.
El código de actividad completa el ciclo registrando lo que se hizo con el componente.
Entre esas opciones se pueden incluir una diversidad de verbos como; ajustado, inspeccionado, modificado, servicio, reparado, verificado y otro, con subcategorías que especifican acciones como limpiar, desmontar e inspeccionar, restaurar según especificaciones del fabricante o reemplazar.
Al completar estos cuatro campos de cierre, la parte objeto, el código de daño, el código de causa y el código de actividad quedan documentados con suficiente detalle para contribuir al análisis de fallas crónicas. Además, el sistema también recoge la fecha de terminación del aviso, dato que, combinado con el inicio de la avería, permite calcular el MTTR directamente desde la plataforma.
Cursos recomendados
Por qué los datos en el CMMS suelen ser deficientes
La realidad en la mayoría de las plantas industriales es que el historial de fallas no está en condiciones de sustentar un análisis de confiabilidad robusto. Eso no es un juicio sobre el personal; refleja un problema sistémico con causas identificables. En una encuesta realizada por Predictiva21, se arrojó lo siguiente:
La causa más frecuente, presente en el 31.6% de los casos según datos relevados en la industria, es la ausencia de un equipo responsable del CMMS. Cuando nadie tiene a cargo asegurar que los campos se completen correctamente y que la estructura taxonómica del sistema esté bien configurada, los registros degradan gradualmente.
El segundo factor más común, con el 20.2%, es que el proceso de registro no está formalizado ni documentado, de manera que el técnico que cierra una orden de trabajo no sabe con exactitud qué campos son obligatorios ni qué nivel de detalle se espera.
Otros factores agravan el cuadro. El 14% de los casos refleja que el CMMS no está configurado para registrar modos de falla detallados, lo que impide capturar la información al nivel de granularidad que requieren los análisis.
Un 8.8% corresponde a falta de diseño adecuado en el sistema, con catálogos de fallas mal construidos o jerarquías de activos incompletas.
La confusión sobre qué constituye un modo de falla, esta presente en el 7% de los casos, y refleja una deficiencia de formación, donde el personal no tiene claridad suficiente sobre la diferencia entre falla funcional, modo de falla, mecanismo de daño y causa, y por tanto no puede seleccionar los códigos correctos aunque el catálogo esté bien diseñado.
Otro 7% corresponde a registros que solo capturan datos a nivel de activo sin desagregar por componente, lo que hace imposible cualquier análisis por subsistema.
Un 5.3% de los casos refleja la ausencia de un equipo que analice los fallos.
El 3.5% restante evidencia que los análisis quedan limitados a reuniones informales.
Por último, un 2.6% se debe a la falta de ingenieros de confiabilidad que lideren el proceso.
Lo que ese panorama muestra es que mejorar la calidad del dato requiere intervenir en varios frentes simultáneamente diseñar el CMMS con los catálogos correctos, asignar un equipo responsable de su gestión, definir un proceso documentado de registro y capacitar al personal técnico para que comprenda el propósito de cada campo y la diferencia entre las categorías disponibles.
Del registro individual al análisis de Pareto
Cuando el registro se ejecuta correctamente durante al menos uno o dos años de operación, el historial acumulado permite construir los análisis del comportamiento estadístico que no son posibles a partir de eventos individuales.
El más directo es el diagrama de Pareto de causas de falla, que ordena los modos de falla de un activo o familia de activos por frecuencia o por impacto acumulado en costo o tiempo de parada.
En el caso de un motor eléctrico, un análisis de historial bien estructurado puede mostrar el comportamiento de su deterioro, veamos el siguiente ejemplo:
El análisis de los eventos registrados durante el período evaluado arroja los siguientes resultados destacados:
Desgaste y degradación de rodamientos: Representa el 20% de los eventos, con 15 fallas registradas, un TPPF de 19,960 horas y un TPPR promedio de 20 horas.
Lubricación deficiente o contaminada: Corresponde al 15% de los casos, con 12 fallas registradas y un TPPF de 14,960 horas.
Bajo aislamiento por contaminación o humedad: Representa el 10% de los eventos.
Sobrecargas eléctricas: Constituyen el 8% del total de fallas.
Desalineación del conjunto motor-bomba: Representa el 7% de los eventos.
Cortocircuitos en bobinados: Representan el 7% de los casos.
Otros modos de falla de baja frecuencia: Completan el 33% restante para totalizar el 100% del período analizado.
Esa tabla no es posible realizarla si los avisos de avería no tienen el campo de "parte objeto" completo ni el código de daño, porque ambos son los que permiten distinguir si el daño fue en rodamientos, bobinados o carcasa.
Cada uno de esos modos requiere una estrategia diferente:
Por ejemplo, el desgaste de rodamientos es detectable mediante análisis de vibraciones antes de que sea funcional; la lubricación deficiente se gestiona con procedimientos de lubricación y monitoreo del estado del lubricante; y los cortocircuitos requieren pruebas de aislamiento periódicas.
Si el historial los agrupa bajo un código genérico como un "problema mecánico", el Pareto no puede diferenciarlos y el plan de mantenimiento resultante sigue siendo genérico. Pero, la idea es hacer un plan de mantenimiento con una selección de tareas con criterios competentes y justificadas.
Si el historial agrupa los eventos bajo un código genérico como "problema mecánico", el Pareto no puede diferenciarlos y el plan de mantenimiento resultante carece de precisión. Por el contrario, la idea es construir un plan basado en una selección de tareas criteriosas y justificadas.
El TPPF y el TPPR que produce ese historial también alimentan directamente el cálculo del intervalo P-F para las tareas predictivas.
Conocer que el modo de falla por lubricación deficiente tiene un TPPF de 14.960 horas, con 12 eventos registrados, permite estimar la vida útil esperada entre intervenciones y comparar ese dato con el intervalo P-F de la técnica de detección propuesta.
La taxonomía ISO 14224 como lenguaje común
Para que el registro sea consistente y los datos puedan compararse entre distintas plantas o regiones de una misma corporación, hace falta un marco taxonómico compartido.
El estándar de la ISO 14224 establece ese marco, definiendo una jerarquía de activos que va desde la industria hasta el componente mantenible individual y estableciendo criterios para las categorías de modo de falla, código de daño y causa.
La taxonomía organiza los activos en nueve niveles. Para un análisis de confiabilidad como el RCM, el foco suele ubicarse en los niveles cinco y seis, que corresponden al sistema y a la unidad de equipo respectivamente.
Esa ubicación permite identificar funciones claras sin descender al detalle de los subcomponentes (a menos que sea necesario), y al mismo tiempo mantiene la trazabilidad necesaria para que las órdenes de trabajo puedan asociarse a los elementos correctos dentro de la jerarquía.
Cuando todos los sitios de una corporación registran las fallas bajo el mismo esquema de clasificación, se puede comparar el desempeño entre plantas, identificar qué sitio tiene los mejores indicadores en un tipo de activo específico y transferir las estrategias de mantenimiento que han demostrado ser más efectivas.
Sin toda esa estandarización, los datos son localmente útiles, pero corporativamente incomparables.
Construir la cultura del dato en la planta
El sistema de codificación no produce resultados por sí solo.
Su valor depende enteramente de la disciplina con que se use; y esa disciplina no surge de la instalación de un software, sino de un proceso de formación y de una cultura organizacional que valore el registro técnico como parte del trabajo.
El técnico que cierra un aviso de avería debe saber por qué cada campo es importante. Si no entiende la diferencia entre parte objeto y código de causa, podría rellenar los campos al azar o dejar en blanco los que no conoce. Y si no distingue entre un modo de falla y una falla funcional, no podrá elegir los catálogos correctos aunque estén bien configurados.
Esa comprensión se construye con formación técnica específica, con catálogos bien diseñados que minimicen la ambigüedad al seleccionar y con el respaldo de un equipo que gestione activamente la calidad de los registros.
A mediano plazo, el resultado de esa inversión es un historial que funciona como insumo real para los análisis de confiabilidad, permite calcular indicadores con fundamento estadístico e identifica dónde están los activos más problemáticos. Eso convierte al CMMS de una herramienta de gestión de órdenes de trabajo en una herramienta de inteligencia operativa.
Conclusión
El registro estructurado de fallas es la condición técnica que hace posible cualquier programa de confiabilidad serio. Un registro preciso no ocurre solo por tener un sistema instalado; ocurre cuando el personal entiende qué capturar, el CMMS está diseñado para permitirlo y hay alguien responsable de mantener la coherencia del proceso.
La práctica industrial muestra que la mayoría de las organizaciones registra los eventos, pero no los documenta en un sentido de trazabilidad para las investigaciones. Completar los campos indicados del CMMS, se convierte en el acto que conecta cada evento con la base de conocimiento que sostiene la gestión del activo a lo largo de su ciclo de vida. Cuando ese ciclo se cierra correctamente de forma consistente, el historial acumulado se convierte en el argumento más sólido para cualquier decisión de mantenimiento, desde la selección de una tarea predictiva hasta la justificación de un rediseño.
Dinos qué te ha parecido el artículo