Cuando MES y ERP intercambian información, el desacuerdo rara vez empieza con un protocolo. Suele empezar con una frase como “necesitamos que la orden llegue igual” o “el ERP debería saber lo que ya produjo la línea”. Detrás hay preguntas sin responder: qué significa la orden en cada sistema, cuándo se considera terminada, qué unidad se comparte y para qué decisión se quiere usar el resultado.

Un contrato de datos documental hace visibles esas preguntas antes de convertirlas en un proyecto técnico. No promete que los sistemas vayan a sincronizarse, ni asegura que una integración sea apropiada. Describe un acuerdo de significado: qué se espera de un campo, con qué límites puede leerse y quién debe aclararlo cuando el proceso cambie.

Esta guía no contiene instrucciones para configurar MES, ERP, middleware, redes, cuentas o interfaces. Tampoco autoriza una conexión ni una modificación de registros. Está pensada para preparar una conversación entre operaciones, planificación, datos y responsables autorizados sin presentar una necesidad de negocio como una solución ya aprobada.

Empiece con una decisión y un objeto compartido

La ficha debe abrir con una decisión concreta. Puede ser comparar producción registrada con una orden, preparar una revisión de cumplimiento de plan o entender por qué una cantidad no coincide entre dos informes. Ese propósito limita el contrato. No hace falta pedir todos los campos que existen en MES y ERP para responder una pregunta acotada.

Después nombre el objeto que se está siguiendo. Una orden, una operación, un lote, una unidad de producción o un estado de confirmación pueden parecer términos simples, pero cada sistema puede usarlos de forma distinta. Anote el nombre local, la definición conocida y el responsable que puede confirmar su significado. Si el significado está pendiente, el contrato debe decirlo.

NIST SP 800-82 Rev. 3 es la fuente primaria citada para el contexto de tecnología operativa. La guía se titula “Guide to Operational Technology (OT) Security” y la publica el National Institute of Standards and Technology. No define el contrato de una planta ni autoriza una integración entre sus sistemas.

Prepare una ficha de campo antes de preparar una interfaz

Una ficha de campo puede tener ocho columnas: nombre local, sistema donde se observa, definición de negocio, unidad o formato, ventana temporal, estado posible, responsable y uso permitido. Añada una novena para dudas o excepciones. Con este nivel de detalle, una persona puede detectar si “cantidad” significa contador de máquina, producción confirmada, inventario contabilizado o una cifra derivada.

El campo debe conservar su contexto. “Cantidad: 120” no permite comparar nada. “Unidades confirmadas en una operación durante una ventana declarada” ya establece una base para preguntar. Si se desconoce el estado, no complete la fila con un término genérico. El estado puede ser la diferencia entre una señal para seguimiento y un dato apto para un cierre administrativo.

No use la ficha para exponer identificadores sensibles o detalles técnicos que una reunión de negocio no necesita. Puede referirse a una fuente interna reconocible y a su responsable. La documentación debe mejorar la interpretación sin ampliar innecesariamente la exposición de sistemas OT.

Separe la equivalencia de nombres de la equivalencia de significado

MES y ERP pueden tener campos llamados “orden”, “lote” o “cantidad” que no son equivalentes. Uno puede representar una instrucción de fabricación y otro una referencia administrativa. Uno puede consolidar varias operaciones y otro esperar una confirmación final. Forzar un mapeo porque las etiquetas coinciden produce errores difíciles de explicar después.

Para cada pareja propuesta, escriba una pregunta de equivalencia: ¿ambos campos representan la misma entidad?, ¿usan la misma unidad?, ¿se actualizan ante el mismo evento?, ¿incluyen la misma población? Si alguna respuesta es no o pendiente, mantenga los campos separados. La decisión puede requerir una transformación posterior, pero el contrato debe empezar por reconocer la diferencia.

Una relación uno a muchos merece una línea propia. Una orden de ERP puede abarcar varias operaciones de MES; un registro de MES puede asociarse a más de un elemento administrativo. La cardinalidad no es un detalle técnico menor. Determina si una suma, una comparación o una investigación puede interpretarse sin perder casos.

