Cómo conectar un MES con un ERP

Antes de mover una sola orden hay que acordar los datos maestros: artículos, listas de materiales, rutas u hojas de operaciones, centros de trabajo, unidades de medida y, a veces, personal y turnos. La regla más sana es que cada dato tenga un único sistema maestro y que el otro lo reciba, sin editarlo localmente.

Un error frecuente es dejar que el MES cree artículos «provisionales» para no parar la línea. Funciona el primer día y genera conciliaciones manuales durante meses. Es preferible un procedimiento rápido de alta en el maestro que permitir altas paralelas.

El flujo descendente típico es el envío de la orden de fabricación liberada en el ERP hacia el MES. La orden debería viajar con lo necesario para ejecutarla sin consultas adicionales: artículo, cantidad, fechas, versión de lista de materiales y de ruta, lote previsto si lo hay y prioridad.

• Estados: define qué estados del ERP se envían (liberada, modificada, cerrada técnicamente) y cómo se reflejan en el MES.
• Modificaciones: decide si se permite cambiar cantidad o fecha de una orden ya iniciada en planta, y cómo se notifica.
• Cancelaciones: una orden cancelada en el ERP con consumos ya registrados en el MES necesita una regla explícita.
• Secuenciación: normalmente es responsabilidad del MES o de un planificador detallado, no del ERP.

El flujo ascendente informa al ERP de lo que realmente ha pasado: cantidades buenas y rechazadas, consumos de material por lote, tiempos de operación, entradas de producto terminado y cierre de la orden. Aquí hay que decidir el grano: confirmar cada pieza, cada palé, cada operación o solo al final de la orden.

Una pauta razonable es mantener el detalle fino en el MES y enviar al ERP agregados con significado contable o logístico. Las correcciones (una confirmación errónea, una merma descubierta tarde) deben viajar como movimientos de anulación o ajuste, nunca como borrado.

En una red industrial los mensajes se pierden, se reintentan y a veces llegan dos veces. Si el ERP registra dos veces la misma confirmación, el inventario queda mal y alguien tendrá que encontrarlo. La idempotencia es la propiedad de que procesar un mismo mensaje varias veces produzca el mismo resultado que procesarlo una sola vez.

• Asigna a cada confirmación un identificador único generado en origen, no en el destino.
• El receptor guarda los identificadores procesados y descarta, con registro, los repetidos.
• Envía cantidades como movimientos identificados, no como totales acumulados que se sobrescriben sin control.
• Respeta el orden cuando importa: un cierre de orden no debería procesarse antes que su última confirmación.
• Documenta qué hace el receptor ante un identificador repetido con contenido distinto: normalmente, rechazar y avisar.

La planta no puede detenerse porque el ERP esté en mantenimiento. Por eso el MES debería poder seguir trabajando y acumular las confirmaciones pendientes, que se envían cuando el destino vuelve a estar disponible. Lo que no puede ocurrir es que un error quede escondido en un registro técnico que nadie lee.

• Cola persistente de mensajes salientes en el MES, con reintentos y límite.
• Bandeja de errores funcionales legible por una persona de producción o de sistemas: «artículo bloqueado», «lote inexistente», «orden cerrada».
• Opción de corregir el dato y reprocesar, conservando la trazabilidad de lo que se hizo.
• Avisos cuando un flujo lleva demasiado tiempo sin mensajes o la cola crece por encima de lo normal.
• Conciliación periódica: comparar órdenes abiertas y existencias en ambos sistemas para detectar desviaciones.

1. ¿Está documentado qué sistema es maestro de cada dato y quién lo mantiene?
2. ¿Se ha acordado el grano de confirmación con producción, logística y control de gestión?
3. ¿Cada mensaje tiene identificador único y el receptor sabe tratar duplicados?
4. ¿El MES puede trabajar si el ERP no responde, y hay una cola visible de pendientes?
5. ¿Existe una bandeja de errores con responsable y procedimiento de reproceso?
6. ¿Se ha previsto una conciliación periódica entre ambos sistemas?
7. ¿Se han probado los casos difíciles: cancelación con consumos, cambio de lista de materiales, merma tardía?

Si varias respuestas son negativas, el primer entregable no debería ser código, sino un documento de interfaz acordado entre los equipos de planta y de sistemas. Con él, la construcción es mucho más previsible.