Permisos y cambios de datos MES consumidos por ERP

Cuando un dato de MES cambia y después aparece en ERP, la pregunta más rápida suele ser: “¿quién tenía permiso para editarlo?”. Es una pregunta útil, pero incompleta. La existencia de un permiso no demuestra que una persona haya cambiado ese valor ni explica si el ERP consumió la versión anterior, la posterior, una transformación o una vista con filtros distintos.

Una revisión responsable debe reconstruir el objeto, la acción observada y el alcance posible. Un indicio de acceso no debe convertirse en una acusación.

ISA-95, también publicada como IEC 62264, es una serie de normas para integrar sistemas empresariales y sistemas de control de fabricación. La descripción oficial de ISA-95 sitúa ese límite de integración. No certifica los permisos de una instalación, no atribuye cambios a usuarios y no indica qué perfil debería tener una persona. Su valor en este caso es recordar que MES y ERP pueden trabajar con objetos relacionados y responsabilidades diferenciadas.

La finalidad de esta guía es preparar una investigación documental para responsables de operaciones e IT/OT. No autoriza retirar permisos, recrear datos, volver a transmitir una interfaz ni cambiar una configuración para “probar” una hipótesis. Si el caso puede afectar producto, trazabilidad, inventario, coste, seguridad, datos personales o cumplimiento, la evidencia debe llegar al proceso local y a la persona con autoridad para decidir.

Empiece por el dato, no por la persona

Defina el caso con una frase comprobable: “El atributo X de la operación Y se muestra con valor A en una consulta MES y con valor B en un informe ERP, y se necesita conocer qué cambio, si lo hubo, puede explicar la diferencia”. Esta formulación evita dos atajos: asumir que hubo edición y decidir antes de tiempo quién es responsable. También evita investigar un grupo completo de usuarios cuando todavía no se sabe qué objeto se está comparando.

Conserve la identidad literal del objeto. Puede incluir orden, operación, lote, material, recurso, estado, unidad y planta si esos campos están disponibles. Guarde el nombre del atributo tal como aparece, el valor consultado, la vista que lo mostró, los filtros y la hora de extracción. Si existe un valor anterior o una marca de versión, regístrelo sin reemplazar el valor visible. Un cambio sin objeto ni contexto es una anécdota, no evidencia que otra persona pueda revisar.

También separe los momentos. La hora en que un usuario abrió un registro no es necesariamente la hora del cambio; la hora del cambio no es la de publicación; la de publicación no equivale a la de recepción o contabilización en ERP. Una línea temporal sencilla puede dejar visibles esas diferencias sin inventar una secuencia.

Bloque	Qué conservar	Pregunta que permite responder
Objeto	ID, atributo, valor, unidad y estado	¿Qué dato exacto se está revisando?
Observación	Consulta, filtros, fecha y zona si existe	¿Qué mostraba cada sistema?
Acción	Evento de cambio, antes/después y origen	¿Qué modificación está realmente documentada?
Acceso	Rol, permiso, cuenta y periodo aplicable	¿Qué capacidad estaba asignada?
Consumo	Interfaz, informe o proceso conocido	¿Quién pudo usar ese dato y con qué límite?

Si falta uno de estos bloques, no rellene el hueco por semejanza de nombres. Puede anotarse “permiso no verificable con las fuentes disponibles” o “consumo pendiente de confirmar”. Es preferible una limitación explícita a una historia convincente que nadie pueda reproducir.

Distinga capacidad, acción y resultado

Un permiso es una capacidad otorgada dentro de una configuración; una acción es un evento que una fuente registra; un resultado es lo que otro sistema muestra o consume. Las tres cosas pueden estar relacionadas, pero no son intercambiables. Una persona puede tener permiso y no usarlo. Una cuenta técnica puede ejecutar un cambio por una automatización autorizada. Un informe ERP puede seguir mostrando una versión anterior sin que MES haya sido alterado.