NIST describe OT como sistemas y dispositivos programables que interactúan con el entorno físico o gestionan dispositivos que lo hacen. El texto está en la publicación de NIST. Esto aporta contexto para tratar con prudencia las rutas de información industrial; no prueba que dos objetos de datos locales tengan el mismo significado.

Declare el momento de cada estado

Un contrato se debilita cuando dice que un campo está “actualizado” sin explicar respecto a qué. Registre qué evento hace que un dato aparezca en MES, qué condición lo vuelve visible en ERP y qué corte usa cada informe. Una cantidad puede existir en una fuente y no estar lista para el uso que otra fuente representa. Esa diferencia no debe esconderse bajo la palabra sincronización.

También indique si un estado puede cambiar. Una confirmación provisional puede revisarse; una orden puede reabrirse; una clasificación puede llegar después del evento. El contrato no necesita decidir la política de cada sistema. Debe avisar a quien consume el dato de que una lectura puntual puede no ser el final del proceso.

Si la hora o el corte son desconocidos, diga qué decisión queda afectada. Por ejemplo, la cifra puede servir para preparar una pregunta de turno, pero no para confirmar un cierre de inventario. Esta precisión evita que la urgencia tome una nota de trabajo y la convierta en una afirmación administrativa.

Escriba las reglas de asociación como hipótesis comprobables

Un identificador compartido puede relacionar objetos, pero no demuestra por sí solo que la relación sea completa. La ficha debe decir qué campo enlaza, qué ocurre cuando falta, qué sucede si hay duplicados y quién puede revisar los casos no asociados. No rellene filas con coincidencias por fecha aproximada o por una descripción parecida sin marcarlas como hipótesis.

Una regla de asociación puede ser útil aunque no cubra todos los casos. Entonces el contrato debe indicar cobertura observada, población excluida y destino de las excepciones. La transparencia permite que el equipo use la relación dentro de sus límites. Una unión aparentemente total puede ocultar precisamente los casos que más importan en calidad, trazabilidad o planificación.

Conserve una pregunta para cada regla sin evidencia: “confirmar si una operación puede contribuir a dos órdenes” o “confirmar el tratamiento de una orden reabierta”. La lista no es un fallo del contrato. Es su parte más útil, porque convierte incertidumbre informal en trabajo asignable.

Incluya el uso permitido y el uso que queda fuera

El campo no adquiere todos los usos por estar disponible. Una cantidad puede apoyar una revisión operativa y no un compromiso contractual. Una referencia de orden puede ayudar a localizar evidencia y no validar un inventario. Escriba ambos límites en lenguaje directo para que el lector sepa qué conversación puede sostener con el dato.

La separación protege a los equipos. Operaciones no tiene que prometer que un dato sirve para una auditoría por haberlo usado en un turno. IT u OT no tiene que aprobar una conexión por haber aclarado una ruta. El contrato describe la necesidad de información y deja los cambios, permisos y controles al proceso que tiene autoridad sobre ellos.

NIST SP 800-82r3 aborda acceso, arquitectura, activos, datos y seguridad de OT. Consulte la fuente original. Ese alcance no ofrece una plantilla de integración ni una autorización técnica. Refuerza que una decisión sobre datos industriales debe considerar sus límites de operación y protección.

Trate las excepciones como parte normal del contrato

Una orden cancelada, una corrección posterior, un lote sin asociación o una parada de proceso pueden producir casos que no encajan en la regla principal. No deje estas situaciones en una nota al margen. Añada una sección de excepciones con condición observada, efecto sobre la interpretación, responsable de la aclaración y siguiente revisión.

No es necesario resolver cada excepción durante la redacción. Es mejor escribir “no usar para conciliación hasta confirmar el tratamiento de reproceso” que inventar un comportamiento para que el documento parezca cerrado. El contrato puede avanzar cuando sus límites son visibles; una integración no debería avanzar basándose en supuestos no registrados.

