Cuando el informe no cuadra entre MES y ERP

Cuando un informe de producción no cuadra entre MES y ERP, la primera pregunta no es cuál de los dos sistemas tiene razón. La primera pregunta es si ambos valores describen el mismo objeto, durante el mismo periodo y con la misma regla. Una cantidad terminada en el MES puede representar ejecución confirmada en planta. El ERP puede mostrar una cantidad contabilizada después de aplicar cierres, conversiones, ajustes o estados empresariales. Compararlas sin ese contexto produce una diferencia que parece técnica, aunque a veces solo sea semántica.

El diagnóstico debe empezar con un caso pequeño: una orden, un lote, un material y una ventana cerrada. Hay que guardar los valores tal como aparecen, antes de corregirlos, junto con timestamps, unidades, estados y versiones de los datos maestros. Después se reconstruye el camino de cada cifra. Si el equipo empieza por exportar meses completos a una hoja, suele añadir más filas antes de entender la primera discrepancia.

ISA-95 explica el nivel 3 como el ámbito de gestión de operaciones de fabricación y el nivel 4 como planificación y logística empresarial. ISA-95 aporta el marco. Es un límite funcional, no una obligación de instalar productos concretos ni una pirámide física rígida. IEC 62264-1 describe actividades e interfaces entre esos niveles y busca aumentar la uniformidad terminológica y reducir riesgo, coste y errores de integración. La ficha oficial de IEC 62264-1 indica que la edición está bajo revisión, por lo que debe citarse con esa limitación.

Congela un caso antes de comparar totales

La conciliación necesita una unidad de análisis estable. “La producción de ayer” puede parecer suficientemente concreta, pero todavía deja abiertas varias decisiones: qué zona horaria define ayer, cuándo cerró el turno, qué órdenes cruzaron medianoche, si se cuentan unidades buenas o terminadas, qué ocurre con retrabajo y qué actualización llegó después del corte.

Un caso mínimo debería identificar:

• Planta, área, línea o recurso.
• Orden de fabricación y, cuando aplique, lote.
• Material y versión del maestro relevante.
• Inicio y fin con zona horaria.
• Estado de la orden en ambos sistemas.
• Cantidad, unidad y precisión.
• Valor original, fecha de consulta y usuario o proceso que lo obtuvo.

Este recorte evita que las diferencias se compensen. Si una orden tiene diez unidades de más y otra diez de menos, el total diario puede cuadrar mientras el inventario, la trazabilidad o el coste permanecen mal asignados. Conciliar solo el total es útil como alarma, pero no demuestra que los registros coincidan.

También conviene seleccionar un periodo cerrado. Mientras una orden está en curso, el MES puede recibir eventos y el ERP esperar una declaración, un consumo o un cierre. Una diferencia durante esa ventana puede ser el comportamiento previsto. El diagnóstico debe distinguir “todavía no sincronizado” de “no coincide después del punto de control acordado”.

El resultado de esta fase no es una causa, sino una ficha de caso. Debe poder entregarse a operaciones o IT/OT sin depender de capturas sueltas: identificadores, valores, timestamps, estados, unidades y regla de corte. Si uno de esos elementos falta, la siguiente tarea es recuperar evidencia, no elegir un ganador.

Alinea el significado de objetos y estados

IEC 62264-2:2026 define modelos conceptuales de objetos y atributos para la información intercambiada entre operaciones de nivel 3 y sistemas empresariales de nivel 4. La ficha oficial de IEC 62264-2:2026 delimita ese alcance. La norma no garantiza que dos implementaciones compartan automáticamente la misma semántica. Sí ayuda a formular la revisión correcta: no basta con comparar dos números; hay que comprobar qué objeto y atributos representa cada uno.

Una orden puede tener estados como creada, liberada, iniciada, parcialmente declarada, terminada, técnicamente cerrada o contabilizada. Los nombres y transiciones varían. Un sistema puede tratar “terminada” como fin de ejecución y otro esperar consumos, calidad o cierre financiero. Si el informe agrupa estados distintos bajo la etiqueta “completada”, la diferencia puede reaparecer en cada cierre.

