Validar una regla de transformación de MES a ERP

Una cifra que cambia al pasar de MES a ERP no se vuelve fiable porque aparezca en dos pantallas. Tampoco se vuelve errónea por no coincidir de inmediato. Entre el evento de fabricación y la lectura empresarial pueden existir reglas que seleccionan campos, traducen unidades, agrupan confirmaciones, asignan estados o relacionan identificadores. La revisión útil consiste en hacer visible ese recorrido para un caso concreto, sin reescribir la historia con el resultado que parece más cómodo para el cierre.

ISA-95 describe estándares para la integración entre sistemas de control de fabricación y sistemas empresariales. Fuente: ISA-95 La descripción pública sitúa un marco de intercambio; no publica la configuración de una planta, sus mapas de campos, sus colas, sus permisos ni sus criterios de corrección. Por eso esta guía no explica cómo programar o cambiar una interfaz. Ayuda a preparar una comprobación documental que otra persona pueda repetir con las fuentes autorizadas.

Delimite el caso antes de mirar una regla

Empiece por algo que pueda volver a abrirse. Puede ser una confirmación de operación, un registro de producción, una orden o un mensaje, siempre que la organización pueda recuperar su identificador y la consulta de la que procede. Anote qué pregunta intenta resolver: por ejemplo, si un resultado de MES llegó al ERP con una unidad, un estado o una relación distinta. No redacte todavía una causa. La primera obligación es conservar el hecho tal como era visible antes de aplicar filtros, ajustes manuales o exportaciones agregadas.

Para ese caso, guarde el identificador principal y los identificadores relacionados que las fuentes muestren: orden, operación, material, activo, lote de interfaz, mensaje o confirmación. Registre además la cantidad, la unidad, el estado, la fecha y hora, el sistema que la muestra y la consulta utilizada. Si una marca temporal no contiene zona horaria o una pantalla no explica su criterio de corte, indique esa ausencia. Una limitación declarada es más útil que una precisión inventada.

Una regla de transformación no tiene sentido sin su entrada. El mismo valor numérico puede representar piezas, cajas, peso, una confirmación parcial o un acumulado; el identificador puede referirse a una orden padre, una fracción o una operación. Reunir el contexto evita el atajo de comparar una salida de ERP con un total que MES construyó en otra ventana. Antes de pedir a nadie que revise la regla, confirme que la comparación contiene objetos que realmente pueden corresponderse.

Elemento	Pregunta verificable	Evidencia que conviene conservar	Límite que debe declararse
Entrada	¿Qué evento o registro llegó al punto de integración?	ID, cantidad, unidad, estado y consulta	La fuente puede no exponer el mensaje íntegro
Regla	¿Qué transformación se afirma que actuó?	Nombre, versión, propietario y estado visible	Un nombre no prueba su lógica efectiva
Salida	¿Qué recibió o muestra el destino?	ID correlacionable, valor, unidad, estado y hora	La carga puede haberse procesado después
Comparación	¿Qué coincide y qué difiere?	Tabla con valores originales y ventanas	La diferencia no identifica por sí sola una causa

Esta tabla evita dos fallos frecuentes. El primero es llamar regla a cualquier paso de una integración sin demostrar que afectó al caso. El segundo es tratar el valor final como si fuera el único registro que importa. La revisión es una cadena: entrada, transformación identificable y salida observada. Si uno de los tres es inaccesible, el resultado debe reflejar que la evidencia es incompleta.

Separe los hechos del modelo que los interpreta

El hecho operativo puede ser que se registró una cantidad en un momento y con un estado determinado. La interpretación puede venir de una unidad, una conversión, una clasificación de movimiento o una relación con la orden. Confundir ambas capas hace que una diferencia de representación se convierta sin prueba en una diferencia de fabricación. Mantenga una columna para los hechos de origen y otra para las decisiones de lectura de cada sistema.