Cuando la excepción implica una modificación de datos, una apertura de acceso, una conexión o un cambio de configuración, detenga la ficha en la descripción del caso. Remítalo a los responsables autorizados. Intentar resolverlo desde un contrato documental puede dañar trazabilidad o eludir controles que existen por una razón.

Revise el contrato cuando cambie el proceso

El contrato debe llevar fecha, versión y responsable de la revisión. Un cambio de producto, de definición, de estado de orden, de cálculo o de propietario puede dejarlo obsoleto aunque los campos conserven el mismo nombre. La versión permite que una conversación futura sepa con qué significado se utilizó una cifra anterior.

La frecuencia de revisión depende de su uso. Un campo que alimenta una lectura diaria necesita al menos un evento claro de revisión, como una modificación del proceso. Un contrato para una investigación puntual puede cerrarse con la decisión y conservar el alcance. No hay una cadencia universal que sustituya el conocimiento del riesgo y del proceso local.

La publicación de NIST fue emitida en septiembre de 2023 por el National Institute of Standards and Technology. Vea NIST SP 800-82r3. La cita identifica la fuente primaria utilizada; no acredita que una ficha local esté completa, ni certifica la disponibilidad o seguridad de una interfaz.

Ejemplo de contrato de una sola página

Una organización quiere revisar una diferencia entre unidades de MES y una orden de ERP. El propósito puede ser “preparar una pregunta de conciliación”, no corregir un registro. La ficha identifica la operación de MES, la orden de ERP y las cantidades mostradas. Declara que la equivalencia de unidad está confirmada, pero que el tratamiento de una corrección posterior sigue pendiente.

El uso permitido puede ser comparar tendencias y localizar una diferencia. El límite puede decir que no se usa para aprobar una corrección de inventario. La excepción anota que una orden reabierta no tiene todavía una regla confirmada. Con esa página, la reunión sabe qué preguntar y evita que un número sea tratado como sentencia final.

Para revisar el resultado, conserve la evidencia de cada definición, el corte de ambas fuentes y la persona que puede explicar la regla. Si una pregunta cambia, cree una nueva versión. Reutilizar una ficha antigua para un propósito nuevo es una forma común de convertir una documentación correcta en una conclusión mal aplicada.

Aclare quién puede cambiar cada término del acuerdo

Un contrato no necesita crear una estructura de gobierno nueva, pero sí debe evitar que los términos cambien sin aviso. Para cada definición relevante, identifique la función que puede explicar el significado actual y la función que debe ser consultada cuando se proponga una modificación. No asuma que la persona que mantiene una plataforma decide el propósito de negocio de un campo.

La responsabilidad puede ser distinta para una orden, una cantidad y un estado. Operaciones puede entender el evento de producción; planificación, el uso de una orden; calidad, el alcance de una clasificación. La ficha debe reflejar esta distribución aunque no resuelva todas las responsabilidades. Una línea con “pendiente de responsable funcional” es preferible a una autoridad inventada.

Incluya una forma de avisar de cambios sin convertir el documento en un directorio de contactos. Puede ser una referencia al procedimiento, un equipo responsable o una revisión programada. El contrato ayuda a reconocer que una modificación de definición puede afectar informes y decisiones aguas abajo. No autoriza a nadie a hacer esa modificación.

Pruebe el contrato con un caso de borde

Un campo parece claro hasta que aparece una orden anulada, una producción de prueba, un reproceso o una corrección posterior. Elija un caso de borde conocido y recorra la ficha: qué valor muestra MES, qué valor muestra ERP, qué estado conserva cada uno y qué uso queda limitado. Si no se puede responder, el contrato ha localizado una incertidumbre importante.

El caso de borde no tiene que convertirse en una simulación técnica. Puede ser una pregunta de negocio: “¿cómo se interpreta una cantidad cuando la orden se reabre?”. La respuesta puede ser “pendiente”. Ese resultado evita que una regla principal se aplique a una excepción de forma silenciosa y después produzca una discrepancia difícil de rastrear.

No cambie datos para que el ejemplo encaje. Conserve el caso tal como fue observado y pida que el proceso competente determine si necesita corrección, exclusión o una nueva definición. El contrato documental explica el impacto en la interpretación; no ejecuta la resolución.