La misma revisión se aplica a cantidades:

No existe una respuesta universal para cada fila. El equipo debe documentar la regla local y el sistema autorizado para cada objeto y estado. Decir “el MES manda en producción” o “el ERP es la fuente de verdad” puede ser demasiado amplio. La autoridad debería expresarse con precisión: qué sistema origina el evento, cuál conserva el estado empresarial, qué transformaciones están permitidas y quién aprueba una corrección.

Revisa tiempo, unidades y datos maestros

Los errores de tiempo son difíciles de detectar porque las cifras pueden ser válidas en ventanas diferentes. Un evento a las 23:58 en hora local puede almacenarse en UTC, agregarse al turno siguiente o llegar después del cierre. Los cambios de horario, los turnos que cruzan medianoche y los reintentos de interfaz requieren una regla explícita.

NIST identifica tiempo y ubicación como metadatos esenciales para contextualizar series industriales y señala la necesidad de conservar el linaje cuando el dato se agrega o transforma. El documento NIST AMS 100-65 desarrolla este principio de modelado, no una receta de reconciliación. En este caso obliga a registrar timestamp de evento, timestamp de recepción, zona horaria, momento de corte y cualquier reasignación de periodo.

Las unidades presentan un problema parecido. Kilogramos y unidades pueden estar conectados mediante un factor teórico que cambia por versión, formato o producto. Una cantidad puede redondearse al declarar y conservar decimales en el sistema de proceso. Un factor de conversión equivocado no siempre produce un error evidente; puede crear pequeñas diferencias acumuladas.

Los maestros que conviene comparar incluyen material, unidad base, conversiones, lista de materiales, ruta, recurso, centro de trabajo, clasificación de scrap y relaciones orden-lote. Copiarlos todos añade ruido. Basta con identificar cuáles participaron en el cálculo del caso congelado y qué versión estaba vigente.

Una tabla de evidencia puede mantener el control:

Reconstruye las transformaciones y la interfaz

Entre el evento de planta y el valor del informe pueden existir filtrado, agregación, conversión de protocolo, redondeo, reglas de negocio, reintentos y correcciones manuales. Algunas transformaciones son necesarias. El problema es no poder explicar cuál se aplicó y con qué versión.

NIST estudió la contextualización de datos de fabricación y una implementación de referencia que combinó manualmente información de diseño, planificación, fabricación e inspección apoyándose en estándares existentes. El estudio de NIST sobre contextualización describe un test bed, no una prueba de que la misma arquitectura funcione en cualquier planta. Demuestra que conectar silos exige contexto y una implementación deliberada.

Otro experimento de NIST y Manufacturing Technology Centre no consiguió enlazar automáticamente toda la información aun utilizando estándares abiertos; la alineación requirió intervención humana. El informe conjunto de NIST y MTC cubre diseño, fabricación e inspección, no un cierre MES-ERP completo. Su limitación es precisamente la enseñanza: usar un estándar no elimina por sí solo el trabajo de alinear identificadores, autoridad y significado.

Para una interfaz concreta hay que revisar:

1. Evento o dato que inicia el intercambio.
2. Payload original e identificador de correlación.
3. Validaciones y transformaciones aplicadas.
4. Respuesta, error o reintento.
5. Orden y duplicación de mensajes.
6. Proceso manual alternativo durante una caída.
7. Correcciones posteriores y su trazabilidad.

MESA recomienda, como práctica industrial, mapear puntos críticos, origen y flujo del dato, documentar capacidades y limitaciones y definir gobernanza antes de escalar una integración. Developing a Phased Integration Approach es orientación de una asociación, no una obligación normativa. Sirve para preparar una revisión donde operaciones e IT/OT hablen sobre el mismo flujo.

Clasifica la diferencia antes de corregirla

No todas las discrepancias representan el mismo riesgo. Una clasificación sencilla evita aplicar la misma solución a cualquier delta:

