Revisar un cambio maestro que altera producción

Un informe de producción puede cambiar de aspecto sin que cambie una sola unidad fabricada. Basta con que una regla de conversión, una unidad de medida, una relación de material, una receta de referencia o cualquier otro dato maestro se publique con otra versión. MES y ERP pueden entonces mostrar cifras que parecen incompatibles aunque ambos estén leyendo datos válidos dentro de sus propios cortes.

La respuesta responsable no es elegir el número que más conviene al cierre. Hay que identificar qué objeto maestro está en juego, qué versiones existen, cuándo se hicieron efectivas y qué eventos u órdenes pudieron recibirlas. Con ese recorrido, la diferencia deja de ser una discusión entre pantallas y se convierte en una pregunta revisable: qué significado tenía cada cifra cuando se registró.

ISA-95 describe normas para la integración entre sistemas de control de fabricación y sistemas empresariales. Fuente: ISA-95 El marco público ayuda a situar la frontera entre las funciones de operaciones y empresa; no publica el modelo de maestro, las reglas de vigencia ni los permisos de una planta concreta. Por eso esta guía propone una revisión documental y no una administración de ERP, MES ni datos maestros.

Empiece por un caso que pueda volver a abrir

No parta de una variación mensual completa. Elija una orden, un material o una confirmación donde la diferencia pueda verse con claridad. Anote el identificador de la orden, el activo o línea, el material, la cantidad, la unidad, el estado, la hora visible en cada sistema y la consulta o exportación que produjo el resultado. Si el caso cruza cambio de turno o medianoche, guarde también zona horaria y regla de corte.

La finalidad de este primer paso es evitar que una exportación grande esconda la primera discrepancia. Una misma suma puede mezclar operaciones terminadas, correcciones tardías, devoluciones, conversiones y estados que todavía no han cerrado. Reducir el alcance no significa minimizar el problema. Significa poder demostrar qué datos se compararon antes de buscar una explicación.

Separe además tres cosas que suelen aparecer juntas en una conversación:

• El hecho operativo. Una cantidad se produjo, se confirmó, se rechazó o se consumió según la evidencia disponible.
• El dato maestro. Una referencia, relación, unidad, versión, estado o atributo que da sentido a ese hecho.
• La regla de lectura. El sistema, interfaz o informe que decidió cómo asociar el dato maestro al evento.

Una modificación de maestro puede afectar a la segunda o tercera capa sin cambiar la primera. Si un factor de conversión se actualiza, el número en cajas puede cambiar al traducirse a kilos aunque la señal de unidades físicas permanezca igual. Si una relación de material se sustituye, la orden puede mostrarse bajo otra clasificación. Antes de llamar “error de producción” a la diferencia, compruebe si el desacuerdo nace de esa interpretación.

ISA-95 también trata modelos, atributos e información intercambiada en la interfaz entre funciones de control y empresa. Fuente: ISA-95 Ese dato no impone una estructura local de tablas ni confirma que un campo concreto se haya sincronizado. Sirve para recordar que compartir un identificador no garantiza compartir automáticamente su definición, versión o uso.

Localice el objeto maestro sin convertirlo en una causa

“El maestro cambió” es demasiado amplio para una revisión. Pregunte qué objeto concreto se modificó y qué campo se utilizó al interpretar la producción. Puede ser una unidad base, una equivalencia de embalaje, una receta, una relación entre material y operación, una jerarquía de activo, una versión de especificación o una regla que asigna una confirmación. No todos esos objetos tienen el mismo dueño, ciclo de aprobación ni efecto.

Es útil escribir el objeto en una línea que otra persona pueda reconocer: “material M-204, atributo de unidad comercial, versión visible V3” o “relación de operación OP-12 con receta R-7, versión que muestra el ERP”. Evite nombres genéricos como “tabla de planta” si no permiten recuperar la fuente. Si el visor solo enseña el valor actual y no la versión, deje documentada esa limitación en lugar de deducir qué valor había antes.

Una diferencia temporal no demuestra que el maestro causó un resultado. Puede coexistir con una captura tardía, una orden dividida, un error de mapeo, una interfaz retrasada o una corrección autorizada. La hipótesis correcta es más pequeña: “este campo podría haber alterado cómo se leyó la cantidad”. Luego hay que comprobar si la versión de ese campo llegó realmente a cada sistema y si entraba en la regla aplicada a la orden.

