Cómo revisar la hora de corte entre MES y ERP

Un cierre puede parecer una operación sencilla: llega una hora, se ejecuta un proceso y el informe queda distribuido. En una integración entre MES y ERP, esa apariencia dura poco. La planta puede seguir confirmando actividad cuando el ERP ya ha construido una vista de negocio. Una orden puede terminar antes del corte, pero su confirmación llegar después. Un turno puede terminar a una hora y el informe usar otra. Si nadie distingue esos momentos, la discusión se convierte en una pelea sobre cuál sistema “va retrasado”.

La revisión útil no busca imponer una hora universal. Busca que las personas que usan el cierre puedan responder lo mismo a cinco preguntas: qué evento limita la ventana, en qué zona horaria, con qué precisión, qué estados entran y qué ocurre con lo que llega después. Sin esas respuestas, dos cifras distintas no prueban una anomalía. Solo muestran que la frontera de información no está suficientemente descrita.

ISA-95, también conocida como IEC 62264, es una serie de normas para integrar sistemas empresariales y sistemas de control de fabricación. La página oficial de ISA-95 describe esa finalidad. No prescribe la hora de cierre de una planta, no impone una zona horaria ni valida que una ejecución local esté bien configurada. La norma ayuda a ubicar la conversación entre el nivel de operaciones y el de negocio; la regla de corte sigue siendo una decisión local que debe documentarse.

Esta guía sirve para revisar un cierre entre sistemas, no para sustituir un procedimiento contable, de calidad, de seguridad o de gestión de cambios. Si una diferencia puede afectar inventario, liberación de producto, coste o compromisos contractuales, el cierre técnico debe escalarse según las responsabilidades de la organización. Un timestamp bien escrito no autoriza una corrección.

Separe los relojes que intervienen en el cierre

La palabra “hora” suele ocultar varias marcas. Está el momento en que ocurre un evento de ejecución, el momento en que el MES lo confirma, el momento en que se emite o recibe una transacción, el instante en que el ERP lo aplica y el instante en que alguien abre un informe. Cada uno puede ser válido. Ninguno debe sustituir a los demás por comodidad.

Haga una lista corta con los relojes realmente disponibles. Anote la zona o desfase que muestra cada fuente, la precisión que conserva y si la marca cambia cuando se procesa el dato. Si un sistema solo expone minutos, no afirme que distingue dos eventos separados por segundos. Si una pantalla convierte UTC a una hora local sin mostrar el desfase, registre esa limitación antes de comparar un día con cambio de horario.

La Part 1 de ISA-95 se titula Models and Terminology. ISA-95 la enumera con ese nombre. Esa información no define las etiquetas de sus pantallas ni la precisión de sus relojes. Explica por qué conviene acordar el vocabulario antes de debatir un desfase: “cierre”, “confirmación” y “completado” pueden tener significados distintos para operaciones, planificación y finanzas.

Un equipo puede comenzar por una sola frase de definición: “El cierre operativo diario incluye eventos de salida confirmados por MES desde las 06:00:00 hasta antes de las 06:00:00 del día siguiente, hora local de la planta; el ERP conserva por separado la fecha de aplicación de la declaración”. Es una frase de ejemplo, no una regla que deba adoptarse. Sirve porque menciona evento, ventana, precisión, zona y separación entre dos vistas.

Escriba el contrato de corte antes de mirar el resultado

Un contrato de corte no es un documento extenso. Es el conjunto mínimo de decisiones que evita alterar la regla después de ver una cifra incómoda. Cada campo debe describir una situación que una persona pueda comprobar con registros. Si se usa una expresión como “cuando esté todo cargado”, falta el instante, falta la autoridad que decide qué es todo y falta una manera de revisar el mismo cierre al día siguiente.

Incluya al menos los siguientes puntos:

• Identificador y versión de la definición.
• Inicio y fin de la ventana, zona horaria y precisión.
• Evento o estado que permite incluir un dato.
• Tratamiento de órdenes abiertas, mensajes pendientes y correcciones.
• Momento de ejecución de cada proceso y propietario de cada decisión.
• Forma de marcar una excepción y de emitir una revisión.

No añada detalle porque una tabla parece más seria. El contrato debe contestar preguntas reales. Si el ERP cierra a las 05:30 y MES sigue recibiendo confirmaciones hasta las 06:00, no basta con registrar ambos horarios. Hay que decir si las confirmaciones de 05:31 a 06:00 pertenecen al cierre actual, al siguiente o a una versión posterior. La respuesta depende del objetivo del informe y de los controles de la organización, no del sistema que resulte más cómodo.

ISA-95 incluye Part 3: Activities of Manufacturing Operations Management. La serie oficial identifica esa parte. La referencia delimita actividades de gestión de operaciones, pero no decide la secuencia de una instalación concreta. Por eso, el contrato local debe asignar quién confirma la actividad, quién gestiona los pendientes y quién puede cambiar la definición.