• Temporal: los valores convergen después del punto de sincronización previsto.
• Semántica: nombres iguales representan objetos, estados o fórmulas diferentes.
• Conversión: unidad, redondeo o factor maestro generan el delta.
• Cobertura: un sistema incluye eventos, áreas o tipos que el otro excluye.
• Interfaz: un mensaje falta, se duplica, llega fuera de orden o falla.
• Corrección: un ajuste manual o automático no se propagó o perdió trazabilidad.
• Registro de origen: el evento inicial contiene un dato incorrecto o incompleto.

La clasificación debe conservar evidencia a favor y en contra. Si una diferencia desaparece después de una hora, puede ser temporal, pero también puede existir un proceso nocturno que reescriba datos incorrectos. Si todas las diferencias corresponden a una unidad concreta, la conversión es una hipótesis fuerte, no una conclusión hasta revisar el maestro y un caso.

Una corrección segura define el sistema autorizado, el valor esperado, el responsable, el control y el criterio de cierre. Debe conservar el valor original o una traza equivalente. Sobrescribir ambos sistemas para que “cuadren” destruye la evidencia que permitiría prevenir la repetición.

Cuando la diferencia afecta inventario, coste, calidad, trazabilidad o compromisos de entrega, deben participar los responsables correspondientes. Esta página ofrece un método general de análisis. No sustituye procedimientos contables, de calidad, ciberseguridad o cambio controlado.

Cierra con una regla y una prueba repetible

El caso está cerrado cuando el equipo puede explicar por qué apareció la diferencia, qué regla es correcta y cómo detectará una repetición. “Se ajustaron los datos” no es un cierre suficiente. El registro debería incluir el objeto, la regla acordada, sistemas afectados, corrección, aprobación y prueba posterior.

Una salida útil tiene esta forma: “Para la orden X y la operación Y, el MES registró unidades buenas al finalizar la operación; el ERP recibió la declaración después del corte del informe. La interfaz funcionó según la regla actual, pero el reporte comparaba timestamps de evento con fechas contables. Se ha definido una ventana común y una prueba verifica ambos valores después del cierre”. El ejemplo es hipotético; muestra la precisión que necesita la explicación sin convertir una posibilidad en causa universal.

Después conviene repetir la consulta con otro caso del mismo tipo. Si la regla solo explica una orden, quizá falta una condición. Si explica el patrón y los nuevos registros incluyen el contexto necesario, el equipo puede automatizar una alerta sin automatizar la conclusión.

El diagnóstico puede revelar que los datos ya cuadran y que el problema real es interpretar una caída de rendimiento. En ese caso, continúe con cómo explicar la caída de un KPI por turno. Si la conciliación está resuelta y debe presentarse una decisión, use la estructura de informe para dirección. El marco completo está en reporting operativo industrial y KPIs.

Prueba la regla con escenarios que suelen romperla

Una conciliación que funciona con una orden sencilla puede fallar en los bordes del proceso. Antes de dar por estable la regla, conviene probar situaciones donde cambian estados, periodos o relaciones entre objetos. El objetivo no es cubrir cualquier combinación teórica, sino comprobar los escenarios que la planta realmente ejecuta.

Incluya, cuando existan:

• Una orden que atraviesa dos turnos o el cambio de día.
• Producción parcial con declaración posterior.
• Scrap registrado antes y después del cierre.
• Retrabajo vinculado a la orden original o a una nueva.
• Conversión entre unidades con decimales.
• Material o ruta actualizados durante la campaña.
• Caída de interfaz y recuperación mediante proceso manual.
• Mensaje duplicado o reintentado.
• Reapertura de una orden cerrada.
• Resultado de calidad recibido después de terminar producción.

Para cada escenario, escriba el resultado esperado antes de ejecutar la prueba. Defina qué valor debe mostrar cada sistema, en qué momento y con qué estado. Después compare el resultado observado. Si el criterio se escribe al final, existe el riesgo de adaptar la expectativa a lo que ocurrió.

Los datos de prueba deben proteger información sensible y no contaminar producción. La forma concreta depende de la arquitectura y los controles de la empresa. Esta guía no recomienda ejecutar pruebas en sistemas reales sin autorización. Puede empezar con casos históricos cerrados y registros de interfaz ya disponibles.

