|
Listen to the article
Getting your Trinity Audio player ready...
|
De mantenimiento reactivo a predictivo: el puente real se llama “datos confiables” (y cómo lograrlos).
En manufactura, plantas de alimentos y operaciones de facility management, el discurso de “hacer predictivo” suele arrancar por el lugar equivocado: comprar sensores, activar tableros y esperar que las fallas “se vean venir” solas. En la práctica, el salto desde el mantenimiento reactivo (apagar incendios) hacia esquemas predictivos o basados en condición no depende primero de la tecnología, sino de la calidad y consistencia de los datos que alimentan las decisiones.
Si los datos son incompletos, inconexos o poco confiables, el resultado es predecible: alarmas que nadie atiende, órdenes de trabajo mal priorizadas, análisis de causa raíz sin evidencia y reportes que no reflejan la realidad operativa. La buena noticia es que lograr datos confiables no es un proyecto gigante e inalcanzable; es un conjunto de hábitos, estándares y flujo de trabajo que se pueden implementar por etapas.
Este artículo describe, con enfoque técnico, cómo construir ese “puente” de datos confiables y cómo un enfoque de mantenimiento basado en condición con **CMMSedge** puede ayudar a convertir variables en tiempo real en acciones de mantenimiento trazables, medibles y sostenibles.
1. Reactivo, preventivo, predictivo y “basado en condición”: aclaración técnica rápida.
Antes de hablar de datos, vale la pena alinear definiciones:
– **Reactivo**: se interviene cuando el activo ya falló o está a punto de fallar (parada no planificada, calidad afectada, riesgo de seguridad).
– **Preventivo por tiempo/uso**: se interviene por calendario o por horas/ciclos (cambio de bandas cada X horas, lubricación semanal, inspección mensual). Funciona, pero puede generar sobre-mantenimiento o fallas entre intervalos.
– **Basado en condición (CBM)**: la intervención ocurre cuando la condición medida (vibración, temperatura, corriente, presión, humedad, diferencial de presión, etc.) indica degradación. Es una estrategia muy aplicable cuando hay equipos críticos y variables que se correlacionan con modos de falla.
– **Predictivo**: en sentido estricto, implica modelos (estadísticos o de aprendizaje) que estiman probabilidad/tiempo a falla. En campo, muchas iniciativas “predictivas” realmente comienzan como CBM con umbrales y reglas, y eso está bien: es un camino sólido.
En las tres industrias objetivo (manufactura, alimentos, facilities), el **CBM con monitoreo en tiempo real** suele ser el punto de entrada más práctico, porque permite capturar datos útiles, generar disciplina de respuesta y crear historial de condición vs. intervención. Ahí es donde el tema de “datos confiables” se vuelve central.
2. Qué significa “dato confiable” en mantenimiento (y por qué no es solo “tener datos”).
Un dato confiable no es simplemente un número en una gráfica. Para que sirva en mantenimiento debe cumplir varias condiciones:
- **Identidad clara**: el dato pertenece a un activo y punto de medición inequívocos (Ej.: “Motor M-203, rodamiento lado acople, vibración RMS”).
- **Contexto operativo**: se sabe bajo qué condiciones se midió (carga, velocidad, turno, producto, temperatura ambiente, modo de operación).
- **Calidad técnica**: el sensor o la captura son consistentes (calibración, rango, muestreo, ubicación correcta, sin ruido excesivo).
- **Continuidad y trazabilidad**: el dato se conserva y se puede relacionar con eventos (alarmas, órdenes de trabajo, intervenciones, repuestos, hallazgos).
- **Accionabilidad**: existe un criterio de respuesta (umbrales, severidad, responsables, tiempos de atención).
- **Gobernanza**: hay roles y reglas para alta/baja de activos, catálogos, cambios de configuración y calidad de registros.
Sin lo anterior, se generan dos patologías comunes:
– **“Data sin acción”**: muchas variables, muchas alarmas, poca respuesta, la operación se acostumbra a ignorarlas.
– **“Acción sin evidencia”**: se interviene por intuición o urgencia, pero sin relacionar condición y resultado; no hay aprendizaje.
El objetivo real del mantenimiento basado en condición no es coleccionar datos, sino **convertir datos en decisiones repetibles**.
3. Los cinco “quiebres” típicos que dañan la confiabilidad de los datos.
Quiebre 1: taxonomía de activos inconsistente
Si los activos no están identificados de forma estándar (códigos, ubicaciones, jerarquía), es imposible relacionar condición con historial. En facilities, por ejemplo, verás “AHU-1”, “Manejadora 1”, “UMA 01” como si fueran equipos distintos.
**Acción recomendada**: definir una jerarquía (sitio > edificio/línea > sistema > equipo > componente) y reglas de nomenclatura.
Quiebre 2: puntos de medición mal definidos
Monitorear “vibración del motor” sin especificar punto y dirección reduce el valor diagnóstico. En alimentos, donde hay lavados y humedad, la ubicación del sensor y su protección importan tanto como la variable.
**Acción recomendada**: para cada equipo crítico, definir “puntos de medición” con nombre, ubicación física, variable, unidad, frecuencia y objetivo (modo de falla que cubre).
Quiebre 3: umbrales sin criterio (o copiados sin contexto)
Poner alarmas genéricas (ej. “temperatura > 80°C”) sin considerar operación, carga, estación, producto o histórico, produce falsos positivos y fatiga por alarmas.
**Acción recomendada**: iniciar con umbrales conservadores, usar tendencias y percentiles, y ajustar por condición base (baseline) por activo/tipo de activo.
Quiebre 4: órdenes de trabajo sin campos mínimos
Si al atender una alarma el técnico registra “revisado OK” sin más detalle, el dato de intervención se pierde y el ciclo de aprendizaje se rompe.
**Acción recomendada**: estandarizar campos mínimos: síntoma, hallazgo, causa probable, acción ejecutada, repuestos, tiempo, condición final y evidencia (foto/medición).
Quiebre 5: desconexión entre condición e historial
Cuando el monitoreo queda en una plataforma y el mantenimiento en otra (o en Excel), no hay trazabilidad: la condición “gritó”, pero no queda claro qué se hizo, cuándo, quién, y con qué resultado.
**Acción recomendada**: conectar la alarma a una **orden de trabajo** y asegurar que el cierre deje evidencia. En CMMSedge, el enfoque es justamente ese: alarmas asociadas a órdenes de trabajo y ejecución en móvil, dejando historial e indicadores.
4. El puente real: un flujo de datos a decisión (y de decisión a aprendizaje).
Un esquema práctico para pasar de reactivo a CBM (y preparar el camino para predictivo) se puede construir con este flujo:
1) **Seleccionar activos críticos (pocos, bien elegidos)**
2) **Definir variables, puntos de medición y objetivo por modo de falla**
3) **Capturar datos con calidad (sensor + configuración + baseline)**
4) **Interpretar con reglas simples (tendencias, umbrales, severidad)**
5) **Convertir eventos en órdenes de trabajo**
6) **Ejecutar y documentar en campo (móvil) con campos mínimos**
7) **Cerrar el ciclo: indicadores y revisión de efectividad**
El paso 5 y 6 son donde muchas iniciativas se caen: hay detección, pero no hay ejecución disciplinada ni evidencia. Con **CMMSedge**, la detección en tiempo real se asocia a acciones de mantenimiento mediante órdenes de trabajo, asignación de técnicos y registro en la aplicación móvil, consolidando historial y métricas.
5. Cómo empezar: metodología en 6 etapas para lograr datos confiables (sin querer hacerlo todo).
Etapa 1: prioriza por criticidad y costo de falla
No intentes monitorear todo. Elige 10–20 activos donde una falla cause:
– parada relevante,
– riesgo de inocuidad/calidad (muy crítico en alimentos),
– incumplimiento de confort/operación (facilities),
– sobrecosto energético,
– impacto en seguridad.
**Entregable**: lista de activos críticos con modo de falla dominante y variable candidata.
Etapa 2: define “catálogo mínimo” (taxonomía + nomenclatura + jerarquía)
Crea reglas de identificación y evita ambigüedades:
– Código único del activo
– Ubicación (línea, área, edificio, piso)
– Tipo de activo
– Marca/modelo (cuando aplique)
– Componentes relevantes (motor, bomba, variador, rodamiento, filtro)
**Resultado**: cuando llegue una alarma, todos saben exactamente “qué” es y “dónde” está.
Etapa 3: define variables y puntos de medición orientados a modos de falla
Ejemplos típicos por tipo de operación:
**Manufactura**
– Motores/bombas: vibración, temperatura de rodamientos, corriente
– Compresores: temperatura, presión, corriente, vibración
– Reductores: vibración, temperatura, análisis de lubricación (cuando aplique)
**Alimentos**
– Refrigeración: presión, temperatura, corriente, ciclos, estado de puertas
– Bombas sanitarias: vibración/temperatura (considerando limpieza y sellos)
– Aire comprimido: presión, punto de rocío (cuando aplique), consumo/caudal
**Facilities**
– HVAC: temperatura de impulsión/retorno, diferencial de presión en filtros, vibración en ventiladores, corriente
– Chillers/bombas: vibración, temperatura, presión, consumo eléctrico
– Elevación y equipos auxiliares: variables según criticidad y disponibilidad
**Clave**: por cada variable, define qué decisión habilita. Si una variable no conduce a una acción, replantéala.
Etapa 4: establece baseline y reglas de severidad
Antes de “alarma alta/alarma baja”, define una condición base:
– ¿Cómo se ve el activo cuando está sano?
– ¿Qué rango es normal por turno/carga/estación?
– ¿Qué tendencia es preocupante?
Luego define severidades (ej. informativa, advertencia, crítica) con respuesta:
– Informativa: observar y registrar
– Advertencia: programar inspección
– Crítica: generar orden de trabajo prioritaria
Con CMMSedge, las alarmas por condición pueden convertirse en eventos accionables que se vinculan a órdenes de trabajo y responsables.
Etapa 5: cierra el ciclo con órdenes de trabajo “con evidencia”
Aquí nace el dato confiable de mantenimiento: lo que se hizo y qué se encontró.
Campos mínimos recomendados en la OT por condición:
– Síntoma observado (relacionado con la alarma)
– Medición confirmatoria (si aplica)
– Hallazgo (ej. holgura, desalineación, filtro saturado)
– Acción (ajuste, cambio, limpieza, balanceo, lubricación, intervención eléctrica)
– Repuestos y materiales
– Tiempo real invertido
– Evidencia: foto, captura de lectura, comentario técnico
– Condición final: normal / monitoreo / requiere seguimiento
En CMMSedge, el técnico puede diligenciar la orden desde la aplicación móvil, dejando todo el registro en el historial.
Etapa 6: revisa efectividad y ajusta reglas
Cada mes (o cada ciclo relevante), revisa:
– ¿Cuántas alarmas generaron OT?
– ¿Cuántas fueron “sin hallazgo”?
– ¿Cuántas evitaron paradas no planificadas?
– ¿Qué reglas deben ajustarse?
Este paso evita la fatiga por alarmas y mejora progresivamente la confiabilidad.
6. Tres ejemplos prácticos (uno por tipo de operación).
Ejemplo A (Manufactura): ventilador crítico con aumento de vibración
**Situación**: ventilador de extracción con variación de carga. Se instala monitoreo de vibración y temperatura de rodamiento.
– Semana 1–2: baseline estable.
– Semana 3: tendencia de vibración al alza en el rodamiento lado acople.
– Regla: “Advertencia” cuando se supera el umbral + tendencia sostenida.
**Acción**:
1) Se genera evento y se asocia a una OT.
2) Técnico inspecciona: encuentra desalineación y base con pernos flojos.
3) Corrige alineación, ajusta pernos, registra evidencia y condición final.
**Valor del dato confiable**:
– Queda registrado: condición medida → hallazgo → acción → estabilización posterior.
– Ese historial permite ajustar umbrales y reconocer patrones.
Ejemplo B (Alimentos): saturación de filtros HVAC en sala con control ambiental
**Situación**: área con requerimientos de control ambiental. Se monitorea diferencial de presión en filtros.
– Se define umbral por tipo de filtro y comportamiento normal por turno.
– Cuando el diferencial sube, se genera alerta.
**Acción**:
1) Se crea OT programable (no siempre urgente, pero sí priorizable).
2) Se hace cambio de filtros, registro de lote/fecha, evidencia y lectura final.
**Beneficio operativo**:
– Menos eventos de baja eficiencia y menos riesgo de desviaciones de ambiente.
– Se evita “cambiar por calendario” cuando aún hay vida útil, o “cambiar tarde” cuando ya impacta.
Ejemplo C (Facilities): bomba de agua helada con sobreconsumo y temperatura elevada
**Situación**: bomba crítica en edificio. Se monitorea corriente y temperatura.
– Se observa incremento de corriente sin cambio de demanda.
– Se cruza con temperatura y condiciones operativas.
**Acción**:
1) Evento → OT asignada.
2) Inspección: se detecta válvula parcialmente cerrada y cavitación incipiente (o problema en succión).
3) Ajuste hidráulico + verificación, registro de mediciones.
**Resultado**:
– Se reduce el consumo y se previenen daños progresivos.
– La OT queda como evidencia para justificar la acción y mejorar rutinas.
7. Indicadores técnicos para saber si ya tienes “datos confiables”.
No necesitas decenas de métricas. Con estas puedes evaluar madurez:
- **% de eventos por condición que terminan en OT cerrada con evidencia**
- **% de OTs por condición con “hallazgo claro”** (evita cierres genéricos)
- **Tiempo de respuesta a alarmas críticas** (desde evento a atención)
- **Tasa de repetición**: misma alarma en el mismo activo en corto plazo (indica mala corrección o umbral mal definido)
- **Relación entre condición y falla**: eventos que, si se ignoraran, terminarían en parada (se valida con historial)
Cuando estos indicadores mejoran, estás dejando atrás el reactivo y construyendo el camino hacia esquemas más avanzados.
8. Dónde encaja CMMSedge en este puente de datos.
En un programa basado en condición, el punto crítico es que **la alarma no se quede en pantalla**. Debe terminar en una acción trazable. CMMSedge está pensado para eso:
– **Monitoreo en tiempo real** de variables de equipos críticos.
– **Alarmas de fallas potenciales** que pueden asociarse a **órdenes de trabajo**.
– **Asignación de técnicos** y ejecución desde **aplicación móvil**, con registro completo.
– **Historial de actividades** e información disponible para análisis e indicadores de desempeño.
Esto refuerza precisamente lo que hace confiable el dato: identidad del activo, evento con contexto, acción registrada y evidencia en historial.
9. Checklist final: 12 preguntas para validar si estás listo para escalar a predictivo.
1) ¿Cada activo crítico tiene código único y ubicación clara?
2) ¿Tus puntos de medición están definidos por variable y componente?
3) ¿Puedes explicar qué modo de falla cubre cada variable monitoreada?
4) ¿Tienes baseline por activo o por tipo de activo?
5) ¿Las alarmas tienen severidad y respuesta definida?
6) ¿Cada alarma relevante genera una OT?
7) ¿Las OTs se cierran con evidencia y campos mínimos completos?
8) ¿Puedes ver el historial de condición junto al historial de intervenciones?
9) ¿Tienes un proceso para ajustar umbrales sin “adivinar”?
10) ¿Sabes cuántas alarmas fueron “ruido” este mes y por qué?
11) ¿Puedes demostrar reducción de paradas o mejor tiempo de respuesta?
12) ¿Tienes roles claros (quién configura, quién atiende, quién analiza)?
Si respondes “sí” a la mayoría, ya construiste el puente: tus datos son lo bastante confiables para escalar en complejidad (más activos, más variables, reglas más finas y, cuando aplique, modelos de predicción.
Pasar de mantenimiento reactivo a esquemas predictivos o basados en condición no empieza por comprar más tecnología, sino por **lograr datos confiables**: bien identificados, contextualizados, accionables y con trazabilidad completa entre evento e intervención. Cuando ese puente existe, el monitoreo en tiempo real deja de ser “ruido” y se vuelve una herramienta práctica para reducir paradas, mejorar tiempos de respuesta y sostener decisiones técnicas.
Aún no hay comentarios, ¡añada su voz abajo!