Cuando MES, planificación y un informe de dirección muestran cifras distintas de capacidad, la discusión suele empezar por la herramienta. Antes conviene preguntar quién gobierna el dato. «Capacidad» puede significar horas programadas, capacidad nominal, ventana disponible, capacidad comprometida o salida buena bajo una receta. Cada definición necesita una autoridad, una unidad y una condición de uso.
Ownership no es solo administrar una tabla. El owner decide qué significa el dato, en qué decisiones se puede usar, qué cambios requieren aprobación y cómo se resuelven excepciones. El steward mantiene el catálogo, la calidad y las incidencias bajo ese mandato. IT puede operar la plataforma; OT puede conservar la señal de control; operaciones puede decidir la definición; dirección puede aprobar el uso en un comité. Esas funciones no deben quedar implícitas.
Esta página está pensada para responsables IT/OT y de operaciones que deben ordenar un dato de capacidad antes de incluirlo en un KPI. Para un inventario de fuentes consulte mapear fuentes de datos para un informe de producción y la guía de acceso a datos IT/OT industriales. Ninguna de las piezas certifica la arquitectura, la seguridad o la capacidad de una instalación.
Para completar el gobierno, contraste identificar la fuente autoritativa para un KPI y revisar la calidad de los datos antes de una capa de lectura. Son controles de linaje y calidad; no reemplazan la asignación explícita del owner de este dato de capacidad.
1. Defina el uso antes de nombrar al dueño
Escriba la pregunta que el dato debe responder: «¿qué ventana de capacidad disponible puede comprometer planificación para la familia F?» no es la misma que «¿qué producción ejecutó la línea L?». Registre use_case, decision_owner, audience, decision_frequency y out_of_scope. El owner se elige por la responsabilidad sobre esa decisión, no por quién tiene más acceso a la base.
Un mismo nombre puede necesitar varios productos de datos. available_capacity para secuenciar órdenes puede tener una ventana horaria y un calendario; effective_capacity para revisar una campaña puede incluir calidad, material y mantenimiento; nominal_capacity puede venir de ingeniería. No fusione esos conceptos para obtener una columna «capacidad total». Si se relacionan, documente la transformación y el límite.
2. Describa el dato campo por campo
Use un catálogo con data_product_id, field_name, definición, unidad, población, ventana, fórmula, estado de calidad, fuente, owner y steward. Añada version, effective_from, expires_at, last_reviewed_at y change_reason. Un owner de «capacidad» sin una definición de campo no puede arbitrar una discrepancia.
La unidad debe ser inequívoca. Horas planificadas, unidades buenas, lotes, kg y minutos equivalentes no son intercambiables. Anote la zona horaria y el cierre: una ventana local de turno puede no coincidir con el día contable o con la semana de planificación. Si el dato mezcla fuentes, indique qué campo procede de cuál y dónde se ejecuta la transformación.
Incluya ejemplos de valores válidos y de valores bloqueados. capacity_status=available no debe aceptar una fila cuyo calendario esté cerrado por mantenimiento. quality_status=unknown no debe aparecer como released. Los ejemplos actúan como pruebas de contrato y ayudan al steward a detectar cambios de esquema.
3. Asigne owner, steward y custodio técnico
El owner responde por significado, alcance, aprobación y excepciones. El steward mantiene metadatos, controles de calidad, incidencias y documentación diaria. El custodio técnico opera almacenamiento, acceso, copias y observabilidad. El consumidor decide si la evidencia es suficiente para su informe. Una matriz simple evita que las cuatro funciones se escondan detrás de un solo correo.
| Función | Responsabilidad | No debe decidir por sí sola |
|---|---|---|
| Owner de negocio | Definición, uso, límites y aprobación | Seguridad técnica o retención de logs |
| Steward | Catálogo, calidad, lineage y tickets | Cambiar el significado sin el owner |
| Custodio IT/OT | Plataforma, interfaces, acceso y monitorización | Declarar capacidad operativa |
| Consumidor | Usar el dato dentro del contrato | Convertir una señal en política |
| Comité de escalado | Resolver conflictos de definición | Corregir una fuente sin evidencia |
Un owner puede ser un rol y no una persona. Guarde owner_role, owner_team, suplente y horario de escalado. Si el rol desaparece, el dato pasa a ownership_pending hasta que una autoridad lo reasigne. No deje una cuenta personal como única referencia de un KPI crítico.
4. Mapee niveles y fuentes sin declarar conformidad
ISA describe niveles, objetos e intercambios entre control y empresa; usar para mapear responsabilidades, no para afirmar que una integración cumple ISA-95. ISA-95, resumen El modelo ayuda a ubicar dónde nace una señal, dónde se transforma y quién la consume. No certifica la arquitectura local ni garantiza que un ERP y un MES compartan una definición.
OPC UA especifica modelos de información, mensajes, comunicación y conformidad para interoperabilidad; no prueba calidad ni latencia de una instalación. OPC UA Part 1 El protocolo puede formar parte del recorrido, pero la frescura, pérdida, duplicación y semántica requieren pruebas. Registre endpoint, perfil, marca de tiempo y transformación, no solo «usa OPC UA».
Para cada campo, dibuje source_system, source_tag o tabla, transformación, destino y consumidor. Si dos fuentes declaran ser autoritativas, no elija la que tenga más filas. Compare definición, cobertura, unidad y momento de cierre; luego eleve el conflicto al comité.
5. Ponga controles de calidad y frescura
Defina reglas de completitud, unicidad, rango, continuidad, unidad, cierre y frescura. Registre quality_rule_id, umbral, frecuencia, resultado, owner de la regla y quality_status. Un dato puede ser completo y aun así usar la unidad equivocada. Un dato fresco puede estar duplicado. No reduzca calidad a un único porcentaje.
Use estados como valid, warning, stale, unknown, blocked y superseded. La regla de cada estado debe estar publicada. warning puede entrar en un análisis exploratorio si el consumidor lo acepta; blocked no debe alimentar un KPI de dirección. Guarde la evidencia de la comprobación y el momento en que se ejecutó.
La nota publica analítica de datos, cloud e IA por sector; esos porcentajes son contexto de digitalización, no evidencia de rendimiento industrial. INE, encuesta TIC La estadística no identifica qué planta tiene un owner, una señal MES o una calidad de datos concretas. Úsela para contexto, no para justificar la madurez de un dato local.
6. Documente acceso, seguridad y escalado
El catálogo debe indicar quién puede leer, escribir, aprobar y exportar cada campo. Separe acceso de ownership: que un administrador pueda escribir no significa que pueda cambiar la definición. Registre read_role, write_role, approve_role, export_policy, retention y audit_log_location.
ENISA aporta ejemplos de evidencias y mapeos técnicos para requisitos NIS2; útil como checklist IT/OT, no como certificación. ENISA, guía técnica NIS2 La guía tiene un alcance europeo y requiere revisar la transposición y el sector aplicable. No declare cumplimiento por tener un ticket o un catálogo.
Un escalado debe definir severidad, tiempo de respuesta, dominio y autoridad. definition_conflict puede ir al comité de datos; stale_signal al custodio; quality_release a calidad; capacity_commitment a planificación y operaciones. Registre el ticket, la evidencia y la decisión. El steward no debe resolver solo un conflicto que cambie el significado de capacidad.
7. Trate cambios de esquema y de significado
Una columna nueva puede ser un cambio compatible o una definición distinta. Use schema_version, semantic_version, migration_owner, compatibility_window y deprecation_date. Si la receta, calendario o regla de capacidad cambia, el owner debe decidir si la versión anterior se conserva, se convierte o se retira.
La hoja 2026 señala integración heterogénea, gestión de big data y operación confiable/explicable como retos. NIST, roadmap AI/ML 2026 Es una hoja de ruta de investigación, no una prueba de ROI ni un despliegue español. La cita ayuda a recordar que la heterogeneidad y la capacidad de explicar resultados son problemas de diseño, no excusas para ocultar ownership.
Cuando cambie el esquema, ejecute una prueba de regresión con datos históricos y anote quién aprobó la compatibilidad. Si no puede conservar la comparabilidad, marque break_in_series y publique un nuevo producto de datos. No corrija la historia silenciosamente.
8. Prepare una decisión con evidencia local
NIST desarrolla métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos para evaluar mejoras y trade-offs. NIST, medición orientada a operaciones La metodología recuerda que hay que caracterizar el sistema y seleccionar métricas; no asigna el owner de una planta. La evidencia local debe incluir fuente, unidad, ventana y estado de cierre.
La decisión puede concluir owner_assigned, shared_ownership, ownership_pending, definition_conflict o blocked. Cada estado necesita motivo, owner temporal, próximo paso y fecha. shared_ownership no significa que nadie responda: enumere qué rol decide cada parte y quién arbitra un desacuerdo.
NIST define el gobierno de información manufacturera como principios para procesar y usar datos de forma consistente, repetible y confiable. NIST, information governance La idea es metodológica. El contrato local debe convertirla en nombres, reglas, revisiones y evidencias sin afirmar certificación.
9. Contrato de ownership
data_product_id, field_name, definition, unit, population
use_case, decision_owner, data_owner, steward, custodian
source_system, source_locator, lineage, transform_version
window_start, window_end, timezone, closure_state
quality_rules, quality_status, freshness_sla, last_checked_at
read_role, write_role, approve_role, retention, audit_location
schema_version, semantic_version, effective_from, expires_at
escalation_path, severity, review_due, evidence_hashPruebe el contrato con un cambio de turno, una orden abierta, una señal retrasada y una discrepancia entre MES y planificación. El resultado debe mostrar quién decide cada caso. Si el campo no tiene fuente, unidad o owner, marque ownership_pending y déjelo bloqueado para el informe directivo.
11. Dibuje el recorrido de una señal
Empiece por el punto en que nace el dato: sensor, PLC, registro de orden, calendario, hoja de calidad o sistema de mantenimiento. Anote origin_locator, marca de tiempo y unidad original. Después enumere cada transformación hasta el informe: normalización, agregación, conversión de unidad, unión de órdenes o cálculo de ventana. En cada salto, indique el owner del significado y el custodio técnico.
El recorrido debe mostrar qué pasa cuando una señal falta o llega dos veces. missing_policy, duplicate_policy, late_event_policy y replay_policy son decisiones de gobierno. No las esconda en el código. Un steward puede comprobar que se aplican; solo el owner puede aceptar que una ausencia se interprete como cero, desconocido o bloqueo.
Cuando un dato cruza IT y OT, defina un límite de responsabilidad. OT puede conservar la integridad y el tiempo de una señal de control; IT puede transformar y servirla; operaciones decide si la señal sirve para un KPI. Ningún equipo debería afirmar por sí solo que el dato representa capacidad efectiva. La definición depende de la receta, el calendario, el estado de calidad y la decisión.
12. Resuelva conflictos con una matriz de usos
Dos áreas pueden usar la palabra «capacidad» de forma correcta para sus preguntas y aun así necesitar productos distintos. Cree una matriz de usos:
| Uso | Definición | Fuente principal | Owner | Límite |
|---|---|---|---|---|
| Secuenciar órdenes | Ventana disponible por recurso y calendario | Planificación + MES | Operaciones | No estima salida buena |
| Revisar ejecución | Tiempo y cantidad cerrados | MES + calidad | Operaciones | No compromete demanda futura |
| Informar a dirección | Métrica versionada y agregada | Producto de datos | Dirección | No sustituye el detalle local |
| Analizar activo | Estado técnico y mantenimiento | OT + mantenimiento | Ingeniería | No es calendario de órdenes |
La matriz no crea una jerarquía automática. Sirve para decidir qué fuente responde a cada pregunta y quién arbitra cuando una columna se reutiliza fuera de su alcance. Si dirección pide una cifra única, muestre las definiciones y el motivo por el que no se pueden fusionar, en lugar de elegir la más cómoda.
13. Revise el ownership en una cadencia fija
Un owner que solo aparece cuando hay una incidencia no está gobernando el dato. Defina una cadencia: revisión mensual de definición y calidad, revisión trimestral de acceso y linaje, y revisión extraordinaria cuando cambie una receta, un calendario, una interfaz o una obligación de seguridad. Registre review_cadence, last_reviewed_at, next_review_at y trigger_event.
La revisión debe incluir consumidores reales. Pregunte qué decisiones tomaron con el dato, qué excepciones encontraron y qué campos dejaron de ser útiles. Si la respuesta cambia, actualice el contrato y el versionado. No archive un conflicto como «error de usuario» sin revisar si la definición era suficientemente clara.
Cuando el owner no responde dentro del plazo, escale según el rol y el impacto. severity=low puede esperar una revisión de catálogo; severity=high debe bloquear el KPI que podría provocar una decisión irreversible. El escalado debe conservar evidencia, no solo un recordatorio. Si el dato sigue sin dueño, muéstrelo como ownership_pending y no lo presente como fuente autoritativa.
14. Proteja el vínculo entre calidad y uso
La calidad del dato no es un atributo decorativo. Una señal con latencia desconocida puede servir para análisis histórico y no para comprometer producción en tiempo real. Un campo sin unidad puede servir como identificador y no como cantidad. Registre allowed_use, blocked_use y quality_evidence para que el consumidor entienda la frontera.
El owner debe aceptar explícitamente los usos y sus límites. El steward puede detectar una desviación y abrir un ticket, pero no ampliar el uso por su cuenta. El custodio puede mejorar la disponibilidad técnica sin convertir un dato experimental en una métrica oficial. Esta separación protege a IT/OT de reclamaciones que corresponden a una decisión de negocio y protege a operaciones de una cifra sin contexto.
Si el dato alimenta un dashboard compartido, muestre también su estado de ownership y la fecha de revisión. Una etiqueta pequeña como owner=operations, quality=warning o review_due=2026-09-01 evita que una tarjeta parezca más definitiva de lo que es. El enlace al catálogo debe llevar a la versión exacta usada en la consulta. Cuando el dashboard se exporte, conserve el hash y el alcance para que otra persona pueda reproducir la lectura.
10. Pasajes verificables de las fuentes
La nota publica analítica de datos, cloud e IA por sector; esos porcentajes son contexto de digitalización, no evidencia de rendimiento industrial. INE, encuesta TIC
ISA describe niveles, objetos e intercambios entre control y empresa; usar para mapear responsabilidades, no para afirmar que una integración cumple ISA-95. ISA-95, resumen
OPC UA especifica modelos de información, mensajes, comunicación y conformidad para interoperabilidad; no prueba calidad ni latencia de una instalación. OPC UA Part 1
La hoja 2026 señala integración heterogénea, gestión de big data y operación confiable/explicable como retos. NIST, roadmap AI/ML 2026
ENISA aporta ejemplos de evidencias y mapeos técnicos para requisitos NIS2; útil como checklist IT/OT, no como certificación. ENISA, guía técnica NIS2
Preguntas frecuentes sobre ownership de capacidad
¿El dueño de un dato es siempre el equipo IT?
No. El dueño decide el significado, el alcance y el uso autorizado; puede estar en operaciones, ingeniería, calidad, planificación o IT según el dato. IT puede operar la plataforma sin decidir qué significa capacidad.
¿Qué diferencia hay entre owner y steward?
El owner tiene autoridad sobre la definición, las reglas y las excepciones. El steward mantiene metadatos, calidad, catálogo y seguimiento diario bajo ese mandato. Una persona puede asumir ambos papeles si se documenta.
¿Una fuente MES es automáticamente autoritativa para capacidad?
No. MES puede ser autoritativo para eventos de ejecución y no para demanda, calendario, costes o capacidad comprometida. Defina la autoridad por campo, estado y decisión.
¿ENISA NIS2 certifica el ownership de datos industriales?
No. ENISA aporta ejemplos de evidencias y mapeos técnicos para requisitos NIS2. Es una guía, no una ley española ni una certificación de una arquitectura o un proceso de datos.
¿Qué hago si dos áreas reclaman el mismo dato?
Conserve ambas definiciones, describa sus usos y eleve la discrepancia al órgano de gobierno que tenga autoridad. No elija una fuente por conveniencia ni fusione columnas con unidades o ventanas distintas.