Mantenimiento predictivo con IoT + dvgmao: por dónde empezar
El mantenimiento predictivo con sensores IoT promete ahorros enormes pero la mayoría de proyectos quedan en piloto. Hoja de ruta práctica con dvgmao sobre BC.
El mantenimiento predictivo con IoT industrial lleva años en las presentaciones de fabricantes 4.0 con promesas de ahorros del 20-40% en costes de mantenimiento. La realidad en pyme industrial es menos brillante: la mayoría de proyectos arrancan con piloto sobre 2-3 máquinas, generan dashboards atractivos durante 6-9 meses, y mueren silenciosamente cuando el responsable de mantenimiento deja de mirar la plataforma porque las alertas no se traducen en acciones operativas.
Este post propone una hoja de ruta práctica para implantar mantenimiento predictivo de verdad en una pyme industrial, evitando los errores típicos del piloto sin continuidad, y explica cómo se integra la plataforma IoT con dvgmao sobre Business Central para que las alertas se conviertan en órdenes de trabajo ejecutadas.
La escalera del mantenimiento: dónde sitúo el predictivo
Antes de invertir en sensores conviene tener claro dónde encaja el predictivo en la escalera global de mantenimiento. El mantenimiento correctivo, preventivo y predictivo cubre cuándo aplica cada estrategia. Resumen para este post:
- Correctivo: reacciona al fallo. Único método si el coste del fallo es bajo y la reparación rápida.
- Preventivo programado: intervenciones cada X horas o Y meses. Estrategia base para la mayoría de equipos.
- Condition-based: inspección periódica de variables clave; se actúa si están fuera de rango. Buena evolución del preventivo en equipos medianos.
- Predictivo con IoT: lectura continua y modelo de tendencia que predice el fallo. Solo aplica en equipos críticos donde el coste de instrumentación se amortiza.
La pregunta correcta no es “¿implantamos predictivo?”, es “¿qué 3-6 máquinas merecen pasar del condition-based al predictivo continuo?”.
Cómo seleccionar las máquinas piloto sin equivocarse
Tres filtros sucesivos para seleccionar candidatos:
Filtro 1: criticidad
¿Qué pasa si esta máquina para 4 horas sin previo aviso?
- Se bloquea producción de la planta entera → criticidad alta.
- Se bloquea una línea aislada → criticidad media.
- Se bloquea operativa local pero el resto continúa → criticidad baja.
Solo las de criticidad alta o media son candidatas. Las de criticidad baja se quedan en preventivo programado.
Filtro 2: modo de fallo observable
¿El modo de fallo dominante de esta máquina se manifiesta en una variable medible con sensores accesibles?
- Sí, con sensores estándar (vibración, temperatura, consumo eléctrico, presión, análisis de aceite): candidato técnico.
- Sí, pero pide sensores muy específicos o invasivos (gases, ultrasonido especializado): candidato condicional.
- No, los fallos son aleatorios o por causas externas no medibles: descartar para predictivo.
Filtro 3: histórico suficiente
¿Hay registro de al menos 6-12 incidencias de fallo del equipo en los últimos 24 meses?
- Sí: hay base para validar umbrales y entrenar modelos.
- No, falla muy raramente: predictivo no aporta valor frente a preventivo bien diseñado.
Si una máquina pasa los tres filtros, es candidata real. Con el catálogo de equipos típico de una pyme industrial, suelen pasar entre el 5% y el 15% del parque.
Sensórica: qué medir en qué máquinas
Los modos de fallo más frecuentes y sus sensores típicos:
Rodamientos (presentes en motores, ejes, transmisiones)
Modo de fallo principal: desgaste progresivo que se manifiesta en aumento de vibración y temperatura del soporte.
Sensórica: acelerómetro tri-axial industrial (mide vibración en 3 ejes) + termopar/RTD en soporte del rodamiento.
Coste por punto: 200-350 €. ROI excelente porque el rodamiento es responsable de un porcentaje muy alto de fallos no programados en muchos sectores.
Motores eléctricos
Modo de fallo principal: degradación del aislamiento, desequilibrio de bobinados, problemas de rodamientos del motor.
Sensórica: pinza amperimétrica con análisis de armónicos + temperatura de carcasa.
Coste por punto: 200-400 €.
Bombas centrífugas
Modos de fallo: cavitación, desgaste del rodete, problemas de junta mecánica.
Sensórica: vibración + presión aspiración/impulsión + temperatura.
Reductoras y transmisiones
Modos de fallo: desgaste de dientes, fallo de rodamientos internos, problema de lubricación.
Sensórica: vibración (espectro avanzado) + análisis de aceite periódico (no continuo, pero estructurado).
Compresores
Modos: fallo de válvulas, problema de etapas, sobrecalentamiento.
Sensórica: vibración + presión + temperatura + consumo eléctrico.
La integración con dvgmao: dónde se decide el éxito
El proveedor IoT entrega típicamente una plataforma que muestra los datos y genera alertas. El paso crítico es convertir esas alertas en acciones operativas desde dvgmao. Sin esta integración el proyecto muere.
Recepción de eventos
dvgmao expone API para recibir eventos desde la plataforma IoT. Cada alerta de degradación llega con:
- ID del equipo afectado.
- Tipo de degradación (vibración, temperatura, consumo).
- Severidad (info, warning, alerta, crítico).
- Ventana temporal estimada hasta fallo.
Conversión automática a aviso
El evento se convierte automáticamente en aviso de mantenimiento en dvgmao con:
- Prioridad calculada según severidad + criticidad del equipo (matriz prefijada).
- Asignación automática al responsable del equipo.
- Plantilla de inspección sugerida según tipo de degradación.
El responsable de mantenimiento recibe el aviso con todo el contexto, no un dashboard con gráficos crípticos.
Generación de orden de trabajo
Si el responsable decide actuar, dvgmao lanza la OT con:
- Materiales y herramientas habituales para ese tipo de intervención.
- Tiempo estimado y operario disponible.
- Trazabilidad respecto al aviso IoT que la originó.
Retroalimentación al modelo
Tras ejecutar la OT, se registra el modo de fallo real encontrado. Si la plataforma IoT predijo “rodamiento” y se encontró “desequilibrio de eje”, el feedback ayuda al modelo a refinar. Sin retroalimentación, el modelo nunca mejora.
Métrica del piloto: qué medir para justificar la continuidad
El piloto típico dura 6-9 meses y debe medir cuatro indicadores:
- MTBF (tiempo medio entre fallos) de los equipos instrumentados vs antes del piloto. Mejora esperada: +25-60%.
- Coste de mantenimiento no programado sobre los equipos instrumentados. Reducción esperada: 20-40%.
- Tiempo de parada no programada de los equipos instrumentados. Reducción esperada: 30-60%.
- Tasa de falsos positivos del modelo: alertas que no derivaron en intervención necesaria. Objetivo: <30% para que el responsable mantenga confianza en la plataforma.
Sin estos KPIs claros desde el día 1, al final del piloto no se sabe si fue exitoso y la decisión de extender o cancelar queda al gusto del comité.
Coste y dimensionamiento de un piloto típico
Para un proyecto de 4 máquinas piloto en pyme industrial:
- Hardware (sensores + gateways + instalación): 12.000-24.000 €.
- Plataforma cloud (12 meses): 4.800-9.600 €.
- Servicios profesionales de integración con dvgmao: 100-160 horas.
- Formación responsable de mantenimiento: 16-24 horas.
Coste total piloto 12 meses: 30.000-55.000 €.
Ahorro objetivo en 12 meses si los KPIs cumplen: 80.000-180.000 € en una pyme que pierde 250.000-600.000 €/año por paradas no programadas. Si el piloto se valida, la extensión a 8-15 máquinas más es directa.
Errores típicos que matan el proyecto
He visto fallar proyectos de predictivo IoT en pymes por las mismas razones:
- Empezar por la máquina equivocada: no es crítica o no tiene histórico — el ahorro no se nota y el proyecto pierde patrocinio.
- No integrar con GMAO: las alertas mueren en un dashboard que el responsable deja de mirar a los 4 meses.
- Falsos positivos no gestionados: el modelo dispara alertas que después no hay nada que hacer. El responsable pierde confianza y empieza a ignorar también las verdaderas.
- No definir métricas del piloto: al cabo de 9 meses, debate subjetivo sobre si “ha valido la pena”. Sin números, la dirección no extiende.
- Olvidar la retroalimentación al modelo: el modelo no mejora porque nadie le dice qué encontró el técnico cuando intervino.
Vinculación con KPIs de mantenimiento globales
El proyecto predictivo solo tiene sentido si mejora los KPIs globales del departamento. Los KPIs de mantenimiento MTBF, MTTR, disponibilidad y OEE son la referencia: si tras 12 meses el MTBF de los equipos instrumentados no ha subido al menos un 25-30%, hay algo mal y conviene re-evaluar antes de extender.
Lo que cambia operativamente a los 12 meses
Pymes industriales que cierran bien un piloto de predictivo y lo extienden ven tres efectos a los 12-18 meses:
- El responsable de mantenimiento gestiona por excepción: el preventivo programado se reduce en los equipos instrumentados (intervención según estado, no según calendario rígido) y libera capacidad.
- El director de producción confía más en la disponibilidad: el % de plan productivo bloqueado por avería baja, lo que mejora el plan comercial.
- La conversación entre mantenimiento y producción cambia de tono: deja de ser “no pares la máquina ahora” y pasa a ser “tienes 14 días antes de que esto rompa, planifica una ventana”.
Resumen práctico
- Mantenimiento predictivo con IoT solo aplica en equipos críticos con modo de fallo observable e histórico suficiente — entre el 5% y el 15% del parque típico.
- La sensórica estándar (vibración, temperatura, consumo, presión) cubre el 80% de los modos de fallo de equipos industriales medianos.
- La integración con dvgmao es donde se decide el éxito: alertas que generan OT con trazabilidad y feedback al modelo.
- Métricas del piloto desde día 1: MTBF, coste mantenimiento no programado, parada no programada, tasa de falsos positivos.
- Hoja de ruta típica: 4 máquinas piloto en 6-9 meses, validación con KPIs, extensión a 8-15 máquinas a 18 meses.
Si tu planta tiene 4-6 equipos críticos con paradas recurrentes y quieres calibrar un proyecto piloto de predictivo IoT integrado con dvgmao, habla con nuestro equipo para diagnóstico inicial sobre el histórico que ya tienes.