La información pública de ISA-95 trata modelos y atributos que se intercambian entre funciones de control y empresa. Fuente: ISA-95 Esto no confirma que un atributo concreto viaje en su instalación ni que un destino interprete un campo de una manera concreta. Sirve para recordar que el intercambio requiere describir entidades y sus atributos; una coincidencia superficial de etiquetas no sustituye esa comprobación local.

Por ejemplo, una entrada puede exponer una cantidad y una unidad base mientras el ERP muestra una cantidad comercial. No es responsable afirmar que se aplicó un factor específico solo porque ambos números guardan una relación aparente. Debe localizarse la unidad de cada registro, la regla o maestro que se indica para el caso y el mecanismo autorizado para verificarla. Si la fuente no exhibe el factor o la versión, anote “no verificable con la evidencia disponible”.

También conviene separar un estado de negocio de un resultado técnico. “Enviado”, “aceptado”, “contabilizado”, “cerrado” o “visible en informe” pueden designar momentos diferentes según la configuración local. No use esos términos como sinónimos. Para cada estado, copie el literal mostrado por la fuente y la hora asociada; después formule una pregunta concreta al propietario: qué significa ese estado para ese objeto y si pertenece al recorrido que se está revisando.

Localice la regla sin presuponer su versión

Una transformación puede estar en una interfaz, un servicio, un adaptador, una consulta o una capa de informe. La revisión no necesita adivinar dónde está programada, pero sí necesita un nombre recuperable. Solicite al propietario de la integración el identificador de regla, versión o artefacto que pueda relacionarse con el caso, junto con la evidencia de que estaba activo en la ventana revisada. Si solo existe un nombre informal, no lo eleve a hecho técnico.

La descripción de ISA-95 sitúa operaciones de fabricación y funciones empresariales como ámbitos funcionales relacionados y distintos. Fuente: ISA-95 Esa distinción ayuda a repartir preguntas: operaciones puede confirmar el contexto del evento; IT/OT puede localizar la integración; el propietario de ERP puede explicar qué lectura muestra el destino. No implica que uno de esos equipos sea culpable ni que la norma asigne permisos, responsabilidades o aprobaciones locales.

Conserve por separado las fechas de creación, publicación, activación, recepción y consulta cuando estén disponibles. Decir “la regla estaba vigente” mezcla posibles significados. Una configuración pudo estar aprobada sin desplegarse, desplegada sin procesar el mensaje concreto o visible en una pantalla después de que el mensaje ya hubiera pasado. Una cronología con fuentes es más sólida que una fecha única llamada “cambio”.

Una ficha breve de revisión puede tener este formato:

1. caso y alcance: qué orden, confirmación o mensaje se compara;
2. entrada original: fuente, ID, valor, unidad, estado y hora;
3. transformación identificada: nombre, versión, estado visible y dueño de la confirmación;
4. salida: fuente de ERP, ID correlacionable, valor, unidad, estado y hora;
5. diferencias observadas: solo hechos, sin diagnóstico;
6. preguntas abiertas y limitaciones: qué fuente falta y quién puede revisarla.

No complete la ficha con datos reconstruidos de memoria. Si se obtiene una exportación posterior, marque cuándo se extrajo y qué filtros empleó. El objetivo no es acumular capturas, sino dejar una senda de evidencia que permita repetir la comparación sin cambiar los valores originales.

Compare unidades, cardinalidad y estado

La validación de una regla no debe limitarse a restar dos totales. Compare primero si ambos registros representan la misma unidad de análisis. Una entrada de MES puede ser una operación; la salida puede resumir varias operaciones en una orden. Una salida de ERP puede contener un registro adicional para una corrección o un movimiento que la consulta de MES dejó fuera. Antes de hablar de duplicado o pérdida, haga visible la cardinalidad: cuántos elementos de origen se relacionan con cada elemento de destino.