No confunda la necesidad de una regla estable con la obligación de mantenerla para siempre. Un nuevo turno, una nueva línea, una interfaz sustituida o una decisión empresarial distinta pueden exigir otra frontera. Lo importante es que el cambio tenga fecha de vigencia, explicación y una comparación de impacto. Cambiar la hora sin versión hace que una serie parezca continua cuando su cobertura ya cambió.

Revise la secuencia, no solo la diferencia final

Una diferencia después del corte no demuestra que haya un fallo. Puede ser una ventana prevista de procesamiento, un evento pendiente de validación, una orden que todavía no cumple su condición de cierre o un dato recibido con una zona horaria distinta. La forma de distinguir esas situaciones es reconstruir la secuencia de un caso, desde el evento que pretende medirse hasta la vista que usa el ERP.

Elija un caso situado cerca de la frontera. Conserve la orden, operación o lote; el valor en ambos sistemas; el estado literal; las marcas temporales disponibles; y los identificadores de cualquier intercambio. Después ordene los hechos observables. Marque qué sabe y qué aún falta. Una línea de tiempo puede ser suficiente:

1. Evento de producción registrado a una hora conocida.
2. Confirmación o validación en el MES.
3. Preparación y salida de la transacción o tarea.
4. Recepción, rechazo o aplicación en ERP.
5. Generación de la versión de cierre que se discute.

Si falta el paso tres o cuatro, no complete la historia con una explicación probable. Solicite la evidencia exacta: resultado de una interfaz, identificador de correlación, estado de una cola o registro de una tarea manual. Los datos que no pueden observarse siguen siendo una limitación; no se convierten en causa por aparecer entre dos timestamps.

La Parte 5 de ISA-95 se denomina Business-to-Manufacturing Transactions. ISA-95 usa esa denominación para Part 5. No garantiza que las transacciones locales se procesen al instante, una sola vez o de igual forma en cualquier ERP. Para una revisión de corte, la referencia permite expresar qué debe investigarse: la transacción o proceso que conecta un dato de operaciones con una vista de negocio.

La tarea de revisión gana precisión cuando cada discrepancia se etiqueta como una de estas alternativas provisionales: comportamiento previsto dentro de la ventana acordada; pendiente que debe aparecer en una versión posterior; diferencia de objeto o estado; diferencia de tiempo o zona; intercambio pendiente de evidencia; o incidencia que requiere corrección aprobada. Ninguna etiqueta debe usarse como atajo para saltar la evidencia.

Trate los pendientes como cobertura, no como silencio

Un registro que llega después del corte no es necesariamente una excepción. Es información que no estaba en la primera versión o que la definición decidió tratar de otra forma. La cifra debe decirlo. Mostrar un total sin indicar que dos órdenes siguen pendientes puede llevar a una persona a interpretar una cobertura parcial como un cierre final.

Una nota de cobertura debe ser específica y sobria. Puede indicar qué objeto falta, por qué condición no entra, quién lo revisa y cuándo se espera la siguiente versión. Si no se conoce el impacto, dígalo. No calcule una estimación para hacer que el informe parezca terminado. Si sí se conoce, conserve la regla que permite calcularla y no la mezcle con el total definitivo sin una etiqueta visible.

La Part 2 de ISA-95 aborda Objects and Attributes for Enterprise-Control System Integration. La página oficial de ISA-95 enumera esa parte. La norma no diseña los campos de una nota de cierre local. La utilidad de la referencia está en recordar que un total sin atributos de periodo, estado, unidad y procedencia pierde el contexto necesario para comparar una versión con otra.

No use “provisional” como una forma elegante de dejar una cifra sin responsable. Una vista provisional debe indicar el criterio que la hace provisional y el hecho que permitirá revisarla. Si no existe una regla para completarla, el caso necesita un acuerdo de gobierno antes de distribuirse como información de decisión.

Alinee las excepciones con personas y controles concretos

Hay cierres que se mueven por una parada, por una campaña especial, por una incidencia de comunicaciones o por una obligación de negocio. Esas situaciones no se resuelven ignorando la hora pactada. Requieren una excepción visible. La excepción debe tener motivo, alcance, periodo, aprobador, datos afectados y forma de recuperar la regla ordinaria. Si cambia la comparabilidad de la serie, el informe debe advertirlo.

La serie ISA-95 también incluye Part 6: Messaging Service Model. ISA-95 identifica Part 6 con ese título. Esta mención no afirma que una planta use ese modelo ni determina cómo se gestionan colas, reintentos o caídas. Cuando exista una incidencia de intercambio, los controles reales de la arquitectura y el procedimiento de cambios son los que deben decidir qué se hace.

Antes de alterar datos o reejecutar procesos, determine si la operación está autorizada y qué otros ámbitos toca. Un reintento puede crear una duplicidad. Una reapertura puede alterar estados que usa calidad. Una corrección contable puede necesitar otra aprobación. Una guía de corte no permite saltar esas fronteras. Puede, eso sí, aportar el caso delimitado que necesitan los equipos responsables.

