Cómo alinear el plan maestro y el calendario MES

Un plan maestro y un calendario MES pueden parecer dos formas de contar la misma producción. No lo son.

El primero suele responder cuánto se quiere fabricar y en qué horizonte; el segundo necesita decidir qué orden entra en una franja, con qué recurso y con qué estado.

Cuando se cruzan sin reconocer esa diferencia aparecen conversaciones difíciles: el plan afirma una cantidad y el calendario muestra otra, o la línea parece adelantada aunque el horizonte de uno empiece una semana después que el del otro.

La forma prudente de resolverlo es conservar la identidad de los dos artefactos y hacer explícita la traducción entre ellos. No se trata de imponer un formato único a todos los centros. Se trata de que otra persona pueda saber qué versión se comparó, qué ventana se eligió y qué supuesto convierte un volumen mensual en una secuencia operativa.

Alinear plan maestro y calendario MES exige conservar versión, horizonte y regla de traducción antes de comparar. El alcance de OPC UA Part 1 aporta el contexto técnico, no una regla de negocio.

El estándar OPC UA Part 1 describe el alcance de una tecnología de intercambio de información industrial. ISA-95 ofrece modelos y terminología para la integración entre empresa y control. Estas referencias ayudan a separar objetos y responsabilidades; no determinan cuál es la autoridad de una pantalla concreta ni prueban cómo funciona una instalación española. La decisión sigue siendo local.

Para este caso, la frase de trabajo es concreta: el plan maestro y el calendario de ejecución usan horizontes y estados distintos. La salida que se busca también lo es: conservar versión, horizonte y regla de traducción antes de comparar. Si alguno de esos tres elementos no se puede comprobar, el informe debe decirlo y dejar la hipótesis abierta.

Qué significa alinear

Alinear no es hacer que dos tablas tengan el mismo número de filas. Es establecer una relación defendible entre una intención de planificación y una representación ejecutable. El plan maestro puede agrupar por familia de producto, semana o centro de trabajo. El calendario MES puede dividir el mismo volumen en órdenes, operaciones, lotes, turnos y recursos alternativos. La relación puede ser uno a muchos, muchos a uno o temporalmente incompleta (OPC UA Part 1).

Antes de abrir los sistemas, describa el objeto de cada lado en una frase:

Objeto	Pregunta que debe contestar	Ejemplo de evidencia
Plan maestro	¿Qué volumen o familia se comprometió para qué horizonte?	Versión, fecha de publicación, periodo de vigencia y responsable
Calendario MES	¿Qué trabajo se colocó en una secuencia y franja?	Orden, operación, recurso, turno, estado y hora de consulta
Traducción	¿Cómo se pasa del agregado al detalle?	Regla de reparto, calendario laboral, unidad y redondeo
Excepción	¿Qué altera la relación normal?	Festivo, mantenimiento, producto alternativo o bloqueo autorizado

La tabla no sustituye al modelo local. Sirve para detectar la primera pregunta sin respuesta. Si el plan dice “semana 33” y el calendario usa horas UTC, por ejemplo, todavía no hay base para afirmar que una orden falta. Hace falta una convención de zona horaria, corte y fecha de negocio.

Fije el horizonte antes de comparar

El horizonte es más que una fecha inicial y otra final. Anote si el plan es rodante, congelado o una previsión que se revisa con una cadencia acordada. En el calendario, registre la ventana que la consulta devuelve y si incluye operaciones ya iniciadas. Dos informes con el mismo nombre pueden tener un horizonte distinto si uno se ejecuta al principio del turno y otro después de una replanificación.

Conviene guardar cuatro marcas temporales:

1. Fecha de negocio, la que usa la operación para agrupar la carga.
2. Fecha de publicación, cuando se puso a disposición la versión.
3. Vigencia, el intervalo en que esa versión podía utilizarse.
4. Consulta, el momento en que se extrajeron los datos.

No sustituya unas marcas por otras. La fecha de consulta explica cuándo vio el analista el dato, pero no demuestra que esa versión estuviera vigente al inicio del turno. La fecha de publicación tampoco indica que todos los sistemas la hubieran recibido. Si existe un retraso de interfaz, regístrelo como parte de la evidencia, no como una causa automática.

Una forma sencilla de probar el horizonte es elegir una orden que cruce el final de la ventana. Si la orden aparece en el plan de agosto y en el calendario de septiembre, pregunte qué fecha de negocio se está utilizando y qué regla parte la carga. Esa prueba suele revelar que el problema no está en la cantidad, sino en el límite temporal.