Diferencie disponibilidad de autorización de uso

Que un campo sea visible para un equipo no significa que pueda copiarse, combinarse o utilizarse para cualquier propósito. El contrato debe indicar el uso previsto y no extenderlo por conveniencia. Una referencia disponible para seguir una orden puede no ser apropiada para evaluar desempeño individual, comprometer entregas o sustentar una decisión de cumplimiento.

La distinción es especialmente importante cuando se solicita una nueva conexión o extracción. El contrato puede demostrar que existe una necesidad de significado y trazabilidad. No sustituye la revisión de acceso, seguridad, privacidad, retención ni arquitectura. Esas evaluaciones pertenecen a los responsables que la organización haya designado.

La guía de NIST sitúa la tecnología operativa dentro de consideraciones de seguridad y operación. Consulte NIST SP 800-82r3. La referencia no concede acceso, no aprueba una interfaz y no define la autorización de uso de un dato local.

Prepare una revisión breve y repetible

Antes de cerrar la ficha, pida a una persona que no participó en su redacción que responda cinco preguntas: qué objeto representa el campo, de qué sistema procede, qué corte tiene, para qué se puede usar y qué excepción queda abierta. Si la respuesta requiere interpretación oral, el contrato necesita más precisión. Si se responde con una frase por punto, ya puede servir de base para la siguiente conversación.

Registre la fecha y el alcance de esa revisión, no una aprobación genérica. La revisión confirma que el documento fue leído para una necesidad concreta. No confirma que una arquitectura, una interfaz o un control técnico hayan sido evaluados. Mantener esa separación evita que una ficha de negocio se use como evidencia de autorización técnica.

Conserve versiones anteriores cuando la definición cambie. Un informe histórico puede necesitar saber por qué un campo dejó de ser comparable después de una fecha. El historial no es un archivo ornamental: permite explicar decisiones pasadas sin pedir al equipo que reconstruya meses de contexto desde capturas y recuerdos.

Límites y siguiente paso

Esta guía no configura MES, ERP, APIs, colas, cuentas, redes ni permisos. No evalúa controles de seguridad, no garantiza exactitud, no aprueba cambios y no sustituye responsabilidades de calidad, inventario, privacidad, cumplimiento, continuidad o ciberseguridad. Los cambios técnicos o administrativos deben seguir los procesos autorizados de la organización.

El siguiente paso es elegir un objeto compartido y completar una ficha de tres campos, no una integración completa. Añada propósito, definición, corte, estado, responsable y límite de cada uno. Revise después una excepción conocida con el propietario funcional. Para una diferencia de cantidades, consulte cómo conciliar contadores de línea con unidades de ERP.

Preguntas frecuentes

¿Un contrato de datos es una especificación técnica?

Puede informar una especificación posterior, pero esta ficha se centra en significado, propósito, responsables y límites de uso. No define protocolos, credenciales, rutas, interfaces ni configuraciones de sistemas.

¿Debo incluir campos que todavía no están confirmados?

Sí, si la necesidad depende de ellos. Marque su estado como pendiente, describa la pregunta abierta y asigne quién debe confirmarla. Excluirlos puede hacer parecer completo un acuerdo que todavía tiene una dependencia crítica.

¿Qué hago si MES y ERP usan la misma palabra con distinto significado?

Mantenga dos definiciones y no las unifique por el nombre. Indique el sistema, el propósito, la unidad, el estado y la ventana de cada una. La coincidencia de etiqueta no demuestra equivalencia de negocio.

¿El contrato demuestra que la interfaz es segura?

No. La seguridad, arquitectura, cuentas, segmentación y controles se revisan por los procesos autorizados. El contrato ayuda a formular la necesidad de información, pero no es una evaluación de seguridad.

¿Cuándo debe revisarse el contrato?

Cuando cambie una definición, un estado de proceso, una regla de asociación, el uso previsto o la persona responsable. También conviene revisarlo antes de reutilizar un campo para una decisión distinta de la que motivó su documentación.