Cómo comparar el plan ERP con la ejecución en MES

Comparar el plan del ERP con lo que muestra un MES suele empezar con una pregunta que parece sencilla: “¿por qué no se ha cumplido el plan?”. El problema es que ambas vistas pueden estar describiendo cosas legítimas y, aun así, no ser comparables. El plan puede ser una versión aprobada antes del turno. La ejecución puede recoger una secuencia que cambió por disponibilidad de material, recurso, calidad o una decisión local. Entre ambas pueden existir cambios formales, cambios todavía sin publicar y eventos que esperan a una interfaz.

La comparación útil no busca una pantalla ganadora. Busca una explicación repetible de una diferencia concreta. Para ello hay que fijar una orden o conjunto de órdenes, la versión del plan que se pretende contrastar, el periodo, la unidad y el instante de consulta. Con esos elementos se puede decidir si se está ante una replanificación, un incumplimiento, un registro pendiente o simplemente ante una comparación mal planteada.

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 explica ese alcance de integración. No establece la autoridad de una pantalla concreta, no garantiza que los mensajes lleguen en un plazo determinado y no diagnostica por sí misma un desvío de producción. Aquí se usa como referencia para separar objetos y responsabilidades, no como una regla de negocio de la planta.

Esta guía está dirigida a responsables de operaciones y de IT/OT que necesitan explicar un contraste entre planificación y ejecución. No autoriza cambios de inventario, de órdenes, de calidad, de seguridad ni de compromisos con clientes. Cuando la diferencia alcance alguno de esos ámbitos, la ficha técnica debe acompañar al procedimiento local y a la persona que tenga autoridad para decidir.

Defina qué versión de plan se está cuestionando

Antes de abrir una exportación, escriba una frase de caso. Por ejemplo: “Para la orden OF-481, se compara la versión de plan aprobada a las 05:30 con los eventos MES visibles a las 14:00, para decidir si la secuencia distinta se debe documentar como replanificación o investigar como ejecución no explicada”. Esa frase parece administrativa, pero evita mezclar un plan original con una planificación ya modificada a mitad de turno.

El plan necesita una identidad. Guarde el identificador de orden, producto, operación, recurso o línea si existe, la fecha de negocio, la versión o estado de planificación y el origen de la consulta. Si no hay una versión explícita, anote qué informe se usó, cuándo se ejecutó y qué filtros tenía. “El plan de hoy” no es suficiente evidencia: mañana puede representar otra secuencia aunque conserve el mismo nombre.

También defina qué significa ejecución. En unas plantas será una operación iniciada; en otras, una confirmación parcial, una cantidad buena, una orden cerrada o una declaración que ya pasó por controles. No compare “planificado” contra “real” hasta escribir qué representa exactamente cada columna. Una cantidad puede coincidir y estar hablando de operaciones distintas. Una secuencia puede divergir y ser correcta porque el recurso autorizado cambió.

Si una fila no puede responderse, no rellene el hueco con una suposición. Marque la evidencia pendiente y formule una solicitud concreta. Por ejemplo, pida la versión del plan o el identificador de cambio, no “toda la información de planificación”. Una solicitud precisa reduce el riesgo de que el equipo reciba un volumen de registros que no permite relacionar con el caso.

Separe la secuencia prevista de la secuencia observada

El plan puede indicar una secuencia por recurso, operación o franja horaria. El MES puede mostrar eventos en el momento en que se producen o se confirman. Es normal que esas capas tengan distinta granularidad. Por eso, el primer contraste no debe ser un porcentaje de cumplimiento. Construya una línea de tiempo pequeña que contenga solamente los eventos necesarios para la orden.

Incluya la liberación del plan, su última modificación conocida, el inicio de la operación, las confirmaciones parciales, los cambios de recurso y el momento en que cada sistema expuso el dato. Distinga el timestamp del evento del timestamp de recepción y del timestamp de consulta. Llamar “retraso” a cualquier intervalo sin saber qué instante se está mirando convierte una hipótesis en una etiqueta.

La norma ISA-95 incluye una parte dedicada a modelos y terminología. La ficha de ISA-95 identifica ese alcance como Part 1: Models and Terminology. La referencia no obliga a una instalación a usar sus nombres de campo, pero es una razón práctica para acordar localmente qué significan plan, orden, operación, recurso y confirmación antes de comparar datos de sistemas distintos.

En la línea de tiempo, cada elemento debe ser un hecho, no una conclusión. “Operación 20 inició a las 08:12 según MES” es un hecho si se conserva la consulta. “La operación empezó tarde por una avería” es una hipótesis que requiere otra evidencia. Mantener esa diferencia evita que la explicación se solidifique antes de revisar los registros disponibles.

Una secuencia observada puede diferir porque se sustituyó una máquina, porque se dividió un lote, porque se adelantó una operación compatible o porque el plan se volvió a publicar. Ninguna de esas opciones debe darse por cierta por el orden de dos registros. Pregunte quién autorizó el cambio, dónde quedó registrado y qué objeto del plan afectaba. Si no hay respuesta, clasifique el caso como cambio sin evidencia suficiente; no como error del operario ni de la interfaz.