La norma ISA-95 incluye una parte dedicada a modelos y terminología. La ficha de ISA-95 identifica ese alcance como Part 1: Models and Terminology. No prescribe el nombre local de un rol, un log o un estado. Sirve para establecer un vocabulario antes de mezclar “editar”, “aprobar”, “confirmar”, “publicar” y “contabilizar” como si fueran la misma acción.

En la ficha del caso, etiquete cada observación. Por ejemplo: hecho: una consulta indica que el atributo vale 18; hecho: el informe ERP muestra 12; hecho: el rol R permite editar el atributo según la configuración visualizada; pendiente: no hay registro recuperable que vincule una edición al caso. La etiqueta “pendiente” no acusa ni exculpa a nadie: indica qué fuente debe aportar el propietario.

Evite usar la lista de personas con permiso como lista de sospechosos. Esa lista puede incluir turnos, administradores, cuentas de soporte, automatizaciones o roles heredados. Su difusión innecesaria puede además introducir datos personales donde no hacen falta. Comparta la mínima información necesaria por el canal autorizado y deje que quien gobierna el acceso interprete la pertenencia y vigencia del rol.

Relacione el cambio con el dato que consume ERP

La siguiente pregunta no es “¿quién puede editar?”, sino “¿qué versión del dato llegó, o pudo llegar, al consumidor?”. Un ERP puede recibir una transacción, consultar una réplica, utilizar un proceso intermedio o presentar un total calculado. Sin conocer esa relación, una diferencia entre pantallas no permite concluir que un cambio MES haya causado el resultado.

ISA-95 incluye Part 2: Objects and Attributes for Enterprise-Control System Integration. La descripción pública de la serie enumera esa parte. No confirma qué atributo se intercambia en una interfaz concreta ni valida un mapeo local. La revisión debe buscar esa relación en fuentes internas autorizadas: contrato de interfaz, trazas, catálogo de datos, definición de informe o confirmación del propietario.

Prepare un mapa limitado del recorrido: origen del dato, evento o extracción conocida, identificación de mensaje si existe, destino, punto de aplicación y vista final. Para cada flecha escriba la evidencia disponible y no la explicación que parece probable. “Se observa que la interfaz está configurada” no equivale a “este mensaje transportó este valor”. Una correlación, un identificador de mensaje o una lectura versionada puede ser necesaria para sostener esa conexión.

Si no se puede demostrar el recorrido, la decisión apropiada puede ser pedir una fuente adicional. La salida no tiene que ser una corrección. Puede ser confirmar el atributo, aclarar el modelo de consumo, comprobar una ventana temporal o escalar por impacto. Esta disciplina reduce el riesgo de modificar un dato para alinear dos informes que nunca midieron lo mismo.

Revise el registro disponible sin extrapolarlo

Los registros de auditoría, las trazas de interfaz y las consultas pueden tener alcances distintos. Un registro puede mostrar que una cuenta accedió a una pantalla, que se intentó guardar un valor, que se publicó un evento o que una integración respondió. Ninguna entrada debe leerse fuera de su significado local. Conserve el literal, la fuente, el timestamp y la versión de la configuración que la expone.

La serie ISA-95 incluye una parte sobre actividades de gestión de operaciones de fabricación. ISA-95 la identifica como Part 3: Activities of Manufacturing Operations Management. Esa descripción no asigna aprobadores, no define segregación de funciones y no sustituye reglas de seguridad locales. Es una referencia de alcance, no una autorización para cambiar el gobierno de acceso.

Cuando aparezca una cuenta técnica, pregunte qué proceso ejecuta, quién la administra, qué disparador documentado tuvo y qué objeto afectó. No convierta automáticamente la cuenta en una persona responsable ni suponga que cualquier transacción automática es correcta. El propietario de la automatización debe verificar el contexto con las fuentes correspondientes.

Una revisión equilibrada también busca explicaciones no relacionadas con el permiso: retraso de interfaz, filtro de informe, cambio de estado, unidad distinta, versión de maestro o referencia equivocada. Enumerarlas no implica que sean verdaderas; impide que la búsqueda se cierre en la primera hipótesis. Marque cada una como hipótesis y asigne una evidencia concreta que permitiría confirmarla o descartarla.