Conserve la versión y su estado

El identificador de versión debe acompañar al plan y al calendario. Si una herramienta no genera un número, construya una clave estable con el informe, la fecha de corte, el filtro y el archivo original; márquela como identificador técnico, no como versión oficial. Mantenga el estado: borrador, revisado, aprobado, publicado, sustituido o retirado pueden significar cosas distintas en cada planta.

El estado no es un adorno de la interfaz. Dice si una persona con autoridad podía usar ese plan para tomar una decisión. Un calendario que muestra una orden en estado “simulada” no debe entrar en la misma columna que una orden liberada. Si se mezclan, la diferencia resultante parece operativa aunque sea una diferencia de ciclo de vida.

La ficha mínima de una versión contiene:

• identificador y sistema de origen;
• autor o rol que la generó;
• momento de creación y de publicación;
• horizonte y zona horaria;
• estado y motivo de sustitución, si lo hay;
• hash o referencia al fichero extraído, cuando el control local lo permita.

Si el ERP conserva solo el último estado, no reconstruya versiones inventando sufijos. Anote que la historia no está disponible y pida la traza de cambios. La ausencia de una versión es un hallazgo de gobierno de datos, no una invitación a rellenar el campo.

Describa la regla de traducción

La traducción responde a cómo un agregado se convierte en detalle. Puede repartir una familia entre líneas, convertir cajas a unidades, distribuir horas entre turnos o asociar una orden a un recurso alternativo. La regla debe ser legible para una persona que no diseñó el modelo.

Escriba la regla con ejemplos pequeños, no con un párrafo abstracto. “Las 1.200 unidades de la familia A se reparten entre las órdenes 481 y 482 según el lote mínimo del maestro de producto” es comprobable. “Se distribuye proporcionalmente” no lo es mientras no indique a qué denominador, en qué versión y con qué redondeo.

Registre también lo que la regla no hace. Si no contempla horas de limpieza, pausas o cambios de formato, no la use para calcular ocupación efectiva. Si redondea cantidades, conserve el residuo y su destino. Un redondeo que desaparece puede parecer una pérdida de producción.

Los modelos de integración de ISA-95 ayudan a discutir niveles, actividades y objetos, pero no ofrecen el mapeo exacto de sus maestros. OPC UA describe modelos de información y mecanismos de comunicación. OPC UA especifica modelos de información, mensajes, comunicación y conformidad para interoperabilidad; no prueba calidad ni latencia de una instalación. Esa es una razón para conservar el perfil local y las pruebas de conformidad junto a la regla.

Ordene los datos para que la comparación sea repetible

La alineación debe producir una tabla de cruce, no una captura de pantalla. Elija una clave que ambos sistemas compartan o cree un enlace explícito con su responsable. Los campos habituales son familia, orden, operación, recurso, fecha, turno, estado, cantidad y unidad. No añada columnas porque estén disponibles: cada una tiene que servir para explicar una diferencia.

Ordenar la revisión del plan y el calendario por fecha, entidad, estado, unidad y propietario antes de comparar o explicar la decisión mantiene visible la procedencia. (NIST, medición del rendimiento operativo; OPC UA Part 1) En esta frase, “entidad” puede ser una orden o una familia según el nivel de análisis; la elección debe quedar escrita. El propietario es la persona o rol que puede aclarar el dato, no una etiqueta genérica como “sistema”.

Después, clasifique cada fila como alineada, pendiente o no comparable. Una fila pendiente necesita una solicitud concreta: versión del calendario, unidad de medida, excepción de turno o evidencia de recepción. Una fila no comparable puede permanecer fuera del total, pero el informe debe indicar cuántas hay y por qué. Ocultar la exclusión altera la lectura del plan.

Use una secuencia de revisión en siete pasos

1. Redacte la pregunta de negocio

Evite “¿cuadra el MES?”. Una pregunta mejor sería: “¿Qué parte del volumen de la familia B previsto para la semana 33 se trasladó a la semana 34, y qué versión autorizó el traslado?”. La pregunta fija el objeto, el periodo y la decisión pendiente.

2. Capture los dos originales

Guarde la exportación o consulta del plan maestro y del calendario, con sus filtros. Si no puede conservar el archivo, registre el identificador, la consulta y el propietario. No trabaje con una tabla que alguien pegó en un correo si no se puede volver a obtener.