Pruebe la definición con escenarios que suelen cruzar la frontera: una orden que continúa después de la hora, una confirmación inmediatamente anterior y otra inmediatamente posterior, una recepción retrasada y un cambio de horario oficial si aplica a la planta. Escriba el resultado esperado antes de consultar los sistemas. Si se redacta después, es fácil convertir cualquier salida en la regla correcta.

Deje una versión que alguien pueda repetir mañana

El cierre queda mejor gobernado cuando la próxima persona puede repetirlo sin interpretar mensajes antiguos. Conserve la definición, su versión, las fuentes de datos, el momento de ejecución, los pendientes y las excepciones. Si se modifica un informe, mantenga la versión anterior y diga qué cambió. La trazabilidad no consiste en guardar todo: consiste en guardar lo necesario para volver a explicar una cifra concreta.

Una revisión final puede plantear estas preguntas: ¿la ventana usa el evento que el indicador pretende medir?, ¿los dos sistemas muestran la misma zona y precisión?, ¿los estados incluidos están definidos?, ¿los pendientes son visibles?, ¿las excepciones tienen aprobador?, ¿la regla se probó con un caso cercano al borde? Cuando alguna respuesta no está disponible, el cierre no necesita fingir certeza. Debe mostrar su limitación y abrir una tarea de revisión.

Si el caso no es un problema de corte sino una diferencia por orden, use una conciliación específica para reconstruir objeto, estado, unidad y transacción. Si el cierre se publica en un informe operativo, puede complementar esta revisión con la validación de la hora de corte del informe de producción. El siguiente paso no es automatizar una decisión; es conseguir que el informe diga con precisión qué incluye.

También conviene registrar quién consultó cada fuente y a qué hora. Esa información no sustituye el timestamp de origen, pero permite descubrir que una comparación se hizo con una versión del MES actualizada y una versión del ERP todavía en proceso. Si las consultas no son simultáneas, la ficha debe decirlo. Es mejor declarar esa limitación que atribuir después el desfase a un sistema sin haber revisado la secuencia de lectura.

Guarde asimismo la decisión de no modificar el cierre cuando el caso queda pendiente. Esa decisión tiene valor: explica que la primera versión conservó su frontera y que el dato se revisará con una regla conocida. Si el informe ya se distribuyó, la versión posterior debe citar la anterior y describir si el cambio afecta la comparación. De ese modo, una corrección no borra el contexto que tenía la persona que recibió el primer cierre.

La revisión periódica puede ser ligera. Basta con revisar algunos casos cercanos a la frontera, comprobar que las notas de cobertura siguen siendo comprensibles y confirmar que nadie ha cambiado una programación sin versionar la definición. Si aparecen patrones repetidos, entonces conviene abrir una mejora formal de la secuencia o de la observabilidad de la interfaz.

Límites y precauciones

Esta guía no fija la hora de una planta ni la fuente de autoridad de un dato. Tampoco asegura que una diferencia temporal sea inocua. La decisión depende de qué representa la cifra, de la arquitectura, del impacto y de los controles internos. Cuando el cierre influye en seguridad, calidad, inventario, contabilidad, derechos laborales o compromisos de entrega, deben participar las funciones que tienen competencia sobre esos efectos.

Evite hacer pruebas en producción para comprobar una hipótesis de timestamps si no están autorizadas. Los casos históricos cerrados, las trazas ya disponibles o un entorno controlado pueden ofrecer evidencia sin cambiar una orden activa. El objetivo es explicar una frontera de información, no conseguir que dos pantallas se actualicen a la vez.

Preguntas frecuentes

¿La hora de corte MES-ERP debe coincidir con el cambio de turno?

Puede coincidir, pero no es obligatorio. El relevo organiza personas y tareas; el corte define qué eventos entran en una vista. Si son distintos, ambos instantes deben declararse para que el informe sea interpretable.

¿Qué timestamp debe gobernar el cierre?

El que represente el hecho que la cifra pretende medir, según la definición local. Puede ser un evento de ejecución, una confirmación o un cierre de orden. Debe diferenciarse de la recepción del mensaje y de la hora en que se consulta el informe.

¿Un registro que llega tarde debe entrar en el cierre original?

Depende de la regla aprobada. Puede quedar como pendiente o requerir una versión posterior. Incorporarlo de forma silenciosa impide saber qué información estaba disponible en el momento de la primera decisión.

¿Quién aprueba una excepción de hora de corte?

La persona propietaria de la definición del cierre junto con las áreas afectadas por su uso. La excepción debe explicar motivo, vigencia, datos alcanzados y cómo se tratará la comparación con periodos previos.

¿Una diferencia tras el corte demuestra que la interfaz falló?

No. Puede haber una regla de procesamiento posterior, un estado pendiente o una ventana distinta. La conclusión exige revisar evento, secuencia y evidencia de intercambio del caso concreto.