Compare objetos y atributos, no solo totales

Un total de unidades terminadas es tentador porque cabe en un cuadro de mando. Sin embargo, puede esconder operaciones omitidas, retrabajos, descartes, sustituciones de recurso o diferencias de unidad. Descomponga el total por la clave que permita repetir el cruce: orden, operación, lote, recurso, material y periodo. La clave exacta depende del modelo local; lo importante es que se use la misma de ambos lados.

ISA-95 incluye Part 2: Objects and Attributes for Enterprise-Control System Integration. La descripción pública de la serie enumera esa parte. No confirma qué atributos conserva una implementación concreta ni cómo se mapean sus objetos. Sí respalda una revisión que pregunte por la identidad y los atributos de un objeto antes de sumar sus cantidades.

Para cada diferencia, compare por separado cantidad, unidad, estado, cobertura y precisión. Una cifra planificada puede ser entera y una confirmación tener decimales. Una vista puede incluir sólo producto bueno; otra, producción declarada antes de una decisión de calidad. La comparación no necesita elegir cuál es “más real”. Necesita indicar si las dos medidas responden a la misma pregunta.

Evite convertir cantidades antes de documentar la regla que usaría la conversión. Si el MES muestra unidades de proceso y el ERP cajas, guarde el factor, su versión, el redondeo y el maestro que lo proporcionó. Un cálculo hecho en una hoja auxiliar puede ser útil para una hipótesis, pero no debería reemplazar la evidencia original ni convertirse en el valor que se remite a un sistema.

En este punto conviene revisar también si el contraste pertenece al plan. Una variación por falta de material, por rechazo de calidad o por parada puede tener un tratamiento independiente. El análisis de plan frente a ejecución puede señalar el momento y la orden donde aparece la diferencia, pero no decide la causa industrial ni autoriza una corrección transversal.

Clasifique el tipo de diferencia antes de escalarla

Una clasificación breve ayuda a que la incidencia llegue a la persona adecuada. Use categorías que describan evidencia, no culpables. Puede ser una diferencia de versión, de secuencia, de objeto, de cobertura, de unidad, de estado o de evidencia faltante. Añada una categoría de “replanificación documentada” solo cuando exista un registro que conecte el plan original con el plan utilizado.

Una diferencia de versión aparece cuando el ERP y el análisis usan versiones o instantes de plan distintos. Una diferencia de secuencia aparece cuando el mismo objeto se ejecutó en otro orden y no se ha confirmado el motivo. Una diferencia de objeto surge cuando lo planificado y lo confirmado no corresponden a la misma operación, lote o recurso. La diferencia de cobertura se da cuando una vista excluye un tipo de evento. La categoría “evidencia faltante” debe ser aceptable: es mejor que inventar una causa.

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. Esa descripción no prescribe el flujo de aprobación, el cierre de una orden ni las responsabilidades de una fábrica. Por eso, la clasificación es una ayuda de triaje: no sustituye el procedimiento de operación, calidad, planificación o contabilidad.

Registre junto a la categoría una pregunta de decisión. Para una diferencia de versión: “¿qué versión de plan era vigente para esta orden a las 08:00?”. Para una de secuencia: “¿existió una autorización de cambio de recurso u orden?”. Para una de cobertura: “¿el informe ERP incluye confirmaciones parciales?”. Una pregunta bien redactada hace que la escalada tenga una salida concreta.

No use una categoría para cerrar el caso cuando falta evidencia. “Replanificación probable” no equivale a “replanificación documentada”. Conserva el estado abierto, identifica qué falta y evita que una posible anomalía quede escondida bajo una explicación plausible. Si el caso implica riesgo para producto, seguridad, trazabilidad o contrato, el control local puede exigir una pausa o una evaluación adicional.

Reconstruya el cambio sin alterar los registros

Una vez delimitado el caso, reconstruya el recorrido conocido. Empiece por el plan de referencia, continúe con los cambios que aparezcan en el ERP o en la herramienta de planificación, y añada después los eventos MES. Cuando sea posible, enlace identificadores de cambio, usuario autorizado, motivo, timestamp y resultado. Si no existen, deje constancia de esa ausencia.

ISA-95 identifica Part 5 como Business-to-Manufacturing Transactions y Part 6 como Messaging Service Model. La página oficial de la serie enumera ambas partes. La enumeración no prueba que una integración local entregue mensajes una sola vez, con un identificador común o en una secuencia concreta. En la práctica, cada caso necesita sus propias trazas, reglas y responsables.

No vuelva a procesar mensajes, cambie fechas ni edite una orden para ver si el total “vuelve a cuadrar”. Esa intervención puede borrar la condición que se investigaba o generar nuevos efectos sobre inventario, coste y programación. Si es necesario probar una regla, use un entorno autorizado o un caso histórico que tenga el mismo patrón y conserve los valores originales.