Prepare una tabla de correspondencia por identificador, no por orden visual. Enumere cada entrada relevante, el ID de salida que afirma corresponderle, la cantidad y el estado en ambos lados. Cuando haya muchos elementos, use una muestra con criterio explícito: primera diferencia en la ventana, una fracción de orden o un mensaje con correlación recuperable. No generalice a todo el periodo desde una única observación.

Las unidades requieren la misma disciplina. Escriba el literal de cada fuente y no convierta por cuenta propia para “hacer que coincidan”. Si el proceso autorizado expone una relación, consérvela como evidencia y señale de dónde procede. Si no la expone, deje la comparación como pendiente. Un informe que mezcla unidad física, comercial y contable puede parecer preciso y seguir sin responder qué representa realmente cada número.

El estado merece otra columna. Un evento confirmado no es necesariamente una recepción contabilizada; una salida aceptada por la interfaz no demuestra que el informe de cierre la incluya. La fecha de consulta también importa: una pantalla puede actualizarse con retraso o aplicar una ventana distinta. Describir estas condiciones no excusa una diferencia; evita atribuirla a una transformación antes de haber descartado explicaciones que la evidencia permite comprobar.

Formule pruebas pequeñas y reversibles

La pregunta útil no es “¿funciona la interfaz?”, sino “¿qué relación observable debería existir si esta transformación se aplicó al caso?”. Una prueba documental puede consistir en verificar que un identificador de entrada aparece asociado al identificador de salida, que la unidad queda explícita o que el estado cambia según una condición visible. No pida cambios de producción, reenvíos ni reproducciones con datos reales para contestar una duda de informe; siga los controles y entornos autorizados por la organización.

La serie ISA-95 se denomina también IEC 62264 y se orienta a la integración entre sistemas empresariales y de control de fabricación. Fuente: ISA-95 El nombre de la norma no valida un mensaje individual, una correspondencia de campos ni una regla concreta. La prueba sigue siendo la evidencia local que relacione ese mensaje, esa versión y ese resultado.

Defina para cada prueba un resultado que pueda quedar como “confirmado”, “no confirmado” o “no verificable”. Evite la categoría “fallo de integración” si la revisión solo ha demostrado una diferencia. Por ejemplo: “se confirma que ambos registros comparten el identificador de orden; no se confirma la relación entre sus unidades; no es verificable la versión de la regla con las fuentes recibidas”. Esa forma de redactar protege la investigación de conclusiones más grandes que la evidencia.

Cuando la salida no pueda relacionarse con una entrada concreta, registre el alcance afectado y escale por el canal de gobierno establecido. No convierta esa ausencia en una instrucción para borrar, reinyectar o corregir datos. Es posible que intervengan trazabilidad, inventario, calidad, coste, seguridad, auditoría o cumplimiento; cada uno requiere propietarios y controles propios.

Prepare una decisión que no borre la evidencia

Al cerrar una primera revisión, entregue una nota breve con hechos, diferencias, límites y siguiente propietario. Incluya enlaces o identificadores que permitan recuperar las fuentes autorizadas, no copias innecesarias de datos sensibles. Diga qué no se ha verificado. Si hay una hipótesis, marque que es hipótesis y qué observación podría confirmarla o descartarla.

La información pública de ISA-95 describe estándares y modelos de integración, no procedimientos locales de corrección, valoración, liberación de calidad, inventario o gestión de permisos. Fuente: ISA-95 La guía, por tanto, no recomienda una acción correctiva sobre los registros. Su resultado responsable puede ser simplemente un paquete de evidencia listo para que el propietario autorizado decida.

Un buen cierre responde cuatro preguntas: qué se comparó, qué se observa, qué todavía no puede demostrarse y quién debe responder la siguiente pregunta. Si el caso afecta producto liberado, trazabilidad, seguridad, inventario, coste, cumplimiento o una obligación contractual, señale el impacto potencial sin emitir una decisión fuera de competencia. La urgencia no justifica sustituir controles por una conciliación informal.