La descripción pública de ISA-95 sitúa la gestión de operaciones de fabricación y las funciones empresariales en ámbitos funcionales relacionados pero distintos. Fuente: ISA-95 Por eso una persona de producción puede ser responsable de aclarar el evento físico sin ser propietaria del dato maestro empresarial. La revisión debe asignar cada pregunta al propietario que puede verificarla, no pedir a un único equipo que resuelva todo el recorrido.

Un registro de revisión puede tener estas columnas:

Pregunta	Evidencia que se conserva	Propietario de la respuesta	Límite actual
¿Qué objeto cambió?	ID, campo, versión y fuente visible	Gobierno de datos o propietario funcional	El visor puede no mostrar historial
¿Cuándo fue aplicable?	Fecha efectiva, fecha de publicación y hora de recepción	Dueño del maestro e integración	Las fechas pueden tener significados distintos
¿Qué órdenes toca?	Orden, operación, material, ventana y estado	Producción y planificación	Una orden puede cruzar el cambio
¿Qué lectura hizo cada sistema?	Consulta, regla de informe y valor original	Propietario de MES, ERP o reporte	La interfaz no prueba la semántica

La tabla no decide quién cometió un error. Reduce una afirmación imprecisa a cuatro comprobaciones que pueden responderse con evidencia.

Distinga fecha efectiva, publicación y recepción

La fecha de creación de una versión no siempre dice cuándo afectó a producción. Un equipo puede preparar un cambio, aprobarlo después, publicarlo para una fecha futura y enviarlo a otro sistema en una ejecución posterior. MES puede recibirlo tarde, mantenerlo en caché o aplicarlo a una orden al comenzar una operación. ERP puede usar la fecha contable, la fecha de liberación o una regla de cierre distinta. Esos mecanismos dependen de la configuración local; no deben inventarse a partir del nombre de un campo.

Conserve por separado, si están disponibles, estas marcas:

1. cuándo se creó o modificó el registro;
2. cuándo se aprobó;
3. desde cuándo declara el sistema que es efectivo;
4. cuándo se publicó o se envió;
5. cuándo lo recibió y utilizó el sistema comparado.

No hay obligación de que todas coincidan. Lo importante es no sustituirlas por una sola “fecha del cambio” porque esa simplificación puede borrar la pregunta que explica la discrepancia. Una orden iniciada antes de la fecha efectiva y confirmada después merece atención especial: puede haber usado la versión que se fijó al liberarla, la versión vigente al confirmar o un mecanismo diferente. Solo los registros y las reglas aprobadas permiten saberlo.

La serie ISA-95 también se conoce como IEC 62264 y se orienta a la integración entre sistemas empresariales y de control de fabricación. Fuente: ISA-95 La equivalencia de nombres de norma no convierte una marca temporal local en una prueba de aplicación. La fuente no especifica qué evento debe elegir una organización española como inicio de vigencia para cada tipo de maestro.

En el informe, nombre la fecha y la fuente completas. Es preferible escribir “fecha efectiva mostrada por ERP: 14:00; recepción que figura en la interfaz: no disponible” que escribir “cambio aplicado a las 14:00”. La primera frase deja un hecho y una ausencia comprobable. La segunda añade una conclusión que quizá nadie pueda defender.

Reconstruya qué versión vio cada orden

Una vez identificado el objeto, siga una orden de extremo a extremo. Comience por la referencia que la orden utilizó al abrirse o liberarse, si el sistema la conserva. Continúe con las operaciones, confirmaciones, consumos y devoluciones relevantes. Después compare las consultas de MES y ERP que alimentan el informe. El objetivo no es reconstruir cada transacción del mes, sino saber en qué punto una versión podría cambiar la interpretación.

Para cada evento, anote la versión visible, la hora, el sistema y el valor antes de cualquier ajuste. Si un sistema no guarda la versión, indique “versión no expuesta” en vez de inferir esa versión por la fecha. Si recibe la versión mediante una interfaz, conserve el identificador de mensaje, lote o consulta que permita al propietario revisar la entrega autorizada. No copie datos personales ni detalles a los que el destinatario del informe no deba acceder.

La siguiente secuencia sirve como guía de revisión:

1. fije la orden y la ventana que va a explicar;
2. identifique el maestro, campo y versión que parecen relevantes;
3. recopile las fechas de creación, aprobación, efectividad, envío y recepción que cada fuente muestre;
4. liste los eventos de la orden que cayeron antes, durante y después de esas marcas;
5. compare qué regla y qué unidad empleó cada informe;
6. clasifique el resultado como explicado, pendiente de confirmación o no reconciliado.

ISA-95 busca proporcionar un lenguaje y modelos comunes para intercambiar información entre esas funciones de fabricación y empresa. Fuente: ISA-95 No proporciona la traza concreta de una integración ni certifica que una correspondencia de versiones esté completa. De ahí que el identificador local, la consulta reproducible y el historial aprobado sigan siendo la evidencia decisiva en este caso.

Una orden tiene historia. Puede incluir varias operaciones y recibir mensajes después de terminar físicamente la producción. Si la revisión solo compara el estado actual de la orden con la versión actual del maestro, puede reescribir el pasado con datos recientes. Mantenga el valor original de la extracción y señale cuándo se obtuvo.

Compruebe si cambió el significado de la cantidad

Las discrepancias más difíciles no siempre cambian el valor visible; cambian el significado que el informe le atribuye. Por ejemplo, una cantidad puede seguir siendo 120, pero una versión nueva puede describir otra conversión de envase, otra clasificación de rechazo o una relación diferente con el material. Esos ejemplos no prueban que haya ocurrido en su planta. Muestran por qué “las dos pantallas tienen 120” no basta para concluir que describen lo mismo.

Revise estos puntos antes de sumar o comparar:

• Unidad. ¿La cantidad es física, comercial, base, de lote, de caja o de peso? ¿Hay una conversión visible y una versión asociada?
• Objeto. ¿El material, operación, activo o receta es el mismo en las dos fuentes? ¿Se ha aplicado un mapeo aprobado?
• Estado. ¿La cifra representa ejecución, confirmación, contabilización, calidad pendiente, reversión o ajuste?
• Ventana. ¿La fecha efectiva y el corte del informe incluyen el mismo conjunto de eventos?
• Regla. ¿El informe usa el dato actual, una copia histórica, una fotografía de orden o una transformación posterior?

No convierta estos controles en una fórmula universal. El valor de la revisión está en explicar qué control fue relevante para un caso determinado. Si el informe no permite responder a uno de ellos, la conclusión debe incluir la limitación. Es más útil un resultado que diga “cantidad coincidente, unidad no verificada” que un total que parece seguro sin tener contrato de medida.

La información pública de ISA-95 describe estándares y modelos para la integración, no reglas de valoración contable, liberación de calidad ni gestión de inventario local. Fuente: ISA-95 Por eso esta página no decide qué cantidad debe usarse en un coste, un cierre financiero o una decisión de liberación. Esas decisiones necesitan sus controles y autoridades correspondientes.

Clasifique la salida sin ocultar la incertidumbre

Al terminar el caso, el resultado no tiene que ser “corregido” o “sin problema”. Una clasificación más honesta ayuda a que el siguiente equipo sepa qué hacer:

Explicado con evidencia. La versión, la fecha aplicable y la orden afectada quedan identificadas. Las fuentes muestran por qué MES y ERP presentan valores o descripciones distintas. La explicación conserva las consultas y no requiere cambiar ningún registro para ser válida.

Probable, pendiente de confirmación. La cronología sugiere que el maestro interviene, pero falta el historial, el mensaje de interfaz o la regla que confirma su aplicación. El informe puede describir la hipótesis como pendiente, sin presentarla como causa.

No reconciliado. Las fuentes siguen siendo incompatibles o no se puede conocer qué versión utilizó un sistema. El caso se conserva con su impacto y se escala al propietario adecuado. No se rellena la brecha cambiando un dato para que el gráfico cierre.

Fuera del alcance de esta revisión. El caso afecta seguridad, trazabilidad, calidad, inventario, coste, cumplimiento o permisos. La evidencia de versiones puede acompañar al caso, pero no reemplaza el procedimiento que debe gobernar la decisión.

Esta clasificación evita dos riesgos frecuentes. El primero es convertir una coincidencia de fechas en una causa. El segundo es tratar una diferencia de datos como si autorizara una corrección operativa. En ambos casos, la trazabilidad se debilita porque el informe deja de mostrar qué se sabía y qué seguía sin saber.