La ficha de evidencia puede tener seis bloques: qué plan se tomó como referencia; qué se observó en MES; qué modificación se conoce; qué trazas se revisaron; qué hipótesis siguen abiertas; y qué decisión se solicita. La ficha no tiene que ser extensa. Debe permitir que otra persona reproduzca la comparación sin depender de la memoria del primer analista.

Decida el siguiente paso y compruebe otro caso

El resultado puede ser aceptar una replanificación documentada, solicitar una corrección autorizada, mejorar la captura de un identificador o abrir una investigación técnica. Elija una acción que corresponda a la categoría hallada. Si se trataba de una versión distinta, no hay razón para tocar la ejecución. Si faltaba un evento, no hay razón para cambiar el plan hasta confirmar qué ocurrió con ese evento.

Antes de cerrar, haga una comprobación posterior sobre otra orden que comparta el patrón. Si el hallazgo fue una regla de publicación, revise una orden próxima al mismo corte. Si fue un cambio de recurso, seleccione una orden con la misma alternativa. La segunda comprobación no convierte la regla en universal; reduce el riesgo de haber interpretado un caso aislado.

Mantenga junto al cierre la versión de plan, los valores originales, la clasificación, los enlaces a evidencias y el responsable de la decisión. El aprendizaje útil no es “el total final coincidió”, sino “esta secuencia distinta se explicó por esta versión y esta regla”. Eso permite a operaciones y a IT/OT mejorar la observabilidad sin convertir el informe en una colección de capturas sin contexto.

Para profundizar en la comparación de una orden, consulte cómo conciliar una orden de producción entre MES y ERP. Si la diferencia aparece al cerrar una jornada, conviene revisar la hora de corte entre MES y ERP antes de atribuirla al rendimiento de producción.

Haga visible lo que hoy solo conoce el turno

Muchas discrepancias se repiten porque la decisión que cambió el plan queda en una conversación, un parte en papel o una herramienta sin enlace con la orden. No hace falta rediseñar toda la integración para mejorar el siguiente análisis. Empiece por identificar qué dato faltó en este caso: una versión, un motivo de replanificación, un identificador de correlación, un recurso alternativo o una marca temporal.

Convierta ese hueco en un requisito observable y acotado. “Registrar el motivo de cambio” es demasiado vago. “Guardar en la orden el identificador del cambio de secuencia y el usuario que lo aprobó” permite comprobar si la medida funciona. Defina también quién revisará una muestra y qué ocurrirá si el campo no llega al informe. Sin esa comprobación, el nuevo dato puede existir y seguir sin servir para conciliar.

La mejora debe respetar la gobernanza local. Un campo adicional puede implicar cambios en la interfaz, protección de datos, formación, validación o controles de calidad. No convierta la ficha de una incidencia en una especificación de producción. Lleve la propuesta al proceso de cambio aplicable y conserve el caso que la motivó como evidencia de necesidad.

Límites de esta guía

Esta guía no define qué sistema es la fuente de verdad en todas las organizaciones. Tampoco decide si una diferencia afecta inventario, coste, calidad, seguridad, obligaciones regulatorias o compromisos comerciales. La arquitectura, los controles y las autorizaciones locales definen esas responsabilidades. El método se limita a conservar evidencia y a convertir una diferencia general en una pregunta verificable.

No aplique una explicación de una orden a un lote completo sin comprobar que comparten versión, material, operación, recurso, condiciones de corte y reglas de intercambio. Dos casos con el mismo delta pueden tener causas distintas. Una ampliación masiva exige su propia autorización, lista de alcance y comprobación posterior.

Preguntas frecuentes

¿El ERP es siempre la referencia para comparar un plan?

El ERP puede contener la planificación aprobada, pero la fuente autorizada depende del objeto y del proceso local. Guarde la versión y el estado del plan que se consulta, sin asumir que toda pantalla representa una instrucción vigente.

¿Una secuencia distinta en MES demuestra que la producción se desvió?

No por sí sola. Puede existir una replanificación, una alternativa de recurso, una operación registrada tarde o una diferencia de modelado. Hay que revisar el cambio y el evento antes de clasificar el caso.

¿Qué hago si la cantidad ejecutada supera la planificada?

Retenga la comparación, confirme objeto, unidad, periodo y versión de plan. La diferencia puede requerir una investigación operativa, de inventario o de calidad; no debe compensarse con un ajuste sin autorización.

¿Se puede comparar por día en vez de por orden?

Puede usarse un total diario para detectar un patrón, pero la explicación debe volver a una orden, operación o evento identificable. Los totales pueden compensar diferencias que siguen abiertas en el detalle.

¿Qué evidencia debe guardarse al cerrar el análisis?

La versión de plan, los eventos ejecutados, las consultas originales, la regla aplicada, los responsables y la comprobación posterior. Una captura sin filtros, fecha o identificador no permite repetir el análisis.