Asigne preguntas, no cambios

Una investigación eficaz termina con preguntas pequeñas y un dueño de respuesta. Operaciones puede aclarar el evento físico y la semántica de la operación. IT/OT puede localizar una traza, una versión de integración o un registro técnico. El propietario de datos puede explicar el atributo, la versión o una regla de consumo. Quien gobierna identidades y permisos puede confirmar vigencia, rol y proceso de aprobación. No se pide a un área que declare algo que no controla.

ISA-95 identifica Part 5 como Business-to-Manufacturing Transactions y Part 6 como Messaging Service Model. La página oficial de ISA-95 enumera esas partes. No prueba que una transacción de negocio concreta se haya emitido ni describe el comportamiento de mensajería de esta planta. Por ello, use la referencia para delimitar qué pregunta necesita una traza local, no para afirmar que el mensaje existe.

Una nota de decisión puede decir: “Se observa una diferencia entre dos consultas. El permiso R estaba asignado a la cuenta C en la fuente revisada, pero no se ha verificado una acción de edición del atributo X. Se solicita al dueño del registro confirmar si existe un evento de cambio y al dueño de integración identificar qué versión consumió ERP. No se modifican datos ni accesos mientras la evidencia esté incompleta”. La nota conserva hechos, límites y siguiente paso.

No desactive, cree ni amplíe permisos para comprobar si un flujo funciona. Además de poder interrumpir producción, esa acción altera el contexto que se intenta revisar. Cualquier cambio de acceso o configuración debe pasar por el control, autorización y comprobación definidos por la organización.

Establezca un límite de impacto y escalada

No toda discrepancia tiene la misma consecuencia. Clasifique el impacto potencial por decisión afectada, no por el tamaño visual de la diferencia. Un atributo aparentemente menor puede alterar una orden, una condición de calidad, un movimiento de stock o una salida hacia un cliente. Otro cambio puede limitarse a una pantalla analítica. La clasificación debe describir evidencia disponible y no declarar una criticidad que el revisor no puede establecer.

Use una matriz simple: alcance del objeto, decisión dependiente, evidencia disponible y dueño. Si se desconoce el impacto, escríbalo como incertidumbre y solicite confirmación. Si la evidencia apunta a trazabilidad, liberación de producto, seguridad, inventario, coste, protección de datos o cumplimiento, comunique el caso por el canal establecido antes de hacer compensaciones manuales.

Al cerrar la revisión, conserve la fuente de cada conclusión y la condición de reapertura. Puede cerrarse porque se demostró que dos vistas usan versiones distintas; porque el propietario confirmó un proceso; o porque el caso se escaló. No se cierre por cansancio, por una pantalla que “ya cuadra” o porque el permiso se retiró. Una comprobación posterior sobre un caso comparable ayuda a saber si la explicación era sostenible.

Mantenga una versión verificable del expediente

El expediente debe distinguir lo que se extrajo en una fecha de lo que se averiguó después. Añada una entrada cuando aparezca una nueva traza, una definición de rol o una explicación del consumidor ERP; no reemplace sin rastro la observación inicial. Cada entrada puede indicar fuente, hora de consulta, autor de la nota y relación con la pregunta pendiente. Así, una revisión posterior puede entender por qué la prioridad o la conclusión cambiaron.

No hace falta copiar datos que el destinatario ya puede recuperar, pero sí dejar una referencia autorizada y los filtros necesarios. Si la evidencia queda en una herramienta restringida, indique quién puede verificarla y mediante qué proceso. Separar expediente y resumen ayuda a que el equipo directivo vea la decisión pendiente sin perder la trazabilidad que necesita el especialista.

