Una visualización muestra “cantidad de orden” y actualiza el valor a medida que MES registra producción. El lunes era una cantidad planificada; el miércoles parece un hecho ejecutado. La etiqueta no cambió y ya no es posible reconstruir qué referencia recibió el turno.
Separar plan y ejecución exige modelar dos objetos: el plan conserva entidad, versión, horizonte, estado y autoridad; la ejecución conserva evento, momento, estado observado y fuente. Se relacionan mediante identificadores sin sobrescribirse. ISA-95 describe niveles, objetos e intercambios entre control, operaciones y negocio. La página de ISA sirve para mapear responsabilidades y no prueba conformidad local.
El resultado no es una comparación de rendimiento. Es un contrato semántico que permite después calcular desviaciones sin confundir previsión, compromiso y hecho observado.
Use el mapa de fuentes industriales y la guía de acceso IT/OT. Revise la fuente autoritativa del KPI y la calidad antes de la capa de lectura.
Definir el objeto planificado
Registre qué se espera: orden, cantidad, operación, recurso, fecha o secuencia. Añada unidad y población.
Incluya versión, fecha de creación, vigencia, estado y autoridad. Un plan aprobado y un borrador no deben compartir etiqueta.
Conserve horizonte y granularidad. Una semana agregada no sustituye una asignación de turno.
Documente supuestos y excepciones conocidos. No los convierta en hechos futuros.
Definir el objeto ejecutado
Identifique evento, orden, operación, recurso, cantidad, estado y marcas temporales. Mantenga el origen.
Separe abierto, cerrado, corregido y anulado. Un evento iniciado todavía no aporta la misma evidencia que uno cerrado.
Registre cobertura: líneas conectadas, entradas manuales, huecos y latencia. La ausencia de eventos no demuestra ausencia de ejecución.
Conserve valores originales y correcciones. La última pantalla no debe borrar el historial.
Usar identificadores comunes
Relacione orden, operación, producto, recurso y centro mediante claves estables. Los nombres visibles pueden cambiar.
Versione correspondencias entre ERP y MES. Un código puede dividirse o agruparse después de una actualización.
No enlace por proximidad temporal cuando existe ambigüedad. Marque sin pareja y solicite evidencia.
Pruebe el enlace en ambos sentidos. Una ejecución no debería asignarse a dos planes sin una regla explícita.
Conservar versiones de plan
Cada revisión crea otra versión con autor, motivo y fecha efectiva. No sobrescriba la referencia anterior.
Indique qué órdenes adoptan la revisión. Una modificación del maestro no cambia automáticamente planes ya liberados.
Conserve diferencias entre versiones por campo. El lector debe saber qué cambió y no solo que existe una versión nueva.
Si una replanificación es parcial, limite su población. No aplique el nuevo valor a toda la semana.
La evidencia semántica conserva entidades, identificadores, versiones, estados, unidades, cortes y autoridades de plan y ejecución. ISA-95 ofrece modelos para integrar funciones de control, operaciones de fabricación y negocio. El resumen de ISA no valida los datos o interfaces de una planta.
Separar tiempos
El plan tiene creación, vigencia y corte. La ejecución tiene momento del evento, recepción, procesamiento y consulta.
No compare la fecha de consulta con la fecha planificada. Son dimensiones diferentes.
Registre zona horaria y criterio de cierre. Un evento tardío puede aparecer en otra versión de la vista.
Cuando el plan cambia durante la ejecución, relacione cada evento con la versión aplicable según la regla aprobada.
Separar estados
Use vocabularios distintos cuando describen ciclos distintos. “Liberado” en ERP y “activo” en MES no son sinónimos.
Documente correspondencias permitidas sin exigir una pareja para cada estado. Algunos solo existen en una capa.
No convierta un estado operativo en aprobación de negocio. Tampoco trate una aprobación como ejecución.
Muestre estados originales en cualquier comparación ejecutiva.
Mantener unidades y denominadores
Registre piezas, lotes, horas o toneladas y su escala. Incluya base de cantidad.
Una cantidad planificada puede incluir total de orden; la ejecutada puede contar solo unidades buenas. Manténgalas separadas.
Conserve numerador y denominador en tasas. No calcule desviación si las poblaciones no coinciden.
Documente conversiones y versiones de producto. Un factor actual puede no aplicar al evento histórico.
Diseñar nombres visibles
Use “plan vigente”, “plan versión 3”, “ejecutado cerrado” o “ejecución provisional”. Evite “valor” o “cantidad” sin semántica.
Incluya corte y unidad cerca del dato. No relegue lo esencial a una ayuda oculta.
Mantenga etiquetas consistentes entre informes. Una traducción local no debe alterar el significado.
Cuando falte estado o versión, muestre “desconocido” y no una etiqueta por defecto.
El proceso local define ambos objetos, conserva versiones y tiempos, enlaza identificadores, alinea unidades y solo después construye una comparación. ISA-95 distingue funciones e intercambios entre niveles empresariales y de operaciones. ISA no prescribe este modelo local ni garantiza interoperabilidad.
Construir la relación sin fusionar
Use una tabla de relación con identificador de plan, versión, identificador de ejecución y estado del enlace.
Mantenga uno a uno, uno a varios, varios a uno y sin pareja. No reduzca relaciones complejas a una única fila.
Registre quién valida la correspondencia y para qué población. Un enlace técnico no decide semántica.
No copie el valor ejecutado sobre el plan. La relación permite consultar ambos.
Tratar replanificaciones
Una replanificación crea una versión con motivo, autoridad y fecha efectiva. Enlace eventos posteriores según regla.
No reasigne retrospectivamente ejecución anterior para mejorar el cumplimiento aparente.
Conserve órdenes que mantienen la versión previa. La coexistencia de planes es válida si está gobernada.
Si no puede determinar la versión aplicable, marque la comparación como pendiente.
Tratar correcciones de ejecución
Una corrección crea otro estado o versión del evento. Mantenga el original y el motivo.
Registre si la corrección cambia cantidad, tiempo, operación o relación con el plan.
No reescriba el plan para hacer coincidir el evento corregido. Son ciclos separados.
Actualice comparaciones derivadas mediante una versión nueva y conserve la vista anterior.
Ejemplo: cantidad de orden
ERP libera 1.000 unidades. El martes revisa el plan a 900. MES registra 850 buenas y 30 rechazadas.
La vista conserva plan inicial, plan vigente, ejecutado total y ejecutado bueno. No muestra una sola “cantidad”.
La desviación se calcula contra la versión y población declaradas. Comparar 850 con 1.000 responde otra pregunta que compararlo con 900.
Ninguna cifra sobrescribe a las demás.
Ejemplo: operación agrupada
ERP define dos operaciones y MES las registra como un evento. La relación es varios a uno.
La ejecución puede asociarse a la ruta sin repartir tiempo entre operaciones por una proporción inventada.
Si una decisión necesita el detalle, la salida queda condicionada y pide otra evidencia.
La agrupación no demuestra que el proceso cambió; puede ser una representación de interfaz.
Ejemplo: evento tardío
El turno cierra a las 06:00 y un evento llega a las 06:20 con hora de ejecución 05:50.
La vista cerrada conserva el corte original. Una versión revisada incorpora el evento y explica el cambio.
No se mueve automáticamente al turno siguiente por hora de recepción. Tampoco se reescribe la reunión anterior.
El linaje conserva evento, recepción, procesamiento y consulta.
Probar el contrato
Seleccione un plan revisado, un evento corregido, una relación compleja y un dato sin pareja.
Pida a otra persona que reconstruya qué se sabía en cada corte. Debe identificar versiones y estados.
Compruebe que las visualizaciones no fusionan valores al faltar uno. Un nulo no se convierte en plan o ejecución.
Registre resultado, población y revisor. Repita la prueba tras cambios de interfaz.
Probar una versión concurrente
Seleccione una orden cuya revisión se aprobó mientras ya estaba en ejecución. Reconstruya el plan inicial, la nueva versión y los eventos observados.
La regla debe indicar si la orden conserva la versión anterior, adopta toda la revisión o cambia solo algunos campos. No lo deduzca por cuál valor coincide mejor con el resultado.
Compruebe que los eventos anteriores al cambio permanecen relacionados con el contrato que estaba vigente. Los posteriores necesitan una transición explícita.
Registre cualquier campo sin autoridad clara y detenga los cálculos derivados que dependan de él.
La prueba termina cuando otro revisor puede explicar qué versión aplicó en cada momento sin consultar a quien diseñó el modelo.
Tratar cantidades parciales
Una orden puede planificar un total y ejecutar confirmaciones parciales. Cada evento necesita cantidad, unidad, estado y relación con el plan.
No reemplace el total planificado por la última cantidad confirmada. Mantenga acumulado ejecutado y saldo como cálculos separados y trazables.
Distinga unidades producidas, buenas, liberadas y transferidas. Una misma cifra no responde a todos esos estados.
Si una corrección reduce una confirmación, conserve ambas versiones y recalcule el acumulado en una vista nueva.
Cuando falta cobertura de un turno, el saldo no demuestra producción pendiente; muestra una diferencia que todavía requiere evidencia.
Modelar secuencia y precedencia
El plan puede ordenar operaciones; MES registra el orden observado. Conserve ambas secuencias con sus identificadores.
Una inversión de eventos no demuestra incumplimiento si la ruta permite alternativas. Registre la regla que autoriza la secuencia.
No cambie el plan histórico para que coincida con la ejecución. La diferencia puede ser relevante para una revisión posterior.
Si dos eventos comparten marca temporal, use estados y relaciones, no un orden arbitrario de carga.
La precedencia observada describe un caso. No se convierte en ruta maestra sin aprobación.
Conservar motivos de cambio
Cada versión de plan debería registrar un motivo: demanda, material, mantenimiento, calidad, prioridad u otro código gobernado.
Mantenga el texto libre como complemento, no como única evidencia. Los motivos necesitan población y autoridad.
No infiera el motivo desde la ejecución. Una demora observada puede coincidir con el cambio sin causarlo.
Cuando el motivo se corrige, cree otra revisión. No edite la explicación que acompañó una decisión anterior.
El motivo permite agrupar revisiones, pero no reemplaza los campos exactos que cambiaron.
Revisar datos derivados
Cumplimiento, desviación, saldo o adherencia combinan plan y ejecución. Documente entradas, versiones, estados y fórmula.
No calcule un indicador definitivo con un plan borrador o eventos abiertos sin marcarlo. La etiqueta debe reflejar la condición.
Conserve el resultado anterior cuando una entrada se corrige. Así se puede reconstruir qué vio cada reunión.
Pruebe valores nulos, eventos duplicados y órdenes canceladas. Un cálculo que falla en silencio puede mezclar poblaciones.
Asigne propietario al derivado sin transferirle autoridad sobre los datos de origen.
Gestionar cancelaciones y cierres
Una orden cancelada mantiene su plan histórico y los eventos que ocurrieron antes del cierre. No elimine ninguno.
Registre momento, motivo y autoridad de cancelación. Separe cantidad cancelada de cantidad no ejecutada.
Si MES continúa recibiendo eventos, marque la discrepancia y revise identificadores; no los descarte automáticamente.
El cierre administrativo y el cierre operativo pueden ocurrir en momentos distintos. Mantenga ambos estados.
La comparación posterior debe declarar si incluye canceladas, cerradas o abiertas.
Auditar la semántica en exportaciones
Compruebe que CSV, API y hojas conservan columnas de tipo, versión, estado y corte. Una exportación plana puede volver a mezclar los objetos.
No use el mismo encabezado para plan y ejecución. Incluya identificadores estables aunque la vista visible sea más breve.
Registre versión del esquema y compatibilidad. Un consumidor antiguo puede interpretar mal una columna nueva.
Pruebe una importación completa y una parcial. Los campos ausentes deben permanecer nulos, no adoptar valores por defecto.
Documente quién consume cada exportación y qué decisión sostiene. Retire contratos obsoletos con fecha y reemplazo.
Preparar una visualización
Muestre plan y ejecución como series separadas con leyenda, versión, estado, unidad y corte.
La diferencia puede aparecer como cálculo derivado si conserva entradas y contrato.
No use el mismo color o etiqueta para objetos distintos. Tampoco oculte revisiones anteriores necesarias.
La visualización consume el modelo; no debe inventar su semántica.
Revisar la lectura con usuarios distintos
Entregue la misma vista a planificación, operaciones y dirección. Pida que expliquen qué representa cada serie y qué acción creen que permite.
Las respuestas deberían coincidir en entidad, versión, estado y corte, aunque cada equipo use el dato para una pregunta diferente. Si “real” significa cerrado para uno y provisional para otro, cambie la etiqueta y el contrato.
Observe si alguien suma, resta o sustituye valores fuera de las reglas. Esa conducta suele revelar que la relación no está suficientemente visible.
No resuelva la prueba con una nota verbal. Añada la información necesaria a la vista, al catálogo o a la documentación versionada.
Repita la revisión después de cambios de esquema. La familiaridad con la pantalla anterior no garantiza comprensión del nuevo modelo.
Preparar un modo de investigación
Una vista ejecutiva puede ocultar detalle que un analista necesita para explicar una discrepancia. Ofrezca un acceso de investigación con los mismos identificadores y versiones.
Mantenga el salto desde el valor agregado hasta eventos y planes originales. No cree otra extracción sin relación trazable.
El modo de investigación no autoriza a corregir fuentes. Puede anotar hallazgos y abrir acciones con propietario.
Limite datos sensibles según rol y finalidad. Trazabilidad no exige exponer toda la información a cualquier usuario.
Cuando el análisis cierre, enlace la conclusión con la versión examinada. Una explicación posterior no debe alterar la vista histórica.
Documentar límites de comparación
Declare qué pares de plan y ejecución son comparables: misma entidad, unidad, población y versión aplicable.
Una coincidencia de identificador puede ser insuficiente si cambió la ruta, el producto o el denominador.
Registre comparaciones condicionadas y el dato requerido para completarlas. No aplique un factor genérico.
Si el contrato impide comparar, muestre ambos objetos por separado. La ausencia de una desviación es preferible a una cifra sin significado.
Revise estos límites antes de publicar cualquier ranking o explicación causal.
Mantener la frontera del KPI
Separar objetos no sustituye definir un KPI. Fórmula, población, frecuencia y propietario pertenecen a otro contrato.
Si un indicador usa plan y ejecución, debe declarar qué versiones y estados acepta.
No cambie la fuente autoritativa de un KPI por una decisión de visualización.
El hallazgo puede abrir una revisión del indicador, pero no resolverla dentro de esta ficha.
Mantener ISA-95 dentro de su alcance
ISA-95 describe modelos, niveles y objetos de intercambio entre control, operaciones de fabricación y funciones empresariales. La página oficial es un resumen y no demuestra que una integración local cumpla la norma o sea segura, correcta o puntual.
Use el modelo para conversar sobre responsabilidades, no para certificar interfaces o datos.
Control final
Compruebe entidades, identificadores, versiones, estados, unidades y tiempos de ambos objetos.
Revise correspondencias, replanificaciones, correcciones y datos sin pareja. Conserve valores originales.
Busque etiquetas que mezclan previsión y hecho. Sustitúyalas por nombres semánticos.
Verifique que ninguna actualización sobrescribe el historial o transfiere autoridad.
La decisión etiqueta entidad, versión, estado y momento de cada dato y permite relacionar plan y ejecución sin fusionarlos; no calcula rendimiento ni redefine el KPI. ISA-95 aporta un marco general de niveles e intercambios. La fuente no certifica la implementación local.
Preguntas frecuentes
¿Por qué no debo usar el mismo campo para plan y ejecución?
Porque representan momentos, estados y autoridades distintos. Sobrescribir el plan con el observado elimina la referencia; presentar el plan como hecho oculta la ejecución.
¿Puedo relacionarlos en una misma visualización?
Sí, si cada serie conserva nombre, versión, estado, unidad y corte. La relación debe mostrarse como comparación y no como un valor combinado sin contrato.
¿Qué ocurre con una replanificación?
Crea otra versión de plan con fecha efectiva y autoridad. La versión anterior permanece disponible para explicar la ejecución y las decisiones realizadas.
¿La ejecución observada corrige automáticamente el plan?
No. Puede activar una revisión, pero el cambio del plan requiere su proceso y propietario. El evento observado no adquiere autoridad de planificación.
¿ISA-95 prueba que mi integración es correcta?
No. ISA-95 ofrece modelos de niveles, objetos e intercambios. La página resumen no prueba interoperabilidad, seguridad, latencia ni conformidad de una implementación local.