3. Compruebe identidad y unidad

Compare códigos de familia, orden, recurso y unidad. Un código que parece igual puede tener una revisión de maestro distinta. Detenga la suma cuando falte la equivalencia. Primero resuelva la identidad; después discuta la cantidad.

4. Normalice la ventana

Aplique una sola zona horaria y una sola convención para el inicio y el final del periodo. Conserve la hora original para auditar el cambio. No convierta un evento nocturno en el día siguiente sin guardar la regla.

5. Aplique la traducción

Desglose el volumen del plan según la regla documentada. Marque redondeos, lotes parciales y recursos alternativos. Si la regla no cubre un caso, deje una línea “sin traducción” en lugar de distribuirlo a ojo.

6. Registre excepciones y estados

Anote festividades, mantenimientos, bloqueos de calidad y cambios autorizados. Relacione cada excepción con el estado de la versión que la incorporó. Una excepción sin autoridad es una hipótesis, no una explicación.

7. Pida una decisión acotada

El informe debe acabar con una decisión concreta: aceptar la alineación de una familia para una ventana, pedir una nueva versión, corregir la regla o abrir una investigación. Añada quién decide y qué muestra se comprobará después.

Ejemplo de una alineación que no fuerza el resultado

Suponga que el plan maestro de la familia C asigna 800 unidades a la semana 34. El calendario MES contiene dos órdenes: 500 unidades el lunes y 300 el miércoles. En la consulta del viernes aparecen 500 el lunes y 300 el jueves. Es tentador llamar “retraso” al jueves, pero todavía faltan datos.

Primero se comprueban las versiones. El plan tiene vigencia hasta el domingo y el calendario de lunes fue publicado antes del cierre del viernes anterior. La orden de 300 se mueve a jueves en una versión posterior, pero el registro no indica si el cambio fue autorizado. La traducción del plan a órdenes sí conserva la familia y la unidad. El horizonte, en cambio, usa una fecha de negocio distinta para el turno nocturno.

El resultado razonable no es sumar las 800 unidades y cerrar. Se documenta que el volumen sigue asignado a la semana, que la secuencia cambió y que la autorización está pendiente. La acción solicitada es localizar el evento de publicación de la versión posterior y confirmar su propietario. Si aparece, se clasifica como replanificación documentada; si no, se mantiene abierta la causa.

Este ejemplo no prueba que una planta concreta funcione así. Solo muestra por qué versión, horizonte y traducción deben aparecer juntos. Cambiar una de las tres variables puede cambiar la interpretación sin que cambie ninguna cantidad.

Asigne responsabilidades sin convertirlas en culpables

El responsable de planificación conserva la intención y la regla de reparto. Operaciones valida si el calendario representa la secuencia que el turno podía ejecutar. IT/OT comprueba la trazabilidad del intercambio y los estados. Calidad, mantenimiento o seguridad intervienen cuando la excepción afecta a su ámbito. La asignación debe seguir el procedimiento local; aquí se propone una pregunta para cada rol, no una cadena de aprobación universal.

En la ficha, use el nombre del rol y el canal donde se guarda la respuesta. “Preguntar a fábrica” no permite seguimiento. “Planificación, bandeja de cambios del turno, evento 2026-08-11-34” sí, siempre que el identificador exista y no incluya datos que el control local prohíba compartir.

NIST describe métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos. Ese enfoque resulta útil para pedir una evidencia concreta, pero no asigna responsabilidades a su organización. Ordenar la revisión del plan y el calendario por fecha, entidad, estado, unidad y propietario antes de comparar o explicar la decisión mantiene visible la procedencia. La responsabilidad debe seguir a la autoridad real de cada dato.

Decida qué hacer cuando falta una versión

Hay tres salidas frecuentes. Si la versión está identificada y la regla se puede repetir, se acepta la alineación para el alcance indicado. Si la versión existe pero la traducción no cubre el caso, se corrige el modelo o se delimita la conclusión. Si no hay versión ni trazabilidad suficiente, se congela la comparación y se solicita la evidencia mínima.

No llame “incumplimiento” a un caso del tercer tipo. Tampoco lo convierta en “alineado” porque los totales coincidan. La coincidencia puede ser accidental o proceder de una compensación entre órdenes. Una decisión prudente deja escrito qué dato desbloquea el caso y quién puede aportarlo.