Antes de declarar una conclusión, pida una comprobación independiente de una fila relevante: objeto, valor, unidad, estado, fuente y permiso mostrado. La segunda persona no tiene que repetir toda la investigación; debe poder detectar una transcripción o una equivalencia incorrecta. Si encuentra un error, actualice la nota con una versión nueva y preserve el motivo del cambio. Esta práctica protege tanto a las personas observadas como a quienes deben tomar una decisión sobre el dato.

Aplique salvaguardas durante la comprobación

La revisión de permisos puede crear riesgos si se convierte en una exploración amplia de cuentas o pantallas. Empiece con el mínimo alcance necesario para responder la pregunta documentada. Si el caso se limita a una operación y un atributo, no recopile el historial completo de una persona ni exporte roles de toda la planta. Limitar el expediente reduce exposición de datos, evita inferencias impropias y hace más fácil que otro revisor confirme qué se examinó realmente.

Conserve el valor original y la fuente incluso cuando una persona autorizada confirme una explicación. Una explicación verbal puede orientar la investigación, pero no reemplaza el registro que permite identificar la versión, el objeto y la hora. Si la fuente no puede compartirse, anote el propietario que la verificó, el canal autorizado y la limitación de acceso. No sustituya esa limitación por una captura sin contexto o por una conclusión más amplia de lo que la fuente permite.

Tenga especial cuidado con los cambios que parecen cosméticos. Un comentario, una unidad mostrada, un estado intermedio o una referencia puede alimentar un informe posterior aunque el dato no cambie el resultado de la pantalla actual. Pregunte qué consumidor utiliza el atributo y con qué versión. Si nadie puede demostrarlo, el resultado debe ser una pregunta asignada, no la afirmación de que el atributo carece de impacto.

La investigación tampoco debe usar un permiso de emergencia como experimento. Cambiar de rol, reproducir una edición con privilegios o desactivar una cuenta puede modificar registros, detener un flujo o borrar el contexto de la evidencia. Si se requiere una prueba técnica, documente su objetivo, el entorno, la autorización, los datos protegidos y la comprobación prevista antes de ejecutarla. Esa decisión corresponde al proceso local de cambio y seguridad, no a quien prepara esta guía.

Finalmente, comunique la incertidumbre de forma operativa. En lugar de escribir “no se sabe quién modificó el dato”, indique “el expediente contiene una capacidad de edición, pero falta un evento que vincule la acción al atributo; el dueño del registro debe confirmar si la fuente conserva ese evento”. Este lenguaje evita atribuciones injustificadas y permite que el caso avance hacia una evidencia verificable.

ISA-95 identifica Part 5 como Business-to-Manufacturing Transactions y Part 6 como Messaging Service Model. Esta referencia no prueba una transacción, un permiso ni un mensaje local; solo delimita el vocabulario que debe contrastarse con las fuentes autorizadas de la instalación.

Preguntas frecuentes

¿Ver un permiso de edición demuestra que se modificó el dato?

No. Demuestra, como mucho, una capacidad asignada en una configuración o periodo determinado. Para atribuir una acción hacen falta registros, fuente, momento, objeto y el proceso local que interprete esa evidencia.

¿Debo retirar el permiso si encuentro una discrepancia?

No desde esta revisión. Retirar o cambiar permisos puede interrumpir operaciones y alterar la evidencia. Preserve el caso y remítalo al propietario autorizado mediante el procedimiento aplicable.

¿Qué datos debo guardar al detectar un cambio?

El identificador del objeto, valor anterior y posterior si están disponibles, unidad, estado, marcas temporales, consulta, usuario o cuenta mostrada, rol, origen del permiso y sistemas o informes que consumen el dato.

¿Una cuenta técnica puede ser la responsable del cambio?

Puede aparecer como ejecutora técnica, pero no permite por sí sola asignar una decisión a una persona o equipo. Hay que revisar el contexto, la trazabilidad disponible y la propiedad local de la automatización.

¿Cuándo debe escalarse el caso?

Cuando el dato pueda afectar trazabilidad, liberación, inventario, coste, seguridad, protección de datos, cumplimiento o una decisión fuera del mandato del revisor.