Conclusiones clave
La mayoría de los talleres cuentan con abundantes datos. Los PLC publican valores de etiquetas en ciclos sub-segundo. SCADA los agrega y los visualiza. Los ERP reciben conteos de producción y consumos.
Donde las cosas se rompen es entre esas capas: una parada en la línea genera una transición de etiqueta en el PLC, se convierte en un "evento de tiempo de inactividad" en SCADA, se resume como "producción perdida" en el ERP, y ninguna de esas tres representaciones coincide sobre qué fue el evento, cuándo empezó o a qué activo pertenece.
El resultado es que nadie puede responder con claridad a preguntas operativas simples. "¿Cuánto tiempo de inactividad provocó el activo L3-PKG-02 ayer?" tiene tres respuestas diferentes según el sistema que consultes. La herramienta de OEE, el CMMS y el ERP tienen cada uno su propia definición, y unirlas manualmente es lo que se come las mañanas del responsable de mantenimiento.
La tentación común, especialmente en proyectos vendidos como "integración Industria 4.0", es volcar los datos del PLC en el ERP. Parece una integración sencilla. Casi siempre falla por tres razones.
Los PLC emiten miles de transiciones de etiqueta por minuto. Los ERP están diseñados para recibir unos pocos cientos de registros por día por planta. Bombeando datos crudos del PLC a un ERP o se satura la base de datos o se fuerza una agregación agresiva en el borde, y esa agregación es lo que destruye la resolución que necesitan el OEE y el CMMS.
El PLC conoce etiquetas. El ERP conoce centros de coste. Ninguno conoce la jerarquía de activos tal como la maneja mantenimiento (línea → estación → activo → componente). Sin una jerarquía explícita en el medio, no se puede responder "qué activo causó esta parada" a partir de los registros del ERP.
Los eventos del PLC tienen precisión de milisegundos. Los eventos del ERP suelen tener precisión diaria. Una parada que empezó a las 14:03:22 y terminó a las 14:08:45 se convierte en "5 minutos de inactividad el 27 de junio" para cuando el ERP lo ve. Esa pérdida de precisión es la razón por la que la mayoría de los informes de OEE basados en ERP son inútiles.
La solución es insertar una capa entre el nivel PLC/SCADA y el ERP. La capa tiene cuatro funciones.
Cada evento, inicio, parada, rechazo, cambio de formato, recibe el mismo nombre en la misma forma en todos los sitios. Aquí es donde se aplica en la práctica la taxonomía de clases de pérdida del artículo sobre KPIs de manufactura. Sin ella, los análisis posteriores nunca se estabilizan.
La capa operativa es la única fuente de verdad sobre "qué es un activo". Líneas, estaciones, activos y componentes se definen aquí, mapeados a etiquetas PLC por un lado y a centros de coste del ERP por el otro. Cuando mantenimiento crea una orden de trabajo, apunta a un activo en esta jerarquía, no a una etiqueta ni a un centro de coste.
Cada evento que almacena la capa se marca temporalmente con un único reloj, normalmente UTC a nivel de milisegundo, independientemente de qué PLC, sistema SCADA o interfaz de operador lo haya producido. Los problemas de zona horaria y de deriva se eliminan en la ingestión, no en los paneles.
El ERP recibe la imagen consolidada y con forma financiera: producción por turno, merma, tiempo de inactividad por motivo, con cadencia diaria o por turno. El detalle de alta resolución queda en la capa operativa, donde lo necesitan OEE, CMMS y el análisis de causa raíz. Véase el artículo relacionado sobre análisis de causa raíz para entender por qué ese detalle es lo que impulsa la mejora.
Una arquitectura de referencia típica para el mercado medio:
La razón por la que la capa operativa necesita alojar tanto OEE como CMMS es que la jerarquía de activos se comparte.
Si el OEE vive en una herramienta con su propia jerarquía y el CMMS vive en otra con una jerarquía diferente, se pierde todo el propósito de la capa, la única fuente de verdad.
Un sistema de gestión de órdenes de trabajo unificado sobre los mismos datos que el motor de OEE evita por defecto esa deriva.
El error que cometen las plantas es empezar por la integración con el ERP porque parece la entrega "real". La secuencia correcta es la opuesta.
Empezar primero por la integración con el ERP garantiza retrabajo, porque las definiciones operativas aún están en flujo y cada registro del ERP habrá de volver a emitirse a medida que esas definiciones se estabilicen.
La capa de datos operativos descrita arriba es exactamente lo que es Fabrico : una plataforma única que aloja la jerarquía de activos, el flujo de eventos de OEE y las órdenes de trabajo del CMMS sobre la misma base de datos, con conectores perimetrales para el lado PLC y exportaciones programadas para el ERP.
La razón por la que lo ofrecemos como un producto unificado en lugar de dos separados es que la brecha OT/IT se colapsa cuando OEE y CMMS comparten una jerarquía, y se mantiene abierta cuando no lo hacen. Para ver cómo quedaría con los datos de su propia línea, reserve una demostración .
No. La capa de datos operativos se sitúa encima de la pila OT existente mediante un conector perimetral. El nivel PLC/SCADA sigue haciendo lo que hace; la nueva capa solo añade una vista normalizada encima.
Un data lake sin una capa de datos operativos contiene datos de etiquetas de alta resolución sin semántica de eventos. Puedes construir paneles sobre él, pero no puedes generar órdenes de trabajo, cálculos de OEE o análisis de causa raíz sin antes reconstruir el vocabulario de eventos y la jerarquía de activos, que es precisamente lo que hace la capa operativa. Saltársela solo aplaza el problema.
Si una planta ya tiene un MES, el MES a menudo cumple parte del trabajo de la capa operativa, particularmente el vocabulario de eventos. La arquitectura funciona igual: el MES alimenta la capa operativa (o es la capa operativa, si cubre OEE y CMMS), que luego consolida hacia el ERP.
Por el equipo de la planta que conoce los activos, no por TI. La capa operativa debe permitir que la jerarquía sea editable por los ingenieros de mantenimiento y producción sin necesidad de un desarrollador en el circuito, o se quedará desactualizada en un trimestre.
El vocabulario de eventos. Si las clases de pérdida no son estables entre líneas, todo análisis y cada regla posteriores son poco fiables. Dedique más tiempo del que parezca razonable a la taxonomía en la semana uno.
Iniciar sesión
Blog
