Cómo comparar el plan ERP con la ejecución en MES
Compare el plan ERP con la secuencia ejecutada en MES sin confundir una replanificación, una confirmación tardía y un desvío de producción.
Investigue una confirmación de producción duplicada entre MES y ERP conservando el evento, el identificador y la evidencia antes de retener o corregir cifras.
Una confirmación repetida entre MES y ERP puede inflar un informe, dejar una orden en un estado inesperado o abrir una discusión que acaba reducida a “hay dos filas iguales”. Esa última frase no es una investigación. Dos registros pueden tener la misma cantidad y no representar el mismo hecho: quizá pertenecen a operaciones distintas, a un reintento visible, a un ajuste o a una agregación posterior. También puede ocurrir lo contrario: un duplicado real puede quedar oculto porque las marcas temporales o los estados no son idénticos.
El objetivo no es encontrar la primera fila que conviene quitar. Es identificar si dos registros describen el mismo evento de producción, cómo llegaron a cada sistema y qué regla local decide su tratamiento. Mientras esa pregunta no esté respondida, un ajuste puede corregir una pantalla y empeorar trazabilidad, inventario, coste o análisis de calidad.
ISA-95, también publicada como IEC 62264, es una serie de normas para integrar sistemas empresariales y sistemas de control de fabricación. La descripción oficial de ISA-95 sitúa ese límite de integración. No certifica que una interfaz concreta sea idempotente, no determina qué fila se debe anular y no prueba que un evento se haya ejecutado una o dos veces. La referencia sirve para distinguir los objetos y transacciones que hay que observar.
Esta guía no sustituye los controles de inventario, contabilidad, calidad, seguridad, contratos ni protección de datos de la organización. Si la posible duplicidad afecta un producto liberado, un movimiento de stock, un coste o una obligación frente a un cliente, siga la escalada local. Aquí se describe cómo preservar y ordenar la evidencia para que la decisión llegue con un caso delimitado.
Empiece por un solo caso y formule la comparación. Anote orden, operación, lote cuando exista, material, recurso, cantidad, unidad, estado y la vista de donde procede cada registro. Guarde la hora de evento, de envío, de recepción, de aplicación y de consulta cuando estén disponibles. Son cinco conceptos diferentes; tratarlos como una sola “fecha” hace imposible saber dónde aparece la repetición.
Asigne al caso un identificador de investigación que no reemplace los identificadores originales. Adjunte las consultas o exportaciones tal como se obtuvieron y registre filtros, zona horaria y versión de informe. Si una persona revisa el caso mañana, debe poder saber qué filas se compararon sin pedir acceso a una pantalla que quizá ya cambió.
No escriba “duplicado” como conclusión inicial. Use “posible duplicidad de confirmación” y declare la hipótesis que se va a comprobar: “Dos aplicaciones del mismo evento”, “una aplicación y una corrección”, “dos eventos parecidos” o “evidencia aún insuficiente”. Una hipótesis limitada obliga a buscar identificadores y evita que la cifra mande sobre el significado.
| Evidencia | Qué conservar | Pregunta que responde |
|---|---|---|
| Evento de origen | Orden, operación, lote, evento y timestamp | ¿Hubo uno o dos hechos físicos? |
| Confirmación MES | Identificador, usuario o sistema, estado y unidad | ¿Qué afirmó el sistema de ejecución? |
| Mensaje | Correlación, emisor, destino, resultado y reintentos | ¿Qué intercambio transportó el dato? |
| Aplicación ERP | Documento, estado, momento y referencia | ¿Cómo se aceptó o rechazó el dato? |
| Consulta final | Informe, filtros, corte y versión | ¿Por qué hoy se ven dos registros? |
La ficha debe admitir huecos. Si no hay identificador de correlación, anótelo y pida el dato a quien mantenga la integración. Inventar una correspondencia por cercanía de hora no convierte dos mensajes en el mismo mensaje. A lo sumo, produce una pista que debe quedar separada de la evidencia.
El primer trabajo es semántico. Pregunte qué representa cada fila: ¿una cantidad declarada por una operación?, ¿una cantidad buena tras una inspección?, ¿una corrección de una declaración anterior?, ¿un movimiento que agrega varios eventos?, ¿un reenvío técnico? El nombre de la columna rara vez basta. Dos campos llamados “cantidad confirmada” pueden tener reglas de generación distintas.
La norma ISA-95 incluye una parte dedicada a modelos y terminología. La ficha oficial de ISA-95 identifica ese alcance como Part 1: Models and Terminology. No impone el diccionario de una fábrica. Su utilidad aquí es recordar que orden, operación, material, estado y confirmación necesitan una definición compartida antes de cruzar sistemas.
Compare las claves de negocio y las claves técnicas. Una coincidencia de orden y cantidad no basta si cambian operación, lote o tipo de movimiento. Una coincidencia de correlación es importante, pero tampoco reemplaza el contexto: el mismo mensaje puede tener reintentos y respuestas. Organice la comparación por pares de registros, no por una suma total diaria.
Una práctica útil es escribir una frase por cada fila: “confirmación de 40 unidades para operación 20, recibida a las 10:14”; “ajuste de -40 unidades para la misma operación, aplicado a las 10:25”; “nuevo mensaje de 40 unidades con igual correlación”. Cuando las frases están completas, se ve si la repetición es real, si hay una reversión o si se mezclaron hechos distintos bajo una etiqueta común.
Una duplicidad puede aparecer en el origen, durante el envío, en la recepción, en la aplicación o en la consulta. No salte al punto que parece más cómodo. Reconstruya el recorrido en orden: creación del evento, transformación conocida, emisión, acuse o error, reintento, recepción y registro final. Para cada paso, separe lo observado de lo supuesto.
ISA-95 incluye Part 2: Objects and Attributes for Enterprise-Control System Integration. La descripción pública de la serie enumera esa parte. Esta mención no confirma qué atributos mantiene una interfaz local. Sí ayuda a plantear una revisión por identidad de objeto, atributos y estado, en lugar de deducir una causa a partir de dos importes.
Un reintento merece especial cuidado. El emisor puede no recibir respuesta y reenviar un mensaje que el receptor ya aplicó. El receptor puede reconocer la misma clave y evitar una segunda aplicación, o puede necesitar una regla complementaria. No suponga ninguno de esos comportamientos sin traza y sin conocer el contrato de la integración. “Hubo timeout” no demuestra que existan dos confirmaciones.
La serie ISA-95 incluye una parte sobre actividades de gestión de operaciones de fabricación. ISA-95 la identifica como Part 3: Activities of Manufacturing Operations Management. La descripción no decide cómo debe actuar un usuario ante una corrección ni qué estado debe cerrar una orden. Las reglas de proceso, autorizaciones y segregación de funciones siguen siendo locales.
Busque también operaciones manuales. Una persona puede haber confirmado una cantidad después de que la interfaz ya enviara el mismo evento, o puede haber creado una corrección autorizada que el informe no diferencia visualmente. La evidencia necesaria no es una sospecha sobre una persona; es la acción, el motivo, el usuario autorizado y el vínculo con el evento original.
Un duplicado de confirmación es un caso donde dos registros aplican el mismo hecho con una cobertura equivalente y no existe una regla que justifique ambas aplicaciones. Una réplica puede contener el mismo hecho para consulta, sin producir un segundo efecto de negocio. Una corrección puede tener cantidad parecida o contraria y estar destinada a modificar una declaración anterior. La clasificación no debe basarse en el signo o en la cercanía temporal solamente.
Documente qué evidencia permitiría cada clasificación. Para un duplicado, normalmente se necesita una identidad común de evento y evidencia de doble aplicación. Para una réplica, el segundo registro debe estar identificado como copia o proyección sin efecto independiente. Para una corrección, debe existir referencia a un valor previo, motivo y autorización. Si no se puede probar ninguna, use “pendiente de evidencia” y solicite el dato exacto.
ISA-95 identifica Part 5 como Business-to-Manufacturing Transactions y Part 6 como Messaging Service Model. La página oficial de ISA-95 enumera ambas partes. Esa enumeración no garantiza que un producto implemente un identificador único, tratamiento de reintentos o secuencia de respuesta determinados. La investigación debe apoyarse en el diseño y en los registros del entorno real.
Evite la compensación rápida. Añadir una fila negativa para hacer coincidir un total puede ocultar el hecho que se duplicó y generar un nuevo objeto que otros procesos interpreten de forma distinta. La corrección, si procede, debe seguir el flujo local, guardar los valores antes y después, explicar el motivo y permitir que un revisor relacione el resultado con la incidencia.
Cuando una posible duplicidad impacta un informe, puede ser razonable retener la cifra de un análisis derivado mientras se investiga. Retener no significa borrar, reescribir ni excluir sin dejar rastro. El registro de la retención debe indicar alcance, criterio, fecha, responsable, fuentes afectadas y condición de salida. Si la organización no dispone de ese mecanismo, escale el caso antes de modificar resultados publicados.
La decisión debe ser proporcional. Un posible duplicado de una orden histórica puede requerir una revisión documental. Una diferencia que afecte producto liberado o compromiso financiero puede necesitar controles adicionales. El equipo técnico puede aportar trazas, pero no debe sustituir a quien tiene autoridad sobre el impacto de negocio.
Prepare una pregunta de decisión clara: “¿Se confirma que la correlación X aplicó dos veces el mismo evento Y, y qué procedimiento autorizado define la reversión?”. Esa pregunta evita reuniones donde se discuten pantallas sin acordar qué evidencia faltaría para tomar una decisión.
Una acción correctiva segura identifica qué registro cambia, en qué sistema, por qué regla, con qué responsable y qué consecuencia se espera en los informes derivados. Conserve el valor original. Registre también qué no se cambió: por ejemplo, “se corrige el documento ERP; el evento MES queda como evidencia de origen”. Esa precisión facilita auditoría y evita que equipos diferentes apliquen dos correcciones.
Después de la acción autorizada, compruebe una nueva confirmación con el mismo patrón. Si el problema era un reintento, use un caso que reproduzca el escenario bajo control. Si era una presentación duplicada, revise una consulta que incluya el mismo filtro. La prueba posterior debe comprobar la regla, no limitarse a confirmar que un total quedó bonito.
Puede ser necesario abrir una mejora de integración: conservar una correlación, mostrar el tipo de movimiento o exponer un estado de deduplicación. Describa el cambio por el dato que faltó, no por la solución que se presupone. “El receptor debe mostrar la referencia del evento original” es verificable; “arreglar duplicados” no lo es. La modificación debe pasar por el proceso de cambio aplicable.
Para una diferencia centrada en una orden completa, consulte cómo conciliar una orden de producción entre MES y ERP. Si los estados no coinciden aunque la cantidad sea única, revise por qué una orden puede estar cerrada en ERP y abierta en MES.
Una manera de reducir errores de análisis consiste en revisar cada posible pareja en tres niveles. Primero, el nivel de negocio: orden, operación, material, lote y unidad. Segundo, el nivel de ejecución: evento físico o lógico, estado, recurso y ventana temporal. Tercero, el nivel de intercambio: mensaje, correlación, resultado y aplicación. Si dos filas coinciden solo en el primer nivel, todavía no hay base para declarar una duplicidad.
El revisor puede usar una tabla corta. Marque “coincide”, “difiere” o “desconocido” para cada atributo. El valor “desconocido” es importante: obliga a obtener la traza o la regla ausente. Una tabla que solo permite sí y no empuja a resolver por intuición, especialmente cuando el informe presenta dos registros muy parecidos.
| Nivel | Atributos de comparación | Resultado que permite avanzar |
|---|---|---|
| Negocio | Orden, operación, material, lote y unidad | Las filas cubren el mismo objeto o se separan como hechos distintos |
| Ejecución | Evento, estado, recurso y timestamp de origen | Se identifica si hubo uno o dos eventos que requieren explicación |
| Intercambio | Correlación, mensaje, respuesta y aplicación | Se puede probar reintento, reenvío, aceptación o falta de evidencia |
No convierta “coincide” en “correcto”. Dos registros pueden coincidir en todos los atributos visibles y seguir requerir una decisión sobre si su doble aplicación produce un efecto contable. Del mismo modo, un atributo diferente puede ser el resultado esperado de una corrección autorizada. El cuadro organiza preguntas; no reemplaza la autoridad del proceso.
Cuando el caso se entregue a otro equipo, incluya qué atributo no se pudo observar y qué acceso o registro permitiría completarlo. Eso hace que IT/OT, operaciones y finanzas trabajen sobre la misma incertidumbre. También permite medir dónde falla la observabilidad: si la mayoría de casos se bloquea por falta de correlación, el problema no es la capacidad de contar filas sino el contrato de evidencia entre sistemas.
Guarde también el resultado negativo. Si se concluye que las dos filas corresponden a eventos distintos, anote qué atributos lo demostraron. Esa nota evita que una revisión posterior vuelva a abrir el mismo caso porque las cantidades se parecen. Una investigación útil registra tanto el duplicado confirmado como la sospecha descartada.
Defina una fecha de revisión si la evidencia aún no llega. El paso siguiente puede ser obtener una traza, validar una regla o comprobar otro evento. Cerrar por falta de tiempo deja el mismo riesgo en el siguiente turno; mantener la pregunta delimitada permite retomarla sin volver a empezar.
Una escalada eficaz no adjunta solamente una captura del informe. Incluye los dos registros, las claves que coinciden y difieren, el periodo, la regla que todavía no se conoce y una petición de decisión. Si la respuesta depende de una traza, especifique el identificador y la ventana de búsqueda. El equipo receptor no debería tener que adivinar qué evento se considera repetido.
La persona que recibe la incidencia también necesita saber el impacto conocido y el que aún es incierto. “La suma de este informe incluye ambas filas” es un hecho. “El inventario está mal” puede ser una hipótesis. Separar ambas frases evita que se active una corrección de alcance excesivo.
Esta guía no prueba que una cifra duplicada haya afectado a inventario, coste, calidad o cumplimiento. No define el comportamiento de reintentos de ninguna plataforma y no reemplaza registros de auditoría, controles de acceso ni procedimientos de corrección. La evidencia de cada caso y las responsabilidades de la organización determinan si existe un duplicado y qué acción puede tomarse.
No extrapole el resultado de una correlación a todas las confirmaciones de una planta. El mismo síntoma puede originarse en una interfaz, un informe, una operación manual o una corrección. Amplíe una medida solo cuando el alcance, la regla y la autorización estén documentados.
No. Pueden corresponder a operaciones, lotes, turnos, unidades o momentos distintos. Hay que demostrar que describen el mismo evento de negocio y de ejecución antes de tratarlas como una duplicidad.
No sin el procedimiento y la autorización aplicables. Conserve valores, identificadores, trazas y motivo; una eliminación inmediata puede destruir la evidencia que permite explicar el caso.
El identificador útil depende de la integración: puede incluir orden, operación, lote, evento, correlación o mensaje. Debe ser estable y relacionable con los registros de origen, recepción y aplicación.
No necesariamente. Un reintento puede ser seguro si el receptor reconoce el mismo evento, o puede requerir análisis si no existe esa protección. La traza y la regla local son necesarias para concluir.
Cuando el caso queda explicado con evidencia, la acción autorizada conserva la trazabilidad y una comprobación posterior confirma que el patrón se comporta como se esperaba.