La salida de la alineación debe conservar versión, horizonte y regla de traducción; si falta evidencia, mantener la hipótesis abierta. (ISA-95) Esa frase es el criterio para el cierre. Añada una fecha de revisión, no una promesa de resultado. Cuando la diferencia tenga impacto en producto, seguridad, inventario o compromisos, aplique el control local antes de modificar cualquier orden.

Compruebe la calidad del intercambio sin atribuirle más de lo que dice

Un mensaje recibido demuestra que llegó un mensaje, no que todos los campos representen el mismo estado. Compare la hora del evento con la hora de recepción, el identificador de correlación y la versión del esquema. Si hay reintentos, conserve el registro de cada intento y la regla que evita contabilizarlo dos veces.

No confunda interoperabilidad con rendimiento. Una especificación o protocolo no es diseño de planta ni garantía de seguridad; requiere perfil, implementación y pruebas de conformidad locales. (OPC UA Part 1) El texto de OPC UA y la referencia de ISA-95 no sustituyen a las pruebas de su interfaz ni a la validación de un cambio en producción.

Si la interfaz cae, el calendario puede seguir mostrando una versión anterior. El informe debe marcar el intervalo sin recepción y evitar una explicación causal hasta revisar los logs y la cola local. Una mejora técnica puede ser necesaria, pero no se decide desde una única comparación.

Mantenga un registro de aprendizaje pequeño

Después de cerrar el caso, elija otra familia o una ventana vecina con la misma regla. Compruebe si la versión, el horizonte y la traducción se reconocen sin ayuda del primer analista. Si la segunda muestra falla, no generalice el hallazgo; conviértalo en una petición de mejora del dato.

El registro puede incluir la pregunta original, las versiones, los campos comparados, la excepción, la decisión, la autoridad y la fecha de comprobación. No guarde capturas con credenciales, información personal o detalles de producto que el procedimiento de seguridad no permita. El control documental forma parte del análisis.

Para una discrepancia entre un plan y una orden ya ejecutada, consulte cómo comparar el plan ERP con la ejecución MES. Si la pregunta cambia a capacidad efectiva con órdenes abiertas, use revisar la capacidad real con órdenes ERP abiertas. La guía de conciliación MES-ERP ayuda a preparar la evidencia común.

Límites y uso responsable

Esta página ofrece una forma de documentar una alineación. No declara qué sistema es la fuente de verdad en todas las empresas, no calcula capacidad, no certifica una interfaz y no autoriza cambios de plan, inventario, calidad o seguridad. Los estándares y artículos citados aportan contexto metodológico; la población, las fechas efectivas y las reglas de su planta tienen que comprobarse por separado.

No extrapole un protocolo a una garantía de seguridad o a una integración correcta. La especificación requiere perfil, implementación y pruebas de conformidad locales. Del mismo modo, la ausencia de una versión no demuestra que alguien haya cambiado el plan sin permiso: demuestra que la evidencia disponible no permite identificarlo. En ambos casos, la decisión correcta es pedir el registro que falta.

Preguntas frecuentes

¿El plan maestro y el calendario MES son el mismo documento?

No. El plan maestro suele expresar volumen, familia o periodo a una granularidad más amplia; el calendario MES organiza órdenes, operaciones y recursos para una ventana concreta. La planta debe documentar cómo se relacionan.

¿Qué versión debo usar si el plan cambia durante el turno?

Guarde la versión que estaba vigente para la pregunta que se quiere responder y la versión posterior que se publicó. Si no se puede identificar el momento del cambio, retenga la comparación y solicite la traza.

¿Cómo trato un festivo o una excepción de calendario?

Registre la excepción como dato del calendario, con fecha, ámbito, autoridad y efecto. No la convierta en una pérdida de capacidad sin revisar si el plan maestro la contemplaba.

¿Puedo comparar cantidades mensuales con órdenes diarias?

Solo después de fijar la unidad, el periodo y la regla de reparto. Una suma diaria puede ocultar una orden parcial, una conversión o un cambio de producto, así que conserve el detalle que permite repetir el cálculo.

¿Qué evidencia debe quedar al cerrar la alineación?

El identificador de cada versión, las fechas de vigencia y consulta, la regla de traducción, las excepciones, los propietarios, las diferencias abiertas y la comprobación posterior sobre otra ventana.