Prepare una solicitud de revisión que otro equipo pueda resolver

Cuando haya que escalar, no envíe una frase como “el maestro rompió producción”. Envíe un paquete pequeño y recuperable: identificador del caso, orden u operaciones, maestro y campo, versiones observadas, fechas y zonas horarias, valores antes de ajuste, fuentes consultadas, regla de informe cuando se conozca y una pregunta limitada. Por ejemplo: “Confirmar qué versión de la conversión de M-204 recibió MES para la confirmación C-18 y en qué momento se aplicó”.

La pregunta tiene que estar dentro de la autoridad de quien la recibe. El gobierno de datos puede confirmar el historial y las aprobaciones. El propietario de integración puede revisar una entrega o transformación. Producción puede confirmar el contexto de la orden y la evidencia física disponible. Finanzas, calidad, seguridad e inventario pueden necesitar intervenir si la consecuencia entra en sus ámbitos. Ningún informe de conciliación sustituye esa responsabilidad.

No borre valores originales al preparar el paquete. Mantenga la fecha de extracción, el estado que mostraba cada fuente y las lagunas. Si el propietario confirma un cambio, añada la respuesta como una nueva evidencia con fecha y fuente. Si rechaza la hipótesis, conserve igualmente la revisión: demuestra que una discrepancia se investigó sin reescribir los registros.

La próxima vez, el equipo no tendrá que recordar qué pantalla se miró ni qué versión estaba vigente ese día. Podrá volver a la orden, al maestro, a las marcas temporales y a la pregunta anotada. La conciliación queda entonces disponible para que otro revisor la repita.

Límites de una revisión de maestro

Esta guía no dice cómo diseñar datos maestros, administrar una interfaz o asignar permisos. Tampoco diagnostica por qué cambió una versión ni decide si el cambio estaba aprobado. Su utilidad termina donde empiezan los procesos que controlan calidad, seguridad, cumplimiento, trazabilidad, inventario o coste.

Un cambio de maestro puede coincidir con una variación de producción y no ser la explicación completa. Puede que la planta haya fabricado con otro material, que el cierre haya llegado tarde o que un operador haya registrado una corrección autorizada. Mantenga esas alternativas abiertas hasta que una fuente específica las confirme. Una cronología bien presentada es una base para investigar, no una sentencia.

El siguiente paso es aplicar la revisión a una orden con una diferencia real y conservar su primer resultado sin editarlo. Identifique un maestro, una versión, una fecha efectiva y una pregunta que tenga dueño. Si los cuatro elementos no pueden recuperarse, el resultado correcto es declarar la limitación y mejorar la trazabilidad antes de usar la diferencia para una decisión sensible.

Preguntas frecuentes

¿Un cambio de dato maestro demuestra que el MES o el ERP está equivocado?

No. Puede explicar una diferencia de interpretación, pero no prueba un error de ninguno de los sistemas. Hay que comprobar qué objeto cambió, qué versión recibió cada sistema, cuándo fue efectiva y qué regla aplicó a la orden concreta.

¿Qué es la fecha efectiva de un dato maestro?

Es la fecha o condición que el proceso local usa para decidir desde cuándo una versión puede aplicarse. No equivale necesariamente a la fecha de creación, aprobación, envío o recepción en otro sistema. El informe debe indicar qué fecha se está mirando y de qué fuente procede.

¿Hay que corregir todas las órdenes abiertas tras un cambio de maestro?

No automáticamente. Primero identifique cuáles órdenes, operaciones, materiales o confirmaciones quedaron dentro del alcance definido por el proceso local. Una orden abierta puede conservar una versión anterior o recibir la nueva en momentos distintos según la integración y sus reglas.

¿Puedo sustituir la versión antigua por la nueva en el informe histórico?

No sin conservar el valor y la versión originales, la regla de transformación y la autorización aplicable. Cambiar el informe para que parezca coherente puede ocultar una diferencia real de periodo, unidad, coste o trazabilidad.

¿Cuándo debe escalarse el caso?

Escale el caso por el canal establecido cuando afecte liberación de producto, trazabilidad, inventario, coste, seguridad, cumplimiento o cuando no pueda determinarse qué versión usó cada sistema. La escalada debe llevar hechos, fuentes y preguntas, no una causa supuesta.