El siguiente paso práctico es elegir un caso que tenga entrada y salida recuperables, rellenar la ficha sin alterar valores y pedir al dueño de la integración solo la evidencia necesaria para identificar la regla. Esa disciplina reduce la discusión a elementos comprobables y deja un registro útil aunque la causa final resulte estar en una ventana, una unidad, un estado o una configuración ajena a la transformación.

Evite que el informe convierta la hipótesis en hecho

Un error habitual aparece cuando una nota técnica pasa a un informe de operaciones. La frase “la interfaz transformó mal la cantidad” puede circular como conclusión aunque el equipo solo haya detectado un desfase. Para impedirlo, separe en el documento la observación literal, la interpretación pendiente y la decisión que depende de ella. La observación puede decir que una entrada y una salida no coinciden bajo la consulta guardada. La interpretación puede decir que se investigará una transformación. La decisión puede ser escalar la evidencia, sin introducir cambios en registros.

Esta separación también protege al equipo que recibe la incidencia. Quien mantiene una regla puede comprobar si la versión era activa, pero no puede reconstruir una fuente que no se conservó. Quien conoce la operación puede explicar un evento parcial, pero no debe certificar el significado de un estado de ERP si no dispone de su definición. Presente cada pregunta con su propietario probable y su fuente de contraste. La colaboración mejora cuando no se envía una acusación genérica junto con una captura aislada.

Si la regla contiene condiciones, no las resuma como “aplica” o “no aplica” sin el dato que permitiría evaluarlas. Liste el campo de entrada pertinente, su valor visible y el lugar donde apareció. Si el campo no está disponible para la persona que revisa, eso limita la conclusión. No solicite registros que excedan el propósito ni distribuya información operativa, comercial o personal sin las protecciones de la organización.

La evidencia debe seguir siendo interpretable después de una actualización. Guarde la versión de la consulta, el rango temporal, los filtros y el momento de extracción. Una pantalla distinta al día siguiente no invalida automáticamente la primera; puede indicar una carga tardía, un cambio de vista o un estado que evolucionó. La revisión debe poder mostrar ambas lecturas y explicar qué se sabe de cada una, no elegir retrospectivamente la que parece más coherente.

La mejor señal de una validación madura es que otra persona pueda repetir la comparación y obtener el mismo conjunto de preguntas, incluso si la causa final cambia. Si no puede identificar el caso, recuperar la entrada, saber qué salida se comparó o comprender el límite temporal, todavía no hay base para afirmar que la transformación explica la diferencia. Detenerse ahí no es una falta de avance: es evitar que una decisión sensible se apoye en un relato no comprobado.

Preguntas frecuentes

¿Una diferencia después de una interfaz prueba que la transformación está mal?

No. Puede deberse a la ventana de consulta, una unidad, un estado, una carga posterior, una regla de informe o la propia transformación. Primero hay que preservar la entrada, la salida y el contexto de ambas sin reemplazar datos originales.

¿Qué debe identificarse de una regla?

El nombre o identificador recuperable, versión si está disponible, propietario, estado visible, fuente de consulta y las condiciones que puedan afectar al caso. Si algún dato no está expuesto, debe consignarse como limitación, no inferirse.

¿Puedo corregir el dato visible mientras se investiga?

No por esta guía. Conserve el valor original y use el proceso autorizado de la organización para cualquier corrección. Una modificación prematura puede ocultar la evidencia necesaria para resolver la discrepancia.

¿Es suficiente comparar totales diarios?

No siempre. Los totales pueden ocultar cambios de estado, fracciones, mensajes repetidos o distintos cortes temporales. Empiece por una unidad de análisis que permita vincular el evento de origen con el resultado observado.

¿Cuándo conviene escalar el caso?

Cuando la diferencia afecte liberación de producto, trazabilidad, seguridad, inventario, coste, cumplimiento o cuando no pueda recuperarse la entrada, la regla y la salida necesarias para una revisión responsable.