Una matriz de prueba debería conservar ID de caso, condición, datos de entrada, regla, resultado esperado, resultado observado y evidencia. Si la regla falla, no basta con anotar “incidencia técnica”. Hay que identificar si el fallo procede del modelo semántico, de una transformación, de la interfaz o del procedimiento manual.

Esta fase revela reglas implícitas. Por ejemplo, un proceso puede funcionar mientras todas las órdenes terminan dentro del día, pero asignar mal las que cruzan el corte. Otro puede tratar correctamente unidades enteras y acumular diferencias al convertir peso. Convertir esos bordes en pruebas repetibles reduce la dependencia de memoria individual.

Mantén un control operativo después de la corrección

El cierre de una discrepancia no garantiza que la interfaz o la definición sigan estables. Cambios de maestros, versiones, configuraciones y procesos manuales pueden introducir un nuevo delta. El control posterior debe ser proporcional al riesgo y evitar convertir la conciliación en otra tarea manual interminable.

Un control básico puede comparar por periodo:

• Número de órdenes y operaciones intercambiadas.
• Mensajes fallidos, duplicados o pendientes.
• Cantidades por estado y unidad.
• Diferencias de cierre por encima de una tolerancia definida.
• Correcciones manuales y motivo.
• Tiempo entre evento, recepción y contabilización.
• Cambios de maestro que afecten a la regla.

La tolerancia no debe inventarse para que el informe quede verde. Tiene que responder al objeto, la precisión, el uso y el riesgo. Una diferencia aceptable para una señal aproximada puede ser inaceptable para trazabilidad, inventario o coste. El propietario funcional debe acordarla con las áreas afectadas.

El control también necesita una ruta de escalado. Una alerta debe indicar caso, valor, regla incumplida, evidencia disponible y responsable. “MES y ERP no cuadran” devuelve al equipo al principio. “La orden X conserva estado terminado en MES y abierto en ERP dos horas después del punto de control; el mensaje Y falló” permite empezar la revisión en un lugar concreto.

Revise periódicamente si el control sigue detectando el riesgo real. Una alerta que dispara a diario y se cierra como comportamiento previsto deja de proteger. Puede requerir una regla más precisa o una corrección de proceso. El objetivo es que las diferencias relevantes lleguen con contexto, no acumular un contador de excepciones sin dueño.

Documente también quién puede modificar cada regla y cómo se prueba el cambio antes de usarlo en un cierre real. Esa responsabilidad convierte la conciliación en un control mantenible.

El siguiente paso es seleccionar una discrepancia real y anonimizada. Complete la ficha de caso sin modificar registros, obtenga los valores originales y alinee primero orden, periodo, estado y unidad. Si el equipo no puede cerrar esos cuatro elementos, todavía no está preparado para discutir cuál de los sistemas tiene razón.

Preguntas frecuentes

¿Debe prevalecer siempre el MES o el ERP?

No. La autoridad debe acordarse por objeto y estado. El MES puede originar eventos de ejecución mientras el ERP mantiene planificación o contabilización, pero la configuración concreta depende de la arquitectura y las reglas de cada empresa.

¿Qué se debe comparar primero cuando las cifras no coinciden?

Empiece por una orden o lote concreto y compruebe que ambos valores usan el mismo periodo, zona horaria, estado, unidad, alcance y momento de corte. Después revise transformaciones e interfaces.

¿Una diferencia MES-ERP suele deberse a latencia?

La latencia es una posibilidad, no una conclusión. También pueden intervenir definiciones diferentes, estados de orden, conversiones, scrap, retrabajo, maestros, cierres contables o correcciones manuales.

¿Qué evidencia conviene guardar para IT/OT?

Identificadores de orden y lote, timestamps, valores en ambos sistemas, versión de maestros, unidad, estado, logs de interfaz, transformaciones conocidas, usuario o proceso que corrigió el dato y resultado de la conciliación.

¿Se deben corregir los registros para que ambos sistemas coincidan?

Solo después de determinar la regla correcta, el sistema autorizado y el control aplicable. Una corrección debe conservar el valor previo, el motivo, el responsable y la fecha; igualar cifras sin trazabilidad oculta el problema.